WebSocket 连接断开和重连：从心跳检测到断线重连策略的工程化实践：一篇不太像模板的实战记录

我碰到过最典型的一次，是首页偶发 502，重启就好，过几分钟又回来。最后不是代码的问题，是超时、keepalive 和上游池子的配合没理顺。

先把话说直一点：WebSocket 连接断开和重连：从心跳检测到断线重连策略的工程化实践 不是把参数堆满，也不是照着别人博客抄一遍就算完。真正起作用的，常常是一些小地方。

调整的时候，我更偏向小步来。一次只动一个地方，跑一轮，看看变化，再决定要不要继续。这样慢一点，但基本不会把自己绕进去。

这类问题最怕急。

如果一口气动太多，事后很难判断是谁在起作用。真正难的不是改，而是改完之后还能说清楚为什么这样改。

排错的时候，我通常会把最近改动过的东西重新过一遍，再去看错误日志和最慢的那一段链路。tail -f /var/log/nginx/error.log 这类检查可以顺手做一下，很多时候都能把方向先拉回来。

还有一个很现实的判断：线上事故通常没那么玄。很多事情不是系统自己坏掉，而是某个细节没对上，最后连锁反应把问题放大了。

几个细节我现在会特别留意：配置能跑，不代表高峰时扛得住。 错误日志比文档更诚实，别只看成功路径。 上游服务一抖，Nginx 的表现会被放大。

这些话听起来不花哨，但多数问题最后都落在这里。越是看着不起眼的地方，越容易影响最终结果。

我一般不会一上来就改东西。先看现象：是慢、是抖、是偶发错误，还是某个点一直在重复出事。这个判断比后面的操作更重要，因为方向一旦错了，后面改得越多越乱。

这一步最值钱的其实不是技巧，而是克制。把边界看明白，别急着往里冲。很多问题看着像配置，最后发现根本不是配置，而是资源、数据分布或者调用顺序先出了问题。

真要动手，我一般会先把几件基础事情抄下来：nginx -t、nginx -T | less、ss -lntp | grep nginx。这些命令不新，但能帮你先确认问题在不在你以为的位置。

有时候只要把这一步做对，后面就轻很多。反过来，如果一开始就凭感觉调，最后你会发现自己一直在兜圈子。

我更愿意把这篇文章看成一份可以直接拿去对照的记录。不是每一条都适合照搬，但顺序和判断方式通常比某个单点技巧更有用。

这一步如果省掉，后面多半要补课。

这一步如果省掉，后面多半要补课。

说白了，越是这种环节，越不能图快。

nginx -t nginx -T | less ss -lntp | grep nginx tail -f /var/log/nginx/error.log