Shadowrocket
配置与规则参考

配置文件结构与生效范围

先区分服务器信息与配置文件

服务器信息描述连接远端所需的地址、端口、协议及认证字段；配置文件描述请求如何处理、使用什么规则以及怎样解析域名。把订阅导入 Home，并不意味着已经替换 Config 中的规则文件。反过来，导入一份包含 Rule 的文件，也不会自动补齐用户自己的服务器凭据。排错时首先确认这两个对象，避免在错误的位置反复修改。

在 Config 中查看当前选用的配置，再打开编辑内容。导入、保存与选用是不同动作：列表里出现文件，只能证明文件已经存在；编辑器里看到新内容，只能证明正在查看该文件。是否由它控制连接，需要核对当前选用状态。修改前记录文件名称和选用状态，保存后重新检查，必要时关闭连接再开启，让后续测试使用新的配置。

四个段落各自负责什么

段落标题使用方括号，字段与规则写在对应标题下。General 是通用设置，Rule 是请求匹配与策略，Host 是静态域名地址映射，URL Rewrite 是符合条件的 URL 改写。它们不能互相代替：把域名映射写进 Rule 不会成为 Host，把重定向表达式写进 General 也不会成为可执行的分流规则。段落名和规则关键字保留英文原文。

[General]
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8, localhost
dns-server = system

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

[Host]
localhost = 127.0.0.1

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

这份示例把未命中的请求交给 DIRECT，仅让示例域名使用 PROXY，因此不是通用的代理配置。复制前必须理解末尾策略。General 中的跳过范围也会影响后续处理路径；一个请求如果已在更早环节绕过代理，就不能只靠移动 Rule 中的一行让它重新进入规则匹配。

编辑、保存与备份的基本顺序

先保留可用文件，再复制一份用于实验。每次只改一个段落或一条规则，保存后重新选用并测试。文件来自远程地址时，还要确认下次更新是否会覆盖本地内容；需要长期保留的修改，应放在可独立维护的本地副本中，而不是依赖某次更新暂时留下的差异。备份名称应能辨认用途，但不必包含账号、服务器地址或认证信息。

逗号分隔规则参数，等号分隔通用字段或 Host 的键值。不要把中文标点、说明性文字和网页复制产生的特殊空格带入配置。多行示例中的换行是实际换行，不是视觉折行；编辑器显示一行很长时可以横向查看，不应随意把规则拆为两行。注释应独立写在以 # 开头的行上，避免把备注追加到策略参数之后。

文件能被保存不等于全部语义正确。一个拼写正确但范围过大的 DOMAIN-KEYWORD，可能正常执行却把不相关请求一起匹配；一个有效的 FINAL，也可能因为放在过早位置而遮住后面的规则。验证要同时关注语法、选用状态与实际请求结果，不能只看编辑器是否报错。

General 字段与 DNS 处理

通用字段不只是规则的前言

General 决定部分请求如何进入处理链以及域名解析使用什么来源。理解 Rule 前应先看这里，因为连接是否进入代理处理、是否已经取得地址、是否保留可匹配的域名信息，都可能改变后续结果。不要把 General 当成一段固定模板：适合某个局域网的跳过范围，搬到另一网络后可能不再符合需要。

bypass-system = true 用于让相关系统流量绕过代理处理。它不是“所有请求都直连”的开关，也不等价于 Global Routing 的 Direct。保留这一设置时，应接受相应系统请求可能不经过普通规则路径的事实；若某项系统功能异常，需要结合具体请求与网络环境判断，不能从一个网页测试结果推断所有系统流量的行为。

skip-proxy 指定跳过代理处理的目标范围，常见对象是局域网地址与本机名称。这里的跳过和 Rule 中指定 DIRECT 所处环节不同。DIRECT 是请求进入规则处理后选择的策略；跳过则可能让请求不按通常的代理规则路径运行。因此日志中没有出现预期的 Rule 命中时，应检查跳过列表，而不是立即把同一规则复制到文件顶部。

