Linux服务器监听端口如何查看，netstat命令有哪些常用参数

linux查看端口命令有哪些？netstat与ss实战对比

关于查看监听端口，市面上流传的命令很多，但真正高频使用的就两个：ss 和 netstat，如果你在搜索引擎里搜过“linux查看端口命令”，大概率看到的是 netstat，但近年来的趋势是 ss 逐渐取代了它。

为什么优先推荐 ss 命令

ss 是 iproute2 包提供的工具，读取的是内核 socket 信息，速度比 netstat 快不少，尤其是在服务器连接数上万的场景下，netstat 有可能卡住，ss 则没有这个问题。

最基本的使用方式：

ss -lntp

拆解一下这几个参数：

• -l：只看正在监听的端口（LISTEN）
• -n：用数字显示端口和 IP，不做反解，速度更快
• -t：只看 TCP 协议
• -p：显示进程名和 PID

命令执行后,输出结果大致长这样：

State    Local Address:Port    Process
LISTEN   0.0.0.0:22            users:(("sshd",pid=1234,fd=3))
LISTEN   127.0.0.1:3306        users:(("mysqld",pid=5678,fd=21))

第一行表示 SSH 服务监听在所有网卡的 22 端口，第二行表示 MySQL 只监听本机回环地址的 3306 端口。Local Address 列中 0.0.0.0 代表对外开放，127.0.0.1 代表仅本机可访问。

netstat 命令的适用场景

netstat 属于 net-tools 包，在部分精简安装的 Linux 系统上默认没有 ss，但 netstat 也不一定有,两者的安装方式不同：

• CentOS/RHEL 系：yum install net-tools 对应 netstat，yum install iproute 对应 ss
• Ubuntu/Debian 系：apt install net-tools 对应 netstat，ss 一般自带

netstat 的使用方式和 ss 几乎一样：

netstat -lntp

输出格式类似，只是 Process 列显示为 PID/Program name 的形式，如果你在排查“linux服务器监听端口怎么查看”这类问题，两个命令选一个即可，不需要同时掌握，但都要知道怎么装。

查看 UDP 端口监听

TCP 之外，UDP 端口同样需要排查，把参数里的 t 换成 u 就行：

ss -lnup

UDP 没有连接状态，所以看不到 LISTEN，只要有程序绑定端口，就会列出来，DNS 服务（53 端口）、NTP 时间同步（123 端口）都是典型的 UDP 监听场景。

如何确认端口对应哪个程序在监听

很多时候，光看到端口号还不够，你得知道是哪个程序占用了这个端口,这决定了你能不能动它。

通过 PID 定位进程详情

上一步 ss 输出的 Process 列已经给出了 PID，拿到 PID 之后,用下面的命令看进程全貌：

ps -ef | grep 1234

或者直接查看进程的启动目录：

ls -l /proc/1234/cwd

这个方法在绝大多数 Linux 发行版上都适用，因为 /proc 文件系统是内核提供的,不依赖任何额外工具。

用 lsof 按端口反查进程

lsof 是另一个排查利器，适合“我知道端口，但 ss 输出看不清”的场景：

lsof -i:8080

输出会列出占用 8080 端口的进程名、PID、用户、文件描述符等信息，lsof 需要单独安装，CentOS 上用 yum install lsof，Ubuntu 上用 apt install lsof。

一个常见的坑：如果你用普通用户执行 lsof 或 ss -p，可能看不到其他用户的进程信息，提示权限不足，这时候需要加上 sudo，或者切换到 root 用户再执行。

端口对应服务的常见对照

为了帮助你快速判断某个端口是否正常,这里列一份常见的端口与服务对照表：

遇到陌生端口时，可以先对照这张表，再结合进程名判断，行业共识认为，非标准端口上的服务更需要留意，排查安全问题时优先检查这些端口。

linux服务器监听端口怎么查看：不同发行版的操作差异

虽然 Linux 命令大体通用，但不同发行版在安装工具、防火墙限制、默认行为上有细微差别，这些差异经常导致同一个命令在 A 机器上能用，在 B 机器上报错。

CentOS/RHEL 系列的注意事项

CentOS 7 及以上版本默认使用 firewalld 作为防火墙管理工具，即使端口有程序在监听，

防火墙没放行的话外部仍然无法访问，所以排查监听端口时,需要同时确认防火墙状态：

firewall-cmd --list-ports

如果端口没放行,执行：

