反向代理配完第一次访问就打不开、页面一直重定向到一个内网地址、登录之后马上又跳回登录页，这类问题排起来特别费劲，因为Nginx的配置看着完全正确，proxy_pass那一行也没写错。多数时候，问题不在转发本身，而在转发时带过去的请求头，尤其是Host这个字段，它被默认改掉的方式和很多人的直觉是反的。更麻烦的是，这个改动是静默发生的，配置里看不到，日志里也不会提醒。
Nginx官方文档里写得很明确：在代理请求时，它默认会修改两个头字段，分别是Host和Connection，同时会把值为空字符串的头去掉。Host会被设为$proxy_host这个变量，Connection会被设为close。而$proxy_host指的就是proxy_pass里写的那个地址，也就是后端自己的地址，不是用户访问的域名。这个默认值不是缺陷，是为了兼容那些只认上游地址的服务，但它不适合大多数走域名的场景。
这意味着，如果后端是127.0.0.1:8000，它收到的Host就是127.0.0.1:8000，而不是用户浏览器里敲的那个域名。对只看内容的静态接口来说没差别，但对任何依赖Host判断自身身份的应用，后果立刻显现：框架按错误的域名拼跳转链接，会话校验认不出站点，跨域和Cookie的作用域全乱套，表现出来就是一堆莫名其妙的跳转和登录失效。排查时你会以为是会话或Cookie出了问题，其实根子在那一行没写的请求头。
Host要显式传，转发链上的信息也要补齐
官方的解决办法就是在location里显式设置请求头。最核心的一条是proxy_set_header Host $host;，它把用户请求的原始域名交给后端，而不是代理服务器自己的地址。这一步补上，绝大多数跳转到了奇怪地址的问题会当场消失，配置改动只有一行，效果却立竿见影。它和权限、缓存那些设置不同，属于很少会引起副作用、可以放心先加上的一条。
光有Host还不够。后端通常需要知道真实的访客信息，所以官方示例里还会带上X-Real-IP和X-Forwarded-For这类头，把客户的真实IP和经过的代理链记录下来。如果站点跑在HTTPS后面，还要带上X-Forwarded-Proto，否则后端会以为自己被用http访问，进而生成一堆http链接，浏览器一加载就报混合内容，页面看起来能用，控制台里全是红色告警。
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://127.0.0.1:8000;
}
另一处高频踩坑点是proxy_pass里的URI。官方文档专门解释了这条规则：如果地址后面跟着URI，比如http://www.example.com/link/，那么这个URI会替换掉location里匹配到的那一段；如果地址后面不带URI，完整的请求URI会原样传过去。这就是为什么有人加了反代之后，访问路径少了一段或者多了一段——两行看起来几乎一样的配置，转发出去的地址完全不同。
还有个关于缓冲的默认值值得留意。Nginx默认开启响应缓冲，也就是后端返回的内容先存进内部缓冲区，等整个响应收完再一起给客户端。这对慢速客户端是好事，能省下后端的处理时间。但对着需要边算边推的接口，比如流式输出、实时日志，缓冲开着会让你看到内容迟迟不出来，因为它在等收完。这种情况要在对应的location里把proxy_buffering设成off，让数据边到边发。
如果站点前面不止一层代理，真实IP的传递要顺着链路一层层接上。每过一层，上游就把访客地址写进X-Forwarded-For，后一层再追加上自己的来源，最终由最后一跳把整套链路交给应用。这里最容易出的错是只配了第一层、后面忘了接，结果日志里记的全是上一台代理的地址，排查时等于蒙着眼睛找问题。
跟Host直接相关的一个典型故障是重定向死循环。后端因为拿到的域名不是自己认识的那个，会要求客户端跳到它认为正确的地址；浏览器跳过去之后，代理又用同样的方式把请求转过去，后端再要求跳一次，来回几趟浏览器就报重定向次数过多。看到这个提示，第一反应就该是去检查Host有没有被正确传递，而不是去查路由或者证书。
排查这类问题有个很直接的办法：让后端把收到的请求头原样打出来看一眼。不用去猜配置文件想表达什么，而是看实际到达的是什么，比对着文档推演快得多。Host是不是你要的域名、X-Forwarded-Proto是不是https、路径有没有被改，打印一次就一目了然，也就省下了一遍遍重启和猜测的时间。
反过来也要克制。不是头加得越多越好，加得越多越容易自相矛盾。比如上游已经把X-Forwarded-For填好了，你在这一层又用一个新值覆盖掉，链路就断了，后端拿到的是一个不完整的链条。原则是每一层只补自己该补的那部分，别去改写上游已经写好的事实，这样整条链路上的信息才是连贯可信的。
反代配不明白的时候，与其反复改proxy_pass，不如先把请求头这条线捋顺。多数配置明明是对的却打不开的情况，答案都在这条线上：你以为它帮你原样传了，实际上它按默认规则悄悄改了一个最关键的字段，而那个字段恰好是后端用来认自己的。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
