Settings · Official Manual

Shadowrocket 功能与常用设置

先确定 Global Routing，再检查规则与服务器，最后调整 Settings。本篇按“是什么、在哪里、怎么设、注意什么”说明常用功能，适用于 iPhone 与 iPad 上的操作核对。

Shadowrocket 是 Apple 平台的付费客户端，唯一获取入口是 App Store。客户端一次性买断 ≠ 线路套餐；下文以用户已有自己的订阅或服务器信息为前提，本站不提供、不销售、不推荐节点或订阅。系统要求以 App Store 页面标注为准。

  • 先选 Global Routing
  • 再核对 Config
  • 最后验证 实际请求

Global Routing

三种模式：配置、代理、直连

Global Routing 决定请求按什么方式选择路径，不负责补齐服务器资料。在 Home 打开 Global Routing，可核对 Config、Proxy、Direct 三种姿态。需要按域名或地址分流时选 Config；需要临时检查代理路径时选 Proxy；需要观察直连表现时选 Direct。修改之前先记下原来的选择，排查结束后恢复日常模式。

界面选项工作方式适用情形优先检查
Config（配置）按当前配置中的规则决定策略。日常规则分流、指定网站代理、局域网直连。配置是否选中、规则先后顺序、末尾兜底策略。
Proxy（代理）让受客户端处理的请求使用代理路径。临时判断异常是否与规则选择有关。当前服务器是否有效、代理连接能否建立。
Direct（直连）让受客户端处理的请求采用直连路径。对照本地网络表现、确认问题是否出在代理路径。当前网络与目标是否能直接通信。

Config 只是模式选择，还需要在 Config 页面确认实际使用的配置文件。导入成功、文件存在与配置已选中，是三个不同状态。若修改规则后没有变化，先检查当前配置，再检查 Global Routing；不要立刻把所有 DNS、测试方式和服务器参数一起修改。

首次操作可先按使用教程完成连接与验证 →

Config · Rule

规则分流：先匹配，再执行策略

规则描述“匹配哪些请求”，策略描述“命中后怎么处理”。在 Config 中查看、导入或编辑配置；使用配置分流时，回到 Home 将 Global Routing 设为 Config。规则通常按自上而下的顺序判断，先命中的规则决定处理结果，所以窄范围规则应放在可能覆盖它的宽范围规则之前。

常见规则类型包括精确匹配域名的 DOMAIN、匹配域名及其子域名的 DOMAIN-SUFFIX、按域名关键词匹配的 DOMAIN-KEYWORD，以及用于 IPv4、IPv6 地址段的 IP-CIDR 与 IP-CIDR6。GEOIP 根据 IP 地理归属判断，并不表示网站内容使用的语言或用户的所在地。地址规则能否命中，还与请求信息及解析过程有关。

PROXY 表示使用代理路径，DIRECT 表示直连，REJECT 表示拒绝请求。它们是策略，不是匹配类型。FINAL 用于处理没有命中前置规则的请求，应放在列表末尾；把它放在前面，后面的规则就可能失去匹配机会。

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

这段示例表达“example.com 及其子域名走 PROXY，指定局域网地址段走 DIRECT，其余走 DIRECT”，不是完整的可用连接资料。修改前保留原配置；修改后使用一个明确的目标重新发起请求，并对照连接记录核实命中的规则与策略。仅凭网页能打开，无法确认它到底走了哪条路径。

继续阅读规则关键字与匹配顺序 →

Subscribe · Add Server

已有订阅与服务器管理

订阅用于维护一组服务器资料，单条服务器则保存某个连接的参数。已有订阅时，在 Home 的添加入口按 Subscribe 类型填写链接并保存；已有单条资料时，使用 Add Server，按实际协议填写地址、端口、认证信息与相关选项。支持的导入形式应以当前应用显示的入口为准，不要把不同类型的资料强行填入同一字段。

Shadowsocks、VMess、VLESS、Trojan 等协议需要的字段不完全相同。服务器地址不能替代订阅链接，订阅名称也不是认证信息。手动填写时，按已有资料逐项核对协议、端口、密码或身份标识，以及 TLS 等附加参数；名称主要用于辨认，不会自动纠正连接参数。

