Shadowrocket 使用全指南：原理、配置、规则与常见问题

第 1 章：什么是 Shadowrocket？

以我自己的使用经验来说，Shadowrocket（大家更习惯叫它“小火箭”）并不是一个“翻墙工具”， 而是一款运行在 iOS / iPadOS 上的系统级网络代理客户端。 它真正做的事情只有一件：把设备产生的网络流量抓出来， 按你设定好的规则进行判断，然后决定这些流量是直连、走代理，还是直接拦掉。

1.1 工具定位：代理客户端，不是 VPN

这点我一直会跟新接触 Shadowrocket 的朋友反复强调：它不是传统意义上的 VPN。 VPN 的逻辑是“接管全部流量”，而 Shadowrocket 更像一个可编排的流量路由器。 你可以精确地告诉它：哪些请求需要走代理，哪些保持直连。 正是这种“你说了算”的控制能力，让它在工程师、跨境业务团队里非常受欢迎。

1.2 为什么它在 iOS 上受欢迎？

从我这些年接触的用户来看，Shadowrocket 在 iOS 上流行主要有三个现实原因： 第一，iOS 对系统级代理工具的限制本身就多，可选项并不多； 第二，Shadowrocket 足够轻量，但该有的能力一个不少； 第三，成本低、学习曲线平缓，新手上手也快。 对跨境电商、广告投放、移动端调试的人来说， 它基本能覆盖 80% 以上的实际使用场景。

1.3 典型用户画像与场景

我在实际项目中见到的典型用法大致是这些：
跨境电商运营：快速验证不同国家访问时，商品页、价格和税费展示是否一致。
工程师 / 开发者：调试移动端 API，请求失败时查看 DNS、TLS 或代理链路问题。
数据采集团队：模拟真实移动端访问，用来分析反爬策略或页面结构差异。

举一个很常见的例子，跨境运营验证英国站价格时，通常会这样操作：

1. 打开 Shadowrocket，切换到英国节点；
2. 访问目标电商页面并刷新；
3. 在 Logs 里确认请求确实走了英国出口；
4. 对比页面是否以 GBP 展示，并包含对应 VAT 信息。

第 2 章：Shadowrocket 的工作原理

2.1 支撑协议与网络标准

从技术角度看，Shadowrocket 本身并没有“发明”任何新协议， 它做的是把成熟、可靠的网络标准整合到 iOS 设备上。 比如， SOCKS5（RFC 1928） 是一个非常通用的代理协议，支持 TCP 和 UDP， 在需要尽量保留原始请求特征的场景下经常会用到； HTTP / HTTPS 代理则更偏向 Web 和 API 请求转发； 在传输层，Shadowrocket 通过 TLS（RFC 8446） 来保证代理链路中的数据加密与完整性。

此外，它还支持 Shadowsocks、VMess（V2Ray）等开源协议。 这些协议各有侧重，有的在复杂网络环境下更稳定， 有的对链路干扰更有韧性， 实际用哪个，更多还是取决于你面对的网络环境和业务需求。

2.2 iOS 层面的实现机制：Network Extension

很多人好奇，为什么 Shadowrocket 能做到“系统级分流”， 关键原因在于它基于 Apple 官方的 Network Extension 框架 实现。 这个框架允许经过授权的应用创建虚拟网络接口， 通过 Packet Tunnel 和 Flow API 捕获系统层面的网络流量。

Shadowrocket 正是借助这套机制， 把设备产生的请求统一接管， 再交给内部的规则引擎决定流量去向。 也正因为 Network Extension 属于受控系统能力， 普通 App 并不能随便实现， 这也是为什么 iOS 上真正好用的代理客户端并不多。

2.3 分流规则的完整工作流程

实际运行时，Shadowrocket 会按照既定顺序匹配规则， 包括 DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GeoIP、User-Agent 以及规则集等。 一旦命中规则，请求就会被分配到对应策略： 走代理（Proxy）、直连（DIRECT）或直接拒绝（REJECT）。

