根本原因是nginx默认absolute_redirect on，生成绝对url时仅感知容器内端口（如80），无法获知宿主机映射端口（如9279），导致location头丢失或错误端口；解决方案是server块中配置absolute_redirect off和port_in_redirect off，强制使用相对重定向路径。
当 Nginx 运行在 Docker 容器中，并通过非标准端口（如 8080）映射对外提供服务时，如果后端应用或 Nginx 自身触发了 301/302 重定向（比如访问 /admin 跳转到 /admin/），浏览器收到的 Location 响应头里可能错误地带上宿主机的端口号（如 http://example.com:8080/admin/），甚至更糟——直接变成 http://example.com/admin/（丢失 :8080），导致跳转失败。根本原因在于 Nginx 默认启用 absolute_redirect on，它会拼出完整绝对 URL，而端口逻辑又受 port_in_redirect 控制。
为什么 absolute_redirect 会引发问题
Nginx 在生成重定向响应（如目录末尾自动补 /、rewrite 后跳转）时，若 absolute_redirect on（默认值），就会构造形如 http://$server_name:$port/path 的完整地址。但 Docker 容器内 Nginx 看到的请求是来自内部网络（如 172.17.0.x），$server_port 是容器内监听端口（如 80），不是宿主机映射端口（如 8080）。于是它要么省略端口（误认为 80/443），要么硬写容器端口（暴露内部结构），造成跳转地址不可达。
配置 absolute_redirect off 的正确方式
核心操作是关闭绝对路径重定向，改用相对路径，让浏览器基于当前 URL 上下文解析跳转目标：
- 在对应
server块中添加：absolute_redirect off; - 同时建议配套设置：
port_in_redirect off;（防止 Nginx 主动往Location加端口） - 确保该
server块能实际匹配到请求，例如明确写server_name example.com;或使用server_name "";匹配空 Host
示例配置片段：
server {
listen 80;
server_name example.com;
absolute_redirect off;
port_in_redirect off;
location /app/ {
proxy_pass http://backend:3000/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
配合 proxy_set_header 避免后端干扰
即使 Nginx 层面修复了，如果后端应用（如 Express、Django）自己生成重定向，它可能依据 X-Forwarded-Port 或原始 Host 头构造 URL。因此需确保反向代理透传关键头信息：
- 必须设置：
proxy_set_header Host $host;（传递原始 Host，含端口） - 显式传递端口：
proxy_set_header X-Forwarded-Port $server_port;（虽然容器内是 80，但宿主机用户访问的是 8080，这里建议改用$http_x_forwarded_port或由前置负载均衡器注入） - 更稳妥做法：在宿主机 Nginx 或 Traefik 等边缘代理层统一处理重定向逻辑，容器内 Nginx 仅作透传
验证是否生效
修改配置后重载 Nginx（nginx -s reload），然后用 curl 触发一个会重定向的路径：
curl -I http://localhost:8080/app
观察响应头中的 Location 字段。成功时应为相对路径：Location: /app/；若仍出现 http://... 绝对地址，说明配置未生效或被其他 location 块覆盖。检查是否遗漏 absolute_redirect off，或是否在错误的作用域（如 http 块而非 server 块）中设置。
