大家吼啊，这里是你们的kisa猫娘喵~ 今天咱要聊一个让很多网络折腾党头秃的问题：为什么微信绑了英国手机号之后，图片加载转圈转到怀疑人生？ 明明网络配置得花里胡哨，结果连个朋友圈都刷不出来，这谁顶得住啊喵！(´；ω；`)
先声明，咱不是标题党，这是真实案例。有位老哥家里用了Dae（基于eBPF的透明代理工具）配合RouterOS做OSPF分流，结果微信图片加载慢到炸裂——朋友圈转圈数秒，视频频繁超时。更诡异的是，换到移动网络+Surfboard就一切正常。你说气不气人？今天咱就从技术实现角度，一层层扒开这问题的皮，看看里面到底藏着啥妖孽喵~
---
第一步：DNS排查——看似背锅，实则无辜
第一反应肯定是DNS污染嘛，毕竟国内环境大家都懂。于是抓了sgshort.wechat.com的DNS查询日志，发现返回的是43.160.144.21，一个新加坡IP。正常情况下国内微信用户应该解析到szshort.wechat.com（深圳）或shshort.wechat.com（上海），但绑定了国外手机号的微信账号，数据默认存新加坡数据中心，CDN也分到新加坡，所以这个结果合情合理。
关键测试来了：把Dae的DNS上游强制换成阿里云DNS，问题依旧。更绝的是，在Surfboard正常工作的情况下，dig命令返回的也是同一个IP。这就说明问题不在DNS，是微信服务器根据账号信息主动分配了海外节点。好嘛，锅甩不出去，继续查喵~
第二步：流量走向——直连还是绕路？
Dae日志里抓到了关键线索：微信流量走了direct（直连）。Surfboard那边也配置了微信直连，理论上两者应该一样快才对啊？可现实就是Dae这边卡成狗，Surfboard那边丝般顺滑。这不科学！(๑•̀ㅂ•́)و✧
于是翻出nchnroutes脚本，这里面有个produce.py，逻辑很简单：获取中国IP列表，做减法生成非中国IP列表，然后将这些非中国IP路由到旁路网关（--bypass-gw）。然后grep "43.160" routes4.conf一看，好家伙——
route 43.160.0.0/12 via "ens18";
43.160.0.0/12这个IP段被判定为“非中国IP”，直接路由到了旁路网关ens18。再跑个WHOIS查一下这个段：ACEVILLE PTE.LTD，实际使用者是腾讯云。这个IP段虽然注册在新加坡公司名下，但其实是腾讯云租用的海外CDN节点，专门用于微信图片和视频分发。
---
第三步：原理深扒——猫腻藏在路由路径里
为什么直连了还慢？网关路由路径的猫腻
这里首先得搞懂一个关键拓扑差异：Surfboard 通常作为手机本地的 VPN 隧道，它说“直连”，数据包直接从手机网卡出去，真的不发代理；而 Dae 是跑在网关层的，OSPF 把 43.160.0.0/12 指向旁路网关的那一刻起，数据包就被强制拉到了 ens18 这个旁路网关上。
咱推测，Dae 的 direct 标记很可能只是告诉透明代理模块“这条流别碰”，但数据包本身已经先被路由到旁路网关的物理接口上了——旁路网关本身就是通往国际出口的通道。也就是说，OSPF 这一步已经把流量送进了“海外出口”这条流水线，哪怕后面配置了直连，它也得先经过这条流水线的第一站，凭空多出一跳，甚至可能触发额外的路由判断或 NAT 处理，延迟自然就上来了。而 Surfboard 是真·本地直连，完全不走这趟折腾。原作者也坦言自己不太懂 Dae 直连实现的细节，所以这部分暂时是合理的推测，但多一跳导致延迟增加这个底层逻辑是确定的。(๑•́ω•̀๑)
为什么“海外IP”直连反而更优？Anycast的魔法
然而故事还没完：就算流量被送去旁路网关→国际出口，为什么反而比直连主网关慢那么多？这里就要请出 Anycast BGP 这个神奇设定了。
这个 43.160.144.21 虽然注册在新加坡，但腾讯云通过 Anycast 技术，在全球多个节点宣告同一个 IP。当你在国内访问它时，电信/联通/移动的骨干网会按照最近的 BGP 路径，直接把你引到腾讯云部署在国内的边缘节点——数据根本没出国，延迟当然低。
可是一旦 OSPF 错误地把这个 IP 段归类为“海外”，硬把流量往旁路网关（国际出口）塞，就等于自废武功：明明家门口就有服务器，却被强制绕到国际线路跑一圈再回来，延迟爆炸也是理所当然。所以根因就是——OSPF 的二分法让一个原本直连更优的“假海外IP”被错误分流，而 Anycast 则放大了这条错误路径的代价。
---
第四步：解决方案——粗暴但有效
老哥的直接做法是：在BIRD配置中注释掉route 43.160.0.0/12 via "ens18";，并优化路由生成程序，把这个段加到保留列表里。然后重新make生成OSPF路由表，重载Bird配置。移除后，微信图片加载速度恢复了正常。简单粗暴，但有效喵~
---
咱的观点：OSPF分流的边界处理，不能无脑
这件事给咱最大启发是：OSPF分流的核心逻辑是“中国IP走主网关，海外IP走旁路”，但这个二分法在面对腾讯云海外CDN时就失效了。因为这些CDN节点虽然是海外IP，但依靠 Anycast 在国内就能就近接入，直连主网关的延迟远低于走国际出口绕圈圈。
更好的做法是：建立例外清单，把那些“海外IP但直连更优”的段手动加入白名单，比如腾讯云、阿里云、华为云的海外CDN段。至于用延迟测量动态调整路由这种玩法，属于进阶操作，咱觉得家庭网络目前最稳妥的姿势还是老老实实维护一份手动例外列表，毕竟稳定压倒一切喵~ (๑•̀ㅂ•́)و✧
---
最后喵~ 如果你也在折腾OSPF分流，遇到了微信图片加载慢，不妨查查路由表里有没有43.160.0.0/12这条记录。移掉它，世界就清静了。当然，Dae的直连实现细节咱也期待有大佬评论区补充，一起探索喵~
咱要去喂猫罐头了，下次见！(๑•̀ㅂ•́)و✧ 记得留言互动哦~ 点赞过100，咱就出一期Dae配置避坑指南喵！
