CONFIGURATION REFERENCE 官方手册 · 系统查阅

Shadowrocket 配置字段与规则参考

从配置文件结构到规则命中结果，按字段查语法，按现象查原因。本文以用户已有自己的订阅或服务器信息为前提，不包含连接服务的获取指引。

入门指南负责首次导入、选择 Global Routing（全局路由）与建立连接的操作主线；本页解释每个配置段如何影响结果，适合在完成首次连接后查阅。首次使用时先走完教程，再回到对应章节修改配置。

01 / STRUCTURE

配置文件结构与启用关系

先区分服务器信息、订阅与 Config

服务器信息描述如何建立到指定服务端的连接，包括协议、地址、端口以及认证参数。Subscribe（订阅）用于导入和更新用户已有的服务器条目。Config 则负责通用选项、域名解析、请求匹配与策略分配。三者用途不同，导入订阅成功并不表示已经采用某份规则，也不能据此判断所有请求都会经过当前选中的服务器。

检查配置时，应先在 Home（主页）确认当前可用的服务器，再查看 Global Routing 的姿态，最后到 Config 确认实际启用的文件。仅在编辑器中打开一份文件不等于它已经生效；保存一份副本也不必然改变当前选择。排错记录中应同时写明这三个状态，否则同一条规则可能因测试入口不同而表现不同。

方括号段名与逐行语法

Shadowrocket 的常见配置使用方括号标记段落。General 保存通用键值，Rule 保存按顺序检查的规则，Host 保存指定主机映射，URL Rewrite 保存网址改写表达式。段落名称是语法的一部分，不应改成中文。空行主要用于阅读分组；字段之间使用半角标点，中文逗号、全角等号或富文本引号都可能使解析结果偏离预期。

# 配置结构示意；不包含服务器连接参数
[General]
dns-server = system
ipv6 = false

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

[Host]
intranet.example.com = 192.0.2.10

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

这份片段只展示各段如何排列，不能替代用户已有的完整连接配置。示例的域名与地址都用于文档说明；尤其 Host 的映射不会凭空创建一台内部服务器。实际合并时，应把对应行放进已有的同名段落，而不是在文件末尾反复添加重复段头，更不能将规则行放到 General 的键值列表中。

配置段主要职责检查重点
[General]通用行为与解析选项键名、值类型与网络条件
[Rule]请求匹配与策略规则顺序与兜底策略
[Host]指定主机地址映射主机名与地址是否对应
[URL Rewrite]请求网址改写或重定向正则范围与目标网址

本地修改与远程更新的边界

如果配置来自远程地址，应先了解更新动作会替换哪些内容。远程文件重新获取后，本地编辑可能被覆盖；服务器订阅更新与配置更新也未必是同一个动作。需要长期保留的规则应记录到可控制的配置副本中，并保留来源说明。不要依靠记忆重新拼接，否则几次更新后很难确认哪条规则来自原文件、哪条是后续添加。

建议以用途命名副本，例如“日常配置”和“规则测试”，而不是用含糊的数字区分。副本建立后，先在不改内容的情况下启用一次，确认基础连接与原文件一致，再开始编辑。这样可以把复制、切换与规则修改分开验证；若第一步就出现差异，应检查文件内容和选中状态，而不是继续叠加新设置。

配置中可能含有用户自己的服务器信息、私有地址或认证内容。分享问题时只保留相关段落，并替换敏感值，同时保留逗号位置、键名和字段顺序。只截取最终错误提示通常不足以诊断，而直接公开完整配置又会暴露不必要的信息。最有效的材料是已脱敏的最小片段、预期结果与实际命中记录。

阅读其他配置示例时，还要区分“段落语法正确”和“适合当前环境”。同一条规则在不同 DNS、不同出口和不同 Global Routing 姿态下可能产生不同结果。移植前逐行解释用途，无法说明用途的行先不加入。配置越复杂，越需要明确每个选项解决的是哪一个可观察问题。

02 / GENERAL

General 通用字段与 DNS 解析

