Since updating to Umbrel 1.7.3 (still present in 1.7.4), my Lightning node has been experiencing severe Tor connectivity issues.
The node normally reaches around 330–340 connected peers, then suddenly drops below 100 peers (sometimes even 0) without any configuration changes. This causes many channels to become temporarily offline, and some remote peers eventually close their channels after repeated disconnections.
The issue started immediately after updating to Umbrel 1.7.3. Before that, my node was stable for months.
Expected behavior
- Stable peer count.
- Channels remain online.
- No need to manually restart any service.
Actual behavior
- Peer count suddenly drops from ~340 to below 100 (sometimes even 0).
- A large number of channels become inactive.
- Routing activity decreases significantly.
- Remote peers sometimes see my node as offline.
- I have already lost 16 channels since this issue started because peers eventually closed them.
Workaround
One important observation is that restarting only the tor_proxy container consistently restores connectivity.
Within about an hour after restarting tor_proxy, the node usually recovers to more than 300 connected peers.
Unfortunately, after several hours the peer count drops again and the same cycle repeats.
To keep my node usable, I wrote a small watchdog script that automatically restarts tor_proxy whenever the number of connected peers falls below a threshold.
This is only a temporary workaround, not a real fix.
Evidence
Watchdog log
The watchdog repeatedly shows the same recovery pattern:
- 73 peers → restart
tor_proxy → recovery to 191 peers
- 15 peers → restart
tor_proxy → recovery to 344 peers
Monitor
After restarting tor_proxy, the node quickly returns to a healthy state.
Typical values:
- ~341 connected peers
- ~343 active channels
- ~41 inactive channels
Tor logs
Tor repeatedly reports messages such as:
These messages appear repeatedly while the peer count is unstable and often coincide with failed onion connection attempts.
All current guards excluded by path restriction type 2; using an additional guard.
These messages appear continuously while the peer count is unstable.
Environment
- Umbrel Home
- Umbrel OS 1.7.4
- Tor-only Lightning node
- LND fully synced (chain and graph)
- CPU and RAM usage are normal
- Restarting LND does not solve the issue.
- Restarting only
tor_proxy consistently restores most peer connections.
Additional observations
The issue does not look like LND itself is crashing.
LND remains fully synchronized and operational.
Based on these observations, the issue appears to be related to Tor connectivity or its integration with Umbrel, since restarting only tor_proxy consistently restores hundreds of peer connections without restarting LND.
Has anyone else experienced similar behavior since Umbrel 1.7.3 / 1.7.4?
Since updating to Umbrel 1.7.3 (still present in 1.7.4), my Lightning node has been experiencing severe Tor connectivity issues.
The node normally reaches around 330–340 connected peers, then suddenly drops below 100 peers (sometimes even 0) without any configuration changes. This causes many channels to become temporarily offline, and some remote peers eventually close their channels after repeated disconnections.
The issue started immediately after updating to Umbrel 1.7.3. Before that, my node was stable for months.
Expected behavior
Actual behavior
Workaround
One important observation is that restarting only the
tor_proxycontainer consistently restores connectivity.Within about an hour after restarting
tor_proxy, the node usually recovers to more than 300 connected peers.Unfortunately, after several hours the peer count drops again and the same cycle repeats.
To keep my node usable, I wrote a small watchdog script that automatically restarts
tor_proxywhenever the number of connected peers falls below a threshold.This is only a temporary workaround, not a real fix.
Evidence
Watchdog log
The watchdog repeatedly shows the same recovery pattern:
tor_proxy→ recovery to 191 peerstor_proxy→ recovery to 344 peersMonitor
After restarting
tor_proxy, the node quickly returns to a healthy state.Typical values:
Tor logs
Tor repeatedly reports messages such as:
These messages appear repeatedly while the peer count is unstable and often coincide with failed onion connection attempts.
These messages appear continuously while the peer count is unstable.
Environment
tor_proxyconsistently restores most peer connections.Additional observations
The issue does not look like LND itself is crashing.
LND remains fully synchronized and operational.
Based on these observations, the issue appears to be related to Tor connectivity or its integration with Umbrel, since restarting only tor_proxy consistently restores hundreds of peer connections without restarting LND.
Has anyone else experienced similar behavior since Umbrel 1.7.3 / 1.7.4?