本页是 Shadowrocket 官方手册的系统查阅部分，适合在编辑配置、检查分流或分析异常时按章节定位。首次添加已有订阅、允许 VPN 配置与建立连接，请先阅读快速上手教程；完成基础操作后，再回到这里理解每一条规则为何生效。Shadowrocket 主要用于 iPhone 与 iPad，系统要求以 App Store 页面标注为准。
开始前应已有自己的订阅或服务器信息。客户端一次性买断 ≠ 线路套餐，本站不提供、不销售、不推荐节点或订阅服务。应用获取与正版核对请使用App Store 下载说明。本文示例着重说明语法与边界，不应整段覆盖正在使用的配置。
01 / 文件与作用范围
配置结构与生效条件
先分清服务器信息与配置文件
服务器信息决定请求通过哪个已有服务建立连接，配置文件决定请求满足什么条件时选择哪种处理方式。这两类内容有关联，却不是同一件事。导入订阅后，Home 中的 SERVER 列表可能已经出现条目，但这不代表 Config 中已经选中了合适的分流配置。反过来，一份写有 PROXY 的规则文件也不会自动补齐服务器地址、端口或认证信息。检查连接前，应分别确认当前使用的服务器与当前选中的配置，避免把列表更新误当作规则更新。
.conf 是用于组织配置文本的文件形式。阅读时先找方括号包围的分段标题，再看该段内部的内容。General 通常容纳全局参数，Rule 容纳按顺序排列的匹配规则，Host 容纳域名映射，URL Rewrite 容纳地址重写条目。分段标题不是普通说明文字；少写括号、把规则粘到另一个段落，或者在编辑过程中删掉换行，都可能改变解析结果。不要只检查某条规则拼写正确，还要检查它处于哪个分段。
用最小片段辨认各段语法
[General]
bypass-system = true
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT
[Host]
lab.example.com = 192.168.1.20这个片段包含三种不同的书写结构。General 与 Host 使用等号表达参数或映射关系，Rule 使用英文逗号分隔规则字段。域名后缀规则的第二个字段是匹配内容，第三个字段才是策略；FINAL 没有独立的匹配值，因此直接跟策略。示例中的私有地址仅说明 Host 格式，只有在用户实际网络中存在对应主机时才有意义。它不是推荐配置，也不包含连接服务所需的全部内容。
将不同段的语法相互套用是常见错误，例如把 DOMAIN-SUFFIX 后面的逗号改成等号，或把 Host 映射写成一条 Rule。复制代码时还应检查标点是否变成中文全角字符，域名两侧是否带有从网页复制的引号，以及文件是否混入富文本格式。保存后优先观察应用是否报告解析问题；若报告行号，应同时检查该行与前一行，因为缺失换行或分段边界可能让错误在下一行才显现。
保存、选中与应用是三个核对点
配置编辑完成后，先保存，再返回 Config 确认实际选中的是刚修改的文件，最后核对 Home 中的 Global Routing 是否为 Config。只修改一个未被选中的文件，当前连接不会因此按新规则工作；处于 Proxy 或 Direct 时，也不能把请求表现当作 Rule 顺序的验证结果。不同应用内页面的入口位置可能调整，应以当前界面显示为准，但“文件内容、选中对象、运行姿态”这三个核对点始终应分开记录。
远程配置与本地编辑也应分开管理。若文件之后会从远程地址更新，本地加入的规则可能在更新时被替换。需要长期保留的改动，先在应用允许的文件管理方式中制作独立副本，再进行编辑，并保留原文件用于回退。不要在唯一可用的配置上一次改动多个分段。先验证一个域名规则，再补充其他规则，出现异常时才容易判断是内容错误、选中错误还是更新覆盖。
若希望先掌握文件分段的阅读方式，可结合.conf 结构详解逐段对照。查阅本文后续章节时，始终保留一份当前文件的完整上下文：单独一行正确，只说明这一行符合某种语法，并不说明整份配置已适用于当前网络与业务。
02 / 全局参数与域名映射
General 与 Host
General 不是 Rule 的替代品
General 中的参数作用于配置的整体处理环境，不能把它当作按网站逐条分流的列表。例如 bypass-system = true 表达系统流量旁路相关设置，而不是“所有网站都走 DIRECT”。这一类设置可能使部分流量不进入普通规则判断，因此分析请求时，要先确认它是否属于当前可观察、可处理的范围。不要仅凭配置中存在 FINAL，就推断设备上的所有连接必然经过该条规则。
修改全局参数前，先说明要解决的具体问题：是域名解析失败、局域网访问异常，还是某类请求没有出现在记录中。只有明确问题，才有条件判断相关参数是否适合修改。把网上看到的一整段 General 直接覆盖原配置，可能同时改变 DNS、旁路和连接行为，随后即使网站恢复访问，也难以知道是哪项改变产生了作用。应保留原值，一次只调整一个参数，再用相同请求做对照。
[General]
bypass-system = true这个示例只展示布尔参数的书写：参数名、等号和值分别保留英文原文。不要根据名字自行推演额外参数，也不要把其他配置格式里的键名直接搬入 .conf。应用内能够识别的参数及其实际作用，应以当前应用支持情况为准。遇到不认识的键，优先查看现有配置说明与应用提示，而不是反复尝试近似拼写。一个文件能被保存，并不能单独证明每项参数都按预期参与运行。
Host 改变映射，不直接指定策略
Host 的基本作用是把指定域名映射到指定地址。它回答“这个名称对应哪个地址”，Rule 则回答“这个请求应采取什么策略”。把一个域名放入 Host，并不等于把它设为 DIRECT；如果域名规则先匹配到 PROXY，请求仍需按匹配结果处理。相应地，Host 映射生效后，后续涉及目标地址的判断可能面对不同的地址值。分析这类配置时，要把名称、解析结果与策略三项分别写清楚。
[Host]
lab.example.com = 192.168.1.20
[Rule]
DOMAIN,lab.example.com,DIRECT
FINAL,PROXY这里同时写出映射和域名规则，是为了明确两者的分工。lab.example.com 是示例名称，192.168.1.20 是私有地址，实际使用时必须替换为用户自己网络中确实存在的主机。即使规则选择 DIRECT，设备也仍需具备访问该私有地址的网络条件。若不在对应局域网，或目标设备没有开放所需服务，规则匹配正确也无法让连接成功。分流判断与目标可达性不能混为一个结果。
检查 DNS、缓存与连接复用的边界
Host 不会自动修改应用层身份。访问 HTTPS 域名时，服务器证书仍应与所访问的名称相符；映射到一个不提供该域名服务的地址，可能出现证书或握手错误。这时继续添加 DIRECT 规则通常不能解决问题。应先检查目标地址是否正确、服务是否监听相应端口，以及服务器是否确实为该域名提供服务。不要通过放宽与问题无关的设置掩盖名称和服务之间的不一致。
修改域名映射后，旧解析缓存或已有连接可能暂时影响观察。先结束目标应用的相关会话，再发起新的请求；必要时按应用内可用的工具检查 DNS 结果，并区分新请求和旧连接。记录应包含测试域名、预期地址、实际地址以及命中策略。如果只记录“网页打不开”，无法判断是映射未应用、服务不可达还是请求并未重新建立。相同测试条件比反复切换许多开关更有排错价值。
最后检查配置内是否同时存在同名 Host 项、较宽泛的域名规则及地址规则。不要依赖重复映射的先后行为来表达意图，能合并为一条明确映射就先合并。对于公共网站，地址可能随服务部署变化，长期固定映射需要用户自行维护；对于自有局域网服务，应确认设备地址稳定。规则维护不只是让文本能解析，还包括让配置中的名称与实际网络持续对应。
03 / 名称匹配
DOMAIN 与域名规则
按精确名称、后缀与关键词选择范围
域名规则优先解决“已知请求名称”的分流问题。DOMAIN 面向一个完整域名，DOMAIN-SUFFIX 面向该域名及其子域名，DOMAIN-KEYWORD 则按名称中是否包含指定文本判断。三者都不以 URL 路径为匹配对象：域名之后的斜杠、查询参数和页面片段不属于这些规则的匹配值。若只想处理 api.example.com，不应直接填入带有 https:// 的完整地址，更不能期待域名规则区分同一主机上的两个页面。
| 关键字 | 示例值 | 匹配边界 |
|---|---|---|
DOMAIN | api.example.com | 指定的完整主机名，不扩大到其他子域名。 |
DOMAIN-SUFFIX | example.com | example.com 本身及其子域名，不等于任意包含该字符串的名称。 |
DOMAIN-KEYWORD | example | 名称中包含指定文本，可能涵盖不同域名后缀。 |
选择规则时，应先使用能准确表达需求的较小范围。精确主机用 DOMAIN，整组子域名有共同策略时用 DOMAIN-SUFFIX，确实需要跨域名后缀按文本识别时才考虑 DOMAIN-KEYWORD。关键词并不天然代表一个组织或一项服务；另一个名称只要包含同样文本，也可能落入范围。将短而常见的词设为关键词，很容易影响本来没有打算处理的请求，而且这种误匹配通常不会表现为语法错误。
用具体例外覆盖宽泛规则
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,REJECT
FINAL,DIRECT在这个教学组合中，api.example.com 先命中精确规则，选择 DIRECT；www.example.com 没有命中第一条，但会命中后缀规则，选择 PROXY；包含 example 文本、却不属于 example.com 的其他名称，才可能到达关键词规则并被拒绝。这里不是应用自动比较三种规则谁更精确，而是前面的匹配先结束判断。若把关键词规则放在最前，后面两条就无法为同样包含该词的请求提供例外。
DOMAIN-SUFFIX 的值通常写为 example.com，不需要前置星号，也不要把通配符的写法与该类型混用。它表达域名标签边界上的后缀关系，因此 notexample.com 不应仅因结尾字符相似就被视作 example.com 的子域名。对含特殊字符、国际化域名或应用内部转换后的名称，应观察请求记录里实际出现的表示形式，再按真实主机名编写规则，避免仅按浏览器地址栏的视觉文字推断。
请求名称不一定就是地址栏名称
一个页面通常包含多个请求。主文档可能来自一个域名，图片、脚本、登录与接口分别来自其他域名。为地址栏中的域名添加规则后，页面仍有部分内容异常，不一定说明规则无效；应检查失败的那一个请求用了哪个名称。相同原则也适用于应用：应用名称并不等同于它全部服务域名，不能根据图标或产品名推导出完整域名列表。本文不提供服务域名清单，应以用户实际请求记录为依据。
当连接只有目标 IP、没有可供规则使用的域名信息时，域名规则不能凭空推导名称。另一些请求可能经过缓存、应用内解析或不同的连接方式，其记录中的主机字段也可能与预想不同。排查时先确认记录是否包含域名，再判断域名规则是否应参与。不要把“没有命中 DOMAIN”直接归结为客户端忽略规则；可能只是该请求没有以所填写的名称进入匹配流程。
测试域名规则应至少准备三个对照：预期命中的完整名称、同组的另一个子域名，以及不应受影响的相似名称。每次只更改一种规则类型，观察命中项和策略是否随之变化。需要进一步理解各种关键字的范围，可以阅读规则写法入门与匹配范围对照。记录这些边界用例，比只验证一个能打开的网页更能防止后续误匹配。
04 / 地址、地区与其他条件
IP-CIDR、GEOIP 与其他规则
IP-CIDR 按地址段判断，不按网站名称判断
IP-CIDR 的匹配值是 IPv4 地址与前缀长度。192.168.0.0/16 表示一个私有地址范围，不是只匹配 192.168.0.0 这一台主机；前缀越长，所覆盖的地址范围通常越小。编写前先明确实际目标属于哪个网段，不要为了方便把范围不断扩大。某个网站偶尔解析到一个地址，也不意味着整个地址段都应采用相同策略，尤其在共享基础设施上，同段地址可能承载多个互不相关的服务。
[Rule]
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
FINAL,PROXYIPv6 地址范围应使用 IP-CIDR6。示例中的 fc00::/7 是 IPv6 本地地址范围，不能把 IPv6 文本直接填进 IP-CIDR 后就期待相同结果。私有或本地地址的 DIRECT 规则只决定连接方式，不创造到目标网络的路由，也不改变目标设备的访问权限。设备不在对应网络、地址发生冲突或服务未监听时，命中 DIRECT 后仍可能失败，应继续检查网络与服务本身。
no-resolve 的重点是避免为了这条地址规则额外触发域名解析。对于已经以 IP 为目标的请求，仍可按已有地址检查；对于只有域名且缺少可用地址信息的请求，不应期待带有 no-resolve 的地址规则必然识别它。它不是让整个客户端停止解析的总开关，也不是让某个域名永远绕过 DNS 的声明。分析时需同时查看请求是否已有地址，以及前面是否已被域名规则处理。
GEOIP 反映地址数据，不代表服务归属
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYGEOIP 根据目标地址及相应地区数据进行判断。GEOIP,CN,DIRECT 表示匹配到地区代码 CN 的目标地址时选择 DIRECT，不表示按注册主体或用户所在地分类。一个域名可能解析到多个地区的地址，地址数据库也可能与实际部署存在差异。因此，对于明确需要固定策略的重要域名，应写在 GEOIP 之前，而不是把地区判断当作精确的服务分类表。
如果相同域名在不同时间得到不同策略，先检查解析地址是否改变，再检查地区规则的位置。不要在没有记录的情况下认定是 GEOIP 自行改变了顺序。还要区分目标地址所属地区和代理出口所在地区，二者不是一个字段；规则匹配使用的对象与用户之后观察到的出口表现也不应相互替代。地址相关排查必须保留测试时的域名、地址和命中条目，否则下一次请求可能已换到另一个目标。
USER-AGENT 与 FINAL 的使用边界
[Rule]
USER-AGENT,ExampleApp*,PROXY
FINAL,DIRECTUSER-AGENT 按能够读取到的 User-Agent 信息进行匹配。ExampleApp* 是教学用模式，不是实际应用清单，也不是按设备中的应用名称识别进程。加密请求的相关字段并不总是可见，不能把这条规则理解为对某个应用的所有流量进行可靠分类。不要为了让示例命中而额外启用不理解的证书或解密设置；优先采用能够从现有请求信息中验证的域名或地址条件。
FINAL 是剩余请求的兜底，不需要再填写域名或地址。它应放在 Rule 的最后，明确未被前文规则处理的请求去向。把 FINAL 写到中间，后面的普通规则就失去了处理剩余请求的机会。检查长文件时，可以先搜索 FINAL，确认它只有一条且位置明确，再检查前面的具体规则。USER-AGENT、地区和地址规则的可用信息各不相同，选择规则前先确定请求提供什么信息，比不断追加条件更有效。
05 / 执行结果与全局姿态
策略与 Global Routing
PROXY、DIRECT、REJECT 回答不同问题
规则前半部分判断是否匹配，策略字段决定匹配之后如何处理。PROXY 表示使用当前代理选择，DIRECT 表示直连目标，REJECT 表示拒绝该请求。策略名称不是域名，也不是服务器地址；不能把 PROXY 改成一个临时说明词就期待应用自动理解。若原配置使用命名策略组，应先确认相应对象确实存在及其选择关系，再引用名称。本文用基础策略示例，避免让未定义的组名进入可复制片段。
| 策略 | 匹配后的处理 | 仍需核对 |
|---|---|---|
PROXY | 交给当前代理选择处理。 | 服务器信息、认证、网络可达性及服务状态。 |
DIRECT | 直接连接目标。 | 本地网络、解析结果和目标服务是否可达。 |
REJECT | 拒绝匹配请求。 | 规则范围是否过宽、是否误伤必要依赖。 |
命中 PROXY 不等于请求成功。服务器信息失效、认证不符、网络限制或目标服务异常，都可能发生在规则判断之后。同样，DIRECT 也不是“强制成功”的指令，它只改变连接路径。排错时应把两层结果分开：先看选中了什么策略，再看该策略下连接为何失败。只根据页面是否打开反推规则是否命中，容易把传输问题误当成语法问题。
Global Routing 决定是否按配置分流
Global Routing 的三种姿态是配置 Config、代理 Proxy、直连 Direct。这里的界面词与 Rule 中的大写策略词有关，但不是同一个层级。Config 用于按选中的配置处理请求；Proxy 与 Direct 可用于观察对应全局姿态下的表现。验证一条 DOMAIN 或 IP-CIDR 时，首先应回到 Config，否则即使文件完全正确，所观察的流量也未必在按该段 Rule 进行判断。
| 界面姿态 | 查阅重点 | 测试用途 |
|---|---|---|
| 配置 Config | 当前配置、规则顺序与策略。 | 验证本文中的分流示例。 |
| 代理 Proxy | 当前代理选择及连接状态。 | 辅助区分代理连接问题与分流问题。 |
| 直连 Direct | 本地网络及目标服务。 | 辅助观察直连路径是否可用。 |
切换姿态只是一项对照操作，不应直接成为长期解决方案。某个请求在 Proxy 下成功、在 Config 下失败，可能说明 Config 中选了 DIRECT，也可能说明命中了 REJECT，或者当前配置根本不是预期文件。应回到记录中确认实际结果，再修改相应规则。测试完成后恢复原定姿态，避免后续使用环境已经改变，却继续按旧条件解读结果。
用拒绝策略时保留例外和回退
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY这个片段展示同一后缀下的不同处理方式，不代表这些示例名称的真实服务用途。api.example.com 先被指定为 PROXY，metrics.example.com 被单独拒绝，其余 example.com 子域名才落入 DIRECT。若把后缀规则移动到最前，两个具体例外就不会按原意执行。策略设计与顺序设计必须一起检查，不能只盯住最后一个策略字段是否拼写正确。
使用 REJECT 时，应留意业务依赖关系。一个看起来只是辅助功能的请求，可能参与登录、资源校验或会话续期。出现局部功能异常时，先临时移除那一条拒绝规则并重新建立请求，不要一次删除整个规则段。确认因果关系后，再缩小匹配范围或补充前置例外。需要核对 Global Routing 与 Home 的位置关系，可阅读首次打开与 Home 区块说明，但服务器本身的可用性仍需独立验证。
06 / 顺序与冲突
匹配顺序与优先级
先命中的规则先决定结果
Rule 段按顺序检查普通匹配规则，命中后采用相应策略，不继续寻找一个“看起来更精确”的后续条件。因此，优先级首先来自排列位置，而不是规则名称。DOMAIN 并不自动高于 DOMAIN-SUFFIX，IP-CIDR 也不天然低于 GEOIP。写配置时，可以使用“具体例外在前、一般范围在后、FINAL 收尾”的组织方式，让阅读顺序与实际判断顺序保持一致。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY以 api.example.com 为例，第一条就足以确定 DIRECT，不会再因为后缀属于 example.com 而改成 PROXY。对于 www.example.com，第一条不匹配，第二条匹配后结束判断。对于直接访问的私有地址，如果前面的域名条件没有参与或没有命中，则可继续到 IP-CIDR。只有此前没有匹配的请求才会走向 GEOIP 或 FINAL。逐条模拟时，应明确每一步使用的请求信息，而不是假定所有请求都同时有完整域名和地址。
重叠不一定是错误，遮蔽才需要解释
一条精确域名规则与一条后缀规则同时覆盖相同请求，可以是刻意设计的例外；两个相同条件指向不同策略，则通常需要合并或说明。后出现的完全相同条件不会为同一请求提供第二次选择。检查大型配置时，先找完全重复，再找包含关系，最后找关键词与后缀之间的交叉。不要仅根据行数判断规则丰富程度，重复项会增加维护负担，却未必增加有效行为。
如果把一条规则从底部移到顶部后问题消失，应进一步判断它原来被哪条规则遮蔽。直接保留“所有新增规则都放最上面”的习惯，会让顶部逐渐积累彼此冲突的例外。正确做法是找到最早命中的宽泛条件，把必要例外放在它前面，并保留清楚的业务分组。对于同一域名，多次加入相反策略只会让后续维护者难以确定哪一条才是有效意图。
用请求表验证规则移动的影响
编辑前可以列出一张小型预期表，至少包含“目标、预期策略、预期命中条件”三项。选择一个具体例外、一个一般子域名、一个私有地址和一个兜底目标。移动一条规则后，不仅测试刚刚出问题的目标，也重新检查其余对照项。这样能够发现修好一个例外却破坏整个后缀范围的情况。测试目标应来自用户实际业务，不能把本文示例域名是否可访问当作配置正确性的标准。
地址规则之间的顺序也遵循同样原则。例如一个较小地址范围需要 PROXY，而它所属的大范围设为 DIRECT，就应把较小范围放在前面。若 GEOIP 提前处理了某个地址，后面的地址例外可能没有机会执行。这里的“具体优先”是编写者通过排序表达的约定，不是运行时自动按前缀长度进行全局排序。不要把网络路由表的其他匹配习惯直接套用到 Rule 列表。
当配置包含远程规则引用或其他扩展内容时，还应核对这些内容位于整个判断链的什么位置。不能只阅读手写的几行，就推断文件没有更早的宽泛条件。遇到无法解释的命中，先回到完整文件，从 Rule 起点按实际顺序检查，必要时复制为最小测试配置逐步加入条目。简化是为了定位影响条件，确认后仍应恢复原配置中的必要段落，而不是长期用一个删减过度的文件代替完整设置。
07 / 地址重写与组合示例
URL Rewrite 与常见写法
重写地址不等于指定代理策略
URL Rewrite 用于按模式处理请求地址，与 Rule 中选择 PROXY、DIRECT 或 REJECT 是两种不同操作。域名分流决定连接走向，重写条目则可能改变请求所指向的地址或返回重定向。不要为了让一个域名走代理而添加重写规则，也不要把普通域名规则粘进 URL Rewrite。需要的只是访问路径选择时，优先在 Rule 中表达；只有确实需要改变地址行为，才考虑重写段。
[URL Rewrite]
^http://example\.com/ https://example.com/ 302这条示例由匹配模式、替换地址与重定向状态码组成，用于说明一个受限的 HTTP 到 HTTPS 地址重定向。模式中的点使用反斜杠转义，开头的 ^ 限定从地址起始处匹配，域名后的斜杠帮助明确主机边界。不要从这条短例推断任意原始路径与查询参数都会按期望保留；如果业务要求保留这些内容，需要明确设计捕获与替换，并逐项验证实际结果。
对于 HTTPS 请求，地址中的路径等信息并不总能以同样方式读取。普通域名分流不要求看到完整 URL，而路径级重写需要相应请求信息可见。因此，“域名规则能命中”不能证明重写模式也一定能执行。不要为测试示例而随意增加证书或解密配置。先确认当前请求类型与应用可观察的信息，再决定是否适合使用 URL Rewrite；无法确认时，保留原始请求行为更便于排错。
将规则意图拆成可独立验证的组合
[Rule]
DOMAIN,lab.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY
[Host]
lab.example.com = 192.168.1.20这个组合同时演示局域网名称映射、单域名拒绝、整个后缀代理与私有地址直连。阅读时先看两条具体域名例外，再看后缀范围，最后看地址与兜底。lab.example.com 的映射让它指向示例私有地址，而前置 DOMAIN 明确选择 DIRECT；blocked.example.com 先被拒绝，不会被后面的后缀 PROXY 覆盖。示例没有附加重写，是为了让每一项都能在较少变量下独立核对。
实际应用时应先复制一份用户现有配置，只加入最必要的一条规则。若只是某个接口需要不同策略，就先加精确 DOMAIN，不必同时引入 Host、GEOIP 与重写。等精确规则通过验证，再考虑是否应扩大到 DOMAIN-SUFFIX。配置的复杂度应来自真实需求，而不是示例包含多少种关键字。每增加一个分段，都会增加一个需要独立解释和测试的处理环节。
避免循环、过宽模式与订阅概念混用
重定向测试要关注最终地址与跳转次数。如果新地址再次满足原模式，或者目标站点又把请求引回原地址，就可能形成循环。应先选单个可控路径观察响应，再扩大匹配范围。正则表达式中的点、问号和括号具有特殊含义，不能把普通 URL 不加检查地当作模式使用。模式写得过宽，即使语法合法，也可能处理了原本不应修改的请求，导致登录状态或资源路径异常。
服务器订阅与配置文件地址也不要混用。用户已有订阅用于导入服务器条目，并不必然返回 .conf 文本；配置文件地址则应返回应用能够识别的配置内容。示例 https://example.com/sub?token=xxxx 只是明显假值，不是可用服务。拿不确定的地址导入 Config 后出现解析错误，应先确认返回内容类型、账户状态及地址用途，不要通过添加 Rule 关键字尝试修复一个实际上不是配置文件的响应。
分享配置供他人检查时，只保留能复现问题的规则与分段，移除个人订阅地址、认证内容及其他敏感信息。说明“期望哪个请求走什么策略”，而不是只发一整份文件让对方猜测。关于常用界面词与策略名称，可查阅概念速查。组合配置的目标是让每个处理环节都能被解释，而不是让一份文件承担所有可能的网络调整。
08 / 操作闭环
验证、维护与排错
按固定顺序建立一次有效测试
一次有效测试需要固定输入和环境。先记录当前网络、Global Routing 姿态、选中的配置及代理选择，再记录要测试的完整主机名与预期策略。保存修改后，返回 Config 核对文件，切回 Config 姿态，然后重新发起目标请求。测试期间不要同时更新订阅、更换服务器和切换网络，否则请求恢复或失败都无法对应到单一变量。配置排错的关键是可重复，而不是连续点击许多按钮。
在应用内可用的请求记录或诊断页面中，重点核对目标域名、目标地址、命中规则和策略；具体字段以当前界面为准。某些请求可能不提供全部信息，应如实记录缺项。Connectivity Test 可辅助了解测试条件下的连接表现，但不能替代业务请求的规则验证。测试成功只能说明该测试对象和条件下得到某个结果，不能保证所有网站或所有应用请求均采用相同路径。
- 确认文件已保存，且 Config 中选中的就是该文件。
- 确认 Global Routing 为 Config，并检查当前代理选择。
- 结束旧会话，发起一个明确的新请求。
- 核对命中条件与实际策略，不只看页面是否打开。
- 重新测试例外、一般范围和兜底目标，确认影响边界。
按现象区分解析、匹配与传输问题
如果配置不能被正常读取，先处理文本结构：检查分段标题、英文标点、字段数量以及策略名称。DOMAIN 规则通常有类型、值、策略三部分；FINAL 则直接跟策略，不能为了凑字段再补一个域名。检查代码复制过程中是否混入说明文字，特别是网页标题、行号与自动换行符。确认文件能被应用识别后，再讨论它如何处理请求，避免在解析尚未完成时研究网络表现。
如果文件可读但命中错误，按顺序检查当前文件是否选中、是否处于 Config、请求实际名称是否与规则一致、前面是否存在更宽泛规则，以及 FINAL 是否提前出现。若域名规则没有机会使用名称，应检查请求是否只提供目标地址；若地址规则带有 no-resolve，应检查是否已经有可用地址信息。每个分支都应找到对应证据，不要把未观察到命中统称为“规则失效”。
如果命中正确但连接失败，就进入传输层排查：PROXY 侧检查用户已有服务器信息与认证，DIRECT 侧检查本地网络及目标服务，REJECT 则先确认是否确实希望拒绝。DNS 失败、连接超时与证书错误代表不同阶段，不应通过同一种规则修改处理。可临时使用 Proxy 或 Direct 做同目标对照，但测试后要恢复原姿态，再回到 Rule 中修正真正的问题。
修改后仍显示旧策略，应该先检查什么？
先核对选中的文件和 Global Routing，再结束旧连接、发起新请求。确认记录来自新会话后，才继续排查缓存、前置规则或远程更新覆盖。
命中 PROXY 后仍然超时，还需要增加域名规则吗？
通常先检查已有服务器的可达性、认证和目标服务。既然已命中预期策略，重复添加相同域名条件并不能直接解决后续连接失败。
保留可回退的维护记录
配置维护应保留修改前后的差异、修改原因和验证目标。可以在自己的记录中写明“将某个精确域名移到后缀规则之前，以保留直连例外”，而不是仅写“优化规则”。定期整理重复项、长期不用的例外与失效的 Host 映射，但不要在同一次维护中大幅改变所有层级。远程配置更新后，应重新检查本地例外是否仍在，以及原来的顺序是否被改变。
出现无法解释的问题时，先回退到最近一次验证可用的文件，确认基础连接恢复，再在副本中重现单个改动。如果回退后同样失败，应考虑网络、服务或订阅状态已变化，而不是继续把问题限定在刚修改的规则。需要重新检查首次连接流程时返回快速上手教程；需要核对应用来源与已购恢复时查看已购恢复说明。提交排错信息前先去掉个人凭据，只保留最小规则、请求条件与实际结果。