内容纲要

🗂 本文目录:Surge 指南 >


Surge 提供两种进行 HTTP 重定向的实现方式:

  • 请求头修改:通过直接修改请求头内容实现,客户端程序对本次重定向无感知。为了保证重定向后的行为正确,URL 被修改后,Surge 会自动使用 URL 的主机名部分覆盖请求头的 Host 字段。脚本进行重定向时不会进行该行为。
  • 返回 302、307 响应:直接向 HTTP 连接返回一个状态码为 302 或 307 的完整 HTTP 响应,客户端需要支持 HTTP 重定向。

Surge 还可以通过 URL 拒绝某些请求。

这是一个新的区块,它在示例中是这样的:

[General]

[Rule]
FINAL,DIRECT

[URL Rewrite]
^http://www\.google\.cn http://www.google.com header
^http://yachen\.com https://yach.me 302
^http://ad\.com/ad\.png _ reject

重写规则由3部分组成:正则表达式、替换和类型。

Header 模式

Surge 会修改请求头,并在必要时将请求重定向到其他主机。客户端不会注意到这个重写动作。

请求头中的「Host」字段将被修改以匹配新的 URL。

[URL Rewrite]
^http://www\.google\.cn http://www.google.com header

不能重定向 HTTPS scheme 的 URL。而且也不能重定向 HTTPS 请求。

HTTP 302 模式

HTTP 302 模式会简单的返回一个 302 响应。当 HTTPS 解密对对应的主机并开启时,可以对 HTTPS 请求使用。

[URL Rewrite]
# Weibo Short URL
^http://t\.cn http://sinaurl.cn 302

比如新浪微博的短链接 t.cn 之前不知因为什么原因在一些地区经常被解析成 127.0.0.1 导致无法使用,但新浪微博的另一个短链接 sinaurl.cn 则完全正常。

这时候可以查询 t.cn 的正确服务器 IP 地址然后使用「本地 DNS 映射」功能。

这是一个解决办法,但是 t.cn 可能存在更换 IP 地址的情况但我们并不一定马上得知,所以也可以如上示例使用 URL Rewrite 的 302 响应,就会变成:

http://t.cn/RVWlDp8 => http://sinaurl.cn/RVWlDp8

HTTP 307 模式

HTTP 307 模式会简单的返回一个 307 响应。当 HTTPS 解密对对应的主机并开启时,可以对 HTTPS 请求使用。

307 的 Rewrite 规则写法与 302 类似,将 302 换成 307 即可。

Reject 模式

当 URL 匹配时拒绝请求,当 HTTPS 解密对对应对的主机开启时,可以对 HTTPS 请求使用。

[URL Rewrite]
^http://img61\.ddimg\.cn/upload_img - reject

然后访问这个图片地址:

可以看到,这个例子在之前讲述 URL-REGEX 类型规则的时候也用到过。

实际上,在 Surge 还没有推出模块功能之前,有些人会为了方便同步 Rewrite 的阻止规则,就使用 URL-REGEX 类型规则来替代 Rewrite 的阻止规则。

不过早期使用 URL-REGEX 类型规则也存在缺陷,在 Surge iOS 3.8.0 之前的版本,URL-REGEX 类型规则并不支持用于 MitM 连接,导致无法将其应用在需要 https 解密的内容上。