判断服务器端口是UDP还是TCP，最直接的方法是查看端口对应的监听协议或尝试建立连接：Windows系统用netstat -an | findstr "端口号"，Linux系统用netstat -anp | grep 端口号或ss -tulpn，输出结果中TCP或UDP字样即为协议类型。
为什么要分清UDP和TCP端口
在排查网络故障或配置防火墙时,协议类型是关键变量，TCP和UDP虽然共用端口号范围，但工作方式截然不同。TCP端口提供可靠、有序的字节流传输，需要三次握手建立连接；UDP端口则发送独立数据报，无连接、无确认机制，适合实时性要求高的场景。
两者的应用场景差异巨大,网页浏览（HTTP/HTTPS）、邮件传输（SMTP/IMAP）、远程登录（SSH/Telnet）依赖TCP端口，而DNS查询虽默认使用UDP 53端口，视频会议、语音通话、游戏实时同步则多走UDP端口，值得注意的是，部分服务会同时占用TCP和UDP同一端口号，如DNS同时监听53端口，因此仅凭端口号无法确定协议，必须查看系统命令的输出结果。
查看服务器端口udp和tcp的命令有哪些区别
不同操作系统查看端口协议的命令语法不同,但原理一致：读取系统内核的网络连接表，以下是主流系统的常用命令，都需要在管理员权限下执行。
Windows系统查看端口协议
Windows自带netstat工具功能全面，打开CMD或PowerShell，输入以下命令查看所有活动连接及其协议状态。
netstat -an | findstr 端口号输出示例：
协议 本地地址 外部地址 状态
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING
UDP 0.0.0.0:5353 : - TCP行末尾的
LISTENING表示正在监听。ESTABLISHED表示已建立连接。 - UDP行没有专门的状态标识，如果存在监听，则显示为或具体端口绑定地址。
若需要查看对应进程PID,使用netstat -ano，随后通过tasklist | findstr PID定位程序名。netstat -ano | findstr 8080查看到PID为1234，再执行tasklist | findstr 1234即可确认是java.exe还是nginx.exe占用。
Linux系统查看端口协议
Linux中netstat和ss命令均可查看端口。ss是iproute2包提供的现代替代工具，性能更高，推荐优先使用。
ss -tulpn | grep 端口号参数含义拆解：
-t显示TCP端口-u显示UDP端口-l仅显示监听状态-p显示占用进程-n以数字形式显示地址和端口
若明确要查TCP监听端口,用ss -tlnp；查UDP用ss -ulnp，输出会列出users:(("进程名",pid=1234,fd=5))字段，可直接看到程序信息。
传统netstat命令同样可用：
netstat -tulnp | grep 端口号多数情况下，先执行不带端口的完整命令，再用grep筛选端口号更清晰。 执行netstat -tulnp时，如果权限不足看不到进程名，需在前面加sudo。
查看服务器端口udp和tcp的占用状态是Linux运维高频场景
实际运维中,检查端口冲突或排查监听异常时，lsof命令更直观。lsof -i :端口号能同时输出TCP和UDP，并用协议列区分，例如TCP :http (LISTEN)或UDP :domain。lsof需要单独安装，在大多数发行版中通过yum install lsof或apt install lsof获得。
使用lsof -i :53时，输出可能同时出现TCP :domain和UDP :domain，这意味着该端口两种协议均有服务在监听，应分别关注。
如何区分端口已被TCP还是UDP占用
当看到端口占用后,判断协议类型主要看命令输出中的协议列，但有几个特殊场景需额外注意。
同一端口号两种协议均被占用
输入ss -tulpn | grep 8080时，可能同时出现tcp LISTEN 0 ... 0.0.0.0:8080和udp UNCONN 0 ... 0.0.0.0:8080两行，这种情况下，两个独立服务共享相同端口号但使用不同协议，互不干扰，修改防火墙规则时需分别指定协议，例如安全组入站规则要添加TCP:8080和UDP:8080两条。
DNS查询同时使用TCP和UDP的53端口
DNS默认走UDP 53端口，但当响应数据包超过512字节时，会切换为TCP 53端口进行“区域传送”，因此查看53端口，几乎必然会看到tcp :53和udp :53同时存在，这属于正常现象，并非端口冲突。
端口状态为UNCONN表示UDP监听
在ss命令输出中，TCP监听状态显示为LISTEN，而UDP监听状态则是UNCONN（unconnected，未连接）。UNCONN并非错误状态，而是UDP协议面向无连接的特性服务端进程已经绑定端口等待数据包，但尚未收到任何入站请求。
若看到ss输出UDP行末尾有[::]:或0.0.0:，表示该端口监听在所有网络接口上，包括公网地址，此时需确认防火墙是否对该UDP端口开放了入站规则，大多数云服务器安全组仅放行TCP端口，UDP端口常被遗漏，导致服务间通信超时，行业共识认为，排查UDP不通问题时，优先检查安全组而非服务配置。
端口状态含义速查
| 状态关键字段 | 所属协议 | 含义 |
|---|---|---|
| LISTENING或LISTEN | TCP | 服务正在监听该端口 |
| ESTABLISHED | TCP | 已建立完整连接 |
| TIME_WAIT | TCP | 连接关闭后等待残留报文消失 |
| UNCONN | UDP | 服务已绑定端口，未接收数据 |
| CLOSE_WAIT | TCP | 对端已关闭，本地等待关闭 |
TIME_WAIT状态大量出现说明短连接请求频繁,并非故障，CLOSE_WAIT堆积则通常表示程序未正确关闭连接，需要检查应用代码中socket关闭逻辑。
端口信息查看完毕后的常见操作
确认协议类型后,可能需要进一步做以下验证。
- 测试TCP端口连通性：使用
telnet 服务器IP 端口号，若端口开放，界面显示连接成功；若拒绝连接，立即返回错误信息。 - 测试UDP端口连通性：UDP无连接特性导致Telnet无法测试，使用
nc -u -zv 服务器IP 端口号尝试发送UDP探测包，若端口开放，返回UDP packet sent successfully或类似提示；若端口关闭，可能收到ICMP端口不可达错误。 - 查看防火墙策略：Linux执行
iptables -L -n -v | grep 端口号或firewall-cmd --list-ports，Windows执行netsh advfirewall firewall show rule name=all。
对于购买香港或海外服务器的用户,国内访问UDP端口常因跨境线路丢包严重而表现不佳，应用层设计时尽量使用TCP端口承载核心业务，UDP端口仅用于实时音视频等必要场景，据工信部公开信息，跨境带宽质量波动属于网络基础设施层面的共性问题，应用架构需预留容错机制。
常见问题速答
服务器端口怎么看udp和tcp两者是否都开放
执行ss -tulpn查看监听列表，确认服务绑定了所需协议和地址，若监听正常，再通过外部工具验证防火墙放行状态，TCP端口用nc -vz 服务器IP 端口号，UDP端口用nc -u -vz 服务器IP 端口号，UDP的探测结果不够精确，因为UDP没有握手过程，即使未监听，也可能因无响应而显示成功。
防火墙规则里同时放行TCP和UDP端口有什么风险
放行UDP端口更容易被用于反射放大攻击,同时开放TCP和UDP同端口会增大攻击面，若业务不需要UDP，建议仅放行TCP，配置安全组时，明确指定协议类型，不要使用“全部协议”的宽泛规则，对外UDP端口仅对业务必需来源IP开放，并配合流量限制策略，DNS服务等必须开放UDP的场景，应确保服务器操作系统补丁及时更新，缓解已知协议漏洞。
排查UDP端口不通应该从哪里入手
按照“监听状态-防火墙-网络路径”三层顺序排查，先确认ss -ulnp能看到进程绑定对应端口，再检查服务器本机防火墙（firewalld或iptables）和云服务器安全组入站规则，最后从客户端执行nc -u -vz发送探测包，并在服务器端用tcpdump -i eth0 udp port 端口号 -nn抓包确认数据是否到达服务器，若服务器能收到请求但客户端无回应，检查服务进程的响应逻辑或出站安全组规则，常见的UDP问题根源在于安全组未放行UDP协议，而非服务本身故障。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/787943.html
