【镜像】使用mitmproxy作为局部科学上网的替代手段

Z时代
2024-01-10
分类：综合

背景

大家都说 Eclipse 有诸多镜像，但大家都没说的是 Eclipse 贼得很，刚开始下载文件还可能用你的镜像，后面就跳转到其他国外的龟速镜像源去了，令人发指。你修改 update sites 它就再弄回来一个给你看，非得你禁用了这个 update site 才行。由此可见，Eclipse 的镜像加速不是那么简单。教训这样不听话的小表弟的方法，就是顺其自然地引流。

Plan A - /etc/hosts

一开始的思路是用全局代理，修改 /etc/hosts，把 download.eclipse.org 引流到清华TUNA镜像，但是

/etc/hosts 不支持 download.eclipse.org 引流到 mirrors.tuna.tsinghua.edu.cn/eclipse

/etc/hosts 无法在请求失败后转回原地址请求，想象一下某个文件在 download.eclipse.org 上有而在 mirrors.tuna.tsinghua.edu.cn/eclipse 下没有镜像。当在下面和 Plan B 协同以增加重定向功能时又发现陷入了请求 download.eclipse.org 等于请求 localhost 的死循环（请求 download.eclipse.org -> mitm 代为请求 download.eclipse.org -> mitm 的代理请求被 /etc/hosts 理解为请求 mitm -> mitm 再次代为请求 download.eclipse.org -> mitm 的代理请求被 /etc/hosts 理解为请求 mitm）。直接重定向到 download.eclipse.org 的 IP 呢？又会转到 account.eclipse.org，而对于有些指向虚拟服务器的域名，如 www.yiban.cn （103.95.221.185），还会提示Unknown Virtual Host，即从访问地址无法判断你具体要访问这个IP对应的服务器的哪个虚拟子服务器，只有在输入准确域名后才能正确重定向。

Plan A 卒。

Plan B - node-mitmproxy

mitmproxy 原本是个黑客工具，示例项目也是为了说明其存在的安全隐患，但是 think differently（另辟蹊径），合理运用可以提高我们国外网站访问的体验。原理是拦截所有 download.eclipse.org 请求，由 mitmproxy 伪装成目标服务器，实际上更改目标服务器为镜像服务器，代为向真正服务器请求后返回镜像服务器返回的文件，之前用了自己修改过的 node-mitmproxy 在一定程度上真爽，然而

在 /releases/neon/ 这里总是不顺，总是提示 Cannot read repository at https://mirrors.tuna.tsinghua.edu.cn/eclipse/releases/neon.

自己修改的 node-mitmproxy 不支持流数据传输

更为成熟的 mitmproxy 呼之欲出，没错，就是这个 Python 版的 mitmproxy！

Plan C - py-mitmproxy

mitmproxy 官网

这是个 Python 开发的软件，试用了其网页交互模式mitmweb，发现确实能够截流，但是不能批量下载响应文件，只能一股脑打包保存到一个流文件中，对于镜像不利。但是现在就唱衰为时过早。真正的威力还是在于用mitmdump加载脚本。

入门教程

请求更改（重定向）

通过修改 flow.request.url 成功引流了 download.eclipse.org，在我们的收拾下变得服服帖帖，完成了初始目标。接下来，为了提供更多方面的加速，新的挑战等着我。

进阶 - Google Map

download.eclipse.org 的导流之所以如此简单还是在于其用的是 HTTP 协议，对于 HTTPS 协议，以我目前初学者的能力使用 mitmproxy 无法干涉。现在有个网页 Interactive Metabolic Pathways Map 使用了 Google Map 展示一张大图，其中 Google Map API 和 ajax.googleapis.com 在墙内都极难访问，而 google.cn 提供了 Google Map API 的镜像，中国科学技术大学提供了 ajax.googleapis.com 的镜像（ajax.lug.ustc.edu.cn）（参考博客）。仅仅用上面的配置无法干涉 HTTPS 的传输，修改 flow.request.url 的方法是无效的。

参考这篇博客，转变思路，目前使用的下下策是：我虽然无法干扰 HTTPS 本身的传输，但我可以在 html 文件中决定向谁请求 Google Map API 和 Google Ajax，通过修改 flow.response.text 可以间接达到这个目的。如此实施以后，Interactive Metabolic Pathways Map 的加载速度着实快了不少，在墙内也能够自如享用了。