DigitalOcean VPC 指南 2026 — 免费私有网络

DigitalOcean 的 VPC（虚拟私有云）是一个与公共互联网完全隔离的私有网络。所有支持的资源——Droplet、托管数据库、Load Balancer、Kubernetes 节点——都可以在同一个 VPC 内通过私有 IP 相互通信，完全不需要经过公共互联网，甚至一次都不需要。这与通过公共 IP 开放端口然后依靠云防火墙过滤不同，因为 VPC 在网络层（网络层）切断外部访问，而不仅仅是在规则层进行过滤——简单来说，如果你不在同一个 VPC 中，或者还没有将它们对等连接在一起，你就根本看不到彼此的私有 IP。 对于开发团队，VPC 的主要优势有三个方面。首先是安全性：数据库、缓存和内部 API 可以只绑定到私有 IP，完全无需暴露公共 IP 面临扫描或暴力破解风险。其次是速度和成本：在同一区域内通过私有网络流动的流量比通过公共互联网流动的延迟更低，并且不计入 Droplet 的出站带宽配额。第三是环境组织：例如，将生产和测试的 VPC 分离可以防止意外连接到错误的数据库。 一个重要的澄清是：VPC 不替代云防火墙——两者在不同层面协同工作。VPC 控制"谁可以看到谁的私有 IP"，而防火墙控制"哪些端口是开放还是关闭"。寻求最大安全性的团队应该将两者一起使用：将敏感资源隔离在没有公共 IP 的 VPC 中，然后仅公开面向 Web 的 Droplet（边缘）并配有公共 IP 和严格的防火墙规则。本指南将指导你从头开始真实 VPC 设置，为开发/生产分离创建自定义 VPC，将数据库隐藏在互联网之外，以及使用 Peering 连接两个 VPC。

什么是 VPC 以及为什么它对安全很重要

DigitalOcean 的 VPC（虚拟私有云）是一个与公共互联网完全隔离的私有网络。所有支持的资源类型——Droplet、托管数据库、Load Balancer、Kubernetes 节点——都可以在同一个 VPC 内通过私有 IP 相互通信，完全不需要连接到互联网，甚至一次都不需要。这与通过公共 IP 开放端口然后依靠云防火墙过滤不同，因为 VPC 在网络层（网络层）切断外部访问，而不仅仅是在规则层进行过滤——简单来说，如果你不在同一个 VPC 中，或者还没有将它们对等连接在一起，你就完全看不到彼此的私有 IP。 对于开发团队，VPC 有三个主要优势。首先是安全性：数据库、缓存和内部 API 可以只绑定到私有 IP，完全无需暴露公共 IP 面临扫描或暴力破解风险。其次是速度和成本：在同一区域内通过私有网络流动的流量比通过公共互联网流动的延迟更低，并且不计入 Droplet 的出站带宽配额。第三是环境组织（环境隔离），例如将生产与测试的 VPC 分离以防止意外连接到跨环境的错误数据库。 需要理解的是，VPC 不替代云防火墙——两者在不同层面协同工作。VPC 控制"谁可以看到谁的私有 IP"，而防火墙控制"哪些端口是开放还是关闭"。寻求最大安全性的团队应该将两者一起使用：将敏感资源隔离在没有公共 IP 的 VPC 中，然后仅公开前端 Droplet（边缘）并配有公共 IP 和严格的防火墙规则。本文将指导你从 VPC 基础开始真实设置，创建自定义 VPC 以实现开发/生产分离，将数据库隐藏在互联网之外，以及使用 Peering 连接两个 VPC。

1. VPC 在网络层切断访问，不同于防火墙在端口层进行过滤
2. VPC 内的流量不计入 Droplet 的出站带宽配额
3. 建议按环境分离 VPC，例如开发/测试/生产
4. 始终将 VPC 与云防火墙结合使用以实现两层安全防护

每个区域的默认 VPC（免费且无限制）

