服务器应选 Debian stable、testing 还是 unstable？

Debian stable、testing 还是 unstable：租用服务器的简短结论

对于租用服务器，应在 Debian stable、testing 和 unstable 之间如何选择，几乎所有人的答案都是：使用 stable。只有 stable 有专门团队按照已公布的计划修复安全问题。testing 和 unstable 是构建下一版本的机制，二者都不会提供可据此规划服务器的承诺。

本页其余内容将解释这一结论背后的机制，帮助您自行判断何时不再适用。下文中的所有日期、套件名称和支持期限均已于 17 August 2026 对照 Debian 官方页面核实。

这些套件属于同一条流水线，而不是4个产品

软件包只会进入 Debian 一次：先进入 unstable，然后从这里继续向前流转。这4个名称表示流水线中的阶段，而不是供您选择的4个版本。

• unstable 始终称为 sid。维护者会在这里上传新版本。Debian FAQ 的说法很明确：sid“永远不会直接发布，因为要发布的软件包必须先纳入 testing”。
• testing 是下一版发行版的候选队列。软件包通过一组自动检查后，会自行从 unstable 进入 testing。当前的 testing 是 forky，它将成为 Debian 14。
• stable 是冻结并发布时的 testing，之后保持不变。当前的 stable 是 Debian 13 trixie，于 2025 年 8 月 9 日发布，并自 2026 年 7 月 11 日起为版本 13.6。
• oldstable 是再前一个发行版，仍会获得补丁，但不再是默认版本。当前的 oldstable 是 Debian 12 bookworm，于 2023 年 6 月 10 日发布。

另外还有2个套件位于这条流水线旁边，而不是其中。trixie-backports包含 testing 中选定的软件包，并重新构建为可在 stable 上运行。experimental包含即使对 sid 来说也过于激进的上传内容。这两个套件都不是用于运行完整系统的套件。

套件之间的流转方向比名称更重要。stable 中不会进行开发。修复之所以进入 stable，是因为维护者先在 unstable 中完成了修复，然后有人为 stable 所采用的旧版冻结代码准备了同一个修复。Debian 的套件也是 Ubuntu 各版本的上游来源；为什么 Debian 和 Ubuntu 分成两个发行版介绍了这种关系，但那是另一个问题。

软件包如何从 unstable 进入 testing

迁移过程是自动的，并由规则驱动。Debian Wiki 列出了软件包必须满足的条件：它已在 unstable 中“至少停留 2-10 天（具体取决于上传的紧急程度）”；已在每个发行版架构上成功构建；没有新增 release-critical bug；安装该软件包不会破坏发行版的其他部分。只要有一个条件不满足，软件包就会继续留在 unstable 中。

等待时间只是较小的部分，transition 才是主要因素。当一个库更改 soname（其他程序进行链接时使用的带版本名称）时，所有基于旧版本构建的软件包都必须针对新版本重新构建。整个软件包组随后必须一起迁移，因为只允许其中一部分进入 testing 会破坏软件包归档。只要该组中有一个软件包在某个架构上构建失败，整个软件包组就会被留在 unstable 中。这就是 Debian 的安全 FAQ 所说修复“可能因 transition 而延迟”的含义，也解释了为什么已修复的软件包可能在 unstable 中停留数周，而 testing 仍然提供存在漏洞的版本。

每个套件的安全支持承诺

这项承诺很明确，只针对 stable。Debian 安全 FAQ 的表述很直接：“安全团队将在 stable 发行版发布后提供三年支持。”之后，由独立的 LTS（长期支持）项目接手，通常再提供约两年支持。

[
  {
    "label": "Debian 11 bullseye",
    "security_team_months": 36,
    "with_lts_months": 60
  },
  {
    "label": "Debian 12 bookworm",
    "security_team_months": 37,
    "with_lts_months": 60
  },
  {
    "label": "Debian 13 trixie",
    "security_team_months": 36,
    "with_lts_months": 58
  }
]

这些月数从各版本的发布日期开始计算，直到生命周期结束和 LTS 日期。数据来自 Debian releases 页面和 LTS wiki 页面，读取日期为 17 August 2026。Debian Security Team 从当前 stable 的发布日期起提供 36 个月支持，LTS 将总支持期延长至 58 个月。对于 trixie，这些日期分别是 9 August 2028 和 30 June 2030。Bookworm 已经越过第一条界线：其安全团队支持已于 11 July 2026 结束，LTS 目前将支持延长至 30 June 2028。

LTS 确实是延续支持，但它与原有支持并不相同。LTS 由志愿者和企业共同维护，“不由 Debian Security 和 Release 团队处理”；其安全公告使用 DLA，而不是 DSA；覆盖的架构也少于原发行版。应按三年支持期规划，并将额外两年视为安排升级的时间，而不是可以忽略升级的时间。

