Shadowrocket 配置大全 规则与匹配顺序

配置文件结构：先分清数据与规则

Shadowrocket 中的服务器信息与配置文件承担不同任务。服务器信息描述连接到哪里、使用哪种协议以及怎样认证；配置文件描述请求如何处理、哪些目标直接连接、哪些目标交给代理策略。导入订阅后能够看到服务器，并不代表已经选中了预期的规则文件。反过来，保存了一份包含完整规则的文件，也不等于其中引用的代理出口已经具备可用参数。查错时应把这两部分分别确认。

Config 中的文件与实际生效文件

进入 Config 后，先核对当前使用的文件，再查看准备编辑的文件。列表里同时存在多份配置时，文件名称只用于辨认，不能证明其中内容相同。修改前保留一份副本，记录当前 Global Routing 姿态和所选服务器；这样即使修改导致访问异常，也能退回原文件进行对照。远程配置还要确认更新方式，避免本地编辑随后被来源文件覆盖。

配置文件通常使用分节结构，方括号包围节名，节内逐行填写设置或规则。General 集中放置通用选项，Rule 描述请求分流，Host 描述静态主机映射，URL Rewrite 描述符合条件的 URL 处理。各节的职责不同，不能因为都写在同一文件里，就把它们理解为一张从头执行到尾的规则表。尤其不能把 Host 行直接粘贴进 Rule。

[General]
bypass-system = true
dns-server = system

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

阅读片段时保留上下文

上例是用于查阅的最小片段：General 中两行采用等号赋值，Rule 中各项采用英文逗号分隔。它只展示通用选项、域名规则、私有地址规则与兜底规则的关系，不能代替你的服务器信息。PROXY 表示交给代理策略，最终出口仍依赖当前配置和所选服务器。示例中的 example.com 是保留示例域名，替换时应使用实际需要处理的目标，而不是服务商的服务器地址。

理解一行规则时，先看首字段的规则类型，再看匹配对象，最后看策略与可选参数。例如 IP-CIDR 行比 DOMAIN-SUFFIX 行多了 no-resolve，含义与触发域名解析有关，不是策略名称。FINAL 的结构又不同，它没有匹配对象字段。复制时应保持英文标点和字段顺序，避免输入法把逗号变成中文逗号，或者给节名添上多余字符。

注释应单独成行，说明为什么需要某个例外，而不是仅仅把规则原文复述一遍。对于从他处取得的片段，先判断它属于哪个节、需要哪些前置条件，再决定插入位置。不要默认所有具有类似节名的配置都能直接互用；设置项、可选参数和功能支持应以 Shadowrocket 当前应用内说明为准。遇到无法识别的项目，应缩小到单行验证。

本地维护与订阅更新的边界

Subscribe 主要用于更新服务器项目，Config 文件更新则可能改变规则、DNS 或其他通用行为。两者即使来自同一服务商，也不必然具有相同更新范围。维护前先问清楚正在更新的是哪一类内容，再观察更新后服务器选择与规则文件是否发生变化。把连接异常一概归因于订阅失效，容易遗漏实际是文件切换或本地例外被替换的问题。

保存配置后应回到使用入口核对生效状态，而不是只确认编辑器已经关闭。某些选项对新连接才有意义，旧连接仍可能沿用之前建立的通道。用于比较的测试应关闭旧请求后重新发起；若需要重新建立连接，先保存正在进行的工作。完整操作顺序可参照使用说明，本页后续章节侧重解释每项设置的判断依据。

域名规则：精确、后缀与关键词

域名规则适合表达“这个服务应当使用哪种策略”，通常也比维护不断变化的服务地址更直观。选择类型时，应先明确希望覆盖一个完整主机名、一个域名及其子域名，还是任何包含某段文字的域名。三者的覆盖范围逐步扩大，不能仅因写起来短就选最宽的类型。范围越宽，越需要检查是否会匹配原本不相关的请求。

DOMAIN：完整域名精确匹配

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

DOMAIN 用于匹配完整域名。第一行只表达 api.example.com 的处理方式，不自动包含 example.com，也不自动包含更深一级的子域名。适合用于单个接口或作为大范围规则之前的特定例外。填写时只写主机名，不带 https://、端口、路径或查询参数；这些 URL 组成部分不是 DOMAIN 的匹配字段，混在一起会改变原本想表达的对象。

精确规则便于审查，因为每一项都能对应到一个具体服务。代价是当页面又请求其他域名时，需要另行确认它们的策略。不要看到主域名已命中，就认为登录、图片、验证和接口请求也走相同出口。排查时应从失败的请求记录取得实际主机名，再决定是否补充规则；从网址外观猜测依赖域名，容易漏掉真正失败的位置。

DOMAIN-SUFFIX：域名边界上的覆盖

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

DOMAIN-SUFFIX,example.com,DIRECT 用于覆盖 example.com 及其子域名。它按域名后缀关系判断，不等于任意字符串包含，因此不应把另一个仅在名称中含有 example.com 字样的域名视为同一范围。上例先对 api.example.com 指定 PROXY，再让该域下其他请求使用 DIRECT。精确例外在前、概括规则在后，阅读时即可看出例外与默认行为。

