问题现象：昨天，突然收到运输公司同事的日志报告，说明在线a服务器转发到主控首页的流量激增。 日志报告如下。
现象分析 ：1，从固定a设备IP传送到网站主页
2、UA给出其一致(暂且考虑抓住包的流程)。
3、1秒钟有300次访问
解决问题 ：
1、查看A设备服务器所有主主页的流量图：
2、相关服务器确认转发到首页的服务器程序查询appapserver.py的相关代码后发现：
有日志转发到ucloud B虚拟机，但未找到转发到首页的通信
出现困惑。
3、仔细调查运输日志，应该是来自http协议的请求，通过上述方法进行证明是tcp传输。 重新定位问题是在nginx代理上出现的问题。 a请确认机器的nginx配置。
4、果断切断跳转后，重启nginx服务器，确认运维监控是否有A设备到主页的流量。 ---！ 问题依然存在。
5、为了确认是否是nginx问题，很难知道是否是nginx传输引起的问题，切换keepalived主从，切换nginx负载，切换到其他备用机c。 结果显示，运维监控报告中的流量是从C机跳转而来的。
可以确认问题一定是nginx传输的问题。
6、仔细观察nginx配置，确实上述传输只有一个地方，传输前访问accesslog日志文件index.access.log文件的次数没有明显增加(问题1 )，理论上不应该这样做。 用浏览器开始测试用手敲击a机器的虚拟ip发现
虽然出现了与index.access.log对应的日志，但是一直跳到了首页的主页(问题2 )，明明已经禁用了rewrite跳转。
7、针对以上两个问题，推测nginx浏览器端有本地缓存，开启浏览器调试模式跟踪问题，发现直接用虚拟ip访问时返回301错误。 这是清除浏览器的缓存后，如果用新的虚拟ip访问，就会发现无法跳转到首页，然后返回304。
针对以上现象，发现nginx中存在本地混合。 因此，用户可以直接访问首页主页，在网上搜索配置并添加nginx header no-cache配置，然后修改为下图，以进行身份验证。
8、重新启动nginx，重新运行浏览器测试步骤后，发现浏览器无法访问主页。 好好享受运输维度的监控，去看看。 -！ 问题依然存在。
9、再反省一次。 通过虚拟ip直接访问可能是数据包问题。 通常，没有用户用这样的ip直接访问。 另外，UA的头部露出是考虑到数据包的可能性。 但是，为什么nginx访问日志没有量？
-align:left;">10、仔细观察 nginx 配置文件 好多 upsteam 转发 ，upstream 后端有很多服务 有日志采集 、算法推荐、各种平台。。。在之前仔细问了下同事都说没有往 首页转发过请求。。。再次费解。。。@_@ ````
11、仔细过滤后端服务后 再次发现 上文中 appapserver.py 脚本 有跳转到 ucloud 虚拟机上的请求，这是个测试环境 大家都可以随意改动 ，当时为了实时日志处理消息测试 spark 集群做测试用的转发。
12、果断查看了下ucloud 上虚机上的配置 发现 nginx 依然有这个首页的跳转流量 ，并且有accesslog 。额 问题终于找到 。。。屏蔽掉虚机上nginx服务 。再次观察 运维监控 。A 机器流量没了 。。。~~~~(>_<)~~~~
13、问题虽然有已经解决 ，但是依然存在如下疑问。纠结的程序员。
待解答疑：
1、为何监控日志中 显示的ip 是A 机器的 ，而不是虚机的 ？？
2、为何所有UA头出其的一致 ？？？
3、为何每秒日志量这么大？？？
4、监控日志中 请求体都是 / 空的 但是虚机上accesslog 请求体都是 /open ???
回答
1、 A机器 upstream 代理转发 配置了 proxy_set_header X-Real-IP $remote_addr; 。
2、 appapserver.py 脚本中构造了 假的固定的 UA头信息 。
3、 虚拟机nginx 配置 改动 ，导致好多流量都走了 默认的server host .并发突增。
4、 rewrite 重定向机制 。
折腾了 一天的问题 ，终于所有的情况都搞清楚。 最后只能说 ~~~
规范线上日志流程 ， 日志格式，日志转发等需求配置 ，防止各种埋坑。
转载于:https://blog.51cto.com/shongx/1716635