混合云部署里最常见的报障现象是：应用所在网段与数据库所在网段已经连通，但连接间歇性超时——新建连接慢、批量任务在固定时段断开、监控里表现为超时而非拒绝。连接被拒绝通常意味着链路通了但端口没放行，超时则往往指向路由不可达、回包路径丢失或被中间设备静默丢弃，排查方向不一样。
下面按现象 → 可能原因 → 逐项排查顺序 → 预防措施展开，涉及的检查项以云厂商通用控制台能力为依据，具体路径以实际环境为准。
先分清超时与拒绝：定位问题的第一步
把「连不上」拆成三类，后续排查才有效率。
- 连接被拒绝：目标主机的端口没有监听，或安全组显式拒绝。报文到达了目标，链路本身是通的。
- 连接超时：请求报文或返回报文在某一跳被丢弃。常见于路由缺失、安全组只放行单向、网络 ACL 拦截、跨网段 MTU 不一致。
- 握手成功但随后断开：比较像空闲超时策略、会话表老化或中间设备的状态检测问题。
建议先在应用侧与数据库侧分别抓包或用 telnet、nc 一类工具测端口。应用侧看的是 SYN 有没有发出、有没有收到回包，数据库侧看的是 SYN 到没到达。两边对照，问题落在哪一段基本就能确定下来。
如果混合云架构本身是新建的，需要在设计阶段就把网段规划、出口方式与回程路由定下来，这部分工作建议纳入软件定制开发与系统集成服务的方案设计环节一并评审，而不是等出问题再补。
VPC 路由表排查：去程和回程都要看
路由问题是跨网段超时的第一大来源，而且它隐蔽——因为去程通、回程不通时，工具显示的往往是「连接已建立但没响应」。排查时不能只看应用所在子网的路由表，还要看数据库所在子网的路由表。
逐项确认的点
- 应用侧子网的路由表里，是否有指向专线网关、VPN 网关或对等连接的目标网段条目。
- 数据库侧子网的路由表里，是否有指回本地机房的网段条目。回程路由缺失是最常被忽略的一项。
- 多个路由表之间存在重叠网段时，最长前缀匹配是否落到了预期的那一条。
- 跨账号或跨 VPC 场景下，对端是否接受了连接请求，路由是否批准生效。
- 使用多可用区部署时，每个可用区的路由表是否都配置一致，避免只有部分实例出问题。
还有一个容易被低估的点：地址冲突。本地机房用了 10.0.0.0/8 这类大网段，云上 VPC 也用了相同或重叠的网段，哪怕路由配了，流量也可能匹配到错误目标。网段规划要在项目早期固定，后期改动牵涉面很大。
安全组与网络 ACL：把「只通一半」排干净
安全组是有方向的。应用发起连接时，数据库侧入方向要放行应用网段到数据库端口；同时数据库侧出方向要允许回包，应用侧入方向要允许来自数据库的高位端口返回流量。很多配置只做了前一半。
排查建议按以下顺序看：
- 数据库实例绑定的安全组，入方向规则是否包含应用所在的具体网段，而不是某个不相关的安全组名称引用。
- 规则是否在默认拒绝之后被覆盖——安全组是允许多条规则的，但排在前面的拒绝规则会直接生效。
- 实例所在的子网是否额外绑定了网络 ACL，ACL 是无状态的，入站和出站要分别配置。
- 是否启用了安全组规则变更后的生效等待，部分策略下发有一定延迟，短时间内的连通性波动不一定代表配置错误。
- 数据库自身是否启用了连接白名单。云数据库的连接白名单与安全组是两层控制，缺一不可。
对国产化环境或政务项目，安全组策略通常还有内部评审要求，建议把规则清单与审批记录一并归档，验收时可追溯。同类型项目的做法可参考政府与国企国产化改造案例。
专线、VPN 与中间网络：看不见的那几跳
当 VPC 内部检查一切正常，但跨网段仍然超时，注意力就要转到云下这一段。
- 专线是否配置了备用线路、主备切换时路由能否收敛。切换瞬间的连接中断常被误报为超时。
- VPN 隧道的加密参数、感兴趣流网段是否与业务网段一致，一侧写了子网明细、另一侧写了整段，就可能出现单向不通。
- 本地防火墙或出口设备是否对空闲连接有老化策略，长事务或定时任务容易被静默中断。
- 跨网段路径的 MTU 是否一致。大包被丢弃时，表现为连接可以建立，但查询大字段或批量写入时卡住。
- 网络地址转换场景下，数据库侧看到的源地址可能是转化后的地址，白名单要按转换后的地址配，否则会超时或拒绝。
这部分建议保留一条随时可用的测试路径，例如在应用所在网段临时起一个探测用主机，出问题时用来隔离是应用侧还是网络侧。详细的部署与联调做法可参考更多技术实现细节中的部署运维专题。
数据库连接池与超时参数：排除应用侧的放大因素
网络排查之后仍要回头看应用。很多「跨网段超时」实际上是网络抖动叠加连接池配置不合理被放大的结果。
与 DBA 和应用开发一同确认：连接池的最小空闲连接数是否过低，导致高峰期频繁新建连接；连接的最大存活时间是否短于中间网络设备的空闲老化时间；获取连接等待时间与查询超时是否设得过短，使短暂抖动直接报错。
还要看是否所有实例都受影响。如果只有某几个节点超时，问题更可能在节点所在子网，而非全局链路。
常见问题
安全组已经放行全部端口，为什么还是超时？ 安全组只是其中一层。回程路由、子网网络 ACL、数据库连接白名单以及云下的出口策略都可能拦截，需要按链路逐段看。
telnet 能通，应用还是报超时，怎么看？ 通只能说明目标端口可达。检查报文大小与 MTU、空闲连接老化时间、连接池配置，以及数据库侧的最大连接数是否已经打满。
改动安全组后立刻恢复，过几天又出现，正常吗？ 说明根因可能不在安全组。更常见的是一次性策略下发让链路暂时恢复，同时另有路由收敛或设备老化的问题仍在。建议保留排查记录，对照故障时间点与网络变更记录。
可照着做的自查清单
- 确认故障形态：连接超时、端口拒绝还是连接建立后断开，两边抓包核对。
- 检查应用侧子网路由表，确认去程有条目；检查数据库侧子网路由表，确认回程有条目。
- 检查是否存在地址段的重叠与最长前缀匹配异常。
- 检查数据库安全组入方向是否放行应用所在的具体网段，出方向是否允许回包。
- 检查子网网络 ACL 的入站与出站规则是否对称配置。
- 检查数据库自身连接白名单是否包含应用侧源地址，经过转换的按转换后地址核对。
- 检查专线与 VPN 的主备状态、感兴趣流网段、隧道是否有丢包。
- 检查路径 MTU 一致性与中间设备空闲连接老化时间。
- 检查应用连接池的空闲连接、最大存活时间与获取超时配置。
- 把上述配置以截图或清单形式归档，纳入变更管理与运维交接材料，后续排障不用从头来。
跨网段排查的本质是把链路拆段、逐段验证，而不是反复重配某一处。我们做过的同类交付见同类项目案例。
