开了 TUN 模式还是直连？90% 的人都踩过这个坑
网络问题是做技术绕不开的三座大山之一，而且往往排第一。所以遇到tun模式失效，我们该怎么火速解决呢？
先说结论
根本原因只有一个：代理客户端没有系统级权限，TUN 虚拟网卡压根没创建成功。
解决方法也只有一个：安装服务模式（Service Mode）。
设置 → 服务模式 → 安装 → 重启客户端 → 重新开启 TUN
就这一步。下面的内容是帮你搞清楚为什么，以及怎么确认问题真的修好了。
你以为开了 TUN，其实没有
很多人的状态是这样的：
- 全局模式 ✅ 打开了
- TUN 模式 ✅ 打开了
- 终端跑一下
curl ipinfo.io，IP 还是国内的
直觉反应是配置有问题，或者客户端 bug。
其实不是。UI 上的开关只是个开关，背后的 TUN 网卡根本没建起来。
怎么确认 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
第二招：看有没有 198.18 地址
ifconfig | grep -B1 "198.18"
没有任何输出 = TUN 网卡不存在。
代理客户端正常创建 TUN 网卡后，会有一个 utun 接口持有 198.18.0.1 这个地址。如果找不到，说明客户端根本没有成功创建这张虚拟网卡。
那些 utun0、utun1、utun2……全是 macOS 系统自己的，跟你的代理客户端无关。
为什么会这样
macOS 管得很严。
向系统路由表写条目、创建虚拟网卡，都需要管理员级别的系统权限。
普通应用进程没有这个权限。客户端 UI 可以显示"TUN 已开启"，但实际的系统操作全部失败了——静默失败，没有任何报错提示。
解决方法：装服务模式
服务模式会把客户端的核心组件注册为系统服务，以足够高的权限运行，才能真正操作路由表和网卡。
步骤：
- 打开 *** Verge
- 进「设置」
- 找「服务模式（Service Mode）」，点安装
- 系统会弹出授权窗口，输入管理员密码
- 安装完成后，完全退出客户端（Cmd+Q，不是关窗口）
- 重新启动，开启 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 的配置文件，有两个字段最容易漏：
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 流量也不会走进去。
DNS 泄漏
流量走了 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。
浙公网安备 33010602011771号