LN Markets - 404 Not Found

[Bryn]

LN Markets:
I recently installed the LN Markets app. For the last couple days I have been receiving a 404 Page Not Found error when trying to login.

I was using my Umbrel node to login directly without credentials. Please see pictures attached.

Running the logs through Grok, it seems LN Markets app is unable to communicate with the Lightning Network Daemon (LND) because the wallet is either not started or locked:

Initial Error: Error: 2 UNKNOWN: waiting to start, RPC services not available (seen at Jul 10 06:56:55).
Subsequent Errors: Error: 2 UNKNOWN: wallet locked, unlock it to enable full RPC access (repeated multiple times).

Lightning Node:
Importing my Lightning Node’s 24 word seed into my BlueWallet mobile app shows transactions started differing around 7 days ago.

BlueWallet shows a withdrawal of 26,889 sats and no other transactions, while my Lightning Node shows a withdrawal of 25,960 sats. Most recently I tried withdrawing 4,656 sats but this never arrived into my Muun wallet.

BlueWallet Screenshot
Lightning Node Screenshot

[gasgar8859]

I have the same issue . I would love to know if you found a solution to this problem.

[Bryn]

Attached is the full LN Markets logs.
umbrel_lnmarkets_2025-07-10_18-25.log.txt (29.3 KB)

[oconical]

They created their proxy with JSNode incorrectly. But this is known since 2011 not to do this.

[DEP0123] DeprecationWarning: Setting the TLS ServerName to an IP address is not permitted by RFC 6066. This will be ignored in a future version.

Looking at the notes behind RFC6066

TLS does not provide a mechanism for a client to tell a server the
name of the server it is contacting. It may be desirable for clients
to provide this information to facilitate secure connections to
servers that host multiple ‘virtual’ servers at a single underlying
network address.

In order to provide any of the server names, clients MAY include an
extension of type “server_name” in the (extended) client hello. The
“extension_data” field of this extension SHALL contain
“ServerNameList” where:

  struct {
      NameType name_type;
      select (name_type) {
          case host_name: HostName;
      } name;
  } ServerName;

  enum {
      host_name(0), (255)
  } NameType;

  opaque HostName<1..2^16-1>;

  struct {
      ServerName server_name_list<1..2^16-1>
  } ServerNameList;

The ServerNameList MUST NOT contain more than one name of the same
name_type. If the server understood the ClientHello extension but
does not recognize the server name, the server SHOULD take one of two
actions: either abort the handshake by sending a fatal-level
unrecognized_name(112) alert or continue the handshake. It is NOT
RECOMMENDED to send a warning-level unrecognized_name(112) alert,
because the client’s behavior in response to warning-level alerts is
unpredictable. If there is a mismatch between the server name used
by the client application and the server name of the credential
chosen by the server, this mismatch will become apparent when the
client application performs the server endpoint identification, at
which point the client application will have to decide whether to
proceed with the communication. TLS implementations are encouraged
to make information available to application callers about warning-
level alerts that were received or sent during a TLS handshake. Such
information can be useful for diagnostic purposes.