1. 先把血缘关系理清楚：CentOS 和 RHEL 到底谁是谁

CentOS 和 Red Hat Enterprise Linux 的关系，是我这些年在群里、在客户现场被问得最多的问题之一。很多人第一次接触 Linux 服务器，装的就是 CentOS，敲命令、配服务都挺顺，直到某天看到“RHEL 订阅到期”“CentOS 停止维护”这类字眼，才开始慌：这两个到底是不是一回事，我手上这套还能不能用，要不要换。这个问题说白了不复杂，但牵扯到商业模式、开源协议、版本节奏、生态认证好几层，只讲“CentOS 是 RHEL 的免费版”会漏掉太多关键细节，真到选型和迁移的时候容易翻车。

我先把结论放在前面，方便你对号入座：RHEL 是 Red Hat 公司出品的商业企业级发行版，代码开源但服务收费；CentOS 是社区把 RHEL 的源码重新编译、去掉商标后做出来的免费重建版；2020 年底之后，CentOS 的重心转向了 CentOS Stream，它从“RHEL 的复刻”变成了“RHEL 的上游预览”。这三句话基本覆盖了它们的关系骨架，剩下的都是血肉。下面我会按“为什么会这样—差在哪些地方—实操怎么分辨—运维怎么对照—遇到问题怎么查”这个顺序往下讲，适合刚入行的运维新人，也适合正在做系统选型、迁移规划的老手。

1.1 RHEL 卖的不是代码，是确定性

要理解 CentOS 为什么存在，得先理解 Red Hat 靠什么活着。RHEL 的源码是公开的，Red Hat 会把每个软件包的源码以 SRPM 的形式发布出来，这是 GPL 等开源许可证的要求，也是它整个商业模式的基石。但 Red Hat 真正收费的部分不是这些代码本身，而是围绕代码建立起来的一整套“确定性”：十年左右的生命周期承诺、按严重等级划分的安全公告、可以订阅推送的补丁、硬件和软件厂商的兼容性认证矩阵、以及出了问题能打电话找到工程师的售后支持。

从企业采购的角度看，这笔钱花得并不冤。服务器上跑的可能是核心交易系统、数据库、ERP，一出问题就是真金白银的损失，这时候“我能找到人负责”比“软件免费”重要得多。所以 RHEL 的定价逻辑更像保险，而不是软件授权。理解这一点之后，你再看 CentOS 的定位就清楚了：它服务的正是那些想要 RHEL 的技术栈、但不需要（或者买不起）官方支持的用户群体，比如内部测试环境、教学实验室、预算有限的中小项目。

1.2 CentOS 的诞生：一条完全合规的“复刻”路径

CentOS 全称是 Community ENTerprise Operating System，社区企业操作系统。它的做法很直接：把 Red Hat 发布的 RHEL 源码包拿下来，去掉里面所有涉及 Red Hat 商标、Logo、品牌标识的内容，重新编译打包，形成一套二进制层面高度兼容的免费系统。这个动作之所以合法，是因为开源许可证允许你分发和修改源码，只要你不冒用原厂的商标、不暗示自己得到了原厂背书就行。CentOS 项目组做的基本就是这件事，改的主要是品牌文件，包本身的版本号、依赖关系、ABI 接口和对应的 RHEL 版本几乎一致。

这就带来一个很实用的结果：绝大多数为 RHEL 写的软件、脚本、配置文档，在 CentOS 上可以原样跑。你在网上搜到的教程、公司内部沉淀的部署手册，只要标的是 RHEL 7 或者 RHEL 8，对应的 CentOS 7、CentOS 8 基本照抄就行。这个特性是 CentOS 当年能火遍中小企业和个人开发者的核心原因，也是很多人至今对它念念不忘的原因。

1.3 CentOS Stream 这一刀，改的是定位不是名字

2020 年 12 月的那次公告，是整个社区记忆最深的一个转折点。Red Hat 宣布 CentOS Linux 8 的支持周期提前到 2021 年底结束，同时把资源集中到 CentOS Stream 上。这个决定让大量用户措手不及，因为原本大家预期 CentOS 8 会跟着 RHEL 8 走到 2029 年。更关键的是定位变了：过去的 CentOS Linux 是 RHEL 的下游复刻，RHEL 先发，CentOS 后跟；而 CentOS Stream 变成了 RHEL 的上游，它先跑，RHEL 的每个次版本是从 Stream 的某个快照分支出来的。

