NixOS 上首次配置 Clash 系客戶端：flake、home-manager 與 systemd 使用者自啟分步（2026）

為什麼 NixOS 需要獨立一篇？和「用 AppImage 裝一裝」差在哪？

NixOS 把可執行檔、函式庫與啟用腳本都收斂到 /nix/store 的唯讀路徑；你登入圖形工作階段看到的「有沒有某個圖示」，取決於你的 configuration.nix、home-manager 匯出，以及 flake 把哪些輸出（packages、devShells、nixosConfigurations、homeConfigurations）釘在一起。多數人第一次卡在「我已經在 nixpkgs 找到 mihomo 或圖形前端了，但更新後 ExecStart 的雜湊變了，systemd 使用者單元卻沒重載，服務以為舊路徑還在」；另一種卡法是「訂閱其實下載了，但客戶端讀的 ~/.config 與你在家目錄實際掛上的 home-manager 路徑不同」。要一次把 安裝、訂閱、重開機後仍可預測的啟動行為串成路徑，就必須從 Nix 模組觀而不是從雜湊式的「手動 wget 丟在 ~/Downloads」開始。

本站在其他發行版已寫滿「訂閱匯入＋systemd 使用者層自啟」的圖形客戶端文；與 Debian 12 專文 或 Arch 的 AUR 寫法 比起來，NixOS 多出的關卡是 宣告式可重現 與 雜湊化路徑，而不是 Clash 的 YAML 語法變了。若你對 proxy-groups 與 規則順序還不熟，仍建議先讀 Clash 代理群組（proxy-groups）完全指南，回來寫 home-manager 時，才知道要把哪些可選項寫在模組參數、哪些要留在圖形客戶端裡用「訂閱＋匯出」解決。

名詞釐清：Mihomo、Clash 系圖形殼、與 nixpkgs 裡你會看到的名字

社群所說的 Clash 系 客戶端，多半指「內建或打包 Clash Meta（實作常稱 Mihomo 核心）＋ 圖形或 TUI 殼，再讀 YAML 設定與 proxy-groups」。在 nixpkgs 裡，你常看到 mihomo 以 CLI 或守護程式的形式出現，而圖形前端則有社群自行打包、或透過 unstable／第三方 overlay 帶入的分支。重點不是「全站都要同一個 nix 路徑才叫正統」，而是：

1. 哪一個實作負責接聽本機代理埠、哪一個負責畫 UI；兩邊的執行檔路徑在 nixos-rebuild 或 home-manager switch 之後，是否都指向同一次建置的函式圖。
2. 你的訂閱匯入是落在圖形客戶端所預期目錄，還是你手動在 ~/.config/mihomo 一類路徑放檔，而 home-manager 又有另一層產生器蓋寫。路徑打架時，症狀通常是「系統層 nix 指到 A、登入圖形卻在讀 B」。

我們在 Clash 生態 2026 與 Clash Meta 與 Premium 比較 已整理過內核差異，這裡不展開內部路線之爭，只把 Nix 使用者 需要的句子講清：用 Nix 裝的 Clash 系 仍然遵守同一套 YAML 與訂閱概念，多出的成本是學會用 nixos-rebuild 與 home-manager 讓變更可回滾、可審查。

先選路：只用 home-manager 家目錄，還是 system 層＋家目錄分層？

在 NixOS 實作裡，常見兩個層次：系統層 configuration.nix 負責 TUN 模組、核心能力、systemd 層政策與有時的網路堆疊；home-manager 則專心處理你登入後的家目錄產生、圖形客戶端 與 systemd 使用者單元。第一次落地時，建議以「圖形桌面登入後要用的代理都放 home 層、需要核心或全域設備名稱的再拉到 system 層」分界，減少一顆設定改完卻不確定是誰產生檔的焦慮。若你同時參考 TUN 模式深度解析 裡的透明代理觀念，在 NixOS 上要特別注意 與 Nix 建置的容器／VM 實驗同時打開 TUN 時的衝突，這一點與單純的「桌面 Linux ＋Clash」不同，斷網除錯時要先把變因拆開。

Flake 的價值在於你能在單一倉庫內，把 nixosConfigurations 與 homeConfigurations 的輸出釘在相同的 inputs 版本 上。第一次配 Clash 系 時，若還在頻繁調整圖形客戶端，先用「讓圖形殼讀寫的設定目錄可預測、訂閱有地方落」為第一目標，再回頭把 flake 模組參數收斂成乾淨的 modules 樹。這條路與在 OpenWrt 上跑 OpenClash 的「以路由器職分思考」是平行軸，只是 NixOS 的邊界在於可重現的 Nix 表達式，不是 LuCI 的點按鈕。

