代理、VPN、默认网关、网卡与路由：一次 macOS 联网路径排查笔记

摘要

用Claude code需要自己的代理，访问公司内网则需要飞连VPN，所以就有了下面这个问题：当本地开启代理、同时公司 VPN 也在线时，访问外网站点（例如 x.com）到底是走代理，还是走 VPN？

先看一下飞连和本地代理的模式：
- 飞连我这边采用的是极速(非全局)模式，只路由公司内网
- v2rayU 这边采用的是全局模式，系统会将所有的请求都交给代理，然后路由规则是绕过局域网和中国大陆，局域网和中国大陆走直连，其他走代理
解释下 PAC 模式和路由的区别：
- PAC 模式是“系统怎么决定哪些请求交给代理”；路由是“已经进了 V2Ray 之后，再决定走代理还是直连”。

最后得到的结论是（当前代理规则）：

x.com 这类外网站点会命中本地代理
当前公司的 VPN 没有接管默认路由
因此：访问 x.com 时走代理，不走公司 VPN

这次讨论还顺带把几个容易混淆的概念串了起来：代理、VPN、默认网关、网卡、虚拟网卡、路由与默认路由。

1. 起点问题：访问外网时到底走谁

其实“代理”和“VPN”不一定互斥，它们处理的是网络链路里的不同层次：

代理更像是“应用先把请求交给谁代为访问”
VPN 更像是“底层网络包通过哪条隧道走”

因此真实情况往往不是简单二选一，而是要拆成两层看：

访问目标站点时，是否命中了代理规则
去连接代理服务器这段底层流量，是否又被 VPN 接管

2. 第一层判断：`x.com` 会不会命中本地代理

因为代理开启的是“绕过局域网和中国大陆”，所以：

局域网地址不走代理
中国大陆目标不走代理
x.com 这种外网站点会命中代理

也就是说，从应用层逻辑上看：

浏览器不会直接连 x.com
而是先把请求交给本地代理程序

这已经能说明一件事：访问 x.com 时，代理一定参与了处理。

这里还有一个很容易让人继续追问的问题：

本地代理到底是怎么知道“这个目标属于局域网”或者“这个目标属于中国大陆”的？

通常不是系统在“智能判断”，而是本地代理程序在按规则匹配目标地址。

常见做法一般分两类：

2.1 怎么判断是不是局域网

最常见的是直接看目标 IP 是否落在局域网或本地保留网段里，例如：

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
127.0.0.1/8
169.254.0.0/16

如果访问目标是这些地址，或者是像 localhost、.local 这类明显指向本地网络的名称，代理通常会直接判定为直连，不走代理。

2.2 怎么判断是不是中国大陆

这一类通常会结合“域名规则”和“IP 归属规则”来做：

域名规则：如果目标域名命中了中国大陆站点规则，就直接走直连
IP 归属规则：如果域名解析后的 IP 属于中国大陆 IP 段，也会走直连

很多代理软件里常见的规则名字会类似：

geosite:cn
geoip:cn
GEOIP,CN

所以本质上，“中国大陆”并不是代理临时猜出来的，而是依赖一份预置的域名/IP 规则库来判断。

2.3 代理是从哪里拿到这个判断依据的

这取决于代理工作在什么模式下：

如果是系统代理、HTTP 代理或 SOCKS 代理，应用通常会把目标域名或 IP 直接交给代理，代理就可以按规则匹配
如果是 TUN 或虚拟网卡模式，代理先看到的是 IP 包，这时往往先按 IP 判断；有些代理还会结合 DNS 结果或连接特征再还原出域名做更细的分流

所以回到 x.com 这个例子：

它通常不会命中局域网规则
也通常不会命中中国大陆规则
因此大概率会被代理判定为“需要走代理”

3. 第二层判断：代理这条链路会不会再走 VPN

真正需要继续判断的是：

应用把请求交给了本地代理之后
本地代理再去连接远端代理节点时
这条“去代理服务器”的连接，是从本地网络直接出去，还是又先进了 VPN 隧道

这一层不能靠猜，需要看系统路由。

4. 实际检查结果

排查时查看了三个信息：