这个顺序一变，含义就完全不同了。Stream 上的包会比 RHEL 更早、更激进，你等于是在帮 RHEL 做前置验证，理论上遇到未打磨问题的概率要高一些。对于追求“和 RHEL 一模一样”的用户来说，这显然不是他们想要的，于是 Rocky Linux、AlmaLinux 这些新的下游重建版迅速冒了出来，填补了空白。所以今天再谈 CentOS，你得区分清楚说的是 CentOS Linux（已停止）还是 CentOS Stream（在维护中），这俩的脾气完全不一样。

2. 差异对照：别只记住“一个收费一个免费”

如果只把差异归结为价格，那在实际项目里迟早要吃亏。我在做迁移评估的时候，习惯从支持模式、版本节奏、认证生态、细节实现四个维度去拆，每个维度都会影响你的技术决策。下面这几节把这四块讲透，你以后拿到一台机器或者接到一个选型需求，心里能有个清晰的判断框架。

2.1 支持模式与生命周期：这才是选型的核心变量

RHEL 的生命周期是明确写在官方文档里的，一般主版本提供十年左右的支持，前几年是完整支持，后面转入维护支持，之后还有延长生命周期支持可以额外购买。CentOS Linux 7 走的是类似节奏，但 EOL 时间点固定在 2024 年 6 月底；CentOS Linux 8 则被提前终止。CentOS Stream 的维护窗口通常跟随它所对应的 RHEL 主版本，但它是持续滚动的，不会像传统版本那样有明显的“次版本”概念。

这张表建议你收藏一下，尤其是做预算和迁移排期的时候，生命周期这个数字直接决定你要不要动、什么时候动。我见过太多团队等到系统 EOL 前一个月才开始评估，结果测试窗口、业务停机窗口全挤在一起，非常被动。

2.2 二进制兼容不等于完全一样，细节都在缝里

“CentOS 和 RHEL 二进制兼容”这句话对，但不能理解成两台机器完全无差别。真实的差异藏在几个地方。第一是品牌文件，RHEL 上有/etc/redhat-release和redhat-release这个包，CentOS 上是/etc/centos-release和centos-release包，有些软件安装脚本会去读这个文件判断发行版，读到 CentOS 就可能走到不同的分支逻辑。第二是订阅管理工具，RHEL 自带subscription-manager、rhsm这套东西，注册、附加订阅、查看可用仓库都靠它，CentOS 上没有这套，仓库配置直接写在/etc/yum.repos.d/里。

第三是仓库地址和更新来源，RHEL 从订阅的 CDN 拿包，CentOS 从社区镜像站拿包，EOL 之后还要手动把源切到 vault 归档地址。第四是部分附加组件，Red Hat 生态里有些工具（比如某些性能分析、合规扫描组件）在 CentOS 上要么没有，要么需要额外折腾。这些差异平时不显山不露水，一旦你写自动化脚本、做镜像构建、跑合规检查，就会一个个冒出来，所以心里要有数。

2.3 认证与生态：生产环境绕不开的一道墙

这一块是最容易被忽略、但对企业用户最要命的。很多商业软件、数据库、中间件在官方的兼容性列表里只写“支持 RHEL 某个版本”，你拿着 CentOS 去装，技术上能跑通，但一旦出问题，厂商第一句话就是“你这是非认证平台，我们不提供支持”。同理，硬件厂商的驱动认证、云厂商的官方镜像、甚至某些行业的合规审计要求，都会明确指向 RHEL。CentOS 在这些场景里处于一个尴尬位置：技术上够用，纸面上不够。

Red Hat 后来推的 UBI（通用基础镜像）算是给这个矛盾打了个补丁，它允许你在容器场景里免费使用 RHEL 的基础镜像并自由分发，目的是把生态往 RHEL 那边拉。对普通用户来说，这意味着如果只是容器里要个基础镜像，不必非得用 CentOS；但如果你的诉求是整机生产系统且需要厂商背书，那还是老老实实走订阅。这个取舍没有标准答案，取决于你的业务能不能承担“没人兜底”的风险。

3. 上手实操：怎么分辨、怎么选、怎么换

理论讲完，落到键盘上。这一章我按“先认清楚手里是什么—再决定装什么—然后验证差异”的顺序来，每一步都给具体命令和判断依据，你可以直接对着自己的机器跑一遍。

3.1 三步确认你手上这台机器到底是什么

