Windows 10 安裝 Mihomo Party：系統代理與 TUN 模式首次設定完整步驟

1. 這篇與 Win11 版有何不同、要幫你解決什麼

許多人在搜尋Windows 10 Mihomo Party 安裝時，並不是卡在「程式叫什麼名字」，而是三個網路層次被混在同一個症狀裡：使用者介面是否真的安裝成功、mihomo 核心有沒有依設定檔監聽本機埠、以及流量走的是由系統代理寫進 Windows 的那份 Proxy，還是透過 Wintun 類虛擬介面送入核心。Win10 在 2026 年仍普遍存在於公司配發機、創作者舊工作站與部份家機；微軟已調整對家用版的主流支援時間表，並不代表硬體突然不能跑新式 Clash／mihomo 客戶端，但累積更新的節奏、驅動簽章舊檔相容、以及資安產品的預設策略往往比剛安裝完成的 Win11「更迂迴」，第一次點開 TUN 就比較容易見到對話框轟炸或被防毒拖慢。

本篇刻意與泛泛的「Windows 一次講完」不同：標題直指 Win10，並且在敘事中反覆對照Win11 Mihomo Party 姊妹篇，讓讀者知道「共用原理」在哪裡、但「對話框／設定頁詞彙／老機問題」要自己落到哪一章。你也可能同時評估Verge Rev或其它圖形殼：只要核心是 mihomo，YAML 規則語意向來可以搬運；真正有差異的是你每天點到哪個選單才能看到訂閱更新、規則覆寫、系統代理、TUN 開關、日誌等級。若是從停更的Clash for Windows（CFW）換血，可先讀替代與遷移指南來整理資料夾與工作流程，再回到本文把 Party 這條乾淨裝機 → 首次成功連線 → 視需求開 TUN走完。

2. 下載、安裝與首次開啟（SmartScreen／架構）

請從本站 下載頁取得適用於 Windows、標註為 Mihomo Party的官方安裝包或可攜壓縮檔。架構對齊是老生常談卻最常踩雷：請確認x64或ARM64與系統完全一致；在老式平板或 Snapdragon 類裝置上若誤裝 amd64 版本，會以「程式閃退、無法載入 DLL、開啟後即崩潰」這類難追查方式呈現。初次執行若遇到 SmartScreen、「已封鎖此應用程式」或請你「仍要執行」，多半與數位簽章聲譽尚未完全覆蓋到你的累積更新版本有關，並不一定代表來源可疑；但仍請只在核對過指紋／校驗和與發行紀錄後再解除封鎖。與 Win11 最常見的微差異是：某些 Win10 長期機台仍停留在較舊的「控制台思維」或企業AppLocker／Device Guard策略介入，對未簽或可攜程式更敏感；若在個人環境正常、在公司網域機上卻被拒絕安裝，多半得先請 IT 放寬或可改走標準 MSI／IT 發佈的版本。

程式進入主畫面後，可把語言、系統匣圖示、開機自動啟動等選項調成順手的狀態，但先不要馬上開 TUN。實務上 TUN 一旦嘗試接掌路由，會牽動驅動載入順序與路由表視圖；如果你的訂閱還在 TLS handshake 無限逾時、mihomo 尚未穩聽mixed-port，把問題複合到路由層只會拉長排錯路徑。建議順序：應用程式可重啟不崩 → 更新訂閱成功 → 本機對核心埠測得通 → 再開切換系統代理或 TUN。

3. 匯入訂閱並確認 mihomo 核心已啟動

在 Mihomo Party 中新增訂閱網址、本機 YAML、或來自機場的遠端檔案後，先手動更新訂閱，並在日誌中確認沒有連續的 DNS 無法解析、憑證驗證失敗或 YAML indent 問題。對 Win10 而言，這一層常見干擾是過期的根憑證套件、時間不同步拖垮 TLS、或公司解密代理把 SUB 請求拆掉；症狀都長得像「客戶端壞掉」。可搭配站內 訂閱匯入教學與 Windows 訂閱更新與 TLS／DNS 對照文章把資料面問題先隔離開來。

接下來在主介面確認mihomo 核心狀態顯示為執行中，並核對mixed-port、HTTP、SOCKS 等數值是否與你閱覽過的config.yaml一致。監聽失敗多半先把矛頭指向埠被佔用、或被安全軟體封鎖本機環回綁定——這類錯誤與選擇系統代理／TUN 無關，卻常常被誤會成「TUN 不支援這台電腦」。建議在完成一次成功的節點延遲測試後，再進入下一節的系統層級開關，心理上也比較有把握。

