apache不支持tls 1.3本质是openssl版本不足或apache链接旧库，需依次验证openssl≥1.1.1、apache≥2.4.37且mod_ssl已加载、sslprotocol与sslciphersuite正确配置tls 1.3专用套件，并用openssl s_client实测确认。
apache 中 tls 参数配置不支持 tls 1.3，本质不是“配错了”，而是底层依赖未达标或关键配置被隐性禁用。排查要从 openssl 版本、apache 编译链接、协议启用方式、密钥套件四层递进验证，不能只看 conf 文件里有没有 +tlsv1.3。
确认 OpenSSL 是否真正支持 TLS 1.3
TLS 1.3 完全由 OpenSSL 实现，Apache 本身不提供协议逻辑。
- 运行
openssl version -a，输出必须是OpenSSL 1.1.1或更高（如1.1.1w、3.0.12、3.1.5）；1.0.2或1.1.0均不支持。 - 更关键的是查 Apache 实际链接的 OpenSSL：
httpd -V | grep -i openssl ldd $(which httpd) | grep ssl
若显示
libssl.so.1.0.2或路径指向旧版本，说明 Apache 是用旧 OpenSSL 编译的——即使系统装了新 OpenSSL，也无效。
检查 Apache 是否满足最低版本与模块要求
- Apache 2.4.37 是官方明确支持 TLS 1.3 的起始版本。低于此版本（如 CentOS 7 默认的 2.4.6）即使 OpenSSL 新，也无法启用。
- 确保
mod_ssl已加载：httpd -M | grep ssl应输出ssl_module (shared)。 -
mod_http2不影响 TLS 1.3，但若你同时启用了 HTTP/2，需注意它依赖 TLS 1.2+，不过不是 TLS 1.3 的前提。
验证 TLS 配置是否正确启用（不是写错，是写得不完整）
在 <virtualhost></virtualhost> 或全局 ssl.conf 中，必须同时满足三项：
-
SSLProtocol +TLSv1.2 +TLSv1.3（不能写成all -SSLv3 -TLSv1 -TLSv1.1，那会把 TLS 1.2/1.3 也一并禁掉） -
SSLCipherSuite必须包含 TLS 1.3 专用套件，例如：SSLCipherSuite TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
混入任何 TLS 1.2 套件（如
ECDHE-RSA-AES128-GCM-SHA256）会导致协商失败。
Apache Superset Dashboard and SQL Exploration Skill下载Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
-
SSLHonorCipherOrder on推荐保留，确保服务器按配置顺序选择。
实测握手结果，而非仅信配置
重启 Apache 后，用真实工具验证：
- 测试 TLS 1.3 是否可达：
openssl s_client -connect example.com:443 -tls1_3 -servername example.com 2>/dev/null | grep "Protocol\|Cipher"
正常应输出
Protocol : TLSv1.3和具体 Cipher。若返回空或CONNECTED(00000003)后立即断开，说明协商被拒。 - 对比 TLS 1.2：
openssl s_client -connect example.com:443 -tls1_2 -servername example.com 2>/dev/null | grep "Protocol"
若 1.2 成功而 1.3 失败，基本锁定为套件不匹配或 OpenSSL 链接问题。
- 浏览器访问后，在开发者工具 → Security 标签页查看实际协商协议，Chrome/Firefox 均明确显示 “TLS 1.3”。
不复杂但容易忽略
