iperf3 UDP测试踩坑：TCP流量正常，UDP服务端收不到流量；

在日常网络性能测试中，iperf3是最常用的工具之一，某次TCP测试一帆风顺，但UDP测试却经常出现"诡异"问题。

TCP测试正常连通、带宽稳定，而UDP测试时客户端显示"发送成功"，服务端却始终收不到一个数据包，后面切换成手机热点连接，一切正常，抓包后发现，问题出在公司出口防火墙的策略上，公司出口防火墙默认禁止UDP流量，只放行常用UDP端口。

一、测试场景与异常现象

测试环境：客户端（Windows 10，iperf3.1.4）、服务端（Linux云服务器，iperf3），两者跨公网通信，服务端公网IP为14.103.245.*，测试端口5002。

测试过程：

TCP测试：客户端执行命令 iperf3.exe -c 14.103.245.* -p 5002 -t 10，服务端正常接收数据，带宽、延迟均正常，证明网络链路、服务端监听、端口放行无问题。
UDP测试：客户端执行命令iperf3.exe -c 14.103.245.* -p 5002 -u -b 10M -t 10，客户端输出显示"Sent datagrams"（看似发送成功），但服务端执行iperf3 -s -p 5002 后，全程显示 0.00 Bytes，一个数据包都未收到。

核心异常：TCP正常 ≠ UDP正常，客户端"发送成功" ≠ 服务端"接收成功"，排除了服务端、客户端配置问题。

二、排错过程，3个坑点

坑1：iperf3版本不兼容 + 服务端参数错误

最初服务端使用的是 iperf -s -u -p 5002（iperf2版本），而客户端用的是iperf3，导致客户端报 Connection refused。iperf2和iperf3协议不兼容。

此外，iperf3服务端无需加 -u 参数（客户端才需要用 -u 指定UDP模式），服务端加 -u 会直接报错 parameter error - some option you are trying to set is client only。正确的服务端命令是 iperf3 -s -p 5002 -B 0.0.0.0（-B 0.0.0.0 监听所有网卡，确保公网可访问）。

坑2：混淆"发送端抓包"的意义

为了排查问题，我们在客户端用Wireshark抓包，发现能抓到UDP数据包（源IP为客户端内网IP，目的IP为服务端公网IP），便误以为"数据包已经发出去了"，进而怀疑服务端配置有问题。

直到后来才明白：发送端抓到包，只代表数据包离开了操作系统协议栈，不代表真的从网口发出去了，更不代表能到达服务端。Wireshark的抓包位置在"系统协议栈→网卡驱动"之间，即便数据包被本机防火墙、出口防火墙拦截，抓包工具依然能抓到包------这是排错中最容易混淆的点。

坑3：忽略"云服务器安全组"与"公司出口防火墙"的区别

最初排查时，我们确认了云服务器安全组已放行UDP 5002端口（甚至临时放开了0.0.0.0/0的所有UDP端口），服务器内部firewalld/iptables也已关闭，便误以为"网络放行无问题"。

但忽略了一个关键：云服务器安全组管的是"公网→服务器"的入站流量，而公司出口防火墙管的是"客户端→公网"的出站流量。我们只放开了服务器侧的入站，却没考虑客户端侧的出站是否被拦截。

三、终极定位：用tcpdump找到"罪魁祸首"

既然客户端抓包有数据，服务端却收不到，最直接的方法就是在服务端抓包，看数据包是否真的到达了服务器。

服务端执行抓包命令：tcpdump -i any udp -nn（监听所有UDP流量，实时打印），然后重新执行客户端UDP测试，结果服务端抓包终端全程空白------这就明确了：数据包根本没到达服务端，被中间网络拦截了。

结合"换手机热点测试UDP正常"的现象，最终定位到问题：公司出口防火墙默认禁止所有UDP出站流量，仅放行DNS（53端口）、NTP（123端口）等常见UDP端口，而我们测试用的UDP 5002端口属于非标端口，被防火墙静默丢弃，且没有返回任何ICMP错误（静默丢包）。

补充：如果防火墙返回ICMP错误（如"端口不可达""协议不可达"），客户端抓包能看到对应的ICMP包；但静默丢包时，客户端只有UDP发送包，无任何错误反馈，这也是"出口防火墙拦截"的典型特征。

四、问题根源：公司出口防火墙为什么要限制UDP？

排查出问题后，我们联系公司IT确认，得知这是企业网络的标准安全策略，核心原因是UDP协议的"先天缺陷"：

UDP无连接、不握手、发完不管，源IP可伪造，极易被用于UDP Flood攻击（打满公司出口带宽）、放大攻击（利用DNS、NTP端口反射大量流量）；
恶意软件（病毒、木马、挖矿程序）常通过非标UDP端口偷偷传输数据，难以审计和管控；
企业日常业务仅需用到少数常见UDP端口（如DNS 53、DHCP 67/68、NTP 123），因此防火墙采用"默认拒绝所有UDP，只白名单放行业务必需端口"的策略，最小化网络攻击面。

五、解决方案与排错经验总结

1. 解决方案

联系公司IT部门，在公司出口防火墙（或上网行为管理设备）上添加规则：放行客户端IP到服务端IP的UDP 5002端口（或临时放行测试所需的UDP端口范围），添加后重新测试，UDP传输恢复正常，服务端能正常接收数据包、统计带宽和丢包率。

2. 核心排错经验（避坑指南）

iperf3 UDP测试：服务端无需加 -u，客户端必须加 -u 且指定带宽（-b），否则可能无法正常发包；
版本统一：客户端和服务端必须用同一版本（iperf2或iperf3），否则会报连接拒绝；
抓包定位逻辑：
- 发送端抓包有UDP → 本机应用、协议栈正常，不代表包发出去；
- 服务端抓包有UDP → 数据包已到达服务器，网络链路正常；
- 发送端有、服务端无 → 中间网络（出口防火墙、运营商）拦截；
防火墙区分：云服务器安全组管"入站"，公司出口防火墙管"出站"，两者缺一不可；
ICMP错误：有ICMP错误（端口不可达等）→ 服务端/网关明确拒绝；无ICMP错误 → 静默丢包（大概率出口防火墙拦截）。

iperf3 UDP测试的坑，大多源于对"协议特性""抓包逻辑""网络设备策略"的不了解。很多时候，TCP正常不代表UDP正常，客户端"发送成功"也不代表数据能到达目标。

遇到这类问题时，记住"双向抓包（客户端+服务端）+ 换网验证"的核心方法，就能快速定位问题------要么是工具配置错误，要么是网络设备拦截。而企业环境中，出口防火墙的UDP限制是最常见的"隐形障碍"，提前和IT部门沟通测试需求，能少走很多弯路。

希望这篇踩坑实录，能帮大家在后续的网络测试中避开同类问题，高效完成UDP传输性能测试。