Shadowrocket
规则与配置字段

配置文件结构与生效前提

配置文件不是服务器清单

配置文件负责描述客户端怎样处理请求，服务器信息负责描述怎样建立连接，两者需要分别检查。导入订阅后能在 Home 看到条目，只能说明服务器数据已进入客户端，不能据此认定某份规则文件已经启用。反过来，配置文件能正常保存，也不说明其中使用的 PROXY 策略拥有可用连接。排查时应先把这两个对象分开，避免用替换规则的方式处理服务器凭据问题。

在 Config 中确认当前选中的配置，再检查 Global Routing 是否为 Config。这个模式按当前配置处理流量，是阅读本页 Rule 示例的前提。切换到 Proxy 或 Direct 后，请求处理路径会改变，不能继续用同一份规则命中预期判断配置对错。文件名称只用于识别，名称相同不代表内容相同；多个文件并存时，尤其需要确认选中状态和实际保存的文本。

用段名划分职责

段名放在方括号内，决定后续各行按哪一种语法解释。General 常见形式是键和值，Rule 常见形式是用英文逗号分隔的规则字段，Host 则把域名映射到地址。把域名规则粘贴到 Host 下，或者把通用设置粘贴到 Rule 下，即使文字看起来完整，也不能获得原本预期的效果。编辑时先定位段名，再插入正文，比只搜索某个关键词可靠。

[General]
dns-server = system

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

[Host]
router.example.com = 192.168.1.1

上面的文件包含三个不同职责的段落。域名后缀规则选择连接策略，Host 行指定某个主机名的解析地址，两者不是同一种覆盖关系。该示例采用 DIRECT 兜底，是为了让匹配范围清楚可见，并非所有场景都应采用这个默认值。需要更换兜底策略时，应先明确未匹配请求应当怎样处理，再检查选定连接是否有效，不要凭文件名称判断用途。

建立可回退的编辑流程

修改之前先导出或保留当前配置副本，给试验文件使用能辨认用途的名称。打开副本后，一次只更改一个配置段或一组紧密相关的规则。保存完成，再重新确认 Config 中的选中项；如果编辑的是另一份文件，仅保存文本不会让正在使用的配置自动变成它。测试结束后记录改动目的，成功则保留，失败则退回已验证的副本，而不是继续叠加不确定字段。

配置文本中的标点也属于语法。规则使用英文逗号，键值设置使用英文等号，地址范围使用斜杠；从富文本复制时应检查是否混入中文标点、不可见空格或被换行截断的字段。长规则在编辑器里视觉折行，不一定是实际换行；应按文件中的真实行判断。注释可以解释规则意图，但不要用注释代替策略字段，也不要把连接密码写入说明文字。

远程配置更新与手工修改还需要考虑覆盖关系。如果正在编辑由远程来源更新的文件，下一次更新可能改变本地内容。先确认该文件的来源和应用内更新行为，再决定是否建立本地副本维护自己的规则。订阅更新通常针对服务器数据，配置更新针对配置文本，不能因为两者都使用地址就视为同一操作。关于保存与迁移的流程，可继续查阅配置备份与换机迁移笔记。

General 与 DNS 解析边界

通用设置与规则选择分开理解

General 描述配置的通用行为，不按 Rule 的逐条匹配方式工作。这里的设置可能影响域名解析、地址处理和连接环境，但不能把它当成另一份分流列表。检查未知字段时，先在应用内对应的配置编辑或设置说明中核对支持情况，再判断值是否合法。其他文本里出现过的键名不等于当前应用一定识别；一个无法确认用途的字段不宜直接加入正在使用的配置。

DNS 的任务是把主机名解析为地址，Rule 的任务是根据请求信息选择策略。解析成功不等于代理连接成功，策略选对也不等于解析结果正确。比如域名规则已经命中 PROXY，但服务器建立连接失败，问题仍可能在连接参数；又如请求被 DIRECT 接受，却拿到不可访问的地址，应继续检查解析来源和目标服务。把这两个环节分别验证，能缩小修改范围。

