DigitalOcean 预留 IP 指南 2026 — 静态 IP 实现故障转移

预留 IP 是一个静态 IP 地址，DigitalOcean 将其与您的账户关联，而不是与特定的 Droplet 关联。这允许您在主服务器故障时立即将 IP 移动到新的 Droplet，无需等待 DNS 传播。本指南说明如何使用实际的 doctl 和 API 命令预留、连接和迁移预留 IP，以实现故障转移系统。

什么是预留 IP 以及它与常规公开 IP 的区别

在 DigitalOcean 上创建 Droplet 时，系统会自动分配一个公开 IPv4 地址。此 IP 直接绑定到 Droplet 本身。如果您删除该 Droplet，该 IP 会立即返回到 DigitalOcean 的池中，无法重新使用。即使您在同一账户中创建新的 Droplet，您也会获得新的 IP。这对于测试目的是正常的，但在需要频繁重建或替换服务器的生产系统中会成为真正的问题。每次 IP 更改时，您都必须更新 DNS 记录、配置文件、防火墙白名单，并等待 TTL 过期后所有用户才能看到新 IP。这可能需要从几分钟到几小时，具体取决于 TTL 值。 预留 IP 通过完全将 IP 从 Droplet 的生命周期中分离出来来解决这个问题。当您预留 IP 时，它成为账户级资源，不绑定到任何特定的 Droplet。您可以选择将其分配给同一区域中的任何 Droplet。每当您想切换时，只需从旧 Droplet 取消分配，然后分配给新 Droplet — 指向预留 IP 的 DNS 记录无需任何更改，因为 IP 地址保持不变。与更改常规公开 IP 不同，您无需等待 DNS 传播。 重要的是：预留 IP 绑定到一个区域，而不是特定的 Droplet。因此您可以将其分配给任何 Droplet，只要该 Droplet 与预留 IP 的区域相同（例如，如果您在 sgp1 中预留，它只能与 sgp1 中的 Droplet 一起使用 — 您无法跨区域移动）。一个预留 IP 一次只能连接到一个 Droplet。

• 常规公开 IP 在您删除 Droplet 时立即消失 — 无法重新使用
• 预留 IP 绑定到您的账户，而不是 Droplet，因此您可以将其移动到另一个具有相同 IP 的 Droplet
• 只能连接到预留 IP 创建所在的相同区域中的 Droplet

定价：连接到 Droplet 时免费 / 未连接时 $5/月

根据我们的实测——预留 IP 定价直接明了，有两种清楚的情况。第一种情况：将其连接到活跃的 Droplet — 无额外成本。只要有 Droplet 支持它，就完全免费。第二种情况：让它保持未连接状态（未分配给任何 Droplet）— DigitalOcean 收取每月 $5，或每小时 $0.01，按秒计费，就像常规 Droplet 计费一样。 DigitalOcean 为什么对未使用的预留 IP 收费？因为 IP 地址是有限的资源。如果您可以免费预留 IP 而不附加任何条件，许多用户会囤积 IP 而不实际使用它们，会更快地消耗已经有限的 IPv4 池。此费用是一个机制来阻止未使用的预留。 需要了解的一件事是：预留 IPv6 无需任何成本，无论是否连接。IPv6 池比 IPv4 大得多，因此不存在像 IPv4 那样的稀缺性问题。如果您的架构支持 IPv6，使用预留 IPv6 而不是或与 IPv4 一起使用可以减轻意外成本。 常见疏忽：删除具有连接预留 IP 的 Droplet 后，预留 IP 不会随之删除。相反，它会自动切换到未连接状态并开始产生 $5/月的费用。您应该定期检查控制面板中的"网络"选项卡，以验证没有未使用的预留 IP 坐在那里花费您的钱（定价截至 2026 年 7 月 — 检查提供商网站以获取最新费率）。

