应分场景按设备能力配置TLS策略：通过$ssl_protocol与UA联合统计识别真实客户端，为旧设备设独立子域名及兼容server块，同步调整后端proxy_ssl配置，并渐进淘汰低版本TLS。
直接在主 server 块里强制启用 TLS 1.3 或禁用 TLS 1.0/1.1，会让 Android 4.x、iOS 9 甚至部分 Android 5–6 的 WebView 直接断连。真正有效的做法是分场景、按设备能力提供匹配的 TLS 策略，而不是“一刀切”升级或降级。
识别真实客户端能力，别只看 UA 字符串
用户代理（User-Agent）容易伪造或不准确，尤其在混合 App 或 WebView 场景中。更可靠的方式是结合日志中的 $ssl_protocol 和 $http_user_agent 做联合统计：
- 在 access_log 格式中加入：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $ssl_protocol';
- 运行几天后，用 awk/grep 统计：zcat access.log*.gz | awk '$12 ~ /TLSv1[.][01]/ {print $11}' | sort | uniq -c | sort -nr
- 重点关注实际握手用了 TLSv1.0/TLSv1.1 的请求，再反查对应 UA——你会发现很多“Android 5.1”其实跑的是 TLSv1.0，因为底层 WebView 或 OkHttp 版本太老
为旧移动设备单独配置兼容性 server 块
不要把所有设备塞进同一个 HTTPS 端口。用子域名（如 m.example.com 或 legacy-api.example.com）隔离流量，专供老旧移动端使用：
- ssl_protocols TLSv1.1 TLSv1.2;（iOS 9 最低要求 TLS 1.2，但部分早期 iOS 9.0–9.2 补丁未全，保留 TLSv1.1 更稳妥）
- ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA';（含 AES-GCM 主流套件，也保留 AES-CBC 保底）
- ssl_prefer_server_ciphers on;（确保旧客户端不乱选弱套件）
- 不启用 http2；旧 Android WebView 不支持 ALPN，会降级失败
后端微服务也要同步对齐（常被忽略）
如果 Nginx 后面还连着 Java 微服务（比如 Spring Boot 1.5 + Tomcat 8.0），它可能只支持 TLSv1.1，而 Nginx 默认用 TLSv1.2 去连——这时用户能打开首页，但 API 请求全 502。需检查并配置：
- 在对应 location 或 upstream 中设置：proxy_ssl_protocols TLSv1.1;
- 配套加：proxy_ssl_ciphers "ECDHE-RSA-AES128-SHA:AES128-SHA";
- 务必开启：proxy_ssl_server_name on;（否则多证书环境可能返回默认证书）
- 用 openssl s_client -connect service:8443 -tls1_1 实测确认后端真实支持版本
渐进式收口，避免突然中断
上线兼容配置后，不是永久保留 TLSv1.1。应建立淘汰机制：
- 每月统计 m.example.com 域名下 TLSv1.1 占比，若连续两月低于 0.5%，可考虑移除
- 在响应头中加自定义标头 X-TLS-Deprecated: "TLSv1.1 will be disabled on 2026-10-01"，推动客户端升级
- 对明确已停更的 SDK（如某厂商 2022 年发布的 Android SDK v3.2），在 Nginx 层返回 426 Upgrade Required，并附提示文案
