在 Windows 上用 x64 的 Python 运行 GoAgent

首先声明：本文适用于至少懂编程，并且爱折腾的人。不一定要很熟悉 Python，但至少应该入过门了。

GoAgent 自带 Python27 运行环境，不过因为本机上也安装了 Python 2.7 x64，所以希望能直接使用我安装的 64 位版本。总结下来，要点有：

• 无论你是否准备使用 x64 版 Python。GoAgent 与 Python 2.7.9 不兼容，应该安装 Python 2.7.8 版本。
• 要运行 GoAgent 还需要 gevent 和 pyOpenSSL。可以手动安装，也可以通过 pip 来安装。推荐后者因为省事。
• Python 2.7.8（无论是否 x64）及更早的版本，没有自带 pip。所以要去下载 get-pip.py，然后用 python 运行这个脚本安装 pip。
  ps: 用 get-pip.py 下载到的 pip.exe 的版本，比 Python 2.7.9 里面带的要新一些。所以就算有自带我也会换掉它。

另一个重点来了：
有些版本的 GoAgent 里面对于 crypt32.dll 的加载代码在 x64 的 Python 中有问题，需要修改。改成像这样就可以了：

crypt32 = ctypes.WinDLL(u'crypt32.dll')
crypt32_handle = crypt32._handle

释放的时候要这样：

ctypes.windll.kernel32.FreeLibrary.argtypes = [HMODULE]
ctypes.windll.kernel32.FreeLibrary(crypt32_handle)

在前面还要：

from ctypes.wintypes import *

否则 x64 下会报错，因为 HMODULE 和 long 的长度在 x64 下不一样了。

我用的 2.1.17 的 GoAgent 中，对于 crypt32.dll 的加载代码还位于 proxy.py 中。最新的 GoAgent 已经移到 proxylib.py 里面了。什么时候移的我没有去考察过。代码改法可能略有不同，不过思路应该是一样的。

折腾好以后。把本机上的 Python.exe 复制一份改名成 Python27.exe。接下来就可以把 GoAgent 自带的 Python27.* 给删掉啦。

GoAgent 证书问题一例

昨天准备在太太的电脑上用一下 GoAgent，结果发现很多网站都不能用。很奇怪的是，Twitter 页面能打开，但 CSS / JS 看起来基本上都不对。而在我自己的电脑（LAN 内部）上却是好的。所以很明显是 Local 而不是 Network 的问题。

看 GoAgent 控制台上的日志，问题似乎跟 SSL 的连接建立有关系。再把 Chrome 的「审查元素」功能打开，Console 里面一堆错误。随便挑了个页面试图打开，好了，这下清楚了，证书有问题。

看了看 GoAgent 的官方 Q & A，基本上只提到说证书需要导入。很多在网上问这类问题的人，得到的也是类似回答。但问题在于，证书的导入是没有问题的，重新导入也没有效果。而且并不是所有网站都不能通过 GoAgent 代理。

其实问题很简单：GoAgent 仿冒的证书被占用啦。
官方其实也提到过这个事情：

因为 GAE 平台限制，没法支持真正的 ssl 加密，goagent 只能通过伪造证书的方式做到代理 ssl 加密的网站，这个证书就是用来欺骗浏览器的。

GoAgent 实际上相当于一个「中间人」。当访问 HTTPS 站点时，就得采用 SSL 中间人攻击的类似方式，才能完成代理的工作。SSL 中间人攻击怎么弄？导入受信任的根证书，然后利用这个根证书签发的证书把内容拆开后重新组装、加密、封包，骗完甲方骗乙方，欺骗通讯双方。否则两端任何一方觉得这内容不对劲，SSL 传输就会失败。这其实也就是为什么必须要干掉 CNNIC 相关的根证书的原因。

所以，对于每一个 HTTPS 站点，GoAgent 都会生成一份用自己根证书签发的数字证书。看看 GoAgent 的 local 目录下，如果访问过 HTTPS 站点，则一定会有一个 certs 目录。这生成的证书，就放在这个 certs 目录下。其实一看这个目录里面都有些什么文件，就很明白了：

这次的问题在于，GoAgent 有不同的版本，其携带的根证书也是变化过的。至少我机器上随便打开 CertMgr 就见到了五个不同的版本：

如果升级的时候不把 certs 目录清空，就有可能会有部分站点对应的证书还是以前的老的、用旧的根证书签发出来的。GoAgent 客户端一看，噢，证书已经有了，就不再重新生成了。但 Chrome 觉得证书不对，于是 SSL 握手就被挡了。

解决办法很简单，每次升级 GoAgent 的时候，把 local/certs 目录删掉。或者干脆每次用新目录来升级好了。

自己给 iOS7 升级下载加速

通知出来了好几天了，今天准备给太太的手机升 iOS7。于是先把 iTunes 升到 11.1（下载速度还不错），然后连上手机。一检查，嗬，1.19G，告诉我下载要 18 个小时。
按照惯例，打开 IE 设上代理，准备用 GoAgent 加速。现在估计用时只要不到一个小时，完全可以接受。
但是担心的事情来了，免费 GAE 的每个 AppID 有 1GB / 天的流量限制，而我的 GoAgent 没能及时切换到下一个可用的 AppID，结果 iTunes 这边报了个错，然后下载又重新开始了。没想到这 iOS 升级包的下载居然不支持断点续传。我又试了下，哪怕是手动点「暂停」，也没法进行续传，每次下载都会重头开始。看来这乔布斯死了之后，苹果真是要没落了。

