在 nginx 中处理带有端口号的重定向死循环，核心做法是区分内部重定向与外部客户端跳转。当使用 return 指令配合 $scheme://$host:$server_port$request_uri 进行强制 https 或域名标准化时，如果配置不当（如未排除特定 uri 或未正确设置端口变量），nginx 会在内部不断触发重写规则，导致请求在同一个 server 块内无限循环，最终返回 500 错误。解决的关键在于利用 $is_args、$args 以及 if 条件判断来阻断对静态资源或已处理过的请求再次进入重定向逻辑，并确保 server_port 在反向代理场景下不被错误地覆盖为后端端口。
为什么带端口的 return 会引发 500 死循环
当你在 server 块中使用 return 301 https://$host:$server_port$request_uri; 时，Nginx 会尝试构建一个新的 URL 并立即发起一个内部子请求。如果这个新的 URL 仍然匹配当前的 server 块（例如因为监听的是 80 和 443 同一 server，或者 proxy_pass 配置错误导致端口回环），Nginx 会再次执行该 return 指令。由于 Nginx 限制了内部重定向的最大深度（默认为 10 层），超过限制后就会抛出 500 Internal Server Error。这种情况常发生在将 $server_port 硬编码或错误地从上游获取，导致协议转换后端口依然指向当前监听的非 SSL 端口，从而形成闭环。
server {
listen 80;
server_name example.com;
# 错误示范：可能导致死循环
# 如果 $server_port 被意外修改或上下文混淆，
# 且没有排除特定路径，可能陷入内部重定向循环。
# 正确做法：明确指定目标端口，或使用 if 隔离
if ($scheme = http) {
return 301 https://$host$request_uri;
}
}
server {
listen 443 ssl;
server_name example.com;
# SSL 配置...
location / {
proxy_pass http://backend;
}
}
上述代码展示了标准的分离写法。通过将 HTTP 到 HTTPS 的重定向放在独立的 if 块中，并确保只针对 $scheme = http 触发，可以避免对已经处于 HTTPS 状态的请求再次处理。注意，这里省略了 :$server_port，因为默认情况下 HTTPS 监听 443，HTTP 监听 80，显式写出反而容易因代理头问题导致端口错乱。如果必须保留端口，应确保 $server_port 反映的是客户端连接的原始端口，而非后端服务器的端口。
反向代理场景下如何避免端口变量污染
在反向代理架构中，Nginx 作为前端网关，后端应用服务器可能运行在非标准端口（如 8080）。如果在前端 Nginx 的配置中直接使用 $server_port 进行重定向，可能会因为 proxy_set_header 或负载均衡器的行为，导致 $server_port 被替换为后端端口，从而产生指向错误端口的重定向链接，进而引发客户端浏览器的重定向循环或 Nginx 内部的解析混乱。解决此问题的方法是使用 $http_host 结合明确的端口映射，或者在 location 级别精确控制重定向行为，避免全局性的 return 干扰正常业务流量。
# 前端 Nginx 配置示例
server {
listen 80;
server_name api.example.com;
# 仅对非静态资源进行重定向，减少循环风险
location /api/ {
if ($scheme = http) {
return 301 https://$host$request_uri;
}
proxy_pass http://backend_cluster;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
# 静态资源直接服务，不经过重定向逻辑
location /static/ {
root /var/www/html;
}
}
在这个配置中，我们针对 /api/ 路径单独处理重定向，而静态资源则直接由磁盘提供，不参与任何协议转换逻辑。这样即使 $server_port 在某些极端情况下出现异常，也不会影响到静态资源的访问，从而切断了潜在的循环路径。同时，通过 proxy_set_header Host $host 确保后端收到的是正确的域名，避免因后端生成绝对 URL 时使用错误端口而导致的客户端侧重定向循环。
如何验证重定向链路的完整性与安全性
在完成配置后，必须通过实际请求验证重定向链路是否闭合且无循环。可以使用 curl -I 命令模拟客户端请求，观察响应头中的 Location 字段是否符合预期，并检查状态码是否为 301 或 302。如果发生死循环，curl 默认会跟随重定向直到达到最大次数（通常为 20 次），此时会返回最后一个页面的内容或报错。为了更清晰地看到每一步的重定向，可以使用 curl -v 查看详细的握手和头部交换过程。此外，建议在测试环境中先禁用 SSL 证书验证（-k 参数）以排除证书错误对重定向流程的干扰，专注于逻辑层面的连通性检查。