对于另外两个套件，FAQ 没有做出类似承诺。关于 unstable：“unstable 的安全支持主要由软件包维护者负责，而不是由 Debian Security Team 负责。”关于 testing：“testing 的安全性受益于整个项目针对 unstable 开展的安全工作。但是，迁移至少会延迟两天，有时安全修复还会因过渡而延后。”同一页面最后给出了明确建议：“如果您希望服务器安全且稳定，强烈建议继续使用 stable。”

为什么 freeze 期间 testing 对服务器最不可靠

Debian 官方 wiki 的说法比任何外部对比都直接：“与 stable 和 unstable 相比，next-stable testing 的安全更新速度最慢。如果安全性很重要，不要优先选择 testing。”

跟踪软件包的流转后，这个结论就不再反直觉。维护者会先将修复版本上传到 unstable，因此 unstable 最先获得更新。Stable 会获得单独构建的修复版本；该版本基于已冻结版本准备，并附带 DSA 推送到 security.debian.org。Testing 只有在正常迁移规则允许后才能获得更新。这意味着最快也要延迟 2 到 10 天；如果软件包被某个过渡阻塞，等待时间还可能没有上限。安全团队会为 stable 提前准备构建版本，但不会以同样的方式为 testing 准备。Testing 的更新速度因此落后于 unstable，同时支持程度又落后于 stable。

Freeze 会改变这一点。这也是为什么那些在接近发布时使用过 testing 的人通常对它评价很好。在 soft freeze 阶段，release team 的 freeze policy 会将所有软件包的迁移延迟提高到 10 天；进入 full freeze 后，除非经过人工审核，否则会完全阻止迁移。在这几个月中，testing 的质量确实接近发布版本。

截至 17 August 2026，release team 的 freeze policy 页面仍将 forky 的全部 4 个 freeze 里程碑列为 TBA；full freeze 日期只承诺会在生效前“至少 14 天”公布，Debian 14 也尚未确定发布日期。如今运行 forky 的系统处于这个周期中范围最大、限制最少的阶段。Security archive 确实包含一个 forky-security suite，就像其中包含 testing-security 一样，但目录存在并不代表有所承诺。FAQ 中的那句话才是承诺。

稳定版服务器如何接收安全修复

稳定版通过独立的软件源接收安全修复，您的计算机必须读取该软件源。在 trixie 上，软件源以 deb822 格式存放在 /etc/apt/sources.list.d/debian.sources 中，发行说明给出的配置结构如下：

Types: deb
URIs: https://deb.debian.org/debian
Suites: trixie trixie-updates
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: https://security.debian.org/debian-security
Suites: trixie-security
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

请检查 apt 实际加载的内容，而不是您认为自己写入的内容：

sudo apt update
apt policy
apt list --upgradable

apt policy 会列出 apt 已知的每个软件包文件，以及其来源和优先级。如果没有任何行提到 trixie-security，您的服务器就不会接收安全更新，也不会有任何提示告知您这一点。如果 apt 报告某个软件源被重复配置，说明同一个套件同时列在旧的 sources.list 和新的 .sources 文件中。这就是 deb822 迁移后出现的 重复软件源错误。

trixie-updates 套件是另一个渠道，作用也不同。Debian 将其描述为“许多用户希望在下一个点版本发布前安装到系统中的更新，例如病毒扫描器和时区数据的更新，或用于解决非安全性质的紧急问题”。请保留它。不要修改 trixie-proposed-updates：它是组装下一个点版本的暂存区域，发行说明要求您在进行重大升级前将其删除。

稳定版的代价，以及 Backports 带来的补偿

稳定版的代价是版本较旧。软件包版本在冻结时确定，之后多年保持不变，只将修复反向移植到这些版本中。这正是系统易于维护的原因。但对于一两个需要上个月才发布的新功能的软件包来说，这确实是个问题。

Backports 可以解决这种情况，而不会影响系统的其他部分。添加一个文件，例如 /etc/apt/sources.list.d/backports.sources：

Types: deb deb-src
URIs: http://deb.debian.org/debian
Suites: trixie-backports
Components: main
Enabled: yes
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

然后按名称请求软件包。这是从该源获取软件包的唯一方式：

sudo apt update
sudo apt install -t trixie-backports PACKAGE
sudo apt install PACKAGE/trixie-backports

两种形式都可以使用。-t 形式还允许 apt 从 Backports 获取该软件包缺少的依赖项。因此，当普通形式因依赖项问题失败时，应使用这种形式。