如果规则指向代理策略， Shadowrocket 会从对应的节点池中选择可用节点完成转发。 从工程角度看， “规则匹配 → 策略选择 → 节点转发” 这条链路就是它整个分流体系的核心。

2.4 Logs、DNS 与隐私边界

在排查问题时，我个人用得最多的就是 Logs。 它会清楚地展示一次请求从 DNS 解析、 TCP 建连到 TLS 握手的完整过程， 很多问题其实一眼就能看出是代理、DNS 还是目标站点导致的。

DNS 方面，Shadowrocket 支持 DoH、DoT、自定义 DNS 以及按规则分流解析， 对修复 ISP 劫持或解析异常非常有帮助。 需要特别说明的是：Shadowrocket 本身并不提供代理节点， 也不会主动上传你的请求数据， 真正决定隐私与安全的， 始终是你所使用的代理服务器本身是否可靠。

第 3 章：Shadowrocket 的核心功能详解

3.1 Profiles（配置文件）——管理策略的核心

在 Shadowrocket 里，配置文件就是“中枢系统”。 一个 Profile 往往同时包含节点列表、分流规则、DNS 策略和去广告规则。 在企业或团队使用中， 我更推荐把不同职责拆分成多个订阅文件， 通过 URL 统一下发和更新， 这样维护成本低，也方便随时回滚。

3.2 节点管理：协议与场景选择

Shadowrocket 支持的协议很多，但重点不是“能不能用”， 而是“用得对不对”。 在不涉及 TLS 解密的前提下， 数据采集场景更偏向 SOCKS5 / HTTP， 以尽量还原真实请求； 跨境电商和日常访问更看重稳定性， 常用 SS / VMess / Trojan； 内部测试环境则会选择 HTTPS Proxy， 方便配合认证和日志分析。

3.3 分流规则（Rules）详解

Shadowrocket 的规则类型覆盖得很全， 包括 DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP、USER-AGENT 等。 实际使用中， 常见做法是把广告和追踪域名直接 BLOCK， 公司内网走 DIRECT， 其余国际站点再按国家或业务走不同代理。

3.4 日志（Logs）与工程排查

Logs 是最快定位问题的工具。 比如 TLS 握手失败， 往往是代理不支持或证书被干扰； 出现 403、429， 更多是目标站点触发了风控， 需要从节点质量或请求节奏上调整。

3.5 DNS 功能与劫持修复

DNS 对跨境业务的影响经常被低估。 Shadowrocket 提供的 DoH / DoT 和分流解析， 能有效避免错误解析或 CDN 定位偏差， 对页面加载内容和速度都有直接影响。

3.6 去广告与请求阻断

Shadowrocket 的去广告并不是浏览器插件级别， 而是作用在系统网络层。 在测试 App、跑脚本或做对照实验时， 能明显减少无关请求和干扰， 这一点在工程实践中非常实用。

第 4 章：界面与菜单解析

Shadowrocket 的界面，说实话不算“友好”， 但胜在逻辑清晰。

4.1 主界面一眼看懂

主界面你只需要记住几块：

• 开关：是否启用代理
• 当前节点：你现在走的出口
• 状态信息：连接情况、速率

其他所有功能，其实都藏在菜单里。

4.2 Configurations：配置的总入口

Configurations 是团队使用 Shadowrocket 的关键。

在这里你可以：

• 导入 / 更新订阅
• 切换不同 Profile
• 统一下发配置

我们在 ipweb.cc 做团队部署时， 基本都会禁止私自手动改配置， 所有调整统一从订阅入口走。

4.3 Servers 与 Rules：一个是出口，一个是方向盘

Servers 决定你“从哪出去”， Rules 决定你“哪些请求出去”。

很多问题，其实不是节点坏了， 而是规则根本没命中。

第 5 章：安装指南

5.1 唯一推荐的安装方式

这一点我必须说得很明确：
只通过 Apple App Store 购买和安装。

市面上那些所谓的“破解版”“企业签名版”， 我见过太多出问题的案例， 包括后门、证书异常、配置被篡改。

Shadowrocket 是一次性付费应用， 价格不高，真的没必要省这点钱。

5.2 安装与授权流程

