Shadowrocket 功能与设置

Global Routing 决定请求采用哪一类路由逻辑，通常从 Home 中进入。它与当前选中的服务器不是同一个设置：选好服务器，并不表示所有请求都会使用该服务器；能否进入代理路径，还要看当前模式和规则命中结果。日常按规则分流时使用 Config，核对所选服务器的基本访问能力时可临时使用 Proxy，需要检查当前网络的直接访问情况时可使用 Direct。

配置时先记录原模式，再选择本次需要的模式，回到 Home 确认服务器与连接开关。测试结束后恢复预期设置。模式切换影响的是之后的请求，已有连接可能仍维持原先状态；验证时重新发起请求，必要时重新建立连接，不要只观察一个一直打开的页面。

规则描述“匹配什么”，策略描述“匹配后如何处理”。在 Config 中选中需要使用的配置文件，再查看或编辑其中的规则。一般按自上而下的顺序匹配，命中第一条适用规则后使用其策略；FINAL 为此前未命中的请求指定最终处理方式。因此，精确规则通常应放在更宽泛的规则之前，不能只看文件里是否出现了某个域名。

常见规则类型

DOMAIN 匹配完整域名；DOMAIN-SUFFIX 匹配指定域名及其子域名；DOMAIN-KEYWORD 按域名中的关键词匹配。IP-CIDR 与 IP-CIDR6 分别描述 IPv4、IPv6 地址网段，GEOIP 根据地址归属信息匹配。USER-AGENT 依赖请求中可获得的相应信息，不能视为适用于所有加密流量的通用条件。

PROXY、DIRECT 与 REJECT

PROXY 指向代理处理，DIRECT 指向直接连接，REJECT 用于拒绝匹配请求。配置也可能引用命名策略或策略组，此时还要确认目标存在、名称一致且当前选择符合预期。界面里的 Proxy 是模式名称，规则里的 PROXY 是策略关键字，编辑时保留各自原有写法。

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

以上是规则顺序示例，不是可直接覆盖日常配置的完整文件。这里的 DOMAIN-KEYWORD,ads 只是演示关键词匹配，可能覆盖并非预期的域名；修改前应检查匹配范围。保留原配置副本，每次只改一类规则，再用新的请求验证，避免同时改动规则、DNS 和服务器后无法定位原因。

服务器记录保存连接地址、端口、协议及认证等参数；订阅则用于集中维护一组记录。以下操作以用户已有自己的订阅或服务器信息为前提。Home 用于查看、选择和管理服务器，Add Server 用于添加记录，Scan QR Code 可识别受支持的二维码内容。导入前先判断内容是订阅链接、单服务器 URI，还是包含规则的配置文件，三者不能仅凭链接外观互相替代。

手动添加时先核对 Type，再逐项填写地址、端口及协议所需参数。例如 Shadowsocks、VMess、VLESS、Trojan 对认证和传输设置的要求不同；HTTP、SOCKS5 等类型也需要与服务信息一致。不要根据名称猜测参数，不要为了让保存成功而随意删掉 TLS、传输或证书相关字段。

Subscribe 与配置文件的区别

Config 页面中的 Subscribe 用于相应配置订阅操作；管理服务器订阅时，应使用用于服务器订阅的导入入口或受支持的导入方式。以导入后的内容判断结果：服务器记录应在 Home 中可见，规则配置应在 Config 中可见并按需启用。若出现解析失败，先核对输入类型和链接完整性，不要反复将同一内容导入不同位置。

订阅刷新主要更新来源提供的记录，不代表当前配置规则也随之调整。更新后检查当前选中的服务器是否仍存在，是否出现重复记录，以及自定义备注能否继续辨认。删除旧订阅前先确认归属，避免误删仍在使用的手动记录。含认证信息的订阅链接、二维码和服务器详情应按敏感信息保管，不应粘贴到公开讨论中。

On Demand 用于根据设定条件触发连接行为，不负责选择具体规则策略，也不替代服务器可用性检查。从 Settings 中查找 On Demand 相关选项，结合实际界面查看可用的网络条件。配置前先用手动连接验证服务器和规则正常，再增加自动触发条件，这样出现问题时能够区分是服务本身不可用，还是连接条件未满足。

设置时明确需要在哪些 Wi-Fi 或蜂窝网络环境下连接，逐项检查条件、适用范围及保存结果。完成后分别在目标网络与另一种网络环境中重新测试，观察系统连接状态是否符合预期。iPhone 与 iPad 的网络能力可能不同，应按设备实际可用选项设置，不要把另一台设备的条件原样照搬。

启用 On Demand 后，手动断开并不一定意味着之后持续保持断开；系统再次满足条件时可能重新触发连接。需要临时停止自动连接时，先检查 On Demand，而不是反复操作 Home 开关。耗电也不能只归因于这个选项，还应结合实际流量、服务器重连、信号状况和后台活动判断。修改规则或排查连接故障期间，可以先停用自动触发，完成验证后再恢复。

Data 用于查看客户端记录的流量信息。进入 Data 后，先辨认页面所显示的统计范围和计数口径，再观察发送、接收等记录。统计值适合辅助确认连接后是否有数据传输，但不能单独证明某个请求已经走了预期策略；需要判断具体访问路径时，应结合规则命中信息或可用的连接记录。