4. 系統代理：適用範圍與 Win10 設定對照

系統代理的做法，是請 Windows 將 HTTP／HTTPS／（某些情境下的）SOCKS 代理指到本機 mihomo 正在監聽的埠號。好處是對全域路由表的侵擾較小，通常無須先有虛擬介面也能讓八成日常瀏覽與套件下載順利復活；代價則是同一句話：只會對「願意讀系統 Proxy 設定」的程式生效。Edge／Chrome／多數 Electron 應用程式在預設情況下會跟 WinINET／系統 UI 對齊，因此很多人會以為「一開就好」；但如果你同時在玩某些遊戲、國產桌面殼／啟動器、或直接在 PowerShell／Cmd 跑的腳本，它們可能根本不讀這份設定，結果就是瀏覽器暢通而其他程式像在直連。

請在 Mihomo Party 中找到語意類似套用系統代理／Set system proxy的項目並開啟，接著進入 Win10 的設定 → 網路和網際網路 → Proxy頁檢視：「手動 Proxy」應顯示啟用、位址常為127.0.0.1，埠號與用戶端顯示一致。這裡與 Win11 的差別多半只是詞彙微調或被改放進「進階」子頁——若發現這裡仍是停用或沿用舊埠，代表寫入被其他程式搶回來或 Party 沒抓到足夠權限。請暫時關閉其他會改 Proxy 的工具（PAC、別的 VPN、過期外掛）先建立乾淨基線，再上調規則。若你希望連命令列環境都跟著同一出口，又不想立刻切 TUN，可以在 profile 稿本補上HTTPS_PROXY等環境變數，並明白那已經進入第二層手動規劃，別與 WinHTTP／WinINET 混談成一個問題。

5. TUN：Wintun、虛擬介面與管理員權限

TUN 模式透過類似 TAP／Wintun 的使用者模式虛擬介面，讓流量在更近核心的層級被送入 mihomo 處理。這對不讀系統 Proxy的桌面程式較為友善，也較有能力覆蓋一些 UDP／DNS／QUIC 行為——仍取決於你的tun:段、dns:模式與RULE排序。對 Win10 而言，第一次按下 TUN 往往伴隨UAC 對話框、驅動安裝細節、或安全軟體要求你「允許變更」，請不要被嚇跑而直接結束程式；強制終止只會留下半套介面紀錄，下次啟動更難還原。請習慣先打開 Party 自帶的核心或應用日誌視窗，對照時間戳確認驅動層發生了什麼。

安裝成功後可到控制台 → 網路和共用中心 → 變更介面卡設定或新版設定搜尋「介面卡」來看是否多出描述含 Wintun／虛擬字的介面。舊電腦／虛擬機雙載若曾安裝 VMware／VirtualBox／WireGuard 並且反覆試驗過殘餘 TAP，偶有「介面卡住」的假性成功：系統看得到介面、mihomo 卻拿不到封包統計增量，這時需要對照事件檢視器與 Mihomo Party 日誌來拆是驅動層還是規則層。請記得：TUN 不是「自動讓 YAML 生效」的神奇按鈕；若規則把大量連線留在DIRECT或者 DNS fake-ip／redir-host 與規則衝撞，你看到的現象仍會像「程式全都不走 Party」。更細分流可延伸閱讀規則分流指南。

Microsoft Store 程式與 UWP 特例

某些以沙箱模型封裝的 App 對回環／Proxy 有不同策略；若你只在那類程式上異常，建議對照本站 UWP／回環一文，避免誤判成 Mihomo Party 不支援 Win10。

6. 何時先留系統代理、何時改 TUN

對日常「瀏覽器查資料、視訊、雲文件」這類強依賴 HTTPS 並且順從 WinINET／系統 UI 的情境，優先試系統代理一般最省事，也最易於退場：關掉 Party、或取消其「設定系統代理」後，系統很快就能回到近似預設。需要整機級一致出口——例如套件管理工具、老式遊戲啟動器、區域連線對時、或小眾國產 IM——再改開 TUN 才有意義。公司 VPN／零信任客戶端常駐時也請小心：多套全隧道／stack 並存會互相改寫路由優先級；若非政策允許，寧可以系統代理＋細分流配合公司通道，而不要硬搶預設閘道話語權。

