使用ss命令是查看Linux系统服务端口和连接状态的首选方法，ss -tuln可快速列出所有监听的TCP和UDP端口，结合-p参数能显示占用端口的进程信息，通过过滤条件还可定位特定端口、IP或连接状态，相比已过时的netstat，ss直接从内核获取数据，性能更强、功能更丰富，适用于高效诊断端口冲突、连接异常等问题。
在Linux系统里，想知道哪些服务占用了哪些端口，或者哪些连接正在活跃，最直接有效的方法就是使用
ss或
netstat命令。简单来说，
ss是现代Linux发行版更推荐的工具，它能提供更快速、更详细的网络统计信息，而
netstat虽然经典，但已逐渐被弃用。
解决方案
要查看Linux系统中的服务端口，最常用且推荐的命令组合是
ss -tuln。
ss -tuln
: 这个命令会列出所有TCP (-t
) 和 UDP (-u
) 协议的监听 (-l
) 端口，并以数字形式 (-n
) 显示地址和端口号，避免进行域名解析，从而加快显示速度。ss -tuln
输出通常会显示本地地址、端口、对等地址、端口以及连接状态。
如果你想查看所有连接（包括监听和已建立的连接），可以去掉
-l参数：
ss -tun
如果还需要查看是哪个进程在使用这些端口，可以加上
-p参数（通常需要root权限）：
ss -tulnp
这个输出会额外显示进程ID (PID) 和进程名称。
对于特定的端口，比如你想知道80端口是不是被占用了，可以结合
grep：
ss -tuln | grep :80
或者，如果你想查看所有已建立的HTTP连接：
ss -antp state established '( sport = :http or dport = :http )'
这里
state established过滤了已建立的连接，
sport和
dport则分别指源端口和目的端口，
:http是80端口的服务名。
至于
netstat，虽然现在推荐使用
ss，但在很多旧系统或一些特定场景下，你可能仍会用到它。它的基本用法和
ss类似：
netstat -tuln netstat -tulnp netstat -tuln | grep :22
我个人觉得，如果你在一个较新的Linux发行版上，直接上手
ss会是更好的选择。它在处理大量连接时，明显比
netstat快得多，而且能提供更丰富的信息。
为什么ss
正在取代netstat
？
说实话，这个问题我经常被问到，尤其是在一些老旧的教程还在推荐
netstat的时候。简单来说，
netstat是
net-tools软件包的一部分，这个软件包已经很久没有更新了，而且被认为已经过时。而
ss是
iproute2软件包中的一员，
iproute2是现代Linux网络管理的主流工具集，包括
ip命令等。
从技术角度看，
ss的优势在于它直接从内核空间获取套接字统计信息，这比
netstat通过读取
/proc/net/下的文件要高效得多，尤其是在系统有大量网络连接时。我记得有一次调试一个高并发服务，
netstat跑起来卡顿得厉害，而
ss几乎是秒出结果，那体验简直是天壤之别。
ss能够显示更详细的TCP状态信息，比如TCP计时器（
timer）、内存使用情况（
mem）等，这些对于深入分析网络问题非常有帮助。比如，你想知道有多少连接处于
TIME_WAIT状态，
ss -s就能直接给出汇总，或者
ss -o state time-wait就能列出详细列表。这在进行性能优化或者排查资源耗尽问题时，简直是神器。所以，在我看来，选择
ss不仅仅是跟上潮流，更是为了获得更高效、更强大的网络诊断能力。
掌握ss
命令的进阶用法：不仅仅是查看端口
光知道
ss -tuln那点儿皮毛，就有点儿浪费这个强大工具了。
ss的真正魅力在于它强大的过滤和显示能力。对我来说，它就像一个网络侦探，能帮我挖出很多隐藏的信息。
比如说，你想看所有处于
ESTABLISHED（已建立）状态的TCP连接：
ss -antp state established
这个命令可以帮你快速定位到当前哪些连接是活跃的。如果发现大量连接处于非正常状态（比如
CLOSE-WAIT或者
FIN-WAIT-1），那可能就预示着你的应用程序或者网络配置存在问题。
再比如，你想看某个特定IP地址（比如
192.168.1.100）的所有连接：
ss -ant '( dport = :80 or sport = :80 ) and ( dst 192.168.1.100 or src 192.168.1.100 )'
这种复杂的过滤表达式是
ss的亮点之一，你可以根据源/目的IP、源/目的端口、TCP状态等进行组合过滤。这在排查特定客户端或服务器的网络行为时特别有用。
还有一点，
ss可以查看Unix域套接字 (
-x)，这在调试本地进程间通信时非常有用。
ss -x
这会列出所有Unix域套接字，包括它们的状态和路径。很多本地服务，比如
systemd的socket，或者一些数据库的本地连接，都是通过Unix域套接字实现的。了解它们的状态，能帮助你诊断一些看似与网络无关，实则与本地通信相关的奇葩问题。
诊断常见的端口冲突与网络问题
在日常的系统维护和开发中，端口冲突和网络连接问题是家常便饭。
ss和
netstat（主要是
ss了）就是我们排查这些问题的利器。
最常见的问题是“Address already in use”（地址已被占用）。当你尝试启动一个服务，比如Nginx或者Apache，它却报错说端口已经被占用了。这时候，我会立刻敲下：
ss -tulnp | grep :80
（假设是80端口冲突） 这个命令会直接告诉我，是哪个进程（通过PID和进程名）正在监听80端口。通常情况下，会发现是另一个Nginx实例、一个测试服务，或者干脆是之前没关干净的进程。知道了“是谁”，解决起来就容易多了，要么停掉它，要么换个端口。
另一个常见场景是服务启动了，但外部无法访问。这时候，除了检查防火墙，我首先会确认服务是不是真的在监听我期望的端口，以及它监听的是哪个接口。
ss -tuln | grep :你的端口号
如果服务应该监听在所有接口（
0.0.0.0），但
ss显示它只监听在
127.0.0.1（本地回环地址），那就说明服务配置有问题，它只接受来自本机自身的连接。这通常是配置文件中的
bind地址设置不正确导致的。
此外，网络连接的
TIME_WAIT状态过多也经常困扰一些高性能应用。
TIME_WAIT是TCP连接关闭的正常状态，但如果数量过多且持续时间长，可能会耗尽资源。
ss -s # 快速查看各种状态的连接汇总 ss -ant state time-wait # 查看所有处于TIME_WAIT状态的连接
通过这些信息，我可以判断
TIME_WAIT的数量是否异常，进而考虑是否需要调整内核参数（比如
net.ipv4.tcp_tw_reuse或
net.ipv4.tcp_tw_recycle，尽管
tcp_tw_recycle现在不推荐使用）来优化连接回收。
这些命令，说白了，就是你的网络“听诊器”。它们能告诉你网络连接的“心跳”和“呼吸”，帮你快速定位到问题的症结所在，而不是盲目地猜测。