键值选项不等于分流规则

General 使用“键名等于值”的形式描述通用行为，与 Rule 的逗号分隔结构不同。修改这一段往往影响多个域名，不宜把它当作修复单个网站的首选入口。出现访问异常时，先确认问题是解析失败、地址不可达还是规则走错，再决定是否需要修改通用字段，避免一次调整使原本正常的请求也改变行为。

dns-server = system 表示使用系统提供的解析设置。它适合作为理解流程的起点，但并不保证任何网络环境下都能得到同样结果。网络切换、系统配置及域名本身的解析策略都可能改变返回地址。若用户已有明确的解析服务器要求，应按其技术说明填写；不要仅因某个地址在示例中出现就认定它适用于当前网络。

[General]
dns-server = system
ipv6 = false
skip-proxy = 127.0.0.1, localhost

ipv6 = false 是布尔值写法示例，不是要求所有用户关闭 IPv6。是否启用应同时考虑当前网络、服务端能力和目标地址。关闭后成功只能说明访问路径发生变化，不能直接证明故障原因。应保留启用前后的解析记录，区分原本返回了不可达的 IPv6 地址，还是其他设置随连接重建一起发生了变化。

理解域名与地址信息出现的时机

应用发起请求时，客户端不一定同时掌握完整网址、域名和目标地址。有些请求以域名建立连接，有些请求直接使用地址，已有连接还可能继续使用缓存结果。域名规则与地址规则依赖的信息不同，因此排错时应先看请求记录实际提供了什么，再判断某种匹配方式是否具备执行条件。

地址规则有时需要等待域名解析才能判断。规则后附加 no-resolve 的作用，是避免仅为检查该条地址规则而主动解析域名；它并不是关闭整个客户端的 DNS。请求本身已经以地址出现时，仍可能使用现有地址进行匹配。这个区别对于减少不必要解析很重要，也解释了同一条地址规则在不同请求上为何表现不同。

[Rule]
DOMAIN,portal.example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

上例先处理明确域名，再检查已有地址是否落入文档专用网段，最后交给兜底策略。若请求只有域名且不符合第一条，带有 no-resolve 的地址规则不会为了自己额外发起查询；此时不能因为域名最终解析到该网段，就断言这条规则必须提前命中。应以实际请求信息和匹配记录为依据。

skip-proxy 与请求路径

skip-proxy 用于列出系统代理层面的例外目标，不应当被当成 Rule 中 DIRECT 的同义写法。不同流量进入客户端的方式可能不同，系统代理例外也不能替代完整的规则设计。对需要可核对分流结果的业务，优先在 Rule 中明确写出条件，并确认该流量确实处于客户端能够处理的路径内。

对于内部域名，应先确认系统网络是否提供相应的解析条件。即使规则选择 DIRECT，系统仍需知道该主机的正确地址；即使 Host 已给出地址，设备也仍需存在到该地址的可达路径。解析、策略与连通性是连续但独立的环节，单独修改其中一项不能替代另外两项。

DNS 结果还可能被应用、系统或客户端缓存。改完解析设置后，应关闭当前测试页面并重新建立请求，必要时使用应用内对应的清理工具。不要同时清理缓存、更换服务器并调整规则，否则恢复访问后也无法知道是哪一步起效。复测记录至少保留网络类型、目标主机、解析地址和实际策略四项。

若只有部分域名失败，先把它们与正常域名分组比较，而不是立即替换所有通用选项。检查失败域名是否返回地址、返回地址是否变化、相同策略下其他目标是否可达。涉及 DNS 的问题往往在网络切换后出现，保存前后状态有助于识别是网络条件变化，还是当前配置被另一份文件替换。

03 / DOMAIN MATCHING

DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD

完整域名与后缀范围

DOMAIN 用于精确匹配一个完整主机名。条件写 api.example.com 时，规则针对这个主机，不自动覆盖 www.example.com 或更深层的子域名。条件中不要带协议、端口、斜杠或网址路径。需要区分同一主机的不同页面时，普通域名规则无法完成，因为这些页面在域名层面没有差别。

