小火箭开了连不上网怎么办:按服务器、模式、DNS、规则逐项排查

一、显示已连接，为什么仍然打不开网页？

先确认故障发生在哪一层。设备建立本地 VPN 隧道，与远端服务器完成连接、解析目标域名、成功请求网页，是不同的环节。Home 中连接开关开启或系统出现 VPN 标识，并不代表某个网站已经通过整条路径返回内容。

第一步应该做什么？先建立基础网络对照。记录当前网络、所选服务器、Global Routing 模式和正在使用的配置，再临时断开 Shadowrocket，打开一个在当前网络下通常可以直接访问的网站。若此时仍然失败，应先处理 Wi-Fi 登录、蜂窝数据权限或网络本身，而不是继续改规则。

1. 记录现场

   在 Home 记下所选服务器与 Global Routing 当前值，在 Config 记下正在使用的配置。保留配置副本，避免排查后无法还原。

2. 暂停自动连接

   进入 Settings → On Demand，记录设置并临时关闭 On Demand，再关闭 Home 的连接开关，避免测试直连时隧道被自动重新启用。

3. 测试基础网络

   用 Safari 打开一个平时可直接访问的网站。如果 Wi-Fi 需要网页认证，先完成认证；再对同一网址做一次蜂窝网络对照。

4. 重建连接

   基础网络正常后，回到 Home 开启连接，使用相同网址复测。后续每完成一项修改，都重新建立连接并发起新请求。

切换 Wi-Fi 与蜂窝网络后结果不同，能说明什么？它说明问题与网络路径有关，但还不能直接判定为某个协议故障。服务器端口的可达性、DNS、网络认证状态都可能随网络改变，应保留这个差异，继续做下一项对照。

二、服务器测试有结果，是否就代表可以上网？

不能。先在 Home 对当前服务器执行连通性测试，并确认所用测试方法。仅测端口建立连接，与通过代理请求测试网址，覆盖的环节不同；一个延迟数值不能保证所有域名、所有传输方式和所有目标端口可用。

测试失败应该先改哪些字段？打开当前服务器的编辑界面，对照自己服务商提供的原始信息，逐项检查地址、端口、Type 和认证参数。不要凭经验把端口统一改成 443：443 只是 HTTPS 的常用端口，远端代理监听端口必须与服务端设置一致。

手动修改与订阅更新应该选哪个？如果服务器来自自己的订阅，先确认订阅更新成功，以及当前选择的条目仍在服务有效范围内。更新订阅只是刷新连接信息，不等于确认远端可用；也不要在未保存副本的情况下反复覆盖配置。本文不提供连接资源，参数有效性应向自己的服务商核实。

这些错误文字在哪里看？在应用的连接记录、诊断信息或系统网络错误中，保留实际出现的原文与发生时间；不同请求可能显示不同措辞。没有看到对应文字时，不要把这里的例子当成设备已经给出的诊断。

三、Global Routing 应该怎样做对照测试？

模式怎么选才便于定位？进入 Home → Global Routing，先记录当前值，再分别用 Direct、Proxy、Config 对同一网址发起新请求。这里只是短时诊断，不是要求长期使用某个模式；Direct 对照应选当前网络允许直接访问的目标。

四、怎样判断是不是 DNS 解析失败？

网页一直等待，是否就一定是 DNS？不是。DNS 故障需要解析记录或明确的解析错误支持。还要区分两个对象：服务器地址若是域名，它需要先被解析；目标网站域名也可能通过另一条解析路径处理。前者失败时，代理连接本身就可能无法建立。

具体从哪里检查？进入 Config，打开当前正在使用的配置查看 DNS 相关内容。先保存副本，再检查 [General] 中的 dns-server，以及是否另有适用于特定域名的 DNS 设置。仅修改系统 Wi-Fi 的 DNS，不一定能覆盖配置指定的解析路径。

• 核对地址格式：检查是否有拼写错误、遗漏分隔符或已经不可达的解析器；加密 DNS 地址还涉及其主机名与 HTTPS 连接是否可达。
• 核对传输路径：普通 DNS 常用 UDP 或 TCP 的 53 端口，DoH 使用 HTTPS，通常为 443；端口含义不能证明当前网络允许访问该服务。
• 单项回退：若问题恰好发生在手动改 DNS 后，优先恢复修改前的配置副本，而不是同时新增多个解析器、改模式和替换服务器。
• 复测新请求：重新连接后重新载入页面，结合新产生的记录判断。浏览器与应用可能保留缓存，一次成功或失败都不足以说明全部域名的情况。

能否直接输入网站 IP 来排除 DNS？不能据此下定论。HTTPS 依赖域名参与证书校验和虚拟主机选择，直接访问 IP 可能出现证书错误，或进入不同站点。应优先查看域名是否得到有效解析结果，再核对随后连接是否成功。

五、规则命中错误，应检查哪些关键字？

Config 模式下只有部分网站失败，先看什么？在 Config 确认选中的配置，再查看失败请求对应的连接记录：目标域名或 IP、命中的规则、最终策略、所用服务器。Shadowrocket 按规则顺序匹配，符合条件的前序规则会影响结果；仅看文件里“写过这条域名”还不够。

规则语法怎么核对？下面仅演示三类规则与顺序，不是建议直接导入的配置。example.com 与 192.0.2.0/24 是文档示例，PROXY 的实际代理出口也需要在自己的配置中核对。

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

这里为什么写 no-resolve？它用于该 IP 规则，表示不为匹配这条规则而主动触发域名解析；它不是全局关闭 DNS。也不要把 FINAL 放在准备继续匹配的规则之前，否则后面的规则无法承担预期的分流作用。

• 页面文字能打开但图片失败：分别查看页面、图片和接口域名的记录，不能只给主站补一条规则。
• 规则选择了策略组：继续核对组内实际选中的服务器，组名存在不代表成员可用。
• 手动调整后短暂恢复：保存修改前后差异，再验证订阅或配置更新是否覆盖了本地改动。

六、排查完成后，怎样恢复并保留有效证据？

问题消失后是否可以立即结束？先恢复日常 Global Routing 模式，再确认 Config 使用的是预期配置；若平时使用 On Demand，回到 Settings → On Demand 恢复原先条件，并分别验证 Wi-Fi、蜂窝网络与网络切换后的表现。不要把临时诊断模式误当成最终配置。

仍然无法定位时应该提供什么？把信息整理成可复现的步骤，而不是只提交“已连接但打不开”。服务商负责核对服务参数和服务状态；应用内设置则需要结合模式、配置和连接记录判断。对外发送材料前，应遮盖订阅令牌、密码、UUID、私钥及其他认证信息。

• 测试环境：设备类型、系统信息、Wi-Fi 或蜂窝网络，以及基础网络是否正常。
• 路由对照：同一网址在 Direct、Proxy、Config 下分别成功还是失败。
• 服务器情况：协议 Type、连通性测试方法与结果，不发送认证密钥。
• 请求证据：发生时间、脱敏后的错误原文、命中规则及最终策略。
• 修改记录：最后一次正常使用后是否更换服务器、更新订阅、修改 DNS 或配置。