HK_T 网络也有 http 缓存劫持

关键是怎么拖下来？如何操作呢？如题不是说拒绝访问？

我这边也有类似的情况

@bclerdx #1 必须用着 hkt 的网络..用途很有限

chrome 直接弹红窗口。。。

这就是运营商的 cdn 吧 可以节约网间带宽

节约网外流量……也不算是奇怪事情吧，除非你全称

@xxq2112 除非你买了 PCCW 的带宽，那就可以去算账了

PCCW 是 Tier 1，但是 HKT 是其下游，两回事

@cloudyi666 这就是运营商的 cdn 吧 可以节约网间带宽+1

现在内地也在朝着这个方向发展，而且是点名了三大运营商要继续大力发展这类 CDN，提升终端到本地网络之间的带宽规模

的確用 HKT IP 進去就會被 302 到一個 HKT IP，但你也得看看，用非 HKT IP 或 HTTPS 進去時的 Server header 也相若。有可能只是 WPS 租一台 PCCW 的做二級緩存而已。

在我看來只是 WPS 自己的 CDN 調度，nginx/tengine 要做出這調度也很簡單，不如在 HKT IP 用 TCP traceroute 測一下，應該可以分辨出劫持點吧?


-==PCCW IP==-
# curl "http://wdl1.cache.wps.cn/wps/download/ep/WPS2019/WPSProPlus_11.8.2.8576.exe" -Lvo /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0* Trying 123.53.182.246...
0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0* Connected to wdl1.cache.wps.cn (123.53.182.246) port 80 (#0)
> GET /wps/download/ep/WPS2019/WPSProPlus_11.8.2.8576.exe HTTP/1.1
> Host: wdl1.cache.wps.cn
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Tengine
< Content-Type: application/octet-stream
< Content-Length: 204818672
< Connection: keep-alive
< Date: Sun, 25 Aug 2019 06:52:43 GMT
< Cache-Control: max-age=86400
< Etag: "5d566014-c3548f0"
< Expires: Sun, 25 Aug 2019 20:02:11 GMT
< X-M-Log: QNM:xs1170;QNM3/304
< X-M-Reqid: XWQAALsnTjneF74V
< X-Qnm-Cache: Hit
< Accept-Ranges: bytes
< Last-Modified: Fri, 16 Aug 2019 07:49:40 GMT
< Via: cache28.l2cn1821[0,304-0,H], cache29.l2cn1821[2,0], cache4.cn850[0,200-0,H], cache3.cn850[6,0]
< Ali-Swift-Global-Savetime: 1565951011
< Age: 115313
< X-Cache: HIT TCP_HIT dirn:11:439342943
< X-Swift-SaveTime: Mon, 26 Aug 2019 00:09:31 GMT
< X-Swift-CacheTime: 86400
< Timing-Allow-Origin: *
< EagleId: 7b35b69715668312767406381e

-==HKT IP + HTTPS==-
# curl "https://wdl1.cache.wps.cn/wps/download/ep/WPS2019/WPSProPlus_11.8.2.8576.exe" -Lvo /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 123.53.182.248...
* TCP_NODELAY set
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to wdl1.cache.wps.cn (123.53.182.248) port 443 (#0)
0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [223 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [104 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2633 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [300 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=wdl1.cache.wps.cn
* start date: Aug 21 00:00:00 2019 GMT
* expire date: Aug 20 12:00:00 2020 GMT
* subjectAltName: host "wdl1.cache.wps.cn" matched cert's "wdl1.cache.wps.cn"
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=Encryption Everywhere DV TLS CA - G1
* SSL certificate verify ok.
> GET /wps/download/ep/WPS2019/WPSProPlus_11.8.2.8576.exe HTTP/1.1
> Host: wdl1.cache.wps.cn
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Tengine
< Content-Type: application/octet-stream
< Content-Length: 204818672
< Connection: keep-alive
< Date: Sun, 25 Aug 2019 06:52:43 GMT
< Cache-Control: max-age=86400
< Etag: "5d566014-c3548f0"
< Expires: Sun, 25 Aug 2019 20:02:11 GMT
< X-M-Log: QNM:xs1170;QNM3/304
< X-M-Reqid: XWQAALsnTjneF74V
< X-Qnm-Cache: Hit
< Accept-Ranges: bytes
< Last-Modified: Fri, 16 Aug 2019 07:49:40 GMT
< Via: cache28.l2cn1821[0,304-0,H], cache29.l2cn1821[2,0], cache4.cn850[0,200-0,H], cache3.cn850[1,0]
< Ali-Swift-Global-Savetime: 1565951011
< Age: 115827
< X-Cache: HIT TCP_MEM_HIT dirn:11:439342943
< X-Swift-SaveTime: Mon, 26 Aug 2019 00:09:31 GMT
< X-Swift-CacheTime: 86400
< Timing-Allow-Origin: *
< EagleId: 7b35b69715668317902284671e
<
{ [2223 bytes data]
8 195M 8 16.8M 0 0 4213k 0 0:00:47 0:00:04 0:00:43 4212k

-==其他 IP==-
# curl "http://wdl1.cache.wps.cn/wps/download/ep/WPS2019/WPSProPlus_11.8.2.8576.exe" -Lvo /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0* Trying 123.53.182.248...
0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0* Connected to wdl1.cache.wps.cn (123.53.182.248) port 80 (#0)
> GET /wps/download/ep/WPS2019/WPSProPlus_11.8.2.8576.exe HTTP/1.1
> Host: wdl1.cache.wps.cn
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Tengine
< Content-Type: application/octet-stream
< Content-Length: 204818672
< Connection: keep-alive
< Date: Sun, 25 Aug 2019 06:52:43 GMT
< Cache-Control: max-age=86400
< Etag: "5d566014-c3548f0"
< Expires: Sun, 25 Aug 2019 20:02:11 GMT
< X-M-Log: QNM:xs1170;QNM3/304
< X-M-Reqid: XWQAALsnTjneF74V
< X-Qnm-Cache: Hit
< Accept-Ranges: bytes
< Last-Modified: Fri, 16 Aug 2019 07:49:40 GMT
< Via: cache28.l2cn1821[0,304-0,H], cache29.l2cn1821[2,0], cache4.cn850[0,200-0,H], cache10.cn850[1,0]
< Ali-Swift-Global-Savetime: 1565951011
< Age: 115494
< X-Cache: HIT TCP_MEM_HIT dirn:11:439342943
< X-Swift-SaveTime: Mon, 26 Aug 2019 00:09:31 GMT
< X-Swift-CacheTime: 86400
< Timing-Allow-Origin: *
< EagleId: 7b35b69e15668314574327095e

Netvigator 的 transparent proxy 只有 56k 年代及早期的 1.5Mbps ATM 寬頻有見識過，之後都沒有見過了。

这算是加速不算劫持吧

不过对于比较敏感的资源,多了一个可能出问题的步骤
以后基本 HASH 要变成常规操作了

@FS1P7dJz 2019 年了, HTTP 劫持也是直接用 HTTPS 能解決的事, 除非你有 APT 一類的 Client 體系可以自造 HASH 的輪子

@caienglishprc
況且這情況, 連 HKT 劫持都說不上, 不讓人家 WPS 做調度嗎?一個大陸網站的 url 被 302, 就跳出來說是 HKT 的鍋, 想太多了吧? 當年航海時代沒世界地圖也沒有定位, 發現了印度尼西亞就以為是印度的......

2019 年我們來看看 Via header(地圖)

被 302 是 cache28 ->cache21->cache8->cache9-> hkpccw13.167 , 最後節點名字就是 hkpccw
HTTPS 直連的是 cache28 -> cache29 ->cache4 -> cache4.cn850

不死心信的話, 看看 HKT IP 的 TCP traceroute (port 80), 這是 GPS 級的了
# traceroute -T 175.6.249.248
traceroute to 175.6.249.248 (175.6.249.248), 30 hops max, 60 byte packets
1 10.193.233.172 (10.193.233.172) 2.689 ms 10.193.232.172 (10.193.232.172) 2.723 ms 2.766 ms
2 10.193.232.182 (10.193.232.182) 3.095 ms 10.193.232.181 (10.193.232.181) 2.414 ms 10.193.233.184 (10.193.233.184) 2.604 ms
3 203.198.24.29 (203.198.24.29) 2.316 ms 218.102.20.18 (218.102.20.18) 2.748 ms 218.102.20.17 (218.102.20.17) 2.772 ms
4 wtsc3a066.netvigator.com (218.102.40.66) 2.688 ms wtsc3a074.netvigator.com (218.102.40.74) 2.793 ms wtsc3a066.netvigator.com (218.102.40.66) 2.741 ms
5 TenGE0-2-0-7.br03.hkg15.pccwbtn.net (63.218.211.17) 4.806 ms 4.566 ms 4.561 ms
6 202.97.121.222 (202.97.121.222) 4.185 ms 202.97.122.118 (202.97.122.118) 3.197 ms 3.629 ms
7 202.97.121.221 (202.97.121.221) 4.163 ms 202.97.122.117 (202.97.122.117) 5.928 ms 202.97.121.221 (202.97.121.221) 9.932 ms
8 202.97.89.53 (202.97.89.53) 11.662 ms 11.634 ms *
9 * 202.97.91.189 (202.97.91.189) 10.592 ms *
10 202.97.94.125 (202.97.94.125) 28.855 ms 12.899 ms 202.97.94.121 (202.97.94.121) 16.688 ms
11 * * *
12 * * *
13 175.6.255.78 (175.6.255.78) 22.780 ms 175.6.255.82 (175.6.255.82) 47.135 ms 175.6.255.78 (175.6.255.78) 38.395 ms
14 * * *
15 175.6.249.248 (175.6.249.248) 35.612 ms 40.844 ms 33.589 ms

嗯, 沒有所謂的 HTTP 劫持。


現在 Q 外的流量大多來自 Facebook/YouTube/Cloudflare/Akamai 等等的 CDN, 都可以用公開的 HKIX 作 Public Peering 或私人的 Free private peering, 早就解決了頻寬的問題, 不像那三大 ISP 的家寬還要用穿透來維持。

HKT 還得費心為一個在香港市佔率不高的 WPS 弄 HTTP Transparent proxy 這些老掉牙的東西?

很早之前就这样了，下载腾讯离线文件有的域名就会被跳转到那 IP 导致下载失败。

@kennylam777 wps 的调度能用来随意下载任意网站资源？洗也不是这么洗的

@just1 沒甚麼奇怪的，domain 多又沒有 token 認證，就只好這樣做，運維偷懶或設計所限

Open proxy 這種東西，隨便一個 VPS 都可以造出來

不過隨你喜歡，把 HKT 說成有 HTTP 劫持的似乎是潮流，下次不知道是哪家香港 ISP 了，但這種說法不影響我使用就是

这是 wps 自己在香港设置的 cdn???

@kennylam777
https://www.google.com/search?q=219.76.13.167

WPS 的自己搞的二级代理同时还是 EPIC Game，腾讯，阿里云三家一起用的二级代理吗？还是这些用户刻意用这个 WPS 的二级代理来加速下载这些文件？

以前某通宽带，下载虾米音乐高音质歌曲总是劫持到缓存的普通音质。。。。我 &%#@! m 的！之后就一直把某通这 ip 给屏蔽了。不然给你下个什么鬼都不知道。

@CernetBoom 誰一起用就天曉得了，可能是 CDN 方案商的機子?

還有，我的 TCP Traceroute 都顯示到了 ChinaNet 了，這也算是 HKT 的鍋? 以前要指控 Hinet 都要拿出 TCP Traceroute，現在一個 server side 302 都比 TCP Traceroute 可信?

Hinet 劫持事件 https://www.v2ex.com/t/247645

@kennylam777 一个区别，Hinet 劫持事件中是直接 TCP traceroute 域名的，不如 traceroute -T wdl1.cache.wps.cn 看看

pccw 这个段的反向代理很早就有了.
之前用它还能上 Google 看 Youtube 的.
后来越搞越慢,基本也就凉了...

@kennylam777 #22
TCP trace 发的是 SYN 包
HTTP 旁路劫持得分析 HTTP GET

如果用 Wireshark/tcpdump 抓包，会抓到这个抢答的 302

@CernetBoom 其實我是直接 TCP Tracerote domain name，只是在 V2EX 發不出來「甚麼外連太多看來像 Spam 」，改掉才能發出來。


@LGA1150 這個有點麻煩了，但現時的證據還是我的比較多吧，樓主的連 302 及 headers 也欠奉就開始指控 HKT。其他人不服的話自己測一下看看，沒理由把舉證責任推給我。

@kennylam777 理解了