最近有了新机子，所以想把许许多多之前觉得可以但没做的小服务部署一下。并且之前经常遇到服务因为各种奇奇怪怪的问题Down了，就准备部署一个监控服务方便查看，还能用Telegram发通知。于是说干就干，笔者立马开始动手。这一动手就遇到了传奇的Lost connection to the socket server. Reconnecting...。

先直接给出结论，这是由 NDM (NeatDownloadManager) extension 导致的，禁用该插件即可解决。

定位问题

1. 检查 Docker 宿主信息

首先看到这个 Lost connection 我第一反应是与 Docker 的通讯不畅，于是按照文档里的 How to Monitor Docker Containers 挂载了docker.sock 配置 Docker 宿主信息。

1volumes:
2    - /var/run/docker.sock:/var/run/docker.sock

随后一连通，问题还是存在！查看日志也看不出所以然来。

那怎么办呢，我搜索issue发现有人提到了Troubleshooting部分，于是我按照这部分继续进行排查。

2. 检查 Docker 容器网络

按照文档里的Troubleshooting部分，我首先检查了Docker容器网络。

1apt update && apt --yes install curl
2ping google.com

没想到居然成功了，那怎么办呢。再继续搜索，发现在 Nodeseek 里有人提到了自己的 CDN 不支持 websocket 导致了这个问题，这给了我检查 ws 情况的想法。

3. 检查 WebSocket 连接

我的网站使用了 Cloudflare 的 CDN，ws 默认是支持的。为了进一步检查，我打开了浏览器开发者工具，检查了网络请求。

可以看到，ws 请求支持且存在，但是由于不明原因连接被结束了，于是浏览器反复尝试再次发送，和日志里面反复尝试登录想对应。这时博主想到了打开干净的 Firefox 尝试，发现问题居然解决了！那Chrome 到底存在什么问题，进一步的，博主发现无痕模式下问题也解决了。那问题自然锁定在了 Chrome 的扩展程序上。

解决问题

挨个排查扩展程序

首先要怀疑的必然是油猴脚本，一大堆脚本很有可能搞出什么问题来，但是没想到它是清白的。博主挨个从自己认为威胁度高的扩展程序开始排查，没想到居然都无关，直到禁用到 NDM 时问题居然解决了。这让博主大吃一惊，没想到 NDM 你这个浓眉大眼的也会搞事情啊。

那么为什么 NDM 会搞事情呢。Uptime Kuma 使用 WebSocket 通讯，来自于将普通的http请求 upgrade 到 ws 请求，NDM会拦截并监控所有网络请求，很显然 ws 请求并不是很普通同时也不是可下载文件，从结果来看 NDM 粗暴地中止了 ws，这使得浏览器反复发生请求，偶尔有几个漏网之鱼可以成功加载，这也就造成了日志中的大量登录记录。很可惜 NDM 并不是一个开源软件，也不是很活跃的项目，无法定位到底是什么原因导致的

总结

没想到一个 NDM 竟然让博主白白浪费了一个下午加晚上，一直到凌晨才解决问题。更可悲的是，博主之后又搜到了一个issue#4409，里面有人提到了 NDM 的问题，不过提到的这一部分被Github 默认隐藏了，同时也没有给出解决方案。目前 Chrome 插件依然不支持排除特定网页，如果要查看可能还是选择另一个浏览环境为妙。