DOMAIN-SUFFIX 用于匹配指定域名及其子域名。条件为 example.com 时，可覆盖该域名本身以及 api.example.com 等子域名；它不是任意字符串结尾比较，不应理解成同时覆盖 notexample.com。填写时不需要在前面加星号，也不要把常见的浏览器网址写法直接粘贴为条件。

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

在这组规则里，账户主机先命中精确例外，其余属于 example.com 的主机再由后缀规则处理。如果把后缀规则放在第一行，账户主机也会先匹配它，下面的精确例外就没有机会执行。精确匹配的条件更窄，但它没有脱离文件顺序的自动优先权，必须主动放在较宽规则之前。

关键词匹配的误伤范围

DOMAIN-KEYWORD 检查域名中是否包含指定关键词，适合确实需要跨多个域名覆盖同一字符串的场景。它不理解组织归属，也不判断词语边界。关键词过短时，许多无关主机也可能被选中。只有一个或几个已知域名时，应优先采用 DOMAIN 或 DOMAIN-SUFFIX，让配置范围能被直接说明。

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

此处先保留 example.com 的例外，再将其他含有 example 字符串的域名交给 PROXY。这个顺序只是语义演示，不是通用推荐规则。采用关键词前，应从实际请求中列出希望覆盖的主机和不希望覆盖的主机，逐个检查是否都符合预期，不能只测试一个成功页面就结束验证。

类型条件示例范围边界
DOMAINapi.example.com只匹配该完整主机名
DOMAIN-SUFFIXexample.com主域名及其子域名
DOMAIN-KEYWORDexample域名中包含该字符串

页面由多个主机共同组成

浏览器地址栏显示的主机不一定包含页面加载的全部目标。图片、字体、登录验证、接口与视频分片可能来自不同域名。主页面成功而部分内容失败时，应观察缺失资源对应的主机，再决定是否补规则。把整个顶级域范围都交给同一策略虽然容易，但会扩大影响面，也会掩盖真正需要处理的条件。

同一服务还可能使用外部存储或内容分发主机，这些主机不一定属于主站的域名后缀。应根据用户实际访问记录与服务文档确认关系，不要通过相似拼写推断归属。对于多人共用的公共资源域名，修改其策略可能影响其他应用；必要时保留更精确的例外，并说明为什么不能只使用主站后缀。

有些请求直接连接地址，没有可用的主机名；有些域名经过别名解析，但规则记录仍围绕原始请求域名显示。不能只根据某次 DNS 查询看到的别名就断言域名规则一定匹配该别名。排错应以客户端记录中的目标字段为准，若记录仅有地址，继续检查地址规则与域名信息的可见性。

测试域名规则时，可先放置一条临时精确规则，将测试范围收窄到单个主机。确认命中后，再扩展为后缀规则，并测试一个子域名与一个无关域名。这个过程能够验证规则语法、排序和范围三个问题。测试完删除临时规则，避免日后忘记其用途而在宽规则前留下隐蔽例外。

维护域名清单时，应记录每条规则服务于哪个实际需求，而不是不断堆积无法解释的后缀。重复规则不会提高可靠性；同条件不同策略的重复行尤其容易误导阅读。整理时保留有效的第一条，核对后续重复是否只是失效旧内容，并在修改后重新测试登录、静态资源和接口这些不同请求。

04 / ADDRESS AND METADATA

IP-CIDR、GEOIP 与 USER-AGENT

地址段与掩码长度

IP-CIDR 使用网络地址与前缀长度表示一段 IPv4 地址。前缀长度越大，覆盖范围通常越小；单个地址可使用三十二位前缀。填写前应确认需要的是某台主机还是整个网段，不能只因两个地址前几段相似就扩大范围。涉及局域网时，还要核对当前网络实际分配的地址段，避免把不相关的远端地址一起归入 DIRECT。

[Rule]
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR,198.51.100.0/24,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

