很多人以为：

只要 v2rayN 节点能连上，TUN 模式就一定生效。

其实不是。

节点能用，只代表代理核心本身通了。

TUN 能用，代表系统流量真的被接管了。

这两个不是一回事。

这次遇到的问题就是典型案例：

手动走 SOCKS5 代理可以访问 Google。

但是浏览器、终端、系统直连还是访问不了。

这说明什么？

说明代理链路本身是好的，但系统流量没有真正走进 TUN。

---

一、先看现象

诊断结果里有三个关键现象。

第一个：

127.0.0.1:10808 正在监听

说明本机 SOCKS5 代理端口已经起来了。

第二个：

curl --socks5-hostname 127.0.0.1:10808 https://www.google.com

可以返回：

HTTP/2 200

说明节点、代理核心、远程链路都是正常的。

第三个：

curl -I https://www.google.com

直接访问超时。

同时：

127.0.0.1:10809 Connection refused

说明 HTTP 代理端口没有起来。

这几个现象合起来，结论就很清楚：

代理核心没坏。

节点没坏。

真正的问题是：

系统流量没有被 TUN 接管。

---

二、什么是 TUN 模式？

普通代理模式，一般是这样的：

软件自己设置代理。

浏览器自己设置代理。

终端自己设置代理。

哪个软件设置了，哪个软件才走代理。

而 TUN 模式不一样。

TUN 模式会在系统里创建一个虚拟网卡，然后把系统流量导进这个虚拟网卡，再交给代理核心处理。

简单说：

普通代理是“软件自己走代理”。

TUN 模式是“系统帮所有流量走代理”。

所以 TUN 模式生效后，理论上你不用单独给浏览器、终端、npm、OpenClaw 配代理，它们也应该能自动走代理。

但前提是：

TUN 真的启动成功了。

路由真的被改了。

DNS 真的被接管了。

---

三、TUN 没生效的典型表现

如果你遇到下面这些情况，基本就可以怀疑 TUN 没生效。

1. SOCKS5 手动访问成功

比如：

curl -I --socks5-hostname 127.0.0.1:10808 https://www.google.com

能成功。

这说明节点本身没问题。

2. 直接访问失败

比如：

curl -I https://www.google.com

失败、超时、无法连接。

这说明系统流量没被接管。

3. 浏览器不设置代理就访问不了

如果浏览器只有在手动设置 SOCKS5 代理后才能访问，关掉代理就不行，也说明 TUN 没真正接管系统流量。

4. 没有新的 utun 网卡

macOS 上 TUN 通常会创建 utun 相关虚拟网卡。

可以用这个命令看：

ifconfig | grep -Ei "utun|sing|tun" -A 8

如果开了 TUN 之后完全看不到相关变化，大概率 TUN 根本没起来。

---

四、这次问题的根因判断

这次日志里，最关键的是：

SOCKS5 10808 成功
HTTP 10809 refused
直连 Google timeout

这说明：

v2rayN / xray / sing-box 代理核心至少有一部分是正常的。

因为 SOCKS5 已经能访问外网。

但系统流量没有自动走代理。

也就是说：

TUN 模式没有真正生效。

进一步看，还有一个问题：

HTTP 代理端口 10809 没有监听。

所以如果某些软件配置的是：

http://127.0.0.1:10809

也会直接失败。

这类失败不是节点失败，而是本机端口没开。

---

五、第一步：确认核心类型，优先用 sing-box

macOS 上使用 TUN，建议优先使用 sing-box core。

因为 TUN、路由接管、DNS 劫持这些能力，sing-box 更适合。

在 v2rayN 里检查：

设置
核心类型
切换为 sing-box

切换之后，重新选择节点。

然后重新开启 TUN。

不要一边用 xray，一边指望 TUN 一定能稳定接管所有系统流量。

---

六、第二步：彻底重启 v2rayN 和代理核心

有时候 TUN 开关点了，但核心没有正确重载。

这时候不要只点界面按钮。

直接把相关进程杀掉：

pkill -f v2rayN
pkill -f sing-box
pkill -f xray

然后重新打开 v2rayN。

重新选择节点。

重新开启 TUN。

如果 macOS 弹出管理员密码授权，一定要允许。

因为 TUN 需要创建虚拟网卡、修改系统路由，这不是普通权限能完成的。

---

七、第三步：确认 TUN 网卡是否创建成功

开启 TUN 后，执行：

ifconfig | grep -Ei "utun|sing|tun" -A 8

如果看到新的 utun 相关接口，说明 TUN 至少创建了虚拟网卡。

如果完全没有变化，说明 TUN 没创建成功。

这时候重点查：

v2rayN 是否有管理员权限。

sing-box 是否正常启动。

TUN 配置是否开启。

macOS 是否阻止了相关网络权限。

---

八、第四步：确认系统路由是否被接管

TUN 模式不是创建虚拟网卡就结束了。

还要把流量导过去。

继续执行：

netstat -rn -f inet | head -n 40

如果 TUN 生效，路由表里通常会出现和 utun 有关的路由。

如果没有任何路由变化，说明：

TUN 网卡可能起来了，但系统流量没走进去。

