hsts热重载后不立即生效是协议设计使然，需通过隐身窗口访问http验证重定向及响应头，并用chrome://net-internals/#hsts确认策略更新，而非依赖已有连接或curl瞬时结果。

HSTS配置热重载后未立即生效，不是配置没写对，而是它本身就不该“立刻”在所有连接上体现——这是协议设计使然，排查重点不在Nginx是否加载了新配置，而在于理解HSTS的生效机制和验证方式。

确认HSTS头确实已写入响应

先排除配置未生效的底层问题。进入容器检查当前生效的配置：

• 运行 docker exec -it <nginx-container> nginx -T | grep -A5 "add_header.*Strict-Transport-Security"</nginx-container>，确认 add_header 指令出现在你期望的 server 或 location 块中，且未被更高优先级的块覆盖
• 用 curl 检查响应头：curl -I https://your-domain.com，看返回中是否含 Strict-Transport-Security 字段及对应 max-age 值
• 若无该头，说明配置未加载或被忽略——此时回到 nginx -t 和 error.log 中查 [emerg] 或 [warn]，常见原因是 add_header 写在了 if 块内（不支持）或被 proxy_hide_headers 清除

理解HSTS不会影响已有连接

HSTS是通过响应头告知浏览器“接下来一段时间只走 HTTPS”，但这个策略只对后续新建的 HTTP 请求起作用。热重载后：

OpenClaw Docker Setup

在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...

下载

• 旧 worker 进程仍在处理已建立的 HTTPS 连接，它们返回的仍是旧配置（包括旧 HSTS 头或无头）
• 浏览器已缓存的 HSTS 策略不会因服务端更新而自动刷新；它只会在下次发起 HTTP 请求时被重定向，并收到新头后才更新本地记录
• HTTP/2 多路复用、TCP Keep-Alive、TLS 会话复用都会延长旧连接生命周期，导致你看到“配置改了却没变”的假象

验证是否真正生效的正确方法

不要依赖已有标签页或 curl -I 的瞬时结果，要模拟“首次访问”行为：

• 用隐身窗口或全新浏览器实例访问 http://your-domain.com（注意是 http），观察是否被 307 重定向到 https，且响应头中包含你新设的 HSTS 值
• 在 Chrome 中访问 chrome://net-internals/#hsts，手动查询域名，确认 includeSubdomains 和 max-age 是否已更新
• 使用 OpenSSL 检查实际 TLS 握手是否触发 HSTS：启动一个无缓存的 curl：curl -k --resolve your-domain.com:443:127.0.0.1 https://your-domain.com -I，再比对响应头

避免误判的实操建议

热重载后别急着刷新页面，更别用 Postman 反复发请求——这些都可能复用旧连接。真正可靠的验证节奏是：

• 执行 docker exec <container> nginx -s reload</container>
• 等待 30 秒以上（让旧 worker 自然退出或被替换）
• 关闭全部浏览器窗口，开隐身模式，输入 http:// 开头地址测试重定向与响应头
• 如仍不生效，再查 Nginx 日志里有无 [warn] 提示 add_header 被忽略，或确认你的 HSTS 配置没写在 if、limit_except 等不支持上下文中