Shadowrocket
导入与连接教程
已有配置 → 选择模式 → 连接 → 验证 → 排错
本页以 iPhone 与 iPad 为操作对象，按首次使用的顺序说明需要点哪里、核对什么，以及何时继续下一步。截图为 App Store 官方截图，实际界面以设备上显示的内容为准。
STEP 01 / IMPORT
添加服务器与订阅导入
先判断手里的资料属于哪一种：只有一个完整地址、用于更新服务器列表的，通常是订阅；包含协议类型、服务器地址、端口和认证信息的，则适合按单台服务器添加。两种方式不必重复操作。已有订阅时优先按订阅导入，以便以后通过同一来源更新列表；只有服务器参数时，再逐项填写。
已有订阅：选择 Subscribe
打开 Shadowrocket，进入 Home，点右上角添加按钮或列表中的 Add Server。在添加页面点 Type，选择 Subscribe，将自己的完整订阅链接填入对应的 URL 输入项，再保存。截图展示的是单服务器表单；切换 Type 后，输入项会随类型改变，不应把订阅地址填进截图中的 Host。
粘贴前后核对链接是否完整，尤其注意问号后的参数、末尾字符，以及聊天应用复制时可能带入的空格或换行。订阅地址常包含访问凭据，不要把它贴到公开评论或截图中。保存后返回 Home，等待内容获取完成，确认订阅分组下已经出现服务器，而不只是多了一个订阅名称。
若列表仍为空，先检查订阅能否成功更新、地址是否有效以及当前网络是否可访问该地址。更新失败与服务器连接失败属于两个阶段：前者还没有拿到列表，不能通过反复打开连接开关解决。具体错误含义可继续查阅疑难解答。
已有服务器参数：填写 Add Server
在 Add Server 中，先选与资料一致的 Type，再填写 Host 与 Port。截图中的 Password、Method 属于该类型的字段示例，其他协议可能显示不同的认证或传输项。不要为了让表单看起来完整而猜测字段，也不要把一种协议的密码直接套用到另一种协议。
Host 应填写服务器域名或地址，Port 填对应端口；其余字段按自己的服务商或服务器配置逐一核对。使用 Trojan 等带有 TLS 设置的类型时，还应核对服务器名称等相关参数，不能只确认地址和密码。二维码资料可以通过 Scan QR Code 识别，但识别完成后仍要检查 Type 与目标服务器是否正确。
保存并返回 Home 后，在 SERVER 列表中确认新条目存在。此时先选中一台要使用的服务器；列表存在只说明资料已保存，并不代表连接已经建立。完成这一步后，再确定这些请求将按哪一种模式处理。
STEP 02 / ROUTING
选择 Global Routing
回到 Home，点 Global Routing。这里决定请求如何选择连接策略，不是用于选择订阅来源。首次使用先理解三种姿态：配置(Config)/代理(Proxy)/直连(Direct)。选择哪一种，应由本次要验证的目标决定，而不是认为某种模式始终更合适。
配置(Config)：按当前配置处理
Config 按当前配置中的规则决定请求走向。进入应用的 Config 页面，确认已有并选用了要使用的配置文件；如果自己的服务商给的是服务器订阅，不要据此推断已经同时导入了规则配置。服务器列表与配置文件用途不同，前者提供连接目标，后者描述如何处理请求。
右侧官方截图展示配置编辑页中的 General、Rule、Hosts、URL Rewrite 与 HTTPS Decryption 分段。首次连接不需要逐段修改。尤其不要把订阅链接直接贴进 Rule，或为了完成教程而开启与当前需求无关的处理功能。
例如，下面规则表达“匹配 example.com 及其子域名时使用 PROXY，其他请求落到 DIRECT”。这只是用于理解的局部语法，不是可以替代现有文件的完整配置，也不代表所有网站都应采用相同策略。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT在 Config 模式下，一些请求直接连接、另一些请求使用代理，可能正是规则的预期结果。若需要调整匹配顺序、策略名称或兜底规则，请转到规则与配置参考大全，不要在第一次连接时一次改动整份配置。
代理(Proxy)与直连(Direct)
Proxy 将一般请求交给所选代理，可用于临时缩小排查范围：先确认服务器本身能否完成访问，再回到 Config 检查规则差异。Direct 则采用直接连接，不通过所选代理服务器访问；因此即使连接开关打开，也不能仅凭这一点判断正在使用该服务器。
选好模式后返回 Home，确认 Global Routing 显示的值与刚才的选择一致。若只想验证代理连接，可以先记下原模式，临时选 Proxy；验证结束后再恢复计划长期使用的 Config。下一步再打开连接，避免把“资料保存”“模式选择”和“连接建立”混在一起判断。
STEP 03 / CONNECT
打开开关与系统授权
现在回到 Home，再次确认 SERVER 中已经选中了要连接的服务器，而不是只打开了该条目的编辑页。接着检查 Global Routing，最后打开顶部连接开关。右侧截图中的 Not Connected 是尚未连接时的状态，截图本身不代表当前设备状态。
首次建立连接时，系统会请求允许添加 VPN 配置。阅读系统弹窗并确认由本次操作触发后，按提示允许，再完成设备密码或系统要求的身份验证。这里是在授权应用配置系统网络连接，与输入服务器密码是两件事；系统验证应在系统界面完成，不应填进 Add Server 的 Password。
若刚才取消了系统授权，先回到应用重新发起连接，查看是否再次出现提示。没有完成授权时，不要把开关自动关闭误判为订阅失效，也不要立即删除所有服务器。先完成这个前提，再观察后续状态，能够少做很多无关修改。
连接状态需要回到 Home 核对
授权完成后返回 Shadowrocket，观察顶部状态是否已经离开 Not Connected，开关是否保持开启，以及是否出现错误提示。系统中的 VPN 标识可以辅助确认隧道状态，但它不能说明某个具体网页使用了什么策略，更不能证明所有服务器字段都正确。
若开关立即关闭，先记录提示内容，确认应用获得的系统权限，再检查是否有其他活动的 VPN 连接影响本次测试。不要连续快速切换开关，也不要在连接尚未稳定时同时更新订阅、更换模式与修改配置，否则很难确认是哪一步改变了结果。
当开关保持开启后，先保留当前选中的服务器和模式不变，进入下一步验证。需要停止本次连接时，回到 Home 关闭同一开关即可。首次测试完成前，暂时不必启用 On Demand，避免按需连接条件使手动测试的状态变得难以判断。
STEP 04 / VERIFY
验证连接与实际访问
验证应分成三个层次：服务器测试是否有结果、实际网页是否能完成加载、请求是否按预期策略处理。这三项互相关联，但不能互相替代。只看开关开启或某个测试数值，容易漏掉解析、认证、规则或目标网站自身的问题。
先用 Connectivity Test 检查连通性
在 Home 点 Connectivity Test，等待测试结束，查看所选服务器对应的结果。它可以帮助发现当前不可达的连接目标，但测试结果受测试方法与网络环境影响。数值较小不等于所有网页都能打开，测试失败也需要结合实际访问再判断，不能直接当作订阅内容已全部失效。
如果同一订阅中有多台服务器，可以在保持网络、模式和配置不变的情况下，改选另一台再测。这样是在对照一个变量，而不是同时改变整套使用条件。不要为了追求某个测试数值频繁修改协议字段；参数是否正确应以自己的服务器资料为依据。
再用实际请求检查访问结果
保持连接开启，切到浏览器，访问一个日常使用且有权访问的网页，确认页面不只是出现标题，还能加载正文。随后再换一个正常使用的目标做对照。单个网站无法访问时，也可能是该网站、账号状态或对应规则的问题，不应直接推断整个连接都失败。
若采用 Config，结合应用内请求记录核对目标域名、命中的规则及策略。预期走代理的请求应使用相应的代理策略；预期直接访问的请求则可能命中 DIRECT。记录中能看到什么应以当前应用显示为准，不要将 Direct 模式下的访问成功算作代理服务器已经通过验证。
如有必要，可以记住当前设置，临时切换到 Proxy 后重试同一目标，再恢复 Config。Proxy 成功而 Config 失败时，优先检查规则、策略引用和解析差异；两种模式都失败时，优先回看服务器信息与网络。完成测试后，恢复预期的日常模式，并保留已经验证可用的配置作为后续排错基线。
STEP 05 / DIAGNOSE
连接失败的排查顺序
遇到失败时，先保留一条明确现象：是订阅更新失败、开关无法保持开启、Connectivity Test 没有结果，还是只有网页打不开。不同现象对应不同阶段。按下面顺序逐项检查，每次只改一个设置，再用第四步的方法复测，避免在没有证据时重建全部内容。
先排本地网络，再查连接资料
关闭 Shadowrocket 连接，确认当前 Wi-Fi 或蜂窝网络能够完成基本访问。如果本地网络本身不可用，先处理网络登录、信号或联网权限。然后回到 Home，确认选中的仍是计划测试的服务器；若订阅内容近期发生变化，先更新已有订阅并查看更新结果，不要反复添加同一个地址造成重复条目。
单服务器方式则回到 Add Server 逐项对照 Type、Host、Port 和认证信息。复制内容多出空格、端口填错、协议选择不一致，都可能使保存成功但连接失败。带有 TLS 或额外传输设置的服务器，还需核对对应参数。不要通过随意关闭验证来绕过错误，应先确认服务器资料与设备时间是否正确。
测试有结果，但网页打不开
先记下当前 Global Routing，比较 Proxy 与 Config 下同一请求的结果。如果只在 Config 下失败，检查目标命中的规则、策略是否引用了可用服务器，以及 FINAL 兜底是否符合预期。如果两种模式下都失败，再检查服务器有效性、解析与实际访问链路，不要因为测试出现数值就排除这些可能。
DNS 问题与规则问题可能表现得很相似。可以结合错误提示和请求记录判断是否已经解析出地址，是否发生连接超时，以及是否命中 REJECT。不要把网上看到的整段 DNS 配置直接覆盖到现有文件；先保存原配置，再针对发现的原因做最小改动。详细说明见连接与解析疑难解答。
Settings 中先检查，不集中改动
进入 Settings，可以看到 Test Method、On Demand、Diagnostics 以及 Proxy、TCP、UDP 等相关项目。Test Method 会影响测试使用的方法，比较结果时应保持一致；On Demand 与按条件连接有关，手动排查时先确认它是否会重新触发连接。不要把 Settings 中的 Proxy 项与 Global Routing 的 Proxy 模式混为一谈。
需要进一步定位时，再按 Diagnostics 中实际提供的项目进行检查。记录错误出现的时间、当前网络、所选模式和复现操作，比只记录“连不上”更有帮助。向自己的服务商反馈前，遮住订阅地址、认证字段及其他访问凭据，只提供与问题有关的状态和错误信息。
如果另一台服务器在同样条件下可用，而当前服务器持续失败，可以先保留可用结果，再向自己已有服务的提供方核对故障目标。若所有目标都异常，则继续检查本地网络、系统授权与当前配置。完整问题分类在疑难解答，规则写法与文件结构在配置大全；本页到此完成首次导入、连接与验证流程。
