一、背景
负责的项目，在test环境，postman连续发送两次接口请求，第二次响应时间高达34s，该现象经常出现，影响QA测试执行效率。这种想象持续一段时间了，今天终于忍无可忍，向Dev和SRE发出求助信息，他们在第一时间，拉群进行讨论排查。
二、排查经过
首先，排查是否是服务内部处理慢导致的？
经查看接口内部处理耗时日志：发现只耗时：10 ms，所以排除服务自身处理慢原因。
接着：Dev 在postman中可以复现该高延时现象，然而SRE 使用curl 尝试多次，却没有复现高延时
postman 和curl为啥不一致呢？一个Dev说，可能跟postman 中keep-alive有关，将postman Headers中Connection：keep-alive 去掉，就不会出现高延时；加上，连续发送，就会出现高延时的现象。
但是，按照理论来讲，设置Connection: keep-alive之后，预期响应的延时会减少，但现在的现象是：设置Connection: keep-alive之后，响应延时比没启用 keep-alive 更高，这不合啊，继续联系SRE排查原因
然后，测试其他接口或网站，是否也有类似的高延时现象？
结论：test环境的 www.xxx.com域名下，每个接口都可以复现，uat和live没有这个问题。
初步定位：那就是网络，网关这块可能有问题。
最终发现，test环境 ，有个网络接口，将LAN口配置成了WAN口
三、解决办法
test环境，将网络接口配置成：LAN
四、收获成长
一个小的现象后面，都隐藏着合理的原因，只要耐心寻找，总会发现真相。
