Open Aobanana-chan opened 2 months ago
I have the same issue. qBittorrent: 4.6.5 Operating system: MacOS Sonoma 14.5
I don't use anything for connecting to the trackers.
I think I have figured out the cause of the issue. I am using qBittorrent with V2rayN. When I set the proxy type to HTTP (port 10809), almost all trackers fail to work properly.
However, when I switch the proxy type to SOCKS5 (port 10808), the situation improves. Most HTTP protocol trackers start working, but UDP protocol trackers still fail to function properly. The reported error is mostly "Permission denied."
It seems that qBittorrent has very poor compatibility with proxies. BitComet is using the same proxy settings and does not have these issues.
When I disable the proxy settings in qBittorrent, the tracker connection issues are resolved. However, since my RSS feed requires a proxy, I can't disable it.
I hope qBittorrent can optimize its proxy support.
However, since my RSS feed requires a proxy, I can't disable it.
You can enable proxy for RSS feeds only.
However, since my RSS feed requires a proxy, I can't disable it.
You can enable proxy for RSS feeds only.
Thank you very much for your response. Enabling the proxy only for RSS has indeed solved a significant part of the problem.
Initially, I enabled the proxy not only for RSS but also for DNS queries. In China, there are certain restrictions on some domain names, and we may receive incorrect IP addresses through DNS queries. Although it's not essential, using a proxy for trackers is somewhat necessary. The proxy used to work very well, and it would be great if it could function as smoothly as it did before.
I would like to ask if qBittorrent has any plans to address the following issues in the future:
If there are no plans to fix these issues, I will close this issue and use your response as a temporary solution. However, if there are plans to address these problems, I think it's best to keep this issue open.
HTTP-type proxies do not work for all trackers.
I guess that's intended. HTTP proxy can only work with HTTP trackers.
SOCKS5-type proxies do not work for any UDP protocol trackers.
This issue already was fixed in libtorrent 2.0.8/2.0.9, afaik. See arvidn/libtorrent#6986 and arvidn/libtorrent#6987. Idk about plans of backporting that fixes into 1.2.x branch though. I'd say chances are low.
HTTP-type proxies do not work for all trackers.
I guess that's intended. HTTP proxy can only work with HTTP trackers.
SOCKS5-type proxies do not work for any UDP protocol trackers.
This issue already was fixed in libtorrent 2.0.8/2.0.9, afaik. See arvidn/libtorrent#6986 and arvidn/libtorrent#6987. Idk about plans of backporting that fixes into 1.2.x branch though. I'd say chances are low.
But i still have this problem with my own qBittorrent Enhanced Edition built with libtorrent 2.0.10. Maybe that's not just libtorrent's problem. Or libtorrent didn't fix it entirely.
qBittorrent & operating system versions
qBittorrent: 4.6.5 Operating system: Windows 11 23H2 (22631.3880) Qt: 6.4.3 Libtorrent: 1.2.19.0 Boost: 1.84.0 OpenSSL: 1.1.1w zlib: 1.3.1
What is the problem?
Recently, I have noticed that almost all trackers in qBittorrent are in a "not working" state, with only a few functioning properly. Most of the trackers are showing errors and failing to connect. The errors are as follows:
I am also using BitComet to connect to these trackers, and they work fine there without any errors.
I found a similar issue, #20882, but I am not sure if it is related. According to that issue, the problem might be caused by the tracker server having multiple IPv6 addresses and responding with a different IP than the one targeted, leading to "timeout" errors. It was suggested that qBittorrent should check the transaction_id according to the specification or inform the server owner to avoid using multiple different IP addresses for responses.
Could you please investigate this issue or provide any advice on how to resolve it?
Thank you!
Steps to reproduce
No response
Additional context
No response
Log(s) & preferences file(s)
No response