这是一个创建于 2851 天前的主题，其中的信息可能已经有所发展或是发生改变。
我估计大部分地区都用不了。都当成内网分配了 23333
93 条回复 2018-04-26 10:30:53 +08:00
 | 1 00oo00 2018 年 3 月 30 日 via Android 1.1.1.1 怎么就内网了。。实测 160ping |
 | 2 titanium98118 2018 年 3 月 30 日  1 从 ipip.net 上的 ping 测试，的确有不少机器访问不了的 |
 | 3 moult 2018 年 3 月 30 日 7 居然还给 IP 地址签出了个可信的 SSL 证书  |
 | 4 f2f2f 2018 年 3 月 30 日 1 6666 业界大佬都开始拼 v4 地址了 |
 | 5 chotow 2018 年 3 月 30 日 via Android 1 怎么觉得比谷歌的 DNS 还牛… |
 | 6 mhycy 2018 年 3 月 30 日 1 用公网 ip 当成容易记忆的内网地址进行网络配置的管理员都是不负责任的 |
 | 7 luojianxhlxt 2018 年 3 月 30 日 这个 ip 我是服气的 |
 | 8 rosu 2018 年 3 月 30 日 via Android 这个 IP 真的好看啊～ |
 | 9 safeoy 2018 年 3 月 30 日 有钱真好 |
 | 10 xiaodongus 2018 年 3 月 30 日 这个 IP 还真是厉害，过目不忘。。。 |
 | 11 yexm0 2018 年 3 月 30 日 via iPhone 3 有钱真好，可惜这个 ip 被那些小运营商当内网 ip 用了。。。 |
 | 12 tyhunter 2018 年 3 月 30 日 ping 了下有 300ms 不过真牛逼 |
| 13 yexm0 2018 年 3 月 30 日 via iPhone 2  1.0.0.0/24 也让 cf 拿去用了 |
 | 14 xctcc 2018 年 3 月 30 日 ping 了一下，时间<1ms。。。 |
 | 15 xctcc 2018 年 3 月 30 日 |
 | 16 zlkent PRO 上海电信，不通 |
 | 17 miaomiao888 2018 年 3 月 30 日 2 [资讯] CloudFlare 跟 APNIC 合作推出的 DNS 服务。 IPv4 DNS 服务器：主要 1.1.1.1 备用 1.0.0.1 IPv6 DNS 服务器：主要 2001:2001:: 备用 2001:2001:2001:: 备用基本都通 |
 | 18 zhuanzh 2018 年 3 月 30 日 via Android 1.0.0.1 好像也是？ |
 | 19 onion83 2018 年 3 月 30 日 via iPhone 9.9.9.9 |
 | 20 gcod 2018 年 3 月 30 日  |
 | 21 neighbads 2018 年 3 月 30 日 @moult #3 请看使用者备用名称。。。 DNS Name=*.dns.cloudflare.com DNS Name=dns.cloudflare.com IP Address=1.1.1.1 IP Address=1.0.0.1 |
 | 22 love4taylor PRO 国内用户不谈 反正都是基本上没法用的样子... 对于海外用户来说相较于 Google Public DNS 有什么优势么 |
 | 23 Cavolo 2018 年 3 月 30 日 via iPhone @Love4Taylor 国外用户的最优解也不是谷歌 |
