Shadowrocket 规则与配置参考

01 · 配置文件结构与编辑边界

先分清 Subscribe 与 Config

Subscribe 通常用于更新服务器列表，Config 用于管理连接行为与请求分流；两者可以分别来自不同的已有来源。服务器列表里能选中一个节点，只说明连接参数已进入客户端，不代表某份规则已经启用。相反，导入了一份内容完整的配置，也不意味着其中引用的代理出口就一定可用。开始编辑前，应分别确认 Home 中的服务器选择、Config 中正在使用的文件，以及 Global Routing 的当前姿态，避免把三个不同状态当成同一个开关。

配置文件按方括号中的段名划分职责。General 放全局连接与解析设置，Rule 放依次匹配的分流规则，Host 放指定主机名的解析映射，URL Rewrite 放符合条件的请求地址改写。段名不是普通说明文字，不能将中文标题写进方括号代替它们。同一个文件内的配置项要放在对应段下；例如 FINAL 是 Rule 中的规则，不能接在 General 的设置后面而省略段落标记，否则解析结果就可能与预期不同。

# 结构示例：只展示段落职责
[General]
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

[Host]
intranet.example.com = 192.0.2.10

[URL Rewrite]
^http://example\.com/(.*) https://example.com/$1 302

用副本建立可回退的修改过程

上面的片段不是适用于所有网络的完整成品。尤其是 Host 映射使用了文档专用地址，实际运行时应删除该演示条目，或替换为用户确实管理的内部地址。编辑现有文件时，先保存一份能正常工作的副本，记录所选文件名称与模式，再另存一个测试文件。每次只调整一种行为，例如先增加一条 DOMAIN 规则，确认命中后再调整 DNS。一次同时修改四个段落，即使页面恢复，也无法判断究竟是哪一项产生了作用。

纯文本配置使用英文标点。等号、逗号与方括号不能换成全角字符；从排版文档复制时尤其要检查自动替换的引号和不可见空格。整行注释可用井号起头，说明文字最好独立成行，不要把较长中文解释直接接在规则策略之后。文件后缀本身不能证明内容有效，将任意文本改成 .conf 也不会补齐语法。保存以后应回到 Config 检查文件是否可以正常载入，并确认选中的是刚刚修改的副本。

本地编辑与远程更新的关系

远程配置可能在再次更新时覆盖本地内容。需要长期保留的个性化规则，应先弄清当前文件是否受远程更新管理，再选择本地副本或应用实际提供的编辑方式。不要依赖“刚刚保存过”判断修改已经持久化；更可靠的方法是重新打开文件，检查目标规则仍在预期位置，并在更新后再做一次验证。订阅链接可能带有访问凭据，不应写入公开笔记或故障截图；向他人描述问题时，保留规则类型与错误现象即可。

当文件包含本页未列出的段落或字段时，不要为了对齐示例而整段删除。已有配置可能还承担本地网络、解析或特定请求处理职责。先读懂对应字段，再决定是否保留；不确定时回到原始副本测试。查阅本页的顺序是先确认段落职责，再查具体规则，最后核对策略与匹配顺序。这个顺序能把“语法能载入”和“实际行为正确”分开检查，避免仅凭文件外观完整就认定配置可用。

02 · General、DNS 与连接前提

全局设置不代替分流规则

General 中的项目影响连接与解析的基础行为，而 Rule 决定符合条件的请求使用哪种策略。两者相关，但不能互相替代。例如修改 DNS 服务器，可能改变目标域名得到的地址，却不会把一条明确的 DOMAIN 规则从 PROXY 改成 DIRECT；修改 Rule 也不能修复一个拼写错误的服务器地址。排查时应将目标域名解析、目标请求分流、代理服务器连接分成三件事，逐项验证，不要把所有无法打开的情况归结为“规则不好用”。

[General]
# 使用当前系统提供的 DNS
dns-server = system

[Rule]
DOMAIN,example.com,PROXY
FINAL,DIRECT

