Nginx rewrite配置域名跳转：从基础到进阶

一、rewrite模块核心机制解析

Nginx的rewrite模块通过正则表达式匹配请求URI，并基于匹配结果修改请求路径或重定向到新地址。其核心指令rewrite的语法结构为：

rewrite regex replacement [flag];

• regex：使用Perl兼容正则表达式（PCRE）匹配请求URI
• replacement：替换后的字符串，支持变量和反向引用
• flag：控制重定向行为（last/break/redirect/permanent）

1.1 域名跳转的典型场景

• HTTP到HTTPS：强制安全连接
• 旧域名到新域名：品牌升级或域名迁移
• 子域名合并：将分散的子站流量集中
• 路径规范化：统一URL大小写或去除尾部斜杠

二、基础域名跳转配置

2.1 HTTP到HTTPS永久重定向

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

关键点：

• 使用return 301比rewrite性能更高
• $host变量自动获取请求域名
• $request_uri包含查询参数

2.2 旧域名到新域名的301重定向

server {
    listen 80;
    server_name old-domain.com;
    rewrite ^/(.*)$ https://new-domain.com/$1 permanent;
}

优化建议：

• 使用permanent标志返回301状态码（SEO友好）
• 正则表达式(.*)捕获所有路径
• 测试时先用redirect（302）避免缓存问题

三、进阶配置技巧

3.1 带条件判断的域名跳转

server {
    listen 80;
    server_name example.com;
    # 仅对移动端UA重定向
    if ($http_user_agent ~* "(android|iphone|ipad)") {
        rewrite ^/app(.*)$ https://m.example.com$1 permanent;
    }
    # 其他请求保持原样
    location / {
        # ...原有配置
    }
}

注意事项：

• if指令在Nginx中性能较低，建议仅在必要时使用
• 考虑使用map模块替代复杂条件判断

3.2 多域名跳转的集中管理

http {
    map $host $redirect_url {
        default         "";
        old1.example.com "https://new1.example.com";
        old2.example.com "https://new2.example.com";
        ~^www\.(.*)     "https://$1";
    }
    server {
        listen 80;
        server_name ~^(.*)$;
        if ($redirect_url) {
            return 301 $redirect_url$request_uri;
        }
    }
}

优势：

• 集中管理所有跳转规则
• 易于维护和扩展
• 支持通配符匹配

四、性能优化与最佳实践

4.1 避免正则表达式陷阱

• 贪婪匹配问题：.*可能导致意外匹配

  # 不推荐（可能匹配过多）
  rewrite ^/(.*)$ /new/$1;
  # 推荐（明确边界）
  rewrite ^/([^/]+)(/.*)?$ /new/$1$2;

• 预编译正则：频繁使用的正则可提取为变量

4.2 跳转链优化

• 避免多次跳转（如A→B→C）
• 使用last标志减少内部重写次数

  rewrite ^/old-path(.*)$ /new-path$1 last;

4.3 日志与调试

server {
    rewrite_log on;  # 开启rewrite日志
    error_log /var/log/nginx/rewrite.debug debug;
    location / {
        rewrite ^/test(.*)$ /new$1;
        # 其他配置...
    }
}

调试步骤：

1. 使用curl -v查看响应头
2. 检查Nginx错误日志
3. 逐步注释规则定位问题

五、安全注意事项

5.1 防止开放重定向漏洞

• 严格验证$host变量

  server {
      listen 80;
      server_name ~^(www\.)?(example\.com)$;
      if ($host !~ "^(www\.)?example\.com$") {
          return 444;  # 关闭非法域名的连接
      }
  }

• 限制重定向目标域名

5.2 HTTPS配置要点

• 确保重定向后使用HSTS

  server {
      listen 443 ssl;
      server_name example.com;
      add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
      # ...其他SSL配置
  }

六、实战案例分析

案例1：电商网站域名升级

需求：将shop.old-domain.com所有流量跳转到new-domain.com/store

解决方案：

server {
    listen 80;
    server_name shop.old-domain.com;
    # 保留查询参数
    rewrite ^/store(.*)$ https://new-domain.com/store$1 permanent;
    rewrite ^/(.*)$ https://new-domain.com/store/$1 permanent;
}

案例2：多语言站点跳转

需求：根据Accept-Language头跳转到对应语言版本

解决方案：

map $http_accept_language $lang {
    default en;
    ~^zh-CN zh-CN;
    ~^ja ja;
}
server {
    listen 80;
    server_name example.com;
    if ($lang != "en") {
        rewrite ^/(.*)$ https://$lang.example.com/$1 permanent;
    }
}

七、常见问题解答

Q1：rewrite和return的区别？

• return直接返回状态码，性能更高
• rewrite可以进行URI修改和内部重定向

Q2：如何测试跳转配置？

1. 使用curl -I http://example.com查看响应头
2. 检查Location头是否正确
3. 验证状态码是否为301/302

Q3：跳转后丢失POST数据怎么办？

• 301/302重定向会丢失POST数据
• 解决方案：
  • 使用307/308状态码（保持请求方法）
  • 修改应用逻辑避免需要POST的重定向

八、总结与建议

1. 优先使用return：简单跳转用return 301而非rewrite
2. 保持规则简洁：避免嵌套过深的正则表达式
3. 重视SEO影响：确保使用301而非302进行永久跳转
4. 定期审计规则：删除不再需要的跳转配置

通过合理配置Nginx的rewrite模块，可以高效实现各种域名跳转需求，同时需兼顾性能、安全性和可维护性。建议在实际部署前进行充分测试，并监控跳转后的流量变化。