拿到一台陌生的 Linux 服务器，我一般三十秒内就能判断它的血统。第一步看/etc/os-release，这个文件是几乎所有现代发行版都有的标准信息源，里面有 NAME、VERSION_ID、ID 这些字段，能直接告诉你是 centos、rhel 还是 rocky。第二步看/etc/redhat-release或者/etc/centos-release，这是 Red Hat 系特有的文本文件，内容形如 “CentOS Linux release 7.9.2009 (Core)”，一眼就能读出版本。

cat /etc/os-release cat /etc/redhat-release 2>/dev/null || cat /etc/centos-release 2>/dev/null rpm -q centos-release redhat-release rocky-release 2>/dev/null rpm -q --whatprovides /etc/redhat-release

第三步用 rpm 反查是哪个包提供了发布信息文件。RHEL 上会返回redhat-release-server之类的包，CentOS 上返回centos-release，这一步能排除掉那些改了 release 文件但底子仍是另一个发行版的情况。三条命令交叉验证，基本不会认错。这个习惯我强烈建议养成，因为它直接决定你后面该用哪套文档、哪个仓库、哪种支持路径，认错血统是很多低级故障的源头。

注意：不要只看uname -a判断发行版。内核版本号在 CentOS 和 RHEL 上几乎一样，光看内核你分不出来，真正的区别在用户态和发布信息里。

3.2 镜像下载与安装：版本怎么挑，虚拟机怎么配

选镜像这件事，思路是先看用途再看生命周期。如果是要长期跑的生产环境，优先选仍在维护窗口内的版本，CentOS Linux 7 和 8 都已经停止维护，除非有明确的存量约束，否则新项目不建议再上。想免费又贴近 RHEL，可以看 Rocky 或 AlmaLinux 的对应版本；想跟 RHEL 节奏一致做开发测试，CentOS Stream 9 或 10 是合理选择。CentOS 7.9 这类老版本还有它的价值，主要是兼容那些跑了很多年、依赖旧版本 glibc 和 OpenSSL 的老系统，镜像站一般会把它们放在 vault 归档目录里。

虚拟机里装 CentOS，最常见的坑在网络和分区。VMware 创建虚拟机时，网络模式选 NAT 还是桥接要提前想清楚：NAT 适合笔记本单机测试，虚拟机能上网但外部访问要配端口转发；桥接适合模拟真实服务器的网络位置，能直接和局域网其他机器互通。安装界面里那一步“网络和主机名”记得把网卡开关打开，否则装完发现自己 ping 不通任何东西，回头还要去改配置文件，白折腾一轮。

# 装完之后检查网卡和地址 ip a nmcli device status nmcli connection show # CentOS 7 传统配置文件路径 cat /etc/sysconfig/network-scripts/ifcfg-ens33

分区方面，我个人习惯用 LVM，好处是后期扩容灵活。虚拟机磁盘扩容的流程是：先在虚拟化平台上把磁盘容量调大，进系统用lsblk看到磁盘变大了，再对分区和 LVM 动手，最后扩展文件系统。这个链路每一步都容易断，后面第 5 章会单独拆开讲。

3.3 验证差异：订阅与仓库的实际动手

想直观感受 RHEL 和 CentOS 的区别，最直接的办法是看仓库是怎么配的。在 RHEL 上，注册和附加订阅是一条核心操作链，仓库是订阅之后自动生成的；在 CentOS 上，仓库文件是你自己写或者装完系统就带着的，更新来源全靠这几个文件。

# RHEL 上查看订阅状态（CentOS 上没有这个命令） subscription-manager status subscription-manager repos --list-enabled # 两边都通用的仓库查看方式 ls -l /etc/yum.repos.d/ cat /etc/yum.repos.d/*.repo yum repolist all # CentOS 7 及更早 dnf repolist --all # CentOS 8 / Stream 9 及更新

这里有个很典型的 EOL 场景：CentOS 7 停维之后，原来的 mirrorlist 地址会失效，yum直接报 “Cannot find a valid baseurl”。解决办法是把仓库地址换成 vault 归档站，把mirrorlist那行注释掉，改成baseurl=http://.../vault.centos.org/7.9.2009/os/x86_64/，然后yum clean all && yum makecache。RHEL 上不会遇到这个问题，因为它走的是订阅 CDN，但订阅过期之后同样会报仓库不可用，排查思路是查订阅状态而不是改地址，这一点别搞混。动手验证一遍，你对两者差异的理解会立刻具体起来。