每个 DigitalOcean 账户都会在已有资源的每个区域中自动创建一个默认 VPC。覆盖全球所有 15 个数据中心：nyc1/nyc2/nyc3（纽约）、sfo2/sfo3（旧金山）、ams3（阿姆斯特丹）、lon1（伦敦）、fra1（法兰克福）、tor1（多伦多）、syd1（悉尼）、atl1（亚特兰大）、ric1（里士满）、mkc1（堪萨斯城），一直到 sgp1（新加坡）和 blr1（班加罗尔）——最接近泰国用户的位置。每个区域都像支持 Droplet、Kubernetes 和 Load Balancer 一样支持 VPC。当你在任何区域创建第一个 Droplet 而不指定 VPC 时，系统会立即自动将其绑定到该区域的默认 VPC。 开发者经常忽视的关键点是 VPC 仅限于单个区域，不跨越区域。nyc1 中的 Droplet 和 sgp1 中的 Droplet 从一开始就不能在同一个 VPC 中（你必须稍后使用 VPC Peering 连接它们，如下一部分所述）。所以在创建第一组资源之前，计划好你是否会使用单个区域或多个区域。如果你的团队很小，大多数用户都在亚洲，那么仅在 sgp1 区域中集中所有内容意味着所有 Droplet、托管数据库、Load Balancer 都会自动放在同一个 VPC 中，无需 Peering。 使用 VPC 不需要任何额外成本，无论是默认 VPC 还是单独创建的自定义 VPC，并且每个账户可以拥有无限数量的 VPC——不同于某些主要云提供商对子网数据传输收费或单独收费 NAT Gateway 的做法。你可以使用命令 doctl vpcs list 轻松检查现有的默认 VPC，它会显示每个 VPC 的名称、区域和 UUID，以及指示每个区域中的默认 VPC。当你想将 Droplet 或数据库创建到目标 VPC 时，了解这个 UUID 是必不可少的。

1. 默认 VPC 按区域自动创建，覆盖所有 15 个数据中心
2. VPC 仅限于单个区域；跨区域需要 Peering
3. 泰国用户推荐 sgp1（新加坡），次选 blr1（班加罗尔）

为开发/生产环境分离创建自定义 VPC

一旦团队拥有多个环境（开发、测试、生产），使用单个默认 VPC 会存在意外将测试 Droplet 连接到生产数据库的风险。解决方案是为每个环境创建单独的自定义 VPC，可以通过 Control Panel 的网络 > VPC 网络下进行，也可以通过 doctl/API 供专注自动化的团队使用。 使用 doctl 创建生产 VPC 的示例：doctl vpcs create --name prod-vpc --region sgp1 --ip-range 10.10.0.0/24 以及在同一区域但不同 IP 范围中的测试 VPC 以避免冲突：doctl vpcs create --name staging-vpc --region sgp1 --ip-range 10.20.0.0/24 创建后，你会获得一个 UUID；保存它以供稍后在创建 Droplet 时使用，通过指定 --vpc-uuid 标志而不是让系统默认到默认 VPC：doctl compute droplet create web-prod-01 --region sgp1 --size s-2vcpu-4gb --image ubuntu-24-04-x64 --vpc-uuid <prod-vpc-uuid> 按环境分离 VPC 的优势是测试 VPC 中的 Droplet 根本看不到生产 VPC 中的 Droplet 或数据库的私有 IP，即使它们在同一区域和账户中——它们必须显式对等连接才能通信，这是适当的最小权限行为，比依赖记忆 Droplet 名称或标签更能防止人为错误。 使用 Terraform 管理基础设施的团队也可以将 VPC 声明为代码，使用 Terraform Registry 中 digitalocean/digitalocean 提供程序的 digitalocean_vpc 资源。这使得创建和销毁整个环境集（VPC + Droplet + 数据库一起）变得可重复，并可以通过状态文件检查历史记录，对于需要一致性的多环境团队来说是理想的。 一个值得了解的限制是：同一账户中不同 VPC 的 IP 范围（CIDR）不能重叠，特别是如果你预计稍后需要对等连接它们，因为重叠的 IP 范围会阻止 Peering。所以提前规划你公司的 IP 方案，例如将生产分配给 10.10.x.x，测试分配给 10.20.x.x，开发分配给 10.30.x.x，以避免以后需要重做。

