云上主机虚拟网络搭建8个步骤与常见配置示例

云上主机虚拟网络搭建，表面看是在云平台里建几个网段、挂几条规则，实际影响的是业务能不能长期稳定跑下去。很多团队刚上云时，注意力都放在云主机数量、配置规格和上线速度上，网络部分只求“先通”。这种做法短期没问题，等服务一多、环境一分、外部系统一接，网络很快就会乱：有的服务互相访问不了，有的端口开得过大，测试和生产混在一起，后面每改一次都像拆线团。

云上主机虚拟网络搭建最好别从“创建云主机”开始，先把访问关系画清楚更稳妥。哪些系统要互通，哪些必须隔离；哪些流量走公网，哪些只走内网；以后会不会接本地机房、专线、VPN，或者再加一套测试环境。这些问题越早确定，后面的返工越少。

搭建前先把目标定清楚

一套能长期使用的方案，通常要先满足三件事：业务能连、安全可控、后面还能扩。

• 业务连通性：Web、应用、数据库、缓存、运维跳板机之间怎么通信，要提前梳理，不然网络建完还得反过来补规则。
• 安全隔离性：生产、测试、开发要不要分开，数据库和缓存能不能暴露公网，这些决定了子网和安全策略的边界。
• 扩展兼容性：以后如果增加可用区、更多主机，或者接入本地IDC，当前地址规划和路由设计还能不能接得住。

有些团队初期只有两台应用服务器和一台数据库，觉得先跑起来最重要，于是所有主机放一个网段里，公网一开就上线。等后面陆续加缓存、日志采集、CI 服务、WAF、VPN 接入，再想拆层就很痛苦。IP 段不够用、路由关系不清、安全组越改越乱，这类隐性成本，通常都出在前期没规划。

一套顺手的做法：先规划，再创建，再收口

实操里，比较稳的顺序是先做网络规划，再划分子网，然后配路由、上安全策略、接入主机，最后做验证和优化。看起来比边建边改多了一步思考，但团队协作时反而更省事，因为每个人都知道资源该放哪、规则该怎么开，不会今天能用、明天冲突。

1. 先定 VPC 网段，避开现有网络

大多数云平台都会提供 VPC，云上主机虚拟网络搭建的第一步，通常就是给 VPC 选一个合适的 CIDR 网段。这里最常见的坑，是地址选得太随意，后面一接本地网络就冲突。

如果企业本地机房已经用了 192.168.0.0/16，云上就尽量别再选同类地址段，可以优先考虑 10.10.0.0/16 或 172.16.0.0/16 里的区段。这样后续接 VPN 或专线时，路由更干净，也不容易出现同网段冲突。

2. 子网按角色分，不按“哪台机器先来”分

子网划分很能看出方案是不是长期可维护。把所有主机塞进一个子网，前期最省事，后期最难管。更稳妥的做法是按业务层级分层，这样访问边界和权限关系会清楚很多。

• 公网接入层子网：放负载均衡、公网跳板机这类直接对外或承担入口功能的组件。
• 应用层子网：放 Web 服务、API 服务、任务服务，主要处理业务逻辑。
• 数据层子网：放数据库、缓存、消息队列，尽量只接受内网访问。
• 运维管理子网：放堡垒机、监控、备份服务，便于单独管控运维入口。

这种分法的好处很实际。比如后面要限制应用只能访问数据库 3306 端口，或者测试环境不能直接连生产环境，规则会好写很多；要是所有主机都混在一个子网里，安全组和 ACL 往往只能不停打补丁。

3. 路由表别做复杂，路径要看得懂

基础业务场景里，应用子网和数据库子网通常靠默认本地路由互通；需要访问公网的流量，再通过公网网关或 NAT 网关出去。这里有个常见误区：为了省事，直接给数据库挂公网 IP。这样虽然连得方便，但攻击面会明显变大，后面审计和权限管理也麻烦。

如果已经有多个子网、多个环境，或者要做跨可用区部署，关键子网最好单独绑定路由表，并把每条路由的用途记录清楚。运维接手时，最怕看到一堆路由存在，却没人说得清为什么要这样走。

4. 安全组和 ACL 一起用，边界更清楚

云上主机虚拟网络搭建不能只盯着“通不通”，还得管住“谁能通”。常用的两层控制分别是安全组和网络 ACL。

• 安全组：面向云主机实例，更适合细一点的规则，比如只允许应用服务器访问数据库 3306 端口。
• 网络 ACL：面向子网边界，适合做粗粒度的入站、出站过滤，补一层整体防护。

