Nginx rewrite死循环解决方法：从原因分析到彻底修复的完整指南

什么是Nginx rewrite死循环

Nginx rewrite死循环是指当URL重写规则配置不当时，请求在服务器内部不断重定向，最终触发Nginx的循环检测机制返回500错误。这类问题在配置HTTPS强制跳转、域名迁移、URL规范化时尤为常见。

典型表现包括：

• 浏览器显示"重定向次数过多"或ERR_TOO_MANY_REDIRECTS
• Nginx错误日志中出现"rewrite or internal redirection cycle"字样
• 页面无法正常加载，持续转圈或直接报错

死循环的5大常见原因

1. location块内无限重定向

最典型的错误配置：

location / {
    rewrite ^/(.*)$ /index.php?url= last;
}

location /index.php {
    rewrite ^/index.php$ / permanent;  # 又跳回根路径
}

这种配置会让请求在两个location之间来回跳转，形成死循环。

2. HTTPS强制跳转未判断协议

常见错误写法：

server {
    listen 80;
    listen 443 ssl;
    server_name example.com;
    
    rewrite ^(.*)$ https://System.Management.Automation.Internal.Host.InternalHost permanent;  # 无论HTTP还是HTTPS都跳转
}

正确写法应该先判断当前协议：

server {
    listen 80;
    server_name example.com;
    return 301 https://System.Management.Automation.Internal.Host.InternalHost;
}

server {
    listen 443 ssl;
    server_name example.com;
    # HTTPS配置...
}

3. last和break使用不当

在location块内使用last会重新触发location匹配：

location /api {
    rewrite ^/api/(.*)$ /backend/ last;  # last会重新匹配location
}

location /backend {
    rewrite ^/backend/(.*)$ /api/ last;  # 又跳回/api，死循环！
}

解决方案是使用break停止重写：

location /api {
    rewrite ^/api/(.*)$ /backend/ break;  # break不再重新匹配
    proxy_pass http://backend;
}

4. 正则表达式匹配范围过大

正则匹配过于宽松会捕获不该捕获的URL：

location / {
    rewrite ^(.*)$ /new last;  # 匹配所有URL，包括/new开头的
}

这样/new/xxx也会被重写成/new/new/xxx，无限循环。

5. try_files与rewrite冲突

try_files和rewrite同时作用于同一location时容易产生冲突：

location / {
    try_files $uri $uri/ /index.php;
    rewrite ^/old/(.*)$ /new/$1 last;  # try_files的fallback可能触发rewrite
}

如何快速定位死循环问题

方法1：开启rewrite日志

在server块内添加：

rewrite_log on;
error_log /var/log/nginx/rewrite.log notice;

重启Nginx后查看日志，可以清晰看到每一步重写过程。

方法2：使用nginx -T查看完整配置

nginx -T | grep -A 20 \"server_name yourdomain\"

这会输出该域名的所有配置，便于检查是否有冲突规则。

方法3：curl测试跟踪

curl -I -L http://yourdomain.com/problem-url 2>&1 | Select-Object -First 50

-L参数会跟踪重定向，如果看到大量301/302跳转就是循环问题。

5个实战修复方案

方案1：添加条件判断阻断循环

location / {
    if ($request_uri !~ ^/new/) {
        rewrite ^/(.*)$ /new/$1 last;
    }
}

通过if判断确保已重写的URL不会被再次处理。

方案2：使用独立server块隔离规则

server {
    listen 80;
    server_name old.example.com;
    return 301 http://new.example.com$request_uri;
}

server {
    listen 80;
    server_name new.example.com;
    # 新域名配置
}

将重定向逻辑放在独立server块，避免同一块内规则冲突。

方案3：用return替代rewrite

对于简单的301跳转，return更简洁且不会触发rewrite循环：

# 不推荐
rewrite ^/old-page$ /new-page permanent;

# 推荐
location = /old-page {
    return 301 /new-page;
}

方案4：正确使用last和break

• last：停止当前rewrite指令，重新按location匹配（适合跳转到其他location）
• break：停止rewrite处理，直接执行当前location内的其他指令（适合内部重写）

方案5：拆分location避免交叉匹配

location /api/ {
    rewrite ^/api/v1/(.*)$ /api/v2/$1 break;
    proxy_pass http://backend;
}

location /api/v2/ {
    # v2版本配置，不再rewrite
}

预防死循环的3个最佳实践

1. 配置前先画流程图

在写rewrite规则前，先画出请求流转路径，确保没有闭环。

2. 测试环境验证后再上线

使用curl或浏览器开发者工具测试重定向链：

curl -I -L -s -o /dev/null -w \"%{url_effective}\n\" http://yourdomain.com/test

3. 为复杂规则添加注释

标注每条规则的意图和预期行为，便于后续排查。

总结

Nginx rewrite死循环本质上是一条或多条规则形成了闭环，理解last/break的区别、正确使用条件判断、合理拆分location是避免问题的关键。遇到循环时，第一时间开启rewrite日志定位问题源头。

相关文章推荐：

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