@sailtao 哦對了， HTTPS 流量是無法緩存的，因為無法解密，而且密文無法重放。

@sailtao 之前不管劫持 TCP 的方式還是劫持 DNS 都是通過旁路搶答的方式，通過交換機的鏡像口就可以部署，還可以輕鬆控制劫持的頻率和規則。
如果按你說的方法，會導致所有流量被引入這些緩存服務器，不管是 HTTP 還是其他流量。相對於中國這麼大的互聯網來講，對處理能力的要求可能比雙十一還要恐怖得多，更不用提如何保證各種加密流量和自定義協議的通信了。

@sailtao 對於聯通這種規模的運營商來講，你說的這種方法成本太高了，當然他們要是誠心搞還是能搞出來。
不過劫持總是有辦法發現的。

@xmoiduts 感覺以後全站 HTTPS 是趨勢。國外的大型網站很多都全站 HTTPS 了，國內淘寶、百度的搜索服務已實現全站 HTTPS ，京東也在內測全站 HTTPS 。隨著 HTTPS 的普及，劫持已經變得越來越沒意義了。

@xmoiduts 得到網站和 CDN 服務商的准許當然就不算劫持了，但這樣的話聯通那套東西不就成了 CDN 了麼。聯通現在瞎搞劫持肯定會導致大量問題的。比如將境外服務器解析到內網，天呐，網絡中又不是只有 HTTP 協議，你讓各種其他協議怎麼辦，比如我用 SSH 登錄機器會被搞成登錄聯通的緩存服務器？所以，聯通絕對腦子抽風了。

@bazingaterry 北京聯通暫時未發現此現象，不過也許是因為我經常投訴被特殊「關照」了。
@heyf 關鍵是「好」心辦壞事。看來聯通確實是窮了，沒錢擴充骨幹網帶寬，只能靠劫持緩存來緩解了。

果然，之前搞劫持代理被投訴後開始玩新花樣了。
如果只是聯通的自建 DNS 會解析到緩存服務器就算了，如果第三方或自建 DNS 也這樣的話，投訴。

用 mtr 測，看看是從哪個節點開始丟的，然後檢查響應的交換機、路由器是否過載，再檢查對應子網是否存在 arp 攻擊或廣播風暴。

如果聯通把這些服務器做成 CDN 賣，那肯定是好事。
如果聯通繼續搞劫持，我還是會投訴。

我有幾個問題：
1. H5 是什麼？是指 HTML5 頁面嗎？
2. WAP 頁面是什麼？是指 WML 頁面嗎？如果是的話， WML 早就屬於淘汰的技術了。
3. GPRS ？你是指 2G 時代那套技術嗎？如果使用 cmwap （移動）或 uniwap （聯通）接入點的話，用戶通過運營商代理訪問網絡， HTTP 頭部會被添加幾個特殊的 Header ，另外我記得 WAP 下只支持 HTTP 協議。

我現在就有一台二手服務器，噪音感人，沒有專門的機房或者乾燥的地下室的話，還是上塔式吧

我就不提我辦的一個北京移動的號碼能登錄前主人的大量網站了，而且我還沒辦法解綁（需要填新手機號）

@moult 個人覺得封鎖 Google 是導致翻牆人數上升的直接原因。百度太難用了。

google.cn 的解析確實是變了。坐標北京聯通：
$ dig www.google.cn +trace

; <<>> DiG 9.10.3-P2-RedHat-9.10.3-7.P2.fc23 <<>> www.google.cn
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19300
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;www.google.cn. IN A

;; ANSWER SECTION:
www.google.cn. 117 IN A 64.233.189.160

;; Query time: 2 msec
;; SERVER: 10.11.0.1#53(10.11.0.1)
;; WHEN: Sat Jan 23 16:08:43 CST 2016
;; MSG SIZE rcvd: 58

[vfreex@rayson-blackchan ~]$ dig www.google.cn +trace

; <<>> DiG 9.10.3-P2-RedHat-9.10.3-7.P2.fc23 <<>> www.google.cn +trace
;; global options: +cmd
. 290918 IN NS i.root-servers.net.
. 290918 IN NS j.root-servers.net.
. 290918 IN NS k.root-servers.net.
. 290918 IN NS l.root-servers.net.
. 290918 IN NS m.root-servers.net.
. 290918 IN NS a.root-servers.net.
. 290918 IN NS b.root-servers.net.
. 290918 IN NS c.root-servers.net.
. 290918 IN NS d.root-servers.net.
. 290918 IN NS e.root-servers.net.
. 290918 IN NS f.root-servers.net.
. 290918 IN NS g.root-servers.net.
. 290918 IN NS h.root-servers.net.
;; Received 239 bytes from 10.11.0.1#53(10.11.0.1) in 14 ms

