节点慢了没人用？先分清是机器坏了，还是本来就没几个用户

今天我们在干的是一件听起来很朴素、做起来很容易翻车的事：给一批服务节点做长期体检和真实测速，搞清楚哪些该留、哪些该撤。一天下来手里的结论挺多，但最有价值的不是某台机器修没修好，而是三个反直觉的判断方法——它们能帮你少走很多冤枉路。这篇就摊开讲。

一、"人数少"要先分清：是服务坏了，还是本来就没几个用户

今天接手的第一件事是：某台节点被报"在线只有 1 个连接"，第一反应都以为是机器出问题了。实际排查下来，服务器没坏，是真的只有 1 个付费用户在多开。

怎么快速分清的？看两样：

• 先看服务状态：进程跑了 51 天没重启，重启后再加载用户表 0 错误，端口通、SSH 通——基础面是好的。
• 再看已建立连接的去重来源：17 条活跃连接全部来自同一个出口 IP，也就是 1 个人开了多个客户端。这一眼就足够定性。

最能唬人的是日志里 5 小时冒出 9085 条 "user do not exist"，看着像节点坏了。实际对上面板数据全对得上：站点有效用户 730 人，过期 99 + 封禁 12 + 流量用尽 9，那一堆 rejected 就是这些失效账号的老客户端在反复敲门。"user do not exist" 八成是过期/欠费账号，不是节点坏。先问一句"这些错误是谁在产生"，能省掉一整轮无谓的"修机器"。

二、测不通，先别怀疑机器，先怀疑参数

做真实测速时，第一批上去有 4 台直接测不通。按惯性差点就下结论"这几台有问题"。结果逐台翻配置表才发现：不是机器坏，是每一台的伪装参数不一样。

有的台 path 是 /img、Host 是某个图床域名；有的台根本不是 ws 而是 tcp。用同一套默认参数去连，当然全军覆没。

教训很硬：连接参数必须从每台节点自己的配置表现取，不能拿"统一模板"硬套。机器和机器之间的差异，往往就藏在这几个字段里。先对齐参数再测，能避免冤枉一大半机器。

三、单轮测速不可信，必须多轮取中位

这是当天踩得最值的一个坑：同一台节点，单轮测速能从 277 跳到 15，噪声大到能骗你做出完全错误的决策。

所以后来定了两条硬规矩：

• 3 轮取中位数，不做单轮判断；
• 每台独立的出口通道，避免互相干扰。

按这套重测后，结论一下子清晰了：同地区两台节点，一台 101、一台只有 14.6，差 7 倍；而那台慢的近 7 天流量从 146GB 崩到 0.2GB——速度崩了，用户自然跑光，数据和体感对上了。反过来，有台速度快到 164 却没人用，那是"可选面窄"，不是机器差。用数据把"速度慢"和"没人选"这两件事分开，撤换决策才有依据。

四、长期观察，比一次排查值钱

光修一天没用，我们把这件事落成了一个长期观察系统：每天定时采集，一次回溯直接拿到了 60 天历史底账，再配上每月一次的真实测速，把每台节点的流量、延迟、速度都摊在一张表上。目标是几个月后，能凭数据、而不是凭感觉，决定谁该留、谁该撤。

这套"先用数据把问题定性、再上长期跟踪"的思路，其实和土拨鼠自己在干的事是同一个路子：不靠临时印象做决定，靠一条能复取、能对账的完整记录。如果你想看看这类"长任务 + 自动检查 + 数据对账"在本机是怎么跑起来的，可以翻 功能页 里工作区与自动化那部分；想先算算持续运行的成本，定价页 有按量对照；真上手就 下载 装一个，拿一件自己的运维小事跑一遍。

五、一个 30 秒自查

下次你手头有一台"看起来不对劲"的节点或服务，动手前先问三句：

• "人少/报错多"——先分是故障还是用户本来就少，去看已建立连接的来源去重。
• "测不通"——先对齐这台自己的连接参数，别拿统一模板套。
• "速度慢"——先确认是不是单轮噪声，多跑几轮取中位再看。

三个问题过一遍，大部分"假故障"当场就能排除，剩下的才是真正值得花力气去修的。