arm5.6.7架构 -n限制线程无效,路由器内存小,直接卡死,并且没有测速结果,只会测出延迟

[lyxhwy]

问题描述

arm5.6.7架构 -n限制线程无效,路由器内存小,直接卡死,并且没有测速结果,只会测出延迟

软件版本

2.2.2/2.2.3/2.2.4

附加截图

No response

[lyxhwy]

@charSLee013

[lyxhwy]

@XIU2

[lyxhwy]

目前参数

[lyxhwy]

win11 测试线程没问题,速度很慢,路由器反而跑的很快,直到卡死

[lyxhwy]

延迟测试.路由器直接可以跑到3000,同样命令在win11,只能100左右

[lyxhwy]

路由器卡死之后,导致测速全为0

[XIU2]

你是如何判断的 -n 参数无效的？

路由器直接可以跑到3000,同样命令在win11,只能100左右 没明白这是什么意思。

建议你找一些不可用的 IP（443 端口超时的），然后去测速这些 IP，观察进度条是不是 10 个 10 个增加的（因为测速都是超时，所以每个 IP 的测速总时间都是一样的），如果是 10 个 10 个增加的，说明 -n 参数正常。

另外，无论是延迟测速还是下载测速，CloudflareST 都不会占用多少内存，因为收到的数据都是直接抛弃的（类似于 Linux 的 /dev/null，既不会存放到内存中，也不会存放到硬盘中）。

[lyxhwy]

你是如何判断的 -n 参数无效的？

路由器直接可以跑到3000,同样命令在win11,只能100左右 没明白这是什么意思。

建议你找一些不可用的 IP（443 端口超时的），然后去测速这些 IP，观察进度条是不是 10 个 10 个增加的（因为测速都是超时，所以每个 IP 的测速总时间都是一样的），如果是 10 个 10 个增加的，说明 -n 参数正常。

另外，无论是延迟测速还是下载测速，CloudflareST 都不会占用多少内存，因为收到的数据都是直接抛弃的（类似于 Linux 的 /dev/null，既不会存放到内存中，也不会存放到硬盘中）。

不是10个10个增加,是几百个几百个得增加,直接增加到3000+,然后路由器就卡死了

[XIU2]

你看清楚我说的内容，照我说的去做，并告诉我结果。

请按照我的指示去反馈内容，否则我无法排查问题。 因为你经历的情况，印象中以前反馈结果中有类似的，大都是其他问题导致的。

我现在有事要出去，等我晚上回来再继续帮你排查。

[lyxhwy]

你看清楚我说的内容，照我说的去做，并告诉我结果。

请按照我的指示去反馈内容，否则我无法排查问题。 因为你经历的情况，印象中以前反馈结果中有类似的，大都是其他问题导致的。

已测 ./CloudflareST -n 10 -t 1 -url https://abc.lyxhwy.top -o "result_hosts.txt"
./CloudflareST -n 10 -t 1 -url 101.125.123.2 -o "result_hosts.txt" 都是一样的结果,跑到3000+然后卡死

[lyxhwy]

你看清楚我说的内容，照我说的去做，并告诉我结果。 请按照我的指示去反馈内容，否则我无法排查问题。 因为你经历的情况，印象中以前反馈结果中有类似的，大都是其他问题导致的。

已测 ./CloudflareST -n 10 -t 1 -url https://abc.lyxhwy.top -o "result_hosts.txt" ./CloudflareST -n 10 -t 1 -url 101.125.123.2 -o "result_hosts.txt" 都是一样的结果,跑到3000+然后卡死

并不是10+10这样,而是直接跑到3000+,路由卡死,断网,过一分钟恢复

[charSLee013]

你看清楚我说的内容，照我说的去做，并告诉我结果。 请按照我的指示去反馈内容，否则我无法排查问题。 因为你经历的情况，印象中以前反馈结果中有类似的，大都是其他问题导致的。

已测 ./CloudflareST -n 10 -t 1 -url https://abc.lyxhwy.top -o "result_hosts.txt" ./CloudflareST -n 10 -t 1 -url 101.125.123.2 -o "result_hosts.txt" 都是一样的结果,跑到3000+然后卡死

平均延迟小于1ms,是不是电脑/路由器的TUN Mode 没关？ 导致Clash 或者 V2rayN 接受大量TCP连接跟着一起崩溃了？

[lyxhwy]

你看清楚我说的内容，照我说的去做，并告诉我结果。 请按照我的指示去反馈内容，否则我无法排查问题。 因为你经历的情况，印象中以前反馈结果中有类似的，大都是其他问题导致的。

已测 ./CloudflareST -n 10 -t 1 -url https://abc.lyxhwy.top -o "result_hosts.txt" ./CloudflareST -n 10 -t 1 -url 101.125.123.2 -o "result_hosts.txt" 都是一样的结果,跑到3000+然后卡死

平均延迟小于1ms,是不是电脑/路由器的TUN Mode 没关？ 导致Clash 或者 V2rayN 接受大量TCP连接跟着一起崩溃了？

好像是的,不是tun模式也会死,关了openclash就好了

[charSLee013]

