旧版浏览器连接失败主因是TLS协议协商不一致，需通过debug日志定位具体错误，用access_log关联UA与实际SSL协议版本，隔离老旧设备至独立server块并降级TLS/禁用HTTP/2，同时确保后端链路同步降级。
直接在 Nginx 配置中启用 ssl_protocols TLSv1.3 后，旧版浏览器（如 IE11/Win7、Android 4.x WebView、iOS 9.0–9.2 Safari）出现连接失败，并非配置写错了，而是 TLS 协议协商在客户端和服务端之间根本无法达成一致。排查关键不在于“有没有开 TLS 1.3”，而在于“哪些设备实际用不了它”以及“它们真正需要什么”。
看日志，别猜设备能力
用户代理（$http_user_agent）不可靠，尤其 WebView 和混合 App 经常上报错误版本。真正可信的是握手时实际协商出的协议版本。
- 在
http或server块中开启详细 TLS 日志：error_log /var/log/nginx/ssl_debug.log debug; - 确保 Nginx 编译含
--with-debug（多数官方包已支持），否则无 debug 输出 - 重启后观察日志中类似：
SSL_do_handshake() failed (SSL: error:1417D18D:SSL routines:tls_process_client_hello:version too low)
该报错明确表示客户端发起的 TLS 版本低于服务端允许的最低版本
用 access_log 反查真实客户端行为
仅靠 error_log 不知道是谁、从哪来、用什么 UA。需增强访问日志，把协议和 UA 关联起来：
- 定义日志格式：
log_format tls_detail '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $ssl_protocol $ssl_cipher'; - 在对应 server 块中启用：
access_log /var/log/nginx/access_tls.log tls_detail; - 运行数小时后统计：
awk '$12 ~ /TLSv1[.][01]/ {print $11}' access_tls.log | sort | uniq -c | sort -nr
重点关注那些 UA 显示“Android 5.1”但实际握手用 TLSv1.0 的请求——说明底层是老 OkHttp 或系统 WebView，必须单独兼容
隔离旧设备流量，不混用同一端口
把所有设备塞进一个 server { listen 443 ssl; } 是最大误区。TLS 1.3 与 TLS 1.1/1.2 在密码套件、ALPN、SNI 处理上存在本质差异，混配必然导致部分客户端失败。
- 为老旧移动端设独立子域名，例如：
legacy.example.com或api-v1.example.com - 为其配置专用 server 块：
ssl_protocols TLSv1.1 TLSv1.2;<br>ssl_ciphers 'ECDHE-RSA-AES128-SHA:AES128-SHA';<br>ssl_prefer_server_ciphers on;<br>http2 off;
- 务必禁用 HTTP/2：旧 Android WebView 不支持 ALPN，会因协议协商失败直接断连
检查后端链路是否同步降级
前端 Nginx 能用 TLSv1.2，不代表后端微服务也能。Spring Boot 1.5 + Tomcat 8.0 默认只支持 TLSv1.1；若 Nginx 用 TLSv1.2 去连它，API 请求就会 502。
- 在对应
location或upstream中强制指定：proxy_ssl_protocols TLSv1.1;<br>proxy_ssl_ciphers "ECDHE-RSA-AES128-SHA:AES128-SHA";<br>proxy_ssl_server_name on;
- 验证后端是否真支持：
openssl s_client -connect backend:8443 -tls1_1 -servername backend.example.com