| 24 love4taylor PRO @Cavolo #23 我知道啊 所以我说 "都是基本上没法用" |
 | 25 brMu 2018 年 3 月 30 日 via Android 这个 ip 不能再牛逼 |
 | 26 princeofwales 2018 年 3 月 30 日 移动的宽带访问不了 到了市局节点路由就傻了 |
 | 27 mangokc 2018 年 3 月 30 日 OMG 跟本地 ISP DNS 相同 PING 用一段看看 Ping 1.1.1.1 (使用 32 位元的料): 回覆自 1.1.1.1: 位元=32 =3ms TTL=59 回覆自 1.1.1.1: 位元=32 =2ms TTL=59 回覆自 1.1.1.1: 位元=32 =3ms TTL=59 回覆自 1.1.1.1: 位元=32 =3ms TTL=59 1.1.1.1 的 Ping 料: 封包: 已送 = 4，已收到 = 4, 已失 = 0 (0% 失)， 大的回 (毫秒): 最小值 = 2ms，最大值 = 3ms，平均 = 2ms Ping 8.8.8.8 (使用 32 位元的料): 回覆自 8.8.8.8: 位元=32 =14ms TTL=44 回覆自 8.8.8.8: 位元=32 =14ms TTL=44 回覆自 8.8.8.8: 位元=32 =15ms TTL=44 回覆自 8.8.8.8: 位元=32 =14ms TTL=44 8.8.8.8 的 Ping 料: 封包: 已送 = 4，已收到 = 4, 已失 = 0 (0% 失)， 大的回 (毫秒): 最小值 = 14ms，最大值 = 15ms，平均 = 14ms Ping 9.9.9.9 (使用 32 位元的料): 回覆自 9.9.9.9: 位元=32 =36ms TTL=57 回覆自 9.9.9.9: 位元=32 =36ms TTL=57 回覆自 9.9.9.9: 位元=32 =36ms TTL=57 回覆自 9.9.9.9: 位元=32 =35ms TTL=57 9.9.9.9 的 Ping 料: 封包: 已送 = 4，已收到 = 4, 已失 = 0 (0% 失)， 大的回 (毫秒): 最小值 = 35ms，最大值 = 36ms，平均 = 35ms |
 | 28 wzw 2018 年 3 月 30 日 正在 Ping 1.1.1.1 具有 32 字节的数据: 来自 1.1.1.1 的回复: 字节=32 时间=15ms TTL=51 来自 1.1.1.1 的回复: 字节=32 时间=15ms TTL=51 来自 1.1.1.1 的回复: 字节=32 时间=16ms TTL=51 来自 1.1.1.1 的回复: 字节=32 时间=15ms TTL=51 为什么这么快 |
| 29 yexm0 2018 年 3 月 30 日 @Love4Taylor 移动去 cf 有 HKIX 加成,延迟很好的.反倒是那个 google 的要绕路美国,延迟很难看. |
 | 30 Showfom PRO 2 @Love4Taylor Google 的 IP 数据库，对比国内也就纯真的水平吧 用 8888 在国外总是瞎解析 希望 CF 的 IP 数据库能更准一点 |
 | 31 MacTavish123 2018 年 3 月 30 日 河北联通 正在 Ping 1.1.1.1 具有 32 字节的数据: 来自 1.1.1.1 的回复: 字节=32 时间=194ms TTL=53 来自 1.1.1.1 的回复: 字节=32 时间=194ms TTL=53 来自 1.1.1.1 的回复: 字节=32 时间=194ms TTL=53 来自 1.1.1.1 的回复: 字节=32 时间=193ms TTL=53 |
 | 32 miyuki 2018 年 3 月 30 日 我这联通城域第二跳是 2.1.1.1 … |
 | 33 lfk0000 2018 年 3 月 30 日 我去，3ms，但是 trace 出来又不是内网地址。。。 服气！ |
 | 34 elvisyao 2018 年 3 月 30 日 3 说实话，国内用这些国外 DNS 解析的不知道是怎么样一种心态，1 是容易被污染，2 是就算不污染，来回程 200-300ms+延迟，3 对国内三大运营商支持不好 对我来说，国内 DNS 无非就三个 119.29.29.29 ； 223.5.5.5 ； 180.76.76.76 。然后，如果是华南用户，就 119 打头，补个 180 ；如果是华东华北的，直接 223 打头，补个 180。就很好用了 |
 | 35 CodemonkeyM 2018 年 3 月 30 日 @elvisyao 阿里的 223.5.5.5 和 223.6.6.6 经常性抽风...ping 不通,延迟高...所以换了腾讯的 119.29.29.29.... |
 | 36 lizhineng 2018 年 3 月 30 日 突然发现 404.qq.com 解析到 Cloudflare，跟这个有关系吗？ |
 | 37 trepwq 2018 年 3 月 30 日 via iPhone @CodemonkeyM 223.5.5.5 禁 ping 了 |
 | 38 loading 2018 年 3 月 30 日 via iPhone 2 这个是我第二个能背下来的 dns，前一个是……忘了 |
 | 40 jmhjhjhj 2018 年 3 月 30 日 via Android 只有我这里 ping 出来都是 200+的吗 |
 | 41 bearqq 2018 年 3 月 30 日 via Android 我司内网上网认证网关 IP 就是 1.1.1.1 |
 | 42 ConnersHua 2018 年 3 月 30 日 1 |
