Shadowrocket
代理模式与设置

Global Routing 位于 Home。日常需要按域名或地址区分请求时，选择 Config；临时验证所选服务器能否承载请求时，可以使用 Proxy；检查当前网络本身是否能访问目标时，可以使用 Direct。更改后应重新发起测试请求，已有连接可能仍保持原来的会话状态。

配置/代理/直连分别对应界面词 Config/Proxy/Direct。界面中的 Proxy 是模式名称，规则中的 PROXY 是策略关键字；两者相关，但不能把选择 Proxy 理解成启用某一条规则。

Config：规则配置决定策略

先到 Config 确认要使用的配置文件，再回到 Home 将 Global Routing 设为 Config。仅导入文件不等于已经选中该文件；规则写得正确，也需要处于会使用规则的模式。测试时选一个预期走 PROXY 的目标，再选一个预期走 DIRECT 的目标，分别核对结果，不要只凭一个网页能打开就判断整份配置正确。

Proxy：临时验证代理路径

在 Home 的 SERVER 列表中确认当前选中项，再选择 Proxy 并开启连接。这里的“全局模式”指应用接管范围内的统一代理处理，不应理解为对设备上所有系统行为的绝对描述。若 Proxy 可用、Config 不可用，重点检查规则匹配与当前配置；排查结束后，恢复原先需要的模式。

Direct：验证当前网络路径

在 Home 将 Global Routing 设为 Direct，再重新访问目标。Direct 不会把不可直达的目标变成可达，也不等同于关闭连接开关；它改变的是处理策略。要完全停止本次 VPN 连接，应操作 Home 的连接开关。遇到局域网设备访问异常时，可先用 Direct 做对照，再回到 Config 检查相应地址规则。

规则通常在 Config 中对应配置的 Rule 部分查看和编辑。DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配域名后缀及其子域，DOMAIN-KEYWORD 按域名中的关键词匹配。地址条件可使用 IP-CIDR 与 IP-CIDR6；GEOIP 依赖地址归属数据，不能据此推断内容所用语种或用户所在地。

常见策略是 PROXY、DIRECT、REJECT，分别用于代理处理、直连处理和拒绝请求。规则一般按从上到下的顺序检查，前面的有效匹配决定结果。因此应把具体例外放在宽泛条件之前，将 FINAL 留作末尾兜底。以下仅展示语法，示例域名不代表需要访问的实际服务。

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
DOMAIN-KEYWORD,ads,REJECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

修改前先保存原配置，修改后确认文件仍可正常载入。不要连续加入大量未经检查的规则：例如过短的 DOMAIN-KEYWORD 可能匹配到不相关域名，过宽的地址范围可能改变局域网访问。USER-AGENT 依赖请求中实际可获取的相关信息，不适合作为所有流量都能命中的通用条件。

需要修改 DNS、Host 或 URL Rewrite 时，应区分配置段的职责，不要把它们混写进 Rule。完整语法、优先级与分段说明见规则参考；这里的重点是先确认 Config 生效，再验证命中结果。

Subscribe 用于按已有订阅地址导入和更新服务器列表，SERVER 显示可选的服务器项。已有订阅通常可在 Home 通过添加入口进入 Add Server，选择 Subscribe 后填写地址并保存；手动录入则应选择与已有服务器信息一致的协议类型。具体字段取决于所选类型，不能把不同协议的参数直接互换。

保存后回到 Home，检查列表是否出现预期条目，并点选需要使用的服务器。名称只用于辨认，不能说明协议、认证或目标地址一定正确。用 Connectivity Test 测试，再开启连接验证实际请求；单个测试有响应，也不表示所有目标都可访问。

订阅更新：先确认分组，再执行刷新

找到对应订阅的更新操作，只刷新需要更新的分组，并核对是否返回成功结果。订阅更新可能增删或重命名服务器，因此更新后还应检查当前选中项是否仍然存在。若分组为空或数量发生意外变化，先确认地址有效性与网络状态，不要立即删除全部配置再导入，以免丢失原有选择和手动备注。

订阅地址可能包含访问凭据，应视为敏感信息。不要将完整地址放进公开截图、网页或诊断记录中。已有订阅与 Config 文件也不是同一概念：前者主要维护服务器条目，后者承载规则和其他配置；更新订阅不能替代检查当前规则文件。

协议字段：以已有服务器参数为准

Shadowsocks、VMess、VLESS、Trojan、Hysteria2 等协议有不同的连接与认证字段。添加时先确认协议，再逐项核对地址、端口、认证信息及相关传输设置。不要为了让一次测试通过而随意关闭验证选项；若缺少必要参数，应回到自己的原始服务器信息核对，而不是尝试拼凑字段。

On Demand 用于根据所设条件触发 VPN 连接，不负责替代 Rule 判断每个请求应走哪种策略。它与 Global Routing 是两层设置：前者关心何时连接，后者关心连接后的处理方式。即使设置了 On Demand，服务器参数错误或规则配置不当也不会因此得到修复。

从 Home 的 On Demand 入口进入，检查当前开关及条件列表，再按应用内提供的网络条件配置。一次只添加一种条件，保存后切换到对应网络验证触发结果，再切到不符合条件的网络检查行为。不同界面布局以当前应用显示为准，不要把仅适用于一种网络的条件理解为所有网络通用。

