XIU2
-n 参数大于200程序运行怪异
#268 这种情况说明 TCP 链接被 “阻断” 了，导致链接终止（CloudflareST 就将其归为 IP 不可用了）。 延迟测速并发调高后就复现的话，可能是触发到了什么机制，导致 TCP 链接被阻断，只有刚开始的部分 IP 完成了测试。
你这是路由器？你在电脑上试过没有？或者其他设备。
我自己也没啥头绪，因为反馈类似问题的，这几年我就没遇到几个，而和你这个问题差不多，更是只有 #268 这一个。。。
我看着更新日志想了想，好像自从 v2.0.0 完全重构后，我就没怎么动过 TCPing 相关的代码。 只有 v2.1.0 新增支持 IPv4 + IPv6 混合测速时，加了个 IP 地址类型判断。 此外 v2.2.0 新增了另一种延迟测速模式 HTTPing，以及附带的 匹配指定地区 功能，和 延迟测速时显示可用 IP 数量 时有所变动，但主要都针对是 HTTPing，对 TCPing 自身代码修改很少。
我浏览了下最近对 TCPing 代码的更改，也没有什么太大改动，都是边边角角的，看起来也没啥问题，完全没头绪。。。 https://github.com/XIU2/CloudflareSpeedTest/commits/master/task/tcping.go
请你挨个测试确定是从哪个具体版本号开始才出现该问题的，我才能判断是那些代码改动引起的该问题，否则我无法解决。
#268 反馈该问题时是 2022年12月7日，当时软件版本号还是 v2.1.0。
也就是说 v2.0.3 版本正常，v2.1.0 及后续版本均存在该问题？
但我看了下只有 v2.1.0 版本关于 TCPing 的代码只改动了几行呀，也就是加了个 IPv4 判断，怎么会引起这个 BUG 咧。。。
https://github.com/XIU2/CloudflareSpeedTest/commit/021914f975195ea493193612abc3c6e67facded7#diff-7759c5798593425341668c380ca48fd03a4f9853faaa237d0b0d4563c62cb136
你会 Debug 的话那倒挺好，这种我无法复现的问题，属实难以排查解决。。。通过文字交流排查的话效率太低。。。
我这边测试了下，-n 500 依然正常，过去几个月了就两个人反馈，说明复现条件较为苛刻。
就像 v2.2.1 修复的一些情况下下载测速数值过大的问题一样，一般人根本碰不到，这个 BUG 是从项目之初就存在的，但几年过去了，那么多的使用者，结果反馈的人才 4、5 个，靠文字交流排查到最后都不了了之了，而因为信息太少，我自己也是完全无法复现，最后也是受到了一个反馈的启发，在海外大宽带服务器上才顺利复现了。。。
结果碰到懂 Golang 的热心用户，默默的一点一点排查最后发现问题所在代码，提 PR 成功修复了这个问题。。。我感觉我也跟中彩票了差不多（狗头~
我自己也比较咸鱼，平时都是能用就行，毕竟我当初也是为了解决自己的需求而临时自学 Golang 写的这 CloudflareST，最近几个版本基本上都是别人提的 PR（特别是我早期版本写的很烂，后来突然有一天有个人帮我完全重构了代码 v2.0.0，给我看傻了），我倒是省力了哈哈~
用psping -t www.baidu.com:80 确认，这个一般是移动宽带限制了每秒并发新建连接数导致，自己降低下就好了 https://qps.itzmx.com 这里也可以检测宽带限制情况，电脑打开点开始，手机WiFi打开B站测试流畅度之类
@1265578519 psping 这个工具有个比较在意的地方是在进行TCP 测试之前会进行一次热身，这样做或许可以避免 #256 的问题
https://qps.itzmx.com/ 这个网址只是进行DNS测试么？开Deverlop tools 看到有大量的无效地址的请求，主要性能瓶颈都卡在了DNS 请求上或者说是目标域名的ns 服务器上🧐
@charSLee013 只产生UDP请求，协议为DNS，因为不会获得DNS解析结果，自然不会发生http协议流量，这个项目可以用来在线测试运营商连接数限制。期间可以用psping来确认tcp中断情况。 注：ping用的icmp协议运营商不会限制，所以触发限制时传统ping不会出现丢包。
@Xmu2022 这不是 BUG。 你没搞明白图里的各个数值都是什么意思，我给你解释一下：
延迟测速进度条后面的 可用：250 指的是在延迟测速完成后有 250 个 IP 没有超时，但你还设置了延迟上下限的条件，按照条件过滤后只剩下 120 个（也就是下面写的下载测速队列）。
然后接下来会对这 120 个 IP 进行下载测速。
下载测速进度条中的 32 / 100，前者指的是找到了 32 个满足下载速度下限条件的 IP（即下载速度高于 1MB/s ），后者 100 指的是你要求找到 100 个满足下载速度下限条件的 IP。
另外，提醒一下，如果你指定的 -dn 大于下载测速队列，比如你延迟测速后只剩下 60 个 IP 了，那么下载测速进度条中后面的数字就会变成下载测速队列的 60 个而非你 -dn 指定的 100 个了。
但总共才 120 个 IP，不可能全都满足条件，因此软件在测速完这 120 个 IP 后，只找到了 32 个下载速度高于 1 MB/s 的 IP，剩下的 88 个 IP 都是“不及格”的。
因此，这不是 “每次测速都不到100，就中断了”，而是所有 IP 都下载测速完了，只找到了 32 个满足条件的。