更新时间：2026-03-21 09:58:31
随着 AI 编程助手（Claude Code、GitHub Copilot、Cursor 等）、AI 对话工具（ChatGPT、Claude）以及包管理器（npm、pip、cargo）日益成为开发者的核心工作流，一个长期被忽视的问题逐渐凸显：系统代理模式无法覆盖所有应用的网络流量。
在传统的系统代理（System Proxy）模式下：
| 场景 | 是否自动走代理 |
|---|---|
| 浏览器访问 ChatGPT | 是 |
| VS Code 内置浏览器 | 是 |
终端执行 npm install | 否，需手动设置 HTTP_PROXY |
| Claude Code CLI | 否，需手动配置环境变量 |
| IDE 内置 AI 补全 | 不确定，取决于应用实现 |
pip install / cargo build | 否 |
开发者不得不反复配置 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 等环境变量，甚至为不同工具单独设置代理参数。这不仅繁琐，还极易出错——忘记配置某个终端窗口就会导致连接超时、依赖安装失败。
TUN（Tunnel）模式通过在系统层创建虚拟网卡，在网络栈的最底层拦截所有流量，从根本上解决了上述问题。
┌─────────────────────────────────────────────┐
│ 应用层（浏览器/终端/IDE/AI工具） │
│ ChatGPT Claude Code npm pip Cursor │
└──────────────────┬──────────────────────────┘
│ 所有流量
▼
┌──────────────────────────────────────────────┐
│ TUN 虚拟网卡 (198.18.0.1) │
│ tun2socks → SOCKS5 代理 │
└──────────────────┬───────────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ Xray 代理核心（智能/全局路由） │
└──────────────────────────────────────────────┘
开启 TUN 模式后，终端、IDE、AI 工具无需任何额外配置，即可自动通过代理访问网络。
"接管全部网络流量，终端/IDE/AI 工具无需额外配置"
以往使用 Claude Code 时，用户需要：
# 以前：每次打开终端都要设置
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
claude # 才能正常连接
TUN 模式下：
# 现在：直接使用，无需任何额外步骤
claude # 自动走代理，直接连通
调用 OpenAI、Anthropic 等 API 开发应用时，不再需要在代码中硬编码代理配置或在运行环境中注入代理变量。TUN 模式让 fetch、axios、httpx 等 HTTP 客户端的请求在操作系统层面被自动路由。
npm install、pip install、cargo build、go get 等命令在 TUN 模式下全部自动通过代理，不再出现因网络不通导致的依赖安装失败和长时间等待。
git clone、git push、git pull 等 SSH/HTTPS 协议的 Git 操作也被 TUN 完整覆盖，无需单独为 Git 配置代理。
TUN 模式深度介入系统网络栈，如果处理不当会导致"断网"。我们通过以下机制确保稳定性：
代理服务器 IP → 走原始网关（绕过 TUN）
直连 IP 列表 → 走原始网关（绕过 TUN）
0.0.0.0/1 → 走 TUN（代理所有其他流量）
128.0.0.0/1 → 走 TUN
代理服务器自身的流量被排除在 TUN 之外，避免"代理自己代理自己"的死循环。
特权辅助进程（Helper）内置 Watchdog 机制，每 5 秒检测 Electron 主进程是否存活。一旦主进程崩溃或被意外杀死，Watchdog 自动执行清理：
即使应用崩溃，用户的网络也不会中断。
TUN 模式强制将 DNS 查询路由到 8.8.8.8 和 1.1.1.1，防止 DNS 请求走本地 ISP 导致的解析污染或泄露问题，确保 AI 工具能正确解析 api.openai.com、api.anthropic.com 等域名。
| 平台 | 实现方式 | IPC 通道 |
|---|---|---|
| macOS | 特权辅助进程（launchd） | Unix Socket (/var/run/sulian-helper.sock) |
| Windows | Windows 服务（SulianHelper） | Named Pipe (\\.\pipe\sulian-helper) |
| Linux | pkexec 提权 | 直接进程管理 |
各平台均通过独立的特权服务执行网络操作，主进程本身无需提权，符合最小权限原则。
当 TUN 启动失败（如 Helper 未安装）时，系统会：
"helper service"、"Access is denied" 等）TUN 模式支持两种路由策略：
1. 从 Xray 配置中提取代理服务器 IP
↓
2. 域名解析为 IP（防止路由循环）
↓
3. 检测系统默认网关和本地网卡
↓
4. 平台特权服务初始化
- macOS: 特权辅助进程 / osascript 降级
- Windows: Windows 服务
- Linux: tun2socks 直接进程管理
↓
5. 创建 TUN 虚拟网卡（198.18.0.1）
↓
6. 配置分流路由规则
- 代理服务器 IP → 原网关
- 直连 IP → 原网关
- 0.0.0.0/1 + 128.0.0.0/1 → TUN
↓
7. 配置 DNS（8.8.8.8, 1.1.1.1）
↓
8. 启动 Watchdog 进程守护
| 组件 | 作用 |
|---|---|
| tun2socks | 将 TUN 网卡流量转发到 SOCKS5 代理 |
| wintun.dll | Windows 平台 TUN 驱动（来自 WireGuard） |
| sulian-helper | 跨平台特权辅助服务（Go 编写） |
| Xray | 代理核心，支持多协议和智能路由 |
| 维度 | 系统代理模式 | TUN 模式 |
|---|---|---|
| 浏览器 | 自动 | 自动 |
| 终端 / CLI | 需手动配置 | 自动 |
| AI 工具（Claude Code 等） | 需手动配置 | 自动 |
| IDE AI 补全 | 不确定 | 自动 |
| 包管理器 | 需手动配置 | 自动 |
| Git SSH/HTTPS | 需手动配置 | 自动 |
| 崩溃后网络恢复 | 不涉及 | Watchdog 自动恢复 |
| DNS 防泄露 | 无 | 有 |
TUN 模式的改造，本质上是将"代理配置"这个长期困扰开发者的负担从应用层下沉到了操作系统层。对于日益依赖 AI 工具的现代开发工作流而言，TUN 模式不是锦上添花，而是真正的基础设施级改进——它让开发者专注于编码和创造，而不是反复排查"为什么连不上"。
目录
