配置 / 代理 / 直连，对应界面词 Config / Proxy / Direct。
Global Routing 决定连接流量采用哪一套路由方式，不负责创建服务器，也不等于连接开关。在 Home 找到 Global Routing 后选择 Config、Proxy 或 Direct，再确认当前 SERVER 和连接状态。初次使用建议先核对已有服务器参数，通过短时测试判断连接是否可用，最后回到 Config 验证规则。切换模式后，应新建一次请求；已经建立的长连接不适合作为切换是否生效的唯一依据。
| 姿态与界面词 | 路由行为 | 何时使用 | 注意事项 |
|---|---|---|---|
| 配置 · Config | 按当前启用的配置文件处理连接，由 [Rule] 匹配策略。 | 日常分流，或验证某个域名应走 DIRECT、PROXY 还是 REJECT。 | 先确认启用的是哪份 Config，再看规则顺序和 FINAL。 |
| 代理 · Proxy | 主要连接交给当前选定的代理服务器处理，不按普通规则逐项分流。 | 短时检查服务器能否承载目标请求，缩小规则排查范围。 | 仍受系统路由、必要绕过项及网络环境影响，不应理解为设备上所有流量的绝对保证。 |
| 直连 · Direct | 主要连接采用直接连接方式，不使用代理服务器转发。 | 对照本地网络访问情况，区分直连问题与代理链路问题。 | Direct 不等于关闭 VPN 连接；关闭连接需操作 Home 的连接开关。 |
如果 Proxy 可以访问而 Config 不可以，优先查看 Config 中的命中规则、策略和 DNS 设置；这说明问题可能在分流路径，而不是所有服务器参数都失效。如果 Proxy 与 Config 都失败，再检查服务器、本地网络和协议参数。Direct 的结果只能说明直接连接路径的情况，不能据此证明代理服务器正常或异常。
测试时记录当前姿态、所选服务器和目标域名，结束后恢复原设置。避免为了排查一次问题而长期停留在与预期不同的姿态；尤其在更换配置文件后，应再次检查 Global Routing，而不是只看 Home 的连接开关是否开启。
类型说明匹配什么，策略说明命中后怎么处理。
规则分流是在 Config 姿态下，按配置中的条件给连接选择路径。在 Config 打开当前配置文件，找到 [Rule]，按从上到下的顺序阅读。普通规则通常命中即停止继续匹配，因此更具体的条件应放在宽泛条件之前，FINAL 放在末尾承接未命中的请求。
DOMAIN 匹配完整域名；DOMAIN-SUFFIX 匹配域名及其子域名；DOMAIN-KEYWORD 按域名中的关键字匹配。IP-CIDR 与 IP-CIDR6 分别描述 IPv4、IPv6 网段；GEOIP 按地址地理数据库判断；USER-AGENT 针对可获取的 User-Agent 信息，不能假定所有连接都能使用它识别应用。
策略 PROXY 表示交给代理路径，DIRECT 表示直接连接，REJECT 表示拒绝。策略名称不代表服务器健康状态，也不提供新的服务器参数。先确认请求命中了什么，再判断策略的后续连接是否成功。
两条语法都正确的规则仍可能产生相反结果。例如，宽泛的 DOMAIN-SUFFIX 放在特定 DOMAIN 之前，会让后者没有匹配机会。修改时先备份当前配置，只调整相关行的位置或策略，再用新连接验证。IP 规则还与可用的解析结果有关；GEOIP 的判断依赖数据库，不适合作为服务实际部署位置的精确证明。完整语法与配置段落见规则与配置参考。
服务器参数解决“如何连接”，配置规则解决“何时使用”。
在 Home 使用 Add Server，按用户已有信息选择对应 Type，再填写地址、端口、认证与传输参数。Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2 等类型的字段并不通用；不要仅因为地址相同就复制另一种类型的参数。TLS、服务器名称及传输选项也应与现有服务器要求一致，不应以关闭验证的方式掩盖填写错误。
保存后回到 Home，在 SERVER 中确认当前选中项。列表里存在某个服务器，不等于连接正在使用它。手动录入时建议给条目设置可辨认的名称，但不要把密码、密钥或完整订阅地址放进名称，以免在展示列表或分享诊断信息时泄露。
已有订阅通常可通过 Add Server 中的 Subscribe 类型录入。填写用户自己的订阅 URL，保存后按该条目的更新操作获取内容，再确认服务器条目是否出现、当前选择是否仍符合预期。Subscribe 中包含的访问凭据应视为敏感信息，不粘贴到公开页面，也不提交到无关的检测工具。
订阅更新失败与服务器连接失败是不同问题：前者涉及订阅地址是否有效、当前网络能否请求该地址以及返回内容能否识别；后者涉及实际服务器的协议、认证和传输。更新成功也不等于每个服务器都能连通。删除订阅前先确认是否会一并移除关联条目，手动修改订阅生成的条目也可能在后续更新时被覆盖。
在 Home 使用 Connectivity Test 前，先到 Settings 核对 Test Method。不同方法可能只覆盖端口响应，或进一步涉及指定目标的请求。某项测试通过，不代表所有网站和应用都可用；某项测试失败，也应先排除测试目标和方法的影响。将测试结果与一次真实目标请求放在一起看，比只依赖列表中的测试显示更可靠。
控制连接何时触发，不替代 Global Routing 与 [Rule]。
On Demand 用于让系统根据已设条件触发或维持 VPN 连接。先在 Home 手动连接，确认服务器与 Config 能正常工作，再到 Settings 的 On Demand 检查开关及可配置条件。具体条件项以当前应用内显示为准；涉及 Wi-Fi 或蜂窝网络时，逐项确认适用范围，避免把“自动连接”误认为“自动选择最快服务器”。
设置完成后，在预期的网络条件下重新测试，并观察 Home 的连接状态。切换 Wi-Fi 与蜂窝网络可能造成已有连接重建，出现短暂中断不应直接归因于规则语法。先核对触发条件是否满足，再检查连接建立之后的路由。
如果手动断开后连接再次出现，先检查 On Demand 是否仍处于启用状态，以及系统是否按已有条件重新触发。需要暂停时，先调整 On Demand，再操作连接开关，最后确认状态没有再次变化。不要在多处反复操作而不记录先后顺序。
On Demand 不能修复过期凭据、错误的端口或失效的配置。自动触发后仍然无法访问，应回到手动连接流程定位原因。工作网络有特定连接要求时，先核对网络管理规定和本地资源访问方式，再决定是否启用自动触发。
观察计数变化，用来辅助验证，不替代网络账单。
Data 用于查看应用能够记录的流量信息。进入 Data 后，先看清当前页面的统计范围和计数说明，再观察连接前后上传、下载等数值的变化。不同视图的范围可能不同，不要把一次会话、某个条目与长期累计值直接相加比较。统计存在更新时机，短时间内没有明显变化也不能单独证明请求没有发生。
先关闭不相关的后台网络活动，记下 Data 当前计数，再打开一个固定页面或执行一次已知请求，返回 Data 对照新增情况。需要清空计数时，先保存排查所需记录，再使用页面提供的重置操作。对比两次测试应保持相同目标、相近持续时间与同一统计范围，避免把不同实验条件产生的差异解释成模式性能差异。
Data 中的计数不等于蜂窝运营商计费流量，也不等于用户已有连接服务的额度记录。协议封装、重传、统计入口和计量周期都可能影响数值。判断某个域名是否命中 PROXY 或 DIRECT，应结合连接记录及当前规则；只看到流量增长，无法确定所有请求都使用了同一条路径。
入口与字段以当前应用内显示为准，每次只修改一个变量。
Settings 中的功能与 Config 文件可能共同影响连接。查找以下项目时，先确认自己正在调整的是全局偏好、当前配置，还是系统权限；不要仅凭名称相似就认为它们属于同一层。界面位置可能随应用调整，下文使用英文项目名帮助定位，不以固定行号描述菜单。
DNS 将域名解析为连接所需的地址。检查 Settings 中的 DNS 相关选项，同时查看当前 Config 的 [General] 是否已有 dns-server 等设置，避免只修改一处却遗漏另一处。排查时先保留原值，确认是域名无法解析、解析结果不符合预期，还是已有地址却连接失败，再决定是否调整。
例如 dns-server = system 表示使用系统解析设置的一种配置写法，不能作为适用于所有网络的建议。改变 DNS 可能影响 IP 规则匹配和实际连接目标，但不能修复服务器认证错误。测试后重新发起请求，并考虑已有解析缓存的影响；不要把一次成功当作所有域名均已恢复。
在 Settings 找到 Test Method，阅读当前选项的说明后选择测试方式；若该方式需要目标地址，也要核对目标本身是否可访问。端口层面的响应与完成一次应用层请求不是同一个结论，因此不同方法的结果不宜直接比较。修改后回 Home 重新执行 Connectivity Test，并用同一目标进行实际访问验证。
测试显示主要用于辅助筛选和定位，不代表持续吞吐能力或所有请求的体验。若只有测试失败而实际使用正常，先检查测试方法及目标，而不是立即重写全部服务器信息。
Today Widget 用于在系统支持的组件位置提供快捷查看或操作。先检查 Settings 中的 Today Widget 相关选项，再在系统的组件编辑入口确认是否能添加对应内容；具体可用形式取决于设备系统与当前应用提供的能力。不要把某一种组件样式视为所有设备都必然具备。
快捷入口仍依赖已经保存的服务器、配置与连接权限。点击后应回 Home 核对实际状态，尤其在设备刚恢复数据、应用尚未完成首次设置时。组件不是独立的连接配置来源，也不能代替对当前 SERVER 的检查。
需要跨设备保留设置时，检查 Settings 中的 iCloud 同步项，并确认系统允许 Shadowrocket 使用 iCloud。启用前先备份重要配置，核对两台设备上已有内容，避免把同步误当作可随时回滚的历史归档。同步完成情况应通过实际条目检查，不以开关已开启作为唯一依据。
App Store 的已购项目用于恢复应用获取资格，iCloud 用于应用支持的数据同步，两者不是同一步骤。换机后即使应用已安装，也需要检查服务器信息、Config 选择及 VPN 授权。同步范围以应用内说明为准；服务器凭据与订阅内容可能敏感，使用前应确认所登录账户和设备访问权限。
遇到问题时，在 Settings 查找 Diagnostics，按应用提供的诊断或记录选项收集信息。先写下故障发生时间、当前网络、Global Routing、所选服务器和失败目标，再重复一次问题。这样的上下文能帮助区分解析、认证、传输或规则匹配环节，比仅保留一条报错更有用。
分享记录前检查域名、IP、订阅地址、认证字段和个人访问内容，移除不必要的敏感信息。日志中看到某个请求失败，不应立即推出全部连接不可用；结合发生时间和同一目标的重复测试判断。排查完成后恢复临时调整的诊断选项，避免长期保留与日常使用无关的记录。
先验证基础连接，再加入分流与自动触发。
首次配置可接着阅读Shadowrocket 使用教程；需要逐行理解配置时，转到规则与配置参考。尚未购买应用时，先查看开发者、官方图标与应用 ID 的核验步骤，再从 App Store 获取。