系統代理和 TUN 模式怎麼選？六個真實場景逐個對照

上一篇講了 TUN 的原理，這篇只回答一個問題：你的具體情況下，該開哪個。

先把結論表放在最前面。

下面逐個說清楚為什麼。

場景一：日常瀏覽網頁

只開系統代理就夠了。

瀏覽器（Chrome、Edge、Firefox）預設跟隨系統代理設定，開一個開關全都覆蓋。TUN 在這個場景下不提供任何額外收益，反而多佔 CPU、多一層 DNS 處理。

場景二：Steam / 戰網 / Epic 下載慢

必須開 TUN。

游戲平台的下載器基本都直接走 socket，完全無視系統代理設定。你會看到一個典型現象：瀏覽器能打開 Steam 商店頁面（走了代理），但下載速度只有幾十 KB（下載器沒走代理，還在擠原本的国际出口）。

場景三：命令列工具卡住

git clone 卡在 0%、npm install 一直轉、docker pull 逾時——這些工具都不讀系統代理。

有兩條路：

路線 A：開 TUN，一勞永逸，所有命令列工具自動生效。

路線 B：設環境變數，更輕量，不用裝虛擬網路卡：

# PowerShell（當前會話有效）
$env:HTTP_PROXY="http://127.0.0.1:7897"
$env:HTTPS_PROXY="http://127.0.0.1:7897"

# Git 單獨設定（永久）
git config --global http.proxy http://127.0.0.1:7897
git config --global https.proxy http://127.0.0.1:7897

# npm
npm config set proxy http://127.0.0.1:7897
npm config set https-proxy http://127.0.0.1:7897

Docker 比較特殊：容器內的 127.0.0.1 指向容器自己，不是宿主機。需要用 host.docker.internal 或者直接開 TUN。開 TUN 是最省事的做法。

場景四：串流媒體（Netflix / Disney+ / HBO）

開系統代理即可，TUN 不需要。

網頁端和桌面用戶端都跟隨系統代理。真正影響解鎖的不是 TUN，而是：

場景五：聯機對戰游戲

開 TUN，但要有心理預期。

游戲需要 UDP，系統代理不處理 UDP，所以只能靠 TUN。但注意：

• 節點必須支援 UDP 轉發（很多低價節點不支援或做了限制）
• 多繞一跳必然增加延遲，除非你的節點是 IPLC/IEPL 專線
• 部分游戲的反作弊會對虛擬網路卡有反應

場景六：公司配發的電腦

慎開 TUN。

企業電腦上通常裝了終端安全軟體（EDR）、VPN 用戶端、或者域策略。TUN 會創建虛擬網路卡並改路由表，容易出現三類問題：

1. 與公司 VPN 搶路由，導致內網訪問不了
2. 被 EDR 判定為可疑網路行為並上報
3. 域策略強制的代理設定與 Clash Verge 衝突

如果確實需要用，建議：

• 只開系統代理，不開 TUN
• 在規則裡把公司內網網域和 IP 段明確設為 DIRECT
• 先跟 IT 部門確認是否允許

三種組合的實际表現

差距不大，現代電腦基本無感。真正的差別在行為複雜度上：TUN 開著的時候，一旦出網路問題，需要排查的層次會多一層。

一個折中方案：只開 TUN，關掉系統代理

如果你既要游戲又要瀏覽器，可以試試這個組合：

• TUN 開
• 系統代理關

好處是所有流量走同一條路徑，行為統一，排查簡單。副作用是某些明確寫死「讀系統代理」的軟體可能表現不同，另外瀏覽器外掛裡的代理設定可能會繞過 TUN（比如 SwitchyOmega）。

小結

不確定的時候，從系統代理開始，缺什麼補什麼，比一上來就全開要好排查得多。

延伸閱讀：TUN 模式原理詳解、區域網路共享代理。