Nginx 301重定向循环问题排查：7个常见原因与解决方案

目录

• 什么是重定向循环
• 原因一：HTTP和HTTPS同时跳转
• 原因二：server_name匹配到自身
• 原因三：rewrite规则死循环
• 原因四：反代后端返回重定向
• 原因五：location嵌套导致重复跳转
• 原因六：if指令滥用
• 原因七：多级代理转发叠加
• 通用排查方法
• 预防建议

什么是重定向循环

重定向循环（Redirect Loop）是指浏览器在访问一个URL时，服务器不断返回301或302重定向响应，最终浏览器检测到超过最大跳转次数（Chrome默认约20次），直接报ERR_TOO_MANY_REDIRECTS错误，页面无法加载。

这是Nginx配置中最常见的坑之一，尤其是做HTTP到HTTPS迁移、域名重定向、URL规范化的时候，稍不留神就会踩进去。

原因一：HTTP和HTTPS同时跳转

这是最常见的原因。你在80端口的server块里把HTTP跳转到HTTPS，又在443端口的server块里做了某种条件判断，把请求又跳回了HTTP。两个规则互相触发，形成死循环。

错误示例：

# 80端口：HTTP → HTTPS
server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

# 443端口：又跳回HTTP（错误！）
server {
    listen 443 ssl;
    server_name example.com;
    # 某些条件下又return 301 http://...
}

解决方法：443端口的server块里不应该再返回HTTP跳转。检查所有443 server块，确保没有向http://的重定向。

原因二：server_name匹配到自身

当你的301重定向目标和当前server_name匹配时，请求会重新进入同一个server块处理，导致无限循环。

错误示例：

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
    # 如果HTTPS的server_name也包含example.com，且跳转回自己...循环！
}

解决方法：确保重定向目标指向的是一个不同的、能正常处理的server块。可以用nginx -T命令查看完整配置，理清每个server块的处理逻辑。

原因三：rewrite规则死循环

rewrite指令如果在正则匹配时没有正确设置终止条件，或者last和break标志使用不当，会导致Nginx内部循环重写URI。Nginx默认最多执行10次内部重写，超过后返回500错误（但有时也会表现为重定向循环）。

错误示例：

location / {
    rewrite ^/(.*)$ /$1/ permanent;  # 不断加斜杠
    # /a → /a/ → /a// → /a/// ...死循环
}

解决方法：

• 使用break标志停止重写
• 在正则中加入排除条件，避免匹配已处理过的URI
• 用if判断URI是否已包含目标模式

# 正确：先判断是否已有尾部斜杠
location / {
    rewrite ^(/.*)$ $1/ permanent;
    # 这样会301到带斜杠的URL，然后location不再匹配
}

原因四：反代后端返回重定向

当Nginx作为反向代理时，后端应用（如Java、PHP、Node.js）返回的Location头可能指向了HTTP地址，而Nginx前端又强制跳转到HTTPS，形成循环。

典型场景：

1. 用户访问 https://example.com/api
2. Nginx反代到后端 http://127.0.0.1:8080/api
3. 后端返回 302 Location: http://example.com/api/login
4. 浏览器跳转到 http://example.com/api/login
5. Nginx 80端口又301到 https://... 回到第1步

解决方法：在后端配置中确保生成的重定向URL使用正确的协议（HTTPS），或者在Nginx层面用proxy_redirect修正：

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_redirect http:// https://;
}

原因五：location嵌套导致重复跳转

多个location块之间存在包含关系，每个都做了重定向，请求在多个location之间来回跳转。

错误示例：

location / {
    return 301 https://example.com/new/;
}

location /new/ {
    return 301 https://example.com/;  # 又跳回去了！
}

解决方法：用nginx -T检查所有location块的重写规则，画出跳转链路，消除环路。

原因六：if指令滥用

Nginx的if指令被称为"evil"，因为它的行为和大多数编程语言的if不同。在if块内部使用return或rewrite时，实际作用于的是父级location的配置，容易产生意想不到的重定向。

常见陷阱：

server {
    listen 443 ssl;
    server_name example.com;

    if ($host != 'example.com') {
        return 301 https://example.com$request_uri;
    }
    # 如果代理传递的Host头被改了，可能意外触发if条件
}

解决方法：尽量避免使用if做重定向，改用独立的server块匹配域名：

server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # 正常处理
}

原因七：多级代理转发叠加

在生产环境中，请求可能经过CDN → WAF → Nginx → 后端多个层级。如果每一层都做了重定向，且目标URL不一致，就会形成循环。

排查思路：

• 用curl -v直接访问源站，绕过CDN
• 逐层检查每一层的重定向配置
• 确认CDN/WAF没有配置与Nginx冲突的跳转规则

通用排查方法

遇到重定向循环时，按以下步骤排查：

1. curl跟踪重定向链：curl -vL --max-redirs 5 https://example.com，观察每次跳转的URL和响应头
2. 查看完整配置：nginx -T，输出所有server块和location块的完整配置
3. 检查错误日志：tail -f /var/log/nginx/error.log，看是否有相关错误信息
4. 临时注释规则：逐个注释掉重定向相关配置，reload后测试，定位是哪条规则导致的
5. 画跳转链路图：把每次重定向的来源URL和目标URL画出来，找到环路

预防建议

• 配置重定向前，先理清所有server块和location块的匹配关系
• 用独立的server块处理域名规范化，不要在业务逻辑中混入重定向
• 修改配置后用nginx -t检查语法，nginx -s reload平滑重载
• 配置完毕后用curl模拟请求验证跳转链路
• 避免在if块中使用return和rewrite做重定向

相关文章

• Nginx 301重定向不生效？8个常见原因排查与解决方法
• Nginx rewrite和return区别详解：重定向到底该用哪个？
• Nginx rewrite last和break区别：实战详解两个指令的核心差异与应用场景