shadowrocket分流规则怎么设置？小火箭规则配置、策略组与配置文件完整指南

我以前把 Shadowrocket 的问题习惯性归结为“节点不稳定”，后来才发现，很多故障其实出在规则文件：同一个网站一会儿直连，一会儿走代理；节点明明能连接，某个应用却始终打不开；切换到全局模式后正常，换回规则模式又失效。

这类问题只靠换节点是解决不了的，Shadowrocket 的实际处理链路是：请求进入客户端，规则从上到下匹配，命中后交给某个策略，最后由策略选择具体节点或直连。只要其中一层理解错了，排查就会陷入反复试错。

下面我不按“点这里、再点那里”的流水账来写，而是先把规则系统拆开，再用几个真实场景说明该怎么判断。

先画出一条完整的分流链路

一条请求进入 Shadowrocket 后，大致会经过四个环节：

环节	它决定什么	常见误解
匹配条件	识别域名、IP、进程或网络请求	以为所有请求都按网站名称判断
规则顺序	决定先匹配哪一条	以为后面更具体的规则会自动覆盖前面
策略组	决定走哪个节点、直连或拒绝	以为策略组本身就是节点
兜底规则	处理没有命中的请求	忘记检查 FINAL 的方向

Shadowrocket 的配置文件可以包含域名、IP、地理位置、重写和策略等内容，规则按顺序匹配，命中后就停止继续向下查找，最后由 FINAL 处理未命中的请求。

这意味着，规则的先后顺序不是排版问题，而是实际的控制顺序。

举个简单例子：

DOMAIN-SUFFIX,example.com,DIRECT
DOMAIN,api.example.com,PROXY
FINAL,PROXY

访问 api.example.com 时，第一条后缀规则已经命中，第二条不会再生效。要让 API 单独走代理，应当把更具体的规则放在前面：

DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

shadowrocket分流规则，先理解四种动作

PROXY

把请求交给首页选中的节点，或者交给指定的策略组。它并不等于固定某个国家的节点，实际节点由策略组当前选择决定。

DIRECT

绕过代理，直接使用当前网络连接。国内网站、局域网设备和不需要代理的服务，常会放在这一类。

REJECT

拒绝请求，它适合处理明确不想访问的域名，或者规则文件中的广告拦截项目。误把正常服务放进 REJECT，页面可能表现为加载失败或没有响应。

FINAL

兜底动作，没有其他规则命中时，请求会按照 FINAL 的设置处理。有人把 FINAL 设为 DIRECT，有人设为 PROXY，结果差异很大。排查“为什么只有部分网站打不开”时，我会先检查这一行。

小火箭规则配置：不要先下载一堆规则集

搜索“小火箭规则配置”时，很多页面一上来就给出所谓懒人配置。对新手来说，下载现成文件确实省时间，但一次导入多个规则集，会让问题变得难以定位。

我会先做一个最小配置：

1. 只保留一个正在使用的配置文件。
2. 先确认节点可以单独连接。
3. 添加一条自己能验证的域名规则。
4. 用测试规则功能查看命中结果。
5. 确认无误后，再增加其他规则集。

例如，我会先加入一条测试规则，把某个明确的域名指定为 DIRECT，然后访问这个域名，再改成 PROXY 对比结果。如果两次行为没有变化，问题可能不在规则，而在当前模式、节点或 DNS。

如果你还没安装 Shadowrocket，可以先参考小火箭下载与账号区域说明。应用本身只负责读取配置，规则和节点是两套独立内容。

shadowrocket策略组到底是什么

策略组可以理解为“选择器”，它里面可以放多个节点，也可以加入直连、拒绝或其他策略组。

• 手动选择：由用户点选具体节点。
• 自动测速：从候选节点里选择延迟较低的项目。
• 故障转移：当前节点不可用时，切换到下一个候选。
• 负载或随机选择：在多个候选之间分配请求。

策略组解决的是“选哪一条线路”，规则解决的是“哪些请求交给这个策略”，二者不是同一层。

可以把它想成快递分拣：规则是分拣条件，策略组是配送路线，节点是具体车辆，DIRECT 是本地配送，REJECT 是退回，FINAL 是没有特殊标签时的默认处理。

所以，规则写成 DOMAIN-SUFFIX,example.com,PROXY 时，PROXY 可能指一个策略组，而不是某个固定节点。你在首页切换策略组里的节点，规则本身不需要重新编辑。

策略组没有节点时怎么办

如果规则页面显示 PROXY，但策略组里没有可选节点，常见原因有三种：节点订阅还没有更新；配置文件引用了一个并不存在的策略组名称；导入的规则文件和节点订阅来自不同模板。

这时继续添加规则没有意义，应先回到首页确认节点列表，再查看策略组是否能看到候选项目。

小火箭全局模式和规则模式，区别不在“快慢”

全局模式

绝大多数流量都交给代理策略，它适合确认“节点本身能不能用”，也能帮助判断问题是否来自规则匹配。

如果全局模式能打开目标服务，规则模式打不开，故障范围大多集中在规则没有命中、命中了 DIRECT、命中了 REJECT、策略组指向错误，或 FINAL 方向不符合预期。

规则模式

请求按照配置文件逐条判断，它适合日常使用，因为不同服务可以分别处理，减少不必要的代理流量。

