cf 的 doh 在国内使用是有技巧的，不要直接用 1111 和 1001 ，而是：
1 、找到 cloudflare-dns.com 的证书对应的其他 ip ，比如[2606:4700:4700::6400]和 162.159.xx.1
2 、或者使用 zero tust 里面的自定义 gateway dns ，这个还支持 ecs
3 、尽量用 doh3

我测下来结果是
linux 下，firefox 和 chrome 不开 doh 依然有 ech 。
然而 windows 下，firefox 可以不开 doh ，chrome 不开 doh 就没有 ech ，挺奇怪的

@bclerdx https://www.speedtest.net/apps/cli

另外 21569 50686 24333 65163 这几个测速节点都是 ntt 线路，9929 过去延迟 40 以内，正常情况下应该是跑满千兆的，有的时候节点会被墙

我刚测了下没有限速，speedtest -s 65101
9929 直连日本七牛云的节点，走的是 ntt ，测速能过千
https://www.speedtest.net/result/c/07959718-0cec-4e24-bb10-665be7aeb7bb

@m1nm13 至于 reality 目前好像没受影响，因为都是偷的大公司的 sni ，之前一直很稳的 naiveproxy 倒是断断续续，感觉墙又在上新功能

@m1nm13 ip 没封，我这是上海联通，不是电信，但是被 gfw 影响应该是一致的，貌似是针对特定域名有 sni 阻断（可能还有特定 ip 段的条件）。
比如说 aws.xxxx.com 用 doh 查询直接 tcp reset ，换用 aws-v4.xxx.com 就正常，然后甲骨文东京和新加坡情况很严重，逼得我一个个改 ip 改域名，其他地方好像就没啥事。奇妙的是当 doh reset 后，我换用 doh3 可能就正常。然后有些情况是 doh 正常，我用 doh3 查询以后，好像触碰了 gfw 的 g 点一样，再回去用 doh 又被重置。doq 也尝试过，所有机子全通，我还美滋滋地准备用 doq 续命，谁想过一晚上全部失联。
目前解决方案是全部退回用传统 doh ，域名 ip 全换，暂时没出现阻断情况了

自建 dns 这最近开始出现严重 sni 阻断，换成 ip 证书就一切正常了

@dizhang 都很稳，甲骨文 sg 的回程绕日本 ntt ，延迟稍高： https://i.imgur.com/Wl6KjU1.png ，甲骨文 sg 新区回程直连 singtel： https://i.imgur.com/q1NGlI9.png
我没有 hk 小鸡，从 cloudflare hk 节点来看到 hk 也稳，但 9929 最优线路还是去日本 ntt

@shakespark 上海这里速度也很美，9929 连甲骨文东京单线程 600m ，三线程跑满 1.2g ，作为主力长期使用很稳

@huihuilang 碰到这种路由器重拨即刻解决，这应该是他们设计的惩罚策略，不能长时间占用大带宽

NTT 到 9929 一直还蛮稳的
<blockquote class="imgur-embed-pub" lang="en" data-id="a/Qw3VmuN" data-context="false" ><a href="//imgur.com/a/Qw3VmuN"></a></blockquote><script async src="//s.imgur.com/min/embed.js" charset="utf-8"></script>

9929 互联网直通车路由挂了啊，请楼主解决

sing-box ios 客户端支持

@vfx666 cn2 这么低延迟得上香港，那月租不菲，而 9929+免费的甲骨文就直接起飞

@shakespark 上海联通极其便宜

9929 到 CF 的体验也是极好的，附近的节点有香港（延迟 70 或者 40 ）、东京（延迟 40 或者 200 ）、大阪（路由经过东京，延迟 50 ）。香港和东京的路由反复横跳，也不知道是怎么回事……
搭配白嫖 CF warp 和 workers ，低延迟无感爬梯