写后缀时通常填写 example.com，而不是把浏览器中的完整 URL 原样复制进去，也不要把网页路径当成域名的一部分。通配符式的 *.example.com 不应凭其他语法的习惯直接套入这里。若只需要一个主机名，优先使用 DOMAIN；若确实需要整组子域名，再使用 DOMAIN-SUFFIX。范围应由业务需求决定，而不是由规则数量决定。

DOMAIN-KEYWORD：字符串范围更宽

[Rule]
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT

DOMAIN-KEYWORD 检查域名中是否包含指定字符串。它不理解某段文字是不是品牌、组织名称或域名边界，所以 example 可能出现在多个彼此无关的域名中。关键词规则适合明确知道覆盖范围的场景，也可用于临时诊断，但不能替代对目标域名的梳理。短词、常见词或带有业务含义的宽词，尤其容易造成意外命中。

把关键词规则插在精确规则之前，会让后面的精确规则失去处理这些请求的机会。即使精确规则“看起来更具体”，也不会因此自动获得更高优先级。测试时应选取三类目标：确实需要覆盖的域名、不应覆盖但含相同文字的域名、完全无关的域名。只有覆盖与排除都符合预期，才能说明这条规则的边界适合当前配置。

规则对象不是服务器名称

域名规则中的匹配对象是请求目标，不是 Home 中展示的服务器备注。改动服务器名称不会让 DOMAIN-SUFFIX 的匹配对象随之改变；反过来，修改目标域名规则也不会修正服务器认证参数。若同一目标在 Proxy 姿态能访问、在 Config 姿态失败，应首先比较命中策略和出口，而不是立即重填 Add Server。两个层面的改动应分开验证。

审查现有域名规则时，可以按“精确例外、明确后缀、必要关键词”的顺序整理，并为每组记录目的。删除重复项之前先比较策略：同样的域名配上不同策略，并不是可以随意合并的重复。若需要屏蔽目标，策略可改为 REJECT，但匹配范围的判断仍完全相同；具体边界见REJECT 规则与拦截原理。

连接策略与 Global Routing 三姿态

规则告诉客户端“哪些请求属于这一类”，策略告诉客户端“这一类请求怎样处理”。PROXY、DIRECT、REJECT 是规则中的策略关键字；Global Routing 下的 Config、Proxy、Direct 则是整体运行姿态。两组名称有关联，但不是同一个层次。排查前必须同时记录当前姿态与命中策略，否则容易把姿态改变造成的结果误认为某条规则已经修好。

PROXY、DIRECT 与 REJECT

PROXY 表示把匹配请求交给代理策略，最终能否建立连接仍取决于出口选择、协议参数、认证信息与当前网络。它不承诺任意目标均可访问，也不自动生成服务器。DIRECT 表示直接连接目标，连接仍会经过当前设备接入的网络。REJECT 表示拒绝匹配请求，客户端可能以相应失败结果结束连接；它不是把请求改送到另一个服务器。

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

三条示例分别表达代理、直接连接与拒绝处理，域名只是教学对象。若 api.example.com 命中 PROXY 后失败，下一步应检查出口，而不是假设客户端会退回 DIRECT。若 blocked.example.com 命中 REJECT，出现连接失败正是策略结果，不能再把这一结果当成服务器失效的证据。测试应先明确成功标准：允许访问、按指定出口连接，还是按预期被拒绝。

Config、Proxy、Direct 的比较用途

这里的三姿态描述用于建立排查思路，并不意味着系统中的每一类流量都必然被同样处理。系统流量、配置中的绕过项以及具体功能仍可能形成边界。对照测试应使用同一个目标和新建立的请求，保持网络环境一致，并查看实际记录。仅凭状态栏图标或某个页面能打开，无法确认所有请求走了哪一种路径。

如果 Proxy 可用而 Config 不可用，优先看目标是否被 DIRECT、REJECT 或其他更早规则处理，再检查当前 Config 文件是否正确。若 Config 与 Proxy 都失败，可以继续验证服务器地址、端口、协议和认证信息，并用其他已知可用目标区分出口整体异常与单个目标异常。Direct 可用只说明当前网络具备一条可行路径，不证明代理参数一定正确。

选中服务器与规则策略的关系

Home 中选中的服务器、配置中存在的策略组以及规则引用的策略名称，需要放在同一上下文里理解。简单配置可以使用 PROXY 交给当前代理策略；复杂配置若引用自定义策略名称，则必须确保该名称确实存在且指向有效成员。不要把别人文件中的自定义名称直接当成通用关键字复制，也不要认为修改服务器备注后所有引用都会自动保持有效。

协议参数决定代理连接本身的建立方式，与规则策略是相邻但独立的层。以 Trojan 为例，地址、端口、密码与 TLS 相关参数需要按已有服务器信息填写；把规则从 DIRECT 改为 PROXY，并不能修正错误的认证参数。相关字段的填写边界可查阅Trojan 参数说明，排查时仍要保持规则与服务器两条线分开。

