小火箭开关已打开却上不了网:服务器、Global Routing、DNS、规则四项逐一排查

本文速览

Shadowrocket（小火箭）的连接开关打开，只能说明本地连接流程已启动，不能单凭这一状态判断服务器、域名解析和分流规则均正常。本文适合已有自己的服务商与订阅、连接后网页仍打不开的用户，按服务器 → Global Routing → DNS → 规则的顺序缩小范围，并用同一目标复测，避免同时修改多个设置后无法确认原因。

先固定测试条件，区分本地网络与代理故障

系统显示 VPN 状态，不等于远端服务器已经完成认证，更不等于目标网站已能访问。Shadowrocket 可以先建立设备上的网络隧道，再按请求连接服务器；因此，即使服务器地址无法到达，连接开关也可能保持打开。排查时要观察实际请求，而不是反复切换开关。

先选一个平时可直接访问的网页，再选一个当前打不开的目标。两者都使用浏览器发起新请求，记下失败时间、当前网络和所选服务器。不要仅用已经打开的标签页或应用首页作判断，因为缓存可能让断网时仍显示旧内容。以下操作以 iPhone / iPad 界面词为主，其他平台按同名设置核对。

确认基础网络

在 Home 关闭连接，再访问平时可直接访问的网页。若仍失败，先完成 Wi-Fi 登录认证、检查蜂窝数据权限或恢复路由器上网；此时修改分流规则无法修复底层断网。
固定测试对象

记录同一个目标域名、当前 Wi-Fi 或蜂窝网络，以及 Home 中选中的服务器。后续每次只改一项，再重新请求该目标，不用不同网站之间的结果替代对照。
暂停自动连接

进入 Settings → On Demand，记录原状态后临时关闭自动连接。这样手动断开时不会立即被系统重新连接；完成测试后恢复原设置。
保留原始配置

修改前记录 Global Routing、当前 Config 和自定义 DNS。需要编辑规则时先保留配置副本，避免把诊断用的临时设置留作日常配置。

第一项：服务器能否连接并完成实际请求

在 Home 核对选中的条目，不要只看订阅分组名称。执行 Connectivity Test 后，先区分结果是延迟数值还是超时，再用浏览器验证实际请求。测试使用的方法和目标会影响结果：测得一个延迟值，可能只证明部分连接阶段成功，不能据此确认账号认证、TLS 握手和目标访问全部通过。

如果用户已有自己的订阅，更新后要重新确认服务器地址、端口和选中条目。旧条目仍显示在列表中，并不能证明它仍有效。手动导入的条目则应逐项核对协议与凭据；例如 Trojan 的密码与 TLS 参数、VLESS 的 UUID、Shadowsocks 的加密方式与密码都不能互相套用。端口应以自己的配置为准，不能因为使用 TLS 就一律改成 443。

全部条目超时：先在 Wi-Fi 与蜂窝网络之间做一次对照。只在某个网络失败，优先检查该网络的出口限制、认证状态或 UDP 可用性。
只有一个条目失败：向自己的服务商确认该服务器地址、端口、认证信息和服务状态，不必先重置整个客户端。
延迟正常但网页失败：继续检查实际请求的错误。TCP 建连成功后仍可能发生 TLS 或认证失败，也可能是测试目标与网页目标的可达性不同。
使用 Hysteria2 时失败：它基于 QUIC，依赖 UDP 传输；普通 TCP 测试成功不能直接证明对应 UDP 路径可用。WireGuard 同样需要检查其 UDP 通信条件。

报错：connection timed out

原因：连接在期限内未得到所需响应，可能涉及服务器不可达、链路丢包或网络过滤，单凭超时无法断定密码错误。

解法：先核对服务器地址和端口，再用同一条目切换网络复测；如果仅该条目持续超时，向自己的服务商确认服务器状态。

报错：connection refused

原因：目标端口没有接受连接，常见于端口填错、服务未监听或中间设备主动拒绝。

解法：按已有配置核对端口与协议，不要通过修改 DNS 来处理明确的端口拒绝。

以上是网络日志中常见的错误原文片段，不是每次失败都会出现的固定弹窗。记录错误时应连同发生时间与目标一起保留；对外提供诊断材料前，遮盖订阅 token、密码、UUID 和其他凭据。

第二项：Global Routing 是否符合测试目的

在 Home → Global Routing 查看当前模式。模式决定请求如何选择处理路径，和开关是否打开是两件事。先确认模式，再判断规则是否有问题；如果停在 Direct，即使连接开关开启，也不能期待普通请求经当前代理服务器转发。

4 项

Global Routing：Config / Proxy / Direct / Scene

传统 DNS 常用端口，UDP 与 TCP 均可使用

443

HTTPS 常用端口，端口可连接不代表网页请求成功

模式	处理含义	排查用途
Config	按照当前配置中的规则选择策略。	验证日常分流是否正确，需同时确认当前使用的 Config。
Proxy	将普通流量交给当前代理路径处理。	临时与 Config 对照，减少普通分流规则对判断的干扰。
Direct	使用直接连接路径。	与代理路径对照，不能用它证明远端代理服务器可用。
Scene	依据配置的场景条件决定实际使用的处理方式。	核对当前网络触发了哪个场景，不要只依据 Scene 这一名称判断出口。

先记录原模式，临时切到 Proxy，用同一服务器访问同一目标，再切回 Config 重试。如果 Proxy 可访问而 Config 不可访问，优先查配置内的规则与策略选择；如果二者均失败，就不能仅把原因归到规则。Proxy 对照也不是对所有网络设置的彻底隔离，DNS、服务器参数和底层链路仍可能共同影响结果。

结论：先用模式对照缩小范围