• 连接到活跃的 Droplet = 免费
• 未连接 = $5/月或 IPv4 每小时 $0.01
• 预留 IPv6 始终免费，无论是否连接
• 删除 Droplet 不会删除其预留 IP — 如果您不需要，必须手动删除它
• 定期检查网络 > 预留 IP，以避免支付未使用 IP 的费用

预留和连接预留 IP 到 Droplet

您可以通过三种方式预留预留 IP：通过控制面板、通过 doctl CLI 或直接通过 DigitalOcean API v2。在控制面板中，转到网络，选择预留 IP 选项卡，然后单击预留 IP 地址。选择您需要的区域（必须与 Droplet 的区域匹配）并选择目标 Droplet（如果您想）— 或空预留以便以后连接。 对于命令行用户，请使用 doctl（DigitalOcean 的官方 CLI 工具）。使用 doctl compute reserved-ip create --region sgp1 进行预留。系统返回 IP 地址。然后使用 doctl compute reserved-ip-action assign <reserved-ip> <droplet-id> 将其连接到 Droplet，其中 droplet-id 来自 doctl compute droplet list。要取消连接，请使用 doctl compute reserved-ip-action unassign <reserved-ip>。要完全删除它（停止未连接费用），请使用 doctl compute reserved-ip delete <reserved-ip>。 对于通过 API 的自动化（如编写自定义故障转移脚本），直接使用 curl 调用 REST API v2。使用 curl -X POST -H "Authorization: Bearer $DO_TOKEN" -H "Content-Type: application/json" -d '{"droplet_id":"DROPLET_ID"}' "https://api.digitalocean.com/v2/reserved_ips" 创建新的预留 IP。要将现有预留 IP 连接到新 Droplet，请向该 IP 的端点发送操作：curl -X POST -H "Authorization: Bearer $DO_TOKEN" -H "Content-Type: application/json" -d '{"type":"assign","droplet_id":"NEW_DROPLET_ID"}' "https://api.digitalocean.com/v2/reserved_ips/45.55.32.11/actions"。此方法适用于自动健康检查脚本，如果主 Droplet 关闭，可以重新分配 IP。 连接预留 IP 后，验证 Droplet 内部 IP 是否已绑定到网络接口，使用 ip addr show eth0。DigitalOcean 通过元数据服务自动添加它 — 您通常不需要在操作系统级别配置任何内容。

• 通过控制面板：网络 > 预留 IP > 预留 IP 地址
• doctl：doctl compute reserved-ip create --region sgp1 然后使用 reserved-ip-action 分配
• API：POST 到 /v2/reserved_ips 或 /v2/reserved_ips/{ip}/actions

在 Droplet 之间移动预留 IP，实现零停机

预留 IP 的主要优势是能够在 Droplet 之间移动，而用户看到的 IP 地址保持不变。这对于蓝绿部署非常理想，您想在旧版本和新版本之间即时切换流量。典型的工作流是：创建新 Droplet，使用其临时公开 IP（或通过私有 VPC IP）安装和测试应用程序，一旦您确信所有内容都有效，就发出命令将预留 IP 移动到新 Droplet。 您可以在单个命令中移动它，而无需单独的取消分配/分配步骤。DigitalOcean 支持使用 doctl compute reserved-ip-action assign <reserved-ip> <new-droplet-id> 的直接重新分配。系统在一个操作中处理从旧 Droplet 的取消分配和对新 Droplet 的分配。此切换在 DigitalOcean 的内部网络级别非常快速 — 它是数据中心的路由更改，不是像典型 A 记录更新那样的 DNS 传播。这使用户可见的停机时间远短于 DNS 更改。 但是，请理解这里的"零停机"是指零 DNS 传播延迟，而不是零断开连接的保证。仍在旧 Droplet 上进行的连接在切换期间可能会中断，如果您没有设置连接耗尽或会话持久性。对于真正的高可用系统，设计您的应用程序以无状态方式工作并支持客户端重试 — 不要仅依赖预留 IP。 在生产中切换之前，在维护窗口中或使用健康检查彻底测试新 Droplet 以验证所有内容都通过（web 服务器、数据库、TLS 证书、环境变量），然后再真正切换。一旦您按下切换，所有流量立即转到新 Droplet。如果出现问题，您可以立即将 IP 重新分配回旧 Droplet — 回滚是单个命令，比修复 DNS 快得多。

