Shadowrocket 首次连接教程

第一步：添加服务器或导入订阅

先让 Home 中出现可选择的服务器，再处理模式和连接开关。订阅链接与单台服务器信息是两种不同的输入：前者用于获取一组可更新的服务器记录，后者用于保存一台服务器的具体参数。只需按手头的信息选择一种方式，不必把同一批内容重复添加。

已有订阅链接：选择 Subscribe

打开 Shadowrocket，进入 Home，点右上角的加号，进入 Add Server。在 Type 中选择 Subscribe，把自己的完整订阅链接填写到 URL。为记录填写便于辨认的名称后，点右上角 Done 保存。返回 Home，等待订阅内容获取完成，再查看相应分组下是否出现服务器条目。

复制链接时应从原始内容完整复制，不要把介绍文字、空格或换行一起带入，也不要手动删除链接末尾看似复杂的参数。订阅地址可能包含身份凭据，这些参数会影响获取权限。仅在自己的设备中使用链接，不要将完整地址贴到公开评论、聊天群或排查截图中。

如果保存后只看到订阅名称而没有服务器，先确认当前网络能否获取该订阅内容，再尝试更新对应订阅。服务商的网页地址不一定是订阅地址；登录页面、订单页面或普通说明页面不能当作 Subscribe 的输入。若返回的是网页或错误提示，应向自己的服务商核对链接用途，而不是连续修改协议设置。

已有单台服务器信息：在 Add Server 填写

如果拿到的是服务器地址、端口、密码或 UUID 等独立字段，仍从 Home 的加号进入 Add Server，但 Type 应选择信息中明确指定的协议，例如 Shadowsocks、VMess、VLESS 或 Trojan，而不是 Subscribe。按照原始资料逐项填写服务器地址、端口和认证字段；不同协议显示的项目不同，不需要照着其他协议的字段补齐。

尤其注意加密方式、TLS、Server Name、传输方式与路径等附加参数。它们不是随意填写的备注，必须与服务器端要求一致。地址、端口填写正确，并不代表整条记录已经正确。不要为了消除提示而任意更换协议或关闭 TLS；缺少必要信息时，应先回到自己的服务商资料核对。

如果已有的是兼容的二维码，可使用 Scan QR Code 读取；相机权限仅用于扫码。读取完成后仍应核对识别出的协议、地址和端口，再保存。二维码可能同样包含连接凭据，不应公开展示。手动填写与扫码只是录入方式不同，后续选择服务器和连接的流程相同。

返回 Home：点选默认服务器

保存成功后，在 Home 的服务器列表中点选准备使用的那一条，确认其左侧选择圆点亮起。看到一组服务器名称只说明导入有结果，并不表示所有记录都已测试通过，也不表示其中某条已经被选作默认服务器。首次操作可使用名称和用途明确的一条，避免一边切换服务器一边更改其他设置。

到这里的完成标准是：Home 有服务器条目，所需条目已被选中，并且能打开记录核对参数。Subscribe 管理的是服务器来源；Config 管理的是配置文件，两者不要混为一项。若需要理解这些名词，先查看概念速查，完成基本导入后再继续下一步。

第二步：选择 Global Routing

服务器决定代理连接使用什么出口，Global Routing 决定流量按什么方式处理。在 Home 点 Global Routing，按当前目的选择配置(Config)/代理(Proxy)/直连(Direct)。首次验证时先明确自己选的是哪一种；否则即使连接开关已打开，也可能把正常的分流结果误认为连接失败。

配置(Config)：按当前配置判断

配置(Config)根据当前使用的配置文件及其规则处理连接。使用这一姿态前，进入 Config，确认当前选用的文件就是准备使用的那一份。文件仅出现在列表中，不等于已经被选中；也不要只依据文件名称推断内部规则。若尚未准备配置，先完成最小连接验证，再按完整手册设置分流，比一次导入多份来源不明的配置更容易排查。

规则通常按顺序匹配，目标可能得到 DIRECT、PROXY 或其他已配置策略。比如 DOMAIN-SUFFIX,example.com,PROXY 表示匹配对应域名后使用 PROXY；FINAL,PROXY 则为前面规则未命中的连接指定最终处理方式。这只是语法解释，不要求首次设置时立即编辑规则，也不应据此覆盖已有配置。

