all trackers listed "not working"

[alpha91]

Please provide the following information

qBittorrent version and Operating System

v3.3.16 (64-bit), Windows 7 Pro (64-bit)

What is the problem

All public trackers showing as "Not Working"

Hi everyone,
I'm hoping to get some help with a problem across all torrent files, they all have public trackers added and every single one shows as not working. This has been happening for the last few weeks but they still manage to connect to DHT, [PeX} and [LSD]
Here is a snapshot - I have setup to have approx 50 public trackers auto added by qbittorrent and not a single one shows as working, across the board.

Checking the logs here is the listening information:

12/02/2018 8:35 PM - UPnP / NAT-PMP support [ON]
12/02/2018 8:35 PM - qBittorrent is successfully listening on interface 0.0.0.0 port: UDP/62222
12/02/2018 8:35 PM - qBittorrent is successfully listening on interface :: port: TCP/62222
12/02/2018 8:35 PM - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP/62222
12/02/2018 8:35 PM - qBittorrent is successfully listening on interface 0.0.0.0 port: UDP/62222
12/02/2018 8:35 PM - qBittorrent is successfully listening on interface :: port: TCP_SSL/4433
12/02/2018 8:35 PM - qBittorrent is successfully listening on interface :: port: TCP/62222
12/02/2018 8:35 PM - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP_SSL/4433
12/02/2018 8:35 PM - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP/62222
12/02/2018 8:35 PM - Options were saved successfully.
12/02/2018 8:35 PM - GeoIP database loaded. Type: GeoLite2-Country. Build time: Thu Feb 8 06:42:47 2018.

13/02/2018 1:29 AM - DHT support [ON]
13/02/2018 1:29 AM - UPnP / NAT-PMP support [ON]
13/02/2018 1:29 AM - Embedded Tracker [OFF]
13/02/2018 1:29 AM - Encryption support [ON]
13/02/2018 1:29 AM - Anonymous mode [OFF]
13/02/2018 1:29 AM - PeX support [ON]
13/02/2018 1:29 AM - Local Peer Discovery support [ON]

I have had a look through other threads here with similar issues and tried the following with none making any difference:

• changed incoming port recently 62222 from 8999 (used 8999 for a long time with no issues until recently)
• listening on IPv6 interface, historically this was enabled but tried disabling recently
• tried adding Proxy Server SOCKS4 0.0.0.0

I run this through ExpressVPN and also run Norton Internet Security, but have recently disabled the firewall and this makes no difference either. I haven't changed anything with the VPN or anything, until the issue became constant and I have tried the changes above.

Really not sure where to go from here or if I'm missing something very simple. Any help would be greatly appreciated.

[alpha91]

The network interface mapping was set to "Any Interface" and changing this to the VPN adapter interface also makes no difference. Still have the round green connection status down the bottom but all trackers still showing as Not Working.

[slrslr]

I subscribed as i am also bothered by this since last year, most of the time i click torrent, i see only trackers with IP addresses to work, others that contain domain names in its address are "Not working". Other torrent client do not have this issue. But i am having 4.0.3, not 3.3.16 as You have. We have VPN in common.

[greasedonkey]

I have the same issue now, haven't changed anthing. I use VPN too. I installed BitTorrent to see if it worked and fortunately it did.

I updated to 4.0.3 and I still have the issue.

[Fixer-007]

Probably dupe of #8099

Workaround, on Trackers tab, move some tracker up or down with arrows on right side, that will reshuffle them and they will all contact properly.

[greasedonkey]

My workaround was to completely uninstall qBittorrent and reinstall it after. I can't find where, but an article I read mentioned this and surprisingly it worked for me.

…

