最准确方法是先执行systemctl list-units --type=service --state=running筛选真正运行的服务，再用sudo ss -tulnp或sudo lsof -a -p pid -i -stcp:listen逐个验证其监听端口，最后用nc -zv 127.0.0.1 端口实测连通性。
你需要确认当前系统中哪些服务正在真实监听端口，而不是只查服务是否启用或配置是否存在——因为服务已激活但未监听端口，或监听了非预期端口，都会导致连接失败。
先列出所有正在运行的服务
执行命令：systemctl list-units --type=service --state=running。
这一步过滤出真正处于 active (running) 状态的服务，排除 loaded 但未启动、失败或被禁用的项；输出中每行第一列是服务名（如 sshd.service），第三列必须为 active、第四列为 running，才代表该服务进程已拉起。
注意：仅靠此命令无法得知它监听了哪个端口，只是锁定“可能开过端口”的候选服务列表。
对关键服务逐个查其监听端口
方法一：用 ss 反向匹配服务名绑定的端口
执行：sudo ss -tulnp | grep -i sshd（将 sshd 替换为目标服务名，如 nginx、mysql、redis-server）。
该命令会显示该服务名关联的所有监听套接字，Local Address 列中冒号后即为端口号；若无输出，说明该服务虽在运行，但并未开启网络监听（例如某些服务默认禁用远程访问）。
方法二：用 lsof 查进程打开的网络文件
先获取服务主进程 PID：systemctl show --property MainPID --value sshd。
再查该 PID 打开的监听 socket：sudo lsof -a -p PID -i -sTCP:LISTEN（把 PID 替换为上一步实际数值）。
这比 grep 进程名更可靠，能避开同名子进程干扰；如果返回空，基本可判定该服务当前未监听任何 TCP 端口。
快速扫描全部活跃监听端口并标注服务归属
第一步：运行 sudo ss -tulnp，一次性列出所有 TCP/UDP 监听端口及对应进程名与 PID。
第二步：观察输出中 PID/Program name 列，格式为 1234/nginx 或 5678/java；斜杠前是 PID，斜杠后是可执行文件名——这就是端口的实际控制者。
第三步：若看到陌生程序名（如 2345/python3），用 ps -p 2345 -o comm,args 查看完整启动命令，确认是否为预期服务。
注意：ss -tulnp 要求 root 权限，否则 PID/Program name 列为空或显示为 -，无法完成归属判断。
验证某个端口是否真被某服务响应
方法一：用 nc 实测连通性
执行：nc -zv 127.0.0.1 22（把 22 换成你要验证的端口号）。
若返回 succeeded!，说明本地确有进程在该端口监听并接受连接；若超时或拒绝，即使 ss 显示监听，也可能因防火墙拦截、bind 地址限制（如只绑 127.0.0.1）或服务异常导致无法通信。
方法二：检查服务自身状态输出
执行：systemctl status nginx | grep "listening\|port"（替换 nginx 为实际服务名）。
部分服务（如 Nginx、Apache）会在日志或 status 输出中直接声明监听地址与端口，这是最贴近服务本意的依据，比底层 socket 扫描更语义明确。