这段配置表示优先按完整域名将 example.com 交给 PROXY，其余未匹配请求交给 DIRECT。dns-server 的 system 值表示使用系统提供的解析设置，并不保证当前网络一定能正确解析所有域名。若切换网络后行为改变，应先检查系统网络与解析条件，再考虑应用设置。不要直接复制陌生配置中的多个 DNS 地址；解析服务的可达性、响应结果与当前网络适配情况都需要验证，条目更多并不等于查询更可靠。

域名规则与 IP 规则看到的内容不同

DOMAIN 与 DOMAIN-SUFFIX 判断主机名，IP-CIDR 与 GEOIP 判断地址。当请求保留域名信息时，前面的域名规则可以先决定出口；当规则需要地址而当前只有域名时，则可能发生解析。解析得到的地址也可能随网络、缓存与服务端调度变化，所以同一个域名并不保证每次命中同一条地址范围规则。诊断记录中要同时看请求域名与实际目标地址，不能只把浏览器地址栏当成完整的连接信息。

对 IP-CIDR 使用 no-resolve 的意义，是避免为了这条地址规则主动做域名解析；它不是“整个客户端不使用 DNS”，也不表示所有域名都将被忽略。请求如果已经带有可用于判断的地址，仍可能匹配相应网段；如果只有域名而没有适合的地址，则应继续考虑后续规则。是否添加此参数取决于希望规则在哪一阶段参与判断，而不是把它当作所有 IP 规则都必须附带的性能开关。

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
FINAL,PROXY

IPv6、局域网与缓存的边界

IPv4 网段规则不会自动覆盖 IPv6 地址。若网络与目标服务使用 IPv6，应检查是否需要相应的 IP-CIDR6 规则，并确认现有连接设置允许怎样的地址路径。单纯关闭某种地址族可能暂时改变症状，但无法说明问题根源已经解决。局域网设备也不一定都能通过主机名访问：有的依赖本地发现，有的依赖固定地址，还有的服务监听端口不同。先核对目标设备是否在同一网络，再判断分流是否相关。

解析缓存与已建立连接会让测试结果滞后。修改 DNS 或 Host 以后，浏览器可能继续复用原连接；这时应重新发起请求，必要时重新连接，再观察新的诊断记录。不要因为旧页面没有立即变化就连续叠加设置。对于已有配置中的 ipv6、bypass-system 等项目，应结合应用内说明理解作用范围，不要仅按字段名猜测。尤其是系统服务或本地网络的处理，可能还受操作系统自身路径影响。

遇到“域名打不开、直接用地址却可达”，不能立即判定应写 Host。许多服务依赖正确的 Host 请求头、TLS 证书名称与服务端路由，用地址访问本来就可能失败。应分别记录解析是否成功、连接是否建立、证书是否通过，再决定下一步。更多现象可对照FAQ 中的规则与故障排查。保留原有可用配置，只在测试副本中更改解析项，是避免网络恢复后留下隐性错误的基本做法。

03 · Rule 类型与参数含义

一行规则先写条件，再写策略

多数常用规则以“类型、匹配内容、策略”的顺序书写，字段之间使用英文逗号。类型决定后面内容的解释方式：同样的 example.com，放在 DOMAIN 后表示完整域名，放在 DOMAIN-SUFFIX 后表示域名后缀。策略决定命中后的处理方式，不属于匹配条件。FINAL 是特殊的兜底规则，不需要域名或地址参数，因此写成 FINAL,PROXY；若机械地补入第三个字段，反而会破坏原本清晰的含义。

三种域名规则怎样选择

DOMAIN,api.example.com,PROXY 只针对 api.example.com，不自动覆盖 www.example.com，也不覆盖 example.com。需要同一站点的根域与子域都采用一种策略时，DOMAIN-SUFFIX,example.com,PROXY 更合适。后缀匹配按域名层级边界判断，不能把它理解为任意结尾字符串搜索。填写匹配内容时不要附带 https://、端口、路径或查询参数；这些不是域名的一部分，放进去通常不会得到希望的命中效果。