REJECT 也不能代替内容过滤的全部需求。一个域名可能同时承载必需功能和希望拒绝的请求，整域拒绝可能影响登录、加载或同步。对于加密流量，域名级规则通常不能据此区分同一主机下的不同网页路径。需要更细的控制时，应先确认目标信息的可见性和功能边界，而不是不断追加范围更宽的关键词规则。

完成对照测试后，应恢复原计划使用的姿态并再测试一次。临时使用 Proxy 验证连接后忘记切回 Config，是“规则看似不生效”的常见原因；临时使用 Direct 后忘记恢复，也会产生类似误判。把当前姿态、服务器与文件写在同一条测试记录里，通常比保留大量没有上下文的成功截图更有利于后续维护。

Host 与 URL Rewrite：地址映射和请求处理

Host、URL Rewrite 与 Rule 经常出现在同一配置文件中，但不能用同一套方式理解。Host 为指定主机名提供静态地址映射，URL Rewrite 根据可识别 URL 的匹配条件执行相应处理，Rule 则选择连接策略。它们分别涉及“地址从哪里来”“请求如何处理”“连接走哪条路径”。一个问题同时牵涉多层时，应分开验证每一层是否符合预期。

Host：固定解析结果不等于指定出口

[Host]
service.example.com = 192.0.2.10

这里将 service.example.com 映射到示例地址 192.0.2.10。该地址来自文档示例地址范围，不是可供访问的服务。Host 行使用等号，不采用 Rule 中的逗号结构，也不能在后面直接追加 PROXY 来指定策略。若同一目标还需要特定连接方式，应在 Rule 中单独写规则，并通过实际连接记录确认目标地址与策略都按预期使用。

Host 适合目标地址明确且能够维护的场景，不适合随意固定经常变化的公共服务地址。域名背后可能存在多地区调度、故障切换或地址轮换；固定单一地址会绕过这些变化，并可能在一段时间后失效。添加映射时应记录用途、预期有效条件与移除方式，而不是把某次解析得到的地址直接作为长期修复。

HTTPS 请求中的域名还参与证书校验与服务选择。即使映射地址可以建立 TCP 连接，目标服务也可能因为证书、SNI 或虚拟主机配置而拒绝请求。Host 映射不会自动让任意地址拥有该域名的合法证书，也不会改变服务器认证参数。遇到证书错误，应核对目标服务配置，不能用关闭校验来代替对地址正确性的确认。

URL Rewrite：先理解匹配范围

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302

上例针对明文 HTTP 的一个精确路径做重定向示范：正则表达式匹配旧地址，目标 URL 指向新地址，302 表示相应的临时重定向处理。它不是域名分流规则，不能放到 Rule 节。点号写成反斜杠加点号，是为了表达字面域名分隔点；开头与结尾的锚点用来限制范围，避免把更长路径或额外字符也纳入示例匹配。

URL 中的查询参数也会影响匹配。上述结尾的美元符号意味着带额外查询串的地址不属于这个示例的精确范围；是否要允许查询串，应按真实需求重新设计表达式。不能为了“让它都命中”就随意删掉边界或增加宽泛通配。修改前先列出应匹配与不应匹配的样本，再逐个验证，有助于发现路径、参数与转义之间的差别。

HTTPS 可见性与循环风险

域名能够用于分流，不等于加密请求的完整路径和请求头天然可见。对于 HTTPS，路径位于加密内容中，不能仅靠域名规则推断 URL Rewrite 一定可以处理。涉及加密内容的进一步处理，需要独立理解证书信任、适用域名与隐私影响；本页示例选用 HTTP，就是为了不把这类额外前置条件隐藏在一个看似简单的重写片段中。

重写规则还可能产生循环：旧地址指向新地址，新地址又被另一条规则改回旧地址，浏览器就会不断重试或报重定向次数过多。也可能出现目标地址仍符合原匹配表达式，导致同一规则反复作用。测试时应观察跳转链，而不是只看最终页面是否出现；若无法解释链中每一步，应先缩小表达式并暂时移除相关重叠规则。

验证 Host 时，保持原有 Rule 不变，只比较目标地址来源；验证 URL Rewrite 时，先用明确的 HTTP 测试地址并确认重定向，再检查目标地址的分流结果。若一次同时修改三节，即使最终成功，也难以确认依赖关系。对正常业务请求，尽量保留原始配置副本，避免测试规则影响登录回跳、表单提交或其他带状态的请求。

配置来源更新后，Host 与 URL Rewrite 也需要复查，不能只看 Rule 有没有变化。地址映射可能已经过期，服务路径可能已经调整，曾经必要的重写也可能与新行为冲突。维护记录至少应包含目标、用途与撤销条件；对于无法说明来源和目的的条目，先在副本中停用并测试，再决定是否删除，比长期保留不明规则更容易控制影响。