有时候觉得自己用了很多年的nginx，应该是很了解nginx的， 但实际上，对于对于其中任意一个参数理解不深，就会在后续的时间里暴露成一个故障或者问题。

今天在rancher 之前配置了一个nginx， 目的也仅仅是将80端口转到8080. 这么简单的需求， 总不该出什么问题吧。

由于长时间不配置nginx， 具体的配置参数已经不会写了，就在一个git仓库中，找到了以前nginx配置文件，然后就抄过来了。

配置nginx

核心部分代码非常简单。

server {
    listen 80;
    server_name qa-rancher.xxx.cn;

    location / {
        proxy_pass http://127.0.0.1:8080;
    }

}

就是把80转到 8080， 这难道还有什么问题？

遇到问题

这果然还是遇到了问题，即使如此简单，在访问80端口时，无法登陆rancher ，在chrome的开发者工具中看到有几个请求，浏览器竟然是 127.0.0.1:8080 ,这让我非常纳闷，这不是我配置在nginx中的信息吗？ 怎么会反应到chrome浏览器中呢？

后来一想， 之前配置的proxy_pass 前面都有几个 proxy_set_header 的信息， 一直没有明白是做什么用的， 是否跟这个有关呢？

确实和这个有关

127.0.0.1:8080 这个信息rancher 是不知道的，只能是 nginx 传给rancher 的 ，而默认情况下， nginx 并没有传访问的浏览器头部信息，而是传的实际的 127.0.0.1:8080, 于是rancher 就认为是 127.0.0.1:8080 访问的，于是将返回的url 用127.0.0.1:8080 做了包装 。

为什么会这样

想到这里，突然理解了， 为什么需要设置 proxy_set_header Host $host; 这个信息就是告诉后端，我是用这个url来访问的， 这样后端就可以识别访问来源。

为什么需要识别访问来源

如果是纯html网页， 其实真不用识别来源啥的，直接返回就得了。 但是在分布式环境下，可能部分代码并不是在同一组服务器提供的， 这就需要服务端接收到信息的时候，需要拼凑出一个地址。

比如某公司的需求是：

1. 前端访问地址是 qa.xxx.com , 那么对应的后端就是be.qa.xxx.com
2. 如果访问地址时 prod.xx.com, 那么对应的后端就是 be.prod.xxx.com

这就需要代码有能力知道是通过哪个url 访问进来的。 这样才有办法拼凑后端地址。

解决方案

想通了这个问题， 解决方案就很简单了。

就是在 location 部分，添加 proxy_set_header Host $host;