UDP 端口测试怎么做？nc、nmap 与 iperf3 检测 UDP 端口是否开放

UDP 端口测试的难点在于 UDP 没有握手。测 TCP 端口时，SYN 发过去，收到 SYN-ACK 就是开放，收到 RST 就是关闭，结论很干脆；UDP 包发出去之后，如果什么都没收到，可能是端口开着但程序不理会你发的内容，也可能是被防火墙悄悄丢了。所以“怎么测试 UDP 端口是否开放”的答案不是某一条命令，而是三种手段配合：发一个对方会回应的包看有没有回复（nc、iperf3 或应用自己的客户端），用 nmap -sU 看端口落在哪种状态，以及在服务器上抓包，确认请求到没到、应答出没出。下面分别给出 Linux 和 Windows 上的命令，最后讲 DNS、游戏、VPN 等服务怎样验证防火墙和安全组。

为什么 UDP 端口不能用 telnet 测

telnet 只会建立 TCP 连接。telnet 203.0.113.10 53 测的是 TCP 53，和 UDP 53 是两个互不相干的端口，它连通了也说明不了 UDP 53 的情况。Windows 上常用的 Test-NetConnection -Port 同样只测 TCP。

UDP 包发出去之后，只会出现下面四种结果：

收到了什么	说明
UDP 应答	端口开放，而且服务认可了你发的内容
ICMP 端口不可达（类型 3，代码 3）	包到达了主机，但没有程序监听这个端口；iptables 的 REJECT 默认也回这种消息
其他 ICMP 不可达（主机不可达、管理禁止等）	路上的设备或主机防火墙明确拒绝了这个包，firewalld 的默认拒绝就属于这种
什么都没有	端口开着但程序不回应、包被防火墙静默丢弃、应答在回程中丢失，三种情况无法区分

最后一行是 UDP 测试最常见、也最容易误判的情况。很多 UDP 服务对看不懂的包一律不回：DNS 收到格式错误的查询可能直接丢弃，WireGuard 对没有通过认证的包不做任何回应，这是它们刻意的设计。所以 UDP 端口测试的原则是：能发应用自己的请求，就不要发空包；客户端看不到结果，就去服务器上抓包。

用 nc 测试 UDP 端口：-zuv 与收发测试

nc -zuv 是最常被搜到的写法，但它的结果要会读。以 Debian、Ubuntu 默认的 OpenBSD 版 nc 为例：

nc -zuv -w 2 203.0.113.10 9999
# Connection to 203.0.113.10 9999 port [udp/*] succeeded!

-z 表示只探测、不交互，-u 表示 UDP，-v 显示结果。它的做法是向端口发几个只含字符 X 的小数据报，只要没有及时收到 ICMP 端口不可达，就报告 succeeded。所以这里的 succeeded 只表示“没有被明确拒绝”，被防火墙丢弃的端口同样会显示 succeeded；只有不显示 succeeded 时，结论才是确定的：端口不可达。

更可靠的做法是两端配合，发一段文字过去，看对方收没收到、能不能回：

# 服务器上：在要测试的端口临时监听（端口必须空闲，正式服务要先停掉）
nc -u -l 9999                 # OpenBSD 版 nc
nc -u -l -p 9999              # 传统版 nc 的写法
ncat -u -l 9999               # RHEL、Rocky 等系统上的 nc 实际是 ncat

# 客户端：以交互方式连接，然后输入一行文字回车
nc -u 203.0.113.10 9999

客户端输入的那行字出现在服务器窗口里，说明去程是通的。接着在服务器窗口里输入任意文字回车，nc 会把它发回给刚才的客户端，客户端窗口里能看到，说明回程也通，测完两边按 Ctrl+C 退出。回程这一步不能省：状态防火墙、NAT 网关和非对称路由都可能让应答回不去，而 UDP 服务能用，必须两个方向都通。

不想手动输入回复时，可以用 socat 起一个回显服务，收到什么就原样发回去：

socat -v UDP-LISTEN:9999,fork PIPE

客户端执行 echo "probe-$(date +%s)" | nc -u -w 2 203.0.113.10 9999，2 秒内屏幕上打印出自己发的那行字，就说明一来一回都没有问题；-v 让服务器一侧同时把收到的内容打印出来。

nmap UDP 扫描：-sU 的四种结果怎么读

nmap 的 UDP 扫描要用 root 权限执行。建议只扫你关心的端口，并加上 --reason，让 nmap 说明每个判断的依据：

sudo nmap -sU -p 53,123,161,500,1194,51820 --reason 203.0.113.10
# 对没有回应的端口追加服务探测，尽量把 open|filtered 确认成 open
sudo nmap -sU -sV -p 1194 --reason 203.0.113.10
# 快速看最常用的 50 个 UDP 端口
sudo nmap -sU --top-ports 50 -T4 203.0.113.10