先保留简单的解析基线

[General]
dns-server = system

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

dns-server = system 表示使用系统 DNS 作为该设置的解析来源。示例的重点是建立容易回退的基线，不是保证所有网络环境下都有同一种结果。使用系统解析时，当前网络的 DNS 配置会参与结果形成；切换网络后，解析结果与可访问性都可能变化。比较两次测试时，必须记录网络环境是否一致，否则容易把网络差异误判为规则修改产生的效果。

若需要调整 DNS 服务器，应先确认用户自己的网络要求以及当前应用接受的值格式，再修改单个设置。不要同时更换解析来源、增加 Host 映射和重排规则，这会让成功或失败都难以归因。解析服务地址与代理服务器地址不是同一字段，把已有订阅地址放进 DNS 设置也不会导入服务器。设置完成后，应重新发起请求，并结合日志判断获得的地址是否符合预期。

域名、地址与 no-resolve

域名规则在请求域名可用时就能参与匹配，地址规则则需要目标地址信息。对于仅有域名而还没有地址的请求，某些地址匹配需要解析才能作出判断，因此规则顺序可能影响是否发生额外解析。排查解析延迟时，不应只看 DNS 设置；也要检查较靠前的地址规则是否为了判断命中而触发了解析，以及原本可以先匹配的域名规则是否被放到了后面。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT

no-resolve 是地址规则的可选修饰字段，用于避免为这一条匹配主动解析域名。它不表示整份配置关闭 DNS，也不表示请求后续连接无需解析。如果客户端已经掌握目标地址，仍可基于已有地址检查该规则；如果缺少地址，不应期待这条规则通过额外解析把域名归到网段中。不要把它追加到所有规则末尾，域名规则和 FINAL 并不因此获得新的含义。

地址族与缓存造成的差异

同一个主机名可能返回多个地址，也可能同时返回不同地址族。只写一条 IPv4 网段规则，并不自动覆盖 IPv6 目标；反之，配置了 IPv6 地址规则也不能保证网络具备相应连通性。应先观察实际使用的目标地址，再判断规则是否包含它。为了解决某一次失败而随意关闭一种地址族，可能掩盖目标网络或连接设置的问题；相关开关应按应用内说明核对。

修改解析设置后，旧连接、应用缓存和系统缓存都可能继续影响观察。页面刷新并不总是新连接，已有连接也不会因为文本改变而必然重新执行完整匹配。测试应关闭或结束相关请求，再重新发起一次能辨认的访问；必要时按应用内提供的操作更新解析状态。记录域名、返回地址、命中策略和连接结果，比只记录“能打开”或“打不开”更适合比较。

DOMAIN 系列的范围与写法

精确匹配与后缀匹配

DOMAIN 用于匹配一个完整域名，DOMAIN-SUFFIX 用于匹配指定域名及其子域名。两者的差别首先是范围，而不是谁天然具有更高优先级。需要只处理一个主机时，精确匹配更容易限制影响；需要处理一个域名树时，后缀匹配更容易维护。先写出希望包含哪些主机、排除哪些主机，再选择类型，可以避免只因某种写法更短就扩大分流范围。

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

这个例子让 api.example.com 使用 PROXY，其他属于 example.com 的主机使用 DIRECT。例外必须在宽范围规则前面，因为该主机也满足后缀条件。交换前两行后，后缀规则先命中，下面的精确规则就不再决定这次请求。精确匹配的类型名称不会自动让它越过前面的规则；执行顺序始终需要通过文本位置表达。

域名字段应填写主机名，不包含协议、路径、查询参数或端口。访问地址里出现的页面路径不属于 DOMAIN 的匹配值，把整个页面地址粘贴进去通常不能表达预期的主机匹配。需要针对路径改变地址时，应查看 URL Rewrite，而不是给域名规则增加斜杠。编辑完成后先把字段拆成类型、匹配值和策略三部分，确认每部分的职责明确。

关键词匹配要控制范围

