Shadowrocket
规则与配置参考

配置文件结构

Shadowrocket 的配置文件通常以 .conf 保存，用方括号标出不同段落，再在各段内填写相应内容。它不是把所有开关逐项抄成文字的记录，也不等同于服务器订阅。阅读时先找段名，再看该段接受的字段格式；同一句文本放进不同段落，可能失去作用或成为解析错误，不能只凭关键词判断配置是否正确。

段落分别负责什么

[General] 存放一般行为与解析相关选项，常见形式是字段名、等号和值。[Rule] 存放按顺序检查的分流规则，常见形式是类型、匹配内容和策略。[Host] 提供指定主机名的静态地址映射。[URL Rewrite] 用于符合条件的请求地址改写。段名附近的上下文比文件中的空行数量更重要。

不要把这四段理解成一条固定流水线：请求不一定先经过所有 General 字段，再逐段经过 Host 与 Rewrite。General 改变客户端行为，Host 影响名称解析，Rule 决定流量策略，Rewrite 处理可识别的请求地址。各能力的执行条件不同；把文件段落前后互换，不等于改变网络处理顺序，只有规则列表内部的排列具有直接的优先级含义。

[General]
dns-server = system

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

[Host]
# 仅在需要固定映射时添加记录

[URL Rewrite]
# 仅在明确目标请求后添加改写

订阅与配置分开管理

服务器订阅主要用于取得与更新连接条目，配置文件主要用于描述这些连接怎样参与请求处理。导入自己的订阅后，Home 中出现服务器，不代表已经启用了某份分流文件；同样，导入带有 PROXY 的规则，也不会凭空生成可连接的服务器。遇到能够解析规则却无法建立连接的情况，应分别检查服务器选择与配置是否生效，不要反复导入同一个文件。

远程配置是另一种需要独立管理的内容。更新它时，本地修改是否保留，取决于实际使用的更新与编辑方式。重要修改先另存副本，再执行刷新；不要默认订阅更新会同步修正规则，也不要默认服务器订阅失效意味着本地规则损坏。订阅刷新相关操作可另查订阅更新方法，本页集中解释配置本身。

配置可以包含服务器凭据、私有地址、请求记录相关设置或改写目标。分享文件前应逐段检查，不仅删除可见的服务器名，还要查看 URL 参数、注释与静态映射。排错时通常只需提供相关几行规则、当前模式和错误现象，不必发送完整订阅地址。示例中的 example.com 是教学域名，不能替换成他人的真实服务信息后公开发布。

编辑、保存与启用

在 Config 中找到准备修改的配置，先确认它是否为当前使用的文件，再建立可恢复副本。修改完成后保存，并检查当前配置指向是否仍是刚编辑的文件。文件名相同不代表内容相同；从远程再次下载的副本，也可能与本地编辑项并存。对照文件内容比单看列表名称更可靠，尤其是在测试多个配置方案时。

纯文本编辑应保留英文逗号、方括号和等号，不要用中文标点替代。规则最好一行一条，注释单独成行并以 # 开头，避免在策略后随意追加说明文字。若编辑器自动折行，只要没有插入真正的换行，通常仍是一条规则；复制时则要检查长地址是否被拆开，完整字段才能被正确读取。

首次验证应从较小的规则集合开始。先保留一个明确的域名条件和 FINAL，确认结果后再补充 IP、Host 或 Rewrite。若修改后异常，恢复副本比继续叠加补丁更容易定位原因。后文所有片段都展示局部语义，并非要求将每个示例同时合并；实际文件只保留符合当前目标、能够说明用途的条目。

General 与 DNS

General 是排查配置行为的起点，但不宜把不理解的字段整段复制进来。一个配置能够被导入，只能说明文本可以读取，不能证明每个字段符合当前环境。应先确认字段在应用内对应的设置与说明，再判断是否需要覆盖默认行为。对于网络解析问题，尤其要区分名称查询失败、得到的地址不可达，以及连接策略选择错误这三种情况。

从最少字段开始