DOMAIN-KEYWORD,example,PROXY 则判断域名中是否出现 example。它可能包含并不属于 example.com 的其他主机名，因此不适合仅凭品牌片段就做整站分流。优先使用边界清楚的 DOMAIN 或 DOMAIN-SUFFIX，只有确实需要字符串条件时才使用 DOMAIN-KEYWORD。关键词 ads 也不等同于精确广告列表，可能匹配正常业务域名；若用于 REJECT，应先核对实际请求，避免把正常内容一起拦截。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
DOMAIN-KEYWORD,tracking,REJECT
GEOIP,CN,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
USER-AGENT,ExampleClient*,PROXY
FINAL,PROXY

地址、地区与请求头规则的局限

GEOIP,CN,DIRECT 根据目标 IP 的地区归类决定策略，不是根据网页语言、网站公司所在地或域名后缀判断。使用内容分发网络的站点可能得到不同地区的地址，地址库也有更新与识别边界。对于必须稳定指定出口的域名，应使用明确的域名规则并放在 GEOIP 之前。IP-CIDR 的斜杠后数字表示前缀长度，数值越大通常覆盖范围越小；单个 IPv4 地址可用 /32，不能把主机端口接在地址后面充当网段。

USER-AGENT 针对能够读取的请求头内容，不是“选择某个 App”的通用机制。加密流量中的请求头通常无法直接读取，不能期待一条 USER-AGENT 规则覆盖所有 HTTPS 请求；也不应为了这条规则随意扩大解密范围。示例中的星号表示匹配模式的一部分，ExampleClient 是演示标识，不对应真实应用。多个应用还可能共享相同的请求头，或者同一应用在不同请求中使用不同值，因此它不能替代对真实目标域名的观察。

规则表应围绕实际需求保持简洁。只有一个完整主机名需要改走代理时，没有必要先添加宽泛的关键词、整个地区和大网段；反过来，控制一个站点的全部子域时，也不必手工枚举所有当前看到的主机名。先用最小条件复现预期行为，再决定是否扩大范围。对不熟悉的关键字，可结合术语手册查阅，但最后仍应通过当前请求是否命中来判断，而不是仅凭规则名称推断有效。

04 · PROXY、DIRECT、REJECT 与模式

规则策略与 Global Routing 是两层选择

PROXY 表示将命中的请求交给当前代理出口，DIRECT 表示直接连接目标，REJECT 表示拒绝该请求。这三种策略并不分别对应三份服务器参数，也不意味着配置会自动创建一个叫 PROXY 的节点。使用 PROXY 之前，应确保用户已有的服务器信息已正确导入，并在 Home 中选择合适出口。若当前文件还使用自定义策略组名称，就要核对该名称在配置中有定义、拼写一致，并且组内存在有效的可选出口。

配置姿态 Config 才是验证 Rule 分流的主要环境。代理姿态 Proxy 与直连姿态 Direct 可以帮助对照连接路径，但不能用来证明某条 Rule 的顺序正确。操作系统服务、局域网和应用实际设置还可能存在特定处理边界，不应把模式名称理解成对设备所有流量的无限覆盖。切换姿态进行测试时，记录原来的设置；测试结束后恢复 Config，再用新请求确认规则行为，防止忘记恢复导致后续判断全部偏离。

DIRECT 不是“停用客户端”

一条 DIRECT 规则表示目标请求采用直接连接策略，而不是关闭 Shadowrocket，也不是让配置文件剩余内容全部失效。客户端仍可能处理其他请求、执行解析或记录诊断信息。对于局域网地址、内部服务或本来直接访问正常的域名，可以设置更具体的 DIRECT 条件。直接连接是否成功仍取决于当前网络的路由、防火墙和目标服务，不能把 DIRECT 当作能够绕过所有连接限制的修复选项。

[Rule]
DOMAIN,intranet.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,blocked.example.org,REJECT
FINAL,DIRECT

这个片段将 intranet.example.com 作为后缀规则之前的例外，因此它直接连接，而 example.com 的其他主机名仍可能走 PROXY。blocked.example.org 则被明确拒绝。末行 FINAL,DIRECT 表示剩余请求直连，不代表前面已命中的请求还会重新回到末行。阅读配置时应把每一行看作独立判断，先读条件，再看策略，最后结合它在文件中的位置理解实际覆盖范围。

