@mytsing520 也不一定，天津联通通过 IPv6 请求会被调度到首尔（我用的谷歌 DNS 作为上游），连接质量稀烂……

@Maxxxxyu 所以广电呢？

@vgjjk 今天好像又进去了……

@jieyitang 9929……一般人不都是 4837 ，帖子说的也是 4837

更新：20.205.243.166 放出来了，140.82.116.3 仍未放出

#8 补充：140.82.116.3 也不通

天津联通，8 行，把解析的 IP （ 20.205.243.166 ）放 itdog 上测试只有个别地区的移动还通，近年来第二次了（上次： https://v2ex.com/t/1009169 ）

@Actrace 确实，这几天连 Akamai 都炸（解析出的 IP 在日本，但是绕美，下载文件不到 200KB/s ，还是 IDM ，Akamai 以前基本上从未炸过），Cloudfront 也炸（情况和 Akamai 差不多，解析出的 IP 在韩国），只能找个没 GeoDNS 功能的 DNS 解析器（比如 cf 的 1.1.1.1 ）把域名解析到美西（我这边 1.1.1.1 的 colo 是 LAX ）再下载文件速度立马就上去了

@GDSR 我这纯 v4 一个也打不开了

国内访问国外 v4 炸，v6 目前还正常

#15 更正：这会不知为何 cf 的免费 IP 段走 v6 的节点一直反复横跳，主要是 LAX ，也刷出过 LHR 、DFW 以及上面提到的 PHX

@c398425861 错误的，免费 IP 段 v4 在我这都是 LAX ，v6 是 PHX （之前也是 LAX ），但是同为 LAX/SJC/PHX 等走美西的 IP 如果不是免费 IP 段（比如 V2EX 的 IP 段、cloudflare.com ）则即便是晚上延迟也相对正常

我这边的测试结果表明并不是 DNS 污染而是单纯的 TCP RST……不知道像 https://github.com/URenko/Accesser 这种能不能规避

@L4Linux ban cf? 你说的应该是每天晚上 cf 免费 P 段延迟巨高吧，联通这边 ICMP 能到 1500-2000 且伴随丢包，别的运营商放 itdog 测试丢包的有但延迟这么高的仅联通一家（以上言论都是基于 4837 网络的测试结果，9929 我不清楚）

之前试过测试版的 MV3 插件也有相同情况，从 Chrome 应用商店已经没有插件无法再使用的提示来看最新版 6.42.42 插件已经更新成 MV3 ，不知为什么没修

@zcf0508 20.205.243.166 被啬了，换个 IP 吧

@lns103 这种方法确实可以，并且理论上*.xn--ngstr-lra8j.com 仍然可以走直连（考虑到国外 cdn 事实上与 YouTube 的视频 cdn 物理上同服尽管域名并没有被封仍然可能需要 IPv6 加持；另外经测试这种方法大概率会重定向回位于中国境内的*.googlevideo.com cdn ，所以需要无污染的 DNS ）

厂商应用商店提供的 APP 绝大多数都是 64 位（至少我的小米是这样），三方应用商店有的自家 APP 都是 32 位（比如百度手机助手）