Shadowrocket 入门指南

01 · 添加服务器或导入订阅

打开 Shadowrocket，进入 Home（主页面），找到添加入口并打开 Add Server（添加服务器）。先判断手头资料属于哪一种：订阅链接用于批量取得服务器条目；单个服务器信息则包含协议、地址、端口与认证参数。两种方式任选与资料相符的一种即可，不需要为了完成教程重复导入。

已有订阅链接：使用 Subscribe

在 Add Server 的类型选择中找到 Subscribe（订阅），进入后把从你的服务商处取得的完整链接填入 URL 字段。复制时确认没有带入说明文字、引号、换行或前后空格。尤其不要删去问号后面的参数；这部分可能用于识别订阅，地址能够打开并不代表删减后仍能获取同一份内容。

填写一个便于自己辨认的备注，再保存订阅。返回 Home 后，查看该订阅是否已取得服务器列表；如果尚未出现条目，使用对应订阅的更新操作，并留意更新结果。保存一个订阅地址与成功取得订阅内容是两件事，只有出现可选择的服务器条目，才完成本步骤的主要检查。

订阅更新会按来源内容调整列表，条目名称也可能变化。首次导入时先确认分组与来源，不要只凭名称相似就删除旧条目。需要替换旧订阅时，先验证新订阅确实能更新、其中服务器可以使用，再整理旧内容，以便出现问题时仍有可核对的原始状态。

已有单个服务器信息：核对协议与字段

如果资料是逐项参数，在 Add Server 中先选对应协议，再填写地址、端口及认证内容。Shadowsocks、Trojan、WireGuard 等协议需要的字段不同，不能仅因为都有地址和端口就互相套用。地址字段通常填写主机名或 IP 地址，不要自行把它扩展为网页地址；端口按资料填写，不要凭常见数值猜测。

对于资料中明确列出的 TLS、Server Name 或其他传输选项，应按原值填写。域名地址与用于 TLS 验证的名称可能承担不同作用，不能随意互换。资料没有给出的必需项，应向原资料提供方确认；不要为了通过保存而关闭证书验证，也不要把某个看似可用的公共地址填进去替代。

保存后回到 Home，在 SERVER（服务器列表）区域找到刚添加的条目，点选本次要使用的服务器。进入编辑页复核一次，重点检查协议类型、端口和认证字段。此时看到条目仅说明资料已保存，还不能证明服务器可达。完成选择后，继续设置 Global Routing。

02 · 选择 Global Routing 姿态

在 Home 打开 Global Routing（全局路由），确认当前采用的请求处理方式。本教程将三种姿态写为配置(Config)/代理(Proxy)/直连(Direct)。这里决定请求按什么原则处理，不是服务器协议选择，也不会替你补齐连接资料。切换之前先记下当前值，方便验证后恢复。

配置(Config)：按当前配置中的规则处理

日常需要分流时选择配置(Config)。随后进入 Config（配置文件页面），确认实际启用的是预期的配置文件。列表里保存了某份配置，并不等于它已经启用；编辑的文件与当前生效的文件也可能不同。若不确定，先查看当前启用标记，再打开对应内容核对。

Config 会依据当前配置中的规则决定策略。请求可能按规则使用 PROXY（代理策略）、DIRECT（直连策略）或 REJECT（拒绝策略），因此开启连接并不意味着每个请求都会经过代理。规则通常按顺序匹配，先命中的条目会影响结果。完整结构、规则语法与最终策略的含义见配置字段参考，首次连接不必在这里重写整份文件。

代理(Proxy)：先检查代理连接路径

当目标是确认所选服务器本身能否承载访问时，可以临时选择代理(Proxy)，让需要通过此姿态处理的请求走所选代理服务器。这样能减少规则分流对判断的干扰。它适合一次有明确目的的对照测试，不代表所有应用、所有目标在任何网络中都必然可以访问。

