Shadowrocket 使用步骤

Add Server 与订阅导入

打开 Shadowrocket，先进入 Home。导入的目标是让自己的服务器信息出现在列表中，而不是立即打开连接开关。此时先判断手头资料的类型：订阅链接通常用来获取一组服务器条目；单个服务器资料则包含协议、地址、端口以及认证信息。两种方式任选其一即可，不必为了完成教程重复添加同一份资料。

已有订阅链接：使用 Subscribe

在 Home 点击右上角的添加按钮进入 Add Server，在 Type 中选择 Subscribe，将自己的完整订阅地址填入 URL。为便于以后辨认，可填写一个能说明用途的备注，再保存返回 Home。粘贴前后检查地址是否完整，尤其留意末尾是否缺少参数、前后是否带有空格，以及是否误把网页标题或说明文字一起复制进来。

保存后观察订阅分组及其中的服务器条目。订阅需要获取并解析远端内容，因此“订阅名称已经出现”和“服务器列表已经生成”不是同一个结果。如果只有分组却没有条目，先使用该订阅项提供的更新操作，等待当前请求结束，再确认列表。不要连续重复添加相同链接；这样只会产生难以区分的分组，不能解决地址失效或返回内容不符合预期的问题。

订阅地址可能携带个人访问凭据，应当按敏感资料保存。需要核对内容时，优先与自己的服务商确认地址是否仍有效、是否适用于 Shadowrocket，以及是否有额外使用条件。不要把完整地址贴到公开评论、截图说明或排查记录中；记录问题时只保留错误提示与出现位置即可。

已有单个服务器：核对 Type 与参数

若拿到的是单个服务器信息，同样从 Add Server 开始，但 Type 应选择资料指定的协议，例如 Shadowsocks、VMess、VLESS 或 Trojan。按页面显示填写地址、端口与对应认证信息。不同协议需要的字段并不相同，不能把某个协议的密码、UUID 或传输参数机械填到另一个协议的表单中。

遇到 TLS、Server Name 或其他传输设置时，以已有资料为准，不要根据服务器地址自行猜测。地址可能是域名，也可能是 IP；端口是独立字段，不应把整段说明文字一起粘贴进去。完成后保存，回到 Home 选中准备使用的条目。此时只确认条目存在、内容与原始资料一致；能否访问留到后面的连接验证环节。

打开连接开关

回到 Home，依次确认选中的服务器、Global Routing 姿态，以及使用 Config 时启用的配置文件。确认这些条件后，再打开主连接开关。不要在切换配置、订阅仍在更新、参数还没有保存时反复开关连接，否则很难判断当前测试到底使用了哪一组设置。

首次连接时，系统可能提示添加 VPN 配置。这是 Shadowrocket 接入系统网络处理所需的授权步骤，并不表示应用已经自动获得可用的连接服务。阅读弹窗后，若确认继续，按系统提示允许并完成设备要求的认证；随后返回 Shadowrocket 检查开关与应用显示的连接状态。

若当时取消了授权，先回到应用重新发起连接，按实际出现的提示处理。若设备受管理或系统设置限制，应核对相应限制，不要反复点击以替代确认。系统设置中的 VPN 项目名称和入口可能随系统界面变化，查找时以设备当前显示为准，不需要为了本教程修改与本次连接无关的设置。

连接建立后，系统可能显示 VPN 标识。这个标识说明系统网络连接状态，不等于远端服务器已通过实际访问验证，也不等于每条请求都走代理。尤其在 Config 或 Direct 下，仅看到 VPN 标识不能作为分流正确的证据。接下来保留当前设置，进入验证步骤，避免“开关已打开”就直接结束检查。

验证连接与规则

验证应拆成三个问题：服务器是否能响应测试、所需服务是否能正常使用、请求是否按预期策略处理。三个结果互有关联，却不能相互替代。按照下面的顺序检查，能避免把基础网络异常、目标服务异常和规则问题混在一起。

先运行 Connectivity Test

在 Home 使用 Connectivity Test，查看本次所选服务器的测试结果。它可帮助初步判断测试路径是否可达，但测试使用的目标和方式不等同于所有应用的真实业务请求。测试成功并不保证每个网站或应用都可用，测试失败也需要结合测试方式、当前网络和服务器资料继续检查。

记录结果时只需写明成功、失败或显示的错误，不必把一个测试耗时当成服务质量结论。若所有条目都失败，先确认设备基础网络能正常访问，再检查订阅与连接参数；若只有一个条目失败，则优先核对该条目的参数和对应服务器状态。

