强制启用TLS 1.3的关键是服务端仅开放TLSv1.3协议并禁用低版本，需OpenSSL≥1.1.1及Nginx≥1.13.0支持，同时剔除TLS 1.2套件、关闭降级路径，并验证客户端兼容性。
要强制所有流量走 TLS 1.3，关键不是“让客户端支持”，而是“让服务端拒绝低版本握手”，同时确保客户端具备兼容能力。TLS 协商是双向过程，服务端可主动终止不满足条件的连接，从而实现事实上的强制升级。
服务端配置：只开放 TLS 1.3 协议栈
这是最直接、最有效的手段。以主流服务器为例：
-
Nginx：在 server 或 http 块中明确限定协议版本
ssl_protocols TLSv1.3;
禁用 TLS 1.2 及以下所有版本。注意：该配置需搭配支持 TLS 1.3 的 OpenSSL（≥1.1.1）和 Nginx（≥1.13.0），否则会启动失败。 -
Apache：使用 mod_ssl 模块
SSLProtocol -all +TLSv1.3 -
ASP.NET Core（.NET 6+）：在 Program.cs 中配置 Kestrel
options.ConfigureHttpsDefaults(https => https.SslProtocols = SslProtocols.Tls13);
配套加固：关闭降级路径与弱协商机制
仅限制协议版本还不够，攻击者可能利用协议降级或不安全扩展绕过限制：
- 禁用 TLS 1.3 降级提示（如 TLS_FALLBACK_SCSV）——现代服务端默认已不响应此类信号，但需确认未启用兼容性补丁；
- 关闭重协商（Renegotiation），避免被用于中间人注入低版本握手请求；
- 不提供任何 TLS 1.2 的加密套件（如 ECDHE-RSA-AES256-SHA），即使协议层允许，也要从 cipher list 中彻底剔除。
客户端适配：避免大面积连接失败
强制 TLS 1.3 后，老旧系统（如 Windows 7 + IE11、Android 4.x、部分 IoT 固件）将无法建连。因此需同步推进客户端侧准备：
- 内部系统统一升级运行时：Java 应用设置 jdk.tls.client.protocols=TLSv1.3；Python requests 使用 TLSAdapter 强制最低版本为 1.3；
- 移动 App 更新 SDK，确认网络库（OkHttp、AFNetworking 等）已启用 TLS 1.3 支持；
- 对外服务若需兼容公共用户，建议先灰度开启 TLS 1.3-only，并通过日志监控 handshake_failure 报错比例，确认影响范围后再全量切换。
验证是否生效
不能只看配置，必须实测验证：
- 用 openssl s_client -connect example.com:443 -tls1_2 测试，应返回 handshake failure；
- 用 curl -v --tlsv1.3 https://example.com 应成功返回，且响应头中显示 ALPN, protocol: h2 或 h3（若启用了 HTTP/3）；
- Wireshark 抓包观察 ClientHello，SNI 后应无 TLS 1.2 版本字段，Supported Versions 扩展中仅含 0x0304（TLS 1.3 标识）。
