WiFi Calling 死活拉不起来？教你在软路由上搞定
文章目录
今天想赶在 Tello 手机卡可以在欧洲 IP 激活漫游的最后几天上车，半夜开始折腾。
前期开 eSIM、付款什么的都很顺利，但是到了 WiFi Calling 这一步卡了一个多小时。
其实我之前拉起 1psim 的 WiFi Calling 时也有类似的问题，但只要关了梯子就能拉起，我就没深究。
但这次不行，梯子不能关。为了保证成功，我最好通过欧洲 IP 来拉起 WiFi Calling，所以必须解决这个问题。
好在最后也是解决了，成功上车 Tello，WiFi Calling 秒拉。
所以，如果你日常在软路由上使用 OpenClash，也遇到了 WiFi Calling 无法拉起的问题，本文记录了解决问题的几个要点，包括我遇到的共性和个性问题，以及对应的解决办法：
-
共性：基本上每个人都或多或少会遇到
-
个性：可能只有我这份 Clash 配置会遇到的问题
希望能帮到你！
先扫盲：什么是软路由？什么又是 OpenClash？
大部分人用梯子，其实还是在设备上装客户端，比如 iOS 的小火箭、Mac 的 Surge、各种乱七八糟的 Clash 客户端。
你有 10 个需要用梯子的设备，就要装 10 个客户端，是不是很繁琐？
这个时候，软路由的作用就体现出来了。
首先，软路由其实就是一个小型 PC，有 CPU、主板、内存条和硬盘等等。和传统 PC 相比，它更省电、网口更多，通常需要 24 小时开机。
这就是我的软路由（服役多年，灰有点大）：
还有就是它上面一般不装 Windows 这类系统，而是装 OpenWrt 这样的软路由系统。OpenWrt 上有很多好用的插件，比如 OpenClash，它就是一个可以安装到 OpenWrt 上的 Clash 客户端。
下面直接说我是怎么用软路由的：
-
我的软路由在家庭网络中担任主路由的角色（也可以做旁路由，这个具体看 YouTube）；
-
我把光猫改为桥接，拨号由软路由负责；
-
把无线路由器通过网线连到软路由，改为 AP 模式，只负责 WiFi；
-
软路由上的 OpenClash 负责梯子，这样的话家里的设备都可以通过一个 OpenClash 爬🪜。
共性问题
先说说会遇到的一些共性问题，基本上很多人解决这些问题就可以正常使用 WiFi Calling 了。
UDP 支持问题
很多人出去用的还是机场节点，但很多机场会禁止转发 UDP 流量，有的即使没有完全禁止 UDP，也会限制端口。
如果机场开放 UDP 流量，就可能有人利用机场节点，对其他网站发起 DDoS 攻击。UDP 比 TCP 更容易发起攻击且不好处理。最后，被攻击的机房就可能直接拉黑机场当前节点的 IP，这对机场的损失是挺大的。
而 WiFi Calling 需要 UDP 才能拉起，用到的端口是 500 和 4500，这也就导致了很多人无法拉起 WiFi Calling。
所以，如果你遇到了这个问题，首先建议询问机场是否禁止 UDP，或者自己用 VPS 搭建节点。一般自己的 VPS，默认不会禁止 UDP。
我在激活 Tello 时，欧洲节点用的是 edgetunnel 这个可以部署到 Cloudflare 的服务，也就是说它是支持 UDP 转发的。
最后，最好再检查一下 OpenClash 里的 UDP 流量转发 是否开启，路径是「插件设置 → 模式设置 → UDP 流量转发」。
PS：改完不会立即生效，需要应用配置，重启内核后才会生效。
Fake-IP 模式
上一步如果还没解决，你折腾的时候，可能会尝试 Google 一下：OpenClash WiFi Calling。
然后你就发现了官方 GitHub 仓库的这个 issue：
很好，这个 issue 已经关闭了，而且还是 24 年的。看着里面的讨论，我发现得先弄明白 Fake-IP 模式。
用 OpenClash 的朋友百分之 99 用的都是 Fake-IP 模式，因为它是默认的。
什么是 Fake-IP 模式？设备查询一个域名时，OpenClash 会先回给它一个临时的假 IP，并记住这个 IP 对应的域名。等设备去连接，OpenClash 就知道它原本要访问谁，可以按域名规则决定走直连还是代理。这样按域名分流更方便，设备也不用先拿到真实 IP。
Fake-IP 很好，但它和 WiFi Calling 有点不兼容，幸好现在插件已经支持让某些域名不走 Fake-IP 模式了，很方便配置。
配置路径：「覆写设置 → DNS 设置」，找到下图的选项。
改完记得应用配置才会生效。
个性问题：核心是 Clash 配置冲突
上面的两个共性问题基本可以解决 90% 的问题了，但我的 WiFi Calling 依然无法拉起。
经过我和 ChatGPT 的多方排查，我发现问题还是出在 DNS 解析上。我连上 OpenWrt 的终端，执行了以下命令：
nslookup ss.epdg.epc.mnc260.mcc310.pub.3gppnetwork.org
这个域名是 WiFi Calling 要走的域名，这个命令是为了看看它解析的 IP 是什么。
结果不是超时，就是无回答。
我就去看了看我的 Clash 配置的 DNS 部分：
dns:
enable: true
nameserver-policy:
geosite:cn,private:
- https://120.53.53.53/dns-query
- https://223.5.5.5/dns-query
geosite:geolocation-!cn:
- https://dns.cloudflare.com/dns-query
- https://dns.google/dns-query
看着很正常：如果是国内域名就走国内 DNS 服务器；如果是非国内域名就走 Cloudflare 和 Google 的 DNS 服务器。
也就是说，用 nslookup 解析这个域名时，应该用的是 Cloudflare 和 Google 的 DNS 服务器，但现在会超时，表示连不上。
接着，我又试了试用国内的 DNS 服务器解析，执行下面这个命令：
nslookup ss.epdg.epc.mnc260.mcc310.pub.3gppnetwork.org 223.5.5.5
发现解析成功了。我调整配置让这个域名走国内 DNS 服务器，最后，WiFi Calling 拉起。
这个时候虽然问题临时解决了，但还是不踏实。毕竟用的国内 DNS，总感觉不安全。
我又联想到：现在这种情况，国外的 DNS 服务器本身是被墙的，用它解析域名确实会超时，可是我开了梯子为什么没办法走代理节点？别的国外网站怎么可以连？
捋了捋思路，我的结论如下：
-
走 Fake-IP 模式的其他国外网站，Clash 内核会根据规则匹配走代理节点，所以能正常连接，这是 Fake-IP 的核心特性；
-
WiFi Calling 的域名特意设置了不走 Fake-IP，就暴露出来了这个问题，导致国外 DNS 无法走代理节点，出现了解析超时等问题。
这个问题是不是和以前用 Clash 客户端时遇到的问题有点像？
以前开了 Clash，浏览器能访问谷歌，但是命令行却没办法访问 GitHub，最后发现需要改成 TUN 模式，也就是更深层次的代理，才能接管命令行的网络流量。
这里也差不多，感觉就是内核解析 DNS 时，上游 DNS 没办法走代理节点，就出现了这种问题。（不过这里不是改成 TUN 模式就好使了）
接着，我就问了 ChatGPT，Clash 里面有什么配置会引起这种情况？它说有个配置是 respect-rules，意思是内核发起的 DNS 上游连接要不要也遵守分流规则。
我马上查看原始配置，值是 true，没问题。
又看了看运行配置，天塌了，怎么变成 false 了？也就是运行时配置显示不遵守分流规则。
到这儿，问题基本定位了，接下来就是找哪里把它设成了 false。
就是这里，默认是关闭的！！！
所以生成运行时配置时，它就把我原本 Clash 配置里的 true 覆盖成了 false。
我把它开启后，问题终于解决了，丝滑拉起 WiFi Calling。
快速检查 WiFi Calling 的小技巧
在排查过程中，如果每次调整配置，都在手机上开关飞行模式、eSIM 和 WiFi Calling，未免也太麻烦。所以可以直接用 SSH 连接 OpenWrt，执行下面的命令，先看域名能不能正常解析。
nslookup ss.epdg.epc.mnc260.mcc310.pub.3gppnetwork.org
小结
就到这里啦，以后终于能丝滑使用 WiFi Calling 了。
另外，也提醒下大家，现在 Tello 这张手机卡在窗口期，可以用欧洲 IP 激活，截止到月底。
如果不把握住，以后就要花高价或者找人给你在美国激活漫游了。
如果对你有帮助，欢迎关注~
李行之 @lxz2677
