這篇適合誰：為什麼要在 Ubuntu 走「核心＋systemd」路線
許多教學聚焦圖形用戶端，但在 Linux 上，你常會遇到兩種現實需求：一是桌面環境想盡量精簡、只保留可控的命令列與設定檔；二是雲端或家用伺服器需要穩定守護行程、開機自動復原、日誌可追蹤。Clash Meta（Mihomo）核心在 Linux 上本質上就是單一二進位＋YAML 設定，再交由 systemd 管理生命週期；若你希望應用程式不必逐一手動指代理，則會進一步談到 TUN 虛擬介面與 DNS 搭配。
本文假設你已具備基礎的終端機操作能力，並理解代理工具僅應在合規情境下使用。流程上會刻意採「先手工啟動驗證、再寫 systemd」的順序，避免一開始就把問題藏進服務管理裡而難以二分法排查。若你想先建立 TUN 與系統代理的觀念地圖，可先對照本站Clash TUN 模式完全指南，再回到本頁逐步落地到 Ubuntu。
前置準備：權限、核心與目錄約定
請先確認 CPU 架構與核心版本（x86_64、aarch64 等），並準備一個專用目錄放置二進位與設定，例如使用者家目錄下的 ~/.local/mihomo 或 /opt/mihomo（後者通常需要 root 維護）。維持「執行檔、設定檔、快取與訂閱快取分層」的習慣，未來升級或備份會輕鬆很多。
若你打算啟用 TUN，行程通常需要能建立虛擬介面並調整路由；實務上常見做法是透過 capabilities（例如 CAP_NET_ADMIN）或適當的權限模型授予，而非長期以 root 互動身分執行整個核心。請依你的威脅模型與組織規範選擇最保守且可審計的做法。對核心功能與升級注意事項，亦可延伸閱讀Clash Meta（Mihomo）核心升級指南，避免設定欄位與版本假設脫節。
第一步：取得二進位並建立最小可執行結構
在合規與資安流程下取得與架構相符的預編譯檔後，將其命名為你可辨識的檔名（常見為 mihomo 或發行端約定的名稱），並賦予執行權限。同一目錄內至少包含：
- 核心執行檔（唯讀即可，更新時整檔替換）
config.yaml（主設定；建議納入備份與變更紀錄）- 執行期寫入目錄（快取、GeoIP、規則集下載等，需寫入權限）
若你需要帶圖形介面的 Linux 用戶端，本站用戶端下載頁提供集中整理的取得入口；本文聚焦「核心＋systemd」以便伺服器與進階桌面場景自行裁剪。若你從套件庫或第三方腳本安裝，請務必驗證校驗和與來源可信度，並避免把不明外掛與核心綁在同一個自動更新通道。
第二步：準備 config.yaml 的最小健康檢查
在談 TUN 之前，請先讓「本機入站埠＋出站節點＋基礎規則」能穩定工作。請在用戶端或編輯器中確認：port／socks-port／mixed-port 是否與你預期一致；DNS 區塊是否避免與 TUN 啟用後的解析路徑互相打架（例如 fake-ip 與部分桌面解析器併用時的邊角案例）。此階段建議先用純本機埠測試瀏覽器或 curl -x 是否能命中策略，而不是一次開滿所有開關。
策略組與規則命中順序請維持「越具體越靠前、MATCH 兜底在後」的習慣；當你後續開 TUN，任何誤命中都會被放大成全機流量現象，因此先把規則調到「可預期」再切 TUN，會省下大量時間。
第三步：手工前台啟動，確認日誌與連線
在尚未接入 systemd 前，請於終端機以前台方式啟動核心（以下為示意，請替換為你的執行檔路徑與設定路徑）：
/path/to/mihomo -d /path/to/workdir -f /path/to/config.yaml觀察輸出是否出現監聽埠資訊、訂閱更新是否成功、以及是否有權限或解析錯誤。若前台正常、背景卻失敗，十之八九是工作目錄權限、環境變數差異或SELinux／AppArmor 輪廓（視你的 Ubuntu 衍生版而定）造成；請先把前台與後台的差異列成清單，再進入單元檔調整。
第四步：撰寫 systemd 單元，完成開機自啟
對桌面使用者，使用者層級的 systemd（systemctl --user）通常較好維護：它與登入會話綁定，較符合「個人設定檔」模型。對常駐伺服器，則可能選擇系統層級單元並搭配專用系統帳號。以下提供一個概念範本，實際欄位請依你的路徑、帳號與安全政策調整：
[Unit]
Description=Mihomo (Clash Meta) Daemon
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml
Restart=on-failure
RestartSec=3
# Hardening and capability example (adjust for your policy)
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
NoNewPrivileges=yes
[Install]
WantedBy=multi-user.target重點說明：① After=network-online.target 可降低「網路尚未就緒就拉起核心」的競態；② Restart= 讓短暫錯誤能自動恢復，但仍應搭配日誌監看避免無限重試洗版；③ TUN 相關能力是否透過 AmbientCapabilities 下發，需與你的套件與內核模組狀態一致，若啟動報權限錯誤，請回到「以前台方式」對照訊息精準修。
完成單元檔後，依層級執行 daemon-reload、enable --now，並用 systemctl status 與 journalctl -u 確認穩定性。當服務已可自動啟動，才把注意力轉到 TUN 與全系統對齊。
第五步：啟用 TUN，讓流量依規則進入核心
在設定檔中啟用 TUN 時，請同步檢查三個層次：設定檔中的 tun 區塊（堆疊、閘道、路由標記等選項）、系統是否允許建立 tun 裝置、以及DNS 是否仍指向可解析且符合策略的上游。TUN 的本質是把「作業系統視角下的 IP 封包」導向使用者空間的核心，因此任何路由閉環或解析迴圈都會表現成全機斷網或極慢。
啟用順序建議：先確認無 TUN 時規則與節點穩定，再開 TUN；開啟後立刻以路由表與連線日誌交叉驗證是否仍有應用程式繞過核心。若你使用桌面環境，請留意 NetworkManager 或其他網路管理員是否會在睡眠喚醒後重寫路由；這類問題不一定來自 Clash 本身，而是系統網路堆疊與守護行程的競態。
更完整的 TUN 觀念、漏流案例與跨平台檢查，仍以TUN 模式完全指南為主軸；本文在 Ubuntu 上提供的是「與 systemd 併存」時的落地節奏。
第六步：DNS 與本機解析協同，避免「看似連上卻打不開」
Linux 桌面常同時存在 systemd-resolved、NetworkManager 與瀏覽器內建 DoH；伺服器則可能是 resolved 或靜態 resolv.conf。當核心接管 DNS 請求或返回 fake-ip 時，請明確知道「誰是最後一哩的解析者」，否則你會看到 ping 正常、HTTPS 握手失敗、或只有部分應用異常。
實務上可採取的策略包括：在設定檔中為不同網域指定合適的 DNS 上游、避免把會造成迴圈的本地監聽位址再轉送回去、以及在過渡期用日誌觀察實際命中規則。若你剛從「僅本機 HTTP 埠」切換到 TUN，第一件事應該是用日誌驗證 DNS 查詢是否仍進入核心，而不是先調整大量規則。
第七步：對齊終端機與工具的代理環境變數（與 TUN 並行時的取捨）
即使 TUN 已啟用，部分命令列工具仍可能因自身實作而「不走路由表預期路徑」；因此在伺服器維護或 CI 場景，保留一套明確的 http_proxy／HTTPS_PROXY／ALL_PROXY 仍常是務實做法。請將埠號與協定前綴對齊你的 mixed-port 或分開的 HTTP／SOCKS 設定，並為內網與本機保留合理的 no_proxy。
若你同時開啟 TUN 又設定環境變數，排查時請遵守單一變因：先用其中一條路徑驗證，再疊加另一條，以免日誌中同時出現「虛擬介面轉送」與「HTTP 代理握手」兩種線索而難以解讀。對桌面使用者，亦可視需要在圖形介面設定系統代理，但請記得 Linux 上「系統代理面板」對終端機的覆蓋並非百分之百，核心仍是環境變數與工具自身設定。
常見問題快速分診：權限、路由、與單元失敗
① 單元反覆重啟：先讀 journalctl 是否為設定檔 YAML 語法、訂閱抓取失敗、或埠占用；② TUN 建立失敗：檢查能力集、模組與裝置節點權限；③ 升級後行為改變：比對發行說明與預設值變更，必要時在測試目錄用最小設定重現；④ 部分應用仍直連：回到規則命中與進程是否使用固定 IP／繞過系統解析等路徑。
這類問題最忌「同時改三個地方」；請把每一次變更記錄在簡短備註裡（日期、動機、回滾方式），你在數月後會感謝當下的自己。更廣義的文件索引與使用情境，也可收藏本站使用說明與文件，把 Linux 與其他平台的差異放在同一知識庫裡維護。
結語：把「可驗證」寫進 Ubuntu 的日常運維
相較於依賴一次性腳本，Clash Meta 在 Ubuntu 上的長期穩定，多半來自清楚的目錄邊界、可重現的啟動命令、以及 systemd 可觀測的失敗模式。當你把手工試跑、單元檔、TUN 與 DNS 的順序固定下來，未來無論是換機、升級發行版，或導入更嚴格的權限模型，都能用同一套檢查清單快速回到正軌。
若你希望跨平台都有一致的使用體驗，並在圖形介面與命令列之間取得平衡，選擇文件完整、更新節奏穩定的 Clash 系工具，通常比四處拼湊過期教學更省時間；相比只解決單點問題，建立可審計的流程會讓代理設定真正「上得了生產環境」。