Win10 裝機族裡仍有不少USB 共用網卡、舊世代 Wi‑Fi 驅動在睡眠喚醒後會短暫丟 DHCP；若你發現TUN 僅在剛開機正常、睡眠後怪怪的，未必是 Mihomo Party 本身，而更可能是電源管理將介面砍掉後路由表未及時重建。對照這類硬體層級症狀時，先把「問題是否隨 TUN 開關重現」釐清，再決定是否要深入netsh或驅動參數，而不是馬上質疑規則寫錯。

7. 首次開啟 TUN 常見錯誤與排查順序

第一步：讀 Mihomo Party 與核心的文字日誌。與wintun、permission denied、already exists有關的句子，十有八九屬驅動／ACL／舊 TAP 佔位，不要誤認成節點延遲。請避免只看系統匣圖示燈號，因為燈號往往在「應用層已成功」之後才亮，對驅動層失敗並無幫助。

第二步：短暫檢視第三方防毒或 Hosts 工具。Win10 常見套裝仍會攔截「新增虛擬網路介面」或「改寫路由」；若你在企業版看到策略鎖定，只能走 IT 管道。家庭版則可以先用排除清單驗證是否誤判，再把策略改細。

第三步：查舊 VPN、加速盒、或校園撥號殘件。解除安裝後若裝置管理員仍留未知介面，可能讓 Wintun 建立半套。清理前務必備份登錄與驅動資訊，並確保知道如何還原網路堆疊。

第四步：回到 YAML 的 stack、DNS、fake-ip、tun 段與規則排序。若你把所有流量仍導向直連或因 DNS 洩漏讓對端看到本地解析，結果就像「開了 TUN 也沒用」。這種症狀在 Win10 反而更常被忽略，因為它容易被誤以為是「這台電腦老」。

8. 埠占用、DNS、Wi‑Fi／有線共用舊堆疊

症狀一：瀏覽器能上，終端與線上工具逾時。多半是你只成功啟動系統代理，但 Shell／PowerShell／WSL／Git 並未繼承相同策略；解法包括顯式環境變數、工具的git config http.proxy、或直接改 TUN 由底層接管。三套方案擇其一即可，別相互堆疊成「連自己都不知道封包怎麼走」的狀態。

REM Example: show WinHTTP proxy (some apps differ from WinINET)
netsh winhttp show proxy

上述輸出有助分辨仍在走 WinHTTP 的程式是否被遺留在舊伺服器設定上。對照這點可避免把「程式沒跟上系統 Proxy」誤判成 Mihomo Party 壞掉。症狀二：換節點後延遲顯示正常但視訊卡頓，通常是 DNS／SNI／CDN 區域不匹配，需要回到設定檔的dns與規則，而不是重裝 Party。症狀三：mixed-port衝突請用資源監視器或netstat檢查佔用者，改埠後記得讓 Party 重新寫入系統 Proxy，否則 Windows 仍指向舊數字。

若你同時關心 IPv6 與雙堆疊是否帶來意外直連，可延伸閱讀IPv6／雙堆疊校準專文，把「介面層」與「規則層」一起對齊，而不是只盯著 Win10 的小版本號。

9. 上游更新習慣與資料備份

Mihomo Party 的上游開發以 GitHub 為中心，公開儲存庫位於 mihomo-party-org／clash-party；Release 註記與套件名偶爾並行使用「Party／clash-party」詞彙，查 issue 時請以發行標籤為準。追新功能或與驅動相關的修正時，請養成閱讀Release Note的習慣，並在升級前先匯出自己的 profiles、規則覆寫、與書籤過的訂閱清單。自動更新若在 Win10 UAC 上卡住，通常不是「新版本壞」，而是舊資料夾權限或防毒鎖住可執行檔——這時手動解壓覆蓋＋對照雜湊，往往比無限 Retry 來得乾脆。

對長期運維多台 Win10／Win11 混用環境的自架方案維護者，建議將「客戶端版本、mihomo 核心版本號、YAML 自訂段落」寫進固定備忘；未來複製到其他機台時可以快速 diff。若你已熟悉 Party 並想對照本站另一種圖形殼，可把本文與Win11 Mihomo Party 姊妹篇、Win10／Win11 Verge Rev 對照組一起加入書籤，形成一套「換殼不必重學規則」的個人索引。