📚 课程目录第4章端口冲突

端口冲突：端口被占用导致服务启动失败

端口冲突，说白了就是你要用的那个门牌号，被别人占了。

服务启动时会在某个端口上监听。如果这个端口已经被别的进程占用了，内核直接告诉你“地址已在使用”。这时候服务起不来，日志里就报错。

怎么判断是端口冲突？

我习惯先看启动日志，通常会有类似这样的关键字：

Error: listen tcp :8080: bind: address already in use
java.net.BindException: Address already in use (Bind failed)

如果日志看不出来，或者项目日志级别太高没打出来，那就得手动排查了。

常见问题原因

我把这几年遇到的端口冲突场景梳理了一下，基本逃不出这几类：

同一个物理端口被多个服务重复配置 —— 这种最直接，配置错误或遗漏了已占用端口。
服务异常重启后端口未释放 —— 进程死了，socket 还在 TIME_WAIT 状态。
系统保留端口与业务端口重叠 —— 比如 Linux 的 ip_local_reserved_ports 范围或 Windows 的动态端口范围。
中间件/代理无意中占用了端口 —— 我遇到过 nginx 里配了一个 upstream 端口，结果这个端口又是另一个业务应用的监听端口。
容器/虚拟机端口映射冲突 —— Docker 的 -p 参数或者 K8s 的 hostPort 配重了。

一个小技巧： 配置服务端口时，我习惯先问一下 infra 团队，确认这个端口是否在全局保留范围里。很多坑其实在前期沟通就能避掉。

排查方法速查表

拿到一个端口冲突报错，我一般按这张表来走：

步骤	命令 / 工具	目的
1	`ss -tlnp \| grep <端口号>`	Linux 上看谁在监听
2	`netstat -ano \| findstr :<端口号>`	Windows 上看端口归属
3	`lsof -i :<端口号>`	通过进程名确认合法性
4	`fuser <端口号>/tcp`	快速拿到 PID
5	`ps -p <PID> -o comm=`	确认该 PID 是否预期进程

核心排查流程

下图是我自己总结的一套端口冲突排查逻辑，每次出问题就照着走一遍。

嗯，这里要注意：别一上来就 kill 进程。先问问自己，这个端口是不是被别人故意占的？我之前有一次把监控 agent 的端口给杀了，结果告警全断了。

深度排查与常见误区

有些时候，ss 或 netstat 看不到端口占用，但服务就是报冲突。我遇到过两种情况：

IPv6 与 IPv4 双栈冲突 —— 服务监听 ::（IPv6 通配），但另一个服务监听（IPv4 通配），在某些内核配置下会冲突。用 ss -tlnp 时注意看 IP 版本。
SO_REUSEADDR 配置不一致 —— 一个开了 reuse，另一个没开，第二次启动就失败。这种情况多见于快速重启的场景。

避坑指南： 我曾经排查过一个 Java 应用端口冲突。日志里只报了一个模糊的 BindException，ss 却看不到任何进程在监听那个端口。后来发现是 /proc/sys/net/ipv4/ip_local_port_range 的范围覆盖了业务端口，系统自动分配出去了。检查一下内核参数，几秒钟就解决了。

Windows 环境差异

Windows 上排查端口冲突，我个人习惯用这几招：

netstat -ano | findstr :8080 —— 看看 PID 是谁。
tasklist | findstr 1234 —— 根据 PID 找进程名。
net stop winnat + net start winnat —— Windows 动态端口范围出问题时，重启 NAT 驱动可以让它重新分配。

Windows 还有一个常见坑：IIS 或 SQL Server 默认会监听 80 端口或 1433 端口。你本地的开发服务如果也选 80 端口，那肯定冲突。我建议开发机不要用 80、443、3306、1433 这些系统级端口，除非你确信没别人在用。

解决方案对比

端口冲突之后怎么解决？说白了就两条路：

场景	推荐方案	备注
冲突端口是预期之外的临时进程	`kill -9 <PID>` + 调查进程来源	如果是僵尸进程，记得排查服务生命周期管理
冲突端口是合法进程但可以移走	修改该进程的监听端口	记得同步给上下游或负载均衡
冲突端口是合法进程且不能动	修改自身服务的监听端口	配置文件中改 server.port 或 listen 参数
端口被系统保留范围覆盖	调整 `ip_local_reserved_ports`	或者把业务端口移到保留范围之外
容器端口映射冲突	`docker rm` 清理 + 检查 -p 映射	K8s 场景检查 Service 与 hostPort 是否重叠

我个人的一个习惯： 生产环境统一做端口注册表。每上线一个服务，就在 CMDB 里记录服务名、监听的 IP:端口、端口用途。端口冲突很多时候都是管理混乱导致的，有了端口注册表，至少能少踩一半的坑。

网络抓包确认

如果以上方法都查不出来，可能是 OS 级别的问题。比如 iptables 的 REDIRECT 规则导致真实端口已经被占用，但 netstat 看到的是另一个端口。这时候得抓包确认。

tcpdump -i eth0 port 8080 -nn -X

看 SYN 包是否被 RST 或者到了别的进程。老实说，这种情况我碰到的次数不多，但一旦遇到，抓包是最快的确认手段。

端口冲突这个问题，排查步骤相对固定，只要你掌握了 ss、lsof、netstat 这三板斧，再配上上面那张流程图，基本都能快速定位。关键是要冷静，别一看到报错就去杀进程，先看清楚谁占的、为什么占、能不能动它。