|
阅读：5949回复：13
【已解决】怎样应对302跳转的运营商劫持/广告？
每隔一段时间，运营商会将http包，302重定向到某网址：
http://231.5.88.30:8080/psbsp/?authIndentifyID=PSBS_CACHE_1478156848157_6945930_931&SESSION_ID=b1-s-gd01111062600000a1fb6e232594&8158 【劫持HTTP返回假响应，包头302跳转】 参考了不少帖子，都没很好解决这问题，例如这些帖： 【2014-11-16】应对【宽带运营商】强插广告、对网页劫持，跳转，自动刷新，加小尾巴 mason的规则怎么写可以阻止电信的域名纠错跳转？ 我目前暂时方案是：用油猴脚本，一旦发现打开http://231.5.88.30:8080就自动关闭，索性眼不见为净 但是以上方案，仍不够完美。我有个设想，不知有没工具能实现： Firefox把network.http.redirection-limit设置为0，能「全局」禁用302/301跳转的。那假如有个工具，能「局部」禁用302/301跳转：设定x是广告网址，如果跳转目标是x，则重发http请求（一般运营商不会无限劫持，所以多次请求总能get到网页，不会死循环）。 ——这个方法，不就完美解决30X劫持问题了吗？有这样的工具吗？记得mason能编写脚本，但太久没用，不知道能不能做到？ |
|
|
1楼#
发布于：2016-11-03 22:09
这种通常都是用伪造包抢答的
解决方法 1、投诉 ISP 1.1、换 ISP 1.2、移民 2、抓包找特征，iptables 中直接丢包 3、出站请求拆包，但部分服务器会有异常反应。之前那个 mason 的帖子说到的 UA 设为空就是这招的极端体现 |
|
|
|
2楼#
发布于：2016-11-04 19:18
本地解决有点麻烦，推荐投诉
交了高额的带宽费，不该被当二等公民对待 投诉注意先找ISP，然后才能找工信部 流程参考https://www.zhihu.com/question/23197534#answer-4791654 |
|
|
|
3楼#
发布于：2016-11-06 12:24
反跳转到是可以实现，比如ublock，redirect control，在跳转请求前发出警告，或者用redirector重定向。但发现转向目标X，则自动重新发送请求就不知道mason能否实现，为了缩减addons列表，也很就没用了。
|
|
|
4楼#
发布于：2016-11-06 19:13
@aaaa007cn @白左 @skytalk
谢谢，我家网不是和运营商签的协议，签的是代理商。拦截是代理商做的，投诉较麻烦。而且是租房，属于爱用不用，不用搬家的类型。目前搬家又不现实… 改UA的副作用太大。而丢包和Redirector反跳转，和我现在用的方案（一旦跳转就自动关闭标签页）类似，都是只眼不见为净，不能无感知的重定向回正确网页。 可能自动重发包，这个需求太小众，没前人做吧，只能算了 |
|
|
5楼#
发布于：2016-11-06 22:06
我说的那些都是针对 ISP 的抢答劫持
比如丢包法，用户完全感知不到 ISP 劫持的存在 改 UA 确实是邪道，拆包比较合适 你这情况未必一样 因为不少转卖带宽的二手贩子会用透明代理来做劫持 这和 ISP 抢答完全不同 所以还是先抓个包分析下吧 话说 自动重发包是哪招？ |
|
|
|
6楼#
发布于：2016-11-07 01:26
aaaa007cn：我说的那些都是针对 ISP 的抢答劫持谢谢，一直思维惯性以为，30X流量拦截都是透明代理直接把用户请求包丢弃，伪造回应包。原来ISP竟然都用的抢答方式… 这个代理商确实用了透明代理，之前还限速，在我投诉下才取消。明天抓包看看… 自动重发包，就是客户端看到响应包是30X跳转到预设的网址时，就丢弃响应包，自动重发请求包……不论抢答还是透明代理，这种应对方案应该都能解决，用户都感知不到劫持的存在吧 |
|
|
7楼#
发布于：2016-11-07 09:51
每过一个网关都能劫持，你这种情况，从ISP，区域代理到出租房房东都有可能的
|
|
|
|
8楼#
发布于：2016-11-07 09:53
|
|
|
|
9楼#
发布于：2016-11-07 23:03
bootislands：谢谢，一直思维惯性以为，30X流量拦截都是透明代理直接把用户请求包丢弃，伪造回应包。原来ISP竟然都用的抢答方式…举个栗子 抢答式的 因为真正的数据包没有被拦截掉 浏览器和服务器之间通信是成功的 考虑到使用一次性 token 的场合 重发包肯定会导致出错 另外也有也有可能请求中包含时间 重发包可能会出错 另外 重发包可能导致浏览器等待响应的时间过长而导致请求超时的误判 浏览器中直接判断是否需要重新发起请求更准确 |
|
|
|
10楼#
发布于：2016-11-08 00:14
aaaa007cn：举个栗子是的，想来要把各种情况兼顾到，也挺麻烦。今天wireshark开了好半天，也没抓到，被拦截的时机不确定…想想算了，再折腾下去不合算…谢谢@aaaa007cn 兄和楼上众朋友 |
|
|
11楼#
发布于：2016-11-08 15:51
我以前写过个脚本，把电信302跳转的结果改为原始的URL，因为302到的地址是带原始URL的，截取就行
你这个经过转换的，要不把IP地址换成127.0.0.1的，至少能跳到出错页面，后退刷新下应该行吧？不会每次都给你302吧？ |
|
|
|
12楼#
发布于：2016-11-08 21:08
如果不准备投诉和用脚投票
那就得耐心 先总结出劫持规律 比如像是 * 每次重新拨号后必然/高几率发生 * 每若干小时后必然/高几率发生 * 某些网站必然/高几率发生 然后再开 wireshark 抓包 一直开着 wireshark 等劫持发生反而会让人很快失去耐心 |
|
|
|
13楼#
发布于：2017-07-11 12:33
|
|