REJECT 的影响与连接失败的区别

REJECT 是主动拒绝，不等于“代理失败时自动改走直连”。一旦规则有意拒绝了目标，页面出现空白、资源加载不全或应用提示网络错误，都可能是预期结果。使用前应确认目标确实可以被拦截，且不承担登录、图片或接口等其他功能。若删除一条 REJECT 后页面恢复，应继续缩小匹配条件，而不是立即认定网站所有请求都必须走代理。关键词匹配越宽，越容易产生这种连带影响。

PROXY 路径失败时，也不要马上把 FINAL 改成 DIRECT。失败可能发生在服务器地址解析、端口连接、协议认证或目标访问的不同阶段；更改兜底策略会同时影响所有未匹配请求，反而掩盖原来的问题。先用 Connectivity Test 或一次明确的目标请求确认当前出口是否可用，再核对用户已有参数。连接测试结果与特定网站的可达性不是一回事，不能仅凭一个测试通过就断定所有目标请求都会成功。

On Demand 解决的是何时建立或恢复连接，而不是命中哪个域名；它与 Global Routing、Rule 的职责不同。若连接没有建立，优先检查连接状态与按需条件；若连接已经建立但出口不符合预期，再检查分流。自定义策略组还可能引入额外选择，因此诊断时要沿“当前姿态—命中规则—所指策略—实际出口”的顺序核对。更详细的模式说明见代理模式，不要通过反复开关连接代替对策略链的检查。

05 · 匹配顺序、优先级与兜底

先命中者生效，不按规则名称自动排序

Rule 中常用规则按文件顺序从上到下判断，前面已经命中的请求通常不会继续等待后面更具体的规则。DOMAIN 并不会因为“看起来更精确”而自动获得高于 DOMAIN-SUFFIX 的优先级，IP-CIDR 也不会天然压过 GEOIP。优先级首先体现在位置上。组织规则时，应把明确的例外放前面，再放一般范围，最后安排兜底。这样既容易读，也能减少后来添加规则时产生的覆盖冲突。

[Rule]
# 特定主机先作为例外
DOMAIN,api.example.com,DIRECT
# 其余同站请求采用代理
DOMAIN-SUFFIX,example.com,PROXY
# 未匹配请求直连
FINAL,DIRECT

这个顺序中，api.example.com 在第一行就得到 DIRECT；www.example.com 不满足第一行，但可以匹配第二行而采用 PROXY。若交换前两行，api.example.com 会先落入后缀范围，原本的直连例外就难以生效。测试规则优先级时，应专门选择一个同时满足两条条件的目标，这样才能证明顺序确实产生了差异；只访问彼此不重叠的两个域名，无法验证覆盖关系。

FINAL 不是可继续向后穿透的普通条件

FINAL 处理前面所有规则都没有匹配的请求，通常应作为 Rule 的最后一条。将它放在中间，会使后面的常规规则失去处理剩余请求的机会；在文件末尾追加新规则时，尤其要检查它是不是被写到了 FINAL 之后。多写几条 FINAL 也不会形成按场景自动切换的兜底方案。若需要不同范围使用不同策略，应先明确这些范围的条件，而不是通过重复兜底来表达模糊需求。

