Web interface is unreachable in LNBits & Lightning Terminal


New user to Embassy OS here. Bitcoin Core & LND up and running, lightning channels imported from Umbrel, no issues. Installed LNBits & Lightning Terminal but both fail to load the UI. Lightning Terminal also can’t reach LND Server either.
Installed Core Lightning (which works) but LNBits won’t load with that implementation either.

Errors shown under Health Checks are-
Web Interface - “LNBits Web interface is unreachable”

Lightning Terminal:
Web Interface - “Error while fetching URL: http://lightning-terminal.embassy:8443
LND API - “LND Server is unreachable”

Embassy OS is running on an Intel NUC. Accessed via a MacBook using Safari, Brave and Tor. Same issue with each browser. All services on the Embassy are up to date.

Hope someone can help, thanks.

1 Like

What URL are you accessing the server and the services with? Is it their .local addresses or the Tor address? Ignoring the health checks for now, what is the error that the browser produces when you attempt to use these 2 services web interfaces?

Did you follow this guide:

Try restarting Lightning Terminal - does that help its health check?

Hi George,
I’ve tried accessing both services with Safari and Brave using the local LAN URLs and using Tor to access the .onion addresses. For both services the error produced by Safari is just-
“Safari Can’t Open the Page…(service LAN address) because Safari can’t establish a secure connection to the server…(same service LAN address)”
and Tor is-
“Unable to connect. An error occurred during a connection to…( the onion address)”
The LAN certificate is installed as per instructions.
Other services, like mempool, load on on the LAN fine with an encrypted connection and load in Tor without issue.
Restarting the services makes no difference, same with restarting the server.

Thanks Pistol. I’ve reproduced this on an Embassy Pro with LND v0.16.2~1. We are looking into it and will get a fix out asap.

Thanks George, that’s great news.

FYI- Just updated LNBits to 0.10.5~1 and it has resolved the issue above. Lightning Terminal remains inaccessible, as before.

Cool. We got a fix for LNBits out as you noticed. We are still working on a fix for Lightning Terminal. It shouldn’t be long.

1 Like

That’s great to hear as I have this exact same problem with lightning terminal. Watched a video from BTCSessions where he showed how to allow your family and friends to use your lightning node where their funds are completely segregated from funds on your lightning node. That procedure uses lightning terminal so I’m also eager to get this running. Appreciate how responsive you guys are to your customers. kudos!

I just want to say thanks George for the good work you guys are doing, especially as I noticed you also fixed the lightning terminal web interface problem that existed before. Looking forward to playing with lightning terminal and learning how to use it. You guys deserve a beer! :beers:

1 Like

Lightning Terminal v0.9.2 is now on prod. Let us know if you continue to have any issues.

Hi George. I’d updated to the most recent LND release the other day and that appeared to resolve the web interface access issue with Lightning Terminal. However Lightning Terminal itself did produce some errors upon login- “UNABLE TO FETCH THE NODE TIER” & “UNABLE TO FETCH SESSIONS”

Since updating Lightning Terminal to v0.9.2 the web interface access is intermittent (mostly fails) and the previous errors upon logging into Lightning Terminal are still there.

The web interface error produces the same error as before-
“Safari Can’t Open the Page…(service LAN address) because Safari can’t establish a secure connection to the server…(same service LAN address)”


Pistol, are you able to find your CA cert among the system keychains? (As in this guide):

Note, it will be called your unique “adjective-noun Local CA” or possibly still “Embassy Local CA” depending on when you setup your server.

The reason I ask is because the error you provided seems to indicate that Safari doesn’t trust your server’s CA certificate. Please confirm it’s in there and if not, add it.

Hi George,

I’ve checked for the CA cert, it is there, added originally as per instructions when I first set up the Embassy. When Lightining Terminal does decide to load the web interface in Safari the little padlock icon in the Safari address bar is visible. Clicking it links to the certificate I added and it confirms there is an encrypted connection.

It seems strange that it loads the web interface sometimes, then other times it isn’t available.
FYI I have also installed the recent OS update, it hasn’t resolved the issue either.

Also, just in case it is relevant- access to the .onion addresses for any service seem to be failing. A restart of the Embassy seems to resolve the issue but a few hours later and the connection will fail. This applies to the likes of Zeus app on my iPhone as well as through the Tor browser on my MacBook. The Tor browser produces the following-

"Onionsite Has Disconnected
The most likely cause is that the onionsite is offline. Contact the onionsite administrator.

Details: 0xF2 — Introduction failed, which means that the descriptor was found but the service is no longer connected to the introduction point. It is likely that the service has changed its descriptor or that it is not running."

Actually, I am experiencing similar issues with my setup. There have been occasions when the Tor address I use for connecting to my node does not work as expected. I’ve noticed this problem occurring a couple of times. In order to resolve it, I had to restart my node, which is running on a Raspberry Pi with all the latest updates. Surprisingly, local connections to the node seem to be functioning properly.

I have thoroughly checked the configuration and settings of my Tor setup, as well as the network and settings on my Raspberry Pi. Everything appears to be correctly set up, and local connections work without any problems. It seems that the issue lies specifically with the Tor address and its stability.

@H0mer & @Pistol:

Thanks for your feedback about the Tor issues. There is definitely something wrong with Tor that has gotten way worse in the last month or so with regard to publishing & ability to serve .onions. We’ve noticed it cropping up with quite a few users and your patterns match the same thing we’ve been seeing elsewhere.

If you view your tor log in ssh:
sudo journalctl -u tor@default.service -efa

You will probably see messages about it being unable to contact the HSDir. So, the tor guard nodes that you enter the network through for some reason are not allowing you to make circuits that are sustained to your introduction points. Or the introduction circuits are too short lived, and then when you go to update your service descriptor with your new introduction points int he HSDir, you can’t reach HSDir nodes via those circuits. This all pretty much points back to guard nodes performing very poorly, as you must make all circuits through them. Rebooting your server flushes the tor state and with it the normally-sticky guard nodes. This is why a reboot fixes things, but only temporarily. I wish I had a better answer for you but right now it seems tor just sucks. This is one reason why our most major push over the next couple months is LAN port forwarding, which enables router port forwarding and lays the foundation for remote access via clearnet. Constant attacks on the tor network are also why Tor themselves are implementing Proof of Work for circuits, slated for Tor 0.4.8 (we are on Tor now).


Hi George, thank you for all your help with this issue. Remote access via clearnet will be a great improvement for StartOS, looking forward to it.