Problem entry · machine-readable · 编码代理与终端

只有个别网站打不开(其他网站都正常)——从 curl 超时到分层定位

本页嵌入 #trove-entity JSON(本条目全量结构化数据);全库数据见 /agent/trove.json。

元数据

idsite-open-fail-others-ok收录2026-09-02
问题域编码代理与终端主题分组网络与镜像
适用工具curl · 外部工具

症状

「个别网站打不开」的典型表现:

```

浏览器: 连接超时 / 无法访问此网站 / ERR_CONNECTION_TIMED_OUT

curl: curl: (28) Connection timed out after 10000 milliseconds

ping: 请求超时(ping 不通不代表网站挂——很多站点禁 ICMP)

```

特征:**同一网络下其他 HTTPS 站点正常**;失败域名稳定复现(换浏览器也一样);重启路由/清 DNS 缓存可能短暂恢复又复发(DNS 缓存被刷新的假象)。

原因

「打不开」是用户侧唯一能看到的症状,它可能来自链路中任何一层:DNS 解析失败或返回坏 IP(缓存污染/上游故障/过滤规则)、TCP 连接超时(IP 不可达、路由黑洞、端口拦截、CDN 节点故障)、TLS 握手失败(证书/SNI,少见)、HTTP 层被拒(服务端策略)。代理工具还会引入自己的断点:分流规则把域名指向不可达节点。**不同层的原因对应完全不同的修法**——这就是必须先分层、再动手的原因。另一个常见误区是用 ping 判断网站状态:ICMP 和 HTTPS 是两条完全不同的路径,ping 不通而浏览器能开、或 ping 通而浏览器超时,都属正常。

解法

1. **定范围**:基线站点 200、目标站点失败 → 进入「个别域名」排障(都失败先查网络本身)。

2. **查 DNS**:`getent ahosts 目标域名`——无结果 = DNS 层;有结果 ≠ 排除 DNS,继续下一步。

3. **直连看层**:`curl -v -I -m 10 https://目标域名`,输出停在 `Trying` = TCP 层,停在 `Connected` = TLS 层。

4. **绕过 DNS 拆层**:`curl --resolve 目标域名:443:<IP> https://目标域名`——能连 = DNS 层坏;仍超时 = 网络路径层坏。

5. **DNS 层坏**:换公共 DNS(223.5.5.5 / 1.1.1.1),Windows 改适配器、路由器改上游、WSL 改 resolved.conf。

6. **网络路径层坏**:换代理节点、开代理直连测试、手机热点换路径;确认访问限制后走合规镜像/加速。

7. **验证**:curl 响应码 + 浏览器硬刷新;CDN 场景等 1-2 分钟再判。

验证证据

- 本机实测(2026-09-02,WSL Ubuntu 26.04):实测复现日志(2026-09-02)

- 基线:同网络 baidu http=200 → 公网出口正常,符合「个别域名失败」现场;

- DNS 层:`getent ahosts www.flextv.cc` 正常返回 CNAME(queniuaa.com)与多个 A 记录 → 解析正常,DNS 层排除;

- TCP 层:`curl -I` 直连 10s 超时(code=28,输出停在 Trying)→ 卡在 TCP 连接;

- 拆层:`curl --resolve www.flextv.cc:443:<解析IP>` 绕过 DNS 直连依然 10s 超时 → 实锤故障在 TCP/网络路径层,不在 DNS 层(换 DNS 对该案例无效,正确方向是换网络路径);

- 坏 IP 对照:指向测试网段 203.0.113.1 同样连不上 → 说明「连不上」这一表现无法区分 DNS 坏还是路径坏,必须用 --resolve 拆层。

- 素材案例(公开排障记录 22529721,2026-08-17):默认 DNS 无法解析目标域名 → 改用 1.1.1.1/8.8.8.8 后正常获得 CDN 地址 → DNS 层故障的完整证据链(nslookup + --resolve)。

- 未实测(如实标注):TLS/HTTP 层故障现场(本机未遇)、路由器后台修改(无权限环境)。

来源与证据

素材来源:https://www.cnblogs.com/pprof/p/22529721

验证证据:Evidence details kept locally (2026-09-02)