4.1 默认路由

route -n get default

输出核心内容是：

gateway: 192.168.1.1
interface: en0

这说明：

默认网关是 192.168.1.1
默认出网接口是 en0

换句话说，系统在没有更精确路由匹配时，会把流量交给本地网络的真实网卡，而不是交给 VPN 隧道接口。

4.2 系统代理

scutil --proxy

输出核心内容是：

HTTPProxy : 127.0.0.1
HTTPPort : 1087
HTTPSProxy : 127.0.0.1
HTTPSPort : 1087
SOCKSProxy : 127.0.0.1
SOCKSPort : 1080

这说明系统代理确实已开启，并且指向本机回环地址：

HTTP/HTTPS 请求先交给 127.0.0.1:1087
SOCKS 请求先交给 127.0.0.1:1080

也就是说，浏览器或系统支持代理的应用，会先把外网请求交给本地代理程序。

4.3 VPN 虚拟接口

ifconfig | grep utun -A 3

输出中可以看到：

utun4: ...
inet 10.254.196.187 --> 10.254.196.187

这说明 VPN 的虚拟接口确实存在，也已经分配到了隧道内地址。

但关键点在于：

utun4 存在，不等于它接管了所有流量
是否接管全局流量，要看默认路由是不是指向 utun4

而前面的默认路由已经表明：默认流量还是走 en0

5. 最终结论

综合以上信息，可以得出比较明确的判断：

访问 x.com 时，会命中本地代理
当前公司 VPN 不是全局接管，更像是分流 VPN
默认流量出口仍然是 en0
所以是：访问 x.com 时走代理，不走公司 VPN

如果把结论说得更精确一点：

应用层：先走代理
底层路由：默认从 en0 出去
VPN：主要承接公司内网或被下发的特定路由，不承接所有普通外网流量

6. 为什么“走代理”和“走 VPN”不是一回事

这是这次讨论里最重要的理解点。

很多人会把“是否走代理”和“是否走 VPN”当成同一个问题，但其实不是。

6.1 代理处理的是应用层转发

代理的含义是：

应用不是直接访问目标站点
而是先连接代理程序
再由代理程序帮你访问目标站点

所以“走代理”强调的是：请求先交给谁处理。

6.2 VPN 处理的是底层网络隧道

VPN 的含义是：

系统创建一条虚拟网络通道
部分或全部流量被加密后送进这条通道
再由 VPN 对端转发出去

所以“走 VPN”强调的是：数据包从哪条底层路径出去。

6.3 二者可以叠加

完全可能出现这种链路：

浏览器 → 本地代理 → 远端代理节点 → x.com
                    ↑
               这段连接再走 VPN

也可能是另一种：

浏览器 → 本地代理 → 远端代理节点 → x.com
                    ↑
               这段连接直接走本地网络

你当前这次检查结果，更接近第二种。

7. 什么是默认网关

默认网关可以理解成：电脑在不知道目标该往哪走时，默认交给的下一跳设备。

通常它就是你所在网络里的路由器。

例如这次看到的：

gateway: 192.168.1.1

它的意思是：

当目标不在当前局域网时
电脑先把数据包交给 192.168.1.1
再由这个设备继续往外转发

它像一个“默认出口”或者“中转站”。

需要注意的是，默认网关不是说“所有流量都必定经过它”，而是：

当没有更具体的路由规则时
系统就走默认网关这条兜底路径

因此它又叫“默认路由的下一跳”。

8. 什么是网卡

网卡就是：电脑连接网络、发送和接收数据的接口。

可以把它理解成电脑的“网络口”。

它负责：

把电脑里的数据发到网络上
把网络里的数据收回电脑里

网卡既可以是物理的，也可以是虚拟的。

8.1 `en0` 是什么

en0 通常是 macOS 上的真实网络接口之一，常见情况是：

Wi‑Fi 对应的主网卡
或者某块实际物理网络接口

这次检查里，默认路由指向 en0，说明普通默认出网流量走的是本地真实网络。

8.2 `utun4` 是什么

utun4 是虚拟网络接口，通常由 VPN 创建。

