有前缀二级泛目录nginx如何实现反向玳理理

即便配置了nginx代理当服务返回重定向报文时（http code为301或302），会将重定向的目标url地址放入http response报文的header的location字段内用户浏览器收到重定向报文时，会解析出该字段并作跳转此时新的请求报文将直接发送给服务地址，而非nginx地址为了能让nginx拦截此类请求，必须修改重定向报文的location信息

使用proxy_redirect可以修改重定向报文的location字段，例子中会将所有的根路径下的url代理到nginx的/my/路径下返回给用户比如服务返回的重定向报文的location原始值为/login，那么经过nginx代理后用户收到的报文的location字段为/my/login。此时浏览器将会跳转到nginx的/my/login地址进行访问。

需要注意的是服务返回的重定向报文的location字段有時会填写绝对路径（包含服务的ip/域名和端口），有时候会填写相对路径此时需要根据实际情况进行甄别。

使用nginx代理最牛（dan）逼（sui）的情况就是http响应报文内写死了服务地址或web绝对路径写死服务地址的情况比较少见，但也偶尔存在最棘手的是写死了web绝对路径，尤其是绝对路径都没有公共前缀举个例子来说：

一般的web页面会包含如下类似路径：

• /api：用于后台服务API接口。
• /login：用于登录验证

对于这样嘚服务，可能的代理配置如下：

由于web页面或静态资源内写死了类似的绝对路径那么对于用户来说，通过页面内的链接进行跳转时都会請求到nginx服务对应的路径上。一旦存在另一个服务也包含类似的路径也需要nginx进行代理，那么矛盾就出现了：访问nginx的同一个路径下的请求究竟转发给哪一个服务

要解决这个问题，必须在用户收到报文前将报文的数据中包含的绝对路径都添加统一的前缀，如/my/public/my/api，/my/login这样nginx代理配置则可以简化为：

使用sub_filter对数据包进行替换的语法如下：

上述配置会将/my/下的所有响应报文内容的href=”/替换为href=”/my，以及src=”/替换为src=”/my即为所有嘚绝对路径添加公共前缀。

注意如果需要配置多个sub_filter，必须保证nginx是之上的即便如此，sub_filter也不能解决所有问题目前流行的js框架都会有自动渲染url的功能，也就是说很多绝对路径并非写死在静态页面内，也是由js代码框架动态生成的面对这样的情况，sub_filter也是无能为力了对于这樣的情况，笔者只能由衷地奉劝还是安静的改代码吧！