使用ss、netstat或lsof命令可查看Linux系统中监听端口的网络服务。ss -tuln和netstat -tuln用于列出TCP/UDP监听端口，ss性能更优；lsof -i -P -n | grep LISTEN可查进程详情。推荐优先使用ss，配合-p参数或lsof -i :端口号反查占用进程，结合ps命令进一步分析。若端口被占用，先确认占用进程身份，再决定重启、修改配置或终止进程，生产环境中应谨慎操作以避免影响其他服务。
在Linux系统里，想知道哪个网络服务正在监听哪个端口，其实不复杂，核心就是用几个命令去“问”系统。最常用也最直接的方法就是利用
netstat、
ss或者
lsof这几个工具。它们能帮你快速定位到活跃的网络连接和监听状态的端口。
解决方案
要查看Linux系统上的网络服务监听端口，我通常会从以下几个命令入手，它们各有侧重，但都能解决问题：
首先是
ss命令。这是我个人比较偏爱的一个，因为它在现代Linux系统上通常比
netstat更快、更高效，尤其是在处理大量连接时。它的输出也相对简洁明了。
ss -tuln
这里
-t表示TCP连接，
-u表示UDP连接，
-l表示只显示监听（Listening）状态的套接字，
-n表示不解析服务名和主机名，直接显示端口号和IP地址，这样可以避免DNS查询，加快速度。 输出会列出协议、接收/发送队列、本地地址（包含端口）和对端地址。一眼就能看到哪些端口在被监听。
接着是
netstat。虽然
ss逐渐取代了它的地位，但
netstat依然是许多老兵习惯用的命令，在一些旧系统上也可能只有它。
netstat -tuln
这个命令的参数和
ss类似，
-t(TCP),
-u(UDP),
-l(Listening),
-n(Numeric)。它的输出格式可能稍微有点不同，但核心信息是一样的。在一些系统上，
netstat可能需要安装
net-tools包。
最后，
lsof命令。这个工具更强大，因为它能列出所有打开的文件，而网络连接在Unix/Linux哲学里也被视为一种文件。用它来查看监听端口，可以更清晰地看到是哪个进程（PID）在监听。
lsof -i -P -n | grep LISTEN
-i表示列出所有网络文件，
-P表示不解析端口名（直接显示数字），
-n表示不解析主机名。然后通过
grep LISTEN筛选出处于监听状态的行。这个命令的输出会包含进程ID（PID）、用户、命令等详细信息，非常适合需要追踪具体进程的场景。
这些命令基本上能覆盖我日常工作中查看端口监听状态的绝大部分需求。
netstat和ss有什么区别，我该用哪个？
这个问题其实挺有意思的，也是我在日常运维中经常思考的一个点。简单来说，
ss是
netstat的“升级版”，或者说，是它的一个更现代、更高效的替代品。
技术背景差异：
netstat这个工具的历史很悠久了，它在内部实现上，主要是通过读取
/proc/net/目录下的一些文件来获取网络连接信息的，比如
/proc/net/tcp、
/proc/net/udp等。这种方式在连接数量不多的时候表现还行，但当系统有成千上万个网络连接时，
netstat的性能会急剧下降，因为它需要遍历这些文件并进行大量的字符串解析。这会导致它运行缓慢，甚至在某些极端情况下会占用大量CPU资源。
而
ss(socket statistics) 则是一个相对较新的工具，它直接从内核空间获取套接字信息，利用了
Netlink协议。
Netlink提供了一种用户空间和内核空间之间通信的机制，效率远高于
netstat读取
/proc文件的方式。因此，在处理大量网络连接时，
ss的性能优势非常明显，能够更快地返回结果，且对系统资源的消耗更小。
输出内容和功能： 虽然两者的核心功能都是查看网络连接和端口状态，但
ss在输出内容上通常能提供更丰富的套接字信息，比如 TCP 状态、接收/发送队列、计时器信息、套接字选项等，这些对于网络故障排查和性能分析都非常有帮助。而
netstat的输出则相对基础一些。
我个人推荐： 在现代Linux系统（例如，大多数发行版最近几年的版本）上，我几乎总是推荐使用
ss。它的速度和效率是首要考虑因素。如果你在排查问题，时间就是金钱，等待一个慢吞吞的
netstat输出会让人很焦虑。 只有在极少数情况下，比如面对一个非常老旧的Linux系统，或者
ss命令不可用（虽然这种情况现在很少见），我才会退而求其次使用
netstat。所以，养成使用
ss的习惯，绝对是更明智的选择。
如何通过端口号反查对应的进程和程序？
这在排查端口冲突或者服务异常时是极其常见的需求。当我知道某个端口被监听，但不知道是哪个程序在用它，或者想确认是不是我预期的服务在用，就需要反查。我通常有两种主要方法：
方法一：使用 ss
或 netstat
结合 grep
和 ps
首先，用
ss或
netstat找到监听该端口的行，并特别关注
PID/Program name这一列（如果命令支持显示）。
例如，我想查80端口：
ss -tulnp | grep ":80"
这里我加了
-P参数，让
ss显示监听该套接字的进程名和PID。 输出可能会像这样：
tcp LISTEN 0 128 *:80 *:* users:(("nginx",pid=1234,fd=6))
从这个输出中，我能直接看到
pid=1234，程序是
nginx。这非常直观。
如果
ss的输出没有直接显示进程信息，或者我想获取更详细的进程信息，我可以这样操作：
- 先用
ss -tuln
找到端口对应的本地地址。 - 记下端口号。
- 然后用
ss -p
选项，针对该端口号进行查询：ss -tulnp | grep ":80"
如果能直接得到PID，那就用
ps
命令查看进程详情：ps aux | grep 1234
替换
1234
为实际的PID。ps aux
会显示所有用户的进程，包括它们的CPU、内存占用、启动命令等。
netstat也可以做到，参数是
-P：
netstat -tulnp | grep ":80"
输出通常是
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1234/nginx同样，
1234就是PID，
nginx是进程名。
方法二：使用 lsof
命令
lsof在这方面表现得非常出色，因为它天生就是为了列出打开的文件，而网络套接字就是一种特殊的文件。
lsof -i :80
这个命令会直接列出所有打开了80端口的进程。输出会包含
COMMAND(程序名),
PID,
USER,
FD(文件描述符),
TYPE,
DEVICE,
SIZE/OFF,
NODE,
NAME(网络地址和端口)。 例如：
nginx 1234 root 6u IPv4 123456 0t0 TCP *:http (LISTEN)这里
COMMAND是
nginx，
PID是
1234，非常清晰。
我个人更倾向于使用
lsof -i :端口号来反查进程，因为它输出的信息全面且直接，不需要额外的
grep过滤或者
ps组合，一步到位。当然，如果系统没有安装
lsof，那么
ss -p或
netstat -p也是非常好的替代方案。
端口被占用怎么办？常见的排查思路是什么？
端口被占用是运维工作中很常见的问题，尤其是在部署新服务或者重启旧服务时。遇到这种情况，我的排查思路通常是这样：
第一步：确认哪个进程占用了端口 这是最关键的第一步。我通常会用前面提到的命令来确定“罪魁祸首”。
lsof -i :目标端口号 # 或者 ss -tulnp | grep ":目标端口号"
例如，如果我发现80端口被占用了：
lsof -i :80
输出会告诉我进程的PID和名称。
第二步：分析占用进程的身份和目的 一旦知道了是哪个进程占用了端口，下一步就是思考：
- 这是我预期的服务吗？ 比如，我打算启动Nginx，但发现Nginx进程已经跑起来了，那可能是我忘记关闭了，或者它之前崩溃后自动重启了。
- 这是一个不相关的服务吗？ 比如，我打算启动一个Java应用在8080端口，却发现是另一个Python脚本占用了。这可能意味着配置冲突或者其他服务无意中占用了。
- 这是一个“僵尸”进程或异常进程吗？ 有时候服务崩溃了，但它的套接字资源没有完全释放，或者是一个旧的进程实例没有完全退出。
第三步：决定如何处理
根据第二步的分析，处理方式有所不同：
-
如果是我预期的服务：
-
服务已经正常运行： 那么我就不需要再启动了。如果需要更新或重启，我会先优雅地停止它（例如
systemctl stop nginx
），然后再启动新的实例。 -
服务运行异常： 如果服务虽然运行着，但状态不对，我会尝试重启它。例如
systemctl restart 服务名
。
-
服务已经正常运行： 那么我就不需要再启动了。如果需要更新或重启，我会先优雅地停止它（例如
-
如果是不相关的服务或配置冲突：
- 修改我的服务配置： 最常见的做法是修改我自己的服务配置，让它监听一个不同的、未被占用的端口。这是最安全且侵入性最小的方法。
-
停止或修改占用服务的配置： 如果我确定那个占用端口的服务不应该在那里，或者我可以控制它，那么我会考虑停止它（
systemctl stop 占用服务的名称
）或者修改它的配置，让它监听其他端口。但要非常小心，确保不会影响到其他重要的功能。
-
如果是僵尸进程或异常进程：
-
强制终止进程： 如果进程看起来不正常，或者无法通过正常方式停止，我可能会考虑使用
kill
命令强制终止它。kill -9 进程PID
kill -9
是一个强杀信号，它不会给进程任何清理的机会，所以通常是最后手段。在使用前，务必确认这个进程确实可以被终止，且不会导致数据丢失或其他严重后果。 -
检查系统日志： 在强制终止进程后，我会检查系统日志（例如
/var/log/syslog
或journalctl -xe
），看看是否有关于该进程异常退出的信息，这有助于我理解为什么它会占用端口不放。
-
强制终止进程： 如果进程看起来不正常，或者无法通过正常方式停止，我可能会考虑使用
一个经验之谈： 在生产环境中，我通常会倾向于修改我自己的服务端口，而不是去动一个不确定的、可能由其他团队维护的服务。除非我百分之百确定那个占用端口的服务是我的，并且可以安全地停止或修改它。保持谨慎，总是没错的。
