Shadowrocket 官方手册 · 功能介绍

Shadowrocket 功能与常用设置

先确定请求采用哪种路由方式，再调整规则、连接条件与诊断选项。设置是否合适，要结合已有服务器、当前网络和实际访问结果判断。

  • Global Routing
  • Config / Proxy / Direct
  • Settings / Data
先读入门指南 查看完整使用手册 →

五类能力，先分清用途

以下是功能说明，不是应用界面。切换分类查看用途；具体操作与注意事项见后续章节。

规则决定请求去向

规则分流把请求的域名或目标地址与配置中的条件逐条比较，再交给相应策略处理。入口在 Config，生效前还要将 Home 的 Global Routing 设为 Config。先检查当前启用的是哪份配置，再调整具体规则；否则，修改了未启用的文件也不会改变连接结果。排查时结合请求记录确认命中项，不要只凭服务器延迟判断分流是否正确。

DOMAIN-SUFFIX,example.com,PROXY
Home

Global Routing：配置 / 代理 / 直连

Global Routing 控制整体路由方式。日常需要按域名和地址分流时使用 Config；需要检查代理路径时可临时切到 Proxy；需要检查直接访问结果时可使用 Direct。三者不是速度档位。

姿态与界面词处理方式常见用途核对重点
配置 · Config按当前启用配置中的规则和策略处理请求。日常分流；验证自定义规则。配置是否启用、规则顺序与策略指向。
代理 · Proxy整体按代理方式处理流量；仍受系统与应用处理范围限制。临时检查当前服务器的代理连接路径。选中的服务器是否有效；测试后恢复日常姿态。
直连 · Direct整体按直接连接方式处理流量。检查本地网络或直接访问结果。Direct 不等同于关闭系统中的 VPN 连接。

设置顺序与复测方法

在 Home 打开 Global Routing，选择所需姿态后返回，确认当前显示值。使用 Config 时，再到 Config 检查启用标记；使用 Proxy 时，核对当前选中的服务器。随后重新发起目标请求，必要时结束旧连接再测试，因为已经建立的连接可能不会立即按新设置重建。

如果只有 Config 下出现问题，而 Proxy 下同一目标可以访问，应优先检查规则命中、策略组选择与解析路径。这只是缩小排查范围的方法，不是故障结论。若两个姿态都失败，还要继续核对服务器参数、认证状态与当前网络。

Config

规则类型、处理策略与匹配顺序

规则回答“哪些请求采用哪种处理方式”。在 Config 中打开当前配置，找到规则编辑入口，先理解现有条目再添加例外。规则通常从上到下检查，命中后采用相应策略；更具体的条件应放在宽泛条件前面，FINAL 作为未匹配请求的兜底放在末尾。

按目标选择匹配类型

  • DOMAIN：匹配指定域名，适合只针对一个完整主机名的情况。
  • DOMAIN-SUFFIX：匹配指定域名及其子域名，适合按域名范围管理请求。
  • DOMAIN-KEYWORD：按域名中的关键词匹配，范围较宽，添加前应评估误匹配。
  • IP-CIDR 与 IP-CIDR6：按 IPv4 或 IPv6 地址段匹配，需注意是否涉及解析以及目标是否使用动态地址。
  • GEOIP：按地址地理数据库分类匹配，数据库结果不能代替对服务实际位置与用途的判断。
  • USER-AGENT：依赖可见的请求信息，不能当作对所有应用都可靠的应用识别方式。

策略名称与界面姿态分开理解

DIRECT 表示直接连接，REJECT 表示拒绝匹配请求，PROXY 用于代理处理，具体指向要结合配置核对。规则中的大写策略与 Global Routing 中的 Config / Proxy / Direct 属于不同层级；还可能存在自定义策略组名称，引用时必须与配置一致。

DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.net,PROXY
FINAL,PROXY

以上是规则语法示例，不是一份可直接覆盖现有配置的完整文件。修改前保留原配置，修改后确认仍启用该文件，再通过请求记录检查实际命中项。不要把所有异常都交给宽泛的关键词规则，否则后续很难追踪哪些域名被一起改变了处理方式。

Home / Add Server

服务器管理与协议参数

服务器条目保存连接远端所需的信息，名称只是便于辨认的标签，并不决定协议类型。以用户已有的服务器信息为前提，在 Home 使用 Add Server，选择对应协议，再逐项填写地址、端口和认证字段。不同协议的字段含义不同，不要把 Shadowsocks 的密码直接套到需要其他身份参数的条目上。

