最简洁可靠的做法是在301重定向的server块中统一添加安全头；hsts必须在https server块中配置且带always参数，$host需校验或替换为$server_name以防开放重定向。
直接在 301 重定向的 server 块中统一添加安全头，是最简洁、最可靠的做法。重定向本身是响应行为，安全头应随跳转响应一同发出，而不是等到后端处理或 location 匹配后再加——那样既无效，又可能被绕过。
重定向响应必须携带关键安全头
301 响应不是“空跳”，它本身就是一个完整的 HTTP 响应，浏览器和爬虫都会解析其响应头。若只写 return 301 https://example.com$request_uri; 而不附加安全头，攻击者可利用该响应做中间人劫持、协议降级或注入攻击。
-
HSTS 必须在 HTTPS server 中启用：仅靠 301 跳转无法防止首次明文请求被篡改。HSTS 需配置在
listen 443 ssl的 server 块中，且带always参数，确保 301、404、500 等所有响应都携带：add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; -
禁止透传危险头部：若 Nginx 前置了 CDN 或代理，需清除客户端伪造的
Server、X-Powered-By等敏感头，避免泄露技术栈。需启用ngx_headers_more模块：more_clear_headers "Server" "X-Powered-By"; -
强制内容类型与 XSS 防护：即使跳转页为空白响应，也建议统一设置：
add_header X-Content-Type-Options "nosniff" always;<br>add_header X-XSS-Protection "1; mode=block" always;
避免在重定向逻辑中依赖不可信变量
很多配置误用 $host 构造跳转地址，而 $host 来自请求头，可被任意伪造（如发送 Host: evil.com），导致开放重定向漏洞。安全做法是：
- 单域名场景下，硬编码目标域名：
return 301 https://www.example.com$request_uri; - 多域名支持时，用
if + 正则白名单校验后再跳转：if ($host ~* ^(www\.example\.com|example\.com)$) { return 301 https://$host$request_uri; }<br>return 403; - 优先使用
$server_name（配置中显式声明的合法域名）替代$host：return 301 https://$server_name$request_uri;
安全头应在 server 级统一继承，而非 location 内零散添加
把安全头放在 http 或 server 块顶层，能保证所有响应（包括 301、404、503）都默认受控。若在 location 中添加，301 响应因不进入 location 流程而无法生效。
- 推荐结构：
在http块设基础头（如 HSTS 除外，因其仅限 HTTPS）：add_header X-Frame-Options "DENY" always;<br>add_header Referrer-Policy "strict-origin-when-cross-origin" always;
- HSTS 和 TLS 相关头必须放在
listen 443 ssl的 server 块内，且不能被子 location 覆盖。 - 禁用默认 Server 头：在 http 或 server 块中加
server_tokens off;，再配合more_set_headers自定义（需模块）。
不推荐的组合方式（易出问题）
以下做法看似灵活，实则破坏安全头一致性或引入风险：
- 在
location /中写rewrite ... permanent并试图加安全头——rewrite触发内部重定向，响应头可能丢失；且permanent是 301，但执行阶段晚于 server 级指令，无法保证头一定发出。 - 用
proxy_pass后再由后端返回 301——此时 Nginx 已失去对跳转目标和响应头的控制权，HSTS、X-Frame-Options 等无法由 Nginx 主动注入。 - 在 HTTP server 块中加 HSTS 头——无效，HSTS 只在 HTTPS 响应中被浏览器接受。