• 使用 doctl compute reserved-ip-action assign 在一个命令中重新分配 — 无需先取消分配
• 比更改 DNS A 记录快得多，因为无需 TTL 传播等待
• 在真正切换之前，始终彻底测试新 Droplet
• 如果缺少连接耗尽，旧 Droplet 上的进行中的连接可能会断开

示例用例：高可用性

根据我们的实测——使用预留 IP 的基本 HA 模式是两个 Droplet 的主动-被动架构：主 Droplet 通过预留 IP 接收真实流量，备用 Droplet 运行相同的软件和数据但不接收流量。监控脚本或健康检查持续监视主 Droplet。如果它检测到主 Droplet 无响应（HTTP 健康检查重复失败或 Droplet 通过 SSH 无法访问），脚本调用 DigitalOcean API 将预留 IP 重新分配给备用 Droplet。流量随后流向备用 Droplet，最终用户无需等待 DNS 更改。 故障转移脚本通常使用外部监控工具（如 Uptime Kuma）或在第三台服务器上的 cron 作业运行（不在主或备用本身上，因为如果您的监控框与主 Droplet 一起故障，没有人可以触发故障转移）。当健康检查失败时，脚本调用指向备用的 reserved-ip-action assign 端点。与手动修复相比，这减少了 RTO（恢复时间目标）。 另一个常见用例是数据库故障转移：将预留 IP 连接到运行 PostgreSQL 或 MySQL 主副本的 Droplet。当主副本故障时，复制系统将副本提升为新主副本，然后您将预留 IP 重新分配以指向新主副本 Droplet。通过指定预留 IP 的连接字符串连接的应用程序不需要任何重新配置 — IP 仍然正常工作。 对于真正需要多个 Droplet 同时提供流量的系统（不仅仅是备用故障转移），预留 IP 不适合，因为它一次只连接到一个 Droplet。请改用负载平衡器，它在多个后端之间分配流量并具有内置健康检查。

1. 主动-被动：主 Droplet 接收真实流量，备用 Droplet 准备好进行故障转移
2. 监控脚本应在第三台机器上运行，以避免与主 Droplet 一起故障
3. 与数据库复制配合使用效果很好 — 在提升副本后重新分配预留 IP
4. 与手动修复或 DNS 更改相比，显著减少 RTO

何时使用此功能（真实用例）

预留 IP 非常适合想要基本故障转移功能但不需要负载平衡器成本的团队或开发人员（从 $12/月开始）。对于具有单个主 Droplet 接收真实流量的小型到中型项目，连接到它的预留 IP 成本为零 — 与每月收费的负载平衡器不同，无论使用情况如何。这使得预留 IP 对于不需要跨多台机器的流量分配但确实需要"备份"以防主 Droplet 故障的系统更具成本效益。 另一个常见用例是蓝绿部署。通过旋转整个新 Droplet（而不是原地更新旧 Droplet）部署新代码的团队受益于预留 IP 作为旧版本和新版本之间的流量切换，完全不涉及 DNS。这适合频繁部署的团队，他们希望在部署后发现错误时立即回滚。 另一种情况是 Droplet 上的自托管数据库的基本 HA，您还没有准备好提交到托管数据库或完整的多节点集群。在具有准备好提升的副本的主数据库上使用预留 IP — 比完整的托管数据库集群更快实现。 相反，如果您的系统具有高流量并需要跨多个 Droplet 始终分配流量（不仅仅是备用），或者如果您的团队想要本机自动健康检查而不需要编写脚本，负载平衡器更合适。当您需要简单、免费的故障转移时，预留 IP 是正确的工具 — 不是当您需要活跃的负载分配时。