这时候重点查 v2rayN 的 TUN 配置。

---

九、第五步：检查 TUN 的关键配置

在 v2rayN 的 TUN 设置里，重点看这些选项：

Enable TUN：开启
Stack：mixed / system / gvisor，优先 mixed
Auto Route：开启
Strict Route：开启
Sniff：开启
DNS Hijack：开启

其中最关键的是：

Auto Route
DNS Hijack

Auto Route 负责让系统流量走 TUN。

DNS Hijack 负责把 DNS 查询也接管过来。

如果只开了 TUN，但没开 Auto Route，可能出现：

TUN 网卡存在，但流量没进去。

如果 DNS 没接管，可能出现：

IP 流量走了代理，但域名解析还是污染或失败。

---

十、第六步：检查 10808 和 10809 端口

执行：

lsof -nP -iTCP:10808 -sTCP:LISTEN || true
lsof -nP -iTCP:10809 -sTCP:LISTEN || true

正常情况下：

10808：SOCKS5 代理
10809：HTTP 代理

但不同客户端配置不一样。

如果只看到 10808，没有 10809，说明 HTTP 代理没有开。

这时候如果某些软件使用的是：

http://127.0.0.1:10809

就会失败。

可以临时改成 SOCKS5：

socks5h://127.0.0.1:10808

---

十一、第七步：用三条命令判断问题在哪

1. 测试直连

curl -I --connect-timeout 8 https://www.google.com

如果失败，说明当前系统默认链路不通。

2. 测试 SOCKS5

curl -I --socks5-hostname 127.0.0.1:10808 --connect-timeout 8 https://www.google.com

如果成功，说明节点和 SOCKS5 代理正常。

3. 测试 HTTP 代理

curl -I -x http://127.0.0.1:10809 --connect-timeout 8 https://www.google.com

如果失败并提示：

Connection refused

说明 10809 端口没有监听。

这时候不要怀疑节点。

应该去检查 HTTP 入站配置。

---

十二、完整排查脚本

可以直接复制执行：

echo "=== core process ==="
ps aux | grep -Ei "v2ray|v2rayn|xray|sing-box" | grep -v grep

echo "=== ports ==="
lsof -nP -iTCP:10808 -sTCP:LISTEN || true
lsof -nP -iTCP:10809 -sTCP:LISTEN || true

echo "=== tun interfaces ==="
ifconfig | grep -Ei "utun|sing|tun" -A 8

echo "=== route ==="
netstat -rn -f inet | head -n 40

echo "=== direct test ==="
curl -I --connect-timeout 8 https://www.google.com

echo "=== socks test ==="
curl -I --socks5-hostname 127.0.0.1:10808 --connect-timeout 8 https://www.google.com

echo "=== http proxy test ==="
curl -I -x http://127.0.0.1:10809 --connect-timeout 8 https://www.google.com

判断方法：

SOCKS 成功，直连失败，没有 utun：
TUN 没创建成功。

SOCKS 成功，直连失败，有 utun：
TUN 创建了，但路由或 DNS 没接管。

SOCKS 成功，HTTP 代理失败：
10809 没开，软件不要配置 http://127.0.0.1:10809。

SOCKS 失败：
节点、订阅、核心、远程链路有问题。

直连成功：
系统网络本身可以访问，不一定说明 TUN 生效。

---

十三、临时解决方案：先用 SOCKS5 接管系统代理

如果 TUN 一时修不好，可以先用系统代理顶上。

先确认网络服务名：

networksetup -listallnetworkservices

一般是：

Wi-Fi

然后执行：

networksetup -setwebproxystate "Wi-Fi" off
networksetup -setsecurewebproxystate "Wi-Fi" off
networksetup -setsocksfirewallproxy "Wi-Fi" 127.0.0.1 10808
networksetup -setsocksfirewallproxystate "Wi-Fi" on

然后测试：

curl -I https://www.google.com

如果能通，说明系统代理已经把流量导到 SOCKS5 了。

这不是 TUN，但可以先解决访问问题。

---

十四、恢复系统代理

如果后面不想走系统代理了，执行：

networksetup -setsocksfirewallproxystate "Wi-Fi" off
networksetup -setwebproxystate "Wi-Fi" off
networksetup -setsecurewebproxystate "Wi-Fi" off

然后再测试网络。

---

十五、最终修复路线

这类问题不要乱猜。

按这个顺序来：

1. 确认 SOCKS5 10808 是否可用。
2. 如果 SOCKS5 可用，说明节点没坏。
3. 检查 TUN 是否创建 utun 网卡。
4. 检查路由是否走 utun。
5. 检查 Auto Route 是否开启。
6. 检查 DNS Hijack 是否开启。
7. 检查 10809 HTTP 代理是否真的监听。
8. TUN 修不好时，先用 SOCKS5 系统代理临时解决。

这次问题最核心的一句话是：

节点没坏，v2rayN 也不是完全不能用。

真正的问题是：

TUN 没有把系统流量接管过来。

所以，不要一上来就重装。

先看端口。

再看 utun。

再看路由。

再看 DNS。

这样排查，才不会越修越乱。