SSD Nodes Learn Hosting plans →
指南 Matt Connor作者: Matt Connor · 更新于 2026-08-23

Ubuntu服务器选LTS还是临时版本?支持周期与升级成本

Ubuntu interim release仅获9个月安全更新,之后必须升级;LTS提供5年标准维护。本文比较服务器上的升级次数、重装风险与实际成本。

Ubuntu LTS 与 interim release:简要结论

在服务器上选择 Ubuntu LTS 还是 interim release,关键取决于一个数字:该版本会持续获得多长时间的安全更新。LTS 提供 5 年的标准安全维护。interim release 提供 9 个月的安全维护,之后更新停止,因此您必须升级或重装。凡是其他用户或系统依赖的服务器,都应运行 LTS。只有在可以随时重装、无需征得任何人同意的环境中,才应运行 interim release。

LTS 表示长期支持。Canonical 每两年发布一个 LTS,时间为偶数年的 4 月;在两个 LTS 之间,每 6 个月发布一个 interim release。26.04 LTS 于 2026 年 4 月 23 日发布,其标准安全维护将持续到 2031 年。26.10 计划于 2026 年 10 月 15 日发布,它属于 interim release,因此其支持周期将在 2027 年 7 月结束。

每个 Ubuntu 版本的支持期限

ChartSupport length and release upgrades needed over five years
The data behind this chart
[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

这些是 Canonical 截至 2026 年 8 月公布的政策数据,不是测试服务器的测量结果。LTS 版本提供 60 个月的标准安全维护期,按此计算,5 年内需要进行 1 次计划内版本升级。临时版本提供 9 个月的支持。在同样的 5 年期间持续使用临时版本,需要进行 10 次版本升级,因为不能跳过版本,而 5 年内会发布 10 个临时版本。

Ubuntu Pro 订阅会将 LTS 的支持期限延长至 120 个月,即 10 年,并将覆盖范围从 main 组件扩展到整个软件仓库。截至 2026 年 8 月,个人用户最多可在 5 台计算机上免费使用 Pro,这已覆盖大多数小型 VPS 集群。临时版本没有对应的方案。其支持期限就是 9 个月,任何订阅都不能延长该期限。

真实服务器上的 9 个月成本

以 26.10 为例。该版本于 15 October 2026 发布,安全维护于 July 2027 结束;这与 25.10 于 July 2026 结束时遵循的 9 个月模式相同。按日历计算,这看起来像是每三个季度才需要一次维护。这个判断是错误的,而且会导致更高的成本。

逐步计算截止日期链

在 October 2026 安装 26.10,并等到最后一个安全时刻。您会在 June 2027、26.10 即将结束前升级到 27.04。但 27.04 已于 April 2027 发布,其自身的 9 个月支持周期会在 January 2028 结束。您的第二个截止日期会在第一个截止日期后 7 个月到来,而不是 9 个月。

随后在 December 2027 升级到 27.10。该版本于 October 2027 发布,并会在 July 2028 结束支持。从此以后,模式就固定了。您始终落后于当前版本一个发布周期,因此大约每 6 个月就会遇到一次截止日期。9 个月是单个版本的支持时长,不是您的维护窗口之间的间隔。

版本升级会直接替换当前系统中的操作系统。do-release-upgrade 会重写 apt 源,禁用第三方仓库,更改几乎所有已安装软件包的版本,暂停下来询问您如何处理已编辑的配置文件,并在最后重启系统。因此,升级需要安排维护窗口,不能作为后台任务运行。

通过 ssh 执行升级时,该工具会防止连接中断导致升级失败。它会启动自己的 screen 会话,并打开第二个 sshd,且会先告知您:

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running ssh
you can still connect to the additional one.

请保留该设置。如果您的防火墙或服务提供商独立的网络防火墙阻止 1022 端口,这个备用连接就无法使用;连接中断后,系统会留下只完成部分升级的软件包集合。您也可以自行在 tmux 或 screen 中运行升级,这样任何服务器都能获得相同的保护。

配置文件提示会把原本 15 分钟的升级变成 1 小时:

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?

保留您的文件,意味着您会错过新默认配置中的更改。使用维护者提供的文件,意味着您之前的加固配置会消失,直到您重新应用。不了解该版本具体更改内容时,两个选择都不安全。因此,阅读发行说明是维护窗口的一部分,而不是可选的准备工作。

然后再乘以服务器数量。在 5 年内,一台使用中期版本的 VPS 需要进行 10 次升级。5 台 VPS 就是 50 次,除非每台服务器都可以丢弃并从镜像重新构建。在相同期间,5 台使用 LTS 版本的服务器只需升级 5 次,而且您可以自行选择每次升级发生的月份。

为什么不能跳过 Ubuntu 版本

升级路径是固定的。临时版本只能升级到下一个版本。LTS 可以直接升级到下一个 LTS,也可以在明确指定时升级到下一个临时版本。任何版本都不能一次跨越两个版本。从 26.10 升级到 28.04 LTS,必须依次经过 27.04 和 27.10,或者重新安装系统。

了解其工作机制很重要,因为这说明该规则不会变通。do-release-upgrade 会从 changelogs.ubuntu.com 获取 meta-release 文件,然后下载一个针对某个特定升级路径构建的升级工具。Canonical 一次只构建和测试一条升级路径,因此跳过某个版本的升级既没有对应工具,也没有经过测试。升级程序不是出于谨慎而拒绝升级,而是没有可供它执行的升级路径。

系统提供哪个版本,取决于配置中的一行:

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts 只提供下一个 LTS。Prompt=normal 提供下一个版本,无论它是否为 LTS。Prompt=never 不提供任何版本。这样可以防止同事擅自启动您未计划的升级。在非 LTS 版本上,lts 与 normal 的行为完全相同,因为无论采用哪种设置,26.10 的下一个版本都是 27.04。检查会输出 Checking for a new Ubuntu release,然后输出 New release ... available. 行或 No new release found.

还有一条计划规则容易被忽略。新的 LTS 发布当天,并不会立即提供从一个 LTS 升级到下一个 LTS。该升级会在第一个点版本发布后开放,而 26.04.1 计划于 27 August 2026 发布。点版本不是 Ubuntu 的新版本,而是在相同版本的安装介质中整合了累计四个月修复的版本。设置等待期,是为了让升级路径先经过这四个月的测试,然后再向用户提供。某台运行 24.04 的系统在 2026 年夏季配置了 Prompt=lts,并对 No new release found. 作出响应,并不表示系统出现故障,而是遵循了既定策略。升级路径开放后,从 24.04 升级到 26.04 LTS就是需要规划和演练的操作。

何时应选择中间版本

以下4种情况下,中间版本确实更合适:

  • 您现在就需要 LTS 软件源中没有提供的内核或用户空间版本。
  • 这台机器是构建主机、CI runner 或测试机,您会根据镜像重新构建它,因此升级实际上是创建新实例,而不是安排维护窗口。
  • 某项硬件或 hypervisor 功能在 LTS 冻结后才加入,且没有可用的 backport。
  • 您正在确认下一个 LTS 将包含哪些内容。28.04 基于 26.10、27.04 和 27.10 构建,在备用 VPS 上发现破坏性变更,比在重要服务器上发现更省成本。

大多数选择中间版本的人,只是需要更新的某个软件包,而不是更新整个发行版。还有两种成本更低的方案。硬件启用栈会将后续版本中的内核引入 LTS:在 24.04 中,这一版本是 sudo apt install linux-generic-hwe-24.04;从第2个 point release 开始,它会在每个 point release 中继续前进。对于单个应用,使用容器镜像或软件供应商自己的软件源,可以只更新一个组件,而不必更新整个操作系统。

不应选择中期版本的情况

  • 任何有付费用户或需要值班轮换的系统。您将每年接受两次强制升级,却可能永远用不到这些软件包版本。
  • 任何由 unattended-upgrades 代您执行安全补丁安装 的主机。自动化的效果取决于它所使用的 security pocket。
  • 任何需要手动升级的服务器集群,因为实际成本是一次维护窗口乘以服务器数量。
  • 任何安装后一年都不会查看的系统。被遗忘的中期版本,9 个月后就会变成未打补丁的公网服务器。

最后一种故障不会发出明显信号,因此尤其危险。版本达到生命周期终点后,其软件包会移至 old-releases.ubuntu.com,因此 sudo apt update 访问 archive.ubuntu.com 时会因 404 错误而失败。磁盘上的软件包列表会逐渐过期。unattended-upgrades 仍按定时器运行,并持续将类似下面的内容写入 /var/log/unattended-upgrades/unattended-upgrades.log:

No packages found that can be upgraded unattended and no pending auto-removals

在完全打好补丁的服务器上,以及在版本已于 4 个月前停止支持的服务器上,这一行看起来完全相同。除非有人查看 apt 错误或跟踪生命周期终止日期,否则主机上的任何信息都无法告诉您当前面对的是哪一种情况。

首先进入中期版本的变更类型

2026 年 3 月,一名 Canonical 工程师在 Ubuntu discourse 上提议,从 26.10 中移除为安全启动提供的已签名 GRUB 引导加载程序。该提议会移除 btrfs、hfsplus、xfs 和 zfs 的文件系统驱动,JPEG 和 PNG 图像解析器,Apple 分区表,LVM 上的 /boot,RAID 1 以外的软件 RAID,以及加密的 LUKS /boot。给出的理由是,引导加载程序中的解析器反复成为安全漏洞的来源,而存储和加密逻辑应放在 initramfs 中。initramfs 是内核在挂载真正的 root 文件系统之前挂载的小型初始 RAM 文件系统。截至 2026 年 8 月,这仍是正在讨论的提议,并非已经发布的变更。

对大多数 VPS 实例来说,这不会带来任何变化,因为它们通常不使用安全启动,而是从 GPT 分区表上的普通 ext4 /boot 启动。请检查自己的配置,不要想当然。如果 root 使用 ZFS,或者 /boot 位于 btrfs 上或 LUKS 内部,那么这正是会首先在中期版本中影响你的变更类型。该讨论串对受影响用户的建议是改用 LTS。这一建议用一句话概括了全部原因:中期版本用于尝试变更;LTS 则是在连续两年的中期版本发现这些变更会破坏什么之后,再接收这些变更。

每个中期版本还会以更小的方式重复这种模式。数据库、语言运行时和 init 配置的默认版本会向前推进,因此原本可用的配置文件可能停止工作。推进默认版本正是中期版本存在的目的,这意味着在每次十次升级之前阅读发行说明,是你需要为此付出的代价。

构建服务器时选择版本轨道

在安装时选择版本轨道。之后再更改,通常需要重新安装或连续升级。在新服务器上,运行以下四个命令即可确认当前状态:

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

lsb_release -a 应显示你计划安装的发行版版本;如果是 LTS 版本,描述行应以 LTS 结尾。Prompt 行应与所选版本轨道一致,而不是跟随提供商镜像实际附带的轨道。当前 LTS 上,do-release-upgrade -c 应返回 No new release found.。如果它提供的是临时版本,则 Prompt 被设置为 normal,需要确认这是否是有意选择的。pro security-status 会报告已安装软件包分别由哪些更新流覆盖,并在服务器未关联订阅时明确说明。

然后将生命周期结束日期记录在之后还能再次看到的位置,并与该服务器的其他构建记录放在一起。这属于 新 VPS 上前十分钟内完成的工作,因为只存在于某个人记忆中的支持日期最容易在无人注意时到期。如果你完全想摆脱每六个月一次的版本更替,那么在决定让整个服务器群采用哪种系统前,值得花一小时阅读 FreeBSD 与 Linux 的版本发布模型对比。

FAQ

我应该在生产服务器上运行 Ubuntu 的中间版本吗?

几乎所有情况下都不应该。中间版本在发布 9 个月后停止接收安全更新,因此在该版本轨道上运行生产环境,意味着大约每年两次必须升级,而且会一直如此。确实存在例外,例如 CI runner 和构建主机。这些机器本来就会从镜像重建,升级相当于创建新实例,而不是安排维护窗口。如果服务器承载真实用户的业务,请安装 LTS,并将节省下来的维护窗口用于其他工作。

Ubuntu 中间版本支持多长时间?

9 个月。26.10 于 15 October 2026 发布,其安全维护将于 July 2027 结束;25.10 也遵循相同周期,并于 July 2026 结束支持。每个中间版本都遵循这一周期:在 April 或 October 发布,9 个月后结束支持。LTS 提供 5 年标准安全维护;使用 Ubuntu Pro 后可延长至 10 年。截至 August 2026,个人用户可在最多 5 台机器上免费使用 Ubuntu Pro。

升级 Ubuntu 时可以跳过版本吗?

不可以。do-release-upgrade 每次只能前进一个版本:中间版本升级到下一个版本,LTS 则可以直接升级到下一个 LTS。从 26.10 升级到 28.04 LTS,需要先依次通过 27.04 和 27.10,或者重新安装系统。Canonical 会逐次构建和测试版本转换,升级程序也会下载针对该次跳转的工具。因此,两步跳转没有对应的工具,系统不会提供这种升级路径。

Ubuntu 版本结束生命周期后会发生什么?

其软件包会移至 old-releases.ubuntu.com,因此 sudo apt update 针对 archive.ubuntu.com 的请求会因 404 错误开始失败,该版本也不会再发布任何新的安全更新。系统不会主动提示这一点。服务器会继续运行并继续提供网络流量服务,但其中新发现的每个漏洞都会一直处于暴露状态。恢复方式是在时间压力下执行版本升级,或重新构建系统。因此应关注日期,而不是等出现症状后再处理。

LTS 内核对于新硬件来说太旧了吗?

通常不是,因为 LTS 不会在 5 年内始终使用最初的内核。硬件启用堆栈(HWE)会在点版本中将后续版本的内核引入 LTS,服务器安装也可以通过类似 linux-generic-hwe-24.04 的软件包选择启用该功能。在认定内核是阻碍因素前,请使用 uname -r 检查当前运行的内核。如果缺少的是 userspace 版本而不是内核,使用容器或供应商软件仓库通常比将整台机器切换到中间版本轨道改动更小。