cn. 172800 IN NS d.dns.cn.
cn. 172800 IN NS b.dns.cn.
cn. 172800 IN NS ns.cernet.net.
cn. 172800 IN NS a.dns.cn.
cn. 172800 IN NS e.dns.cn.
cn. 172800 IN NS c.dns.cn.
cn. 86400 IN DS 24697 8 2 A8BD8346D72C8C08FCE76D85298A8D58025323487122C5354D6E34AD 857498E3
cn. 86400 IN RRSIG DS 8 1 86400 20160202050000 20160123040000 54549 . S+WFT1uFr9yuYwtE8+w4UKXwcQQRtZPcFNUr8MkgP8+NmQ+eGNJCV/Qj mUCIg17L50kHgWijjYubk3Lctq1ZuVPP6Hayjjz5zZIekYW/5qi4LcoJ EO6pcdgZQUfL7/adoX9Pf5CdY6D/FAkDjqBgr2UvWEoGgY5rD7yfBTdo YeQ=
;; Received 512 bytes from 192.112.36.4#53(g.root-servers.net) in 328 ms

google.cn. 86400 IN NS ns1.google.com.
google.cn. 86400 IN NS ns4.google.com.
google.cn. 86400 IN NS ns3.google.com.
google.cn. 86400 IN NS ns2.google.com.
3QDAQA092EE5BELP64A74EBNB8J53D7E.cn. 21600 IN NSEC3 1 1 10 AEF123AB 3QLMP0QRNQ96G5AFGOPNB7U7IJ4MBP4B NS SOA RRSIG DNSKEY NSEC3PARAM
3QDAQA092EE5BELP64A74EBNB8J53D7E.cn. 21600 IN RRSIG NSEC3 8 2 21600 20160204095230 20160105085239 10680 cn. prOlIUtwQhqsnPUz8N3XVdNkZ8h7JQfLUZrQGuTHXC5vPDOF8vBOClEM SzzObVb6FR5acEL0HFNsKncyPbVraBxGvMd1h0a6MGPI6QBLvBNpCQya cgvkQa2rhl6zvFWfWnfQsFwvLtASI+5dGDcWrIf36GjmFW8yNBx3tnXX ANU=
8TM10SUG7NMG1C1GU6KIL3P61OE3JKI2.cn. 21600 IN NSEC3 1 1 10 AEF123AB 8TN7D4R99B9F9CM0C56QGJVQNGD0TU04 CNAME RRSIG
8TM10SUG7NMG1C1GU6KIL3P61OE3JKI2.cn. 21600 IN RRSIG NSEC3 8 2 21600 20160201024418 20160102022048 10680 cn. u63loHTk3l8QBnnWtDu0an0l9PtMpSSnBa1Ch94HTKAyUlo/KmjjGkzu 38YiLEFpI2r4STglBAlIysQyLEO2NouP+VTfQWT9k4VejxE2qjz/wVUC 5pBs8YuWjRo6wwRSYDVDs7vxxSdQSyS5h0cVa+9+CW4BWLG/iog74q5q TNM=
;; Received 615 bytes from 2001:dc7:1000::1#53(d.dns.cn) in 264 ms

www.google.cn. 300 IN A 64.233.189.160


$ mtr 64.233.189.160
;; Received 47 bytes from 216.239.36.10#53(ns3.google.com) in 409 ms

Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. ************* 0.0% 14 1.2 27.7 1.1 368.4 98.1
2. ************* 0.0% 14 4.7 37.2 4.7 310.9 85.1
3. 61.148.174.185 38.5% 14 6.1 5.2 2.7 9.0 2.0
4. 61.51.113.145 0.0% 14 6.9 20.1 5.8 185.2 47.5
5. 123.126.0.57 0.0% 14 7.9 17.0 5.5 124.7 31.1
6. 219.158.7.18 0.0% 14 35.5 52.3 35.4 135.2 28.2
7. 219.158.11.202 0.0% 14 191.2 144.1 78.6 191.2 36.0
8. 219.158.19.89 15.4% 14 162.3 160.5 109.1 289.5 50.9
9. 219.158.97.254 0.0% 13 230.6 201.7 115.1 290.7 55.8
10. 219.158.33.174 7.7% 13 197.4 163.7 106.3 364.3 71.4
11. 209.85.241.56 0.0% 13 193.6 181.0 115.5 301.4 48.5
12. 216.239.40.35 16.7% 13 193.7 155.7 116.6 239.3 35.2
13. 216.239.57.239 0.0% 13 412.7 388.3 316.3 508.4 53.2
14. 64.233.175.209 25.0% 13 259.8 279.1 190.2 750.8 179.0
15. ???
16. tl-in-f160.1e100.net 8.3% 13 442.8 459.9 379.9 806.7 118.2

聯通的出口問題從 12 初就存在了，聯通技術人員說是海纜故障，誰知道呢

@1423 如果是真丢包的話，會從某個節點開始一串全是丢包。像這種某一跳丢包而後續不丢的都是策略丢包，目的是防止 ICMP 耗費性能，保護路由器的。

好多網絡設備在負載高的情況下會對 ICMP 策略丢包，但並不會影響 TCP 、 UDP 等數據包的傳輸。建議還是按樓上所說排查一下。

@fourstring 我記得是可以在不影響電話和 ITV 的情況下改橋接的，你可以打電話問問或網上查一下。

據 @redsonic 講，「魔都联通最近访问外站十分缓慢，联通的技术人员回复我说去年 12 月以后联通海缆故障造成的。不知道和这次的缓存事件有没有联系。一开始他们建议我换 dns ，走国内 cdn ，然后我说我用的服务是 ip 直连海外 他们就说只能等年后海缆修好再看了。」
但願如此吧。