同事问我：会不会把服务器测挂

准备加一轮端口监控，同事拦住我，说别把生产环境扫崩了。

这个担心合理，但要看怎么测。正常检测的代价，比很多人想象的小得多。我当时也愣了一下。

一次检测做了什么

发起 TCP 握手，成功后立刻关闭，不发请求、不传数据。

服务器那边的开销是：分配一个连接、走完握手、处理关闭。跟一个真实用户打开连接差不多。

不是扫描器那种半开连接洪水，也不是压测工具的并发冲击。真正消耗资源的是应用层请求，握手本身很轻。

TCP 检测：填域名和端口，多节点看连通与握手耗时

TCP 检测：填域名和端口，多节点看连通与握手耗时

什么时候会有影响

频率太高，比如一秒几十次，对老旧的防火墙或者连接表是个负担。老设备处理握手的能力比现代服务器低很多。连接表大小是常见的瓶颈，尤其是小规格的云主机。

范围太宽，扫全端口，会产生大量日志，也可能触发防护策略。

并发太大，同时从几十个节点发起，短时间连接数会上去。

这些情况下，影响来自「量」，不是「检测」本身。

参数怎么设

目标只写自己需要的，域名或 IP，别顺手扫网段。

端口写准确，用业务真实端口，不要全端口。

频率按分钟级就够，监控不需要秒级。

节点选主要地区，几十个节点同时跑没必要。在宝塔拨测的 TCP 测速里，它就是按你填的目标和端口探测，不会自动扩展范围。节点多不等于数据好，重复样本没有额外价值。这条底线比技术细节重要。

合规与边界

只测自己的资产，这条底线比技术细节重要。

扫别人家的地址，无论频率多低，都不合适，也可能违反规定。

这条底线比技术细节重要。

测完怎么确认

对比测试前后的负载、连接数和日志量。正常情况下曲线应该没什么变化。

如果发现连接数明显上升，先降频、缩范围，再观察。测试要有对照，否则感觉不可靠。检测频率和业务峰值错开，影响更小；临时排查可以短时加密，长期监控按分钟级，两者不要混着配。

看到告警变多，不一定是服务器被压垮，可能是触发了防护规则，这也是一种信号。小机器并发一高，先丢新连接，表现是间歇性失败，很容易误判，看日志里的 SYN 数量就能确认。别把自测当成攻击，但真触发了防护，按规则处理，找安全团队确认更快。

报告里写清测试窗口和频率，别人看到流量异常时能对上，省得半夜被叫起来查。监控是长期的事，别一次配太猛，先小范围跑一周再逐步扩，有异常就回退，稳比快重要，配置也一样。