在伺服器與開發者的工作流程中，Linux 往往以「純命令列、可腳本化、可長期常駐」為核心需求。相較於已具備圖形化客戶端的 Windows 與 macOS，Linux 使用者更常直接在終端機操作編譯、容器與 SSH，因此能否用同一套邏輯接管系統與終端流量，會直接影響日常效率。2026 年社群主流已全面轉向以 Mihomo（Clash Meta） 為核心：它延續 Clash 規則模型，並在協議與效能上持續演進，非常適合在 Ubuntu、Debian 等發行版上以單一二進位檔＋設定檔的方式部署。本篇將從命令列安裝、設定檔結構、啟用 TUN 透明代理，一路到 systemd 開機自啟與日誌排查，協助您建立可維運的 Linux 代理環境。

一、為什麼 Linux 需要獨立談「命令列＋TUN」？

傳統「僅設 HTTP/HTTPS 代理連接埠」的做法，對瀏覽器有效，但對 curl、git、容器拉取映像檔、以及未讀取環境變數的程式往往完全不走代理。若您逐一設定 http_proxy，維護成本會隨工具數量上升而失控。TUN 模式透過在核心建立虛擬網路介面，讓符合規則的流量進入 Mihomo 決策，實務上更接近「全系統透明分流」。在伺服器或桌面 Linux 上，這也是與 macOS「增強模式」概念最對齊的做法。若您想先建立對規則與 DNS 的全域觀，可先參考站內的 Clash Meta 配置指南，再回來落地到本機服務與開機流程。

二、環境準備：Ubuntu／Debian 與核心能力

以下以常見的 Ubuntu 22.04／24.04 LTS 與 Debian 12 為例說明；其他發行版原則相同，差異主要在套件管理員指令。

  • 核心模組：TUN 依賴系統提供 /dev/net/tun，一般桌面與雲端映像檔皆已具備；若缺失請安裝對應核心標頭或檢查虛擬化主機是否停用 TUN。
  • 權限邊界：建立 TUN、調整路由表通常需要 CAP_NET_ADMIN（或以 root 執行）。生產環境建議用專用系統使用者搭配 systemd 的權限欄位，而非長期以 root 互動式啟動。
  • 防火牆與 nftables：若您使用 ufw、firewalld 或自訂 nft 規則，後續啟用 TUN 後若出現迴圈或本機服務異常，需要把「本機繞過／區網直連」納入規則檢查清單。

三、取得 Mihomo 二進位並建立目錄結構

實務上常見流程為：從官方 Release 或可信來源下載與您 CPU 架構相符的壓縮包，解壓後將執行檔放到 /usr/local/bin/ 或 ~/bin/，並以靜態路徑在 systemd 中引用。架構請對照 uname -m：x86_64、aarch64 等需與下載檔名一致，避免「能執行但核心錯誤」的隱性問題。

設定檔目錄建議採用 Mihomo 慣例 ~/.config/mihomo/（若您沿用舊版路徑，也可能是 ~/.config/clash/，重點是啟動參數與實際檔案路徑一致）。目錄內至少包含：

  • config.yaml：主設定（含 port、tun、dns、proxy-groups 等）。
  • 規則集快取與訂閱資料：視您的 rule-providers／proxy-providers 設定而定，請保留足夠磁碟與權限供程序寫入。
// TIP: 與圖形客戶端分流的差異 在純命令列環境沒有「一鍵匯入訂閱」時，您可以把服務商提供的 Clash／Mihomo 訂閱網址寫入 proxy-providers，由核心定期拉取；細部 YAML 結構可對照 Meta 指南中的 Provider 章節逐步拼接。

四、最小可用設定：連接埠、DNS 與 TUN 區塊

在啟動服務前，請確認 config.yaml 中監聽位址與本機防火牆一致；若僅本機使用，可綁定 127.0.0.1 降低暴露面。DNS 方面，建議啟用與規則一致的解析策略（例如 fake-ip 與 nameserver-policy），否則常見現象是「網頁能開、但部分網域反覆重導或解析到錯誤節點」。以下為示意結構（請依您的訂閱與規則補齊完整欄位）：

