端口没反应需先确认服务是否真在监听：用ss -tuln | grep :端口检查，无输出说明未监听成功；有输出则看local address是否为0.0.0.0或*，127.0.0.1仅限本机访问。
端口没反应？先确认服务真在监听
服务启动了却访问不了，八成是压根没监听成功。不是端口被占，而是根本没 bind 上去——比如只绑了 127.0.0.1 却试图从外网访问，或者配置写错端口（如写成 8080 却查 :80）。
-
ss -tuln | grep :8080：快速看 8080 是否出现在监听列表里（-tTCP、-uUDP、-l仅监听、-n不解析域名） - 如果没输出，说明服务没起来，或监听地址不对；有输出但连不上，再查
Local Address列——127.0.0.1:8080表示只本机可连，*:8080或0.0.0.0:8080才对外开放 -
netstat -tuln功能等价但慢，新系统可能没装net-tools，不推荐作为首选
谁占了 3000 端口？得看到进程名和 PID
查到端口在监听只是第一步，关键是要知道哪个进程干的。普通用户执行带 -p 的命令会提示 Permission denied，不是命令错了，是权限不够。
- 必须加
sudo：例如sudo ss -tunlp | grep :3000，否则看不到其他用户的进程信息 - 输出中
users:(("node",pid=1234,fd=23))这类字段才是真实归属，pid=1234可直接用于ps -p 1234或kill 1234 - 替代方案：
sudo lsof -i :3000更灵活，不依赖iproute2，还能查已建立连接的进程，但部分最小化系统默认没装
UDP 端口也要查？别漏掉 -u
TCP 查得再细，如果服务走的是 UDP（比如 DNS、NTP、某些监控 agent），漏掉 -u 就等于没查。很多新手只打 ss -tln，结果死活找不到监听进程。
-
ss -tuln是完整写法：-t和-u要同时带上，否则 UDP 监听端口不会出现 - 例如排查
53端口：用sudo ss -tulnp | grep :53，否则可能错过systemd-resolved或dnsmasq - UDP 没连接状态概念，所以不用关心
ESTABLISHED，只看UNCONN（未连接）那一栏是否在监听即可
为什么 ss 比 netstat 快？内核读取方式不同
ss 直接读 /proc/net/ 下的内核 socket 表，而 netstat 是通过遍历所有进程再反查 socket，数据路径长、开销大。高并发服务器上，netstat -an 可能卡好几秒，ss -an 基本瞬间返回。
- 生产环境一律用
ss，尤其做监控脚本时——watch -n 1 "ss -s"看连接摘要比netstat -s稳定得多 -
ss -s输出里的TIME-WAIT数量突增，往往意味着上游连接频繁断开；SYN-RECV高则要警惕 SYN Flood，这些信号netstat也能给，但延迟高、易丢帧 - 老系统若无
ss（极少见），再退用netstat -tulnp，但记得先yum install iproute或apt install iproute2
真正容易被忽略的，是监听地址的细节——ss -tuln 输出里那一列 Local Address，它决定了服务能不能被访问到，而不是仅仅“有没有监听”。
