使用 nghttpx 搭建 HTTP/2 代理（转）

来自http://www.fanyue.info/2015/08/nghttpx-http2.html

使用 nghttpx 搭建 HTTP/2 代理 [转]

HTTP/1.1，定义于 1999 年，至今仍在流行。纵使人们试图在它上面添加各种黑科技，但它依然有各种各样的不足。终于，在 2015 年 5 月，HTTP/2 发布了。HTTP/2 基于 SPDY 而建，性能和特性较 HTTP/1.1 有了极大的提升，此外，虽然 HTTP/2 标准本身并没有强制 TLS 加密（HTTPS），但主流实现（Google Chrome, Mozilla Firefox）均要求 HTTP/2 被包裹在 TLS 中，因此，HTTP/2 + TLS（HTTPS）已是事实上的标准。

本文中，如无特殊说明，「HTTPS」指代「HTTP + TLS」，其中的 HTTP 可以是 HTTP/1.1, SPDY/3.1 或 HTTP/2；但由于几乎所有的 HTTP/2 实现全部要求 TLS，因此单说「HTTP/2」的话，一般指自带了 TLS 的 HTTP/2。

本文介绍使用 nghttpx 配合 Squid 搭建一个支持 HTTP/2 的 HTTPS 代理的方法。

nghttpx 本身并不是一个代理，它只是一个翻译器，因此如果我们需要一个支持 HTTP/2 的正向 HTTPS 代理，可以用一个 HTTP/1.1 的正向代理（如 Squid）和 nghttpx 接在一起实现。使用这样一个 HTTPS 代理，既可以享受 HTTP/2 对多连接的优化（提高客户端和代理服务器之间的连接流畅度），又可以享受外层 TLS 带来的加密和安全。且由于流量特征是 HTTPS，不仅额外开销小，而且在一些封锁严重的 ISP 里也能应用自如。（如封锁了 DTLS 流量的情况下，OpenConnect / AnyConnect 只能 TCP over TCP，效率很低）

一、需求

需求有两种，一种是客户端原生支持 HTTP/2 的，以下以 Chrome 为例：

+------------+    +------------+    +------------+    +------------+

|            |    |            |    |            |    |            |

|   Chrome   +----+  nghttpx   +----+   Squid    +----+  Internet  |

|            |    |            |    |            |    |            |

+------------+    +------------+    +------------+    +------------+

如图，nghttpx 与 Squid 部署于服务器上，客户端的 Chrome 与 nghttpx 用 HTTP/2 交流，nghttpx 将请求翻译成 HTTP/1.1 发给 Squid，最后 Squid 抓取了结果返回。

另一种是客户端只支持 HTTP/1.1 的，以下以 Pidgin 为例：

+------------+    +------------+    +------------+    +------------+    +------------+

|            |    |            |    |            |    |            |    |            |

|   Pidgin   +----+  nghttpx   +----+  nghttpx   +----+   Squid    +----+  Internet  |

|            |    |            |    |            |    |            |    |            |

+------------+    +------------+    +------------+    +------------+    +------------+

如图，Pidgin 将 HTTP/1.1 请求发给本机的 nghttpx，本机的 nghttpx 翻译成 HTTP/2 之后发给服务器上的 nghttpx。之后的过程和上一种相同。

二、工具

nghttp2 是一个很优秀的 HTTP/2 的 C 类实现。它的前身是 SPDY 库 spdylay，作者都是 Tatsuhiro Tsujikawa，同时他也是著名下载工具 Aria2 的作者。nghttp2 含有多个组件，其中的 nghttpx 程序，可以进行 HTTP/2 和 HTTP/1.1 之间的翻译，如果编译时链接了 spdylay，它也可以支持 SPDY/3.1。

如果你是 Arch Linux 用户，可以直接使用我维护的 aur/nghttp2 包，直接 yaourt -S nghttp2 即可，吃豆人会帮你照料好剩下的一切。

如果你是 Debian / Ubuntu 用户，请按照官方 README 完成编译操作，编译完成后在 contrib 目录里可以找到 Upstart 配置文件。注意：nghttp2 库默认是不带 SPDY/3.1 支持的，如果需要 SPDY 支持，请先编译 spdylay 再编译 nghttp2，后者会自动检测到 spdylay 的存在并链接。

如果你是 CentOS 用户，祝您今天有个好心情。

三、服务器配置

无论是哪种需求，服务器上都需要 nghttpx 和 Squid。

nghttpx

服务器上 nghttpx，前端接受的是来自客户端的 HTTP/2 请求，后端是 Squid，最小配置是这样：

frontend=0.0.0.0,443

backend=127.0.0.1,3128

private-key-file=/path/to/private/key

certificate-file=/path/to/certificate

http2-proxy=yes

其中私钥和证书必须是客户端认可的。你可以选择：