DOMAIN-KEYWORD 检查域名中的关键词，范围通常比后缀规则更难从文字直观看出。相同字符串可能出现在不相关的主机名中，因此它不适合代替明确的域名所有权边界。关键词也不是正则表达式，把点号、星号或括号按正则思路填进去，不能据此期待正则匹配。已有明确域名清单时，优先用能准确描述目标范围的条件组织规则。

[Rule]
DOMAIN,keep.example.com,DIRECT
DOMAIN,ads.example.com,REJECT
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT

示例通过前两行保留一个直连例外，并拒绝一个精确主机，随后才让关键词规则处理其余符合条件的域名。这里的 ads.example.com 只是语法示例，不能代表任何真实内容分类。拒绝主机还可能影响页面加载依赖，使用前应确认目标用途。如果误拒绝后页面空白，应从实际请求日志找出依赖关系，而不是立即增加更宽泛的允许规则。

子域名、别名与请求可见性

一个页面可能调用多个主机，包括接口、图片、认证和静态资源。只为浏览器地址栏中的域名写规则，不会自动让其他主机采用相同策略。发现部分内容加载失败时，应列出失败请求对应的主机，分别检查它们是否处于当前后缀范围。也不要因为某个服务使用了同一目标地址，就把它与地址相同的其他域名归为同一个域名规则范围。

域名别名和解析链需要与原始请求主机区分。看到 DNS 结果指向另一个名称，不意味着所有匹配都必然改为检查那个名称；具体可见信息应以当前请求记录为准。直接访问地址时，客户端可能没有足够的域名信息让 DOMAIN 系列命中，这时应检查地址规则和兜底。不要仅凭网页标题或应用名称推断请求使用的主机名。

验证后缀规则时，至少选择根域名、一个子域名和一个范围外域名分别检查。再为前置例外发起独立请求，确认日志里的策略确实不同。若为了临时测试加入了精确规则，应在测试记录中写明原因，完成后决定保留还是删除。随着例外逐渐增加，定期合并重复行、移除过期主机，比无限向文件顶部添加规则更容易维护和回退。

地址规则与 USER-AGENT 条件

IP-CIDR 与地址范围

IP-CIDR 用网段描述 IPv4 地址范围，斜杠后面的数字是前缀长度，不是端口号，也不是要匹配的地址数量。前缀越长，范围越小。检查规则前应确认目标地址属于哪个网络，而不是只比较开头几个字符。多个范围重叠时仍按规则位置选择策略，因此更小范围的例外需要放在包含它的较大范围之前。

[Rule]
IP-CIDR,192.168.1.10/32,REJECT,no-resolve
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,PROXY

示例中的第一行只匹配一个 IPv4 地址，后续两行分别匹配常见私有地址范围。第一行位于更大的范围前面，因此该地址会先被拒绝；若放到后面，就会被已有 DIRECT 规则覆盖。私有地址规则并不意味着任意网络上的同一地址都是同一设备，网络切换后它可能指向不同主机。使用这些范围时，要结合当前局域网和用户自己的连接环境判断。

IP-CIDR6 用于 IPv6 地址范围，不能用 IPv4 的写法代替。示例中的范围与 IPv4 私有地址不是一一对应关系，只是说明不同地址族需要分别表达。一个服务可能同时具有两种地址，命中哪一条取决于实际目标。排查时应记录完整地址，尤其不要因为界面显示了一个域名，就忽略它最后使用的是哪一种地址族。

GEOIP 不是域名分类

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

GEOIP 根据地址的地域数据库信息匹配，不能用域名后缀、页面语言或网站名称替代判断。某个域名使用不同的分发地址时，匹配结果可能随实际地址变化。它适合表达地址归类条件，不适合保证某一整套业务永远使用同一策略。如果对某个域名有明确处理要求，应将域名规则放在地域规则前面，用确定的条件表达例外。

地址数据库可能与服务实际部署情况存在差异，地域命中也不等于服务经营主体所在地。遇到结果与直觉不同的请求，应先核对目标地址和日志记录，再决定是否增加精确域名规则。为了纠正一个域名而改变所有地域流量的策略，通常会扩大影响范围。需要解析才能获得地址的请求，还应结合上一章的 DNS 与 no-resolve 边界判断。