• 通过 Control Panel（网络 > VPC 网络）或 doctl vpcs create 创建
• 创建 Droplet 时指定 --vpc-uuid 以避免意外使用默认 VPC
• 提前规划 IP 范围不重叠，以防后来需要 Peering

示例：将数据库隐藏在互联网之外

最常见的 VPC 使用场景是隐藏托管数据库，使其对互联网完全没有公共 IP。DigitalOcean 托管数据库（PostgreSQL、MySQL、Valkey、MongoDB）会自动创建到其区域的 VPC 中，并配有与公共主机名不同的单独私有主机名——当你的 Droplet 在同一 VPC 中时，使用该主机名而不是公共端点。 安全设置有三个主要步骤。首先，在与应用程序 Droplet 相同的 VPC 中创建数据库。使用 doctl：doctl databases create app-db --engine pg --region sgp1 --size db-s-1vcpu-1gb --vpc-uuid <prod-vpc-uuid> 其次，通过转到数据库集群的设置 > 受信源选项卡并删除"允许公共访问"，或将受信源限制为仅限同一 VPC 中的 Droplet/标签来禁用公共网络访问。完成后，即使有人获得了数据库凭证，他们也无法从 VPC 外部连接——网络级连接在源处被阻止，无论有无密码。 第三，更新你的应用程序的连接字符串以指向私有主机名而不是公共主机名。检查数据库的连接详情页面并在复制连接字符串之前选择"私有网络"，因为 DigitalOcean 同时显示两个选项。通过私有主机名连接还有额外好处：延迟更低，并且不会消耗 Droplet 的出站带宽配额，因为流量永远不会离开 DigitalOcean 的内部网络。 对于自托管数据库在 Droplet 上而不是使用托管数据库的团队，同样的原则适用：在创建时给数据库 Droplet 不分配公共 IPv4（在 Droplet 创建期间取消选择公共 IPv4），并让应用程序仅通过 VPC 内的私有 IP 连接。结合云防火墙规则，仅允许来自应用程序 Droplet 私有 IP 的数据库端口（例如 PostgreSQL 的 5432）——永远不要 0.0.0.0/0。这将攻击面减少到可能的最大程度，而不需要花费额外的钱。

1. 托管数据库有与公共主机名不同的单独私有主机名
2. 从数据库集群的受信源选项卡禁用公共访问
3. 从连接详情中复制"私有网络"类型的连接字符串

使用 VPC Peering 跨 VPC 连接 Droplet

让我们意外的一点是：VPC Peering 连接两个 VPC，使其内部的资源可以通过私有 IP 相互通话，无需通过公共互联网。它是双向工作的：对等连接同一账户中不同区域的两个 VPC（例如连接 sgp1 到 blr1）以及对等连接同一账户中同一区域但为环境隔离分离的两个 VPC，如前所述。 使用 doctl 创建 Peering：doctl vpcs create-peering --name prod-to-staging --vpc-ids <prod-vpc-uuid>,<staging-vpc-uuid> 或通过 Control Panel 的 VPC 页面、Peering 选项卡，然后单击创建 Peering 并选择要连接的两个 VPC。系统需要一段时间来建立连接。一旦状态变为活动，一侧的 Droplet 可以立即连接到另一侧的私有 IP，无需自己配置路由表——DigitalOcean 会自动处理路由。 最重要的注意是 Peering 是非传递的——如果 VPC A 与 B 对等，B 与 C 对等，A 仍然无法直接到达 C。你必须在 A 和 C 之间单独创建 Peering。其次，被对等连接的两个 VPC 的 IP 范围（CIDR）根本不能重叠。如果你没有如前所述提前规划 CIDR，你可能需要创建新 VPC 并迁移所有资源——比提前规划要混乱得多。 真实世界的用例包括团队在一个 VPC 中拥有 Kubernetes 集群（DOKS）而在另一个 VPC 中拥有托管数据库（例如数据团队单独管理数据库 VPC）。Peering 让 Pod 通过私有主机名连接到数据库，无需任何公共访问。另一个用例是从一个区域扩展到多个区域以服务全球用户（例如从 sgp1 开始然后扩展到 fra1 为欧洲用户）并希望内部服务通过私有网络而不是在两侧暴露公共 IP 来跨区域通信。 使用 doctl vpcs list-peerings 检查所有 Peering，并使用 doctl vpcs delete-peering <peering-id> 删除未使用的 Peering 以减少系统中不必要的访问面。