了解启用 Backports 后为什么不会自动产生任何变化很重要，因为之后配置软件包固定时也会使用同一套机制。trixie-backports Release 文件包含 NotAutomatic: yes 和 ButAutomaticUpgrades: yes。根据 apt_preferences 手册，这些设置会使其中的每个版本获得 100 的优先级，而普通的非目标套件通常获得 500。100 与 apt 为当前已安装版本分配的优先级相同，因此 apt 不会自行切换到 Backports 中的版本。安装其中一个版本后，这些标志仍会使 apt 在 Backports 中持续升级该版本。

Debian 也明确说明了一个限制。Backports“无法像 Debian stable 那样经过充分测试，因此仅按尽力而为的方式提供支持”，并且“可能与 Debian stable 中的其他组件不兼容”。这意味着：Backports 中的软件包可能落后于 stable 在同一天获得的安全修复。

从 testing 固定软件包，以及为什么这是最后手段

如果 backports 中没有所需的软件包，可以添加 forky 软件源，并将其优先级设为较低值。除非明确请求，否则不会从该源安装软件包。将以下内容写入 /etc/apt/preferences.d/99-forky：

Package: *
Pin: release n=forky
Pin-Priority: 100

n= 与代号匹配。通用 pin 会将所有 forky 软件包的优先级设为 100。手册明确说明，命令行中指定的目标版本“优先于你在 /etc/apt/preferences 文件中设置的任何通用优先级”。因此，在确实需要时，sudo apt install -t forky <package> 仍然有效。

接下来是问题所在。大多数复杂软件包都依赖 glibc。为 forky 构建的软件包需要的 glibc 版本高于 trixie's 版本；截至 17 August 2026，该版本是 2.41-12+deb13u3。因此，apt 会出现以下两种结果之一，而两种结果都不好。它可能拒绝执行：

The following packages have unmet dependencies:
 <package> : Depends: libc6 (>= <version newer than trixie has>) but 2.41-12+deb13u3 is to be installed
E: Unable to correct problems, you have held broken packages.

也可能同意执行，但这更糟糕，因为升级 libc6 会连带从 testing 拉取大量基础系统软件包。此时，这台服务器既不是 stable，也不是 testing。未设置 pin 的部分使用 stable 中更新缓慢的软件包版本；设置了 pin 的部分则面临 testing 较弱的安全维护，而且没有任何经过测试的升级路径。apt 手册用一句话说明了风险：“特定发行版中包含的软件包并未在较旧或较新的发行版中进行测试，因此不一定能按预期工作；它们也未与其他发行版中的软件包一起进行测试。后果由你自行承担。”

因此，请按以下顺序逐项尝试，并在第一个可行方案处停止。先尝试 backports。然后尝试上游项目自己的 Debian 软件源，前提是该项目提供了为 trixie 构建的软件源。也可以将这一个服务放入容器中运行，让它自行管理所需的库。只有在其他三个方案确实不可用时，才从 testing 固定软件包；在确认采用前，使用 apt policy <package> 检查结果。

点版本、oldstable 以及何时迁移

点版本是汇总版本，不是新版本。Trixie 已从 2025 年 8 月 9 日的 13.0 更新到 2026 年 7 月 11 日的 13.6，平均约每两个月发布一个。无需追逐点版本，也无需重新安装。已经持续应用安全更新的服务器通常已包含大部分内容；sudo apt update && sudo apt full-upgrade 会获取剩余的非安全修复，/etc/debian_version 中的版本号也会自动变化。

主要版本之间的迁移才是需要主动执行的操作。编辑 debian.sources 中的套件名称，运行 apt update，再运行 apt full-upgrade，然后重启，并遵循该版本发行说明中的升级章节。大约每两年执行一次，并在支持结束前保留一年的宽限期，这就是 Debian 服务器的全部维护负担。如果您正在将这种节奏与其他方案比较，Ubuntu 的 LTS 和 interim 版本发布节奏会用不同的数字回答同一个问题，而为 VPS 选择操作系统介绍更广泛的选择。

现在有一个日期需要立即关注。Debian 11 bullseye 的覆盖期限达到 60 个月，其 LTS 将于 2026 年 8 月 31 日结束，距本文撰写时只有两周。此后，它将不再享有免费的安全更新渠道。Extended LTS 确实存在，但请先了解它的性质：这是“一项商业服务”，“由 Freexian 管理”，并且“不是 Debian 官方项目”；预计从 2026 年 9 月起提供 bullseye 覆盖。bullseye 服务器本月就需要制定升级计划，而不是条件反射式地购买订阅。

在不持续监控的情况下维护稳定服务器的补丁

安装更新程序并让它运行。在 Debian 上，默认配置“自动安装安全更新，但不安装新功能”，这正是服务器所需的行为：

sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