USER-AGENT 的适用条件

[Rule]
USER-AGENT,ExampleClient*,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

USER-AGENT 根据可取得的请求头信息匹配，这里的 ExampleClient* 是用于说明通配写法的示例模式，不是真实应用标识。它不是按应用名称匹配，也不是按设备进程选择策略。只有相关请求信息可见时，这种条件才有判断依据；不能假定所有应用连接都携带相同请求头，更不能把它当成对某个应用全部流量的稳定分类方法。

加密请求的内部头字段并非天然可见。不要为了让一条 USER-AGENT 规则命中，就随意增加证书或改变 HTTPS 处理设置；这类操作涉及独立的信任和访问边界，需要明确授权与用途。对于一般域名分流，先使用 DOMAIN 系列即可。即使某次测试观察到了请求头，也不能据此断定后台连接、其他接口或后续请求都具备相同条件。

综合规则时，先放明确的主机例外，再根据需要放地址范围和地域条件；若采用请求头条件，则单独确认其可见性和匹配范围。检查未命中原因时区分三类情况：字段不存在、字段存在但值不符、前面的规则已命中。三者对应的处理不同，不能都靠调整通配符解决。把每条规则需要的信息写进维护说明，可以减少以后重复猜测。

策略、Global Routing 与匹配顺序

先看模式，再看策略

Global Routing 决定当前采用哪种整体处理模式。Config 是按配置分流，Proxy 是按代理模式处理，Direct 是按直连模式处理；具体效果还要结合应用当前设置与请求类型观察。只有确认 Config 正在使用，才能用 Rule 文本中的逐条匹配解释本章示例。切换模式可用于定位问题，但它不是修复规则的替代操作，测试结束应恢复原来的明确选择。

界面中的 Proxy 与规则中的 PROXY 位于不同层级，不能因为名称相近就认为两者完全相同。前者是整体模式选择，后者是一条规则命中后采用的策略。DIRECT 不经过所选代理连接目标，但仍需要目标地址和本地网络具备连通性。REJECT 则用于明确拒绝，不应把它当成连接失败后的自动备用策略；被拒绝的请求不会因为失败继续向下寻找允许规则。

命中即停，例外在前

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

这份示例从上到下检查。接口主机先使用 PROXY，指定主机先被 REJECT，其余域名树使用 DIRECT；只有前面域名条件未决定结果时，后续地址条件才有机会决定策略。规则类型没有自动排序，也没有“更具体就总能获胜”的隐含权重。文本位置就是优先级的重要表达方式，新增例外时应检查所有可能提前命中的规则，而不是只看紧邻的上一行。

所谓常见的“域名优先、地址兜底”，是维护者安排出的顺序，不是任何配置都会自动遵守的机制。将地址规则放在较前位置，有时会先决定原本希望按域名处理的请求，也可能影响解析需求。是否如此取决于可用请求信息和具体条件。阅读陌生文件时，应顺着真实顺序检查，不要根据分组注释推断优先级；注释写着例外，但行放在宽规则后面，仍然不能生效。

FINAL 的位置和含义

FINAL 是没有额外匹配值的兜底规则，常见写法为 FINAL,PROXY 或 FINAL,DIRECT。它应放在规则列表末尾，让前面的明确条件先作出选择。把 FINAL 放到中间，会使后续规则失去预期的匹配机会；重复添加多个 FINAL 也不能形成轮流尝试的备用链。决定默认策略之前，应先明确未被列举的请求应如何处理。

PROXY 命中后连接失败，不意味着客户端会自动退回 DIRECT，也不意味着继续匹配下一条 Rule。规则决定策略，连接结果是下一环节；只有另行明确设置的相关机制才可能改变后续行为。若需要检查代理是否可用，应对用户已有连接单独测试，核对认证与传输参数。用宽泛直连规则掩盖代理故障，会让日志中的“页面成功”失去原本的验证意义。

