关键不是能否打开网页，而是真实设备在真实网络下能否完成TLS握手并建立可信连接，需覆盖老旧系统、特定WebView版本及企业环境，用真实终端（如Android 5.1/6.0、iOS 9.3/10.2、微信/企业微信旧版）在蜂窝网络下测试，清空App数据后抓包分析ClientHello/ServerHello，并通过Nginx日志中$ssl_protocol精准识别实际协商协议版本。
测试移动端 App 对 Nginx HTTPS 证书的兼容性，关键不是“能不能打开网页”，而是验证真实设备在真实网络环境下能否完成 TLS 握手、建立可信连接。重点要覆盖老旧系统、特定 WebView 版本和企业环境等易出问题的场景。
用真实设备 + 真实网络做最小闭环验证
别只依赖 Chrome DevTools 或 curl 模拟。必须用目标用户实际使用的设备访问：
- 准备几台典型终端：Android 5.1（WebView 39）、Android 6.0（OkHttp 2.7）、iOS 9.3、iOS 10.2、微信内置浏览器（v8.0.x）、企业微信旧版
- 关闭 Wi-Fi，切到蜂窝网络（部分运营商代理会干扰 TLS 握手）
- 访问前清空 App 数据或卸载重装（WebView 缓存 SSL 状态，错误可能持续数小时）
- 用手机自带浏览器访问同一地址作为对照，区分是 App 自身限制还是系统级不兼容
抓取并分析 TLS 握手过程
仅看页面是否加载成功远远不够。要定位到底是证书链、协议版本还是加密套件导致失败：
- 在 Android 手机上启用开发者选项 → 启用 USB 调试 → 用 Chrome 连接调试（chrome://inspect），查看 Network 面板中请求的 Protocol 和 Security 标签页，确认是否出现 “ERR_CERT_AUTHORITY_INVALID” 或握手超时
- 用电脑运行：
openssl s_client -connect your-domain.com:443 -servername your-domain.com -tls1_2 -showcerts，观察返回的证书块顺序是否为「域名证书→中间证书」，且不含根证书 - 对失败设备，用抓包工具（如 Packet Capture for Android 或 iOS 上的 Proxyman + 本地代理）捕获 TLS ClientHello 和 ServerHello，检查协商出的 protocol（TLSv1.1? TLSv1.2?）、cipher suite（是否含 ECDHE-RSA-AES128-SHA？）
日志里找真实客户端能力证据
UA 字符串不可靠，真正握手用的协议版本才是铁证：
- 在 Nginx access_log 中加入
$ssl_protocol和$http_user_agent，例如：log_format debug '$remote_addr - $remote_user [$time_local] "$request" $status $ssl_protocol "$http_user_agent"'; - 上线后采集 24 小时日志，执行：
awk '$6 ~ /TLSv1[.][01]/ {print $7}' access.log | sort | uniq -c | sort -nr
找出哪些 UA 实际用了 TLSv1.0/TLSv1.1 —— 这些就是必须兼容的“灰度对象” - 若发现大量 Android 5.x 却握手为 TLSv1.0，说明不能直接启用 TLSv1.3，需保留 TLSv1.2 并搭配兼容套件
分路径/子域名做可控灰度验证
避免全量上线后大面积故障。用最小扰动方式暴露问题：
- 配置独立测试路径，如
location /cert-test { return 200 "TLS: $ssl_protocol"; }，App 内主动请求该路径并上报响应头 - 为兼容性风险高的流量设置子域名，如
legacy.example.com，绑定旧证书+宽松 TLS 策略，主站保持现代配置 - 通过请求头分流：
if ($http_x_test_cert = "true") { return 307 https://canary.example.com$request_uri; }，测试人员可在 App 请求中加 Header 主动触发新证书验证