状态	--reason 显示	含义	下一步
open	udp-response	收到了 UDP 应答，有服务在监听	用应用客户端测功能是否正常
closed	port-unreach	包到达主机，但没有程序监听（或被 REJECT）	服务器上 ss -ulnp 查程序是否在运行、监听的地址对不对
filtered	其他 ICMP 不可达，如 admin-prohibited	被防火墙明确拒绝	查安全组、主机防火墙的拒绝规则
open|filtered	no-response	重试后仍然没有任何回应	加 -sV、改用应用请求，或在服务器上抓包

nmap 对 53、123、161 这类知名端口会发送符合协议格式的探测内容，所以 DNS、NTP、SNMP 服务通常能被识别为 open；对自定义的游戏端口、业务端口，它发的是空数据报，服务不回应，结果就停在 open|filtered。看到 open|filtered 不要急着下结论，它只说明“没有收到拒绝”。

closed 其实是个好消息：它通常说明包已经到达服务器、路上的安全组和 ACL 都放行了，剩下的只是程序没在监听，或本机防火墙以 REJECT 方式拒绝。filtered 和 open|filtered 才需要去查路上的规则。

只扫描你自己管理或已经获得授权的地址。UDP 扫描会向大量端口发包，对他人的服务器这样做可能违反服务商的使用条款。

iperf3 -u：测通断，也测丢包与抖动

nc 和 nmap 只能回答通不通。游戏、语音、视频、VPN 这类业务还关心丢包和抖动，这要用 iperf3 的 UDP 模式在两端实测：

# 服务器端
iperf3 -s -p 5201

# 客户端：UDP 模式，目标速率 20 Mbit/s，数据报 1200 字节，测 10 秒
iperf3 -c 203.0.113.10 -p 5201 -u -b 20M -l 1200 -t 10
# 加 -R 反过来测服务器发、客户端收的方向
iperf3 -c 203.0.113.10 -p 5201 -u -b 20M -l 1200 -t 10 -R

有一点经常被忽略：iperf3 的 UDP 测试要同时放行 TCP 5201 和 UDP 5201。它先用 TCP 连接到服务器的 5201 交换测试参数和结果，数据才走 UDP 5201。只放行了 UDP，客户端会直接报连接失败；只放行了 TCP，控制连接能建立，测试却会卡在开始阶段或报错，拿不到丢包和抖动数据。

输出的最后两行是汇总，数字仅为示例：

