https重定向安全关键在于防止恶意host污染和确保后端识别真实域名：禁用$host构造location，改用$server_name或固定域名；反向代理需proxy_set_header host $host；默认server块应校验host白名单并return 444拦截非法请求。
HTTPS 重定向后保留原始 Host 头，关键不是“保留跳转后的 Host”，而是**确保重定向本身不被恶意 Host 污染，同时让后端服务能正确识别用户真实访问的域名**。Nginx 默认不会在重定向响应中透传原始 Host 头，但 Host 头本身是请求头，只存在于客户端发起的请求中；重定向（如 301）返回的是 Location 响应头，与 Host 无关。真正需要关注的是：如何让重定向目标安全可信、如何让反向代理转发时把原始 Host 正确交给后端。
重定向目标必须可信，不能拼接 $host
很多问题其实源于错误地用客户端可控的 $host 或 $http_host 构造重定向地址：
- ❌ 危险写法：
return 301 https://$host$request_uri;—— 攻击者发Host: evil.com，就会跳到https://evil.com/... - ✅ 安全写法：
return 301 https://$server_name$request_uri;—— $server_name 来自配置文件，不可伪造 - ✅ 更稳妥写法：
return 301 https://www.example.com$request_uri;—— 固定域名，彻底规避变量风险
反向代理场景下，后端需要原始 Host？用 proxy_set_header
如果你的 Nginx 是 HTTPS 入口，再 proxy_pass 到后端应用（如 Node.js、PHP），后端要识别用户访问的是 app.example.com 还是 admin.example.com，就必须显式传递 Host 头：
-
proxy_set_header Host $host;—— 把客户端原始 Host 头传给后端（推荐用于多租户或多域名路由） -
proxy_set_header Host $server_name;—— 强制统一为配置中的 server_name，适合单域名或需标准化场景 - ⚠️ 不要省略这一行：默认 Nginx 会把 Host 设为
proxy_pass地址（如backend:3000），后端就收不到真实域名
防止非法 Host 请求到达重定向逻辑
即使重定向写得再安全，如果恶意 Host 请求（如 Host: xxx.attacker.com）直接打到 80 或 443 端口，仍可能触发非预期行为。必须设置兜底拦截：
- 在
listen 80 default_server;和listen 443 ssl default_server;的 server 块中，用 if + 白名单校验 Host - 匹配失败时直接
return 444;（关闭连接）或return 403;，不进入任何重定向或 proxy_pass 流程 - 示例：
if ($host !~ ^(example\.com|www\.example\.com|api\.example\.com)$) { return 444; }
后端重定向响应的 Location 头也要清洗
如果后端应用（如 Django、Spring Boot）自己生成 302 跳转，Location 可能含 HTTP 协议或错误域名。Nginx 需主动干预：
-
proxy_redirect ~^http://[^/]+(.*)$ https://$server_name$1;—— 把后端返回的所有 HTTP Location 强制转成当前 HTTPS 域名 -
proxy_redirect off;+ 手动重写 Location 头（配合add_header或 Lua）—— 更精细控制，适合复杂协议/子路径场景 - 避免
proxy_redirect default;—— 它依赖$host，有 Host 注入风险
