一个优化建议

[livingfree2023]

你好，我以前也写过类似的脚本自用，发现你做的各方面都比较完善，所以以后想主要用你的脚本来定时优选了，Good job点个赞。

这里我有一个小小的建议，我以前的程序逻辑是

先用nslookup hostname 1.1.1.1查我的域名当前的IP地址，然后直接用CloudflareST指定IP跑一次，看看第一次测速速度current_speed是否达到配置中的-sl参数要求（needed_speed），如果能够达到要求的话，直接退出程序即可。

如果速度没有达到要求，再进行优选测速获得new_speed，并且在ddns update之前，比较一下第二次测速的速度是否大于current_speed。

第二次测速速度优于第一次测速时，再去更新IP地址。

优于CloudflareST是随机测试IP，常常会出现原本非常好的IP被脚本替换成了一个很普通的IP，用我上述逻辑稍加改写可以节约很多运行时间，也节约测速所造成的路由侧和CF侧流量压力

望能参考

祝好

[frankiejun]

不错的建议，我会抽空实现一下。如果你已经实现了，也可以提个pr

[dust2k]

优于CloudflareST是随机测试IP，常常会出现原本非常好的IP被脚本替换成了一个很普通的IP，用我上述逻辑稍加改写可以节约很多运行时间，也节约测速所造成的路由侧和CF侧流量压力

就是因为这个原因，我取消了每天定时刷IP的任务，每个选上的IP大概率能存活2，3天，所以我就手工去走测试。。

有个奇怪的地方是，每次选出的IP，前面两个都是连接的延迟都比较高，600~900ms左右，但第三或者第四个都是几十ms，然后速度飞快，但这种IP通常挂的也快。。呵呵。。

[livingfree2023]

优于CloudflareST是随机测试IP，常常会出现原本非常好的IP被脚本替换成了一个很普通的IP，用我上述逻辑稍加改写可以节约很多运行时间，也节约测速所造成的路由侧和CF侧流量压力

就是因为这个原因，我取消了每天定时刷IP的任务，每个选上的IP大概率能存活2，3天，所以我就手工去走测试。。

有个奇怪的地方是，每次选出的IP，前面两个都是连接的延迟都比较高，600~900ms左右，但第三或者第四个都是几十ms，然后速度飞快，但这种IP通常挂的也快。。呵呵。。

嗯，完全看脸，有的运气好的能用1周，运气不好的一个小时都不到。不过我对CF研究也不多，不知道原库的ip.txt和 @frankiejun 从baipiao下载到的库之间有什么区别，希望懂得能解释一下。

[frankiejun]

原来ip.txt给出的cf服务器的ip段，CloudflareST从中随机抽取一些并做测试，把能用的挑出来。但这些多半是cf的代理，我们要的是cf的反代，baipiao 下载的那个库理应全是反代。它们差别是cf代理不能访问自家（走CDN）的网站，而反代没有这个限制。 但最近发现baipiao 选出来的反代ip，很多感觉不像反代，更像cf代理，chatgpt也不能访问。baipiao 库的作者似乎没有在维护这个库了，也正常，现在这些ip库都作为一种资源去卖了，还哪有什么白嫖。所以我现在很少用这些cf节点，只做防失联。

对了，今天搞了个tg群，有兴趣可以加来交流。https://t.me/fanyousuiqun

[sliploach]

老帖新回复，能不能指定自有文件进行测速？比如jp.txt us.txt，自建文件放服务端，指定自建文件里的ip去测速。至少fofa挑出来的ip还能用用，不至于别人没有维护就傻眼了。
另外，可否多个ip指向同一个域名，比如选出来5个ip，第1个才1天时间就失效了，反而后面的很坚挺。
谢谢。

[sliploach]

还有个发现，这个项目https://github.com/ddong1031/openwrt_cf/blob/main/，，，似乎是自动优选后，直接在opw里面修改节点的信息，不用去折腾cf网站，感觉有点意思但是没有维护了