flake 與 home-manager：一條從可重現到「可以每天切換」的軸心

實作面你可以把 flake.nix 定義成：輸出本機的 nixosConfigurations.你的主機 與 homeConfigurations.你的帳號@你的主機 兩條。日常指令會圍繞在 nixos-rebuild switch（當家目錄模組是 system 匯出時）與 home-manager switch（家目錄專屬）兩邊。第一次配 Clash 系 時，務必記一條 Nix 鐵則：/nix/store 裡的每個執行檔路徑都帶內容位址的雜湊，更新通道或 flake lock 之後，舊的 ExecStart= 自然失效；要嘛讓 home-manager 幫你重新產生 systemd 使用者單元 裡的 ExecStart，要嘛把服務從靜態路徑改成包在 Path 裡、由產生器在每次 switch 重寫，而不是在 ~/.config/systemd/user/*.service 寫死一條人類可讀的 /nix/store/...-mihomo-1.x/bin/mihomo 又忘了更新。這也是為什麼在 NixOS 教學 裡我們反覆掛鉤 home-manager，而不是單寫一個從上游僅手動下載的 AppImage 教學就好——前者是釘版本的世界觀，後者常把「訂閱有更新、但執行檔舊雜湊沒了」的錯誤藏在使用者層，表現成莫名的崩潰日誌。

在整理 flake 輸入 時，盡量只信任你知道上游在做什麼的通道或 flake.lock 裡的 commit；代理 客戶端屬於高權限、可觀測你大部分 HTTPS 的程式，安裝包來源 的說明可先看本站 下載頁 的一級導向，與從 GitHub 讀專案說明、提報 issue 的用途分開，避免讀者誤以為「非跳 Release 就無法安裝」；在 Nix 世界，正確的說法通常是「用 nix expression 從可驗證的原始碼與雜湊建置，再由系統產生執行檔」。

訂閱匯入、啟用中設定檔，與家目錄內的「誰產生誰」

圖形 Clash 系 客戶端在圖層內的操作，與 macOS 初配 或 WSL2 內的代理對齊 文章描述的操作類似：取得訂閱網址、在介面內執行更新、選啟用中的設定、檢查 proxy-groups 是否真的有節點。在 NixOS 上多出的兩層是：

1. home-manager 是否用 xdg 產生器重寫了 ~/.config 內的某幾條，導致圖形殼的「儲存」寫在暫路徑、下次 switch 被覆寫。第一次配時，建議在改模組之間保留備份、並用 git 或至少檔名註日期的備份夾，避免一次 home-manager 參數改錯、訂閱沒丟、節點卻變成空白。
2. 在 headless 或 SSH 沒圖層的場景，不要以為「systemctl --user 有跑就能代表圖形殼有正常畫出來」；systemd 使用者層 的排錯在 Debian 專文 的 FAQ 也提過。你在 NixOS 的圖形工作階段，仍然應以「登入圖層＝Wayland／X11 的 graphical-session.target」掛鈎自啟，與在伺服器上跑常駐守護的用法不同。

針對訂閱本身會失效、或節點全空，仍請回到 訂閱連結那些事 的思維：先釐清帳戶與 URL，再懷疑 Clash 客戶端。若你打算用自訂規則把特定網域釘在特定群組，再讀 自訂規則教學 搭配本機測試，不要一次把規則寫到與訂閱產生器衝突的兩層產生器上。

systemd --user：在 NixOS 圖形登入下自啟圖形殼或常駐核心

與 Ubuntu 24.04 文 相同，我們把「開機自啟」的實用含義釘在「圖形工作階段就緒之後、使用者帳號下的常駐」，而不是在顯示伺服器未起時硬開圖形程式。在 NixOS，你可以由 home-manager 的 systemd.user.services（實際模組屬性名以你使用的 home-manager 版本與手冊為準）描述服務、並用 WantedBy = [ "graphical-session.target" ] 一類的綁定，讓 systemctl --user status 的日誌在「訂閱沒匯到」與「執行檔雜湊斷了」之間看得出差異。一個在純 Debian 寫的靜態 ExecStart=/nix/store/.... 範例，往往不該原樣照貼在 NixOS 長期工作流 裡，而應該回到「由模組產生服務檔」的原則。下方骨架僅在概念上示範 單元檔的段落，實際專案請以你產生器寫入的內容為準：

[Unit]
Description=Clash-family GUI (user session, NixOS)
PartOf=graphical-session.target
After=graphical-session-pre.target

[Service]
Type=simple
# ExecStart must be provided by a generator or `home-manager` output
# (never a stale /nix/store/... path copied by hand)
ExecStart=REPLACE_WITH_GENERATED_PATH
Restart=on-failure

[Install]
WantedBy=graphical-session.target

在筆電單一使用者圖形登入的情境，一般不需要 loginctl enable-linger 來幫圖形殼續命；linger 常用於要讓 systemd 使用者層 在沒圖層的登入下仍執行某些長駐，與有畫面可互動的 Clash 系 圖形殼不必然同一用途。要延伸「全系統 TUN 與 DNS 觀念」的讀者，可再併讀 Clash 使用教學 與 TUN 專文，但請記得在 NixOS 上任何內核或網路相關模組更動幾乎都牽涉 nixos-rebuild 與重啟的節點，與只改圖形客戶端不同。

常見坑與分步除錯：把「Nix 更新」從心態上分開

若介面顯示連不上或訂閱更新失敗，建議在 NixOS 用這條順序，避免一開始就歸因到 YAML：

1. 系統時間與 HTTPS 憑證是否正常；在筆電長期斷網的環境，時間漂移會讓多數訂閱抓不下來。
2. 你目前的 DNS 是否與圖層的 Clash 系 fake-ip 設計衝突；先把分流暫到「能連上的最小集」、再慢慢加自訂規則。概念與我們在 TUN 文 討論的對齊一致。
3. nixos-rebuild 或 home-manager switch 之後，systemd 使用者守護是否重載、ExecStart 所指的 /nix/store 路徑是否隨之更新。若 status 出現 203/EXEC 一類的錯誤，幾乎都是舊雜湊。
4. 在裝了公司全機 VPN 隧道或另一套透明代理的時候，路由可能互蓋；與在 Zoom、Teams 文 的建議相同，先關掉其中一邊測一輪，縮小變因。

安全、合規與信任邊界

任何本機 代理 都會站在大量 TLS 連線的關口；訂閱 內容與遠端節點也屬於你必須自行判斷信任範圍的資產。本文只從 Nix 宣告式 與 Clash 系 的落地說法提供除錯節點，不提供規避法律、突破授權或侵權用途的建議。公共熱點的 Captive portal 要先把本機臨時切到能完成入口頁的網路，再開 Clash 類規則，也與其他桌面發行版的常識相同。

常見問題

我可以混用從 nix 裝的 mihomo 與從專案 Release 下載的圖形殼嗎？

在技術上「可能可以」，在可維運性上常見的結果是兩邊的執行檔路徑、設定目錄、更新節點不同步。第一次配 NixOS 時，建議堅持同一次建置圖裡能追到的套件組合，讓 switch 之後的狀態能一句話還原。

我照抄了別人的 flake，為什麼一 switch 圖形殼不見了？

別人的 homeConfiguration 可能沒有把圖形殼帶入你的帳戶的 home.packages 或沒有啟用對應的模組。請先確認 輸出真的包含你的使用者在用的主機維度，而不是以為名字相同就等於帳戶相同。

systemctl --user 顯示成功，但沒有工作列圖示？

有些圖形殼可以只在匣道存在；也有一部分版本在 Wayland 上對「登入自啟」的整合不同。此時以日誌與「手動在終端執行同一 Exec 路徑」雙邊比對，通常比亂刪 Nix 建置還能定位問題。

總之，在 NixOS 上把 Clash 系 用成可長期維運的桌機工具，成敗通常繫於三件事：同一次 flake／home-manager 圖內的執行檔與家目錄產生器一致、訂閱與啟用中檔的落點可預測、systemd 使用者層 的 ExecStart 跟得上 /nix/store 的變遷。把這層學起來之後，你在規則面與節點面就能放心沿用本站其他圖文（例如 自訂規則、訂閱 FAQ、或各情境分流教學），而不用每次都在「為什麼 nix 裝的軟體跟我想像的路徑不同」上耗掉整晚。同樣以規則彈性與社群實作深度取勝的前提下，Clash 系列在桌面長期自維上往往比封閉的整機 VPN 敘事更容易對齊開發者與多工作階段的需求。若你正在找一個能搭配上述流程的正式版本，歡迎先從本站取得安裝入口，實測匯入、切節點、除錯節點是否順手。→ 立即免費下載 Clash，開啟流暢上網新體驗。