Shadowrocket 使用说明
按添加、模式、连接、验证、排查五步操作。先完成一次可复现的连接，再逐步调整规则与自动连接设置。
截图为 App Store 官方展示图，用于辨认页面与字段，不是需要照抄的配置。实际入口与字段以设备上当前应用显示为准。
Add Server：添加服务器或导入已有订阅
先判断手中的资料属于单条服务器信息，还是会返回服务器列表的订阅链接。两者都从添加入口开始，但选择的 Type 不同。
已有服务器信息：按实际协议填写
在 Home 下方找到 Add Server，点开后先查看 Type。将 Type 设为资料中明确写出的协议，再核对 Host、Port 以及该协议要求的认证字段。不要因为某几个字段看起来相似就选择另一种类型；协议不一致时，即使能保存，也不代表可以完成连接。
以 Shadowsocks 为例，Host 填服务器地址，Port 填端口，Password 与 Method 应与服务器端完全一致。其他协议可能使用不同的认证方式，或需要 TLS、传输方式等额外参数，应逐项依照已有信息填写。Host 一般只填主机名或地址，不要把整条订阅链接塞进 Host，也不要擅自补上路径。
填写后使用页面的保存操作，返回 Home，在 SERVER 列表确认新增条目存在。名称只是帮助辨认的备注，不能代替地址与端口。若准备添加多条记录，建议使用能区分用途的备注，避免后续测试时选错条目。
已有订阅链接：选择 Subscribe
在 Add Server 的 Type 中选择 Subscribe，进入对应页面后，将你已有的完整订阅链接填入 URL，并设置便于识别的备注后保存。链接中的路径和查询参数可能用于识别订阅，复制时要保留完整内容，尤其检查末尾是否被截断、是否带入空格或换行。
返回 Home 后，检查相应订阅分组是否加载出服务器条目。如果未出现列表，先查看是否有更新失败提示，再通过该订阅分组的更新操作重试。订阅能成功读取，只说明列表已获取；其中每条服务器是否可用，还要在后续测试中确认。订阅更新也不等于替换 Config 中启用的规则文件。
单条分享链接或二维码应使用应用支持的相应导入操作；Scan QR Code 用于扫描已有二维码，Import from Cloud JSON 用于对应的 Cloud JSON 资料，不是任意订阅的通用入口。导入完成后仍应打开条目核对 Type 和主要参数，再进入下一步选择路由姿态。
Global Routing：选择配置、代理或直连
Global Routing 决定请求按什么方式处理，不负责补齐服务器信息。先理解当前姿态，再打开连接。
在 Home 点开 Global Routing，核对当前选项。三种基本姿态写作配置(Config)/代理(Proxy)/直连(Direct)。选择后返回 Home，确认 Global Routing 旁显示的是预期值；不要只记住上一次使用的模式，因为排查过程中可能已经改动。
配置(Config)：按当前配置决定路径
Config 适合需要规则分流的使用方式。它根据当前启用配置中的 Rule 等设置决定请求使用 PROXY、DIRECT 或其他已定义策略。要使用这一姿态，先进入底部 Config 页面，确认正在使用哪份配置，再查看其中的 Rule；仅在 Home 导入订阅，并不能说明规则已经按预期设置。
官方截图中的 Config 编辑页包含 General、Rule、Hosts、URL Rewrite、HTTPS Decryption 等分段。首次上手只需确认当前配置和 Rule，不必为完成连接而修改所有分段。Add Rule 是增加规则的入口；在不清楚匹配对象和策略含义时，先保留原配置，避免将导入问题与规则问题混在一起。
代理(Proxy)：作为短时对照
Proxy 将一般请求交由所选代理路径处理，适合在排查时与 Config 做短时对照。如果 Proxy 下可以访问，而 Config 下同一目标失败，应优先检查配置中的规则命中和相关设置，而不是立即重建服务器。它不是对所有系统流量或所有应用行为的绝对保证，测试结束后应恢复符合实际需求的姿态。
直连(Direct)：区分基础网络与代理路径
Direct 用于直接连接目标，不是更换服务器的按钮。若目的是测试所选服务器，不能停留在 Direct 后再据此判断服务器有效。它更适合帮助区分基础网络问题与代理路径问题。完成姿态选择后，下一步回到 Home 选中服务器并启动连接。
规则关键字、协议参数与性能取舍不必在首次连接时全部掌握。需要核对所选 Type 的字段含义时，可阅读协议参考；路由与 On Demand 的区别可查看设置说明。
Home：选中服务器并打开连接
列表中存在条目不等于已经使用该条目。先选择，再开启顶部开关，最后核对系统授权与连接状态。
返回 Home，在 SERVER 列表点选准备使用的服务器，确认选中标记落在目标条目上。若列表来自多个订阅分组，先核对分组名和备注，不要把列表排序变化误认为服务器已经切换。随后再次看一眼 Global Routing，确认它与上一步的选择一致。
打开 Home 顶部连接开关。未连接时页面可见 Not Connected；开启后应等待状态变化，不要连续快速开关。首次启动连接时，系统可能弹出添加 VPN 配置的提示。确认提示来自刚刚操作的 Shadowrocket 后，按系统提示允许，并按需完成设备验证，再返回应用观察状态。
VPN 配置授权用于让应用通过系统网络扩展处理流量，不是订阅登录，也不会替你生成服务器。若取消了授权，应回到应用重新尝试连接并处理提示。设备由组织管理、受系统限制或存在其他 VPN 配置时，还需先确认设备策略是否允许建立这类连接；不要通过反复删除配置来盲目尝试。
连接状态发生变化只表明连接流程已推进，不能单独证明远端服务器可用或所有请求都按预期分流。保留当前服务器和姿态，继续完成下一步测试。若开关立即回落或出现错误，记下错误原文与发生环节，再跳到失败点排查，避免同时修改多处设置后无法还原。
Connectivity Test：验证连接与实际访问
验证分两层：服务器测试提供线索，实际请求确认使用效果。两层结果应一起看。
在 Home 点 Connectivity Test，等待列表中的测试结果更新。测试方法会影响结果的含义，可在 Settings → Test Method 核对当前方法。某一条记录出现结果，只能说明对应方法在当时完成了测试；超时也未必等于该服务器在所有用途下都不可用，需要结合实际请求进一步判断。
接着保持连接，在浏览器打开一个你日常可用于核对的网页，先确认页面能完成加载，再检查原本需要验证的目标。尽量使用新的请求，避免只看已经缓存的页面。若只有某个应用异常，而浏览器可访问，不要直接推断整个连接失败，应记录该应用与目标的差异。
需要核对规则分流时，在相同网络、相同服务器和相同目标下，对照 Config 与 Proxy 的表现，每次只改变 Global Routing。若两个姿态结果不同，再回到 Config 查看 Rule 与相关设置。规则通常按顺序匹配，较早命中的条目可能决定后续路径；仅看到文件中存在某条规则，并不能证明实际请求命中了它。
Data 中的流量变化可作为请求活动的辅助线索，但不能单凭累计流量判断某个网页走了哪条路径。完成验证后，恢复准备长期使用的姿态，记录所选服务器、配置名称和测试目标。以后出现异常时，用这一组固定条件重测，比不断更换条目更容易定位变化来自哪里。
Settings：按顺序排查常见失败点
从基础网络开始，再查服务器、模式、DNS 与规则。一次只改一项，修改前保留原值。
第一层：先区分网络、订阅与服务器
暂时关闭 Shadowrocket 连接，确认设备的基础网络能正常使用，尤其检查当前 Wi-Fi 是否需要先完成网络登录。基础网络本身不可用时，先处理这一层；更改代理协议或规则不能修复尚未建立的网络连接。
若订阅没有加载出条目，回到订阅记录核对 URL 完整性和更新提示，检查链接是否仍有效。若已有条目但连接失败，则打开该服务器核对 Type、Host、Port 与认证字段，并检查订阅中的信息是否已发生变更。先确认自己的资料仍有效，再决定是否更新订阅；不应把每次失败都当作需要重新导入。
第二层：对照姿态，再查 DNS 与 Rule
确认 Home → Global Routing 没有误选 Direct，并确认当前服务器是刚刚核对的条目。使用 Proxy 做短时对照：若同一目标恢复访问，重点转向 Config；若仍失败，继续检查服务器参数、基础网络与目标本身。对照时不要同时切换网络和服务器，否则结果无法说明是哪一项产生影响。
域名访问失败时，DNS 是需要检查的环节之一，但不是唯一原因。先记录当前配置中的 DNS 设置和相关提示，再检查是否有输入错误或冲突。不要连续套用不明配置，也不要将任意固定地址作为所有网络的通用修复方案。若 Proxy 正常而 Config 异常，继续检查 Rule 的先后顺序、目标匹配范围和最终策略。
第三层：核对 On Demand 与 Diagnostics
如果表现为连接关闭后又自动开启，进入 Settings → On Demand 核对是否启用了触发条件。On Demand 控制何时建立连接，Global Routing 控制请求如何处理，两者不是同一个开关。首次排查时，先记录 On Demand 原设置，必要时暂时停用以减少变量，确认手动连接稳定后再恢复。
需要进一步诊断时查看 Settings → Diagnostics，保留错误原文、发生时间、网络类型与可复现步骤。不要为尝试修复而随意调整 Proxy、TCP、UDP 中不理解的选项。准备分享诊断资料前，应遮盖订阅 URL、服务器认证信息和其他敏感内容；保留协议类型与错误阶段通常已经能帮助判断方向。
如果问题仅发生在一种协议，转到协议参考核对该协议的必需字段与传输条件；如果需要重新梳理操作顺序，回到本页添加与导入步骤，从有效资料开始逐项复核。完成排查后恢复临时改动，避免把诊断用的 Proxy 姿态或关闭的自动连接条件长期遗忘。