[General]
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8, localhost
dns-server = system

system 的含义与测试基线

dns-server = system 表示使用系统提供的 DNS 来源，不代表固定使用某一个解析服务器。连接不同 Wi-Fi 或移动网络后，系统获得的解析配置可能变化；局域网内部名称也可能只有当前网络的解析服务知道。采用 system 作为基线，便于先判断现有网络能否解析目标，再决定是否需要在用户自己的环境中指定其他解析来源。

DNS 的工作是把名称解析为地址，规则的工作是决定请求采用什么策略，二者互有关联却不是同一功能。DOMAIN 规则可以依据已知域名匹配；GEOIP 或 IP-CIDR 面向地址，可能需要解析结果。若日志里出现解析失败，说明尚未获得所需地址，不能直接把它解释为 PROXY 服务器不可用，更不能用增加 FINAL 的办法修复不存在的解析结果。

区分应用请求和解析请求也很重要。一个目标网页使用 PROXY，不足以证明所有 DNS 查询都沿同一路径；具体解析行为还受应用、系统缓存与配置选项影响。需要精确判断时，应查看实际日志和当前配置，而不是从规则行的策略名反推解析链路。涉及服务器域名时，还要先确保服务器自身能够被解析，避免把连接入口的失败误当成目标网站分流失败。

更改 DNS 前后的边界检查

当外部域名能够解析、内部域名不能解析时，先检查是否离开了提供内部解析的网络；当所有名称都失败、直接访问已知地址仍可达时，再集中检查 DNS 来源。不要同时改 DNS、服务器和 Rule，否则即使恢复连接，也无法判断是哪一步起作用。每次改变后使用相同目标、相同网络与新建连接复测，并记录变化。

DNS 缓存会让修改效果看起来延迟。系统、客户端和应用都可能保留此前的结果，浏览器也可能复用既有连接。保存配置后仅刷新页面，未必产生新的解析请求。应先关闭旧连接、重新连接，再重新打开目标应用；只有在仍然异常且有明确必要时，才进一步检查系统网络状态。不要把一次缓存命中当成新配置已经得到验证。

IPv4 与 IPv6 也需要分别观察。域名可能同时返回两类地址，某一网络对其中一类的可达性较差，于是出现解析成功但连接超时的情况。此时应查明实际使用的地址与命中规则，而不是机械地替换解析来源。与其堆叠多个不明来源的字段，不如保留可工作的基线，先把“名称、地址、策略、连接结果”四项信息对应起来。

DOMAIN 系列规则的范围

精确名称与域名后缀

DOMAIN 按指定域名匹配，适合仅处理一个明确的主机名称。例如只让 api.example.com 使用 PROXY，而不改变同一站点其他名称的行为，就应优先考虑精确规则。参数写域名本身，不带协议、路径、端口或查询字符串。把完整网页地址放进 DOMAIN，虽然看起来更具体，实际上并不是该规则预期的匹配对象。

DOMAIN-SUFFIX 按域名层级后缀匹配，example.com 可以覆盖该名称本身及它的子域名，例如 www.example.com 和 api.example.com。它不是对任意字符串尾部做不受边界限制的判断；名称之间的点号层级很重要。写后缀时通常直接使用域名，不需要手工补上星号，也不应把网页路径接在参数末尾。

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

这个顺序让 api 的精确规则先命中，随后覆盖其他 example.com 请求。若把 DOMAIN-SUFFIX 放到前面，api 请求也会先被较宽的规则匹配，后面的 DOMAIN 不会获得“更精确所以优先”的特殊待遇。精确程度是编排时的判断依据，不是规则引擎自动重新排序的依据。

关键词规则为什么需要谨慎

DOMAIN-KEYWORD 按域名中出现的关键词匹配，适用于确实需要字符串范围的场景。它不识别站点归属，也不理解某个词是否代表特定业务。关键词 example 可能出现在不同层级、不同后缀的名称中，因此覆盖范围通常比 DOMAIN-SUFFIX 更宽。能用明确域名或后缀表达时，优先使用可审查的窄范围规则。

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

