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