• Peering 是非传递的——为每个需要通话的 VPC 对创建单独连接线
• 两个 VPC 的 CIDR 在 Peering 之前不能重叠
• DigitalOcean 在 Peering 变为活动后自动管理路由表
• 同时适用于跨区域和同一账户中的同一区域

VPC 使用的故障排除和最佳实践

VPC 设置期间最常见的问题是在不同时间创建的两个 Droplet 试图通过私有 IP 连接但无法连接，尽管它们应该在同一区域。最主要的原因是 Droplet 被意外放在不同的 VPC 中而没有注意到（例如旧 Droplet 在默认 VPC 中但新 Droplet 指定了错误的 --vpc-uuid）。快速检查：通过 doctl compute droplet get <id> --format Name,PrivateIPv4,VPCUUID 查看每个 Droplet 的私有 IP 和 VPC UUID，并比较两侧以确保 VPCUUID 匹配。 第二个问题是通过私有主机名连接到数据库失败，尽管公共访问已关闭。通常是因为旧的公共连接字符串仍然存在于 .env 文件或秘密管理器中。审计存储凭证的每个地方并完全切换到私有主机名。还要验证应用程序 Droplet 是否与数据库在同一 VPC 中——如果它们在不同的 VPC 中，仅更改主机名是没有帮助的；你需要先进行如前所述的 Peering。 第三个问题是 Peering 卡在待处理状态超过正常时间。通常需要几分钟；如果它挂起，首先检查两个 VPC 的 CIDR 范围是否重叠，这是 Peering 创建失败的第一大原因。 长期认真使用 VPC 的团队的最佳实践建议：在创建任何真实内容之前，提前规划和记录整个公司的 VPC 名称和 CIDR 方案。有意义地命名 VPC，如 prod-sgp1-vpc 而不是系统默认分配的名称。从一开始就禁用不需要直接从互联网接收流量的 Droplet 的公共 IPv4，而不是稍后禁用。始终按照拒绝优先原则将云防火墙与 VPC 一起使用，仅打开实际需要的端口/流量。定期审查所有现有 Peering 连接并删除那些不再使用的，因为未使用的 Peering 连接随着时间推移在系统中构成隐藏的安全风险。

1. 在怀疑其他问题之前，首先检查两个 Droplet 的 VPCUUID
2. 数据库连接问题大多来自连接字符串中过时的公共主机名
3. 重叠的 CIDR 是 Peering 创建失败的第一大原因
4. 在开始之前有意义地命名 VPC 并记录 CIDR 计划作为共享参考

将 VPC 与 Load Balancer 和托管数据库集成

