ss比netstat更快更准且不依赖/proc，生产环境应优先使用；查established连接需用ss -t state established，因ss默认只显示connected状态（含fin-wait等），不等于活跃通信。
ss 比 netstat 更快、更准，且默认不依赖 /proc（避免卡死），生产环境应优先用 ss；netstat 已被标记为废弃，多数新发行版（如 RHEL 9、Ubuntu 22.04+）默认不预装。
查所有 ESTABLISHED 连接，为什么 ss 要加 -t 状态过滤才准？
ss 默认只显示 “connected” 状态的 socket（即 ESTABLISHED、FIN-WAIT-1 等），但不包括 LISTEN；而 netstat -an 默认混着列所有状态，容易误判。要精准抓活跃连接，必须显式限定协议和状态：
-
ss -t state established—— 只看 TCP 已建立连接（推荐） -
ss -tn state established—— 加-n跳过 DNS 解析，提速且避免因 hosts 配置异常卡住 -
netstat -ant | grep ESTABLISHED——netstat无原生命令级状态过滤，只能靠管道筛，效率低、易漏（比如状态字段前后有空格） - 注意：
ss state connected会包含 FIN-WAIT、TIME-WAIT，不等于“正在通信”，别直接当成活跃业务连接数
LISTEN 端口查不到？检查 -l 和 -t/-u 是否配对
常见错误是只输 ss -l 或 netstat -l，结果为空——因为没指定协议类型。LISTEN 是 socket 属性，不是独立状态，必须搭配协议开关：
Python Linux版
下载
Python Linux版 为 Python.org 官方提供的 Python 3.14.6 Linux/Unix 源码包，适合在Linux/Unix环境中安装、运行 Python 代码并学习函数、模块和脚本开发。
-
ss -tln查所有 TCP 监听端口（-tTCP，-llistening，-n数字端口） -
ss -uln查 UDP 监听（如 DNS、NTP） -
netstat -tln/netstat -uln效果相同，但启动慢、可能被大量 TIME-WAIT 拖累 - 若仍看不到某服务端口（如 nginx 明明在跑却没显示），先确认是否 bind 到 127.0.0.1（
ss -tln | grep :80要带冒号）或使用了SO_REUSEPORT（某些旧内核下ss不显示全部）
定位某个进程占用了 8080 端口，-p 权限和兼容性怎么处理？
-p（显示 PID/进程名）需要 root 权限，且行为在两个命令中差异明显：
-
sudo ss -tulpn | grep ':8080'——ss的-p输出格式统一：users:(("nginx",pid=1234,fd=6))，fd 是文件描述符号 -
sudo netstat -tulpn | grep ':8080'——netstat的-p在部分系统（如容器内）会报can't identify protocol，因它依赖 /proc/net/* 的完整结构 - 非 root 用户执行
-p会静默失败（无报错，但不显示进程名），建议先试ss -tln确认端口存在，再切 sudo 补-p - 容器场景慎用：宿主机
ss -tulpn看不到容器 netns 内的进程，需进容器 ns 执行或用nsenter
真正麻烦的是 TIME-WAIT 泛滥时 netstat 直接卡死，而 ss 仍可响应；还有就是 ss 支持 src/dst 过滤（如 ss dst 192.168.1.100:），netstat 完全没这能力——这些细节不实操一次根本意识不到。
