起因
由于nas坏了一块儿硬盘，在恢复后发现对应存储池反应很慢，所以重建存储池后把软件又装了一遍（数据已提前备份），然后就发生所有馒头tracker host not found 问题
解决办法
问题的本质是DNS在解析馒头域名时会请求IPV6解析，而IPV6解析速度过慢（15S）导致触发qBittorrent的tracker响应超时（默认10秒）。
编辑host,将tracker域名直接指向对应的ip（馒头是cloudflare节点，所以请使用cloudflare自选工具测出最适合你的ip然后填入host）
在你的dns服务器（如果你没自己搞复杂的网络，那就是连你nas的路由器）中禁止解析 IPv6 DNS 记录
过程
首先自然是控制变量了，我是威联通nas，qbittorrent是通过套件安装的，所以我就又安装了docker版的qBittorrent（版本均为最新版4.4.5），docker版也出现同样错误，所以排除套件问题。
查看了馒头论坛，在论坛的公告贴里置顶是一篇关于tracker问题的帖子，里面给的思路就是通过host给tracker配置固定ip，也就是上述解决方案的第一种，这里就解决了问题。但是我通过路由器配置了host却没有成功（我喜欢统一管理，不喜欢各个设备都有自己的网络设置，后期维护麻烦），这让我就得很奇怪，因为我浏览器访问没问题，说明DNS也是能解析出ip的，我就继续开始查这个问题。
首先在威联通nas上通过nslookup命令测试tracker域名，也是秒解析。这时我很怀疑人生，后来又抱着试一试的想法通过curl来测试tracker域名，此时出现耗时过久（15秒），这里终于重现问题，所以通过扶墙搜索得知qBittorrent跟tracker超时有关的参数（libtorrent参数）有
tracker_completion_timeout --向tracker发送请求后的超时时间，默认30秒
tracker_receive_timeout -- 等待从tracker接收数据的超时时间 默认10秒
这时我想试图修改tracker_receive_timeout，但查qBittorrent资料后没找到修改该参数的地方，所以只能排查为什么curl速度如此之慢。
通过命令curl -o /dev/null -s -w 'time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n' tracker域名
看到time_namelookup时间为15秒（意思就是dns解析耗时15秒），所以再次通过扶墙搜索，看到谋篇帖子里一个人通过strace（用来查看命令在执行时有哪些函数调用）发现curl会发送ipv6解析请求，这里恍然大悟，然后通过两个命令来看ipv4和ipv6两种解析的时间,分别是
ipv4： time dig A tracker域名
ipv6：time dig AAAA tracker域名
发现的确是ipv6时间为15秒，到这里终于找到问题，去路由器的dns设置里“禁止解析 IPv6 DNS 记录”（不同路由器不同系统叫法可能不同哈），然后重启qbittorrent，馒头tracker不再是host not found了，变成不工作，无法解析响应，这个也是扶墙搜索，只要上设置里关掉“验证 HTTPS tracker 证书”即可。
总结
总的来说，是qbittorrent使用的libtorrent库在请求tracker时会请求解析IPV6记录导致的问题,花了一天时间终于解决。（这里吐槽下网上很多人都是通过回退qbittorrent版本来解决，推断应该是旧版本qbit使用的库和新版本不一致导致的）。顺便提醒下，即便你没有我这个问题，如果你的PT站访问会走cloudflare，那么最好通过自选ip工具选一个最好的cf节点ip，然后设置host，这样会让你平时访问快很多。