本稿でできるようになること
作業完了後は、単一の Linux マシン上で Mihomo がデーモンとして常駐し、設定ディレクトリ内の YAML を読み込んで動作します。TUN を有効にすると、HTTP プロキシを知らないアプリや curl／git などの CLI も、OS のルーティング層で同じポリシーに乗せやすくなります。さらに rules セクションとプロキシグループを整えれば、国内サイトを直結しつつ海外サービスだけを出口に回すといった基礎的な分流の出発点に立てます。すでに OpenWrt ゲートウェイや Windows クライアントの記事を読んだ方は、設定思想の共通部分（Meta コア、ルール、DNS）をそのまま活かせます。
対象環境・権限・カーネル
想定は一般的な amd64 デスクトップ Linux（Ubuntu、Fedora、Arch 系など）およびヘッドレス VPS です。systemd が使える環境を前提にします。TUN デバイス（通常は /dev/net/tun）が利用でき、カーネルモジュールが無効化されていないことが重要です。コンテナ内だけで動かす場合は、ホスト側へのデバイス渡しや権限が別問題になるため、本稿ではネイティブインストールを主に説明します。
Mihomo のルーティング変更には CAP_NET_ADMIN に相当する権限が必要です。root で動かすのが最も単純ですが、本稿の systemd 例では非特権ユーザー＋能力（capabilities）の考え方を示します。職場・学校・プロバイダ契約ではプロキシや迂回の利用が禁じられている場合があります。適用法令とネットワーク規約を確認したうえで、許可された環境でのみ設定してください。
バイナリの配置と実行ファイル
Linux での典型的な流れは、配布アーカイブから mihomo 実行ファイルを取り出し、/usr/local/bin/ などパスの通った場所へ置く方法です。バージョンアップ時は旧バイナリの退避と設定の互換にだけ注意すれば、GUI が無い環境でも運用しやすいです。デスクトップでGUI とトレイから扱いたい場合は、同じ Meta 系クライアントを公式ダウンロードページの Linux 向けセクションから入手する方法もあります。本稿の主役はコア単体ですが、挙動の比較やログの見やすさの点で GUI と併用するのは有効です。
入手経路の整理：ソースコードの閲覧や Issue の追跡は GitHub が適しています。一方、日々のクライアント入手と更新は本サイトのダウンロード導線に寄せると、リリース資産の取り違えを防ぎやすくなります。
設定ディレクトリと config.yaml の骨格
Mihomo は起動時に -d で指定したディレクトリ（例：/etc/mihomo）を読みます。ここに config.yaml、購読から生成したプロファイル、rule-providers 用のキャッシュなどを置きます。ポート（HTTP／SOCKS／ミキサー）とモード（rule 推奨）を確認し、プロキシグループ名がルール内の参照と一致しているかを最初に揃えます。購読 URL の取り扱いは秘密情報として扱い、シェル履歴やスクリーンショットに写り込ませない運用を推奨します。
ルールセットの選び方やコミュニティプロバイダの比較は、ACL4SSR と Loyalsoldier の比較記事が参考になります。いきなり巨大なリストを足すより、自分のトラフィックに必要な分類から始めた方が、ログでの切り分けが楽です。
systemd ユニットで常駐・自動再起動
手動起動のままではセッション終了や再起動のたびに途切れるため、systemd サービスに登録します。After=network-online.target を付けると、NIC の準備後に起動しやすくなります。Restart=on-failure と短い RestartSec を組み合わせると、一時的な設定ミス以外のクラッシュからの復帰がしやすくなります。以下は説明用のスケッチです。パスとユーザー名は環境に合わせて置き換えてください。
# /etc/systemd/system/mihomo.service
[Unit]
Description=Mihomo (Clash.Meta) daemon
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=3
# Grant NET_ADMIN for TUN; adjust user/group for your site policy
User=mihomo
Group=mihomo
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
LimitNOFILE=65535
[Install]
WantedBy=multi-user.target
ユニットを有効化したら systemctl enable --now mihomo で起動し、journalctl -u mihomo -f でログを確認します。権限エラーが続く場合は、能力の不足かディレクトリの所有者を疑うと早いです。
TUN モード：ブラウザと CLI を同じテーブルに載せる
Linux では「デスクトップの手動プロキシ設定」だけではすべてのアプリが従うとは限りません。TUN を有効にすると、仮想インタフェースとルーティングルールを通じてトラフィックをコア側へ引き込みやすくなります。設定ファイルの tun セクションで enable: true、stack（system または gvisor など環境に合うもの）、auto-route や auto-detect-interface を状況に応じて指定します。詳細なキー名はリリースごとに増減するため、利用中のバージョンのドキュメントと実際の YAML スキーマを突き合わせてください。
TUN をオンにした直後に名前解決だけがおかしい場合は、DNS のハイジャックや FakeIP の設定がルールと矛盾していないかを確認します。深掘りは Meta コア DNS リーク防止ガイド に譲りますが、「TUN を使うなら DNS もセットで設計する」という意識だけは先に持っておくと安全です。
競合に注意：同じマシンで別の VPN クライアントや Docker の複雑な iptables ルールが動いていると、TUN の自動ルートと二重に干渉することがあります。まずは余計なトンネルを止めてから Mihomo だけで再現するのが切り分けの近道です。
デスクトップ環境での「見え方」を揃える
GNOME や KDE などでは、システム設定に手動プロキシの欄があります。TUN を主に使う場合でも、ブラウザ拡張が独自のプロキシを握っていると挙動が分岐します。拡張をオフにして比較したり、プライベートウィンドウで試したりしてください。CLI については HTTP_PROXY／HTTPS_PROXY 環境変数をシェルプロファイルに書く方法もありますが、TUN で一元化した方が長期的にはルール管理が楽になることが多いです。開発ツール全体の考え方は Cursor・GitHub・npm 向け分流の記事 と合わせて読むと、ドメイン単位の足し方がイメージしやすいです。
Wayland／X11 の違い自体は Mihomo のコア挙動よりもブラウザとターミナルの挙動差の方が実務では目立ちます。画面録画やセキュリティソフトがトンネルを検知して警告を出す場合は、除外設定やポリシー確認が必要になることがあります。
基礎分流：GEOIP・DOMAIN・DIRECT の組み合わせ
rules の末尾は通常 MATCH で締め、直前に GEOIP,CN,DIRECT のような国内迂回を置く構成がよく使われます。購読プロバイダがすでに類似ルールを含む場合は二重に書かないよう注意してください。特定サービスだけ遅いときは、ログに出た実ドメインを DOMAIN-SUFFIX で追記するループが確実です。ルールを増やすほど評価順序と DNSの関係が複雑になるので、変更は小さな単位で入れて都度検証するのがおすすめです。
# Example tail — replace proxy group names with yours
rules:
- GEOIP,CN,DIRECT
- MATCH,PROXY
DNS とルールの整合
分流は「名前から IP に解決されたあと」に効くため、DNS だけがクライアント外で別経路になると、ルールと実際の接続先がずれることがあります。Mihomo の dns セクションと TUN の DNS ハイジャックをどう組むかは、ネットワーク構成次第で最適解が変わります。ドキュメント・チュートリアル と併せ、まずは購読側の推奨に沿うのが無難です。細かいチューニングは DNS リーク防止ガイド の手順へ進んでください。
よくあるつまずき
サービスは動くが一切繋がらない：プロファイルが空、購読期限切れ、プロキシグループ名のタイポ、tun 無効のままルートだけ期待している、などを順に疑います。
ブラウザだけ通る／CLI だけ通らない：TUN オフ時の典型的な差です。tun.enable と権限を確認し、環境変数の古いプロキシ指定が残っていないかも見ます。
再起動のたびにルールが消える：生成物を /tmp に置いていないか、権限不足でキャッシュが書けていない可能性があります。作業ディレクトリと所有者を見直してください。
まとめ
Linux における Mihomo の実用ラインは、「バイナリと設定ディレクトリを決める → systemd で常駐 → TUN で経路を揃える → ルールと DNS を矛盾なく積み上げる」という短いパイプラインです。Windows やルーター向け記事とシーンは違っても、Meta コアの考え方は共通なので、すでに他環境で慣れている方は移行コストを大きく感じないはずです。GUI が無いぶんログとファイル編集に慣れると、かえって再現性の高い運用に寄せやすいのも Linux ならではの強みです。
同種の機能を複数ツールで重ねるより、一つのコアに設定を集約し、購読更新とルール検証を習慣化したほうが、結果として接続トラブルの切り分け時間は短くなりがちです。安定したクライアント体験を求める場合は、エコシステム全体を公式ダウンロードページから揃え、本稿のコア運用と比較検証するのも一案です。