1. 先弄清楚服务器端口到底是什么我们到底在查什么1.1 从一次网络连接说起很多接触服务器时间不长的朋友一上来就问“端口怎么查”但其实端口这东西理解起来并没有那么神秘。你可以把一台服务器想象成一栋写字楼每个服务器的 IP 地址就是这栋楼的门牌号而端口就是楼里的一个个房间。TCP/IP 协议里的端口号范围是 0 到 65535其中 0 到 1023 是知名端口通常绑定系统级服务比如 80 端口一般给 Web 服务用22 端口给 SSH 远程登录用3389 给 Windows 远程桌面用。1024 到 49151 是注册端口可以给普通应用使用49152 到 65535 则是动态端口通常是客户端临时分配的。当你访问一个网站时浏览器向服务器的 80 或 443 端口发起请求服务器响应后完成“握手”之后才开始传输数据。这个过程里端口承担的就是“识别服务”的职责。服务器上开着哪些端口意味着这台机器对外提供了哪些服务。我们查端口本质上是想搞清楚两件事第一这台服务器上哪些服务在跑、监听了哪些端口第二这些端口能不能从外部正常访问到。1.2 端口状态的几个关键概念查端口的时候你一定会看到类似LISTEN、ESTABLISHED、TIME_WAIT这样的状态词。这些状态并不难理解。LISTEN表示某个服务正在该端口上监听等着别人来连接。这是查端口时最关心的状态。ESTABLISHED表示当前已经有一条建立好的连接说明有客户端正在和服务端通信。TIME_WAIT表示连接已经关闭但系统还在等待一段时间确保网络上残留的数据包不会干扰新连接这是正常现象。CLOSE_WAIT表示对方已经关闭了连接但本地进程还没正式释放这个连接如果大量出现这个状态往往说明程序里有没处理好的连接回收逻辑。很多新手一看到TIME_WAIT或者CLOSE_WAIT就当成了故障这其实是个误区。TIME_WAIT是 TCP 协议正常的运行机制只要数量不是特别夸张都不用管它。CLOSE_WAIT如果一直在涨才需要留心是不是代码里有连接泄漏我在后面“常见问题排查”里还会细说。所以“服务器端口怎么查”这件事核心其实是一套组合技能先学会在操作系统层面查询端口监听和进程对应关系再掌握从外部验证端口连通性的方法最后还得懂一点防火墙规则和端口管理安全常识。下面我就按这套思路把 Windows 和 Linux 两侧的方法全部过一遍。2. Linux 下查端口从 netstat 到 ss、lsof一套组合拳2.1 netstat最经典但正被 ss 替代在大多数 Linux 发行版里netstat 通常是 net-tools 包的一部分。用之前可以先确认一下系统里有没有装没装的话CentOS 系列用yum install net-toolsUbuntu 系列用apt install net-tools。不过说实话现在很多新版系统已经默认不带 netstat 了我更推荐直接学 ss。netstat 查端口最常用的命令是netstat -tlnp每个字母拆开看-t表示只看 TCP 连接-l表示只看监听状态的端口-n表示把域名和端口号显示成数字而不是做反向解析不加这个参数排查问题时会因为 DNS 解析卡半天-p表示同时显示占用这个端口的进程信息。输出结果大概是这样的Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1234/nginx tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 5678/sshd这里的0.0.0.0:80表示这台服务器上所有网卡的 80 端口都在监听外网 IP 和内网 IP 都能访问到这个 Web 服务。如果某个服务只希望内网访问你会看到监听地址是内网 IP。这个细节很关键它决定了服务的暴露范围。如果你只想看某个特定端口比如想看 6379Redis 默认端口有没有被监听可以加上 grepnetstat -tlnp | grep 6379查不到任何输出就说明这个端口当前没有服务在监听或者服务监听在其他 IP 上。这时候别急着下结论还要结合服务进程本身的状态来判断。2.2 ss 命令又准又快强烈建议第一个学ss 是 iproute2 包里的工具执行效率比 netstat 高很多。在连接数很多的服务器上netstat 可能会卡住但 ss 不会。所以我也习惯先把 ss 用熟。查看所有监听中的 TCP 端口ss -tlnp-tTCP、-l监听、-n数字显示、-p进程信息这些参数含义和 netstat 完全一致。如果你想连 UDP 端口一起看就换成ss -ulnpUDP 端口虽然没有“监听”和“已连接”这种状态区分但服务同样要绑定端口才能接收数据像 DNS53 端口、DHCP67/68 端口这些都是典型的 UDP 服务。还想看所有处于已建立连接状态的连接就用ss -tnp这个命令在排查“某个客户端到底连没连上服务器”时特别有用。比如你开了个 8080 端口的服务外部客户端说“连不上”你先ss -tlnp | grep 8080确认服务在监听再ss -tnp | grep 8080看有没有建立连接很快就能判断问题出在哪一层。2.3 lsof 和 fuser通过端口反查进程有时候你查到某个端口被占了但进程名看起来模模糊糊或者你想知道到底是哪个程序监听的这时候 lsof 就派上用场了。lsof 的全称是 list open files在 Linux 里一切皆文件网络连接也被当作文件来管理。所以用 lsof 查端口也是常规操作lsof -i :8080这条命令会显示所有关联到 8080 端口的进程和连接。输出里能直接看到 PID 和进程名。如果想强制结束占用端口的进程可以用 fuser 一步到位fuser -k 8080/tcp不过这个命令要慎用它会直接杀掉占用端口的进程如果你误操作把重要服务的端口给“清理”了那就得赶紧重启服务了。我一般只在确认某个进程是僵尸进程或者完全没用的残留进程时才会用它。还要提到一点如果你是用普通用户执行这些命令部分进程信息可能看不到因为涉及权限。必要时加sudo就能看到完整信息了。2.4 端口对应进程识别的注意事项端口查出结果以后把端口号和服务对应起来也需要一点经验。比如看到LISTEN的端口是 3306你基本可以判断是 MySQL看到 27017 就大概率是 MongoDB。但有些服务是可以手动指定端口号的不能只靠端口号猜。我给你列一个日常运维中经常遇到的端口对应表端口号常见服务说明22SSH远程管理80HTTPWeb 服务443HTTPS加密 Web 服务3306MySQL / MariaDB数据库5432PostgreSQL数据库6379Redis缓存/消息27017MongoDB文档数据库8080常见 Web 备用端口各种应用631IPP 打印服务下面会专门讲3389Windows 远程桌面Windows 侧常用不过这只是经验值最终还是要通过ss -tlnp里的进程名来确认。最稳妥的办法是先看端口号再看进程名最后用ps -ef | grep 进程名确认这个进程到底是什么程序。3. Windows 上查端口命令提示符、PowerShell、还有 GUI 工具3.1 netstat -ano 组合拳Windows 也通用很多管理员觉得查端口是 Linux 的活儿其实 Windows 服务器同样需要这些操作。尤其在排查 Windows 服务器上 IIS、远程桌面或者各类业务应用的时候端口查询技能特别常用。Windows 上最经典的组合是netstat -ano-a显示所有连接和监听端口-n以数字形式显示地址和端口-o显示占用端口的进程 PID。这一步非常关键因为 Windows 上往往要凭 PID 去任务管理器里找对应进程。比如你发现 8080 端口被占了先执行netstat -ano | findstr 8080拿到 PID 后再执行tasklist | findstr 1234其中 1234 是你查到的 PID这样就能知道是哪个程序占用了。如果你想直接杀掉这个进程可以用taskkill /PID 1234 /F注意/F是强制结束也会导致进程内的未保存数据丢失使用前要确认这个进程确实可以结束。3.2 PowerShell 更现代Get-NetTCPConnectionWindows Server 2012 以后的系统PowerShell 已经默认内置了Get-NetTCPConnection这个命令。它比 netstat 的输出更结构化而且可以按状态过滤、按端口排序非常方便。查看所有监听状态的 TCP 端口Get-NetTCPConnection -State Listen如果你想看本地端口和对应进程可以使用Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess加了Select-Object之后输出就干净多了只有 IP、端口和 PID。但 PID 光是数字还不够继续配合Get-Process -Id 1234就能把 PID 对应的进程名、路径全部显示出来。还可以直接一行管道实现Get-NetTCPConnection -LocalPort 8080 | Select-Object LocalAddress, LocalPort, State, OwningProcess这种写法很适合直接复制到脚本里做定时巡检。3.3 资源监视器和 TCPView不想敲命令就用 GUI如果不想背命令Windows 自带“资源监视器”也是一个不错的选择。按Win R输入resmon回车切到“网络”选项卡下面就有“侦听端口”列表能看到端口号、进程名和绑定地址一目了然。不过说实话资源监视器的列表在端口数量较多的机器上刷新很不流畅我更喜欢微软官方的免费小工具 TCPView。它来自 Sysinternals 工具集十几年前就在用了列数据非常清晰能看到所有 TCP 和 UDP 连接双击某条记录就能跳到对应进程属性右键直接结束进程。下载地址在微软官网搜索 Sysinternals TCPView 即可这里就不贴链接了。TCPView 还可以设置高亮和刷新频率在排障时特别好用。连接状态一变就变颜色配合过滤条件你能非常直观地看到端口占用和连接的实时变化。3.4 Windows 防火墙查端口放行情况查完端口监听还要看防火墙到底放行了哪些端口。很多人遇到过这样的问题服务明明已经在监听端口了但从外部就是连不上十有八九是 Windows 防火墙没放行。查看当前所有入站规则里放行了哪些端口命令如下netsh advfirewall firewall show rule nameall dirin输出可能很长想快速找某个端口的话可以用 PowerShell 过滤Get-NetFirewallRule -Direction Inbound -Enabled True | ForEach-Object { $_.DisplayName }不过这个命令只列了规则名没直接列端口如果要看端口信息用Get-NetFirewallPortFilter会更好不过那又是另一套更复杂的操作了。日常排障时我建议直接用图形界面wf.msc打开“高级安全 Windows Defender 防火墙”左侧选“入站规则”右侧操作栏里选“按端口筛选”输入具体端口号就能看到相关规则。这个方法对新手比命令更友好也会显示出这个端口是被允许还是被阻止一目了然。4. 远端检测从你电脑上验证服务器端口通不通4.1 telnet 命令看起来老但依然好用服务器端口查清楚了本机也确认服务在监听了接下来最重要的一件事就是从客户端电脑上验证端口是否能通。因为“服务在监听”和“客户端能访问”之间还隔着一层防火墙、路由和安全组不能画等号。最简单的验证工具是 telnet。虽然很多教程都说 telnet 不安全但用它测端口仍然非常高效。在 Windows 命令提示符或者 Linux 终端里执行telnet 192.168.1.10 8080如果端口通屏幕会显示一个空白的连接窗口或者服务端的欢迎信息如果端口不通则会提示无法打开到主机的连接。这里要提醒一下Windows 默认可能没装 telnet 客户端你可以在“启用或关闭 Windows 功能”里勾选安装也可以在管理员 CMD 里执行dism /online /enable-feature /featurename:TelnetClient装好之后就能用了。测完端口记得直接输入quit退出。4.2 ncnetcat更强可以测端口范围还能测 UDP如果装了 nc也就是 netcat那能干的就更多了。它的写法比 telnet 稍微复杂一点但功能很强nc -zv 192.168.1.10 8080-z表示只扫描端口不发送数据-v是显示详细过程。端口通的话会提示succeeded不同版本 nc 输出格式不太一样但基本都能看出结果。nc 一次测试多个端口也很方便nc -zv 192.168.1.10 80 443 8080它也可以测试 UDP 端口nc -zuv 192.168.1.10 53UDP 测试有个天生的问题就是它没有连接状态某些端口即使没服务响应也会让你以为通了所以 UDP 的测试结果只能作为参考。真正要确认 UDP 服务正常还得看服务端日志和业务表现。4.3 nmap 批量扫描把“查端口”提升到安全审计层面前面讲的方法都是单点验证如果你想系统地了解一台服务器开放了哪些端口nmap 才是真正的利器。它既可以做单端口探测也可以做大范围扫描而且能识别服务类型和版本号。基础用法nmap -sS 192.168.1.10-sS是 TCP 半开扫描默认只发 SYN 包速度快且不容易在目标服务器上留下太多痕迹。如果你是扫描自己的服务器做安全审计也可以更直接地加-sV探测服务版本nmap -sV -p 1-10000 192.168.1.10这台机器上 1 到 10000 之间所有开放的 TCP 端口都会列出来并且会尝试识别每个端口后面是什么服务。我看过不少人拿着 nmap 去扫别人的服务器这个习惯非常不好。端口扫描在某些环境下会被视为不友好的行为甚至直接触发对方的入侵检测告警。所以我的原则很简单只对自己名下或者有书面授权的基础设施做扫描。对自己的服务器定期做端口审计是安全运维的基本功不是攻击行为。4.4 在线端口检测工具的使用分寸有些云服务器没有公网 IP 给你直接 telnet 操作这时候你会看到网络上有很多“端口扫描/端口检测”的在线工具号称输入 IP 和端口就能测通不通。这类工具确实方便但在使用前要注意两点第一准确率受制于工具本身的节点位置不同地区测出来的结果可能有差异别把它当成唯一标准第二这些工具背后是什么人在跑、数据用来做什么你完全不知道所以别拿生产环境的真实 IP 去做测试。我的建议是在线工具只用于初步判断最终还是要靠你从自己可控的客户端发起验证。5. 真实场景排查案例631 端口、开发工具端口冲突、存储设备管理端口5.1 打印服务 IPP 的 631 端口怎么确认Windows 服务器上开启 IPP 后对应的就是 631 端口。很多单位用 Windows Server 做打印服务器配置好 IPP 打印机后客户端总说找不到打印机这时候先验证 631 端口是否正常监听。在 Windows 服务器上用命令行netstat -ano | findstr 631如果看到LISTENING状态就说明打印服务的 IPP 接口已经启动。如果没有任何输出检查一下“打印服务”和“Internet 打印”相关角色是否装好了。接下来从客户端电脑上 telnet 服务器 IP 的 631 端口telnet 192.168.1.10 631能进入空白连接窗口说明网络层是通的。到这一步防火墙如果没有挡住 631 端口那大概率就是打印驱动或者打印机本身的问题了。我还遇到过一种情况服务器 631 端口正常但局域网内的交换机启用了端口隔离策略导致跨网段的打印请求被拦截。所以排查到最后别忘了检查网络设备层面的策略不能只盯着服务器本身。5.2 开发机上的端口冲突HBuilderX 项目启动失败的解法开发场景里端口冲突几乎是每天都会遇到的事。我把 HBuilderX 的例子放进来是因为很多人用这个工具做开发但一旦本地服务起不来完全不知道该从哪里查起。比如你在 HBuilderX 里跑一个项目默认会使用某个端口结果提示端口被占用或者服务启动失败。这时候不要慌先在命令行查一下端口被谁占了。Windows 上netstat -ano | findstr 端口号拿到 PID 后在任务管理器里看对应进程是什么。常见的情况是之前一次调试没有正常关闭残留了旧的 node 进程或者 8080 端口被其他本机 Web 服务占用。直接结束占用进程或者在项目配置里换一个端口问题就解决了。至于热搜里提到的“HBuilderX 查看哪里调用此函数方法快捷键”那是另一个编辑器的功能问题和端口排查不是一回事我在这里就不展开了。但你可以把它当作一个引子开发工具好不好用很大程度上取决于你懂不懂它的运行机制和日志信息。遇到端口冲突时优先从工具的输出控制台和系统端口占用两条线同时下手能省掉很多瞎折腾的时间。5.3 海康存储服务器 DS-AT1000S 管理端口识别思路像海康这种存储服务器 DS-AT1000S通常有专门的管理入口可能是 Web 管理界面也可能是配套的客户端工具。不少管理员刚接手设备时不知道管理端口是多少其实思路很简单。第一步查阅设备附带的技术手册或者官网文档里面都会有端口说明。第二步如果文档丢了就扫描设备 IP 的常见管理端口比如 80、443、8000 等看看哪个端口有 Web 服务响应。第三步使用配套的管理客户端软件设置里一般会显示出设备默认端口。但这里我想强调一下排错顺序如果设备管理页面打不开先确认服务器的 IP 能 ping 通再确认管理软件指定的端口和实际监听的端口一致。我见过有人折腾了半天端口最后发现是两台设备的 IP 配错了。物理链路、IP 连通性、端口连通性这三层的排查顺序不要乱。6. 端口管理和日常运维的几点建议6.1 端口放行原则能不开就不开能少开就少开有句话叫“端口即攻击面”每一个对外暴露的端口都可能成为被扫描和利用的目标。日常运维中我发现不少服务器的故障和安全隐患就是因为放开了太多不必要的端口。举个例子数据库端口 3306 通常只需要给应用服务器访问如果你在防火墙上把它暴露到公网那等于把数据库放到了大街上暴力破解只是时间问题。同理Redis 的 6379 端口如果允许外网访问可能出现未授权访问风险数据被清空都不是稀奇事。所以我给几条非常实际的建议对内网服务的端口在云安全组和系统防火墙两层都限制来源 IP只放行需要访问的网段。对外提供服务的端口单独通过负载均衡或反向代理转发后端服务不要直接暴露公网。定期检查防火墙规则把长期不用、已经失效的端口放行规则清理掉。6.2 建立端口档案别靠脑子记服务器多起来以后光靠记忆管理端口很危险。我自己的习惯是每台服务器都维护一份简单的端口档案表格内容包括端口号、服务名称、监听地址、对应进程、防火墙规则、负责部门、备注信息。这份表格不需要多么复杂一个 Excel 或者云文档就够了。每次变更端口、新增服务、调整防火墙规则时我要求相关同事必须同步更新文档。别小看这一步很多故障排查的瓶颈不在技术上而在于没人知道某个端口跑的是什么服务。有了这份档案排障时对照着查效率提升非常明显。6.3 用动态报告的态度做端口安全审计查端口不应该只发生在故障发生的时候。我建议把它变成一个周期性的工作每个月或者每个季度主动做一次端口审计。具体做法是用 nmap 或者专门的扫描平台扫描自己的服务器和网络资产把开放端口清单和之前记录的端口档案做比对多出来的新端口要确认是谁开的、是否合理少了的端口则要排查服务是否异常下线。我处理过的很多安全问题其实在早期端口审计中就能发现端倪。比如某台机器突然多了一个不认识的端口在监听后来查下来是被安装了后门程序又比如某个临时开的调试端口一直没关结果被外部扫描发现。这些问题的共性就是没有一套主动的端口检查机制。查端口这件事表面上是几个命令的事实际上是一种运维习惯的体现。在我个人的实际操作中无论是 Linux 还是 Windows查端口的命令都花不了几分钟真正难的是你愿不愿意在故障发生前就把它列入日常工作。如果你能把端口查看和防火墙规则审计绑定在一起做那这台服务器的网络层面基本上就是可控的。记住一个原则端口不在多而在清晰。清楚了任何问题都有迹可循。