乐趣区

关于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)排查问题从上到下,从下到上要适当的灵便变动;不能只停留在表层谬误去排查问题,利用的日志是最能体现问题的。

退出移动版