实操教程|Shadowrocket(小火箭)分流完全教程:从规则原理到 DNS、策略组与排错
文章目录
昨天我发了关于爬墙上网的帖子,很多人问我怎么做 Shadowrocket 配置、分流,我根据我的实际使用情况整理了这篇文章。
本文讨论 iPhone、iPad、Mac 与 Apple TV 上的 Shadowrocket。软件、规则库和界面会持续更新,具体字段以你设备上的当前版本为准。
*我正在使用的VPS是搬瓦工的机器,https://bandwagonhost.com/aff.php?aff=81656&pid=87
Jason VPS 交流群:*https://t.me/JasonVPS
VPS补货雷达:https://t.me/jason_vps_deal
一、先把“分流”说清楚
Shadowrocket 是一个规则驱动的网络工具,不是代理服务,也不自带服务器或订阅。App Store 的产品页把它描述为 “Rule based proxy utility”,列出的能力包括捕获 HTTP/HTTPS/TCP 流量、按域名/CIDR/GeoIP 匹配、导入远程规则、DNS 映射、IPv6、DoH/DoT/DoQ 等;当前产品页还明确写明:用户须自行提供配置。
“分流” 就是:每个连接先与规则表匹配,再交给某个策略处理。常见策略只有三类:
-
DIRECT:设备直接访问目标,不经过代理节点;
-
PROXY: 或自定义策略组:交给某个节点或节点组;
-
REJECT :拒绝连接,常用于广告、追踪或已知恶意域名。
最重要的规则只有一句:从上到下匹配,第一条命中即停止(first match)。因此,规则的顺序往往比规则数量更重要。
例如:
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY
访问 api.example.com 会直连,因为精确规则先命中;
访问 www.example.com 才会命中后面的后缀规则。
二、三种运行方式
Shadowrocket 首页通常可选择全局路由方式:
-
配置(Config):按配置文件中的规则分流。本文所有内容都基于此模式。
-
代理(Proxy):绝大多数流量统一走当前节点,适合临时排查“是否是规则导致故障”。
-
直连(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、协议能力或目标服务不可用时依旧会失败。
四、推荐的规则优先级
一套稳健的顺序通常是:
-
用户自己的精确修正规则;
-
局域网和系统兼容规则;
-
明确需要拒绝的规则;
-
需要固定地区的服务(AI、流媒体、支付等);
-
Apple、Microsoft、Google 等大类服务;
-
国内域名集;
-
国外域名集;
-
国内 GeoIP;
-
FINAL兜底。
顺序不是宗教。若广告库误杀银行或登录域名,可把一条精确 DIRECT 规则放到广告库之前;若某个服务同时属于 Google 与 AI,哪个策略在前,它就走哪个。
五、从零配置:最稳妥的操作流程
- 先备份
在“配置”页找到当前使用的本地配置,长按或进入详情后导出到“文件”或 iCloud Drive。不要直接在唯一副本上大改。
- 导入配置
通常可以在“配置”页通过右上角 + 从 URL 下载,也可从“文件”导入 .conf。下载后要点击该配置,使其出现选中标记。远程配置以后更新可能覆盖本地编辑,因此个人修正规则最好保存在自己可控的配置中。
- 添加自己的节点或订阅
节点属于隐私数据,应在首页单独添加。不要把订阅 URL、密码、UUID 或私钥写进公开配置、截图或 GitHub Issue。配置文件的 [Proxy] 可以留空,策略组可引用 App 中已有的节点池。
- 切到“配置”模式并首次授权
打开总开关,接受 iOS 添加 VPN 配置的系统提示;将全局路由选为“配置”。先用一个简单网站测试直连和代理是否都能工作,再增加复杂规则。
- 用日志验证,不凭感觉
打开 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,example.cn,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 回退带来隐私与兼容性的取舍。
建议路线:
-
新手先用稳定的国内 DoH + 系统回退,确保可用;
-
需要严格控制时,再测试境外 DoH、按域名指定 DNS 和 HTTPDNS 拦截;
-
每改一项都用日志检查解析服务器、返回 IP 与最终策略;
-
不要把“DNS 请求经过 HTTPS”误认为目标连接本身已加密或匿名。
Shadowrocket 官方产品页明确列出 DoH、DoT 和 DoQ 支持;第三方配置研究也指出,局域网 .local 与 PTR 查询常有意交回系统 DNS,以换取 Bonjour 兼容性。
九、规则库怎么选:不要只看“条数最多”
- 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)
- ACL4SSR
历史较久,覆盖 SSR/Clash/iOS 常用规则,在本次检索时主仓库约 6400 Star、2000 Fork,2026-07-31 仍有更新记录。它适合提供 LocalAreaNetwork、ChinaDomain、ChinaIP、GoogleCN 等基础分类,但许多文件目录以 Clash 命名,导入 Shadowrocket 前必须确认内容语法兼容,而不是看到 .list 就直接用。[ACL4SSR 组织页](https://github.com/acl4ssr)
- SukkaW Ruleset
强调高性能与分类维护,提供域名集、非 IP 规则、IP 规则、流媒体、Apple CDN 等集合。其公开文档主要给出 Surge/Clash 方式;Shadowrocket 使用前需要核对对应格式,不能照抄 Clash provider 配置。[规则说明](https://github.com/getsomecat/SukkaW) · [规则服务器](https://ruleset.skk.moe/)
- 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)
- 广告规则
域名级拦截简单省电,却一定存在误杀与漏网:同一域名同时承载广告和正常内容时,网络层无法只屏蔽其中一个 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 解密。
十一、常见故障的最快排查顺序
规则完全不生效
-
首页全局路由是否为“配置”;
-
当前配置是否有选中标记;
-
目标域名是否被更早的宽泛规则截获;
-
远程规则是否下载成功、格式是否匹配;
-
修改后是否重新加载配置。
国内 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]。
十三、理解分流的三个结论
-
分流准确度 = 规则质量 × 顺序 × DNS 结果。** 任一项错误都可能得到错误路线。
-
大而全不是目标。** 精确、可解释、能排错的规则通常比几十万条黑盒规则更可靠。
-
日志是唯一可信的裁判。** 网站“看起来能开”不能证明 DNS 没泄漏、规则没旁路或所有子请求都走了预期策略。