以上地址均为文档用途，不能作为实际服务地址。第一条只选择一个 IPv4 地址，第二条选择一个 IPv4 网段，第三条展示 IPv6 前缀写法。IP-CIDR6 对应 IPv6 地址范围，不应把含冒号的地址塞入 IP-CIDR。前缀表达的是地址集合，不是端口范围，也不能用它区分同一服务器上的不同网站。

如果多个域名共享同一地址，地址规则可能同时影响这些域名。因此已知目标主机时通常先考虑域名规则，只有确实按地址管理的业务才使用网段规则。反过来，目标是固定内部设备且请求直接使用地址时，域名规则又无法替代地址规则。选择依据应是业务标识，而不是哪一种写法看起来更简短。

GEOIP 是地址归类，不是网站身份

GEOIP 按地址数据库中的地区归类进行判断，例如 GEOIP,CN,DIRECT。这类规则描述的是目标地址的归类，不是域名注册地或服务提供者所在地。网站使用内容分发后，不同网络下可能解析到不同地址；数据库也可能与当前实际使用情况存在差异，所以地区规则适合作为较宽的补充条件。

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

此例先固定特定接口的策略，再使用地区条件处理其他请求。若把 GEOIP 提到前面，当接口解析地址符合该地区归类时，精确域名例外可能不再执行。规则评估仍然遵循顺序，不会因为后面出现了更具体的域名条件就自动重选。出现误分流时先看命中位置，再讨论地址数据库本身是否需要核对。

GEOIP 的判断可能涉及解析目标域名。是否附加 no-resolve，应根据是否愿意为该条件触发解析来决定。加上以后，只有域名而没有可用地址的请求可能直接继续检查后续规则；不加时则可能产生额外解析等待。两者是行为取舍，不存在对所有网络都正确的固定写法，必须结合实际记录验证。

USER-AGENT 的可见性限制

USER-AGENT 根据可见请求中的 User-Agent 信息匹配，不能等同于按应用身份分流。多个应用可能发送相同标识，同一应用也可能按请求类型改变标识。普通加密连接不会自然暴露所有 HTTP 请求头，因此不能期待它识别所有应用流量，更不能把它当作系统级进程选择器使用。

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

ExampleClient* 是演示模式，实际条件应来自用户可以确认的请求标识。仅凭应用名称猜测 User-Agent 容易失败，因为品牌名称和请求头并不一定一致。若请求记录没有相应信息，应改用能够观察到的域名或地址条件，不应通过不断放宽通配符来试图弥补信息缺失。

访问控制需求也不应只依赖 USER-AGENT。该字段是请求元数据，并不是强认证凭据；同一个目标可能在不同请求中携带不同值。若目标是阻止某个明确主机，直接写域名条件更容易复核。若目标是区分同一主机上的不同业务，则应先确认客户端可见的信息能否表达这种差别，再决定是否适合在规则层处理。

地址与元数据规则测试时，要分别覆盖已有连接和新建连接、域名访问和地址访问。某次命中只能说明该请求满足条件，不能推导所有相似流量都相同。记录中若缺少关键字段，应把结论写为“当前证据不足”，保留更可观察的规则，而不是将偶然结果固化成大范围默认策略。

05 / POLICY AND PRECEDENCE

PROXY、DIRECT、REJECT 与规则优先级

先确认 Global Routing 姿态

Global Routing 的 Config、Proxy、Direct 分别对应配置、代理与直连姿态。研究 Rule 中的逐条分流时，应使用 Config，并确认实际启用的配置文件。Proxy 和 Direct 用于按相应全局姿态处理连接，不应拿它们的测试结果证明某条普通分流规则是否正确。界面中的 Proxy 与规则关键字 PROXY 大小写不同，阅读时要区分层次。

层次名称含义与检查点
Global RoutingConfig按当前配置研究规则命中
Global RoutingProxy / Direct全局姿态，不等同于规则行
Rule 策略PROXY交由当前代理选择处理
Rule 策略DIRECT通过本地网络直接连接
Rule 策略REJECT拒绝匹配请求