[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  23.8 MBytes  20.0 Mbits/sec  0.000 ms  0/20833 (0%)  sender
[  5]   0.00-10.04  sec  23.7 MBytes  19.8 Mbits/sec  0.215 ms  104/20833 (0.5%)  receiver

看 receiver 那一行：Jitter 是抖动，Lost/Total Datagrams 是丢失数和总数。几个判断方法：

• 先看 receiver 一行的总数。这一行由服务器统计后经 TCP 控制连接传回，Total 大于 0 就说明这个方向的 UDP 已经放行；再加 -R 测一次，确认另一个方向。
• -l 不要超过路径 MTU。默认 1500 的以太网 MTU 下，UDP 载荷超过 1472 字节就会被分片，分片在部分网络里会被丢弃，测出的丢包会偏高。用 1200 字节比较稳妥。
• 测通断用低速，查丢包再加速。不加 -b 时 UDP 只按 1 Mbit/s 发送，足够验证放行；要排查丢包，再逐级调高 -b：低速时也稳定丢包，问题在线路质量；某个速率之后丢包陡增，这个速率就接近端口的限速值或可用带宽。

测试时注意流量：大速率、长时间的 UDP 测试会占满端口带宽，影响同一台服务器上的业务；按 95 计费的端口，持续的大流量还会抬高当月的计费值。先用小速率、短时间测，确认需要再加大。

Windows 上怎么测试 UDP 端口

Windows 自带的 Test-NetConnection 不支持 UDP，有三种替代办法。

1. 微软的 PortQry 命令行工具（需要从微软官网单独下载）。它会对 DNS、SNMP 等常见服务发送协议格式的请求：

portqry -n 203.0.113.10 -e 53 -p udp

结果为 LISTENING 表示收到了应答，NOT LISTENING 表示收到 ICMP 端口不可达，LISTENING or FILTERED 对应 nmap 的 open|filtered。

2. 用 PowerShell 调用 .NET 的 UdpClient 发包。 Windows 有个便于判断的特性：对已连接的 UDP 套接字，收到 ICMP 端口不可达后，接收操作会报“连接被重置”，因此能把“端口关闭”和“没有回应”区分开：

$target = "203.0.113.10"; $port = 9999
$udp = New-Object System.Net.Sockets.UdpClient
$udp.Client.ReceiveTimeout = 3000
$udp.Connect($target, $port)
$data = [Text.Encoding]::ASCII.GetBytes("probe")
[void]$udp.Send($data, $data.Length)
$remote = New-Object System.Net.IPEndPoint([System.Net.IPAddress]::Any, 0)
try {
  $reply = $udp.Receive([ref]$remote)
  "收到应答: " + [Text.Encoding]::ASCII.GetString($reply)
} catch {
  $code = $_.Exception.InnerException.SocketErrorCode
  if ($code -eq "ConnectionReset") { "收到 ICMP 端口不可达: 端口没有程序监听" }
  elseif ($code -eq "TimedOut") { "3 秒内没有回应: 可能开放但不回包, 也可能被丢弃" }
  else { "其他错误: $code" }
} finally { $udp.Close() }

对端用上一节的 socat 回显服务配合，能完整验证往返两个方向。

3. 安装 Windows 版 nmap（安装时一并装上 Npcap 抓包驱动），用法与 Linux 相同；也可以在 WSL 里使用 Linux 的 nc 和 nmap。

DNS、游戏、VPN 等服务：用应用请求验证放行

服务器上开 UDP 服务时，最有说服力的测试是用这个服务自己的客户端发一次真实请求。常见服务的验证方法：

服务	常用端口	怎么测	怎样算通
DNS	UDP 53	dig @203.0.113.10 example.com +tries=1 +time=2	返回 NOERROR、NXDOMAIN、REFUSED 都说明端口可达，只有超时才是不通
NTP	UDP 123	sudo nmap -sU -p 123 --script ntp-info 203.0.113.10	端口显示 open，并列出服务器返回的时间信息
SNMP	UDP 161	snmpget -v2c -c 团体名 203.0.113.10 SNMPv2-MIB::sysUpTime.0	返回运行时间；团体名错误时设备不回应，表现和端口不通一样，先核对团体名
Syslog	UDP 514	logger -n 203.0.113.10 -P 514 -d "udp-test"	单向发送，到服务器日志里查这条记录
OpenVPN	常用 UDP 1194	用客户端连接，看日志是否完成 TLS 握手	启用 tls-auth 或 tls-crypt 时，服务器对未通过校验的包不回应，nmap 只能显示 open|filtered
WireGuard	常用 UDP 51820	客户端发起连接后，在服务器执行 wg show	latest handshake 有更新；它对未认证的包一律不回应
游戏服务端	按游戏文档，常为一段 UDP 端口	用游戏客户端或服务器查询工具连接一次	能列出服务器信息或进入游戏
IPMI	UDP 623	ipmitool -I lanplus -H 203.0.113.10 -U 用户 -P 密码 mc info	返回 BMC 信息

客户端看不到结果时，在服务器上抓包，一边测一边看：

tcpdump -nni any udp port 9999

客户端结果	服务器抓包看到	结论
收到应答	请求和应答都有	双向都通
没有回应	什么都没有	包在路上被拦：安全组、机房 ACL、客户端所在网络的出口限制
没有回应	有请求，没有应答	程序没在监听或不回应，或者本机防火墙丢弃了请求：tcpdump 在本机防火墙之前抓包，看到请求不代表防火墙放行了它
没有回应	请求和应答都有	应答在回程被拦：出方向规则、非对称路由，或客户端一侧的 NAT 和防火墙
收到端口不可达	有请求，回了 ICMP	端口没有程序监听，或者防火墙以 REJECT 方式拒绝

对应地检查服务器上的监听和防火墙。监听地址是 127.0.0.1 时，外部永远连不上，要改成 0.0.0.0 或具体的网卡地址：

ss -ulnp | grep 9999                    # 程序是否在监听，监听在哪个地址
firewall-cmd --list-ports               # firewalld，UDP 端口写作 9999/udp
iptables -S INPUT | grep -- '-p udp'    # iptables 中与 UDP 有关的规则
nft list ruleset | grep -n udp          # nftables

# Windows：找出涉及 UDP 9999 的防火墙规则，看是否启用、是允许还是阻止
Get-NetFirewallPortFilter -Protocol UDP | Where-Object LocalPort -contains '9999' |
  Get-NetFirewallRule | Select-Object DisplayName, Enabled, Direction, Action

安全组一侧最常见的三个疏漏：只加了 TCP 规则，没加 UDP 规则（“全部 TCP”不包含任何 UDP 端口）；游戏、语音要的是一段端口，只放行了其中一个；源地址写成了自己办公网的地址，真实玩家或客户端的地址不在其中。

在机房里怎么落地

UDP 测试里“能通但丢包”的情况，很多时候不是防火墙的问题，而是服务器所在的交换机端口被限了速：iperf3 的 -b 一超过端口限速值，丢包率就会陡然上升。Toplink DCIM 的 交换机管理 登记了每台服务器接在哪台交换机的哪个端口，服务器列表里就能看到端口速率和 VLAN，进、出方向的速率上限在服务器或交换机详情里设置；如果服务器配置了 带宽自动限速，按时间窗口统计的平均带宽一旦越过阈值，端口就会被自动限速，面板上会显示“限速中”。做 UDP 压测或客户反映游戏、语音丢包时，先看一眼端口状态，就能排除“测到的其实是限速”这种误判。