首页/网络/网络排障速查/nc 测端口:TCP 与 UDP

nc 测端口:TCP 与 UDP

netcat(nc/ncat)是端口检测瑞士军刀:-z 扫描模式、-v 详细、-w 超时、-u 走 UDP;不同发行版的 nc 实现参数有差异,需注意。

网络排障速查网络更新于 2026-10-13

nc 测端口

netcat 常被称作网络调试的瑞士军刀:它既能当客户端连出去,也能当服务端听进来。做端口排查时最常用的是只探测模式——连上就说明该端口有人监听,被拒绝说明主机可达但端口没开,超时说明包根本没回来。需要注意各发行版里的 nc 可能是三种不同实现,参数并不通用,写脚本前先确认本机用的是哪一种。

基本信息

常见实现openbsd 版、nmap 项目提供的增强版、busybox 精简版,参数互有差异
核心参数-v 输出过程、-z 只探测不传输、-w 超时秒数、-u 使用 UDP、-n 不解析名称
协议支持TCP 与 UDP;UDP 无连接语义,探测结论可靠性明显低于 TCP
反向用法用监听参数在同一网段对测,可判断是本地问题还是对端策略问题
权限普通用户可用;监听低位端口需要 root

典型使用场景

  • 服务割接后核验:确认新端口在新地址上真的可连
  • 批量巡检:用循环对一组端口一次性探测,快速产出可用性清单
  • 区分拒绝与丢弃:被拒绝说明策略为明确拒绝,超时说明包被静默丢弃
  • 跨网段验证:从不同来源分别探测,判断策略是否按来源网段差异化放行
  • 临时对测:在对端机器上起一个临时监听端口,验证中间路径是否放行

端口探测与对测

端口探测与对测
nc -vz -w3 10.0.0.5 22            # TCP 探测 22 端口
nc -vz -w3 10.0.0.5 53            # 这条测的仍然是 TCP,不是 DNS 的 UDP
nc -vzu -w3 10.0.0.5 53           # 明确使用 UDP 探测
for p in 22 80 443 3306; do nc -vz -w2 10.0.0.5 $p; done   # 批量巡检
nc -l 12345                        # 在对端起临时监听,配合探测验证路径
nc -vz -w3 10.0.0.5 12345 && echo 路径放行   # 连上说明中间设备没有拦这个端口

结果判读

输出结果含义指向
succeeded 或连接提示三次握手完成端口开放且中间路径放行
Connection refused对端明确拒绝端口未监听,或被策略设置为拒绝
超时无输出没有收到任何回应策略静默丢弃,或路由不可达
路由不可达提示本机或上一跳找不到路径路由与网关配置问题
UDP 探测无回应不可判定UDP 无握手,需业务层回应或抓包佐证
三种结果背后的动作完全不同:拒绝说明包到了对端,超时说明包丢在路上,路由不可达说明连本地出口都没找到,混为一谈会把排查方向带偏。
同一台机器上不同实现的参数差别很大:精简版可能没有只探测模式,增强版的方向参数与写法也不同,脚本里最好先探测本机版本。

探测策略对照

场景推荐方式理由
只放行业务端口的网络对业务端口做 TCP 探测与真实流量走同一策略,结论最贴近实际
需要判断 UDP 服务改用业务层请求配合抓包UDP 无握手,探测无回应不可判定
跨网段差异放行从不同来源分别探测并对照定位策略是按来源还是按端口区分
判断是否被静默丢弃对测:一端临时监听,一端连过来能直接区分拒绝与丢包两种拦截方式
对生产系统做批量端口扫描可能触发安全设备告警甚至封禁来源地址,扫描范围与频率要事先和网络安全团队确认。

易错点

  • 用 UDP 探测的无回应直接得出端口开放的结论,而它其实属于不可判定状态
  • 把不同发行版的 netcat 参数照搬过来,命令报错后误判为网络不通
  • 忘记设置超时,探测被丢弃的端口时长时间挂住,批量巡检脚本被卡死
  • 在容器内探测却按宿主的网络视角理解结果,回环地址与端口映射都会带来偏差
  • 批量巡检测试生产端口,触发安全告警或导致来源地址被临时封禁
  • 把探测结果当作业务可用性结论:端口连通只证明可以建连,业务是否正常还要看应用响应

数据来源与参考

  • man 1 nc(netcat-openbsd)
  • man 1 ncat(nmap 项目)

相关工具

​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