2. 端口占用现象：常见的端口冲突表现
端口冲突这事儿，说白了就是两个进程抢同一个门。系统只允许一个进程在某个端口上监听，第二个来的就得吃闭门羹。我这些年排查过不下上百起端口问题，总结下来，最常见的表现就两种：服务启动失败和连接被拒绝。
你想想看，一个服务起不来，或者客户端连不上，第一反应往往是配置写错了、防火墙没关。但很多时候，罪魁祸首就是端口被占了。咱们得学会从现象反推根因。
2.1 服务启动失败
这是最直接的表现。你执行启动命令，日志里啪地甩出一行错误，服务直接退出。我见过不少新手这时候慌了神，开始重启服务器、重装软件……其实看一眼错误信息就能定位。
典型错误日志
# Java 应用常见错误
java.net.BindException: Address already in use (Bind failed)
# Nginx 常见错误
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
# MySQL 常见错误
Can't start server: Bind on TCP/IP port: Address already in use
# Python Flask/Django 常见错误
OSError: [Errno 98] Address already in use这些错误的核心信息都一样——Address already in use。系统告诉你：你要用的地址和端口，已经被别人占了。
为什么会这样？我简单解释下底层逻辑。每个 TCP/UDP 连接由四元组唯一标识：源IP、源端口、目标IP、目标端口。服务端监听时，绑定的是 本地IP:本地端口。如果这个组合已经被占用，内核就会拒绝新的绑定请求。
我的经验：有一次线上 Tomcat 突然起不来，日志报端口被占。我查了监听列表，发现是另一个运维同事在同一台机器上部署了另一个 Java 应用，默认端口也是 8080。两个人没沟通好，就撞上了。从那以后，我要求所有服务端口必须在部署文档里显式登记。
2.2 连接被拒绝
服务启动成功了，但客户端连不上。这种情况更隐蔽。你 telnet 过去，提示 Connection refused。很多人第一反应是服务挂了，但实际可能是端口被其他进程占了，真正的服务根本没在预期端口上监听。
注意区分：
- Connection refused：目标端口上没有进程在监听。可能是服务没启动，也可能是端口被别的进程占了，你的服务被迫换了个端口。
- Connection timeout：网络不通，请求包没到达目标或被防火墙拦截了。
我举个例子。你配置了 Nginx 监听 80 端口，启动成功了。但客户端访问时一直报连接被拒绝。你查 Nginx 进程，发现它在跑。再仔细一看——Nginx 监听的是 8080，不是 80。为什么？因为 80 端口已经被 Apache 占了，Nginx 启动时自动 fallback 到了备用端口。这种情况，日志里通常会有警告，但很多人不看。
2.3 两种表现的对比
| 表现 | 发生时机 | 错误信息 | 根因 | 排查方向 |
|---|---|---|---|---|
| 服务启动失败 | 启动阶段 | Address already in use | 目标端口已被占用 | 查监听列表，杀旧进程或改端口 |
| 连接被拒绝 | 运行阶段 | Connection refused | 服务未在预期端口监听 | 查实际监听端口，确认端口冲突 |
这两种表现其实是一体两面。启动失败是主动冲突——你的服务想占一个端口，发现被占了，直接罢工。连接被拒绝是被动冲突——你的服务虽然起来了，但被挤到了别的端口，客户端按原端口连，自然连不上。
2.4 端口冲突的常见场景
我梳理了几个高频场景，你在实际工作中大概率会遇到：
- 同一台机器部署多个相同服务：比如两个 Tomcat 实例都默认用 8080，第二个必然起不来。
- 服务异常退出后端口未释放：进程被 kill -9 了，但内核还没完全回收端口。处于
TIME_WAIT或CLOSE_WAIT状态。 - 开发环境 IDE 残留进程：IDEA 或 Eclipse 启动过应用，关闭后进程没杀掉。下次再启动就冲突。
- 系统预留端口被占用：Linux 上 < 1024 的端口需要 root 权限。你用普通用户启动 Nginx 监听 80，就会报权限错误，但有时候也会被误认为是端口冲突。
- Docker 端口映射冲突：容器内部端口映射到宿主机端口，如果宿主机端口已被占用，容器启动会失败。
避坑指南：我曾经在排查一个 Kafka 连接失败问题时，花了两个小时看网络配置、防火墙规则。最后发现是 ZooKeeper 占用了 Kafka 配置的 9092 端口。两个服务都是默认配置，部署时没检查端口重叠。嗯，从那以后，我每次部署前都会先跑一遍 ss -tlnp 确认端口空闲。
2.5 端口状态与冲突的关系
要深入理解端口冲突，得先知道端口有哪些状态。TCP 连接的状态机比较复杂，但跟端口冲突直接相关的就几个：
- LISTEN：服务端在监听。这个状态下的端口，别人不能再绑定。
- ESTABLISHED：连接已建立。这个状态不影响新监听，但会影响端口复用。
- TIME_WAIT：主动关闭连接后，端口会停留在这个状态一段时间（2MSL，默认约 60 秒）。这个端口不能被新连接复用。
- CLOSE_WAIT：被动关闭连接后，等待应用层关闭。如果应用层不关，端口会一直挂着。
你想想看，如果一个进程异常退出了，但端口处于 TIME_WAIT 状态，你立刻重启服务，就会报 Address already in use。这不是真的被其他进程占了，而是内核还没释放。这时候可以等一会儿，或者设置 SO_REUSEADDR 选项。
快速查看端口状态的命令
# 查看所有监听端口
ss -tlnp
# 查看指定端口的状态
ss -tlnp | grep 8080
# 查看 TIME_WAIT 状态的端口
ss -tan state time-wait
# 查看 CLOSE_WAIT 状态的端口
ss -tan state close-wait2.6 知识体系总览
下面这张图把端口冲突的表现、根因和排查路径串起来了。你可以把它当作本章的思维导图。
这张图从端口冲突的两种表现出发，一路延伸到错误信息、根因、排查命令和解决方案。你可以把它当作排查时的路线图。遇到端口问题，先看是启动失败还是连接被拒绝，然后对号入座，按图索骥。
2.7 小结
端口冲突不是什么高深的问题，但处理不好会浪费大量时间。记住两个核心点：
- 服务启动失败：直接看日志，
Address already in use就是铁证。 - 连接被拒绝：别急着怀疑网络，先确认服务到底在哪个端口上监听。