PROXY 并不在规则里定义一个服务端，它引用当前可用的代理选择。若服务器参数错误、认证失败或服务端不可达，即使规则命中完全正确，请求仍会失败。DIRECT 则不表示绕过设备的一切系统网络条件，它仍受当前网络、DNS 与目标服务状态影响。REJECT 是明确拒绝，不应作为诊断未知故障的默认试探方法。

首条命中与明确例外

Rule 的常见处理逻辑是自上而下检查，先命中的条件决定该请求的策略。规则不会按域名长度、类型名称或书写时间重新排序。建立配置时，可按“精确例外、业务域名、地址补充、最终兜底”的顺序组织，但这只是便于推理的结构，不是必须照抄的固定清单；每一条仍需说明为什么放在当前位置。

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,blocked.example.net,REJECT
GEOIP,CN,DIRECT
FINAL,PROXY

登录主机命中第一条后便无需再由 example.com 的后缀规则决定策略。另一个 example.com 子域名会继续到第二条。被明确列出的拒绝目标由第三条处理，其余请求才进入地区判断。阅读配置时，可以拿一个具体主机从第一行向下模拟，而不是孤立地盯着看似相关的那一行。

如果把第三条的拒绝目标同时包含在更靠前的宽范围直连规则中，拒绝条件就可能无法执行。这样的冲突不能靠重复写同一条 REJECT 修复，应移动位置或收窄前面的条件。删除一条失效规则之前也应检查它是否是刻意保留的文档说明；若确实无效，用注释解释比留下互相矛盾的活动行更清楚。

FINAL 是兜底，不是自动修复

FINAL 不需要填写域名条件，基本形式为 FINAL,PROXY 或 FINAL,DIRECT。它负责接住前面没有命中的请求，应放在规则末尾。把 FINAL 放在中间，会让后续普通规则失去预期执行机会。配置检查时先搜索 FINAL 出现次数，通常保留一条明确的最终策略即可，不要通过多条兜底表达不同用途。

选择哪种兜底需要考虑实际使用需求与已有连接条件。FINAL 设为 PROXY，意味着尚未分类的请求交给代理选择；设为 DIRECT，则意味着未分类请求直接通过当前网络。二者都不能保证目标一定可达。出现单一业务异常时，先增加有依据的精确例外，而不是来回切换整个兜底以碰运气。

# 精确例外必须位于覆盖它的宽规则之前
[Rule]
DOMAIN,health.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

测试上例时，至少检查健康检查主机、另一个 example.com 子域名和一个完全无关的域名。三类请求分别验证例外、后缀与兜底。如果只测第一类，可能发现不了 FINAL 被误改；如果只测主站，又可能发现不了精确例外被覆盖。规则验证应覆盖边界，而不只是确认一个成功路径。

On Demand（按需连接）决定在相应网络条件下是否建立连接，不代替 Rule 决定请求策略。连接被自动建立后，仍需核对当前 Global Routing 与 Config。若切换网络后结果改变，应分别检查连接是否重建、配置是否相同、DNS 是否变化，不能因为 On Demand 开着就断定所有请求已使用预想出口。

策略命中和业务成功应分开验收。命中记录证明分类逻辑，目标响应证明当前路径可用；两者缺一不可。遇到失败时先确定是“走错策略”还是“策略正确但连接失败”，再进入下一步。更多首次连接相关问题可查问答，避免把授权或服务器认证故障误判成规则优先级问题。

06 / HOST AND URL REWRITE

Host 映射与 URL Rewrite 的作用边界

Host 改变地址映射，不改变网站身份

Host 为指定主机提供静态地址映射，常用于用户明确知道目标地址的受控环境。它不能自动发现内部设备，也不能保证该地址可达。配置前应取得准确地址，并确认该主机确实在目标地址提供服务。把随机可访问地址填进去，只会使请求发往错误目标，不能作为修复解析问题的方法。

[Host]
portal.example.com = 192.0.2.20
files.example.com = 192.0.2.21

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

