Shadowrocket 使用教程
从已有连接信息开始，按顺序完成导入、模式选择、连接与验证。
本页以 iPhone、iPad 上的操作为主。截图来自 App Store 官方素材；实际项目的位置与可用选项请以应用内显示为准。第一次配置先跑通一条连接，再逐项调整规则与自动连接设置。
01 添加服务器或导入订阅
先分清输入的是单个服务器参数，还是用于更新列表的订阅地址。
打开 Shadowrocket 后进入 Home，在 SERVER 分组附近找到 Add Server，也可使用页面上的添加入口进入。先不要打开顶部连接开关：此时最重要的是把连接资料准确保存下来。单条分享链接、订阅地址和配置文件的用途不同，不能只因它们都是一段文字就使用同一个入口。
已有服务器参数：使用 Add Server
进入 Add Server 后，先选择 Type。Type 应与已有信息中的协议一致，例如 Shadowsocks、VMess、VLESS 或 Trojan；不要根据名称相似程度猜选。选定后，页面会按协议显示相应字段。依照原始资料填写 Host、Port，以及该协议要求的身份认证信息。截图展示的是含 Password 与 Method 的一种表单，不代表所有 Type 都使用相同字段。
逐项核对时，Host 只填资料要求的服务器地址，不把整条网页地址误放进去；Port 按原值填写，不自行更换。Password、Method，以及其他协议可能出现的传输或安全设置，都应与原始资料一致。遇到未提供的可选字段，先保留默认值，不把其他协议的示例拼接过来。完成后使用页面的保存操作，返回 Home，确认 SERVER 中出现了刚添加的项目。
已有订阅地址：选择 Subscribe
如果持有的是可以更新服务器列表的订阅地址，在 Add Server 中将 Type 选择为 Subscribe，然后把完整地址填入对应的 URL 项，确认后保存并等待读取。保留地址中的全部查询参数，复制时注意开头、结尾以及意外混入的空格。订阅地址往往含有访问凭据，应视作密码保管，不要贴进公开留言或截图。服务器订阅用于取得或更新服务器列表，并不等同于 Config 中的规则配置文件。
若资料以二维码提供，可使用 Scan QR Code 识别；只有在持有相应格式内容时才使用 Import from Cloud JSON。识别成功后仍需核对 Type 和关键字段，不能把“读出了文本”当作“参数已经正确”。导入结束后检查列表是否有实际项目，并选中本次准备测试的服务器。若列表为空，先到失败点排查检查地址与读取结果，不必继续切换连接开关。
02 选择 Global Routing
服务器决定连接目的地，Global Routing 决定请求采用哪一种处理方式。
有了可选服务器后，回到 Home，点击 Global Routing。这里的选择与 SERVER 列表中的选择不是同一件事：选中服务器并不意味着每个请求都会使用它。首次操作先理解三种姿态，再决定这一次要验证什么，能减少“已经连接却与预期不同”的误判。
配置(Config)：按当前配置处理
配置(Config) 按当前配置文件中的规则决定请求去向。规则可能将部分请求交给 PROXY，部分交给 DIRECT，也可能用 REJECT 拒绝特定连接。因此，使用 Config 时看到某个请求直接连接，不一定是失效，也可能恰好符合规则。进入底部 Config 页面，确认正在使用的配置文件；打开文件查看时，可按 General、Rule、Hosts、URL Rewrite 等分段检查相关内容。
截图展示的是配置编辑页面，其中 Add Rule 用于添加规则。首次连接不需要立即编写大量规则：先确认所用配置的来源和内容，并保存可恢复的副本，再考虑修改。应用已有配置不应在不了解其用途时整份覆盖。尤其要查看 Rule 中的匹配顺序及最后的 FINAL，否则仅凭某一条规则的名称，很难判断实际请求会采用什么策略。
代理(Proxy)与直连(Direct)：用于明确对照
代理(Proxy) 将全局路由切到代理姿态，适合暂时排除规则分流对测试结果的影响；它不会修复错误的服务器地址、认证信息或传输参数。直连(Direct) 使用直接连接姿态，不用于验证代理服务器是否工作。两种姿态都应结合当前网络环境理解，不把它们当作提高连接成功率的固定开关。
如果你已经有明确可用的规则配置，日常使用可选择 Config；如果正在判断新添加的服务器是否可用，可先临时使用 Proxy 完成对照。测试结束后回到 Global Routing，恢复自己需要的姿态。更细的规则类型、PROXY／DIRECT／REJECT 策略与首条命中逻辑，见规则手册；本页继续完成首次连接，不展开复杂规则编辑。
03 打开连接并完成授权
先选定服务器，再处理系统提示，最后确认应用内的连接状态。
回到 Home，确认 SERVER 中当前选中的是刚才准备使用的项目，再核对 Global Routing。如果订阅里有多个项目，首次验证只使用其中一个已知参数完整的项目，记录其名称即可，不需要在多个项目之间连续快速切换。这样一旦出现问题，能够判断究竟是在检查同一条连接，还是测试条件已经改变。
打开 Home 顶部的连接开关。未连接时，页面可显示 Not Connected；开启后应观察实际状态变化，而不只是看手指是否碰到了开关。首次使用时，系统可能请求允许 Shadowrocket 添加 VPN 配置。这是应用通过系统网络扩展处理连接所需的授权步骤，不是购买确认，也不会补全缺失的服务器信息。
核对弹窗中的应用名称后，按系统提示完成允许及设备验证。若此前取消了授权，回到应用重新发起连接，并按系统界面提示处理。不要为了跳过弹窗而修改不相关的系统设置。系统界面的文字和验证方式可能随设备设置而不同，以当前屏幕实际提示为准。
完成后返回 Home，查看连接状态是否保持。系统已允许添加 VPN 配置，与远端服务器已经可访问，是两项不同检查。即便系统状态显示已连接，仍可能存在服务器认证失败、目标不可达或规则不符合预期等情况；下一步必须用实际请求验证，不能仅凭系统标识下结论。
首次配置期间，先保留可手动控制的连接流程。如果同时启用了自动连接设置，测试时手动关闭后又自动开启，容易误以为开关失灵。有关 On Demand 的行为可在 Settings 核对；在理解触发条件前，不必为了首次连通额外开启它。现在先让当前选择保持不变，进入下方的验证步骤。
04 验证连接与分流结果
按“应用状态 → 测试结果 → 实际访问”的顺序检查。
连接开启后，先使用 Home 中的 Connectivity Test 做一次检查。测试结果反映的是当前测试方式下的连通情况，不等于所有网站、所有协议和所有请求都能成功。出现超时也不能立刻认定订阅已失效：测试方式、测试目标以及当前网络状态，都可能影响结果。先记下这一次的现象，再去验证实际访问。
打开浏览器，访问一个你知道本来可用、并且与本次验证目标相关的页面。尽量使用新打开的页面或重新加载，避免把已经缓存的内容当作新连接成功。先确认页面能否完整加载，再检查具体资源或操作；一个页面的文字能显示，并不代表它引用的图片、视频或其他请求也使用了相同路径。
如果使用的是配置(Config)，对照当前配置中应当命中的规则，确认这个目标预期走 PROXY 还是 DIRECT。不能只根据“页面打开了”推断代理生效，因为该目标可能本来就走 DIRECT。如果需要判断所选服务器本身，可以临时切换代理(Proxy)，保持同一个服务器和同一个目标重新请求；测试后再恢复 Config。
对照时一次只改变一个条件。例如，先保持服务器不变，仅切换 Global Routing；或者保持模式不变，仅在自己的已有服务器中更换一个项目。不要同时更换服务器、重写配置和切换网络，否则成功或失败都难以归因。需要在 Wi-Fi 与蜂窝数据之间比较时，也应分别记录各自结果，而不是把两次不同条件的测试混为一谈。
05 按失败点逐项排查
从最早出现异常的位置开始，每次核对一层。
没有项目：回到导入环节
保存后 SERVER 仍为空，先检查使用的是服务器订阅地址、单条分享链接，还是规则配置文件地址。确认输入类型与入口相符，再核对地址是否完整、是否带有多余换行以及读取时网络是否可用。订阅返回的内容、有效状态与访问限制，需要由你已有信息的提供方核对；反复点击连接开关并不能修复导入失败。重新导入前保留原来的资料，避免误删后失去核对依据。
有项目但无法使用：核对参数与测试方式
手动填写的项目先逐项比对 Type、Host、Port 和认证信息，再检查该协议要求的传输与安全设置。订阅导入的项目则先确认是否成功更新，不要在不清楚含义时修改大量字段。进入 Settings 查看 Test Method，理解当前测试结果采用的方式；不同测试方式的结果不应直接当作同一种数值比较，更不能把其中一次结果作为全部连接的最终判断。
已连接但访问不符：检查模式与规则
先回 Home 核对 Global Routing：是否仍在直连(Direct)，或 Config 中的规则本来就把目标交给 DIRECT。若临时使用 Proxy 后可以访问、恢复 Config 后却不符合预期，应把重点放在当前配置、规则顺序和策略引用上，而不是重复导入同一个服务器。若两种姿态下均失败，再检查服务器本身、当前网络及目标是否可用。DNS 相关异常也应结合具体报错分析，不应只因页面打不开就任意更换所有解析设置。
开关自动恢复或诊断信息不清晰：查看 Settings
若手动关闭后连接又被触发，进入 Settings 核对 On Demand 是否启用，以及它是否符合当前测试需要。需要更多线索时，可查看 Diagnostics 中实际提供的诊断项目。页面中也可能显示 Proxy、TCP、UDP 等分类；这些不是首次连接必须全部修改的清单，不要为了排错把所有选项轮流开关。只操作与当前现象有关的项目，并记录原值以便恢复。
准备诊断记录时，写清“在哪一步失败、选用什么姿态、Connectivity Test 的现象、实际目标是否可访问”，通常比只说“连不上”更有帮助。分享内容前移除完整订阅地址、密码、认证标识和二维码，截图也要检查是否泄露这些信息。确认修复后，返回验证步骤重复同一组检查；需要继续理解配置结构、匹配优先级与规则片段时，再阅读规则手册。
