Nginx反向代理之巨坑underscores_in_headers

一、背景

因为项目需求，在做Windows的相关的事情；基本架构就是Nginx--> Nginx --> IIS，在Linux机器上通过Nginx做反向代理到Windows的IIS；然后遇到的问题直接使用IIS的IP访问是没有任何问题的；只要通过Nginx的反向代理总会有部分会报错；报错具体如下：

1）表面错误

Server Error, unsaved changes may have been lost, please reload the page before you continue.

2）浏览器检查报错

3）应用层的具体日志报错如下

<error errorId="fe8491dc-8dd1-49f2-8339-1dc3863b2280" host="aaaaaa" type="System.Web.Mvc.HttpAntiForgeryException" 
message="The required anti-forgery form field &quot;__RequestVerificationToken&quot; is not present." source="System.Web.WebPages" 
detail="System.Web.Mvc.HttpAntiForgeryException (0x80004005): The required anti-forgery form field &quot;__RequestVerificationToken&quot; is not present.&#xD;&#xA;  
at System.Web.Helpers.AntiXsrf.TokenValidator.ValidateTokens(HttpContextBase httpContext, IIdentity identity, AntiForgeryToken sessionToken, AntiForgeryToken fieldToken)&#xD;&#xA;   
at System.Web.Helpers.AntiXsrf.AntiForgeryWorker.Validate(HttpContextBase httpContext, String cookieToken, String formToken)&#xD;&#xA;   
at SunGard.AvantGard.Web.Infrastructure.AntiForgeryHelper.Validate()&#xD;&#xA;   
at SunGard.AvantGard.Web.Infrastructure.UseAntiForgeryTokenOnPostByDefault.OnActionExecuting(ActionExecutingContext filterContext)&#xD;&#xA;   
at System.Web.Mvc.Async.AsyncControllerActionInvoker.AsyncInvocationWithFilters.InvokeActionMethodFilterAsynchronouslyRecursive(Int32 filterIndex)&#xD;&#xA;   
at System.Web.Mvc.Async.AsyncControllerActionInvoker.AsyncInvocationWithFilters.InvokeActionMethodFilterAsynchronouslyRecursive(Int32 filterIndex)&#xD;&#xA;   
at System.Web.Mvc.Async.AsyncControllerActionInvoker.&lt;&gt;c__DisplayClass7_0.&lt;BeginInvokeActionMethodWithFilters&gt;b__0(AsyncCallback asyncCallback, Object asyncState)&#xD;&#xA;   
at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncResultBase`1.Begin(AsyncCallback callback, Object state, Int32 timeout)&#xD;&#xA;   
at System.Web.Mvc.Async.AsyncControllerActionInvoker.BeginInvokeActionMethodWithFilters(ControllerContext controllerContext, 
IList`1 filters, ActionDescriptor actionDescriptor, IDictionary`2 parameters, AsyncCallback callback, Object state)&#xD;&#xA;   
at System.Web.Mvc.Async.AsyncControllerActionInvoker.&lt;&gt;c__DisplayClass3_1.&lt;BeginInvokeAction&gt;b__0(AsyncCallback asyncCallback, Object asyncState)" 
user="aaaaaa" time="2021-09-03T09:56:15.1925032Z" statusCode="500">

二、排查过程

1）直接使用IP行，加上Nginx的代理就是不行，说明肯定是Nginx的哪些配置有问题

2）通过浏览器的检查，发现直接返回错误就是400，Bad request；于是把网上所有关于400的可能给排除了，还是不行

3）因为对Windows的服务确实很少用，也没想着去看的应用日志；直到最后才想办法找到他的应用日志，发现了上面的问题

4）在Nginx的配置文件里加上underscores_in_headers on配置后，解决。

三、根本原因

请求的请求头参数有下划线，而Nginx代理默认会把header中参数有“_”下划线的参数去掉；解决这个问题只需要在Nginx的配置文件中添加：underscores_in_headers on；重启Nginx即可。在上面的这个问题中，就是因为Cookies的参数里有两个参数是带有下划线的，因此每次请求Nginx都会把这两个参数当作无效参数去掉，导致每次请求都需要认证，因此就会报上面的错误第一条。

四、总结

1）在做设计时就要考虑不要用下划线做请求头

2）作为SRE层面，排查一定要根据日志来，程序有问题一定是有证据的，不能只靠猜测；要去找到可靠的证据来验证自己的猜想。日志、日志、日志，重要的事情说三遍，绝对是你排查第一需要看的，自己就是因为思想上有一定的懒惰，没有直接第一时间去看应用日志，而是一直盯着浏览器返回的错误在排查导致排查时间过长。

3）排查问题从上到下，从下到上要适当的灵活变动；不能只停留在表层错误去排查问题，应用的日志是最能体现问题的。