规则设计尽量遵循最小权限。跳板机只放公司固定出口 IP 登录，数据库只接受应用子网或指定安全组来源，测试环境默认不要直接访问生产环境。还有一个容易忽视的点：云平台的安全组放通了，不代表主机本地防火墙也放通，排障时要两边一起看。

云上主机虚拟网络搭建的8步实操流程

1. 梳理业务架构：把前端、应用、数据库、缓存、运维节点的访问关系列出来，尤其要标清哪些是单向访问、哪些需要公网入口。
2. 规划 VPC 地址段：给当前业务留空间，也给后面扩容、多环境部署留空间。刚开始图省事只给一个很小的网段，后面最容易卡住。
3. 划分子网：至少区分公网层、应用层、数据层；如果运维入口独立，单独做管理子网会更稳。
4. 创建网关能力：按需配置公网网关、NAT 网关或 VPN 网关。需要出网的业务和只做内网通信的业务，出口设计不要混在一起。
5. 配置路由表：确保私网互通关系清晰，公网访问路径明确。多子网场景下，别让一条临时路由长期留在生产环境里。
6. 绑定安全策略：安全组、ACL、主机防火墙配合使用。规则名称和用途最好写明，后期改动才不容易误删。
7. 部署云主机并分配内网 IP：按角色放入对应子网，不要为了方便把数据库和应用都丢进同一层。
8. 做联通与安全验证：验证端口是否按预期开放、链路是否正常、登录入口是否收敛、异常来源是否会被拦截。

这 8 步里，前 3 步最见功夫。前面规划错了，后面每多一台主机、一个服务，复杂度都会跟着涨；前面分层做对了，后面加资源通常只是复制已有规则。

一个常见场景的配置示例

拿一个精简的电商团队场景来看，思路会更直观。团队准备上线一套新商城系统，初期有 6 台云主机：2 台 Nginx 应用节点、2 台 Java 服务节点、1 台 MySQL 数据库、1 台堡垒机。要求也很明确：系统要能对公网提供服务，但数据库不能暴露公网。

示例规划

• VPC 网段：10.20.0.0/16
• 公网子网：10.20.1.0/24，放堡垒机和对外接入组件
• 应用子网：10.20.2.0/24，放 Nginx 和 Java 服务
• 数据子网：10.20.3.0/24，放 MySQL

访问逻辑可以这样收口：用户流量先从公网入口进来，再转发到应用层；应用层通过内网访问数据库；运维人员先登录堡垒机，再进入应用或数据库主机。数据库主机不绑定公网 IP，3306 端口只对应用安全组开放。

这套结构的好处很实际，后面也好扩。比如再加 Redis 和消息队列，通常只要继续放进应用层或数据层子网，再补安全组规则，不用整体重做网络。后面再加测试环境，也可以新增独立子网和安全组，把环境隔离开，不必继续堆在现有网段里。

几个最容易踩的坑

• 网段规划太小：初期觉得 /24 足够，后面多环境、多服务一上来，地址不够、子网难拆，只能迁移。
• 所有主机都开公网：刚开始登录方便，后期风险很高。数据库、缓存、内部服务能不暴露就别暴露。
• 安全组规则过宽：直接放通 0.0.0.0/0 和一堆端口，看似省事，实际等于把隔离能力废掉了。
• 缺少命名规范和文档：子网、路由、规则名字全是临时起的，人员一交接，谁也不敢改。

中小团队尤其容易遇到第四种情况。技术上并不复杂，问题往往是没有形成统一方法：有人按业务分，有人按部门分，也有人临时改规则不留记录。最后网络虽然还能跑，但谁都不敢动。

建完网络，还得继续管

云上主机虚拟网络搭建完成，不代表这件事结束了。后面至少要把监控、审计和演练补上。

• 监控：盯带宽、流量、异常连接、丢包和延迟。很多网络问题是高峰期变慢、偶发超时，这类情况要靠持续观察。
• 审计：记录安全组变更、登录来源、关键端口访问情况。哪怕只是一次临时放通，也最好留痕。
• 演练：定期验证故障切换、误删规则恢复、跨子网通信。平时不测，真出问题时恢复速度通常会很慢。

如果后面还要接容器平台、微服务或者混合云，前期的地址规划和安全分层会直接影响迁移难度。网络结构稳，后续新增主机、部署新服务、接入更多环境时，基本是在原有框架上扩；结构乱，越往后修补，成本越高。

把云上主机虚拟网络搭建做好，说白了就是三件事：地址别乱选，子网别乱放，权限别乱开。前期多花一点时间把结构定稳，后面业务增长时会省掉很多麻烦。