ss -tulnp 查不到 PID 和进程名是因为非 root 用户权限不足，-p 参数静默失效；需 sudo 执行，否则输出中 PID/Program name 列为空或报 Permission denied。

ss -tulnp 为什么查不到 PID 和进程名

直接执行 ss -tulnp 却看不到 PID/Program name 列，通常是因为权限不足。非 root 用户无法读取其他用户进程的 socket 信息，-p 参数会静默失效，输出里 PID 那列为空或报错 Permission denied。

实操建议：

• 加 sudo 执行： sudo ss -tulnp | grep :8080
• 如果仍无 PID，检查是否被 SELinux 或容器命名空间隔离（如 Docker 容器内运行时，宿主机视角才可见完整进程）
• ss 在某些精简镜像（如 Alpine）中默认不带 -p 支持，需安装 iproute2 完整版

lsof -i :端口号 输出里 NAME 字段显示 *:http-alt 是什么意思

http-alt 是 IANA 注册的服务别名，对应端口 8080；*:http-alt 表示该进程监听在所有 IPv4/IPv6 地址（*）的 8080 端口，协议为 TCP。这不是错误，而是正常解析结果。

但要注意：

• 如果看到 *:https 却实际想用 8443，说明配置里写的是服务名而非数字端口，可能引发意外交互
• 想跳过服务名解析、强制显示数字端口，加 -P 参数：sudo lsof -i :8080 -P
• NAME 列出现 IPv6 但你只绑了 IPv4，可能是应用未显式禁用 IPv6，导致内核自动映射双栈监听

netstat 显示端口在 LISTEN 状态，但 kill 掉 PID 后端口还是被占

常见于僵尸监听、TIME_WAIT 残留或内核级绑定（如 systemd socket activation）。netstat 显示的 LISTEN 不一定对应活跃用户态进程。

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

排查要点：

• 确认 PID 是否真实存在：ps -p ，若返回 “No such process”，说明进程已退出但 socket 尚未释放
• 检查 TIME_WAIT 状态：ss -tan state time-wait | grep :8080，这是 TCP 正常回收机制，持续约 60 秒
• 查看 systemd socket 单元：systemctl list-sockets | grep 8080，若匹配到，需停用对应 .socket 单元而非服务
• 某些内核模块（如 nf_conntrack）或代理（如 haproxy 的 transparent mode）也可能持有端口，此时 lsof 和 ss 均不可见

fuser -k 强杀后新进程启动仍报 Address already in use

fuser -k 只终止直接打开该 socket 的进程，但不会清理其子进程、守护进程或 fork 后 exec 的新实例。尤其 Java、Node.js 等常通过守护模式重启，杀一次很快又拉起。

更稳妥的做法：

• 先定位主进程：sudo lsof -i :8080 | head -n 2，关注 COMMAND 列和父进程关系
• 结合 systemctl 查服务：systemctl status $(basename $(readlink /proc//exe) 2>/dev/null)
• 对 Java 应用，用 ps aux | grep java 配合 -Dserver.port=8080 等 JVM 参数反查启动命令
• 真正要释放端口，得停服务单元：sudo systemctl stop tomcat 或 sudo pkill -f "java.*8080"

真实场景里，端口冲突往往不是单点问题——它可能是服务配置残留、容器网络重叠、或 systemd socket 激活机制在背后维持监听。盯住 PID 只是起点，关键要看进程生命周期是否受更高层管理器控制。