ss 为什么必须加 -n
不加 -n 时，ss 会对每个地址做反向 DNS 解析、对每个端口查 /etc/services 名称。现场往往正是 DNS 有问题才来排查，于是命令自己卡住，几秒的停顿足以打乱节奏；更糟的是脚本里的调用会直接超时失败，让人误以为系统异常。加 -n 后只输出数字，结果稳定、可脚本化，这是排障时最省事的习惯之一。同一习惯适用于 netstat、route、arp、iptables 等一整套网络命令。
基本信息
| 适用平台 | Linux（ss 与 netstat 行为一致） |
|---|---|
| 作用 | -n 关闭名称解析，只显示数字地址与端口 |
| 同类选项 | netstat -n、route -n、arp -n、iptables -n |
| 建议 | 交互环境可设别名，脚本里一律显式写 -n |
典型使用场景
- DNS 故障现场：确保连接表查看不受解析拖累
- 大连接表机器：解析开销随连接数放大，不加 -n 明显变慢
- 自动化脚本：显式加 -n 保证输出格式稳定可解析
- 精简容器镜像：内容里缺少 /etc/services，按服务名过滤会直接失败
- 监控采集：把 ss 输出交给采集器解析时，名称会随环境变化，必须固定为数字
- 跳板机与堡垒机：受限环境常无外网 DNS，加 -n 才能保证命令可用
对比与建议
对比与建议
# 不加 -n：可能卡在反向解析上
time ss -tan | head -5
# 加 -n：立即返回
time ss -tan -n | head -5
# 交互环境里的习惯做法
alias ss='ss -n'
# 脚本里务必显式书写，不依赖别名
ss -tan -n state established | wc -l有无 -n 的差异
| 场景 | 不加 -n 的风险 | 加 -n 的表现 |
|---|---|---|
| DNS 不可用 | 每个地址都要等解析超时 | 立即输出 |
| 超大规模连接表 | 解析开销成倍放大 | 耗时稳定 |
| 容器精简镜像 | 缺少 /etc/services，按名过滤失败 | 数字端口过滤正常 |
| 脚本解析输出 | 名称可能变化，格式不稳定 | 输出固定、便于解析 |
常用组合写法
常用组合写法
# 只看监听端口与进程，数字端口更可靠
ss -tlnp
# 统计已建立连接数量，用于容量评估
ss -tan -n state established | wc -l
# 按端口过滤（用数字端口，兼容精简镜像）
ss -tan -n '( dport = :3306 )' | head
# 组合常用参数一次看全
ss -tanp -n | sort -k4 | head -20同样的规则适用于一整套工具：netstat、route、arp、iptables 都提供 -n。断网现场统一加 -n，能避免把『工具卡顿』误读为『系统卡死』。
排查『连接数异常』时的顺序：先用 ss -s 看总量趋势，再用 ss -tan -n 按状态与端口细分，最后才去解析名称。数字口径在前，人工解读在后，能避免很多来回。
依赖服务名过滤（如 sport = :http）在精简镜像里会失败，因为 /etc/services 可能被裁剪掉；脚本与容器中一律改用端口号更稳妥。