1 為什麼要在 Linux 原生 KVM 上單獨談 Mihomo
本站已涵蓋 Hyper-V、VMware、Parallels、WSL2 等宿主環境；在Linux 桌面或伺服器上，虛擬化堆疊改為 QEMU 加上 libvirt，預設網路常是由 Linux 核心與 libvirt 建立的 NAT 橋（virbr0），與 Windows 上 VMnet 的編號習慣不同。若您沿用「找 .1 當閘道」的直覺，方向大致正確，但實際位址區段與防火牆後端（nftables／iptables、firewalld）必須以 ip addr show virbr0 為準，而不是抄教學裡的固定 192.168.x.x。
Mihomo延續 Clash.Meta 的 YAML 與規則生態，圖形用戶端（例如 Clash Verge Rev）在 Linux 上同樣常監聽 127.0.0.1 的混合埠；訪客機若要連入，必須改為允許區網介面（介面常稱 Allow LAN），並確認宿主機轉送介面上的 IPv4 可被訪客機路由到。以下兩條路徑——「整台訪客機應用層走代理」與「只在宿主機做埠轉發進 VM」——目標不同，請先選拓樸再動設定檔，可避免把 NAT 與反向代理混成一團。
2 libvirt 預設 NAT：virbr0、閘道與訪客機視角
安裝 KVM 並使用預設「網路」時，多數發行版會建立名為 virbr0 的虛擬橋，並由 libvirt 的 dnsmasq 為訪客機配發 DHCP。訪客機內執行 ip route 所看到的預設閘道，通常就是宿主機在該橋上的 IPv4（常見為 192.168.122.1，實際請以現場為準）。對外流量由宿主機做位址轉換，因此訪客機不需為了「上網」而手動把預設閘道改成 Mihomo；您要做的是讓需要代理的程式連到宿主機在 virbr0 上的 IP，再加上 Mihomo 的 HTTP／Socks／mixed-port。
與 VMware NAT 與宿主機 Clash一文對照：VMnet8 與 virbr0 角色類似，都是「訪客機私網 ↔ 宿主機 NAT 出口」；差別在於 Linux 上您更常直接用 nmcli、ip、ss -tlnp 排查，而不是圖形「網路連線」資料夾。若您同時在宿主機跑 Docker，也請注意是否另有 docker0 或自訂橋，避免把代理 IP 抄錯成另一張虛擬介面的位址。
ip -4 addr show dev virbr03 在 NAT 拓樸下讓訪客機走宿主機 Mihomo
步驟可收斂為四件事：① 在宿主機查 virbr0（或您自訂之 NAT 橋）的 IPv4；② 在 Mihomo／用戶端設定中開啟允許區網連入監聽埠，並確認綁定介面包含該位址或 0.0.0.0（依用戶端語意而定）；③ 在訪客機設定 http_proxy／HTTPS_PROXY／ALL_PROXY 指向 http://<步驟①的IP>:<mixed-port>，或使用等價的 Socks URI；④ 用 curl -x 從訪客機測試，再開瀏覽器或 apt。若第④步連線被拒，多半是②未開或宿主機防火牆未放行自 virbr0 入站，與機場節點品質無關。
無圖形介面時，可在設定檔確認 bind-address、mixed-port 等欄位；細節可延伸閱讀Linux 安裝 Mihomo 並以 systemd 常駐，把宿主機服務先穩定後再掛虛擬機。需要圖形儀表板與外部控制器時，亦請避免將控制器埠誤開在不可信介面；開發機可僅綁 127.0.0.1 再透過 SSH 轉發。
4 NAT 埠轉發：對外服務進 VM，與「VM 內走代理」是分開需求
埠轉發典型需求是：宿主機或上游路由器對某 TCP／UDP 埠的連線，要轉到訪客機內某服務（例如 SSH、HTTP 測試站）。在 libvirt 中可透過 <port forwarding> 型態的 XML、hook 腳本，或於宿主機以 nft／iptables 做 DNAT 至訪客機在 NAT 網段上的位址。這條路徑不會自動讓訪客機對外下載走 Mihomo；它只是把「從外頭打進來的連線」導向 VM。
若您的目標是讓訪客機主動對外（apt、podman pull、瀏覽器）穩定經代理，請優先採上一節的應用層代理或宿主機 TUN 類全流量方案，而不是只設埠轉發。兩者可以並存：例如同時轉發 2222→22 方便 SSH 進 VM，再在 VM 內設 HTTPS_PROXY 走宿主機混合埠。混淆兩種需求時，最常見的症狀是「以為設了轉發就會代理 apt」，結果套件索引仍直連逾時。
5 QEMU 使用者模式網路（-netdev user）與 10.0.2.2
當您不用 libvirt、而以原生 qemu-system-x86_64 搭配 -netdev user,id=net0 與 -device virtio-net-pci,netdev=net0 時，訪客機會落在 QEMU 內建的 slirp 使用者模式網段（常見為 10.0.2.0/24）。此時訪客機內固定可把宿主機視為 10.0.2.2——這是 QEMU 文件約定的宿主機別名，不必先查 virbr0。因此設定代理時可寫 http://10.0.2.2:7890（埠號以您的 Mihomo 為準），在教學與自動化腳本裡特別好維護。
使用者模式網路的限制是效能與通訊方向性（例如預設不適合高吞吐或部分進階協定），且與 libvirt NAT 是兩套不同堆疊；請勿把在 virbr0 上量到的宿主機 IP 硬套到 slirp 訪客機，也不要在 libvirt 管理的 VM 上假設一定有 10.0.2.2——是否出現取決於該 VM 的 XML 網路後端型別。若您從 virt-manager 建立 VM，預設多半是 libvirt 的 NAT 而非純 QEMU user，請以訪客機內實際路由與文件為準。
virbr0 上的宿主機位址。QEMU user：代理主機名可記 10.0.2.2。兩者擇一，先確認您的 VM 究竟掛在哪種後端。
6 virt-manager：網路來源、macvtap 與「訪客機看不看得到宿主機」
在 virt-manager 中編輯 NIC 時，「網路來源」常見為 NAT（預設網路）、橋接（接到您建立的 linux bridge）、或 macvtap。其中 macvtap 在 vepa／bridge 模式下，訪客機與宿主機之間可能無法像典型 NAT 私網那樣雙向 ping 通管理 IP——許多使用者因此發現「VM 能上網卻連不到宿主機上的 Clash 埠」。若您的代理只開在宿主機而訪客機必須直連該埠，請改回同一橋上的 NAT 網路、額外加一張專用管理網卡，或改用 SSH 反向隧道等替代方案，不要只在 macvtap 上硬試同一組 IP。
實務上開發機最常勝出的組合仍是：預設 NAT 負責上網與到宿主機代理，必要時再加一張橋接網卡讓 VM 與區網其他裝置同層互通。多網卡時請在訪客機內確認預設路由與DNS綁在哪張介面，避免流量從 A 卡出去卻把 HTTP_PROXY 指到 B 卡才看得到的位址。
7 橋接：訪客機與區網同層時，代理 IP 改指宿主機區網位址
當訪客機網卡橋到實體區網時，宿主機在訪客機眼中是「同一子網路上的另一台機器」，與 VMware 橋接敘述一致：請在宿主機查目前連線到路由器的那張介面 IPv4（例如 wlp2s0 或 enp3s0 上的位址），訪客機代理設定指向該區網 IP。公司網路若有用戶隔離或 802.1X，可能出現「訪客機拿不到與宿主機互通的二層路徑」，此時應先與網管確認政策，再回退到單純 NAT 開發環境。
8 apt、Podman／Docker 與環境變數
Debian／Ubuntu 系訪客機可於 /etc/apt/apt.conf.d/ 內設定 Acquire::http::Proxy 與 Acquire::https::Proxy，指向宿主機代理；亦可只在 shell 匯出 http_proxy 後執行單次安裝。容器引擎拉映像時，請區分「在訪客機 OS上執行 docker pull」與「在容器內再建網路」兩層：前者繼承訪客機的 daemon 設定與環境變數，後者常需額外設定 buildkit／daemon.json 的代理，否則仍會直連 registry。
若訪客機內也安裝了一套 Mihomo 當「二跳」出口，請避免與宿主機使用完全相同的本機監聽埠而造成混淆；命名上建議區分「連宿主機的 upstream」與「本機入站」，並在註解中標明對應關係，日後升級較不易被還原覆蓋。
curl -I -x http://192.168.122.1:7890 https://www.debian.org/9 DNS、fake-ip 與 Linux 宿主機防火牆
宿主機若啟用 fake-ip 或自訂 DNS 流程，訪客機不會自動繼承；訪客機仍可能用 DHCP 配到的上游做解析，出現「瀏覽器偶發失敗、換 IP 直連卻正常」的假性節點故障。建議在訪客機明確設定可信 DNS，或讓 DNS 查詢也經由代理路徑（視模式與用戶端能力而定），並留意 systemd-resolved 與 NetworkManager 的優先順序。
在宿主機上，firewalld 可能預設將 virbr0 歸入 trusted 或 libvirt 區；若您曾手動強化規則，請用 firewall-cmd --list-all 或對等指令確認自 libvirt 介面到本機監聽埠未被 DROP。使用 nftables 自管全表時，亦請避免在 INPUT 鏈全面攔截導致訪客機無法連到混合埠。與 TUN 全流量模式疊加時，可一併參考Clash Verge Rev TUN 模式指南，釐清路由與本機程序行為。
10 驗證清單（依序做，少繞路）
- 訪客機內確認網路後端：預設閘道、介面名稱、是否為
10.0.2.x（暗示 user）或192.168.122.x（常見 libvirt）。 - 宿主機確認 Mihomo 監聽位址與埠，並開啟區網連入。
- 訪客機
curl -x測試 HTTPS，再測apt／映像拉取。 - 若需對外轉發服務進 VM，另開「埠轉發」工作項，勿與代理需求混寫同一組設定。
- 若改 macvtap 後連不到宿主機埠，先改回 NAT 驗證，再決定拓樸。
11 總結
在 Linux 上以 QEMU／KVM 跑虛擬機並複用宿主機 Mihomo，關鍵是先認定網路後端是 libvirt NAT 還是 QEMU 使用者模式：前者把代理指到 virbr0（或您自訂 NAT 橋）上的宿主機 IPv4；後者可慣用 10.0.2.2 作為宿主機位址。NAT 埠轉發服務的是「由外而內連進 VM」，與「VM 主動流量走代理」應分開設計。virt-manager 下選到 macvtap 時，要額外確認訪客機與宿主機是否仍能 L3 互通到代理埠。
相較在每台訪客機重複訂閱與規則維護，讓開發／測試機出口收斂到宿主機同一套 Clash 相容策略，長期可讀性與除錯成本通常更好；若您尚未在 Linux 桌面裝好用戶端，可從本站下載頁取得與教學一致的版本後，再銜接 systemd 與本文明細的網路拓樸。
相較其他同類工具，Clash 系在規則表達與社群累積上更利於「宿主機統一出口、虛擬機只指代理」這類開發者場景；把拓樸畫清楚後，KVM 與 Mihomo 的組合在裸機 Linux 上同樣能穩定落地。
