昨天帮朋友排查一个线上故障，查询折腾到凌晨两点。网站他那个网站突然打不开，端口服务器CPU飙到100%，查询日志里全是网站异常连接。我第一反应就是端口——端口被人扫了。用netstat一看，查询果然，网站8080端口上挂着几百个来自不同IP的端口半开连接。这活儿干多了你就明白，查询查端口这事儿，网站看着简单，端口里面门道不少。查询

最基础的网站工具是netstat和ss。Linux上我基本不用netstat了，端口ss更快，输出也更干净。比如ss -tlnp能列出所有监听的TCP端口和对应的进程，-u换成UDP。Windows上netstat -ano凑合用，但记得配合tasklist找PID对应的进程名。有一次我在一台Windows服务器上看到445端口被占用，以为是系统服务，一查PID才发现是个挖矿木马伪装成svchost.exe。这种事儿不亲自查一遍，光看文档永远学不会。

光看本地监听还不够，你得知道端口对外到底通不通。telnet是最土的测试方式，但很多新系统默认没装。我习惯用nc -zv target_ip port，-z是扫描模式，-v输出详细信息。要是想测UDP端口，nc也能干，但结果不一定准——UDP无连接，对方不回应不代表端口关闭。这时候就得靠nmap了。nmap -sU -p 53 target能扫UDP，但慢得让人抓狂，别在生产环境乱跑。

有一次客户说他们的网站端口明明开着，外网就是访问不了。我本地nc测了下，端口确实通。后来一查，是云安全组规则只放行了80，没放行443。这种云平台的安全组、防火墙、iptables三层叠加的逻辑，最容易出幺蛾子。你光看服务器内部端口监听没用，得顺着数据包的路径一层层排查。从客户端到服务器，中间经过的每一道关卡都可能把端口给你掐了。

查端口还得学会看连接状态。TIME_WAIT多说明短连接频繁，CLOSE_WAIT多说明程序没正常关闭socket。上次帮人调一个高并发服务，发现CLOSE_WAIT堆积到几千个，最后定位到是代码里忘了调用close()。用ss -s能看整体统计，ss -state close-wait能列出具体连接。这种细节，比背一堆命令参数管用多了。

最后说个野路子。有时候端口被占用，但lsof和ss都查不到进程，尤其是某些rootkit干的活儿。这时候可以试试cat /proc/net/tcp，直接翻内核的TCP连接表。虽然格式难看，但能绕过用户态工具的隐藏。真要遇到这种情况，别犹豫，赶紧查入侵痕迹吧——端口异常往往是系统被搞的前兆。

查端口这事儿，本质上是在跟操作系统和网络栈打交道。工具只是手段，理解数据怎么流动才是关键。下次再遇到端口问题，别急着百度命令，先想想数据包从哪来、到哪去、中间经过啥。思路顺了，命令自然就蹦出来了。