它不是实体硬件，而是一条逻辑上的隧道接口。系统把需要走 VPN 的流量送进 utun4，然后由 VPN 软件负责封装、加密和转发。

因此：

en0 更像是真实道路
utun4 更像是专用地下隧道

9. 为什么 `interface: en0` 很关键

在路由输出里看到：

interface: en0

它表示的是：

这条路由命中的出口接口是 en0
底层包会从 en0 发出去

它不直接表示“有没有用代理”，而是表示“底层使用哪块网络接口”。

所以：

“是否走代理”要看代理配置和代理规则
“底层从哪出去”要看路由和命中的接口

这两件事分别回答的是不同问题。

10. 这次排查的实用判断方法

以后遇到类似问题，可以按这个顺序判断：

10.1 先看默认路由

route -n get default

如果默认接口是：

en0 / en1 之类真实网卡，通常说明默认流量直接走本地网络
utunX，通常说明 VPN 接管了默认路由

10.2 再看系统代理

scutil --proxy

如果代理指向 127.0.0.1，说明系统或应用会先把请求交给本地代理程序。

10.3 最精确的方法：看代理节点的实际路由

如果想把结论完全坐实，最好的办法不是去查 x.com，而是查“远端代理节点 IP”的路由：

route -n get 代理节点IP

这行命令的意思是：“如果我现在要直连这个 IP，系统准备把包从哪儿发出去？”

如果我的飞连开的是极速模式，则返回 en0 如果我的飞连开的是全局模式，则返回 utun4

看它的 interface：

en0：到代理节点这段直连本地网络
utun4：到代理节点这段走 VPN

这一步能彻底区分“代理链路有没有再叠加 VPN”。

11. 一个完整的心智模型

把这次讨论串起来，可以得到这样一个更完整的理解模型：

11.1 访问站点时发生了什么

以访问 x.com 为例：

浏览器准备发起请求
先看代理规则，发现 x.com 命中代理
请求先发给本地代理 127.0.0.1
本地代理再去连接远端代理节点
系统路由决定“到远端代理节点”这条连接从 en0 还是 utun4 发出去
远端代理节点再替你访问 x.com

11.2 每个概念各自回答什么问题

代理：请求先交给谁处理
VPN：哪些流量进入加密隧道
网卡：数据通过哪个接口收发
默认网关：默认情况下先交给哪个下一跳设备
路由：某个目标地址到底走哪条路径

把这些概念分开，很多网络问题都会一下子清楚很多。

12. "开启本地代理"并不意味着所有流量都经过代理

这是一个常见的误解，需要拆成两个层面来看。

12.1 哪些应用会把请求发给代理

系统代理（scutil --proxy 看到的配置）是系统级声明，但并非所有应用都会遵守：

会走代理：浏览器、大多数 GUI 应用（它们主动读取系统代理设置）
不会走代理：命令行工具（curl、wget、git 等默认不读系统代理，除非手动配置或设置 http_proxy 等环境变量）、某些直接使用底层 socket 的程序

12.2 即使请求到了代理程序，也不是所有请求都会被转发

代理程序内部有分流规则。以“绕过局域网和中国大陆”为例：

访问 192.168.x.x 局域网地址 → 直连，不转发
访问国内站点（如 baidu.com）→ 直连，不转发
访问外网（如 x.com）→ 才通过远端代理节点转发出去

12.3 完整的判断链路

应用是否把请求发到 127.0.0.1:1087
    ↑ 取决于：应用是否遵守系统代理设置
         ↓（发到了）
代理程序再根据规则决定：直连 or 转发给远端节点

“流量到达本地代理端口”和“流量被转发出去”是两回事。开启代理，只是把请求的第一站改成了本地代理程序，后续走不走远端节点，还要看规则匹配结果。

13. 这次讨论的最终一句话总结

在“本地代理开启、公司 VPN 在线、默认路由仍是 en0”的情况下：

x.com 这种外网请求会命中代理
而当前网络迹象显示，默认底层出口仍然是本地真实网卡 en0
所以最合理的结论是：访问 x.com 时主要走代理，而不是走公司 VPN 的全局隧道

