网络问题是做技术绕不开的三座大山之一，而且往往排第一。所以遇到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阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。