Shadowrocket 添加服务器、分流与连接验证

准备检查：先确认输入资料完整

首次操作前，先把已有资料分成两类。第一类是单个服务器信息，通常包含协议类型、服务器地址、端口以及认证字段；部分协议还可能包含传输、TLS、SNI、Public Key、Private Key 或其他参数。第二类是订阅链接，它由你的服务商提供，用于一次导入并更新多条服务器记录。两类资料只需选择一种导入方式，不必重复添加。

打开 Shadowrocket 后，先停留在 Home。这个页面用于查看当前服务器、选择连接对象、设置 Global Routing 并控制连接开关。底部的 Config 用于管理规则配置，Data 用于查看连接产生的数据记录，Settings 则包含 DNS、On Demand、Log 等客户端设置。先认识这些入口，后面的操作就不容易在页面之间走错。

如果设备上还没有 Shadowrocket，应先前往本站的 App Store 下载说明核对产品页。开发者名应为 Shadow Launch Technology Limited，应用 ID 为 932747118。iPhone、iPad 以及商店兼容性栏列出的其他 Apple 设备，其系统要求均以 App Store 页面标注为准。本教程接下来只说明 iPhone 与 iPad 上的基础操作。

添加服务器或导入已有订阅

从 Home 进入 Add Server。接下来根据手中资料选择操作路径：如果你拿到的是一组明确的服务器字段，使用手动添加；如果拿到的是订阅链接，进入 Subscribe。完成其中一条路径后，都要回到 Home 确认服务器条目已经出现，再继续设置 Global Routing。

路径一：使用 Add Server 手动填写

在 Add Server 中先选择与你现有资料一致的协议类型，例如 Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard 或 Hysteria2。协议名称只是类型入口，不能相互替代。选定后，按照原始资料逐项填写服务器地址、端口和认证字段；页面中出现的额外字段，也只在服务商明确给出对应值时填写。

填写时应特别留意三类常见输入问题。第一，服务器地址前后不要带空格，也不要把说明文字一并复制进去。第二，端口应放在端口字段，不要和地址写在同一格。第三，区分大小写的认证内容必须保持原样。完成后保存，返回 Home，在 SERVER 列表中找到刚添加的条目并点选。当前选中的服务器通常会在列表状态上有所区别。

如果已有资料以二维码形式保存，可在对应入口使用 Scan QR Code。扫描前应确认二维码确实来自你已有的服务器资料；识别完成后仍要打开条目检查协议类型和主要字段，避免因二维码内容过期而直接进入后续步骤。若你已有符合客户端要求的 Cloud JSON，可使用 Import from Cloud JSON，导入后同样要回到 Home 检查条目。

路径二：通过 Subscribe 导入

在 Add Server 中进入 Subscribe，为订阅填写便于自己识别的名称，再粘贴已有订阅链接并保存。保存后执行更新，等待 Shadowrocket 完成解析。更新成功时，Home 的服务器列表会出现该订阅带来的条目；如果列表没有变化，不要立即反复创建相同订阅，应先打开原订阅记录确认链接是否完整，并查看更新过程是否给出错误提示。

订阅是一种更新服务器记录的方式，不等于连接已经开启。导入后还要从 Home 选中一个具体服务器，并完成 Global Routing 与连接开关设置。以后订阅内容发生变化时，应更新现有订阅记录，而不是每次新建同一条链接。这样可以减少重复条目，也更容易判断当前使用的是哪一组信息。

完成本步的判断标准很简单：回到 Home 后能够看到至少一个由你自己资料产生的服务器条目，并且可以点选它。如果 Add Server 保存后没有条目、Subscribe 更新后列表为空，问题仍停留在导入阶段，此时不必先调整 DNS 或 Config。

选择 Global Routing 姿态

服务器条目准备好后，回到 Home，找到 Global Routing。这里决定流量采用哪种基本处理方式。Shadowrocket 中常用的三种姿态是配置 Config、代理 Proxy、直连 Direct。三者作用不同，选择前要先明确本次是验证服务器本身，还是按规则长期使用。

