port_in_redirect控制Nginx主动重定向时Location头是否含端口：默认on会保留非标端口（如:8443），off则省略，使HTTPS重定向符合443规范；仅作用于return、rewrite等Nginx自身重定向，不影响后端返回的302。
当 Nginx 以非标准端口（如 8443）监听 HTTPS 请求，且自身触发重定向（例如 return 301 或 rewrite ... permanent）时，port_in_redirect 直接决定浏览器看到的跳转地址是否包含该端口——默认开启会带端口，关闭则一律省略，这对用户访问体验和 HTTPS 正常工作很关键。
port_in_redirect 如何影响 HTTPS 重定向地址
该指令只作用于 Nginx 主动发起的重定向（不是后端返回的 302），控制其自动构造的 Location 响应头中是否显示端口号：
- 设为 on（默认）：若当前请求来自
https://example.com:8443/login，Nginx 执行return 301 /new;时，生成的Location: https://example.com:8443/new会保留:8443； - 设为 off：同样请求下，生成的
Location: https://example.com/new不含端口，符合 HTTPS 默认端口 443 的规范，浏览器能正确识别并使用 443 连接； - 注意：即使设为 on，当实际监听的是标准端口 443 时，Nginx 仍按 HTTP 协议规范自动省略端口，不会写出
:443。
为什么非标准 HTTPS 端口下容易出问题
用户通常通过域名访问（如 https://example.com），背后由 CDN、LB 或防火墙将流量转发到 Nginx 的 8443 端口。此时：
- 若
port_in_redirect on，重定向结果含:8443，但用户浏览器直接访问该地址会失败——因为 8443 并未对外暴露或未配置证书； - 若后端服务（如 Spring Boot）也返回重定向，那属于另一类问题，需用
proxy_redirect处理，port_in_redirect对其无效； - 常见现象是登录后跳转到
https://example.com:8443/dashboard，页面白屏或连接被拒绝。
推荐配置方式
对监听非标准 HTTPS 端口（如 8443）的 server 块，应显式关闭该行为：
- 在对应
server块内添加port_in_redirect off;； - 配合
server_name_in_redirect off;，确保重定向使用用户请求中的Host头，而非固定server_name； - 避免混用：不要在同一个 server 块里既监听 8443 又期望重定向显示 443——Nginx 不会自动“映射”端口，它只根据当前监听端口和该指令判断是否写出；
- 若需强制走标准 HTTPS，更稳妥的做法是用
return 301 https://$host$request_uri;，此时port_in_redirect不起作用，因为 URL 是手动拼的。
验证是否生效
用 curl 模拟请求，观察响应头：
-
curl -I http://example.com:8443/old（假设该路径触发重定向）； - 检查返回中的
Location:字段是否含:8443； - 修改配置后执行
nginx -t && systemctl reload nginx，再测试确认。
