软件在测试延迟时正常，只要一进入测速阶段，网络就中断，右下角显示为无法识别的网络！

[somebird]

结果测速全是零，然而将result.csv文件中的一百多个IP复制，将IP.TXT中的内容全部用这一百多个IP替换掉，再运行软件，就可以正常测速前十位的速度。请问一下是哪里出了问题？有办法解决么？

[XIU2]

命令行方式运行时，加上 -n 50 试试，即调低 测速线程数量（默认为 200）。

这种情况，是因为你的设备无法承受这个延迟测速的并发，这种情况以前有好几个人反馈过了，所以我才将最初的默认 500 改成 200 了，结果还是有人测速时会出现网卡、断网的情况（虽然相比以前少很多了），但是我这边即使跑到 800 也没感觉。。。而我的也只是个低端路由器，性能也很捉急。

当然，这些反馈中，有一些人是在路由器等微型设备上跑的，有的是连 WiFi 网络跑的，这种情况自然影响更大（特别是后者，WiFi 比有线会占用更多设备资源，并发承受能力更差）。

你最初延迟测速时有 4000+ 个 IP，而再次测速时你给改成了 100+ 个 IP，这点数量自然不会出现网卡、断网的问题了。
另外，这只是 IP 数量，还有个 -t 4 延迟测速数量，即每个 IP 延迟测速几次，默认为 4 次，即实际测速数量为 IP 数量*4 。

---

“软件在测试延迟时正常，只要一进入测速阶段，网络就中断”

实际上，在测试延迟过程中，可能网络就已经不行了，但是软件只会将后续测试延迟的 IP 认为是超时，并继续测速下去，导致网络一直堵着，而到了下载测速阶段，自然是无法测速了。

[somebird]

懂了， 谢谢楼主指点！

[CrazyBoyFeng]

大部分延迟测试时卡住、网络中断的原因，除了设备性能，运营商限制最大连接数也是个很重要的因素。超过了运营商设置的最大连接数就会被运营商强制踢掉线。我估计 #238 也是这个问题。
解决办法是把 -n 协程数（也就是并发连接数）设置得小一点。但这样延迟测试耗费时间就会比较长。
或者 @XIU2 你考虑一下要不提供个开关跳过延迟测试，直接从速度测试开始。

[XIU2]

@CrazyBoyFeng 不选出来 IP 怎么去下载速度测试。。。直接挨个把所有 IP 下载测速一遍？这效率也太低了吧，而且还严重浪费时间（大量不可用、高丢包的 IP）。

下载测速是单线程的，一次一个，而延迟测速是多线程的，一次 200 个（默认）。
延迟测速就是过滤筛选一遍 IP 段，过滤掉不可用的、高丢包、高延迟的 IP，然后再对剩余少量优质 IP 进一步下载测速提纯。

延迟测速是软件核心功能，不可能跳过的，否则就破坏了软件整体功能逻辑。
下载测速反倒是可选的，我平时为了节省时间压根就不下载测速，仅延迟测速就完事了（需要提高 -t 测速次数来保证测速结果质量），只要延迟够低、够稳且不丢包，那么速度就差不到那里。

[CrazyBoyFeng]

@XIU2
443 能通的 IP 不一定能用。除了假墙，可能的原因还有：作为中间传输节点、某些地区专用的 IP，某些网站专用的 IP。后两种情况甚至 HTTP 也是通的，但是访问到的其实是个报错页面（我原先写过一个用 HTTP OPTIONS 探测是否可用的脚本，就在这个问题上踩了坑）。
虽然 ip.txt 中已经将中间传输节点初步排除，不过 Cloudflare 的路由实际上是动态变化的。

所以在我的实际使用中，最终还是依赖速度测试。（为了快速完成测试，我使用了小文件。这样虽然测速不精确，但是至少可以保证筛出的IP是可靠的。）

如果要实现纯速度测试逻辑，确实要重建 IP 选取的逻辑。之前是从延迟测试的结果中从高到低挨个测速。纯速度测试就只能随机选取 IP 了。如果你觉得增加了这个软件的复杂度的话，那我还是考虑另写吧。

[XIU2]

@CrazyBoyFeng 我已经很久没遇到过假墙了，好像今年就没遇到过，至于专用 IP 那都是极少数。

该软件是我为了解决个人需求写的，目前功能已经完全满足我使用了，所以如无必要不会再增加新功能，或大量改动代码了。距离上个版本发布已经过去 8 个月了。

对于这种个性化需求，尽量自给自足吧，我写的这些开源项目就是不喜欢完全指望别人~ 为此专门临时学的 Golang（够用即可）