Shadowrocket 怎么设置全局代理和分流？
简答：只想确认节点能不能用，先选 Proxy；想按域名或 IP 分别直连、代理或拒绝，选 Config；需要和本地网络做对照时选 Direct。最快流程是：准备已有服务器或订阅→选择节点→打开 Home 的 Global Routing→用 Proxy 测试→确认连接后切换 Config→验证规则是否命中。注意，“全局”只表示 Shadowrocket 能接管范围内的连接，不保证所有 App、协议和系统流量都一定经过代理。
定义：Shadowrocket 的全局代理与分流，是通过 Home 中的 Global Routing 选择 Proxy、Config 或 Direct，再结合当前服务器和配置文件中的规则决定连接路径。
先看三行速查：Proxy、Config、Direct 怎么选
如果你已经导入节点或订阅，但不知道应该选哪个模式，先按下面的目标选择：
| 你的目标 | 建议模式 | 先检查什么 | 注意事项 |
|---|---|---|---|
| 只测试节点和代理路径 | Proxy | Home 中是否已选服务器或策略组 | 适合排除规则影响，但不等于所有系统流量都会被接管 |
| 按域名、IP 或地区分流 | Config | Config 页面是否选中了正确配置文件 | 实际结果取决于规则顺序和策略名称 |
| 对照本地网络直连结果 | Direct | 当前网络和 DNS 是否正常 | Direct 失败不代表代理节点一定有问题 |
Shadowrocket 在开发者页面中被描述为基于规则的代理工具；App Store 页面也明确说明它是独立网络工具，不包含代理服务或服务器资源，用户需要自行提供配置资料。可查看开发者页面和App Store 产品页核对产品身份与基本说明。
首屏结论：只测节点选 Proxy，日常按规则分流选 Config，排查本地网络选 Direct。三种模式改变的是路由方式，不会自动补充服务器地址、端口、认证信息或订阅内容。
从零设置：先让 Proxy 模式跑通
- 准备连接资料。你需要已有的服务器参数、订阅链接或配置文件。客户端安装完成，不代表已经具备可用的代理连接。
- 导入订阅或添加服务器。在 Home 或服务器管理入口中导入已有订阅，或者手动填写服务器地址、端口、协议和认证信息。不同版本的按钮名称可能不同，按照当前界面显示为准。
- 确认服务器列表出现节点。如果列表为空，先排查订阅地址、网络、权限和资料格式，不要急着修改分流规则。节点没有成功导入时，Config 规则通常无法产生预期结果。
- 选择一个服务器或策略组。先选择明确的单个节点，便于判断问题来自服务器还是策略组。使用自动选择组时，组内节点状态也可能影响测试结果。
- 进入 Home，打开 Global Routing，选择 Proxy。首次开启连接时，系统可能要求允许添加 VPN 配置。按系统提示完成授权，再观察连接开关、日志或流量状态。
- 用同一个目标做测试。不要同时更换节点、DNS、规则和网络。若 Proxy 模式可以访问，说明代理路径至少在当前测试条件下有响应；若 Proxy 也失败，应优先检查服务器资料、节点状态、网络权限和 DNS。
- 记录结果后再切换 Config。保留刚才的节点和测试目标，只把 Global Routing 改为 Config，这样才能判断变化是否来自规则。
Shadowrocket 的产品页面只说明它是网络工具，并没有把客户端和代理资源绑定在一起。因此，遇到“已安装但不能连接”时，应把“客户端是否正常”“服务器资料是否完整”“当前配置是否生效”分开判断。
Config 分流设置：配置文件、规则和策略不是一回事
Config 是路由模式，表示按照当前启用配置文件中的规则处理连接；底部的 Config 页面则用于管理或选择配置文件。两者名称相近，但不能混为一谈。
服务器订阅主要用于提供一组服务器条目；配置文件负责规则、策略和其他路由参数。更新服务器订阅，不等于分流规则也随之更新。反过来，修改规则也不会自动修复服务器地址或认证参数。
进入 Config 后，先确认以下三项：
- 当前选中的配置文件，确实是你刚刚编辑或更新的文件。
- 规则中引用的策略名称，在当前配置中确实存在。
- Global Routing 已经回到 Config，而不是仍停留在 Proxy 或 Direct。
规则通常由“匹配类型、匹配内容、策略”组成。常见写法如下，示例域名和网段仅用于说明格式：
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.net,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- DOMAIN：匹配明确的域名。
- DOMAIN-SUFFIX：匹配域名及其子域名。
- IP-CIDR：匹配 IPv4 网段；是否使用
no-resolve，要结合当前 DNS 和配置需求判断。 - GEOIP：按照目标 IP 的地理归属进行匹配。
- PROXY、DIRECT、REJECT：分别表示代理、直连和拒绝策略；也可能使用自定义策略组名称。
- FINAL：前面没有规则命中时使用的兜底策略，通常放在规则段最后。
规则排查时，按“从上到下、先命中先处理”的思路检查。宽泛的 GEOIP 或其他规则如果放在具体域名规则之前，可能让后面的例外规则无法按预期执行。FINAL 也不是重新尝试所有路径，而是处理前面没有命中的请求。
两套分流模板：复制前先替换策略名和示例内容
模板一：指定域名代理，其余直连
[Rule]
DOMAIN-SUFFIX,example-proxy-target.com,PROXY
DOMAIN,api.example-proxy-target.com,PROXY
FINAL,DIRECT这套模板适合只让少量目标走代理。请把示例域名替换成真实目标，并确认当前配置确实存在名为 PROXY 的策略。如果配置使用的是自定义节点组名称，必须替换为实际名称。
模板二：部分地址直连，其余走代理
[Rule]
DOMAIN-SUFFIX,intranet.example,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY这套模板的关键是把明确的域名或网段规则放在前面，再放较宽泛的 GEOIP 规则，最后用 FINAL 兜底。示例网段不是业务地址，不能直接当成真实网络范围。
复制模板后，至少检查四件事：策略名是否存在、配置是否保存、当前是否选中了该配置、测试目标是否真的匹配了规则。若目标使用 IPv6、QUIC、特殊 DNS 或应用自有网络通道，实际结果可能与只看域名规则时不同。
如何验证：不要只看连接开关
- 验证 Proxy。选择 Proxy，使用固定节点和固定目标测试，观察是否有连接或流量记录。
- 验证 Config。切换 Config，分别测试一个明确写入代理规则的目标和一个明确写入 DIRECT 的目标。
- 确认配置文件。检查当前启用文件，而不是只确认文件出现在列表中。
- 检查规则命中。如果结果与预期相反，先看是否被更早的 DOMAIN、DOMAIN-SUFFIX、GEOIP 或其他规则提前匹配。
- 检查策略组。规则即使命中代理策略，策略组没有可用节点时仍可能连接失败，这属于节点或策略组问题。
- 重新发起请求。切换模式后关闭并重新打开目标页面或 App 请求，不要把已经缓存的页面结果当成新模式的验证。
“Direct 流量不为零”不一定是错误，因为分流本来就可能让部分请求直连。只有当明确应走代理的目标被识别为 DIRECT，或明确应直连的目标进入代理路径时，才需要继续检查规则。
还要注意“全局代理”的边界：它只针对 Shadowrocket 能接管的连接。系统保留流量、局域网连接、应用特殊网络实现、某些 UDP 或 IPv6 场景，可能不完全按照普通网页请求的表现工作。因此不要把一次网页访问成功，直接推断为所有 App、所有协议都已代理。
失败分流：按现象逐层回退
| 现象 | 优先检查 | 回退方法 |
|---|---|---|
| Proxy、Config 都失败 | 服务器地址、端口、认证、系统 VPN 权限、当前网络 | 切到 Direct 做本地网络对照，重新核对服务器资料 |
| Proxy 成功，Config 失败 | 配置文件是否选中、规则顺序、策略名称、FINAL | 暂时回到 Proxy，再逐条恢复规则 |
| 某个 App 不走代理 | 实际访问域名、DIRECT 或 GEOIP 规则、应用自身网络方式 | 先用 Proxy 做对照，再添加单个明确域名规则 |
| 浏览器可用，单个 App 失败 | 应用是否使用 UDP、IPv6、独立 DNS 或特殊连接方式 | 查看日志和连接记录，不要立即判定节点失效 |
| 规则改了但结果不变 | 是否保存、是否重载、是否选错配置、是否被前置规则命中 | 用一个唯一测试域名验证，并一次只改一个变量 |
| 规则命中代理但仍打不开 | 代理策略组是否有可用节点、DNS 是否能解析、目标是否拒绝连接 | 改用单个已确认可用节点测试，再回到策略组 |
排查时不要同时改 DNS、MTU、节点、规则和网络。建议顺序是：先固定网络与节点→验证 Proxy→再验证 Config→最后再处理 DNS、IPv6、UDP 或 MTU 等分支。这样更容易判断真正变化来自哪里。
常见问题
Shadowrocket 全局代理应该选 Proxy 还是 Config？
只想确认节点和代理路径时选 Proxy；希望按域名、IP 或地区分流时选 Config；想观察本地网络直连结果时选 Direct。Proxy 不是服务器，Config 也不是订阅，两者只是不同的路由处理方式。
选择 Proxy 后，是否代表所有 App 都走代理？
不代表。Proxy 只影响 Shadowrocket 能接管的连接，系统保留流量、局域网、应用特殊网络方式、部分 UDP 或 IPv6 请求可能有不同表现。应使用目标 App 的实际请求和日志进行验证。
Shadowrocket 已连接，但某个 App 仍然直连怎么办？
先确认 Global Routing 是 Config 还是 Proxy，再查看该 App 实际访问的域名是否命中 DIRECT、GEOIP 或更早的规则。临时切到 Proxy 做对照；如果 Proxy 也失败，再检查应用自身网络方式、DNS、UDP 或 IPv6。
为什么 FINAL 要放在最后？
FINAL 是前面没有规则命中时的兜底策略。放在具体规则前面，可能让后续规则没有机会处理目标。具体域名例外通常放前面，宽泛规则放后面，FINAL 放规则段末尾。
更新订阅后，分流规则会自动更新吗？
不能直接这样判断。服务器订阅主要提供服务器条目，配置文件负责规则和策略；两者可能是分开的。更新后应分别确认节点列表、当前配置文件和 Global Routing 模式。
规则复制后不生效，最常见的原因是什么？
常见原因包括示例域名没有替换、策略名不存在、配置没有保存或重载、Global Routing 仍是 Proxy 或 Direct、当前启用的不是刚编辑的文件，以及目标被更早的宽泛规则命中。
Shadowrocket 是否自带代理服务器或订阅？
App Store 产品页明确说明它是独立网络工具，不包含代理服务或服务器资源；使用前仍需准备自己的服务器、订阅或配置资料。具体版本和系统兼容性以当前 App Store 页面为准。
常见问题
Shadowrocket 全局代理应该选 Proxy 还是 Config？
只想测试节点选 Proxy；需要按规则分流选 Config；排查本地网络时选 Direct。
选择 Proxy 后是否所有 App 都会走代理？
不一定。Proxy 只影响 Shadowrocket 能接管的连接，系统保留流量、局域网、部分 UDP、IPv6 或应用特殊网络方式可能有不同表现。
Shadowrocket 已连接但某个 App 不走代理怎么办？
确认当前模式，检查该 App 实际访问的域名是否命中 DIRECT、GEOIP 或更早规则，再用 Proxy 做对照。
FINAL 为什么要放在最后？
FINAL 是未命中前面规则时的兜底策略，提前放置可能导致后面的具体规则无法生效。
更新订阅会自动更新分流规则吗？
不能直接这样判断。服务器订阅和配置文件可能是两套内容，应分别检查节点列表、配置文件和 Global Routing 模式。