测试前确认 Home 选中的仍是刚才核对过的服务器。测试结束后，如果日常使用依赖规则分流，应恢复配置(Config)，并重新验证目标请求。否则后续看到的访问结果可能来自 Proxy 姿态，而不是你正在检查的配置规则。

直连(Direct)：核对本地网络访问

直连(Direct)用于让请求直接访问目标，不借助所选代理服务器。它可以帮助判断本地网络能否访问某个服务，但不能用来证明代理服务器可用。如果导入资料后一直处于 Direct，即使网页打开正常，也不能据此得出订阅已经生效的结论。

完成本步骤时，应能说清当前姿态及选择原因：按规则日常使用选 Config，隔离规则影响检查代理路径可临时选 Proxy，检查本地直接访问则用 Direct。确认后返回 Home，准备建立连接。

03 · 打开开关并完成系统授权

回到 Home，先检查所选服务器与 Global Routing，随后打开连接开关。首次建立连接时，系统可能提示添加 VPN 配置。这个提示是允许 Shadowrocket 在设备上建立用于处理网络流量的系统连接配置，不是购买流程，也不是取得服务器信息的步骤。

阅读弹窗中的应用名称和提示内容，确认它由刚才的操作触发，再选择允许，并按系统要求完成设备认证。若取消了授权，客户端无法仅靠保存服务器条目完成连接。重新操作时回到 Shadowrocket 再触发一次连接，按当前系统提示处理，不要反复点击开关试图跳过确认。

授权完成后等待状态稳定，观察 Home 的连接状态。系统的 VPN 标识只能说明相关连接状态，不能单独证明目标服务已可访问，更不能说明全部请求都已走代理。如果开关刚打开便恢复关闭，先记录应用给出的提示，再进入下一步排查，不要连续修改协议、路由与配置文件。

如果设备上还有其他正在使用系统 VPN 连接的设置，应先结束当前不需要的连接，再进行本次验证。在受组织管理的设备上，网络策略或配置管理可能限制相关操作，应按设备管理要求处理，不要删除不了解用途的系统配置。

首次验证建议保持同一种网络环境，例如全程使用当前 Wi-Fi，不要一边切换网络一边判断服务器是否可用。网络变化会改变连接条件，容易把本地网络问题误认为资料填写问题。确认一次连接成功后，再单独测试其他网络环境。

本步骤完成的判断是：授权流程已结束，连接状态保持稳定，且当前服务器与路由姿态仍符合预期。接下来用测试和实际访问共同确认结果。

04 · 用测试与实际访问验证生效

在 Home 找到 Connectivity Test（连通性测试），对当前服务器进行测试。把结果视为特定测试目标、测试方式和当前网络条件下的可达性参考。测试出现读数，不代表每个目标服务都能正常使用；没有得到结果，也不应立即认定所有协议参数都错了，应结合实际访问继续判断。

随后打开浏览器，访问一个你日常使用、当前可以明确判断成功与否的目标页面。确认是否取得新的页面内容，而不是只看到先前缓存的内容。若页面本身具有登录、地区、账户或服务端限制，这些因素可能独立影响结果，不能全部归因于 Shadowrocket。

实际访问成功后，回到应用检查连接是否仍保持，并结合可用的请求记录核对该目标的处理路径。对于配置(Config)，重点看目标命中了哪条规则、最终使用了什么策略。若命中 DIRECT，网页能够打开说明直连路径可用，并不能证明所选代理服务器参与了该请求。

如果需要验证某条规则，保持同一个目标与同一个服务器不变，再检查配置。先确认正在查看的是当前启用文件，再看匹配顺序。有些目标会同时请求多个域名，主页能打开而资源加载不完整时，应区分失败的是哪个请求，而不是只根据地址栏中的主域名判断全部规则。

