结论
如果 Clash/Mihomo 的 TUN 网卡叫 Meta，直接放行这个接口即可：
sudo ufw allow in on Meta
sudo ufw allow out on Meta
sudo ufw route allow in on Meta
sudo ufw route allow out on Meta
sudo ufw enable
如果你的 TUN 网卡不叫 Meta，先用下面命令查看实际名称：
ip addr
然后把命令里的 Meta 替换成你的 TUN 网卡名。
背景
这次问题发生在 Ubuntu 终端中。Clash/Mihomo 已经开启了 TUN 模式，但终端里直接访问外网时一直卡住，看起来像是终端没有走 Clash 的虚拟网卡。
一开始容易怀疑这些方向：
- 终端没有读取系统代理；
- Clash/Mihomo 的 TUN 没有真正启用；
- DNS 没有被劫持；
- 路由没有接管；
- 节点或代理端口有问题。
但最后排查下来，真正原因是 UFW 防火墙拦截了 Meta TUN 网卡相关流量。
问题现象
终端里直接访问 ipinfo.io 会超时：
curl -4 -v --connect-timeout 10 https://ipinfo.io
关键输出是：
Host ipinfo.io:443 was resolved.
IPv4: 198.18.0.8
Trying 198.18.0.8:443...
Connection timed out
这里有一个重要信息：域名已经被解析成了 198.18.0.8。
198.18.0.0/16 通常是 Clash/Mihomo fake-ip 使用的地址段。这说明 DNS 劫持已经生效，流量至少已经进入了 TUN 相关逻辑。
但 TCP 连接一直超时，说明问题不在 DNS，而是在后续 TCP 流量转发或返回路径上。
代理端口本身是正常的
随后用本地代理端口测试：
curl -4 -v --connect-timeout 10 --proxy http://127.0.0.1:63088 https://ipinfo.io
这次可以正常返回代理出口 IP：
{
"ip": "146.190.112.118",
"city": "Santa Clara",
"region": "California",
"country": "US"
}
这说明：
- Clash/Mihomo 程序本身正常；
- 代理节点正常；
- 本地代理端口
127.0.0.1:63088正常； - 规则和出站链路没有问题。
因此，问题不是“代理不可用”，而是“系统流量通过 TUN 时被拦住了”。
TUN 网卡也已经创建成功
查看网卡：
ip addr
可以看到 Meta 网卡：
9: Meta: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP>
inet 198.18.0.1/30 scope global Meta
这说明 TUN 虚拟网卡已经创建成功。
再查看路由和策略路由：
ip route
ip rule
ip route show table 2022
关键结果是：
default via 198.18.0.2 dev Meta
这说明策略路由表 2022 也已经把流量导向了 Meta 网卡。
到这里可以基本确认：
| 项目 | 状态 |
|---|---|
| Clash/Mihomo 本地代理端口 | 正常 |
| 代理节点 | 正常 |
TUN 网卡 Meta | 已创建 |
| 策略路由 table 2022 | 已存在 |
| DNS fake-ip | 已生效 |
| 直接 TUN TCP 连接 | 超时 |
为什么关闭防火墙后就好了
后来关闭 UFW 防火墙后，终端立刻可以正常访问外网。
这说明根因很明确：
UFW 防火墙拦截了经过
MetaTUN 网卡的流量。
TUN 模式不是简单地让程序连接 127.0.0.1 代理端口。
显式代理模式的路径大致是：
curl -> 127.0.0.1:63088 -> Clash/Mihomo -> 代理节点
这通常只是本机 loopback 连接，防火墙一般不会拦截。
但 TUN 模式的路径大致是：
curl -> 系统路由 -> Meta 虚拟网卡 -> Clash/Mihomo TUN -> 代理节点
这里会涉及：
Meta虚拟网卡；- 策略路由；
- DNS 劫持；
- INPUT / OUTPUT / FORWARD 规则；
- UFW / iptables / nftables。
如果 UFW 没有放行 Meta 网卡，就可能出现这种现象：
- DNS 已经正常劫持；
- 域名已经解析成 fake-ip；
- 代理端口手动指定时正常；
- 但直接走 TUN 的 TCP 连接一直超时。
为什么不建议直接关闭防火墙
关闭防火墙当然可以验证问题，但不建议长期这样做。
更合适的做法是保留 UFW，只放行 Clash/Mihomo 的 TUN 网卡 Meta。
这样既能保留防火墙，又能让 TUN 正常转发流量。
最终修复命令
执行：
sudo ufw allow in on Meta
sudo ufw allow out on Meta
sudo ufw route allow in on Meta
sudo ufw route allow out on Meta
sudo ufw enable
然后测试：
curl -4 https://ipinfo.io
如果返回的是代理出口 IP，就说明终端已经正常走 Clash/Mihomo TUN。
补充说明
如果你的系统里 TUN 网卡不是 Meta，比如叫 tun0、clash0、mihomo，就需要把命令里的 Meta 替换成实际网卡名。
查看网卡名：
ip addr
查看 UFW 状态：
sudo ufw status verbose
如果仍然不通，可以再检查默认转发策略：
cat /etc/default/ufw | grep DEFAULT_FORWARD_POLICY
如果是：
DEFAULT_FORWARD_POLICY="DROP"
并且前面的 ufw route allow 仍然不生效，再考虑是否需要调整默认转发策略。但这个影响范围更大，优先使用只放行 Meta 网卡的方案。
一句话总结
这次问题不是 Clash/Mihomo 没开 TUN，也不是 Ubuntu 终端不支持 TUN，而是 UFW 默认拦截了 Meta 虚拟网卡相关流量。
放行 Meta 的入站、出站和路由转发后，终端流量就可以正常走 TUN：
sudo ufw allow in on Meta
sudo ufw allow out on Meta
sudo ufw route allow in on Meta
sudo ufw route allow out on Meta
sudo ufw enable