1. 在 App Store 搜索 Shadowrocket
2. 确认开发者信息，避免仿冒
3. 购买并安装
4. 首次打开时，允许网络相关权限

权限弹窗不用太紧张， 这是 Network Extension 正常的系统授权。

没有这个授权， Shadowrocket 也就失去了存在的意义。

第 6 章：导入节点与订阅

说实话，Shadowrocket 本身不难， 真正容易出问题的地方，永远是节点怎么进来的。

我在 ipweb.cc 这几年，看过太多“配置没问题、规则也对，但就是不好用”的情况， 最后一查，基本都卡在节点导入和管理上。

6.1 手动添加节点：适合少量、自建或测试

手动添加的流程你应该已经很熟了：

Servers → + → 选择协议 → 填 IP / 端口 / 认证信息 → 保存

这种方式我一般只在两种情况下用：

• 自建节点，数量很少
• 临时测试某一个出口

一旦节点数量超过十个， 或者需要给多人用， 手动添加基本就不可控了。

6.2 订阅 URL：团队和长期项目的首选

如果你是团队使用， 或者项目周期比较长， 那我强烈建议用订阅 URL。

在 Shadowrocket 里：

Profiles → Download from URL

你可以把节点、规则、DNS 全部通过订阅统一管理。 我们在 ipweb.cc 内部基本都是这个模式， 好处非常直接：

• 节点更新，用户不用手动改
• 规则出问题，可以随时回滚
• 避免私自添加来路不明的节点

对企业或跨境团队来说， 这一步其实是在做风险控制。

6.3 二维码导入：快，但不适合规模化

二维码导入确实很方便， 扫一下就能用。

但我的建议很明确：
个人可以用，团队不要依赖。

二维码的问题在于：

• 不可追溯
• 不可版本控制
• 容易被转发、复用

一旦出问题，很难定位是谁、什么时候、扫了什么。

第 7 章：规则与分流策略

7.1 规则类型与优先级

常见规则包括：DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、USER-AGENT、FINAL 等。规则以先后顺序匹配，越上面的规则优先级越高。因此编写规则时要注意把最精确的规则放在上方，通用的 FINAL 或 DEFAULT 放在最后。

7.2 实战示例

示例一：把所有 amazon.com 下的流量走美国代理：
DOMAIN-SUFFIX,amazon.com,USProxy
示例二：把内网地址直连：
IP-CIDR,10.0.0.0/8,DIRECT

7.3 策略组（Policy Group）管理

策略组可以实现自动选择（url-test/min/latency），也可以手动切换。企业场景常用“主备节点池 + 自动测速”来保证高可用。

第 8 章：进阶使用与建议

8.1 Shadowrocket 界面与菜单该怎么看？

Shadowrocket 的界面并不复杂，但初次使用时，很多用户会分不清 Configurations、Servers、Rules、Logs 各自的作用。 简单理解：

• Configurations：整体策略与规则的“总控文件”
• Servers：具体可用的代理节点列表
• Rules：决定哪些流量走代理、哪些直连
• Logs：排查问题时最重要的调试入口

8.2 团队或公司使用 Shadowrocket 时要注意什么？

当 Shadowrocket 被用于团队或公司环境（如跨境电商、广告投放、测试团队）时， 问题往往不在“会不会用”，而在“用得是否规范”。

实际风险通常来自：

• 员工私自添加来源不明的节点
• 多人共用同一代理出口导致风控
• 在代理环境下登录公司内部或财务系统

8.3 Shadowrocket 是否是唯一选择？

Shadowrocket 并不是 iOS 平台上唯一的代理工具。 在更复杂的工程或调试场景中，一些用户会选择功能更强但学习成本更高的替代方案。

简要结论是：

• 如果你追求简单、稳定、够用，Shadowrocket 是最佳起点
• 如果你需要脚本、MITM、深度抓包，可以考虑更专业的工具

常见术语速查

• Proxy：代理服务器，用于转发请求
• Residential IP：住宅网络出口 IP
• Policy Group：节点选择策略组
• DIRECT：直连，不走代理