接下来的时间，我考虑了以下解决方案：
1. 开 VPN：可手头上的 VPN 速度都跟直接下载差不多。何况有些 VPN 还有流量限制。不肯花钱的后果就出来了。
2. 找代理：手头上没现成的。不管是去搜 Google 还是开 ProxyHunter 都得花时间。懒得去找了。
3. SSH Tunnel：目前手头上访问起来快一点的只有台 H3C 的交换机，大概是深圳的地址。不过 SSH 没开，要想架隧道还得要我去帮它开。由于担心被抓去集中营活摘器官，并且从这台交换机到 appldnld.apple.com 的 ping 值并不好，所以最后还是放弃了。

最终，还是自己找了组 appldnld.apple.com 比较快的地址，解决了这个问题。100ms 左右的 ping 值，偶尔丢包。放在 hosts 里用上去之后，显示的估计用时也是不到一小时，跟开 GoAgent 加速的效果相当。那就先这样用吧。话说这苹果的 DNS 设置咋自己就解析不到这组地址上去呢？是我 RP 问题？

让 GoAgent 直接使用自己指定的 Google 服务器 IP 地址

一直很疑惑，为什么 proxy.ini 中把 [google_cn] 下面的 hosts 改成了自定义的 IP 地址，但日志中显示 GoAgent 客户端还在寻找其它的 Google 服务器 IP，并试图作为 GAE 代理进行连接。

因为一直都算还能用，所以就没下决心来解决这个问题（发现自己真的很懒）。但最近 GoAgent 客户端自己找到的IP越来越不靠谱，有时候甚至会导致一半左右的请求都会被重试，实在是太浪费时间了。而且第一次使用的时候 DNS 解析导致的等待也让人很不爽。所以终于决定来看看到底是怎么回事。

一看代码就明白了，问题很简单：GoAgent 客户端针对 [google_cn] 这个 Section 有特殊行为。它会去从 www.google.cn 和 www.g.cn 这两个域名进行解析得到 IP（好像会无视 proxy.ini 中自己设的地址或 IP），然后进行建立 SSL 连接的测试，根据测试情况决定是否切换到 [google_hk]（这又是一个特殊行为）。

这种做法，对于初级用户可能会比较适合。但如果想自己控制 GoAgent 客户端使用哪个 Google 服务器 IP，最好是另外开一个 Section，比如 [google_cn2] 或 [google_us] 之类。这样就不会碰到代码里面预设的这些特殊行为了。

PS: 以上内容基于 GoAgent 2.1.11 / 2.1.15 测试。

修改 GoAgent 客户端以支持 Mega

为了能用来访问 Mega，对 GoAgent 客户端代码做了略微的修改。不过首先要说明一下为什么会有这个修改。

Mega 是个总部位于 New Zealand 的网盘服务。服务器当然全世界都有，但至少在我这边 ping 值不好。严重的时候 600ms 以上，并且丢包。这样的话，不管本地有多少带宽，实际上也是不可用的。总不可能花上一整天的工夫来传一个 ISO 吧。
开着 VPN 会快，但流量和费用都是问题。于是很自然地想到了是否可以通过 GoAgent 之类的 GAE 代理来访问。Google 服务器与 Mega 之间的带宽应该是不成问题的，而 Google 服务器与我之间的速度也是我可以在一定程度上控制的。不过测试下来发现 GoAgent 不支持 OPTIONS 这种 HTTP Method，而且这个局限性是 GAE 导致的。GAE 只支持GET / POST / HEAD / POST / DELETE 这五种 HTTP Method。偏偏 Mega 在登录和上传下载的时候都会发 OPTIONS 请求，于是这个方案一度被搁置了。
后来 Mega 的速度进一步下降，有时候一整天都传不完一个 100M 的文件。于是这个方案又被我拿出来考虑。这次我准备绕开服务端的限制，直接从客户端下手。OPTIONS 请求涉及的数据量是很小的，文件传输用到的 CONNECT 之类才是主要的带宽压力。因此可以让客户端在遇到 GAE 服务器无法处理的 HTTP 请求时，直接将其发到目标服务器。由于 Mega 目前还没有被 GFW 给 IP 黑洞，因此应该可以在一种「混合模式」下被通过 GoAgent 访问到。

下面介绍一下修改方法，以 GoAgent 2.1.15 版（2.1.17 还需要服务端改动才行）为例：

首先在 local/proxy.py 中找到这两行：
"""rules match algorithm, need_forward= True or False"""
need_forward = False
第一行是注释。而下面这个 need_forward，就是用来控制是否把一个请求直接送出（FWD），而不是送去 GAE 服务器进行中转。

在后面的 if 语句前，加入这样的内容：
if self.method != 'GET' and self.method != 'POST' and self.method != 'HEAD' and self.method != 'PUT' and self.method != 'DELETE':
    if host not in http.dns:
        http.dns[host] = list(set(http.dns_resolve(host)))
    need_forward = True
非 Python 程序员也应该很容易读懂这段代码，不过要提醒一下：Python 中缩进是很关键的，改代码时一定要用空格正确地缩进。
最后，别忘了把下面那个原来的 if 改成 elif。

这样改过之后的 GoAgent 客户端，在遇到 GAE 服务端不能处理的那些 HTTP 请求类型时，就会把它们直接发到目标服务器上。
从理论上讲，这个小修改不会对 GoAgent 的翻墙能力有任何的增加，但可以让它具有更大的适用范围。一些原来不能用 GoAgent 访问的站点（比如上面提到的 Mega），现在可以用它来访问了。GAE 的流量按天计算（VPN 一般按月，VPS 也是）。并且因为可以使用多个 GAE 账号，因此流量基本上是免费且无限的。Mega 那 50GB 的大空间，终于具有一定的可用性了。