设置参考 · 官方手册

Shadowrocket 功能与设置

先确定 Global Routing，再核对 Config 与服务器。按 Home、Data、Settings 的用途逐项设置，每次只改变一个条件。

查看模式对照 查看首次连接教程
  • Home · 连接与选择
  • Config · 配置文件
  • Settings · 偏好与诊断

Home / Global Routing

Global Routing：配置、代理与直连

Global Routing 决定连接启用后如何选择流量路径，不负责导入服务器，也不代替连接开关。日常需要按域名或地址分流时使用配置模式 Config；需要临时验证当前服务器时可使用代理模式 Proxy；需要对照本地网络是否正常时可使用直连模式 Direct。模式名称相近，但作用范围不同，切换前应先明确本次验证的目标。

在哪个界面，怎么选择

在 Home 打开 Global Routing，选择 Config、Proxy 或 Direct，再返回 Home 核对当前服务器与连接状态。这里的 Config 是一种路由模式；底部导航中的 Config 则用于管理配置文件。选择 Config 模式后，还需要在 Config 页面确认实际启用的文件，不能只看到模式名称就认为所需规则已经生效。

Global Routing 三种模式的用途与核对项目
模式 路径选择 适用场景 需要核对
配置 · Config 依据当前配置文件中的规则与策略处理请求。 需要让不同域名、地址使用不同策略的日常连接。 启用的文件、Rule 顺序、最终规则及策略目标。
代理 · Proxy 以代理为全局路由方向，仍需考虑系统与配置中的绕过项。 临时对照当前服务器是否能够访问目标。 选中服务器、连接参数、目标本身及网络环境。
直连 · Direct 以本地网络直接访问为全局路由方向。 对照本地网络或确认问题是否与代理路径有关。 本地网络可达性，以及是否仍有其他配置影响请求。

切换模式时注意什么

Proxy 不表示所有应用的每一项系统请求都会经过同一条路径，Direct 也不等于关闭系统中的 VPN 配置。排查时应分别记录模式与连接开关，避免把两者混为一谈。若 Config 下访问异常而 Proxy 下正常，优先检查规则和策略；若两者都失败，先回到服务器参数与网络连通性。完成对照后恢复原来的模式，不要把临时测试状态当作长期设置。

Config / Rule

规则分流：先匹配条件，再执行策略

规则分流把“请求是什么”和“请求怎么走”分开处理。DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD 用于不同范围的域名匹配；IP-CIDR 与 IP-CIDR6 用于地址段；GEOIP 按地址归属数据判断；USER-AGENT 依赖能够读取到的请求信息。策略 PROXY、DIRECT、REJECT 则分别表达代理、直接连接与拒绝处理。协议名不是策略名，服务器使用 Trojan 或 WireGuard 并不会自动决定某个域名命中哪一条规则。

在哪个界面，怎么修改

进入 Config，先确认当前启用的配置文件，再打开文件的编辑入口检查 Rule 段。修改前保留可用副本，随后一次只调整一条规则，并确认修改后的文件仍是当前使用的文件。新增规则通常应放在较宽泛的匹配之前；FINAL 放在末尾，负责前面的规则都未匹配时的最终处理。

