ssl证书过期不会导致nginx崩溃，但客户端会强制中断连接，表现为页面打不开、api失败等；排查核心是确认生效证书是否真过期及是否全链路正确加载。
SSL证书过期不会让服务“宕机”，但会触发客户端（浏览器、App、API调用方）主动中断连接，表现为访问被“隔离”——页面打不开、接口返回连接失败、WebSocket断连、健康检查失活等。这种隔离是客户端强制执行的安全策略，不是Nginx或后端崩溃所致。排查核心是确认：**当前生效的证书是否真的已过期？它是否被所有访问路径正确加载？**
快速定位：验证服务端真实证书状态
别信浏览器报错，先看服务器上实际提供的是哪张证书：
- 用openssl s_client直连服务端获取实时证书：
openssl s_client -connect yoursite.com:443 -servername yoursite.com 2>/dev/null | openssl x509 -noout -dates
输出中的notAfter=若早于2026-09-16，即确认过期。 - 检查Nginx配置中
ssl_certificate指向的文件路径是否存在、可读：grep ssl_certificate /etc/nginx/sites-enabled/*→ls -l /path/to/fullchain.pem - 确认该证书文件确实是fullchain.pem（含服务器证书+中间CA），而非仅
cert.pem——后者会导致证书链断裂，在iOS、部分Android设备上直接隔离。
排除缓存干扰：证书没换，但客户端“记住了旧状态”
即使证书已更新，客户端可能因缓存仍拒绝连接：
- 浏览器侧：清除“HTTPS/SSL状态”（Chrome/Edge/Firefox设置中均有独立选项），不是只清Cookie或缓存。
-
系统级：Windows需运行
inetcpl.cpl→ “内容”选项卡 → “清除SSL状态”；macOS需重置钥匙串中相关证书信任设置。 - CDN/WAF层：若使用Cloudflare、阿里云WAF等，它们可能缓存旧证书；登录控制台，手动触发SSL配置“重新部署”或“刷新证书”。
检查多节点与代理链：单点正常 ≠ 全链路可用
故障常出现在“你以为只有一处配了证书”的地方：
- 多台Nginx负载均衡？逐台执行
nginx -t && nginx -s reload，并用curl -vI https://yoursite.com在每台机器上验证返回的证书有效期。 - 前端有四层SLB（如AWS ALB、腾讯云CLB）？这些设备自身也需上传并启用新证书，且可能有独立的证书生效延迟。
- 反向代理后端服务（如Node.js/Python API）也启用了HTTPS？检查其TLS配置——若后端证书过期，Nginx作为客户端发起
proxy_pass https://时也会被拦截，报错常显示为upstream SSL certificate verify failed。
验证客户端兼容性：老设备或特殊环境易被隔离
过期只是表象，某些场景下“看似过期”实为协议或链路不匹配：
- Android 7以下、Windows 7 SP1前系统，可能不信任ISRG Root X1/X2等新根证书——即使证书未过期，也会提示“不受信任”。需确认证书链是否包含兼容性更强的备用根（如Let’s Encrypt的DST Root CA X3历史链）。
- 企业内网设备常禁用OCSP/CRL校验或时间同步，导致证书状态无法验证。临时绕过方式（仅调试）：
Chrome启动参数加--ignore-certificate-errors；curl加-k。 - 移动App或IoT设备硬编码了证书指纹（pinning）？证书更新后指纹变更，会直接拒绝连接——此时需同步更新客户端代码或配置。
