子网划小了会出什么问题？聊聊华为云 VPC 的网段、子网与安全组

很多网络故障并不是一开始就报错，而是在业务长大之后才突然出现：新机器加不进去，地址不够分，两个环境一打通就冲突，防火墙规则越改越乱。回头看，问题往往出在最开始的规划上。虚拟私有云 VPC 的网段、子网和安全组，看起来只是建云资源时的几个选项，实际上决定了以后能不能扩容、能不能互通、出了问题好不好查。这篇文章就把这三件事讲清楚：网段怎么选，子网怎么划，安全组怎么写，路由和排查又该按什么顺序做。

一、先理解三者的关系

可以把 VPC 理解成一个逻辑上的专属网络，子网是这个网络里按区域和用途划分出来的小区，安全组则是挂在云服务器、数据库等资源上的一道虚拟防火墙。网段决定了整个 VPC 最多能容纳多少地址，子网决定了这些地址怎么分配，安全组决定了哪些流量可以进出。网段定错了，后面再怎么调子网和安全组都很被动；子网划乱了，地址管理和故障定位都会变难；安全组写宽了，等于把门打开了还不知道。

二、网段怎么选：先算地址，再留余量

选网段的第一步不是看哪个数字顺眼，而是先估算地址需求。把现在要用的云服务器、负载均衡、数据库、容器节点、预留地址都列出来，再乘上未来一段时间可能的增长。很多人只算了眼前的机器数量，忽略了弹性扩容、滚动升级、测试环境和新项目，结果子网刚用几个月就满了。

地址的数学关系本身并不复杂。掩码越小，可用地址越多；掩码越大，可用地址越少。例如一个 /24 网段理论上有 256 个地址，而 /28 网段理论上只有 16 个地址。实际可用地址还要再扣掉网关、广播、系统保留等用途，具体保留情况以控制台和官方文档为准，所以规划时一定要把这部分余量算进去，不要按理论最大值排满。

一个实用的做法是：先给 VPC 一个相对宽松的网段，再按用途切分子网，中间留出一段连续的空白地址作为扩容缓冲。宁可一开始多留一点，也不要把每个子网都切得刚刚好。地址规划最怕的不是浪费一点，而是后期没有办法再切出一个可用的子网。

三、子网划小了会出什么问题

子网划得太小，最直接的问题就是地址不够用。弹性伸缩要扩节点时没有地址，新的服务实例起不来；想给某个子网再加一台机器，却发现地址池已经满了。这时常见的临时办法是再建一个子网，但新子网和老服务之间的访问关系、路由关系、安全组关系都要重新梳理，反而增加了出错的可能。

第二个问题是扩容时容易打乱原来的分区思路。本来按业务、按环境、按可用区划分得很清楚，一旦地址不够，就只能把不同用途的资源挤到同一个子网，或者临时借用别的子网。这样一来，子网的边界就失去了意义，后面做访问控制、流量分析、故障隔离时都更难下手。

第三个问题是和扩容、迁移相关的连锁改动。子网地址不足时，有时不得不重新规划网段，而已经在运行的资源改网段并不像改一个配置那么简单，可能涉及重建、迁移和停机窗口。相比之下，前期多留余量、按可用区和用途留出备用子网，成本要低得多。

四、子网规划最常见的几个错误

第一个错误是子网之间、或者和线下机房、其他 VPC 的网段重叠。只要两个要互通的网络地址重叠，路由就很难区分流量该往哪里走，互通往往做不起来，或者出现时通时不通的奇怪现象。所以在规划前，先把已有网络的网段清单整理出来，包括线下机房、其他云账号、其他区域的 VPC，再决定新网段。

第二个错误是没有任何备用子网。所有地址一次性分光，看似整齐，实际上等于把未来的路堵死了。比较稳妥的做法是：按业务和可用区划分主子网，同时在每个区域留一个备用子网，或者在 VPC 里留一段未分配的连续地址。

第三个错误是按人、按项目随意切分子网，而不是按用途和生命周期划分。建议用相对稳定的维度来划分：生产和测试分开，不同业务线分开，不同可用区分开，数据库等有状态服务和管理类服务也可以单独放。这样即使某个子网出问题，影响范围也更容易控制。

第四个错误是命名和记录缺失。子网名字写成 test1、test2，过几个月谁也记不清用途。建议在名称或描述里写清楚环境、业务、可用区和地址范围，并把网段分配表保存下来，团队里任何人都能查到。

