防护设备已部署，不代表流量一定经过它。云虚拟网络路由表防止流量绕过防护，关键是核实每个子网实际采用的路由、下一跳和返回路径。路由配置还受云平台规则影响：AWS VPC、Azure 虚拟网络和 Google Cloud VPC 的路由关联与优先级机制并不完全相同，不能只凭配置名称判断流量走向。
六个常见配置误区
1. 检查了路由表，却漏看子网关联
路由表配置正确，不等于目标子网正在使用它。以 AWS VPC 为例，子网可能关联自定义路由表，也可能使用主路由表；Azure 用户定义路由（UDR）需要关联到相应子网。应逐个核对业务子网、管理子网和新建子网的实际关联，避免有的网段经过检查设备，有的仍走原有路径。
2. 默认路由的下一跳指向直连出口
检查 0.0.0.0/0（IPv4 默认路由）和 ::/0（IPv6 默认路由）分别指向哪里。若设计要求出站流量先经过检查设备，默认路由就不能在某些子网中直接指向互联网出口或其他未检查的网关。云平台支持的下一跳类型不同，配置前要确认目标资源、所在网络及路由限制。
3. 忽略更具体的路由
多数网络按最长前缀匹配选择路由：目的地址同时匹配 /16 和 /24 时，通常优先采用范围更小的 /24。于是，一条看起来无害的明细路由，可能让部分地址绕开原本的默认路径。排查时不仅看默认路由，还要搜索覆盖目标网段的明细路由；平台另有优先级或策略规则时，也要一并核验。
4. 只验证去程，没有检查回程路由
流量经过中间检查设备后，返回流量若从另一条路径直达客户端，可能形成非对称路由。对于依赖连接状态的设备，这会造成连接中断或检查不完整。分别查看请求和响应方向的路由，并确认两端子网、对等连接、VPN 或专线相关路由没有把回程导向其他出口。
5. 忘记对等连接与路由传播带来的旁路
VPC 对等连接、VPN、云专线及动态路由传播，可能增加新的可达路径。它们本身并不必然绕过防护，但若某网段获得了直达目标的路由，就要确认该路径是否符合检查策略。变更时记录新增路由来源、传播范围和影响的子网，不能只检查手工添加的静态路由。
6. 只测 IPv4，或漏掉新网卡与新子网
双栈网络中，IPv4 和 IPv6 路由需分别核查；只验证 IPv4，无法证明 IPv6 也经过同一防护路径。实例新增网卡、扩展网段或新建子网后，也应重新检查路由关联和安全设备覆盖范围。云虚拟网络路由表防止流量绕过防护，必须覆盖实际启用的地址族和网络接口。
按转发路径逐项核查
- 列出流量范围：记录源子网、目标网段、协议、方向，以及需要经过的检查设备或出口。
- 确认路由关联：在云控制台或配置清单中，逐个查看相关子网实际绑定的路由表；区分主路由表、显式关联和平台自动传播的路由。
- 追踪下一跳：检查目的网段匹配的全部路由，重点查看默认路由、较具体的路由及其目标资源。必要时对照 AWS VPC Route Tables、Azure 有效路由视图或 Google Cloud 路由信息。
- 双向验证：从受控测试主机分别发起出站和回程测试，结合路由视图、流日志及检查设备日志确认实际路径。Traceroute 可能受过滤或云网络实现影响，不宜单独作为路径证明。
- 变更后复测：变更路由或子网关联后，重测 IPv4、IPv6 和相关网段，并保存变更前后的路由记录与测试结果。
若发现旁路，先确认它是预期的管理、备份或内网路径，还是未经设计的出口；再调整关联或下一跳，并评估对回程连通性的影响。云虚拟网络路由表防止流量绕过防护，靠的不是单条默认路由，而是完整转发路径与回程路径都符合设计。
常见问题
路由表里有默认路由，就代表所有流量都走它吗？
不一定。更具体的路由通常优先匹配，且不同云平台还可能使用优先级、路由传播或其他规则，应检查实际匹配结果。
为什么防护设备有日志，仍可能存在旁路？
日志只能证明部分流量到达设备，不能证明所有子网和地址族都经过设备。还需核对路由覆盖范围及未出现于日志的测试流量。
调整路由后首先复测什么？
先测目标业务的去程与回程，再覆盖 IPv4、IPv6、相关子网及可能受影响的对等连接或专线路径。