前言：：：：差不多一切的问题不是网络问题就是配置问题！！！！！
懒得看的就往下看，最最最后面，问题解决和总结
当时有一个项目，有一定的并发要求，十台服务器，java项目（排查出来的问题是Linux的关系），前后端分离的，
前端相当于静态资源，使用nginx进行反向代理进行访问；
问题描述：访问域名，网站突然就无法打开，然后等几分钟再刷新，啥也没动，他就又能打开了，再过一会儿又不能打开了，还是内侧阶段，几本可以认为没有其他用户访问，不存在啥访问量太大的影响；
遇到问题了，还原一下当时的判断过程;
过程一：网站无法访问的时候，尝试访问了后台接口和静态资源，都无法访问，但是服务器上直接curl 127.0.0.1这样访问网站是没有问题的。而且看了一下系统内存，读写啥的都正常（看来我的后端代码没啥问题，静态资源肯定也没有问题的）
过程二：代码没问题，内存啥的也没问题，服务器本地访问也没问题，难道是nginx出毛病了么，于是清理了nginx的日志，特意等到了出问题的时候去刷新，nginx泡都不冒，日志都没有，根本就没进来，仔细思考了一下，难道我nginx装出问题了，nginx配置有问题，于是特意docker重新装了一个nginx，然后只配置了一个静态文件，原来的nginx关了，结果！！！还是偶尔无法访问，真的是哔了狗了
过程三：仔仔细细的回想了一下我以前对我做负载这台服务器干了啥，当时为了并发,https，在负载服务器上各种改，nginx配置，Linux配置都动了，然后想想好像当初没有记录自己修改了啥！！！公司没这种要求，我也不是运维，不清楚还要记录一下，遇到了这次的坑了才知道，。。改Linux这种看来还是要记录一下才行，当初jmeter测试并发的时候很多错误 connect time out啥的，百度去改了几个东西，改了nginx配置，改了Linux配置，然后突然并发率就蹭蹭蹭的上去了，然后就通过检验合格了，就没有然后了
还好我遇到新鲜的事情的时候喜欢记录一个书签，仔仔细细找了自己电脑上的书签，然后用两三台服务器和负载服务器的Linux配置去对比，很好，最后发现了
问题解决：
我竟然启用了tcp recycle，就这个坑了我
这个是之前在部署应用主机系统时，修改优化了部分内核参数，当时想的是为了增大主机对tcp的连接性能，防止遇到并发用户的连接，导致tcp 连接不能快速释放，从而引发服务器 出现性能上的瓶颈(会导致服务器内存和CPU的暴增)。因为client 与server 建立链接传输完数据后，会断开链接，而服务器这边还会有2MSL的 time_wait 时间，超过这个时间之后，正常情况下，该socket才会被释放， 然后才可以接收其它client的请求。因为server 的端口是有固定范围的，不是说65535个全部都用来建立连接( 可参看系统内核配置：net.ipv4.ip_local_port_range)。
另外关于time_wait具体的可以参考tcp 的4次断开后的状态。 所以为了快速回收和重新使用，才开启了 tcp的reuse 和 recycle。但没想到这个会引起这么大的问题。 并且这个参数之前确实也在前公司用过。但没有发现这个类似的问题（也可能是当时的监控不到位，没有发现也不代表该问题不存在。
总结
不要开启tcp_tw_recycle！！！ .重要的话说三遍。 一定要有配置管理！可以方便在系统出问题时，检查对主机所做的历史记录。考虑问题不能光从 软件程序、网络上，还要加入对主机系统的分析。tcpdump、ss、还有log等。
参考文章：https://aliasmee.github.io/post/is-my-website-response-time-so-why-slow/