保存订阅后执行更新，检查是否出现预期的服务器列表，再选择要使用的一项并运行 Connectivity Test。订阅更新解决的是“资料是否刷新”，连接测试解决的是“测试目标在当前条件下是否可达”，两者不是同一项验证。若更新失败，先核对链接是否完整、服务资料是否仍有效及当前网络是否能访问订阅地址。

手动调整由订阅生成的服务器时，要考虑后续更新可能覆盖改动。长期需要保留的自定义资料，应与自动更新的内容明确区分。删除订阅前确认影响范围，尤其注意是否会一并移除关联服务器。订阅地址可能含有个人凭据，分享截图、日志或配置前应遮盖相关内容，也不要把完整链接贴到公开页面。

查看导入、选择服务器与首次验证步骤 →

On Demand

按需连接：让连接行为符合网络条件

On Demand 用于根据设定条件触发或调整 VPN 连接行为，不替代域名分流规则。在 Settings 中找到 On Demand，先阅读当前页面提供的条件与动作，再决定是否启用。不同系统和应用状态下可见选项可能有所差异，应以设备上的实际说明为准。

设置前，先在手动连接状态下确认服务器和 Config 工作正常。然后只添加一条明确的条件，保存后切换到对应网络，观察系统 VPN 状态与实际请求结果。例如希望某类网络环境使用不同连接行为，应在 On Demand 中描述网络条件；希望某个网站走 DIRECT，则应修改 Config 中的规则，而不是试图用连接条件替代网站规则。

启用后，手动断开与条件触发可能产生看似矛盾的现象：刚关闭连接，满足条件时又出现连接状态。此时先检查 On Demand 条件，不要反复删除服务器或重置全部设置。排查过程中可暂时停用 On Demand，固定在单一网络下测试，确认基础连接后再逐条恢复条件。

按需连接仍依赖系统权限、当前网络和可用的服务器资料；它不是连通性的保证。测试时至少覆盖一次进入条件和一次离开条件的过程，并留意从 Wi-Fi 切换到蜂窝网络后是否符合预期。

Data

流量统计：区分速率、累计量与计费量

Data 用于查看客户端记录的流量情况，不能直接代替服务侧的计费记录。进入 Data 后，先看清当前页面的统计范围、方向与单位，再判断数字代表上传、下载、累计传输量，还是某个时刻的速率。速率是单位时间内的传输情况，累计量是统计区间内的数据总和，两者不能直接比较。

验证统计时，可以先记录当前数值，再执行一次可识别的访问，回到 Data 观察变化。若界面提供重置入口，重置前先保存需要的记录；重置本地统计不会重置服务侧额度。也不要把应用显示的传输量直接当作设备全部网络用量，设备系统统计与客户端统计的观察范围可能不同。

本地记录与服务侧记录不一致时，应核对统计周期、单位、是否包含多个设备，以及连接协议带来的额外传输开销。直连与代理路径是否分别统计、当前页面展示哪些维度，均应按实际界面判断。不能仅因 Data 有增长，就推断某条规则已正确命中；路径验证仍需结合连接记录与请求目标。

持续排查时，建议同时记录时间、所用网络、服务器名称与 Global Routing 模式。这样即使累计数值发生变化，也能把变化与具体操作对应起来，而不是只保留一个缺少上下文的总量截图。

DNS

DNS：先核对生效位置，再修改解析设置

DNS 负责把域名解析为地址，解析成功不等于后续连接一定成功。检查时同时查看 Settings 中的 DNS 相关选项，以及当前 Config 文件中是否存在 [General] 段和 dns-server 参数。不要只根据某个设置页面的一个值，就认定所有请求都使用了同一种解析路径。

如果现有网络正常，没有明确需求时先保留原来的解析方式。确需修改时，先备份配置，记录原值，再按应用接受的格式填写。采用 dns-server = system 的配置会引用系统提供的解析设置，但最终行为还需要结合当前配置与相关 DNS 选项判断。不同来源配置之间的差异，应逐项核对，而不是整段覆盖。

