一个命令行 HTTP 工具访问某些站点时报 SSL 握手失败，你换了 Wi-Fi、换了热点，甚至换到另一台机器——还是失败。这篇文章解释为什么"换网络没用"，以及该往哪个方向查。
现象
某命令行 HTTP 工具访问部分站点时报 SSL 握手失败：
SSL connection failed: handshake failure
部分站点正常，部分站点失败。你怀疑是网络问题，于是换了网络——结果一模一样。同一台机器上，浏览器访问那个站点却是正常的。
根因
这不是网络不通，而是该工具在 Windows 上使用系统自带的 TLS 后端，与部分 CDN 的 TLS 握手不兼容。
关键在于"TLS 后端"这个概念。命令行 HTTP 工具在 Windows 上，往往直接调用操作系统提供的加密库（Schannel），而不是自己带一套 OpenSSL。Schannel 对某些 TLS 参数（支持的加密套件、协议版本、扩展）的处理与 OpenSSL 有差异，遇到配置较新的 CDN 时，就可能在握手阶段谈不拢。
握手失败发生在建立加密通道的阶段，此时 TCP 连接其实已经通了——所以"换网络"当然没用，因为问题根本不在链路上，而在两端加密能力的协商上。同理，同一台机器上浏览器能访问，是因为浏览器自带了一套完整的 TLS 实现，不依赖系统后端。
解决
改用走 OpenSSL 的客户端配合代理抓取。 最直接的方案是用 Python 的 urllib（它走 OpenSSL）：
import urllib.request
import ssl
proxy = "http://<IP>:<port>"
handler = urllib.request.ProxyHandler({"http": proxy, "https": proxy})
ctx = ssl.create_default_context()
opener = urllib.request.build_opener(
handler, urllib.request.HTTPSHandler(context=ctx))
opener.addheaders = [("User-Agent", "Mozilla/5.0")]
with opener.open(url, timeout=15) as resp:
data = resp.read()
这段代码做了三件事：绕过系统 TLS 后端、走 OpenSSL 的默认上下文、按需走代理。除此之外也可以换用其它自带 OpenSSL 的客户端：
- 用带
--ssl参数的curl（如果它是用 OpenSSL 编译的，而非 Schannel 版本）； - 用
requests（底层同样是 OpenSSL，通常不受系统后端影响）。
排查时可以用一条命令快速确认工具用的是哪个 TLS 后端：
curl -V
# 输出里若含 "Schannel" 则是系统后端，含 "OpenSSL" 则是自带库
延伸与预防
这个坑的通用教训是：握手失败是"工具与站点的兼容问题"，先换客户端，别急着查网络。
遇到 SSL/TLS 握手失败，可以按这个顺序排查：
- 换客户端——用另一个走不同 TLS 后端的工具试同一 URL。如果换了就通，问题定位完成；
- 确认后端——看工具是用系统后端还是自带库（Windows 上尤其重要）；
- 对端兼容性——用
openssl s_client -connect host:443看对端支持哪些协议和套件； - 最后才查网络——前面都排除了，再考虑链路、防火墙、代理问题。
排查时还有一个便捷的判据：如果同一个工具在 Linux 上成功、在 Windows 上失败，那几乎可以确定是 TLS 后端差异——因为 Linux 版通常链接 OpenSSL，Windows 版则用 Schannel。这个"换平台就变"的特征，比"换网络没用"更能一击定位问题。
预防上，跨平台的采集/下载脚本应当显式选择自带 TLS 库的客户端（Python 的 requests/urllib 默认就满足），而不是依赖系统的 TLS 后端。这样同一份脚本在 Windows、Linux、macOS 上的行为才一致。反过来，如果某个工具的行为"换台机器就不一样"，那第一个该怀疑的就是它的 TLS 后端。