项目场景：

笔者所在的项目组是一个电商项目的商户中心，商户中心的主要功能就是提高商户的入住、商户的管理、审核以及店铺的入住管理等。

问题描述：

业务产线反馈商户入住提示服务连接失败，然后要到客户的账号密码，进入系统发现服务确实连接失败，

打开network查看请求的响应，发现请求石沉大海，根本没有到达服务器。

原因分析：

1.前端没有收到服务端的任何响应，此时怀疑是不是服务响应超时，或者是服务出了什么问题，然后开始打开日志系统查看生产日志，发现服务日志刚刚还在打，当前请求的日志并没有体现然后确定是请求没有进入到服务器中。

2.确认了请求没有进入到服务器，然后开始排查服务是否出了问题，查看接口服务和对应的实现服务均正常，然后又通过接口访问生产服务，发现接口调用正常，确认了服务是没有问题的。

3.确定了服务没有问题后，初步怀疑是网关的锅，然后咨询其他产线的人员发现网关服务正常，联系网关人员确定了路由规则并没有变动后，排除网关。

4.排除自身服务和网关后，问题的出处只能怀疑是网络层面的问题了，只有网络层面的问题才会导致正常的服务无法访问了，然后几经周转联系到了生产的运维负责人，与运维确认了是生产于今日调整了网络的访问策略，导致了该问题的出现。

解决方案：

1.临时解决

与运维沟通后初步解决方案是调整网略策略（不知是以白名单的形式还是更改的网络配置，运维没有言明），

然后将服务初步进行了恢复。

2.彻底解决

当晚走了漏洞检修，在nginx服务器上配置了网关的代理，实现了访问的Referer和Origin同源，然后彻底解决了

该问题。

调整网络策略如何导致的前后端交互失败？

这是因为项目有一个遗留的坑，目前生产上商户中心的前端是直接访问的网关地址，并没有通过nginx进行代理这就导致了跨域问题，运维给出的解释是调整的网略策略禁用不同源的访问（Referer与Origin）这两者不同源请求其实是一个不安全的请求，这也就导致了生产的请求失败了因为生产是前端直接访问的网关，在请求中有修改Referer的值，就出现了这个问题。

总结

这个问题其实是偏向于前端和运维的一个工作，与后台服务没有太深的关系，但是作为一个比较典型的问题还是记录一下，防止下次在遇到类似问题。