Hey all, ran into a weird issue with my Ubuntu server running qbittorrent-nox I can’t seem to figure out.
When Qbittorrent is running, I can’t load some sites. How I discovered this was Jackett was failing tests to my trackers. Sometimes all trackers would fail, other times only a couple would.
From the server I ran a curl to the tracker URLs and confirmed they were not loading.
Pcap shows the TLS hello go out, but no response from the server.
Once I kill the qbittorrent process, everything works.
Wondering if anyone has any ideas or has seen this issue before.
Things I’ve tried:
Disabled ipv6
Changed Qbit UI port
Paused Torrents
re-installed openssl
rebooted about 150 times and counting
Qbit version is 4.5.5
Ubuntu 22.04.3 headless running on Esxi
Appreciate any ideas!
Edit: So after much frustration and some other weird things, restored to a previous snapshot and the issue seems to have resolved. Appreciate all the troubleshooting ideas and responses!
Were you trying to install a VPN kill-switch in iptables or something and mess up somehow? I did have an issue similar to this once, where I was firing up my VPN, not realizing it wasn’t allowing multiple clients, and so my initial client would get kicked off and I’d have to reauth on the VPN to get connected again – in my case I was split-tunnelling a wireguard connection, but could that be happening? Are you firing up Qbittorrent with some sort of VPN scripts and getting kicked off of your normal VPN connection?
Do you currently have a bunch of active torrents, each with a bunch of connected peers? What’s your network topology like? Aging combo modem/wifi/router? Have you tried limiting the total number of connected peers in your torrent manager? Torrents can really clog up a network. Sometimes routing too many connections overwhelmed my old router, forcing a reboot before any traffic could get through again.
From your description I would gues that the affected trackers have some rate or connection limits, and your qbittorrent announces are exceeding them.
try setting a higher announce interval, like 1+ hours
Anonamouse just announced that they’re likely to ban some client/version pairs precisely because of announce floods. Thing is, does the problem clear up instantly when the client is killed, or does it take time? The latter would indicate a server side van expiring, the former some issue on the client side.
Sounds like you’ve already maybe ruled out some things, but as far as the port exhaustion question people had, you could prove that with “netstat -s” to see total number of active connections. You might also look in the qbittorrent log file for anything stands out. You might also check your router to make sure you’re not doing some weird port forward or something of that nature.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !piracy@lemmy.dbzer0.com
⚓ Dedicated to the discussion of digital piracy, including ethical problems and legal advancements.
Were you trying to install a VPN kill-switch in iptables or something and mess up somehow? I did have an issue similar to this once, where I was firing up my VPN, not realizing it wasn’t allowing multiple clients, and so my initial client would get kicked off and I’d have to reauth on the VPN to get connected again – in my case I was split-tunnelling a wireguard connection, but could that be happening? Are you firing up Qbittorrent with some sort of VPN scripts and getting kicked off of your normal VPN connection?
Do you currently have a bunch of active torrents, each with a bunch of connected peers? What’s your network topology like? Aging combo modem/wifi/router? Have you tried limiting the total number of connected peers in your torrent manager? Torrents can really clog up a network. Sometimes routing too many connections overwhelmed my old router, forcing a reboot before any traffic could get through again.
Sorry, to clerify: this server is the only one effected. The rest of my network is working perfectly fine.
All other internet traffic is running without a problem, it’s only http/https traffic on this one server running Qbit and Jackett.
Thanks for the response!
Have you verified that this is not a DNS issue? For example, is
curl http://1.1.1.1working, whilecurl http://ip.menot working?From your description I would gues that the affected trackers have some rate or connection limits, and your qbittorrent announces are exceeding them. try setting a higher announce interval, like 1+ hours
Anonamouse just announced that they’re likely to ban some client/version pairs precisely because of announce floods. Thing is, does the problem clear up instantly when the client is killed, or does it take time? The latter would indicate a server side van expiring, the former some issue on the client side.
The issue would resolve almost immediately after killing Qbit.
You router’s NAT table is probably getting full, try a better router and/or putting torrents over a vpn
I’ll double check this, but my router is enterprise grade so I don’t think I would hit any NAT limitations.
Also, as mentioned in my other response, this isn’t affecting any other nodes on my network except the server running Qbit and Jackett.
I have another Ubuntu VM on the same host that works fine when this one is failing.
Thanks so much for the response!
Some DNS servers are blocking the requests? Maybe try 1.1.1.1 for all DNS and retry
Cleared NAT translations and rebooted my router for good measure. No dice.
Sounds like you’ve already maybe ruled out some things, but as far as the port exhaustion question people had, you could prove that with “netstat -s” to see total number of active connections. You might also look in the qbittorrent log file for anything stands out. You might also check your router to make sure you’re not doing some weird port forward or something of that nature.