如何查看启动了哪些服务器，查看服务器状态用什么命令？

开篇答案

查看启动了哪些服务器，分两个层面：一是看操作系统里跑了哪些服务进程，二是看这些服务监听了哪些端口，最直接的答案是：Linux 用 ps、netstat 和 systemctl，Windows 用任务管理器、netstat 和 PowerShell，按这几个命令走一遍，所有运行中的服务一目了然。

linux查看服务器启动了哪些服务：这些命令最直观

在 Linux 服务器上，服务本质上就是进程，所谓”查看启动了哪些服务器”，实际操作上就是查看当前有哪些服务进程在运行、以什么身份运行、占用了哪些资源，业内专家指出，运维排查问题时，八成以上的情况靠三条命令就能定位：ps 看进程、netstat 看端口、systemctl 看服务状态。

加载中

给服务器增加一个简约可爱的监控面板！随时随地获取服务器的运行状态

A

AMGYzhea

5.4万--

原视频地址

ps 命令：看进程全貌

ps 是老牌进程查看工具，但裸执行 ps 只能看到当前终端的进程，意义不大。真正实用的是组合参数：

ps -ef | grep java

这条命令能筛选出所有 Java 进程，比如你部署了一个 Spring Boot 应用，执行后能看到完整的启动命令、JVM 参数、工作目录，如果发现进程不存在，说明服务挂了；如果进程存在但端口不通,那就进入下一步查端口。

更全面一点的用法：

ps aux --sort=-%mem

按内存占用从高到低排列所有进程，一眼就能看出哪些服务吃资源，机器卡顿的时候,这条命令比看监控面板还快。

systemctl：查 systemd 托管的服务

现代主流 Linux 发行版都用 systemd 管理服务。查看所有正在运行的服务：

systemctl list-units --type=service --state=running

输出结果会列出服务名称、加载状态、运行状态，配合 systemctl status 服务名 能看到具体 PID、内存占用、最近日志。

这里有个常见的坑：systemctl 显示服务在运行，但业务请求就是不通，原因是服务进程崩了但 systemd 没检测到，或者只起了主进程没起工作进程，所以行业共识认为，systemctl 要和 ps、netstat 配合使用，只看一个不够。

实时动态：top 和 htop

top 是动态刷新界面，按 c 键显示完整命令路径，按 P 按 CPU 排序，按 M 按内存排序，排查”服务器负载突然飙高”时，top 是首选。

htop 是增强版，彩色界面，支持鼠标操作，F6 可以按进程树展开，虽然不是所有服务器都预装，但 apt install htop 或 yum install htop 装一下很值得。

windows服务器查看端口占用命令和进程对照方法

Windows 服务器的查看逻辑和 Linux 不一样，没有统一的 ps 命令，但PowerShell 的 Get-Process 和内置的 netstat 组合起来功能更强大。

任务管理器：最直观的入口

按 Ctrl + Shift + Esc 打开任务管理器，切到”详细信息”标签页，这里能看到所有进程的 PID、CPU 占用、内存占用、用户名，但任务管理器有个致命弱点：看不到进程对应的完整路径和启动参数,有些恶意进程光看名字根本识别不出来。

所以专业运维的流程是：任务管理器发现可疑进程，记下 PID,然后用下面的命令查它的底细。

netstat 查端口和 PID 的对应关系

netstat -ano

解释一下输出：-a 显示所有连接和监听端口，-n 用数字形式显示地址和端口（不做域名反解，速度快得多），-o 显示所属进程的 PID。

最实用的场景是”端口被占用”，比如启动 Tomcat 时报 8080 端口被占,执行：

netstat -ano | findstr 8080

看到输出最后一位数字就是占用进程的 PID，然后查这个 PID 是谁：

tasklist | findstr 12345

这样能拿到进程名，如果想看更详细的启动路径，用 PowerShell：

Get-Process -Id 12345 | Select-Object Path

运行中服务的完整清单

Windows 上查看”服务器启动了哪些服务”还有一个独特视角，Windows 服务管理器：

services.msc

里面列出了所有注册为 Windows 服务的程序，状态列会显示”正在运行”或”已停止”，但这个列表不包含直接启动的 exe 程序,所以不能完全替代任务管理器。

把服务管理器、任务管理器、netstat 三者结合起来，才是一份完整的 Windows 服务清单，查看启动类型（自动/手动/禁用）在服务属性里，启动类型为”自动”但状态停止的服务，往往就是开机失败或崩溃的服务,值得重点检查。

如何确认服务器上的服务都正常启动：端口和进程的双向验证

很多新手有个误区：觉得进程在就等于服务正常。进程活着和业务可用是两回事,最稳妥的做法是端口验证和进程验证双向交叉确认。

用端口反向验证监听状态

netstat -tlnp

Linux 上这条命令列出所有 TCP 监听端口和对应的程序名。-t 只看 TCP，-l 只看监听状态，-n 不做域名解析，-p 显示程序名和 PID。

