工具 · 2026年7月26日

为什么用Nezha探针

尽管Nezha爆出了惊天大漏洞(CVE-2026-53519)，而且我也不喜欢“Nezha”这个名称，我仍然坚持使用哪吒作为探针。 我见过一些其他选择，但是由于各种原因，我都没有使用

选项不使用原因
Komari探针算法耍赖皮
Beszel对tcp探针支持得似乎不大好
blackbox + prometheus + grafana听着很麻烦，还没研究过
…

Komari“探针算法耍赖皮”

和nezha最相似的产品就是Komari了，在很多方面，他的开箱功能做得比Nezha更好，比如：

但是唯一令我不满的的是，他的tcping探针算法非常诡异

换句话说，Komari 会把许多我本来想看到的高延迟尖峰，改写成更低延迟，或者改写成丢包/失败。这会显著减少图上的 spike。

Komari 探针算法源码
source: https://github.com/komari-monitor/komari-agent/blob/main/server/task.go

我觉得这完全是画蛇添足。愚以为，在网路上，tcp丢了就是丢了，超时了就是超时了；而Komari探针却认为这种丢包可能是测量误差，进而通过算法来人为降低丢包率，我实在搞不懂。

想象一下，如果每次采样都触发高延迟重测，而重测又测得低延迟结果。这条链路实际上是不大行的，但是画出来的探针图是一条线。这合理吗。。。

如果说未经komari算法过滤的裸TCPconnect可能会导致偏高的延迟，那Nezha 上面这种全天一条线的探针图为什么还存在呢？

akko 法兰克福探针图
akko 法兰克福 July25-26

如果探针硬编码已经过滤了一次延迟尖峰，那么消峰功能是干什么用的呢？

总而言之，我认为Komari的探针无法忠实地展示真实的网络延迟情况。给人一种报喜不报忧，专挑好的说 的感觉。对于我这种线路机爱好者来说，网络质量的体现非常重要。这种诡异算法足以一票否决Komari。

安全使用Nezha

虽然改一下komari的探针算法也不是很难，不过我目前一直在用nezha，短时间也懒得迁移了。。。所以我还是在使用nezha。。。

之前Nezha漏洞刚出的时候，我也被陌生人攻击过，不过我已经更新过Nezha版本，所以他应该没有成功。哈哈。如下是他尝试渗透的日志。

[GIN] 2026/06/16 - 14:47:15 | 404 | 1.42ms    | 2602:ffe4:8:5287:a25b:4451:27b2:31f8 | GET "/dashboard../data/config.yaml"
[GIN] 2026/06/16 - 14:47:16 | 404 | 534.465µs | 2602:ffe4:8:5287:a25b:4451:27b2:31f8 | GET "/dashboard../data/config.yaml"
[GIN] 2026/06/16 - 14:47:17 | 404 | 365.277µs | 2602:ffe4:8:5287:a25b:4451:27b2:31f8 | GET "/dashboard../data/config.yaml"

探针由两部分组成，中心面板端和agent端。想要尽量安全的使用探针，需要分别加固这两侧。