基于真实使用经验，DigitalOcean 的 Load Balancer 充当边缘前端，从互联网接收流量并使用公共 IP，然后通过同一 VPC 内的私有网络将其分配给后端 Droplet。创建 Load Balancer 时，你可以使用标志 --vpc-uuid 直接指定目标 VPC，例如：doctl compute load-balancer create --name web-lb --region sgp1 --vpc-uuid <prod-vpc-uuid> --forwarding-rules entry_protocol:https,entry_port:443,target_protocol:http,target_port:80 --droplet-ids <id1>,<id2> 关键点是每个附加到 Load Balancer 的后端 Droplet 必须在与 Load Balancer 相同的 VPC 中。如果 Droplet 在不同的 VPC 中（例如在创建 Droplet 时忘记指定 --vpc-uuid，它落入默认 VPC），Load Balancer 无法将流量转发到该后端——运行状况检查会立即失败。这是后端状态显示"不健康"尽管 Droplet 运行正常的常见原因。 在托管数据库方面，与 Load Balancer 架构的集成通常遵循三层模式：第一层是从互联网接收流量的 Load Balancer，第二层是位于 Load Balancer 后面的同一 VPC 中的应用程序 Droplet 组，第三层是同一 VPC 中的托管数据库但公共访问完全关闭。第二层通过如前所述的数据库私有主机名与第三层通话。但使用 Load Balancer 的额外步骤是配置数据库受信源以仅允许应用程序 Droplet 的标签，而不是整个 VPC 范围，防止其他可能意外在同一 VPC 中的 Droplet（如监控或 Bastion 主机）意外访问数据库。添加特定标签作为受信源的示例命令：doctl databases firewalls append <db-id> --rule tag:app-backend 将 Load Balancer、VPC 和托管数据库以这种方式连接的好处是从应用程序 Droplet 一直到数据库的所有流量永远不会离开互联网，甚至一次都不需要。只有一个点被暴露给公众：Load Balancer 前端。这将攻击面最小化到可能的最小值，同时仍然正常服务公开流量。通过在 Load Balancer 后面添加更多应用程序 Droplet 进行水平扩展的团队遵循相同的原则：只需验证每个新 Droplet 都在 Load Balancer 的 VPC 中，并且已有数据库受信源允许的标签。

• Load Balancer 始终通过私有网络转发流量到后端 Droplet
• 后端 Droplet 必须在与 Load Balancer 相同的 VPC 中，否则运行状况检查变为"不健康"
• 使用标志 --vpc-uuid 在 Load Balancer 创建时指定 VPC
• 按应用程序 Droplet 的标签限制数据库受信源，而不是整个 VPC

VPC 的限制需要记住

尽管 VPC 提供了许多好处，但在设计真实架构之前需要理解这些限制，这样你就不需要稍后重塑基础设施，这通常比提前规划要混乱得多。 第一个也是最重要的限制是 VPC 仅限于单个区域；没有跨越多个区域的全局 VPC。如果你希望不同区域中的资源通过私有网络相互通信，你必须创建连接区域对的 VPC Peering（并记住 Peering 是非传递的）。或者，流量必须通过公共网络，失去安全和延迟的好处。计划扩展到多个区域的团队应该提前设计他们的整个 VPC 和 CIDR 方案，而不是随着扩展逐片进行。 第二个限制是每个区域只能有一个默认 VPC，不是多个。默认 VPC 在创建资源时自动使用，而不显式指定 VPC。如果你在创建 Droplet 或数据库时即使只有一次忘记指定 --vpc-uuid，该资源会立即进入默认 VPC 而不出现任何警告——这是"彼此看不到"问题的最主要原因，如故障排除部分所述。 第三个限制是 VPC 的 CIDR（IP 范围）在创建时是固定的，之后无法更改或调整大小；你只能更改名称和描述。如果你提前计算错误 CIDR，如选择太小的范围并用尽 IP，或选择与你稍后需要对等的 VPC 重叠的范围，唯一的修复是创建新 VPC 并迁移所有资源——显著的停机时间和私有 IP 更改风险。所以提前进行适当的 CIDR 规划并留有增长空间至关重要。 最后一个限制是并非所有 DigitalOcean 服务都支持 VPC。Spaces（对象存储）是明确的例子——它仅通过公共端点访问（即使用 HTTPS 加密）——没有选项将其作为仅限私有的服务绑定到 VPC，就像你可以对 Droplet 或托管数据库所做的那样。所以如果你的应用程序在对象存储中存储敏感文件，你必须依靠文件级加密和严格的访问密钥权限，而不是 VPC 作为保护层，就像你可以对 Droplet 或托管数据库所做的那样。

• VPC 仅限于单个区域；没有跨越多个区域的全局 VPC
• 每个区域只有一个默认 VPC；忘记 --vpc-uuid 意味着资源立即进入默认
• CIDR 在创建时固定；之后无法调整大小，仅能更改名称和描述

领取 $200 免费额度 →