Surge - 转发，代理和规则系统

本文整理自官方文档： 《Surge 官方中文指引：理解 Surge 原理 - 章节 4 转发，代理和规则系统》

本文旨在介绍清楚概念，所以只描述常用只要功能，更多细节请参考官方文档。

被 Surge 拦截的请求在处理完毕后将被转发。

如果 Surge 的出站模式设置为 直接连接 ，那么该请求将被 直接发往目标服务器 ；

如果出站模式设置为 全局代理 ，那么将 转发给指定的代理服务器 ；

当出站模式设置被设置为 规则判定 时，将 根据配置的规则决定转发策略 。

规则系统中有两个基本概念： 策略 和 规则

1、策略：描述了 Surge 进行转发的方式，有三种类别：

2、规则：规则由四个部分组成：类型、条件、策略和参数。当条件满足时，该规则匹配，使用该规则指定的策略。

内置策略由 Surge 提供，不随配置而变化：

由于操作系统对用户空间程序（user-space program）的 socket 并没有提供抛弃的操作，Surge 静默抛弃的实现方式是将该 socket 闲置一段时间后再关闭。

同时，如果发往某主机名的请求短时间内大量触发 REJECT/REJECT-TINYGIF 策略（当前版本的阈值为 30 秒内 10 次），为了避免产生大量资源浪费，Surge 将自动升级策略为 REJECT-DROP 策略。

代理策略由用户自己定义，每个策略描述了一个代理服务，当使用该策略时即为通过该代理服务转发请求。

一个简单的代理策略定义行如下：

其中，ProxyA 为策略名，供规则和策略组所使用。第一个参数为代理协议类型，目前 Surge 支持的代理协议类型有：

另外还有两个特殊类型：

第二个参数为代理服务器主机名，第三个参数为代理服务器端口号，后续为 key=value 的参数表，根据协议类型不同需要提供不同的参数。

这是一个特别的类型，严格来说并不是一个代理，用于强制使用某一个网卡进行请求。

external 类型策略可以让 Surge 与其他代理客户端（如：SSR、Brook）更方便的协同工作。

该功能 目前只能通过直接编辑配置 实现，策略定义行为：

其中 args 和 addresses 参数为选填，其他必填。args 和 addresses 字段可以反复使用进行追加。

当使用到该策略时 Surge 会进行以下工作：

（1）使用 exec 和 args 参数启动该外部程序，之后向 SOCKS5 127.0.0.1:[local-port] 转发请求。

（2）如果外部进程被终止，当再次使用该策略时会自动进行重启。

（3）Surge 会在启动增强模式时自动将 addresses 参数中的地址排除在 VIF 路由表外。（请在该字段填写使用的代理服务器 IP 地址）

（4）当由 Surge 启动的外部进程的请求被 Surge VIF 处理时，永远使用 DIRECT 策略。（为了应对像 obfs-local 这样的插件请求问题，外部进程的子进程也会被同样处理）

（5）Surge 退出时会自动关闭所有外部进程，增强模式关闭时会自动清理加入的路由表。

上述 3 和 4 的功能是有重叠的，请尽量使用 addresses 声明使用到的地址以排除 TUN 处理，这样可以减少系统开销，4 的功能是一重额外保护。

RULE-SET 规则集可以将 多个子规则 放在 一个单独的文件中 ，便于分享和复用。但是规则集中的规则 不可以指定策略 ，整个规则集指向一个同一个策略。

另外 Surge 自带了 SYSTEM 和 LAN 两个规则集，规则集包含的具体子规则会随 Surge 更新而有所调整。注意 LAN 规则集会触发 DNS 解析。

可通过 AND，OR，NOT 运算对所有规则类型进行组合使用。如

可以拦截 Chrome 发出的 UDP 数据包。

（完）

[toc]

基于原文截取修改：

原文链接： 让代理服务器支持HTTPS很难吗？

我们开展稳定高匿名HTTP代理业务以来，我听到客户咨询最多的问题之一就是“你们的代理支持HTTPS协议吗？”。我觉得很多人对HTTPS代理存在理解上的误区，所以我写了这篇文章。目的就是想说明“实现支持HTTPS的代理一点都不难！”。

说到HTTPS代理很多人瞬间就会联想到HTTPS的各种证书和各种加密，觉得很高端很复杂的样子。其实不然，代理服务器不需要配置证书、也不需要处理任何加密。因为HTTPS代理是通过Web隧道（Web tunnel）工作的。

Web隧道允许用户通过HTTP连接发送非HTTP流量（例如FTP，Telnet，SMTP），这就使得那些使用非HTTP协议的应用程序可以通过HTTP代理工作了。你现在应该就明白了为什么QQ可用设置使用HTTP代理工作。Web隧道这么强大，但它并不复杂。

Web隧道是用HTTP协议的CONNECT方法建立起来的。CONNECT方法不是HTTP/1.1核心规范的一部分，但确是一种得到广泛应用的扩展。客户端通过CONNECT方法请求代理服务器创建一条到达任意目的服务器和端口的TCP链接，代理服务器仅对客户端和服务器之间的后续数据进行盲转发（只是转发，不关心、也不懂发送的内容是什么）。

1） 客户端通过HTTP协议发送一条CONNECT方法的请求给代理服务器，告知代理服务器需要连接的主机和端口。

例如：

在本例中客户端通过CONNECT方法请求代理服务器打开一条到 www.alipay.com 主机443端口的TCP链接。

2） 代理服务器一旦建立了和目标主机（上例中的 www.alipay.com:443 ）TCP连接，就会回送一条HTTP 200 Connection Established应答给客户端。

例如：

3） 此时隧道就建立起来了。客户端通过该HTTP隧道发送的所有数据都会被代理服务器（通过之前建立起来的与目标主机的TCP连接)原封不动的转发给目标服务器。目标服务器发送的所有数据也会被代理服务器原封不动的转发给客户端。注意：是原封不动的转发，代理服务器并不需要知道内容的含义，也不会尝试去对内容进行解析。

PS：上面这张插图是我引用《HTTP权威指南》一书的，做了修改。

这下你应该明白了Web隧道的工作原理。所以对代理服务器来说只要其支持Web隧道就支持HTTPS协议（和其它非HTTP协议），与证书、加密没有任何直接的关系。从上面的过程可以看出，实现Web隧道并不难，只要代理服务器能够正确处理CONNECT请求，然后对数据进行盲转发即可。从难度上看这比标准的HTTP协议代理还要简单（标准HTTP协议代理需要对客户端和服务端双方的HTTP报文先进行解析，修改后再进行转发）。

我能说

哈哈，没写，你来

在nginx下起一个https服务器用作另一个http服务器的代理，配置文件为:

测试的时候，查看error日志发现报错，如下:

基本上全是connect failed的信息。去网上搜索一番，发现upstream中[::1]是ipv6的地址，linux下输入命令ip address 查看，确实本机开启了ipv6的地址

所以请求是转发到ipv6的http服务去了，当然会connect failed了。所以配置文件修改为

显示指明为ipv4地址

但是此时请求还是没被转发，到error日志和access日志查看，都没有什么消息。后来在chrome上面调试才发现请求都被chrome屏蔽了（因为网站证书不是受信任的证书，请求会被chrome默认屏蔽掉）

需要到chrome设置里配置一下

设置--->隐私设置和安全性--->不安全内容--->允许

然后刷新页面后，就可以正常访问网站了。

---