Shadowrocket 使用教程
导入已有信息，选择处理方式，再连接与验证。
先完成一次手动连接，再调整规则与自动连接条件。
阅读顺序：首次使用从第一步开始；已经导入成功但无法访问时，可直接跳到验证与失败点检查。文中截图为 App Store 官方截图，显示的字段随所选 Type 与应用界面可能有所不同，以设备上的实际界面为准。
Add Server：添加服务器或导入订阅
打开 Shadowrocket 后先停留在 Home，暂时不要打开顶部连接开关。下方 SERVER 分组用于查看服务器条目。找到 Add Server 并进入添加页面，接下来按手中资料的类型操作：一条完整的订阅链接走 Subscribe；服务器地址、端口和认证信息则按对应协议手动填写。两条路径选一条即可，不需要将同一份资料重复添加。
已有订阅链接：选择 Subscribe
在 Add Server 中打开 Type，选择 Subscribe，再把从你的服务商处获取的完整订阅链接填入 URL 字段。复制时应包含链接全部内容，不要混入说明文字，也不要在首尾留下空格或换行。订阅链接可能含有个人访问凭据，应当像密码一样保存，不要贴到公开讨论区或发送给无关人员。
确认后保存，返回 Home，等待订阅内容载入。看到订阅分组和服务器条目，才说明已有信息已进入列表；只看到订阅名称却没有条目时，应检查订阅是否成功更新。订阅有变更后可通过对应分组的更新操作重新获取内容，具体入口以当前界面为准。刷新失败时先核对链接有效性和基础网络，不要反复添加多个同名订阅来尝试修复。
已有服务器参数：先选 Type，再填字段
手动添加时，先按提供的资料选择 Type，例如 Shadowsocks、VMess、VLESS 或 Trojan，再填写该类型实际显示的字段。Host 填服务器域名或地址，Port 填对应端口；需要 Password、Method 或其他认证、传输参数时，逐项照原始资料填写。不要因为某个字段出现在截图里，就认为所有协议都需要填写它。
Host 通常不是网页地址，不能把包含路径的订阅链接整段填进去；端口也不能凭习惯猜测。涉及 TLS、服务器名称或传输路径等附加设置时，应与已有信息一致，不清楚的参数向你的服务商确认，不要为了尝试连接随意关闭校验。若持有自己的二维码，可使用 Scan QR Code 录入，完成后仍需核对 Type 和主要参数；Import from Cloud JSON 仅用于相应格式的数据，不是所有链接的通用入口。
保存后回到 Home，在 SERVER 分组中选择一个准备使用的服务器，并确认选中标记位于该条目旁。名称只是辨认标签，不等于协议或服务状态；首次测试应固定一个条目，避免每次同时切换多项条件。下一步再决定流量按什么方式处理。
Global Routing：选择 Config、Proxy 或 Direct
服务器条目决定连接到哪里，Global Routing 决定流量如何处理。返回 Home，点开 Global Routing，按当前目的选择配置(Config)/代理(Proxy)/直连(Direct)。这三个选项不是不同的服务器，也不会改变订阅本身。选择前先弄清当前是在验证服务器连接，还是已经准备按规则日常使用。
配置(Config)：依据当前配置的规则处理
配置(Config)会依据当前选用配置中的规则决定处理方式。需要按域名、地址或其他条件分流时使用这一姿态，但前提是已经核对实际启用的配置。进入底部 Config 页面，找到当前选用的配置并查看内容；如果不确定已有配置来自哪里、包含哪些规则，应先了解内容再使用，不要只看文件名称。
右侧截图是 Config 的配置编辑页面，不是 Global Routing 的选择菜单。其中 General、Rule、Hosts、URL Rewrite 与 HTTPS Decryption 属于不同配置分段，Add Rule 用于添加规则。本次入门不要求修改这些分段，也不需要为建立普通连接开启 HTTPS Decryption 或安装证书。
订阅和配置不能混为一谈：服务器订阅主要用于取得连接条目，配置则描述规则与相关设置。不要将订阅链接直接当作规则文件地址使用。已有完整配置时，应先确认其中引用的策略与当前服务器选择相符；规则指向不存在的策略，可能出现连接开关已开启但部分请求不能按预期处理的情况。
代理(Proxy)与直连(Direct)：用于明确目的的对照
代理(Proxy)将由客户端处理的流量交给所选代理服务器，适合在排查时暂时减少规则分流带来的变量，但并不保证所有目标都能正常访问。直连(Direct)则按直连方式处理，可用于与当前基础网络的结果进行对照；选择 Direct 不是修复服务器参数的方法，也不能用它来证明代理服务器已经可用。
初次按规则使用时，选择 Config 并核对当前配置；若要区分“规则问题”与“服务器连接问题”，可以记录原选项，临时切换到 Proxy 对同一目标进行测试，完成后恢复原选项。不要每次遇到问题就同时换服务器、改规则和切换模式。有关规则匹配的详细解释可继续阅读功能与设置，常见模式疑问见疑难解答。
Home：打开开关并确认系统授权
完成添加和模式选择后回到 Home，再检查两处：SERVER 分组中选中的是准备测试的服务器，Global Routing 显示的是刚才确定的选项。如果曾临时选择 Direct 做对照，连接前应根据本次目的调整回来。先检查当前 Wi-Fi 或蜂窝网络本身能否正常使用，再打开顶部连接开关。
首次建立连接时，系统可能提示允许添加 VPN 配置。这是 iPhone 或 iPad 用于管理相关网络连接的系统授权步骤，不是订阅登录页面。阅读提示中的应用名称与说明，确认本次操作由 Shadowrocket 发起后，按系统要求使用设备认证方式完成确认。若暂时取消授权，本次连接不能继续；需要时回到应用重新发起，不必先删除已导入的服务器。
确认授权后返回 Home，观察顶部原有的 Not Connected 状态是否发生变化，开关是否保持开启。不要只凭开关动作就立即判断设置已完成：系统连接建立、服务器可以访问、目标页面正常打开，是需要分别验证的结果。某些参数错误可能在实际发起请求时才显现，所以还要完成下一步的测试。
如果开关很快关闭、系统持续弹出授权提示，或界面报告错误，先记录完整提示，再关闭连接检查。到设备的系统设置中核对 Shadowrocket 对应的 VPN 配置是否存在，以及设备是否有影响配置变更的管理限制。不要反复删除系统网络设置；这可能影响其他已保存的连接，也不能替代对错误参数的核对。
这一轮先保持手动连接，不急于设置 On Demand。自动连接条件应建立在手动连接已经稳定可用的基础上，否则排查时容易把“条件触发了连接”和“服务器能正常使用”混在一起。需要断开时，返回 Home 关闭顶部开关，再进行后续参数修改或基础网络对照。
Connectivity Test：测试后再检查实际访问
连接建立后，在 Home 使用 Connectivity Test 做初步检查。测试结果取决于当前测试方式与目标，能帮助判断对应测试是否得到响应，但不能代表所有应用、所有网站都正常。不同测试方式的数值也不适合直接放在一起比较；排查时应尽量保持相同方式和同一网络环境。
接着打开实际需要使用的页面或应用，检查能否完成一次完整请求，而不是只看首页是否显示了缓存内容。可以刷新页面、打开一个此前没有加载过的页面，并观察图片、登录或后续请求是否正常。若只有某个目标失败，先记录该目标与发生时间，不要马上认定整个连接都失效。
验证时应把三个问题分开：第一，系统连接是否保持建立；第二，所选服务器对当前请求是否可用；第三，Config 下的规则是否把该请求交给预期策略。连接保持开启只回答第一项，Connectivity Test 通常也只覆盖特定测试条件。需要确认某个请求是否命中预期规则时，应结合应用当前提供的连接或诊断信息查看，不能单凭网页能否打开判断。
如果 Config 下访问失败，可先记住原设置，暂时用 Proxy 对相同目标进行一次对照。Proxy 可用而 Config 不可用时，重点检查配置、规则顺序及策略引用；两种方式都失败时，再检查服务器参数、服务状态和当前网络。Direct 的结果则用于观察基础网络下该目标的表现，不应据此推断代理连接的安全性或完整性。
验证通过后，恢复准备日常使用的模式，再检查一次实际目标。若要从 Wi-Fi 切换到蜂窝网络，切换后也应重新验证；一次测试成功不意味着所有网络条件下都相同。测试方式、规则细节或单个目标异常的进一步解释见疑难解答，无需在首次上手时修改全部高级选项。
Settings：检查常见失败点
遇到失败时，先保留现有条目与配置，关闭连接，再按下面的顺序检查。一次导入失败不等于应用安装错误，一次测试超时也不等于所有服务器都不可用。将错误定位到导入、授权、连接或规则中的某一环节，比反复重装更有帮助。
订阅保存了，但 SERVER 中没有可用条目
先确认添加时选择的是 Subscribe，而不是将订阅地址填进普通服务器的 Host。重新核对完整链接是否与原始信息一致，是否已经过期或被替换，以及当前网络能否完成订阅请求。某些订阅需要有效的服务状态才能返回内容，这部分应从你的服务商处确认；本站不能代为查询订阅账户或提供替代链接。
若导入后有条目但部分内容看起来不完整，先检查返回内容是否适用于所选导入方式，不要手动拼接不明参数来凑齐字段。保留错误提示即可，向他人描述时不要附上完整订阅链接，尤其注意链接末尾的凭据与查询参数。
能选择服务器，但连接后访问失败
对照原始资料逐项核对 Type、Host、Port、认证信息与附加传输设置。手动输入容易出现空格、大小写或字符混淆；复制内容时也要留意是否把说明括号一起带入。涉及证书或 TLS 的报错，应先核对服务器名称、设备日期时间与服务端要求，不要把关闭验证作为通用解决办法。
基础参数一致后，再在同一网络、同一模式下测试另一个自己已有的服务器条目。如果仅一个条目失败，优先确认该条目的服务状态；如果切换到另一种网络后结果改变，则重点关注网络条件。对 UDP 有要求的连接尤其需要核对网络是否允许相关流量，不应只根据服务器名称判断可用性。
测试有结果，但某个页面或应用仍异常
进入 Settings，查看 Test Method，先确认此前测试究竟检查了什么。测试响应不是完整业务请求的替代，单个目标异常还可能涉及 DNS、规则选择、目标服务状态或应用自身缓存。返回 Global Routing 做一次有记录的模式对照，再决定是否需要检查 Config 中的 Rule，不要一次添加多条覆盖范围过大的规则。
需要更多线索时，可查看 Settings 中的 Diagnostics。记录失败发生时的模式、网络、操作步骤与错误文字；分享诊断内容前，检查是否包含服务器地址、密码、认证信息、订阅地址或个人访问记录，并移除不必要的敏感内容。截图也应先检查，不能因为来自设置页面就默认适合公开。
手动连接正常，再考虑 On Demand
On Demand 用于按条件触发连接，不是提升服务器可用性的开关。首次使用建议在手动连接与规则验证完成后再设置，并逐项核对触发条件。Settings 中的 Proxy、TCP、UDP 等分类也不需要为了“完整设置”全部修改；只有明确问题对应哪项设置时，才记录原值并做单项调整。
完成上述检查后，若仍有问题，可到疑难解答按现象继续查找。购买、商店地区、已购恢复等问题不属于连接排错，请阅读App Store 获取指南。保留可复现的步骤和准确提示，通常比“无法使用”这样的概括更容易确定下一项检查。
完成后保留这三项记录
确认当前选中的服务器、Global Routing 姿态和实际使用的 Config。以后更新订阅或调整配置时，先记下原有状态，变更后再用同一个目标验证。自己的订阅凭据与服务器认证信息应妥善保存，购买应用的记录与连接配置则分开管理。
本教程以完成一次可验证的连接为终点。日常使用中，新增规则、自动连接或更换测试方式都应有明确目的，不必为了与截图完全一致而改动已经正常工作的设置。