1. 为什么你的Nginx代理总跳404？从Location头说起
最近在帮朋友排查一个诡异的Nginx问题：他的电商网站通过Nginx反向代理多个微服务，用户登录时总随机出现404页面。我打开Chrome开发者工具，发现点击登录按钮后出现302跳转，但Location头竟然指向了内网地址http://192.168.1.100:8080/login！这就是典型的代理重定向问题。
当Nginx作为反向代理时，后端服务返回的重定向响应会原封不动地传递给客户端。比如Java应用常用的Spring Security，在未登录时会自动302跳转到/login页面。如果没配置proxy_redirect，客户端拿到的Location头就是Tomcat容器的内网地址，浏览器当然找不到这个地址。
更麻烦的是单域名多路径场景。比如用同一个域名区分管理后台和用户端：
- https://example.com/admin 代理到后端8001端口
- https://example.com/app 代理到后端8002端口
当8001端口的服务返回重定向到/login时，如果不处理Location头，用户就会被错误地跳转到https://example.com/login（实际应该跳/admin/login）。这种问题在微服务架构中特别常见，我去年在容器化迁移时就踩过这个坑。
2. proxy_redirect指令的三种武器库
2.1 基础替换：字符串精准匹配
最直接的用法就是字符串替换，把后端返回的Location头中的旧地址换成新地址：
location /api/ { proxy_pass http://backend:8080/internal/; proxy_redirect http://backend:8080/internal/ /api/; }这个配置会把：
Location: http://backend:8080/internal/user/profile替换为：
Location: /api/user/profile注意替换时的路径拼接问题：如果proxy_pass带斜杠结尾（如http://backend:8080/internal/），Nginx会先去除请求URI的/api/前缀，再将剩余部分拼接到proxy_pass地址后。所以proxy_redirect的redirect参数必须与proxy_pass完全一致。
2.2 智能默认：default的魔法
对于标准代理场景，Nginx提供了更智能的default模式：
location /shop/ { proxy_pass http://127.0.0.1:9000/; proxy_redirect default; }这相当于自动做了如下替换：
proxy_redirect http://127.0.0.1:9000/ /shop/我在配置Kibana时就用过这个技巧。Kibana默认会重定向到/login路径，通过default模式自动转换为/shop/login，完美解决子路径访问问题。
2.3 核武器：正则表达式替换
遇到复杂场景时，正则表达式才是终极武器。比如处理带动态端口的重定向：
proxy_redirect ~^http://[^:]+:(\d+)/(.*)$ https://$host/$2;这个正则会：
~表示区分大小写匹配^http://匹配协议头[^:]+匹配主机名（非冒号字符）:(\d+)捕获端口号/(.*)$捕获路径
最终将http://backend:8080/admin转换为https://example.com/admin
3. 实战中的经典坑位与填坑指南
3.1 多服务共用一个域名的混乱
最近部署的监控系统就遇到这个问题：
- Prometheus => /monitor/prometheus
- Grafana => /monitor/grafana
- Alertmanager => /monitor/alert
解决方案是组合使用proxy_pass和proxy_redirect：
location /monitor/grafana/ { proxy_pass http://grafana:3000/; proxy_redirect default; # 处理grafana静态资源路径 proxy_redirect /grafana/public/ /monitor/grafana/public/; }特别注意Grafana这类自带前端路由的应用，除了处理Location头，还要处理静态资源路径。我当初漏了这点，导致CSS文件全部404。
3.2 容器环境下的动态代理
在K8s环境中，服务地址经常动态变化。这时可以用变量：
location ~ ^/service/(?<svc>\w+)/ { proxy_pass http://$svc:8080/; proxy_redirect http://$svc:8080/ /service/$svc/; }这个配置：
- 通过正则命名捕获
(?<svc>\w+)提取服务名 - 动态生成proxy_pass目标
- 同步更新proxy_redirect规则
3.3 多层代理的套娃问题
在云原生架构中，经常出现Nginx->Ingress->Service的套娃代理。这时需要逐层修正Location头：
# 第一层Nginx location /external/ { proxy_pass http://ingress-nginx/internal/; proxy_redirect http://ingress-nginx/internal/ /external/; } # Ingress-NGINX配置 proxy_redirect http://backend-service:8080/ /internal/;这种场景下，要像剥洋葱一样从外到内逐层处理。去年我们迁移到Service Mesh时就因为漏了一层，导致连环跳转错误。
4. 调试技巧与性能优化
4.1 快速定位问题
当遇到重定向问题时，我的诊断三板斧：
- curl -v查看完整响应头
curl -v http://example.com/login - Nginx日志添加调试信息
log_format debug '$remote_addr - $upstream_http_location'; - 浏览器开发者工具检查Network标签
4.2 性能优化建议
proxy_redirect虽然方便，但过度使用正则会影响性能。我的经验法则是：
- 简单场景用字符串匹配
- 中等复杂度用default模式
- 只有动态需求才用正则
对于高并发场景，可以关闭不需要的重定向处理：
proxy_redirect off;记得去年双十一大促前，我们通过将20个正则替换简化为5个default配置，QPS直接提升了15%。
4.3 安全注意事项
错误的重定向配置可能导致开放重定向漏洞。务必：
- 限制替换域名为白名单
proxy_redirect http://backend/ https://trusted.example.com/; - 避免使用过于宽松的正则
- 对用户输入做严格校验
上个月某金融公司就因Nginx配置不当导致重定向劫持，损失惨重。
