Separating DNS failure from slow CDN delivery

The original evidence bundle contained real infrastructure identifiers and raw resolver output. This public version keeps the troubleshooting method and historical observations while removing hostnames, addresses, private domains, and local paths.

这是一份经过公开化处理的历史故障记录。原始调查比较了两台远程 Linux 主机访问同一个 JetBrains Remote Development 客户端压缩包时的行为。当前版本保留方法、可复用结论和已观测到的数量级，删除了真实主机名、IP、内部 DNS、私有域名和本地文件路径。

问题

同一个下载失败或速度偏慢时，问题究竟发生在：

1. 名称解析；
2. TCP / TLS 建连；
3. HTTP 重定向；
4. CDN 边缘节点选择；
5. 实际大文件吞吐。

把这些阶段拆开，比笼统地说“服务器网络很慢”更有用。

测试方法

两台主机运行同一组 curl -vL 和 timing 检查：

curl -vL \
  -o client.zip \
  -w '\nDNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\nHTTP: %{http_code}\n' \
  'https://download.jetbrains.com/.../client.zip'

同时记录：

• curl 退出码；
• 系统 resolver 与显式公共 resolver 的差异；
• HTTP 重定向目标；
• x-geocode、x-amz-cf-pop、cf-ray 等 CDN 头；
• IPv4/IPv6 路由可达性；
• 代理环境变量；
• 下载大小与总耗时。

观测

主机 A：系统 DNS 路径失败

系统 resolver 无法解析下载域名，curl 以退出码 6 结束；但显式查询公共 resolver 可以得到记录。这说明故障边界位于本机 stub resolver 或上游 DNS 路径，而不是“目标域名不存在”。

绕过系统 resolver 后，主机能够进入面向中国区域的加速路径并完成下载，但吞吐仍只有约 1.2–1.3 MiB/s。由此不能把 DNS 修复与高吞吐画等号：它们是两个独立问题。

主机 B：解析和下载成功，但大文件走远端 POP

主机 B 可以完成约 750 MB 文件的下载，总耗时约 335–340 秒，平均约 2.1 MiB/s。入口请求显示香港区域信息，但重定向后的实际大文件响应来自旧金山 CloudFront POP。

这个结果支持一个更具体的描述：入口定位和大文件对象最终命中的边缘节点可能不同。只检查第一次 302 响应，会遗漏真正承担大文件流量的路径。

解释边界

这些观测不能单独证明 CDN 配置错误，也不能证明某个 POP 是吞吐瓶颈。一次远程测量还混合了：

• 当时的网络拥塞；
• 云主机出口策略；
• DNS 缓存与 CDN 调度；
• 对象缓存状态；
• 跨境路径；
• 服务端限速或中间链路整形。

更强的因果结论需要多时段重复、不同对象、受控 DNS、路径追踪和对照主机。

可复用排查顺序

1. 先保留 curl 退出码，不把 DNS 失败写成下载慢。
2. 分别测量 DNS、TCP、TLS、TTFB 和总时间。
3. 跟随全部重定向，并检查最终大文件响应的 CDN 头。
4. 比较系统 resolver 与显式 resolver，但不要永久修改 DNS 只为完成一次诊断。
5. 将 IPv4 与 IPv6 分开验证。
6. 记录代理环境，但不要把代理 URL 或凭据写进公开日志。
7. 保存原始证据到受控位置；公开笔记只保留经过泛化的结果。

结论

这次调查得到两个不同的故障类型：一台主机的首要问题是系统 DNS 路径；另一台主机能够下载，但入口区域与最终对象 POP 不一致，且大文件吞吐偏低。最重要的收获不是某个瞬时速度，而是形成了一个按解析、连接、重定向和数据传输逐层缩小故障范围的方法。

状态：历史测量记录。CDN、DNS 与网络状态会变化，不应把这里的节点和速度当作当前事实。