不能靠“降级安全”换兼容性，而应通过子域名或SNI分流实现老旧设备（如Android 4.4、iOS 9）与现代终端的TLS路径隔离：主站用TLSv1.2/1.3+ECC+强套件，老旧终端走独立子域名+RSA证书+TLSv1.1兼容套件，双配置互不干扰。
不能靠“降级安全”来换兼容性，而是用隔离策略+精准协商，在同一套基础设施里分层满足不同终端。核心是把老旧设备（如 Android 4.4、iOS 9、IE11 旧补丁版）和现代终端（Chrome 120+、Safari 17+、Edge 120+）的 TLS 路径分开，既不牺牲主站安全性，也不让老用户掉线。
用子域名或 SNI 分流，而不是混在同一 server 块
这是最稳定、审计友好的做法。Nginx 不支持单个 server 块内根据 UA 动态切换证书或协议，硬塞一起容易引发协商失败或策略冲突。
- 为主站（www.example.com）配置 TLS 1.2/1.3 + ECC 证书 + 强套件，启用 HSTS、OCSP Stapling、HTTP/2
- 为老旧终端单独设子域名（如 m.example.com 或 legacy.example.com），绑定 RSA 证书，仅启用 TLSv1.1/TLSv1.2，保留 AES-CBC 类兼容套件
- 两套配置完全独立，互不影响；前端可通过轻量 UA 检测做 302 跳转，也可由客户端直连对应域名
双证书部署（RSA+ECC 同时加载）需严格满足前提
如果必须共用同一个域名（如 SEO 或运维约束），可启用 Nginx 原生双证书能力，但必须确认以下四点全部达标：
- Nginx ≥ 1.11.0（推荐 1.21.0+），OpenSSL ≥ 1.1.1（非 1.0.2）
- RSA 和 ECC 两套证书的 Subject 及所有 SAN 字段必须逐字一致（含大小写、通配符格式）
- 两个私钥均无密码；且在 server 块中连续声明：rsa 证书/密钥 → ecc 证书/密钥，中间不插其他 ssl_* 指令
- ssl_protocols TLSv1.2 TLSv1.3，ssl_ciphers 必须同时包含 ECDHE-RSA 和 ECDHE-ECDSA 类套件（如 ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256）
针对真实弱客户端，只开必要兼容项，不松动安全底线
统计日志中的 $ssl_protocol 和 $http_user_agent 组合，确认哪些设备真在用 TLS 1.1 或弱套件，再针对性适配——不是“所有安卓都弱”，而是“某批 WebView 固定卡在 TLSv1.1”。
- 若确有 TLS 1.1 流量（如部分 Android 5–6 系统 WebView），可在兼容 server 块中启用 ssl_protocols TLSv1.1 TLSv1.2，但绝不启用 TLSv1.0
- 禁用 OCSP Stapling（ssl_stapling off）、HSTS（max-age=0 或直接移除）、HTTP/2（ALPN 不被旧 WebView 支持）
- 对 IE6–IE8 补充 msie_padding on 和 msie_refresh on，解决响应截断与跳转异常，但仅限专用 server 块
后端链路也要同步兼容，否则前段再稳也会 502
老旧移动端访问 API 时，Nginx 是 HTTPS 入口，但后端微服务（如 Java/Spring Boot/Tomcat）可能只支持 TLS 1.1，导致 proxy_ssl 握手失败。
- 在对应 location 或 upstream 中显式设置：proxy_ssl_protocols TLSv1.1;
- 指定兼容 cipher：proxy_ssl_ciphers "ECDHE-RSA-AES128-SHA:AES128-SHA";
- 务必开启：proxy_ssl_server_name on;（避免 SNI 错误导致证书不匹配）
- 用 openssl s_client -connect backend:8443 -tls1_1 实测验证后端真实支持能力