如果这是第一次操作，建议先用 Proxy 完成一次基础连通性检查。确认当前服务器能够工作后，再切换到 Config，观察规则分流是否符合预期。这样可以把“服务器本身不能连接”和“配置规则没有按预期匹配”分成两个问题，排查时更清楚。

选择 Config 前，点开底部 Config，确认当前确实选中了需要使用的配置文件。配置文件为空、没有被选中，或者规则内容与预期用途不一致，都可能导致请求走向与设想不同。规则通常按顺序匹配，较具体的规则应放在合适位置，最终未命中的请求再由 FINAL 等规则处理。规则语法和 DNS 配合方式较多，可继续阅读 Settings 设置手册。

打开连接开关并完成系统授权

保持在 Home，再次确认当前服务器名称和 Global Routing，然后打开连接开关。首次在设备上建立连接时，系统会要求允许添加 VPN 配置。这个授权由 iOS 或 iPadOS 显示，按屏幕提示确认，并使用设备要求的验证方式完成操作。没有完成系统授权时，Shadowrocket 无法建立对应的系统网络配置。

授权完成后回到 Shadowrocket，等待连接状态稳定。不要在开关刚打开时连续切换服务器、Config 和 Global Routing，因为多项同时变化会使失败原因难以判断。如果状态很快恢复为未连接，先记录当时选中的服务器和姿态，再进入下一节验证，不要仅凭开关颜色判断所有网络环节都正常。

如果之前已经授权，但系统设置发生变化，也可能需要重新确认权限。可以先关闭连接开关，等待数秒后重新打开；若仍无法保持连接，再检查设备当前是否有可用的 Wi-Fi 或蜂窝网络。Shadowrocket 需要先建立在正常的本地网络之上，本地网络本身无法访问时，更换 Global Routing 通常不能解决基础连接问题。

连接建立后暂时不要启用 On Demand。On Demand 会按条件自动触发连接，适合在手动流程确认正常后再配置。首次排查阶段保持手动开关，可以清楚看出每次操作发生在何时。需要长期使用 On Demand 时，可在基础流程完成后前往 Settings 设置，并参考 On Demand 设置说明。

使用 Connectivity Test 验证结果

连接开关保持打开后，先检查 Home 的状态是否已经稳定，再对当前服务器执行 Connectivity Test。可从服务器条目的操作入口找到同名功能；如果当前界面布局将它放在相关菜单中，以 Connectivity Test 这一英文界面词为准。测试用于检查服务器相关的连接环节，但单次测试结果不能代替实际访问验证。

接着打开一个你原本就需要访问的页面或应用，观察是否能够正常加载。然后回到 Shadowrocket，查看 Data 中是否出现新的连接记录。若使用 Config，还应留意请求最终命中了哪条规则以及使用了 PROXY 还是 DIRECT。能看到连接记录但页面没有完成加载，说明系统开关已经工作，问题可能位于服务器响应、DNS、规则策略或目标服务这一层。

如需更细的依据，可在 Settings 中查看 Log 相关入口。Log 适合确认域名解析、规则命中、连接建立与失败提示，但其中可能包含域名、服务器地址等运行信息，转发给他人前应先检查内容。排查完成后再按实际需要调整日志设置，不必为了日常使用长期保持最详细的记录级别。

建议用下面的顺序判断结果，而不是只看某一个状态：

1. Home 中已经选中预期服务器，连接开关保持打开。
2. Global Routing 与测试目的相符，验证服务器时不是 Direct。
3. Connectivity Test 能完成对应检查，或给出可用于定位的明确提示。
4. 实际页面能够加载，Data 中可以观察到新的连接记录。
5. 使用 Config 时，规则命中结果与 PROXY、DIRECT 的预期一致。

如果 Proxy 下可以正常访问，而 Config 下结果异常，服务器本身通常已经通过基础验证，应把重点移到配置文件、规则顺序、策略名称和 DNS。相反，如果 Proxy 下也无法完成测试，则先检查服务器字段、本地网络和订阅状态，不要急于重写规则。

