為何在伺服器或 NAS 優先選 Docker 跑核心
Docker 把執行環境與依賴封裝在映像裡，升級時只要改標籤或 digest、重新 compose pull，比直接在宿主機散落多個二進位檔更容易對齊版本。對 NAS 使用者而言，圖形化套件中心往往也是容器包裝，本質仍是「掛卷＋對外埠」；自己寫 docker-compose 反而能把設定檔路徑、備份範圍、重啟策略寫進版本庫，換機或還原時一拉即用。
另一方面，容器代理最常見的用途是只暴露 SOCKS／HTTP Mixed 埠，由區網內其他裝置手動或透過 PAC／系統代理指向宿主 IP；這與在單機上開 TUN 接管整台路由表是不同維度。若您要的是「整台 Linux 桌面全系統接管」，仍建議對照 Linux 安裝 Mihomo 並啟用 TUN：systemd 常駐與桌面分流；本文則補上容器化部署這條路，兩者可並存於不同機器角色。
目錄規劃與卷掛載要點
建議在宿主機建立獨立目錄，例如 ~/mihomo，底下至少包含 config/config.yaml（或您慣用的檔名，但需與容器啟動參數一致）。執行過程中產生的快取、下載的規則集、GeoIP／GeoSite 資料庫，也應一併掛進容器可寫入的路徑，否則每次重建容器都會重新拉檔，既慢也增加上游壓力。
卷掛載有兩種常見寫法：bind mount（直接對應宿主資料夾）與 named volume（由 Docker 管理儲存位置）。家用場景為了備份與直覺，多半用 bind；雲端若不想在 compose 裡寫死絕對路徑，可改用 named volume，但還原時要記得用 docker volume 匯出。無論哪種，請確保宿主目錄權限與容器內執行使用者一致，避免「能起容器卻寫不入快取」的靜默問題。
建議：將整份 config 目錄納入私人 Git 或加密備份；訂閱連結與 secret 請用環境變數或獨立檔案注入，勿把敏感字串長期留在可公開同步的儲存庫。
1docker-compose 範例（映像、卷、埠）
下列為示意骨架：映像名稱與標籤請依您信任的 Registry 調整；重點是 volumes 對應設定目錄、ports 把服務埠轉到宿主，以及 restart 政策。程式內實際監聽埠須與 config.yaml 中 mixed-port、socks-port、port、external-controller 一致。
# docker-compose.yml — example skeleton; adjust image tag and paths
services:
mihomo:
image: metacubex/mihomo:latest
container_name: mihomo
restart: unless-stopped
volumes:
- ./config:/root/.config/mihomo
ports:
- "7890:7890" # HTTP proxy (if enabled in config)
- "7891:7891" # SOCKS
- "7893:7893" # mixed-port example
- "9090:9090" # external-controller (example)
environment:
- TZ=Asia/Taipei
若映像預設工作目錄或設定路徑與上文不同，請改掛載目標或覆寫啟動指令（command）指向您的 config.yaml。部分映像會用環境變數指定訂閱 URL，仍建議以完整 YAML管理規則與策略組，與桌面客戶端匯出格式一致，日後遷移成本較低。
2埠映射：該開哪些、對誰可見
埠映射語意是「宿主 IP:宿主埠 → 容器 埠」。區網裝置若要連線，宿主防火牆與 NAS 安全設定必須允許該埠從區網進入；僅綁 127.0.0.1 時，外機無法直接使用，適合只有本機透過代理連容器。
實務上常映射 Mixed（單埠同時相容 HTTP CONNECT 與 SOCKS）或分開映射 port／socks-port。外部控制器（external-controller）若對外開放，務必在設定檔設強密碼或關閉對外，否則等於在區網甚至公網上暴露管理 API。DNS 相關埠（若您在設定裡開了 dns.listen）是否要映射，取決於您是否打算讓其他裝置把 DNS 指到這台機器；一般僅用 HTTP／SOCKS 代理時，不必對外開 DNS 埠。
安全：將代理埠暴露在公網 IP 上風險極高；若必須遠端使用，請改走 VPN 或 SSH 隧道，而非直接把 Mixed 埠對全世界開放。
3allow-lan 與區網裝置接入容器代理
預設許多核心僅監聽本機位址；要讓宿主以外的裝置連進容器映射出來的埠，需在 config.yaml 開啟 allow-lan: true，並確認監聽位址為 0.0.0.0（或等效設定），否則即使 Docker 已做埠轉發，程式仍可能只接 127.0.0.1。
區網客戶端設定方式：在 Windows／macOS／手機的代理欄位填入「NAS 或伺服器的區網 IP」以及映射後的埠號；若使用 PAC，可把該 IP 寫進腳本。若您同時在區網還有遊戲主機類需求，可延伸閱讀 Switch／PS5 區網代理與閘道思路，概念上都是「找得到宿主 IP＋對外服務埠」。
網路模式：bridge 與 host 的取捨
預設 bridge 最單純：透過 ports 精確控制對外開哪些埠，與其他容器隔離。當您需要讓核心直接看見宿主網卡名稱、或某些進階場景要減少一層 NAT，可評估 network_mode: host；此時 ports 映射常失去意義，因為程式直接佔用宿主網路堆疊，設定錯誤時影響面也較大。
對多數「NAS 當區網代理閘道」讀者，維持 bridge 並清楚映射 Mixed／SOCKS 即可；除非您已理解宿主防火牆、路由與容器網路命名空間的互動，否則不必急著切 host。
容器內啟用 TUN：權限與維運成本
TUN 需要建立虛擬介面並改寫路由，在容器內通常要額外 CAP_NET_ADMIN、掛載 /dev/net/tun，甚至 privileged: true，且仍未必能取代「宿主本身當閘道」的網路模型。許多 Docker 使用者其實不開容器 TUN，改由區網裝置顯式使用代理埠，維運與除錯都更直觀。
若您堅持在容器內實驗 TUN，請在測試環境操作，並確認 NAS 或雲廠商是否允許這類權限；生產環境務必最小權限、僅對內網開放管理介面。DNS 與 Fake-IP 細節可再對照 Meta 核心 DNS 防洩漏終極指南，與是否跑在容器無關，但掛卷後設定檔語法相同。
4驗證流程與常見問題
容器啟動後，先在宿主本機測試映射埠是否通：例如 curl -x socks5h://127.0.0.1:7891 https://ipinfo.io/ip（埠號請替換）。再在區網另一台裝置把代理指到宿主 IP，重複同樣測試。若本機通、區網不通，依序查：防火牆、allow-lan、監聽位址、以及 NAS 是否僅允許本機連線該服務。
設定改了但容器內沒生效
確認卷掛載路徑是否指到正在編輯的那份檔案；部分使用者會誤改宿主備份副本。若核心支援 API 重載，可透過 external-controller 觸發；否則 docker compose restart mihomo 最保險。
規則集或 GEO 資料異常
檢查掛載目錄是否可寫、磁碟是否滿；首次下載 Geo 檔需時間，可看容器日誌。訂閱若為非標準格式，可先參考 Subconverter 訂閱轉換指南 再併入設定。
圖形客戶端與本站資源
伺服器跑 Docker 處理區網出口時，個人電腦與手機仍常搭配圖形客戶端做日常切換；安裝包請優先從 本站 Clash 下載頁 取得，並以 設定說明文件 對照名詞。GitHub 適合查閱開源授權與版本紀錄，與「下載安裝包」分開理解即可。
結語
用 Docker 與 docker-compose 部署 Mihomo，核心僅是三件事：卷掛載讓設定可持久化與備份、埠映射把容器代理能力接到宿主網路、再依需求收斂 allow-lan 與管理 API 的暴露範圍。相較裸機 systemd，容器版更利於版本凍結與多機複製；相較隨手下載二進位檔，compose 檔本身就是文件。
若您已能穩定從區網裝置連上宿主映射埠，代表「容器代理」這條路已打通；後續優化應轉向規則品質、DNS 與策略組命名，而不是反覆改網路堆疊。相較於拼湊多種小工具，基於 Clash Meta 生態的設定語言與工具鏈更一致，長期維護通常更省力。