Shadowrocket
规则与配置参考
按配置段落查字段，按请求目标选规则，按命中记录验证结果。
本页是 Shadowrocket 的系统查阅手册，适合已经持有自己的订阅或服务器信息、需要调整规则的用户。首次导入、授权和连接请先按入门指南操作，再回到本页理解每项配置的作用；本页示例是独立知识片段，不是包含服务器凭据的完整连接配置。
01 / 配置文件
配置段落与生效范围
先区分服务器、订阅与配置文件
服务器记录保存连接目标及认证参数；Subscribe 用于管理已有订阅及其中的服务器记录；Config 中的配置文件则描述解析、规则和请求处理方式。三者彼此有关，但并不互相替代。成功更新订阅，不能据此判断当前使用的是哪一份规则文件；导入一份规则文件，也不等于已经补齐服务器的地址、端口和认证信息。查阅前应先在 Home 确认已有可用记录，再到 Config 确认当前选用的文件，避免把连接资料问题误判成规则语法问题。
订阅与规则配置还可能有不同的更新周期。一次订阅更新通常围绕它实际包含的内容展开，不应假定它会同步修改你手工维护的规则。反过来，远程配置更新也可能改变原先编辑过的段落。修改之前先保留一份副本，并记录哪些内容来自远程、哪些内容由自己维护。订阅信息从你的服务商处获取，账户凭据与私人链接不应出现在用于公开讨论的配置截图或文本中。
方括号定义段落，字段只在所属段内解释
Shadowrocket 的配置文件使用段落组织内容。[General] 放置通用设置，[Rule] 放置有先后顺序的匹配条目，[Host] 表达指定域名的地址映射，[URL Rewrite] 描述符合条件的 URL 如何改写。段名并不是注释，不能随意翻译，也不要把规则条目粘贴在尚未切换到 Rule 的段落中。下面展示基本形态，各段分别处理不同问题，不代表每份配置必须同时包含这些字段。
[General]
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY
[Host]
printer.example.com = 192.168.1.20
[URL Rewrite]
^http://example\.com/ https://example.com/ 302读取示例时，应把段落边界和规则顺序分开理解。文件中的 General 不会像 Rule 那样逐条决定某个域名的策略；Host 中的地址映射也不是一条 DIRECT 指令。若一个域名映射到了局域网地址，仍应检查该请求最终命中什么规则。将配置拆成“解析目标、选择策略、建立连接”三个观察点，比仅看文件里是否出现某个域名更有助于判断实际行为。
编辑、保存与选用是不同操作
在 Config 中编辑后，先完成保存，再确认保存的是当前准备使用的文件。若同时保留原文件与测试副本，应为副本使用能辨认用途的名称，避免只凭列表位置判断。随后确认 Global Routing 处于 Config；如果仍是 Proxy 或 Direct，Rule 的分流效果就不能按预期验证。测试时重新发起请求，必要时结束原有连接再打开目标页面，因为一个已经建立的连接不会因文本被保存而自动重新走一遍完整匹配。
对于来源明确的已有配置，优先做小范围修改，而不是删除所有段落后重新组合。某些通用字段之间存在配合关系，移除一行可能同时影响 DNS、局域网访问或连接建立方式。无法解释的字段先保留，并查阅应用内对应说明。每次只改变一个可验证条件，测试通过后再继续；出现异常时恢复副本，比继续堆叠例外规则更容易找出真正原因。
02 / 通用设置
General、Global Routing 与 DNS
路由姿态决定规则是否参与选择
Global Routing 是排查规则前应先检查的入口。Config 按当前配置文件选择策略；Proxy 让受客户端处理的请求使用当前代理选择；Direct 则采用直连方向。它们描述的是不同的处理姿态，不是同一规则文件的三个优先级。若一个请求在 Proxy 下能建立连接，在 Config 下失败，应继续查看具体命中规则，而不是立即断定服务器失效。相反，Direct 下的访问结果也不能用于证明代理路径可用。
| 界面词 | 查阅重点 | 适合验证的问题 |
|---|---|---|
| Config | 当前配置与首条命中规则 | 特定目标为何采用某项策略 |
| Proxy | 当前代理选择及连接参数 | 代理路径是否能完成同一请求 |
| Direct | 本地网络与目标可达性 | 直连路径是否具备访问条件 |
这里的“受客户端处理”是重要边界：应用外部的系统行为、既有连接以及配置中的特殊处理条件，都会影响你实际观察到的请求。切换姿态后，应使用同一个目标和同一种请求方式重新测试，不能拿网页访问和应用后台连接互相比较。需要逐步了解切换方法，可阅读Global Routing 的 Config、Proxy、Direct 说明，再根据本页的规则章节解释命中结果。
General 是通用条件，不是规则优先级开关
General 中常见字段采用 key = value 形式，具体可用选项应以应用内配置编辑器与说明为准。不要把其他语法体系的同名字段直接移入文件，也不要认为字段名称相近就具有相同语义。下面只保留最小 DNS 示例：system 表示使用系统提供的解析设置，并不是固定写入某个解析服务器地址。修改 DNS 之前，应先确认问题发生在解析阶段还是建立连接阶段。
[General]
dns-server = system
[Rule]
DOMAIN,api.example.org,DIRECT
FINAL,PROXYDNS 负责把名称解析为地址，策略负责决定请求采用哪条处理路径，两者需要协同但不能画等号。某域名命中 DIRECT 后仍然可能解析失败；某域名成功得到地址，也仍可能因代理认证、目标端口或远端连接异常而失败。排查时先看是否有域名和解析结果，再看命中规则与连接错误。仅凭“切换 DNS 后暂时恢复”这一现象，不能推断原有所有规则都已经正确。
地址规则可能引入解析依赖
当请求以域名发起，而后续规则需要判断目标 IP 或 GEOIP 时，匹配过程可能需要先获得地址。这个解析动作不仅影响耗时，也可能使日志里出现与目标请求相关的 DNS 记录。若把大量地址规则放在域名规则前面，原本可以直接按域名决定的请求也可能进入额外的地址判断。通常先放明确的域名例外，再放需要地址信息的范围规则，有助于使配置意图更清楚。
地址规则中的 no-resolve 可以限制为了该条规则而主动解析域名，但它不是“关闭全部 DNS”的开关。已经具备目标 IP 的请求仍然可以参与地址匹配，而仅有域名、没有可用地址的请求可能继续落到后面的规则。启用后应分别测试按域名和按 IP 发起的请求，不能仅测试其中一种。具体写法见地址章节；不要为减少一条日志而随意给所有 IP 规则追加这个参数。
还应区分 IPv4 与 IPv6 的实际连接目标。同一域名可能返回多个地址，应用选择的地址不一定与你手工查询时看到的第一项相同。只覆盖 IPv4 私有网段的规则，并没有自动覆盖全部 IPv6 场景。遇到“同一域名偶尔走不同路径”，先核对实际目标地址、解析缓存和连接复用，再评估是否需要补充另一地址族的规则。把这些观测条件记录下来，才能得到可重复的结论。
03 / 名称匹配
DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD
DOMAIN：只处理一个明确的主机名
DOMAIN 用于完整域名匹配，适合为某个 API、登录入口或业务主机设置独立策略。例如 DOMAIN,api.example.org,DIRECT 针对 api.example.org，不等于同时包含 example.org，也不包含另一个名为 static.example.org 的主机。填写时只写主机名，不要带协议前缀、端口、路径或查询参数。若目的是处理某一页 URL，应先确认需要的是整台主机的路由，还是后文介绍的 URL 改写。
[Rule]
DOMAIN,api.example.org,DIRECT
DOMAIN,static.example.org,PROXY
FINAL,PROXY浏览器地址栏里看到的主机名不一定涵盖整个页面的请求。页面可能继续加载独立的图片、脚本、登录和接口主机，主文档走 DIRECT 并不表示它们也会走 DIRECT。规则验证应以日志中的实际请求域名为依据。若页面主体能打开但登录或资源失败，先逐项确认出错主机，不要直接把范围扩大到一个可能包含无关业务的关键词。
DOMAIN-SUFFIX：按域名层级覆盖一组主机
DOMAIN-SUFFIX 用于后缀匹配。以 example.com 为参数，通常覆盖 example.com 本身及 www.example.com、img.example.com 等子域名。这是按域名层级理解的后缀，不是任意字符串包含关系；不能将 notexample.com 当作同一域名的子域。适合的场景是同一业务域及其下属主机应使用同一策略，而其中少数主机再通过更靠前的 DOMAIN 规则单独处理。
[Rule]
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT该片段中，local.example.com 先命中精确条目，其余属于 example.com 的主机才由后缀条目接管。若把两行顺序互换，精确条目不会因为名字更具体而自动取得优先级。也应注意，服务使用的内容分发域名可能并不位于自己的主域下；仅增加一个后缀，无法保证全部资源都落入同一策略。需要结合实际请求补充，而不是凭品牌名称猜测域名集合。
DOMAIN-KEYWORD：方便但范围更难约束
DOMAIN-KEYWORD 判断域名是否包含给定关键词，适合确实需要跨多个命名空间处理同一特征的情况。它的范围比后缀更宽：参数 example 可能匹配 example.com，也可能匹配包含该字符串的其他域名。因此不宜把过短、常见或含义模糊的词作为大范围分流条件。若已知明确主机或主域，优先使用 DOMAIN 或 DOMAIN-SUFFIX，维护时更容易说明这条规则究竟覆盖什么。
| 类型 | 参数示例 | 范围含义 |
|---|---|---|
| DOMAIN | api.example.org | 完整主机名 |
| DOMAIN-SUFFIX | example.org | 主域及其子域 |
| DOMAIN-KEYWORD | example | 域名内包含关键词 |
域名规则依赖客户端在匹配时能够取得目标名称。如果应用直接连接 IP，或者当前请求记录只有地址而没有可用域名，增加更多域名条目未必产生效果。先核对日志中可用于判断的信息，再决定使用域名规则还是地址规则。不要根据“访问的是某网站”这一用户层面的描述，就假定每条底层连接都带有那个网站的完整名称。
维护域名规则时，还需留意重定向与缓存。一个输入地址可能先跳往另一个主机，浏览器也可能复用此前建立的连接。修改后建议重新打开目标并观察新请求；若仍存在疑问，再在条件允许时结束旧连接后测试。对于含国际化字符的域名，应以客户端实际记录的名称形式核对，避免把显示名称、编码形式和 URL 路径混为同一个匹配参数。
04 / 地址与特征
IP-CIDR、GEOIP、USER-AGENT 与 FINAL
IP-CIDR 与 IP-CIDR6：匹配目标地址范围
IP-CIDR 使用地址和前缀长度表示 IPv4 网络范围。192.168.0.0/16 覆盖对应的私有地址段，而 192.168.1.20/32 只表示一个 IPv4 地址。前缀越长，范围越小，但这种“更具体”只描述地址集合，不会改变规则的先后顺序。IP-CIDR6 则用于 IPv6，例如 fd00::/8 表达相应的本地地址范围。写错前缀可能把例外扩展到远超原意的目标。
[Rule]
IP-CIDR,192.168.1.20/32,DIRECT,no-resolve
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fd00::/8,DIRECT,no-resolve
FINAL,PROXY以上片段只示范部分地址范围，并不是完整的局域网处理清单。DIRECT 只决定不经代理服务器发送，并不保证目标设备在线、路由存在或访问权限允许。若打印机或本地服务仍无法访问，应检查设备地址是否变化、当前网络是否允许设备间通信，以及访问所需的系统权限。不要仅因为规则已经命中，就将所有后续错误归为应用问题。
no-resolve 是可选匹配修饰参数，含义是避免为了该条地址判断主动解析域名。请求本身带有目标地址时仍可能命中；只有域名且没有适用地址信息时，则可能继续检查后续条目。如果局域网服务是通过域名访问，单靠带此参数的私有地址规则不一定符合预期，可以先用精确 DOMAIN 明确处理已知主机，再根据需要保留地址范围规则。
GEOIP：依据地址数据库判断区域
GEOIP,CN,DIRECT 表示当目标地址按所用数据库归类为 CN 时采用 DIRECT。它不是按域名后缀判断，也不是识别网页语言、账户地区或业务所有者。一个中文页面可能使用不同地区的基础设施，一个相同域名也可能因解析条件返回不同地址。因此 GEOIP 更适合作为较宽的地址归类条件，而不应代替业务明确的域名例外。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY地址数据库的归类结果与实际链路可达性是两个问题。命中某个地区，并不能保证直连速度或连接成功；不同网络观察到的目标地址也可能改变。排查时应同时保留实际目标 IP、命中条目和错误类型。若某个已知业务需要固定策略，优先增加能够解释业务范围的域名条目，而不是因为一次结果不符合预期就全面替换所有 GEOIP 规则。
USER-AGENT：只在请求特征可见时有意义
USER-AGENT 根据可取得的 User-Agent 特征匹配，例如 USER-AGENT,ExampleApp*,DIRECT 用星号表达相应的通配形式。它不等同于按应用名称或进程识别流量，也不能假定每条加密连接都暴露这个请求头。普通 HTTPS 连接中，头部位于加密内容内，客户端不一定具备这项信息。因此该规则应作为明确条件下的补充，不能用来保证某个应用的全部请求统一分流。
FINAL：为尚未命中的请求给出结果
FINAL 不需要域名或地址参数，形式是 FINAL,PROXY 或 FINAL,DIRECT。它应放在匹配列表末尾，明确前面条件均未匹配时的处理方向。若放在中间，后面的普通规则通常就失去参与匹配的机会。选择兜底策略时要考虑现有配置目标：PROXY 依赖可用代理，DIRECT 依赖本地网络直接访问。两者都不构成连接成功的保证。
组合这些规则时，先问当前请求有哪些可靠信息。已知域名就优先表达域名意图，确实是地址范围需求再使用 CIDR，区域归类放在更宽的位置，最后通过 FINAL 收束。对于 USER-AGENT 等依赖请求可见性的规则，要准备信息不可用时的后续处理。这样配置不仅能说明“命中时做什么”，也能说明“未命中时会去哪里”。
05 / 策略结果
PROXY、DIRECT、REJECT 与 Proxy Group
策略是处理方向，不是可达性结论
规则的最后一个主要字段通常指向处理策略。PROXY 表示使用代理方向，DIRECT 表示直接发送，REJECT 表示拒绝相应请求。三者的名字说明的是客户端应如何处理，而不是目标是否正常。日志显示 PROXY，仅能证明进入了相应方向；后续仍可能因服务器认证、远端连接或目标服务问题失败。显示 DIRECT 也不意味着请求绕过所有系统网络条件，它仍受本地网络与目标状态影响。
| 策略 | 处理含义 | 后续核对 |
|---|---|---|
PROXY | 采用当前代理方向 | 实际选中的服务器与连接参数 |
DIRECT | 不经代理服务器发送 | 本地网络、解析与目标可达性 |
REJECT | 拒绝符合条件的请求 | 拒绝范围是否包含必要依赖 |
理解这一点可以避免反复改错位置。例如已准确命中目标 DOMAIN 且采用 PROXY，却出现认证相关错误，优先核对已有服务器资料，而不是把 DOMAIN 改成 DOMAIN-SUFFIX。相反，如果日志显示目标被更早的 DIRECT 条目接管，即使代理本身可用，也需要先修正规则范围或顺序。应先证明策略选择正确，再判断该策略下的连接是否成功。
PROXY 与自定义分组的关系
PROXY 是内置策略词，不是一个必须手工新建的服务器名称。在使用自定义 Proxy Group 的配置中，规则也可以引用已经定义的组名，让不同目标进入不同选择集合。引用之前必须确认组实际存在，且组内成员能被当前配置识别。拼写、空格与名称应与定义保持一致；仅在规则尾部写出一个新名字，不会自动生成包含服务器的可用分组。
[Rule]
DOMAIN,api.example.org,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,blocked.example.org,REJECT
FINAL,PROXY上例只使用内置策略，避免引入未定义的分组依赖。如果已有配置使用自定义组，排查时还要多检查一层：先确认请求进入哪个组，再确认该组最终选择了哪个成员。组名正确但成员不可用，与规则未命中是两类问题。自动选择类分组还可能在网络条件变化后选择不同成员，因此对比测试时应记录最终实际使用的服务器，而不只是组的显示名称。
DIRECT 与 REJECT 要按目标范围使用
DIRECT 常用于明确需要本地网络路径的请求，例如已知的局域网主机。不要只因为一个业务“看起来属于本地”就大范围直连，仍应确认它的实际域名与依赖。REJECT 则适合需要明确停止的请求，但一条过宽的拒绝规则可能影响登录、资源加载或其他基础功能。将拒绝范围缩到能够解释的主机，并通过日志验证，通常比使用含义模糊的关键词更可控。
目标被拒绝后，应用的表现并不固定。有的页面立即报错，有的应用反复重试，还有的界面只显示一直等待。这些现象不等于代理服务器故障。若新增 REJECT 后出现异常，先恢复该条规则并重新发起同一操作，比较相关请求是否恢复，再决定是否缩小范围。不要在拒绝规则之后增加同目标的 DIRECT，期待后者自动覆盖前者；顺序未改变时它不会得到机会。
客户端购买与连接服务分别管理
Shadowrocket 是 Apple 平台的付费客户端，客户端一次性买断 ≠ 线路套餐。规则里出现 PROXY，不会产生新的服务器，也不会补齐订阅信息。已有订阅从你的服务商处获取，认证和到期状态也由其管理。需要核对应用获取入口时，请查看App Store 正版核验说明；购买应用与准备连接资料应分别确认，避免把商店付款成功当作连接配置完成。
对分组和策略的维护，建议保留一个简单、可解释的基线。先用内置策略验证目标路径，再引入分组；先验证单个成员，再评估自动选择行为。这样发生错误时可以逐层退回，而不是同时面对规则、组名、成员和连接参数四种变量。若只是首次连接尚未完成，回到入门指南按主线操作，比提前搭建复杂策略结构更合适。
06 / 优先级
从上到下匹配，首条命中即停止
不存在自动的“更具体优先”
Rule 按文件中实际顺序检查。一个目标一旦满足某条条件，就采用该条指定的策略，后续普通条目不再用于重新选择。DOMAIN 不会天然压过 DOMAIN-SUFFIX，单地址规则也不会天然压过大网段，REJECT 更不会因为语义强烈就自动优先。所谓优先级，首先就是配置位置。理解这个原则后，多数“规则写了却没有效果”的现象都可以通过查找更早的匹配解释。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY对 api.example.com，第一行已经给出 DIRECT；对 www.example.com，第一行不匹配，第二行给出 PROXY；对其他域名，才继续检查 GEOIP，最后落到 FINAL。这是一条有明确停止点的判断链，而不是对所有命中规则打分。即使 www.example.com 解析到的地址满足后面的 GEOIP，也不会因此改用 DIRECT，因为前面的后缀规则已经完成了策略选择。
用反例解释顺序冲突
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,api.example.com,DIRECT
FINAL,PROXY这个反例里，api.example.com 会先被后缀规则接管，下面的精确规则无法实现例外目的。修复方法是将精确例外移动到范围规则前，而不是复制同一条到文件末尾。若存在多条相同条件，通常先出现的那条决定结果。重复条目会增加阅读成本，还会让维护者误以为后面新写的内容已经覆盖旧设置，因此整理时应检查重复和相互包含的范围。
先局部例外，再业务范围，最后宽泛归类
一种便于维护的组织方式是：先放明确的允许或拒绝例外，再放业务域名范围，然后处理目标地址与区域，最后写 FINAL。这不是应用强制的固定模板，而是让规则意图更容易阅读的方法。若业务需求与此不同，可以调整，但每一次调整都应能说明它为什么必须在上一条之前。不要为了“看起来整齐”按字母排序整个 Rule，否则可能改变原有的先后关系。
例外之间也可能重叠。例如希望某个主域使用 PROXY，但其中一个接口使用 DIRECT，同时另一个具体主机需要 REJECT，那么两个精确主机条目都应位于主域后缀之前。若再加入包含同一字符串的 DOMAIN-KEYWORD，必须确认它不会抢先接管原有例外。审查时不要只问一条规则单独是否正确，还要问它上方有哪些更宽条件，下方哪些条目会因此变得无法命中。
配置更新后重新审查实际列表
远程配置更新可能改变条目位置、删除本地修改或加入新的范围规则。一次更新成功只说明内容获取完成，不代表原有定制意图仍被保留。更新后至少检查关键例外、末尾 FINAL 和自定义组引用，再针对常用目标做一次验证。若必须长期维护个人例外，应采用自己能够稳定管理的配置方式，并保留修改说明；不要依赖每次更新后凭记忆找回所有差异。
定位顺序问题时，可以先列出一个请求的预期判断过程：目标名称是什么，是否具备地址，最早可能匹配哪条，预期策略是什么。再把这个过程与日志结果逐项对照。如果结果不一致，先确认是否使用了错误文件、Global Routing 是否为 Config，以及观察到的是否为新连接。只有这些基础条件一致，才有必要继续研究某个关键字的具体匹配边界。
性能与可读性也需要平衡。把确切域名规则放在需要解析的地址判断之前，往往能减少不必要的判断依赖，但不应为了减少行数而把多个明确目标压缩成一个宽泛关键词。优先维护可说明、可复现的行为，再清理真正重复的内容。一个较短却无法解释边界的文件，并不比稍长但职责清楚的文件更容易维护。
07 / 解析与改写
Host 与 URL Rewrite 的职责边界
Host 修改地址映射，不直接选择策略
Host 用于显式指定域名对应的地址，例如把 printer.example.com 指向当前网络中的设备。它解决的是“这个名字对应哪个地址”，而不是“这个请求要走哪条策略”。因此 Host 与 Rule 可以同时需要：前者给出目标地址，后者决定处理方向。若只添加映射，却仍让请求进入不适合访问该局域网地址的代理路径，访问依然可能失败。
[Host]
printer.example.com = 192.168.1.20
[Rule]
DOMAIN,printer.example.com,DIRECT
FINAL,PROXY这个片段把两项意图分别写清：名称映射到指定设备，对这个名称的请求使用 DIRECT。实际使用前应确认设备地址稳定、服务端口正确且本地网络允许访问。换到其他网络后，同一个私有地址可能对应不同设备，也可能完全不存在，所以不宜把局域网映射当作所有网络都适用的通用配置。需要迁移设备或切换环境时，应同步检查映射与规则。
固定映射还会改变服务原本依赖的动态解析结果。公开服务可能通过 DNS 调整接入地址或区域，长期写死某个地址可能在一段时间后失效。HTTPS 访问也仍会按请求名称校验证书，指定地址不会自动使证书适用于另一个名称。若出现证书错误，不应以继续增加 Host 条目作为通用处理方法，应先核对目标服务与名称是否真正对应。
URL Rewrite 匹配 URL，不是域名路由
URL Rewrite 处理的是符合表达式的 URL，可用来进行明确的跳转改写。它与 Rule 的逗号分隔语法不同，通常由匹配表达式、替换目标和处理方式组成。下面把指定主机的 HTTP 地址跳转到 HTTPS，状态码为 302。它只是受控示例，不应直接扩展为所有网站的统一改写，因为目标未必提供相同的 HTTPS 路径或服务能力。
[URL Rewrite]
^http://example\.com/ https://example.com/ 302表达式开头的 ^ 限制从 URL 起始位置匹配，域名中的点写作 \.，表示字面的点，而不是正则表达式中的任意字符。域名后的斜杠也帮助明确主机边界。若省略必要约束，一个原本只想处理 example.com 的表达式可能意外匹配其他字符串。编写时应同时准备应命中和不应命中的 URL，确认表达式没有超出预期范围。
保留路径时使用明确的捕获关系
[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302这里用捕获组保存斜杠后的内容，再通过 $1 放入替换目标，以便保留后续路径及匹配到的查询部分。它与前面的固定目标示例是两种替代写法，不应不加判断地同时保留。包含登录状态、签名或敏感查询参数的 URL 尤其需要谨慎，改写可能使服务端校验失效，也可能改变原有请求语义。先在自己能够验证的目标上测试，再决定适用范围。
还要检查是否形成循环。如果原地址跳转到新地址后，又被另一条规则改回原处，就可能出现重复跳转。避免循环的办法是把匹配范围限定在旧协议或旧路径，确保替换结果不再满足同一条件。调试时逐次观察实际跳转目标，而不是只看最终页面是否打开；缓存中的旧跳转也可能干扰测试，必要时用新的请求条件重新验证。
加密可见性决定改写能否发生
普通 HTTPS 连接的完整 URL 路径位于加密内容中，不能因为已经看到域名就假定客户端能匹配其中任意路径。涉及 HTTPS 内容处理的功能有额外条件与信任影响，不是添加一条 URL Rewrite 就会自动生效。本页不以改变系统信任设置作为常规分流步骤。如果目的仅是让某个主机使用 PROXY 或 DIRECT，应回到 Rule，用域名规则表达，不必引入内容改写。
维护这两个段落时，保留的条目应尽量少且有明确用途。已经失效的临时映射、过宽的改写表达式和不再需要的跳转都会增加排查成本。删除之前保存副本，删除之后重新测试受影响目标。若只是某个页面打不开，优先从请求、解析和策略的证据开始，不要同时添加 Host 与改写规则，让问题变成多个相互影响的修改。
08 / 验证与维护
用 Logs 定位问题，按副本恢复配置
先建立能够重复的观察条件
开始验证前，记录当前网络、Global Routing、正在选用的配置文件，以及实际代理选择。然后指定一个目标和一个动作，例如打开某个页面或请求某个接口，而不是笼统地说“整个应用不能用”。Connectivity Test 可以辅助观察连接条件，但一次测试成功并不能代替真实业务请求。代理连接可建立、域名可解析、目标接口可响应，是三个需要分别确认的结果。
测试时尽量保持其他条件不变。不要一边切换网络、一边更换服务器，又同时修改 DNS 与规则，否则结果即使改善，也难以判断是哪项变化产生作用。规则保存后重新发起请求，注意连接复用和缓存；必要时在能够安全结束当前任务的前提下重新建立连接。对于只在特定网络出现的问题，应分别保留各网络的观测结果，而不是用一次成功覆盖之前的失败。
按“请求、命中、连接”阅读记录
Logs 的具体显示字段以应用内为准。查阅时先找请求目标，确认它是否就是本次测试的主机；再检查采用的策略与可见的规则信息；最后观察连接错误或响应表现。如果记录只有 IP，不要先假定域名规则失效，应检查请求是否提供了可用名称。如果已经明确命中 REJECT，就先回看拒绝规则的范围，而不是继续调整服务器端口。
| 观察结果 | 优先检查 | 暂不同时修改 |
|---|---|---|
| 没有对应新请求 | 测试动作、既有连接、客户端处理范围 | 整份规则列表 |
| 命中非预期策略 | Global Routing、当前文件、上方规则 | 服务器认证参数 |
| 策略正确但连接失败 | 解析、认证、目标地址及可达性 | 已验证正确的匹配范围 |
| 更新后行为变化 | 配置差异、分组引用、最终兜底 | 所有网络设置 |
对“解析失败”，先确认记录是否取得地址，并检查 General 与 Host 中相关设置。对“连接超时”，继续分辨是代理方向无法建立，还是目标服务没有响应。对“认证失败”，核对已有服务器信息是否完整。不同错误不应共用一个万能修复动作。若无法从单条记录得出结论，可按时间关联相邻的解析与连接记录，但不要把同一时刻所有后台请求都归为本次测试。
缩减为最小配置，再逐项恢复
复杂配置可以通过副本缩减来定位，但缩减时应保留建立连接所必需的已有信息。先移除与目标无关的临时改写和映射，再用一个精确域名规则与 FINAL 形成明确判断。如果最小副本按预期工作，再分批恢复原有条目，每恢复一批都重测同一目标。这样可以找出是哪一批条件改变了结果，而不是在完整文件中不断增加新的补丁。
[Rule]
DOMAIN,api.example.org,DIRECT
FINAL,PROXY这个片段仅用于验证规则选择，不应覆盖你未备份的完整文件。预期是 api.example.org 命中 DIRECT，其他未匹配请求采用 PROXY。若结果仍不一致，先检查副本是否被选用、是否处于 Config，以及看到的记录是否对应新请求。若结果一致但目标仍失败，就应把关注点移到连接路径，而不是继续扩展规则关键字。
维护变更记录与隐私边界
每次修改保留一份简短记录：修改目标、涉及条目、预期结果、实际结果及恢复方式。导出配置时检查是否包含服务器地址、认证信息、私人订阅链接或敏感 Host 映射；用于讨论时只提供脱敏后的最小片段。日志同样可能包含访问目标与查询信息，应仅保留解释问题必需的内容。常见导入和连接问题可继续查阅问答，首次操作则返回入门指南。
换机前应分别确认应用获取、服务器资料和配置文件的恢复方式。重新从 App Store 获取应用，不等于所有个人配置必然已经恢复；系统要求与购买适用范围以 App Store 页面标注为准。配置迁移可参考配置备份与换机恢复说明。恢复后先核对文件和凭据，再复测关键规则，不要只根据文件名相同就认为内容一致。
完成维护的标准不是“没有再修改”，而是关键目标能够按预期命中，未匹配请求有明确兜底，配置中的每个例外都有可解释用途，并且出现问题时能回到可用副本。把规则选择与连接结果分开验证，把远程内容与个人修改分开管理，后续遇到网络变化或配置更新时，就能沿着同一条观察路径继续定位。