Shadowrocket 开关已打开却上不了网:服务器、模式、DNS、规则逐项排查

一、先确认故障范围，不要立即重装

先区分基础网络故障与连接开启后的故障。在 Home 关闭连接，用 Safari 打开两个平时能直接访问的网站；再开启连接，访问相同页面。测试时固定同一 Wi-Fi 或蜂窝网络，不要同时更换网络、服务器和配置，否则无法判断是哪项变化产生了影响。

1. 记录原设置

   在 Home 记录所选服务器与 Global Routing，在 Config 记录当前启用的配置。若准备编辑配置，先保存副本；记录中不要包含密码、完整订阅地址或其他凭据。

2. 关闭后对照

   关闭 Home 的连接开关后重试网页。若网络会自动重新连接，检查 Settings → On Demand，测试期间暂时关闭已启用的触发设置，并在排查结束后恢复。

3. 确认基础网络

   若关闭后仍不能访问普通网站，先检查 Wi-Fi 登录认证、蜂窝数据权限与网络信号。公共 Wi-Fi 需要完成认证时，先完成系统或 Safari 中的登录流程。

4. 固定测试目标

   选一个已知可直接访问的页面和一个原本需要通过自己服务器访问的页面，分别记录是否成功、是否超时。不要仅用单个网站的结果代表全部网络状态。

关闭连接也失败时，应先处理基础网络。仅开启连接后失败，才继续检查本文后续项目；仅某个网站失败，则还要考虑网站自身故障、访问限制或规则差异。系统 VPN 标识同样不能证明某个远端网站已经建立连接。

二、检查服务器：测试结果不等于完整可用性

先确认当前选中的服务器能够完成实际请求。在 Home → Connectivity Test 执行测试，再核对 SERVER 列表中的选择状态。测试出现延迟数值通常只说明该测试条件下得到了响应，不代表所有域名、端口和应用流量都能正常通过。

• 地址与端口：打开当前服务器的编辑页面，逐项核对服务商提供的地址和端口。端口没有统一值；只有已有参数明确写着 443 时才填 443，不能把它当成所有协议的默认修复值。
• 认证参数：按所用协议核对密码、UUID 或密钥。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的参数不能相互套用。
• 传输参数：服务端要求 TLS、SNI、路径或特定传输方式时，必须与已有参数一致。不要通过关闭证书验证来掩盖主机名或证书问题。
• 有效状态：向自己的服务商核对现有服务是否有效、服务器是否维护、连接数是否受限。重新导入相同数据不会修复远端服务停止的问题。

错误文本应结合发生位置阅读。以下是连接日志中可能出现的底层错误片段，实际措辞会随协议和失败阶段变化；同一段文字不能单独证明服务商、DNS 或规则中的哪一项一定有错。

三、核对 Global Routing：先用模式对照定位

Global Routing 决定请求使用哪种分流方式，不负责修复失效的服务器。在 Home → Global Routing 记录当前选项，再用 Proxy 与 Config 做短暂对照。测试结束后恢复原选项，避免让诊断操作长期改变所有请求的路径。

On Demand 控制何时触发连接，不代替 Global Routing 的请求分流。若现象是关闭后自动开启，应先检查 Settings → On Demand；若现象是开着却只有部分网站失败，应先核对模式和具体请求，而不是反复切换 On Demand。

四、检查 DNS：区分服务器域名与目标域名

DNS 排查的第一步是确定哪个名字解析失败。服务器地址使用域名时，建立连接前就可能依赖解析；目标网页使用域名时，则还涉及该请求实际采用的解析路径。前者失败会使服务器连接无法建立，后者失败可能只影响部分网站。

端口能连通不代表解析一定正确。加密 DNS 还需要解析服务地址可达、TLS 校验正常，使用域名的解析服务也可能需要初始解析。把多个陌生解析地址同时加入配置，会增加变量，无法据此证明故障已经定位。

1. 在 Config 中确认当前启用的文件，打开它的编辑入口，检查 [General] 下已有的 dns-server 设置。先保存原值，不要直接覆盖整段配置。
2. 如果问题恰好发生在手动更改 DNS 之后，先恢复之前可用的设置。需要建立对照时，可在配置副本中使用 dns-server = system，测试系统解析路径；它是诊断基线，不是所有网络的最终答案。
3. 保存并启用测试配置后，重新连接并发起新的网页请求。浏览器可能复用旧连接或缓存，单次刷新不足以证明新设置已经生效。
4. 若存在 [Host] 中的手动域名映射，也要检查是否指向旧地址。恢复 DNS 设置并不会自动清除配置中另行指定的静态映射。

五、检查规则：从第一条匹配到 FINAL

Config 模式下应检查实际启用的规则，而不是仅查看文件是否存在。规则通常按从上往下的顺序匹配，前面的宽泛规则可能让后面的精确规则没有机会生效。先在 Config 核对启用文件，再检查 [Rule] 中与失败域名相关的条目和最终策略。

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

这段代码只说明语法，不是可直接替换日常配置的完整方案。example.com 是示例域名，PROXY 需要对应可用的代理策略；如果自己的文件使用命名策略，应检查该策略实际选中的服务器，而不是只检查 Home 列表。

• DOMAIN-SUFFIX：DOMAIN-SUFFIX,example.com,PROXY 匹配该域名及其子域名。网站还可能请求其他域名，因此首页能打开不代表图片、登录或接口都命中同一条规则。
• IP-CIDR：192.168.0.0/16 表示一个地址范围。示例中的 no-resolve 用于避免仅为了该 IP 规则而触发域名解析，不表示整个连接不再使用 DNS。
• GEOIP：GEOIP,CN,DIRECT 根据 IP 地理分类决定策略，不等同于按域名后缀分类，结果也受所用数据库影响。
• FINAL：FINAL,DIRECT 在前面规则均未命中时直接连接。若目标必须经过已有代理却落到这里，即使开关开启也可能无法访问。

修正规则时一次只改一处，并用同一目标重新验证。如果 Proxy 模式仍失败，单纯把 FINAL 改成代理并不能修复服务器认证错误；如果只有 Config 模式失败，则优先核对命中规则及其策略。完成测试后恢复不需要保留的临时规则。

六、常见追问与排查收尾

收尾时应保留可复现的现象，而不是提交整份含凭据的配置。记录网络类型、服务器协议、Global Routing、失败目标和错误阶段，通常比“开关是开的”更有定位价值。需要向自己的服务商反馈时，先移除密码、UUID、私钥与订阅令牌。