Shadowrocket 功能与设置

Global Routing 决定由 Shadowrocket 接管的流量如何选择处理路径。在 Home 打开 Global Routing，先看当前选中项，再决定是否切换。配置、代理、直连分别对应界面中的 Config、Proxy、Direct，实际操作时按英文名称识别。切换模式不是更换服务器，也不会修正服务器资料中的错误。

日常使用与临时排查分开处理

已经准备好分流配置时，可使用 Config，并通过请求记录确认规则效果。怀疑规则造成异常时，记录原模式，再用 Proxy 或 Direct 对同一目标做一次对照。测试结束恢复原模式，避免把临时状态当成日常配置。某个目标在一种模式下能打开，只能帮助缩小问题范围，不能单独证明 DNS、服务器或规则中的哪一项必然有错。

Direct 不等同于关闭系统 VPN 配置。要检查是否完全停止连接，应同时查看 Home 的连接开关与系统 VPN 状态。对连接路径有明确要求时，不要只凭状态栏图标判断。

一条规则通常包括匹配类型、匹配内容和处理策略。规则类型回答“依据什么识别请求”，策略回答“匹配后怎样处理”。在 Config 中查看当前配置的规则部分，先核对较具体的条目，再核对宽泛匹配与 FINAL。规则通常按顺序匹配，不能只确认某条规则存在，还要确认它是否有机会被执行。

按目标选择匹配条件

DOMAIN 用于完整域名匹配；DOMAIN-SUFFIX 用于域名后缀匹配；DOMAIN-KEYWORD 按域名中的关键字匹配，范围可能比预期更大。使用后缀规则时填写域名本身，不附带网页路径。对单个域名做例外处理，通常应把精确条件放在可能覆盖它的宽泛条件之前。

IP-CIDR 与 IP-CIDR6 按地址范围匹配，GEOIP 依赖地址归属数据。域名规则与地址规则观察的对象不同：域名解析结果、IPv4 与 IPv6 路径都可能影响检查结果。USER-AGENT 依赖请求中能被识别的相关信息，不宜把它理解成对所有应用都有效的应用级选择器。

策略名称与 FINAL

DIRECT 表示直接连接，PROXY 表示代理处理，REJECT 表示拒绝匹配请求。配置如果使用自定义策略名称，应确认名称有对应定义且拼写一致。FINAL 负责处理前面规则未命中的请求；它的选择会决定大量未单独列出的目标走向，因此修改时必须明确预期。

