关于nginx:Nginx反向代理之巨坑underscoresinheaders

一、背景

因为我的项目需要，在做 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）排查问题从上到下，从下到上要适当的灵便变动；不能只停留在表层谬误去排查问题，利用的日志是最能体现问题的。