按用途组织维护顺序

建议把精确例外、域名范围、局域网地址、其他地址归类和 FINAL 依次组织，并为每组写明用途。顺序不是固定模板，关键是能够解释每个例外为什么位于当前位置。遇到重复规则时，不只删除看起来相同的主机，还要检查策略是否不同、是否存在故意覆盖。宽范围规则前的精确例外可以有意义，宽范围规则后的同范围同策略重复行通常只增加维护负担。

比较 Config 与 Proxy 的测试结果时，要同时记录命中规则和所选连接。若 Proxy 能连接而 Config 失败，优先检查分流到 DIRECT 或 REJECT 的条件；若两者都失败，则继续检查连接与网络。Direct 成功也不能证明代理参数正确。更详细的模式说明见Global Routing 三种模式笔记，修改时仍以当前应用内的实际记录为准。

Host 映射与局域网边界

映射地址，不是选择策略

Host 用于为指定主机名设置地址映射，解决的是“这个名称对应哪个地址”，不是“这个请求使用哪条连接”。映射完成后仍需要检查适用的规则和当前模式。尤其不要因为主机名在 Host 中指向局域网地址，就断定请求一定直连；前置域名规则仍可能选择 PROXY。读取配置时，应把 Host 与 Rule 一起检查，但分别理解它们的职责。

[Host]
router.example.com = 192.168.1.1
service.example.com = 192.168.1.20

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

示例显式为两个主机指定地址，并用精确域名规则声明直连意图。它只适用于用户自己有权访问、且当前网络中确实存在的对应设备。示例地址不是所有网络都能访问的公共入口；如果当前局域网使用不同网段，照抄不能获得服务。配置映射之前应先确认目标设备的地址、端口和服务是否正常，再让域名成为方便辨认的访问名称。

主机名、端口与路径分别处理

Host 左侧写主机名，右侧写对应地址，不把页面路径、协议前缀或端口混进去。映射不负责修改应用所请求的端口，也不会把一个普通网页请求变成另一种协议。目标服务只监听特定端口时，访问方仍应使用正确的访问方式。若映射生效但服务不可达，下一步是检查连接目标与服务监听状态，而不是继续在 Host 值中拼接路径。

Host 也不是后缀规则，不能根据一条具体主机映射就假定所有子域名都会获得相同结果。需要多个主机时，应逐项确认应用支持的写法和各自目标，先使用明确主机名建立可验证的结果。一般分流任务并不需要 Host；如果只是让一个域名走代理，应使用 Rule 表达策略，保留正常解析，避免人为固定地址后增加额外维护工作。

HTTPS 名称检查不会消失

把主机名映射到一个地址，不会替换请求中的主机身份，也不会让目标证书自动适用于该名称。HTTPS 连接仍可能检查证书名称与信任链，目标服务也可能根据主机名选择站点。映射后出现证书错误，应检查服务是否真正支持这个名称，不应把关闭验证视为常规修复。地址可达、域名映射和证书有效是三个独立条件。

对用户自己管理的服务，可以按服务端设置安排正确的主机名与证书，再在当前网络验证。对不由用户管理的服务，任意固定解析地址可能导致访问错误节点，或者在地址变化后持续失败。网络分发服务经常通过解析返回不同地址，长期保留某次观察到的地址可能破坏正常调度。没有明确需求时，优先删除试验映射，让正常解析恢复工作。

切换网络后的维护与回退

局域网映射最常见的边界是网络切换。同一个私有地址在不同网络里可能不存在，也可能对应另一台设备；离开原网络后，原映射不会因为用途不再成立就自动改成公共地址。测试成功后应记录它适用的网络和服务，并考虑是否需要在其他网络停用相关配置。仅凭保存过一次成功记录，不足以证明这条映射在移动网络或其他局域网仍然正确。

排错时先确认当前网络，再直接检查目标地址的服务连通性，然后查看映射后的域名请求是否使用预期地址与策略。若直达地址失败，优先处理网络或目标服务；若地址能访问但域名失败，检查名称、证书和应用请求方式；若两者都正常但策略错误，则检查前置 Rule。这样分层验证，可以避免在 Host 中反复改地址，却遗漏真正影响结果的规则。

