TL;DR：Surge 模块规则冲突不要靠肉眼猜。先关掉全部模块，只保留基础 profile；再按顺序逐个打开，每次只观察一个目标域名的 Rule、DNS、MITM 和 Script 变化。
Surge 的模块很好用，也容易叠太多。一个去广告模块、一个流媒体模块、一个 DNS 模块、一个自写规则补丁叠在一起，最后某个 App 打不开，日志里却只看到「命中规则」。这时真正要查的是：这条规则是从哪里来的，DNS 结果有没有被改，脚本有没有提前处理请求。
先做最小复现
建立一个临时排查表：
| 状态 | 模块 | 目标域名 | DNS 结果 | 命中规则 | 最终策略 |
|---|---|---|---|---|---|
| 基础 profile | 全关 | example.com | 记录原值 | 记录原值 | 记录原值 |
| 加模块 A | A | example.com | 对比变化 | 对比变化 | 对比变化 |
| 加模块 B | A+B | example.com | 对比变化 | 对比变化 | 对比变化 |
不要一次开回全部模块。只要某一步结果变化，就把那一步的模块内容打开看。很多冲突不是「规则写错」，而是模块新增了一条更靠前的规则，或改了 DNS 后让原规则不再命中。
模块顺序不是摆设
Surge 的模块会把内容合并到当前 profile。常见冲突有三类：
- 同名策略组被引用，但你的主配置里没有这个策略组。
- 模块追加了更具体的 DOMAIN 规则，覆盖了你后面预期命中的规则。
- 模块里的 DNS Rewrite 让域名解析结果变化，导致 IP-CIDR 或 GeoIP 规则接手。
遇到这类问题，先把模块下载到本地，查它到底改了哪些段落。只看模块名称很容易误判，因为很多模块同时包含 Rule、MITM、Script 和 DNS。
DNS 副作用最容易漏
DNS Rewrite 和 Rule 是两条线。你可能以为某个域名命中了代理策略，实际它已经被 DNS 改写到另一个地址，后续连接命中了完全不同的规则。
排查时打开 Surge 的最近请求，重点看：
- 请求的原始域名是什么。
- DNS 结果是否被 rewrite。
- 是否出现
REJECT、DIRECT或某个意外策略。 - 命中的规则来自主配置还是模块。
如果目标是 App 内请求，还要确认 MITM 是否开启。没有抓到域名，不代表没有请求；也可能是证书、HTTPS 解密范围或 App 自身连接方式导致日志不完整。
处理策略组命名问题
模块作者常用 PROXY、Proxy、Final、REJECT 这类策略名。你的主配置如果叫 🚀 Proxy 或 节点选择，模块规则引用的策略就可能不存在，或者被 Surge 自动映射到非预期位置。
最稳的做法是给常用模块保留一组固定别名。例如保留 PROXY、DIRECT、REJECT，再在自己的策略组里做二级选择。这样模块更新时不容易因为名字变化而失效。
使用配套订阅线路导入策略组后，也建议先把组名整理成稳定英文名，再叠加模块。排查时中文、符号和表情都可能增加对照成本。
不要同时改三件事
Surge 排障最怕同时更新订阅、更新模块、改 DNS。这样即使问题消失，也不知道是谁修好的。建议顺序是：固定订阅和策略组，先定位模块；模块稳定后，再处理 DNS；最后再恢复脚本和 MITM。
快速修复清单
- 关闭全部模块，确认基础 profile 正常。
- 按顺序逐个启用模块，每次只测一个目标。
- 查看最近请求，记录命中规则来源。
- 检查 DNS Rewrite、Script、MITM，不只看 Rule。
- 统一策略组命名，避免模块引用不存在的策略。
- 模块更新前保留上一版 URL 或本地副本。
最后把冲突模块单独留一份注释，写明它改了哪些段落。下次 Surge 或模块更新后，同类问题能直接对照，不用从头猜。