4. 运维场景对照：同一件事在两边怎么做

真正拉开差距的不是安装，而是日常运维。同一个需求，在 RHEL 和 CentOS 上的操作路径八成一样，剩下两成不一样的地方，恰恰是容易卡住的地方。这一章挑几个最高频的场景做对照，包括网络、磁盘、防火墙、软件安装和服务部署，给你一份可以直接抄的对照清单。

4.1 网络、磁盘、防火墙这些高频操作

网络这块，CentOS 7 时代主流是network服务和/etc/sysconfig/network-scripts/ifcfg-*文件，CentOS 8 之后逐步转向 NetworkManager 的nmcli命令。RHEL 8 和 9 也走 NetworkManager 这条路，所以新版本上两边几乎没差别。改 IP 的推荐做法是用 nmcli，比手改配置文件更少出错：

# 修改 IPv4 地址、网关、DNS nmcli connection modify ens33 ipv4.addresses 192.168.1.100/24 nmcli connection modify ens33 ipv4.gateway 192.168.1.1 nmcli connection modify ens33 ipv4.dns 223.5.5.5 nmcli connection modify ens33 ipv4.method manual nmcli connection up ens33

磁盘挂载和扩容是另一个高频需求。挂载新盘的流程是lsblk看盘、parted或fdisk分区、mkfs.xfs格式化、blkid取 UUID、写/etc/fstab、mount -a验证。写 fstab 时我强烈建议用 UUID 而不是设备名，因为设备名在磁盘顺序变化时会漂移，UUID 不会。扩容则分两步：先扩 LVM 逻辑卷，再扩文件系统，XFS 用xfs_growfs，ext4 用resize2fs，顺序反了文件系统不会变大。

防火墙方面，新旧版本都默认用 firewalld，操作命令一致。开放一个 TCP 端口的标准动作是加--permanent再--reload，两步缺一不可，很多人只执行了前半句然后纳闷为什么没生效：

firewall-cmd --permanent --add-port=8080/tcp firewall-cmd --reload firewall-cmd --list-ports

配置文件层面，/etc/firewalld/zones/public.xml是最终落盘的地方，用命令行加规则之后这里会同步更新。如果你想批量下发规则，直接改这个文件再 reload 也行，但要注意 XML 格式别写错，否则 firewalld 起不来，SSH 可能一起断掉，那就麻烦了。

4.2 离线安装软件：思路比命令重要

内网环境离线装软件是绕不开的坎，gcc、Node.js、Maven、Python 包这些都是重灾区。核心思路只有一条：把依赖提前备齐，做一个本地仓库，别一个个 rpm 手动怼。具体做法是在一台能上网的同版本机器上用yumdownloader或者dnf download --resolve把主包和依赖全下下来，拷到目标机，用createrepo生成元数据，然后写一个指向本地目录的 repo 文件。

# 在联网机器上下载 rpm 及依赖 yumdownloader --resolve --destdir=/tmp/pkgs gcc gcc-c++ make nodejs maven # 拷到离线机器后生成仓库元数据 createrepo /opt/localrepo # 写仓库文件 cat > /etc/yum.repos.d/local.repo <<'EOF' [local] name=Local Repo baseurl=file:///opt/localrepo enabled=1 gpgcheck=0 EOF yum clean all && yum makecache yum install -y gcc nodejs maven

这里有个我踩过的坑：目标机和下载机的发行版大版本必须一致，CentOS 7 的包拿到 Stream 9 上装，依赖关系对不上，会陷入“装 A 要 B，装 B 要 C”的死循环。另外系统自带的 Python 千万别乱动，很多系统工具依赖它，硬升级或者删掉会导致 yum/dnf 直接罢工。要装新版本 Python 就单独编译或者用虚拟环境，和系统 Python 隔离，这条经验用血换来的，建议刻在脑子里。Maven 这类 Java 工具更推荐直接下二进制压缩包解压，比走 rpm 省事，还不用担心依赖冲突。

4.3 服务部署：Nginx、Docker、MySQL 的差异点

这三个服务的部署流程在两套系统上基本一致，差异主要体现在仓库来源和依赖前置条件上。装 Nginx 的常规做法是加官方 yum 源，或者直接用二进制包编译。编译方式要提前装好 pcre、zlib、openssl 的开发包，离线环境下这些依赖同样要走本地仓库。二进制包的好处是不依赖系统库版本，解压即用，适合内网快速铺开，缺点是要自己写 systemd 服务文件做开机自启。

