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-07-26 10:53:34 +08:00
8888 确实不行了,安徽电信; 8844 还好
之前有次 114114114114 跪了,换成了 8888,现在 8888 也凉了 |
2
ddzy 2019-07-26 10:57:07 +08:00
打断一下, 我爱 gcc
|
3
blakebill OP @qwerthhusn 暂时用回电信官方 DNS 了,等后续,然后准备自建还是其他的。
|
4
anguiao 2019-07-26 10:57:51 +08:00 via Android
国内没必要用国外 DNS
|
5
ZhouMidan 2019-07-26 10:59:08 +08:00
上海电信
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.8.8.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-07-26 11:02:42 +08:00
mtr 看下路由
|
7
blakebill OP @ZhouMidan 我这边两条一条 SDN 200M,一条普通 500M 均测试为超时,上海的网络确实跟重庆的路一样让人搞不懂:)
|
9
meteor 2019-07-26 11:22:26 +08:00
@blakebill 那就是恢复了。Google 的 DNS 被屏蔽以前不是没发生过。要稳定还是用国内的 DNS 比较好,Google 的备用。
|
10
mrw77 2019-07-26 11:36:11 +08:00
为什么在国内用谷歌的 dns,我不明白。
过 Q 那一刻污染,谷歌国内就北京有服务器,但肯定不会解析的 |
11
leonard916 2019-07-26 11:37:29 +08:00 1
這個 IP 一直都被搶答 被屏蔽
早就沒有實用價值了 |
12
z919126592 2019-07-26 11:46:54 +08:00 via Android
我这里 Google DNS 一直都是抢答的…
|
13
HalloCQ 2019-07-26 11:55:25 +08:00
|
15
titanium98118 2019-07-26 13:36:42 +08:00
国内没必要用 8.8.8.8
|
16
stephenyin 2019-07-26 14:10:38 +08:00
@bclerdx #14 mtr
|
17
blakebill OP @mrw77 路由器设置大概三年没动过了,之前使用倒还不错,近半年的话开始丢包,昨天上海电信应该是明确屏蔽了,现在也用回电信 DNS 了,反正现在劫持现象比较少
|
18
blakebill OP @titanium98118 确实是这样了,体验很差。
|
19
nevermakeyoucryt 2019-07-26 14:38:48 +08:00
国内用谷歌确实不是一个明智的选择,不嫌解析慢拖累网速么
|
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-07-26 15:05:50 +08:00
这不是很久之前就这样了么,一阵能用一阵不行。反正能用的时候也是被污染的
|
22
tuding 2019-07-26 15:06:39 +08:00
墙裂不建议用 114.114.114.114
|
23
iPhoneXI 2019-07-26 15:07:00 +08:00 via Android
Android 自带 DNS over TLS
用 dns.google 就行 |
24
xuyl 2019-07-26 15:13:25 +08:00
国内有很多可选的,
百度公共 dns 180.76.76.76 阿里公共 dns 223.5.5.5 223.6.6.6 腾讯公共 dns 119.29.29.29 |
26
masana 2019-07-26 15:31:28 +08:00 1
你想象的 8888 其实早就被透明代理了
|
27
chcx 2019-07-26 16:59:49 +08:00
mtr 看丢包起飞~
|
28
billytom 2019-07-26 17:02:12 +08:00
今天的 8888 是有点问题,8844 还是好的,1111 也一切正常
|
30
est 2019-07-26 17:35:12 +08:00
墙内的 8888 早就不是 g 家在返回了吧。。
|
31
passerbytiny 2019-07-26 17:36:38 +08:00
@Counter #25 114 做大了(可以开始宰羊了),就这一条就够了。
|
32
missdeer 2019-07-26 17:45:08 +08:00
我 8888 和 8844 都是自己截持到本地用,有些程序好像写死了用 8888/8844,没办法
|
33
Buges 2019-07-26 17:52:19 +08:00 via Android 1
DNS 问题强烈推荐用 DNScrypt-proxy 上 doh,直接用 1111 就好。手机电脑路由器全平台。
|
34
tuding 2019-07-26 18:15:35 +08:00 via Android 1
|
35
hailaz 2019-07-26 18:22:10 +08:00
一直用 8844 挺稳的,8888 以前特意测试过不稳。坐标广州电信
|
36
hailaz 2019-07-26 18:24:18 +08:00
至于 114,呵呵
|
37
wwbfred 2019-07-26 18:38:37 +08:00
四个 8 经常会挂,基本上过段时间自己就好了.其实直接用 8844 挺稳的.
国内的话别只用这个当主 DNS.解析国外域名挺好的,但有 cdn 的国内站会被带着全世界到处跑. |
38
Windelight 2019-07-26 19:25:23 +08:00 via Android
經 Trace。河北鐵通,從石家莊移動、北京移動出國去美利堅加州 level3 (谷歌加州)。河北聯通,從本地的城級網直接到廣州聯通再到香港聯通到谷歌香港。
|
39
fancyhan 2019-07-26 21:06:30 +08:00
这都什么年代的新闻了,这个很早就不推荐了
|
40
bclerdx 2019-07-26 21:13:35 +08:00
@stephenyin 上个工具图,谢谢!
|
41
mattx 2019-07-26 21:14:52 +08:00 via iPhone
村网通么?国内还用谷歌 dns ?又不能防污染,用这个干嘛?
|
43
runtu2019 2019-07-26 21:36:59 +08:00
一般是本地自建 dns 缓存,用香港 dns
|
45
SvenRogue 2019-07-26 22:51:48 +08:00
114 最近也不太行 求问打游戏(战地 5 )用哪家 dns 比较好
|
46
mytsing520 2019-07-27 19:09:29 +08:00
2019.07.27 ,电信网络已经恢复 8.8.8.8 的连接。
|
49
blakebill OP @SvenRogue 8844 吧,目前看来 8888 不稳定 8844 还是可以的,或者你可以下载一个 DNSBench 测一下
|
50
duoduo1x 2019-07-28 14:10:05 +08:00
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-08-11 22:43:42 +08:00 via Android
不行就不行
|