dns-server = system 表示使用系统提供的 DNS 解析来源。它适合作为对照基线，但不意味着所有网络上的结果必然一致：系统得到的解析服务器会随 Wi-Fi、蜂窝网络或上游路由环境变化。测试时同时记录当前网络，否则同一文件在两次测试中表现不同，可能只是解析路径发生了改变，并非配置保存失败。

[General]
dns-server = system

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

本段示例只用于隔离域名规则与系统解析的关系，不是通用推荐方案。若已有配置中包含其他 General 字段，不必为了对齐示例全部删除。应先备份，再一次只修改一个字段，观察失败现象是否改变。客户端全局设置与文件字段之间的实际作用，还应以当前应用显示和请求记录为准，不能用某一条示例推断所有选项的覆盖关系。

配置里的布尔值、地址列表与数字参数必须遵循各自字段要求。不要把说明性中文接在值后面，也不要根据其他软件的同名字段猜测可用取值。尤其是跳过代理、排除路由与 DNS 设置，名字看似接近，影响的层次却不同；如果某条流量根本未进入客户端，继续调整 Rule 的顺序通常不会产生预期变化。

域名解析与规则命中

DOMAIN 与 DOMAIN-SUFFIX 可以利用已知的主机名判断条件，IP-CIDR 与 GEOIP 则需要目标地址信息。若客户端为了评估 IP 规则解析域名，DNS 失败就可能让这类条件无法按预期参与判断。某条规则带有 no-resolve 时，含义是不要仅为该 IP 条件额外发起解析，而不是禁止整个请求使用 DNS，更不是强制所有连接改用数字地址。

应用也可能直接连接一个 IP，或者通过自己的机制取得地址，此时客户端未必拥有原始域名。不能因为浏览器地址栏里出现了某个域名，就断定每条底层连接都携带可用域名；网页可能同时请求多个资源主机。检查请求记录时，应逐条区分主站、静态资源与接口请求，观察规则实际面对的是域名还是地址，再选择合适条件。

解析成功后仍可能连接失败。例如返回的地址在当前路径不可达，或者 PROXY 所用服务器无法访问该目标。换用 DNS 后现象暂时改变，也不足以证明根因已解决；地址缓存、连接复用和目标的多地址响应都会影响观察。应在同一网络下重复测试，并对照实际连接地址，而不是只比较网页第一次是否打开。

IPv6、缓存与验证边界

支持 IPv6 的网络可能同时返回不同地址族的结果。只写 IPv4 网段规则，并不能自动覆盖 IPv6 连接；反过来，限制地址族也不能代替修复错误的路由与解析。排查时先看失败连接使用哪种地址，再决定是否添加 IP-CIDR6 或检查上游支持情况。不要把所有双栈异常都归因于域名规则，域名条件与地址可达性是两回事。

缓存会使刚改过的配置看起来没有变化。DNS 缓存保存解析结果，浏览器与应用还可能复用已有连接；后者不会因为新规则被保存就必然重新走完整匹配。验证前结束相关请求，必要时重新连接客户端，再发起新的访问。不要以为连续刷新页面就一定产生了全新的解析与连接，记录中的时间和目的地址更有参考价值。

如果多个域名都无法解析，先恢复可用的 General 基线并检查当前网络；如果只有某个域名异常，先核对拼写、Host 覆盖与该域名本身的解析结果。若同一目标在 Direct 下能访问、在 Proxy 下失败，再检查服务器路径，不要继续盲目更换解析来源。完整的连接排查顺序可见开关已开却无法上网。

域名规则类型

域名条件适合表达按站点或服务名称分流的意图。常用的 DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD 不是三种等价写法：它们的匹配范围逐步扩大，误命中的风险也不同。选择前先明确需要一个主机名、一个域名及其子域，还是包含某个文本片段的全部主机名，再用最小范围的条件实现，而不是先写宽泛关键字再补大量例外。

DOMAIN 精确匹配