[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.net,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY
  • DOMAIN,example.com,DIRECT：精确匹配 example.com，使用 DIRECT；不因此覆盖它的所有子域名。
  • DOMAIN-SUFFIX,example.net,PROXY：匹配 example.net 及其子域名，交给 PROXY。
  • IP-CIDR,192.168.0.0/16,DIRECT：目标地址落在该私有地址段时使用 DIRECT，不代表其他私有地址段也已包含。
  • FINAL,PROXY：未被前面规则匹配的请求使用 PROXY；应先确认代理目标可用。

匹配顺序与可见信息的限制

Rule 段按从上到下的顺序检查，先命中的规则决定后续策略。将宽泛规则放在前面，可能让后面的精确规则没有机会执行。地址类匹配还可能涉及域名解析，不能只看文字顺序而忽略 DNS 的结果。USER-AGENT 并非对所有加密请求都可直接读取，不能把它当作通用的应用识别机制。

上述片段只用于解释规则语法，并非完整配置文件。PROXY 在实际文件中应有可用的代理目标；如果文件使用自定义策略名称，还要核对名称及引用是否一致。需要继续阅读 General、Host、URL Rewrite 与规则优先级时，参见规则与配置参考。

Home / Add Server / Subscribe

订阅与服务器管理：参数和规则分别核对

服务器记录保存连接某个服务器所需的地址、端口、协议与认证参数；订阅则用于集中获取和更新一组记录。两者都不等于分流配置文件。本站以用户已有自己的订阅或服务器信息为前提，只说明导入和管理方法，不提供、不销售、不推荐节点或订阅。

在哪个界面，怎么添加

在 Home 使用添加入口进入 Add Server。已有订阅时，按应用提供的 Subscribe 类型填写自己的订阅地址，并设置便于辨认的名称；已有单个服务器信息时，选择对应协议并逐项填写。使用 Scan QR Code 前先确认二维码来自自己的配置资料，导入后仍应检查记录的类型、地址和端口，不要把扫码成功当作连接成功。

Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 等协议的字段并不相同。填写时以资料与当前页面实际显示的字段为准，不能把一种协议的密码、标识符或传输参数机械复制到另一种协议。TLS 相关字段尤其需要核对服务器名称与证书配置，不应为绕过错误而随意改变校验设置。

更新、测试与删除的注意事项

更新订阅后，先核对分组中的记录是否发生变化，再重新确认当前选中的服务器。订阅来源可能调整记录名称或内容，因此对订阅生成的条目进行本地修改后，要考虑下一次更新是否会覆盖修改。删除前也应分清是在删除单条记录，还是移除整个订阅分组。

Connectivity Test 用于在当前测试条件下检查响应，不代表网页、视频或所有协议流量都能正常传输。测试有结果但实际访问失败时，应继续查看目标域名、Global Routing、DNS 与规则命中情况。测试无结果也需要结合 Test Method 判断，不能仅据一次结果断定记录失效。

Settings / On Demand

On Demand：根据条件触发连接

On Demand 用于根据配置的网络条件按需触发连接，与 Global Routing 的职责不同：前者处理何时建立连接，后者处理连接后的流量路径。开启 On Demand 不会修复服务器参数，也不会自动替换失效的配置资料。

在哪个界面，怎么设置

从 Settings 检查 On Demand 相关入口，先阅读当前页面提供的网络条件与动作，再按自己的使用场景启用。若需要按 Wi-Fi 或蜂窝网络区分行为，应逐项确认对应条件；若设置涉及特定 Wi-Fi 名称，应核对名称是否准确。具体可选项以当前应用内显示为准，不应照搬其他设备上的选择而跳过核对。

首次设置前，先在手动连接状态下验证同一份服务器资料能够正常工作，再启用 On Demand。之后分别在预期连接与预期不连接的网络条件下验证。这样可以区分是连接条件没有触发，还是触发后服务器无法使用。

手动断开后又连接，先看哪里

若手动断开后又出现连接，先检查 On Demand 及其条件，再观察系统中的 VPN 状态。网络从 Wi-Fi 切换到蜂窝网络时也应重新核对，不要仅以 Home 上某一次显示判断整个切换过程。需要长时间停止按需连接时，应明确停用相应设置，再确认状态，而不是反复操作连接开关。

Data

Data：读取客户端统计，不替代服务端账单

Data 用于查看应用记录的流量信息，帮助了解上传、下载以及当前统计范围内的使用情况。它适合辅助判断连接后是否有流量经过，但统计数值本身不能证明某个网页已完整加载，也不能证明请求使用了预期策略。

在哪个界面，怎么看

进入 Data 后先确认页面当前展示的统计对象与范围，再区分上传和下载方向。做短时间测试时，可以先记下当前读数，只执行一次明确操作，随后返回比较变化。若当前页面提供重置入口，使用前应确认是否还需要保留原来的记录，重置后不能再凭这一组读数回看之前的使用情况。

统计差异怎么理解

客户端与服务端可能采用不同的计量范围、时间边界和协议开销口径，因此 Data 的数值不应直接等同于订阅资料中显示的额度。订阅额度也不等于当前设备的累计使用量。需要确认服务端计量时，应查看用户已有服务的信息；需要判断客户端请求路径时，应结合模式、规则和诊断记录，而不是只看累计流量。

Settings / Config

Settings 常用项：按用途分别调整

Settings 集中管理应用偏好、测试方式及相关工具，但并非所有行为都只由这里决定。配置文件中的 General 段也会影响连接与解析。核对设置时应同时记下当前配置文件，遇到入口位置或可选项差异，以当前应用内实际显示为准。

DNS：先核对配置文件，再改变解析方式

DNS 把域名解析为地址，会影响域名访问以及部分地址类规则的判断。先在 Config 中检查当前文件的 General 段及 DNS 相关设置；若 Settings 中有相关选项，也应一起核对，避免只改一处就假定全部生效。

[General]
dns-server = system

dns-server = system 表示使用系统 DNS，是理解解析来源的示例，不是适用于所有网络的统一答案。若准备使用自定义 DNS 或 DNS over HTTPS，应先确认目标解析服务在当前网络可达，再修改配置并重新验证同一域名。一次不要同时调整 DNS、服务器与 Global Routing，否则难以判断哪个变化产生了影响。

Test Method：测试结果必须带上测试条件

在 Settings 找到 Test Method，按当前提供的方式选择测试方法，再回到 Home 执行 Connectivity Test。不同方法可能检查不同层面的响应，因此切换方法后得出的数字不宜直接比较。比较多条记录时应保持测试方法、网络与测试时段尽量一致；完成测试后仍要用实际访问验证，不能把较小的响应时间等同于更高吞吐量。

Today Widget：用于便捷查看与操作

Today Widget 相关设置用于配合系统的小组件入口，便于查看状态或执行所提供的快捷操作。先在 Settings 检查 Today Widget 的可选项，再在系统允许的位置添加对应组件。是否显示、能提供哪些操作，与设备系统及应用内支持情况有关，以实际界面为准。

组件显示可能存在刷新间隔，连接状态需要确认时应回到 Home 和系统 VPN 状态核对。快捷入口也不会绕过首次连接所需的系统授权，组件中未显示记录时，先检查组件配置和应用状态，不要重复导入同一份资料。

iCloud：同步前先区分本地与云端资料

使用 iCloud 相关同步功能前，先确认设备已登录所需账户，系统允许应用使用 iCloud，并在 Settings 的相关入口查看实际可同步的内容。保留当前可用配置后再启用或恢复同步，随后检查另一台设备是否收到预期资料，不要默认所有偏好与运行状态都会一起迁移。

订阅地址、认证字段和配置文件可能含有敏感信息，同步前应了解将被保存的内容。iCloud 同步不等于应用购买记录恢复，也不意味着原设备上的系统 VPN 授权会直接迁移到新设备。换机后仍应逐项检查服务器、配置文件与首次连接授权。

Diagnostics：围绕一次失败收集信息

出现问题时，在 Settings 的 Diagnostics 相关入口查看当前提供的诊断工具。先记录问题发生时的网络、Global Routing 模式、服务器和配置文件，再重现一次失败。诊断内容应与同一次操作对应，避免把不同网络下的结果拼接后作判断。

分享诊断材料前，检查是否包含订阅地址、认证信息、访问域名或其他个人资料，并先作必要处理。若诊断提示与实际访问表现不一致，应返回 Home 核对当前选择与连接状态，再检查 DNS 和 Rule；不要通过反复导入资料代替定位问题。

Settings checklist

设置核对顺序：先连接，再分流，再自动化

  1. 确认资料。在 Home 核对用户已有的服务器或订阅记录，确认协议与必要参数完整，选中本次要验证的服务器。
  2. 确认模式。在 Global Routing 查看当前是 Config、Proxy 还是 Direct，并写清这次需要验证代理路径还是规则行为。
  3. 确认文件。使用 Config 模式时，进入 Config 检查启用文件、Rule 顺序和 FINAL，尤其留意自定义策略引用。
  4. 验证实际请求。先执行 Connectivity Test，再访问一个明确目标；必要时结合 Data 与 Diagnostics 判断是否有对应请求。
  5. 最后启用自动化。手动连接和规则验证正常后，再设置 On Demand、Today Widget 或 iCloud，并分别验证结果。

如果改动后无法判断原因，回到之前保留的可用配置，逐项恢复，而不是一次开启更多选项。首次导入和连接的连续步骤见上手教程；概念不清时可查阅概念速查；具体故障可按疑难解答逐项核对。