我以前把 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,PROXYshadowrocket分流规则，先理解四种动作
PROXY
把请求交给首页选中的节点，或者交给指定的策略组。它并不等于固定某个国家的节点，实际节点由策略组当前选择决定。
DIRECT
绕过代理，直接使用当前网络连接。国内网站、局域网设备和不需要代理的服务，常会放在这一类。
REJECT
拒绝请求，它适合处理明确不想访问的域名，或者规则文件中的广告拦截项目。误把正常服务放进 REJECT，页面可能表现为加载失败或没有响应。
FINAL
兜底动作，没有其他规则命中时，请求会按照 FINAL 的设置处理。有人把 FINAL 设为 DIRECT，有人设为 PROXY，结果差异很大。排查“为什么只有部分网站打不开”时，我会先检查这一行。
小火箭规则配置：不要先下载一堆规则集
搜索“小火箭规则配置”时，很多页面一上来就给出所谓懒人配置。对新手来说，下载现成文件确实省时间，但一次导入多个规则集，会让问题变得难以定位。
我会先做一个最小配置：
- 只保留一个正在使用的配置文件。
- 先确认节点可以单独连接。
- 添加一条自己能验证的域名规则。
- 用测试规则功能查看命中结果。
- 确认无误后，再增加其他规则集。
例如，我会先加入一条测试规则，把某个明确的域名指定为 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 规则命中不是同一类故障。
配置文件失效时的回滚方法
- 暂停自动更新。
- 切换回之前能工作的本地配置。
- 删除最近添加的规则集。
- 用测试规则确认目标域名的走向。
- 只恢复一份远程文件，再观察结果。
配置文件最好保留一个日期备注，例如“2026-10-05 可用版本”。这样出现问题时，可以知道是哪次更新导致变化。
不要把完整配置文件和订阅令牌一起公开。配置里可能包含服务器地址、访问参数和个人化设置，分享前应删除敏感内容。若需要处理账号登录或购买应用的问题，应单独检查 Apple ID，而不是把账号信息写进配置文件。
FAQ
shadowrocket分流规则是自动生成的吗？
应用内会带有基础配置，但具体覆盖范围和策略取决于当前配置文件。需要更精细的分流时，要检查或导入适配 Shadowrocket 的规则文件。
小火箭全局模式和规则模式应该选哪个？
排查节点时先用全局模式，日常使用再切回规则模式。规则模式更适合按域名和策略分流，但前提是配置文件内容正确。
策略组和节点有什么区别？
节点是具体服务器连接，策略组是管理多个节点的选择器。规则可以把请求交给策略组，再由策略组决定使用哪一个节点。
为什么导入 shadowrocket配置文件 后没有变化？
可能只是文件下载成功，还没有切换为当前使用的配置；也可能规则被更早的条目抢先匹配。检查配置状态、规则顺序和测试结果。
规则应该从上往下怎么写？
更具体的规则放前面，更宽泛的规则放后面，最后保留明确的 FINAL 兜底。因为命中一条后，后面的规则不会继续参与判断。
可以同时导入很多规则集吗？
可以，但不建议一开始就这样做。多个规则集可能重复匹配同一域名，先使用一份可验证的配置，再逐步增加内容更容易定位问题。
免责声明
本文仅介绍 Shadowrocket 的配置文件、规则匹配和网络排错思路，不提供节点、订阅地址或绕过服务。请确认相关工具和网络服务符合所在地法律法规及服务商条款，不要公开分享订阅令牌，也不要将 Apple ID、验证码或其他账号凭证交给第三方。