按什么条件匹配
DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配域名后缀，DOMAIN-KEYWORD 检查域名中的关键字。IP-CIDR 与 IP-CIDR6 分别匹配相应地址段，GEOIP 按地址所属区域数据判断。选规则时先确认对象是域名还是 IP 地址，不能把完整网址直接当作域名规则的匹配值。
DOMAIN-SUFFIX,example.com,PROXY
官方手册 · 功能与设置
Shadowrocket
设置与功能说明
从 Global Routing 到 Diagnostics，按“功能含义 → 界面位置 → 设置方法 → 检查结果”逐项核对。先确认当前姿态和配置，再调整具体参数，避免同时修改多处后无法定位原因。
- Global Routing / Config
- On Demand
- Data / Diagnostics
本页以 iPhone 与 iPad 的操作逻辑为主。入口位置和可用选项以当前应用内显示为准；系统要求以 App Store 页面标注为准。首次配置可先阅读入门指南，再返回本页核对各项设置。
Global Routing：配置、代理与直连
Global Routing 决定连接使用哪一种总体处理方式。它通常位于 Home；这里的 Config、Proxy、Direct 分别对应配置、代理、直连三种姿态。它们不是三份服务器信息，也不是连接开关本身。选择姿态后，仍需检查 Home 中选中的服务器、当前配置和连接状态，才能判断请求实际如何处理。
日常需要按域名或地址区分处理方式时，使用 Config；需要暂时排除规则匹配因素时，可以用 Proxy 作对照；需要判断当前网络直接访问是否正常时，可以用 Direct 作对照。三种姿态的结果必须结合具体目标观察，不能因为一个页面能打开就推断所有请求都走了相同路径。
| 姿态与界面词 | 主要处理方式 | 适用场景 | 注意事项 |
|---|---|---|---|
| 配置 / Config | 按当前启用配置中的规则及策略处理请求。 | 需要规则分流，或检查特定域名命中哪条规则。 | 确认配置已启用；仅保存文件不等于已切换到该文件。 |
| 代理 / Proxy | 以代理方式处理一般请求，具体行为仍受相关网络设置影响。 | 临时对照服务器连接与规则判断的差异。 | 不代表每项系统流量都经过同一路径，也不保证目标可达。 |
| 直连 / Direct | 以当前网络直接连接目标。 | 对照当前 Wi-Fi 或蜂窝网络的基础访问情况。 | 不是关闭连接开关；On Demand 的连接行为仍需单独检查。 |
怎样切换并验证
在 Home 打开 Global Routing，选择所需姿态，返回后核对显示值。用同一个目标发起新的访问，再查看可用的连接记录。已经建立的长连接未必立即体现新设置；必要时先结束测试连接，重新发起请求。完成对照后恢复原来的姿态，尤其不要把临时使用的 Proxy 或 Direct 当成规则仍在生效。
规则分流：匹配对象与处理策略
规则负责判断请求符合什么条件，策略负责决定命中后怎么处理。入口在 Config：先核对当前启用的配置，再查看其中的规则顺序。一般按自上而下的顺序检查，前面的规则已命中时，后面的规则不会替它重新作决定；FINAL 用于承接前面未命中的请求。
命中后如何处理
DIRECT 表示直接连接，PROXY 表示交给代理处理，REJECT 表示拒绝请求。配置也可能引用策略组名称，最终行为还取决于组内当前选择。修改时应同时核对规则末尾的策略和它引用的组，不能只看规则前半段就判断请求路径。
IP-CIDR,192.168.0.0/16,DIRECT
调整方法是先定位目标，再检查它可能匹配的前几条规则，把更具体的条件放在合适位置，并保留明确的最终处理方式。上面的规则只用于解释语法，不是一份完整配置。若启用配置后网页异常，先记录命中规则，再修改这一处；不要同时替换整份配置和 DNS。协议参数的含义可继续查阅协议参考。
订阅与服务器管理
服务器条目保存连接所需的地址、端口、协议与认证字段；订阅则用于批量导入和更新已有条目。它们与 Config 中的分流规则属于不同层次：有了服务器信息，不等于已经启用了合适的规则；导入规则文件，也不等于已有可连接的服务器。
Home / Add Server：添加已有信息
在 Home 使用 Add Server，按已有服务器资料选择对应类型，再逐项填写参数。使用已有订阅时，在添加入口选择相应的 Subscribe 类型，填入自己的订阅地址并保存；使用二维码时，从 Scan QR Code 导入后仍应核对类型和关键字段。不同协议需要的认证、传输与 TLS 字段不同，不应把一个类型的参数直接套用到另一个类型。
保存后返回 Home，确认条目已出现并选中预期服务器，再做 Connectivity Test。条目名称只是便于辨认的标签，不是连接成功的依据。手动编辑前可记录原值；订阅生成的条目可能在后续更新时被覆盖，需要长期保留的调整应先确认当前应用提供的管理方式。
Subscribe：更新与重复条目检查
更新已有订阅后，检查条目数量变化、分组及当前选择是否符合预期。更新失败时先确认地址完整、当前网络能访问该地址，再检查是否需要重新取得有效的原始信息。不要把“订阅能更新”和“其中某个服务器能连接”当成同一件事：前者只说明资料获取成功，后者还涉及服务器状态、协议参数与网络条件。
订阅地址、二维码及导出的配置可能含认证信息。截图或分享排查资料时应遮盖这些内容，尤其不要把完整订阅地址放进公开留言。需要逐步导入说明时，使用入门指南中的添加流程。
On Demand：按网络条件连接
是什么、在哪里设置
On Demand 用于让系统按已设定的网络条件决定是否发起连接。它处理的是连接触发，而不是替代 Config 中的请求分流。可在应用的 On Demand 相关入口查看可用条件；入口及条件名称以当前应用显示为准。设置前先完成一次手动连接，确认系统 VPN 配置授权、服务器参数与基础访问均正常。
根据实际需要设置 Wi-Fi、蜂窝网络或特定网络条件时，应从少量条件开始，保存后分别在对应网络下观察连接状态。只有触发条件与当前环境一致，测试结果才有意义；同一网络内反复开关页面不能代替网络切换测试。
怎么检查、注意什么
若手动关闭后连接又出现，先检查 On Demand 是否仍在触发，而不是连续删除系统 VPN 配置。需要完全停止本轮测试时，先暂停 On Demand，再处理连接开关，并确认系统状态。反过来，未自动连接时也应先核对条件是否匹配，而非立即更换服务器。
On Demand 不会修复错误的认证字段，也不能保证网络切换后所有既有连接持续可用。Wi-Fi 与蜂窝网络之间的变化可能使原连接重建。测试时记录切换前后的网络、触发条件及状态，才能区分是按需条件问题还是连接本身失败。
Data：观察流量而非判断套餐余额
Data 展示客户端可记录范围内的流量统计，用来观察使用量及变化。进入 Data 后，先查看当前页面显示的统计范围、时间范围和计量单位，再比较上传与下载。应用内统计与系统蜂窝用量、已有服务的计费口径可能不同，不能据此推算剩余可用额度。
实际检查时，可以先记下当前数值，完成一段明确的访问，再返回观察变化。如果页面提供重置操作，应先确认其作用范围并记录需要保留的数据，避免清除后失去排查基线。统计增长只能说明相应范围内有流量被记录，不能单独证明某个域名命中了 PROXY，也不能说明它一定成功取得了完整内容。
排查异常用量时，把 Data 与连接记录配合使用：先确定增长发生的时间，再查看对应的目标和处理策略。后台同步、媒体预加载与应用重试都可能产生请求，应先找出具体活动，再考虑调整规则。不要只凭一段时间的总量就判断是某个协议“更省流量”。
Settings：DNS、测试、小组件与同步
以下项目按功能解释。请在 Settings 或对应功能入口核对当前可用选项，界面名称、展示位置及系统支持情况以实际显示为准。
DNS：把域名解析与后续连接分开检查
DNS 负责把域名转换为可用于连接的地址；解析成功与目标服务可达是两个不同阶段。在 Settings 的 DNS 相关设置或当前 Config 的 DNS 内容中，先确认实际使用的来源。配置文件可能包含自己的 DNS 指令，调整前应检查是否与其他设置重复或相互影响，而不是只改一个输入框就认为全部请求已切换。
设置时保留原值，每次只调整一个来源或一项行为，再访问同一目标并查看解析与连接记录。延迟测试正常但网页打不开时，先区分解析失败、连接失败与 TLS 阶段失败；不要直接把所有故障归因于 DNS。涉及 IPv6 时，需同时考虑当前网络是否支持对应地址连接，而不是仅凭出现 IPv6 地址就判定异常。
Test Method：统一测试口径
Test Method 决定 Connectivity Test 使用何种测试方法。进入对应设置后，先阅读当前方法的说明，再固定同一种方法比较已有服务器。如果方法需要测试目标，也应保持目标一致。不同方法可能分别反映端口建立连接或特定请求的情况，结果不能直接混在一起排序。
测试显示数值并不等于实际页面一定能打开，也不能直接代表持续传输速度。比较前先确认设备处于同一种网络，尽量避免同时进行大流量任务；出现单次失败时重复测试并记录现象。完整排查还要检查 Global Routing、命中规则与实际访问的目标。
Today Widget：快捷查看与操作入口
Today Widget 用于系统小组件相关的快捷展示或操作。先在 Settings 中查看应用提供的相关选项，再到系统的小组件编辑界面检查是否能添加对应项目。不同系统环境提供的入口可能不同，以当前设备显示为准，不把小组件是否出现作为应用连接能力的判断条件。
配置完成后，先在应用内确认连接可用，再观察小组件的显示与操作结果。小组件可能存在刷新延迟；状态不一致时回到 Home 及系统 VPN 状态核对，不要仅凭小组件文字决定是否已连接。也应考虑锁定屏幕或共享设备场景下会暴露哪些服务器名称。
iCloud：同步前先确认范围
iCloud 相关选项用于同步应用支持的内容。先在系统中确认 iCloud 可用及应用访问权限，再到 Shadowrocket 的相关设置核对同步范围。同步、文件导入与完整恢复不是同一个动作；不要假定所有服务器、认证信息、统计和系统 VPN 授权都会一起迁移。
启用或在另一台设备恢复前，先保留当前可用配置的副本，并确认可能发生的合并或覆盖行为。完成后逐项检查当前 Config、服务器选择、Global Routing 与 On Demand。系统 VPN 配置授权仍需在相应设备上核对；即使同步内容已出现，也应做一次实际连接测试后再继续使用。
Diagnostics：把故障定位到具体阶段
Diagnostics 用于收集和检查连接相关线索，可从 Settings 的对应入口查看当前提供的诊断项目。它与 Connectivity Test 的用途不同：一次延迟测试给出有限的连通性信息，诊断则帮助判断失败发生在哪一步。运行前先明确要复现的现象，例如“同一域名在 Config 下失败，在 Direct 下可访问”，而不是只记录“连接不好”。
按顺序观察
- 核对当前网络、连接开关和系统 VPN 授权状态。
- 核对 Global Routing、当前 Config 与选中的服务器。
- 对同一个目标重新发起请求，查看解析、连接和规则记录。
- 每次只改一项条件，再重复相同测试并比较结果。
保留必要证据
记录故障发生时使用的网络类型、姿态、测试方法与错误文字。超时、认证失败和证书错误指向不同阶段，处理方式也不同。诊断结果含有域名、地址或认证信息时，先遮盖敏感内容，再整理需要说明的部分。
不要为消除报错而随意放宽证书验证。应先核对服务器资料、证书名称和设备时间；确认字段后，再复测原目标。
若只有一个目标失败，先检查它的解析、匹配规则和目标服务状态；若所有目标都失败，再回到基础网络与服务器参数。这样的顺序可以减少无关改动，也便于把应用设置问题与服务器端状态区分开来。具体常见现象可查阅疑难解答。
设置调整顺序与恢复检查
第一次配置时，先把“能够手动连接”和“按预期分流”分成两项任务。前者检查已有服务器资料与系统授权，后者检查 Global Routing 和 Config。基础连接未验证前就加入复杂规则、自动触发条件和多处 DNS 修改，会让同一个失败现象出现多个可能原因。
- 记录当前状态。保存可用配置，记下当前姿态、服务器选择及关键设置原值。需要恢复时，以这些记录为基线，而不是凭记忆重新填写。
- 先验证手动连接。暂停 On Demand 的干扰，确认已有条目可以用于预期访问。Connectivity Test 与实际请求都应观察，但二者不能互相替代。
- 再验证 Config。启用预期配置，检查具体目标命中的规则和策略。遇到异常时只修改相关规则，避免连同服务器认证字段一起改动。
- 最后加入自动化。按需要启用 On Demand、小组件或同步，并在对应环境单独验证。确认结果后，再以 Data 和诊断记录观察日常使用情况。
恢复设置后仍需新建测试请求。已经存在的连接、应用缓存和系统网络变化，都可能使刚修改后的表现与预期暂时不同。把测试目标、网络条件和观察窗口固定下来，比反复切换多个开关更容易得到可复核的结论。