qBittorrent-IPV6-UDP-dns解析缓慢and不支持IPV6地址直达

[rer]

qBittorrent-IPV6-UDP-dns解析缓慢and不支持IPV6地址直达
（qBittorrent-IPV6-UDP-dns resolution is slow and does not support direct udp IPV6 address）


据我了解 我的电脑使用

Code: Select all

nslookup bt.rer.lol

命令查询解析非常快 而且默认是IPV6解析
我认为这是qBittorrent的一个程序问题：响应速度 达不到预期
As far as I know, my computer uses the command to query and parse very quickly, and the default is IPV6 parsing.
I think this is a programming issue with qBittorrent: response speed not up to expectations

[rer]

在过去 旧版本的 qBittorrent 就不支持UDP的IPV6
当时我还以为是我的tracker服务器问题 还傻傻的去别人的项目那边提交
后来我才知道 是qBittorrent 的问题 即便是现在 更新了最新版
也只是从不能用 到 缓解 一卡一卡的 缓慢能用
希望这些问题 能得到解决
In the past, older versions of qBittorrent did not support UDP IPV6
At that time, I thought it was a problem with my tracker server and stupidly submitted it to other people’s projects.
Later I found out that it was a problem with qBittorrent. Even now, it has been updated to the latest version.
It just went from being unusable to being relieved, one lag after another, and then slowly being usable.
Hope these issues can be resolved

[Peter]

qBittorrent relies on libtorrent ( https://libtorrent.org/ & https://github.com/arvidn/libtorrent ) for this functionality... or Qt.
I am 99% sure libtorrent is at fault here so to speak, because I just checked and qBittorrent only does DynDNS work and nothing else.

Please check their Github issue tracker and see if there is any ticket regarding this.

Maybe this?
https://github.com/arvidn/libtorrent/issues/7195

Not sure if you use a proxy though.

[rer]

我非常确认 这个问题 出在IPV6的UDP上 当tracker包含 IPV4和IPV6地址时 qBittorrent解析tracker域名的速度就会变得非常慢 仅仅是UDP很慢
因为过去qBittorrent不支持UDP的IPV6现在虽然支持了 但是也只是兼容模式一样 更新非常的慢 我尝试将tracker的地址使用IPV4模式的UDP://xx.xx.xx.xx:6969就能非常的快 这是一个tracker的UDP解析域名到IPV6缓慢的问题
I am very sure that this problem lies in UDP of IPV6. When the tracker contains IPV4 and IPV6 addresses, qBittorrent will become very slow in parsing the tracker domain name. It is only UDP that is very slow.
Because qBittorrent did not support UDP IPV6 in the past, although it does support it now, it is only in compatibility mode and the update is very slow. I tried to use the tracker address in IPV4 mode UDP://xx.xx.xx.xx:6969 and it was very fast. This is a problem of tracker’s UDP resolving domain name to IPV6 slowly.

[Peter]

It is not qBittorrent. I am 99.99999999999999% sure.
Again, qBittorrent itself does NOT have any kind of networking code.

- It relies on Qt solely
- It only updates DynDNS via code
- libtorrent is the library doing all the heavy lifting in the background

For example:
https://github.com/arvidn/libtorrent/bl ... ection.cpp

Please make a report on their issue tracker and help with the debugging. I even linked a ticket where help is needed.

[rer]

谢谢你！REPLY
我解决了。。该问题出现的原因是win10系统
启用了IPV6临时地址 导致的多地址IPV6
应用查询 当前可用上 可能查找了很久 我禁用了临时IPV6地址 就能迅速反应解析了！
刚刚咨询了 微软的AI【Copilot】他告诉了我方法
Thank you!REPLY
I solved it. The cause of the problem is the win10 system
IPV6 MULTI-ADDRESS CAUSED BY IPV6 TEMPORARY ADDRESS ENABLED
The application query is currently available on the may have been searched for a long time I disabled the temporary IPV6 address and it will be able to respond quickly!
Just consulted Microsoft's AI [Copilot] and he told me the method

window关闭临时ipv6地址、开启临时ipv6地址（disables temporary IPv6 addresses and enables temporary IPv6 addresses）：
https://www.cnblogs.com/Twobox/p/16342872.html

[rer]

似乎还是不行 又开始 解析缓慢了。。
感觉是底层DNS解析的问题？（似乎并不是……）
It still doesn't seem to work, and it's starting to parse slowly.
It feels like it's a problem with the underlying DNS resolution？（It doesn't seem to be...）

[rer]

由于libtorrent没有windows原生应用 所以我无法测试 但是他的源码我已经向AI询问 并未发现BUG 并且我使用qBittorrent本地tracker通信时进行抓包 也是发现tracker通信包 瞬间就完成了 这并不是网络问题 我更愿意相信 这是qBittorrent应用响应UDP的IPV6速度的问题
循着这个思路 我对其他BT软件进行了测试(Tixati) 以下是对比图
qBittorrent(IPV6 域名)需要长达10多秒甚至更久来回传UDP tracker的响应
Tixati则是瞬间完成 或者几秒内 状态也是很直观的能看到
Since libtorrent does not have a native Windows application, I cannot test it, but I have asked AI about its source code and found no bug. And I used qBittorrent to capture packets when communicating with the local tracker. I also found that the tracker communication packet was completed instantly. This is not a network problem. I am more aware. Want to believe this is an issue with the IPV6 speed of the qBittorrent app responding to UDP
Following this idea, I tested other BT software (Tixati). The following is a comparison chart.
qBittorrent (IPV6 domain name) takes more than 10 seconds or more to send back the response of the UDP tracker
Tixati can complete it instantly or within a few seconds, and the status can be seen very intuitively.