判断一台Linux服务器有没有打补丁，最直接的办法是查看系统当前补丁版本与已安装补丁记录，通过几条命令即可确认，不用靠猜。
很多运维朋友接手一台旧服务器,第一句话就是：“这机器上次打补丁是什么时候？”Linux不像Windows那样有醒目的“更新历史”界面，它把补丁信息藏在了包管理器、内核版本和系统日志里，下面我把这套检查逻辑按场景拆开讲，从最基础的命令到日常巡检思路，一次说清楚。
先分清系统发行版再谈补丁检查
Linux服务器不是铁板一块,CentOS、Ubuntu、Debian、openEuler它们的补丁管理机制各不相同，如果拿Red Hat系的yum命令去查Debian系，大概率会碰壁，所以第一步是确认你手里是什么系统。
用一条命令看清系统身份
cat /etc/os-release
输出结果里会明确写着发行版名称和版本号,比如Ubuntu 22.04.3 LTS或者CentOS Linux release 7.9.2009，这一步决定了后续所有补丁查询命令的选择，行业共识认为，先确认系统身份再执行补丁审计，能避免一大半无效操作。
内核版本是补丁状态的第一张脸
uname -r
内核版本号里藏着补丁信息,比如15.0-91-generic，其中15是主版本，-91是Ubuntu内核补丁级别，如果同一系列内核的补丁号落后于官方最新值，说明这台服务器已经有一段时间没更新了，行业共识认为，内核版本号本身就是一种补丁标识，它不完整，但足够用来做初步判断。
如何查看linux服务器补丁：按系统类型执行对应命令
这是本篇文章的核心操作区,下面按发行版分类，把查询命令和输出解读讲透。
Red Hat系（CentOS、Rocky、AlmaLinux、RHEL）
这类系统使用yum或dnf管理补丁，查询已安装更新记录有两个常用入口。
查看已经安装的补丁列表：
yum history list
这个命令会列出过去所有yum事务记录,每条记录对应一次安装、更新或移除操作，输出中能看到事务ID、操作时间和动作内容，想深入了解某次事务装了什么补丁，执行：
yum history info [事务ID]
检查当前系统是否有待安装补丁：
yum check-update
如果系统有未打的补丁,它会列出可更新的软件包及版本号，返回退出码100，如果输出空白或提示“没有需要更新的包”，说明系统在软件层面已经是最新状态。
CentOS 7时代常用yum update --security只升级安全补丁，但CentOS 8之后需要额外安装yum-plugin-security插件。 这个细节很多老运维都会踩坑，因为默认的yum源并不区分普通更新和安全补丁，需要单独配置。
Debian系（Ubuntu、Debian）
Debian系使用apt，查询补丁记录的方式有两个方向。
查看已安装/升级的包历史：
cat /var/log/apt/history.log
这个日志文件里记录了每一次apt install、apt upgrade的详细清单，包括操作时间、软件包名称和版本变化，对于长期运行的旧服务器，这个文件能直接回答“上次打补丁是什么时候”。
检查未应用的补丁：
apt list --upgradable
这条命令会列出所有有新版但尚未安装的软件包,配合apt-get update先刷新软件源，然后执行升级审计：
apt-get -s upgrade
-s参数是模拟执行，会展示升级计划但不会真的改动系统，这种“先当赛后补”的操作模式，在排查生产环境时非常实用。
SUSE系（SLES、openSUSE）
SUSE使用zypper，补丁查询命令相对冷门，但语法简洁：
zypper patches
该命令会列出所有已安装补丁和未安装补丁,加上--all参数可以看到全部历史补丁：
zypper patches --all
通用内核补丁审计法
无论什么发行版,uname -r与官方内核版本对比都能定位补丁状态，比如Ubuntu 22.04内核最新是15.0-118，而你机器还是-91，说明中间有多个维护补丁没打，使用命令查询官方仓库：
apt list --upgradable | grep linux-image
或者查看当前运行内核与已安装内核：
dpkg --list | grep linux-image
如果系统里有多个内核版本且运行的不是最新,说明重启后才会用上新内核补丁。
区分安全补丁与功能补丁：优先级差很多
不是所有补丁都必须急着打,安全补丁修复漏洞，功能补丁修复Bug或增加特性，对于生产环境，安全补丁的优先级远高于功能补丁。
安全补丁的专项查询命令
Red Hat系用yum list-security，前提是安装了安全补丁插件：
yum install yum-plugin-security -y yum list-security
Ubuntu/Debian系统使用apt changelog查看某个包的更新日志中是否包含安全修复字样，或者访问Ubuntu CVE官网对照当前包版本号，近年来的多数安全公告都标注了CVE编号，在包版本号后加上+security标记的通常就是安全补丁。
功能补丁一般不打也没大问题
功能补丁往往涉及软件新特性或非关键Bug修复,如果不影响业务，可以纳入月度维护计划，但要注意，安全补丁和功能补丁经常捆绑发布，单独挑出安全补丁对CentOS老旧版本来说难度较大，需要依赖插件或第三方源。
服务器补丁遗漏了怎么办：分步骤补救
发现补丁落后了,别急着一股脑全打上去，生产环境里最忌讳的就是盲目yum update，很容易把业务依赖的库版本升级搞坏。
第一步：做完整快照或备份
打补丁前必须执行备份,针对云服务器，先在控制台创建系统盘快照；物理机用LVM快照或dump命令备份关键分区，行业专家指出，补丁回滚成本远高于备份成本，这一步不能省。
第二步：查看安全公告确认补丁影响面
到发行版官方站点搜索当前版本对应的补丁公告,例如Ubuntu的USN编号、Red Hat的RHSA编号，确认这些补丁是否涉及当前运行业务所需的内核模块、OpenSSL、动态链接库等核心组件。
第三步：分批更新并设置回滚点
先用yum upgrade --exclude=kernel排除内核只更新软件包，重启一次观察系统状态，确认无异常后再单独更新内核：
yum update kernel -y
更新完成后系统会新增一个内核条目,重启时在GRUB菜单里还能选择旧内核，这样相当于自带回滚机制。
第四步：验证补丁是否已生效
更新后运行uname -r查看内核版本；用rpm -qa | grep openssl或dpkg -l | grep openssl确认软件包版本号，最关键的是确认进程没有崩溃、网络服务正常响应。
用自动化工具替代手工检查：linux安全补丁检查工具
手工定期查补丁容易漏检,尤其服务器多的时候，自动化审计工具能批量输出补丁状态。
常见的开源审计工具
openscap：Red Hat系官方推荐的安全扫描工具，能基于CVE库检查系统漏洞和补丁状态。lynis：轻量级安全审计脚本，输出内容包含补丁缺失提示，适合快速巡检。osquery：Facebook开源的主机监控工具，可以用SQL查询系统补丁信息。
工具的使用逻辑都是先扫描系统包缓存,再比对CVE数据库，输出风险级别，以lynis为例，一条命令完成初步审计：
lynis audit system
输出报告末尾会汇总补丁相关建议,工具的核心价值在于定期生成持续对比的记录，而不是一次性查出问题。
补丁管理的周期建议
据不完全统计,相当一部分安全事件发生在补丁发布后30天内，因此生产环境建议每两周做一次安全补丁检查，每月执行一次完整补丁更新，非生产环境可以放宽到季度，补丁周期要和业务低峰对齐，最好写在值班流程里。
Linux服务器怎么确定有没有打补丁？常见问题快速解答
有没有一条命令能显示所有历史补丁？
没有单条统一命令,但可以组合命令实现等效结果，Debian系用zgrep查询dpkg.log历史记录，Red Hat系用yum history list，SUSE用zypper patches --all，如果想看内核补丁，统一用uname -r结合官方发布版本对比，多条命令组合使用，才能得到完整的补丁时间线。
服务器显示没有可用更新，就一定打过补丁吗？
不一定,软件源如果配置错误或已失效，yum check-update和apt list --upgradable会给出假阴性结果，比如CentOS 8停止维护后，默认源失效，再跑yum check-update就提示“没有软件包需要更新”，实际上补丁已经无人投递，此时必须更换可用源（如Vault源或第三方镜像）才能恢复补丁检查能力。
uname -r显示的内核版本比官方新，是不是补丁就全了？
不是,内核版本只能反映内核本身的补丁状态，不代表用户态软件包都已更新，比如OpenSSL、Bash、sudo这类高价值攻击面工具的补丁独立于内核发布，需要用包管理工具单独核对版本，安全补丁审计需要同时关注内核态与用户态，缺一不可。
补丁检查的本质是建立一条从版本号到安全状态的映射链路,无论你用包管理器命令手工查询，还是借助自动化工具批量扫描，最终都要回到“系统当前版本与官方安全修复版本是否一致”这个问题上，把补丁审计写进例行巡检，比出了问题再补救高效得多。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/766743.html