这里的 Host 指定地址，Rule 指定策略，两段共同描述不同环节。地址使用文档专用范围，实际使用必须替换为用户自己环境中的有效值。若目标地址只在特定网络可达，设备离开该网络后，即使静态映射仍存在也可能连接失败；这时应检查可达路径，而不是继续添加同名映射。

使用 HTTPS 时，原始域名仍参与网站身份校验。Host 将域名指向另一个地址，不会让证书自动变成正确，也不会把请求中的主机身份改为该地址。出现证书名称不符时，应核对映射目标与服务配置，不要把关闭验证当作正常修复。静态映射尤其需要在目标服务迁移后及时复核。

Host 与缓存也可能共同影响观察结果。修改后仍连接旧地址时，应先结束已有连接，并检查是否存在应用侧缓存。只有确认新请求已经使用新映射，才能评价它是否有效。若需要恢复原有解析，删除测试映射并重新发起请求，比在同一主机下不断添加多个互相竞争的值更容易追踪。

URL Rewrite 匹配的是网址表达式

URL Rewrite 使用正则表达式识别请求网址，并按配置执行改写或重定向。它与域名分流不是同一个机制：域名规则决定策略，改写规则改变目标表达式。仅希望某个主机走 DIRECT 时，不需要使用网址改写；只有确实存在受控的网址迁移、路径调整等需求时，才应增加这一段。

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

示例将旧主机上的 HTTP 网址重定向到新主机，保留捕获到的后续内容。开头的插入符限定起点，反斜杠使域名中的点按字面含义匹配，括号建立捕获组，目标中的美元符号加数字引用该组。最后的 302 表示临时重定向。该写法只演示语法，目标域名不是可用业务服务。

省略起点约束或不转义点号，会扩大正则匹配范围。正则中的点通常表示任意字符，并不是普通域名分隔点。编辑前应拿几个相近网址检查：预期旧主机应匹配，其他主机不应匹配，已经是新主机的网址也不应再次匹配。范围越窄，越容易证明改写只影响预期请求。

重定向、加密与循环检查

客户端能够处理哪些网址信息，取决于实际请求路径与加密可见性。不能假设加入 URL Rewrite 后就能读取任意 HTTPS 路径；隧道中只有主机信息时，基于完整路径的表达式可能没有执行条件。先用信息可见、范围受控的请求验证，不要为一个路径问题随意扩大证书信任或检查范围。

重定向后，应用需要向新目标发起后续请求，新目标也需要符合当前分流配置并且可达。旧目标规则正确，不代表新目标策略也相同。如果新主机又把请求送回旧主机，就会形成循环；浏览器可能只显示重定向次数过多。此时应分别查看每次跳转的来源和目标，检查服务端行为与本地规则是否相互叠加。

永久重定向可能被客户端缓存，因此验证阶段通常更适合先使用可控的临时重定向语义，并在确认后根据业务要求决定最终方式。即使删除本地规则，应用缓存也可能让测试结果暂时不变。排错时使用新的请求入口，记录实际跳转链，而不是只凭地址栏最终显示的地址判断规则是否还在执行。

查询参数可能包含认证或业务状态，不能在不理解结构时随意丢弃或拼接。捕获表达式是否保留查询部分，需要用具体样本检查；路径中的特殊字符也可能涉及转义差异。对登录、付款或提交表单等敏感流程，应优先遵循服务自身的跳转设计，不把简单 GET 请求的测试结论推广到所有请求方法。

07 / COMPOSITION

常见规则组合、合并与配置维护

从能够解释的最小规则开始

建立规则集前，先用自然语言写清需求，例如“账户主机直接连接，其他业务子域名使用当前代理，其余请求保持直连”。再把每一部分转换为对应条件。这样能够判断某条新增规则是否真的必要，也能在测试失败时回到需求本身，而不是通过增加更多宽匹配条件掩盖原有冲突。

[Rule]
# 账户主机例外
DOMAIN,accounts.example.com,DIRECT

# 业务域名
DOMAIN-SUFFIX,example.com,PROXY

