Bad Guards, HSDir failures, compression bombs, jam order book 504 - I’ve tried everything i could find online and through this forum. Used AI to really help me dig into common issues. I’m not having resource constraints on server, have tried numerous (100+) wipes (box unchecked) waited, done wipes with box checked, done wipe loops and waited. I use cable internet(spectrum) I have replaced and updated my router, modem, cords. I’ve reset in the jam container numerous times as my peer retry grows to 13,300 sec. I get small blips when pinging all 3 of the devices( google dns, router, server). plugged straight into modem and bypassed new router to eliminate double nat. I run knots(if that matters). Please let me know what you need to see from me and any help would be much appreciated. This problem is really irking me. Thank you
I’m understanding your server is fine, but the internal Tor daemon in Jam is having connectivity issues.
You can force reset Tor inside that service (it doesn’t use the main StartOS Tor daemon) with the following commands…
dinitctl stop jmwalletd && dinitctl stop ob-watcher && dinitctl stop tor && rm /home/tor/.tor/state && dinitctl start tor && dinitctl start ob-watcher && dinitctl start jmwalletd
But I’m afraid I don’t have a way to make Tor behave… but hopefully the above helps.
Thanks for the quick reply! I run the suggested command in the jam container, once my times max out at 13,300 seconds. Should I be doing this reset in a loop, let’s say every 2 hours? Should i be mixing these jam wipes with tor wipes under experimental? Or do I just keep doing what I’m doing till tor grab’s a new guard? I’ve read in a couple of places that cable internet can be finicky with tor, that’s why I decided to update all my equipment. And I don’t feel comfortable enough to make any changes in the torrc. Thanks again!
what you’re doing, should be enough… if you can’t get a stable tor connection in that container despite resetting tor a hundred times… then it suggests some broader issue. I’d check your server’s tor connection… is that unstable?
This is a screen shot of the tor logs under experimental. I’ve never seen bootstrap get stuck like I captured in this screen shot. It always goes right to 100% within 20-30seconds. This log is always my “No more HSDir available to query” that can happen 4-8 times/hr. I’ve also seen compression bombs in this log as well. I can share a jam log as well, normally that is peer connection failures and reattempts.
Starting tor@default.service - Anonymizing overlay network for TCP…
2026-03-29T09:05:07-04:00 Mar 29 13:05:07.463 [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.
2026-03-29T09:05:07-04:00 Mar 29 13:05:07.463 [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
2026-03-29T09:05:07-04:00 Mar 29 13:05:07.463 [notice] Read configuration file “/usr/share/tor/tor-service-defaults-torrc”.
2026-03-29T09:05:07-04:00 Mar 29 13:05:07.463 [notice] Read configuration file “/etc/tor/torrc”.
2026-03-29T09:05:07-04:00 Mar 29 13:05:07.463 [warn] Fixing permissions on directory /var/lib/tor
2026-03-29T09:05:07-04:00 Configuration was valid
2026-03-29T09:05:07-04:00 Mar 29 13:05:07.478 [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.
2026-03-29T09:05:07-04:00 Mar 29 13:05:07.478 [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
2026-03-29T09:05:07-04:00 Mar 29 13:05:07.478 [notice] Read configuration file “/usr/share/tor/tor-service-defaults-torrc”.
2026-03-29T09:05:07-04:00 Mar 29 13:05:07.478 [notice] Read configuration file “/etc/tor/torrc”.
2026-03-29T09:05:07-04:00 Mar 29 13:05:07.478 [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.
2026-03-29T09:05:07-04:00 Mar 29 13:05:07.478 [notice] Opening Socks listener on 0.0.0.0:9050
2026-03-29T09:05:07-04:00 Mar 29 13:05:07.478 [notice] Opened Socks listener connection (ready) on 0.0.0.0:9050
2026-03-29T09:05:07-04:00 Mar 29 13:05:07.478 [notice] Opening Control listener on 127.0.0.1:9051
2026-03-29T09:05:07-04:00 Mar 29 13:05:07.478 [notice] Opened Control listener connection (ready) on 127.0.0.1:9051
2026-03-29T09:05:07-04: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.
2026-03-29T09:05:07-04: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.
2026-03-29T09:05:07-04: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
2026-03-29T09:05:07-04:00 Read configuration file “/usr/share/tor/tor-service-defaults-torrc”.
2026-03-29T09:05:07-04:00 Read configuration file “/etc/tor/torrc”.
2026-03-29T09:05:07-04: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.
2026-03-29T09:05:07-04:00 Opening Socks listener on 0.0.0.0:9050
2026-03-29T09:05:07-04:00 Opened Socks listener connection (ready) on 0.0.0.0:9050
2026-03-29T09:05:07-04:00 Opening Control listener on 127.0.0.1:9051
2026-03-29T09:05:07-04:00 Opened Control listener connection (ready) on 127.0.0.1:9051
2026-03-29T09:05:07-04:00 Parsing GEOIP IPv4 file /usr/share/tor/geoip.
2026-03-29T09:05:07-04:00 Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
2026-03-29T09:05:07-04:00 Bootstrapped 0% (starting): Starting
2026-03-29T09:05:07-04:00 Starting with guard context “default”
2026-03-29T09:05:07-04:00 Signaled readiness to systemd
2026-03-29T09:05:07-04:00 Started tor@default.service - Anonymizing overlay network for TCP.
2026-03-29T09:05:08-04:00 New control connection opened from 127.0.0.1.
2026-03-29T09:05:08-04:00 Opening Control listener on /run/tor/control
2026-03-29T09:05:08-04:00 Opened Control listener connection (ready) on /run/tor/control
2026-03-29T09:05:08-04:00 Bootstrapped 5% (conn): Connecting to a relay
2026-03-29T09:05:15-04:00 Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (No route to host; NOROUTE; count 1; recommendation warn; host 01B8F18C11CE2877E8190FA2C81808CD087515C0 at 89.58.34.53:9001)
2026-03-29T09:05:15-04:00 Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (No route to host; NOROUTE; count 2; recommendation warn; host 1709E7D66185C2BD138D48530E0D800ED44F2BEA at 78.61.137.118:9001)
2026-03-29T09:05:15-04:00 1 connections have failed:
2026-03-29T09:05:15-04:00 1 connections died in state connect()ing with SSL state (No SSL object)
2026-03-29T09:05:18-04:00 Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (No route to host; NOROUTE; count 3; recommendation warn; host 21C9D9F1633246269DEB84A79495E85C07E8466D at 92.223.105.174:443)
2026-03-29T09:05:18-04:00 2 connections have failed:
2026-03-29T09:05:18-04:00 2 connections died in state connect()ing with SSL state (No SSL object)
2026-03-29T09:05:18-04:00 Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (No route to host; NOROUTE; count 4; recommendation warn; host 74A910646BCEEFBCD2E874FC1DC997430F968145 at 199.58.81.140:443)
2026-03-29T09:05:18-04:00 3 connections have failed:
2026-03-29T09:05:18-04:00 3 connections died in state connect()ing with SSL state (No SSL object)
2026-03-29T09:05:18-04:00 Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (No route to host; NOROUTE; count 5; recommendation warn; host 0136696B025AC5503847D736FE9F3D65EB27A596 at 134.209.159.74:443)
2026-03-29T09:05:18-04:00 4 connections have failed:
2026-03-29T09:05:18-04:00 4 connections died in state connect()ing with SSL state (No SSL object)
2026-03-29T09:05:21-04:00 Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (No route to host; NOROUTE; count 6; recommendation warn; host 6FF148A28DB6478CAC9ADFDCACC0D81C0C212EA2 at 95.214.53.96:8444)
2026-03-29T09:05:21-04:00 5 connections have failed:
2026-03-29T09:05:21-04:00 5 connections died in state connect()ing with SSL state (No SSL object)
2026-03-29T09:05:21-04:00 Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (No route to host; NOROUTE; count 7; recommendation warn; host 1A25C6358DB91342AA51720A5038B72742732498 at 128.31.0.39:9201)
2026-03-29T09:05:21-04:00 6 connections have failed:
2026-03-29T09:05:21-04:00 6 connections died in state connect()ing with SSL state (No SSL object)
2026-03-29T09:05:27-04:00 Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (Network is unreachable; NOROUTE; count 8; recommendation warn; host 7BE683E65D48141321C5ED92F075C55364AC7123 at 193.23.244.244:443)
2026-03-29T09:05:27-04:00 7 connections have failed:
2026-03-29T09:05:27-04:00 7 connections died in state connect()ing with SSL state (No SSL object)
2026-03-29T09:05:31-04:00 Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (Network is unreachable; NOROUTE; count 9; recommendation warn; host 3DA05FF92861FB0A0901C65E1C041C72C0D1CAE3 at 31.133.0.82:443)
2026-03-29T09:05:31-04:00 8 connections have failed:
2026-03-29T09:05:31-04:00 8 connections died in state connect()ing with SSL state (No SSL object)
2026-03-29T09:05:39-04:00 Interrupt: exiting cleanly.
2026-03-29T09:05:39-04:00 Stopping tor@default.service - Anonymizing overlay network for TCP…
2026-03-29T09:05:39-04:00 tor@default.service: Deactivated successfully.
2026-03-29T09:05:39-04:00 Stopped tor@default.service - Anonymizing overlay network for TCP.
2026-03-29T09:05:40-04:00 Starting tor@default.service - Anonymizing overlay network for TCP…
2026-03-29T09:05:40-04:00 Mar 29 13:05:40.584 [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.
2026-03-29T09:05:40-04:00 Mar 29 13:05:40.584 [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
2026-03-29T09:05:40-04:00 Mar 29 13:05:40.584 [notice] Read configuration file “/usr/share/tor/tor-service-defaults-torrc”.
2026-03-29T09:05:40-04:00 Mar 29 13:05:40.584 [notice] Read configuration file “/etc/tor/torrc”.
2026-03-29T09:05:40-04:00 Configuration was valid
2026-03-29T09:05:40-04:00 Mar 29 13:05:40.598 [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.
2026-03-29T09:05:40-04:00 Mar 29 13:05:40.598 [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
2026-03-29T09:05:40-04:00 Mar 29 13:05:40.598 [notice] Read configuration file “/usr/share/tor/tor-service-defaults-torrc”.
2026-03-29T09:05:40-04:00 Mar 29 13:05:40.598 [notice] Read configuration file “/etc/tor/torrc”.
2026-03-29T09:05:40-04:00 Mar 29 13:05:40.599 [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.
2026-03-29T09:05:40-04:00 Mar 29 13:05:40.599 [notice] Opening Socks listener on 0.0.0.0:9050
2026-03-29T09:05:40-04:00 Mar 29 13:05:40.599 [notice] Opened Socks listener connection (ready) on 0.0.0.0:9050
2026-03-29T09:05:40-04:00 Mar 29 13:05:40.599 [notice] Opening Control listener on 127.0.0.1:9051
2026-03-29T09:05:40-04:00 Mar 29 13:05:40.599 [notice] Opened Control listener connection (ready) on 127.0.0.1:9051
2026-03-29T09:05:40-04: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.
2026-03-29T09:05:40-04: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.
2026-03-29T09:05:40-04: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
2026-03-29T09:05:40-04:00 Read configuration file “/usr/share/tor/tor-service-defaults-torrc”.
2026-03-29T09:05:40-04:00 Read configuration file “/etc/tor/torrc”.
2026-03-29T09:05:40-04: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.
2026-03-29T09:05:40-04:00 Opening Socks listener on 0.0.0.0:9050
2026-03-29T09:05:40-04:00 Opened Socks listener connection (ready) on 0.0.0.0:9050
2026-03-29T09:05:40-04:00 Opening Control listener on 127.0.0.1:9051
2026-03-29T09:05:40-04:00 Opened Control listener connection (ready) on 127.0.0.1:9051
2026-03-29T09:05:40-04:00 Parsing GEOIP IPv4 file /usr/share/tor/geoip.
2026-03-29T09:05:40-04:00 Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
2026-03-29T09:05:40-04:00 Bootstrapped 0% (starting): Starting
2026-03-29T09:05:40-04:00 Starting with guard context “default”
2026-03-29T09:05:40-04:00 Signaled readiness to systemd
2026-03-29T09:05:40-04:00 Started tor@default.service - Anonymizing overlay network for TCP.
2026-03-29T09:05:41-04:00 New control connection opened from 127.0.0.1.
2026-03-29T09:05:41-04:00 Opening Control listener on /run/tor/control
2026-03-29T09:05:41-04:00 Opened Control listener connection (ready) on /run/tor/control
2026-03-29T09:05:41-04:00 Bootstrapped 5% (conn): Connecting to a relay
2026-03-29T09:05:41-04:00 Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (Network is unreachable; NOROUTE; count 1; recommendation warn; host B91A1EB30E66D52026EFCD1E96BFC0E966C83E6D at 62.210.105.46:9201)
2026-03-29T09:05:42-04:00 Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (Network is unreachable; NOROUTE; count 2; recommendation warn; host CE47F0356D86CF0A1A2008D97623216D560FB0A8 at 193.108.118.218:587)
2026-03-29T09:05:42-04:00 1 connections have failed:
2026-03-29T09:05:42-04:00 1 connections died in state connect()ing with SSL state (No SSL object)
2026-03-29T09:05:59-04:00 Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (Network is unreachable; NOROUTE; count 3; recommendation warn; host E34853BFFFA4034DF4C710D3CDD73818E998FEB4 at 46.38.255.27:9001)
2026-03-29T09:05:59-04:00 2 connections have failed:
2026-03-29T09:05:59-04:00 2 connections died in state connect()ing with SSL state (No SSL object)
2026-03-29T09:05:59-04:00 Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (Network is unreachable; NOROUTE; count 4; recommendation warn; host BD6A829255CB08E66FBE7D3748363586E46B3810 at 171.25.193.9:80)
2026-03-29T09:05:59-04:00 3 connections have failed:
2026-03-29T09:05:59-04:00 3 connections died in state connect()ing with SSL state (No SSL object)
2026-03-29T09:06:06-04:00 Bootstrapped 10% (conn_done): Connected to a relay
2026-03-29T09:06:06-04:00 Bootstrapped 14% (handshake): Handshaking with a relay
2026-03-29T09:06:06-04:00 Bootstrapped 15% (handshake_done): Handshake with a relay done
2026-03-29T09:06:06-04:00 Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
2026-03-29T09:06:06-04:00 Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
2026-03-29T09:06:07-04:00 Bootstrapped 30% (loading_status): Loading networkstatus consensus
2026-03-29T09:06:08-04:00 I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
2026-03-29T09:06:08-04:00 Bootstrapped 40% (loading_keys): Loading authority key certs
2026-03-29T09:06:08-04:00 The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.
2026-03-29T09:06:08-04:00 Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors
2026-03-29T09:06:08-04:00 I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/9764, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.)
2026-03-29T09:06:09-04:00 Bootstrapped 50% (loading_descriptors): Loading relay descriptors
2026-03-29T09:06:11-04:00 The current consensus contains exit nodes. Tor can build exit and internal paths.
2026-03-29T09:06:13-04:00 Bootstrapped 56% (loading_descriptors): Loading relay descriptors
2026-03-29T09:06:14-04:00 Bootstrapped 63% (loading_descriptors): Loading relay descriptors
2026-03-29T09:06:14-04:00 Bootstrapped 69% (loading_descriptors): Loading relay descriptors
2026-03-29T09:06:14-04:00 Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
2026-03-29T09:06:14-04:00 Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
2026-03-29T09:06:14-04:00 Bootstrapped 95% (circuit_create): Establishing a Tor circuit
2026-03-29T09:06:15-04:00 Bootstrapped 100% (done): Done
2026-03-29T09:06:51-04:00 Closed 1 streams for service [scrubbed].onion for reason resolve failed. Fetch status: No more HSDir available to query.
2026-03-29T09:08:04-04:00 Tor has not observed any network activity for the past 62 seconds. Disabling circuit build timeout recording.
2026-03-29T09:08:34-04:00 Interrupt: exiting cleanly.
2026-03-29T09:08:34-04:00 Stopping tor@default.service - Anonymizing overlay network for TCP…
2026-03-29T09:08:34-04:00 tor@default.service: Deactivated successfully.
2026-03-29T09:08:34-04:00 Stopped tor@default.service - Anonymizing overlay network for TCP.
I see a lot of 5%s.
5% is almost always stuck at the LAN level, not even getting past your Router. Yet, later it seems to be able to. Not sure what to make of this. Maybe general network connectivity to the server is bad. Maybe you could run a ping on it and leave it running to see if pings are dropped.
could it be double NAT? I’ve ran ping test from my laptop(wireless). I had 3 ping’s going at once 8.8.8.8, router and server. I ran a two hour test, I saw big spikes across all 3 happened 4 times, across both router and server 1 time, never just the server. But 8.8.8.8 had numerous request timed out as the other 2 had none. Should i plug straight into the modem shutdown server and just ping modem and 8.8.8.8 or 1.1.1.1? or plug in laptop directly to router and do the test on server and 8.8.8.8?
Possibly. I can’t really say. I’d suggest not double NATing and see what happens.
The pings to 8.8.8.8 timing out does mean there’s clearly a serious connection issue in at least one part of your setup. Time to narrow it down and fix. It will be fixable, even double NAT won’t interrupt pinging to the wider internet. Something is wrong.
I’m running some ping test and will get back to you with results! Could my oslog or kernel logs tell me anything related to this issue, I can post them if you think any info in them would be valuable?
Or any settings in my knots that could effect tor? I did make some changes to the config file when installed months ago. Should i try to set them back to the default. And to let you know that this did work great for a period and I was able to do things over tor and jam.
No logs on your server will be able to tell you anything about things external to the server, other than direct LAN connections being up or down. You’ll need to troubleshoot for trial and error. Knowing your server is fine means you have eliminated one component, which is useful.
Update! I ran 3 separate ping test. The first one was modem and router only unhooked start9, plugged laptop straight into router. In 3 hours I had 0 drops to the router and 7 request timed out to google dns. The next test was for 7 hours, I plugged back in the start 9 and pinged google dns, router and server. I had 0 request timed out on the start9 and router, but had 13 on google dns. The next test I did was unplug everything besides modem and i went straight into my laptop. I pinged google dns for 3 hours, I couldn’t ping the actual modem unless I went static. I had one giant spike and 8 request timed out. I also did winmtr ping to 8.8.8.8 to stress it a little more and that showed it was having a hard time somewhere before my network, on charter’s side. I called charter, and they seen a signal problem on their end and they are sending a tech to check my drop line tomorow. I’ll keep you posted what happens after everything is fixed. Fingers crossed!