Nginx反向代理回源强制TLS 1.3需三步：先确认nginx -V显示OpenSSL≥1.1.1；再配置proxy_ssl_protocols TLSv1.3（不可混用旧版）；最后严格限定proxy_ssl_ciphers为TLS 1.3专用套件，避免协商降级。
要让 Nginx 在反向代理回源时强制只用 TLS 1.3（比如拉取静态资源、CDN 回源或上游 API），关键不是仅写 proxy_ssl_protocols TLSv1.3，而是必须配合 OpenSSL 版本验证、上游服务支持确认和 cipher 协商控制——否则容易静默降级或连接失败。
确认 Nginx 运行时 OpenSSL 支持 TLS 1.3
Nginx 自身不实现加密，完全依赖编译时链接的 OpenSSL 库。即使系统 openssl 命令版本是 3.0，Nginx 仍可能绑定旧版库。
- 运行
nginx -V 2>&1 | grep "OpenSSL"，确认输出中 OpenSSL 版本 ≥ 1.1.1（推荐 ≥ 3.0） - 若显示
OpenSSL 1.0.2k或更低，需重新编译 Nginx 并指定新版 OpenSSL 路径，或换用 Ubuntu 22.04+/AlmaLinux 9 等自带高版本 OpenSSL 的发行版官方包 - 不建议仅靠
openssl version判断——它反映的是命令行工具，不是 Nginx 实际调用的库
配置 proxy\_ssl\_protocols 强制 TLS 1.3
在 location 或 upstream 块中设置，作用于 Nginx 主动发起的上游 HTTPS 连接（即“回源”）：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
- 写法示例：
proxy_ssl_protocols TLSv1.3; - 不要混入 TLSv1.2：
proxy_ssl_protocols TLSv1.2 TLSv1.3会允许降级，失去强制性 - 该指令可放在
http、server或location块，越靠近具体 upstream 越精准
同步限制 cipher 套件，避免协商失败
TLS 1.3 只接受 5 种标准化密钥交换+加密组合，若 proxy_ssl_ciphers 中混入 TLS 1.2 套件（如 ECDHE-RSA-AES256-GCM-SHA384），Nginx 不报错但上游可能拒绝握手。
- 推荐值：
proxy_ssl_ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"; - 务必删除所有含
SHA256、SHA384后缀但不含TLS_前缀的老式套件（例如AES256-GCM-SHA384是 TLS 1.2 的，不能用） - 可加
proxy_ssl_verify on;和proxy_ssl_trusted_certificate提升证书校验强度
验证是否真正生效
不能只看配置语法正确，要实测回源连接使用的协议版本：
- 启用调试日志：
error_log /var/log/nginx/debug.log debug;，并添加proxy_ssl_verify_depth 2;触发详细 SSL 日志 - 抓包验证：在 Nginx 服务器上对上游 IP 执行
tcpdump -i any -w upstream.pcap port 443，用 Wireshark 打开，查看 TLS 握手层的supported_versions和实际协商结果 - 简单检查：临时将 upstream 指向一个支持 TLS 1.3 的公开测试服务（如
https://httpbin.org），curl 回源地址并观察响应头或错误信息
