强制向gvs服务器请求某些特定证书(eg:ECDHE-RSA-AES128-SHA)竟然能使服务器提供gws服务(虽然发的证书依然是gvs的),Google怎么想的我也是醉了...
https://github.com/XX-net/XX-Net/issues/491

@AVC 我觉得其实可以不用做这么多条目,只要根据vps的地理位置和运营商做两三组就够了.比如你的vps在日本,那google几乎不可能给你定向到欧洲的服务器.例如9gv7en,9gv7ln服务器在墨西哥,就不需要去做.

@LGA1150 不可以.这个我也试过,但不同的视频存放于不同的服务器,自己定向到固定域名会出问题的...
@AVC 不可以.Google在国内的确有发放googlevideo.com的证书,也有ggc,但目前都是处于残废状态,不能提供视频服务.direct到哪组服务器是由google说了算,google不把我们direct到国内服务器我们就没办法.

@lennylxx 非常感谢你做的sn domains的wiki!之前也一直想弄清楚sn domains代表了什么意思,但一直没分析清编码方式...直到搜到你的解码方式才茅塞顿开!

@JamesR 我们说的不是一个东西.

@MicrosoftAzure 实际上想用hosts看youtube,在官方的redirector(见https://redirector.googlevideo.com/report_mapping)不变或有限变化的情况下(即返回视频节点不变或在几个节点之间改变),只需要将一个或几个系列的googlevideo.com地址加入hosts即可,无须将所有googlevideo.com的子域名加入hosts,而这是非常简单的,就是形成的hosts会有点长.之前相当长的一段时间之所以不能通过hosts方法访问youtube是因为当时googlevideo.com并不支持https,但在支持之后,hosts的方法实际上又变得有效了.但要这样做有一个很关键的前提,就是youtube第一次direct到的服务器或是第二次的redirect到的备用服务器,这两个必须至少有一个没有被封锁ip.如果前者的服务器没被封锁,则可直接播放;如果前者的服务器被封锁,后者没有,则会在加载相当长的一段时间后播放;如果都被封锁则无法播放.并且即使是两个服务器A和B都有同一个视频,当你把A的url的地址解析到B的ip上,那么这个视频也无法播放,所以我们无法通过dns做重定向.而google又不允许我们自主选择节点,所以导致的结果就是:在解除了dns污染之后,视频有时能播放,有时需要加载很长时间播放,有时又不能播放.

20好像被封了 把26换成50...

一般googlevideo的证书附近都会有google的证书.你把26换成20看看.

看到这个泥马真是吓尿了...我还以为psp就永远停在6.60了呢...

gmail translate scholar 静态内容(googleusercontent ggpht) 地图服务 广告服务 我知道的大概就这么多吧...我这里是电信网络,图片写到国内整体加载速度会快不少...

单位限制?不太清楚啊...可能性有点多,你先换个dns试试吧...

升级吧...我之前在win上跑旧版本也是经常100%,不知道你是用的什么系统...

1.对于google.com并没有做dns污染,无论是哪里的dns解析都会是正确的.114dns属于缓存服务器,想要查询google的ip地址第一次或者缓存期过了都要去访问ns1.google.com(还有ns2 ns3 ns4),这一过程会经过gfw. twitter/facebook等同理.所以墙有污染的,国内的缓存服务器一定有污染.
2.墙对于google 74.125与173.194段的ip没有进行完全的封锁,它对于大部分ip放行了icmp数据包,封锁/劣化了tcp数据包(或是80/443端口的数据包),这就导致能ping通,ping不丢包,但完全无法访问或是访问非常不流畅.这可以通过tcping命令来观察到(系统不自带).
3.美国的ip服务器不一定在美国,你所说的173.194.127.196应该是在香港.ping的数据包的确是由google返回的,不是伪造的.再次ping出现timeout就是当前时间段对icmp数据包也进行了封锁/劣化,你刚刚ping的时候正好放行了.

scholar.google.com.cn 走的是北京的服务器,Gmail是出国线路.
意味着状况其实没有什么本质上的改观.
神马时候能tcping通74.125或173.194,就解封了.