讲解 Linux TCP/UDP 端口、监听地址、PID、systemd Socket、Docker 映射和安全停止。
先不要杀进程。在服务器终端用 sudo ss -lntup 找出监听地址、端口和 PID，再用 sudo lsof -nP -iTCP:端口 -sTCP:LISTEN 交叉确认。只读检查不会改数据；真正危险的是直接 kill -9 数据库、Nginx 或容器代理。默认处理是确认哪个服务应该占用该端口，再停掉错误的重复实例或调整新服务端口。
使用 ss 定位监听端口
sudo ss -lntup
sudo ss -lntp 'sport = :8080'
sudo ss -lnup 'sport = :53'TCP 与 UDP 是不同协议；同一端口号可以分别存在 TCP 和 UDP Socket。监听在 127.0.0.1、0.0.0.0、具体私网地址或 IPv6 地址，影响可访问范围和绑定冲突。
使用 lsof 核对进程
sudo lsof -nP -iTCP:8080 -sTCP:LISTEN
sudo lsof -nP -iUDP:53
ps -fp 1234
systemctl status example.service --no-pager找到 PID 后应判断它由 systemd、容器、进程管理器还是人工启动。直接 kill 由管理器托管的进程，管理器可能立即重新拉起。
容器端口需要额外检查
docker ps --format 'table {{.Names}} {{.Ports}}'
docker compose ps
sudo ss -lntp 'sport = :8080'容器内应用端口与宿主机发布端口不同。冲突通常发生在宿主机发布端口；修改 Compose 后应确认旧容器已经停止和移除。
安全停止而不是强制杀进程
- 确认进程和业务归属。
- 使用
systemctl stop、容器停止或应用自身优雅停止方式。 - 等待连接排空，并再次检查端口。
- 只有进程无法响应时才逐步升级信号。
- 启动目标服务并验证监听、健康接口和日志。
端口空闲仍无法启动
- 应用尝试绑定不存在的本机 IP。
- IPv6 与 IPv4 双栈绑定行为造成冲突。
- 非 root 进程绑定低端口缺少能力。
- systemd Socket Activation 已预先占用端口。
- 应用短时间内重复启动多个实例。
现象对照
| 现象 | 检查方向 |
|---|---|
| ss 显示 systemd | Socket unit 与服务激活 |
| 端口由 docker-proxy 占用 | 容器发布端口 |
| 只绑定 127.0.0.1 | 本机可访问、外部不可访问 |
| 没有监听仍报错 | 地址不存在、双栈或启动竞态 |
边界条件
不要把监听地址从 127.0.0.1 改为 0.0.0.0 作为通用修复，这可能把内部服务暴露到公网。修改后还应检查安全组、UFW 和身份认证。
怎样读懂 ss 的输出
127.0.0.1:8080 表示只在本机监听，外网不能直接访问；0.0.0.0:8080 表示所有 IPv4 网卡；[::]:8080 是 IPv6 监听，部分系统也会同时接收 IPv4。users:(("nginx",pid=...)) 才是进程证据。不要把客户端临时连接或 TIME-WAIT 当成监听冲突。
按进程归属选择处理分支
- systemd 服务：用
systemctl status 服务名和单元文件确认是否启动了两份，不直接杀子进程。 - Docker：用
docker ps --format查看端口映射；宿主端口冲突应改 Compose 映射或停掉旧容器。 - systemd socket：即使服务停止，
.socket单元仍可能占端口，需要核对 socket 激活设计。 - 手工后台进程：确认命令、工作目录、父进程和启动脚本，再用正常信号停止。
端口看似空闲仍启动失败
检查服务是否短时间反复重启、配置同时声明两个监听器、IPv4 与 IPv6 双重绑定冲突，或旧进程在检查后又被守护程序拉起。应用日志中的端口必须与实际配置一致。端口小于 1024 时还要检查运行用户是否有绑定权限；这类错误通常是 Permission denied，不要混成占用问题。
处理后的验收与回退
重新执行 ss，确认只有目标进程监听预期地址。随后从本机和真实客户端分别访问健康端点，检查 systemd 状态、容器重启次数和近十分钟日志。若改端口后上游 502 或监控失败，恢复原配置、重新加载原服务，再逐项修改反向代理、防火墙和健康检查，不能只证明进程启动就结束。
Linux 端口被占用怎么排查现场验收单
- 入口或命令：先在服务器终端执行 ss，再用 lsof 和 systemctl/docker 核对归属
- 提交前风险：只读检查不收费也不改数据；强杀数据库、代理或容器可能造成请求和数据损坏
- 不能继续时：端口由 systemd socket、Docker 代理、IPv6 监听或短暂连接占用，普通 ps 看不到原因
- 完成证据：目标服务稳定监听预期地址和端口，健康检查通过且没有重启循环
- 退出办法：记录原配置和服务状态；修改端口失败就恢复配置并重启原服务，而非继续杀进程
联系 Telegram 客服 