这里的关键词规则是为了展示层次，不代表实际文件必须同时包含三种写法。登录名称先采用 DIRECT，域名及子域名随后采用 PROXY，其他包含关键词的名称再由第三行处理。实际维护时应删除没有明确需求的宽范围规则，减少误匹配和排错成本；规则更长并不意味着配置更准确。

域名规则命中所需的信息

请求处理时必须有可用的域名信息，域名规则才能依据名称工作。应用若直接连接一个 IP，或者相关阶段无法关联到原始域名，规则引擎可能只能继续检查地址规则。用户在浏览器地址栏输入域名，并不能证明每一条后续连接都保留相同名称；页面还可能加载图片、接口、字体或其他资源域名。

遇到主页打开但部分资源失败，应从日志中找实际失败请求的域名，而不是只给主页名称增加重复规则。一个业务页面往往有多个依赖名称；这些名称是否应采用同一策略，需要依据实际请求判断。不要为了省事把短关键词扩大到所有相似名称，也不要从某次成功访问推断所有依赖都已经覆盖。

测试时准备一个应命中的名称和一个不应命中的名称，分别观察策略。前者检查规则是否生效，后者检查边界是否过宽。如果采用 DOMAIN-SUFFIX，应同时检查根域名和子域名；如果采用 DOMAIN，则检查邻近子域名没有被误纳入。用这种正反两组请求，比只测试一个成功页面更能发现范围错误。

域名大小写通常不是排错重点，但配置参数仍建议统一书写便于审查。国际化域名、特殊名称或应用实际使用的规范化形式，应以日志中可见的匹配对象为准。不要凭网页显示名称推测规则参数；可见标题、链接文字与实际连接主机可能完全不同。修改后保留测试依据，下一次遇到同类问题才能判断是规则变化还是请求对象变化。

IP-CIDR、IP-CIDR6 与 GEOIP

地址网段不是域名分类

IP-CIDR 面向 IPv4 地址范围，参数由网络地址与前缀长度组成。192.168.0.0/16 描述该私有地址网段，而不是单个主机；需要只匹配一个 IPv4 地址时，使用对应地址加 /32。写规则前先确认真实目标地址与掩码，不要把路由器地址误当成整个网络，也不要为了覆盖一个设备直接扩大到所有私有网段。

IP-CIDR6 用于 IPv6 地址范围，前缀长度同样决定覆盖边界。fc00::/7 覆盖 IPv6 的唯一本地地址范围，::1/128 仅表示回环地址。IPv4 和 IPv6 规则互不替代；一个域名同时获得两类地址时，只写 IPv4 网段不会自动约束 IPv6 连接。排错应检查日志中的实际地址类别。