Data（流量统计）中的上传、下载变化可以作为活动参考，但不是某个目标一定采用某条路径的直接证据。统计可能包含其他应用的后台请求，也可能与服务商的计量范围不同。首次验证优先看真实访问结果及对应策略，不用追求两处数字完全一致。

建议记下四项简短结果：使用的网络、选中的服务器、Global Routing 姿态，以及目标服务的访问表现。不要记录完整密码或订阅链接。这样稍后更换网络、更新订阅或修改规则时，可以在相同条件下复测，而不是凭印象比较。

本步骤结束时，把临时切换的 Proxy 或 Direct 恢复到预期的日常姿态，再访问一次相同目标。如果恢复 Config 后表现改变，优先检查规则；如果两种姿态都失败，则继续按下方顺序检查网络和服务器资料。

05 · 按层排查常见失败点

排查时每次只改变一个条件，并重复同一项测试。先修改订阅、再切网络、再换规则，即使最后恢复访问，也很难知道是哪一步起作用。按下面顺序检查，可以把“导入失败”“连接未建立”和“规则未命中”分开处理。

订阅保存了，但列表没有服务器

先确认设备本地网络可用，再检查订阅地址是否完整。更新失败时阅读对应提示，区分地址不可达、认证失效与内容无法识别等情况。如果链接能在浏览器中打开，也只能说明浏览器取得了某种响应，不能证明响应一定是可导入的订阅内容。不要把登录页面或提示页面的地址当成订阅地址。

若链接曾经可用而现在不能更新，向你的服务商核实链接状态及内容格式。订阅更新失败不一定会立即移除原有服务器，所以还应区分“旧条目仍存在”和“本次更新成功”。不要在尚未确认来源状态前清空原列表。

服务器存在，但连接或访问失败

重新进入该条目的编辑页，逐项核对协议、地址、端口、密码或其他认证参数。复制内容时容易混入空格，也容易把备注当成地址。对于使用 TLS 的连接，检查资料中的名称设置及设备日期时间是否合理；不要通过放宽验证要求来掩盖资料错误。

随后确认 Home 实际选中的是该条目，而不是同名的旧服务器。临时切到 Proxy 对同一个目标进行测试，如果仍失败，再分别检查本地网络与该服务器状态。不要仅凭一次测试超时就批量删除所有服务器；某个测试目标不可达与整个连接不可用并不总是同一件事。

连接状态稳定，但部分目标不能使用

先确认当前 Global Routing。若 Proxy 下可以访问、Config 下不可以，检查当前启用文件及目标命中的规则，尤其留意前面更宽泛的规则是否提前匹配，以及是否命中 REJECT。不要先增加大量重复规则；先找到实际决定策略的那一条，再做最小修改。

如果域名访问失败而其他访问正常，再考虑 DNS（域名解析）相关因素。域名尚未正确解析时，改变服务器备注或重新排列列表通常无法解决问题。记录失败域名和当时的姿态，深入的 DNS 与规则解释查看问答页及配置字段参考，不要在首次排查中同时替换所有解析设置。

开关无法保持，或关闭后又自动连接

开关无法保持时，先检查系统授权是否完成、应用是否给出错误提示，以及设备是否存在连接管理限制。关闭后又连接时，检查 On Demand 是否按条件重新触发。两种现象的原因不同，不应都归结为订阅失效。需要查看系统配置时，只处理能明确确认属于本次设置的项目。

准备求助时，用文字描述“哪一步失败、使用什么协议、当前姿态、测试和实际访问各是什么结果”。分享截图或日志前，遮盖订阅地址、密码、密钥与账户标识。可以保留错误类型和必要字段名称，让排查有依据，同时避免泄露连接凭据。

排查结束后，恢复临时修改的路由姿态与测试设置，确认当前 Config 和服务器选择，再完成一次真实访问。至此应保留一套能复现的操作顺序：资料导入成功、服务器选中正确、连接授权完成、实际策略符合预期。后续只在需要时逐项加入 On Demand 或更细的规则。