ss是现代linux首选网络排查工具，因其直接读取内核socket表、无需dns解析、响应快且默认预装；而netstat依赖用户态遍历/proc、易卡顿、新系统常未预装。
直接用 ss -tun，它比 netstat -tun 更快、更可靠，且现代 Linux 发行版默认自带。
为什么不用 netstat -tun？
netstat 依赖用户态解析，需遍历 /proc 并做 DNS 反查（除非加 -n），在连接数多时明显卡顿；而 ss 直接读内核 socket 表，零延迟。很多新系统（如 RHEL 8+/Ubuntu 20.04+）已不预装 net-tools，运行 netstat 会报 command not found，得额外装包。
常见错误现象：
- 普通用户执行 sudo netstat -tunp 却看不到其他用户的进程名 → 缺少 -p 权限或未用 sudo
- 执行 netstat -tun 输出缓慢、卡住几秒 → 实际是 DNS 解析阻塞，但加了 -n 仍慢，说明底层开销大
ss -tun 的参数含义和典型输出
-t：只看 TCP；-u：只看 UDP；-n：强制数字地址（跳过 DNS 和服务名解析）；三者合用即覆盖全部活跃连接（不含监听态）。
输出字段关键点：
- State 列只对 TCP 有效（如 ESTAB、TIME-WAIT），UDP 行该列为 UNCONN 或空
- Local Address:Port 和 Peer Address:Port 全是 IP+端口格式，例如 192.168.1.5:49153 或 [::1]:5432
- 若看到大量 *:* 在 UDP 行，属正常（表示未绑定具体地址，如某些广播/多播行为）
想看监听端口？加 -l 参数
仅查“谁在等连接”，不是查“正在传数据的连接”——这是最常混淆的点。监听端口必须显式加 -l：
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
ss -tuln：同时列出所有监听的 TCP 和 UDP 端口（推荐日常排查服务是否启动） -
ss -tln：只看 TCP 监听（如 Web、SSH、数据库） -
ss -uln：只看 UDP 监听（如 DNS、NTP、DHCP 客户端）
注意：ss -tun 默认**不包含监听态连接**，哪怕它们处于 LISTEN 状态。如果漏掉 -l，就永远看不到 nginx 是否真在监听 80 端口。
需要知道哪个进程在用？必须加 -p 且提权
ss -tunp 会尝试显示 PID 和进程名，但普通用户只能看到自己启动的进程；要看到全部，必须 sudo ss -tunp。
输出中最后一列类似：users:(("nginx",pid=1234,fd=6))
- pid=1234 是进程 ID，可进一步 ps -p 1234 查详情
- fd=6 是文件描述符号，用于定位该连接在进程内的具体 socket 句柄
- 若提示 Permission denied，不是命令错，是权限不够 —— 别改参数，直接加 sudo
容易踩的坑：
- 用 sudo ss -tunp | grep :80 却没结果 → 因为 grep 运行在普通权限下，管道右侧无法继承 sudo 权限，应写成 sudo sh -c 'ss -tunp | grep :80'
- 在容器或 systemd 服务里看到 pid=-1 或 users:(("?",pid=-1,fd=-1)) → 表示该 socket 属于内核线程或命名空间隔离导致不可见，不是异常
真正难的不是命令本身，而是分清「连接已建立」「连接在监听」「连接已关闭但未释放」这三种状态对应的命令组合 —— 多数问题其实卡在没意识到 ss -tun 和 ss -tuln 查的根本不是一回事。
