Shadowrocket 使用教程
已有订阅导入 → Global Routing → 连接授权 → 请求验证 → 失败点排查。
本教程以 iPhone 与 iPad 上的首次配置为主。先完成一条可核对的连接，再处理复杂规则，不需要在第一次打开时改遍所有设置。官方截图用于辨认页面与字段，具体排列可能随应用界面调整；操作时以设备上实际显示的英文界面词为准。不要照抄截图中的服务器内容，也不要把截图里出现的配置选择当作必须使用的选项。
01 · Add Server：添加与导入
打开 Shadowrocket，进入 Home，在 SERVER 区域找到 Add Server，或使用页面上的添加入口。接下来先判断手里的内容是什么：订阅链接用于获取并维护一组服务器；单条服务器信息则需要逐项填写协议和认证参数。两者不是同一种输入，不要把订阅地址直接填进服务器的 Host。
已有服务器信息：先选 Type
进入 Add Server 后，先点 Type，选择与你已有信息一致的协议。然后填写 Host 与 Port，再根据当前 Type 显示的字段填写认证信息。以 Shadowsocks 为例，通常需要核对 Password 与 Method；换成其他协议时，所需字段会不同，不能沿用上一种协议的填写方式。
Host 填服务器域名或地址，Port 填对应端口，认证字段按原始配置完整复制。注意前后空格、换行以及大小写；TLS、传输方式和服务器名称等字段也应按已有配置填写，不要凭名称相似自行推断。填写完毕后保存，返回 Home，确认 SERVER 列表中出现新项目。出现条目仅代表保存完成，还要在后续步骤中测试。
已有订阅链接：选择 Subscribe
如果你已有服务商提供的订阅链接，在添加页将 Type 设为 Subscribe，把完整链接填入对应的 URL 字段，并填写便于自己辨认的备注后保存。链接中的路径与查询参数也属于地址的一部分，不要只复制域名；如果复制的是账户管理页面地址，通常不能作为订阅导入。保存后回到 Home，等待订阅获取完成，再检查对应分组与服务器条目。
如果得到的是二维码，可使用 Scan QR Code，读取后先核对解析出的类型与内容再保存。Import from Cloud JSON 对应另一种导入入口，并不意味着任意网页地址都可以使用。只选择与你已有资料格式一致的方式，不要为了让导入通过而反复切换不相关类型。
完成这一步后，应当能在 Home 找到至少一条可选服务器。如果列表仍为空，先跳到订阅失败排查，不要继续把空列表下的连接失败当成 VPN 授权问题。订阅链接可能包含账户识别信息，保存到个人安全位置即可，不要放进公开截图、文章或分享文本。
02 · Global Routing：选择姿态
服务器保存成功后，返回 Home，打开 Global Routing。这里决定请求采用哪种处理方式，和 SERVER 列表中选中了哪条服务器是两个不同设置。先明确此次操作是验证单条服务器，还是运行已有规则，再选择配置(Config)/代理(Proxy)/直连(Direct)。
配置(Config)：按当前规则处理
选择 Config 时，客户端按当前生效的配置与规则决定请求去向。进入 Config 页面，先确认所选配置文件，再查看规则内容。官方截图中的 General、Rule、Hosts 等是不同配置分段；看到文件出现在列表里，不等于已经选中并生效。
初次使用时，重点核对 Rule 中的规则顺序、策略名称与最后的兜底行为。例如，DOMAIN-SUFFIX 用于匹配域名后缀，FINAL 处理前面未匹配的请求。规则指向 DIRECT 时，请求不经过所选代理服务器；指向 REJECT 时，请求会被拒绝。这些结果不应直接归结为服务器失效。
代理(Proxy)与直连(Direct)：分清测试目的
Proxy 用于让代理处理的请求使用所选代理路径，适合在排查时减少规则分流带来的变量；具体行为仍受应用设置及系统流量范围影响。Direct 用于直连访问，不能用它来判断已选服务器是否可用。开关处于连接状态，也不意味着每个请求都使用代理，必须把 Global Routing 与实际策略一起看。
本教程建议先记录当前姿态。若你还没有需要保留的规则，可以用 Proxy 检查单条服务器，再按实际需要切回 Config；若已有正常使用的配置，先保留原文件，不要覆盖后再尝试恢复。不要为了普通连接验证启用 HTTPS Decryption 或额外配置证书，这不属于本教程的必要步骤。协议字段与设计取舍可继续阅读协议手册。
03 · Home：打开连接
现在回到 Home，在 SERVER 列表中点选准备使用的服务器，确认选中标记已经落在目标条目上。订阅分组里有多条记录时，不要把分组名称误当成实际服务器。随后再看一次 Global Routing，确认它与上一步的选择一致，然后打开页面顶部开关。
首次建立连接时，系统可能要求允许添加 VPN 配置。阅读系统弹窗，确认是这次由 Shadowrocket 发起的操作后，再按提示允许，并完成设备要求的身份验证。这是系统管理 VPN 配置的授权过程，不是让你在服务器 Password 字段里输入设备密码。若取消授权，返回 Home 后连接不会按预期建立，需要再次操作并完成授权。
授权后回到应用，观察顶部状态是否从 Not Connected 发生变化，以及开关能否保持开启。若立即回到断开状态，先保留提示信息，转到排错步骤，不要连续快速拨动开关。若状态已连接，则进入下一步验证；此时只能说明连接流程已启动，不能据此断言目标服务已经可用。
如果设备上还有其他 VPN 连接正在运行，先确认当前由哪一个配置接管系统连接，避免把另一个连接的状态当作本次结果。测试期间保持网络环境稳定，不要同时切换 Wi-Fi、修改协议字段和更换服务器。完成首次验证前，暂时保留 On Demand 的原有设置；自动触发条件应在手动连接确认正常之后再单独配置，相关说明见On Demand 参考。
04 · Connectivity Test：验证生效
开关保持开启后，在 Home 使用 Connectivity Test 查看测试结果。先辨认测试方法，再理解返回值：不同测试方法检查的网络层次与目标不完全一样，能得到延迟结果不代表认证、TLS 与目标服务的全部请求都已成功。反过来，一次超时也可能来自测试目标、当时网络或测试方法，不宜直接删除整份配置。
接下来打开你实际需要使用的应用或页面，执行一个明确操作，例如重新载入一个页面。不要只看之前缓存的内容；也不要一次打开很多页面，否则难以把失败请求与记录对应起来。如果正在使用 Config，确认这个目标应当匹配什么策略，再对照应用里可用的连接记录检查实际去向。目标按规则走 DIRECT 时，即使加载成功，也不能据此证明代理路径正常。
Data：查看流量变化
进入应用的 Data 相关页面，观察测试前后的上传、下载统计，结合记录时间判断是否有新请求。流量变化可以辅助确认客户端正在处理数据，但它不是某个页面成功加载的直接证明：后台应用、重试和其他请求也可能计入统计。不要把累计流量当成当前服务商剩余额度，两者的统计范围与计费口径可能不同。
验证可以按固定顺序做一遍：记录服务器与姿态，运行 Connectivity Test，访问一个实际目标，查看相应流量与连接记录，最后记下结果。若只有某个目标失败而其他目标正常，排查应转向该目标的规则、DNS 或服务状态，而不是重新导入全部订阅。若所有目标都失败，再检查服务器参数与基础网络。
05 · Settings：常见失败点
排错先确定失败发生在哪一层：列表没有服务器属于导入问题；开关不能保持开启属于连接或系统配置问题；已连接但请求失败，则需要检查服务器、DNS 与分流。先记下失败时使用的网络、服务器、Global Routing 和具体提示，再开始改动。每次只改一个变量，修改后重复第四步，才能判断变化是否有效。
Subscribe：导入失败或列表为空
先在正常基础网络下确认设备能够联网，再核对订阅链接是否完整、是否含有多余空格，以及复制内容是否确为订阅入口。如果返回的是登录页面、错误文本或空内容，不能靠更换服务器 Type 修复。回到你已有服务商的配置说明，核对链接状态、适用格式与账户有效性；不要把包含完整订阅地址的错误截图公开发布。
已有旧条目并不代表刚才更新成功。查看本次获取结果，再核对分组中的实际记录；若导入失败，不要先删除唯一可用的原订阅。先保留当前状态并确认原因，避免失去对照。
订阅更新：先更新，再重新选择
需要刷新已有订阅时，在 Home 找到对应订阅分组，使用该分组的更新操作，等待结果返回后再检查服务器列表。更新可能改变条目名称、数量或参数，因此更新完成后应重新确认选中的服务器，而不是默认仍在使用原来那条。若服务商已经更换了订阅链接，应按其说明修改已有记录的地址，不能仅靠反复刷新旧地址获取新内容。
手动修改订阅生成的服务器参数前，要考虑下次更新可能覆盖改动。需要排查某个字段时，先记录原值和修改原因，测试后恢复，或在明确了解影响的前提下保存独立的测试记录。订阅用于维护服务器信息，Config 用于配置与规则；前者更新成功，不等于后者的规则也已更新。
服务器连接：逐项核对，而不是只看延迟
如果列表正常但连接失败，回到 Add Server 对应记录，按 Type、Host、Port、认证字段、传输方式和 TLS 相关设置的顺序检查。域名与服务器名称字段可能用途不同，不能因为文本看起来相近就互换。设备系统时间也应准确，明显偏差可能影响证书验证。若原始信息不完整，应向已有服务商核对字段，不要用猜测值填满所有选项。
如果切换网络后表现不同，先在相同参数与相同目标下复测，区分当前网络路径与配置错误。Settings 中的 Test Method 会影响测试结果的含义；Diagnostics 可用于进一步查看可用诊断信息。不要看到 TCP 或 UDP 就随意关闭某项，协议是否依赖对应传输应以配置说明为准。
DNS：连接成功但域名访问失败
DNS 负责把域名解析为地址。若连接保持正常，但特定域名无法打开，先确认失败是否稳定复现，并查看可用记录里有没有解析相关错误。使用 Config 时，核对当前配置的 DNS 设置、Hosts 条目与目标规则，避免只修改一个未生效的文件。先记下原配置，再按其说明调整；不要不断叠加不同设置，导致无法判断当前实际使用的是哪一项。
部分目标失败还可能来自规则命中 REJECT、策略指向不可用服务器，或目标服务自身异常。把 Global Routing 暂时改为 Proxy 可以帮助比较规则影响，但测试后应恢复原姿态；Proxy 成功而 Config 失败，说明应优先检查配置与分流，不是直接认定所有规则都需要删除。协议的详细参数请查阅Shadowrocket 协议手册，本页只保留首次配置所需的检查顺序。
完成检查后：恢复日常设置
确认实际目标能够访问后，恢复准备日常使用的 Global Routing，并再验证一次。如果测试期间关闭过 On Demand 或修改过 Test Method，也应逐项确认最终状态。需要停止连接时回到 Home 关闭顶部开关，并观察状态变化；若随后自动连接，检查 On Demand 条件，而不是继续重复手动断开。
首次配置完成的标准不是“设置越多越好”，而是已有服务器信息正确、当前配置明确、连接授权完成、目标请求与策略相符。保留一份简短的检查记录即可；其中不要包含密码、完整订阅链接或其他认证信息。以后遇到问题，从最后一次成功状态与本次变化开始排查，通常比重新填写所有字段更容易定位原因。