判断标准：你部署的每一个服务都应该有一个对应的监听端口，而且这个端口必须出现在 0.0.0 或 监听地址上（表示对所有网卡开放），如果出现在了 0.0.1 上，说明服务只监听了本机回环地址，外部设备访问不了这是非常常见的配置错误。

检查端口连通性

进程在、端口也监听了，还不算完，实际还能不能通信，用 ss 或 telnet 验证：

ss -tnlp

ss 是 netstat 的现代替代品，输出更快更全。-t 显示 TCP socket，-n 不解析服务名，-l 只显示监听 socket，-p 显示进程信息。

本地验证连接：

curl -I http://localhost:8080

如果返回 HTTP 响应头，说明 HTTP 服务正常响应，对 MySQL、Redis 这类非 HTTP 服务，可以用 telnet ip 端口 测试 TCP 握手。

配置了服务的开机自启检查

有些服务当前运行正常，但系统重启后会失效。检查开机自启配置是”确认服务正常”不可少的一环：

systemctl is-enabled 服务名
systemctl list-unit-files --type=service | grep enabled

第一条查单个服务是否开机自启，第二条列出所有自启动服务，行业里做服务器巡检，这三样必须同时确认：当前运行状态、监听端口、自启动配置，三样都落实了，才算一个服务”真正正常”。

快速实战：一次典型服务器排查的完整流程

把上面这些零散命令串成一个场景化流程，你会更清楚”查看启动了哪些服务器”在实际工作中是怎么用的。

刚部署完服务，想知道起来没有

假设你刚在一台 CentOS 服务器上部署了一个 Java 后端和 Nginx 前端：

1. 先看 Nginx 状态：systemctl status nginx，显示 active (running) 就过了第一关
2. 查 Java 进程：ps -ef | grep java，确认 jar 包路径和启动参数没问题
3. 验证端口：netstat -tlnp | grep 8080，确认 Java 服务监听了 8080
4. 本地请求验证：curl -I localhost:8080/api/health，看返回 200
5. 远程验证：从你的电脑上 telnet 服务器IP 8080，通的话就彻底没问题

顺序不能乱,每一步都在上一层验证基础上增加一个维度。

服务器变卡了，找出吃资源的服务

1. 执行 top 按 M 键按内存排序，看看哪个进程排前面
2. 按 c 键展开命令全路径，确认是不是已知的业务进程
3. 如果是未知进程，用 ls -l /proc/PID/exe 查看它的可执行文件路径
4. 用 systemctl status PID 反查这个 PID 属于哪个 systemd 服务
5. 查日志：journalctl -u 服务名 --since "1 hour ago" 看这个服务这一小时在干什么

服务器上有大量时间和资源的进程

最稳妥的做法是按时间戳排查：

ps -eo pid,lstart,cmd --sort=start_time | head -30

lstart 显示进程的精确启动时间，--sort=start_time 按启动时间排序，如果服务器是三天前重启的，但某个进程显示启动时间是一小时前,那就需要重点关注了。

lsof -p PID | wc -l

统计某个进程打开的文件句柄数，如果数量异常高,基本可以断定有资源泄漏或者行为可疑。

常见问题解答

Q1：Linux 服务器上 ps -ef 显示的进程太多了，怎么快速找到自己部署的应用？

业界有两种主流思路，都基于部署前的规划：一种是用启动账号区分，比如专门创建一个 app 用户部署服务，然后用 ps -u app 直接列出该用户全部进程；另一种是用端口反查，先用 netstat -tlnp | grep 端口号 找到 PID，再用 ps -fp PID 看完整信息，建议在部署文档里注明每个服务的默认端口和启动用户，排查时直接按这两个维度筛选,效率远高于在千行输出里逐条找。

Q2：查看启动的服务和查看正在监听的端口，两者有什么区别？

服务是一个逻辑单位，可能包含一个主进程加多个子进程；端口是网络通信的入口，是运行结果而非运行本体，最典型的例子是 Nginx：ps 能看到一个 master 进程和多个 worker 进程，但 netstat 只会看到一个 80 端口监听。如果某个服务没监听端口，说明它要么还没启动完成，要么启动失败了。

Q3：网络上有哪些服务在监听，这些服务占用的端口范围大概是什么样的？

以常见部署架构为例：Web 服务器占用 80/443，反向代理也是 80/443，后端 API 通常是 8080 或 8443，数据库服务 MySQL 是 3306、PostgreSQL 是 5432，缓存服务 Redis 是 6379，消息队列 Kafka 是 9092，这些端口是业界约定俗成的默认值，但出于安全考虑，公网环境的实际部署方案通常会改用随机高位端口并开启防火墙白名单策略，大多数情况下，生产服务器的监听端口不超过 20 个，如果数量远超这个数,建议审计每一个非白名单端口的用途。

写在最后

查看启动了哪些服务器，说到底就是三件事：进程有没有、端口通不通、自启动配没配，把 ps、netstat、systemctl 三个工具用熟，再理解 pid 和端口的对应关系，绝大多数问题都能在几分钟内定位，掌握这套方法论，比背下任何一条单独的命令都重要因为命令会变，但”进程和端口双向验证”的思路不会过时。