我家的网络是NAT1，意味着：只要本地打通了本地到NAT设备的映射，任何外部设备都可以直接通过NAT的端口访问本地。
同时，我也靠 站内 和站外的几篇教程，利用 “Lucky”软件 成功地给自己电脑上的webdav服务器进行TCP打洞。我也试了一下，排除IPv6干扰项后，把端口给到比特彗星，结果比特彗星黄灯秒变绿灯。
但是，这也有两个弊端。
-
一个是端口可能会变化，每次都需要到Lucky软件里获取最新的端口，并确保NAT后的外网端口、Lucky软件内置端口转发的目标端口、比特彗星的监听端口三者保持一致。
-
另一个是所有的IPv4-TCP连接都变成了“127.0.0.1”，那么基于IP地址的反吸血保护就失效了，因为比特彗星和PeerBanHelper只能看到Lucky软件的IP。
可以看到，这几个IP均为本地的127.0.0.1，但是使用的客户端不一样。
所以，我的想法是：让比特彗星自己实现NAT1环境下的STUN-TCP打洞，打洞完成之后对Tracker服务器通报自己的NAT后的端口，实现“伪公网IPv4”。
这和比特彗星已有的UDP打孔是不一样的，这种方法可以让有NAT1的用户接收远程传入的TCP请求，体验与公网别无二致。
理论上，工作流程是这样子的：
- 检测端口是否开放。如果否，那么继续下一步。
- 检测用户是否开启STUN打洞功能。如果是，那么继续下一步。
- 检测NAT类型。如果是NAT1，那么继续下一步。如果不是NAT1（例如NAT3、NAT4、检测失败），那么再检测两次（总共检测3次），确认无误后放弃打洞。
- 已确认网络为NAT1。比特彗星以原来的监听端口向外打洞。
- 如果打洞成功，右下角显示：
（绿灯）NAT1打洞：监听端口（外部端口） - 向Tracker服务器通报自己打洞后获得的外部端口，不再通报自己的监听端口。
- 其他用户通过NAT端口连接到比特彗星，实现数据传输。由于NAT1打洞发生在比特彗星内部，所以比特彗星有能力得知对方的IP地址，而不是像借助Lucky软件一样只看得到“127.0.0.1”。
- 循环检测打洞结果是否有效。如果失败，重新打洞。
如果这个功能被做进比特彗星里，那么拥有NAT1的比特彗星用户将获得与公网用户完全一致的体验，这无疑是巨大的飞跃。
附：
Lucky软件作者维护的公共STUN服务器列表：always-online-stun/valid_hosts_tcp.txt at master · pradt2/always-online-stun · GitHub