# 用户确认的拒绝目标
DOMAIN,blocked.example.net,REJECT

# 其他请求
FINAL,DIRECT

这份组合故意保持短小，便于逐条核对。它不包含服务端地址，也不包含订阅内容，必须建立在用户已有可用连接信息的基础上。新增业务时先确认目标主机，再决定是精确条件还是后缀条件；不要因为一个页面加载失败就把一长串未经核对的域名一起加入，后续将无法判断哪些行真正参与了处理。

合并规则时处理语义冲突

合并两份配置不能只把文本首尾相接。先识别两份文件各自的段落，再将同类内容放到对应段落中，最后统一检查规则顺序和 FINAL。General 中相同键的不同值、Host 中同名主机的不同地址，以及 Rule 中相同条件的不同策略，都应人工决定保留哪一个，而不是依赖不明确的重复覆盖行为。

域名后缀与精确域名也可能存在隐含冲突。某份规则把 example.com 全部交给 PROXY，另一份把其中一个接口交给 DIRECT；它们不是简单的重复行，必须把精确例外放到宽规则之前。合并时应搜索同一主域名附近的所有条目，检查是否有更高层的后缀或关键词已经提前覆盖了它。

# 合并后的顺序：例外在前，宽条件在后
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

如果原文件包含自定义策略名称，迁移时还要确认目标配置中存在同名定义，并且名称与大小写一致。本页使用 PROXY、DIRECT、REJECT 来解释基础语义，不能据此推断任何陌生策略名都可以直接使用。遇到未知引用，先查明它连接到哪个服务器选择或策略组，确认后再决定是否保留。

保持修改记录与更新边界

每次变更应记录目标、改动行和验证结果。注释可放在独立行，写明业务用途和例外原因，不必写冗长叙述。对临时诊断规则尤其要标记撤销条件，否则几次测试后容易遗忘，形成看不见的优先级。整理规则时，应同时检查注释是否仍与实际策略一致，过时注释会让配置比没有说明更难维护。

远程配置更新前，先备份本地副本，再比较关键段落，而不是仅检查文件是否成功获取。上游可能改变兜底、增加宽范围规则或调整解析选项，这些变化都会影响本地例外。若需要将本地内容重新合并，应按规则语义检查位置；把旧例外原样粘到文件末尾，可能正好落在 FINAL 之后而失效。

订阅更新主要涉及已有服务器条目，不应被理解为规则同步的统一替代动作。更新后如果代理路径异常，检查当前选中的服务器是否仍然有效、认证参数是否变化以及旧条目是否被替换。规则仍命中 PROXY 但指向不同连接选择时，业务结果也会改变，这类问题不能靠调整域名顺序解决。

配置备份与服务器凭据应分清保管范围。导出文件可能包含连接参数，也可能依赖独立保存的服务器列表；换机后不能仅凭文件名相同就断言内容完整。具体准备与恢复步骤可查配置备份与换机恢复说明，并在旧设备仍可用时完成一次恢复核对。

逐渐增长的规则集需要定期缩减。对于从未命中、用途不明或已经被更宽条件覆盖的条目，应先在测试副本中停用并观察，再决定删除。清理目标不是追求行数最少，而是让每条活动规则都能解释必要性。对正常业务保持稳定，比把所有可能类型都加入配置更容易维护。

协议连接参数与规则策略也应独立管理。例如 WireGuard 的密钥和地址影响连接建立，DOMAIN-SUFFIX 决定哪些目标交给该代理选择；两者不是同一层问题。字段含义可另查WireGuard 配置填写说明，不要为了修复认证错误而不断扩大业务域名匹配范围。

08 / VERIFICATION

规则验证、故障分支与恢复检查

建立能够重复的测试条件

一次有效测试应有明确目标主机、预期策略、固定网络与清楚的配置状态。先确认使用 Config 姿态，记录启用文件和当前服务器，再发起新的请求。测试期间不同时更新订阅或切换网络。若条件不断变化，即使结果偶尔成功，也难以证明是规则修正带来的变化，更无法将结论用于后续维护。

