
一、背景:AI 開發工具的網路困境
隨著 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 模式的核心優勢
TUN(Tunnel)模式透過在系統層建立虛擬網卡,在網路堆疊的最底層攔截所有流量,從根本上解決了上述問題。
┌─────────────────────────────────────────────┐
│ 應用層(瀏覽器/終端機/IDE/AI工具) │
│ ChatGPT Claude Code npm pip Cursor │
└──────────────────┬──────────────────────────┘
│ 所有流量
▼
┌──────────────────────────────────────────────┐
│ TUN 虛擬網卡 (198.18.0.1) │
│ tun2socks → SOCKS5 代理 │
└──────────────────┬───────────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ Xray 代理核心(智慧/全域路由) │
└──────────────────────────────────────────────┘
開啟 TUN 模式後,終端機、IDE、AI 工具無需任何額外配置,即可自動透過代理存取網路。
「接管全部網路流量,終端機/IDE/AI 工具無需額外配置」
三、對 AI 開發工作流的具體便利性提升
1. Claude Code / Cursor 等 AI CLI 工具:零配置即用
以往使用 Claude Code 時,使用者需要:
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
claude
TUN 模式下:
claude
2. AI 模型 API 呼叫:開發測試無縫銜接
呼叫 OpenAI、Anthropic 等 API 開發應用時,不再需要在程式碼中寫死代理配置或在執行環境中注入代理變數。TUN 模式讓 fetch、axios、httpx 等 HTTP 用戶端的請求在作業系統層面被自動路由。
3. 套件管理器與依賴下載:告別逾時
npm install、pip install、cargo build、go get 等命令在 TUN 模式下全部自動通過代理,不再出現因網路不通導致的依賴安裝失敗和長時間等待。
4. Git 操作:推拉自如
git clone、git push、git pull 等 SSH/HTTPS 協議的 Git 操作也被 TUN 完整覆蓋,無需單獨為 Git 配置代理。
四、穩定性保障機制
TUN 模式深度介入系統網路堆疊,如果處理不當會導致「斷網」。我們透過以下機制確保穩定性:
1. 防路由迴圈(Anti-Routing Loop)
代理伺服器 IP → 走原始閘道(繞過 TUN)
直連 IP 清單 → 走原始閘道(繞過 TUN)
0.0.0.0/1 → 走 TUN(代理所有其他流量)
128.0.0.0/1 → 走 TUN
代理伺服器自身的流量被排除在 TUN 之外,避免「代理自己代理自己」的死迴圈。
2. Watchdog 程序守護
特權輔助程序(Helper)內建 Watchdog 機制,每 5 秒偵測 Electron 主程序是否存活。一旦主程序當機或被意外終止,Watchdog 自動執行清理:
- 刪除 TUN 路由規則
- 恢復原始 DNS 配置
- 終止 tun2socks 程序
- 恢復系統網路至正常狀態
即使應用當機,使用者的網路也不會中斷。
3. DNS 洩漏防護
TUN 模式強制將 DNS 查詢路由到 8.8.8.8 和 1.1.1.1,防止 DNS 請求走本機 ISP 導致的解析污染或洩漏問題,確保 AI 工具能正確解析 api.openai.com、api.anthropic.com 等網域。
4. 跨平台特權輔助服務
| 平台 | 實作方式 | IPC 通道 |
|---|
| macOS | 特權輔助程序(launchd) | Unix Socket (/var/run/sulian-helper.sock) |
| Windows | Windows 服務(SulianHelper) | Named Pipe (\\.\pipe\sulian-helper) |
| Linux | pkexec 提權 | 直接程序管理 |
各平台均透過獨立的特權服務執行網路操作,主程序本身無需提權,符合最小權限原則。
5. 優雅的錯誤復原
當 TUN 啟動失敗(如 Helper 未安裝)時,系統會:
- 自動偵測錯誤類型(
"helper service"、"Access is denied" 等)
- 觸發 Helper 安裝引導彈窗
- 引導使用者一鍵安裝特權服務
- 安裝完成後自動重試連線
五、智慧路由與全域路由
TUN 模式支援兩種路由策略:
- 全域代理:所有流量經代理出站,適合對 AI 服務穩定性要求極高的場景
- 智慧分流:國內網域/IP 直連,海外流量走代理——既保證 AI 工具的可存取性,又不影響國內服務的存取速度
六、技術實作細節
啟動流程
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 模式不是錦上添花,而是真正的基礎設施級改進——它讓開發者專注於編碼和創造,而不是反覆排查「為什麼連不上」。