删除或修改映射后，应重新发起请求，并注意已有连接与解析缓存可能保留旧结果。维护副本时，在注释里写清每条映射的用途与回退方法，不记录设备凭据。若某条映射只是临时诊断，测试结束就将其移出常用配置；若长期保留，则定期检查目标地址是否变化。配置越明确地限定用途，后来接手检查时越容易判断哪些内容仍然必要。

URL Rewrite 的语法与作用边界

重写 URL，不是域名分流

URL Rewrite 用正则表达式识别请求地址，再按配置执行相应改写。它与 Rule 的目的不同：Rule 选择处理策略，重写改变符合条件的地址行为。只需要让某个主机走 DIRECT 或 PROXY 时，不应加入重写段；只有明确需要把一种访问地址引向另一种地址，且理解应用如何处理这类请求时，才建立相应规则。

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

这个示例匹配指定主机的 HTTP 地址，并用捕获内容构造 HTTPS 目标，末尾的 302 表示重定向状态码。匹配条件、目标和状态码用空格分隔，不沿用 Rule 的逗号格式。它用于讲解结构，不意味着这个域名实际提供对应服务，也不应直接用作任意网站的通用改写。实际配置必须针对用户明确授权和可以验证的访问对象。

锚点、转义与捕获组

正则开头的 ^ 限定从地址开头匹配，末尾的 $ 限定匹配到末尾；域名中的点号使用反斜杠转义，避免被解释为任意字符。括号形成捕获组，目标中的 $1 引用第一组内容。检查规则时应逐项解释这些符号，而不是只把整个表达式当作固定字符串复制。少一个转义或锚点，都可能扩大原本希望限定的范围。

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

第二个例子只处理指定主机下以 /old/ 开头的路径，其他路径不属于这个条件。捕获部分会参与目标拼接，所以需要检查实际输入包含什么内容。查询参数、编码字符和末尾斜杠都可能影响匹配结果，不能只用一个短地址推断所有请求都正确。若目标拼接后多出斜杠、丢失参数或产生不合法地址，应调整表达式，而不是靠更换代理策略处理。

重定向会产生新的请求

重定向响应通常要求访问方再次请求目标地址，新请求可能涉及不同主机、协议或路径，因此还需要重新考虑后续策略和服务行为。原始请求通过 DIRECT，并不保证新目标也使用 DIRECT；目标改变主机时，应分别检查两次请求的规则命中。调试日志里看到多个请求并非必然是错误，关键是它们是否按照预期形成有限、明确的跳转过程。

必须避免把目标再次写回会命中同一条件的地址，否则可能产生循环跳转。检查时至少列出原始地址、改写目标和目标是否再次符合条件三项。较宽的正则放在前面也可能抢先处理后面的精确条件，因此应先放范围小的特例，再放经过验证的普通规则。正则越来越复杂时，分成几个可解释的条件通常比继续增加嵌套更容易排查。

HTTPS 可见性与访问边界

普通连接转发不能直接读取加密请求内部的完整路径与头字段，因此不能假设一条针对 HTTPS 路径的重写规则天然可见。涉及 HTTPS 内容处理时，需要独立理解应用内相关设置、证书信任和目标范围，本页的简单示例并不要求开启这些能力。只为修复一般连接故障而增加内容处理设置，会把问题从规则分流扩大到信任与兼容性，应避免这种混合排错。

即便用户对目标服务有管理权限，也应只处理明确需要的主机和路径，保留原配置作为回退基线。改写可能影响认证跳转、跨主机请求、表单提交和服务端对地址的校验。先用普通读取请求验证地址变化，再检查实际业务流程；不要用一次页面打开成功替代完整验证。对携带敏感参数的地址，测试记录中只保留必要的脱敏结构，不导出完整访问数据。