验证时可以先记下当前读数，发起一次明确的访问，再返回查看变化。后台应用、系统服务以及已有连接都可能产生流量，因此不要把短时间内的全部增量等同于刚打开的一个网页。若准备清空计数，先保存必要记录，并确认重置影响的范围；不同统计周期的数值不适合直接相减比较。

Data 不是服务端账户余额，也不等于运营商计费账单。服务端统计可能包含不同的计费方式、时间范围或额外开销，数值不一致时应先对齐统计口径。遇到“连接状态正常但没有预期流量”，依次检查当前服务器、Global Routing、目标请求是否重新发起，以及是否因命中 DIRECT 而没有使用代理路径。

Settings 集中提供应用行为与工具相关选项。调整前先确认当前配置文件是否也定义了相关参数，避免仅修改全局设置，却忽略正在使用的配置内容。下列项目按用途说明，具体分组位置与可选值以设备上的界面为准；每次修改后保存并验证，保留可回退的原值。

DNS：域名解析

DNS 负责将域名解析为可连接的地址。可从 Settings 的 DNS 相关入口核对解析设置，同时检查 Config 中当前配置的 DNS 内容。排查时先区分“域名解析失败”与“得到地址后连接失败”：若服务器使用域名，其自身解析也可能影响连接建立。填写自定义解析地址前确认格式、可达性与使用场景，不要把更换 DNS 当作所有故障的统一处理方法。

涉及 IPv6、局域网域名或不同网络环境时，还应检查解析结果是否适合当前网络。改变 DNS 后重新发起请求，必要时重新连接，并留意缓存影响。不要通过关闭证书验证来代替解析排查；证书错误、域名错误和路由错误需要分别处理。

Test Method：连通性测试方式

Test Method 用于选择连通性测试采用的方法，可在 Settings 中查看。设置后回到 Home 使用 Connectivity Test，结合本次方法理解测试结果。不同方法验证的环节不同，耗时数值也不宜跨方法直接比较；测试目标、当前网络与服务器状态都会影响表现。

某次测试成功，只说明该测试条件下的对应链路可用，不代表所有目标站点、DNS 与规则都正确。测试失败时先确认所选方法及测试目标适用，再检查服务器参数和网络状态。为了便于比较，应在同一网络、同一方法下测试，不要在连续修改多个设置后只保留最后一次结果。

Today Widget：快捷查看与操作

Today Widget 的相关设置用于管理系统组件可展示或可操作的内容。先在 Settings 中查看对应选项，再到系统允许添加组件的位置完成配置；是否可添加、显示样式与刷新行为取决于系统和设备实际支持情况。组件适合日常快捷操作，完整配置仍应回到应用内完成。

组件显示可能受系统刷新节奏影响，不能仅凭组件中的旧状态判断当前连接。发生状态不一致时，打开 Home 核对连接与服务器；锁定屏幕上可见的内容也应按个人隐私需求选择。

iCloud：同步与换机准备

在 Settings 中查看 iCloud 相关选项，并结合系统中的 iCloud 权限确认是否允许应用使用相应能力。同步前核对当前界面明确列出的同步对象；不要默认服务器、配置、全部设置与使用记录都会同时同步。更换设备前，先检查重要内容是否确实出现在目标设备上，并保存必要备份。

iCloud 同步与 App Store 已购恢复是两件事：前者涉及应用内容，后者用于恢复应用获取资格。换机后仍需检查服务信息、启用的配置及系统连接授权。关于购买记录与恢复顺序，可继续查看已购恢复说明。

Diagnostics 提供辅助定位问题的诊断入口，可在 Settings 中查找。使用前先记录问题发生的网络环境、当前服务器、Global Routing 与配置名称，再运行实际可用的检查。诊断输出用于缩小范围，不是自动修复的保证；应把结果与真实访问现象对应起来，而不是仅凭一行提示判断所有设置正常。

可按下面的顺序建立最小验证链。每一步只改变一个因素，并保留前后结果。若临时切换 Proxy 后可以访问，而 Config 下失败，优先检查规则、策略目标和配置内容；若两者都失败，则进一步核对服务器信息、解析和当前网络。Direct 的结果只反映直接访问条件，不能据此推断代理服务器一定正常。

1. 核对基础状态。确认当前网络能正常建立连接，系统授权已完成，Home 选中的是预期服务器。
2. 验证服务器。在一致的 Test Method 下运行 Connectivity Test，核对地址、端口、认证与协议参数。
3. 检查路由。确认 Global Routing，检查 Config 中启用的文件、规则先后顺序和 FINAL 指向。
4. 检查 DNS。区分解析失败与连接失败，记录当前解析设置，再按需要做单项调整。
5. 重新发起访问。结合 Data 与可用记录观察结果，排除旧连接和缓存造成的误判。

对外提交诊断信息前，检查其中是否包含订阅地址、认证字段、服务器详情或访问记录，先移除敏感内容。描述故障时保留“操作前提、执行步骤、实际结果、预期结果”，比只写“无法连接”更容易复现和定位。