代理(Proxy)：用于核对代理路径

代理(Proxy)将整体路由姿态设为使用代理，适合首次核对所选服务器是否能够承载实际访问。在 Home 已选好服务器后，选择 Proxy，再按下一步打开连接。它可以减少首次测试中分流规则带来的干扰，但不代表所有请求在任何情况下都必然经由远端服务器；系统流量、排除项及相关设置仍可能影响实际路径。

如果 Proxy 下测试和网页访问正常，切回 Config 后只有某个目标异常，应优先查看该目标命中的规则或策略，不必立即重新导入整组订阅。这个对照能把“服务器不可用”和“分流结果不符合预期”分开。

直连(Direct)：不要当作代理成功依据

直连(Direct)按直连方式处理流量，不使用所选代理服务器作为通常的访问路径。它可用于对照设备原有网络，但在 Direct 下网页能够打开，不能证明刚导入的代理服务器有效。同样，打开应用的连接开关与使用代理是两个不同判断，不能只看开关状态得出结论。

本步完成后，记下所选姿态以及 Config 下正在使用的配置文件。后续每次复测尽量保持这两项不变。规则优先级、策略与配置字段的深入解释见完整手册；这里先确保测试目的与所选姿态一致。

第三步：打开开关并允许 VPN 配置

回到 Home，再核对一次默认服务器的选择圆点与 Global Routing。确认无误后，打开页面顶部的连接开关。首次建立连接时，系统可能显示允许 Shadowrocket 添加 VPN 配置的提示；这是应用接入系统网络处理所需的授权，不是订阅已经验证成功的通知。

在系统弹窗中核对发起应用确为 Shadowrocket，再选择允许，并按设备提示完成身份确认。授权过程中不要反复切换应用或连续点击连接开关。完成后返回 Home，等待连接状态更新；如果之前取消了授权，可再次发起连接，并按系统提示完成操作。

在 iPhone 和 iPad 上，系统提示的排版、认证方式与状态显示位置可能不同，以设备实际显示为准。若需要核对系统中的配置，可在系统 Settings 中查找 VPN 相关项目，确认 Shadowrocket 的配置是否存在。不要为解决一次连接失败而删除用途不明的设备管理配置。

同时检查设备是否有其他正在工作的 VPN 连接。多个配置争用当前连接时，可能出现刚连上又断开、开关自动恢复或状态与预期不一致的情况。先明确当前启用的是哪一个配置，再进行测试；受管理设备若限制添加 VPN 配置，应遵循设备管理要求，不能通过修改服务器参数解决系统限制。

本步的完成标准是系统连接已建立，而不是所有目标都已可用。连接状态正常只说明本地网络处理已启动，仍需下一步核对远端连通性与实际网页。若开关始终无法保持开启，先停在这一阶段排查授权和系统状态，不要继续修改 DNS 或规则。

第四步：Connectivity Test 与实际访问

连接建立后，在 Home 找到 Connectivity Test 并运行一次，等待结果出现。测试用于观察当前条件下的连通情况，应记录是成功、超时还是其他错误，而不是只记一个延迟数字。列表中的延迟测试与连接后的实际访问不是同一个判断：服务器有响应，不等于认证、传输及目标访问的全部环节都正常。

先测连通，再打开实际目标

测试结束后，打开浏览器访问自己需要使用的正常网页。先选择一个地址明确、平时可以确认状态的目标，不要同时打开大量页面。若页面此前已经打开，可刷新并确认内容确实重新加载；看到缓存内容并不能证明当前路径可用。一次只测试一个目标，便于把浏览器结果与应用记录对应起来。

Connectivity Test 成功但某个网页打不开时，可能是测试目标与该网页的访问条件不同，也可能涉及 DNS、规则命中或目标服务本身。反过来，测试目标暂时不可达，也不必直接判定全部服务器都失败。应把测试结果与实际访问一起看，不用单次结果替代完整判断。

使用 Config 时，再核对分流

若正在使用配置(Config)，至少分别验证一个预期直连的目标和一个预期使用代理的目标。在应用的连接记录中查看相应请求及策略结果，对照当前配置中的规则顺序。网站能打开只能证明该次访问成功，不能单凭这一点确认它采用了预期路径；需要结合命中记录判断。

