作者： Fedora VPS服务器为何每13个月必须升级一次
Fedora每个版本约支持13个月。了解VPS服务器何时失去安全更新、版本升级的实际维护成本，以及何时应选择Ubuntu LTS或AlmaLinux。
Fedora 版本会获得多长时间的安全更新？
Fedora 服务器大约每年需要升级一次，只要这台机器仍在使用，就需要持续升级。Fedora 大约每六个月发布一个新版本。每个版本会一直获得支持，直到其后第 2 个版本发布约 4 周后，累计可获得约 13 个月的更新。超过该日期后，该版本将不再获得任何安全修复。服务器仍可继续运行，但其中的软件包将不再有人提供补丁。
具体日期如下。截至 2026 年 8 月，受支持的版本是 Fedora 43 和 Fedora 44。Fedora 44 于 2026 年 4 月 28 日发布，计划于 2027 年 6 月结束生命周期。Fedora 42 于 2025 年 4 月发布，并于 2026 年 5 月结束生命周期，也就是 Fedora 44 发布 4 周后。因此，从 Fedora 42 镜像创建的服务器在 13 个月后便失去支持，期间并没有任何操作出错。
Fedora 与 LTS 的对比（单位：月）
LTS 表示长期支持，即供应商连续多年提供补丁，而不是仅维护几个月的版本。EOL 表示生命周期结束，即停止提供补丁的日期。下面列出各项目针对当前可安装版本公布的信息。
The data behind this chart
[
{
"distro": "Fedora 44",
"support_window": 13,
"upgrades_per_decade": 10
},
{
"distro": "Ubuntu 26.04 LTS",
"support_window": 60,
"upgrades_per_decade": 2
},
{
"distro": "Debian 13 stable",
"support_window": 36,
"upgrades_per_decade": 3
},
{
"distro": "AlmaLinux 10",
"support_window": 120,
"upgrades_per_decade": 1
}
]Fedora 每个版本提供 13 个月的支持。Ubuntu LTS 提供 60 个月，AlmaLinux 这类企业级重构发行版提供 120 个月。第二列表示需要承担的升级成本。按十年计算，Fedora 大约需要进行 10 次完整操作系统升级，而 Ubuntu LTS 需要 2 次。Debian 的 36 个月是常规安全支持期限，另外还有独立的 LTS 团队将大多数版本的支持期限延长到约五年。
这些是截至 2026 年 8 月核实的官方支持期限，不是实测运行时间。有关不同发布节奏的原因，请参阅Ubuntu LTS 与服务器上的临时版本有何区别。这里需要关注的是每种方案会为您带来多少维护工作。
Fedora 版本升级实际涉及的内容
Fedora 41 起，DNF 5 是默认的软件包管理器，dnf 会调用它。system-upgrade 命令属于 dnf5 本身，因此无需先安装插件。如果您从 Debian 或 Ubuntu 服务器迁移过来，日常输入的大多数命令都有直接对应的 apt 到 dnf 写法，而下面介绍的版本升级是少数没有真正对应操作的任务之一。请从已完全更新补丁的当前版本开始：
sudo dnf upgrade --refresh
sudo reboot重启很重要，因为升级会根据已安装且正在运行的内容解析依赖。如果内核或 glibc 更新只完成了一半，下一步就更难判断问题。现在暂存新版本。将 44 替换为您要升级到的版本：
sudo dnf system-upgrade download --releasever=44此命令会解析完整事务并下载所有软件包，但不会修改正在运行的系统。小型服务器通常需要下载几千个软件包，总量为一到三 GB。如果 dnf 无法解析事务，它会在此处停止，并指出阻止解析的软件包。这是理想情况，因为故障发生时机器仍在运行，您仍然可以使用 shell。
然后执行升级：
sudo dnf offline status
sudo dnf system-upgrade rebootdnf offline status 表示事务已暂存并等待执行。dnf system-upgrade reboot 会将机器重启到离线事务环境：系统以最小化启动方式运行 RPM 事务。这样设计是因为在运行中的服务下替换 glibc 和 systemd，容易导致系统处于半安装状态。整个事务期间服务器都无法访问。小型 VPS 通常需要几分钟，随后系统会再次重启并进入新版本。请预留两次重启的时间，并预计 SSH 会有一段时间无法连接。
系统恢复后：
cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras/etc/fedora-release 应输出类似 Fedora release 44 (Forty Four) 的行。log 子命令会输出本次离线启动中的事务日志。这是您没有 shell 时发生的操作的唯一记录。distro-sync 会将遗留内容更新到新版本对应的版本。repoquery --extras 会列出不再存在于任何已启用仓库中的已安装软件包。您可以在这里找到那些从未为新版本发布软件包的仓库留下的内容。
在下载步骤之前创建磁盘快照。事务在您无法查看屏幕时运行。如果离线启动期间失败，SSH 不会恢复，您只能通过服务商提供的控制台、VNC 或串行控制台访问服务器。请在开始前确认您有控制台或快照，不要等到失败后才确认。
还有一项经常被跳过的检查：
sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'当软件包发布新的默认配置文件，而您修改过旧文件时，RPM 不会覆盖您的文件。它会将软件包提供的版本另存为 .rpmnew。因此，您的 sshd 或 nginx 会继续完全按照旧版本的配置运行，而新的默认配置则未被使用地留在磁盘上。每次升级后都要查看这些文件。安装 rpmconf 并运行 sudo rpmconf -a，即可逐个查看这些文件及其差异。
第三方软件源会导致升级失败
Fedora 自带的软件包会在发行日统一更新。Fedora 之外的软件包则由各自的软件供应商按不同时间表发布。大多数供应商软件源会在 URL 中包含 $releasever，因此升级后，dnf 会立即请求一个可能尚不存在的路径。
列出当前配置的软件源：
sudo dnf repo list --enabled
grep -R -e baseurl -e metalink /etc/yum.repos.d/对于每个非 Fedora 官方软件源，在确认升级前，先针对目标发行版进行测试：
sudo dnf --releasever=44 --repo=docker-ce-stable makecache如果供应商已经为该发行版发布了软件包，dnf 会下载元数据，然后静默退出。如果尚未发布，您会收到类似 https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml 路径的 404 错误，稍后执行 system-upgrade download 时也会因同样的问题失败。Fedora 发布后的最初几周内，这是升级无法开始的最常见原因。
有两种处理方式。等待几周，直到供应商发布对应版本的软件包，通常应优先采用这种方式。或者在不使用该软件源的情况下升级：
sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stable禁用软件源不会删除其中的软件包。这些软件包仍会保留在系统中，但不再受软件源管理；如果它们阻止事务执行，dnf 会明确提示。添加 --allowerasing 后，dnf 可以删除已安装的软件包来解决冲突，因此在确认前请先查看删除列表。很多人就是在这里误删了原本打算保留的数据库服务器。
错过支持窗口的 Fedora 服务器会发生什么
当天不会发生任何事情。下次操作软件包管理器时，故障才会出现。生命周期结束的版本会从镜像网络移入归档，因此 dnf upgrade 在获取元数据时失败，并针对当前版本的 metalink URL 返回 404：
Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64服务器仍会继续提供网络流量，这正是问题隐蔽且危险的原因。它不会再收到安全更新，也无法安装任何软件。因此，当 OpenSSH 或 nginx 发布安全公告时，您没有受支持的方式为其打补丁。
仍然可以恢复，但过程缓慢。您可以将软件源指向 Fedora 的归档地址 https://dl.fedoraproject.org/pub/archive/fedora/linux/，然后从那里升级。Fedora 要求每次跨越一个或两个版本，因此落后4个版本的服务器需要连续执行多次升级。每次升级都有失败的可能，而且每次离线启动时都无法获取支持。在 VPS 上，使用当前镜像重建服务器，再迁移数据，通常更快也更安全；这与新 VPS 上的前十分钟需要完成的工作相同。
自动更新会为当前发行版安装补丁，但不会升级发行版版本。
Fedora 可以按定时器安装更新：
sudo dnf install -y dnf5-plugin-automatic
sudo systemctl enable --now dnf5-automatic.timer设置位于 /etc/dnf/automatic.conf，它会覆盖 /usr/share/dnf5/dnf5-plugins/automatic.conf 中随软件提供的默认值。apply_updates 默认关闭，因此开箱即用时，定时器只会下载更新，不会安装任何内容。upgrade_type 用于在 default 和 security 之间进行选择。reboot 接受 never、when-changed 或 when-needed。
这样可以让系统始终保持在当前发行版版本内。它不会将 Fedora 43 升级到 Fedora 44，因为版本升级是一个单独且需要明确执行的操作，系统会重启并进入离线事务。这就是它与 LTS 的实际差距。在 Ubuntu 上，无人值守安全升级 可以让系统在整个五年支持周期内持续获得更新，同时完全不更改版本；版本升级本身则是计划任务，例如每隔几年执行一次 从 24.04 升级到 26.04。
Fedora 适合作为服务器的场景
如果重点是使用新版本，Fedora 是不错的选择。
- 您需要比任何 LTS 版本都更新的内核或用户空间：例如支持最新硬件，或使用仍需一年左右才会进入企业版的容器和 systemd 技术栈。Fedora 还会在一个发行版生命周期内持续采用新的上游内核，因此它的优势不只体现在安装时。
- 您正在验证即将进入 RHEL（Red Hat Enterprise Linux）的内容。Fedora 为 CentOS Stream 提供基础，而 CentOS Stream 又为 RHEL 提供基础。因此，现在能在 Fedora 上构建和运行的软件，实际上正在针对未来几年后的企业平台进行测试。
- 该机器从设计上就是短期使用的。运行两个月后即销毁的构建运行器或测试机，不会等到生命周期结束日期。这个逻辑同样适用于交给编码代理的一次性 VM，因为这类机器的重建频率远高于 Fedora 的发行频率。
- 有明确的负责人负责升级。对于有指定负责人并已安排升级日期的服务器，Fedora 是合适的选择。对于所有人都已遗忘的服务器，Fedora 并不合适。
稳定基础上的新版本软件
大多数希望在服务器上使用 Fedora 的人，需要的是两三个新版本软件，而不是整个操作系统都保持最新。这两者可以分开处理。以 LTS 版本或企业重建版作为基础系统，然后只在实际需要的地方引入新软件。容器镜像可以在无需为此升级主机的情况下，提供新版本的应用（在 VPS 上运行 Docker）。如果只关心 PostgreSQL 或 nginx 等某个软件，也可以使用该软件的供应商仓库，仅升级这一个软件而保持基础系统不变。
这种取舍的两面都很明确。容器在主机的旧内核上提供新的用户空间，因此如果需要更新的是内核，容器无法解决问题。供应商仓库会在基础系统上提供一个新版本软件，但该基础系统经过供应商测试的程度较低。两种方式都让基础系统继续按照 LTS 的周期接收安全更新，而在 Fedora 中，每年都需要维护窗口的正是这个周期。
如果确实选择 Fedora 作为服务器系统，请将升级周期安排到日历中。新版本发布后，等待几周让供应商仓库完成同步，然后创建快照并升级，最后确认各项服务已恢复运行。这样的维护节奏每年大约需要 1 小时，而且可以正常工作。真正容易出问题的情况，是只有在系统已经发生故障后，才想起原本应该进行升级。
FAQ
Fedora 版本支持多长时间？
大约 13 个月。Fedora 大约每 6 个月发布一个版本，每个版本通常支持到后续第 2 个版本发布约 4 周后。Fedora 44 于 28 April 2026 发布，计划于 June 2027 结束生命周期。到期后，该版本将停止接收安全更新，其软件包也会从镜像站移至 Fedora 的归档库。
我可以跳过一个 Fedora 版本，一次升级 2 个版本吗？
可以，但有一定限制。dnf system-upgrade download --releasever= 接受领先当前版本 1 个或 2 个版本的目标版本；每年升级一次时，一次跨越 2 个版本正是对应的升级方式。跨越更多版本不属于受支持路径，而且每多跨越一个版本，软件包重命名或配置格式变更导致事务失败的可能性都会增加。如果机器已经落后多个版本且已结束生命周期，通常直接使用当前镜像重建，比连续升级更快。
Fedora 服务器结束生命周期后会发生什么？
服务器会继续运行，但不再接收补丁。下一次运行 dnf upgrade 时，会因该版本已结束生命周期并被移至 dl.fedoraproject.org 归档库，而在其 metalink URL 上返回 404。您可以将软件仓库文件重新指向该归档库，然后逐步升级；也可以使用受支持的版本重建服务器。在完成其中一种操作前，服务器无法接收安全更新，也无法安装任何软件包。
Fedora 不适合用作生产服务器吗？
将 Fedora 作为默认选择并不理想，但在有明确原因时可以使用。其代价是每年都要对操作系统进行完整升级，并且服务器可能需要长期持续运行而不希望频繁变更。需要使用比 LTS 发布版本更新的内核或用户空间，或者服务器本身设计为短期运行时，可以选择 Fedora。如果希望多年为服务器安装补丁而不更改版本，应选择 LTS 或企业版重构发行版。