I recently updated one of my sparrow wallets from 2.2.3 to 2.3.0. All was well regarding connectivity prior to the upgrade, but after the upgrade, the v2.3.0 wallet refuses to connect over tor and lan (although I need to test the lan setup again as I may have missed something doing it at 4AM).
For reference, the following apply:
My core is reachable locally (have another wallet connected running v2.2.3 on another machine (connection is over .local))
My Core is currently at v28.1.0~2
When I attempt to access the server UI over Tor, I get an SSL certificate error, but I am able to reach the login prompt, so its accessible over the net, although this is likely an unrelated problem.
Additional services are Corelightning, Electrs and Mempool, all have been updated to their respective latest version.
Has anyone else running Sparrow 2.3.0 experienced any issues since upgrading? Any feedback specific to a .onion connection troubleshooting?
No passwords or any other server settings have been changed before and after the wallet upgrade, it was a straight up software patching event.
Are you experiencing any trouble connecting to any other service over Tor?
If all other services are able to connect without a problem then it is a good idea to redo all the steps in the Sparrow Integration Setup Guide found here:
If on the other hand you cannot connect to any other service on your server by visiting their specific .onion address, then there are two options:
Your client device (PC, Phone, Tablet) cannot connect to the tor network for some reason. Make sure you run over this other guide and that everything is set up correctly.
Your server is having trouble connecting to the tor network. You can check the tor logs under System → Insights → Tor Logs and making sure the connection is bootstrapping to 100% and remaining stable.
If the connection is not bootstrapping or is constantly failing, you can attempt to reset the servers tor connection by going to System → Experimental Features → Reset Tor
Try this process at first without selecting the “Wipe State” Option and rechecking the tor logs. If you still have trouble, use that option.
I have reset Tor. Would you say this looks like a clean bootstrap or likely issues there? - I’m not entirely sure what it should look like.
Immediately after a reset -
2025-11-10T13:59:26+00:00 Interrupt: exiting cleanly.
2025-11-10T13:59:26+00:00 Stopping tor@default.service - Anonymizing overlay network for TCP…
2025-11-10T13:59:26+00:00 tor@default.service: Deactivated successfully.
2025-11-10T13:59:26+00:00 Stopped tor@default.service - Anonymizing overlay network for TCP.
2025-11-10T13:59:26+00:00 tor@default.service: Consumed 8min 14.365s CPU time.
2025-11-10T13:59:27+00:00 Starting tor@default.service - Anonymizing overlay network for TCP…
2025-11-10T13:59:27+00:00 Nov 10 13:59:27.386 [notice] Tor 0.4.8.9 running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.11, Zlib 1.2.13, Liblzma 5.4.1, Libzstd 1.5.4 and Glibc 2.36 as libc.
2025-11-10T13:59:27+00:00 Nov 10 13:59:27.386 [notice] Tor can’t help you if you use it wrong! Learn how to be safe at Tor Browser best practices - Security - Tor Browser — Tor
2025-11-10T13:59:27+00:00 Nov 10 13:59:27.386 [notice] Read configuration file “/usr/share/tor/tor-service-defaults-torrc”.
2025-11-10T13:59:27+00:00 Nov 10 13:59:27.386 [notice] Read configuration file “/etc/tor/torrc”.
2025-11-10T13:59:27+00:00 Configuration was valid
2025-11-10T13:59:27+00:00 Nov 10 13:59:27.428 [notice] Tor 0.4.8.9 running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.11, Zlib 1.2.13, Liblzma 5.4.1, Libzstd 1.5.4 and Glibc 2.36 as libc.
2025-11-10T13:59:27+00:00 Nov 10 13:59:27.428 [notice] Tor can’t help you if you use it wrong! Learn how to be safe at Tor Browser best practices - Security - Tor Browser — Tor
2025-11-10T13:59:27+00:00 Nov 10 13:59:27.428 [notice] Read configuration file “/usr/share/tor/tor-service-defaults-torrc”.
2025-11-10T13:59:27+00:00 Nov 10 13:59:27.428 [notice] Read configuration file “/etc/tor/torrc”.
2025-11-10T13:59:27+00:00 Nov 10 13:59:27.429 [warn] You specified a public address ‘0.0.0.0:9050’ for SocksPort. Other people on the Internet might find your computer and use it as an open proxy. Please don’t allow this unless you have a good reason.
2025-11-10T13:59:27+00:00 Nov 10 13:59:27.429 [notice] Opening Socks listener on 0.0.0.0:9050
2025-11-10T13:59:27+00:00 Nov 10 13:59:27.429 [notice] Opened Socks listener connection (ready) on 0.0.0.0:9050
2025-11-10T13:59:27+00:00 Nov 10 13:59:27.429 [notice] Opening Control listener on 127.0.0.1:9051
2025-11-10T13:59:27+00:00 Nov 10 13:59:27.429 [notice] Opened Control listener connection (ready) on 127.0.0.1:9051
2025-11-10T13:59:27+00:00 We compiled with OpenSSL 300000b0: OpenSSL 3.0.11 19 Sep 2023 and we are running with OpenSSL 300000b0: 3.0.11. These two versions should be binary compatible.
2025-11-10T13:59:27+00:00 Tor 0.4.8.9 running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.11, Zlib 1.2.13, Liblzma 5.4.1, Libzstd 1.5.4 and Glibc 2.36 as libc.
2025-11-10T13:59:27+00:00 Tor can’t help you if you use it wrong! Learn how to be safe at Tor Browser best practices - Security - Tor Browser — Tor
2025-11-10T13:59:27+00:00 Read configuration file “/usr/share/tor/tor-service-defaults-torrc”.
2025-11-10T13:59:27+00:00 Read configuration file “/etc/tor/torrc”.
2025-11-10T13:59:27+00:00 You specified a public address ‘0.0.0.0:9050’ for SocksPort. Other people on the Internet might find your computer and use it as an open proxy. Please don’t allow this unless you have a good reason.
2025-11-10T13:59:27+00:00 Opening Socks listener on 0.0.0.0:9050
2025-11-10T13:59:27+00:00 Opened Socks listener connection (ready) on 0.0.0.0:9050
2025-11-10T13:59:27+00:00 Opening Control listener on 127.0.0.1:9051
2025-11-10T13:59:27+00:00 Opened Control listener connection (ready) on 127.0.0.1:9051
2025-11-10T13:59:27+00:00 Parsing GEOIP IPv4 file /usr/share/tor/geoip.
2025-11-10T13:59:27+00:00 Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
2025-11-10T13:59:27+00:00 Bootstrapped 0% (starting): Starting
2025-11-10T13:59:28+00:00 Starting with guard context “default”
2025-11-10T13:59:28+00:00 Signaled readiness to systemd
2025-11-10T13:59:28+00:00 Bootstrapped 5% (conn): Connecting to a relay
2025-11-10T13:59:28+00:00 Started tor@default.service - Anonymizing overlay network for TCP.
2025-11-10T13:59:28+00:00 New control connection opened from 127.0.0.1.
2025-11-10T13:59:29+00:00 Opening Control listener on /run/tor/control
2025-11-10T13:59:29+00:00 Opened Control listener connection (ready) on /run/tor/control
2025-11-10T13:59:29+00:00 Bootstrapped 10% (conn_done): Connected to a relay
2025-11-10T13:59:29+00:00 Bootstrapped 14% (handshake): Handshaking with a relay
2025-11-10T13:59:29+00:00 Bootstrapped 15% (handshake_done): Handshake with a relay done
2025-11-10T13:59:29+00:00 Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
2025-11-10T13:59:29+00:00 Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
2025-11-10T13:59:29+00:00 Bootstrapped 95% (circuit_create): Establishing a Tor circuit
2025-11-10T13:59:29+00:00 Bootstrapped 100% (done): Done
2025-11-10T13:59:32+00:00 Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 1000 buildtimes.
2025-11-10T13:59:32+00:00 Guard YukisTorRelay ($2E289A14B649F500C194BD56DEE28F0A0D75533C) is failing more circuits than usual. Most likely this means the Tor network is overloaded. Success counts are 121/185. Use counts are 92/92. 121 circuits completed, 0 were unusable, 0 collapsed, and 3 timed out. For reference, your timeout cutoff is 60 seconds.
2025-11-10T13:59:32+00:00 Guard shiva ($8921CB0ECEA669EEF8A2FD20537D58A676F47228) is failing more circuits than usual. Most likely this means the Tor network is overloaded. Success counts are 147/210. Use counts are 98/98. 147 circuits completed, 0 were unusable, 0 collapsed, and 3 timed out. For reference, your timeout cutoff is 60 seconds.
2025-11-10T13:59:34+00:00 Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 156 buildtimes.
2025-11-10T13:59:36+00:00 Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 188 buildtimes.
2025-11-10T14:01:06+00:00 Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 102 buildtimes.
Sorry for the belated response. Not had time to play.
The solution in my case was indeed to restart the TOR service at the server end.
It makes no sense why before the Wallet update it was working and immediately following it rejected to connect, given nothing else had changed and I had not even restarted the client machine.
Anyway, problem solved. Thanks for the assistance.