[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

在这个片段里，域名例外先于地址归类，因此即使 example.com 解析到某个可能命中 GEOIP 的地址，已在前面匹配的请求仍按域名规则处理。若请求没有可用于域名匹配的信息，则需要继续看地址条件。不要把这种差异理解为规则随机失效；规则能看到什么，与请求进入处理流程时携带的信息有关。诊断时同时保存主机名、目标地址、命中行与最终策略，才能区分顺序问题和识别条件问题。

重复、包含与远程内容的覆盖

重复规则不一定导致语法错误，却会增加维护负担。同一个 DOMAIN-SUFFIX 在前面写 PROXY、后面写 DIRECT 时，后者通常无法实现想象中的覆盖。维护前可先搜索相同域名，检查是否已经存在更宽的后缀或关键词；再检查是否有更早的地址规则命中。删除重复项前要保留原始副本，并确认其中没有必要的例外。整理的目标是让每条规则的作用可解释，而不是单纯追求行数更少。

如果现有配置还引用外部规则内容，主文件中引用项的位置同样值得检查。不能只看外部列表里写了什么，还要看这段内容何时参与判断、由哪种策略处理，以及更新后范围是否改变。对尚未理解的引用，不要根据名称直接判断“应该更优先”。本页的独立片段适合先在本地测试副本中验证基本条件，再回到现有复杂配置中逐项对照，不建议把片段直接插入未知层级而省略检查。

最有效的顺序测试只需要很少的规则：一条例外、一条范围规则和一条 FINAL。确认三者行为后，再逐批恢复其他条目。每批增加后都访问同一组测试目标，并使用新连接查看记录；这样可以准确定位是哪一批引入了覆盖。若只有切换到 Proxy 才能访问，而 Config 不行，优先核对命中策略，不要先重装应用。关于仅指定部分网站的完整场景，可继续阅读DOMAIN-SUFFIX 规则写法。

06 · Host 与 URL Rewrite 的边界

Host 改变解析映射，不直接选择出口

Host 段用于指定主机名对应的地址。它回答“这个名称解析到哪里”，而不是“连接使用什么策略”。例如内部服务需要固定到用户管理的地址，可以在 Host 写入明确映射，同时在 Rule 中根据需求选择 DIRECT。两段职责应分别理解：仅有 Host 映射不会自动保证请求直连，仅有 DIRECT 也不会替用户补齐正确的内部解析。映射地址必须真实属于预期服务，否则后续规则再精确也只会连接到错误目标。

[Host]
intranet.example.com = 192.0.2.10

[Rule]
DOMAIN,intranet.example.com,DIRECT
FINAL,PROXY

192.0.2.10 是文档专用地址，这段内容只用于解释语法，不能直接当作内部服务投入使用。实际填写前，应向用户自己的网络管理员或服务配置记录核对地址与端口。若服务地址会随网络变化，固定 Host 可能让访问在某一网络成功、换网后失败；若服务使用多个地址做调度，固定单一地址也可能破坏故障切换。不要用长期静态映射代替对异常解析的排查，更不要从陌生笔记中复制某个网站的旧地址。

映射不会替换 TLS 名称与服务器配置

使用域名访问 HTTPS 时，连接地址与证书验证的名称不是同一个概念。Host 可以改变去往哪个地址，但服务端仍应为该域名提供合适证书与响应内容。映射以后出现证书错误，不能通过忽略验证来认定配置正确；应先核对目标服务是否确实支持这个域名，以及服务端的站点绑定是否正确。相同地址上可能托管多个站点，单纯知道地址可连接，不足以证明这个域名会返回所需内容。

Host 修改后的测试也受缓存与连接复用影响。先保存文件、确认选中，再产生新请求；必要时关闭旧页面后重开，并对照实际目标地址。若只有某个应用不变化，还要考虑它是否使用自己的解析或直接访问地址。不能因为其他应用已受映射影响，就推断设备上每一个请求都会采用同样路径。维护时给每条静态映射记录用途与来源，服务迁移后及时核对，可以减少“规则没改却突然失效”的情况。

URL Rewrite 按地址模式处理请求

URL Rewrite 是对可识别请求地址的改写，不是服务器列表更新，也不是域名分流的别名。常见形式由匹配表达式、替换地址与动作组成。下面使用重定向动作，将示例站点的 HTTP 地址导向 HTTPS，捕获组保留原路径。正则中的点号需要转义，起始锚点用于限制开头；否则一个看似简单的表达式也可能匹配到不相关地址。正式使用前应逐条列出应匹配与不应匹配的样例，避免只用一个成功案例验证。

[URL Rewrite]
^http://example\.com/(.*) https://example.com/$1 302

这里的 $1 引用前面括号捕获的内容，302 表示让客户端继续访问替换后的地址。目标站点仍需实际提供 HTTPS 服务；规则本身不能为服务器添加证书或创建页面。重定向还可能改变后续请求的主机名，从而触发另一条 Rule，因此看到最终出口变化时，要检查请求是否已经换了目标。若替换地址又匹配原表达式，或服务端反向跳回旧地址，还可能形成循环，应立即停用该条并检查完整跳转链。

HTTPS 请求中的路径与请求头通常位于加密内容中，并非所有 URL Rewrite 都能直接处理；涉及解密时还存在证书信任、限定主机与应用兼容边界。本页不要求开启解密来完成规则分流，也不建议为了测试一个简单条件扩大处理范围。能用域名规则解决的出口需求，应优先放在 Rule。Host、Rule 与 URL Rewrite 各自解决不同问题，组合使用时按解析、策略、改写后的新请求分别验证，避免把一次成功跳转当成全部配置都正确。

07 · 常见规则写法与调整方法

只让指定网站走 PROXY

当需求是少数指定网站走代理、其他目标直接连接时，可以采用“明确域名条件加 FINAL,DIRECT”的结构。先从一个可确认的目标开始，不要立刻导入大量未经检查的关键词。下面把 example.com 及其子域放入代理范围，再单独保留内部主机直连。运行之前应替换为用户真实需要管理的域名，并确认当前代理服务器可用；示例域名只展示匹配关系，不代表访问它能够测试真实服务。

[Rule]
DOMAIN,intranet.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

实际网站往往不只使用地址栏中的一个域名，还会请求独立的登录接口、静态资源或文件服务。页面文字能出现但图片不加载时，应观察缺失资源的真实请求，而不是直接把所有流量改成 PROXY。只有确认资源属于需要调整的范围后，才增加相应 DOMAIN 或 DOMAIN-SUFFIX。若资源域名由多个服务共用，过宽的后缀可能影响其他网站；这种情况下，完整主机名规则通常更容易控制影响范围。

明确例外，其余请求交给 PROXY

另一种常见需求是为内部服务、局域网地址或特定地区地址设置 DIRECT，其余请求使用代理。此时 FINAL,PROXY 只是兜底，不代表所有请求从第一行就走代理。应把已知例外放在它之前，并按业务精确度安排域名与地址条件。对于确实需要代理的具体域名，可以放在地区规则之前，防止它因地址归类而落入 DIRECT。地区归类不能替代对关键业务的明确说明。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,intranet.example.org,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

这份示例仅列出部分内部地址范围，不是所有本地网络情形的穷尽清单。家庭设备、办公网络或虚拟网络可能采用其他地址与发现方式，应根据实际拓扑补充，而不是逐字复制后就认定全部本地服务已覆盖。no-resolve 的边界也要保留：它避免为对应地址条件主动解析，不负责把内部主机名转换成地址。若一个内部名称无法解析，仍需检查系统 DNS、Host 或用户自己的内部解析设置。

拒绝精确目标，避免宽泛误伤

需要拒绝一个已经确认的请求目标时，先采用 DOMAIN，而不是根据名称中的常见词进行大范围 REJECT。完整主机名便于核对，也便于恢复。下面只拒绝 telemetry.example.com，保留 example.com 其他主机的代理行为。若改成 DOMAIN-KEYWORD,telemetry,REJECT，就可能影响其他包含同一字符串的域名。是否值得扩大范围，要由实际请求记录和明确需求决定，不应以规则“看起来更全面”为依据。

[Rule]
DOMAIN,telemetry.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

验证 REJECT 时，应同时检查目标请求确实被拒绝、页面核心功能仍能工作，以及登录或提交操作没有异常。某个端点可能兼具统计与业务响应功能，单看名称无法确定拦截后果。出现故障后先停用刚添加的精确规则，用相同操作复测；确认因果关系后再决定保留还是删除。不要为了维持拦截而继续堆叠多个例外，使配置逐渐变成难以理解的补丁集合。

将场景写法转成维护记录

三类片段是不同需求的起点，不应直接首尾拼接，因为它们各有自己的 FINAL。合并时先选定总体兜底，再提取必要的域名例外、内部地址与拒绝条目，最后按顺序重新检查。建议为每个新增条件记录一行用途，例如“内部接口需直连”或“指定站点采用代理”；不要记录订阅凭据。需求消失时，按用途删除对应规则，比在成百上千行中猜测来源更可靠。

若更换已有订阅后只有 PROXY 路径失效，应先核对服务器选择与连接参数，而不是重写这些域名条件；规则指向的策略可能没变，变化的是策略背后的出口。多条订阅的分组与重复节点问题可参阅多个订阅管理说明。维护边界应始终清楚：服务器信息归服务器管理，目标匹配归 Rule，名称解析归 General 或 Host，只有这样才能在网络变化后快速定位需要调整的部分。

08 · 验证流程、排错分支与维护

建立固定测试目标与观测记录

验证配置不应只问“页面能不能打开”，还应确认它是否按预期路径打开。先选择一个应走 PROXY 的域名、一个应走 DIRECT 的域名，以及一个用于检查 FINAL 的未列出域名。若使用了 REJECT，再增加一个明确拒绝目标。对每个测试写下预期策略，测试时记录实际目标、命中规则和最终出口。目标越固定，前后对比越有意义；每次换不同网站，会把服务端波动误当成配置变化。

1. 确认用户已有的服务器信息已导入，并在 Home 选中可用出口。
2. 在 Config 选中测试副本，将 Global Routing 调整为 Config。
3. 建立连接，以新请求访问固定测试目标。
4. 在应用实际提供的请求记录或诊断视图中核对命中条件与策略。
5. 一次只修改一处，重复同组测试；通过后保存可回退副本。

Connectivity Test 可帮助判断某些连接条件，但不能代替具体业务测试。连接到服务器成功，不代表目标网站的认证、资源加载与请求方法都正常；同样，一个网页失败也不必然说明服务器整体不可用。遇到问题时，先确定失败发生在解析、连接、规则匹配还是应用层响应，再选择对应工具。若没有足够记录，保留一个最小复现片段，比反复切换大量设置更能缩小问题范围。

按现象选择排错分支

“规则未命中”应优先检查实际主机名，而不是直接扩大后缀。有些页面会重定向到不同域名，有些应用访问的是接口主机，有些请求直接使用地址。若规则条件本来正确，再检查文件是否选中、保存是否成功、Global Routing 是否仍在 Proxy 或 Direct。随后向上查找更早的命中项，尤其是宽泛关键词、地址规则与提前出现的 FINAL。这个检查顺序能避免把状态错误误写成更多规则。

“命中正确但访问失败”则应转向连接链路。检查用户已有的地址、端口、认证信息与协议相关参数，不要用更宽的 Rule 掩盖认证错误。Trojan 等使用 TLS 的连接还要核对服务方提供的名称与参数；参数应以用户自己的服务信息为准，不可从规则示例推导。相关字段可参阅Trojan 密码、SNI 与 TLS 要点。如果服务器列表本身为空，则先处理订阅更新，规则无法替代缺失的服务器信息。

回退、更新与故障材料整理

每次调整成功后，保存一份用途明确的稳定副本，并记录修改的条件与原因。远程配置或订阅更新后，先检查原有测试目标，不要等所有应用都出现异常才回想改动。若新版内容引入故障，回退到已验证副本可以恢复基线；之后再逐段比较，而不是把旧文件与新文件混在一起继续修补。对于已不再使用的 Host 映射、过时例外与重复规则，应在确认没有依赖后清理。

整理故障材料时，保留必要结构即可：当前姿态、相关 Rule 的前后几行、测试域名、预期策略和实际结果。不要公开完整订阅链接、服务器密码、访问令牌或带个人信息的请求地址；截图前应检查这些内容是否可见。无法确定问题归属时，先用最小规则副本复测，再对照FAQ与订阅更新失败自查步骤，避免把订阅解析错误和规则分流错误混为一谈。