使用 Scan QR Code 导入已有信息时，允许相机访问只用于完成扫码操作。导入后仍要打开条目检查类型和地址；二维码可能只包含单个服务器，也可能指向订阅，不能仅凭二维码外观判断内容。通过剪贴板导入时，同样要确认没有复制到前后说明文字。

修改条目时先保留可回退状态

先记录原参数或保留一份独立条目，再修改需要验证的字段。TLS、服务器名称及传输参数应与已有服务信息一致。连接失败时不要连续猜测端口，也不要把降低校验要求当作通用修复方法。对于 HTTP、SOCKS5、WireGuard、Hysteria2 等类型，按实际字段说明填写，不把一个协议的经验机械套到另一个协议。

完成保存后，在 Home 选中该服务器，再执行 Connectivity Test 并发起实际访问。条目出现在列表中只代表保存成功；测试方式、远端可达性和业务访问是三件不同的事。删除条目前，也应确认它是否被某个策略组或当前配置引用。

Subscribe

已有订阅的导入、更新与维护

Subscribe 用于集中获取和更新服务器列表，不等于规则配置。将用户已有的订阅地址填入对应入口并保存后，执行更新，检查是否出现预期条目。地址应来自自己的服务信息；网页后台地址、支付页面地址和订阅地址用途不同，不能相互替代。

更新后检查三件事

  1. 检查本次更新是否成功，区分网络访问失败与内容无法解析；不要连续重复添加同一地址。
  2. 检查当前选中的服务器是否仍存在，确认条目名称或分组变化后没有选到其他项目。
  3. 重新验证实际访问，确认规则中的策略组仍然引用正确的服务器范围。

订阅更新可能覆盖由订阅管理的条目。若需要独立维护某个参数，应先理解更新行为，再决定是否保留单独的手动条目。不要直接删除整组后才发现缺少原始地址；清理前先确认能重新导入，并妥善保存自己的必要信息。

客户端一次性买断 ≠ 线路套餐。Shadowrocket 的购买与已有服务的使用资格分别管理。本站不提供、不销售、不推荐节点或订阅，只说明如何使用用户已有的信息。

订阅地址常包含身份凭据。分享故障截图时隐藏完整地址和认证字段；不要把链接放进公开文档。遇到获取失败，先确认地址是否仍有效、当前网络能否访问以及返回内容是否正确，再考虑调整客户端配置。

On Demand

On Demand：按需连接条件

On Demand 是自动连接行为的条件设置，不是规则分流的另一种名称。先在应用中打开 On Demand，阅读当前界面提供的条件与动作，再根据自己的网络场景配置。具体入口和可用选项以当前应用内文案为准；不要仅按其他设备上的设置位置寻找。

从单一条件开始测试

需要按 Wi-Fi 区分时，核对 SSID 的拼写与适用动作；需要覆盖蜂窝网络时，单独检查对应条件，不要认为 Wi-Fi 条件会自然延伸到所有网络。使用域名触发条件时，应理解它与规则文件中的域名策略分别作用于连接触发和请求处理。

建议先保留一条容易验证的条件，切换到目标网络后观察系统 VPN 状态，再离开该网络复测。存在多条条件时，应结合界面顺序与实际动作检查重叠关系，避免一条要求连接、另一条要求不同处理。每增加一条条件都做一次双向测试，比一次写完全部条件更容易定位问题。

若手动断开后系统再次连接，先暂时停用 On Demand 并复测，确认是否由条件触发。需要日常完全断开时，同时检查应用连接状态和按需连接设置。正常使用前还应完成系统要求的 VPN 配置授权；授权连接能力不代表已经有可用服务器。

Data

Data：流量变化与统计口径

Data 用于查看应用能够统计到的流量信息。打开 Data 后，先读清当前页面的统计范围、方向和时间口径，再观察一次具体访问前后的变化。上传与下载反映数据传输方向，不直接表示网页是否完整加载，也不能单凭某个数字判断是规则还是服务器出错。

排查时可以先暂停其他明显的网络活动，记下测试前的显示值，再访问一个已知目标并对比。若统计变化但页面仍失败，说明仍需检查解析、握手或应用层错误；若变化不明显，则继续核对连接状态、路由方式与请求是否进入预期处理路径。

不要把客户端统计当作服务账单

