共计 2874 个字符，预计需要花费 8 分钟才能阅读完成。
一、背景
因为我的项目需要，在做 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 "__RequestVerificationToken" is not present." source="System.Web.WebPages"
detail="System.Web.Mvc.HttpAntiForgeryException (0x80004005): The required anti-forgery form field "__RequestVerificationToken" is not present.

at System.Web.Helpers.AntiXsrf.TokenValidator.ValidateTokens(HttpContextBase httpContext, IIdentity identity, AntiForgeryToken sessionToken, AntiForgeryToken fieldToken)

at System.Web.Helpers.AntiXsrf.AntiForgeryWorker.Validate(HttpContextBase httpContext, String cookieToken, String formToken)

at SunGard.AvantGard.Web.Infrastructure.AntiForgeryHelper.Validate()
 at SunGard.AvantGard.Web.Infrastructure.UseAntiForgeryTokenOnPostByDefault.OnActionExecuting(ActionExecutingContext filterContext)

at System.Web.Mvc.Async.AsyncControllerActionInvoker.AsyncInvocationWithFilters.InvokeActionMethodFilterAsynchronouslyRecursive(Int32 filterIndex)

at System.Web.Mvc.Async.AsyncControllerActionInvoker.AsyncInvocationWithFilters.InvokeActionMethodFilterAsynchronouslyRecursive(Int32 filterIndex)

at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass7_0.<BeginInvokeActionMethodWithFilters>b__0(AsyncCallback asyncCallback, Object asyncState)

at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncResultBase`1.Begin(AsyncCallback callback, Object state, Int32 timeout)

at System.Web.Mvc.Async.AsyncControllerActionInvoker.BeginInvokeActionMethodWithFilters(ControllerContext controllerContext, IList`1 filters, ActionDescriptor actionDescriptor, IDictionary`2 parameters, AsyncCallback callback, Object state)

at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass3_1.<BeginInvokeAction>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）排查问题从上到下，从下到上要适当的灵便变动；不能只停留在表层谬误去排查问题，利用的日志是最能体现问题的。