Shadowrocket 功能与设置

ROUTING MODE

Global Routing 三种模式

Global Routing 决定连接开启时采用的总体路由方式。入口在 Home；打开 Global Routing 后，按用途选择 Config、Proxy 或 Direct。中文可理解为配置、代理、直连，但操作时应核对英文选项。它与 Home 的连接开关不是同一件事：选好模式后，仍需确认连接是否已开启。

需要按规则分流时使用 Config。在 Config 页面确认当前启用的配置，再回到 Home 检查服务器选择。仅把文件导入列表，并不意味着该文件已经被选为当前配置；同样，文件中写有 PROXY，也不意味着服务器参数已经可用。

遇到目标无法访问，可以临时用 Proxy 对照测试。如果 Proxy 下成功、Config 下失败，下一步应检查命中的规则、策略和 DNS，而不是立即重建所有服务器。用 Direct 测试时，也应保持目标与网络条件不变。完成对照后恢复原来的模式，避免把排查用状态留作长期设置。

RULE MATCHING

规则类型与策略

规则分流把请求条件与处理策略连接起来。规则位于 Config 中当前配置文件的 [Rule] 段；通常从上到下检查，首条命中后采用该条策略。因此，具体域名应放在宽泛条件之前，FINAL 放在末尾。不要只检查某条规则是否存在，还要检查它前面是否已经有能够命中的规则。

这段示例中，example.com 本身先命中 DOMAIN，采用 DIRECT；其子域名可继续命中 DOMAIN-SUFFIX，采用 PROXY。IP-CIDR 用于指定地址网段，FINAL 接收未被前面规则处理的请求。示例只是说明顺序，不应未经检查就替换完整配置。

PROXY、DIRECT、REJECT 是策略，不是规则条件。PROXY 把请求交给代理路径，DIRECT 使用直连路径，REJECT 拒绝匹配请求。排查时分别回答两个问题：请求匹配了哪条条件，以及该条件指定了什么策略。若配置使用自定义策略名称，还要检查该名称是否有效、实际指向哪个服务器。

修改前保留原配置，修改后确认文件仍为当前启用项，并用新的请求验证。已有连接可能继续沿用之前的路径，不能仅凭仍在播放或仍在传输的内容判断新规则是否生效。完整语法、配置段与顺序示例见 配置大全。

SERVER MANAGEMENT

订阅与服务器管理

服务器信息负责描述连接端点、协议和认证参数；订阅负责批量提供并更新已有服务器条目。服务器订阅与规则配置文件用途不同，不能因为链接都以文本形式提供，就把它们导入同一个入口。操作前先确认已有内容是服务器订阅、单个服务器分享内容，还是配置文件。

Add Server 与导入入口

手动添加服务器时，从 Home 进入 Add Server，先选择协议，再填写地址、端口和认证字段。Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2 使用的字段并不完全相同，应按已有服务器信息填写；TLS、传输方式与服务器名称等参数也要与服务端一致，不应仅凭协议名称猜测。

已有二维码可以使用 Scan QR Code；已有分享内容可通过相应导入操作处理。使用 Subscribe 时，应辨别当前入口管理的是服务器订阅还是 Config 中的配置订阅。导入前检查内容类型，导入后检查它出现在哪个列表，不要把规则文件地址当成服务器订阅地址。

更新、选择与保留本地修改

更新订阅后，先查看条目是否发生变化，再回到 Home 确认当前选中的服务器仍是预期条目。更新成功只表示内容被获取和处理，不代表其中每个服务器都可连接；后续仍需 Connectivity Test 与实际请求验证。若更新失败，先检查链接是否完整、当前网络是否可访问，以及订阅内容是否仍有效。

手动修改订阅生成的条目前，应考虑下次更新是否会重新生成或覆盖该条目。重要的本地修改要另行记录，移除订阅前也要核对其中是否包含正在使用的服务器。订阅链接、二维码和认证字段可能含有访问凭据，提交问题时不要公开原始内容。

CONNECTION TRIGGER

On Demand 按需连接

On Demand 根据配置的网络条件触发连接，解决的是“什么时候建立连接”，而不是“某个域名采用哪种策略”。入口在 Home 的 On Demand 设置；进入后按当前界面提供的网络条件配置，再启用。它需要系统 VPN 配置正常可用，因此应先完成一次手动连接验证。

设置时先明确预期：在指定网络连接，还是在网络条件变化后重新触发。按应用提供的 Wi-Fi、蜂窝网络及网络匹配选项逐项检查，不要在不了解条件关系时全部启用。测试时先保持一个稳定网络，再切换到另一网络，观察触发结果；只在原网络上反复打开页面，无法验证网络变化条件。

