Shadowrocket 设置详解

Shadowrocket 的常用设置可以分成四层。第一层是 Global Routing，决定流量整体采用 Config、Proxy 还是 Direct；第二层是 Config 中的规则与策略，负责在 Config 姿态下逐条判断请求；第三层是用户已有订阅或服务器信息、DNS、On Demand 等连接条件；第四层是 Data、Connectivity Test 与 Diagnostics，用来观察实际结果。按这个顺序理解，可以避免在整体姿态不正确时反复修改 DNS 或服务器参数。

多数日常场景适合先使用 Config，让规则决定 PROXY、DIRECT 或 REJECT。临时验证服务器是否能够建立连接时，可以短时间切到 Proxy，减少规则对测试结果的影响；需要确认本地网络自身是否正常时，可以切到 Direct 进行对照。测试完成后应回到实际需要的姿态，并重新检查页面能否访问、规则是否命中以及 DNS 是否正常解析。

是什么：Global Routing 是连接前最重要的总入口，用于确定流量是交给 Config 规则判断、统一经过当前服务器，还是直接使用本地网络。三种姿态分别显示为 Config、Proxy、Direct，中文说明通常对应配置、代理、直连。

在哪里：在 Home 中找到 Global Routing。切换后，当前连接会按照新姿态处理后续请求。若正在排查问题，改变姿态后应重新打开测试页面，避免浏览器缓存或已有连接影响判断。

怎么设：日常使用先选择 Config，并确认正在使用的 Config 是预期文件。如果某个页面无法打开，先记下当前姿态，再依次用 Direct 与 Proxy 做对照。Direct 也无法访问时，优先检查本地网络或目标地址；Proxy 可以访问而 Config 不行时，重点查看规则顺序、策略映射与 FINAL；Proxy 也失败时，再检查当前服务器信息和 DNS。

注意什么：Global Routing 只说明总体处理姿态，不等于具体服务器一定可用，也不说明某条规则一定命中。每次切换后都应结合 Data、日志或 Diagnostics 观察结果。排查结束后恢复原设置，避免忘记停留在用于测试的 Proxy 或 Direct。

是什么：规则分流是在 Global Routing 选择 Config 时，根据请求的域名、IP 地址或其他特征决定使用 PROXY、DIRECT、REJECT 或自定义策略。规则按排列顺序检查，通常在命中第一条适用规则后停止继续匹配，因此“规则内容正确”之外，“规则放在哪里”同样重要。

在哪里：从 Config 进入当前配置文件，查看 Rules 或对应规则编辑区域。不同来源的 Config 结构可能不同，但规则关键字和目标策略仍应逐项核对。修改前建议保留原 Config，以便在结果不符合预期时恢复。

怎么设：先把范围最明确、最特殊的规则放在前面，再放覆盖范围更大的规则，最后用 FINAL 承接未命中的流量。例如，若某个完整域名需要 DIRECT，而其主域名后缀整体使用 PROXY，则完整 DOMAIN 应排在 DOMAIN-SUFFIX 前。策略名称必须与 Config 中已有策略一致；大小写、标点与逗号位置也需要保持规范。

DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

注意什么：上述地址仅用于展示语法。规则看似未生效时，先检查 Global Routing 是否为 Config，再检查更靠前的规则是否已经命中。域名经过 DNS 解析后也可能进入 IP 类规则判断；启用 IPv6 的网络还要同时关注 IP-CIDR6。REJECT 会主动阻止匹配流量，添加前应明确目标，避免影响页面中的必要资源。

是什么：Shadowrocket 可以保存用户已有的订阅或单个服务器信息。Subscribe 适合由同一来源维护多条服务器记录；Add Server 适合手动录入一条明确配置；Scan QR Code 与 Import from Cloud JSON 则用于导入已有资料。支持的配置可能涉及 Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard 与 Hysteria2，实际能否连接取决于协议参数与服务器端配置是否一致。

在哪里：在 Home 的服务器列表区域进入添加菜单，可看到 Add Server、Subscribe、Scan QR Code 或 Import from Cloud JSON 等入口。已有条目通常可以打开编辑，检查 SERVER、端口、密码、协议附加参数及备注。只应使用用户自己持有并有权使用的信息。

怎么设：导入前先确认资料类型。订阅地址放入 Subscribe，而不是当作单个 SERVER 地址；单个服务器则选择相应协议，逐项填写 SERVER、端口与认证字段。导入完成后不要立即同时修改多项参数，先选择一条记录进行 Connectivity Test，再尝试建立连接。若失败，回到原始资料逐字符核对，尤其注意协议、端口、传输方式、TLS 相关名称和认证内容。

注意什么：订阅更新通常会按照来源内容刷新条目，手动修改由订阅管理的记录可能在下次更新时被覆盖。删除旧记录前先确认 Config 或策略组是否仍引用其名称。Connectivity Test 只能作为连接检查的一部分；测试可达不代表所有目标都按预期分流，仍需结合 Global Routing、Rules 与 DNS 验证。

