01 / 文件边界
配置文件结构：先分清四类职责
Shadowrocket 的配置文件以分段文本组织设置。方括号中的段名划分职责，段内再写参数、规则或映射。阅读文件时，先找到 [General]、[Rule]、[Host] 与 [URL Rewrite]，再看每段具体内容。配置文件不是服务器列表的同义词：服务器负责建立连接，配置负责规定哪些请求采用什么处理方式，两者必须结合当前运行状态理解。
段名决定内容的解释方式
[General] 放置配置级参数，通常采用键值写法；[Rule] 放置按顺序检查的分流条件；[Host] 表达指定主机名的本地地址映射；[URL Rewrite] 处理符合表达式的请求地址。把一条合法规则放进错误的段，并不会让它自动成为有效的分流规则。排错时应先检查段落归属，再讨论规则是否精确。
# 分段结构示意；不是完整的连接配置
[General]
dns-server = system
[Rule]
DOMAIN,example.com,DIRECT
FINAL,PROXY
[Host]
test.example.com = 192.0.2.10
[URL Rewrite]
^http://example\.com/ https://example.com/ 302上面的四段展示了不同语法，不表示每份配置都应包含全部内容。没有本地映射需求时，可以不添加 Host 条目；没有明确的地址改写目标时，也不必添加 URL Rewrite。最小配置的价值在于可解释：每个设置都应对应一个实际需求，而不是为了文件看起来完整而加入不清楚作用的参数。
配置、服务器信息与订阅分别管理
用户已有的服务器信息通常包含地址、端口、协议与认证参数。订阅用于集中导入或更新这些条目，配置文件则另行描述分流行为。导入成功只能说明某类内容已经进入应用，并不同时证明服务器可连接、配置已经选中、规则会按预期执行。检查时应把三件事分开确认，避免用“已经更新订阅”代替“正在使用正确配置”。
在应用的 Config 中查看当前配置，核对名称与内容，然后回到 Home 检查 Global Routing。仅保存一个本地文件，不等于它已经成为运行中的配置。远程配置与本地副本也可能名称相近，修改前先确认编辑对象。若配置来自用户自己的管理来源，还应判断后续更新是否会覆盖本地改动；需要保留实验时，先另存一份可辨认的副本。
| 配置段 | 负责什么 | 不应混淆的内容 |
|---|---|---|
General | 配置级运行参数 | 不是按顺序匹配的规则列表 |
Rule | 条件匹配与策略选择 | 不保存服务器认证参数 |
Host | 主机名与地址的本地映射 | 不直接指定 PROXY 或 DIRECT |
URL Rewrite | 按表达式处理请求地址 | 不等同于域名分流 |
编辑前建立可回退的基线
首次维护一份较长配置时，先记录当前能够正常访问的目标、所选服务器和 Global Routing，再保存原文件。不要在同一次实验中同时替换 DNS、重排全部规则和增加改写。若结果发生变化，单项修改才能帮助判断原因。对配置做注释时，解释“为什么需要这条例外”比重复规则字面意思更有价值，例如说明某个内部主机必须使用本地网络访问。
语法层面还应检查英文逗号、段名拼写、意外换行和复制时带入的全角符号。注释建议独占一行，避免把说明误当作字段。规则片段可以分批加入，保存后检查应用反馈，再重新建立需要验证的连接。若只需逐段速览，可阅读配置文件各段作用；本页后续章节进一步解释匹配边界与验证方法。
02 / 生效条件
General：运行参数与 DNS 的边界
General 的作用是提供配置级运行条件，不是替代 Rule 决定每个目标的出口。排查“同一条规则为什么表现不同”时，需要把域名解析、目标地址、当前网络与实际选用的配置一起检查。尤其涉及 IP-CIDR 或 GEOIP 时，能否得到目标地址会影响后续判断；只看一行规则而不看解析过程，通常无法解释完整结果。
从最少的参数开始阅读
General 中的参数采用键与值对应的形式。不要把别处看到的长参数列表整体拼入现有文件，因为某些设置会改变解析、网络接管或地址处理方式。阅读陌生参数时，先在应用内核对其说明，再确认它与当前问题是否有关。没有明确目的的设置应保留原有状态，而不是为了“优化”同时改动多个运行条件。
[General]
# 使用系统提供的 DNS 解析设置
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT这个片段只说明 DNS 设置与 Rule 分段是独立的。dns-server = system 表示使用系统解析设置，不表示每个域名一定返回相同地址，也不表示所有网络环境都具有同样的解析结果。网络切换、解析缓存以及目标自身的地址调度都可能改变返回内容。判断某次请求时，应以当次可核对的信息为准。
域名规则与地址规则需要不同信息
DOMAIN 类规则需要可识别的目标主机名；IP-CIDR 与 GEOIP 则需要地址信息。一次以域名发起的请求，可能先通过域名规则确定策略，也可能在继续检查时涉及地址解析。不能简单认为“域名在某个地区注册，所以必然命中某条 GEOIP”，因为 GEOIP 判断的对象是地址及其数据库归属，并不是网站名称或注册资料。
解析所走的路径与后续业务连接所走的路径也不是同一个问题。看到一条 DNS 请求，不能直接推断随后的网页连接一定使用同样出口；看到业务命中 PROXY，也不能据此认定所有解析都经过同一服务器。排查时把“取得地址”和“连接目标”分成两个阶段记录，分别检查错误发生在哪里，避免把超时一律归因于规则。
IPv4、IPv6 与缓存要分别检查
只有 IPv4 网段规则时，不应假设它同时覆盖 IPv6 目标。若某次连接实际采用 IPv6，应该检查 IP-CIDR6 及相应策略，而不是继续扩大 IPv4 网段。同一个域名还可能在不同请求中使用不同地址族。为了验证配置，不必先关闭某种地址族；优先记录实际目标地址，再针对该地址所属的规则进行解释。
缓存与已有连接会让修改后的效果不立即出现在观察结果中。应用、浏览器与网络层可能分别保留信息，长连接也不一定因为保存配置而重新建立。完成一次变更后，先确认配置仍为选中状态，再关闭测试目标的旧会话或重新发起请求。是否需要重新连接取决于所改设置及应用提示，不应把反复切换连接当成唯一排错方法。
系统网络条件不属于规则本身
本地网络需要登录、无线网络无法访问目标、服务器主机名解析失败，都会让一份语法正确的配置表现为不可用。此时添加更多 DOMAIN-SUFFIX 不会修复底层连接。先确认设备已经接入可用网络，再检查用户已有服务器的可达性与认证信息，最后验证业务目标的分流。这一顺序能够把规则问题与网络问题分离。
维护 General 时，建议同时记录修改前后的网络类型、解析设置和测试目标，不记录真实认证信息。若只有某个网络出现异常，保留另一网络作为对照，逐项比较即可。涉及权限与首次启动的步骤见入门指南；涉及 Global Routing 的模式选择见代理模式说明。不要用运行参数去补偿尚未确认的服务器或权限问题。
03 / 主机名匹配
DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD
域名规则适合表达“这个主机或这一组主机应使用什么策略”。三种常用写法的区别在于覆盖范围，不在于哪一种更高级。需要精确例外时使用 DOMAIN；需要包含根域与子域时考虑 DOMAIN-SUFFIX；只有确实需要按名称片段宽泛匹配时，才使用 DOMAIN-KEYWORD。范围越宽，越需要检查误命中的可能。
DOMAIN：给单个主机建立明确例外
DOMAIN,api.example.com,PROXY 针对完整主机名，不会因为它包含 example 就自动覆盖其他主机。规则字段只写主机名，不带协议、路径、查询参数或端口。把 https://api.example.com/login 整段填进 DOMAIN，并不能表达“只让登录页面使用代理”；路径处理属于另一层需求，需要先判断是否真的应使用改写。
[Rule]
# 单个主机的精确例外
DOMAIN,api.example.com,PROXY
DOMAIN,intranet.example.com,DIRECT
FINAL,DIRECT这种写法适合先做小范围实验。确认单个主机的策略正确之后，再决定是否扩展到同一服务的其他域名。一个页面可能访问接口、图片与身份验证等多个主机，因此“主页面命中”不等于所有关联请求均命中。遇到页面部分加载时，应检查失败资源的实际主机名，而不是立刻把整类域名全部改为相同策略。
DOMAIN-SUFFIX：按域名层级覆盖
DOMAIN-SUFFIX,example.com,PROXY 用于匹配 example.com 及其子域，例如 api.example.com。它表达域名后缀关系，而不是任意字符串结尾；notexample.com 并不是 example.com 的子域。通常不需要在字段前再加星号。理解这一点可以避免把通配符写法与规则自身的匹配语义混在一起。
后缀规则覆盖面较大，放置之前应确认该域下是否包含必须直连的内部服务。例如内部管理主机与公开接口共用一个根域时，应先放内部主机的精确 DIRECT 例外，再放根域的 PROXY 后缀规则。如果反过来排列，内部主机已经在上方匹配，后面的精确例外就没有机会改变该次结果。
[Rule]
DOMAIN,intranet.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTDOMAIN-KEYWORD：范围由片段决定
DOMAIN-KEYWORD,ads,REJECT 根据域名中的关键词匹配，不理解词语含义，也不识别某个请求是否真的属于广告。只要主机名包含相应片段，就可能纳入范围。因此短关键词更容易误伤正常服务。示例用于说明语法，不能作为适合所有网络环境的拦截建议；实际维护应优先使用经过核对的精确主机或后缀。
| 规则类型 | 示例字段 | 匹配范围 |
|---|---|---|
DOMAIN | api.example.com | 指定的完整主机名 |
DOMAIN-SUFFIX | example.com | 根域与其子域 |
DOMAIN-KEYWORD | ads | 主机名中包含的片段 |
如果需要保留某个包含关键词的正常主机，应把精确例外放在关键词规则之前。但例外持续增长时，应重新审视关键词是否过宽，而不是无限追加补丁。规则维护的目标是让条件与需求一致，不是让一条过宽规则依赖大量例外才能勉强工作。可读性和验证成本也应纳入选择。
域名不可见时，不靠猜测补规则
并非每次连接都能得到预期的主机名。直接使用地址访问、请求经过其他中间处理或连接信息不足时，都可能无法按想象命中域名条件。此时先核对应用内可见的目标信息，再判断是否需要地址规则。不要因为浏览器地址栏出现某个名称，就假设该页面建立的每一条连接都携带同一个可用于匹配的域名。
最后，域名字段与代码示例都使用英文逗号分隔，多个主机应分别写成多条规则，不要把它们塞入同一个字段。遇到国际化域名或名称格式差异时，应依据实际请求中可核对的形式进行测试。有关 DOMAIN、FINAL 等关键词的简短释义可查名词解释，本章则用于判断覆盖范围和例外关系。
04 / 地址与请求属性
IP-CIDR、GEOIP 与 USER-AGENT
当需求直接针对目标地址、网段或请求属性时，域名规则未必是最合适的工具。IP-CIDR 表达 IPv4 地址集合，IP-CIDR6 表达 IPv6 地址集合，GEOIP 依据地址归属数据库进行分类。USER-AGENT 则依赖可获得的请求头信息。这些规则需要的输入不同，不能把它们简单当作域名规则的另一种拼写。
IP-CIDR：用前缀表示地址集合
192.168.0.0/16 表示一个 IPv4 网段，斜杠后是网络前缀长度，而不是端口。前缀越长，覆盖范围越小；单个 IPv4 地址可以用 /32 表达。写规则前应先确认目标实际使用的地址，尤其不要把服务器地址、设备自身地址与业务目标地址混为一谈：普通目标分流规则检查的是请求目标。
[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
FINAL,PROXY上述片段用于说明私有地址范围的写法，不保证所有本地服务都会因此可达。设备所在网络的路由、服务端监听地址、防火墙以及应用中的绕过设置，都可能影响结果。某些流量若已经在规则处理之前被排除，就不会再通过这些条目。排查内部服务时，需要同时确认设备本身确实能够到达那个地址。
no-resolve：不为这一条主动触发解析
地址规则末尾的 no-resolve 用于避免为了匹配该规则而主动对域名进行解析。它不表示关闭整个配置的 DNS，也不表示已经存在的地址信息会被忽略。对于只有主机名、尚无可用地址的请求，带此选项的地址规则可能无法据此匹配；请求会继续由后面的规则处理，因此仍然需要合理的域名规则和 FINAL。
在本地网段规则中使用它，常见目的是避免让大量普通域名仅为了检查私有网段而触发额外解析。但是否适合现有配置，需要观察请求信息和解析机制。若某个内部域名必须直连，可优先增加明确的 DOMAIN 规则，并确认该名称在当前网络能够正确解析，而不是只依赖地址规则碰巧取得所需信息。
GEOIP：数据库归属不等于服务身份
GEOIP,CN,DIRECT 表示依据目标地址的数据库归属选择策略。它不按网页语言、域名后缀或用户所在地点判断，也不能证明目标由哪家机构运营。地址归属数据存在更新与边界差异，同一个服务还可能使用多个地区的地址，因此 GEOIP 更适合作为较宽的分类条件，而不是身份核验依据。
[Rule]
DOMAIN,api.example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY这个顺序让明确指定的主机先采用 PROXY，其余请求再检查 GEOIP。若把宽泛的地址分类放在前面，已满足条件的请求可能提前结束匹配，后面的域名例外便不再生效。需要稳定地指定某个服务去向时，先用可核对的主机名描述需求，再将 GEOIP 作为补充，通常更容易解释和维护。
USER-AGENT：先确认信息是否可用
USER-AGENT 根据可见的请求头内容进行模式匹配，例如 USER-AGENT,ExampleClient*,DIRECT。这里的 ExampleClient 只是示例客户端标识，不是实际应用承诺。它不等同于按应用名称分流，也不能仅凭设备上安装了某个应用，就推断该应用全部流量都会命中同一个请求头模式。
HTTPS 会加密请求内容，规则处理过程未必能够读取其中的 User-Agent；有些请求也不包含这个字段，或者字段会随应用变化。不要为了验证普通分流而扩大到解密相关操作。若目标可以通过已知域名准确描述，优先使用域名规则。确实需要 USER-AGENT 时，应先确认应用内能够观察到相应信息，并保留未匹配请求的明确兜底策略。
05 / 流量去向
PROXY、DIRECT、REJECT 与 Global Routing
规则中的策略回答“命中之后怎样处理”，Global Routing 回答“当前采用哪种整体路由方式”。二者属于不同层次。排查一条 Rule 没有生效时，应先看 Global Routing 是否为 Config；如果当前使用 Proxy 或 Direct，就不能继续按 Config 中的普通规则顺序解释同一请求的结果。先确认模式，才能讨论策略。
三个基础策略的职责
PROXY 将符合接管条件的目标交给代理路径处理，能否连接仍取决于用户已有服务器的可用性与相关设置。DIRECT 表示目标使用直连路径，不经过所选代理服务器；它并不保证目标本身一定可达。REJECT 表示拒绝符合条件的请求，并不是在失败后自动改走另一条路径。三种策略都应与具体需求对应。
| 策略 | 处理含义 | 常见误解 |
|---|---|---|
| PROXY | 使用代理路径 | 命中不代表服务器必然可用 |
| DIRECT | 使用直连路径 | 直连也可能受网络条件影响 |
| REJECT | 拒绝匹配请求 | 不会自动回退为 DIRECT |
文件中的基础策略保留大写写法，便于与界面中的 Config、Proxy、Direct 区分。若已有配置使用自定义策略名称，应同时检查名称是否有对应定义，以及名称指向何种服务器或选择逻辑。本手册的最小示例只使用三个基础策略，不假设用户已经建立任何自定义分组，也不要求为了基础分流额外创建复杂结构。
Config、Proxy、Direct 的对照
Global Routing 的 Config 用于按照选中配置中的规则分流；Proxy 用于让受接管流量采用代理方式；Direct 用于采用直连方式。这里的“全局”不应理解为绕过一切系统限制并处理设备所有可能的流量，实际仍受系统、应用接管范围与相关设置影响。它首先是应用中的路由选择，不是连接成功的保证。
日常需要同时保留内部服务直连与指定目标代理时，Config 更适合表达这种差异。临时切到 Proxy 可以帮助判断代理路径是否可用，切到 Direct 可以作为直连对照，但两者都是诊断手段，不等于已经修复规则。测试完成应恢复原先需要的模式，否则后续观察会脱离原配置的设计目标。
FINAL 决定未命中请求的处理
FINAL,PROXY 表示此前没有匹配成功的请求最终使用 PROXY；FINAL,DIRECT 则选择 DIRECT。它没有域名或网段字段，不应写成三字段的普通条件规则。FINAL 应放在规则末尾，因为任何请求到达这一行都会得到兜底处理，后面的条件条目无法再影响该请求。
[Rule]
DOMAIN,intranet.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
FINAL,DIRECT这个片段把未明确列出的目标设为 DIRECT，而不是表示这种兜底适合所有用户。选择 FINAL 时，应先决定配置的默认处理原则，再为例外补充规则。更改兜底会影响大量未显式列出的目标，因此其验证范围应大于修改单个 DOMAIN。不要只测试一条已明确命中的域名，就认为新的 FINAL 已经得到验证。
连接状态、策略命中与业务成功分开判断
系统显示连接已建立，只能说明相应连接状态，不代表每个目标均可访问。规则命中 PROXY，也只说明选择了相应处理方向，之后仍可能发生认证失败、连接超时或目标拒绝。Connectivity Test 可以提供连通性参考，却不能替代对具体业务请求的规则核对。三个层次应分别记录，避免把测试结果相互替代。
需要获取应用时，先到App Store 正版核验页核对开发者与应用 ID。Shadowrocket 是 Apple 平台付费客户端，唯一获取入口是 App Store，系统要求以 App Store 页面标注为准。应用购买与用户已有服务器是两件事，客户端买断 ≠ 线路套餐。关于模式的独立说明见Global Routing 三种模式的区别。
06 / 优先级
匹配顺序：先命中的规则先决定结果
规则列表按照顺序检查，通常由第一条匹配成功的规则决定策略。不要假设 DOMAIN 天然比 DOMAIN-SUFFIX 优先，也不要认为较具体的网段会自动覆盖前面较宽的条件。具体程度用于帮助人安排顺序，并不是独立于文件顺序的优先级系统。要预测一次结果，应从规则列表顶部开始逐行判断。
先写精确例外，再写范围规则
假设 example.com 及其子域需要使用 PROXY，但 intranet.example.com 必须 DIRECT。正确表达不是简单同时放入两条规则，而是先放内部主机的精确条件。因为 intranet.example.com 同样属于 example.com 的子域，如果后缀规则排在前面，它会先命中，后续精确条件即使写得完全正确也无法改变结果。
# 例外在前
[Rule]
DOMAIN,intranet.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT反过来的列表看起来只交换了两行，行为却不同。这也是排错时不应只搜索“有没有那条规则”的原因：存在不代表可达。找到目标条目后，还要向上检查所有可能覆盖它的条件，包括关键词、域名后缀、地址分类与提前出现的 FINAL。前方任何一条命中，都可能让目标条目没有执行机会。
跨类型规则也共享同一条顺序
域名规则与地址规则不是彼此独立的两套列表。在同一个 Rule 段中，仍应按实际排列逐项理解，只是不同条件需要的信息不同。前面的域名条件如果已经命中，就没有必要指望后面的 GEOIP 改写结果；前面的地址条件若满足，也可能使后方域名例外失去机会。涉及解析时，还需结合第二章说明的地址信息边界。
所谓“具体到宽泛”可以作为组织习惯：明确主机例外、明确域名集合、必要的地址范围、较宽的分类条件，最后 FINAL。但这不是必须照抄的固定模板。例如要求某个已确认主机拒绝连接时，该精确 REJECT 可能应放在对应域名后缀放行规则之前。顺序始终由业务优先关系决定，而不是由策略颜色决定。
重复条目与矛盾条目怎样处理
相同条件出现两次、策略也相同时，后面的条目通常只是增加阅读负担；相同条件出现两次、策略不同时，实际结果仍由前面命中的条目决定。维护时应先标记重复来源，再决定保留哪一条，不要只删除看起来较旧的行。某些条目可能来自更新内容，若不处理来源，下次更新还会重新出现。
范围重叠不一定是错误。精确例外与后缀规则的重叠可以是有意设计，但必须能解释优先关系。无法说明用途的重叠，往往意味着配置是多次拼接而来。整理时先按需求分组，再在每组旁写明例外原因；不要只按域名字母顺序排序，否则原本依赖上下顺序的行为可能被悄然改变。
用测试矩阵检查每个分支
为上面的例子至少准备三类目标：精确例外主机、同域下的普通主机、与该域无关的主机。它们分别验证 DIRECT 例外、PROXY 范围与 FINAL。再加入一个接近但不属于该后缀的名称，用来检查是否误解了匹配边界。示例名称不需要真实提供服务；实际连通性测试应换成用户自己确认存在的目标。
测试时记录目标、预期命中条件、预期策略、观察到的结果和失败阶段。若预期规则没有命中，先检查它前方的覆盖条件；若规则命中但请求失败，再检查出口和目标服务。修改顺序后重新建立测试连接，以免旧会话干扰。这样的记录比连续追加许多相似规则更容易复现问题，也更便于在更新配置后重新验证。
07 / 映射与改写
Host 与 URL Rewrite：不要代替分流规则
Host 改变指定名称所对应的地址，URL Rewrite 处理符合表达式的请求地址，而 Rule 决定采用什么策略。三者可以出现在同一个文件中，但不能相互替代。某个主机需要 DIRECT，通常应先写清分流条件；不应为了实现直连就随意把主机映射到固定地址，更不应通过改写把访问目标换成另一个不相关的服务。
Host 映射固定的是解析关系
例如 test.example.com = 192.0.2.10 展示一个主机名到地址的静态映射。这里的地址属于文档示例用途，不是可访问的实际服务。Host 条目不含 PROXY、DIRECT 或 REJECT 字段；后续连接采用什么策略，仍需结合 Rule 和实际请求信息判断。把地址映射成功与分流成功视为同一件事，会掩盖问题所在。
[Host]
test.example.com = 192.0.2.10
[Rule]
DOMAIN,test.example.com,DIRECT
FINAL,PROXY静态映射适用于用户明确管理的测试环境等有限场景。公开服务可能采用动态地址、负载调度或故障切换，长期固定地址可能导致连接失效，也可能绕过原本应随网络变化的调度。只有在能够确认地址归属、用途与维护责任时才添加映射，并记录撤销条件。不要把某一次成功解析得到的地址永久写入配置。
映射不能消除证书与服务身份检查
将主机映射到另一个地址，并不让那个地址上的服务自动拥有原主机的身份。HTTPS 仍涉及证书与请求主机等检查；若目标服务并未为该主机配置，可能出现证书不匹配或业务拒绝。遇到这种错误，不应通过忽略身份验证来“证明映射有效”，而应重新确认地址、主机与服务配置是否一致。
若访问行为与映射预期不同，还要检查应用是否确实使用了这份解析信息、已有连接是否仍保留旧地址，以及请求是否通过其他机制取得地址。先移除单条映射做对照，再恢复并重新发起连接。只有确认差异来自 Host 后，才继续讨论它与地址规则的交互，避免同时修改映射和分流导致无法归因。
URL Rewrite 的三个组成部分
常见重定向写法由匹配表达式、替换目标与状态码组成，字段间按相应语法分隔。下面的例子将特定主机的 HTTP 前缀替换为 HTTPS 前缀，并采用 302。表达式中的点使用反斜杠转义，避免把它解释为任意字符；开头的 ^ 限定从请求地址起始位置匹配，从而减少不必要的误命中。
[URL Rewrite]
^http://example\.com/ https://example.com/ 302这个片段只说明语法，不能替代网站自身正确的 HTTPS 配置。匹配范围包括斜杠位置，因此与没有路径斜杠、不同端口或不同主机的输入并非必然等价。测试应分别检查首页、带路径请求和带查询参数请求，确认替换后目标仍符合预期。表达式写得越宽，越需要对不应匹配的输入做反向测试。
避免循环与超出可见范围的改写
如果一个改写结果再次满足另一条改写，可能出现重复跳转，甚至在两个地址之间循环。添加规则前应把原始地址、第一次替换结果和后续可能匹配的条件写出来。浏览器可能缓存重定向结果，调试时应考虑这一影响，不要把缓存中的跳转误认为当前配置仍在生效。撤销规则后也要重新验证新的请求。
加密请求的路径并不天然对规则处理过程可见，URL Rewrite 不是任意 HTTPS 内容都能修改的保证。本页不要求为普通分流配置额外的解密能力。只需改变流量出口时，回到 Rule；只需解释名称对应的地址时，检查 Host；确实管理请求地址转换时，再使用 URL Rewrite。保持这三个边界，才能在出现故障时快速定位负责的部分。
08 / 维护闭环
配置验证：从最小片段到可回退维护
验证配置的目标不是看到一次成功访问，而是确认预期规则在预期条件下产生可解释的结果。完整闭环包括保存原配置、确认运行模式、修改单项内容、建立新请求、核对命中与连接结果、记录并保留回退方案。把每个阶段分开，既能减少误判，也能在后续订阅或配置更新后快速复查。
第一步：确认当前实际运行的对象
先在 Home 检查连接状态、当前选中的服务器以及 Global Routing，再到 Config 确认正在使用的文件。文件名相同或相似时，应直接检查内容，不只依赖名称判断。用户已有服务器的参数应与自己的来源保持一致，尤其不要在验证规则时顺便修改协议、端口和认证字段，否则连接结果变化将无法归因。
如果尚未建立过可用连接，先完成入门指南，不要立即导入一份包含大量规则和改写的配置。应用获取与已购恢复问题应查购买恢复说明，而不是修改 Rule。App Store 正版核对的开发者是 Shadow Launch Technology Limited，应用 ID 为 932747118；系统要求以 App Store 页面标注为准。
第二步：缩小到能够解释的配置片段
出现异常时，保留原文件，在副本中只留下与测试目标有关的条件和明确的 FINAL。先验证精确 DOMAIN，再逐步恢复后缀、地址分类、Host 与改写。不要直接删除唯一可用配置，也不要将测试副本覆盖远程来源。最小化的作用是排除干扰，不是建议日常永远只使用两三条规则。
[Rule]
# 将 example.com 换成用户自己确认存在的测试主机
DOMAIN,example.com,PROXY
FINAL,DIRECT用这个结构测试时，应选择一个明确命中 DOMAIN 的目标，再选择一个不命中的目标来检查 FINAL。若两者结果都不符合预期，先回查是否确实处于 Config，以及副本是否选中。若只有 PROXY 目标失败，单独检查代理路径；若 DIRECT 目标失败，检查当前网络能否直连该目标。不要用一个失败结果直接否定全部配置语法。
第三步：区分四类常见失败
| 现象 | 优先检查 | 下一步 |
|---|---|---|
| 规则未命中 | 配置是否选中、模式、上方覆盖条件 | 核对目标信息并最小化规则 |
| 命中但超时 | 所选出口、服务器与目标可达性 | 分别测试连接路径 |
| 仅部分资源失败 | 失败资源的实际主机和策略 | 逐个核对依赖请求 |
| 修改后仍是旧结果 | 旧连接、缓存、配置选择状态 | 建立新请求后再次观察 |
应用内可用的连接记录或日志可以帮助核对目标、策略与失败阶段，具体呈现以当前应用内界面为准。记录中若只有地址，不要擅自补成某个域名；只有域名而无地址时，也不要断言它必然属于某条网段。Connectivity Test 用来辅助判断连通性，具体网页或接口仍需单独发起请求验证。
第四步：处理更新覆盖与规则回归
订阅更新与配置更新应分别检查。更新已有服务器条目，不必然改变当前 Rule；更新远程配置，则可能重新排列或替换本地调整。每次更新后至少复测精确例外、常用范围与 FINAL 三类目标。若有 Host 或 URL Rewrite，再补测映射目标和重定向边界，避免只确认主页面可打开就结束维护。
维护记录可以包含变更原因、原规则、新规则、预期结果与实际结果，不应包含完整订阅地址、认证信息或其他敏感内容。需要向他人说明问题时，先替换真实主机和凭据，同时保留规则顺序、字段结构及必要错误信息。仅删除密码而保留带认证参数的订阅地址，仍可能暴露用户自己的访问权限。
规则已经保存，为什么还没有看到变化？
先确认选中的配置与 Global Routing，再检查旧连接和缓存。重新建立测试请求后，核对前方是否存在先命中的规则，不要只检查新增条目是否存在。
命中 PROXY 是否就证明配置全部正确？
只能证明该次请求选择了相应策略。服务器连接、认证、解析与目标服务仍可能失败；还需检查其他规则分支和未命中请求的 FINAL。
最后保留一份经过验证的可回退配置，并清理已经证明多余的试验条目。规则越多不代表结果越稳定，能说明每个条件的用途、顺序与验证方法，才便于长期维护。需要复查第一次连接过程，可阅读选默认服务器与 Connectivity Test 验证；需要快速确认术语，则转到名词解释按关键词查阅。