TUN「堆疊」到底在決定什麼？
開了 TUN 之後，系統會多一張虛擬網卡，符合策略的流量會被導向核心，再進到 Mihomo 的規則引擎與出站層。所謂 tun.stack，大致可理解成：從虛擬介面到核心代理邏輯之間，封包要經過哪一種轉送與重組實作。system 這一路通常更仰賴平台原生的 TUN／WFP／路由整合；gvisor 則把較多協定處理放在使用者空間，換取行為一致與可攜性，但可能多一層處理成本。
這不代表某一個「永遠比較快」。您的瓶頸可能是：節點本身 RTT、策略組選線、Fake-IP 與規則誤命中、甚至是雙重 VPN 互搶路由表。堆疊只佔其中一環，卻常是遊戲與 QUIC這類對延遲抖動與 UDP 行為敏感的應用最先抗議的那一環。建議把堆疊當成第一輪二分法：若症狀在切換堆疊後明顯變化，再往下鑽；若完全無感，優先懷疑 DNS、規則，或節點協定能力。
gvisor 與 system：概念級對照
gvisor（使用者空間堆疊）
在一般描述裡，gvisor 路線較常與「使用者空間 TCP／IP 行為較完整、與核心耦合較鬆」聯想在一起。對桌面使用者而言，實務感覺經常是：某些舊版系統或特殊驅動在 system 路徑上會出現奇怪相容性時，gvisor 有機會繞開那條問題路徑；相反地，在高封包率、追求極低延遲的場景下，多一層使用者空間處理，有時會轉成CPU 占領或抖動，讓體感不如預期。
system（系統／驅動取向）
system 路線較常接近「讓作業系統與既有 TUN 驅動做它最擅長的事」。在硬體與驅動鏈路健康的機器上，這條路有時能給出較直接的轉發，對於需要穩定穿越大量小封包的遊戲，值得一試。但若您的環境有第三套安全軟體、公司策略代理、或舊版核心對 TUN 的支援不完整，system 也可能放大驅動層的不一致，表現成間歇性掉封包、DNS 查詢怪迴圈、或特定程式一載入就崩潰。
記憶點：gvisor 偏「行為可預期、平台差異較可吸收」；system 偏「跟著系統走，快時很快、遇到驅動地雷也會很痛」。
什麼情境優先試哪一個？
下列不是醫療等級處方，而是現場排錯的工作假說，請在同一段測試窗口內只改堆疊、其餘設定盡量凍結，否則難以歸因。
- 優先試
system：新機、乾淨系統、CPU 效能餘裕大，且您主要在意FPS 競技、即時對戰類延遲；或您懷疑gvisor讓機器風扇狂轉、佔用偏高。 - 優先試
gvisor：遇過system下特定應用只在此機器失常、與其它網路軟體衝突、或需要跨版本可重現同一份行為（例如開發機與筆電對照）。 - UDP／語音／視訊仍怪：在兩種堆疊各跑一輪，若僅在某一側重現，請把結果寫進您的除錯筆記（時間、遊戲版本、是否 IPv6），再接上 Discord／UDP 與 TUN 的流程查
PROCESS規則與策略組是否支援 UDP。 - QUIC／HTTP3 與多路徑：這類協定對丟包與重排敏感；堆疊切換若會改變重組行為，有時會讓瀏覽器在「看似只有網頁變慢」時露出馬腳。若同網站 TCP 正常、QUIC 異常，請同步比對節點與規則，不要只盯堆疊。
設定檔裡怎麼寫？
下列為示意片段，請與您既有的 dns、proxy-groups、rules 合併；註解使用英文以利部分工具相容。鍵名與可用值請以您實際使用的 Mihomo 版本文件為準，若圖形客戶端以覆寫檔管理 TUN，亦可在 UI 變更後匯出 YAML核對。
# Snippet — tun stack toggle (merge into your config)
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
將 stack 改為 gvisor 後重載核心，再跑一輪測試。部分環境另有 mixed 或平台限定選項：可把它想成折衷模式，在特定版本上混用堆疊能力；若您不確定語意，請以官方說明與變更日誌為準，不要在生產環境盲目抄寫關鍵字。
Linux 桌面若以 systemd 常駐核心，亦可對照 Linux 安裝 Mihomo 並啟用 TUN 的骨架，把 stack 納入同一套驗收流程；重點仍是改一項、測一次。
怎麼量到「堆疊真的有差」？
主觀體感很重要，但請至少準備可重播的基準：同一台機器、同一個策略組、同一條測速或遊戲伺服器時段。建議記錄：重載後前後的一分鐘內 CPU 占用、任務管理員中的核心程式、以及核心日誌是否出現 TUN／路由相關警告。
- 關掉其它 VPN 與「全流量」競品，只保留 Mihomo。
- 固定
log-level: info短時間觀察即可，避免長期 debug 洗版。 - 用兩種堆疊各測一次遊戲內建延遲或
ping對照（注意：ICMP 不一定與遊戲埠同一條路徑）。 - 針對 QUIC，觀察瀏覽器是否在切換堆疊後回退 HTTP/2：若回退後反而穩定，代表問題可能在 UDP 路徑或節點政策，而不是單純「延遲」。
選完堆疊之後，才輪到 DNS、規則與環境變數
許多人反覆在同一組 Fake-IP、nameserver-policy 與規則順序上打轉，卻沒寫下「當時的 tun.stack」。這會讓您難以回顧：到底是解析錯，還是轉發錯。建議固定順序如下。
第一步：DNS 與 TUN 劫持是否閉環
請先確認 dns-hijack 與系統解析器沒打成迴圈，且 Fake-IP／redir-host 模式下的域名命中與規則一致。完整步調可讀 Meta 核心 DNS 防洩漏；本篇不再複製長表，只強調堆疊變更後要重測解析鏈，因為有些平台的系統解析快取行為會跟著介面重建而變動。
第二步：規則第一條命中與遊戲進程
遊戲與啟動器常是多執行檔、多埠、甚至 P2P；若第一條命中把流量送去錯誤的策略組，堆疊再優也救不了。請用日誌確認實際進程名稱或域名，再決定是否寫 PROCESS-NAME 規則與獨立策略組，避免與全局 MATCH 搶順序。
第三步：環境變數與「誰在繞過 TUN」
部分開發工具、容器與終端機 session 會帶著 HTTP_PROXY／ALL_PROXY；少數應用會優先讀環境變數而繞過系統路由。當您懷疑「只有某個終端機里的指令不走 TUN」時，請在該 shell 內清空這些變數试一下，或改以分流規則明確接管。這一步與堆疊無直接因果，卻常和 TUN 問題並行出現，值得列進同一張除錯表。
提醒：同時改 DNS、堆疊、訂閱與規則集，等於一次改四個變因；除錯期請自律，否則只是浪費晚間遊戲時間。
圖形客戶端與進階選項
Windows／macOS 使用者若透過 Clash Verge 類客戶端管理 TUN，堆疊欄位通常出現在 TUN 區塊或進階覆寫中。開啟流程與常見錯誤可先看 Clash Verge Rev TUN 模式完整開啟教程，再回到本文決定 gvisor／system。若客戶端與核心版本跨度大，請優先對齊版本再討論堆疊，避免追到已修復的舊問題。
合規與免責語境
本文僅協助在合法合規前提下進行網路除錯與隱私保護設定；請遵守所在地法律與服務條款。不涉及任何節點商業評測或繞地方法律的指導。
結語
在 Mihomo／Clash Meta 的 TUN 世界裡，gvisor 與 system 不是「誰比較高級」，而是兩種封包進入規則引擎前的交通工具：一個偏使用者空間的一致性，一個偏跟隨系統與驅動的原生路徑。對遊戲與QUIC這類敏感應用，先把堆疊當成兩次可重現的實驗，再串起 DNS 與規則，通常比盲目調整 url-test 閾值更有效。
相較於靠單一技巧包打天下，把「堆疊、DNS、命中順序」分層處理，長期維護成本更低；若您希望圖形化介面裡快速切換與匯出設定，也可優先使用與核心詞彙一致的客戶端，降低概念轉譯成本。