Shadowrocket 使用说明
订阅导入与连接检查
以 iPhone / iPad 界面为例，按添加资料、选择模式、打开连接、验证请求、检查失败点的顺序操作。先让一条连接可验证，再调整规则。
建议先保留现有配置，不急着批量修改。准备好一条常用页面地址作为验证目标；遇到问题时，记录停在哪一步以及对应提示，比反复重装更容易定位原因。不同版本的布局可能略有变化，请按英文界面词寻找相应入口。
Add Server：添加服务器或导入 Subscribe
先辨认拿到的资料类型。订阅链接、单个服务器参数和配置文件不是同一种输入。
打开 Shadowrocket，在 Home 下方找到 SERVER 分组，点击 Add Server。进入添加页面后先看 Type：它决定后面需要填写哪些字段。右侧官方截图展示的是一种服务器类型，切换 Type 后出现不同字段属于正常情况，不应把截图中的字段组合当成所有协议通用的填写表。
已有订阅链接：选择 Subscribe
如果资料是一条订阅地址，在 Type 中选择 Subscribe，将完整地址粘贴到 URL 字段，并填写便于辨认的备注。粘贴后从头到尾检查一次：开头的协议、路径、问号后的参数都应保留，不能把换行、引号或说明文字一并带入。示例 https://example.com/sub?token=xxxx 只用于说明结构，不是真实订阅，也不需要打开。
保存后返回 Home，等待订阅获取完成，再检查分组中是否出现服务器条目。保存成功只表示应用记住了地址，不代表远端内容已经下载成功；若分组为空，应先检查订阅获取提示，再核对地址是否过期、是否要求额外认证，以及当前网络能否访问该地址。不要用另一个普通网页地址替换订阅来试，因为网页内容并不等于服务器列表。
已有单个服务器：按 Type 逐项填写
如果拿到的是单个服务器信息，先选择与资料一致的协议，例如 Shadowsocks 或 Trojan，再填写 Host 和 Port。Host 通常只填主机名或 IP，不附加网页路径；Port 填资料中的端口。随后核对该类型要求的 Password、Method、UUID 或 TLS 相关字段：有些字段只属于特定协议，不能因为名称相似就互相替代。
手动输入容易把空格或换行带进密码，复制后应核对首尾。若资料带二维码，可在 Scan QR Code 入口扫描，按系统提示允许使用相机，然后检查解析出的 Type、Host 和 Port 再保存。Import from Cloud JSON 只在已有资料确实采用对应格式时使用，不要把任意订阅或普通文本放进去。
添加完成后，回到 SERVER 分组点选准备使用的服务器，确认选择标记落在目标条目上。此时只完成了资料准备，还没有确认系统连接与规则生效。若订阅含多个条目，先选一个做后续验证；先保持选择不变，下一步再决定请求采用哪种 Global Routing 模式。
Global Routing：配置(Config) / 代理(Proxy) / 直连(Direct)
服务器决定连接参数，Global Routing 决定请求采用什么处理方式。
回到 Home，点击 Global Routing 查看当前模式。首次使用最容易混淆的是把“已经选中服务器”理解为“所有请求都会使用它”。实际上，Global Routing 的选择以及当前配置中的规则共同决定请求路径。先明确本次要验证服务器本身，还是要验证一套已有分流配置，再做选择。
配置(Config)：按当前配置的 Rule 处理
选择配置(Config)后，请求依次匹配当前配置中的规则，并使用命中规则指定的策略。进入 Config，核对实际启用的配置文件，再打开其编辑页查看 Rule。截图中的 General、Rule、Hosts、URL Rewrite 与 HTTPS Decryption 是不同设置分段；初次连接只需确认相关规则和策略是否存在，不必逐段开启或修改。
例如 DOMAIN-SUFFIX,example.com,PROXY 表示匹配指定域名后缀的请求采用名为 PROXY 的策略。这里的策略名必须能在当前配置中解析到有效目标；规则文字存在，并不自动证明策略引用正确。规则通常按顺序检查，因此更具体的匹配要放在合适位置，并核对末尾的 FINAL 兜底。通过 Add Rule 修改前，建议先保留原配置副本。
代理(Proxy)：临时缩小检查范围
需要先验证所选服务器能否处理请求时，可以临时选择代理(Proxy)，减少分流规则对判断的干扰。这里的 Proxy 是 Global Routing 模式，规则文本中的 PROXY 则是策略名称，两者不要混为一谈。Proxy 下仍受系统路由、应用行为和现有设置影响，不能据此认定设备上的每一种流量都必然走同一路径。
直连(Direct)：不交给代理服务器处理
直连(Direct)用于直接连接目标，不会因为 SERVER 中有选中的服务器就自动改用它。若当前目的是测试代理服务器，应检查是否误选了 Direct；若正在比较设备基础网络，则可以用 Direct 作对照。基础网络无法访问的目标，也不能仅靠切换 Direct 得出服务器故障的结论。
本轮操作先记下选定模式。已有可信且理解用途的配置，可从 Config 开始；尚未理解配置时，可先用 Proxy 验证服务器，再恢复 Config 检查分流。复杂的规则顺序、协议字段与选型解释放在技术参考，这里暂不扩展修改范围，避免首次连接同时引入多个未知变量。
Home：打开连接开关并允许系统配置
先确认选择，再开启连接。系统授权完成与远端服务器可用是两件事。
完成前两步后回到 Home，依次检查 SERVER 中的目标服务器、Global Routing 中的模式，以及 Config 中正在使用的配置。检查时尽量不要同时更新订阅和切换多个服务器，否则稍后即使连接恢复，也难以知道是哪项变化起了作用。若设备当前有其他活动的 VPN 连接，先退出该连接，再测试 Shadowrocket。
点击 Home 顶部的连接开关。首次建立系统配置时，iPhone / iPad 可能显示添加 VPN 配置的授权提示；阅读提示，确认是刚才主动发起的操作后允许，并按系统要求完成设备认证。这里需要的是系统对本机网络配置的授权，不是订阅密码，也不需要把设备认证信息填写进 Add Server。
授权后返回 Shadowrocket，观察顶部原先的 Not Connected 状态是否改变，以及开关能否保持开启。官方截图展示的是尚未连接的 Home，因此不要把图中的状态当作完成标准。状态变化只说明本机连接流程推进了，仍需下一步用真实请求核对远端链路与规则处理结果。
如果刚开启就自动关闭，先留意是否出现权限提示、系统配置错误或应用内错误记录。若此前拒绝过授权，可以重新发起连接并查看系统提示；若设备受组织管理，相关权限可能由管理策略限制，应由设备管理员确认，不要随意删除不认识的管理配置。重复点击开关不会修复缺失参数，反而可能让提示和记录更难对应。
测试期间可以暂不启用 On Demand，让每次开关变化都来自明确的手动操作。否则系统在满足条件时重新连接，容易被误认为开关失效。先保持应用在前台完成一次基本验证，再观察切换到浏览器、锁屏或更换网络后的表现；不要把所有场景放到首次测试里一起判断。
至此，资料已经保存、模式已经选择、系统连接已经发起。接下来请保持服务器和模式不变，完成 Connectivity Test 与页面请求检查。只有当这些结果能对应起来，才适合继续调整日常分流或按需连接设置。
Connectivity Test：从测试结果核对到真实请求
在 Home 使用 Connectivity Test 检查服务器。测试结果受所选测试方法、测试目标与当前网络影响，因此应把它视作排错线索，而不是对所有网站和应用的可用性保证。测试失败时先记录目标服务器和错误表现，不必立即删除条目；测试成功后也需要继续发起一次实际请求。
先请求，再核对记录
打开浏览器，访问一个自己熟悉且正常提供服务的页面，等待新请求完成。尽量避免只看已经缓存的页面，也不要仅凭某个应用显示的旧内容判断连接成功。如果页面没有变化，可刷新或重新打开页面，再回到 Shadowrocket 查看 Data 或当前版本提供的连接记录。
核对记录时，重点看这次请求的目标、处理策略与时间是否对应刚才的操作。Config 模式下尤其要检查命中的 Rule，以及最终是 DIRECT、PROXY 还是其他已定义策略；DIRECT 是合法的分流结果，并不必然表示连接失效。反过来，看到代理策略名称也不等于远端已经成功返回内容，还需要结合错误记录和实际响应。
用模式对照区分问题位置
如果 Proxy 下实际请求成功，而 Config 下同一个新请求失败，先检查当前配置中的匹配规则、策略引用及 DNS 相关设置，不要优先重填已验证过的服务器密码。如果两种模式都失败，再回到服务器参数与基础网络检查。对照时只改变 Global Routing，保持服务器、目标页面和网络不变，测试后恢复需要使用的模式。
有些请求会涉及多个域名，页面主体能打开但图片、登录或视频失败时，应查看失败资源对应的连接，而不是只检查地址栏中的域名。应用缓存、已有长连接和系统网络设置也会影响结果；改规则后应发起新请求再观察。若记录与预期不一致，先把目标和命中策略整理出来，再阅读问答中的规则与故障排查说明。
Settings：按失败阶段检查，而不是重新开始
先找出最后一个正常步骤，再检查紧接其后的输入、权限或请求。
导入失败：检查输入与内容格式
Subscribe 无法获取内容时，先核对完整 URL、有效期与认证条件；能获取但没有条目时，再检查返回内容是否属于支持的订阅格式。手动添加失败则回到 Add Server，对照原资料检查 Type 和必填字段。二维码扫描成功只代表解析出了内容，保存前仍应核对参数。不要公开粘贴完整订阅来请求帮助，链接中的参数可能直接代表访问权限。
服务器测试失败：检查参数与网络
进入 Settings 查看 Test Method，确认当前测试针对什么目标、使用什么方式。单一测试超时并不能覆盖所有实际请求情况，应结合上一节的页面验证。然后核对 Host、Port、认证字段和设备时间；涉及 TLS 时，继续检查资料要求的服务器名称与证书条件，不要用关闭证书检查的方式掩盖名称或时间错误。
可以在保留原设置的前提下，分别在 Wi-Fi 与蜂窝网络发起相同请求，观察问题是否只出现在一种基础网络中。每次切换后等待系统网络稳定再测试，避免把网络切换瞬间的超时误判为服务器持续故障。若多个条目都异常，先检查设备本身是否能正常访问已知可用的直接连接目标。
开关异常或部分请求失败：查看 Diagnostics
如果连接开关无法保持开启，回到系统权限与 VPN 配置检查；如果开关正常但部分请求失败，在 Settings 中找到 Diagnostics，按当前版本提供的记录查看具体错误。截图中的 Proxy、TCP 与 UDP 是不同设置入口，不应把这些入口视为必须全部修改的清单。先读错误，再决定是否需要进入对应分项。
整理问题时记录：使用的 Global Routing、失败发生在哪一步、是否仅影响特定目标、切换基础网络后是否变化。分享记录前遮盖订阅地址、密码、密钥与个人网络信息。若需要查看协议参数含义，前往技术参考；若是导入、权限或规则顺序的常见问题，先查问答，无需把本页操作全部再做一遍。
基本验证通过后，再配置 On Demand
确认手动连接稳定后，再进入 On Demand 设置需要的触发条件。它管理的是满足条件时是否发起连接，不替代 Global Routing 的分流规则，也不会补齐失效服务器的参数。启用后分别检查连接目标网络、离开该网络与手动关闭时的行为；如果结果与预期不同，先停用 On Demand 回到手动测试，再单独调整触发条件。
最后恢复日常需要的模式并保留一份已经验证可用的配置。后续更新订阅或修改规则时，每次只调整一个类别，使用相同页面复测。这样出现变化时可以回到最近的正常状态，而不是重新猜测全部参数。