| 43 gcod 2018 年 3 月 30 日 2 @lizhineng 404.qq.com 看了下 A 记录是解析到了 1.1.1.1 上面 @kimown 软件在这里下载 https://www.ipip.net/download.html#ip_trace |
 | 44 nightcat 2018 年 3 月 30 日 via Android 个人认为 CNNIC 的 1.2.4.8 才是最完美的二进制地址 |
 | 45 abmin521 2018 年 3 月 30 日 |
 | 46 bsder 2018 年 3 月 30 日 via iPhone ip 地址真好记，又多了个选择 |
 | 48 CloudnuY 2018 年 3 月 30 日 路由死在了省核心机房上……而且居然有 rDNS …… |
 | 49 input2output 2018 年 3 月 30 日 via Android 我上个星期还查过这个 ip 的所在商,还在想怎么没做个 dns …… |
 | 50 orzz 2018 年 3 月 30 日 ping 值 200+ms |
 | 52 LittleYangYang 2018 年 3 月 30 日 上海电信.... 正在 Ping 1.1.1.1 具有 32 字节的数据: 来自 1.1.1.1 的回复: 字节=32 时间=180ms TTL=53 来自 1.1.1.1 的回复: 字节=32 时间=180ms TTL=53 来自 1.1.1.1 的回复: 字节=32 时间=180ms TTL=53 来自 1.1.1.1 的回复: 字节=32 时间=180ms TTL=53 1.1.1.1 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)， 往返行程的估计时间(以毫秒为单位): 最短 = 180ms，最长 = 180ms，平均 = 180ms |
 | 53 dfly0603 2018 年 3 月 30 日 via Android |
 | 54 sodora 2018 年 3 月 30 日 广州移动的延时真心好哇！ Cloudflare 在香港有节点，移动到 Cloudflare 走的是香港。 C:\Users\Sodora>tracert -d 1.1.1.1 通过最多 30 个跃点跟踪到 1.1.1.1 的路由 1 1 ms 1 ms 2 ms 192.168.0.254 2 <1 毫秒 <1 毫秒 <1 毫秒 192.168.0.1 3 * * * 请求超时。 4 5 ms 4 ms 7 ms 183.233.54.41 5 * 10 ms * 211.139.159.181 6 9 ms 9 ms 21 ms 221.183.26.57 7 17 ms 13 ms 13 ms 221.176.18.110 8 * 16 ms 14 ms 221.176.19.194 9 12 ms 17 ms 15 ms 221.183.55.81 10 * 28 ms * 223.120.2.5 11 29 ms 30 ms 30 ms 223.120.2.54 12 25 ms 30 ms 25 ms 223.120.2.54 13 28 ms 28 ms 28 ms 123.255.90.246 14 29 ms 27 ms 29 ms 1.1.1.1 跟踪完成。 C:\Users\Sodora>ping 1.1.1.1 正在 Ping 1.1.1.1 具有 32 字节的数据: 来自 1.1.1.1 的回复: 字节=32 时间=19ms TTL=51 来自 1.1.1.1 的回复: 字节=32 时间=17ms TTL=53 来自 1.1.1.1 的回复: 字节=32 时间=16ms TTL=53 来自 1.1.1.1 的回复: 字节=32 时间=26ms TTL=52 1.1.1.1 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)， 往返行程的估计时间(以毫秒为单位): 最短 = 16ms，最长 = 26ms，平均 = 19ms |
 | 55 xzpjerry731 2018 年 3 月 30 日 和 8888 差不多吧 ~ ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=57 time=8.307 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=9.160 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=7.643 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=7.643 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=7.669 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=7.690 ms 64 bytes from 1.1.1.1: icmp_seq=6 ttl=57 time=7.887 ms 64 bytes from 1.1.1.1: icmp_seq=7 ttl=57 time=8.337 ms 64 bytes from 1.1.1.1: icmp_seq=8 ttl=57 time=8.419 ms 64 bytes from 1.1.1.1: icmp_seq=9 ttl=57 time=8.426 ms 64 bytes from 1.1.1.1: icmp_seq=10 ttl=57 time=8.426 ms ^C --- 1.1.1.1 ping statistics --- 11 packets transmitted, 11 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 7.643/8.146/9.160/0.460 ms ~ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=59 time=8.038 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=8.071 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=7.434 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=8.025 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=7.470 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=8.282 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=59 time=7.304 ms 64 bytes from 8.8.8.8: icmp_seq=7 ttl=59 time=7.731 ms 64 bytes from 8.8.8.8: icmp_seq=8 ttl=59 time=7.513 ms 64 byts from 8.8.8.8: icmp_seq=9 ttl=59 time=7.457 ms 64 bytes from 8.8.8.8: icmp_seq=10 ttl=59 time=7.367 ms ^C --- 8.8.8.8 ping statistics --- 11 packets transmitted, 11 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 7.304/7.699/8.282/0.328 ms |
 | 57 leopard080264 2018 年 3 月 30 日  |
 | 58 wdlth 2018 年 3 月 30 日 这年头都用 IP 地址炫富么？ |
 | 59 beimenjun PRO CloudFlare 这几年这是赚了多少啊…… |
 | 62 zyqf 2018 年 3 月 31 日 via Android 坐等 6.6.6.6 |
 | 63 unneeded 2018 年 3 月 31 日 正在 Ping 1.1.1.1 具有 32 字节的数据: 来自 1.1.1.1 的回复: 字节=32 时间<1ms TTL=254 来自 1.1.1.1 的回复: 字节=32 时间<1ms TTL=254 来自 1.1.1.1 的回复: 字节=32 时间=2ms TTL=254 来自 1.1.1.1 的回复: 字节=32 时间<1ms TTL=254 1.1.1.1 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)， 往返行程的估计时间(以毫秒为单位): 最短 = 0ms，最长 = 2ms，平均 = 0ms |
 | 64 bin456789 2018 年 3 月 31 日 前几天学习搭建 dns 服务器，刚好转发器设置了 1.1.1.1，居然解析成功了 ping 1.1.1.1 延迟也很低，还以为是运营商搞的鬼 |
 | 66 bitkwan 2018 年 3 月 31 日 1 记得当时去澳门机场的时候，澳门机场的 Wifi 验证服务器就用的 1.1.1.1，这下澳门机场要尴尬了（ |
 | 67 nyanyh 2018 年 3 月 31 日 PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=50 time=275.330 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=50 time=176.645 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=50 time=319.279 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=50 time=187.436 ms 为什么你们延迟都那么小 |
 | 68 xenme 2018 年 3 月 31 日 上海电信，40ms 以内，还行 Host Loss% Snt Last Avg Best Wrst StDev 1. 172.x.x.7 0.0% 11 3.3 3.6 3.1 4.6 0.3 2. 172.x.x.1 0.0% 11 3.4 3.9 2.5 4.8 0.3 3. 192.x.x.1 0.0% 11 3.8 4.7 3.6 11.0 2.0 4. 222.72.255.206 0.0% 11 6.7 6.6 5.9 7.5 0.0 5. 124.74.38.153 0.0% 11 8.5 8.9 6.7 15.0 2.1 6. 101.95.41.185 0.0% 11 7.3 9.5 6.6 14.7 2.2 7. 59.43.77.157 0.0% 11 6.5 7.1 6.0 10.1 1.0 8. 59.43.18.106 0.0% 11 6.3 6.6 5.9 8.3 0.5 9. 59.43.130.202 36.4% 11 8.5 8.1 7.3 8.7 0.0 10. 59.43.247.62 0.0% 11 7.4 7.3 6.4 11.8 1.5 11. 59.43.188.230 0.0% 11 35.9 35.7 35.1 37.6 0.5 12. xe-0-0-21-2.a00.chwahk02.hk.bb.g 0.0% 10 60.3 39.3 35.4 60.3 7.6 13. ae-14.r03.tkokhk01.hk.bb.gin.ntt 0.0% 10 37.8 37.9 37.1 41.3 1.1 14. ae-1.a01.newthk03.hk.bb.gin.ntt. 0.0% 10 39.6 38.8 36.2 46.7 2.9 15. 203.131.254.94 0.0% 10 36.8 36.4 35.5 37.5 0.3 16. 1dot1dot1dot1.cloudflare-dns.com 0.0% 10 37.7 38.0 37.2 38.8 0.0 |
 | 70 mytsing520 PRO C:\Users\hasee>ping 1.1.1.1 正在 Ping 1.1.1.1 具有 32 字节的数据: 来自 1.1.1.1 的回复: 字节=32 时间=194ms TTL=53 来自 1.1.1.1 的回复: 字节=32 时间=194ms TTL=53 来自 1.1.1.1 的回复: 字节=32 时间=194ms TTL=53 来自 1.1.1.1 的回复: 字节=32 时间=194ms TTL=53 1.1.1.1 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)， 往返行程的估计时间(以毫秒为单位): 最短 = 194ms，最长 = 194ms，平均 = 194ms C:\Users\hasee>ping 8.8.8.8 正在 Ping 8.8.8.8 具有 32 字节的数据: 来自 8.8.8.8 的回复: 字节=32 时间=43ms TTL=42 来自 8.8.8.8 的回复: 字节=32 时间=43ms TTL=42 来自 8.8.8.8 的回复: 字节=32 时间=43ms TTL=42 来自 8.8.8.8 的回复: 字节=32 时间=43ms TTL=42 8.8.8.8 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)， 往返行程的估计时间(以毫秒为单位): 最短 = 43ms，最长 = 43ms，平均 = 43ms C:\Users\hasee>ping 9.9.9.9 正在 Ping 9.9.9.9 具有 32 字节的数据: 来自 9.9.9.9 的回复: 字节=32 时间=216ms TTL=51 来自 9.9.9.9 的回复: 字节=32 时间=216ms TTL=51 来自 9.9.9.9 的回复: 字节=32 时间=216ms TTL=51 来自 9.9.9.9 的回复: 字节=32 时间=216ms TTL=51 9.9.9.9 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)， 往返行程的估计时间(以毫秒为单位): 最短 = 216ms，最长 = 216ms，平均 = 216ms C:\Users\hasee>ping 1.2.4.8 正在 Ping 1.2.4.8 具有 32 字节的数据: 来自 1.2.4.8 的回复: 字节=32 时间=5ms TTL=54 来自 1.2.4.8 的回复: 字节=32 时间=5ms TTL=54 来自 1.2.4.8 的回复: 字节=32 时间=5ms TTL=54 来自 1.2.4.8 的回复: 字节=32 时间=5ms TTL=54 1.2.4.8 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)， 往返行程的估计时间(以毫秒为单位): 最短 = 5ms，最长 = 5ms，平均 = 5ms |
 | 72 0017 2018 年 3 月 31 日 正在 Ping 1.1.1.1 具有 32 字节的数据: 请求超时。 不通的不是因为内网 ip 而是因为被墙了吧... |
 | 73 BlueFly 2018 年 3 月 31 日 1.0.0.1 1.1.1.1 4.2.2.2 4.2.2.1 8.8.4.4 8.8.8.8 9.9.9.9 |
 | 77 la0wei 2018 年 3 月 31 日 江苏扬州移动 tracert 1.1.1.1，到南京后基本无显，然后直接到 cloudflare，时延在 200-230 之间。 tracert 1.0.0.1 倒是挺快的，走的上海移动到香港移动，然后香港 hkix |
 | 80 realpg PRO @mhycy #76 实际上 有很多这种蛋疼的设备 另外一段的 loopback 接口为 1.1.1.1 的就接入了公网……也没人发现，而且通过 ospf 学习并广播了 我说的是一级运营商的真实生产大网 比如沈阳联通：  |
 | 81 xttttt 2018 年 3 月 31 日 via Android 在中国都成内网了吧 |
 | 83 kennylam777 2018 年 3 月 31 日 https://1.1.1.1 及 https://1.0.0.1 也有了，希望更一步提供 https DNS 吧。 |
 | 84 v2register 2018 年 4 月 1 日 1 @kennylam777 #83 现在就支持啊，客户端可以用 dnscrypt-proxy ## cloudflare Cloudflare public DNS server (anycast) sdns://AgcAAAAAAAAABzEuMS4xLjEg63Ul-I8NlFj4GplQGb_TTLiczclX57DvMV8Q-JdjgRgSZG5zLmNsb3VkZmxhcmUuY29tCi9kbnMtcXVlcnk |
 | 85 sliamb 2018 年 4 月 1 日 我记得某些交换机管理用的就是这个地址。。无语 |
 | 86 cat9life 2018 年 4 月 2 日 我这里电信延迟 160ms |
 | 87 loser 2018 年 4 月 2 日 64 bytes from 1.1.1.1: icmp_seq=281 ttl=54 time=181.375 ms 64 bytes from 1.1.1.1: icmp_seq=282 ttl=54 time=181.528 ms 64 bytes from 1.1.1.1: icmp_seq=283 ttl=54 time=180.985 ms 64 bytes from 1.1.1.1: icmp_seq=284 ttl=54 time=181.818 ms 64 bytes from 1.1.1.1: icmp_seq=285 ttl=54 time=181.621 ms 64 bytes from 1.1.1.1: icmp_seq=286 ttl=54 time=181.078 ms 64 bytes from 1.1.1.1: icmp_seq=287 ttl=54 time=181.311 ms 64 bytes from 1.1.1.1: icmp_seq=288 ttl=54 time=181.076 ms 64 bytes from 1.1.1.1: icmp_seq=289 ttl=54 time=181.226 ms 64 bytes from 1.1.1.1: icmp_seq=290 ttl=54 time=181.207 ms 64 bytes from 1.1.1.1: icmp_seq=291 ttl=54 time=180.727 ms 64 bytes from 1.1.1.1: icmp_seq=292 ttl=54 time=181.453 ms 64 bytes from 1.1.1.1: icmp_seq=293 ttl=54 time=180.866 ms 64 bytes from 1.1.1.1: icmp_seq=294 ttl=54 time=180.757 ms 64 bytes from 1.1.1.1: icmp_seq=295 ttl=54 time=181.241 ms 64 bytes from 1.1.1.1: icmp_seq=296 ttl=54 time=180.725 ms 64 bytes from 1.1.1.1: icmp_seq=297 ttl=54 time=181.368 ms 64 bytes from 1.1.1.1: icmp_seq=298 ttl=54 time=181.569 ms 64 bytes from 1.1.1.1: icmp_seq=299 ttl=54 time=181.496 ms chengdu telcom |
 | 88 ivyliner 2018 年 4 月 2 日 @moult SSL 证书是为了支持 DoH https://datatracker.ietf.org/wg/doh/about/ |
 | 90 ahxsong 2018 年 4 月 4 日 我咋 1 毫秒都不到？？ PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=127 time=0.577 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=127 time=1.043 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=127 time=0.614 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=127 time=0.640 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=127 time=0.759 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=127 time=0.904 ms 64 bytes from 1.1.1.1: icmp_seq=6 ttl=127 time=0.643 ms 64 bytes from 1.1.1.1: icmp_seq=7 ttl=127 time=0.649 ms 64 bytes from 1.1.1.1: icmp_seq=8 ttl=127 time=0.678 ms 64 bytes from 1.1.1.1: icmp_seq=9 ttl=127 time=0.652 ms ^C |
 | 93 liuyinltemp 2018 年 4 月 26 日 @elvisyao 其实就 119 这个不错，另外 114 其实也可以，其他阿里百度都不行 |
Select Language