• 具有单个主 Droplet 的小型到中型系统，需要故障转移而不需要负载平衡器成本
• 蓝绿部署：在旧版本和新版本之间切换流量，不涉及 DNS
• 自托管数据库的基本 HA，然后才升级到托管集群
• 需要快速回滚的频繁部署的团队

常见错误及其修复方法

最常见的错误是忘记未连接的预留 IP 成本 $5/月。许多人为了测试预留一个，然后忘记删除，或在没有意识到预留 IP 在未连接状态下持续存在并开始产生费用的情况下删除 Droplet。修复：设置计费警报并定期查看网络 > 预留 IP 以捕捉未使用的。如果您不打算再使用它，请立即使用 doctl compute reserved-ip delete 删除它。 第二个错误：从一开始就将您的 DNS A 记录指向 Droplet 的常规公开 IP 而不是预留 IP。这违反了目的 — 当您稍后想切换 Droplet 时，您仍然必须更新 DNS 并等待传播。教训：从一开始就将 DNS 配置为指向预留 IP，即使您只有一个 Droplet 且没有故障转移计划。这样做的成本是零（连接的预留 IP 是免费的），但它为未来的扩展或故障转移而不重新做 DNS 提供了灵活性。 第三个错误：尝试跨区域连接预留 IP，如在 sgp1 中预留的连接到 nyc1 中的 Droplet。您无法 — 预留 IP 与区域锁定。修复：从一开始就仔细计划您的区域。如果您真的需要跨区域移动，您必须在目标区域中预留新 IP 并完全更新 DNS。 第四个错误：防火墙规则（云防火墙或 ufw）引用 Droplet 的旧公开 IP 而不是预留 IP。故障转移后，这些规则不适用于新 Droplet。更好的方法：使用标签编写防火墙规则而不是硬编码 IP。标签应用于所有具有该标签的 Droplet，无论它是哪个物理 Droplet。 第五个错误：编写故障转移脚本但在依赖它之前从未在生产中测试过。您只在实际需要时发现错误或权限错误。修复：在计划的维护窗口中至少彻底排练一次故障转移，然后再在真实中断中依赖它。

• 未连接的预留 IP 成本 $5/月 — 设置计费警报并定期检查
• 从一开始就将 DNS 指向预留 IP，而不是 Droplet 的公开 IP
• 无法跨区域连接 — 从一开始就仔细计划区域

最佳实践

第一原则：从系统设置的第一天就将 DNS 配置为指向预留 IP，即使您只有一个 Droplet 且没有 HA 计划。前期成本为零（连接的预留 IP 是免费的），但它为扩展或故障转移而不需要每次重新做 DNS 提供了将来的灵活性。 第二：安全地存储故障转移脚本的 API 令牌 — 使用环境变量或密钥管理器，永远不要将其硬编码到进入版本控制的源代码中。将令牌权限限制为所需的最小值（最小权限原则），以限制令牌泄漏时的损害。 第三：编写您的整个团队可以访问的运行手册或记录的故障转移程序。准确指定何时触发手动故障转移与让脚本自动处理，并记录故障转移导致新问题时的回滚步骤。当熟悉系统的工程师在事件期间不可用时，此文档特别关键。 第四：定期测试您的故障转移，而不是仅在设置时测试一次。系统和依赖项不断演变（操作系统更新、库版本、证书过期）。至少每季度排练一次故障转移可以确认系统在重要时刻仍然有效。 最终原则：根据系统规模定制您的方法。小型系统受益于使用简单监控脚本的预留 IP。随着系统增长并需要跨许多 Droplet 同时分配流量，考虑切换到具有内置健康检查和自动故障转移的负载平衡器 — 自己维护的东西更少。并始终立即删除未使用的预留 IP 以避免持续费用。

• 从一开始就将 DNS 配置为指向预留 IP，即使没有 HA 计划 — 零成本，最大灵活性
• 在环境变量或密钥管理器中存储 API 令牌，永远不要硬编码它们
• 编写您的团队可以访问的记录故障转移和回滚运行手册

领取 $200 免费额度 →