DOMAIN,example.com,PROXY 表示对 example.com 这个主机名使用 PROXY。它不会因为 api.example.com 属于同一个站点就自动覆盖该子域。精确规则适合单独处理登录接口、下载主机或某个已确认的请求目标，边界容易解释，也方便在记录中核对；代价是站点增加新的资源域名时，需要重新判断是否补充规则。

规则中的域名不要带协议、端口与路径。把完整网址填入 DOMAIN，会把原本属于 URL 的内容混进主机条件。访问 example.com 的某个页面时，规则不依赖路径文字；如果只想区分同一主机上的两个目录，单靠域名规则做不到。应先确认应用是否提供适合该需求的请求处理能力，不要把路径写进 DOMAIN 期待部分匹配。

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

在这个例子中，api.example.com 先命中精确规则，走 DIRECT；其余属于 example.com 的主机再交给后面的后缀规则。这个结果来自排列顺序，而不是 DOMAIN 天生比 DOMAIN-SUFFIX 优先。若两行调换，前面的后缀规则会先覆盖该主机；只有未命中它的请求才有机会继续检查后续条件。

DOMAIN-SUFFIX 的域名边界

DOMAIN-SUFFIX,example.com,PROXY 用于匹配 example.com 本身及它的子域，例如 www.example.com 与 api.example.com。它按域名后缀边界处理，不应被理解成对任意字符串进行结尾比较；notexample.com 并不属于 example.com 的子域。编写后缀规则前，要确认输入的是需要覆盖的域，而不是浏览器复制出的完整地址。

不要在后缀前随意添加星号来模仿通配符。这里的类型名称已经表达匹配方式，直接填写 example.com 即可。后缀越短，覆盖范围通常越大；若把条件扩大到公共后缀或一个非常宽泛的组织域，可能影响大量与目标无关的请求。维护配置时应写下注释说明覆盖目的，方便日后判断一条宽泛规则是否仍有必要。

一个网站的资源不一定全部放在它的主域下。图片、支付、身份验证或文件下载可能使用独立域名，添加主站后缀后仍有部分功能失败，并不代表 DOMAIN-SUFFIX 本身失效。应在请求记录中查找失败的具体主机，确认它确实属于需要处理的业务，再添加边界明确的条件；不要根据页面上的品牌文字猜测资源域名。

DOMAIN-KEYWORD 的适用范围

DOMAIN-KEYWORD,example,PROXY 匹配域名中包含 example 的情况，范围比后缀条件更宽，可能包含并非同一组织的主机。它适用于确有稳定命名特征、且能够接受这种覆盖范围的场景。将短词、常见词或品牌简称作为关键字，容易产生意外结果；用于阻断时尤其应谨慎，因为误命中会直接表现为无关服务不可用。

整理已有配置时，先列出关键字规则当前命中的主机，再判断是否可以改成几条精确或后缀规则。这样做不是为了单纯增加行数，而是把原本含糊的意图变成可验证的边界。对于临时排错，优先使用已经观察到的完整主机名；验证成功后再决定是否扩大范围，避免把偶然命中误认为完整方案。

三个类型都只描述条件，不决定请求最终能否成功。匹配到 PROXY 后仍需要可用的服务器；匹配到 DIRECT 后仍依赖当前网络；匹配到 REJECT 则会主动拒绝。若记录显示规则已经命中，应转向策略与连接路径排查，不必继续调整域名写法。若完全没有对应记录，还应检查该请求是否进入客户端，以及是否复用了旧连接。

IP 与识别边界

地址规则用于处理明确的目标 IP 或网段，常见类型是 IP-CIDR、IP-CIDR6 与 GEOIP。它们适合表达网络范围，不等价于域名所属组织，更不能代替对应用行为的完整识别。同一个服务可能使用多个地址，同一共享地址也可能承载多个域名。编写前先判断需要控制的是一个名称、一段网络，还是某类已能识别的请求，避免把不同维度混在一起。

IP-CIDR 与 IP-CIDR6