[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

这一片段将列出的本地地址范围设为 DIRECT，其他请求交给 PROXY。它没有覆盖所有特殊用途地址，也没有替代 General 中的跳过设置。不要因为看见“本地网段直连”就认为所有局域网名称都能访问：名称仍需解析到正确地址，网络仍需允许到达相应设备，目标服务也必须处于可用状态。

no-resolve 控制的是解析触发

no-resolve 用于避免为了匹配该条地址规则而额外触发域名解析。它不是 DIRECT 的别名，也不是对整份配置禁用 DNS。若当前请求已携带可匹配的地址，规则仍可根据地址判断；如果只有域名且尚无所需地址，则不应期待这条规则主动解析后再命中。是否添加，应依据需要匹配的请求形态决定。

对于本来就以 IP 访问的局域网设备，带 no-resolve 的网段规则比较容易理解；对于通过内部名称访问的设备，还应确认解析流程能得到本地地址。若为了“减少解析”给所有地址规则都加这一参数，可能改变原先依赖解析结果的命中路径。出现结果差异时，先看该请求在检查这条规则时是否已有地址，而不是只比较最终网页是否打开。

GEOIP 是地址数据库判断

GEOIP 根据 IP 地址归属数据库作判断，GEOIP,CN,DIRECT 是常见语法示例。它不按网页语言、域名后缀、账号地区或用户所在地分类。一个中文页面可能使用多个不同归属的地址，同一域名也可能由分布式服务返回不同地址。因此 GEOIP 适合作为较宽的地址分类层，而不是某项业务一定直连的证明。

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

域名例外置于 GEOIP 前面，可以让该名称先获得明确策略；随后地址范围与地理归属处理剩余请求，最后由 FINAL 收口。如果把 GEOIP 放在需要的域名例外之前，且地址条件已满足，请求可能先命中地址规则。所谓“域名优先”需要通过顺序表达，不是由规则类型自动保证。

数据库归属与即时网络可达性之间没有必然对应关系。命中 GEOIP 后连接失败，可能是本地网络到目标不可达，也可能是目标服务异常，不能据此认定数据库语法无效。需要稳定例外时，可根据可核对的域名写更具体规则；不要为了固定一次测试结果，把某个临时解析地址永久扩大为大网段例外。

地址规则还容易被连接复用干扰。修改网段策略后，应用继续使用原来的连接，日志可能没有新的匹配记录。应重新建立连接，再核对目标 IP、规则类型与最终策略。若同一名称的多次解析返回不同地址，应保留这些差异，判断是地址池变化还是规则范围缺漏，而不是反复移动 FINAL。

策略、Global Routing 与匹配顺序

配置策略与界面姿态分开看

规则中的 PROXY、DIRECT、REJECT 是请求处理策略；Home 中 Global Routing 的 Config、Proxy、Direct 是整体路由姿态。两组名称相关，但不应混写。使用 Config 时，重点查看当前配置的 Rule；切到 Proxy 或 Direct 后，不应继续用正常配置模式下的逐条分流预期解释测试结果。排错记录必须先写明当前姿态。

整体姿态不意味着系统级绕过、跳过范围等边界设置消失。比较三种姿态的目的，是分离服务器链路问题与配置匹配问题，而不是证明每条系统请求一定经过同一处理路径。测试完应恢复预期的 Config 状态，再进行规则验证，否则即使编辑文件正确，也可能观察不到期望的分流结果。

三个常用策略的实际含义

PROXY 把匹配请求交给当前代理路径，需要已有且可用的服务器信息。规则写成 PROXY 只说明选择了代理策略，不表示服务器已通过认证，也不保证远端能够到达目标。DIRECT 从当前网络直接连接目标，不等于访问会成功；本地路由、解析和目标服务仍可能失败。REJECT 则拒绝匹配请求，适合明确需要阻断的对象，不应用来掩盖原因不明的连接故障。

配置中若引用额外的命名策略，应先确认当前文件确实定义并支持该名称，而不能把服务器备注随意当作策略关键字。本文示例仅使用三个基础策略，减少对文件外部对象的依赖。服务器备注、订阅名称、规则策略分别属于不同层次，名称相似并不意味着可以互换。

自上而下，首次命中后结束

Rule 按文件顺序检查，满足条件的规则决定该请求策略，后面的普通规则不再继续替它寻找“更好”的匹配。推荐把明确例外放前面，把宽范围分类放后面，再用 FINAL 处理剩余请求。这个编排便于审查，但关键仍是实际覆盖关系；某条看似具体的关键词规则，也可能比后面的后缀规则更宽。

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

blocked 名称先被拒绝，api 名称先使用 PROXY，其余 example.com 名称使用 DIRECT。若调换第一行与后缀行，阻断例外就会被后缀规则遮住。若把 FINAL 放到开头，它会提前收口，后面的规则难以按原意执行。检查顺序时应模拟请求逐行经过哪些条件，而不是只搜索目标域名有没有出现在文件中。

FINAL 不带匹配目标，通常写为 FINAL,PROXY 或 FINAL,DIRECT，放在 Rule 末尾。它表达默认选择，不表达所有请求都必须经过它。需要判断 FINAL 是否合适，先问“未被前面分类的请求应怎样处理”，再看用户已有服务器是否可用。两种末尾策略没有脱离使用场景的统一答案。

维护时可按“阻断例外、精确域名、域名后缀、地址分类、末尾策略”分组，并在组前写注释。每次添加规则，都检查已有规则是否覆盖新目标；重复行通常不会提高可靠性，反而让修改者误以为后面的行有机会覆盖前面的决定。删除重复项前也要确认参数完全相同，避免把有意设置的不同范围误删。

当 Proxy 姿态可用而 Config 不可用，优先查命中规则、DIRECT 分支、REJECT 与 DNS 关联；当两者都失败，再查服务器信息与网络。Direct 可用也不证明所有目标适合直连，只能证明当时测试目标的该条链路可达。记录同一目标在三种姿态下的结果，才能建立有意义的对照。

Host 静态映射与地址边界

映射名称，不指定策略

Host 用于把指定域名映射到静态地址。它改变的是名称对应的地址信息，不直接选择 PROXY 或 DIRECT，也不替代 Rule。需要为某个内部服务指定地址，同时让它直连时，应分别处理映射和策略；只写 Host 后就期待请求自动直连，或者只写 DOMAIN 后就期待域名被解析到指定地址，都是把两层功能混在一起。

[Host]
localhost = 127.0.0.1
intranet.example.com = 192.168.1.20

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

这里的内网名称和地址都是教学示例，只有用户自己的网络确实存在对应服务时才有实际意义。示例域名不会因为写入配置就产生服务器；静态映射也不会替用户启动目标服务。使用前先确认设备地址、服务端口和当前网络，再决定是否保留这类映射，避免把示例误当成可以直接访问的功能入口。

localhost 指向当前设备

localhost = 127.0.0.1 表示 IPv4 回环地址，指向正在发起请求的本机，不是路由器，也不是代理服务器。手机上访问 localhost，不会自动到达另一台设备上的服务。如果教程要求连接用户自己的局域网设备，应使用实际可达的地址或正确内部名称，并确认服务监听范围允许其他设备接入。

私有地址只在相应网络路由中有意义。家中 Wi-Fi 上有效的 192.168.1.20，切换网络后可能不存在，也可能对应另一台完全不同的设备。把内网名称固定到私有地址前，应考虑使用范围；如果文件长期在多种网络间使用，静态映射可能让名称继续指向已经失效的地址，表现为固定超时而不是 DNS 查询失败。

Host 不能绕过 TLS 身份检查

HTTPS 连接仍会检查目标证书与请求主机是否匹配。把域名指向另一个地址，并不会让新地址上的任意证书获得认可；服务端也可能依据主机名称选择站点。若映射后出现证书错误，应核对地址是否属于该服务、证书是否覆盖原名称，而不是把错误理解为“Host 没有生效”。解析成功与身份验证成功需要分别判断。

同一个 IP 可以承载多个站点，域名仍用于区分请求目标。因此不能把“能够连接该 IP”当成“映射到它的任何域名都能工作”。检查内部 HTTPS 服务时，应同时确认名称、地址、端口与证书。本文不要求更改证书信任来配合静态映射；优先使用用户自己服务已经配置好的名称与正确地址。

静态映射与缓存、动态服务

对采用动态地址或分布式服务的名称，固定地址可能破坏原本的调度。某次解析结果可达，不意味着它适合长期写入 Host。服务调整后，旧地址可能停止提供相同内容，且静态映射仍持续覆盖正常解析路径。没有明确维护依据时，不建议仅为了缩短一次解析过程而固定公共业务域名的地址。

应用可能保留自己的解析结果或已有连接，部分请求也不一定经过同一套解析路径。修改 Host 后，要建立新连接并查看实际目标地址；日志里仍然出现旧地址时，先排除缓存与连接复用，再判断是否选错配置。不要仅凭编辑器显示新映射，就认定目标应用已经使用它，也不要把所有应用的表现预设为一致。

删除映射后，正常解析也可能暂时受旧缓存影响。回退时应保留原文件，移除单条映射，保存并重新选用，再用同一目标复测。若名称恢复正常而某个地址仍无法访问，说明先前问题更接近静态地址失效；若仍然解析失败，则回到 DNS 章节检查系统来源与网络环境。

长期维护 Host 时，每条映射都应有可解释的用途。可在独立注释行记录“本地测试服务”或“内部固定地址”等原因，不要写账号凭据。设备重新分配地址、网络网段调整或服务迁移后，应同步复核。Host 条目越少且越明确，越容易发现失效项，也越不容易影响与该实验无关的正常请求。

URL Rewrite 与 USER-AGENT 边界

改写 URL 与选择路由不同

URL Rewrite 针对可见的请求 URL 进行匹配与改写，Rule 针对请求条件选择策略。把一个地址重定向到另一个地址，并不等于让它采用 PROXY；新地址产生的请求仍需按当前路由设置处理。理解这一点，可以避免“改写成功但目标仍打不开”时只调整正则表达式，而漏查新目标的域名规则、解析和连接状态。

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

这行展示把匹配的 HTTP 地址重定向到 HTTPS 地址的语法。左侧是正则表达式，中间是目标 URL，末尾是重定向状态码。^ 限定从字符串开头匹配，\. 表示字面点号；域名后的斜杠帮助限定主机边界。缺少转义时，正则中的点号可代表其他字符，可能匹配到原本不打算处理的名称。

路径与查询参数要明确保留

上面的简短示例没有声明保留原路径和查询参数，不适合直接套用到需要保持业务参数的请求。若目标地址包含接口路径、搜索参数或认证信息，重定向到固定首页会改变请求含义。编写改写前先列出输入与期望输出，再决定是否需要捕获组；不要先复制一条宽泛表达式，然后靠页面恰好能打开来判断正确性。

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

这个示例使用捕获组与 $1 引用，表达保留斜杠之后的内容。它仍然只是语法示例：目标服务必须支持 HTTPS，客户端必须按重定向行为继续请求。遇到编码字符、查询参数或多次跳转，应查看实际请求结果，确认新地址与预期一致。重定向不是服务器内部路径改写，也不会改变远端服务原本提供的内容。

302 与永久重定向的缓存语义不同，测试阶段采用临时重定向更容易观察变化，但仍应留意浏览器与应用自己的缓存。配置生效后，如果目标又被其他规则改回原地址，可能形成循环；若浏览器提示跳转过多，应检查每一跳的来源和目标，而不是只修改最后一条规则。每次先保留一条可解释的改写进行验证。

HTTPS 可见性与处理限制

普通 HTTPS 请求的路径与请求头处于加密连接内，不能因为客户端承载连接就假设所有字段都可供改写。需要处理 HTTPS 内容的能力涉及额外的 MITM 配置、域名范围与证书信任，并且还可能受到应用证书校验方式限制。本文的最小片段不包含这些设置，不应被理解为对任意 HTTPS 应用都能直接改写。

即使具备内容处理条件，也应限定到用户理解且需要测试的域名，不要为了让一个规则命中而扩大到所有请求。含登录参数、会话信息或个人数据的 URL 不应复制到公开笔记。若目前只是解决连接失败，先检查 Rule、DNS 与服务器，通常没有理由先进入内容改写层；路由排错与内容修改应保持独立。

USER-AGENT 不是任意应用识别

USER-AGENT 是 Rule 中基于可见 HTTP 请求头进行匹配的类型，不是按应用名称识别所有连接。加密流量中的相应请求头若不可见，就不能指望它命中；某个应用也可能采用不同标识、多个网络组件或不提供可用的该字段。因此它适合有明确请求样本的场景，不适合作为“某应用全部流量”的通用替代规则。

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

这里的 ExampleClient 是教学标识，星号表示匹配模式中的通配范围。只有实际可见字段符合该模式时，第一行才有意义；未满足条件的请求继续检查后续规则。把该行放到前面意味着匹配到的请求先采用 DIRECT，即使它随后也满足域名后缀条件。编排前要确认这种优先关系正是所需行为。

验证 USER-AGENT 或 URL Rewrite 时，先证明匹配对象可见，再证明表达式符合，最后证明结果正确。三个环节应分别记录。没有命中记录时，不要立即扩大通配范围；字段不可见、请求根本没有重新发起、配置未选用，都可能产生相同表象。先用普通域名规则完成路由基线，再逐项增加内容相关条件，更容易保持可回退的测试过程。

配置验证、排错与维护流程

先建立可重复的基线

开始排错前记录当前网络、Global Routing 姿态、选用配置、当前服务器及测试目标。不要把不同 Wi-Fi、不同目标和不同服务器的结果混作一次对照。若用户已有订阅刚更新，先确认 Home 中当前选择仍指向期望的服务器；配置文本没有改变，也可能因为订阅内容或选择对象变化而出现不同结果。

Connectivity Test 可以帮助判断服务器测试结果，但单次测试成功不等于所有目标都可达，也不等于 Rule 一定按预期命中。测试工具与目标应用可能使用不同请求路径。应把它作为基线信息，再用实际目标的新连接核对域名、地址和策略。连接开关已开启，只能说明客户端进入连接状态，不能替代目标请求的成功验证。

按处理链逐项定位

第一步确认文件确实被选用，第二步确认 Global Routing 使用 Config，第三步核对 General 是否让目标绕过通常处理路径，第四步查看域名或 IP 的实际匹配对象，第五步查命中规则与策略，最后检查所选链路的连接结果。这个顺序避免在前提尚未成立时讨论后续规则，也能区分“没有进入匹配”与“匹配了但连接失败”。

查看日志时应找同一时间的新请求。旧记录里的策略可能来自修改前的配置；连接复用也可能没有触发新的完整匹配过程。重启连接后重新打开目标，可以减少这类干扰。若仍然没有预期记录，继续检查目标是否实际发起了请求、是否使用 IP 直连以及是否受跳过设置影响，不要直接增加重复规则。

用最小规则验证单一假设

怀疑域名规则范围不正确时，复制可用配置，只保留必要 General、目标精确规则与 FINAL，暂时移除相关关键词规则、Host 和 URL Rewrite。最小文件不是长期配置，而是用于验证一个假设。如果精确规则可以稳定命中，再依次恢复后缀、地址分类与其他例外，找出是哪一层改变了处理结果。

[General]
dns-server = system

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

示例仍需要用户已有可用服务器。若它在 Proxy 姿态下也失败，继续扩充 Rule 没有明确意义，应回到服务器与网络检查。若最小规则成功、完整配置失败，则比较两份文件中提前命中的范围、静态映射和 DNS 设置。每次只恢复一组，记录第一次出现差异的位置，通常比一次性加入全部内容更快定位。

保护信息与保持回退能力

分享排错材料前，应移除订阅地址、认证字段、个人域名、敏感路径及可能识别账号的查询参数。可以保留规则类型、目标类别、策略与错误现象，并用示例域名替换真实对象。截图或日志也可能包含凭据，不应因它们不是配置文件就忽略检查。本站手册不需要用户公开自己的订阅来解释基本规则语法。

长期维护应保留最近可用的本地副本，注明每次修改的目标和测试结果。远程配置更新后，复查选用状态、FINAL、General 和关键例外，不要只比较文件名。规则新增容易、删除困难时，可以先逐组审查用途；无法说明原因的宽范围规则，应在副本中验证移除效果，而不是继续叠加新例外补偿旧问题。

基础操作回到快速上手主线；界面与规则词义可查术语表。开关已开启但网页失败时，结合服务器、模式、DNS 与规则排查逐项对照；系统授权异常可阅读添加 VPN 配置提示说明。这些入口承担不同问题，不需要为同一现象同时重做购买、导入与配置。