客户端、系统和已有服务的计量范围可能不同，连接开销、统计周期与计费规则也可能不同。Data 适合观察趋势与辅助排查，不能替代服务侧的剩余额度或使用记录。需要比较时，应先对齐时间范围和单位，而不是直接将两个总数相减。

如当前界面提供重置统计的操作，先确认是否需要保留排查记录，再执行重置。重置显示记录不会改变已发生的服务使用量；换机或重新安装后，也不要假定全部历史统计都会恢复。

Settings

常用 Settings：按问题调整

先保持可用基线，再逐项修改。部分设置可能由当前 Config 管理；核对应用设置的同时，也要检查配置文件是否存在对应项。下面按用途说明，不要求把所有选项都改一遍。

DNS：域名解析路径

DNS 将域名解析为地址。到 Settings 与当前 Config 中检查相关设置，先确认采用的解析来源，再检查是否存在覆盖关系。网页打不开而 Connectivity Test 正常时，可优先查看目标域名是否解析成功。

修改前记录原值，一次只更换一个相关选项，并重新建立请求验证。不要同时叠加多套不清楚用途的 DNS 设置；解析成功也不等于后续连接一定成功。

Test Method：测试方式

在 Settings 中查看 Test Method，并了解当前方式实际检查的是哪一段连接。不同测试方式依赖的请求和目标可能不同，因此同一服务器的结果不一定可直接互比。

比较已有服务器时，尽量使用同一网络、同一测试方式和相近时间。测试正常后仍应访问实际目标；测试失败也要结合错误类型检查，不能直接据此认定所有业务都不可用。

Today Widget：快捷查看与操作

Today Widget 用于系统支持的快捷查看或操作场景。先在应用中查看相关设置，再到系统提供的小组件管理入口添加；可用形式与操作能力以当前系统和应用内说明为准。

如果显示状态与预期不同，先回到 Home 核对实际连接，再检查 On Demand。小组件是快捷入口，不能代替服务器配置、系统授权和完整的连接验证。

iCloud：同步前先检查范围

在 Settings 中查看 iCloud 相关选项，并检查系统中对应的 iCloud 权限。按当前界面说明确认同步范围，不要假定服务器、配置、统计和系统授权都会一起同步。

首次启用或换机前保留重要配置，遇到多设备内容不一致时先停止并行编辑。应用购买记录与配置同步是不同流程；系统 VPN 授权仍需在相应设备上确认。

Diagnostics

Diagnostics：记录、复现、验证

Diagnostics 用于获取排查线索，通常可从 Settings 的相关入口进入。先记录故障发生时的网络、所选服务器、Global Routing 姿态和目标，再按当前界面说明开启所需诊断。并非所有问题都需要长时间记录；围绕一次可复现的请求收集信息，通常更容易阅读。

用固定顺序缩小范围

  1. 检查连接基础。确认系统网络本身可用、应用连接状态符合预期，已有服务器参数没有被误改。
  2. 检查域名解析。观察是否有解析失败或超时；若使用地址能够连接而域名请求失败，进一步核对 DNS 路径。
  3. 检查规则命中。在 Config 姿态下确认请求采用的策略，再核对策略组实际选中的服务器。
  4. 检查连接错误。把超时、认证失败和 TLS 相关问题分别处理，不用同一种设置修改覆盖所有错误。
  5. 只改一项再复测。使用相同目标重新建立请求，确认结果后再决定保留或回退修改。

完成排查后，按需要停止额外记录，保留能够说明问题的最小片段。对外反馈前检查内容中的服务器地址、认证信息、订阅地址与访问域名；去除敏感部分后，再说明复现步骤和已尝试的修改。

为什么 Proxy 可用，切回 Config 就失败？

先检查当前启用配置、目标命中规则和策略组指向，再核对 DNS。两种姿态采用的处理路径可能不同，不能仅凭这一现象认定服务器故障。修改后重新建立请求，避免旧连接影响判断。

延迟测试正常，还需要检查什么？

测试只反映所选 Test Method 下的结果。继续检查实际目标的域名解析、规则命中、TLS 连接与访问结果，并确认当前选中的服务器与刚才测试的是同一个条目。

设置越来越多，怎样恢复可排查的状态？

先保留当前配置，再回到一份已知可用的基线，暂时简化 On Demand 条件，选定一个已有服务器和一个测试目标。按一次只改一项的方式恢复设置；不要在没有备份的情况下直接清空全部内容。

需要完整的操作顺序，可继续阅读入门指南；需要按首次启动、配置管理和日常维护逐章查阅，可使用新手到进阶官方手册。