CloudflareSpeedTest
CloudflareSpeedTest copied to clipboard
XIU2
如遇到 `延迟异常低 (几十 ms)` 且不可用的测速结果，请加上 `-tll` 参数过滤 `假蔷 IP` ！
因为很多人被假蔷勒索，然后它们套 Cloudflare 来抵御假蔷，结果就是 Cloudflare 大量 IP 被假蔷。 虽然被假蔷的 IP 很快就会解封，但是因为假蔷勒索泛滥，导致一直有新的 Cloudflare IP 被假蔷。
最近发现 Cloudflare 被假蔷的 IP 似乎越来越多了，因此在大家的建议下加了个 [平均延迟下限] 参数~
# 区分假蔷
-
假蔷 IP 的表现特征：
Ping 延迟正常，TCPing 延迟异常的低，下载速度为
0.00（或约等于 0，即不可用）。即 TCPing 延迟远低于 Ping 延迟。
# 使用方法
# 电信/联通用户
因为除了移动(直连香港) 外，电信/联通几乎不存在 TCPing 延迟低于 100ms 的 IP，因此低于 100ms 的 IP 可以确定为被假蔷了。
具体 TCPing 延迟多少往往取决于你到国际网络出口处（北京、上海、广州）多远，因为蔷是在出口处进行 TCP 劫持的。
# 平均延迟下限：100 ms
./CloudflareST -tll 100
CloudflareST.exe -tll 100
# 平均延迟上限：300 ms，平均延迟下限：100 ms
./CloudflareST -tl 300 -tll 100
CloudflareST.exe -tl 300 -tll 100
# 平均延迟下限和其他的上下限参数一样，都可以单独使用、互相搭配使用！
# 移动用户
因为移动直连香港的原因，测出来的香港节点的 IP 延迟也很低，和 TCPing 延迟很低的假蔷 IP 混在一起难以区分，不能简单通过延迟下限来过滤了，因此需要加上 -sl 参数(下载速度下限) 来过滤掉同样延迟低但实际不可用的假蔷 IP。
# 下载速度下限：1 MB/s
./CloudflareST -sl 1
CloudflareST.exe -sl 1
# 平均延迟上限：300 ms，下载速度下限：1 MB/s
./CloudflareST -tl 300 -sl 1
CloudflareST.exe -tl 300 -sl 1
# 移动用户注意不要使用 -tll 参数（延迟下限），除非你不想要香港节点~
# 被假蔷的 IP 下载速度基本为 0.00（或 0.0X 忽略不计），所以可以用下载速度来过滤掉不可用的假蔷 IP
@China-Huanghe 我这边测试了下，没有提示更新。
用 -v 参数主动检测更新也正常显示为： 当前为最新版本 [v1.5.0]！
你给个提示更新的截图看看。
这是我刚刚的没有加任何参数的测试结果，同样没有提示更新：
D:\Program Files\CloudflareST>CloudflareST.exe
# XIU2/CloudflareSpeedTest v1.5.0
开始延迟测速（模式：TCP IPv4，端口：443，平均延迟上限：9999.00 ms，平均延迟下限：0.00 ms）：
17236 / 17236 [-----------------------------------------------------------------------------------------------] 100.00%
开始下载测速（下载速度下限：0.00 MB/s，下载测速数量：20，下载测速队列：20）：
20 / 20 [-----------------------------------------------------------------------------------------------------] 100.00%
IP 地址 已发送 已接收 丢包率 平均延迟 下载速度 (MB/s)
104.24.31.20 4 4 0.00 198.89 7.90
104.25.231.126 4 4 0.00 192.65 6.90
104.25.181.3 4 4 0.00 186.89 6.59
104.24.72.119 4 4 0.00 194.17 6.30
104.24.80.41 4 4 0.00 191.43 3.51
104.25.198.208 4 4 0.00 198.62 2.95
104.25.190.110 4 4 0.00 198.11 1.19
104.24.53.74 4 4 0.00 198.09 0.95
104.21.208.139 4 4 0.00 33.78 0.00
172.65.167.59 4 4 0.00 189.99 0.00
104.18.219.78 4 4 0.00 32.68 0.00
172.65.159.127 4 4 0.00 192.82 0.00
104.16.21.103 4 4 0.00 45.02 0.00
172.65.104.176 4 4 0.00 195.27 0.00
172.65.111.116 4 4 0.00 197.92 0.00
104.16.205.93 4 4 0.00 39.48 0.00
104.16.3.106 4 4 0.00 38.35 0.00
104.21.31.36 4 4 0.00 34.77 0.00
172.65.166.200 4 4 0.00 198.76 0.00
104.22.27.83 4 4 0.00 24.56 0.00
完整测速结果已写入 result.csv 文件，请使用记事本/表格软件查看。
按下 回车键 或 Ctrl+C 退出。
没有加上 [平均延迟下限] -tll 参数，一大片假蔷 IP。。。
@China-Huanghe 这个好像是 Cloudflare 的页面。。。 你浏览器能打开 https://api.xiuer.pw/ver/cloudflarespeedtest.txt 这个最新版本号的地址吗？
@China-Huanghe 我这个最新版本号地址托管在 Cloudflare 中，我刚刚把版本号的 URL 加到防火墙例外中了，应该不会再出现这种问题了。
这是 Cloudflare 的质询，即 Cloudflare 怀疑是机器人，需要真人验证。 你重新拨号换个 IP 试试。
另外不需要每次都去测速一遍，可以使用 -v 参数来主动检查更新。
CloudflareST.exe -v
因为很多人被假蔷勒索，然后它们套 Cloudflare 来抵御假蔷，结果就是 Cloudflare 大量 IP 被假蔷。 虽然被假蔷的 IP 很快就会解封，但是因为假蔷勒索泛滥，导致一直有新的 Cloudflare IP 被假蔷。
最近发现 Cloudflare 被假蔷的 IP 似乎越来越多了，因此在大家的建议下加了个
[平均延迟下限]参数~# 区分假蔷
- 假蔷 IP 的表现特征： Ping 延迟正常，TCPing 延迟异常的低，下载速度为
0.00（或约等于 0，即不可用）。即 TCPing 延迟远低于 Ping 延迟。# 使用方法
# 电信/联通用户
因为除了移动(直连香港) 外，电信/联通几乎不存在 TCPing 延迟低于 100ms 的 IP，因此低于 100ms 的 IP 可以确定为被假蔷了。
具体 TCPing 延迟多少往往取决于你到国际网络出口处（北京、上海、广州）多远，因为蔷是在出口处进行 TCP 劫持的。
# 平均延迟下限：100 ms ./CloudflareST -tll 100 CloudflareST.exe -tll 100 # 平均延迟上限：300 ms，平均延迟下限：100 ms ./CloudflareST -tl 300 -tll 100 CloudflareST.exe -tl 300 -tll 100 # 平均延迟下限和其他的上下限参数一样，都可以单独使用、互相搭配使用！# 移动用户
因为移动直连香港的原因，测出来的香港节点的 IP 延迟也很低，和 TCPing 延迟很低的假蔷 IP 混在一起难以区分，不能简单通过延迟下限来过滤了，因此需要加上
-sl参数(下载速度下限) 来过滤掉同样延迟低但实际不可用的假蔷 IP。# 下载速度下限：1 MB/s ./CloudflareST -sl 1 CloudflareST.exe -sl 1 # 平均延迟上限：300 ms，下载速度下限：1 MB/s ./CloudflareST -tl 300 -sl 1 CloudflareST.exe -tl 300 -sl 1 # 移动用户注意不要使用 -tll 参数（延迟下限），除非你不想要香港节点~ # 被假蔷的 IP 下载速度基本为 0.00（或 0.0X 忽略不计），所以可以用下载速度来过滤掉不可用的假蔷 IP
提供个参考数据: cf香港节点正常没有Re-routed的时候, 移动实测都是四五十ms, 坐标粤西, 测速时间一般是凌晨, 移动300M家宽.
