Shadowrocket 设置与功能说明
先确定连接何时建立，再确定请求采用哪种策略。按 Global Routing、Config、On Demand 与 Data 的顺序检查，可把模式选择、规则判断和结果验证分开处理。
操作以 iPhone 与 iPad 为主。界面入口可能随应用调整，具体名称以当前应用内显示为准；系统要求以 App Store 页面标注为准。首次连接步骤见入门指南。
Global Routing：配置、代理与直连
Global Routing（全局路由）决定整体请求处理方式，不是服务器协议选择器，也不等同于连接总开关。
在 Home（首页）找到 Global Routing，进入后选择 Config（配置）、Proxy（代理）或 Direct（直连）。选择前先确认 Home 中的服务器和 Config 中启用的配置文件。模式改变后，新发起的请求才适合作为验证对象；已经建立的连接可能继续沿用原有路径，不能只靠刷新一次页面就判断设置是否生效。
| 界面模式 | 处理方式 | 适用检查 | 注意事项 |
|---|---|---|---|
| Config（配置） | 依据当前配置中的规则决定请求策略。 | 日常按域名、地址等条件分流。 | 必须确认当前启用的 Config 与编辑的是同一份。 |
| Proxy（代理） | 将代理处理作为整体路由方式。 | 临时检查所选服务器的实际连接能力。 | 不是把全部规则中的 PROXY 项分别重新选择一次。 |
| Direct（直连） | 采用直接连接方式。 | 临时检查当前网络自身的访问情况。 | 不等同于关闭系统连接配置或停用 On Demand。 |
日常使用先选 Config
如果目标是让不同请求采用不同策略，应选择 Config，再检查规则顺序。此时 Home 中选中一个服务器，并不意味着每个请求都会经过它：命中 DIRECT 的请求直接连接，命中 REJECT 的请求被拒绝，命中 PROXY 的请求才按相应代理策略处理。规则中若引用了指定策略组，还需检查该策略组当前的选择。
Proxy 与 Direct 用于缩小问题范围
当 Config 下只有某个目标异常，可以临时用 Proxy 或 Direct 对照同一个目标，判断问题是否与规则路径有关。每次只更改一个模式，记录结果后切回原设置。这个对照只能帮助定位，不能独立证明 DNS、服务器或目标服务一定正常。模式名称是整体路由选项，具体请求仍应结合连接记录核对。
规则分流：匹配条件与执行策略
规则左侧描述匹配条件，末尾指定处理策略。规则类型和策略是两件事，不能把 PROXY 当作一种域名匹配方式。
在 Config（配置文件）中选择当前使用的文件，检查其中的 Rule（规则）部分。规则通常自上而下匹配，先命中的条目决定请求去向。设置时先写范围较小的例外，再写覆盖范围较大的通用条目，最后安排 FINAL 作为未命中前序条件时的最终策略。编辑并保存之后，还要确认该文件已启用。
| 关键字 | 匹配对象或含义 | 检查重点 |
|---|---|---|
DOMAIN | 完整域名。 | 只写域名，不附带路径。 |
DOMAIN-SUFFIX | 指定域名及其子域名。 | 范围比单个完整域名更大。 |
DOMAIN-KEYWORD | 域名中包含的关键词。 | 短关键词容易扩大匹配范围。 |
IP-CIDR / IP-CIDR6 | IPv4 / IPv6 地址段。 | 地址段与掩码必须符合对应格式。 |
GEOIP | IP 地理归类。 | 归类结果不等于目标实际运营位置。 |
USER-AGENT | 可识别的 User-Agent 信息。 | 受请求信息可见性影响，不宜作唯一依据。 |
FINAL | 前序规则均未命中时的最终策略。 | 置于规则末尾，避免提前覆盖后续规则。 |
PROXY / DIRECT / REJECT | 代理处理 / 直接连接 / 拒绝请求。 | 属于策略，不属于匹配条件。 |
用最小规则片段理解顺序
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT此示例仅用于说明语法。访问 account.example.com 时，第一条先命中并采用 DIRECT；其他属于 example.com 的域名由第二条匹配；其余请求进入 FINAL。如果将第二条移到第一条之前，原本的精确域名例外就会被更早命中的后缀规则覆盖。示例不是适合所有网络的完整配置。
发现分流结果不符时，先检查 Global Routing 是否为 Config，再检查命中的规则及其策略。不要在尚未确认匹配结果时同时调整 DNS、服务器和规则顺序。更完整的配置结构、地址段写法与优先级说明见配置字段参考。
订阅与服务器管理
Subscribe 管理一组可更新的服务器信息；单独添加服务器则逐项保存连接参数。两者都不能代替分流规则配置。
Subscribe：导入已有订阅
在 Home 进入 Add Server（添加服务器），选择 Subscribe（订阅）类型，并将从你的服务商处取得的已有订阅地址填入对应字段。保存后执行更新，检查服务器条目是否出现，再选择需要使用的一项。订阅地址可能包含访问凭据，应按敏感信息保存，不要把完整地址放进公开截图或求助内容。
订阅更新成功只说明内容已取得并被处理，不代表其中每台服务器都可用。更新后要核对所选条目是否仍存在、名称是否改变，以及连接参数是否符合原有用途。订阅维护的条目可能在下次更新时被重建，临时手工修改不应作为长期保存参数的唯一方式；有需要时先保留自己的配置记录。
Add Server：逐项填写服务器信息
手工添加时，在 Add Server 中先选择正确的协议类型，再填写地址、端口与认证信息。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 等协议使用的字段不同，不能把一类协议的参数直接填进另一类表单。涉及 TLS、传输方式或公钥等项目时，应按已有服务器资料逐项核对，不凭服务器名称推断。
保存前可用备注区分用途，但备注本身不会改变请求路径。保存后先选中该服务器，再执行 Connectivity Test（连通性测试）并进行实际访问验证。若列表中保留多条相似记录，应核对地址和协议而不只看名称，避免误选过期条目。
Connectivity Test 与 Test Method 的边界
Connectivity Test 用于观察指定测试条件下的结果。其测试方式由 Test Method 等设置影响，测试值不等于所有目标的访问耗时，也不代表实际传输速率。出现测试成功但访问失败时，应继续检查规则、DNS、认证和目标本身；出现测试失败时，也要先确认测试目标与方法是否适合当前网络。
On Demand：按网络条件建立连接
On Demand（按需连接）管理连接何时被触发；Global Routing 与 Config 管理连接建立后如何处理请求。
在 Settings（设置）中找到 On Demand，先阅读当前列出的触发条件和例外，再根据使用场景启用或调整。可设置的网络条件以应用内实际选项为准。首次设置时，先使用简单条件验证，再逐项加入网络例外；这样在连接行为不符合预期时，能够知道是哪一项条件产生影响。
例如，需要在某些网络环境下自动建立连接时，应先确认普通手动连接能够正常工作，再启用对应的按需条件。随后切换一次符合条件的网络，并查看系统连接状态与应用内状态。不要直接把 On Demand 当作修复不可用服务器的方法：它不会补齐错误的密码、证书或规则。
如果手动断开后连接又被建立，先查看 On Demand 是否仍处于启用状态，以及当前网络是否满足触发条件。需要暂停自动行为时，应先调整按需设置，再检查连接开关。仅把 Global Routing 改为 Direct，不表示自动连接条件已经停用。
Data：流量统计与读数核对
Data（流量统计）用于查看客户端记录的传输量，不是服务商账单，也不能单独用来判断规则是否正确。
进入 Data，先确认当前显示的统计分类、累计范围和上传、下载方向，再观察对应服务器的变化。若当前界面提供按应用分类，可切换分类查看；应用识别与归类受系统和请求信息影响，不能把未归类部分直接理解为异常连接。需要比较两次操作时，应保持同一分类和同一观察区间。
测试某个目标是否产生流量时，可以先记录初始读数，再进行一次明确操作，等待界面刷新后比较增量。后台同步、媒体预加载和其他应用活动也会产生传输，不能把整个增量都归到刚打开的页面。需要重置统计时，先保存需要的读数，再使用应用提供的重置入口，并核对确认提示所覆盖的范围。
客户端与服务商的读数可能因统计起止时间、连接开销、计量单位和计费口径不同而不一致。客户端重置不会替服务商重置用量，服务商开始新的计费周期也不必然清空 Data。判断剩余用量应依据自己的服务商记录；排查传输行为则结合客户端连接记录。详细读数说明见Data 流量统计笔记。
Settings：常用项目与修改边界
Settings 不是所有设置的唯一来源。DNS 等项目还可能受当前 Config 影响，修改前要先确认实际生效的配置。
DNS：解析与连接路径一起检查
DNS（域名解析）负责把域名转换为连接使用的地址。在 Settings 的相关项目以及当前 Config 中核对 DNS 设置，先确认是否存在配置文件指定的解析项，再决定修改哪一处。不要只因某个域名无法打开就连续替换多个解析地址；应先验证服务器连接，再查看解析是否成功、解析结果是否符合预期。
设置解析服务时，应使用自己确认可达且符合使用需求的配置，并保留原值。解析请求的路径与最终连接策略并非同一概念，域名能够解析也不等于目标连接成功。改动后应使用新的请求验证，必要时重新建立连接，避免缓存与既有连接影响观察结果。具体参数含义可继续查阅配置字段。
Test Method：统一测试条件
Test Method（测试方式）用于选择服务器测试采用的方法，在 Settings 中进入对应项目，按当前界面提供的选项设置。比较多个服务器时，应保持同一种方法及相同测试目标；改变测试方法后，原有结果不再适合直接横向比较。测试显示的是特定条件下的表现，不应把一个数值解释为连接质量的完整结论。
如果测试结果与实际访问不一致，记录方法、测试目标和当前 Global Routing，再做一次实际请求验证。不要为了得到更小的测试值而反复改变条件，这会丢失排查依据。测试只是诊断的一步，认证、规则和 DNS 仍需分别核对。
Today Widget：便捷入口
Today Widget（今日视图组件）用于提供便捷操作或状态查看。在 Settings 核对相关选项，并根据系统提供的编辑入口添加可用组件；具体展示形式与可用性以当前系统和应用内说明为准。添加之后先确认它对应的是当前使用的配置或服务器，不要只凭组件显示就认定目标已经连通。
从组件触发连接后，如果状态没有及时刷新，应回到应用检查实际状态。On Demand 仍可能按条件重新建立连接，因此组件上的一次断开操作不一定等同于长期停用自动连接。涉及网络行为的判断，仍以应用状态和实际请求验证为准。
iCloud：同步与独立备份
iCloud 同步用于在相应账户和系统条件下同步应用支持的数据。在 Settings 查看 iCloud 相关开关及应用内说明，并在系统设置中确认 iCloud 可用。启用前先整理当前配置，启用后在另一台设备检查实际出现的内容；不要假定所有服务器、订阅、规则和本地统计都会按同样方式同步。
同步不等于保留历史版本。删除或误改也可能传播到其他设备，重要 Config 应另行导出并妥善保存。配置中若含订阅地址或认证信息，备份文件同样需要保护。换机时先确认应用获取、同步和配置恢复分别完成，再建立连接，避免在未检查内容时直接覆盖原有配置。
Diagnostics：一次只验证一个假设
Diagnostics（诊断）用于收集或观察连接问题的相关信息。在 Settings 中进入对应入口，按当前可用工具检查网络、解析或连接情况。先写清复现条件，例如“同一服务器、Config 模式、访问某个域名失败”，再运行相关测试；一次更换服务器、DNS 和规则会让结果失去对照。
需要保存诊断结果时，只保留与问题相关的片段，检查其中是否包含订阅凭据、认证信息、访问记录或个人地址。向他人描述问题时可用域名和字段名说明现象，不应公开完整敏感内容。诊断结束后，将临时调整恢复到原有设置，并重新验证日常访问。
修改后的检查顺序
按固定顺序复查，比同时切换多个选项更容易判断原因。先证明基础连接可用，再核对规则与自动行为。
- 确认输入资料。核对已有订阅是否成功更新，或手工服务器的协议、地址、端口与认证字段是否一致。不要用备注名称代替参数检查。
- 确认模式与文件。在 Home 查看 Global Routing，在 Config 确认启用的文件。修改了某份配置，不代表它已成为当前生效文件。
- 发起新的测试请求。使用 Connectivity Test 辅助观察，再验证实际目标。记录测试方式与结果，避免既有连接干扰判断。
- 核对命中策略。检查请求对应的规则和最终策略，区分 DIRECT、PROXY 与 REJECT。若只有一个域名异常，优先检查精确规则和解析结果。
- 最后检查自动与统计项。基础访问正常后，再验证 On Demand 的触发条件、Data 的统计范围，以及 iCloud 的同步结果。
需要回退时，恢复本次改动的原值，而不是重新导入多份来源不明的配置。保留一份已验证可用的 Config 和简短修改记录，可以减少重复排查。对于界面入口、首次授权或购买恢复的问题，可从下列官方手册章节继续阅读。