


























网络问题是做技术绕不开的三座大山之一,而且往往排第一。所以遇到tun模式失效,我们该怎么火速解决呢?
根本原因只有一个:代理客户端没有系统级权限,TUN 虚拟网卡压根没创建成功。
解决方法也只有一个:安装服务模式(Service Mode)。
设置 → 服务模式 → 安装 → 重启客户端 → 重新开启 TUN
就这一步。下面的内容是帮你搞清楚为什么,以及怎么确认问题真的修好了。
很多人的状态是这样的:
curl ipinfo.io,IP 还是国内的直觉反应是配置有问题,或者客户端 bug。
其实不是。UI 上的开关只是个开关,背后的 TUN 网卡根本没建起来。
netstat -rn | grep default
有问题的输出长这样:
default 192.168.3.1 UGScg en0
default fe80::%utun0 UGcIg utun0
default fe80::%utun1 UGcIg utun1
看到没有——IPv4 的 default 路由指向的是 en0,也就是你的物理网卡。utun 接口全部是 fe80:: 开头的 IPv6 地址,跟代理一点关系没有。
正常接管后应该是这样:
default 198.18.0.1 UGScg utunX ← IPv4 走 TUN 虚拟网卡
default 192.168.3.1 UGScg en0
ifconfig | grep -B1 "198.18"
没有任何输出 = TUN 网卡不存在。
代理客户端正常创建 TUN 网卡后,会有一个 utun 接口持有 198.18.0.1 这个地址。如果找不到,说明客户端根本没有成功创建这张虚拟网卡。
那些 utun0、utun1、utun2……全是 macOS 系统自己的,跟你的代理客户端无关。
macOS 管得很严。
向系统路由表写条目、创建虚拟网卡,都需要管理员级别的系统权限。
普通应用进程没有这个权限。客户端 UI 可以显示"TUN 已开启",但实际的系统操作全部失败了——静默失败,没有任何报错提示。
服务模式会把客户端的核心组件注册为系统服务,以足够高的权限运行,才能真正操作路由表和网卡。
步骤:
装完之后验证一下:
# 看 TUN 网卡有没有建起来
ifconfig | grep -B1 "198.18"
# 看 IPv4 默认路由是不是走 utun 了
netstat -rn | grep "^default.*utun"
# 最终验证
curl ipinfo.io
如果 ifconfig 里出现了 inet 198.18.0.1 的 utun 接口,路由表里 IPv4 default 指向 utun,就说明完全修好了。
服务模式装好了,也别忘了检查 TUN 的配置文件,有两个字段最容易漏:
tun:
enable: true
stack: system
auto-route: true # 漏了这个,路由表不会写入
auto-detect-interface: true # 漏了这个,网卡出口识别不了
inet4-address: 198.18.0.1/16
dns-hijack:
- any:53
auto-route: true 是最常见的漏填项。没有它,即使 TUN 网卡创建成功,IPv4 流量也不会走进去。
流量走了 TUN,但 DNS 查询没被接管,一样会暴露真实位置:
scutil --dns | grep nameserver
正常情况下应该能看到 198.18.0.2(*** 的虚拟 DNS 地址),如果还是运营商的 DNS 就说明 DNS 没被劫持,需要检查 dns-hijack 配置。
有时候终端里设了代理相关的环境变量,会干扰测试结果:
env | grep -i proxy
如果有输出,先清掉再测:
unset ALL_PROXY HTTP_PROXY HTTPS_PROXY
curl ipinfo.io
TUN 模式不生效,99% 是没装服务模式。装好、重启、重开 TUN,三步搞定。配置文件记得加 auto-route: true。
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。