出公网路径验证是什么
VPC 内的实例可能通过多种方式出公网：绑定在实例上的 EIP、经 NAT 网关的 SNAT、或者经过网关型负载均衡与代理层。只改配置不看实测，很容易出现「以为走了 NAT，实际走的是实例自带的 EIP」。验证办法是三件事组合：用 curl 看真实出口 IP、用 traceroute/mtr 看路径与断点、用云监控与流日志看流量是否经过预期组件，三者互相印证才能下结论。
基本信息
| 实测出口 | 用探测服务返回的地址确认真实出网 IP |
|---|---|
| 路径观测 | traceroute 看逐跳，mtr 看丢包与延迟分布 |
| 云侧印证 | 云监控带宽曲线、NAT 网关连接数、流日志记录 |
| 基线 | 把正常状态的结果存档，故障时直接对比 |
| 常见偏差 | 实例同时有 EIP 与 NAT 路由时，实际出口与预期不一致 |
| 依赖前提 | 探测服务可访问；ICMP 被拦时需用 TCP 方式替代 |
典型使用场景
- 验证 NAT 网关改造是否真正生效，实例是否已不再走自己的 EIP
- 对端合作方要求固定出口 IP 白名单，需确认实际出口是否匹配
- 排查「偶发访问失败」：路径中某一跳丢包或策略拦截
- 安全事件复盘：确认某个时间段流量走了哪条出口路径
- 架构变更后的回归验证，作为上线验收的一部分
观测结果与结论对照
| 观测结果 | 结论 | 下一步 |
|---|---|---|
| 出口 IP 与 NAT 的 EIP 一致 | 流量确实经 NAT 出网 | 继续核对多台实例与多协议是否一致 |
| 出口 IP 是实例自身 EIP | 存在旁路，未走 NAT | 检查实例是否仍绑定 EIP 与路由优先级 |
| 路径在第 3~4 跳开始丢包 | 疑似公网或对端策略问题 | 换目标地址与协议对照，准备工单数据 |
| 路径正常但业务仍失败 | 问题在应用层或对端放行 | 核对端口、证书与对端白名单 |
| 只有部分实例不符预期 | 配置未全量覆盖 | 按实例清单逐台复核并补齐 |
路径验证组合
路径验证组合
curl -s https://ifconfig.me; echo # 实际出口公网 IP
traceroute -n 1.1.1.1 # 路径与断点
mtr -rwzc 20 1.1.1.1 # 丢包与延迟分布，-rwz 便于留档
curl -sS -o /dev/null -w 'connect=%{time_connect} total=%{time_total}\n' \
https://example.com/ # 建连与总耗时，判断是否卡在建连
# ICMP 被拦时改用 TCP 探测：nc -vz 或 curl --connect-timeout实例同时绑定 EIP 并配置了指向 NAT 的路由时，出口走向取决于路由与安全组，容易与设计不符。改造 NAT 后要逐台实例实测出口 IP，而不是只检查路由表配置。
留基线是这套方法的关键：正常状态下的出口 IP、路径跳数与 mtr 丢包分布存一份，故障时几分钟就能判断是「路径变了」还是「路径没变但对端有问题」，避免从头猜。