err_ssl_protocol_error本质是tls握手失败。其主因包括系统时间偏差超5分钟、证书过期或未生效、证书链不完整、tls版本或加密套件不兼容、中间安全软件干扰等，需按网络—dns—连接—https—服务顺序排查。
这不是 HSTS 的问题，而是 HTTPS 证书失效后，浏览器在强制 HTTPS 的前提下又遭遇证书错误，双重拦截导致完全无法访问——HSTS 只是让 HTTP 请求根本发不出去，而证书失效则让 HTTPS 请求在 TLS 握手阶段就被拒绝。排查必须先剥离 HSTS 干扰，直击证书本身。
第一步：绕过 HSTS 确认是否真是证书问题
别用常规窗口测试，因为 HSTS 已锁死 HTTP，且证书错误会阻断 HTTPS：
- 打开 Chrome 或 Edge 的无痕窗口（Incognito），直接访问 https://你的域名；无痕模式不继承 HSTS 缓存，但会完整执行证书校验
- 如果仍看到 NET::ERR_CERT_DATE_INVALID、ERR_CERT_AUTHORITY_INVALID 等提示，说明问题根源就是证书失效，和 HSTS 无关
- 若无痕窗口能正常打开（绿色小锁），那才是 HSTS 配置或缓存问题；当前场景中，99% 是证书先挂了
第二步：本地验证证书真实状态与链完整性
浏览器提示不可信，不代表服务端没配证书——可能证书已过期、路径错、链不全，或私钥权限不对：
- 查有效期：openssl x509 -in /etc/nginx/ssl/fullchain.pem -noout -dates，确认 notAfter 时间是否早于当前（2026年10月2日）
- 查链是否完整：openssl s_client -connect your-domain.com:443 -servername your-domain.com -showcerts 2>/dev/null | grep "BEGIN CERTIFICATE" | wc -l，输出应 ≥2；只有 1 行说明中间证书缺失
- 查私钥权限：ls -l /etc/nginx/ssl/privkey.pem，必须是 600（仅 root 可读）；644 或 755 会导致 Nginx 静默降级或加载失败
- 查配置路径：grep ssl_certificate /etc/nginx/sites-enabled/*，确认指向的是 fullchain.pem（不是 cert.pem），且文件真实存在
第三步：排除 HSTS 对诊断的干扰
HSTS 会让问题“看起来更糟”，但它不制造证书错误，只放大后果：
- 即使证书已失效，只要 Nginx 还在返回 Strict-Transport-Security 头，浏览器就继续强化 HTTPS 强制策略，用户连报错页面都看不到（HTTP 请求被拦截，HTTPS 请求握手失败）
- 临时停用 HSTS 不是为了修复证书，而是为了获得可调试的错误反馈：把配置中 add_header Strict-Transport-Security 行注释掉，执行 nginx -t && nginx -s reload
- 再用无痕窗口访问 https://，此时若仍报证书错，坐实是证书问题；若突然能打开（说明之前被 HSTS+证书双杀），那就先修证书，再考虑 HSTS 恢复
第四步：快速恢复与防复发
证书问题必须现场解决，不能靠 HSTS 缓冲：
- 立即更新证书：用 certbot renew --nginx -d your-domain.com（推荐），或手动替换 fullchain.pem 和 privkey.pem 后重载
- 重载前必做 nginx -t：避免因路径错误、权限不足或语法问题导致 reload 失败，Nginx 自动回退到旧配置——你以为更新了，其实还在用过期证书
- 验证生效：curl -I https://your-domain.com 2>&1 | grep "200\|301"，并用 openssl s_client 再确认链完整
- 长期建议：给 Certbot 配置定时任务 + post-hook 自动 reload，并设置 Prometheus 或邮件告警，在证书到期前 15 天触发提醒
