添加服务器或导入已有订阅
手动填写单个服务器
打开 Shadowrocket 后先停留在 Home。在下方找到 SERVER 分组，点按 Add Server 进入添加页。第一项通常是 Type，这里必须与已有服务器资料标注的协议一致，例如 Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard 或 Hysteria2。协议只是字段结构的入口，不能仅凭端口或服务器名称推断。
选定 Type 后，按照原始资料逐项填写 Host、Port、Password、Method 以及该协议实际要求的其他字段。Host 应填写主机名或 IP 地址，不要附带说明文字；Port 只填写端口值；Password、UUID、Method、TLS 等内容要保持原有大小写和字符顺序。某个字段在资料中没有提供时，不要随意补值，应先核对该 Type 下是否确实需要。
Type: Shadowsocks
Host: example.com
Port: 443
Password: your-password
Method: 以已有资料为准上面的内容只用于说明字段位置，不是一组可连接的信息。填写完成后使用页面上的保存操作返回 Home。新条目应出现在 SERVER 分组中；点按该条目，使其成为当前选中的服务器。此时先不要急于改动 Global Routing，先确认名称、Type、Host 与 Port 均与原始资料一致。
通过 Subscribe 导入已有订阅
如果手中已有完整订阅链接，可在服务器或订阅管理入口选择 Subscribe。把链接完整粘贴到对应地址栏，按需要填写便于辨认的名称，然后保存并执行更新。示例形式可以写成：
https://example.com/sub?token=xxxx示例域名与参数仅展示链接结构。实际操作必须使用用户自己已有的完整地址。粘贴后重点检查三处：开头是否包含正确的 https://，地址中间是否因换行产生空格，末尾参数是否被聊天工具截断。更新成功后，Home 的 SERVER 分组会出现订阅返回的条目；更新失败则先保留原链接，不要连续新建多个同名 Subscribe 项目。
订阅是批量维护服务器信息的一种方式。以后服务方更新内容时，应在原有 Subscribe 项目上执行更新，而不是反复粘贴并生成重复列表。手动修改由订阅生成的条目，也可能在下一次更新时被订阅内容覆盖。若需要保留单独调整的服务器，应先明确该条目是否由订阅管理，再决定修改方式。
选择配置、代理或直连姿态
回到 Home，点按 Global Routing。中文说明中常把三个姿态写作配置（Config）、代理（Proxy）、直连（Direct）。它们决定流量进入 Shadowrocket 后采用哪种处理方式，不等同于服务器是否可用。
配置（Config）：按规则逐条判断
Config 适合日常规则分流。请求会按照当前配置文件中 Rule 的排列顺序从上到下匹配，命中第一条适用规则后采用对应策略。常见关键字包括 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、IP-CIDR6 与 USER-AGENT；处理结果通常是 PROXY、DIRECT 或 REJECT。具体结果取决于配置文件本身，而不是关键字名称。
进入 Config 后，先确认当前选中的配置文件，再查看 Rule。更具体的域名或地址规则通常放在较前位置，范围更广的规则放在后面，最终由 FINAL 处理此前未命中的请求。如果一条宽泛规则过早出现，后续更具体的条目就不会获得匹配机会。
代理（Proxy）：统一交给当前服务器处理
Proxy 用于把进入 Shadowrocket 的流量统一交给当前选中的服务器处理。它适合做短时对照测试：如果 Config 下某个目标不能按预期访问，而 Proxy 下可以，问题更可能位于规则匹配、策略名称或 Config 选择；如果 Proxy 下同样失败，则应优先检查服务器资料、连通性、DNS 或本地网络。
直连（Direct）：不交给代理服务器
Direct 让流量直接使用当前网络。它同样适合对照判断。例如某个目标在 Direct 下正常、Proxy 下失败，应回到服务器连通性与服务器参数检查；若 Direct 下也异常，问题可能来自当前 Wi-Fi、蜂窝网络、DNS 或目标本身。Direct 是排查姿态，不代表已经验证了服务器。
初次配置时，建议先用 Proxy 做一次服务器连通性基线，再回到 Config 检查分流结果。不要把 Global Routing 的切换当作永久解决方法：Proxy 能访问而 Config 不能访问时，应找出具体规则命中差异；Config 能正常工作后，才算完成规则层的设置。
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY这段规则只展示按序匹配的写法。第一条会优先处理指定域名后缀，局域网地址由 IP-CIDR 直连，未命中的请求最后进入 FINAL。实际配置应根据用户自己的使用目标整理。有关规则优先级、DNS 与复杂故障的系统化说明，可继续阅读故障排查文档。
打开连接开关并确认状态
连接前回到 Home，从上到下做一次快速核对：SERVER 分组里已经选中目标服务器，Global Routing 显示预期姿态，当前 Config 与规则也已确认。然后打开顶部连接开关。首次建立连接时，系统会显示 VPN 配置授权提示；按系统流程确认后，Shadowrocket 才能创建本机的网络通道。
开关打开后，Home 顶部状态应从 Not Connected 转为 Connected。状态变化表示本机通道已经建立，但不能单独证明远端服务器可用，也不能证明每个请求都命中了期望规则。因此看到 Connected 后还要继续进行 Connectivity Test 与实际请求验证。
如果状态短暂变化后立即回到 Not Connected，不要连续快速点按开关。先等待几秒，再检查当前服务器是否选中、字段是否完整，以及系统是否允许创建 VPN 配置。若系统中存在正在切换的其他网络状态，也应等 Wi-Fi 或蜂窝网络稳定后再试。
先建立单一、可重复的测试条件
首次测试时，不要同时开启 On Demand、频繁切换 Config 或连续更换多个服务器。建议固定一个网络、一个服务器和一种 Global Routing 姿态，完成一次完整验证后再改变下一项。这样可以把“开关无法保持”“服务器超时”和“规则命中不符”分开处理。
在 iPad 上，Home 可能因为横屏或分栏显示而改变项目排列，但操作逻辑相同：选服务器、看 Global Routing、开连接、再验证。Mac、Apple TV 与 Apple Vision 的兼容情况可在同一 App Store 产品页查看，系统要求以 App Store 页面标注为准；本页步骤以 iPhone 与 iPad 为主。
验证服务器连通与规则命中
验证应分为两层：第一层检查所选服务器能否建立有效连接，第二层检查实际请求是否按照 Global Routing 与 Config 规则处理。只看开关状态会遗漏远端超时，只看单次网页结果又难以区分缓存、DNS 与规则影响。
运行 Connectivity Test
在 Home 点按 Connectivity Test，对当前服务器执行连通性测试。若测试能够完成，说明服务器资料与当前网络至少具备基本通信条件；若出现 timeout 或持续无结果，先回到 Add Server 核对 Type、Host、Port、Password、Method 及协议所需字段。订阅生成的条目则先更新原 Subscribe，再重新选择服务器测试。
Connectivity Test 的结果只能作为连通性线索。它不会替代规则验证，也不能说明所有目标都采用相同路径。测试通过后，应保留当前设置，产生一次容易辨认的实际访问，再查看请求记录。
在 Data 或连接记录中核对结果
打开 Data 或应用内可查看连接记录的区域，清理视线后重新访问一次目标。找到新产生的请求，核对域名、目标地址、策略与规则信息。Config 姿态下，重点查看它是否命中预期的 DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR 或 FINAL，以及最终结果是 PROXY、DIRECT 还是 REJECT。
如果请求命中了错误规则，先检查顺序，不要先改服务器。规则按从上到下的顺序处理，先命中的条目会结束本次判断。例如，某个范围较大的 DOMAIN-SUFFIX 规则位于具体 DOMAIN 规则之前时，后者可能永远不会被使用。调整后应保存 Config，回到 Home 确认该 Config 仍处于选中状态，再重新产生一次请求。
用三种姿态做最小对照
- Direct 基线：短时切换为 Direct，确认当前本地网络是否能完成基础访问。
- Proxy 基线：切换为 Proxy，确认当前所选服务器能否处理访问。
- Config 验证：切回 Config，在 Data 中核对具体请求的规则与策略结果。
若 Direct 正常、Proxy 失败，应优先检查服务器资料与 Connectivity Test；若 Proxy 正常、Config 失败，应优先检查当前配置文件、Rule 顺序及策略引用；若三种姿态都失败，应先检查本地网络、DNS 与目标状态。每轮对照都使用同一个服务器和同一个目标，避免引入新的变量。
按层检查常见失败点
排错时按“输入资料—服务器连通—本机连接—Global Routing—Config 规则—DNS 与网络”的顺序进行。一次只修改一层，并在修改后重复相同测试。若同时换服务器、改规则和调整 DNS，即使恢复正常，也无法判断真正原因。
Subscribe 更新失败
先确认链接完整、没有空格或换行，开头协议与原始地址一致，末尾参数没有缺失。然后暂时关闭 Shadowrocket 连接，使用当前网络确认该地址能够被正常请求，再回到原 Subscribe 项目执行更新。不要用新建多个同名项目的方式覆盖问题；重复条目会增加后续选择错误的概率。
Connectivity Test 超时
手动服务器应逐项核对 Type、Host、Port、Password、Method、TLS 及协议要求的附加字段。由 Subscribe 生成的服务器先更新订阅，再重新选择目标条目。随后在 Wi-Fi 与蜂窝网络之间做一次单变量对照；若仅某个网络失败，继续检查该网络的 DNS、认证页面或连接限制。
显示 Connected 但无法访问
先切换 Direct 做本地网络基线，再用 Proxy 检查服务器基线。如果 Direct 可用而 Proxy 不可用，回到服务器与 Connectivity Test；如果 Proxy 可用而 Config 不可用，检查当前 Config、Rule 顺序、策略名与 FINAL。若状态显示 Connected，但 Data 中没有出现新请求，应确认系统 VPN 状态是否对应 Shadowrocket，并查看 On Demand 是否改变了连接触发条件。
只有部分目标结果不符合预期
这类问题通常位于规则层。先在 Data 中找到对应请求的真实域名或 IP，再检查它实际命中的第一条规则。不要只根据浏览器地址栏猜测，因为一个页面可能同时请求多个域名。对具体域名可使用 DOMAIN 或 DOMAIN-SUFFIX；对关键词范围要谨慎使用 DOMAIN-KEYWORD；地址段可使用 IP-CIDR 或 IP-CIDR6。添加规则后保存 Config，并重新产生请求验证。
DNS 解析异常
若 Connectivity Test 可以完成，但域名访问失败而直接地址表现不同，应检查 DNS。先恢复到可说明来源的 DNS 设置，避免同时叠加多种解析方式。随后分别在 Direct、Proxy 与 Config 下重复同一域名测试，并观察 Data 中是否出现解析后的连接。复杂的 Hosts、URL Rewrite 或 HTTPS Decryption 设置也可能改变结果，排查时可先确认它们是否与当前问题有关。
On Demand 导致状态反复变化
On Demand 会根据网络条件触发连接或断开。初次设置与故障定位期间，建议先关闭 On Demand，手动完成一次稳定连接；基础流程验证通过后，再回到 Settings 配置触发条件。若刚切换 Wi-Fi、离开某个网络或唤醒设备后状态变化，应同时查看 On Demand 条件，而不是只重复点按 Home 开关。
修改后仍无法判断原因
使用 Settings 中的 Diagnostics 与相关测试项目收集现象，记录当前网络、服务器名称、Global Routing、Config、Connectivity Test 结果和具体失败时间。分享诊断信息前应检查其中是否包含个人连接资料。更完整的无网络、节点超时、订阅失败、速度慢、DNS、耗电及 iPad 专项流程，可转到Shadowrocket 故障排查大全逐章处理。
保存可复现的正常配置
完成验证后，把 Global Routing 恢复到日常需要的姿态。使用 Config 时，确认选中的配置文件名称清晰，Rule 顺序能够解释实际请求；使用 Subscribe 时，保留一个主要更新入口，清理测试期间产生的重复项目。服务器名称可按用途整理，但不要修改由协议决定的关键字段。
建议记录一组最小正常状态：当前服务器、Global Routing 姿态、Config 名称、一次成功的 Connectivity Test 结果，以及 Data 中一条符合预期的规则命中。以后发生异常时，先与这组状态对照，比从头改动全部设置更容易定位。
换机或重新从 App Store 恢复 Shadowrocket 后，应用购买记录与服务器资料是两类内容。已购项目可按 App Store 流程恢复，订阅与 Config 则应按用户自己的备份方式重新导入。系统要求、兼容范围及购买显示均以 App Store 页面标注为准。
下一步：按症状继续排查
若基础设置已经完成，但仍遇到无法上网、超时、规则错误、DNS 或耗电问题，可进入长文档按症状逐项检查。