Shadowrocket 使用教程
按导入、模式、连接、验证、排错的顺序操作。先完成一次可复查的连接，再调整自动连接与复杂规则。
本页针对 iPhone、iPad 上的首次操作。请先让设备连上可用的 Wi-Fi 或蜂窝网络，确认普通网页可以打开，再准备服务商提供的原始信息。订阅链接通常包含访问凭据，应只在应用内填写；手动录入则需要明确协议类型、服务器地址、端口及相应认证字段，不能只凭一个服务器名称开始设置。
阅读时以当前应用实际显示为准，界面词保留英文原文。旁边的官方 App Store 截图用于辨认页面，不作为应照抄的服务器参数。iPad 的页面排列可能随窗口宽度变化，操作仍围绕 Home、Config 与 Settings 展开；设备兼容性与系统要求以 App Store 页面标注为准。
01 添加服务器或导入订阅
订阅与手动录入二选一即可，不必把同一批信息重复添加。先进入 Home，找到 Add Server 或页面上的添加入口，打开 Add Server 页面。先看 Type：它决定后续需要填写哪些字段。截图展示的是一种字段排列，切换到其他协议后，所需认证和传输选项可能不同，不要把截图当作所有协议通用的表单。
使用已有订阅：选择 Subscribe
持有订阅链接时，在 Type 中选择 Subscribe，将完整链接填入 URL，并用可辨认的名称备注来源，然后保存。粘贴后检查开头、末尾是否混入空格、换行或聊天文字；也不要把服务商的登录页面地址误当成订阅地址。订阅里的认证参数属于链接的一部分，删掉后可能无法获取内容。
保存后返回 Home，查看是否出现订阅分组及服务器条目。如果暂时只有分组名称，应检查订阅更新结果，必要时使用该订阅的更新操作。成功导入应以实际出现可选择的条目为准，而不是仅以保存动作完成为准。若提示获取失败，先保留提示内容，检查当前网络与链接有效性，不要连续创建多个相同订阅。
手动录入：先 Type，再填字段
只有单个服务器信息时，先按原始资料选择 Type，再填写 Host、Port 以及该协议要求的 Password、Method 或其他认证字段。Host 一般填服务器域名或 IP 地址，不要把整段网页链接粘进这个字段；Port 应与服务商给出的端口一致。Password 的大小写、符号都应保留，Method 也必须与服务器端对应，不能凭名称相近自行替换。
涉及 TLS、服务器名称或传输设置时，同样以已有服务器资料为准。不要因为连接失败就随意关闭验证或删除必要字段。Scan QR Code 适用于扫描用户已有且确认来源的二维码；Import from Cloud JSON 是另一种导入入口，只有持有相应格式资料时才使用，不能据此判断任意订阅都能从这里导入。
保存并回到 Home 后，在 SERVER 中选择本次要测试的条目。先用一个条目完成后续步骤，暂不加入自动切换或复杂策略，便于判断问题发生在哪一层。本步完成标志：Home 中有已保存的服务器条目，并已明确选中其中一个。接下来选择流量如何处理。
02 选择 Global Routing 姿态
Global Routing 决定整体处理方式，选中服务器并不等于已经选好分流方式。在 Home 点开 Global Routing，确认当前是配置(Config)、代理(Proxy)还是直连(Direct)。三个选项用途不同，不是连接质量的高低档位。先明确本次是日常按规则使用，还是临时验证服务器路径，再作选择。
配置(Config)：按所选配置中的规则处理
已有适用配置时，可以选择配置(Config)。随后进入 Config，确认实际选中的是准备使用的配置，而不只是曾经导入过一个文件。配置页面中的 General、Rule、Hosts、URL Rewrite、HTTPS Decryption 对应不同部分；首次连接主要确认配置选择和 Rule，暂不需要逐项修改其他部分。
Rule 会根据条件决定请求交给哪种策略。通常按顺序检查，前面命中的规则会影响最终去向，末尾的 FINAL 用于兜底。例如某个域名命中 DIRECT，意味着该请求走直接连接路径；即使 Home 中选了服务器，这个请求也不会因此自动改为 PROXY。理解这一点，可以避免把“规则按预期直连”误判为“应用没有生效”。
代理(Proxy)：用于检查代理处理路径
首次排查时，代理(Proxy)可以帮助缩小规则因素的影响范围：选定同一个服务器，再对同一个目标重复测试。但这仍不保证所有目标都能访问，服务器连通性、DNS、目标服务和相关设置仍会影响结果。测试结束后，如果日常使用依赖规则，应回到原来的 Config，再确认配置仍然正确选中。
直连(Direct)：检查直接连接路径
直连(Direct)用于直接连接，不以选中的代理服务器作为通常的请求出口。它适合与代理路径做对照，但不能证明代理服务器可用。如果切到 Direct 后普通网页恢复，只能说明这次请求在直接连接路径上能够完成；下一步仍需检查服务器与配置，不能把两条路径的结果混在一起。
本步先选择一个明确的姿态并记住它。不要同时改规则、换服务器、改 DNS，否则即使结果变化，也难以确定是哪项设置起作用。本步完成标志：能够说清当前姿态，以及 Config 对应的配置是否已选中。购买、商店地区与已购恢复问题另见App Store 正版获取全指南，不需要通过修改这里的规则解决。
03 打开开关并确认连接
先确认服务器和姿态，再打开 Home 顶部的连接开关。返回 Home，查看 SERVER 中当前选中的条目，再看 Global Routing。若刚才编辑过服务器，先确保已经保存并退出编辑页面。顶部显示 Not Connected 时表示尚未建立当前连接，不应仅根据服务器列表里存在条目就认为连接已开始。
打开顶部开关后，首次使用可能出现系统添加 VPN 配置的提示。这是系统为应用建立网络配置所需的授权流程。核对提示来自当前正在使用的 Shadowrocket 后，按设备给出的步骤确认，并完成设备要求的认证。如果此前拒绝过，应再次发起连接并查看系统提示；不要在不清楚用途时删除设备上的其他网络配置。
完成授权后回到 Home，观察顶部状态是否进入已连接状态。如果开关立即回退或仍停在未连接状态，先记下当时出现的错误，再到失败点排查检查，不要反复快速开关。若系统设置中已有其他正在工作的 VPN 配置，也应核对当前实际启用的是哪一个，避免把另一项配置的状态误认为本次连接结果。
需要特别区分：系统隧道处于已连接状态，只说明相应网络配置已启动，不代表选中的服务器已成功处理所有请求，也不代表某个网站一定可访问。此时先保持当前服务器与姿态不变，进入下一步检查实际请求。只看顶部开关，或只看设备状态栏中的网络标记，都不足以完成验证。
测试期间如果需要停用，可回到 Home 关闭开关，再确认状态已退出连接。如果关闭后又自动开启，不要继续反复点击，应到 Settings 检查 On Demand 的触发条件。本步完成标志：已理解授权提示，并能在 Home 确认连接状态变化。随后用测试与实际访问一起验证，而不是马上增加更多设置。
04 验证测试结果与实际访问
把连接状态、服务器测试、目标访问分开看，三者不能互相替代。保持刚才的服务器和 Global Routing，在 Home 使用 Connectivity Test。先看测试是否返回结果或超时，再打开一个平时熟悉、此刻能够核对的网页，观察是否完整载入。不要只看某个数字，也不要把网页缓存中已经显示的内容当作一次新的成功请求。
Connectivity Test 的含义取决于当前测试方法。一个成功结果不能覆盖所有协议功能，也不能说明任意网站、任意应用都能正常使用；超时同样需要结合所用方法和实际请求判断。如果测试正常而单个目标失败，应继续检查该目标、DNS 与规则路径，不要立即认定所有服务器都不可用。
使用 Config 时，核对请求命中的策略
如果当前是配置(Config)，结合应用内可查看的连接记录检查目标请求：关注目标域名、命中规则及策略去向。预期直接连接的请求命中 DIRECT，预期代理处理的请求命中相应代理策略，才与设置目的相符。Data 的流量变化可以作为辅助观察，但总流量变化不能单独证明某一个目标命中了哪条规则。
需要对照时，记录当前 Config，再临时切换代理(Proxy)，使用同一个服务器访问同一个目标。如果 Proxy 可以而 Config 不可以，优先检查配置选择、规则顺序与策略关联；如果两者都失败，再回到服务器参数和网络路径排查。完成对照后恢复原姿态，防止忘记临时设置，造成后续行为与预期不一致。
每轮只改变一个条件
建议用简短记录保留四项信息：当前网络、所选服务器、Global Routing、失败提示。下一轮只改其中一个条件，再执行同样的测试。例如仅切换 Wi-Fi 与蜂窝网络，不同时改密码和 DNS。这样得到的差异才可用于缩小范围，也便于向自己的服务商描述问题。
本步完成标志：实际请求能完成，且其处理路径符合预期。对于只有某个应用、某个域名或某类请求异常的情况，应保留这个具体边界，再进入排错；不要把局部失败概括成“全部连接失败”。首次流程确认后，再逐步恢复或增加个性化规则。
05 按顺序定位常见失败点
按网络、导入、参数、规则、解析的顺序检查，避免一次重设所有选项。先关闭本次连接，确认当前 Wi-Fi 或蜂窝网络本身可用。如果网络需要先完成登录，应先处理网络接入。网络基础状态没有确认前，反复更新订阅或重建服务器条目通常无法提供有效线索。
订阅没有条目：检查获取过程
回到已保存的 Subscribe，核对 URL 是否完整、是否仍然有效，以及更新时具体出现什么提示。订阅下载失败与订阅中某个服务器连接失败是两件事：前者先检查链接获取与内容格式，后者检查服务器参数与可用性。更新前保留现有可用信息，避免在不清楚原因时删除全部条目。
条目存在但连接失败：逐字段核对
打开对应服务器的编辑页面，与原始资料逐项比对 Type、Host、Port、认证字段和传输设置。使用 TLS 时还应核对服务器名称及相关参数，并在系统中检查日期与时间是否正确。不要只检查 Password；协议类型、端口或必要传输字段不一致，也可能表现为超时或连接失败。若服务端资料已变更，应以自己的服务商提供的新资料重新核对。
部分请求异常：检查规则与 DNS
先确认 Global Routing 没有停留在临时测试姿态。使用 Config 时，再确认所选配置及规则命中；只有特定域名异常时，重点查看该请求是否去了预期策略。涉及 DNS 的调整，应先保留当前设置，区分“域名解析失败”与“已解析但连接失败”，再一次只改一项。不要把更改解析设置当成修复所有问题的通用步骤。
检查 Settings 中的测试与自动连接设置
进入 Settings，可查看 Test Method、On Demand 与 Diagnostics 等相关入口。Test Method 会影响测试结果的解释，比较两次结果时应使用相同方法。On Demand 可能根据条件重新触发连接；如果手动关闭后又连接，应先检查这些条件，而不是认定顶部开关失效。首次排查可以暂时停用相关自动触发条件，验证手动连接后再恢复。
需要使用 Diagnostics 时，围绕刚刚发生的一次失败查看信息，记录时间、网络环境、服务器类型与错误内容。分享截图或诊断材料前，遮盖完整订阅链接、Password、认证标识及其他敏感信息，只保留定位问题所必需的部分。系统连接正常但目标请求失败时，这些具体记录比“不能用”的描述更有帮助。
完成修正后，回到打开连接与验证生效，重复同一组操作，确认结果确实变化，再恢复日常 Config 与 On Demand 设置。购买账户、商店可见性或换机找回应用的问题，应转到正版指南；它们与已有服务器的参数排查属于不同流程，不需要通过重写网络规则来处理。
