Apple 的应用信息里写到，Shadowrocket 可以显示 HTTP、HTTPS、DNS 请求记录，支持 URL rewriting、HTTPS decryption、scripts 和本地 DNS mapping。也就是说，模块出问题时，开关颜色不够用，Recent Requests 才是定位入口。

退回基础规则的顺序

按以下顺序退回基础规则代理：

  1. 关闭全部 Module。
  2. 关闭 URL Rewrite。
  3. 关闭 HTTPS 解密。
  4. 保留 [Rule] 和订阅节点。
  5. 重新连接，打开同一个失败网页。

如果网页恢复，问题就在模块层。别急着删订阅或重装 App，这两步会把现场信息清掉，更难判断是哪条规则动了请求。

default.conf 里哪些字段最容易撞车？

Shadowrocket 官方 config 仓库的 default.conf 能看到这些段落和字段：

[General]
bypass-system = true
skip-proxy = ...
bypass-tun = ...
dns-server = 114.114.114.114,119.29.29.29,8.8.8.8

[Rule]
DOMAIN-SUFFIX,example.com,Proxy,force-remote-dns
GEOIP,CN,DIRECT,no-resolve
FINAL,Proxy

[URL Rewrite]
^http://example.com https://example.com 302

DNS 问题重点看 dns-server、force-remote-dns、no-resolve。Rewrite 问题重点看 [URL Rewrite] 里的正则是否命中过宽。

如果模块来自不同作者，一个模块改 DNS，另一个模块改 rewrite，网页白屏时很容易误判成订阅不可用。此时可以先把节点订阅和功能模块分开检查；需要重新导入节点时，再使用多格式测试订阅源承载基础连接测试，不要把订阅问题和模块问题混在同一轮排查里。

Recent Requests 要盯什么？

打开失败网页后，马上去 Recent Requests 找同一个域名。重点看这 4 类信号：

看到的情况指向问题下一步
请求被 302 到陌生 URLURL Rewrite 规则过宽关闭该 rewrite
证书提示HTTPS 解密作用到不该处理的域名收紧解密域名
DNS 请求走了异常服务器dns-server 或 force-remote-dns改回基础 DNS 测试
命中 REJECT模块注入了拒绝规则查模块规则段

不要一次启用多个模块。模块之间互相覆盖时，Recent Requests 只能看到最后结果，很难知道最早改请求的是谁。

模块恢复顺序怎么排？

恢复时按从低风险到高风险：

  1. 只恢复纯规则模块。
  2. 再恢复 DNS 相关模块。
  3. 再恢复 URL Rewrite。
  4. 最后恢复 HTTPS 解密。

每开 1 个模块，都刷新同一个页面，记录 Recent Requests 的变化。如果打开某个模块后立刻白屏，问题就足够清楚：停在这个模块，不要继续叠加第二个变量。

哪些域名不要拿来测 HTTPS 解密？

登录页、支付页、系统服务、银行类 App 都不适合拿来做第一轮测试，用一个普通 HTTPS 页面确认功能，再给具体域名加规则。

HTTPS 解密要安装和信任证书。证书链一旦出错，很多 App 会直接拒绝连接，看起来像代理故障，其实是证书校验失败。

修好后怎么确认不是偶然恢复？

用同一个域名做 2 轮确认：第一轮只开基础规则，第二轮只多开刚才定位出的模块。如果第二轮复现白屏、302 或证书提示，就能确认冲突来自该模块。

再换一个无关域名测试。只有特定域名异常，通常是 rewrite 或 HTTPS 解密范围过宽；多个域名都异常，再回头看 DNS 字段和全局规则。

相关阅读