この記事のゴールと前提
Ubuntu（22.04 LTS や 24.04 LTS など）のデスクトップやヘッドレスサーバーで、Clash Meta コア（多くの配布物では実行ファイル名が mihomo）を導入し、systemd でブート後に自動起動させる。必要に応じて TUN を有効にしてカーネルレベルでトラフィックをルール下へ載せ、併せて HTTP プロキシとシェルの環境変数を揃えて CLI からの更新作業も滑らかにする——という実務向けの流れを、段階に分けて整理します。
GUI クライアントに比べると設定ファイルと権限の話が前面に出ますが、一度パスを決めてしまえば再現性が高く、リモート環境や軽量 VM でも同じ型を使い回せます。コアの機能差分やバージョン管理の考え方は、当サイトのMihomo アップグレード解説とあわせて読むと、設定キーの変遷を追いやすくなります。
本稿は技術的なセットアップ手順の共有であり、利用するネットワークポリシー・契約・法令はご自身の環境で必ず確認してください。共有サーバーや職場端末では管理者権限とセキュリティ方針に従ってください。
ステップ0：OS 側の下準備
まず uname -r でカーネルが想定どおりか、ip route でデフォルトゲートウェイが通常どおりかを軽く確認します。TUN を使う場合は /dev/net/tun の存在や、モジュールが読み込まれていること（多くの環境では最初から利用可能）を見ておくと後工程が速いです。
以降の例では、設定と GeoIP などの作業用ディレクトリを /etc/mihomo（管理者運用）またはホーム直下の ~/.config/mihomo（ユーザー運用）のどちらかに固定し、バイナリは /usr/local/bin/mihomo に置く想定で書きます。実際のパスは組織の標準に合わせて置き換えてください。
ステップ1：バイナリの配置と実行権限
公式リリースや配布アーカイブから、自分のアーキテクチャ（例：linux-amd64）に合った実行ファイルを取得し、上書き更新しやすい場所へ配置します。chmod +x を付与し、sha256sum などで取得物の整合性を確認する習慣があると、自動更新スクリプトを回すときに安心です。
クライアントの入手先としては、当サイトのダウンロードページを第一の導線にし、バージョン表記と実行ファイル名を手元の systemd ユニットと一致させてください。ソースコードや Issue の参照は、仕様確認用にMihomo の GitHubを別枠で使い分けると、読者が「どこからインストールすればよいか」を取り違えにくくなります。
ステップ2：設定ファイルの最小スケルトン
作業ディレクトリに config.yaml を置き、少なくとも ポート（mixed-port または port）、ログレベル、DNS、プロキシ定義、プロキシグループ、ルールが矛盾なく繋がっている必要があります。最初の一回は「手元の購読 URL を proxy-providers に載せる」「フォールバック用の proxy-groups を一つ用意する」「最後に MATCH を置く」程度に絞り、起動ログでエラーを潰す方が早いです。
DNS と Fake-IP、ルール順の相互作用で「接続は出ているのにページが開かない」症状が出やすいので、切り分けの型はログと DNS の記事も参照してください。TUN をオンにする前に、まずはローカル HTTP／mixed ポート経由でブラウザや curl が期待どおりに動く状態を作ると、障害の層が分かれて楽になります。
ステップ3：手動起動で一次確認
systemd に入れる前に、フォアグラウンドで起動してログを目視します。
# Example: adjust -d to your config directory
sudo /usr/local/bin/mihomo -d /etc/mihomo別ターミナルから ss -lntp | grep mihomo などで待受ポートを確認し、mixed-port に合わせて curl -x http://127.0.0.1:PORT https://example.com -I のように疎通を見ます。ここで失敗する場合は設定ファイルの文法、プロバイダの到達性、ルールの誤マッチを先に直し、デーモン化は後回しにしてください。
ステップ4：systemd ユニットで自動起動
手動起動が安定したら、/etc/systemd/system/mihomo.service のようなユニットを作成します。ポイントは次のとおりです。（1） User= と WorkingDirectory= を、設定ディレクトリの所有者と一致させる。（2） ExecStart にバイナリの絶対パスと -d を明示する。（3） 失敗時の再起動方針（Restart=on-failure など）を決める。（4） TUN を使うなら、後述のとおり 権限（capabilities） か 所有者を root に寄せる判断を先に決める。
一般ユーザーで TUN を操作する場合、ユニットに AmbientCapabilities=CAP_NET_ADMIN などを付与する例がよく使われます。組織ポリシーで capabilities が禁止されている場合は、root での実行や別の分離手段（コンテナ／専用ネームスペース）を検討する必要があります。次はそのまま使える形の雛形です（パスとユーザー名は環境に合わせて差し替えてください）。
# /etc/systemd/system/mihomo.service — replace User and paths
[Unit]
Description=Mihomo (Clash Meta)
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=mihomo
Group=mihomo
WorkingDirectory=/etc/mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=3
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
NoNewPrivileges=yes
[Install]
WantedBy=multi-user.target作成後は sudo systemctl daemon-reload、sudo systemctl enable --now mihomo.service、systemctl status mihomo の順で確認します。ログは journalctl -u mihomo -f が便利です。設定を更新したあとに反映だけ行いたい場合は、クライアントの API や再起動ポリシーに合わせて systemctl restart mihomo を運用に組み込みます。
ステップ5：TUN を段階的に有効化する
TUN は「システムプロキシを見ないアプリケーション」や「DNS の取りこぼし」を減らすのに有効ですが、ルートテーブルや DNS の扱いが変わるため、いきなり本番で全面 ONにせず、次の順が安全です。（1）まず設定ファイル内で tun.enable を false のまま mixed ポートだけで日常運用。（2）検証環境で true にし、スタック（system／gvisor など）をドキュメントの推奨に合わせて試す。（3）問題なければ本番へ展開。
スタック選択や「自動ルート」「厳密な除外ルート」まわりの考え方は、プラットフォーム横断の整理としてTUN モード解説に譲ります。Linux 特有の論点としては、他製品の仮想インタフェースや Docker のブリッジ、社内 VPN クライアントとルートが競合しないかを必ず確認してください。競合時はクラッシュではなく「一部ホストだけ遅い／届かない」となり、ログと ip rule の両方を見る必要が出ます。
ステップ6：HTTP プロキシと環境変数の揃え込み
TUN でほぼ全体を覆う構成でも、コンテナ内や特定のサービスアカウントでは依然として http_proxy が必要になることがあります。mixed-port が 7890 なら、シェルでは次のように大文字・小文字の両方を揃えるとトラブルが減ります（ポートは手元の値に合わせてください）。
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"デスクトップでは GNOME のネットワークプロキシ設定とシェル変数が二重管理になりがちです。どちらを正とするか決め、NO_PROXY に社内ドメインや localhost を列挙するルールも合わせて見直すと、ブラウザは通るのに apt だけ失敗、といったズレを防げます。シェル初期化ファイルの読み込み順による「設定したはずなのに空」問題は、macOS 向けにまとめたターミナルと環境変数の記事と同型の思考で切り分けできます。
よくあるつまずき
起動直後に終了する場合は、設定ファイルの YAML インデントミス、プロバイダ URL の到達不可、ファイル権限（秘密鍵や購読キャッシュの読み取り）を疑います。ポートが開かない場合は mixed-port と実際の ExecStart が参照するディレクトリが一致しているか、SELinux／AppArmor 的な制限が無いかを確認します。
TUN オン後に全通信が不通になりやすいのは、DNS がループしたり、ローカルサブネットへの例外ルートが不足しているケースです。まず TUN をオフに戻して回線を復旧し、ルールと DNS をドキュメントの推奨に沿って再配置すると安全です。
まとめ
Ubuntu で Clash Meta を「たまに手動起動」から「再起動後も同じ状態に戻るサービス」へ昇格させるには、パスとユーザー権限を固定し、手動起動でログを確認してから systemd に載せる順序が重要です。TUN は便利ですがルートと DNS に触れるため、段階的に有効化し、競合する VPN やコンテナネットワークと先にすり合わせてください。
GUI 製品に慣れた方にとってはファイル運用の負担が増えますが、その分バージョン管理や自動更新、複数マシンへの展開がしやすく、インフラ寄りのワークフローと相性がよいのが Linux 版コアの強みです。Windows や macOS で使っていたルールセットも、ディレクトリとポートさえ揃えれば同じ考え方で移植できます。
同種のツールのなかでも、Mihomo 系はルール表現とプロバイダ周りの拡張が豊富で、ログから挙動を追いやすい点が実務では助かります。手元の構成が固まったら、クライアントを最新に保ちつつ、購読とルールの更新ポリシーを決めておくと長期運用が楽になります。