实操教程｜Shadowrocket（小火箭）分流完全教程：从规则原理到 DNS、策略组与排错
实操教程｜Shadowrocket（小火箭）分流完全教程：从规则原理到 DNS、策略组与排错
昨天我发了关于爬墙上网的帖子，很多人问我怎么做 Shadowrocket 配置、分流，我根据我的实际使用情况整理了这篇文章。
本文讨论 iPhone、iPad、Mac 与 Apple TV 上的 Shadowrocket。软件、规则库和界面会持续更新，具体字段以你设备上的当前版本为准。
我正在使用的VPS是搬瓦工的机器，
https://bandwagonhost.com/aff.php?aff=81656&pid=87
Jason VPS 交流群：
VPS补货雷达：
一、先把“分流”说清楚
Shadowrocket 是一个规则驱动的网络工具，不是代理服务，也不自带服务器或订阅。App Store 的产品页把它描述为 “Rule based proxy utility”，列出的能力包括捕获 HTTP/HTTPS/TCP 流量、按域名/CIDR/GeoIP 匹配、导入远程规则、DNS 映射、IPv6、DoH/DoT/DoQ 等；当前产品页还明确写明：用户须自行提供配置。
“分流” 就是：每个连接先与规则表匹配，再交给某个策略处理。常见策略只有三类：
- DIRECT：设备直接访问目标，不经过代理节点；
- PROXY： 或自定义策略组：交给某个节点或节点组；
- REJECT ：拒绝连接，常用于广告、追踪或已知恶意域名。
最重要的规则只有一句：从上到下匹配，第一条命中即停止（first match）。因此，规则的顺序往往比规则数量更重要。
例如：
DOMAIN,
,DIRECT
DOMAIN-SUFFIX,
,PROXY
FINAL,PROXY
访问
会直连，因为精确规则先命中；
访问
才会命中后面的后缀规则。
二、三种运行方式
Shadowrocket 首页通常可选择全局路由方式：
\1. 配置（Config）：按配置文件中的规则分流。本文所有内容都基于此模式。
\2. 代理（Proxy）：绝大多数流量统一走当前节点，适合临时排查“是否是规则导致故障”。
\3. 直连（Direct）：不走节点，适合排查节点或代理协议问题。
想要分流，不能只导入配置，还要在首页把“全局路由”切到“配置”。不少“规则没生效”只是运行在代理或直连模式。
三、最常用的规则语法
先看域名：越精确的规则越靠前，越宽泛的规则越靠后。
目标是 IP 地址，或域名规则没有覆盖时，再由地址段和 GeoIP 接手。
no-resolve 到底加不加
no-resolve 表示 IP 类规则不要为了匹配而把域名再解析成 IP，可减少额外 DNS 查询。
- 明确的 IP 段规则通常可加：IP-CIDR,149.154.160.0/20,策略,no-resolve；
- GEOIP,CN,DIRECT如果加no-resolve`，它只能匹配本来就是 IP 的连接，无法通过解析把“未收录的国内域名”捞回直连；
- 所以“国内优先直连”的配置常故意不给 GEOIP,CN 加 no-resolve，以解析开销换覆盖率。
远程规则负责批量装载，FINAL 负责接住最后仍未命中的流量。
RULE-SET与DOMAIN-SET不能只看文件名互换：前者可装载混合规则，后者面向纯域名集合。blackmatrix7 的生成器在某一服务的域名规则超过 1000 条时，可能拆成XXX.list与XXX_Domain.list`，必须同时引用才能完整覆盖。
dns-failed 是什么
FINAL,PROXY,dns-failed 表示本地 DNS 解析失败时，仍将连接交给兜底代理策略，让远端有机会解析。它不是万能修复：节点自身 DNS、协议能力或目标服务不可用时依旧会失败。
四、推荐的规则优先级
一套稳健的顺序通常是：
\1. 用户自己的精确修正规则；
\2. 局域网和系统兼容规则；
\3. 明确需要拒绝的规则；
\4. 需要固定地区的服务（AI、流媒体、支付等）；
\5. Apple、Microsoft、Google 等大类服务；
\6. 国内域名集；
\7. 国外域名集；
\8. 国内 GeoIP；
\9. FINAL 兜底。
顺序不是宗教。若广告库误杀银行或登录域名，可把一条精确 DIRECT 规则放到广告库之前；若某个服务同时属于 Google 与 AI，哪个策略在前，它就走哪个。
五、从零配置：最稳妥的操作流程
\1. 先备份
在“配置”页找到当前使用的本地配置，长按或进入详情后导出到“文件”或 iCloud Drive。不要直接在唯一副本上大改。
\2. 导入配置
通常可以在“配置”页通过右上角 + 从 URL 下载，也可从“文件”导入 .conf。下载后要点击该配置，使其出现选中标记。远程配置以后更新可能覆盖本地编辑，因此个人修正规则最好保存在自己可控的配置中。
\3. 添加自己的节点或订阅
节点属于隐私数据，应在首页单独添加。不要把订阅 URL、密码、UUID 或私钥写进公开配置、截图或 GitHub Issue。配置文件的 [Proxy] 可以留空，策略组可引用 App 中已有的节点池。
\4. 切到“配置”模式并首次授权
打开总开关，接受 iOS 添加 VPN 配置的系统提示；将全局路由选为“配置”。先用一个简单网站测试直连和代理是否都能工作，再增加复杂规则。
\5. 用日志验证，不凭感觉
打开 Shadowrocket 的连接或请求日志，访问目标 App/网站，检查：
- 请求域名是什么；
- 命中了哪条规则；
- 最终走了哪个策略/节点；
- 是 DNS 失败、TCP 超时、TLS 错误，还是服务端拒绝。
“测试规则（Test Rule）”适合检查某个域名预计会走 DIRECT、PROXY 还是策略组，但真实 App 可能同时访问多个域名，所以仍需配合日志。
六、一个保守、可读的配置骨架
下面是教学骨架，不包含节点、不强制 HTTPS 解密，也不绑定某个机场。先复制到自己的 .conf，再按需求增删服务规则。
[General]
bypass-system = true
skip-proxy = 127.0.0.1,localhost,*.local,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
dns-server =
https://dns.alidns.com/dns-query,https://doh.pub/dns-query
fallback-dns-server = system
ipv6 = true
prefer-ipv6 = false
dns-direct-system = false
private-ip-answer = true
udp-policy-not-supported-behaviour = REJECT
[Proxy]
# 节点在 App 首页单独添加；不要把隐私凭据放进公开配置
[Proxy Group]
🚀 节点选择 = select,PROXY,DIRECT
🤖 AI 服务 = select,🚀 节点选择,DIRECT
🎬 流媒体 = select,🚀 节点选择,DIRECT
🍎 苹果服务 = select,DIRECT,🚀 节点选择
🌍 境外流量 = select,🚀 节点选择,DIRECT
🐟 漏网之鱼 = select,🚀 节点选择,DIRECT
[Rule]
# 1. 自定义精确修正：永远放在大规则集之前
DOMAIN,
,DIRECT
# 2. 局域网
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
IP-CIDR6,fe80::/10,DIRECT,no-resolve
# 3. 按需加入服务规则；URL 必须来自你信任且格式兼容的规则源
# RULE-SET,https://…/OpenAI.list,🤖 AI 服务
# RULE-SET,https://…/Netflix.list,🎬 流媒体
# RULE-SET,https://…/Apple.list,🍎 苹果服务
# DOMAIN-SET,https://…/Apple_Domain.list,🍎 苹果服务
# 4. 国内域名规则应在国外规则和 FINAL 之前
# RULE-SET,https://…/China.list,DIRECT
# DOMAIN-SET,https://…/China_Domain.list,DIRECT
# 5. 国外域名规则
# RULE-SET,https://…/Global.list,🌍 境外流量
# DOMAIN-SET,https://…/Global_Domain.list,🌍 境外流量
# 6. IP 地理位置与兜底
GEOIP,CN,DIRECT
FINAL,🐟 漏网之鱼,dns-failed
[Host]
localhost = 127.0.0.1
*.local = server:system
*.in-addr.arpa = server:system
*.ip6.arpa = server:system
```
关于这份骨架的取舍
- fallback-dns-server = system 兼容性更好，但不能称为“零系统 DNS”；严格隐私路线可改为另一组加密 DNS，但加密 DNS 全部不可达时会更脆弱。
- udp-policy-not-supported-behaviour = REJECT 避免节点不支持 UDP 时静默改为直连；字段拼写和行为应在当前版本实机验证。
- IPv6 开启后必须同时考虑 IPv6 规则、节点 IPv6 能力与 DNS AAAA 记录。遇到只有部分 App 超时，可临时关闭 IPv6做对照测试，而不是长期盲关。
- *.local 与反向解析交给系统 DNS，目的是保留 AirPlay、打印机、Bonjour 等局域网发现能力。
七、策略组：让规则指向“选择”，而不是写死节点
策略组的价值是解耦：规则只决定“这是 AI 流量”，策略组再决定“AI 当前用哪个节点”。这样换节点不用改几十条规则。
常见组类型：
- select：手动选择，最可靠；
- url-test：定时测试候选节点，自动选择延迟较低者。
示例：
[Proxy Group]
🚀 手动选择 = select,PROXY,DIRECT
🇭🇰 香港自动 = url-test,policy-regex-filter=(?i)(香港|港|HK|Hong),url=
http://www.gstatic.com/generate_204,interval=600,timeout=5
🇯🇵 日本自动 = url-test,policy-regex-filter=(?i)(日本|东京|大阪|JP|Japan),url=
http://www.gstatic.com/generate_204,interval=600,timeout=5
注意：
- 自动组依赖节点名称；名称不规范时会空组或错配；
- 延迟最低不等于体验最好。流媒体更看地区授权、带宽和出口 IP 质量；
- 10 分钟一次测速会增加耗电和请求量，节点多时尤其明显；
- 测速 URL 应稳定、体积小，并能从目标网络访问。
八、DNS：分流最容易被忽略的一半
访问域名时，客户端通常先把域名解析为 IP，再建立连接。以下问题看起来像“节点坏了”，其实可能是 DNS：
- 国内外 DNS 返回不同 CDN 地址，导致绕路；
- 某 App 使用 HTTPDNS 或硬编码 DNS，绕过配置；
- IPv6 返回 AAAA，但节点或出口对 IPv6 支持不完整；
- GEOIP 为了判断 IP 触发额外解析；
- 系统 DNS 回退带来隐私与兼容性的取舍。
建议路线：
\1. 新手先用稳定的国内 DoH + 系统回退，确保可用；
\2. 需要严格控制时，再测试境外 DoH、按域名指定 DNS 和 HTTPDNS 拦截；
\3. 每改一项都用日志检查解析服务器、返回 IP 与最终策略；
\4. 不要把“DNS 请求经过 HTTPS”误认为目标连接本身已加密或匿名。
Shadowrocket 官方产品页明确列出 DoH、DoT 和 DoQ 支持；第三方配置研究也指出，局域网 .local 与 PTR 查询常有意交回系统 DNS，以换取 Bonjour 兼容性。
九、规则库怎么选：不要只看“条数最多”
\1. blackmatrix7/ios_rule_script
覆盖 Shadowrocket、Surge、Clash、Quantumult X 等多个客户端，按 Apple、Google、Telegram、OpenAI、流媒体等服务拆分，适合精细策略组。仓库在本次核对时约 2.77 万 Star；项目说明其内容整合自互联网，并不保证第三方数据的准确性和有效性。[项目主页](
https://github.com/blackmatrix7/ios_rule_script
)
关键注意：大规则可能拆为普通 list 与 Domain list；只引用一个会漏规则。项目的 Shadowrocket 目录可从这里选择：[Shadowrocket 规则目录](
https://github.com/blackmatrix7/ios_rule_script/tree/master/rule/Shadowrocket
)
\2. ACL4SSR
历史较久，覆盖 SSR/Clash/iOS 常用规则，在本次检索时主仓库约 6400 Star、2000 Fork，2026-07-31 仍有更新记录。它适合提供 LocalAreaNetwork、ChinaDomain、ChinaIP、GoogleCN 等基础分类，但许多文件目录以 Clash 命名，导入 Shadowrocket 前必须确认内容语法兼容，而不是看到 .list 就直接用。[ACL4SSR 组织页](
)
\3. SukkaW Ruleset
强调高性能与分类维护，提供域名集、非 IP 规则、IP 规则、流媒体、Apple CDN 等集合。其公开文档主要给出 Surge/Clash 方式；Shadowrocket 使用前需要核对对应格式，不能照抄 Clash provider 配置。[规则说明](
https://github.com/getsomecat/SukkaW
) · [规则服务器](
)
\4. Loyalsoldier/geoip 与 v2ray-rules-dat
适合更新 GeoIP/GeoLite2 数据与中国、私网、Telegram、Netflix、Cloudflare 等 IP 集。geoip 项目提供 MaxMind MMDB、V2Ray dat、Surge/Clash 文本等多种格式，且有 SHA-256 校验文件；Shadowrocket 可使用 MMDB，但不要把给 V2Ray 的 .dat 或给 Clash 的 YAML 当作 Shadowrocket 文本规则。[GeoIP 项目](
https://github.com/Loyalsoldier/geoip
) · [v2ray-rules-dat](
https://github.com/Loyalsoldier/v2ray-rules-dat
)
\5. 广告规则
域名级拦截简单省电，却一定存在误杀与漏网：同一域名同时承载广告和正常内容时，网络层无法只屏蔽其中一个 URL。超大广告库还会增加更新、解析和排错成本。建议先用中等规模列表，保留自己的白名单；银行、支付、验证码、登录、推送异常时，先临时把广告策略切 DIRECT 做 A/B 测试。
选源检查表
在导入第三方规则前，至少检查：
- 最近提交或生成时间；
- 维护者、许可证和上游数据来源；
- 是否明确支持 Shadowrocket；
- 文件是 RULE-SET 还是 DOMAIN-SET 格式；
- 是否包含脚本、重写、MITM 或证书要求；
- 是否提供校验值、固定版本 URL 或变更记录；
- 是否有误杀反馈与白名单机制；
- 项目失效时，你是否还能恢复本地副本。
Star 数只能反映热度，不能证明安全或准确。
十、不要把“模块”和“分流”混为一谈
纯分流主要由 [Rule]、[Proxy Group]、DNS 和 Host 完成。模块可能额外包含：
- URL Rewrite；
- JavaScript 请求/响应脚本；
- HTTPS 解密（MITM）；
- 定时任务；
- Header 或 Body 修改。
MITM 要安装并信任本地根证书，使工具能解密 HTTPS。它扩大了权限和攻击面，不应为了普通分流开启，更不应安装来源不明的证书或脚本。涉及网银、支付、密码管理器、企业设备时尤其谨慎。只想让某网站走不同节点，不需要 HTTPS 解密。
十一、常见故障的最快排查顺序
规则完全不生效
\1. 首页全局路由是否为“配置”；
\2. 当前配置是否有选中标记；
\3. 目标域名是否被更早的宽泛规则截获；
\4. 远程规则是否下载成功、格式是否匹配；
\5. 修改后是否重新加载配置。
国内 App 变慢或定位异常
- 检查是否掉入 FINAL,PROXY；
- 增加准确的国内域名规则，并保留 GEOIP,CN,DIRECT；
- 检查地图、支付、推送与 CDN 域名；
- 不要用 DOMAIN-KEYWORD 粗暴匹配常见短词。
某个境外 App 登录失败
- 日志中找出全部相关域名，不要只给主域名加规则；
- 确认节点出口地区满足服务条款；
- 检查 UDP/QUIC 是否被节点或配置拒绝；
- 关闭 IPv6 做一次对照；
- 临时切全局代理：若仍失败，通常不是分流顺序问题。
局域网设备、AirPlay、打印机找不到
- 检查 *.local、私网 CIDR、mDNS 与反向解析是否直连/走系统 DNS；
- 不要把整个局域网交给远端代理；
- 检查 skip-proxy 和 TUN 排除路由。
开启广告拦截后 App 白屏
- 临时把广告策略从 REJECT 改为 DIRECT；
- 若恢复，查看日志定位误杀域名；
- 添加精确白名单到广告规则之前；
- 不要直接关闭所有拦截后宣布“规则不能用”。
耗电明显增加
- 降低 url-test 频率；
- 减少重复或超大的远程规则；
- 关闭不需要的脚本、抓包和详细日志；
- 检查是否有 DNS 重试、节点反复切换或连接失败循环。
十二、日常维护建议
- 每次大改只改一类：先规则，再 DNS，再 IPv6；
- 保留“上一个可用版本”和变更日期；
- 远程规则按需引入，不追求全家桶；
- 每月检查规则源是否仍更新，重大系统升级后复测；
- 将私有白名单、地区策略和节点凭据分离；
- 公共规则跟随 master 方便自动更新，但稳定性要求高时应固定提交或版本，并定期人工升级；
- 导入配置前通读 [Script]、[URL Rewrite]、[MITM] 与 [Host]，不要只看 [Rule]。
十三、理解分流的三个结论
\1. 分流准确度 = 规则质量 × 顺序 × DNS 结果。** 任一项错误都可能得到错误路线。
\2. 大而全不是目标。** 精确、可解释、能排错的规则通常比几十万条黑盒规则更可靠。
\3. 日志是唯一可信的裁判。** 网站“看起来能开”不能证明 DNS 没泄漏、规则没旁路或所有子请求都走了预期策略。