常见失败点：按层次逐项检查

不同问题可能呈现相似现象，例如开关无法保持、测试失败、页面一直加载或只有部分域名不可用。有效的处理方式是从最外层开始，每次只改一个变量，并在修改后重新执行相同验证。下面的顺序覆盖首次使用最常见的环节。

一、Home 中没有服务器条目

先回到 Add Server 检查保存是否完成。手动填写时确认协议类型、服务器地址和端口均已保存；通过 Subscribe 导入时，打开已有订阅记录并执行更新，观察是否出现解析提示。不要连续创建多个同名记录，否则会增加后续选择难度。订阅链接失效、认证信息变化或服务状态问题，需要由提供该信息的服务商核对。

二、服务器可以看到，但连接开关无法保持

先确认设备本地网络可用，再检查系统授权是否完成。关闭开关，等待连接状态完全结束后重新打开，避免快速连续点击。如果更换网络后现象改变，应分别记录 Wi-Fi 与蜂窝网络下的结果。随后检查当前服务器的协议、地址、端口和认证字段，尤其留意复制时产生的空格与遗漏。

三、Connectivity Test 失败

将 Global Routing 暂时设为代理 Proxy，选择一个确定已保存完整的服务器再测。若多个服务器都失败，应优先检查本地网络、订阅是否已更新以及公共字段是否填写错误；若只有单个条目失败，则重点核对该条目的独立参数。Connectivity Test 是定位工具，不应通过反复点击代替字段核对。

四、Proxy 正常，但 Config 下无法访问

进入 Config 确认配置文件已被选中，并检查规则策略名称是否存在。规则从上到下匹配时，前面的宽泛规则可能提前接管请求，使后面的具体规则没有机会生效。可通过 Data 或 Log 查看目标域名命中了 DOMAIN、DOMAIN-SUFFIX、GEOIP、IP-CIDR 还是 FINAL，再决定调整哪一条规则。不要一次删除整组规则，否则难以比较修改前后的差异。

五、测试有结果，但网页仍打不开

这种情况要把 DNS 单独列为一层。服务器测试正常只说明部分连接条件成立，不代表域名解析一定完成。先观察是所有域名都失败，还是只有个别域名失败；再查看 Log 中是否出现解析相关提示。DNS 设置、远程解析与规则之间存在关联，具体字段和排查顺序可阅读 DNS 设置参考。

六、部分应用正常，部分请求异常

如果使用 Config，先查看异常请求命中的策略。某些连接可能由 DOMAIN-SUFFIX 匹配，另一些可能落到 GEOIP 或 FINAL，因此同一应用内部也可能出现不同结果。确认规则后，再检查对应策略是否指向当前可用的服务器。若使用 Proxy 仍只有特定目标异常，则应保留测试时间和 Log 中的错误类型，区分目标服务状态与客户端配置问题。

七、订阅更新后服务器发生变化

订阅更新会按照订阅内容刷新相关记录。更新后应回到 Home 重新确认当前选中的服务器，并再次执行 Connectivity Test。若原条目已不在列表中，不要继续依据旧名称排查。需要保留的手动服务器应使用独立条目管理，不要把手动填写和订阅更新产生的记录混为一组。

基础连接完成后的设置顺序

当 Home 的连接开关可以稳定保持、Connectivity Test 有明确结果、实际访问正常，并且 Config 下的规则命中符合预期时，基础流程就已经完成。接下来再根据实际需要处理 DNS、On Demand、Ping、Log、Widget、iCloud 同步和 Proxy 端口等设置。不要在基础连接尚未确认时同时修改这些项目。

推荐的后续顺序是：先固定一个已验证的服务器，再确认 Config 规则；随后检查 DNS；最后才启用 On Demand 或 Widget 等便捷功能。这样每一层都有可比较的基准。若后续调整导致连接异常，可以退回到本教程的 Proxy 验证步骤，先判断服务器是否仍能工作，再继续检查新改动的设置。