type
status
date
slug
summary
tags
category
icon
password
家里一直在使用Dae（基于eBPF的透明代理工具配合RouterOS做OSPF分流。前阵子玩giffgaff卡，给微信绑定了英国的手机号之后，发现微信加载图片速度异常缓慢。具体表现为：朋友圈图片加载转圈很久；图片需要等待数秒才能显示；视频更是频繁超时。更奇怪的是，如果使用移动网络，同时使用Surfboard时微信图片加载完全正常。
📝 初步排查：DNS之谜
1. 第一反应：DNS污染
因为在国内，所以首先怀疑是DNS解析出了问题。于是先用ProxyPin获取了微信请求的域名列表，然后对其中的sgshort.wechat.com抓取了DNS查询日志：
返回的IP是43.160.144.21，这是一个新加坡的IP地址，符合sg的前缀。正常情况下，国内用户应该解析到深圳或上海的节点（如 szshort.wechat.com），而绑定国外手机号的微信账号，默认会将数据存储在新加坡的数据中心，并使用新加坡的CDN，所以分配到sgshort.wechat.com 也就不意外了。
2. 检查DNS上游配置
Dae的DNS配置如下：
尝试强制指定上游为阿里云DNS(alidns)，但问题依旧。
3. 关键发现：Surfboard也返回同样IP
在关掉WIFI之后，使用移动网络和Surfboard这个配置，正常工作时执行同样的dig命令，返回的IP也是 43.160.144.21 ，所以确认这不是DNS问题，而是微信服务器端根据账号信息主动分配了海外节点。
📝 再次排查：OSPF路由分析
1. 抓取流量日志
在Dae所在机器，使用journalctl -xeu daed -f | grep "wechat" 抓取实时日志，发现一个关键信息：
那么流量确实走了direct（直连），和Surfboard一样（我Surfboard配置了微信直连），那么理论上应该两者的速度是一样的，不应该加载视频或者图片会卡。
2. 检查nchnroutes脚本
对nchnroutes脚本进行重新检查，主要是目录下的produce.py 脚本。这个脚本的逻辑是：
- 获取中国 IP 列表
- 做减法，生成**非中国 IP 列表**
- 将非中国 IP 路由到旁路网关（`--bypass-gw`）
3. 查找关键路由
使用命令grep "43.160" routes4.conf 查找关键路由，发现信息：route 43.160.0.0/12 via "ens18"; ，那么意味着 43.160.0.0/12 这个 IP 段被识别为"非中国 IP"，并被路由到了旁路网关 ens18。那么问题就在于，当微信分配CDN为新加坡数据中心时，触发了OSPF的分流，将流量重定向到了旁路网关来，然后旁路网关尽管配置了直连，但是还是对图片、视频等资源加载产生了影响。
通过 WHOIS 查询 43.160.0.0/12：ACEVILLE PTE.LTD， 实际使用者为腾讯云，这个IP段虽然注册在新加坡公司名下，但实际上是腾讯云租用的海外CDN节点，专门用于微信的图片和视频分发。
📝 临时解决方案：手动移除路由
由于我不太了解Dae具体直连实现如何，以及为何会影响到微信，所以只能采用粗暴一点的方式，直接移除涉事路由。
在BIRD配置中注释掉或删除route 43.160.0.0/12 via "ens18"; ，这一行。同时对OSPF路由表生成的程序进行优化，增加保留的IP范围：
然后重新make生成新的OSPF路由表，并重新载入Bird配置文件。移除路由后，再次打开微信，图片加载速度恢复正常。
🤗 经验总结
1. 不是所有海外 IP 都要走旁路网关
某些**腾讯云海外节点**（包括微信 CDN）通过 Anycast BGP 优化，从国内直连反而比走普通国际出口更快。 2. OSPF 分流的边界处理 OSPF 分流的核心逻辑是"中国IP走主网关，海外IP走旁路"。但在实际运营中，需要对特殊的海外节点（如腾讯云海外CDN）进行人工干预，不能完全依赖自动化的IP列表。
如果你也遇到了类似的微信图片加载问题，不妨检查一下你的路由表里是否有 43.160.0.0/12 这条记录。移除它，可能就解决了。
📎 参考文章
有关Dae安装或者使用上的问题，欢迎您在底部评论区留言，一起交流~ 版权声明：本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明出处！