1. Nginx Rewrite基础概念解析
Rewrite是Nginx服务器中一个强大的URL重写模块，它允许我们在请求到达后端应用前对URI进行修改和重定向。这个功能在日常运维和开发中扮演着关键角色，特别是在以下场景：
- 保持旧URL兼容性同时进行站点结构更新
- 实现SEO友好的URL规范化
- 处理复杂的路由逻辑
- 实现A/B测试分流
Rewrite的核心原理是通过正则表达式匹配请求URI，然后根据规则将其转换为新的URI。这个转换过程发生在Nginx的rewrite阶段，早于其他处理阶段（如代理、缓存等）。
重要提示：rewrite规则会改变原始请求的URI，但不会修改查询字符串（即?后面的参数），除非显式地进行处理。
2. Rewrite指令详解
2.1 基本语法结构
Nginx的rewrite指令遵循以下标准格式：
rewrite regex replacement [flag];- regex：用于匹配URI的正则表达式
- replacement：替换后的目标URI
- flag：可选标志位，控制重写行为
2.2 常用flag参数
| Flag | 作用 | 典型应用场景 |
|---|---|---|
| last | 停止处理当前rewrite规则集，用新URI重新匹配location | 复杂的多级重写规则 |
| break | 停止处理当前rewrite规则集，但不再重新匹配location | 最终重定向规则 |
| redirect | 返回302临时重定向 | 临时URL跳转 |
| permanent | 返回301永久重定向 | 永久URL迁移 |
2.3 正则表达式技巧
Nginx使用PCRE正则引擎，支持以下常用匹配模式：
^匹配字符串开始$匹配字符串结束.*匹配任意字符（贪婪模式）[^/]+匹配非斜杠字符\d匹配数字()创建捕获组，可在replacement中用$1-$9引用
3. 实战配置案例
3.1 基础URL重写
# 将/product/123重写为/product.php?id=123 rewrite ^/product/(\d+)$ /product.php?id=$1 break;这个规则会：
- 匹配以/product/开头后接数字的URL
- 将数字部分捕获为$1
- 重写到product.php并传递id参数
3.2 多条件组合规则
# 同时处理带/和不带/的URL location /blog { rewrite ^/blog/([^/]+)/?$ /blog.php?slug=$1 last; rewrite ^/blog/([^/]+)/(\d+)/?$ /blog.php?slug=$1&page=$2 last; }3.3 域名重定向
# 将旧域名重定向到新域名 server { listen 80; server_name old-domain.com; return 301 https://new-domain.com$request_uri; }4. 高级应用场景
4.1 动态路由实现
# 实现类似框架的路由功能 location / { try_files $uri $uri/ @rewrite; } location @rewrite { rewrite ^/(.*)$ /index.php?route=$1 last; }4.2 多环境配置
# 根据不同环境重写URL set $env "prod"; if ($http_x_env) { set $env $http_x_env; } location / { rewrite ^/api/(.*)$ /api-$env/$1 break; proxy_pass http://backend; }4.3 前后端分离路由
# 处理前端路由的HTML5 history模式 location / { try_files $uri $uri/ /index.html; }5. 性能优化与调试
5.1 重写规则优化原则
- 精确匹配优先：将最具体的规则放在前面
- 减少正则复杂度：避免使用过于复杂的正则表达式
- 合理使用flag：理解last/break的区别
- 避免重复匹配：设置适当的终止条件
5.2 调试技巧
# 启用rewrite日志 rewrite_log on; error_log /var/log/nginx/rewrite.log notice;调试时可以添加临时规则：
rewrite ^/test/(.*)$ /debug.php?original=$1;5.3 常见性能陷阱
- 过度使用if：Nginx中的if指令有特殊行为，可能导致意外结果
- 捕获组滥用：不必要的捕获会增加CPU开销
- 无限重定向循环：规则设计不当会导致301循环
6. 安全注意事项
6.1 防止开放重定向漏洞
错误的配置可能导致开放重定向：
# 不安全的写法（容易被利用） rewrite ^/redirect/(.*)$ $1 permanent;安全做法：
# 安全的写法 rewrite ^/redirect/(https?://[^/]+\.example\.com/.*)$ $1 permanent;6.2 敏感路径保护
# 阻止对配置文件的直接访问 location ~* \.(ini|conf|env)$ { deny all; }6.3 请求限制
# 限制/admin路径的访问 location /admin { allow 192.168.1.0/24; deny all; rewrite ^/admin/(.*)$ /admin.php?page=$1 break; }7. 与其他模块的协作
7.1 与try_files配合
location / { try_files $uri @rewrite; } location @rewrite { rewrite ^/(.*)$ /index.php?q=$1 last; }7.2 与proxy_pass结合
location /api { rewrite ^/api/(.*)$ /$1 break; proxy_pass http://api_backend; }7.3 与map指令组合
map $uri $new_uri { ~^/old/(.*) /new/$1; } server { ... rewrite ^ $new_uri permanent; }8. 实际案例解析
8.1 电商网站URL优化
# 产品页URL美化 rewrite ^/product/([a-z0-9-]+)-(\d+)\.html$ /product.php?id=$2&slug=$1 break; # 分类页分页处理 rewrite ^/category/([a-z]+)/page/(\d+)$ /category.php?name=$1&page=$2 break;8.2 多语言站点处理
# 根据语言前缀路由 rewrite ^/(en|fr|de)/(.*)$ /$2?lang=$1 break;8.3 移动端适配
# 移动设备重定向 map $http_user_agent $mobile_rewrite { default 0; ~*(android|iphone|ipod) 1; } server { ... if ($mobile_rewrite) { rewrite ^(.*)$ /mobile$1 break; } }9. 常见问题排查
9.1 重写规则不生效
检查步骤：
- 确认配置文件已重载
nginx -s reload - 检查错误日志
tail -f /var/log/nginx/error.log - 使用curl测试
curl -v http://example.com/test
9.2 出现重定向循环
典型症状：
- 浏览器显示"重定向次数过多"
- 网络面板显示连续的301/302
解决方案：
- 检查规则中是否有自引用
- 确保有终止条件
- 使用break代替last尝试
9.3 特殊字符处理问题
对于包含特殊字符的URL：
# 处理含中文的URL rewrite ^/search/(.*)$ /search.php?q=$1? break;10. 最佳实践总结
经过多年Nginx运维经验，我总结了以下rewrite最佳实践：
- 保持规则简洁：每个规则只处理一个明确的任务
- 充分测试：在生产环境部署前进行完整测试
- 添加注释：说明每条规则的用途和业务场景
- 性能监控：关注rewrite对QPS的影响
- 版本控制：所有rewrite规则纳入配置管理系统
一个典型的良好实践示例：
# 将旧博客URL迁移到新系统 (2023-07更新) rewrite ^/blog/(\d{4})/(\d{2})/(\d{2})/(.*)$ /posts/$1-$2-$3-$4 permanent; # API版本控制 rewrite ^/api/v1/(.*)$ /api/internal/$1?version=1.0 break; # 静态资源缓存优化 rewrite ^/static/(.*)\.v\d+\.(css|js)$ /static/$1.$2 break;最后需要强调的是，rewrite规则虽然强大，但应该作为URL处理的最后手段。在可能的情况下，优先考虑调整应用本身的路由逻辑，保持Nginx配置的简洁性和可维护性。