CIDR 用斜杠后的前缀长度描述地址范围。IPv4 中，192.168.0.0/16 覆盖对应的私有地址网段；192.0.2.10/32 则只表示一个 IPv4 地址。前缀长度不是端口，也不是任意的范围编号。输入时应使用与网络范围一致的地址，避免把某个主机地址和不理解的前缀随意组合后误覆盖更大的网络。

[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
IP-CIDR6,2001:db8::10/128,PROXY,no-resolve
FINAL,PROXY

IPv6 使用 IP-CIDR6，单个地址可用 /128 表达。示例中的 2001:db8::10 属于文档示例地址，不是实际服务器；fc00::/7 是 IPv6 本地地址范围，是否需要此类规则仍取决于网络布局。写有 DIRECT 不代表系统一定能访问目标，本地路由、设备防火墙、服务监听地址与客户端接管范围都会影响最终结果。

局域网打印机或管理页面无法访问时，先确认访问的是目标真实地址，再检查请求有没有进入客户端。如果某些地址由系统直接处理，Rule 中看不到它们并不异常。反过来，给私有网段加 DIRECT 也不代表能够发现所有设备：自动发现使用的广播或组播机制，与对某个地址建立普通连接不是同一个问题，应分别验证。

GEOIP 与 no-resolve

GEOIP,CN,DIRECT 根据目标 IP 的地理分类结果匹配 CN。它判断的是地址数据库中的分类，不是网页语言、用户所在地、域名后缀或网站运营主体。数据库内容可能滞后，服务地址也可能变化；因此不应把 GEOIP 当成某个网站永远走固定策略的保证。对确定需要例外处理的域名，前置精确规则通常更容易核查。

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

带有 no-resolve 的 IP 规则，不会仅为了判断这一条条件而额外解析一个尚无地址信息的域名。如果请求本来就以 IP 为目标，或者已有可用地址信息，它仍可能参与匹配。因此该参数不是“跳过全部 IP 规则”，也不是提高某条规则的优先级。是否添加，应该取决于是否愿意为该判断引入额外解析及其依赖。

当域名规则与 GEOIP 并存时，前面的域名条件命中后，后续地理条件通常不再决定该次策略。若期望某域名始终走 PROXY，就应把明确例外放在宽泛的地址分类之前。若只是为了减少解析步骤而给所有规则机械添加 no-resolve，可能让原本依赖解析结果的分流意图落空；优化之前先建立正确且能复现的基线。

USER-AGENT 的可见性

USER-AGENT 按可识别的请求头内容匹配，不应当作应用名称规则。它常用于客户端能够读取相应 HTTP 信息的情形，示例 USER-AGENT,ExampleClient*,DIRECT 使用模式表达一类请求头。这里的名称是教学值，只有实际记录中存在对应内容才有意义；不能把手机桌面的应用名称填进去，就期待客户端自动按应用分流。

普通 HTTPS 连接中，请求头处于加密内容内，仅有网络连接信息不代表能够读取 User-Agent。不要为让一条规则命中就随意开启额外的内容处理或安装证书。对于常规分流，先使用可观察的域名与地址条件；只有明确理解可见范围、处理条件和隐私影响时，再考虑更细的请求级匹配，且应先在受控目标上验证。

如果某条 USER-AGENT 规则从未命中，按顺序检查请求头是否可见、模式是否符合实际文本、前面是否已有规则命中，以及请求是否仍在复用旧连接。不要把不命中直接归因于协议不支持，也不要用宽泛关键字暂时掩盖问题。规则能匹配什么取决于客户端当时获得的信息，而不是配置文件里写了多少识别条件。

策略与运行模式

规则的最后一个主要字段通常是策略。PROXY、DIRECT 与 REJECT 描述不同的处理结果，但并不包含同样的信息：PROXY 需要可用的代理路径，DIRECT 使用当前网络直接连接，REJECT 主动拒绝。理解这些词之前，应先确认 Global Routing 当前选择；否则即使 Rule 内容正确，也可能并未按配置模式参与请求处理，继续修改文件只会增加排查成本。

PROXY、DIRECT 与 REJECT

PROXY 表示将命中的流量交由代理路径处理。常见基础配置依赖 Home 中当前选定的服务器，因此应先验证该服务器本身可连接。规则中的 PROXY 不携带服务器地址、密码或协议参数；把它写在每一行，也不会自动修复错误的端口、认证或服务端状态。出现连接失败时，应将“规则已命中”和“代理连接成功”作为两个独立事实记录。

DIRECT 表示不通过该代理路径直接访问目标，但并不意味着流量脱离所有系统网络机制。当前网络的 DNS、默认路由、其他 VPN 配置与上游限制，仍会影响连接。对局域网资源使用 DIRECT 时，还要确认当前设备真的处于可访问该网段的网络中；设备切到蜂窝网络后，原来可达的私有地址通常不能仅靠这条规则继续访问。

REJECT 用于拒绝命中的请求，适合边界清楚、已确认可以阻断的目标。它不是故障修复策略，也不能从域名名称判断内容一定有害。规则过宽时，页面主文可能仍可显示，但登录、验证码或文件传输会失败。添加阻断规则后要检查完整业务流程，不能只以首页是否打开判断没有副作用；保留恢复途径也比不断补充例外更重要。

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

Global Routing 三种姿态

Global Routing 中的配置姿态对应 Config，按当前配置进行分流；代理姿态对应 Proxy，用代理路径处理进入该模式作用范围的请求；直连姿态对应 Direct，使用直接连接路径。三者是运行方式，不是 Rule 里的三条规则，也不能与 PROXY、DIRECT、REJECT 简单一一对应。尤其是 Direct 姿态，并不等于在当前文件开头自动写入了一条规则。

表中的姿态不应被理解为能够绕过系统权限、接管排除项或其他网络边界。如果请求没有进入客户端，切换模式未必改变它的路径。若界面还提供 Scene 等入口，应按照该入口本身的设置核对实际状态；不能仅凭名称推断当前生效的是哪份规则。排错时先回到明确的 Config、Proxy 或 Direct，对照记录再继续处理。

在 Config 下失败、Proxy 下成功，只能提示分流或配置相关环节值得检查，不能立即断言某条域名规则写错。DNS、Host、拒绝规则与兜底策略都可能造成差异。在 Proxy 下同样失败，则应优先检查选定服务器与目标路径。每次切换后都建立新连接，并使用同一个目标测试，才能使对照结果具有解释价值。

自定义名称与实际目标

一些配置使用策略组或具体服务器名称作为规则目标。此类名称必须对应当前配置能够解析的对象，不是任意标签。将别人文件中的组名原样保留，却没有相应定义，可能造成导入提示或执行异常。基础排错时可先在副本里用已理解的内置策略缩小范围，再根据应用对自定义策略的实际支持逐步恢复，避免一次迁移整个复杂结构。

检查配置时不要只搜索 PROXY。某条规则可能指向名称相近的策略组，组内最终选择又与 Home 当前条目不同。应同时确认规则目标、组的选择和最终连接服务器，不能看到“代理”二字就认为路径一致。需要分享问题时，可用中性名称替代私人服务器标识，但应保留各对象之间的对应关系，避免脱敏后丢失排错线索。

模式测试结束后，应切回原计划使用的姿态，并核对当前配置是否仍被选中。临时使用 Proxy 让网页恢复，并不意味着 Config 中的问题已经消失；长期忘记切回还会让直连例外失去原本意义。关于首次选择服务器与打开连接开关的顺序，可返回入门指南，本页只讨论模式与规则之间的边界。

匹配顺序与兜底

Rule 的核心阅读方法是从上到下检查，前面的有效命中决定策略，而不是把所有条件打分后挑一个最精确的结果。类型名称、条件长度和策略名称本身不会自动产生更高优先级。要判断一次请求为什么走某条路径，先找到能够匹配它的第一条规则，再检查后续条目是否因此没有参与决定；不要只搜索文件中最后出现的目标域名。

例外先于宽泛条件

如果希望 example.com 及其子域默认走 PROXY，但 api.example.com 走 DIRECT，应把精确例外放在后缀条件之前。这是一种便于维护的组织方式，不是固定的语法要求。反过来，若明确希望所有子域都走相同策略，就没有必要再保留被前文覆盖的精确条目；删除失去实际作用的规则，有助于避免维护者误判它仍在控制请求。

[Rule]
# 精确例外先匹配
DOMAIN,api.example.com,DIRECT

# 再处理同一域名的其他请求
DOMAIN-SUFFIX,example.com,PROXY

# 最后处理其余请求
FINAL,DIRECT

关键字规则尤其需要注意位置。若在上方写入 DOMAIN-KEYWORD,example,REJECT，上例的 api.example.com 会先被拒绝，后面的 DIRECT 不会“纠正”它。遇到意外结果时，应检查目标之前的所有宽泛条件，而不只是检查目标附近几行。规则越多，越需要用注释说明每一组的范围与例外，不能指望类型名称替代文档。

地址规则也遵循同样的阅读思路。若某个域名的明确条件已命中，后面的 GEOIP 不再决定这次策略；若前面的 IP 判断需要地址信息，则解析行为还会影响是否能命中。排序时不仅考虑逻辑覆盖，也要考虑信息是否可获得。先确定希望表达的语义，再评估解析开销，不能为了减少一步查询把重要例外挪到失效位置。

FINAL 是最后的剩余集合

FINAL,PROXY 表示此前没有匹配的请求使用 PROXY。FINAL 不需要额外的域名或地址参数，后面的文本就是策略。它应放在相关规则列表末尾；若提前出现，后续条目对已经进入兜底的请求便失去意义。文件里出现多个 FINAL 时，不要把它们当成逐级回退机制，应整理成一个意图清楚的末尾兜底。

FINAL 选择 DIRECT 还是 PROXY，取决于配置目标，而不是哪一种写法天然正确。以大量直连例外搭配 FINAL,PROXY，与以少数代理域名搭配 FINAL,DIRECT，表达的是不同的默认范围。比较两份配置时，要同时看前面的例外集合和末尾策略；只比较 FINAL 一行，会忽略真正决定大部分请求的条件，也容易误读配置作者的意图。

兜底不会自动完成连接故障切换。某请求命中 PROXY 后连接失败，不代表客户端会继续尝试后面的 DIRECT 或另一个 FINAL；后续规则不是备用服务器列表。若需要服务器层面的选择与恢复，应查看对应选择机制，而不是在相同域名后再写一行不同策略。把分流判断和连接失败后的处理分开，是理解规则行为的关键。

冲突、重复与合并规则

完全相同条件、完全相同策略的重复条目，通常只会增加阅读成本；相同条件、不同策略的条目，则应检查哪一条先出现以及为何保留。不能简单地按字母排序整个 Rule，因为排序会改变例外与宽泛条件的关系。整理前先按用途分组，例如明确阻断、单域例外、域名集合、地址范围与兜底，再在组内处理真正等价的重复项。

合并两份配置时，不要直接把第二个 Rule 段及其 FINAL 接到第一份后面。应先提取各自意图，检查是否含相互覆盖的域名、不同的策略名称和重复兜底，再组成一个可解释的列表。远程规则内容变化时，同样需要重新核对新增条件是否扩大覆盖范围；“曾经可用”不代表更新后的匹配关系仍保持不变。

验证排序时可以在副本中只保留一组冲突条件，用同一目标反复建立新请求，观察记录中的命中类型与策略。若删除上方宽泛规则后结果改变，说明问题很可能出在覆盖关系；若完全不变，则检查是否编辑了错误文件或仍在使用非 Config 姿态。通过缩小规则集合建立证据，比不断把规则移到最上方更容易得到稳定结论。

Host 与 URL Rewrite

Host 与 URL Rewrite 都可能改变访问结果，却处于不同层次。Host 给主机名指定地址，URL Rewrite 则处理符合条件的请求地址。两者都不是选择代理服务器的替代方式，也不能用来填入订阅内容。排查时要把它们从 Rule 中分开看：某个请求可能正确命中 DIRECT，却因为 Host 指向旧地址失败；也可能先改变了请求目标，导致后续观察到另一个域名。

Host 的静态映射

在 Host 段中，一条常见静态映射写作 example.com = 192.0.2.10。左侧是主机名，右侧是地址，不填写协议或网页路径。这里的 192.0.2.10 是文档示例地址，不能直接作为真实站点使用。实际配置应填写你有权管理或已确认的地址，且只对需要固定映射的主机设置，不要把整个网站的资源域名都猜成同一个地址。

[Host]
# 文档示例地址，仅用于展示格式
example.com = 192.0.2.10
api.example.com = 192.0.2.20

固定映射改变的是解析结果，不会自动改变 TLS 中所使用的站点身份。访问 HTTPS 时，目标服务器仍需要正确处理相应域名，并提供符合要求的证书。只把域名指向一个能够响应的地址，不能保证页面可用；如果地址属于不同服务，可能遇到证书错误、默认页面或连接拒绝。不要通过忽略证书检查来掩盖错误映射，应恢复正确的目标。

Host 也不能替代端口配置。一台服务器上不同端口对应不同服务，而静态主机映射只描述名称与地址的关系。如果问题是应用连接了错误端口，应在对应连接设置或目标 URL 中修正。排错时先记录原始主机名、解析出的地址与实际端口，三者分别核对；只看域名能否解析，无法判断最终连接是否指向正确服务。

URL Rewrite 的条件与结果

URL Rewrite 规则通常用正则表达式描述要匹配的 URL，再给出替换目标与相应动作。下面的例子展示将指定教学域名的 HTTP 地址重定向到 HTTPS，并保留捕获到的路径。它只用于说明格式，复制前必须理解匹配范围与替换结果；在无法观察对应请求内容的场景下，写入规则也不代表它会处理每一条连接。

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

正则中的 ^ 约束起点，\. 表示字面上的点，(.*) 捕获后续内容，替换中的 $1 引用第一组捕获。没有转义的点会扩大匹配范围，没有主机边界的表达式也可能覆盖意外目标。不要为了让规则“更容易生效”就删除边界；应拿具体请求逐项推导它会得到什么替换结果。

重定向可能让客户端再次访问新地址，因此要检查是否形成循环。例如两条规则分别把甲地址改成乙地址、又把乙地址改回甲地址，会造成重复请求而不是恢复访问。涉及查询参数时，还应确认捕获范围是否保留了必要内容，避免认证流程或分页请求丢失参数。验证应从简单的受控 HTTP 目标开始，而不是直接用于登录或支付流程。

处理范围与回退方法

普通 HTTPS 的路径和请求头受到加密保护，客户端拥有目标域名信息不等于能够读取完整 URL。本章不要求为改写而增加证书或内容解密设置。若需求只是决定一个主机走 PROXY 还是 DIRECT，使用 Rule 更直接；只有明确需要改变可识别请求地址时才考虑 Rewrite，不能把它当作更强的域名分流规则随意叠加。

排查时分别停用 Host 映射与 Rewrite 条目，不要同时删除两段后就断言其中某一项有错。先恢复原始解析，验证目标地址是否正确；再在未改写的情况下测试请求；最后逐条恢复改写，记录第一次出现差异的步骤。这样能区分旧地址、正则范围、循环与目标服务行为，也能避免误把正常重定向当成代理连接故障。

长期保留的映射与改写需要定期复查。服务迁移后，固定 IP 可能失效；网站调整路径后，旧正则可能不再命中，或者开始覆盖新的业务地址。注释中应说明用途和验证方法，但不要写入真实凭据。无法解释用途的条目先在副本中停用观察，而不是因为来自旧配置就永久保留；维护的目标是可理解、可恢复的行为。

验证与配置维护

配置验证的目标不是让规则越写越多，而是让每次变化都有可观察的原因。开始前记录当前网络、Global Routing 姿态、选定服务器和配置文件，再选择一个稳定、明确的测试目标。若这些前提同时变化，就难以判断结果来自哪项修改。建议保留一个已知可用的基础副本，并把新规则先放进测试副本，确认后再用于日常连接。

建立最小可解释配置

最小配置应保留需要测试的条件和一个明确的 FINAL，不必一次包含所有段落。测试域名例外时，先不加入 Host 与 Rewrite；测试解析时，先避免混入大量地址条件。这样并不是要求长期采用极简规则，而是减少同一现象背后的可能原因。只有能够用一句话说明某行的目的，才容易判断它应该保留、移动还是删除。

[General]
dns-server = system

[Rule]
# 验证指定主机是否采用代理路径
DOMAIN,example.com,PROXY
FINAL,DIRECT

示例配置只能证明指定条件下的行为，不代表适合所有访问需求。使用前确保已有可用的服务器，并在 Config 姿态下测试。若没有实际访问教学域名的需求，可以换成自己正在排查且有权访问的目标，但只填写主机名。测试成功后再逐步恢复其他规则，每次新增一组并重复验证，能够直接定位首次引入异常的那次修改。

对于局域网问题，使用已知地址测试服务端口，比只看自动发现列表更有意义；对于网页问题，则应分开检查主文、登录与静态资源。一个页面成功打开并不能证明整个站点都使用同一策略。记录中应挑选真正失败的请求，确认它的主机名、地址与时间，而不是把同时发生的所有后台连接都视为故障的一部分。

按证据划分失败阶段

第一阶段确认请求有没有进入客户端。完全没有记录时，检查连接开关、系统权限、接管范围和旧连接复用，而不是先修改规则。首次授权相关问题可参阅添加 VPN 配置提示说明。已经能看到请求后，再进入第二阶段：核对域名或地址信息是否完整，实际命中的规则是否符合当前文件的排列。

第三阶段检查策略后的路径。命中 PROXY 但失败，查看选定服务器、协议参数与目标可达性；命中 DIRECT 但失败，检查当前网络与目标服务；命中 REJECT，则先判断是否预期阻断。Connectivity Test 可以帮助观察服务器连通性，但测试目标和实际业务目标不同，结果不能直接证明所有网页都能访问。必须把工具结果与实际请求分开记录。

第四阶段排除缓存与状态差异。完成一次修改后，保存并确认文件仍被选中，结束旧请求，必要时重新连接，再访问相同目标。比较时保持网络不变，不要同时从 Wi-Fi 切到蜂窝并更换服务器。若只在某一种网络异常，优先追踪该网络的解析和路由差异；若所有网络都异常，再考虑配置公共部分或目标服务本身。

备份、更新与问题记录

维护记录应写清修改目的、涉及的规则和验证方法，而不是只保留“修复网络”这样的结论。可以记录“将指定主机的 DOMAIN 例外移到后缀条件之前，重新建立连接后命中 DIRECT”，这比单纯说“移动规则有效”更便于复现。用于分享的记录应删除私有订阅参数与认证信息，只保留解释问题所需的结构和脱敏目标。

远程配置更新前先保存本地改动；更新后比较 General、Rule、Host 与 Rewrite 是否出现实质变化，而不只看文件长度。服务器订阅更新则另查条目是否仍存在、当前选择是否改变，两类更新不要混为一谈。若采用自己的维护文件，应把自动更新内容与手工例外的管理方式明确下来，避免下一次刷新覆盖刚完成的修复。

需要恢复时，切回已知可用的配置副本，并重新确认模式和服务器；不要只撤销最后一行就假定全部状态已还原。恢复后用同一目标重新验证，再决定是否继续试验。如果仍无法定位，可按常见问题中的分类继续查阅，并附上最小复现步骤。完整安装与获取问题交由下载页安装放行说明处理，本页的规则修改不能替代系统安装与权限步骤。