你看清楚我说的内容，照我说的去做，并告诉我结果。 请按照我的指示去反馈内容，否则我无法排查问题。 因为你经历的情况，印象中以前反馈结果中有类似的，大都是其他问题导致的。

已测 ./CloudflareST -n 10 -t 1 -url https://abc.lyxhwy.top -o "result_hosts.txt" ./CloudflareST -n 10 -t 1 -url 101.125.123.2 -o "result_hosts.txt" 都是一样的结果,跑到3000+然后卡死

平均延迟小于1ms,是不是电脑/路由器的TUN Mode 没关？ 导致Clash 或者 V2rayN 接受大量TCP连接跟着一起崩溃了？

好像是的,不是tun模式也会死,关了openclash就好了

然后我发现了另一个细节，你的速度测试结果已经出来了，说明整个延迟+测速已经完成了 但是没有结束语

完整测速结果已写入 result.csv 文件，可使用记事本/表格软件查看。

你可以检查下 当前的目录下是否有充足的容量或者当前目录用户是否有权限写入

[lyxhwy]

你看清楚我说的内容，照我说的去做，并告诉我结果。 请按照我的指示去反馈内容，否则我无法排查问题。 因为你经历的情况，印象中以前反馈结果中有类似的，大都是其他问题导致的。

已测 ./CloudflareST -n 10 -t 1 -url https://abc.lyxhwy.top -o "result_hosts.txt" ./CloudflareST -n 10 -t 1 -url 101.125.123.2 -o "result_hosts.txt" 都是一样的结果,跑到3000+然后卡死

平均延迟小于1ms,是不是电脑/路由器的TUN Mode 没关？ 导致Clash 或者 V2rayN 接受大量TCP连接跟着一起崩溃了？

好像是的,不是tun模式也会死,关了openclash就好了

然后我发现了另一个细节，你的速度测试结果已经出来了，说明整个延迟+测速已经完成了 但是没有结束语

完整测速结果已写入 result.csv 文件，可使用记事本/表格软件查看。

你可以检查下 当前的目录下是否有充足的容量或者当前目录用户是否有权限写入

关闭openclash就全部正常了,打开什么都不正常,不管测速地址走不走内核都会卡死

[charSLee013]

关闭openclash就全部正常了,打开什么都不正常,不管测速地址走不走内核都会卡死

打开什么都不正常

这个是因为Clash 的TUN mode是fake ip模式，即每个DNS查询都会返回一个本地的P地址 所以关闭后需要清除应用程序和电脑里的DNS缓存，最简单的方式就是重启设备 然后应该就正常了

不管测速地址走不走内核都会卡死

如果在关闭open clash后还是会卡住 你可以用这条命令查看测速程序是否被OOM了 dmesg -T | egrep -i 'killed process' 如果有看到 CloudflareSpeedTest 可能是测速过程中因为内存不足被干掉了

还有一个可能是ssh 连接掉了

如果你用的是家用路由器的话，CPU性能挺差的，而且没有散热的情况下 进行大量的TCP请求可能会导致Soc发热巨大，进而导致整个系统崩溃 在用户眼中就是ssh 连接无响应了，实际上路由器可能已经挂了或者WiFi模块无响应

win11 测试线程没问题,速度很慢,路由器反而跑的很快,直到卡死

速度很慢的话可以试着调高并发数量 -n 并发数量 比如 -n 1000 如果在调高并发后，电脑网络（右下角的网络标志）显示无网络连接 那么瓶颈可能在电脑的网卡或者路由器上了，可能需要改为用有线连接更好

[lyxhwy]

没有问题了,关闭openclash就可以了 谢谢各位

[lyxhwy]

可以啦

[XIU2]

该问题就是 CloudflareST 走了代理，导致延迟测试速度特别快（时间特别短），因此虽然你设置了 -n 10，但因为单个 IP 的测试时间很短（0.X ms），因此只需 0.X ms 就能延迟测速完成 10 个 IP 了（当然实际测速消耗的时间不会这么少），然后 CloudflareST 就开始继续测速下一批 10 个 IP 了，但是所有 IP 的总测速时间加起来也很少，因此表现为你描述的情况，进度条嗖嗖的~

关于这个问题，在项目介绍中的 #下载运行 - Linux 使用示例 和 #结果示例 都提到了：

# 如果平均延迟非常低（如 0.xx），则说明 CloudflareST 测速时走了代理，请先关闭代理软件后再测速。
# 如果在路由器上运行，请先关闭路由器内的代理（或将其排除），否则测速结果可能会不准确/无法使用。

就是因为老是有人犯这种错误，所以我特地注明了。。。如果你仔细看的话就不会问这个 Issues 了。

---

另外，我前面说的：

建议你找一些不可用的 IP（443 端口超时的），然后去测速这些 IP，观察进度条是不是 10 个 10 个增加的（因为测速都是超时，所以每个 IP 的测速总时间都是一样的），如果是 10 个 10 个增加的，说明 -n 参数正常。

你还是没做，或者说你没理解我说的意思，我让你指定一些不可用的测速 IP（ -f ip.txt 或 -ip x.x.x.x,x...），结果你指定的是 -url 。。。不过既然问题已经找到了，那就算了。