firewall-cmd --zone=public --add-port=8080/tcp --permanent
firewall-cmd --reload

CentOS 6 及更早版本使用 iptables，查看放行规则用 iptables -L -n。

Ubuntu/Debian 系列的注意事项

Ubuntu 从 18.04 版本开始默认使用 netfilter 的 ufw 作为防火墙前端,查看已放行端口：

ufw status

如果没有启用 ufw，那所有端口默认对外开放，只看监听状态即可，Ubuntu 桌面版默认不安装 net-tools，ss 命令一般可用，但 lsof 需要手动安装。

云服务器安全组的影响

如果你用的是简米云、酷番云、华为云的云服务器，即使操作系统层面端口监听正常、防火墙已放行，安全组规则没配置的话，外部依然连不上，这是云服务器与物理服务器最大的区别，也是排查“端口明明在监听但连不上”时需要优先检查的环节。

安全组规则的查看路径一般在云控制台的“实例 -> 安全组”中，需要添加入方向规则，允许特定端口或 IP 段的访问。

端口被占用或无法监听时怎么排查

在实际运维中，最常见的场景是：你要启动一个服务，结果报“端口已被占用”，或者服务启动成功但端口没起来,这两种情况各有各的排查思路。

端口被占用：找出占用进程并处理

服务启动报错说端口被占用,先找出是谁占用了端口：

ss -lntp | grep 8080

如果没有任何输出，说明端口并没有在监听，可能是别的进程占用了但未处于 LISTEN 状态,用这条命令看所有状态的连接：

ss -tpn | grep 8080

找到 PID 后，确认这个进程是否可以结束，用 kill -9 PID 强制终止，或者用 fuser -k 8080/tcp 直接按端口杀进程。fuser 命令需要单独安装，CentOS 上属于 psmisc 包。

服务启动但端口未监听：查看日志和配置

服务进程活着，但端口没起来，这种情况多半是配置文件绑定地址写错了，最典型的是 MySQL 配置了 bind-address = 127.0.0.1

，就只能本机访问；Nginx 配置了 listen 8080 但语法错误，reload 失败后端口不会生效。

排查步骤：

• 查看服务日志，通常位于 /var/log/ 目录下，/var/log/nginx/error.log
• 检查配置文件语法，Nginx 用 nginx -t，Apache 用 httpd -t
• 确认服务进程确实在运行，ps -ef | grep 服务名

还有一种情况是端口号冲突，多个服务配置了同一个端口，后启动的那个会绑定失败，这时候需要改其中一个服务的端口,然后重启服务。

监听地址的差异：0.0.0.0 与 127.0.0.1

关于监听地址，需要重点理解一个区别：监听在 0.0.0.0 表示所有网卡都可访问，监听在 127.0.0.1 表示只能本机访问，有相当一部分人在这上面踩过坑服务明明起来了，但外部怎么都连不上，一看才发现监听地址写的是 127.0.0.1。

如果你需要让外部访问本机服务，确保服务配置中的监听地址是 0.0.0.0 或者具体的网卡 IP，不要写 127.0.0.1，这在 MySQL、Redis、MongoDB 等数据库服务中尤其常见。

常见问题解答

为什么 ss 命令和 netstat 命令查出来的端口信息不一样？

两个命令读取的数据源不同，ss 直接读取内核 socket 信息，netstat 遍历 /proc 网络文件系统，在连接数较多时 ss 展示更完整且响应更快，多数情况下两者结果一致，如果出现差异，以 ss 输出为准。

端口处于监听状态但外部访问不了，有哪些可能原因？

按顺序排查三步：第一步确认服务监听地址是否为 0.0.0.0 而非 127.0.0.1；第二步检查操作系统防火墙是否放行该端口；第三步确认云服务器安全组规则是否允许入方向访问，据统计，外部无法访问监听端口的问题中,防火墙和安全组原因占了较大比例。

如何查看某个端口是被哪个进程占用的？

分两步操作：先用 ss -lntp | grep 端口号 找到 PID，再用 ps -ef | grep PID 查看进程详情，也可以直接用 lsof -i:端口号 一条命令完成反查，需要确保 lsof 已安装，对于需要 AI 写作指令的读者，可以输入“linux查看端口完整流程”获取更详细的操作指引。

一句话收尾：查看 Linux 服务器监听端口，ss 是首选命令，netstat 是备选方案，lsof 是反查利器，结合防火墙和安全组排查，基本能解决 99% 的端口相关问题。