规则模式不是“自动识别一切”。它依赖规则库的覆盖范围，也受域名、IP、DNS 和应用行为影响。某些应用使用多个接口或动态域名，只匹配主域名可能不够。

直连模式

所有请求都不经过代理，它适合临时停用代理，或者确认当前网络本身是否正常。

我的排查顺序是：先用直连确认本地网络，再用全局确认节点，最后回到规则模式检查分流。三种模式分别对应三个不同问题，混在一起切换只会增加判断成本。

shadowrocket配置文件怎么选

配置文件不只是“规则合集”，还可能包含 Hosts、URL Rewrite、DNS、脚本和策略组。下载前先看来源和用途，不能只看文件名。

文件是否明确适配 Shadowrocket

Clash、Surge、Loon 和 Shadowrocket 的语法并不完全相同。文件能下载，不代表客户端能正确解析。

节点订阅和规则文件是否分开

节点订阅负责提供服务器信息，配置文件负责规则和策略。把节点订阅地址放进远程配置文件，或者把规则文件当成服务器订阅，都会出现导入成功但列表为空的情况。

是否包含远程更新地址

带远程规则的配置会在更新时重新拉取内容。来源失效、域名变更或网络无法访问时，旧规则可能继续存在，也可能更新后变成空文件。

是否有清晰的 FINAL 规则

没有兜底规则的文件，遇到未匹配请求时很难判断去向。导入前先查看末尾设置，可以减少后续排错。

是否重复叠加多个规则集

多个规则集都处理同一批域名时，先加载的规则会抢先命中。看起来规则很多，实际可能只有排在前面的那一组在工作。

用“测试规则”找到真正命中的一行

这是很多教程没有讲清楚的一步。

当某个网站行为不符合预期时，不要先重装 Shadowrocket，也不要马上换节点。打开当前配置文件中的测试功能，输入目标域名，查看最终匹配到的规则和策略。

我会记录三项结果：命中的规则类型、使用的策略或策略组、最终选择的节点。

如果命中 DIRECT，就检查是否有过宽的域名后缀规则。如果命中 REJECT，就检查拦截规则。如果显示 FINAL，说明前面没有规则覆盖这个请求。

这一步能把“感觉配置不对”变成一个可验证的结果。相关教程也把 Test Rule 作为检查规则走向的重要工具，可参考Shadowrocket 规则测试说明。

三个常见场景，分别该改哪里

国内网站速度变慢

先查看这些域名是否被 PROXY 或 FINAL 代理。如果希望它们直连，应增加更具体的 DOMAIN-SUFFIX 或 IP 规则，并放在宽泛规则之前。

某个海外应用打不开

不要只添加首页域名。应用可能同时使用登录、接口、图片和推送域名。先看连接日志，找出失败的域名，再逐一判断是否被 DIRECT、REJECT 或错误策略组处理。

浏览器可以打开，App 却不行

浏览器和 App 的请求域名可能不同，也可能使用不同的 DNS 或网络协议。此时不要把问题归咎于策略组，先分别查看两者的日志和命中规则。

如果同时遇到 App Store 下载、账号验证等问题，可以参考App Store 下载验证排查，那属于账号和商店服务层面，和 Shadowrocket 规则命中不是同一类故障。

配置文件失效时的回滚方法

1. 暂停自动更新。
2. 切换回之前能工作的本地配置。
3. 删除最近添加的规则集。
4. 用测试规则确认目标域名的走向。
5. 只恢复一份远程文件，再观察结果。

配置文件最好保留一个日期备注，例如“2026-10-05 可用版本”。这样出现问题时，可以知道是哪次更新导致变化。

不要把完整配置文件和订阅令牌一起公开。配置里可能包含服务器地址、访问参数和个人化设置，分享前应删除敏感内容。若需要处理账号登录或购买应用的问题，应单独检查 Apple ID，而不是把账号信息写进配置文件。

FAQ

shadowrocket分流规则是自动生成的吗？

应用内会带有基础配置，但具体覆盖范围和策略取决于当前配置文件。需要更精细的分流时，要检查或导入适配 Shadowrocket 的规则文件。

小火箭全局模式和规则模式应该选哪个？

排查节点时先用全局模式，日常使用再切回规则模式。规则模式更适合按域名和策略分流，但前提是配置文件内容正确。

策略组和节点有什么区别？

节点是具体服务器连接，策略组是管理多个节点的选择器。规则可以把请求交给策略组，再由策略组决定使用哪一个节点。

为什么导入 shadowrocket配置文件 后没有变化？

可能只是文件下载成功，还没有切换为当前使用的配置；也可能规则被更早的条目抢先匹配。检查配置状态、规则顺序和测试结果。

规则应该从上往下怎么写？

更具体的规则放前面，更宽泛的规则放后面，最后保留明确的 FINAL 兜底。因为命中一条后，后面的规则不会继续参与判断。

可以同时导入很多规则集吗？

可以，但不建议一开始就这样做。多个规则集可能重复匹配同一域名，先使用一份可验证的配置，再逐步增加内容更容易定位问题。

免责声明

本文仅介绍 Shadowrocket 的配置文件、规则匹配和网络排错思路，不提供节点、订阅地址或绕过服务。请确认相关工具和网络服务符合所在地法律法规及服务商条款，不要公开分享订阅令牌，也不要将 Apple ID、验证码或其他账号凭证交给第三方。