这是一个创建于 2451 天前的主题，其中的信息可能已经有所发展或是发生改变。
昨天起网络就开始不好，今天早上起来一查 DNS ； 测试了上海（下均为上海） 电信 200M、电信 500M、移动 100M ； 电信方面 8.8.8.8 全部 timeout 但 8.8.4.4 可用； 移动方面均可用。
Microsoft Windows [版本 10.0.17763.615] (c) 2018 Microsoft Corporation。保留所有权利。 C:\Users\admin>ping 8.8.8.8 [电信] 正在 Ping 8.8.8.8 具有 32 字节的数据: 请求超时。 请求超时。 请求超时。 请求超时。 8.8.8.8 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 0，丢失 = 4 (100% 丢失)， C:\Users\admin>ping 8.8.4.4 [电信] 正在 Ping 8.8.4.4 具有 32 字节的数据: 来自 8.8.4.4 的回复: 字节=32 时间=36ms TTL=53 来自 8.8.4.4 的回复: 字节=32 时间=33ms TTL=53 来自 8.8.4.4 的回复: 字节=32 时间=33ms TTL=53 来自 8.8.4.4 的回复: 字节=32 时间=35ms TTL=53 8.8.4.4 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)， 往返行程的估计时间(以毫秒为单位): 最短 = 33ms，最长 = 36ms，平均 = 34ms C:\Users\admin>ping 8.8.8.8 [移动] 正在 Ping 8.8.8.8 具有 32 字节的数据: 来自 8.8.8.8 的回复: 字节=32 时间=196ms TTL=51 来自 8.8.8.8 的回复: 字节=32 时间=193ms TTL=51 来自 8.8.8.8 的回复: 字节=32 时间=194ms TTL=51 来自 8.8.8.8 的回复: 字节=32 时间=186ms TTL=51 8.8.8.8 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)， 往返行程的估计时间(以毫秒为单位): 最短 = 186ms，最长 = 196ms，平均 = 192ms C:\Users\admin>ping 8.8.4.4 [移动] 正在 Ping 8.8.4.4 具有 32 字节的数据: 来自 8.8.4.4 的回复: 字节=32 时间=181ms TTL=51 来自 8.8.4.4 的回复: 字节=32 时间=184ms TTL=51 来自 8.8.4.4 的回复: 字节=32 时间=176ms TTL=51 来自 8.8.4.4 的回复: 字节=32 时间=186ms TTL=51 8.8.4.4 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)， 往返行程的估计时间(以毫秒为单位): 最短 = 176ms，最长 = 186ms，平均 = 181ms  | 1 qwerthhusn 2019 年 7 月 26 日 8888 确实不行了，安徽电信； 8844 还好 之前有次 114114114114 跪了，换成了 8888，现在 8888 也凉了 |
 | 2 ddzy 2019 年 7 月 26 日 打断一下, 我爱 gcc |
 | 3 blakebill OP @qwerthhusn 暂时用回电信官方 DNS 了，等后续，然后准备自建还是其他的。 |
 | 4 anguiao 2019 年 7 月 26 日 via Android 国内没必要用国外 DNS |
 | 5 ZhouMidan 2019 年 7 月 26 日 上海电信 C:\Users\xxx>ping 8.8.8.8 正在 Ping 8.8.8.8 具有 32 字节的数据: 来自 8.8.8.8 的回复: 字节=32 时间=31ms TTL=53 来自 8.8.8.8 的回复: 字节=32 时间=31ms TTL=53 来自 8.88.8 的回复: 字节=32 时间=32ms TTL=53 来自 8.8.8.8 的回复: 字节=32 时间=32ms TTL=53 8.8.8.8 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)， 往返行程的估计时间(以毫秒为单位): 最短 = 31ms，最长 = 32ms，平均 = 31ms C:\Users\xxx>ping 8.8.4.4 正在 Ping 8.8.4.4 具有 32 字节的数据: 来自 8.8.4.4 的回复: 字节=32 时间=33ms TTL=53 来自 8.8.4.4 的回复: 字节=32 时间=33ms TTL=53 请求超时。 来自 8.8.4.4 的回复: 字节=32 时间=33ms TTL=53 8.8.4.4 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 3，丢失 = 1 (25% 丢失)， 往返行程的估计时间(以毫秒为单位): 最短 = 33ms，最长 = 33ms，平均 = 33ms |
 | 6 meteor 2019 年 7 月 26 日 mtr 看下路由 |
 | 10 mrw77 2019 年 7 月 26 日 为什么在国内用谷歌的 dns，我不明白。 过 Q 那一刻污染，谷歌国内就北京有服务器，但肯定不会解析的 |
 | 11 leonard916 2019 年 7 月 26 日  1 IP 一直都被答 被屏蔽 早就有用值了 |
 | 12 Apllex 2019 年 7 月 26 日 via Android 我这里 Google DNS 一直都是抢答的… |
 | 13 HalloCQ 2019 年 7 月 26 日 |
 | 15 titanium98118 2019 年 7 月 26 日 国内没必要用 8.8.8.8 |
 | 16 stephenyin 2019 年 7 月 26 日 @bclerdx #14 mtr |
| 17 blakebill OP @mrw77 路由器设置大概三年没动过了，之前使用倒还不错，近半年的话开始丢包，昨天上海电信应该是明确屏蔽了，现在也用回电信 DNS 了，反正现在劫持现象比较少 |
| 18 blakebill OP @titanium98118 确实是这样了，体验很差。 |
 | 19 nevermakeyoucryt 2019 年 7 月 26 日 国内用谷歌确实不是一个明智的选择，不嫌解析慢拖累网速么 |
