官方手册 · 配置参考
Shadowrocket 规则配置大全
从配置段落到最终策略，按请求的处理顺序核对规则。
Shadowrocket 是仅通过 App Store 发行的 Apple 平台付费客户端，主要用于 iPhone 与 iPad。首次使用请先按快速上手教程完成已有订阅导入和连接验证；本页用于系统查阅配置结构、规则边界及排错方法，不替代首次连接的操作主线。
以下示例以用户已有自己的订阅或服务器信息为前提。客户端一次性买断 ≠ 线路套餐，购买应用与取得连接服务是不同事项。正版获取与购买恢复请查看App Store 下载与核验说明；系统要求与兼容范围以 App Store 页面标注为准。
01 配置文件结构与修改范围
在 Shadowrocket 中，服务器信息、订阅条目与配置文件承担不同职责。服务器信息描述连接端点及协议参数，订阅用于把用户已有的一组连接信息导入并更新，配置文件则组织通用设置、匹配条件和处理策略。能在 Home 看到服务器，并不表示当前 Config 已经包含适合该请求的规则；反过来，一份规则完整的配置也不能补齐缺失的服务器地址、密码或协议参数。开始排查前，应把这三层分别确认，避免把所有问题都归结为规则。
先识别段名，再理解每一行
常见配置以方括号段名分区。[General] 放通用行为设置，[Rule] 放按顺序执行的规则，[Host] 放静态域名映射，[URL Rewrite] 放 URL 匹配与改写条目。段名确定后续行的解释方式：同一行文本移到错误段落，可能不能按预期解析。阅读时应先定位最近的段名，再看键值或规则字段，不要只凭一行里出现了某个域名就判断它是分流规则。
[General]
bypass-system = true
dns-server = system
ipv6 = false
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY
[Host]
localhost = 127.0.0.1
[URL Rewrite]
^http://example\.com/ https://example.com/ 302这份片段只是段落关系示例。它表达的是：通用设置采用系统 DNS，规则对示例域名选择 PROXY，部分地址按 GEOIP 判断，其他请求交给 FINAL；Host 和 URL Rewrite 各自处理另一类任务。示例不应被理解为所有用户都适用的推荐组合，尤其是 DNS、IPv6 和最终策略必须结合本地网络与用户已有连接服务核对。修改时保留原有必需字段，不要为了对齐示例而删除尚未理解的设置。
在 Config 中确认实际使用的文件
打开 Config 后，先区分“文件已经存在”和“文件正在使用”。导入成功只说明内容进入了文件列表，并不能证明当前连接选中了它。检查当前选择状态，再进入对应文件查看内容；需要试验时，先用应用当前提供的复制或导出功能保存副本，并给副本取能区分用途的名称。保存副本后重新检查正在使用的项目，避免编辑的是试验文件，实际连接仍使用另一份旧配置，最后误以为保存没有生效。
文件来源也影响修改能否保留。若配置由远程地址更新，应先了解再次更新时是否覆盖本地编辑。用户订阅中的服务器更新与配置文件更新不是同一回事：更新节点列表不一定改变 Rule，重新取得远程配置也不一定更新订阅。对需要长期保留的自定义规则，记录新增条目、插入位置和修改目的；当远程内容变化时，用差异核对重新合并，而不是只凭文件名相同就认为内容没有变化。
把一次修改限定在一个层次
建议按照“连接信息正确、配置文件选中、规则顺序正确”的顺序建立基线。首次调整只改一个域名规则，保留 General、Host 与改写段不动，然后重新建立待测试请求。若同时替换服务器、切换 DNS、改变最终策略并开启改写，即使访问恢复，也无法知道哪个改动有效；若失败，也没有可靠的回退边界。把修改目的写成一句具体的话，例如“让示例域名及其子域名使用 PROXY”，比“优化所有规则”更容易验证。
恢复文件时同样要按层次处理。替换回原配置后，再核对当前姿态与选中节点，必要时断开并重新建立连接，随后发起新的请求。旧连接、缓存页面和后台重试可能延续修改前的表现，不宜作为配置是否恢复的唯一证据。如果尚未完成首次导入，先返回教程主线把基础连接验证通过，再继续阅读本页后续章节；这能避免在连接端点不可用时反复修改与故障无关的规则。
02 General、DNS 与地址解析
[General] 决定一组通用行为，但它不是“速度参数集合”。其中的 DNS、IPv6、系统绕过等设置影响请求进入规则判断前后能获得哪些信息，也会改变网络兼容性。阅读已有配置时，应把每个键与应用内相应说明一起核对，不要把其他人的一组值视为固定标准。尤其在 Wi-Fi 与 Cellular 之间切换后，网络提供的解析器、地址族及可达路径可能变化，相同配置出现不同表现并不一定意味着规则文本有误。
DNS 负责解析，不等同于最终策略
域名访问通常需要取得目标地址。DNS 回答的是域名对应什么地址，而 Rule 回答的是匹配到的请求使用何种策略。两者有关联，却不能互相替代：域名解析成功后，PROXY 指向的连接仍可能失败；某条 IP 规则表现异常，也可能是实际解析结果与预想不同。排查时先记录访问的域名，再观察解析是否成功、返回何种地址，以及请求最终命中什么规则，避免把“打不开”直接等同于“DNS 有问题”。
[General]
dns-server = system
ipv6 = falsedns-server = system 表示在该设置中使用系统 DNS，并不是手动指定一个固定公共解析地址。它适合用作理解现有网络行为的起点，但不保证适用于所有网络。若网络存在内部域名，任意替换解析器可能使内部名称失去正确答案；若系统解析本身异常，也需要先检查当前网络。修改 DNS 前保留原值，修改后使用新的解析与连接结果验证，不应只刷新一个已经被浏览器缓存的页面。
IPv6 开关应结合可达性判断
ipv6 = false 在本例中关闭相关 IPv6 行为，它不是普遍适用的性能建议。支持 IPv6 的网络与服务可能具有不同于 IPv4 的连接条件，关闭后观察到变化，只能说明地址族或路径值得进一步检查，不能据此判断某一种地址族总是更快。需要启用 IPv6 时，应同时核对目标是否提供 IPv6 地址、所用服务器和协议是否按预期处理它，以及 Rule 中是否有对应的 IP-CIDR6 条目。
以地址规则排错时，必须使用本次请求实际使用的地址。如果只检查 IPv4 网段，而请求选择了 IPv6，原有结论就缺少依据。也不要把一次测试得到的地址写死为长期 Host 映射：同一域名可能随网络、地域或服务调度返回不同地址，静态固定后反而可能绕过正常的可用性调整。应先用域名规则完成路径选择，只有明确需要静态映射时，再评估 Host 的维护成本和适用范围。
理解系统绕过与规则日志的边界
bypass-system = true 涉及系统流量的绕过行为，应结合应用当前说明理解具体范围。它不代表所有业务请求都会逐条进入同一套 Rule，也不能保证开启后每个应用的行为一致。若某次访问没有出现预期日志，除了检查规则，还应考虑请求是否重用了旧连接、是否由系统组件发起、是否命中其他绕过设置。先确认待测请求确实进入了当前连接处理链，再讨论 Rule 的命中顺序。
一个可重复的测试流程是：先保留系统 DNS 作为基线，选择单一域名，记录解析和访问结果；只修改一个解析相关设置，再重新连接并生成新请求；最后对比地址、命中规则与错误阶段。若改变 DNS 后只有某个网络恢复，应继续检查该网络提供的解析服务，而不是立即把新设置推广到全部设备。规则配置的目标是行为可解释，某次打开页面只是证据之一，不足以证明所有请求都符合预期。
当同一配置在家中 Wi-Fi 正常、切换 Cellular 后异常时，先把测试条件分开记录。检查是否有 On Demand 条件改变了连接状态，再核对 Global Routing、当前服务器和地址解析结果。相关触发条件可结合On Demand 按需连接说明查阅。把网络变化与解析变化分开，通常比连续更换多组 DNS 值更容易找到稳定、可复查的原因。
03 DOMAIN 系列规则与域名边界
域名规则适合表达“某个名称或一组名称应该走什么策略”。它比把一次解析结果写成固定 IP 更贴近服务名称，也通常更便于维护。常用类型包括 DOMAIN、DOMAIN-SUFFIX 和 DOMAIN-KEYWORD，三者的区别不是优先级高低，而是匹配范围不同。Shadowrocket 按列表顺序检查，范围更精确的规则如果排在宽泛规则后面，仍可能没有执行机会。选择类型时先描述目标范围，再决定关键字，而不是先复制一条规则再猜它覆盖哪些请求。
DOMAIN：只针对完整名称
DOMAIN,api.example.com,PROXY 用于匹配指定的完整域名。它适合把接口子域名与同一站点的其他子域名区分开。这里的值不是 URL：不包含 https://、路径、查询参数和端口。若要处理某个页面路径，单靠 DOMAIN 无法表达，因为同一域名下不同路径仍属于同一个域名条件。把浏览器地址栏的整段地址粘到域名字段，是常见的匹配失败原因。
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,static.example.com,DIRECT
FINAL,PROXY这个例子把两个完整名称分别处理，而其他子域名进入后续规则。验证时应确保请求实际使用的是写入的名称：页面可能先访问主域名，再跳转到登录域名，随后从另一个静态资源域名加载内容。主页面打开并不能证明全部资源走了同一策略。应从请求记录中找出出现问题的具体域名，再决定增加精确规则还是扩展匹配范围，不要一遇到资源加载失败就把整个站点的所有名称都改成同一策略。
DOMAIN-SUFFIX：匹配域名及子域名
DOMAIN-SUFFIX,example.com,PROXY 用于覆盖示例域名及其子域名，适合统一处理同一域名树。它按域名边界匹配，不应被理解为任意字符串包含；像 notexample.com 这样的其他域名，不因为尾部字符相似就属于该域名树。编写时一般直接使用根域名，不需要在前面添加星号，也不要把路径写到值里。若只想让一个接口直连，可以先写完整域名例外，再写后缀规则。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT上述顺序明确表达“接口例外优先，其余示例域名使用 PROXY”。如果把两行对调，接口请求会先命中后缀条件，后面的精确例外就没有机会生效。这里没有“DOMAIN 天然覆盖 DOMAIN-SUFFIX”的特殊优先级，决定结果的是位置。维护大量域名时，可先把同一业务的精确例外放在一起，再放范围规则，并在修改记录里说明为什么存在例外，避免以后整理时误删。
DOMAIN-KEYWORD：谨慎使用字符串范围
DOMAIN-KEYWORD,example,PROXY 根据域名中的关键字进行匹配，范围通常比后缀规则宽。它适合目标确实由稳定关键字定义的场景，但也容易匹配到原本不打算处理的其他名称。关键字短到只有常见片段时，误匹配风险更高；不能因为一次测试有效，就认为它等价于某个服务的完整域名集合。需要可预测范围时，优先使用明确的 DOMAIN 或 DOMAIN-SUFFIX 条目。
| 类型 | 条件范围 | 检查重点 |
|---|---|---|
DOMAIN | 指定完整域名 | 不含协议、路径和端口 |
DOMAIN-SUFFIX | 域名及其子域名 | 例外条目应放在前面 |
DOMAIN-KEYWORD | 域名中的关键字 | 检查不相关名称是否被覆盖 |
域名判断还依赖客户端是否能够取得对应名称。对于只呈现为 IP 的连接，不能假定它一定能命中 DOMAIN；对于已经建立的长连接，规则修改也不一定立刻反映在旧会话上。验证时新建连接、查看记录里的实际目标与命中项，必要时在完成一次测试后关闭相关应用再重新发起请求。如果当前问题是“某一个域名始终不按例外执行”，先查前方更宽的规则，再查名称信息是否存在，最后才考虑解析与缓存。
04 GEOIP、IP-CIDR 与补充规则
域名规则之外，IP 规则直接依据目标地址进行判断。它们适合已知网段、内部服务及按地址归属分类的需求，但不能自动表达某个网站的全部业务范围。网站可能使用多个地址，地址也可能由多个服务共用；把一次解析得到的地址扩大成整个网段，会把其他目标一起纳入规则。编写地址条件前，应确认需要匹配的是一个固定地址、一段受控网络，还是一个依赖数据库归属判断的集合，这三类需求应分别处理。
IP-CIDR 与 IP-CIDR6 的范围
IP-CIDR 用于 IPv4 地址段，IP-CIDR6 用于 IPv6 地址段。斜杠后的数字是网络前缀长度，不是端口号；IPv4 的 /32 表示单个地址，IPv6 的 /128 表示单个地址。前缀越短，覆盖范围通常越大。内部网络中应根据实际网段填写，不能因为地址开头相似就随意扩大范围。示例里的文档保留地址用于说明格式，不代表实际连接目标。
[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,PROXYno-resolve 的作用是避免仅为尝试该 IP 条件而额外进行域名解析。它不是“忽略所有 DNS”的开关，也不保证整个请求过程完全不需要解析。若请求只有域名信息、尚无可用于判断的目标地址，带此选项的 IP 条件不应被当作必然命中；后续仍会继续检查其他适用规则。是否使用它取决于规则目的：希望避免额外解析，和希望借助解析结果进行地址分类，是不同的取舍。
GEOIP 是地址归属判断
GEOIP,CN,DIRECT 按可用的地址归属数据判断目标是否属于指定地区代码。这里检查的是 IP 归属，不是域名后缀、页面显示的语种或访问者所在位置，也不保证能反映服务实际部署的全部情况。相同域名在不同网络返回不同地址时，命中结果可能改变；数据库分类与运营实际之间也可能存在差异。因此，对必须固定策略的特定域名，应在 GEOIP 之前写明确域名规则，而不是期待地区分类替代业务例外。
[Rule]
DOMAIN,api.example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY这个顺序先固定接口策略，再对其余可判断的目标执行 GEOIP，最后兜底。若接口在本次解析中取得的地址符合 CN，仍然会因为前面的 DOMAIN 先命中而使用 PROXY。反过来，如果把 GEOIP 放在前面，接口可能在地区条件处结束匹配。检查这类问题时，既要看实际地址，也要看规则位置，不能只展示一个域名和一个地区标签就断定客户端判断错误。
USER-AGENT 的适用条件与限制
USER-AGENT 依赖可获得的请求头信息，并不是对所有应用都可靠的身份识别机制。应用可能修改请求头，同一应用的不同请求也可能使用不同值；加密连接中的请求头不一定能直接取得。不能因为请求来自某个应用，就假定它一定携带可以匹配的 USER-AGENT。需要稳定地选择服务路径时，优先确认能否用明确域名和地址完成表达，而不是仅依据应用显示名称推断规则条件。
[Rule]
USER-AGENT,ExampleClient*,PROXY
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT示例中的 ExampleClient* 只是说明匹配值的形式，应以实际可观察到的信息及应用支持的匹配方式为准。不要为了使这一条规则命中而直接开启不理解的流量解密设置；本页不把 USER-AGENT 作为通用分流前提。若记录无法提供请求头，转向可观测的域名或 IP 条件更容易验证，也更便于跨网络维护。配置的可读性来自条件明确，而不是使用的规则类型越多越好。
对地址规则进行回归检查时，至少选取一个应命中的目标和一个不应命中的目标，并确认两者都建立了新连接。内部网段还应在不同 Wi-Fi 下分别验证，因为相同地址段可能在另一网络对应完全不同的设备。如果问题表现为全局连接变慢，而非单条规则异常，可继续阅读速度慢的逐层排查，把服务器可达性、本地网络和规则匹配分开检查。
05 PROXY、DIRECT、REJECT 与 Global Routing
规则的最后一部分通常是处理策略。PROXY、DIRECT 和 REJECT 分别表达代理连接、直接连接和拒绝处理，但它们不等于 Global Routing 中的三个姿态。策略是在规则命中后决定处理方式，姿态则决定当前整体连接采用怎样的路由模式。把两者混在一起，容易出现“写了 DIRECT 却仍然走代理”或“改了规则完全没变化”的误判。开始测试前，先看 Global Routing，再看当前 Config，最后看具体命中条目。
配置 / Config：按当前配置检查
配置姿态对应界面词 Config，是验证 Rule 的主要工作状态。在此状态下，已进入相应处理链的请求按配置条件选择策略。它不是自动保证所有业务都符合用户预期，而是把决定权交给当前配置及相关设置。若选择了错误文件、前面存在宽泛规则、Host 改变了地址，结果仍可能不同。对规则进行修改、截图记录或请求他人协助时，写清当前为 Config，比只说“已经开启连接”更有价值。
代理 / Proxy 与直连 / Direct：用于对照
代理姿态对应 Proxy，主要用于检查代理路径；直连姿态对应 Direct，主要用于观察直接连接表现。它们可作为对照条件，但不应被理解为会覆盖所有系统绕过、地址解析或协议行为的绝对开关。测试时保持服务器、网络和目标一致，只切换姿态；若 Proxy 可访问而 Config 不可访问，应优先检查规则、最终策略和相关配置。若 Proxy 本身也不可访问，先确认连接信息与服务器可达性，不必立即重写 Rule。
| 姿态 | 主要用途 | 测试时关注 |
|---|---|---|
配置 / Config | 按当前配置选择策略 | 选中文件、命中规则、FINAL |
代理 / Proxy | 对照代理连接路径 | 当前服务器、协议参数、可达性 |
直连 / Direct | 对照直接连接路径 | 本地网络、解析和目标可达性 |
PROXY 不会创建连接服务
PROXY 只是把匹配请求交给相应代理路径，不会自动生成服务器信息，也不会修复已经失效的订阅。应先在 Home 核对选中服务器来自用户已有的连接信息，并确认地址、端口、认证和协议参数一致。某些协议还涉及传输方式、TLS 名称或其他扩展字段，不能只看名称相同就认定参数完整。客户端一次性买断与连接服务分开，规则正确也不意味着服务器必然可用。
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,local.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
FINAL,PROXYDIRECT 表示从当前网络直接连接目标，不等于目标一定可以访问。内部名称可能依赖特定 Wi-Fi 的 DNS，某些服务器也可能只允许特定来源地址。DIRECT 失败时，应核对本地网络与解析结果，而不是马上把它改成 PROXY。判断规则是否正确和判断目标是否可达是两个问题：命中了预期的 DIRECT，但目标拒绝连接，仍然可能是规则已经正确执行，只是连接环境不满足目标要求。
REJECT 应有清晰的限制范围
REJECT 用于拒绝匹配请求，适合明确知道不需要访问的目标。不要一开始就把宽泛关键字或大段地址交给 REJECT，否则页面依赖的接口、登录跳转或资源请求也可能被一并阻断。出现页面部分空白、反复加载或登录失败时，应检查相关请求是否命中了拒绝条目。删除规则之前先在副本中暂时缩小范围，用同一操作重新测试，确认问题确实来自该条件，再保留最小必要修改。
FINAL 同样需要指定策略。例如 FINAL,PROXY 表示前面均未匹配时进入代理路径，FINAL,DIRECT 则表示其余请求直接连接。两者是不同的配置目标，没有对所有用户都成立的默认答案。决定最终策略前，应列出哪些请求必须例外、所用服务是否可达以及维护规则的方式。更多常见现象可在问答页查阅，但排查记录中仍应保留当前姿态和实际命中策略，不能只写“连接失败”。
06 匹配顺序、例外与 FINAL
规则列表的核心原则是自上而下检查，先命中的适用条目决定策略。不要把它想成先收集全部条件，再自动挑选“最精确”的一个；在普通顺序规则中，后面的精确条件不会天然推翻前面的宽泛条件。因此，一份配置不仅要看有哪些规则，还要看它们排列在哪里。排查某条规则不生效时，从列表开头向下阅读，往往比只搜索那一行更快，因为真正拦住请求的可能是早已存在的上方条目。
先放明确例外，再放范围条件
一种便于维护的组织方法是：先写具体业务例外，再写域名树或受控网段规则，然后放通用分类，最后写 FINAL。这个顺序不是唯一合法结构，而是让阅读者容易理解“为什么这个目标与大多数目标不同”。例如接口必须走 PROXY，但同一域名树其余请求希望 DIRECT，就应把接口 DOMAIN 放在 DOMAIN-SUFFIX 前面。若后续增加关键字规则，也要重新检查它是否越过了原先的例外边界。
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY对 api.example.com 的新请求，第一行已满足条件，就不应再用后面的后缀条件解释结果。对 static.example.com 的请求，第一行不匹配，第二行才有机会决定策略。对没有命中域名规则的目标，再考虑地址条件和 GEOIP。这个阅读顺序也可用于人工检查：为目标逐行写出“匹配”或“不匹配”，找到第一条匹配的位置，就能判断配置表达是否与修改意图一致。
FINAL 是兜底，不是修正规则
FINAL 通常放在 Rule 末尾，为未被前面条件处理的请求提供明确结果。放在前部会使后面的普通规则失去执行机会，也会让读者误以为后面还存在有效例外。重复出现 FINAL 通常说明合并配置时没有整理结构，应在副本中保留一个符合目标的末尾兜底，再检查之前的条目。不能用追加第二个 FINAL 的方式“覆盖”前一个，也不要把它当成统计或测试用标记。
合并两份配置时，不能把两个完整 Rule 段的内容原样首尾拼接后就结束。应先提取各自的精确例外，检查同一条件是否指定了不同策略，再决定宽泛条目的先后关系，最后合并为一个明确兜底。重复条件即使语法正确，也可能使维护者误读真正生效的那一行。清理时不要只按文本去重，还要理解覆盖关系：一条后缀规则可能覆盖许多并不完全相同的完整域名规则。
用冲突案例验证理解
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
DOMAIN,api.example.com,PROXY
FINAL,PROXY这个例子中，接口请求先命中第一行，所以第二行没有机会决定结果。修正方式是调整两行位置，而不是更换代理服务器，也不是再复制一条相同 DOMAIN 到末尾。相反，如果第一行的 DIRECT 本来就是希望覆盖全部子域名，那么应删除没有实际作用的后续例外，让文件反映真实意图。规则越少不一定越好，但每一条保留规则都应该有可说明的作用范围和测试依据。
规则改动后，要考虑连接复用带来的观察延迟。一个已经建立的连接可能继续沿用原路径，网页刷新也可能没有生成你以为的新连接。可先保存配置并确认选中状态，再重新建立连接，随后发起新的测试操作。若需要对照，固定同一网络、同一服务器与同一目标，避免把网络切换引起的地址变化当成顺序变化。对动态分配地址的域名，记录每次测试的实际解析结果也很重要。
最后进行反向检查：除了目标例外是否生效，还要确认相邻业务没有被新规则影响。例如把一个精确域名改成关键字后，应检查至少一个不相关但含相同字符串的名称。把 GEOIP 向上移动后，应检查之前需要固定 PROXY 的接口是否仍先命中例外。维护规则的过程是维护条件之间的边界，而不是不断在末尾追加条目；每次整理都应保留可回退副本，并重跑一组固定测试。
07 Host 与 URL Rewrite 的作用边界
Host 与 URL Rewrite 经常同时出现在配置中，但它们与 Rule 解决的不是同一个问题。Host 用静态映射影响名称解析结果，URL Rewrite 根据 URL 条件进行改写或重定向，Rule 则选择处理策略。某个域名已经匹配 PROXY，并不意味着它的解析或改写一定正确；添加 Host 也不会自动使请求直连。排错时应分段禁用或回退试验，把“目标变成了什么”和“目标经什么路径连接”分开观察。
Host 固定名称与地址的关系
[Host]
localhost = 127.0.0.1
test.example.com = 192.0.2.10第一行是常见的本地名称映射示例，第二行使用文档保留地址说明语法，不是可用服务。实际使用时，只有明确知道目标地址并有相应测试需求，才应固定映射。网站正常解析可能包含多个地址和故障切换逻辑，Host 则会把本地观察固定到指定结果。若服务地址改变，原来可用的映射可能变成故障来源。因此，应为每条自定义映射记录用途，并在结束临时测试后评估是否移除。
静态映射通常不会改变请求所使用的域名本身，也不能替代 TLS 中对名称的校验。把某个 HTTPS 域名指到另一台服务器后，那台服务器仍需能正确处理原域名并提供匹配证书；只要地址可达就认为访问一定成功，是常见误区。出现证书名称不一致时，先恢复正常解析或核对服务器配置，不要把证书错误归咎于 DOMAIN-SUFFIX 的策略，也不要用关闭校验掩盖映射目标不正确的问题。
URL Rewrite 匹配的是 URL 条件
[URL Rewrite]
^http://example\.com/ https://example.com/ 302这条示例将匹配的 HTTP 地址重定向到示例 HTTPS 地址。正则表达式中的 ^ 表示起始位置，\. 表示域名中的字面点号，结尾斜杠用于收紧匹配边界。若点号不转义，它在正则里可能代表任意字符；若域名后缺少合理边界，表达式也可能匹配到原本不打算处理的地址。这里的目标地址是固定值，不应假设它会自动保留全部路径与查询参数。
302 表达重定向响应。重定向会让客户端访问新的 URL，并不是在原请求内部悄悄替换全部连接行为。新的请求仍需解析、选路并完成连接；如果目标不可达，改写本身成功也不能让页面正常打开。测试时应分别核对原始地址是否符合表达式、响应是否指向预期目标、后续请求是否被正常处理。只看到浏览器地址发生变化，不能证明后续资源请求也都正确。
先确认可观测范围，再启用改写
HTTP 与 HTTPS 的可见信息不同，不能假定配置里写了一条规则，就能直接读取所有加密请求的完整 URL。对需要额外条件才能观察的内容，应先阅读应用当前相关说明，评估涉及的证书与信任设置。本页的普通规则分流不依赖开启流量解密，也不把它作为修复访问问题的默认步骤。若目的只是给某个域名选择 PROXY，应使用 Rule，没必要为了路径匹配引入额外处理层。
一份可维护的改写规则应说明原始范围、目标地址和预期响应。复制包含捕获组的复杂正则时，先确认替换字符串如何引用捕获内容，再用最简单路径与带查询参数路径分别测试；不能把语法看似相近的表达式直接视为等价。用于临时诊断的规则应与长期规则分开记录，结束后清理，避免日后访问其他路径时触发遗留行为。复杂不意味着更准确，能覆盖实际需求的最小表达式通常更容易复核。
联合排错时，先保留正常 DNS 与最小 Rule，确认目标本来可达，再加入 Host 或 URL Rewrite。若只有加入 Host 后失败，检查地址和证书；若只有加入改写后失败，检查匹配边界、目标与循环；若两者都撤回后仍失败，再回到服务器与网络层。采用这样的顺序，可以避免用更多规则去补偿错误映射或错误重定向，也能清楚知道最终保留的每一段究竟解决了什么问题。
08 配置验证、故障定位与回退
完成编辑后，验证应围绕一个明确目标展开，而不是把“网页能打开”作为唯一结论。先描述期望：哪个域名、在什么网络、使用哪个服务器、应命中哪条规则，以及应得到 PROXY、DIRECT 还是 REJECT。随后确认当前 Config 与 Global Routing，再发起新的请求观察结果。这样即使请求失败，也能区分规则是否已经正确执行，故障发生在解析、连接、认证还是目标响应阶段，而不是继续盲目增删条目。
建立一组可重复的测试记录
每次测试记录目标、网络环境、选中服务器、配置文件和命中结果。至少准备三类目标：明确应该 PROXY 的例外、明确应该 DIRECT 的例外，以及应该落到 FINAL 的普通目标。涉及拒绝规则时，再增加一个预期 REJECT 的目标。测试值使用用户实际有权访问的服务，不需要为了验证去寻找新的连接服务。对比两轮结果时，除被修改的那一项之外，其他条件尽量保持不变。
| 观察项目 | 需要记录 | 异常时先查 |
|---|---|---|
| 配置状态 | 当前 Config 与 Global Routing | 是否编辑了未选中的文件 |
| 解析结果 | 目标域名与实际地址 | DNS、Host、地址族 |
| 规则结果 | 首次命中条目与策略 | 上方宽泛规则、FINAL 位置 |
| 连接结果 | 失败阶段及错误提示 | 服务器参数、本地网络、目标状态 |
把 Connectivity Test 与业务请求分开
Connectivity Test 可辅助判断相应测试条件下的连通情况，但测试成功不保证每个网站、每种请求和每条分流规则都能工作。业务请求可能使用不同域名、地址族、连接方式或认证流程。反过来，某项测试失败也不应直接等同于所有业务都不可用，应查看测试对象和错误信息。正确做法是先用测试工具缩小范围，再用实际业务的新请求确认规则与路径，不把单一结果当成全部网络状态。
如果全部 PROXY 请求都失败，先保持最小配置，核对当前服务器及用户已有服务状态；如果只有某个域名失败，查看命中规则、解析与目标响应；如果页面主体可用但资源缺失，分别查找资源域名和 REJECT 条目；如果切换网络才失败，记录 DNS、On Demand 与地址族变化。这样的分支比一次修改所有 General 参数更有效，也能避免因为一个业务接口异常而破坏本来正常的其他规则。
日志只保留必要信息
借助应用提供的记录观察目标、命中规则和错误阶段，但不要把订阅链接、密码或认证字段直接粘贴到公开讨论。需要保存排错材料时，先检查截图与文本中的敏感信息，再提供能够复现问题的最小规则片段。服务器名称也可能包含用户自定义标记，应一并核对。分享一整份配置并不会自动提高排错效率，保留清晰的请求条件与首次命中证据，通常比大量未经整理的日志更有帮助。
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY上面的最小片段可以说明规则先后关系，却不暴露连接凭据。实际整理问题时，可用示例域名替换真实业务名称，同时保留“精确例外在后缀前面”这样的结构关系；如果问题依赖实际地址归属，则应说明已做脱敏，避免让阅读者把示例地址当成真实测试结果。复现材料要能够解释逻辑，但不需要包含用户订阅或服务器认证信息，更不应把私密链接作为问题标题或文件名。
回退并确认远程更新没有再次覆盖
出现不符合预期的行为时，恢复修改前副本，确认它已被选中，再恢复原 Global Routing 与服务器选择，重新建立连接后执行同一组测试。若恢复后立即正常，逐个重新加入修改以定位最小差异；若恢复后仍失败，检查网络和服务状态是否也发生变化。远程配置再次更新可能覆盖本地修订，因此回退完成后还应核对文件内容，而不是只看列表里的名称与上次相同。
日常维护可以保留一份稳定配置、一份试验副本和简短变更记录。新增规则后运行固定测试，订阅更新后确认选中节点仍符合预期，更换设备后重新核对配置是否已经导入，不假定应用已购状态会同步所有连接信息。iPad 的获取与购买关系可查阅iPad 已购应用与使用说明；恢复购买只解决应用获取，不替代配置迁移和服务器参数核对。
需要重新走通完整连接流程时，返回Shadowrocket 使用教程；需要快速定位常见现象时，查看问答与故障排查；需要核对应用来源时，前往正版三要素核验。应用图标、开发者 Shadow Launch Technology Limited 与应用 ID 932747118 应在商店页共同核对。配置维护始终以可理解、可验证、可回退为准，不以规则数量或文件长度判断质量。