Data 可辅助观察连接过程中的流量变化，但有数据增长并不等于规则正确，也不能据此确认所有应用的访问路径。首次验证的重点仍是：所选服务器明确、Global Routing 明确、Connectivity Test 有结果、实际目标可访问，使用 Config 时还能解释对应策略。

若四项都符合预期，就可以保持当前设置开始正常使用。此时不必为了追求更低的测试数字连续切换服务器，也不必立刻更换 DNS。记录当前成功组合，日后出现异常时便能与这次的网络、姿态及服务器作对照。

第五步：按失败阶段排查

先区分“内容没有导入”“系统连接没有建立”和“连接后访问异常”。这三个阶段需要检查的对象不同。每次只改一项，修改后复测同一个目标；若同时换服务器、改 DNS、换配置，结果即使恢复也很难确定原因，后续还可能重复遇到同样的问题。

订阅没有内容：检查输入与获取过程

返回 Subscribe 记录，核对 URL 是否完整，是否误贴成了服务商网页，以及当前网络是否能获取订阅。注意链接是否已被原服务商重置、失效或更换。更新失败时保留原有可用记录，先核对提示，再决定是否重新导入；重复创建相同订阅通常不能解决原始链接的权限问题。

如果新订阅的服务器列表与预期不同，应先核对订阅来源及服务有效状态。不要在公开场合发送完整 URL 求助。可以提供“更新后为空”“提示认证失败”等现象描述，并由自己的服务商核实账户和订阅状态。

开关无法开启：检查系统授权

若打开开关后立即恢复，检查是否取消了添加 VPN 配置的系统提示，以及设备是否允许该配置建立连接。重新回到 Home 发起连接，留意系统提示是否被遮挡或尚未确认。此阶段还未完成系统连接，反复更换订阅中的服务器往往不是有效的第一步。

若状态显示异常，还应确认当前启用的 VPN 配置及设备管理限制。能正常使用普通网络，只能排除部分基础网络问题，不能代替 Shadowrocket 所需的系统授权。

已连接但测试失败：核对服务器与网络

先检查 Home 中实际选中的服务器是否就是刚才填写或准备测试的那条，再核对地址、端口、密码或 UUID、TLS 与传输参数。服务器名称相似时尤其容易选错。若已有订阅中另有自己确认可用的记录，可以保持其他设置不变，仅切换该记录作对照，不需要重新导入所有内容。

随后确认设备原有网络可用，必要时在自己允许使用的另一种网络下复测。切换网络后使用相同服务器与相同目标，结果才有对照意义。测试失败也可能与服务器端状态有关，客户端的连接开关无法证明服务商侧的认证和服务仍然有效。

仅部分目标失败：检查规则与 DNS

如果 Proxy 下正常而 Config 下异常，回到 Config 核对当前文件以及目标命中的策略。查看是否被更靠前的 DIRECT 或 REJECT 规则匹配，不要只检查最后一条规则。更改规则前先保存原配置，修改一处后复测，确认确实改变了对应目标的处理方式。

若提示与域名解析有关，再检查当前 DNS 设置，而不是把所有失败都归因于 DNS。修改前记录原值，使用自己理解且有明确依据的设置；仅凭网页打不开就连续替换多个解析地址，会增加新的变量。DNS、IP-CIDR 与 FINAL 等概念可先在概念速查中确认，再按完整手册展开处理。

仍未恢复：整理最小排查记录

向自己的服务商反馈前，整理所用协议、Global Routing 姿态、失败发生在哪一步、Connectivity Test 的结果，以及换网络后是否一致。可以附去除敏感信息后的错误文字，但不要包含完整订阅链接、密码、UUID、二维码或身份参数。描述具体错误，比只说“无法连接”更有助于定位。

完成首次设置后，日常操作保持简单：需要时更新已有订阅，确认默认服务器和当前配置，再打开连接并验证实际访问。App Store 负责应用获取与更新，Subscribe 负责已有服务器列表的更新，Config 负责配置文件；三者分别处理，不必因一次线路异常重新进行应用购买。