约 6 分钟读完 · 更新于 2026-10-21 · 文中每条都能在下面的配套工具里动手验证
先定位再动手：一条命令问出端口归谁
报错的含义是「这个 IP + 端口组合已经被一个 socket 占着了」，不是「服务起不来」。定位只要一条命令：macOS 和 Linux 用 lsof -nP -iTCP:8080 -sTCP:LISTEN，输出里的 PID 就是占用者，-n 跳过 DNS 反查、-P 显示原始端口号，在容器和本机混用时能省掉几秒和误判。拿到 PID 后先看它是谁：ps -p <PID> -o pid,ppid,command，往往这一眼就发现是上次没退干净的自己。
lsof -nP -iTCP:8080 -sTCP:LISTEN # 只看监听态，输出最后那列是 PID ps -p 12345 -o pid,ppid,command # 先确认这是谁 kill 12345 # 礼让：SIGTERM，让它自己收尾 kill -9 12345 # 五秒后还在，再上硬手段 # 没有 lsof 时：ss -tlnp | grep :8080
netstat -ano | findstr :8080 # 最后一列是 PID tasklist | findstr 12345 # 确认进程名 taskkill /PID 12345 # 先礼 taskkill /F /PID 12345 # 强制结束 # PowerShell 一行版： Get-NetTCPConnection -LocalPort 8080 | Select-Object OwningProcess
kill 的顺序：先 SIGTERM，再 SIGKILL
kill 默认发 SIGTERM，目标进程能收到并执行清理：关连接、刷缓冲、摘掉服务注册。发完等几秒再判断是否还活着，kill -9 是 SIGKILL，内核直接结束进程、不给任何清理机会，socket 处于什么状态完全看运气——写了一半的日志文件、被截断的响应、直接丢掉的优雅退出逻辑都是它的后果。所以顺序永远是：kill → sleep 2 → 再查端口 → 仍在才 kill -9。
kill -9 之后端口还占着：TIME_WAIT 与 SO_REUSEADDR
正常情况下，监听套接字会随进程消失而立刻释放。所以「kill -9 完端口还占着」几乎都是 TIME_WAIT：那是已经建立过的连接在关闭后留在内核里的状态，默认要等 2MSL（Linux 一分钟量级）才回收，netstat 会显示几十条 CLOSE_WAIT / TIME_WAIT。但 TIME_WAIT 不会让新进程 bind 失败（内核知道它们不占监听端口），真正阻塞的是 CLOSE_WAIT——对端没关连接而你这边泄漏了句柄。排查时把两者分清：前者等一会就好，后者说明你的代码没有正确关闭连接，得回去改代码。
端口状态一眼分清：谁真的挡着你
| 状态 | 含义 | 会不会挡住新进程启动 |
|---|---|---|
| LISTEN | 有进程在监听，等连接 | 会——这就是占端口的那个 |
| ESTABLISHED | 连接已建立，两端都在 | 不会 |
| SYN_RECV / SYN_SENT | 握手进行中 | 不会 |
| TIME_WAIT | 主动关闭方等待 2MSL 回收 | 不会，等一会即可 |
| CLOSE_WAIT | 对端已关闭，本地没关句柄 | 不挡端口，但句柄在泄漏 |
| 本机地址是 127.0.0.1 而外部连不上 | 只绑了回环地址 | 不会——是绑定地址选错了 |
三个「不是端口占用」的假象
- 只绑了 127.0.0.1，外部访问一律 Connection refused。服务正常、端口也正常，是监听地址写窄了；需要对外提供服务时绑 0.0.0.0 或具体网卡地址。
- IPv4 / IPv6 双重监听：同一个端口上，Node 与部分运行时会各占一个协议族，lsof 看到两个 PID 很正常；只 kill 掉一个之后另一个还在，报错照旧。
- 代理和网关占的端口：docker run -p 8080:80 时，宿主机上的 8080 由 docker-proxy 持有，杀掉应用进程没用，要先停容器。
端口号从哪来的：确认意图再动手
报错里那串数字通常有明确出处：配置文件里的 server.port、环境变量、前端 dev server 的默认值，或者框架自动 +1 挑下一个空闲端口。查清它属于谁再决定动作——端口号本身是公开信息，<a class="faq-link" href="/tools/port-lookup/">常用端口速查</a>能确认 3000、5000、8080、6379、5432 这些高频值分别归谁，避免误杀数据库或消息队列。另外，端口号只在同一 IP 上唯一：改绑 0.0.0.0 与改绑 127.0.0.1 冲突的是不同集合，「换个 IP 就能起」这种判断要建立在具体绑定地址上。
排查顺序：五分钟内定位到进程
- 确认报错来自谁：框架输出里那行 “started on port 8080” 之后紧跟的 EADDRINUSE，通常和日志里的最后一条正常请求对得上。
- 查占用者：lsof -nP -iTCP:<port> -sTCP:LISTEN（Linux 也可 ss -tlnp），拿到 PID。
- 查身份：ps -p <PID> -o command。属于自己就重启，属于别的服务先确认能不能停。
- 查是不是自己人：同一服务常有多个 worker 或 vite/webpack 的父进程，PID 是一组而不是一个，全停掉再启动。
- 顺手看状态分布：ss -ant | grep <port> | awk '{print $1}' | sort | uniq -c。大量 CLOSE_WAIT 说明连接泄漏，与端口无关但同样要修。
常见问题
端口被占用怎么释放？
先 lsof -nP -iTCP:8080 -sTCP:LISTEN 拿到 PID，确认是谁（ps -p
kill -9 之后端口还是被占用，为什么？
多数情况是残留的 TIME_WAIT 连接，它默认要等 2MSL 才被内核回收，但它不阻止新进程 bind，等一分钟通常就消失。真正会一直挡着的是 CLOSE_WAIT，说明对端已关闭而你的进程没释放句柄，属于代码里的连接泄漏，重启进程才能立刻腾出端口。
Docker 启动报端口被占用，但容器里服务已经停了？
宿主机的 8080 是 docker-proxy 持有的，它与容器进程的生命周期不同步，容器停了代理可能还在。先 docker ps 找到占用映射的容器并 docker stop，而不是在宿主机上乱 kill；或者换成随机映射 docker run -P，让宿主机自己挑端口。
怎么确认某个端口本来应该归谁？
先看配置来源（配置文件、环境变量、框架默认值），再用 常用端口速查对照 3000、5000、8080、6379、5432 这些高频端口的标准归属。临时调试要换端口时，优先只改自己的服务配置，并把端口做成可配置项，而不是硬编码。