系统代理更像一份「君子协定」：只有主动去读取这项设置、并且愿意遵守的程序，流量才会被送进代理。TUN 模式则是直接在网卡和路由层动手，操作系统发出的 IP 数据包先交给 VPN 客户端，不管程序认不认代理都会被接住。本文基于 2026 年 11 月的各系统行为，讲清楚两者各自接管哪些流量、怎么验证、怎么选。
为什么浏览器能上网，终端和某些软件却不行？
最常见的原因是：你开的是系统代理，而终端、游戏、部分桌面软件根本不读系统代理。浏览器遵守这份约定所以正常，其他程序没有遵守就直接连外网，看起来就像「代理时灵时不灵」。
这类问题的典型症状有几种：Chrome 或 Edge 里查到的 IP 已经变了，但 curl、git、npm 之类的命令仍然走本机原来的网络；某个游戏客户端、聊天软件的更新模块始终连不上；同一台电脑上不同程序看到的出口 IP 不一致。要理解这些现象，需要先弄清楚两种机制到底在哪一层工作。
系统代理是怎么工作的？
系统代理是写在操作系统网络设置里的一个代理地址（或一份 PAC 自动配置脚本）。程序发起连接前，如果主动去读这个地址，就会把请求交给代理，由代理替它去连目标站点；不去读的程序则完全不受影响。
可以把它理解成大楼前台的访客登记：自觉登记的访客会被前台带路，不登记直接走侧门的人，前台既看不见也管不着。具体的特点有：
- 工作在应用层：程序把「我要访问某某域名」交给代理，由代理建立连接。
- Chrome、Edge 等基于 Chromium 的浏览器默认读取系统设置；Firefox 有独立的代理选项，需要单独设置或选择跟随系统。
- 命令行工具通常不读图形界面里的系统代理，而是读
http_proxy、https_proxy、all_proxy等环境变量，甚至要在工具自己的配置里设置。 - HTTP 代理只中转 HTTP 请求和 HTTPS 的
CONNECT隧道，基于 UDP 的流量（QUIC、语音通话、多数游戏）走不了。 - 一般不需要管理员权限，开关很方便。
TUN 模式是怎么工作的？
TUN 模式会创建一块虚拟网卡，并把系统路由指向它。程序发出的数据包在离开本机之前，先被交给这块网卡背后的 VPN 客户端，客户端再按自己的隧道或代理协议转发。因为发生在应用下面一层，程序完全无感，TCP、UDP、DNS 查询都能被覆盖。
如果说系统代理是「前台登记」，TUN 就像把大楼所有出入口改成同一条必经通道，不管谁进出都要先过一遍。几个背景知识：
- TUN 设备是内核功能：Linux 内核文档里称为通用 TUN/TAP 驱动，Windows 上的客户端常基于 Wintun 驱动，macOS 上则是 utun 接口。
- 创建虚拟网卡、修改路由都需要提权，所以首次启用时会弹出管理员授权，或者安装一个后台辅助服务。
- 不同客户端对它的叫法不一样，有的叫「虚拟网卡模式」，本质都是上面这套机制。
- 客户端自己连接服务器的那条流量必须排除在隧道之外，否则会形成路由环路；正规客户端会自动处理这一点。
两者的差别，一张表看清
| 对比项 | 系统代理 | TUN 模式 |
|---|---|---|
| 接管层级 | 应用层，靠程序自觉 | 网络层，按路由强制 |
| 不认代理的程序 | 接不住，直接连外网 | 可以接住 |
| UDP / QUIC | HTTP 代理无法承载 | 协议支持 UDP 时可以覆盖 |
| DNS 解析 | 由程序或代理决定，各不相同 | 客户端可在系统层面接管 |
| 权限要求 | 通常不需要 | 需要管理员 / root |
| 出问题时的表现 | 个别程序悄悄直连 | 路由冲突时全机断网 |
怎么判断一个程序到底走没走代理？
按「系统设置、环境变量、路由表」三步查，就能判断一个程序走的是哪种机制。不要只看浏览器里的 IP 检测结果，那只能说明浏览器走了代理。
- 看系统设置：Windows 在「设置 → 网络和 Internet → 代理」，macOS 在系统设置里对应网络服务的「代理」页；macOS 还可以用命令行查看。
- 看当前终端的环境变量，确认命令行工具有没有拿到代理地址。
- 看路由表，开着 TUN 时应该能看到指向新虚拟网卡的路由。
# macOS：系统代理设置
scutil --proxy
# Linux / macOS：当前终端里的代理环境变量
env | grep -i proxy
# Linux：网卡与路由（找新增的虚拟网卡）
ip -br addr
ip route show
# Windows：WinHTTP 代理与路由表
netsh winhttp show proxy
route print
# 看 curl 有没有从环境变量里拿到代理
curl -v https://example.com -o /dev/null用 curl -v 时，如果输出里有以「Uses proxy env variable」开头的一行，说明 curl 从环境变量里读到了代理。注意 Windows 的 netsh winhttp 显示的是 WinHTTP 代理，和「设置」页面里的当前用户代理不是同一份配置。TUN 路由的写法也因客户端而异：有的直接加一条更优先的默认路由，有的拆成 0.0.0.0/1 和 128.0.0.0/1 两条。
开了 TUN 之后有哪些常见的坑？
多数问题出在路由冲突、权限和局域网，而不是 TUN 本身。遇到异常，先关掉其他 VPN 和代理软件再复现。
- 同时开了两个带虚拟网卡的软件：它们会抢默认路由，同一时间只开一个。
- 没授权管理员权限：授权弹窗被关掉，虚拟网卡就没建成功，重启客户端重新授权即可。
- 局域网设备访问不了：打印机、NAS 等内网地址需要排除在隧道之外，在客户端里找「绕过局域网」之类的选项。
- 小页面正常、大页面卡住：封装会占用报文空间，MTU 偏大是经典原因；客户端若提供 MTU 选项，适当调小即可。
- 域名解析结果不对：确认客户端是否接管了 DNS，以及它用的是哪个解析服务器。
日常到底怎么选？
只用浏览器上网，系统代理足够，简单省事；要让命令行、桌面软件、游戏、语音都走同一条线路，就开 TUN。两者可以同时开，但排查问题时建议一次只留一个。
- 办公和网页浏览：系统代理，几乎没有副作用。
- 开发者的终端、容器、包管理器：TUN 更省事，否则要逐个工具配置代理。
- 游戏、语音、视频会议等依赖 UDP 的软件：TUN，前提是客户端使用的协议支持 UDP。
- 没有图形界面的服务器：直接设代理环境变量或各工具自带的代理选项，不一定要加虚拟网卡。
安泊 VPN 能在哪里帮上忙
安泊 VPN 的官方客户端同时支持 TUN 模式和应用级智能分流：想让整台设备都走 VPN 就开 TUN，只想让指定应用走 VPN 就用智能分流。一个账号可以在任意数量的设备上使用，按流量套餐计费；新注册账号赠送一次性的 1 GB 流量，有效期 1 个月。客户端覆盖 Windows、macOS、iOS、Android 和 Linux，可在安泊 VPN 下载页获取。