如果手动断开后又出现连接，应先查看 On Demand 是否仍然启用，以及当前环境是否符合触发条件。需要暂停自动连接时，应同时检查按需设置，而不是反复操作 Home 开关。网络切换、设备唤醒与现有会话可能影响观察结果，应给系统完成状态切换的时间，并重新发起请求验证。

Data 页面用于查看应用记录的流量信息。进入后先辨认显示的是哪一类条目、哪个统计范围，再比较上传与下载数据。若页面提供重置操作，重置前应保留需要的记录；重置客户端统计不会改变已有订阅对应的远端账户状态。

需要判断某次操作是否产生流量时，可记录操作前的读数，完成一次明确的访问，再回到 Data 比较变化。后台任务、其他应用请求和连接维持活动都可能同时产生流量，因此不要把两次读数差直接当成某个网页的精确用量。统计增长也只能说明发生了数据传输，不能单独证明目标内容加载完整。

排查流量方向与规则效果时，应把 Data 与当前 Global Routing、Config 和请求记录结合起来看。不要将客户端统计当作剩余额度或账单依据；若需要核对自己的服务使用情况，应查看已有服务对应的账户记录，注意统计周期和计算方式可能不同。

DNS：先确认当前解析设置来自哪里

DNS 将域名解析为地址，解析结果也可能影响地址类规则的匹配。在 Settings 的 DNS 相关设置与当前 Config 中检查已有配置，先确定实际生效的来源，再修改解析方式或服务器。若域名访问失败而地址访问行为不同，可以把解析作为排查方向，但这并不足以直接证明 DNS 故障。

修改前记录原值，修改后重新发起请求，必要时按应用内提供的方式处理缓存。不要同时修改 DNS、规则和服务器，否则很难确定原因。某些配置依赖特定网络路径，直接换成另一组地址不一定改善结果，还可能影响局域网名称解析。

Test Method：统一测试方法再比较

Test Method 决定连通性测试采用的方法，可在 Settings 相关测试设置中查看。先选定一种方法，再对同一组服务器执行 Connectivity Test。不同测试方法考察的连接阶段不同，结果不应直接混在一起排序；测试响应快也不等于持续传输速度高，更不等于所有应用请求都能成功。

如测试项涉及目标地址，使用自己明确理解的目标，并在对照测试期间保持不变。某一种测试失败时，先用实际请求交叉验证，再检查协议与测试方法是否适合，不要只凭一个数字删除服务器。

Today Widget：快捷操作前确认当前选择

Today Widget 用于提供快捷查看或操作入口。先在 Settings 中检查相关选项，再按系统支持的方式添加到相应区域。系统是否展示该入口及可用操作，以当前系统与应用实际界面为准。使用快捷入口前，仍应在 Home 确认所选服务器和 Global Routing。

快捷入口用于减少操作步骤，不会自动判断哪一份配置适合当前网络。遇到显示状态与预期不同的情况，应打开应用核对连接状态，而不是仅根据快捷区域的一次显示判断连接成功。

iCloud：同步前检查范围

iCloud 相关同步在 Settings 中检查，同时需要设备系统允许应用使用 iCloud。开启前先查看应用列出的同步对象，不要假设订阅、配置、认证信息和历史数据都会以相同方式同步。两台设备上应分别确认同步状态，并保留重要配置的可恢复副本。

修改同一份数据前，先等待上一台设备完成同步，避免在多台设备上同时编辑造成冲突。iCloud 同步不等于 App Store 购买恢复：应用购买与重新下载由 App Store 管理，配置是否同步则取决于应用设置和账户状态。含有凭据的配置仍需谨慎处理。

Diagnostics 是定位连接问题的工具入口，可从 Settings 中查找。按界面提供的诊断项目执行并阅读结果，区分当前网络、域名解析、服务器连接和目标请求几个阶段。诊断结果描述的是测试当时的状态，不能代替长期可用性判断，也不应根据一条错误信息推断所有目标都不可用。

1. 确认基础网络。检查当前 Wi-Fi 或蜂窝网络可用，必要时通过 Direct 做同目标对照，记录两种路径的差异。
2. 确认 SERVER。检查选中项、协议、端口与认证信息；更新已有订阅后，再确认选中项没有发生变化。
3. 执行 Connectivity Test。保留同一种 Test Method，结合实际访问结果判断，不把测试数值当成速度承诺。
4. 切换 Proxy 做对照。若 Proxy 正常而 Config 异常，回到 Config 检查规则顺序、策略和 FINAL；若两者都异常，继续检查服务器与网络条件。
5. 最后检查自动化与辅助设置。核对 On Demand、DNS 和同步状态，每次仅改一个变量，并在验证后决定保留或恢复。

保存或分享诊断信息前，移除订阅完整地址、服务器认证信息及其他个人内容。仅保留复现步骤、所用模式和必要的错误描述，通常更有助于定位问题。需要重新梳理从导入到连接的完整流程，可继续阅读入门指南；需要逐条修改规则，转到规则参考。