五、安全组：最小权限比写得多更重要

安全组的核心原则是最小权限：只放行确实需要的流量，其他一律不放行。很多故障和安全问题都来自两类极端：一种是图省事放行全部地址和全部端口，另一种是规则写得太严，把正常业务也拦住了。两者都要避免。

写规则时先问三个问题：谁要访问，访问哪个端口，用什么协议。来源尽量写具体的地址段或安全组，而不是直接写全部地址；端口尽量写业务实际使用的端口，而不是一个很大的范围；协议按实际需要选择，不要顺手把所有协议都打开。对管理端口尤其要小心，只允许来自运维跳板机或办公网等可信来源的访问。

方向也要分开想。入方向规则控制别人能不能访问这台资源，出方向规则控制这台资源能不能主动访问外面。排查时经常发现问题不在入方向，而在出方向：例如应用需要访问数据库、对象存储或者外部接口，出方向被限制后，表现出来的症状却是业务接口超时。把入方向和出方向当成两张不同的表来检查，能少走很多弯路。

优先级和匹配顺序也值得单独检查一遍。安全组规则通常按控制台展示的顺序依次匹配，排在前面的规则会先起作用。如果一条宽松规则排在前面，后面再写严格规则也很难生效。调整规则后，建议从上往下完整读一遍，确认没有被前面的规则意外放行，也没有被前面的规则意外拦截。

另外，安全组是挂在资源上的，改动会立刻影响该资源。修改前先确认这条规则影响了哪些资源，修改后马上验证业务是否正常。不要同时改多个地方，否则出了问题很难判断是哪一次改动引起的。

六、路由表：流量走错路，常常不是安全组的问题

子网关联的路由表决定了流量下一跳去哪里。常见的路由问题有几种：目标地址没有对应的路由，流量不知道往哪里走；默认路由指向了错误的下一跳；需要走专线或对等连接的流量，却走了互联网出口；两个子网的路由表被弄混，导致本该内部互通的流量绕了远路。

检查路由时，先确认子网关联的是哪张路由表，再看这张表里有没有到目标地址的路由，以及下一跳是不是预期的网关、NAT 网关、对等连接或专线网关。还要确认对端网络有没有回程路由：去程通了、回程没有路由，业务同样不通。很多跨 VPC、跨机房的问题，最后都卡在回程路由上。

路由和安全组要配合着看。路由决定能不能到达，安全组决定到没到达后放不放行。只查其中一个，很容易得出错误的结论。建议排查时把两者放在同一张检查清单里，逐项打勾。

七、常见故障的排查顺序

遇到网络不通时，不要一上来就改配置，先按固定顺序定位。第一步，确认源和目标的地址、子网、可用区有没有写错，资源本身是不是正常运行。第二步，检查安全组：入方向是否放行了来源和端口，出方向是否放行了目标和端口。第三步，检查路由表：有没有到目标的路由，下一跳对不对，对端有没有回程路由。第四步，检查网段有没有重叠，目标地址是不是落在了另一个网络里。第五步，再看网关、NAT、对等连接、专线等中间环节的状态。

如果仍然找不到原因，可以把问题范围缩小：换一个同子网的目标试试，换一个不同子网的目标试试，换一个端口试试。这样能快速判断是单台资源的问题、子网的问题，还是跨网络的问题。每次只改一个地方，改完马上验证，验证通过再继续下一步。

八、动手前的检查清单

在创建 VPC 之前，先把这张清单过一遍：业务现在和未来一段时间的地址需求估算了吗，是否留了扩容余量；网段是否和线下机房、其他 VPC 冲突；子网是否按环境、业务和可用区划分，是否留了备用子网；子网名称和地址分配表是否记录清楚；安全组是否按最小权限编写，管理端口是否只对可信来源开放；路由表是否区分了内网流量和出云流量，对端是否有回程路由；变更后是否有人负责验证业务。

网络规划最难的不是某一个配置项，而是把网段、子网、安全组和路由当成一个整体来设计。网段留有余量，子网边界清晰，安全组只放行必要流量，路由表去程和回程都配齐，后面的扩容、互通和排查都会轻松很多。希望这篇文章能帮你在下一次建 VPC 之前，少踩几个子网划小、网段重叠、安全组过宽的坑。