On Demand 建立连接后，请求仍由 Global Routing 和当前配置处理。它不能修复失效的服务器，也不能替代规则选择。如果手动断开后又出现连接，先检查 On Demand 是否仍启用，以及当前网络是否满足触发条件。临时排查时可先关闭 On Demand，再进行手动连接对照，结束后恢复所需条件。

TRAFFIC OBSERVATION

Data 流量统计

Data 用于查看客户端记录的流量情况。打开 Data 后，先确认当前统计项目、时间范围及界面提供的分类，再观察上传与下载的变化。测试前记下已有数值，发起一次明确请求后比较新增量，比只看累计总数更容易确认本次操作是否产生了流量。

客户端统计并不等同于服务商的计费记录。两者可能使用不同的周期、统计边界和计算口径；不能把 Data 中的总量直接当成账户剩余额度，也不能根据下载数值增加就断定网页已完整加载。后台请求、应用重试和连接开销都可能造成统计变化。

需要重新建立观察基线时，先记录必要信息，再使用界面提供的重置操作。重置统计不会修复连接，也不应与更换规则同时进行。若页面失败但 Data 有变化，应继续检查请求结果、命中策略和目标状态；若没有变化，则先核对连接开关、当前模式以及测试请求是否真正重新发出。

COMMON SETTINGS

Settings 与配置常用项

Settings 提供测试、辅助入口、同步和诊断等设置；DNS 等行为也可能由当前配置文件定义。以下按功能说明检查位置，具体层级与可用选项以当前应用界面为准。不要因为某个选项名字相似，就认为 Settings 的全局项与 Config 的文件项一定具有相同作用范围。

DNS：先确认生效位置

DNS 负责将域名解析为地址，解析结果会影响连接与部分 IP 规则的判断。检查 DNS 时先在 Config 打开当前文件，查看 [General] 中的 dns-server，以及当前界面提供的 DNS 相关设置。下面的 system 示例表示使用系统 DNS；它不是对所有网络都适用的固定建议。

如果怀疑解析异常，先比较同一个域名在修改前后的新请求，不要同时更换服务器。确认所设解析方式在当前网络可达，再检查规则是否依赖解析后的地址。修改 DNS 不会自动改变服务器认证、目标证书或已有连接；出现错误时应区分解析失败与连接失败。

Test Method：统一测试口径

Test Method 位于 Settings，用于选择服务器测试采用的方法。先查看当前方法及其可配置参数，再执行 Connectivity Test。不同方法衡量的阶段不同：端口能够建立连接，不等于目标页面请求完成；通过代理完成测试请求，也不代表所有目标都能访问。

比较服务器时保持 Test Method、测试目标与网络条件一致。不要将不同方法得到的数值直接排序，也不要把某次测试较短解释为长期速度保证。测试失败后，应分别核对端点可达性、认证信息、传输参数和测试目标，最后再检查实际使用的目标。

Today Widget：辅助查看与操作

Today Widget 是系统小组件相关的辅助入口，可在 Settings 检查应用提供的相关选项，再按系统支持的方式添加或管理。可用位置和操作形式受设备与系统影响，应以当前系统界面为准。先在应用内完成服务器选择和连接验证，再配置小组件，避免把初始配置问题误认为组件问题。

小组件展示属于辅助信息，系统刷新可能不即时。状态有疑问时打开 Home 检查实际连接开关、Global Routing 与服务器选择，不要只凭小组件的一次显示判断当前路由。移除小组件也不等于关闭应用中的 On Demand。

iCloud：同步与恢复分别检查

使用 iCloud 相关功能前，先检查系统中的 iCloud 可用状态及 Shadowrocket 的访问权限，再检查应用 Settings 中提供的同步选项。按当前功能支持的范围同步，不要假设所有服务器、配置、统计和系统授权都会一并复制。首次同步前，应保留重要配置的可恢复副本。

多设备修改同一内容时，先确认同步已经完成，再继续编辑，避免无法辨认哪一份是预期状态。换设备后仍应检查当前配置、选中的服务器与系统 VPN 授权。App Store 已购恢复与 iCloud 内容同步是不同流程：应用能够重新获取，并不意味着所有使用数据已恢复。

Diagnostics：收集可复现信息

Diagnostics 用于辅助检查运行状态与连接问题，可从 Settings 中的诊断相关入口查看当前可用工具。排查前记下网络类型、Global Routing、当前配置和出现问题的操作，再复现一次。诊断信息应与实际失败时间对应，过早保存的记录可能没有包含需要分析的请求。

分享诊断结果前，删除订阅链接、密码、认证字段和不必要的个人信息。只保留有助于判断阶段的内容，例如解析是否完成、连接在哪一步失败以及命中了什么策略。一次收集足够定位的信息后，应恢复日常记录设置，避免长期保留不必要的详细请求记录。