关于该BUG测试2
在服务器A中取消防火墙封锁UDP，重新启用任务，在自动检测的情况下，服务器B依旧无法连入服务器A，所以该BUG和防火墙无关系
3台服务器均使用了1.78测试版
以前我也测过utorrent，是根本无法NAT打洞的。。。包括 qBittorrent 也不行，可能开发者都搞错了，现在市面上所有的BT软件，，基本都是需要对方为外部网络，TCP端口开放，然后通过升级到UTP传输而已，而不是打洞
比特彗星1.78这个版本，，连都连不上，BUG比较严重了，等修复
我试了自动检测，优先，强制，三个选项都无法进行连接，只有禁用才可以
qBittorrent 的nat1打洞测试，并打洞不上，无法从服务器C连接到服务器到B，但是它不存在比特彗星打开UTP后就无法连接服务器A的BUG，顺便吐槽一下，，qBittorrent 这么多年了，单线程传输速率还是这么烂，5MB/S极限了，比特彗星可以跑到80MB/S
不应当由统一服务器的方式，安全性不足，易查出作者信息，容易喝茶，最好是通过DHT网络查询其他有公网ip的客户端用户协助进行NAT内网穿透，但由于实际网络的多样性，不一定能穿透成功
感谢反馈。这种情况下应该是建立TCP连接。目前版本的uTP连接需要是pex返回的peer才会尝试，tracker返回的应该不行。我也来测试一下。
来自tracker的节点应该只包含本机申报的监听端口，而不提供NAPT后的外部端口。
因此只能依赖PEX提供协议支持和外部端口信息来打洞。
这里可能出现一个问题，如果某个IP先从tracker获得，后又获得PEX来源，这时候软件会如何处理？
如果把PEX来源的信息丢弃，只保留tracker来源的话，则不具备可用作UDP打洞的正确外部端口。
另外，如果通过TCP连接上中继节点，交换的是TCP连接时的外部端口。
这个外部端口显然是无法用作UDP打洞的，因此需要再建立UDP连接获得一个新的外部端口，并把它通过PEX交换给需要打洞的peer。
bug已修复，是判断使用TCP加密协议重连或uTP重连的代码问题。在下一版发布前，您可以暂时把协议加密设置为禁用，以方便测试。
目前尚无机制处理NAPT后的外部端口与peer自己监听端口不一致的状况。后续版本再优化吧，先改bug
目前尚无机制处理NAPT后的外部端口与peer自己监听端口不一致的状况。后续版本再优化吧，先改bug
以前我也测过utorrent，是根本无法NAT打洞的。。。包括 qBittorrent 也不行，可能开发者都搞错了，现在市面上所有的BT软件，，基本都是需要对方为外部网络，TCP端口开放，然后通过升级到UTP传输而已，而不是打洞
这就是我上面说的，其实目前市面上没有任何一款软件做了打洞，单纯的只是升级为同端口的udp传输而已。
如果nat打洞功能没有实现成功，，，那utp实属无意义，等下一个测试版看看
目前应该还是有点意义吧，好像μtp的加入，能增加一点点速度（部分资源，支持μtp的）。
如果无法实现打洞，那么uTP的意义就只有它的初衷——拥塞控制。
uTP作为基于UDP的传输协议，当与TCP流量发生竞争时，自降优先级以保证TCP连接（主要是网页）的畅通。
在电缆时代，BT占带宽导致网页体验变差的情况非常明显，那时候大多采取限速的方法避免。
但限速方案的缺点也很明显：
uTP的诞生是为了解决这些问题。
至于打洞，是所有UDP连接都拥有的特性。
而uTP基于UDP，理所当然地被赋予了这种期待。
在普遍光纤入户的现在，带宽已经不是当年的级别。
当然，带宽占满仍然会导致延迟增大，这一点上uTP有它的意义。（虽然重要性已经降低）
但UDP连接本身是个双刃剑。
比起同样是基于UDP连接的QUIC，甚至WireGuard，uTP显得有点简陋。
在一些环境下使用uTP可能更好，但反之亦然。
我赞成新增uTP的支持，但不能盲信。
当然了，最理想的是把UDP打洞搞出来。
补充：
据我观察，在TCP和uTP均可被直接发起连接的情况下，由远程发起的大部分连接仍然是TCP。
这说明大部分BT客户端是采取TCP优先的策略。
这情况下uTP的拥塞控制可能没有效果，因为前提是占带宽的是uTP连接，它才可以自我调整。
据说有根据uTP拥塞控制器提供的信息来对TCP连接进行限速的机制，具体实现情况未知。
不会有速度增加 因为是基于udp传输的 全世界在哪都不欢迎udp
特别是这种未加密的utp流量 直接识别 限速qos在骨干网上 如果打洞不了 确实没意义了
新的bittorrent.utp_after_holepunch选项和之前的bittorrent.peer_hole_punch有什么区别。。
bittorrent.peer_hole_punch，是和其它peer交互pex报文？
bittorrent.utp_after_holepunch是执行打洞？
不知道这个版本能打洞了没，，要花时间测一下
根据前面的讨论推测，bittorrent.utp_after_holepunch应该是用来控制是直接发起uTP连接，还是通过UDP打孔方式发起。
bittorrent.peer_hole_punch 选项用于启用 BEP 55 Holepunch extension
bittorrent.utp_after_holepunch 选项用于控制发起uTP连接前是否需要先向第三方请求协助打洞
设置窗口BT设置页面里的uTP选项用于控制peer连接优先使用 TCP 或 uTP 的顺序
目前实现的BEP 55打洞只支持 Full Cone NAT / Restricted Cone NAT / Port Restricted Cone NAT 三类，对于 Symmetric NAT 暂时无解。
只需要支持NAT1的Full Cone NAT就行，后三种不用考虑，基本不太现实，nat3和nat4效率太低，nat2还可以凑合用用
晚上抽时间我再测一下好使了不
是不是说反了？
另外禁用utp_after_holepunch后，若无法建立uTP连接，会不会重新触发UDP打孔？
就UDP打洞来说，Symmetric NAT 可以与 Full Cone NAT 和 Restricted Cone NAT 建立连接。
NAT4无法接收来自任何未知的端点的连接。
NAT1和NAT2则能够接收来自NAT4发起的连接，但NAT4主机发起这个连接时所使用的是一个新分配的端口。（如果IP也分配到与此前不同的，则只有NAT1才能接收连接）
NAT1和NAT2主机需要对这个新接收到的端点再发起一次连接，才能建立双向的通信。
如果我没理解错，BEP 55会让双方同时发起一个常规的uTP连接。
而NAT1或NAT2主机在接收到这个连接后，按道理会向其NAPT后的[IP:PROT]返回应答。
这时候尽管这个端点与之前中继节点交换到的信息不一致，但实际上连接已经成功建立。
BEP 55让双方同时发起连接，因此只要是Cone NAT，无论是NAT1还是NAT2、3，都能越过各自的防火墙。
由中心服务器控制，远端单方面发起连接时，才需要考虑淘汰NAT234。
说到底BEP 55的方案效率就是这么低。
感谢反馈，已更正
目前不会
您研究得很透彻。搭建各种NAT类型的测试环境很麻烦，我这边还没仔细测过呢。
感谢 @wxhere15 版主又开始持续更新BitComet，
我这边一个问题不知道版主能否优化，
就是有关Torrent市场他人共享种子的问题，
因为我BitComet设定Torrent市场是设定无限，
所以数据一直长大已经将近一千万笔，共2.3G的SQLite DB大小，
但是我又舍不得把累积了这么久的数据重新建置，
我建议可否在介面上增加查询种子笔数的条件，
例如用SELECT * FROM “PeerShares” LIMIT “笔数”，
去避免一次捞取这么大容量的DB的数据，
以上是我小小的期望，也期望BitComet能够越来越好，谢谢。
nat1环境好搞，购买vps服务器就行，基本都是nat1，然后第三台设备用家中自己的电脑，可以在路由器中设置成nat4，就可以进行测试了
感谢您的关心和支持。目前彗星启动时开启了种子市场，就会加载全部数据库记录。如果只加载部分数据的话，排序、查找、保持记录唯一性等操作等很麻烦。欢迎您提出更具体的功能建议。您也可以使用 sqliteadmin 等第三方程序对数据库文件进行整理、备份等操作。