Shadowrocket
代理模式与常用设置
先选择 Global Routing 的工作方式，再核对服务器与配置。连接开关、分流规则和按需连接分别控制不同环节，设置时应分开验证。
- Home
- Config
- Data
- Settings
Global Routing 三种模式
日常按规则分流使用 Config；临时验证代理链路使用 Proxy；对照直接连接使用 Direct。在 Home 打开 Global Routing，选择对应模式。这里的选择决定进入客户端的请求如何处理，不等同于打开连接开关，也不会自动修正服务器地址、认证信息或 DNS 设置。
| 模式 | 处理方式 | 适用场景 | 核对重点 |
|---|---|---|---|
配置Config |
按照当前启用配置中的规则选择策略。 | 需要让不同域名或地址采用不同策略。 | 配置是否启用、规则顺序、最终兜底策略。 |
代理Proxy |
将进入客户端的流量按代理模式处理；仍需注意系统流量范围与应用内例外设置。 | 短时判断问题是否来自分流规则。 | 当前选中的服务器是否可用，目标能否经该服务器连接。 |
直连Direct |
将进入客户端的流量按直接连接模式处理。 | 比较当前网络的直接连接结果。 | 当前网络本身能否访问目标，DNS 是否正常。 |
Config：规则决定去向
在 Config 界面确认正在使用的配置，再回 Home 将 Global Routing 设为 Config。配置中命中的策略可能是 PROXY、DIRECT、REJECT，也可能是配置内定义的策略组。Home 里选中了某台服务器，并不意味着每个请求都会经过它；规则若指定 DIRECT，请求就按直接连接处理。
Proxy 与 Direct：用于缩小问题范围
如果同一目标在 Proxy 下正常、Config 下失败，应优先核对命中的规则和策略引用，而不是立即改写全部服务器字段。如果 Direct 正常、Proxy 失败，则继续检查所选服务器、认证与传输参数。模式对照只是定位线索，不是单凭一次结果就能确定故障原因的结论。
切换后关闭并重新打开测试页面，必要时重新建立客户端连接，以免旧连接影响观察。完成测试后恢复预定模式；把 Proxy 长期保留为排查时的临时状态，会改变原本的分流结果。
规则类型与策略
规则说明“匹配什么”，策略说明“匹配后怎么处理”。在 Config 中打开当前配置，查看或编辑其中的 Rule 部分。通常按文件中的先后顺序判断，先命中的规则先决定结果，因此具体规则应放在合适位置，FINAL 作为最后的兜底。
| 规则类型 | 匹配对象 | 设置注意 |
|---|---|---|
DOMAIN | 指定的完整域名。 | 适合只处理一个明确域名的情况。 |
DOMAIN-SUFFIX | 域名本身及其子域名。 | 不要把完整网页地址或路径填入域名位置。 |
DOMAIN-KEYWORD | 域名中的关键字。 | 范围可能比预期更宽，注意误匹配。 |
GEOIP | IP 地址对应的地区分类。 | 分类结果与使用的地址数据库有关。 |
IP-CIDR / IP-CIDR6 | IPv4 / IPv6 地址段。 | 确认地址类型与前缀长度。 |
USER-AGENT | 可识别的 User-Agent 信息。 | 能否匹配取决于请求中相应信息是否可见。 |
FINAL | 此前未命中的请求。 | 应置于规则末尾，明确最终去向。 |
PROXY、DIRECT、REJECT 的区别
PROXY 指向代理处理，DIRECT 表示直接连接，REJECT 表示拒绝请求。这些大写关键字是配置语法，与 Global Routing 中的 Proxy、Direct 界面选项不是同一层级：前者是某条规则的处理结果，后者是全局工作方式。使用自定义策略名称时，还要确认该名称确实在配置中存在。
[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.org,PROXY
DOMAIN-KEYWORD,ads,REJECT
GEOIP,CN,DIRECT
FINAL,PROXY以上只演示语法，不是适合所有网络的完整配置。第一条仅匹配 example.com，第二条覆盖 example.org 及其子域名；关键字规则范围更宽，复制前需要理解它会影响哪些请求。不要为了增加规则数量而重复添加同一条内容，也不要把 FINAL 放在尚需生效的规则之前。
修改前保留原配置副本，每次只调整一小组规则，并用目标域名检查实际策略。若需要逐项理解 General、Rule、Host 和 URL Rewrite 的结构，继续阅读规则与配置参考大全 →
订阅与服务器管理
服务器记录保存连接参数，订阅用于批量获取和更新这些记录。以用户已有自己的订阅或服务器信息为前提，在 Home 使用 Add Server 添加内容。选择 Subscribe 时填写自己的订阅地址；手动添加时，先选正确的协议类型，再按照原始资料填写对应字段。
Add Server：协议与字段逐项对应
Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2 的参数并不完全相同。地址和端口相同也不能说明记录可以互换。密码、UUID、TLS、传输方式及相关字段应以用户自己的服务器资料为准；有些字段仅在选择相应协议或传输方式后显示。
已有单条分享信息时，可使用应用提供的导入入口；已有二维码时使用 Scan QR Code。导入后仍需打开记录核对协议、地址、端口与认证字段，不能只根据显示名称判断导入是否正确。名称便于辨认，但真正决定连接的是记录内的参数。
Subscribe：区分更新与本地编辑
订阅更新会重新获取地址中的内容。若某条记录由订阅管理，本地对它的编辑可能在后续更新时被替换，因此需要保留长期修改时，应先明确记录来源及应用当前的保存方式。多个订阅同时存在时，建议使用可辨认的备注，核对分组后再删除失效项目，避免把名称相近的记录误当成重复内容。
订阅刷新成功只说明内容获取和解析完成，不代表每台服务器都可连接。反过来，订阅更新失败也不必然使已经保存的记录立刻失效；应分别检查地址获取结果和服务器连接结果。
On Demand 按需连接
On Demand 用于根据设置的条件请求系统建立连接，不负责替代分流规则。在 Settings 中打开 On Demand，查看应用提供的条件与开关。具体可选条件以当前应用界面为准；先确认手动连接工作正常，再启用按需连接，便于把连接本身的问题与触发条件的问题分开。
设置与验证方法
- 在 Home 选定服务器与 Global Routing 模式，手动连接并打开需要测试的目标。
- 进入 On Demand，阅读当前条件的作用，再启用所需选项。涉及网络名称的条件应与设备实际连接的网络一致。
- 切换到目标网络或重新满足触发条件，观察系统连接状态，同时检查实际请求能否完成。
- 若结果与预期不符，先暂时关闭 On Demand，再回到手动连接验证，不要同时改动规则与服务器参数。
On Demand 与 Config 可以共同使用：前者控制何时建立连接，后者控制连接建立后请求采用的策略。看到系统连接标识并不能推断所有请求都经由代理，因为 Config 中仍可能存在 DIRECT 或 REJECT 规则。
如果手动断开后连接又出现，应检查是否仍有 On Demand 条件生效，而不是反复删除配置。首次建立连接时的系统 VPN 配置授权属于系统流程；允许后仍需验证应用内设置。设备的网络变化、系统调度与条件匹配都会影响观察结果，不应把按需连接理解成对每个应用请求的单独开关。
Data 流量统计
Data 用于查看客户端记录的流量情况，不是服务方的账单。打开 Data，按照界面展示的统计范围查看上传、下载及相关记录。需要比较某次测试时，先记下观察起点，再只执行一个明确操作，随后返回查看变化；如果要使用重置功能，应先确认是否仍需保留原有统计。
流量数值能说明什么
数值增加说明客户端在相应统计口径下记录到了数据活动，但不能单独证明某个网页完整加载，也不能仅凭总量判断使用了哪台服务器。后台应用、同步任务和重复请求都可能产生流量；判断某个目标的路由结果，应结合当前模式、命中策略与连接记录，而不是只看总量。
为什么与服务方记录不同
双方可能采用不同的统计周期、重置时间、协议开销计算或计费规则。客户端统计与服务方提供的记录应分别理解，剩余可用量以用户自己服务方的说明为准。不要把本地重置统计误认为服务方的用量也会随之清零。
排查时可以采用一个固定测试流程：暂停不必要的后台活动，记录 Data 中的当前值，访问一个已知目标，再比较变化。这样有助于减少干扰，但仍不是精确的线路计费测量。统计记录中若包含目标信息，分享前也应检查是否涉及个人访问内容。
Settings 设置说明
Settings 集中管理测试方式、辅助入口、同步与诊断等选项。部分网络行为也由当前配置的 General 部分控制。同一问题先确认设置来自哪里，再修改对应位置；不要仅因设置名称相近，就假定它们会影响同一条请求链路。以下项目是否显示及具体入口，以当前应用界面为准。
DNS：先确认解析路径
DNS 把域名转换为连接需要的地址。相关选项需结合 Settings 中的 DNS 设置与当前 Config 的 General 内容核对，重点是使用哪个解析器、请求通过哪条路径，以及配置是否另有指定。先记录原值，再根据已有网络与配置要求调整；保存并重新连接后，用同一个域名比较结果。
不要只凭 Connectivity Test 出现数值就认定 DNS 正常：某些测试只验证服务器端点的可达性，与网页域名解析不是同一过程。若只有域名访问失败，先排查解析；若域名解析成功但仍无法连接，再检查目标策略、服务器链路及 TLS 等环节。随意叠加多个不理解的 DNS 选项，会增加定位难度。
Test Method：明确测试测量的对象
Test Method 用于选择 Connectivity Test 的测试方法。在 Settings 找到该项，根据界面提供的方式和说明选择，再回 Home 对已有服务器执行测试。比较不同记录时，应尽量使用相同的方法、目标与网络环境，否则数值缺乏可比性。
测试结果是当时条件下的可达性或响应情况，不等于带宽，也不保证所有网站可访问。出现数值但网页失败时，应继续核对网页使用的域名、规则与 DNS；测试失败时，也要先区分测试目标不可达与实际代理连接失败，避免直接删除仍可能可用的记录。
Today Widget：辅助操作入口
Today Widget 为系统支持的组件入口提供相关设置，可在 Settings 中核对其选项。是否能够添加、展示哪些操作，以及组件入口所在位置，取决于当前系统与应用支持情况；应按设备上的实际组件列表操作。先在应用内确认连接正常，再尝试从组件操作。
组件是辅助入口，不会代替服务器参数、Global Routing 或系统 VPN 授权。若组件展示与实际访问结果不同，回到 Home 核对当前连接与模式，而不是仅依据组件外观判断流量去向。
iCloud：同步与本地保存分别核对
iCloud 相关功能用于在应用支持的范围内保存或同步资料。在 Settings 查看 iCloud 选项，并确认设备已登录自己的 Apple 账户、系统允许应用使用 iCloud。启用前先保留重要配置副本，操作后核对应用实际显示的同步项目与结果。
不要假定开启后所有服务器、认证资料、配置、统计和临时状态都会完整同步。跨设备使用时逐项核对内容，尤其是当前启用的配置与服务器选择。应用购买记录、iCloud 同步资料和用户自己的服务方账户属于不同事项；同步完成也不能替代重新验证连接。
Diagnostics：收集线索后再修改
Diagnostics 用于查看或收集与运行问题有关的诊断信息。进入 Settings 中相应入口，按界面提示执行检查；先记录发生问题时的网络环境、Global Routing 模式、目标和操作步骤，再查看诊断输出，这样才容易把记录与实际失败对应起来。
不要把某一条警告直接当作全部原因。诊断内容应与 Connectivity Test、DNS 和规则结果交叉检查。对外提供信息前，移除订阅地址、服务器认证、个人域名和其他敏感内容；修改设置前保留原值，便于确认修改是否真正有效。
设置验证与排查顺序
一次只改变一个条件，用同一目标重复验证。服务器、模式、配置与 DNS 同时修改，即使恢复访问，也很难知道是哪项调整生效。建议先建立可以复现的最小测试，再按下面的顺序检查。
- 确认当前网络。先判断设备是否具备正常联网条件；切换 Wi-Fi 与蜂窝网络时，分别记录结果，避免把网络变化误认为配置变化。
- 确认服务器记录。核对协议、地址、端口、认证与必要的传输字段；明确正在选中的记录是否来自预期订阅。
- 确认连接状态。核对 Home 中的连接操作与系统授权，不把服务器被选中误认为连接已经建立。
- 进行模式对照。在相同目标上比较 Proxy 与 Config。若仅 Config 失败，检查规则与策略引用；若均失败，继续检查链路与解析。
- 检查 DNS 和诊断。区分无法解析、无法建立连接、连接后请求失败，不把所有现象都归结为某一条规则。
- 恢复日常设置。保留验证有效的修改，恢复临时切换的模式，再测试 On Demand 和辅助入口。
Config 模式下，为什么部分请求没有使用代理？
Config 按当前配置选择策略。请求可能命中 DIRECT，或进入包含直接连接选项的策略组。核对启用的配置、规则顺序和实际命中结果；不能只根据 Home 选中的服务器判断所有请求的去向。
On Demand 开启后，还需要设置 Global Routing 吗？
需要。On Demand 控制连接触发条件，Global Routing 控制流量处理方式。先手动验证服务器与模式，再开启 On Demand 并检查触发结果，两部分应分别确认。
Connectivity Test 正常，为什么网页仍打不开？
测试与网页访问可能使用不同目标和路径。继续检查网页域名的 DNS 解析、Config 中的策略、所选服务器到目标的连接，以及诊断记录中的失败环节。测试数值不能替代实际访问验证。