NixOS で Clash 系クライアントを初めて揃える：flake、home-manager、systemd ユーザーサービス（2026）
「NixOS」「Clash」「flake」「home-manager」で検索して辿り着いた方むけに、宣言的な OS で Mihomo／Clash Meta 系コアを入れ、購読（サブスクリプション）URL からルール群を取り込み、systemd --user でデスクトップにログインした直後からプロキシ常駐までを一気通貫で整理します。従来の Ubuntu や Debian、Arch 向け手順はパッージングの前提がまったく違うため、本稿は Ubuntu 24.04 向け・Debian 12 向け・Arch 向け とは被らない切り口です。immutable な /nix/store 由来のパス扱いと、設定の再現性 を意識したときの罠もまとめます。
この記事の前提と、他の Linux 手順との違い
対象は、すでに flake ベースで NixOS を組んでいるか、これから導入する方です。本稿は「1 行の apt install で終わる」世界ではありません。代わりに、同じ .nix を共有すれば他マシンでも同じ挙動 に近づけられる、という取引があります。Clash 系の位置づけは Clash エコシステムの整理 を参照し、コア（Mihomo／Clash Meta 互換）と フロントエンド（例：各種 GUI）を分けて考えてください。Nix ではどちらも pkgs かオーバーレイ、あるいはフレーク入出力で指定します。コアの挙動（嗅探、DNS まわり）は Clash Meta／Mihomo の sniffing と DNS も併せて読むと、症状の切り分けが速くなります。
以降で触れるモジュール名・オプション名は nixpkgs や home-manager の バージョンで差が出る ため、必ず man home-configuration.nix や NixOS／HM の検索サイトで、お使いの rev に合う記述に読み替えてください。思想として押さえたいのは次の 3 点です。（1）バイナリは /nix/store/<hash>-mihomo/bin/mihomo のように ハッシュ入り。（2）そのため手書きの絶対パスは 次のビルドで壊れやすい。（3）ExecStart やパッケージ参照は、可能な限り ${pkgs.mihomo}/bin/mihomo のように Nix 式の補間 に寄せる。
flake 入力の整理と、Nix パッケージとしてのコア
典型例は、フレークの inputs に nixpkgs と（必要なら）home-manager を置き、outputs で NixOS 構成子と home-manager のモジュールを束ねる形です。チャンネル固定ではなく、flake.lock に rev が焼かれる点が、他ディストリの「同じ週に同じ apt update」とは違います。更新は意図したときに nix flake update（または入出力をピン留め替え）で行い、nixos-rebuild switch や home-manager switch で反映します。購読 URL やトークンをそのまま Git に書くのは避け、購読 URL の扱い も合わせて整理してください。
コアとしては nixpkgs 同梱の pkgs.mihomo や、用途に合わせた Clash Meta 系のビルド を選びます。GUI が欲しければ、同じフレームワークで 同じ nixpkgs リビジョン上の クライアントに寄せ、ABI の食い違いを減らします。ここは「従来 Linux と同じ AppImage 落として chmod」より、宣言的に一括が基本です。入手の導線としては、本サイトの ダウンロードページ で各クライアントの位置づけを把握し、実体の導入は Nix 式で固める、という二段に分けるのが扱いやすいです。
home-manager：設定ファイル、購読、ユーザー環境
home-manager では、ホームの下に生成する設定 YAML／JSON の場所、および プロキシ用のシェル連携（home.sessionVariables や任意の shellAliases）を一括管理できます。購読は「生成されたファイル内に平文の URL」にしたくない場合、agenix、sops-nix など、Nix コミュニティで定番のシークレット管理を併用し、ビルド時にのみ復号・配置するパターンが多いです。手早く試す段階では、権限の狭いパス（例：~/.config/… かつ 600）に一時的に置き、のちに SOPS 等へ移す、でも構いません。
home-manager 側に Mihomo 用のモジュール がある rev なら、configFile かパッチ相当の 重ね貼り、さらに systemd.user 連携の有無を確認し、二重起動（同じコアを HM と手書きユニットの両方で起動）になっていないかに注意します。ルールの追記方針は カスタムルールの入門 を参照し、購読で上書きされる行と競合しないよう、rules の順序を踏まえてください。
systemd --user：ログイン後の自動起動と unit の書き方
従来 Linux で一般的な「~/.config/systemd/user/foo.service を生で書く」手順も、Nix なら 同じ定義の中に宣言 できます。重要なのは、ExecStart が ストア上の mihomo/clash バイナリ を指し、作業用ディレクトリ（ランタイムの状態、キャッシュ、DB）が ReadWritePaths や StateDirectory（system 用だが、ユーザー unit では RuntimeDirectory／ExecStart の --dir 相当）で書き込み可能なこと、くらいです。Wayland 下で GUI フロントを載せる場合は、After=graphical-session.target を置く、といった Debian 向け例 と同系の考え方が当たります。違いは、ExecStart 行を手で書かず、Nix が閉じた式で生成する ことで、次回の nixos-rebuild 後も一貫することです。
ログの見方は他ディストリ同様、journalctl --user -u ユニット名 -b です。起動しないときは、（1）バイナリのパスが古い hash を指していないか、（2）サンドボックス系の ProtectSystem などで設定置き場に書けていないか、（3）TUN や権限系は TUN モードの文脈 で別解が必要か、の順に絞ると早いです。
linger ありのユーザーデーモンは「ログイン前から常駐」に近づけられますが、デスクトップ用 GUI と組み合わせると期待とズレることがあります。まずは通常の ログイン後自動起動 から試すのが安全です。
immutable なストアと、よくあるはまりどころ
（1）手動で /nix/store 以下のファイルを書き換えた つもりの設定が、次の garbage collect や再ビルドで消える。（2）他マシンからコピーした絶対パス の unit が、ローカルでは別 hash を指し続ける。（3）nix-shell -p だけで起動して試した挙動と、rebuild 後の systemd の挙動が違う、などです。解決策は一貫して「単一の flake.nix または configuration.nix／HM に落とし、同じ pkgs rev で評価する」ことです。GUI を使わずコアだけで捌く場合のメリットは、再現可能な config.yaml の形に寄せやすいこと。逆に、GUI が購読を都度上書きする挙向なら、宣言的と実運用の衝突 を避けるため、どちらを「正」とするかを最初に決めます。
オーバーレイでフォーク版のビルドを当てる場合は、同じ inputs ツリー内に閉じ、レビュー可能な形で pin するのがおすすめです。大きなセキュリティ観点では、信頼できる導入元（nixpkgs か、審査した flake）に限定し、平文の購読 URL をリポジトリに残さない、が鉄則です。
ビルドと適用、そして挙動確認の流れ
作業の流れを抽象化すると次の通りです。フレークを更新（必要なら） → sudo nixos-rebuild switch --flake .# でシステム → home-manager switch --flake .#<user>@<host> などでホーム → systemctl --user daemon-reload && systemctl --user restart …。初回は status で active を確認し、ブラウザのプロキシが期待どおりなら、必要に応じて TUN やルール拡張へ進みます。用語の腹落ちは チュートリアル全般 も併用してください。サブスクリプション周りの典型トラブルは 購読 FAQ に集約しています。
コマンド断片のイメージとして、式の中で補間される ことがポイントです。実際の属性名はお使いの Nix 版に合わせてください。
# Example shape only; adjust attribute names to your nixpkgs / HM revision.
# ExecStart = "${pkgs.mihomo}/bin/mihomo" "-d" "…state dir…"
# nixos-rebuild switch --flake /path/to/flake#hostnameよくある質問
Flakes を使わず channels だけでも同じか
同じ Nix 式の考え方は通じます。差分は入力の固定の仕方（flake.lock かチャンネルの世代）で、再現性の取り方が変わるだけです。本稿の systemd／ストア上パスの注意は channels 派にも当てはまります。
GUI クライアントを Nix 外から入れてもよいか
可能ではありますが、ライブラリの世代がホストの pkgs とズレると、起動失敗や更新のたびに手作業が増えがちです。可能な限り 同じ nixpkgs 上のパッケージに寄せる方が、immutable 系の罠に当たりにくいです。
他ディストリ向け記事の手順をそのまま使えるか
思想は共通でも、パス・パッケージマネージャ・ユニットの生成方法は置き換え必須です。例えば AUR 前提 の文は、Nix では AUR ではなく pkgs かオーバーレイで代替します。
まとめ
NixOS では Clash 系を 「1 本の Nix 式 + home-manager + systemd ユーザー」に閉じ込めるのが、ストア不変性と衝突しにくいやり方です。購読は 平文のまま VCS に載せない こと、ExecStart のパスは式で解決 すること、更新フローは flake／チャンネル方針と揃える こと、の 3 点を押さえれば、従来 Linux の How-to を読んでも戸惑いがちな「Nix 特有の抜け道」に、かなり近づけます。端末の種類をまたいで同じ体験を揃えたい場合は、各 OS の導線を ダウンロードページ で一度俯瞰してから、Nix 側の宣言に落とし込むと切り替えが楽になります。ソースや Issue は GitHub で追えますが、利用者向けの入手物の整理はダウンロードページに寄せるのが迷いにくいです。