SSL证书过期不会导致Nginx崩溃，但客户端会主动终止TLS握手，表现为页面打不开、接口报NET::ERR_CERT_DATE_INVALID等；排查核心是确认Nginx当前对外提供的证书是否真过期且全链路（含CDN、多节点、证书链）正确加载。
SSL证书过期不会让Nginx崩溃，但客户端（浏览器、App、API调用方）会主动终止TLS握手，表现为页面打不开、接口报NET::ERR_CERT_DATE_INVALID、WebSocket断连、健康检查失败等。排查关键不是找Nginx故障，而是确认它是否正在对外提供已过期的证书，以及该证书是否被全链路正确加载。
直接验证服务端实际响应的证书
别信浏览器提示——它可能缓存旧状态或受本地策略干扰。必须从服务端实时获取Nginx当前送出的证书：
- 运行：
openssl s_client -connect yoursite.com:443 -servername yoursite.com 2>/dev/null | openssl x509 -noout -dates，看notAfter=时间是否早于当前（2026年10月10日）。若已过期，问题定位完成。 - 同时检查该命令输出中是否有
Verify return code: 0 (ok)；若非0，说明证书链不完整或域名不匹配，即使未过期也会被部分设备拦截。 - 确认Nginx配置中
ssl_certificate指向的是fullchain.pem（含域名证书+中间CA），而不是仅cert.pem——后者在iOS、部分Android上极易触发连接中断。
检查配置加载与文件状态
证书文件更新了，Nginx不会自动读取；路径写错、权限不足、语法错误都会导致静默回退到旧证书：
- 用
grep ssl_certificate /etc/nginx/sites-enabled/*查配置路径，再用ls -l确认文件存在、可读，且私钥权限为600、证书建议644。 - 执行
nginx -t验证语法和路径有效性——这是重载前必做步骤，避免因错误配置导致reload失败却误以为成功。 - 执行
nginx -s reload（不是restart），确保新证书真正载入内存。reload后可用curl -vI https://yoursite.com 2>&1 | grep "subject:"快速核对生效证书信息。
排查代理链与多节点干扰
单台Nginx正常，不代表用户能连上。证书可能卡在上游或下游环节：
- 若前端有CDN（如Cloudflare）、WAF（如阿里云盾）或四层SLB（如AWS ALB），它们各自持有并缓存证书，需登录控制台手动刷新或重新部署SSL配置。
- 多台Nginx负载均衡？逐台执行
nginx -t && nginx -s reload，并在每台机器上用curl -vI https://yoursite.com验证返回的证书有效期，不能只测其中一台。 - 若Nginx作为反向代理调用后端HTTPS服务（如
proxy_pass https://api.internal），检查是否误启proxy_ssl_verify on——此时后端证书过期会导致502，但这是后端问题，不影响用户直连Nginx。
验证客户端兼容性与缓存残留
即使证书已更新，老设备或系统级缓存仍可能拒绝连接：
- 浏览器侧：清除“HTTPS/SSL状态”（Chrome/Edge/Firefox设置中独立选项），不是清Cookie或普通缓存。
- 系统级：Windows运行
inetcpl.cpl → 内容 → 清除SSL状态；macOS需在钥匙串中删除对应域名的证书信任设置并重置。 - 移动端测试建议用未登录新设备或开启隐私模式，避开本地证书缓存影响；重点观察iOS和Android低版本是否仍异常，常指向证书链缺失或TLS协议不兼容。