建议为每次修改挑选三类样本：应该命中的目标、应该进入例外的目标以及不应受影响的目标。分别记录规则、策略和业务结果。新增一条后缀规则时，至少包含主域名、子域名与相似但不属于该后缀的域名；新增地址规则时，则验证范围内外两个地址，避免仅验证成功样本。

观察到的现象优先检查下一步
没有预期命中文件、姿态、请求字段检查前置宽规则与新请求
命中 PROXY 但失败服务器连接与认证区分出口与目标服务问题
命中 DIRECT 但失败本地解析与网络路径检查返回地址和可达范围
主页面正常、资源失败资源实际主机逐项核对依赖请求
修改后结果不变缓存与已有长连接建立新请求并核对文件

先分辨未命中与命中后失败

没有命中时，首先检查目标是否真的具备规则需要的信息。域名条件不能匹配只有地址的请求，USER-AGENT 条件不能匹配不可见的请求头。其次从 Rule 顶部向下检查，寻找更早的后缀、关键词、地区条件或 FINAL。最后核对半角标点、策略拼写以及该行是否位于正确段落。

已经命中但访问失败时，应停止无依据地移动规则。PROXY 分支检查当前服务器是否能建立连接、认证信息是否仍有效以及目标服务是否可达；DIRECT 分支检查本地网络是否能访问解析地址。若只有一个目标失败，优先比较目标差异；若所有同策略请求失败，再检查该策略共用的连接条件。

Connectivity Test（连通性测试）能提供特定测试条件下的结果，但不能替代每个业务请求的验证。一个测试目标能够响应，不代表登录接口、视频资源或其他协议请求都能成功。应把测试结果视为缩小范围的证据，并结合实际失败请求判断，不能只用一个读数为整份配置下结论。

处理缓存、长连接与网络切换

配置变化不一定让所有已建立连接立刻以新策略重建。浏览器复用连接、应用后台传输和媒体连续播放，都可能保留旧状态。验证时应主动结束相关会话并重新请求，必要时重建客户端连接。已有页面持续播放只能说明旧连接仍能工作，不能证明新规则已经覆盖后续连接。

网络从无线局域网切换到蜂窝网络后，解析服务器、可达地址与连接状态可能一起变化。内部主机在原网络可达而切换后失败，不一定是规则错误。重新检查 On Demand 是否建立连接、Global Routing 是否保持原姿态，以及目标是否依赖原网络路径，再决定是否需要不同网络下的独立配置安排。

Data（流量统计）反映记录范围内的传输量，不是规则命中的直接证明。看到某个服务器有流量，只能说明它参与过传输，不能证明当前测试目标一定经过它；缓存命中也可能没有明显新增流量。统计口径与读数解释可查流量统计说明，分流验收仍以具体请求为单位。

最小化复现与安全回退

复杂问题可在测试副本中逐步缩减：保留必要的 General、单个目标规则和一条 FINAL，暂时移除无关 Host 与 URL Rewrite。每移除一组内容就重复同一个测试，观察差异。不要直接在日常配置中清空所有段落；一旦失去基线，连原本正常的行为也难以恢复。

# 用于隔离单个目标的规则段；不是完整连接配置
[Rule]
DOMAIN,api.example.com,PROXY
FINAL,DIRECT

如果最小规则能按预期命中，再逐组恢复原有内容，找到首次出现差异的位置。若最小规则仍不命中，应回头检查启用关系和请求字段，而不是继续合并更多规则。每一步只改变一个变量，可以把“文件没有启用”“前置条件覆盖”和“策略路径故障”区分开来，减少重复试错。

需要进一步咨询时，提供脱敏后的相关段落、实际主机、命中策略、网络条件与复现步骤。不要公开完整订阅地址、密钥或认证字段。无法继续定位时，恢复已验证的备份，确认原有业务恢复，再安排下一次测试。有关导入与首次授权的操作可返回入门指南；购买核对和恢复获取请查看已购恢复说明。