去 NameCheap 之类的网站上买一个商业证书，低至 $9 一年；
自己用 OpenSSL / GnuTLS 等工具签一个，然后在你的客户端里强制设置为信任；
如果你不愿意花钱也不愿意折腾 OpenSSL，那你可以尝试去找家免费的 CA 给你签一个。

需要说明的是，GFW 曾被报道会区分商业证书和野证书并对后者做定点清除。试图使用野证书的同学请将此因素考虑在内。

以上只是最小配置，我个人使用的配置还加上了以下内容，是我在 nghttpx 的文档中挑出来觉得比较有用的选项：

# 使用四个 worker，请根据自己服务器的 CPU 合理调整，太小性能差，太大机器挂

workers=4

# 开启客户端 TLS 认证

verify-client=yes

verify-client-cacert=/path/to/client/ca

# 不添加 X-Forwarded-For 头

add-x-forwarded-for=no

# 不添加 Via 头

no-via=yes

# 不查询 OCSP 服务器

no-ocsp=yes

# 指定 NPN / ALPN 的顺序

npn-list=spdy/3.1,h2

# 只使用 TLS 1.2

tls-proto-list=TLSv1.2

# 开启日志功能

accesslog-file=/var/log/nghttpx/access.log

accesslog-format=$remote_addr [$time_iso8601] "$request" $status $body_bytes_sent $alpn "$http_user_agent"

有关 --npn-list 选项：前文已经说明了，nghttp2 如其名字所示，是一个 HTTP/2 的库，但是由于 Chromium / Google Chrome 的一个bug（发稿时最新的 v45 仍未修复），Cr 对 HTTP/2 代理的支持有点问题（Firefox nightly 没有问题），而 nghttpx 默认的 NPN / ALPN 顺序是 h2 优先的，所以需要在这里把 spdy/3.1 的优先级调成最高，以便让 Cr 能用 SPDY/3.1 协商……

有关 --verify-client 功能：请看下文「有关鉴权」一节。

Squid

Squid 是一个久经考验的正向代理。在我们的用例中，它是 nghttpx 的后端，只需监听 localhost 即可。我用的最小配置如下：

http_port 127.0.0.1:3128

http_access allow localhost

# 关闭缓存功能和日志功能

cache deny all

access_log none

# 优先访问 IPv4 站点，有完整 IPv6 支持的机器可以去掉

dns_v4_first on

# 不添加 Via 头

via off

# 删除 X-Forwarded-For 头

forwarded_for delete

我曾试图让 nghttpx 把源 IP 地址发给 Squid 然后让 Squid 记到日志里，但是未能成功，于是 Squid 始终只能记到一堆来自 127.0.0.1 的请求，干脆就把 Squid 的日志关闭，让 nghttpx 去记日志了。

一个可能会让强迫症不爽的地方是，Squid 默认的错误页面会引用 Squid 官网的图片（一只乌贼），而这个图片资源是 http:// 的，因此页面会带有「混合内容」，强迫症用户可以通过编辑 errorpage.css 把这个去掉：

background: url('http://www.squid-cache.org/Artwork/SN.png') no-repeat left;

或者像我一样把这个图片换成 data:image/png;base64 嵌在 CSS 里……

有关鉴权

只按照最小配置来做的话，配置出来的 HTTP/2 代理是没有任何鉴权的，任何人都可以把这个地址填进 Chrome 里当代理用，也就是说，这是一个开放代理。但实践证明：

如果你在公网上搭一个不带 TLS 的 HTTP/1.1 开放代理的话，分分钟各种爬虫就会把你的地址撸走，教你做人；
如果你在公网上搭一个带 TLS 的 HTTP/1.1 开放代理的话，来光顾你的爬虫就非常非常少了，几个月也遇不到几只；
如果你在公网上搭一个只允许 TLS 1.2 的 HTTP/2 开放代理的话，根本不会有爬虫来光顾你……

所以，如果不想弄鉴权的话，问题也不大，因为目前根本没有 TLS 1.2 + HTTP/2 的爬虫，除非你主动把地址告诉别人，否则不会有人来用你的代理。不过，这样毕竟只是迷宫，而不是门锁，所以为了安全还是可以配置一下鉴权。

在这种 TLS 1.2 + HTTP/2 的结构下，鉴权可以在两个阶段做：TLS 和 HTTP/2（感觉是废话），也就是 nghttpx 和 Squid（好像还是废话）。

在 TLS 层面做鉴权的话，就是用上文所述的 --verify-client 了。你需要自己维护一个 CA，然后把 CA 的根证书放到服务器上，持有该 CA 根证书的私钥签出的证书对应的私钥的用户可以使用该代理，否则根本完成不了 TLS 握手，直接被拒绝。CA 的搭建和管理又是一个巨大的话题了，在此不多做叙述，只是推荐一下两个软件：适用于 GNU/Linux 用户的 XCA，和适用于 OS X 用户的 Keychain。这两个都是能够管理中小型 CA 的 GUI 程序。我个人使用的则是 EasyRSA。当然如果你足够硬核，也可以直接使用命令行的 OpenSSL 去管理 CA。再次强调，这个 CA 只是客户端认证所用的，和你买证书的那种商业 CA 没有也不应该有联系。

