Nginx永久重定向外部主机并保留子路径、请求方法及Header方案咨询

需求：将原服务器子路径 https://my-server1.com/api/old/subpath 永久重定向到外部主机根路径，需保留：

• 子路径（最终目标：https://my-server2.com/subpath）
• HTTP请求方法（以POST为主）
• 包含认证信息的请求Header

尝试过以下4种Nginx配置，均存在问题：

1. 配置1：

location ^/api/old(.*)$ {
    rewrite $scheme://my-server2.com$1 permanent;
}

问题：发送POST请求时返回404错误。

2. 配置2：

location /api/old {
    rewrite ^/api/old(.*)$ $scheme://my-server2.com$1 permanent;
}

问题：发送POST请求时返回405错误，推测POST请求被转为GET请求。

3. 配置3：

location ~ ^/api/old(.*)$ {
    return 308 $scheme://my-server2.com$1;
}

问题：发送POST请求时返回403错误，推测请求方法正常但认证Header未被转发。

4. 配置4：

location ~ ^/api/old(.*)$ {
    proxy_pass $scheme://my-server2.com$1;
}

问题：发送请求时返回502错误。

各配置问题拆解 #

• 配置1/2：permanent对应301重定向，HTTP标准里301会强制把POST请求转成GET，这就是405错误的根源；另外配置1的location语法错误（^不是合法的匹配前缀，应该用~或^~），导致路径匹配失效引发404。
• 配置3：308是永久重定向且能保留请求方法，但重定向是客户端发起二次请求的行为，默认情况下客户端不会自动转发自定义Header（比如认证用的Token），所以my-server2收不到认证信息就返回了403。
• 配置4：proxy_pass是反向代理而非重定向，这里的写法有问题——如果proxy_pass后面带路径变量，Nginx的URI拼接逻辑会出问题；再加上如果my-server2域名解析失败、网络不通或者请求头没传全，都会导致502错误。

正确方案推荐 #

如果要同时满足保留POST方法、认证Header的需求，单纯的HTTP重定向（308）做不到，因为Header转发是客户端行为，没法通过Nginx控制。这种场景下更适合用反向代理，由Nginx作为中间层转发请求，确保所有请求信息都能传递到目标服务器。

正确反向代理配置 #

location ^~ /api/old/ {
    proxy_pass https://my-server2.com/;
    # 转发主机头，让目标服务器识别请求来源
    proxy_set_header Host $host;
    # 转发真实客户端IP
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    # 开启所有请求Header转发，包括认证信息
    proxy_pass_request_headers on;
    # 显式保留原请求方法（默认已支持，显式声明更稳妥）
    proxy_method $request_method;
}

配置关键点说明 #

• ^~ /api/old/：用前缀匹配且优先级高于正则匹配，确保所有/api/old/开头的请求都走这个规则，避免和其他location冲突。
• proxy_pass https://my-server2.com/：注意末尾的/，Nginx会自动把/api/old/之后的路径（比如subpath）拼接在my-server2.com的根路径后，正好实现/api/old/subpath → /subpath的需求。
• proxy_pass_request_headers on：这是保证认证Header能被转发的核心配置，开启后Nginx会把客户端发送的所有Header原样传给目标服务器。

若必须用重定向（需客户端配合） #

如果业务上一定要用永久重定向，那只能依赖客户端修改逻辑：收到308响应后，自动携带原请求的Header发起二次请求。此时配置3的写法是正确的：

location ~ ^/api/old(.*)$ {
    return 308 https://my-server2.com$1;
}

但要注意，大部分默认的HTTP客户端（比如浏览器、原生curl）不会自动转发自定义Header，所以这种方案局限性很大，优先推荐反向代理。

内容的提问来源于stack exchange，提问作者bolino