Shadowrocket 连接不上节点怎么办？按症状排查 VPN、订阅与路由
简答：Shadowrocket 连接不上节点时，先不要同时更换节点、DNS 和规则：先确认 iPhone 普通网络正常，再判断是 VPN 开关、单个节点、全部节点、订阅还是路由规则的问题。Shadowrocket 本身是用于规则分流和代理连接的客户端，并不包含节点或订阅服务，App Store 页面也说明它支持规则、DNS、连接与流量相关功能。你可以按本文的症状表逐项测试，每次只改一个设置，并用同一网络、同一节点和同一网页复测。
定义：Shadowrocket 是运行在 iPhone、iPad 等 Apple 设备上的规则代理客户端，节点和订阅信息需要用户自行准备。
先看症状：Shadowrocket 连接不上节点属于哪一种
先记录当前现象，不要立即重装应用或修改 DNS。Shadowrocket 的 App Store 页面将它描述为规则代理工具，并列出服务器连接、规则匹配、DNS 请求记录和连接速度测量等能力；因此“开关已打开”“Connectivity Test 有响应”和“目标网页能正常访问”并不是同一个结果，应该分开验证。App Store 中的 Shadowrocket 页面也明确说明它是独立的网络工具，不包含代理服务或服务器资源。
| 看到的现象 | 优先检查 | 下一步 |
|---|---|---|
| 开关无法开启，或点开后马上关闭 | iOS VPN 授权、其他 VPN、设备管理或配置文件 | 重新开启并观察系统授权提示；检查“设置 → 通用 → VPN 与设备管理” |
| 显示 Connecting，几秒后断开 | 当前网络、节点地址和端口、认证参数、TLS 或时间 | 先在 Wi-Fi 与蜂窝数据之间对照，再只测试一个节点 |
| 只有一个节点失败 | 该节点的地址、端口、协议、密码、TLS、SNI 等 | 保留配置不变，换另一个节点做对照 |
| 全部节点都失败 | 订阅是否更新成功、当前网络、VPN 权限、设备时间 | 先验证普通网络，再重新更新订阅并检查节点列表 |
| 显示已连接，但网页打不开 | Global Routing、Config、规则匹配、DNS 和目标网页本身 | 先用 Proxy 与 Config 做对照，随后查看规则和请求记录 |
| 只有某个网站或应用打不开 | 该域名命中的规则是否为 DIRECT 或 REJECT | 检查活动配置文件中的规则顺序和最终策略，不要先判定节点失效 |
最重要的判断原则是：如果关闭 Shadowrocket 后，iPhone 的普通网页也打不开，先修复 Wi-Fi 或蜂窝数据；如果普通网络正常，才继续检查客户端、订阅和节点。
第一步：确认普通网络与 iOS VPN 权限正常
- 关闭 Shadowrocket。用 Safari 打开一个平时可访问的网页，分别确认当前 Wi-Fi 或蜂窝数据是否正常。如果普通网络本身失败，先切换网络、重新连接 Wi-Fi 或确认蜂窝数据权限。
- 重新打开连接开关。回到 Shadowrocket 的 Home 页面，只选择一个已有节点，再打开顶部连接开关。首次或重新授权时，iOS 可能显示允许添加 VPN 配置的系统提示；如果之前点过取消，需要再次发起连接并完成授权。
- 检查是否有其他 VPN 或配置文件占用设置。打开“设置 → 通用 → VPN 与设备管理”，查看不再使用的 VPN 或配置文件。Apple 说明，删除配置文件会同时删除与其关联的设置、应用和数据；如果设备属于学校或公司，删除前应先咨询管理员。可参考 Apple 关于 iPhone 配置文件安装与移除的说明。
- 暂时关闭自动连接条件。如果开关反复自动打开或关闭，先检查 Shadowrocket 的 On Demand 或 iOS 中其他自动连接设置。只做临时调整，完成测试后恢复原来的设置。
完成后应看到的结果是：普通网络可以访问，Shadowrocket 开关保持开启，状态不再马上回到关闭。如果仍然闪退式断开，先不要修改规则，继续检查节点和时间。
第二步：检查节点参数与订阅是否真的有效
- 确认选中的是具体节点。订阅导入后，列表里可能同时有分组、配置文件和多个服务器条目。测试时不要只停留在订阅名称或分组，进入 SERVER 列表并明确选中一个具体节点。
- 核对节点字段。根据你已有的服务信息，检查服务器地址、端口、协议、用户名或密码，以及 TLS、SNI、传输方式和认证字段。不同协议显示的字段可能不同；缺少任何一个必要参数，都可能出现连接超时、拒绝或 TLS 握手失败。
- 重新更新订阅。如果节点列表为空、节点数量突然减少，或更新后出现登录页、错误页、截断链接和带空格的订阅地址，先保留原订阅信息，再重新复制完整链接。不要把订阅链接、密码、UUID、密钥或二维码截图公开发给他人。
- 做单节点与多节点对照。先测试一个节点，再测试同一订阅中的另一个节点。如果只有一个节点失败，更像是该节点参数或服务端状态问题；如果全部节点失败，应回到网络、订阅、权限和时间检查。具体服务状态如果没有服务商公告或可复现证据，本文不作判断。
Shadowrocket 的 App Store 页面说明，应用支持多种规则、DNS 和连接相关功能，但它不提供服务器资源。因此，客户端能否连接还取决于你导入的节点信息是否完整、可用和与当前网络匹配。
第三步：用 Connectivity Test 和真实网页访问分开验证
- 固定测试条件。记录当前网络类型、节点名称、Global Routing 模式和要访问的同一个网页。测试期间不要同时切换节点、DNS、规则和 On Demand。
- 先运行 Connectivity Test。在 Home 页面使用 Connectivity Test，等待结果完成。它适合做节点可达性的初步检查，但有响应不等于所有网站和应用都能访问；无响应也需要结合当前网络、节点参数和测试方法判断。
- 再访问真实网页。保持同一个节点和网络，用 Safari 打开同一个目标网页。如果测试有响应但网页打不开，优先检查路由模式和规则，而不是马上重新导入订阅。
- 记录结果。至少记录“节点名称、Wi-Fi 或蜂窝数据、测试结果、网页表现、错误提示、Global Routing 模式”。这比只说“连不上”更便于自己定位，也便于向服务提供方提交经过打码的排查信息。
| Connectivity Test | 真实网页 | 更应检查什么 |
|---|---|---|
| 失败 | 失败 | 当前网络、节点地址端口、认证参数、订阅、设备时间 |
| 成功 | 失败 | Global Routing、活动 Config、规则命中、DNS 或目标网页 |
| 成功 | 部分成功 | 具体域名的规则、DIRECT 或 REJECT 策略、IPv4/IPv6 差异 |
| 不同网络结果不同 | 不同网络结果不同 | 分别记录 Wi-Fi 与蜂窝数据，避免把网络差异误判成节点参数错误 |
如果你还需要比较节点延迟和实际访问表现，可以参考站内的代理节点速度与延迟测试方法，但不要把延迟数值直接当成网页访问成功的证明。
第四步：排查 Global Routing、Config 与规则命中
- 先做 Proxy 与 Config 对照。在 Home 页面找到 Global Routing。Config 会按照当前活动配置文件中的规则处理请求；Proxy 通常用于把请求统一交给所选代理；Direct 则直接连接。先保持节点不变，记录 Config 下的网页结果，再临时切到 Proxy 测试同一网页。
- 如果 Proxy 成功、Config 失败，检查活动配置。确认导入的 Config 已启用，而不是只导入但没有选中。再查看目标域名是否被规则匹配为 DIRECT、REJECT 或其他策略。规则通常按顺序匹配，前面的宽泛规则可能在更具体的规则之前生效。
- 检查最终规则。如果目标域名没有命中前面的规则，通常会落到 FINAL 或配置文件规定的最终策略。不要只看自己想修改的那一条规则，要同时检查它之前的域名、关键词、IP 段和规则集。
- 一次只改一条规则。修改前保留原 Config 备份，改完后只测试同一个网页。如果变化不符合预期，恢复原规则，避免把多个变量叠加在一起。
如果你不确定 Config 和 Proxy 的区别，可先阅读站内的规则模式与全局模式对照说明，理解“客户端连接状态”和“请求实际走哪条路由”并不是一回事。本文仍以 Shadowrocket 的菜单和测试流程为准。
第五步：检查 DNS、设备时间与 TLS 错误
- 先看错误类型。“连接拒绝”更应检查地址、端口和服务端是否接受连接；“超时”要对照当前网络和节点可达性；“TLS 握手失败”则要检查设备时间、TLS 相关参数、SNI 和协议配置。仅凭一个错误词不能确认具体原因。
- 确认设备时间。打开“设置 → 通用 → 日期与时间”，开启“自动设置”。Apple 建议设备连接互联网并使用自动设置，以便根据时区调整日期和时间；时间明显错误时，证书和 TLS 校验可能出现异常。可参考 Apple 关于设备日期、时间和时区的说明。
- 不要一上来就换 DNS。DNS 只负责域名解析，不能单独修复错误的节点地址、端口、认证或 VPN 授权。只有在 Connectivity Test 有响应、但某些域名无法解析或网页表现与规则不一致时，才记录原 DNS 设置，再一次只调整一个 DNS 选项。
- 检查 IPv4 与 IPv6 表现。如果 Wi-Fi 可以、蜂窝数据不行，或同一个节点在不同网络表现不同，记录两种网络下的结果。不要为了“试试看”长期关闭系统网络能力或 TLS 校验；这可能掩盖真正配置问题，也会降低安全性。
完成 DNS 或时间的临时调整后，应恢复原设置并用同一节点、同一网络和同一网页复测。若只有某个域名失败，优先查看规则命中和解析记录，不要直接认定所有节点不可用。
第六步：复测、整理日志并安全求助
- 恢复测试环境。确认是否需要恢复原 DNS、On Demand、Global Routing 和规则设置。保留一个明确的测试组合：一种网络、一个节点、一个模式、一个网页。
- 按顺序复测。先关闭 Shadowrocket 验证普通网络，再打开客户端验证开关，再运行 Connectivity Test，最后访问真实网页。每一步都记录成功或失败，不要只记录最终结果。
- 安全打码。提交截图或日志前，遮挡订阅链接、服务器完整地址、用户名、密码、UUID、私钥、二维码、Cookie 和个人账号信息。错误提示和时间可以保留，但不要公开完整配置文件。
- 说明已经做过什么。向服务提供方反馈时，写明 iPhone 或 iPad、Wi-Fi 还是蜂窝数据、一个节点还是全部节点、Connectivity Test 结果、真实网页结果、Global Routing 模式和错误类型。不要只发送“连不上”。
如果以上步骤仍无法定位，最有价值的下一次动作通常不是继续乱改设置，而是用另一种网络重复同一组条件，并将结果与原网络逐项比较。
常见问题
Shadowrocket 开关一打开就自动关闭，怎么办？
先确认 iPhone 普通网络正常，再重新打开 Shadowrocket 并留意 iOS 是否出现允许添加 VPN 配置的系统提示。如果仍然马上关闭，检查“设置 → 通用 → VPN 与设备管理”中的配置文件和其他 VPN；设备属于学校或公司时，不要自行删除管理配置。Apple 说明，移除配置文件会删除与其关联的设置、应用和数据，具体操作前应确认影响。
Shadowrocket 显示已连接，但网页还是打不开，节点一定失效了吗？
不一定。开关和连接状态只说明本地连接流程达到某个阶段，不能证明每个域名都能访问。保持节点不变，先用 Connectivity Test，再用同一个浏览器页面测试；如果测试有响应但网页失败，检查 Global Routing、活动 Config 和规则是否把域名设为 DIRECT 或 REJECT。
Shadowrocket 只有一个节点连不上，其他节点正常，应该怎么处理？
先保留其他设置不变，核对该节点的服务器地址、端口、协议、密码、TLS 和 SNI 等参数，再用同一网络测试另一个节点作对照。若只有这个节点失败，更接近单节点参数或服务端状态问题；没有公开公告或可复现证据时，不应直接断定服务方故障。
Shadowrocket 全部节点都连不上，更新订阅有用吗？
可以先检查订阅是否更新成功，但不要只重复点击更新。确认订阅地址没有空格、截断或跳转到登录页，更新后检查节点列表是否正常出现；同时验证普通网络、VPN 权限和设备时间。如果 Wi-Fi 与蜂窝数据结果不同，分别记录两种网络下的测试结果。
Shadowrocket 需要马上修改 DNS 才能连接吗？
通常不需要。DNS 主要负责域名解析，不能修复错误的服务器地址、端口、认证参数或 VPN 授权。只有在节点测试有响应、但特定域名解析异常或规则结果不一致时，才应记录原设置并一次只修改一个 DNS 选项，测试结束后恢复临时改动。
向服务提供方提交 Shadowrocket 日志时，哪些内容必须打码？
至少遮挡订阅链接、完整服务器地址、密码、UUID、私钥、二维码、Cookie 和账号信息。可以保留设备类型、网络类型、时间、错误提示、Connectivity Test 结果、节点数量和 Global Routing 模式，这些信息更有助于定位问题，也不容易暴露凭据。