| 20 blakebill OP @HalloCQ 目前国内就电信，国外转 CloudflareDNS 了。 从以下测试中 CFDNS 明显优于 GDNS 测试网络环境：HKCN2 ``` root@HIK:~# dig @1.1.1.1 www.google.com ; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> @1.1.1.1 www.google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23044 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1452 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 134 IN A 172.217.163.228 ;; Query time: 3 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Fri Jul 26 14:38:13 CST 2019 ;; MSG SIZE rcvd: 59 root@HIK:~# dig @8.8.8.8 www.google.com ; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> @8.8.8.8 www.google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11797 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 27 IN A 216.58.199.4 ;; Query time: 13 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Jul 26 14:38:28 CST 2019 ;; MSG SIZE rcvd: 59 ``` |
 | 21 dot2017 2019 年 7 月 26 日 这不是很久之前就这样了么，一阵能用一阵不行。反正能用的时候也是被污染的 |
 | 22 tuding 2019 年 7 月 26 日 墙裂不建议用 114.114.114.114 |
 | 23 iPhoneXI 2019 年 7 月 26 日 via Android Android 自带 DNS over TLS 用 dns.google 就行 |
 | 24 xuyl 2019 年 7 月 26 日 国内有很多可选的， 百度公共 dns 180.76.76.76 阿里公共 dns 223.5.5.5 223.6.6.6 腾讯公共 dns 119.29.29.29 |
 | 26 masana 2019 年 7 月 26 日 1 你想象的 8888 其实早就被透明代理了 |
 | 27 chcx 2019 年 7 月 26 日 mtr 看丢包起飞~ |
 | 28 billytom 2019 年 7 月 26 日 今天的 8888 是有点问题，8844 还是好的，1111 也一切正常 |
 | 30 est 2019 年 7 月 26 日 墙内的 8888 早就不是 g 家在返回了吧。。 |
 | 31 passerbytiny 2019 年 7 月 26 日 @Counter #25 114 做大了（可以开始宰羊了），就这一条就够了。 |
 | 32 missdeer 2019 年 7 月 26 日 我 8888 和 8844 都是自己截持到本地用，有些程序好像写死了用 8888/8844，没办法 |
 | 33 Buges 2019 年 7 月 26 日 via Android 1 DNS 问题强烈推荐用 DNScrypt-proxy 上 doh，直接用 1111 就好。手机电脑路由器全平台。 |
| 34 tuding 2019 年 7 月 26 日 via Android 1 |
 | 35 hailaz 2019 年 7 月 26 日 一直用 8844 挺稳的，8888 以前特意测试过不稳。坐标广州电信 |
| 36 hailaz 2019 年 7 月 26 日 至于 114，呵呵 |
 | 37 wwbfred 2019 年 7 月 26 日 四个 8 经常会挂,基本上过段时间自己就好了.其实直接用 8844 挺稳的. 国内的话别只用这个当主 DNS.解析国外域名挺好的,但有 cdn 的国内站会被带着全世界到处跑. |
 | 38 Windelight 2019 年 7 月 26 日 via Android Trace。河北通，石家移、北京移出去美利加州 level3 （谷歌加州）。河北通，本地的城直接到州通再到香港通到谷歌香港。 |
 | 39 fancyhan 2019 年 7 月 26 日 这都什么年代的新闻了，这个很早就不推荐了 |
 | 40 bclerdx 2019 年 7 月 26 日 @stephenyin 上个工具图，谢谢！ |
 | 41 mattx 2019 年 7 月 26 日 via iPhone 村网通么？国内还用谷歌 dns ？又不能防污染，用这个干嘛？ |
 | 43 runtu2019 2019 年 7 月 26 日 一般是本地自建 dns 缓存，用香港 dns |
 | 45 SvenRogue 2019 年 7 月 26 日 114 最近也不太行 求问打游戏（战地 5 ）用哪家 dns 比较好 |
 | 46 mytsing520 PRO 2019.07.27 ，电信网络已经恢复 8.8.8.8 的连接。 |
 | 50 duoduo1x 2019 年 7 月 28 日 PING 8.8.8.8 (8.8.8.8): 56 data bytes Request timeout for icmp_seq 0 64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=23.179 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=37.379 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=52 time=25.040 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=52 time=23.534 ms Request timeout for icmp_seq 5 64 bytes from 8.8.8.8: icmp_seq=6 ttl=52 time=23.565 ms 64 bytes from 8.8.8.8: icmp_seq=7 ttl=52 time=26.157 ms 64 bytes from 8.8.8.8: icmp_seq=8 ttl=52 time=30.675 ms 64 bytes from 8.8.8.8: icmp_seq=9 ttl=52 time=36.038 ms 64 bytes from 8.8.8.8: icmp_seq=10 ttl=52 time=26.160 ms 64 bytes from 8.8.8.8: icmp_seq=11 ttl=52 time=32.977 ms 64 bytes from 8.8.8.8: icmp_seq=12 ttl=52 time=37.107 ms 64 bytes from 8.8.8.8: icmp_seq=13 ttl=52 time=25.819 ms 64 bytes from 8.8.8.8: icmp_seq=14 ttl=52 time=42.742 ms 64 bytes from 8.8.8.8: icmp_seq=15 ttl=52 time=28.138 ms 64 bytes from 8.8.8.8: icmp_seq=16 ttl=52 time=23.016 ms 64 bytes from 8.8.8.8: icmp_seq=17 ttl=52 time=44.251 ms 64 bytes from 8.8.8.8: icmp_seq=18 ttl=52 time=24.949 ms 64 bytes from 8.8.8.8: icmp_seq=19 ttl=52 time=26.882 ms |
 | 51 6zac 2019 年 8 月 11 日 via Android 不行就不行 |
Select Language