________________________________ From: Fixer <notifications@github.com> Sent: Monday, February 26, 2018 5:17:53 PM To: qbittorrent/qBittorrent Cc: greasedonkey; Comment Subject: Re: [qbittorrent/qBittorrent] all trackers listed "not working" (#8397) Probably dupe of #8099<#8099> Workaround, on Trackers tab, move some tracker up or down with arrows on right side, that will reshuffle them and they will all contact properly. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#8397 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AElFzTJ5oAsaoiCrnBqGKt4OoLIMx3J4ks5tYy2QgaJpZM4SB-Mv>.

[IrishNachos]

I am having the same issue. I have tried all the above mentioned fixes including a clean re-install with no luck. Has anyone found a solution?

[slrslr]

4.1.5 does not fix this issue, still only trackers with IPs in its address works, it is rare i see hostname tracker to work and i am also using VPN as OP. @sledgehammer999 can you add it a priority on your list? i am willing to help debug it if i can help. I am having 1000 torrents now, sleeping my WIndows 10 computer so qbt is running long time. This is top importance problem in qbt on WIndows i think.

[nmadole]

I am also having this issue; using PIA VPN Client.... Private Trackers work perfect; all Public trackers are "not working" ...

[buddhaman001]

Try disabling UPnP / NAT-PMP and manually forwarding the set port on your router. This seems to have solved my issue as Upnp is garbage on my current firmware. I don't know why this helps as I am going out VIA a VPN.

[JasonEverling]

removing UPnP worked for me, set to change port at startup and upnp off

[slrslr]

removing UPnP worked for me

not in my case (MS WIndows, OpenVPN, qbt 4.1.5). I can see only like 1 working tracker out of many - the one with IP in its URL. "Force reannounce to selected trackers" worked only for one tracker (one with IP in its URL). @sledgehammer999
Majority of the following trackers are working when i paste them into the torrent: https://raw.githubusercontent.com/ngosang/trackerslist/master/trackers_best_ip.txt

[Fr33raNg3r]

Hi, I have a way to fix it.
just sort to the trackerlist.
The tracker is not working when the number is 0.

[Fr33raNg3r]

How can fix it when I have used web UI.

[slrslr]

@jetranger i do not think your image is a way to fix this issue, also you have not provided detailed explanation on what to do to fix it (to turn "not working" trackers into "working")

[Fr33raNg3r]

@jetranger i do not think your image is a way to fix this issue, also you have not provided detailed explanation on what to do to fix it (to turn "not working" trackers into "working")

1.select anyone tracker URL.
2.click up or down button.
3.It's work when the NO. is not "0".
4.Done.

[slrslr]

@jetranger thanks for clarifying. in my case this does NOT help to fix the issue. Trackers are reloaded indeed, but keep in Non working state. Only trackers with IP addresses works most of the time.

[pwnjuice]

I am assuming everyone with this issue is using a VPN. I tried all the workarounds and zero luck. I have qbit to auto download via RSS. This has happened to me before but it self corrected. I have also set Windows firewall to kill any connections when the VPN is not connected. No settings have changed and nothing has been updated. No reason why qbit should have stopped auto-downloading and checking trackers. I was dumbfounded.

Think about data caps the ISP's use I guess something was blocking me ISP wise aka the VPN server I was connected to because I never change it. I looked and it stop downloading 15 mins from my next one. I download about 800GB's a month. Yes I have tons of storage. I simply changed to a new VPN server New York to Washington then restarted qbit and BAM everything starting working.

Overall If you're on a VPN and you stay on the same server try changing it. That server "ISP" might be data caping you.

[slrslr]

@pwnjuice

If you're on a VPN and you stay on the same server try changing it. That server "ISP" might be data caping you.

Thank you for your research. I do not think this is true, because the data that the ISP sees is encrypted tunnel in case of VPN usage. They can not do packet inspection to limit some kind of traffic. Also even UDP trackers not working. When talking about ISP, in case you mean the VPN provider, that is also not true per my experience as i am using rented virtual private servers in different professional datacenters (just linux computers, not a vpn service) as a OpenVPN server and problem is everywhere. (maybe i should try to use different vpn server software?). Btw. i agree that the described issue may temporarily vanish if one for example restart qbt or change VPN server, but it is just temporary from my experience.

[benzoto]

I'm having the same issue however it just started. Yesterday it was working ok. I'm trying this on Azure containers and now it suddenly stops.

[DominikDeak]

How can fix it when I have used web UI.

I'm facing a similar situation. I have about 20 trackers sitting there, with a "Not Working" status for every new magnet link I added.

[expressrussian]

I use no VPN. I have the same error. All trackers are not working.
qBittorrent v4.1.8 Web UI
Sometimes one tracker works. It has "ipv6" in its name.
"Ping request could not find host bt.t-ru.org. Please check the name and try again."
But nslookup finds it. Strange.

[WolfieXIII]

Something I found solving this for myself ... IPVanish most recent update has an option to kill local network traffic is the killswitch is enabled. This option while providing extra security also breaks uPnP. Disabling this option fixed my uPnP and thusly my ability to lookup and connect to trackers.

[joe1970]

Hi,
I am experiencing this problem in qbittorrent version 4.2.1 on Ubuntu. It started some time last year. The symptoms are that sometimes torrents do not start on certain trackers. I am saving torrent files into a monitored folder and the torrent is picked by qbittorrent. But it goes into "stalled" status showing also "Not working" for all trackers. After closing and re-starting qbittorrent these torrents immediately start downloading. So I think it is not an issue of the trackers.
No solution has helped other than re-starting qbittorrent.
The important thing is that this is a persistent issue also in the latest version of qbittorrent.

[WillKoehrsen]

Encountered the same problem with all trackers listed as "Not Working" and solved as follows:

I went into the logs at ~/Library/Application Support/qBittorrent/logs/qBittorrent.log (on MacOS) and saw the following errors:

(C) 2020-03-02T15:21:57 - Failed to listen on IP: 0.0.0.0, port: TCP/22448. Reason: Address already in use
(C) 2020-03-02T15:21:57 - Failed to listen on IP: fe80::1%lo0, port: TCP/22448. Reason: Address already in use
(C) 2020-03-02T15:21:57 - Failed to listen on IP: fe80::aede:48ff:fe00:1122%en5, port: TCP/22448. Reason: Address already in use
(C) 2020-03-02T15:21:57 - Failed to listen on IP: fe80::1c5b:803e:dd6b:6048%en0, port: TCP/22448. Reason: Address already in use
(C) 2020-03-02T15:21:57 - Failed to listen on IP: fe80::ac61:d2ff:fe50:b44c%awdl0, port: TCP/22448. Reason: Address already in use
(C) 2020-03-02T15:21:57 - Failed to listen on IP: fe80::ac61:d2ff:fe50:b44c%llw0, port: TCP/22448. Reason: Address already in use
(C) 2020-03-02T15:21:57 - Failed to listen on IP: fe80::ff1a:3edb:a269:1cc0%utun0, port: TCP/22448. Reason: Address already in use
(C) 2020-03-02T15:21:57 - Failed to listen on IP: fe80::5854:8f62:b795:b69f%utun1, port: TCP/22448. Reason: Address already in use

This suggested that the outgoing port was used by another service (if anyone knows more about this, I'd be glad to hear).

I then went into Preferences > Connection and set the incoming port to random.

Immediately the trackers began working. In the logs I now see:

(I) 2020-03-05T09:34:35 - qBittorrent is successfully listening on interface :: port: TCP/51325
(I) 2020-03-05T09:34:35 - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP/51325
(I) 2020-03-05T09:34:35 - qBittorrent is successfully listening on interface 0.0.0.0 port: UDP/51325

Torrents are downloading as expected. I hope this helps!

[Frontlemon]

I encountered the same problem...
I am attaching a screenshot which shows that qBittorrent fails to download a torrent while other torrent downloaders (my example uses Deluge) can download with no problem...
The problem is always that trackers are listed as not working...
Happens both with public and private trackers...
Happens with whatever ports selected, (I don't have VPN and not using proxy either)...

Log shows no errors!

(N) 2020-03-06T18:47:27 - qBittorrent v4.2.1 started
(N) 2020-03-06T18:47:27 - Using config directory: /home/xxxxxxxx/.config/qBittorrent/
(I) 2020-03-06T18:47:27 - Trying to listen on: 0.0.0.0:31384,[::]:31384
(N) 2020-03-06T18:47:27 - Peer ID: -qB4210-
(N) 2020-03-06T18:47:27 - HTTP User-Agent is 'qBittorrent/4.2.1'
(I) 2020-03-06T18:47:27 - DHT support [ON]
(I) 2020-03-06T18:47:27 - Local Peer Discovery support [ON]
(I) 2020-03-06T18:47:27 - PeX support [ON]
(I) 2020-03-06T18:47:27 - Anonymous mode [OFF]
(I) 2020-03-06T18:47:27 - Encryption support [ON]
(I) 2020-03-06T18:47:27 - GeoIP database loaded. Type: GeoLite2-Country. Build time: Wed Nov 20 00:42:33 2019.
(N) 2020-03-06T18:47:27 - Options were saved successfully.
(I) 2020-03-06T18:47:27 - Successfully listening on IP: 127.0.0.1, port: UDP/31384
(I) 2020-03-06T18:47:27 - Successfully listening on IP: 192.168.0.17, port: UDP/31384
(I) 2020-03-06T18:47:27 - Successfully listening on IP: ::1, port: UDP/31384
(I) 2020-03-06T18:47:27 - Successfully listening on IP: fe80::c570:1b51:e87c:5b59%wlp0s20f0u4, port: UDP/31384
(N) 2020-03-06T18:47:27 - 'kali-linux-2020-1a-installer-amd64-iso' restored.
(I) 2020-03-06T18:47:27 - Python detected, executable name: 'python3', version: 3.8.1

In my case not even trackers with only IPs in its address works as mentioned earlier (@slrslr)
Manjaro linux, qBittorrent v4.2.1

[Frontlemon]

Ok, a little update that might help resolve this issue...
I tried to download the torrent again and the log came out as follows:

3/7/20 1:08 AM - Tracker 'udp://tracker.kali.org:6969/announce' was added to torrent 'kali-linux-2018-3a-amd64-iso'
3/7/20 1:08 AM - Tracker 'http://tracker.kali.org:6969/announce' was added to torrent 'kali-linux-2018-3a-amd64-iso'
3/7/20 12:54 AM - Successfully listening on IP: 2401:4900:1049:cbc3:1044:40:69f8:2, port: UDP/58976
3/7/20 12:54 AM - Successfully listening on IP: 2401:4900:1049:cbc3:1044:40:69f8:2, port: TCP/58976
3/7/20 12:54 AM - Successfully listening on IP: 2401:4900:1049:cbc3:e708:fd1f:c7ff:bbc8, port: UDP/58976
3/7/20 12:54 AM - Successfully listening on IP: 2401:4900:1049:cbc3:e708:fd1f:c7ff:bbc8, port: TCP/58976
3/7/20 12:54 AM - Successfully listening on IP: fe80::a272:3491:b500:3dce%wlo1, port: UDP/58976
3/7/20 12:54 AM - Successfully listening on IP: fe80::a272:3491:b500:3dce%wlo1, port: TCP/58976
3/7/20 12:54 AM - System network status changed to ONLINE
3/7/20 12:54 AM - Successfully listening on IP: 192.168.0.2, port: UDP/58976
3/7/20 12:54 AM - Successfully listening on IP: 192.168.0.2, port: TCP/58976

And as usual, all trackers were listed as not working.

Then suddenly at 6:47 AM qBittorrent displayed the following message:

3/7/20 6:47 AM - Detected external IP: 182.66.44.138

and started downloading the torrent and the status of the trackers changed to working...

[dilkie]

I'm seeing the same thing... with VPN off, it can detect my address (even though I'm behind CGN on mobile LTE so my router doesn't even have a public ip... With the VPN on, I start up qbittorrent and the logs don't show it can detect my external address (which, obviously, other things can). Wonder if the ip detection code is at fault? maybe using something funky?

{edit} Interesting... When using Private Tunnel VPN, qbit doesn't detect the public ip.. when using OpenVPN with my own far end, it does and the trackers work... Odd, since Private Tunnel is using OpenVPN under the covers....

[rlegault33]

I had the same issue and the problem was that UPnP was not opening the port on my router TP-LINK Archer C3200. Once I went into NAT and open the port manually the trackers started working again.

[Xunnamius]

Encountered the same problem with all trackers listed as "Not Working" and solved as follows:
...
Torrents are downloading as expected. I hope this helps!

@WillKoehrsen's solution worked. Thanks!

[cotwitch]

In my opinion, setting a "new" random port using UPNP doesn't actually resolve this issue - it just overcomes the real problem (Address-port-combination is already in use). It's just kind of workaround - not a real solution.
To be honest, I see the similarity with #10312 even it's different architecture...

[Drobilliard]

I have at least somewhat of a solution because this is happening for me. I used ngosang's IP Based tracker list and had them automatically add to each of my torrents, I am now getting Peers, Seeds, Leeches and Downloaded information in the tracker info. Beforehand I was just getting Not Working on every tracker. The only issue now is that it's not seeming to download metadata still even though it seems to connect to the trackers...

The tracker list I used to get this far is here: https://github.com/ngosang/trackerslist

I honestly think this is down to the fact that ports set on the user's end are ignored by the VPN, because most VPN providers don't allow for static ports as they are a security issue that would allow you to be identified. At least, that's what my VPN has responded with when asked.

I don't think port or uPNP set up on routers is really going to matter, because the tunnel occurs between your computer and the remote server hosting the VPN. So really, your router will just tx/rx your data and blank anything to do with ports because it can't see inside the tunnel.

[Balls0fSteel]

@Drobilliard Haha, the lack of port forward is just a nice excuse. They probably lack the talent, resources, or just want to save money. Mullvad who is a very privacy concious provider, has it. Windscribe who is also very privacy-focused, has it. And so many others.

Just change providers once your sub is done with. :p

[FranciscoPombal]

Original report is for a very old version, and the subsequent comments over time have referred to many different issues with the same symptom which have since been fixed.
Recent connectivity issues have been addressed in #11735.
The one outstanding SOCKS5 issue that remained is being handled in #12583 at the time of writing.

If you have VPN/proxy problems with the latest release that are not related to that SOCKS5 issue, first make sure the "network interface" and "optional IP address to bind to" in the advanced settinggs are set to correct values according to your system's network configuration. If you are sure you've configured everything correctly and still have problems, please open a new issue report.