官方手册 · 首次连接
Shadowrocket 使用教程
从导入到连接验证
先导入已有资料，再确认分流方式，最后用实际访问验证。首次配置按下列五步进行；已有配置的用户，可直接跳到遇到问题的环节。
- 适用 iPhone / iPad
- 保留英文界面词
- 按失败位置排查
STEP 01 · 资料进入客户端
Add Server：添加服务器或导入订阅
先判断手里的资料属于哪一类：一条用于更新服务器列表的订阅链接，还是单台服务器的地址、端口和认证信息。两种资料进入应用的方式不同，不需要同时操作。打开 Shadowrocket，进入 Home，点击右上角添加入口进入 Add Server；完成保存后应回到 Home 检查结果，而不是停留在编辑页直接尝试连接。
已有订阅链接：使用 Subscribe
在 Add Server 中打开 Type，选择 Subscribe，再将已有订阅链接完整填入 URL。备注可使用自己容易辨认的名称，例如“日常订阅”，不要把密码或链接中的认证内容写进备注。确认后保存，等待订阅读取完成。成功时，Home 的列表中会出现该订阅对应的服务器项目；只有订阅名称、却没有可选服务器时，先检查更新结果。
复制链接时尤其要注意开头、结尾与中间参数。聊天消息里的说明文字、换行、空格或句末标点都不属于链接，不应一起填入。下面只是字段形态的教学示例，不能作为实际订阅使用，也不需要打开它。
https://example.com/sub?token=xxxx导入成功后，先保留这一份订阅，不要因为列表尚未刷新就连续创建多个相同项目。需要重新拉取服务器列表时，对已有订阅执行更新即可。订阅地址本身可能包含访问凭据，应像密码一样保管；把问题截图发给他人前，要遮住完整 URL 及其中的参数。更新与多订阅整理的详细方法见订阅手册的更新策略。
已有单台服务器资料：按协议填写
若拿到的是服务器字段，在 Add Server 的 Type 中选择资料明确指定的协议，例如 Shadowsocks、VMess、VLESS 或 Trojan。随后填写地址、端口与该协议要求的认证信息。协议不同，后续字段也会不同；不能把某一种协议的密码、UUID 或传输参数随意套到另一种协议上。填写顺序应以资料和当前表单为依据。
保存前逐项核对地址是否带入了多余空格、端口是否完整、认证内容是否漏字符。若资料还要求 TLS、传输方式或服务器名称，也要保持一致，不要为了让表单看起来更简单而删掉这些参数。对某个字段没有把握时，应向你的服务商确认，而不是反复尝试不同组合。表单可以保存，只说明输入被接受，不代表远端一定能够连接。
二维码与剪贴板资料：先确认内容类型
已有适用于导入的二维码时，可使用 Scan QR Code，并按系统提示给予必要的相机权限。二维码可能承载单台服务器分享链接，也可能承载订阅地址；识别后先检查结果，确认类型、备注和地址符合已有资料，再保存。剪贴板导入同样要先确认复制的是完整分享内容，而不是网页标题或普通说明文字。具体整理方式见扫码与导入说明。
完成任一路径后回到 Home，找到刚添加的服务器并选中。此时先不要连续修改其他设置：下一步要确定的是请求按什么方式处理。订阅负责提供服务器列表，规则配置负责决定流量走向；导入订阅成功，不等于已经导入或启用了适合自己的规则配置。
STEP 02 · 确认请求处理方式
Global Routing：选择配置、代理或直连
在 Home 找到 Global Routing 并打开选择界面。这里决定请求采用哪一种处理姿态，与上一节选中哪台服务器是两件事。三种姿态分别是配置(Config)/代理(Proxy)/直连(Direct)。先理解当前选择的含义，再打开连接，能够减少“服务器正常但访问结果不符合预期”的误判。
| 姿态 | 处理方式 | 何时使用 |
|---|---|---|
| 配置(Config) | 按当前启用配置中的规则处理请求。 | 已有可信配置，并希望按规则区分不同请求。 |
| 代理(Proxy) | 将请求统一交由代理路径处理。 | 短时检查已选服务器的实际访问能力。 |
| 直连(Direct) | 请求采用直连方式。 | 需要比较基础网络状态或确认直连访问结果。 |
使用 Config 前，检查正在启用的文件
如果准备按规则分流，进入 Config 查看当前启用的配置文件，确认它是你打算使用的那一份。列表中存在文件，不代表它一定处于启用状态；也不要仅凭名称判断内容。规则按实际配置中的顺序检查，通常首条匹配后就执行对应策略，FINAL 用于最后的兜底处理。某条请求走 DIRECT 或 REJECT，可能正是配置规则的结果，并不一定是服务器失效。
首次使用、还没有确认规则内容时，不必马上编辑大量规则。可以先临时选择 Proxy，对一个普通网页进行验证，确认服务器路径能够工作，再切回 Config 比较结果。如果 Proxy 能访问而 Config 不能，应转向检查配置与规则命中，而不是立即删除订阅重新导入。规则的语法与设置解释可继续阅读功能与设置。
选定姿态后返回 Home，再次确认服务器仍是准备测试的那一项。后续若临时改变 Global Routing，测试结束应恢复自己的日常设置。不要为了排查一次问题，同时更换服务器、修改 DNS、切换模式并编辑配置；这些变化叠加后，即使访问恢复，也很难确定真正原因。
STEP 03 · 建立系统连接
Home：打开连接开关与 VPN 配置授权
回到 Home，确认已选中服务器、Global Routing 也符合本次验证目的，然后打开连接开关。首次连接时，系统可能弹出添加 VPN 配置的请求。这是让应用通过系统网络能力处理流量所需的授权，不是让你再次导入服务器。应先确认提示由当前操作触发，再按系统界面选择允许，并在设备上完成密码或生物识别验证。
授权完成后返回 Shadowrocket，观察连接开关是否保持开启。如果刚才没有完成系统确认，应用可能仍处于未连接状态；先处理权限提示，再尝试一次即可。若开关立即退回关闭状态，先不要反复快速点击，也不要连续添加多份资料。检查是否存在尚未处理的系统弹窗，以及设备是否允许建立当前 VPN 连接。
分清 VPN 配置与规则配置
系统里的 VPN 配置记录用于建立应用与系统网络能力之间的关联；应用 Config 中的文件则用于规则、DNS 等处理设置。两者名称都可能包含“配置”，但用途不同。删除系统 VPN 配置不能修正一条写错的规则；更换 Config 文件也不能代替系统授权。只有明确问题属于哪一层，才考虑相应操作。
若此前拒绝了授权，可以重新触发连接并留意系统提示。若设备受管理策略限制，或系统提示无法添加 VPN 配置，应先检查设备管理要求，不要把这个问题当成订阅失效。需要核对系统记录时，在系统设置中搜索 VPN，查看与 Shadowrocket 对应的项目；修改前确认目标，避免影响仍在使用的其他网络设置。
完成授权且开关保持开启后，只能说明连接流程已经开始或系统连接状态已建立，不能据此推断每个网站都能访问。系统状态标识也不能代替应用层验证。接下来保留当前服务器和模式不变，按下一步检查实际网页请求，这样得到的结果才便于比较。
STEP 04 · 用请求结果验证
Connectivity Test：测试之后再验证实际访问
先使用 Connectivity Test 对当前服务器做初步检查。测试结果可以帮助判断特定测试条件下是否收到响应，但不等于所有域名、协议与业务请求都能成功，也不等于当前网页一定命中了这台服务器。不要只凭一个响应时间数值判断配置已经完成；仍需验证实际访问与分流结果。
保持 Shadowrocket 连接开启，切换到浏览器，打开一个你平时能够正常访问的普通页面，并进行一次刷新。随后再检查本次真正需要使用的服务。优先选择不涉及敏感操作的页面，暂时不要用支付、提交表单或大文件传输作为首次验证手段。页面已经缓存时，单看旧内容不能证明新请求成功，可打开站内另一个页面辅助判断。
把结果分为三层记录
- 服务器测试：Connectivity Test 是否有响应，是否所有项目都失败。
- 实际访问：普通网页能否加载，问题是否只发生在某个服务。
- 规则路径：当前是否为 Config，目标请求是否按预期使用 PROXY、DIRECT 或 REJECT。
需要确认规则时，结合应用当前可用的连接记录或日志，查找刚才的目标域名与处理策略。不同界面提供的信息可能不同，只根据实际显示的字段判断，不要把未显示的项目推测成已经通过。使用 Config 时，一个页面也可能发出多个域名请求；主页面能打开、其中某个资源失败，需要分别看对应请求，不能只检查地址栏里的域名。
若测试与网页都正常，回到应用确认日常所需的 Global Routing 已恢复，并记下本次可用的服务器与配置名称。首次验证期间可先保持 On Demand 不变；等手动连接行为确认正常后，再按自己的网络条件单独设置 On Demand。它负责按条件触发连接，不会自动补齐错误的服务器字段或修正失效订阅。
如果只有部分步骤通过，也不要急着清空配置。保留当前结果，进入下一节按症状定位：导入、远端响应、系统连接、DNS 与规则属于不同环节，分别检查通常比一次性重做全部步骤更有效。
STEP 05 · 一次处理一个失败点
Shadowrocket 连不上：按现象逐项排查
先记录失败发生在哪一步：保存不了、更新不了、服务器测试失败、连接开关退回，还是连接后网页打不开。保留原来的可用配置，每次只修改一个变量，并用同一个页面重新验证。不要一开始就删除全部服务器、清空 Config 或重置所有网络设置，这些操作会同时移除排查依据。
订阅更新失败，或列表中没有服务器
先确认设备基础网络能够访问普通网页，再核对 Subscribe 中的 URL 是否完整。若链接参数遗漏，或复制时混入换行和标点，重新从你的服务商处获取完整链接并替换。若资料已经变更，应更新原订阅而不是重复添加多个副本。仍失败时，记录应用实际显示的错误内容，并向你的服务商确认链接是否有效、返回内容是否适用于导入。
订阅更新失败与已有服务器能否连接需要分开判断。有时列表尚在，但订阅读取暂时失败；也可能更新成功，某台服务器却不可用。因此先检查当前列表与选中项目，不要把“能更新”当成“全部服务器可用”的证明。关于更新后项目变化与多订阅管理，见订阅更新说明。
Connectivity Test 失败
手动添加的服务器先回到 Add Server 编辑界面，对照已有资料核对协议、地址、端口和认证字段，再看 TLS 与传输参数。订阅导入的项目先更新一次，确认测试的是仍在列表中的服务器。如果只有一项失败，可以选择自己已有的另一项对照；如果全部失败，先检查当前网络状态与共同使用的配置条件。不要用猜测的密码或端口反复尝试。
连接开关无法保持开启
回看是否完成了添加 VPN 配置的系统授权，以及是否还有未处理提示。若系统已显示明确错误，应先处理对应错误，再做服务器验证。设备切换网络后出现异常时，可以先关闭连接，等待基础网络恢复，再重新开启；每次观察结果后再进行下一步。受管理设备的限制需要按设备管理要求处理，修改服务器内容通常不能解决系统权限问题。
测试有响应，但网页打不开
先确认问题是所有页面都有，还是仅某个域名或某个应用出现。保持服务器不变，临时从 Config 切到 Proxy 做一次对照：若 Proxy 正常、Config 异常，优先检查当前配置的规则与 DNS；若两者都异常，再回头检查服务器参数、远端状态与当前网络。比较结束后恢复原本需要的模式，不要把临时测试状态当成最终配置。
DNS 负责把域名解析为地址，服务器测试收到响应，并不能保证页面所需域名都能正确解析。先核对当前 Config 里的 DNS 设置是否来自自己确认过的配置，避免同时改动多个解析选项。详细的分层检查可阅读网页打不开但延迟正常的 DNS 排查说明。
反馈问题前，整理最少必要信息
记录设备类型、当前网络、Global Routing 选择、失败环节与错误文字，并说明是否只有某个目标受影响。不要发送完整订阅链接、密码、UUID 或其他认证信息；日志与截图也应先检查并遮盖敏感字段。描述“在 Proxy 可访问，切回 Config 后某域名失败”，比只说“连不上”更有助于定位。
需要重新检查前面的操作，可返回添加与导入、Global Routing 选择或连接授权，从第一个未通过的步骤继续。