外部不通，内部正常

用户报障，我在机器上 telnet 本地端口，通。外部用 TCPing 测，全部超时。服务活得好好的，只是外面进不来。

这种情况十有八九是安全策略，不是服务故障。一开始我还以为是运营商封了，查了半天。

两种表现

丢弃：探测包被直接扔掉，客户端只能一直等，最后超时。云安全组默认拒绝经常是这种。

拒绝：对方回一个 RST，连接立刻失败。这个更像端口没开，或者策略明确拒绝。有些策略对特定端口回 RST、对其它端口直接丢，同一台机器表现都可能不一样。

两种都只能说「没通过」，说不了「谁拦的」。

宝塔拨测控制台：定时拨测任务、节点与告警配置

宝塔拨测控制台：定时拨测任务、节点与告警配置

为什么反推不出设备

路径上可能有多层：云平台的安全组、系统防火墙、WAF、CDN、运营商的策略。

中间设备还可能伪装成对端发 RST，或者干脆静默丢弃。你看到的失败，和真实位置可能隔着好几跳。

想精确定位，只能逐层放开再测，或者查各层自己的日志。这也是为什么「ping 不通」和「端口不通」经常给出互相矛盾的结论。

对监控的影响

最直接的是误报：策略一变，几十个端口同时告警，实际上业务没事。

第二个是盲区：把裸端口探测当唯一指标，策略拦住了探测，你反而看不到真实的服务状态。

第三是告警疲劳：噪声多了，真正的问题就没人看。监控的价值在于发现变化，不是每天复述一次测量。

怎么调整

先明确监控目的：是要确认服务可用，还是确认端口对公网开放。这两件事不一样。

在宝塔拨测的控制台里配任务时，把探测范围和真实用户范围对齐。只对特定来源开放的服务，就别用全网节点去测。

能用业务层检查的，优先用业务层。一个能正常返回 200 的健康检查接口，比裸端口更有意义。业务层检查也可能被 WAF 拦，记得给它单独放行一条规则。

实在要测端口，就在策略里给探测节点留白名单，并且把这条规则写进变更记录。白名单要定期清理，旧探测节点留着就是暴露面。别为了监控方便，把整个端口对公网开放。

复测和告警

改完策略，用同一批节点复测，先确认预期内的能通、预期外的不能通。

告警阈值别按单次失败算，连续两三次失败再报，能过滤掉策略抖动和网络瞬断。

该警惕的是：策略没有变更记录，端口却突然从通变不通；或者只有某个地区被拦，其他正常。前者可能是有人改了规则，后者可能是区域策略。变更记录里写清谁改的、什么时候、为什么，排查时能省很多事。