两台计算实例都显示运行正常，私网地址也在同一网段，连接却超时，问题未必出在实例本身。计算实例私网互通故障的安全组与路由排查，应先确认流量是否有路可走，再检查请求方向和返回路径，避免只反复放宽规则。
先把通信条件说清楚
记录发起端和接收端的私网 IP、目标端口、协议，以及访问方向。例如，一台 Linux 实例通过 TCP 访问另一台实例的 443 端口，与 ICMP ping 测试不是同一件事：前者验证具体服务端口，后者验证网络层可达性，且可能被单独禁用。
还要核对两端所在的虚拟网络、子网和网段。实例分别位于不同子网时，不能仅凭“同一私网”推断一定互通；跨虚拟网络通信还可能依赖对等连接、网关或专用路由配置。检查实际生效的路由表，而不只看配置页面中的规则名称。
按路径定位故障
- 验证服务端口。在接收端确认服务进程正在监听目标端口，并检查操作系统防火墙。Linux 可用 ss -lnt 查看 TCP 监听情况；从发起端用 nc -vz 目标私网 IP 端口测试连接。连接拒绝通常说明主机可达但端口未监听或被拒绝；超时则还需继续检查网络策略和路径。
- 逐条检查安全组规则。确认发起端出站规则允许相应协议和目的端口，接收端入站规则允许来自发起端地址或其所属安全组的流量。规则应尽量限定来源网段、协议和端口，不要为了测试长期开放所有来源。部分云平台安全组具有有状态特征，但具体行为和规则优先级应以平台说明为准。
- 核对路由表。查看目的网段是否匹配一条有效路由，以及下一跳是否指向正确的本地网络、对等连接或网关。最长前缀匹配会优先选用更具体的网段；一条宽泛路由存在，并不代表实际流量一定走它。可在 Linux 上用 ip route get 目标私网 IP 查看本机选路结果。
- 检查返回路径和网络 ACL。请求能到达接收端，不代表响应一定能回到发起端。跨网段或经过网关时，要确认两侧都有正确路由。若网络 ACL 是无状态的，返回流量也需要相应规则；临时端口范围和规则顺序应按平台及系统配置核实。
根据现象缩小范围
同子网实例互通失败
优先核对两端安全组、实例内防火墙、目标服务监听地址，以及子网关联的路由和网络 ACL。服务若只绑定 127.0.0.1，只能接受本机连接；即使安全组放行，其他实例仍无法访问。
跨子网或跨网络失败
分别检查两端路由表和连接状态，并确认网段没有重叠。以常见的云网络对等连接为例，连接建立后仍需配置两侧指向对端网段的路由；它通常不等同于自动提供 NAT 或完整的跨网络转发能力。
如果权限允许，可在接收端用 tcpdump 观察目标端口流量：能看到 SYN 却没有响应，重点查服务、防火墙及回程；完全看不到请求，则回头查发起端选路、安全组、网络 ACL 和中间网关。抓包内容可能包含敏感信息，应控制权限和保存时间。
修复后做最小范围复测
每次只调整一项规则或路由，记录变更前后的来源、目的、协议和端口，再用同一条连接测试。修复后删除临时放宽的规则，并从两个方向验证必要业务端口。计算实例私网互通故障的安全组与路由排查，关键是沿实际路径逐跳验证：主机是否监听、规则是否允许、路由能否到达、响应能否返回。
常见问题
能 ping 通，为什么应用仍连接失败？
ping 使用 ICMP，应用通常使用 TCP 或 UDP。还要检查应用端口、监听地址和对应协议的安全规则。
同一子网还需要检查路由吗？
需要确认子网实际关联的路由和网络策略；同时检查主机防火墙及服务状态，不能只凭网段相同判断。
安全组是否需要同时配置入站和出站？
视平台的状态跟踪机制及现有规则而定。先确认发起方向和目标端口，再按平台规则语义核查双向流量。
怎样区分安全组问题和路由问题？
结合路由查询、规则核对与接收端抓包判断：无有效下一跳偏向路由问题，流量到达实例但被拒绝则重点检查安全组、主机防火墙或服务。