维护时为每条重写记录目的、匹配边界和撤销方式。失效后先停用对应行，确认原始地址能否正常访问，再判断是服务变化还是表达式问题。Rule 与重写同时修改时，很难判断是哪一层改变了结果，因此应分两轮测试。确实只需要主机分流的场景，回到域名规则即可；没有重写需求的配置可以完全不包含这个段落，不必为了结构完整而添加空操作。

配置验证、故障分层与回退

建立可以解释的测试配置

验证从已知可用状态开始，而不是从一份不断追加字段的复杂文件开始。先确认用户已有服务器能完成基本连接，再在副本中保留必要通用设置、少量明确规则和一个 FINAL。暂时移出不参与本次目标的 Host 与重写规则，这不是断定它们错误，而是减少变量。基线稳定后再逐组恢复，每恢复一组就用相同请求观察一次。

[General]
dns-server = system

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY

这份示例可以检查精确代理例外、明确拒绝、后缀直连和默认代理四种结果。它仍然只是语法样本，真实验证要替换为用户自己有权访问且状态已知的目标，不把示例域名是否提供网页作为客户端是否正常的依据。每个测试目标只承担一个验证目的，尽量避免同时依赖多个未知接口。这样出现差异时，可以定位到具体条件而不是整份文件。

保存不等于已经重新测试

保存后重新确认当前 Config、Global Routing 和当前连接，再结束原有测试请求并发起新请求。已有长连接可能延续先前路径，应用缓存也可能直接显示旧内容，因此页面没有变化不能立即证明新规则无效。观察应用内连接或日志信息时，核对请求主机、目标地址、命中条件和实际结果，确保查看的是修改之后产生的记录。

区分语法、匹配和连接故障

语法问题通常表现为无法正常载入、某行被忽略或设置未按预期识别。先检查英文标点、段落位置、额外字段和真实换行，再将最近加入的内容移出副本对照。匹配问题则表现为请求采用了不同策略，应从列表顶部找第一条满足条件的规则。若该请求没有域名或地址信息，也要把“条件所需信息不足”作为独立原因，而不是只怀疑字段拼写。

策略正确但连接失败时，继续检查服务器、解析、目标服务和本地网络。Connectivity Test 可帮助观察连接情况，但一次测试不能替代所有协议和业务请求的验证。已有服务器参数应与用户自己的服务资料逐项核对，包括地址、端口、认证及传输相关设置。不要因为延迟测试有结果就认定所有目标均可访问，也不要因一个目标失败就更改整份分流默认值。

拒绝造成的失败要单独识别。命中 REJECT 后目标无法访问，是该策略的直接结果，不是代理连接质量问题。若拒绝影响了不希望阻断的业务，应缩小匹配范围或调整前置例外，并重新测试页面依赖。域名关键词规则尤其需要检查误命中；修正时优先改为明确主机条件，不用覆盖整个域名树的允许规则抵消一个过宽拒绝条件。

回退与变更记录

每次修改记录三个要点：原本出现什么现象、改变了哪几行、哪些请求验证了结果。记录应能帮助以后复现，不需要保存真实订阅地址、认证信息或完整访问日志。导出配置之前检查是否包含用户自己的敏感数据；给其他人查看排错片段时，只提供相关段落和脱敏后的请求条件。配置示例中的明显示例值与真实凭据应始终分开管理。

更新远程配置或订阅后，先检查哪些对象发生变化，再复用原来的测试清单。服务器数据变化可能影响 PROXY 连接，规则变化可能影响匹配，不能把两种更新混在一次结论里。若新状态不可用，退回已验证的本地副本，并确认选中状态确实切回；只把旧文件保存在列表中并不构成回退。恢复之后再逐项定位差异，不继续在故障文件里累积临时补丁。

本页负责解释配置机制，首次导入、开启连接和基础验证请返回快速上手教程；字段名称需要简短解释时查阅概念速查。购买、原账号恢复及商店兼容性事项使用已购恢复说明，不通过修改配置处理。把问题放回所属层级，再使用最小改动验证，是维护长期可读配置的基本方法。