在 HTTP 层面做鉴权的话，请照着 Squid 官方文档做。

推荐用 TLS 鉴权，你会爱上它的。而且 TLS 鉴权的话，Chrome 能用 AutoSelectCertificateForUrls 策略自动选证书，不用每次开 Chrome 的时候点一下。

四、客户端配置

客户端配置分为两种。Chrome 和 Firefox 等直接支持 HTTP/2 代理的，直接填进去就行。大部分不支持的程序，需要在本地再起一个 nghttpx，翻译一下，在本地生成一个 HTTP/1.1 的代理，供程序使用。

无需翻译的程序

Chromium / Google Chrome 理论上支持 HTTPS 代理的，但是如上文所述，目前由于一个 bug 的存在，对 HTTP/2 代理的支持有问题，暂时只能用 SPDY/3.1；Firefox 曾经不能正常使用 HTTPS 代理（当年 Chrome 是唯一能使用 HTTPS 代理的浏览器），现在它的 nightly 版本反而是支持 HTTP/2 了而超越了 Cr……

令人郁闷的是，无论是 Cr 还是 Fx，它们都未提供直接配置的 GUI，只能通过命令行或插件的方式来使用 HTTPS 代理。比如这样一个 pac 文件便可以让 Cr 和 Fx 使用 HTTPS 代理了：

function FindProxyForURL(url, host) {

  return "HTTPS proxy.example.org:443";

}

当然，pac 文件可以写得非常复杂，也可以使用浏览器插件进行更灵活的代理配置。Cr 用户推荐使用 SwitchyOmega。

需要翻译的程序

如前文所述，目前除了 Cr 和 Fx，大部分软件是不支持 HTTP/2 的，而 nghttpx 是个 HTTP/1.1 和 HTTP/2 的翻译器，因此我们可以在本机起一个 nghttpx 生成一个 HTTP/1.1 的代理供不支持 HTTP/2 的程序使用。这种情况下，nghttpx 的前端接收 HTTP/1.1 的请求，然后翻译成 HTTP/2 发给服务器上的另一个 nghttpx 实例。最小配置如下：

frontend=127.0.0.1,8080

backend=proxy.example.org,443

client-proxy=yes

同样地，这只是最小配置，我个人使用的配置中还有以下选项：

# 认证用证书和私钥，如果你没用 TLS 认证则不需要

client-cert-file=/path/to/certificate

client-private-key-file=/path/to/private/key

# 四个 worker，请根据自己计算机/手机性能调整

workers=4

# 不添加 X-Forwarded-For 头

add-x-forwarded-for=no

# 不添加 Via 头

no-via=yes

# 不查询 OCSP

no-ocsp=yes

# NPN / ALPN 优先使用 h2

npn-list=h2

另外可能有用的选项是 -k。如果你用了野证书，这个选项让 nghttpx 放弃证书校验（不安全！），此外它在手机等慢速网络下也有缩短启次握手时间的效果。另外如果你想看实时请求情况的话，加上 -L INFO 能看到漂亮的彩色输出。这个 nghttpx 跑起来之后，别的程序设置 http://127.0.0.1:8080 为代理即可使用。

刚才提到了手机。是的，手机。Tatsuhiro Tsujikawa 大大的程序都是为 Android 交叉编译优化过的。（什么，您是 iOS 用户？您还是用您的 APN 代理，也就是 HTTP 明文代理吧……）

在 nghttp2 的文档中，提供了两种方便的交叉编译 Android 版 nghttpx 的方法，一种是自己装 Android NDK 和依赖，然后用android-config 和 android-make 脚本自动做。另一种是用 Dockerfile.android 文件，在 Docker 容器里装上乱七八糟的编译环境和依赖，最后产出珍贵的 nghttpx 文件并复制到容器外面来。编译完的二进制文件记得 strip 一下，能从 11 MiB 减到 2 MiB……

在 Android 上运行起 nghttpx 之后（可以用 JuiceSSH 之类的起一个，无需 root），推荐配合 Drony 使用（也无需 root），该应用使用VpnService() 捕获所有应用流量，然后再按照你定的规则（来源地址、应用名、目标主机名、目标端口号、HTTP 方法等），将这些流量进行分流（直连、截断、传给代理、交给 pac 处理等）。

五、尾声

我竟然已经整整一年没有写博客了。一年里可以写的东西其实不少，但是由于各种原因的确没怎么写。今天因某人提醒我一年没更新了，又正好手头的事情告一段落，于是便这么写了一篇。也算是能造福一些人吧。

最后，Google Chrome 使用 HTTP/2 代理看 YouTube 4k 效果如下：