同一网络、同一服务器、同一目标在 Proxy 成功而 Config 失败时，保留成功的服务器参数，转查 Config 的命中规则与策略去向，不要同时更换协议和 DNS。

第三项：DNS 失败发生在解析的哪一步

网页请求通常先把域名解析为地址，再建立连接。DNS 超时会让后续连接没有可用目标，但服务器域名本身也可能需要先解析。因此要分清失败对象：是代理服务器的域名无法解析，还是网站域名无法解析；两者对后续排查方向不同。

进入 Settings → DNS 查看当前设置，同时检查 Config 中是否包含影响 DNS 的配置。不要只改一个界面选项就认定所有请求都改用了该解析器；应用自身的加密 DNS、现有缓存和不同的解析路径，都可能使观察结果与预期不一致。

确认错误对象。记录日志里无法解析的主机名。服务器主机名解析失败时，应先恢复这一步，不能用切换目标网站来验证服务器是否正常。
撤回近期改动。如果故障始于手动填写 DNS，先记录原值，再撤回该改动复测。不要一次添加多组不明解析地址，增加判断变量。
检查解析器可达性。传统 DNS 常用 53 端口；使用加密 DNS 时，还需要对应服务器的连接和证书验证正常。加密不意味着一定可达。
重建请求。保存设置后断开再连接，并关闭后重新打开目标页面。若仍疑似缓存影响，重启相关应用复测，不把旧页面的显示当作新解析结果。
区分地址族。若只在部分网络失败，检查是否与 IPv6 路径有关。临时对照可以帮助定位，但应记录变化，不要把关闭 IPv6 当作所有故障的固定解法。

报错：No such host is known

原因：这是 Windows 中可能出现的主机名解析错误，表示当前解析过程没有得到可用结果，并不能据此判断远端端口是否开放。

解法：先核对主机名拼写，再检查所用网络与 DNS 设置；如果是自己的服务器域名，向服务商确认域名当前是否有效。

第四项：规则是否命中 REJECT 或 DIRECT

回到 Home → Global Routing → Config，再进入 Config 核对当前实际启用的配置。普通规则按顺序检查，先匹配的规则决定后续处理；只有前面的规则均未匹配时，才会走到 FINAL。订阅服务器更新与规则配置更新不是同一件事，更新服务器列表不代表当前规则也发生了变化。

下面只演示规则结构，使用 example.com 与文档专用地址段，不是可直接套用的配置。PROXY 在此表示代理策略；实际配置需要确认相应策略名称和目标均存在。

[Rule]
DOMAIN-SUFFIX,example.com,REJECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX：第一行会匹配 example.com 及其子域名，并交给 REJECT。后面的 FINAL 不会覆盖前面已经命中的拒绝规则。
IP-CIDR：按目标 IP 网段匹配。示例中的 no-resolve 表示不为匹配该条规则而主动进行域名解析，不代表关闭所有 DNS 请求。
GEOIP：按目标 IP 的地理归属数据匹配，不是按网站界面语言或域名后缀匹配，归属判断也可能受数据库与实际解析结果影响。
FINAL：承接未被前面规则匹配的流量。若实际配置写成 FINAL,DIRECT，未命中的目标会走直连，而不是自动使用 Home 选中的服务器。

若只有个别网站失败，查看该次请求对应的域名、命中规则和最终策略。网页往往同时访问主域名、登录域名、脚本与图片域名；首页能显示而登录失败，可能只是其中一个必要域名被拒绝。应针对失败请求修正规则，不要为了一个资源直接删除整组过滤规则。

DIRECT 并不等于错误，它只是直接连接。当目标在当前网络无法直连时，命中 DIRECT 才会表现为访问失败。同样，规则选择了代理策略，也要继续检查该策略实际指向的服务器是否可用，不能只看到 PROXY 字样就结束排查。

结论：修正实际命中的那一层

若日志表明目标被 REJECT，先检查对应规则及顺序；若走 DIRECT 后超时，核对它是否本应走代理；若已走代理但连接失败，回到服务器与 DNS 检查，不要反复调整无关规则。

常见追问与恢复检查

完成四项排查后，把诊断用的临时改动恢复成有明确依据的设置。特别是 Proxy、On Demand 和临时 DNS，不应因测试成功就忽略原先的使用需求。以下问题可以用来核对是否遗漏了自动重连、规则回退或网络差异。

为什么关掉开关后又自动打开？

先检查 Settings → On Demand 是否启用。记录原状态后临时关闭，再手动断开复测；同时确认设备上没有其他自动连接管理设置。排查结束后按原需求恢复。

延迟很低，为什么网页还是一直转圈？

延迟测试不能代替完整请求。固定该服务器，查看网页请求是否完成解析、是否在 TLS 或认证阶段失败，再对照 Proxy 与 Config。不要仅按延迟数值反复切换条目。

切到 Proxy 就好了，是否一直用它？

这说明需要优先检查 Config 的分流路径，不代表所有请求都适合长期走代理。切回 Config，检查失败目标命中的规则、FINAL 去向及策略实际选中的服务器。

Wi-Fi 不行，蜂窝网络可以，先改什么？

保留服务器参数，先确认 Wi-Fi 已完成登录认证，并排查该网络的 DNS、出口限制与 UDP 条件。相同配置换网络后成功，是定位网络差异的证据，不是必须重装应用的理由。

恢复需要的 Global Routing 模式，确认当前 Config 与预期一致。
恢复 On Demand 的原状态，并验证切换网络后实际使用的处理路径。
保留一份修改记录：故障现象、修改项、修改前后结果，避免下次重复排查。
若需要向自己的服务商反馈，只提供必要的错误时间、协议、网络类型和脱敏日志，不公开完整订阅链接或凭据。