[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.org,PROXY
FINAL,DIRECT

Home 用于查看、选择和管理已有服务器。单条资料可通过 Add Server 按协议录入；已有订阅链接可通过 Subscribe 导入；已有二维码可使用 Scan QR Code。选择哪种入口取决于用户手中的资料格式，而不是哪种方式能改变服务端能力。导入之前确认资料来自用户自己的服务来源，并保留原始信息以便核对。

导入后先核对，再连接

1. 确认服务器列表确实出现预期条目；如果列表为空，先查订阅获取与解析，不急于修改规则。
2. 打开条目检查协议、地址、端口与认证字段。TLS 或传输参数应与已有资料一致，不凭名称猜测。
3. 选择准备使用的条目，执行 Connectivity Test，再进行实际请求验证。测试方式不同，结果含义也不同。
4. 查看 Global Routing 与当前 Config，最后开启连接；只有这几项同时明确，才便于解释流量去向。

更新订阅会重新读取远端条目，可能出现名称改变、条目增减或原选择不再存在的情况。更新后重新核对当前服务器，不要只看“更新完成”的提示。需要手动保留的特殊参数，应先记录再更新，并核实订阅更新是否会重建对应条目。

服务器名称是识别标签，不是连接质量的证明。整理时可用便于辨认的名称区分用途，但不要把凭据放入名称。订阅链接、二维码和导出内容都可能携带认证信息；提供排查资料时只保留必要字段。需要完整导入流程时，按教程逐步操作。

Data 用于观察应用记录的流量与连接情况。排查时先确定当前展示的统计范围、时间口径及是否曾重置，再看上传、下载或连接记录。某次连接有流量，只说明发生了数据交换；握手、解析及失败重试也可能产生数据，不能把计数增长直接当成业务访问成功。

用一次可复现请求对照记录

开始前记录所选服务器、Global Routing 和测试目标。打开一个目标页面后，返回 Data 查看新增记录，结合可见的目标、策略与时间判断请求是否经过预期路径。若需要更详细的处理原因，再按需查看 Log。测试期间减少其他应用的后台请求，避免把不同请求混在一起解释。

Data 的统计口径不应直接等同于服务端账单或设备蜂窝数据统计。不同计数范围、协议额外开销、重连和时间区间可能造成差异。需要比较时先统一观察时段，并保留重置前的数据。记录可能包含访问目标与地址，截图或导出前应检查隐私信息。

DNS：先区分解析失败与连接失败

DNS 负责把域名解析成地址。在 Settings 的 DNS 相关项目与当前 Config 中检查解析设置，先记录已有值，再确认使用目的。目标域名无法解析与已经得到地址但连接失败，是两类不同问题；应先用诊断记录区分，再调整对应环节。不要一次替换多个解析选项后仅凭网页是否打开判断原因。

DNS 请求本身也需要可用的网络路径。若设置的解析方式依赖当前代理，而代理连接又未建立，可能出现相互依赖的故障。检查时同时考虑服务器可达性、规则和 IPv4、IPv6 结果。域名解析会涉及查询信息的处理，选择设置时应理解其路径，而不是只比较一次测试耗时。

Test Method：测试方式决定结果含义

Test Method 控制连接测试采用的方式。在 Settings 查看该项目，再回到 Home 执行 Connectivity Test。比较多个条目时应保持测试方式、目标和网络环境一致。测试超时不一定表示服务器完全不可用，也可能是测试目标或测试方式不适合；测试通过同样不代表所有业务请求都能完成。

不要只依据一次结果重排全部服务器。先重复测试，再用真实目标请求验证，最后结合日志判断。若更改测试相关参数，记录修改前的状态，避免把不同条件下的结果放在一起比较。

Today Widget：快捷查看与操作

Today Widget 是与系统小组件相关的设置入口，可用于配置相应的快捷展示或操作内容。先在 Settings 查看当前可用选项，再按设备系统提供的方式添加相应小组件。可展示内容、添加方式与刷新行为以实际界面为准，不把小组件显示理解为持续实时监测。

从快捷入口操作后，重要测试仍应回到 Home 核对连接开关、当前服务器与 Global Routing。若小组件未及时更新，先打开应用查看实际状态；不要仅凭旧的展示文字连续切换连接。

iCloud：同步范围与覆盖检查

iCloud 相关设置用于应用支持的同步功能。在 Settings 检查可同步的项目，并确认系统已允许相应的 iCloud 使用。启用前保留当前重要配置，换设备后先观察同步结果，再进行编辑。不同类别的数据不一定全部同步，不能把“已开启 iCloud”视作所有连接资料都已完整恢复。

多台设备同时修改时，应先确认各设备看到的内容，再决定保留哪一份。同步存在等待过程，切换账号或关闭功能前先检查本地资料。iCloud 同步与 App Store 购买记录属于不同事项：恢复购买不会自动证明服务器资料或配置已经同步。

Diagnostics 与 Log：为一次问题收集证据

Diagnostics 用于进一步检查连接问题；Log 用于查看请求处理过程。进入 Settings 的相关入口，按实际可用项目执行检查。收集前写下失败目标、发生条件和当前模式，再复现一次问题，优先保留与这次请求有关的记录。这样比长时间连续记录后猜测原因更容易定位。

日志中可能包含域名、地址、订阅信息或其他连接细节。分享前删除或遮去敏感字段，保留解释问题所必需的时间、错误信息与策略上下文即可。详细记录完成后，恢复适合日常使用的记录设置；不要在资料不完整时根据单条错误推断全部连接都失效。

设置较多时，按固定顺序检查，比同时尝试多个选项更容易复原。先确认当前网络可用，再确认服务器资料与所选条目，随后检查 Global Routing、当前 Config、DNS，最后检查 On Demand 和快捷入口带来的状态变化。每一步记录原值，测试结束后恢复临时调整。

1. Home：确认所选服务器与连接开关，区分订阅更新成功、测试通过和实际请求成功。
2. Global Routing：明确当前是 Config、Proxy 还是 Direct；若做模式对照，始终使用同一个目标。
3. Config：确认生效文件、命中规则、策略引用与 FINAL，不只搜索目标域名是否存在。
4. Settings：按问题类型检查 DNS、Test Method 或 On Demand，不把统计展示项当作路由开关。
5. Data / Diagnostics：以一次可复现请求核对记录，保存必要证据后恢复日常状态。