peter2022
peter2022
./CloudflareST -tll 90 -p 30 输出结果没有显示30条测试结果？
``` bash #!/bin/bash # sleep 8s bash /etc/init.d/haproxy stop bash /etc/init.d/passwall stop # 进入 CloudflareST 目录 # cd /root/CloudflareST # 运行 CloudflareST 测速（脚本示例中的 CloudflareST 位于 /root/CloudflareST 目录下） /root/CloudflareST/CloudflareST -f ip.txt...
``` #!/bin/bash # sleep 8s bash /etc/init.d/haproxy stop bash /etc/init.d/passwall stop # 进入 CloudflareST 目录 cd /root/CloudflareST # 运行 CloudflareST 测速（脚本示例中的 CloudflareST 位于 /root/CloudflareST 目录下） ./CloudflareST -f ip.txt -o result.csv...
/etc/init.d/haproxy stop /etc/init.d/passwall stop 请问这两个命令，停止pw 和ha后，跑CloudflareST,延迟测速跑得非常快，下载测速测出的速度也就在10-20M之间，pw基本设置-模式-tcp udp的模式选择中国列表以外。 当选择pw的tcp udp的模式(或者路由器自身 TCP UDP代理模式 gfw) 选择gfw列表时，延迟和下载都正常。 请问passwall stop 无效吗？ 问题出在哪里？
跟楼主的阻断时间重合，将来不能嵌套cf了吗？
> 据说是GFW专门针对优选ip的手段，使用优选ip访问非cloudflare域名就会触发，猜测是常用的优选ip段可能有一个sni白名单。 > > 如果是要中转梯子，解决方法其实也简单，不套tls不发sni，用80/8080等http端口连接cloudflare就行了。 这个原理是什么？
> > > 据说是GFW专门针对优选ip的手段，使用优选ip访问非cloudflare域名就会触发，猜测是常用的优选ip段可能有一个sni白名单。 > > > 如果是要中转梯子，解决方法其实也简单，不套tls不发sni，用80/8080等http端口连接cloudflare就行了。 > > > > 这个原理是什么？ > > sni阻断原理是根据tls握手时候的明文sni(域名)进行tcp阻断。绕过去方法有两个： > > 1. 不用tls协议，走cf的http端口，没有tls，就没有sni，sni阻断就无从谈起。 > 2. 使用quic协议，目前的信息来看，墙的sni阻断只对tcp流量生效，走udp的quic（h3）协议可以通畅无阻。 可以理解为把vless or vmess中的tls改为quic协议对吗？
> > > 2. 使用quic协议，目前的信息来看，墙的sni阻断只对tcp流量生效，走udp的quic（h3）协议可以通畅无阻。 > > > > 可以理解为把vless or vmess改为quic协议对吗？ > > 梯子中转不能用quic过cf，cf不支持quic回源。cf中转梯子可以用vmess ws无tls协议。 > > 梯子直连情况下遇到sni阻断，可以改成quic协议绕过去。 > > > > Vless+ws过cf也可以把？
> > > > 据说是GFW专门针对优选ip的手段，使用优选ip访问非cloudflare域名就会触发，猜测是常用的优选ip段可能有一个sni白名单。 > > > > 如果是要中转梯子，解决方法其实也简单，不套tls不发sni，用80/8080等http端口连接cloudflare就行了。 > > > > > > > > > 这个原理是什么？ > > > > sni阻断原理是根据tls握手时候的明文sni(域名)进行tcp阻断。绕过去方法有两个： > > > > 1....