最有效方式是在https的server块中配置hsts与csp：hsts强制加密传输（需always参数、覆盖所有响应码、max-age逐步提升、慎用includesubdomains），csp按业务定制（先report-only测试、避免unsafe-inline/eval、显式声明第三方资源），并配套301跳转、证书检查及响应头验证。
直接在 HTTPS 的 server 块中配置 HSTS 和 CSP，是构筑 Web 安全防线最有效、最稳妥的方式。这两个头必须配合使用，但作用不同：HSTS 强制传输层加密，CSP 控制资源加载行为，二者共同堵住降级攻击和 XSS 利用路径。
HSTS 配置要点：只在 HTTPS 下生效，且必须覆盖所有响应码
HSTS 头不会在 HTTP 响应中起作用，所以它只能出现在监听 443 端口、启用 SSL 的 server 块里。同时，浏览器只在收到该头后才开始“记住”强制 HTTPS 规则，因此必须确保每个响应——包括 404、500、302——都携带它。
- 务必加上
always参数，否则默认只对 2xx 响应生效 - 不要写在全局
http{}或 80 端口的 server 块中，否则可能误触发或被忽略 -
max-age建议从 300（5 分钟）起步，确认全站无 HTTP 资源调用后再逐步延长至 31536000（一年）或更久 - 启用
includeSubDomains前，确保所有子域名（如 api.example.com、cdn.example.com）已部署有效 HTTPS 证书，否则会直接导致子域不可访问
CSP 配置要点：按实际资源加载逻辑定制，避免“一刀切”
CSP 不是越严越好，而是越贴合业务越安全。一个错误的 script-src 或漏掉第三方统计域名，会导致页面功能异常甚至白屏。
- 上线前建议先用
Content-Security-Policy-Report-Only模式运行两周，收集浏览器上报的违规日志，再调整正式策略 - 禁止滥用
'unsafe-inline'和'unsafe-eval'；内联脚本可用nonce或hash替代 - 常见资源需显式声明：Google Fonts 补
font-src fonts.gstatic.com，YouTube 视频加frame-src youtube.com，CDN 图片加img-src cdn.example.com -
frame-ancestors 'none'可替代X-Frame-Options，兼容性更好且支持更细粒度控制
推荐组合配置（放入 443 server 块内）
以下为兼顾防护力与实用性的基础组合，可直接复制使用：
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' data: https://cdn.example.com; style-src 'self' 'unsafe-inline'; frame-ancestors 'none'; object-src 'none'" always;add_header X-Content-Type-Options "nosniff" always;add_header Referrer-Policy "strict-origin-when-cross-origin" always;
注意：示例中的 https://cdn.example.com 需替换为你真实使用的 CDN 域名；style-src 'unsafe-inline' 属临时兼容方案，长期应移除并改用外部 CSS 或 nonce。
配套动作不能少
光配头不够，还需确保底层基础设施支撑策略落地：
- 80 端口 server 块必须配置 301 跳转到 HTTPS，保证用户首次访问也能顺利进入加密通道
- 检查所有子域名是否具备有效证书，否则
includeSubDomains会锁死访问 - 定期用 securityheaders.com 或 curl 验证响应头是否正确返回
- 若使用 Nginx Proxy Manager 或其他管理界面，确认其模板未覆盖你手动添加的安全头