是什么：On Demand 用网络条件触发连接行为，适合在 Wi-Fi 或蜂窝网络发生变化时按预设规则自动处理。它解决的是“什么时候建立连接”，而 Global Routing 与 Config 解决的是“连接后流量怎样处理”，两者作用层级不同。

在哪里：在 Settings 中找到 On Demand，进入后设置启用状态与网络条件。首次使用前，应先在手动模式下确认当前服务器、Global Routing 和 Config 可以正常工作，再添加自动条件。这样能把“基础配置问题”和“触发条件问题”分开排查。

怎么设：先从简单条件开始，例如只区分蜂窝网络与已知 Wi-Fi。保存后分别切换网络，观察系统状态与 Shadowrocket 连接状态是否按预期变化。条件较多时，一次只新增一条并立即验证；若同时配置多个相互重叠的条件，要确认优先关系不会产生与预期相反的结果。

注意什么：On Demand 触发由系统网络状态变化驱动，不应把短暂的网络切换过程误判为服务器故障。Wi-Fi 名称变化、网络尚未完成认证、蜂窝与 Wi-Fi 快速切换，都可能让连接状态暂时变化。排查时可先关闭 On Demand，改为手动连接；手动连接正常后，再逐条恢复触发条件。

是什么：Data 用于查看 Shadowrocket 处理到的流量记录和用量概况，可辅助判断某段时间是否产生持续传输、哪些连接占用较多，以及切换规则或服务器后流量行为是否发生变化。它是本地观察工具，不应单独用来推断服务器质量或服务计费结果。

在哪里：从应用底部或相应入口进入 Data。查看统计前先记录当前连接姿态与测试时间段，随后执行一个明确动作，例如打开指定页面或运行一次下载，再返回 Data 对照变化。这样比查看混合了大量后台活动的累计数据更容易判断。

怎么设：若需要比较两种配置，先让后台活动稳定，再分别在相近网络条件下测试。测试一轮只改变一个变量，例如只换 Global Routing、只换 Config，或只换服务器。记录上传与下载方向、开始时间及测试动作，可以减少把系统同步、媒体预加载或应用后台请求误认为目标流量的情况。

注意什么：Data 中的流量可能包含系统与其他应用的后台请求，数值也可能与服务端统计口径不同。短时间内没有明显变化，不代表规则没有工作；某些连接会复用已有会话。需要判断具体规则时，应把 Data 与日志、Diagnostics 以及实际访问结果一起使用。

Settings 中的选项会影响解析、测试方式、快捷入口和配置同步。调整前应先记住原值，完成后用同一个目标复测。一次修改多个项目虽然省步骤，但发生异常时难以确定具体原因。

是什么：Diagnostics 用于检查当前网络、DNS、连接与请求处理过程中的线索；Connectivity Test 更偏向对服务器或目标进行快速可达性测试。两者适合用于缩小故障范围，但最终仍需用实际访问结果确认。

在哪里：Diagnostics 通常位于 Settings 或工具区域，Connectivity Test 可从服务器管理相关入口执行。开始前先记录当前网络类型、Global Routing、Config 名称和选中的服务器，避免测试过程中切换多个条件。

怎么设：先在 Direct 下确认本地网络，再在 Proxy 下检查当前服务器，最后回到 Config 验证规则。若问题集中在域名解析，查看 DNS 相关结果；若表现为连接超时，核对 SERVER、端口、协议和认证参数；若只有指定网站异常，查找对应 DOMAIN、DOMAIN-SUFFIX、GEOIP、IP-CIDR 或 FINAL 的命中关系。

注意什么：诊断信息可能包含服务器地址、域名和网络环境细节。保存或转交前应先检查内容，只保留解决问题所需部分。排查过程中不要频繁切换网络、服务器与规则；每次只改变一个变量，才能把结果与具体设置建立对应关系。

1. 记录当前环境。

   写下正在使用的 Wi-Fi 或蜂窝网络、Global Routing 姿态、Config 名称和当前服务器。若未记录初始状态，后续很难判断是哪次改动产生影响。

2. 确认本地网络。

   临时选择 Direct，打开一个已知可正常访问的页面。如果 Direct 也失败，应先处理网络认证、信号或 DNS 基础问题。

3. 检查服务器连接。

   切换到 Proxy，对当前记录执行 Connectivity Test，并进行实际访问。失败时逐项核对 SERVER、端口、协议和认证资料。

4. 恢复 Config 并核对规则。

   查看目标域名可能命中的第一条规则，确认策略名称存在，并检查 FINAL。不要只看规则文件中是否出现目标域名，还要检查它前面的规则。

5. 检查 DNS 与 IPv6。

   域名异常而其他连接正常时，复核 DNS 设置与缓存；网络启用 IPv6 时，同时检查 IP-CIDR6 以及目标返回的地址类型。

6. 最后恢复自动功能。

   基础连接稳定后，再启用 On Demand、Today Widget 与 iCloud 同步。逐项恢复并验证，可避免自动触发或同步变化干扰核心连接排查。