14. 补充：内网、公网、NAT 与“出入口”

很多关于代理/VPN/路由的困惑，最后都会落到一句话：你的流量最终是从哪个“出入口”去到公网的？

内网（局域网/企业内网）

常见是私有地址（例如 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）
只在局部范围内可路由（家庭/公司/园区）
对外访问通常需要经过网关做 NAT（地址转换）

参考：博客园-内网IP和公网IP

公网（可在互联网路由）

在互联网范围内可路由的地址
具备“对外可达性”，但是否能被访问仍受防火墙/安全组/端口策略影响
家庭/公司常见：多台设备共享一个公网出口（NAT）

参考：知乎-公网IP与内网IP

NAT 的直观理解：你电脑发起访问时，源地址是内网 IP；到达网关时，网关把源地址“翻译”成公网 IP 再出网。回包回来时，网关再根据连接映射表把流量转回对应的内网设备。

把这一节和前文“飞连极速模式”对照起来更好理解：极速模式本质是只把公司内网相关的网段路由进 VPN 隧道，公网默认路由仍然走本地网关（en0 -> 192.168.1.1）。

15. 补充：什么是防火墙

**防火墙（Firewall）**可以理解为：放在网络边界（或主机上）的“流量守门员”，它会根据策略对流量做“允许/拒绝/记录/告警”。它既可以是硬件设备，也可以是软件形态（例如主机防火墙、云安全组/云防火墙等）。

防火墙常见能力包括：基于五元组（源/目的 IP、源/目的端口、协议）做访问控制；跟踪连接状态（状态检测）；对部分应用协议做深度解析（应用层网关/下一代防火墙）；记录日志用于审计与溯源。

参考：阿里云开发者社区-什么是防火墙、其特点、类型以及如何工作、华为云社区-深入理解防火墙

16. 补充：“上网限制”（企业网关/网络审查等）的常见技术原理

无论是企业“上网行为管理”，还是更大范围的网络审查系统，其技术手段往往是分层叠加的，常见包括：

DNS 层：DNS 劫持/污染/拦截（让域名解析失败或解析到错误地址）
IP/路由层：IP 黑名单、路由丢弃（让你压根到不了对方 IP）
传输层：对某些连接注入 RST/阻断握手，或对特定端口/协议做限速
TLS/HTTP 元信息识别：在不解密内容的情况下，基于 SNI、HTTP Host、证书信息等做策略判断
深度包检测（DPI）与主动探测：对流量特征进行识别，对疑似隧道/代理流量做探测和阻断（企业侧常见于安全网关/IDS/IPS；更大范围场景也可能存在类似思路）

这一点也能解释为什么“代理/VPN 只是把流量换了一条路走”：你走的那条路本身依然可能被不同层面的策略设备识别、允许或阻断。

参考（原理性讨论）：上网限制和翻墙基本原理

17. 关于“翻墙/绕过限制”的说明（仅原理，不提供操作指南）

本节只解释“为什么某些代理/VPN/隧道技术在原理上可能绕过特定限制”，不提供任何规避监管/翻墙的具体软件、配置、步骤或可执行建议。如需访问外部资源，请遵守所在地法律法规与公司安全合规要求；在公司网络场景下，优先走合规渠道（例如飞连、镜像站、IT/安全团队审批的访问策略）。

从原理上讲，“绕过限制”通常利用的是两点：

把真实目标藏在“看不见的地方”：例如把原本直连目标站点的流量，改为先连到一个中转点/网关，再由中转点代为访问（这也是前文代理的思路）。
降低策略设备可识别的信息量：例如通过加密隧道，让中间设备难以直接读取应用层内容；或通过协议封装，把流量看起来更像“普通业务”。

与此同时，防守方也会用流量统计特征、握手指纹、主动探测等方式去识别“看起来不普通”的连接，因此它更像是一个持续演化的对抗过程，而不是“有一个万能方法”。

如果你的诉求是“研发环境访问外部开源资源”，通常更推荐的路径是：使用公司提供的合规 VPN/零信任接入、配置公司官方镜像/代理缓存、或按流程申请目标域名/服务访问权限。