Nginx HTTPS 配置中应正确添加安全响应头：HSTS 仅在 443 块启用并先确保 80 跳转；X-XSS-Protection 设为 "1; mode=block"；X-Frame-Options 用 "DENY" 或 "SAMEORIGIN" 并加 always；同时配齐 X-Content-Type-Options、Referrer-Policy 和 CSP。
直接在 Nginx 的 server 块（尤其是监听 443 的 HTTPS 配置）里加几行 add_header，就能一次性配齐核心安全响应头。关键不是“全加上”，而是加得对、加得稳、不冲突。
HSTS 必须只在 HTTPS 响应中生效
HSTS 不是加了就起作用——它只在 HTTPS 返回的响应头里被浏览器识别。如果用户首次访问的是 http://，而你没做跳转，那这个头根本不会发出去。
- 先确保 80 端口有强制跳转：
return 301 https://$host$request_uri; - 在 443 的
server块中添加：add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; -
别一上来就设大 max-age：建议先用
max-age=300（5 分钟）观察几天，确认所有资源都走 HTTPS、没有混合内容报错，再逐步调高
X-XSS-Protection 要启用并阻断，不是仅过滤
这个头虽已逐渐被 CSP 取代，但仍是 IE、旧版 Chrome/Safari 的重要防线，尤其对反射型 XSS 有效。
- 推荐值：
add_header X-XSS-Protection "1; mode=block" always; -
1表示启用过滤器，mode=block表示发现可疑脚本时直接中断页面渲染，而非尝试清理后继续加载 - 避免写成
"0"或"1; report=..."（后者需配套上报服务，否则无效）
X-Frame-Options 要选对策略，且必须加 always
它防点击劫持，但现代浏览器更倾向支持 CSP 的 frame-ancestors。若两者共存，CSP 会覆盖它，所以建议明确取舍。
- 多数场景用：
add_header X-Frame-Options "DENY" always;（完全禁止嵌套）或"SAMEORIGIN" always;（仅同源允许） -
ALLOW-FROM已被 Chrome/Safari 废弃，不建议使用 -
务必加
always：否则 404、502、500 等错误响应不带该头，攻击者可借此绕过防护
额外提醒：别漏掉基础防护组合
这三项之外，还有三个几乎零成本、高收益的头，建议同步配置：
-
add_header X-Content-Type-Options "nosniff" always;：阻止浏览器 MIME 嗅探，防恶意文件伪装成图片/JS 执行 -
add_header Referrer-Policy "strict-origin-when-cross-origin" always;：平衡隐私与功能，跨域时不泄露完整路径 -
add_header Content-Security-Policy "default-src 'self'; frame-ancestors 'none'; object-src 'none'" always;：比 X-Frame-Options 更强，且是现行标准；如已配 CSP，X-Frame-Options 可保留作兼容，但不要设冲突值