# Example skeleton — replace with your full config
mixed-port: 7890
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.google/dns-query

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

tun.stack 可選 system 或 gvisor 等，依核心版本與相容性調整；auto-route 會嘗試寫入系統路由，若與既有 VPN 或公司內網衝突，需回頭檢視規則中的「直連／繞過」列表與介面偵測設定。

五、啟動測試：前景執行與日誌觀察

在尚未交給 systemd 前，建議先以一般使用者或將使用的服務帳號前景啟動一次，確認設定檔可被解析、訂閱可拉取、TUN 可建立。啟動參數通常包含設定目錄，例如：

mihomo -d ~/.config/mihomo

若出現權限不足，請先檢查是否缺少 CAP_NET_ADMIN，或暫時以可驗證環境的方式提高權限（僅限測試）。畫面上若持續出現 DNS 或路由錯誤，請同步開啟 log-level: debug（短期）並對照上游節點與規則命中情況。當前景測試穩定後，再進入下一節的常駐化。

六、systemd 常駐與開機自啟

將長時間執行的代理交給 systemd，可獲得開機自動啟動、異常自動重啟、統一日誌與權限最小化等好處。典型做法是建立 /etc/systemd/system/mihomo.service（檔名可自訂），內容包含執行檔絕對路徑、工作目錄或環境變數、以及必要的權限宣告。以下為示意範例，實際路徑與使用者請替換為您的主機設定：

[Unit]
Description=Mihomo (Clash Meta) Service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=your-user
Group=your-group
ExecStart=/usr/local/bin/mihomo -d /home/your-user/.config/mihomo
Restart=on-failure
RestartSec=3
AmbientCapabilities=CAP_NET_ADMIN
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

寫入後執行 sudo systemctl daemon-reload，接著 sudo systemctl enable --now mihomo.service 即可完成開機自啟與立即啟動。日常排查可使用 journalctl -u mihomo.service -e 檢視最近事件；若您更改設定檔，依部署習慣可選擇重啟服務或透過 API 熱載（若您有啟用對外 API 並做好存取控制）。

// WARNING: 遠端伺服器操作風險 若您透過 SSH 連線到同一台機器調整路由與 TUN，錯誤設定可能導致連線中斷且難以回復。建議在實體主控台、帶外管理（IPMI）或具備救援連線的情境下操作，或先備妥還原路由的指令與防火牆規則。

七、常見故障與排查方向

1. TUN 建立失敗：檢查帳號權限、/dev/net/tun 是否存在、以及其他守護行程是否占用相同策略路由。

2. 能連外網但 DNS 怪異：確認 dns.enable 與 enhanced-mode 是否與規則匹配；必要時為內網網域設定 nameserver-policy 或直連規則，避免內部服務被導到代理。

3. 本機服務變慢或無法連線：檢視模式是否誤設為 global、規則是否缺少對區網與本機位址的直連；同時檢查 tun 的介面偵測是否指向錯誤網卡。

4. systemd 反覆重啟：以 systemctl status 與 journalctl 查看退出碼；常見原因是設定檔語法錯誤、資料目錄不可寫入、或二進位架構不符。

八、結語：把 Linux 代理變成「可維運」而非「一次性腳本」

在 Linux 上部署 Clash 生態的核心價值，是把分流規則、DNS 與透明流量接管收斂成可版本化、可重啟、可觀測的服務。相較於僅在 shell 裡臨時匯出代理變數，TUN 搭配 systemd 能顯著降低長期維護成本，也更符合伺服器與開發主機的使用節奏。若您同時需要桌面平台對照，亦可一併參考站內其他系統的教學文章，維持跨裝置一致的規則思維。

若您希望省去四處尋找核心與相容客戶端的時間，想直接取得經過整理的安裝入口與更新節奏，歡迎從本站下載頁取得適合各平台的 Clash 用戶端與資源導引；相較於零散來源，集中入口能減少下錯架構或誤用過期版本所造成的連線不穩。

→ 立即免費下載 Clash，開啟流暢上網新體驗