配置详情（包括如何查看它在夜间执行的操作）请参阅自动安全更新操作指南。Debian 上使用相同的软件包和配置文件名。

自动更新不会重启任何服务。已修补的内核已写入磁盘，但在重启前，计算机仍会继续运行旧内核。因此，请将 uname -r 与 apt 安装的内核进行比较，并安排重启。如果重启成本较高，请参阅VPS 上的内核实时修补，了解可用方案及其限制。

最后，确认已安装的软件包中哪些未获得完整支持：

sudo apt install debian-security-support
check-support-status

该程序用于“识别支持范围受到限制或提前终止的已安装软件包，并向管理员发出提醒”。trixie 发行说明列出了常见情况。基于 qtwebengine 构建的应用没有安全支持。Go 和 Rust 编写的软件包“在基础设施改进到可以持续维护这些软件包之前，仅提供有限的安全支持”，因为静态链接意味着修复某个库后，必须重新构建嵌入该库的每个二进制文件；而这些重建通常会在小版本发布中提供，而不是作为即时更新提供。如果你实际关注的服务是软件包仓库中的 Go 二进制文件，那么最好在安全公告发布前了解这一点，而不是事后才发现。

租用服务器上应执行的操作

安装 stable。启用 trixie-security 和 trixie-updates，并使用 apt policy 确认两者均已启用，不要想当然。启用 unattended-upgrades。需要更新版本的包，最多从 backports 中选择一两个真正需要的包，并接受这些特定包的保障较弱。将下一次 major upgrade 安排在生命周期结束前一年。对于 trixie，这意味着 2027 年夏季。

如果您希望帮助构建 Debian，可以在故障只会让您损失一个下午的计算机上运行 testing 或 unstable。Sid 适合作为开发工作站，也适合作为测试机。但它不是任何人承诺提供保障的 suite；存放他人数据的租用服务器不适合用来认识这一差异。

FAQ

在服务器上运行 Debian testing 安全吗？

不安全，Debian 自己也明确说明了这一点。Debian Wiki 指出：“与 stable 和 unstable 相比，next-stable testing 的安全更新速度最慢”；安全 FAQ 也建议安全服务器使用 stable。修复后的软件包会先进入 unstable，然后等待 2 到 10 天才能迁移到 testing；如果遇到库过渡，则可能无限期等待。安全团队会为 stable 提前准备构建版本，但不会以同样方式为 testing 准备。testing 只有在冻结期间才接近发布质量。截至 17 August 2026，forky 的冻结日期仍未公布。

Debian stable 版本会获得多长时间的安全更新？

Debian Security Team 从 stable 版本发布之日起提供 3 年支持，其中大约 2 年处于 stable 阶段，之后 1 年处于 oldstable 阶段。随后，LTS 项目会继续支持大约 2 年，但支持的架构更少，安全公告称为 DLA，且维护团队独立于 Debian 的安全团队和发布团队。Debian 13 trixie 于 9 August 2025 发布，其安全团队支持于 9 August 2028 结束，LTS 支持于 30 June 2030 结束。

如何在 Debian stable 上安装某个软件包的较新版本？

优先使用 backports。为 trixie-backports 添加一个 .sources 文件，运行 sudo apt update，然后运行 sudo apt install -t trixie-backports <package>。系统中的其他内容不会发生变化，因为 backports 使用 NotAutomatic: yes 发布；其中所有软件包的 apt 优先级都被固定为 100，因此除非明确指定软件包名称，否则 apt 不会选择它。如果该软件包不在 backports 中，优先使用上游项目自己的 Debian 软件源或容器，不要通过 pinning testing 安装，因为 testing 中的软件包通常会拉取更新版本的 glibc，并带动基础系统的大部分组件一起升级。

13.6 这样的点版本发布是否意味着必须重新安装或升级？

不需要。点版本发布是对已经发布的更新进行汇总，同时包含此前等待发布的非安全修复。已应用安全更新的服务器通常已经包含其中的大部分内容。运行 sudo apt update && sudo apt full-upgrade；如果内核发生变化则重启，/etc/debian_version 中的版本会自动更新。Trixie 在 August 2025 到 July 2026 期间发布了 6 次此类更新，平均约每 2 个月一次。

sid 和 testing 有什么区别？

Sid 是 unstable，是维护者上传每个新版本的入口，并且不会直接发布。Testing 是软件包从 sid 迁移进入的队列。软件包必须先等待 2 到 10 天，完成所有发布架构的构建，且不能新增 release-critical bug，才能迁移到 testing。因此，testing 的故障频率低于 sid。就安全更新而言，顺序正好相反：sid 会先收到修复后的软件包，而 testing 只有在迁移条件满足后才能收到该软件包。