Nginx 301重定向不生效？8个常见原因排查与解决方法

为什么Nginx 301重定向不生效

配置了Nginx的301重定向，结果浏览器就是不跳转——这种情况在运维日常中太常见了。本文总结了我实际工作中遇到的8个最常见原因，每个都给出了具体的排查思路和解决方案，帮你快速定位问题。

原因一：配置写在了错误的server块中

这是新手最容易踩的坑。Nginx的配置是按server块匹配的，如果你的重定向规则写在端口80的server块里，但用户访问的是443端口的HTTPS地址，重定向自然不会生效。

排查方法：检查你的rewrite或return指令所在的server块，确认它监听的端口和域名与实际请求匹配。

# 错误示例：重定向写在443的server块里，但用户访问的是80端口
server {
    listen 443 ssl;
    server_name example.com;
    return 301 https://www.example.com$request_uri;  # 永远不会执行
}

server {
    listen 80;
    server_name example.com;
    # 这里才是HTTP请求进来的地方
}

解决办法：确保重定向规则写在监听对应端口的server块中。

原因二：缺少Nginx重载配置

修改了Nginx配置文件后，如果只是保存了文件而没有重载Nginx服务，新配置是不会生效的。这个看起来很简单，但确实经常被遗忘。

# 修改配置后必须执行
sudo nginx -t          # 先检查配置语法
sudo nginx -s reload   # 再重载配置

注意：nginx -s reload是平滑重载，不会中断现有连接，可以放心在生产环境执行。

原因三：浏览器缓存了旧的301响应

301是永久重定向，浏览器会缓存这个重定向。即使你在服务器端已经改了配置，浏览器可能还记得旧的跳转目标，直接从缓存里读取。

排查方法：

• 用无痕/隐私模式打开页面测试
• 使用curl命令测试：curl -I http://example.com/old-url
• 清除浏览器缓存后重试

建议：在正式上线301重定向之前，先用302临时重定向测试，确认无误后再改为301。

原因四：正则表达式匹配错误

使用rewrite指令时，如果正则表达式写得不对，URL匹配不上，重定向就不会触发。

# 常见错误：没有考虑尾部斜杠
rewrite ^/old-page$ https://example.com/new-page permanent;
# /old-page/ 匹配不上，/old-page?foo=bar 也匹配不上

# 正确写法：兼容尾部斜杠和查询参数
rewrite ^/old-page/? https://example.com/new-page permanent;

排查技巧：在Nginx错误日志中查看rewrite匹配情况：

error_log /var/log/nginx/error.log info;

原因五：存在多条冲突的重定向规则

当配置文件中有多个server块或多个location块都定义了重定向规则时，可能产生冲突。Nginx按特定优先级匹配location，后面的规则可能覆盖前面的。

常见冲突场景：

• default_server的优先级干扰
• location块中的rewrite与server块中的return冲突
• include的子配置文件中有重复规则

排查方法：执行 nginx -T 查看完整合并后的配置，检查是否存在冲突规则。

原因六：proxy_pass或upstream干扰了重定向

如果Nginx前面还有一层代理（如CDN、负载均衡器），或者Nginx本身配置了反向代理，重定向的响应可能被上游服务器覆盖。

例如：Nginx配置了return 301，但后端应用也返回了一个重定向，最终用户可能看到的是后端的跳转而非Nginx的。

# 确保重定向优先级高于反向代理
location /old-path {
    return 301 https://example.com/new-path;
    # 这里的return会在proxy_pass之前执行，没问题
}

原因七：DNS缓存导致请求未到达目标Nginx

域名解析的DNS缓存可能指向旧的IP地址，导致请求根本没有到达你配置了重定向的Nginx服务器。

排查方法：

• 使用 nslookup 或 dig 确认域名解析是否正确
• 直接用IP+Host头测试：curl -H "Host: example.com" http://1.2.3.4/old-url

原因八：if指令的陷阱

Nginx中if指令是出了名的"坑"，官方文档明确警告："if is evil"。在location块中使用if可能导致重定向行为不符合预期。

# 不推荐的写法
location / {
    if ($host != 'www.example.com') {
        return 301 https://www.example.com$request_uri;
    }
}

# 推荐写法：用两个server块
server {
    listen 80;
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 80;
    server_name www.example.com;
    # 正常处理
}

排查清单总结

遇到301重定向不生效时，按这个顺序逐一排查：

1. 确认配置已重载 — nginx -t && nginx -s reload
2. 用curl直接测试 — 排除浏览器缓存干扰
3. 检查server块匹配 — nginx -T 查看完整配置
4. 验证正则表达式 — 注意斜杠和特殊字符
5. 排查规则冲突 — 检查是否有多个重定向规则互相覆盖
6. 检查代理层干扰 — CDN、负载均衡器是否修改了响应
7. 确认DNS解析正确 — 请求是否到达了正确的服务器
8. 避免使用if指令 — 用独立的server块替代

扩展阅读

• 批量检查HTTPS证书到期时间脚本
• HSTS配置后浏览器仍然走HTTP排查
• Nginx HSTS配置错误排查