再检查实际访问

保持连接开启，打开浏览器访问自己确实需要使用的服务，观察页面是否能完成加载及必要操作。尽量重新发起请求，而不是只看之前已打开的页面，因为页面缓存可能让一次看似成功的显示没有产生新的网络请求。若只在某一个应用中失败，也要区分该应用自身登录、权限或服务状态的问题。

如需做前后对照，应使用同一设备、同一网络和同一目标，每次只改变连接状态或路由姿态中的一个因素。切换网络、切换服务器又同时修改规则，会让对照失去意义。访问成功之后，还要检查分流是否符合原意；能打开页面只是业务可用的证据，不是策略命中的完整证据。

最后核对 Data 与匹配策略

进入 Data 查看当前可见的请求信息，结合请求目标、时间和策略判断本次访问的处理路径。不同显示内容以应用当前提供的记录为准。先找到刚才发起的请求，再对照 Config 中的规则；如果没有对应记录，先确认请求是否真的重新发出，而不是立即修改规则。

对于预期 DIRECT 的目标，应确认实际使用了对应策略；对于预期 PROXY 的目标，则应结合当前服务器及策略引用核对。REJECT 表示拒绝匹配请求，并不保证应用内所有相似内容都会消失。如果规则影响了正常功能，应定位具体请求和命中项，再做范围尽量小的修改，不要直接删除整份配置。

请求记录可能含有域名等个人使用信息。保存排查材料时只保留定位问题必需的内容，分享前去掉个人凭据和无关请求。完成这三层检查后，正常的结束状态应是：实际服务可用、路由姿态符合目的、代表性请求的策略与预期一致。

常见失败点排查

遇到问题先停在出错的那一层，不要从头删除全部资料。下面按操作顺序列出检查路径。每改动一项就复测一次，保留上一次可用设置；这样才能知道是哪一个变化影响了结果。

订阅保存了，但列表为空

回到订阅项检查 URL 是否完整，确认该地址是订阅内容地址而不是需要登录的说明页面。然后执行一次更新，记录应用提示。如果返回的是网页、访问错误或不符合预期的内容，列表便可能无法生成。此时应向自己的服务商核对地址有效性与返回格式，而不是把 Subscribe 随意改成某个服务器协议。

更新失败与已有条目消失也不是同一种情况。若原有条目仍在，先保留它们并记录失败时机；不要为了重试立即清空所有内容。订阅内容变化后，还要重新确认当前选中项是否仍是需要使用的条目，不能只看分组名字没有变化。

有服务器条目，但测试失败

先确认设备当前网络正常，再检查 Type、地址、端口和认证字段是否与自己的原始资料一致。若资料要求特定 TLS 或传输参数，也要逐项核对。不要使用反复切换全部开关的方式碰运气，这会把原本明确的参数错误变成多个未知因素。

若其他已有条目可用，可以选取其中一个做对照；若同一条目只在某个网络下失败，记录网络环境与错误提示，进一步核对是否有网络限制或解析差异。Connectivity Test 的单次结果只作为线索，最终还要结合实际业务访问。

开关打开，但目标访问失败

首先确认系统授权已完成、应用未立即断开，接着查看 Global Routing 是否仍是测试所需的姿态。若为 Direct，选中的服务器并不能证明请求通过了它；若为 Config，应检查正在启用的配置，而不是只打开一份同名文件查看内容。需要时短暂用 Proxy 做对照，测试后恢复原选项。

如果 Proxy 可用而 Config 不可用，重点回查规则顺序、策略引用以及与该目标相关的配置。若两者均失败，再回到服务器、基础网络和目标服务本身的检查。不要仅凭 VPN 标识存在就排除这些因素。

更新后行为改变，或断开后仍有变化

订阅更新可能改变服务器条目，配置更新可能改变规则，两者应分别记录。先确认到底更新了哪一项，再检查当前选择与先前是否一致。若手动断开后又出现连接，回看 On Demand 的启用状态及触发条件；若仅页面表现没有改变，则重新发起请求并留意缓存，不要把旧页面内容当成新的连接结果。

准备继续排查时，整理四项信息即可：失败发生在哪一步、当前 Global Routing 姿态、是否仅影响某个目标、刚才唯一修改了什么。不要附上完整订阅地址、密码或其他认证资料。购买、商店地区与已购恢复问题转到App Store 获取指南；协议和规则关键字的深入解释转到术语表，不必为了完成首次连接一次性修改所有设置。