# /etc/systemd/system/nginx.service 简化示例 [Unit] Description=nginx After=network.target [Service] Type=forking ExecStart=/usr/local/nginx/sbin/nginx ExecReload=/usr/local/nginx/sbin/nginx -s reload ExecStop=/usr/local/nginx/sbin/nginx -s quit [Install] WantedBy=multi-user.target

Docker 的部署有个容易忽略的前置条件：CentOS 7 的内核虽然在支持范围内，但要跑 overlay2 存储驱动，内核版本不能太旧，3.10.0-514 以后的版本才比较稳妥。安装前先把yum-utils装上，配置好镜像加速地址，再装 docker-ce。RHEL 上安装 Docker 的流程类似，但仓库来源不同，有些企业会直接用 Red Hat 提供的容器工具链替代。装完记得systemctl enable --now docker，否则重启机器服务不会自己起来。

MySQL 8 的部署有个经典冲突：系统里预装的 mariadb-libs 会和 MySQL 官方的 rpm 包抢文件，必须先卸掉。这个动作在 CentOS 和 RHEL 上都要做，顺序是先清理冲突包再装服务端，最后跑mysqld --initialize初始化数据目录，注意初始化时会生成临时密码，在日志里找。Samba 配置也是类似，/etc/samba/smb.conf写共享定义，然后处理 SELinux 布尔值和防火墙端口，这两步漏一个就访问不了，表现为能连上但打不开目录，很容易误判成权限问题。

5. 常见问题与排查技巧实录

运维的价值一半体现在不出事，另一半体现在出事能快速定位。这一章把我在 CentOS 和 RHEL 上遇到的高频故障整理成速查表，再补几条独家心得，都是常规文档里不太会写、但现场特别好用的东西。

5.1 高频故障速查表

这张表里最值得展开的是 dracut 卡住这个，因为它看起来最吓人。这个现象通常出现在你动过磁盘、克隆过虚拟机、或者改过分区之后，本质是引导阶段找不到根文件系统。处理办法是在内核启动参数里加rd.break，进到紧急 shell 里把根分区挂起来，检查/etc/fstab里的 UUID 和实际blkid输出是否一致，不一致就改回来。克隆虚拟机之后网卡 MAC 变化导致配置对不上，也是同一类问题的不同表现，处理思路是重新生成网卡配置或更新绑定。

5.2 几条用教训换来的避坑心得

第一条，EOL 的老系统别裸奔在公网上。CentOS 7 和 8 停维之后不再有官方安全补丁，暴露在公网等于把门敞开。现实做法是尽快规划迁移，短期内至少用防火墙把访问来源限制死，只放必要的端口给必要的 IP，别图省事全开。第二条，改任何关键配置之前先备份，cp /etc/fstab /etc/fstab.bak这种一秒钟的动作，能省下你几个小时甚至一天的重装时间，我在单用户模式下改错 fstab 导致系统起不来的经历，至今想起来都觉得亏。

第三条，别迷信“一键脚本”。宝塔面板这类工具确实能省事，但它对系统版本、内存、SELinux 状态都有隐性要求，装之前把环境对齐，装之后清楚它改了哪些地方（比如它会动防火墙、动软件源、占用端口），否则后续和你的其他服务冲突时，排查方向会被完全带偏。第四条，升级 OpenSSH 这类基础组件要格外谨慎，先在小范围验证，确认新版本和现有 PAM、密钥、客户端兼容之后再铺开，配置文件一定要留旧版本做回滚。第五条，区分清楚你面对的到底是“配置问题”还是“发行版差异问题”，前者查文档能解决，后者往往需要换包、换源或者调整脚本判断逻辑，两者排查路径完全不同，搞混了会在错误方向上浪费大量时间。

我个人在实际操作中的体会是，把 CentOS 和 RHEL 当成“同一套技术栈的两种交付方式”来理解最省心：技术内容通用，支持和使用条款不同。真正要你做的判断，从来不是“哪个更好”，而是“这个场景里我能承担多大的不确定性”。测试环境、容器基础镜像、个人学习，免费路线完全够用；生产核心、要厂商背书的场景，该走订阅就走订阅。把这条线想清楚了，选型、迁移、故障处理都会顺畅很多。后续如果系统要扩，记得先看版本的生命周期表，再动手做镜像和仓库的准备，这比事后补救从容得多。