遇到“地址可达但域名打不开”，可以优先检查解析；遇到“域名已有解析结果但连接超时”，则继续检查策略、服务器和目标服务。不要把所有失败都归因于 DNS。修改后重新发起连接与请求，必要时使用应用提供的相关诊断入口检查结果，避免沿用旧连接得出错误结论。

同时调整多个解析选项会增加定位难度。每次只改一个变量，记录调整前后的同一目标结果；没有改善就恢复原值，再继续下一项检查。公共网络可能还有需要先完成的网络登录流程，也应在测试前排除这一因素。

进入设置手册查看 DNS 参考 →

Settings

测试方式、Widget 与 iCloud 同步

Settings 中的选项服务于不同环节，不宜统一理解为“提高连接速度”。先明确要改变的是测试方法、系统展示还是资料同步，再进入对应项目。选项位置与可用范围以当前应用界面为准；本页不为不同设备指定统一的默认值。

Test Method：统一测试条件

Test Method 决定连接测试采用什么方法。在 Settings 找到 Test Method，按当前界面提供的选项选择，再返回 Home 执行 Connectivity Test。若同时显示测试目标或超时等参数，也应记录下来。同一批服务器需要比较时，保持测试方法、目标、网络环境和测试时段尽量一致。

测试读数只反映所选方法下的一次结果，不能等同于持续传输速度。某种测试失败，也不必然代表所有实际请求都会失败；反之，测试成功也不能证明每个网站都能访问。选择服务器后，仍应访问实际目标，并结合规则命中情况核对。

Today Widget：核对应用与系统两侧配置

Today Widget 用于系统支持位置的快捷展示或操作。在 Settings 中检查相关选项，再到系统的组件编辑入口确认是否已添加相应组件。可用的组件形式、显示内容和交互方式会受到系统支持情况影响，不应把应用内开启选项与系统中已经添加组件混为一谈。

若组件没有出现，先回到应用确认设置，再检查系统组件列表；若显示信息与刚完成的操作不同，打开应用核实当前状态。分享屏幕前留意组件是否展示服务器名称等个人信息，不要仅依赖组件上的一个状态来判断规则路径。

iCloud：确认同步范围，再处理冲突

iCloud 同步用于在支持条件下协调应用资料，不等于恢复所有运行状态。先在系统设置确认当前 Apple 账号与 iCloud 可用，再到 Shadowrocket 的 Settings 检查同步选项及其说明。具体同步哪些资料、何时触发，应以当前界面为准；不要假定所有设置、统计和连接状态都会同步。

首次启用或多设备资料不一致时，先保留各设备的重要配置，再观察同步结果。避免在两台设备上同时修改同一份资料后立即反复开关同步。同步也不能代替购买记录：换机恢复应用应在 App Store 使用原购买账号查找，购买与恢复步骤见已购恢复说明。

Diagnostics · Log

诊断与日志：围绕一次失败请求定位

Diagnostics 与日志用于提供定位线索，不应把记录中的单个提示直接当作最终原因。在 Settings 中查找 Diagnostics 或相关 Log 入口，先确认当前界面能够提供哪些检查与记录。需要采集时再启用相应选项，记录一次问题复现过程，完成后恢复原设置。

  1. 固定当前网络，记录 Global Routing、当前 Config 与所选服务器，暂时避免自动切换条件干扰。
  2. 运行 Connectivity Test，然后访问一个明确的目标，记下发生失败的时间与现象。
  3. 查看同一时间段的记录，依次检查域名解析、规则命中、策略选择与连接建立环节。
  4. 只修改与证据相符的一项设置，再对同一目标重复测试；没有改善时恢复原值。

日志可能包含访问域名、服务器地址、订阅资料或认证信息。保存与分享之前，应检查并遮盖敏感内容，仅保留定位所需的时间、错误描述和必要上下文。不要为求方便长期记录所有活动，也不要通过反复导入新配置掩盖原问题。

本页用于理解功能与操作边界。需要逐项核对 Settings，可继续阅读设置手册；遇到具体症状，可进入常见问题，或按连接开关打开但无法访问的排查顺序继续检查。