nc -uz 显示 succeeded，但 UDP 服务仍然不可用

用 nc -vzu 检查 DNS 等 UDP 服务时，终端显示 succeeded!，实际客户端却一直超时。甚至换成没有部署服务的端口，仍然得到相同提示。这样的输出不能作为“远端 UDP 服务已接收并回应请求”的证据。

这里针对 OpenBSD netcat 及相应发行版移植实现的 -u、-z 组合。名为 nc 的程序还可能来自其他实现，选项和探测行为并不完全一致。先查看本机 nc -h 与对应软件包手册，不要把某个实现的输出规则推广到所有 netcat。

成功提示没有完成应用协议验证

例如，下面只是有问题的检测方式示意，地址需替换为自己管理的目标：

nc -vzu 192.0.2.53 53

在 Debian 的 OpenBSD netcat 实现中，-uz 的 UDP 扫描会报告成功，不能据此确定目标状态。UDP 没有 TCP 那样的连接建立握手；本地发送操作没有立即报错，也不等于远端程序已经收到数据，更不等于它能够正确处理业务请求。

DNS 服务通常不会把任意文本当作有效查询。即使改用 echo 往 UDP 53 发送一句话，没有响应仍不足以判断端口关闭。某些协议本来就会静默丢弃格式不对或没有通过认证的数据。

把探测超时调长，或者在脚本中只判断 nc 是否返回 0，都没有补上这层协议证据。要判断服务可用，应发送合法请求，并核对相应的返回内容。

检查 DNS 时，用真正的 DNS 查询

以下适用于 BIND 9 的 dig。将 192.0.2.53 换成待检查的 DNS 服务 IP，把 service.example.com. 换成这台服务器应当能够回答的完整查询名：

dig -r @192.0.2.53 service.example.com. A +notcp +ignore +timeout=2 +tries=1

-r 避免用户的 .digrc 改变检测参数；+notcp 选择 UDP，+ignore 防止收到截断回答后自动改用 TCP。后两个参数限制单次等待和尝试次数，便于观察当前结果，不应直接作为所有网络环境的永久超时策略。

这条命令会发起实际网络请求。只查询已获授权的服务和名字；不需要对外部地址做端口范围扫描。

查看回答里的 SERVER、响应状态和所需记录。收到匹配的 DNS 响应说明这次请求获得了协议层回应，但 REFUSED、SERVFAIL 或非预期的 NXDOMAIN 仍不能算业务解析正常。dig 的退出码 0 包括收到 NXDOMAIN 的情况，不能再次把退出码直接等同于所需记录存在。

如果出现 tc 标志，说明收到的是截断回答。这里的 +ignore 只是为了单独观察 UDP，不能拿不完整答案做永久健康检查。正常解析还需要按 DNS 的规则处理后续传输；这也说明“UDP 有响应”和“完整 DNS 查询成功”是两个不同判断。

超时则只说明在给定尝试和时间内没有收到可用回应。服务没监听、地址或路由错误、策略丢弃、返回路径问题以及丢包，都可能造成这一结果，不能直接据此关闭防火墙。

非 DNS 服务，使用对应客户端并核对两端

NTP、VPN、日志接收等服务各有自己的报文格式和回应条件。用对应客户端或服务自身的状态检查，保留目标地址、端口、协议与请求时间。不要把 DNS 示例移到其他 UDP 端口上，或者为了让任意文本收到回应而修改业务服务。

能够管理两端时，可以结合服务日志或范围受限的抓包，确认请求是否到达、应用是否回应、回应是否回到客户端。只在接收端看到报文，证明的是该方向的数据到达；它不能同时证明回程和应用处理成功。抓包可能包含业务内容，采集范围与保存权限应按实际需要控制。

如果最终发现配置或网络策略确有问题，再针对具体监听地址、授权客户端和返回路径修正，记录修改前的设置供回退。无需先放开全部 UDP，也不要把内部服务暴露到公网来迎合探测工具的输出。

替换监控脚本时，先让新检查在相同目标上观察响应状态和实际结果，再替换原来的 nc -uz 判断。保留旧脚本便于回退，但应注明它只能提供有限诊断线索，不能恢复成“看到 succeeded 就判服务健康”的验收标准。