客户反馈公司站点访问慢，本地 traceroute 看着一路正常，抓包却发现回包从另一个运营商绕了大半个中国才回来。

去程和回程是两条独立的路

数据包从客户端到服务器走一条路径，返回时走另一条，BGP 各算各的最优。去程经过的机房，不代表回程也走那里。跨运营商访问时，两边选路不对称很常见，尤其是多线机房只优化了去程。

怎么验证回程

在服务器上 traceroute 客户端公网 IP，和客户端 traceroute 服务器对比，两条路径的 AS 号不一样就说明不对称。mtr -r -c 100 双向各跑几分钟，看丢包出现在第几跳。云主机上注意安全组是否放行 ICMP，不放行的话看到的全是星号。

回程绕路的常见原因

  • 多线机房：策略路由只优化了去程，回程仍走默认出口
  • BGP 前缀：宣告的网段和实际出口不一致
  • 运营商互联：两家之间带宽紧张，选路绕开拥堵点
  • 云厂商出口：NAT 后的回程由云侧决定，用户改不了

能做的优化

找运营商加回程路由，或者上 BGP 多线，让回程也走同一家。智能 DNS 按运营商解析到对应线路，CDN 回源也按线路选。非对称路由还会让状态防火墙丢包，排查时把会话表一起看，别只盯着带宽。

排查时容易漏的点

用 ping 看延迟只能看到往返总和，分不清去和回。tcpdump 在两端各抓一段，对比时间戳和 TTL，能判断绕路方向。TTL 每经过一跳减一，回包初始值不同，也能反推路径长度。

多线和 CDN 场景

机房有三条线路时，去程按源地址选路，回程常回到默认网关。用策略路由把回程也绑到对应运营商，配置前先确认对端 AS 和下一跳，配错会直接断网。CDN 回源同理，回源 IP 走哪条线，用户拿到的内容就从哪条线回来。

只测去程等于只查了一半。回程路径要单独跑一遍，否则优化方向从一开始就是错的。