Linux 常用端口 + 排障对照表，运维人收藏这篇就够了

服务起不来？连不上？防火墙后面到底谁在监听？端口问题排查，看这一篇就够了。

事情是这样的。

那天一个新人在群里问："我 nginx 配置明明没问题，怎么访问不了？" 让他贴了 nginx -t，没报错。让他贴 curl localhost——连不上。问他端口开了没，他说"我关了防火墙的"。

最后发现：他的 nginx 监听的是 8080，但他的 upstream 转发地址写的是 localhost:80——而 80 端口上根本没东西。

端口问题排查有个铁律：先看谁在用，再看通不通，最后才怀疑配置。

一、端口速查：你真正需要记住的

最常用（这些背下来，剩下的查表）

服务端口（按场景索引）

Web 相关：

数据库：

基础设施：

二、排障三板斧

第一斧：谁在监听

ss -tlnp
# ss       → 取代 netstat，速度快得多
# -t       → TCP
# -l       → 只显示正在监听（listening）的端口
# -n       → 不解析域名，显示数字端口（快）
# -p       → 显示哪个进程在监听
# 输出：
# LISTEN  0  128  0.0.0.0:80  0.0.0.0:*  users:(("nginx",pid=1234,fd=6))
#                    ^^^^^^               ^^^^^^^^^^^^^^^^^^^^^^^^^
#                    监听地址              进程名+PID

ss -tlnp | grep :80
# 确认 80 端口确实有人在监听
# 如果没输出 → 服务没起来

关键字段看两个：

• • 0.0.0.0:80 → 监听所有网卡，外网可访问
• • 127.0.0.1:80 → 只监听本地，外网连不上（这是很多"外网访问不了"的根因）

第二斧：通不通

# 本地测试——先确认服务本身活着
curl -I http://localhost:80
# -I  →  只拿 HTTP 头，不下载页面
# 输出第一行 HTTP/1.1 200 OK → 服务正常

# 远程测试——从另一台机器
curl -I http://10.0.1.5:80 --connect-timeout 5
# --connect-timeout 5  →  5 秒连不上就放弃，别傻等

# TCP 层面测试
nc -zv 10.0.1.5 80
# -z  →  不发数据，只测能不能建立 TCP 连接
# -v  →  输出详细结果
# 输出 Connection to 10.0.1.5 80 port [tcp/http] succeeded! → 通了

第三斧：中间有什么挡着

# 查 iptables 规则（传统方式）
iptables -L -n -v
# -L  →  列出所有规则
# -n  →  不解析（快）
# -v  →  显示匹配次数和字节数（看哪些规则真的在命中）

# 如果你用 firewalld
firewall-cmd --list-all
# 看 ports 那一段，确认目标端口在不在列表里

# 如果你用 ufw（Ubuntu）
ufw status verbose
# 最直接的端口开放列表

# 云服务器别忘了安全组
# ⚠️ 80% 的"服务器上一切正常但外网访问不了"都是安全组没放行
# 去云控制台 → 安全组 → 入方向规则 → 确认端口有没有

三、常见场景速查

场景 1：服务起不来，端口被占

ss -tlnp | grep :8080
# 8080 端口有人占着 → 你的服务起不来

fuser 8080/tcp
# 直接告诉你占 8080 的 PID
# 输出：8080/tcp:  12345
# 然后：
kill 12345  # 或者先 ps -p 12345 看看是谁再决定

场景 2：改了配置但外网还是访问不了

按顺序查：

# ① 服务监听地址对了吗？
ss -tlnp | grep :80
# 看到 127.0.0.1:80 → 问题找到了，只监听本地
# 应该看到 0.0.0.0:80 或者具体的公网/内网 IP

# ② 本机 curl 通吗？
curl -I http://localhost:80
# 不通 → 服务本身有问题，不是网络问题

# ③ 云安全组开了吗？（去控制台确认）
# ④ iptables 有没有拦截？
iptables -L -n | grep 80

场景 3：TIME_WAIT 爆炸

ss -tan state time-wait | wc -l
# state time-wait → 只显示 TIME_WAIT 状态的连接
# wc -l → 计数
# 如果这个数字很大（上千），说明大量短连接在快速建立和关闭

# 看各状态分布：
ss -tan | awk '{print $1}' | sort | uniq -c | sort -n
# 输出：
#   5 LISTEN
#  12 ESTAB
# 847 TIME_WAIT   ← 主力部队
# 如果 TIME_WAIT 占比超过 80%，考虑长连接或者调整内核参数

四、几个"居然这也会出问题"的经验

• • Docker 容器的端口映射：docker run -p 8080:80 意思是宿主 8080 → 容器 80。记反了会排查到怀疑人生。
• • SELinux 的端口标签：semanage port -l 看看端口有没有被 SELinux 限制。setenforce 0 临时关掉试试是不是它的问题（但排查完记得开回来）。
• • Nginx 的 proxy_pass 结尾斜杠：proxy_pass http://backend/ 和 proxy_pass http://backend 转发路径不一样——多一个 / 能让你 debug 一下午。

这份对照表建议存到书签，下次端口出问题直接打开对着查。你遇到过最离谱的端口问题是什么？评论区留下你的故事。

🐧 野生推荐：回复「野生」获取我的《Linux效率工具清单》，回复「手册」获取《Linux命令速查手册》