ss 命令替代 netstat 时存在四大高频误区：一是查监听端口必须显式加 -l，否则漏掉 LISTEN 状态；二是查进程名需 sudo 配合 -p，否则权限不足显示为“-”；三是 UDP 监听不能混用 -t，须用 -u 单独过滤；四是状态过滤需用 state 关键字加具体状态（如 established），且不可写成 state=xxx。
ss 命令确实全面替代了 netstat，但很多用户照着 netstat 习惯“翻译”时，会掉进几个高频坑里——不是语法报错，而是查不到想要的信息，或者结果不完整、权限缺失、状态遗漏。
监听漏掉 -l 就白查
netstat -tuln 和 ss -tuln 看似一样，但新手常写成 ss -tun（缺 -l）。这会导致只显示已建立的连接，完全看不到 LISTEN 状态的端口。比如查 80 端口是否在监听，ss -tun | grep :80 很可能返回空，而正确命令是 ss -tuln | grep :80。
关键点：
- -l（listen）必须显式带上，ss 不像 netstat 那样默认包含监听项
- 单独用 -t 或 -u 时不加 -l，等同于查“活跃连接”，不是“服务是否启动”
查进程名却忘了 sudo
netstat -tulpn 和 ss -tulnp 都需要 root 权限才能显示进程名（PID+程序路径），但很多人只记得加 -p，却没加 sudo。结果看到的是：
Permission denied (are you root?) 或者进程列显示为 –，而不是 nginx: master 这类信息。
正确做法：
AI设计工具
sudo ss -tulnp | grep :8080- 如果只想看某端口且避免全量扫描，可先用非特权查端口，再用 sudo 查进程：
ss -tuln | grep :8080→ 确认端口存在 → 再sudo ss -tulnp | grep :8080
UDP 监听误用 -t 导致无结果
netstat -uln 查 UDP 监听，对应 ss 应该是 ss -uln，但有人写成 ss -tuln 或 ss -tun。-t 强制限定 TCP，UDP 监听项直接被过滤掉，哪怕端口确实在 listen（如 DNS 的 53 端口），也完全不会出现。
常见错误场景：
- 查 masq 或 systemd-resolved 是否监听 53 端口，用了
ss -tuln | grep :53→ 找不到 - 正确命令是
ss -uln | grep :53；如需进程信息，再加sudo ss -ulnp | grep :53
状态过滤写法不兼容，别信“-a 就是全部”
netstat -an 能看到所有连接（包括 TIME-WAIT、FIN-WAIT 等），而 ss 默认不显示非 established 状态的连接，除非显式指定状态或用 -a。但 ss -a 实际上包含监听 + 已连接 + 关闭中等全部 socket，容易和 netstat -a 混淆——它比 netstat -a 更“全”，甚至包含未完成三次握手的 SYN-RECV。
更稳妥的做法是按需指定状态：
- 只看已建立连接：
ss -tn state established - 查异常堆积：
ss -s（快速统计各状态数量）→ 发现大量 TIME-WAIT 或 CLOSE-WAIT 后再深入 - 查等待关闭的连接：
ss -tn state fin-wait-1或ss -tn state time-wait
注意：ss 的 state 过滤必须跟在命令末尾，不能写成 ss -tn state=established（语法错误）。
