unexpected EOF during TLS handshake：握手期间提前断开的原因
unexpected EOF during TLS handshake严重程度 HighTLS 握手进行到一半，对端没有返回任何 TLS 告警就直接关闭了连接。最可能是链路上的设备识别 ClientHello 特征后主动切断；第一步是确认目标端口上跑的确实是 TLS 服务，然后换网络对比。
结论
EOF（End of File）在网络语境里的意思是"对面把连接合上了"。正常的 TLS 失败会带一个告警码（handshake_failure、protocol_version 之类）——连告警都不给的沉默关闭，说明关闭连接的一方根本不想按 TLS 的规矩交流。它可能是一台不懂 TLS 的服务（你连错端口了），也可能是一台懂但不想让你完成握手的中间设备。区分两者是本页的核心。
适用环境
- Windows / macOS / Linux
- 高发场景：自定义端口的代理协议、被策略关注的线路
一分钟快速判断
- 核对端口：目标端口是 TLS 服务吗？对一个纯 HTTP 端口（如 80）或 SSH 端口发起 TLS 握手，得到的正是这种沉默关闭。客户端配置里端口错位一格是高频笔误；
- 换网络：热点下同一目标握手成功 → 原网络链路在掐握手，基本结案；
- 重试几次看稳定性：每次都在同一阶段断 → 策略性切断；偶尔成功偶尔断 → 更像链路质量或服务端过载。
这条错误代表什么
握手中断的时间点透露信息：
- ClientHello 刚发出就断：对端或中间设备看了你的第一句话就挂断。SNI 明文可见，deep packet inspection 设备正是在这一刻做决定；
- 收到部分 ServerHello 后断：更少见，可能是分片丢失（MTU 问题的另一种表现）或服务端进程崩溃；
- 对端根本不是 TLS 服务：它收到一堆"乱码"（在它看来），按自己协议的逻辑关闭连接。
与近亲的边界：有告警的失败不是本条；超时（对面不关闭也不回复）是 TLS-002；建连都没成功是 TCP 层错误。
ConnProof 如何判断
connproof tls 目标域名 --port 端口证据要点：TCP 建连成功（对端活着）、握手在多少毫秒后收到 EOF、断开时是否收到过任何 TLS 数据。补充对照：
connproof tcp <目标> --port <端口> --hold 3000：只建连不说话，看对端是否也断——连沉默连接都被断，说明策略在 TCP 层；只有发 ClientHello 才断，确认触发点是 TLS 特征；- 换一个已知正常的 TLS 端口（如同目标的 443）对比，验证链路对"正统 HTTPS"的态度。
最常见原因
- 中间设备识别 ClientHello 后切断：针对特定 SNI、指纹或协议特征；
- 端口配置错误：目标端口跑的不是 TLS（HTTP、SSH、或代理协议的明文端口）；
- 服务端不支持你的协议版本/套件：极老的服务端遇到只肯 TLS 1.2+ 的客户端，部分实现不发告警直接关闭；
- SNI 不被服务端接受：严格配置的服务器对未知 SNI 直接断开而不回默认证书。
Windows / macOS / Linux 排查步骤
桌面端流程一致：
- 逐字核对客户端配置里的端口与服务方文档；
connproof tls+connproof tcp --hold组合确定触发点（TCP 层还是 TLS 特征）；- 换网络对比锁定链路；
- 服务维护者侧：在服务器本机对自己做一次
connproof tls 127.0.0.1 --port <端口> --insecure-test（自签证书会报警但握手应能完成）——本机成功而公网失败，问题在链路而非服务配置； - 确认为链路特征切断的：个人层面能做的是换端口/换线路/换网络，并把证据反馈给服务方调整。
手机端排查步骤
- 手机客户端报类似错误（各家表述不同：EOF、connection closed、握手失败）时，用桌面 ConnProof 复现取证；
- Wi-Fi 与蜂窝对比不可省略；
- 修改配置前先截图原始配置，端口和 SNI 字段改错比改对更常见。
MTU 与分片：被忽视的第四种可能
除了策略切断、端口错位和版本不合，还有一种物理感更强的原因值得排除：握手报文过大导致的分片丢失。ServerHello 携带完整证书链时经常超过单个 MTU（PPPoE 宽带常见 1492，VPN 嵌套后可能更小），需要分片传输；链路上任何一处对分片处理不当（丢弃分片、Path MTU 发现被防火墙掐掉），客户端就永远等不齐完整回复——部分实现把这种残缺状态报为 EOF 而非超时。
它的识别特征：小网站（证书链短）握手正常，某些证书链长的目标稳定失败；或者同一目标在直连宽带下失败、在手机热点下成功（两者 MTU 不同）。验证与缓解：把网卡 MTU 临时降到 1400 复测（Windows 用 netsh，macOS 在网络硬件设置里改），恢复则确认是 MTU 问题——长期方案是修正路由器的 MTU/MSS 钳制设置，而不是永久压低网卡 MTU。测试后记得改回原值。
如何区分本地问题和节点问题
| 证据 | 更可能是 |
|---|---|
| 换网络后成功 | 原网络链路切断 |
| 所有网络都在 ClientHello 后立即断 | 目标端口不是 TLS 或服务端严格拒绝 |
| 沉默 TCP 连接也被断 | TCP 层策略（转 TCP-003 思路） |
| 同目标 443 正常、自定义端口被断 | 链路对非标端口的策略 |
| 服务器本机测试正常 | 链路问题（服务方可换端口应对） |
仍未解决时收集什么信息
- ConnProof 错误码（TLS-003）与脱敏报告；
- 断开时间点（发出 ClientHello 后多少毫秒）；
- 两种网络与两个端口的对照结果；
- 客户端名称和版本、操作系统版本。
禁止提交：完整订阅链接、密码、验证码、私钥、Token。
重新运行检测
connproof tls 目标域名 --port 端口 --format markdown --output tls-report.md修复后握手应完成并给出协议版本与证书证据。
相关文档
更新记录
- 2026-07-28：规则 v1 发布，确立"沉默连接对照法"区分 TCP 层与 TLS 特征切断。