ConnProof

no shared TLS protocol version：客户端与服务端谈不拢协议版本 ​

TLS-005unsupported protocol / wrong version number严重程度 High
一句话结论

TLS 握手在版本协商这一步就失败了：客户端与服务端没有共同支持的协议版本。最可能是服务端只支持已被淘汰的 TLS 1.0/1.1，而现代客户端默认要求 1.2 以上；第一步是确认端口号正确且该端口确实提供 TLS 服务。

适用环境WindowsmacOSLinux
适用客户端通用客户端
最后验证：2026-07-29规则版本：v1内容更新：2026-07-29

结论 ​

TLS 握手的第一件事是协商版本：客户端在 ClientHello 里报出自己支持的版本范围，服务端从中选一个。这条错误意味着两边的范围没有交集——谈判在第一句话就结束了。

这与其他 TLS 错误的区别很清楚：不是证书有问题（TLS-001）、不是握手被中途掐断（TLS-003）、也不是超时无响应（TLS-002）。双方都在正常说话，只是说的不是同一种语言。

适用环境 ​

  • Windows / macOS / Linux
  • 所有使用 TLS 的连接：HTTPS、基于 TLS 的代理协议、wss://

一分钟快速判断 ​

connproof tls 目标域名 --port 端口 --verbose

按三种可能性依次排除：

  1. 端口写错了。 对一个纯 HTTP 端口发起 TLS 握手，收到的响应会被当作畸形的 TLS 报文，报出版本相关的错误。这是最高频的原因，也最容易被忽略——先逐字核对端口号；
  2. 服务端太旧。 只支持 TLS 1.0/1.1 的老服务端，遇到默认要求 1.2 以上的现代客户端就会谈崩；
  3. 客户端或运行环境太旧。 反过来，很旧的客户端遇到只接受 TLS 1.3 的服务端也会失败，多见于长期未更新的系统。

这条错误代表什么 ​

TLS 版本的淘汰是有时间表的：TLS 1.0 与 1.1 已被主流浏览器、操作系统和运行时先后停用，原因是它们存在无法通过配置修补的密码学缺陷。所以"服务端只支持 1.1"在今天不是配置偏好问题，而是该升级了。

值得留意的是它的报错措辞很多样：unsupported protocol、wrong version number、no protocols available、version too low 都指向同一件事。ConnProof 会把这些不同的表述统一归到 TLS-005，避免你为了不同的英文短语分别去搜。

wrong version number 这一条尤其容易误导——它听起来像"版本号写错了"，实际上更常见的含义是收到的根本不是 TLS 数据，也就是上面第 1 种情况：端口错了。

ConnProof 如何判断 ​

检测器在握手失败后读取底层错误码与消息，匹配版本协商相关的标记（包括 ERR_SSL_UNSUPPORTED_PROTOCOL、ERR_SSL_VERSION_TOO_LOW、ERR_SSL_WRONG_VERSION_NUMBER 等一组 OpenSSL 码，以及消息中的版本相关措辞），命中即判为 TLS-005。

这个判定的位置很关键：它排在证书类错误之后、通用握手失败之前。先确认不是证书问题，再看是不是版本问题，最后才归入笼统的握手失败——这个顺序保证了越具体的结论优先级越高。

同时报告里会保留 TCP 建连耗时的证据。TCP 通了而 TLS 版本谈不拢，这个组合本身就说明目标主机和端口是活的，问题纯粹在协议层。

最常见原因 ​

  1. 端口配置错误：对非 TLS 端口发起了 TLS 握手；
  2. 服务端 TLS 配置过旧：仅支持 1.0/1.1，或密码套件配置只包含旧算法；
  3. 客户端运行环境过旧：长期未更新的系统，其 TLS 库不支持较新版本；
  4. 中间设备改写握手报文：较少见，但会造成版本字段解析异常。

Windows / macOS / Linux 排查步骤 ​

用户侧：

  1. 先核对端口，与服务方文档逐字比对。这一步能解决相当比例的案例；
  2. connproof tls <目标> --port <端口> --verbose 确认失败发生在版本协商而非证书环节；
  3. 对同一主机的标准 HTTPS 端口（443）做一次对照检测——443 正常而自定义端口报版本错误，基本确认是端口或该端口上的服务配置问题；
  4. 更新你的客户端与运行环境到较新版本后复测。

服务维护者侧：

  1. 检查服务端 TLS 配置的 minVersion / ssl_protocols 一类设置，至少支持 TLS 1.2；
  2. 若服务需要兼容老旧客户端，正确做法是同时支持 1.2 与 1.3，而不是保留 1.0/1.1；
  3. 修改后用 connproof tls 从公网侧验证，而不是只在服务器本机测。

不要这样做 ​

不要降级客户端来迁就服务端

遇到这条错误时，把客户端的最低协议版本调回 TLS 1.0/1.1 确实能"修好"连接——但代价是让这条连接暴露在已知的密码学缺陷之下。TLS 1.0/1.1 被淘汰不是因为过时的美学，而是因为它们无法安全地保护你的数据。正确方向是推动服务端升级，或者更换服务。

为什么"能连上"不等于"该连上" ​

有一类场景值得单独说明：某些老旧的内部系统、打印机管理界面、老设备的 Web 控制台，确实只支持 TLS 1.0/1.1，而你又必须访问它们。

这时降级客户端看起来是唯一选择，但更稳妥的思路是限定降级范围：只对那一个特定主机放宽协议要求，而不是全局调低最低版本。多数工具与浏览器都支持按站点设置例外，全局降级则会让你访问所有站点时都失去保护。

另外要意识到一个现实：随着运行环境更新，旧协议支持会被逐步彻底移除——那时降级选项本身都不存在了。依赖旧协议的设备最终必须升级或隔离到内网，把降级当作长期方案只是在推迟问题。

如何区分本地问题和服务端问题 ​

证据更可能是
同主机 443 正常、自定义端口报版本错误端口写错或该端口非 TLS 服务
所有客户端连该服务都失败服务端 TLS 配置过旧
只有你这台设备失败，别人正常你的运行环境过旧
换网络后依旧与链路无关，不必再换网络试

仍未解决时收集什么信息 ​

  • ConnProof 错误码（TLS-005）与脱敏报告；
  • 底层错误码与消息原文（不含敏感信息，可直接提供）；
  • 同主机 443 端口的对照结果；
  • 客户端名称和版本、操作系统版本。

禁止提交：完整订阅链接、密码、验证码、私钥、Token。

重新运行检测 ​

connproof tls 目标域名 --port 端口 --format markdown --output tls-report.md

修复后握手应成功，报告中会给出协商到的协议版本与加密套件。

相关文档 ​

更新记录 ​

  • 2026-07-29：规则 v1 发布。此前版本协商失败与握手中断一同归入 TLS-003，本次拆分以区分"谈不拢"与"谈到一半被打断"。