1 なぜ Ubuntu 24.04 LTS なのか
デスクトップとサーバー双方で導入事例が多いのが Ubuntu の LTS 系列です。2026 年時点でも検索クエリは「Ubuntu 24.04」とバージョン付きで伸びやすく、ドキュメントやコミュニティ記事との突き合わせもしやすいのが利点です。ディストリビューション横断の Linux 向け Mihomo 手順が既にある場合でも、ここではパッケージセットやファイアウォール前提を 24.04 に寄せ、読者が「この版で迷わない」導線を優先しました。
Mihomo（Clash Meta 系コア）は単一バイナリで動くため、apt にネイティブパッケージが無い環境でも再現性が高いです。圧縮された公式ビルドを展開し、/usr/local/bin に置けばパス管理が単純になります。その上で宣言的な設定を /etc/mihomo に集約し、ブート後も残るプロセス監督を systemd に任せるのが、Linux プロキシで一番押さえやすい組み合わせです。
以降のサンプルは教育目的の骨格です。利用規約・所在地の法制度・プロバイダー側の制限は利用者の責務であり、購読 URL やノード記述の中身を鵜呑みにせず、事故時の影響範囲を理解したうえで運用してください。
2 事前準備：アーキテクチャとディレクトリ
まず CPU アーキテクチャを確認します。クラウドの x86_64 イメージはリリース名で amd64、Graviton や Ampere、64bit ARM ボードは arm64 に相当します。判別は uname -m で十分で、x86_64 なら amd64 資産、aarch64 なら arm64 資産を選びます。
Ubuntu 24.04 の最小クラウドイメージでも curl と gzip は概ね利用できますが、ローカル環境で欠ける場合は sudo apt update && sudo apt install -y curl ca-certificates gzip で揃えてください。企業プロキシ下では環境変数や /etc/apt/apt.conf.d/ の設定が先です。
uname -m
sudo mkdir -p /etc/mihomo/providers
sudo mkdir -p /var/log/mihomo/etc/mihomo は root のみが読めるよう、配置後に chmod 600 を忘れないでください。専用ユーザーで動かす構成に拡張する場合は、読み取り専用のグループ ACL を検討します。
3 公式アーカイブの取得、解凍、配置
Mihomo の Linux 向け配布は GitHub Releases の gzip 圧縮ファイルが定番です。バージョン番号は記事執筆後にも進むため、必ずリリースページで最新の安定版を確認し、URL を置き換えてください。以下は amd64 を想定したコマンド例です。
# Replace URL/filename with latest amd64 .gz from upstream releases
curl -fL -O 'https://github.com/MetaCubeX/Mihomo/releases/download/v1.18.0/mihomo-linux-amd64-v1.18.0.gz'
gunzip -f mihomo-linux-amd64-v1.18.0.gz
sudo install -m 0755 mihomo-linux-amd64-v1.18.0 /usr/local/bin/mihomo
/usr/local/bin/mihomo -v
install コマンドは所有者とモードを一度に決められるため、手作業の mv と chmod より明示的です。検証は必ず systemd に登録する前に行い、バイナリが壊れていないかを切り分けます。
4 最小 YAML：mixed ポートと購読インポート
Mihomo は -d で渡したディレクトリ内の config.yaml を読みます。GUI が無い環境では、最初から巨大なルール集を載せず、mixed ポートと購読取得、簡潔なセレクタだけを載せた Clash Meta 互換の骨格から始めるのが安全です。実運用では geoip やドメインルールを段階的に足していけばよいです。
購読は proxy-providers に HTTPS URL を書き、ローカルキャッシュとして ./providers/*.yaml に落とします。プロバイダーが User-Agent やリダイレクトに敏感な場合は、取得失敗がログに出るため、まず interval を長めにして負荷を下げ、必要ならヘッダを追加します。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090
secret: "replace_with_long_random"
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- 223.5.5.5
fallback:
- https://1.1.1.1/dns-query
proxy-providers:
sub:
type: http
url: "https://example.com/your-subscription-url"
interval: 3600
path: ./providers/sub.yaml
health-check:
enable: true
interval: 600
url: https://www.gstatic.com/generate_204
proxy-groups:
- name: Proxy
type: select
use:
- sub
proxies:
- DIRECT
rules:
- GEOIP,CN,DIRECT
- MATCH,Proxy
配置後に sudo chown root:root /etc/mihomo/config.yaml && sudo chmod 600 /etc/mihomo/config.yaml を実行します。allow-lan を true に広げる場合は、LAN 向けの境界を理解したうえで、後述の UFW やクラウド SG と整合させてください。external-controller はループバック縛りを推奨し、どうしてもリモート管理するなら SSH ポートフォワードか VPN 経由に寄せると露出が減ります。
5 systemd ユニットを一発登録
長時間プロセスは screen より systemd 向きです。Mihomo はフォアグラウンドで待受する実装なので Type=simple で十分です。Restart=always と RestartSec を入れておくと設定ミスでの暴走を少し抑えつつ、一時的なクラッシュから復帰しやすくなります。
sudo tee /etc/systemd/system/mihomo.service > /dev/null <<'EOF'
[Unit]
Description=Mihomo (Clash Meta) on Ubuntu
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
StandardOutput=append:/var/log/mihomo/stdout.log
StandardError=append:/var/log/mihomo/stderr.log
[Install]
WantedBy=multi-user.target
EOFUser= を下げる選択肢があります。TUN や能力が必要になる段階では公式ドキュメントの能力セットを再確認してください。
6 有効化、起動確認、ログの見方
ユニットを書き込んだらデーモンをリロードし、即時起動とブート時自動起動を有効にします。初回は journalctl を別端末で追従させ、YAML のインデントや購読取得エラーにすぐ気づけるようにします。
sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
systemctl is-active mihomo
journalctl -u mihomo -n 80 --no-pager
設定を変えたら sudo systemctl restart mihomo、メンテナンスでは stop、自動起動を止めるには disable が基本操作です。/var/log/mihomo に追記している場合はローテーションを忘れず、長期運用なら logrotate の設定を足してください。
curl -x http://127.0.0.1:7890 -I --max-time 15 https://www.example.com7 UFW を使う Ubuntu サーバーでの境界
デスクトップ版では初期状態が緩い一方、クラウドの 24.04 イメージでは UFW が有効化されていることもあります。allow-lan を true にして他端末から mixed ポートに乗る設計なら、9090 や 7890 を開ける前に本当に公開すべきかを再確認してください。管理 API はインターネットに晒さず、SSH トンネルで届ける方が安全なケースが多いです。
典型的には sudo ufw status numbered で現状を把握し、必要最小限のルールだけを追加します。クラウドベンダーのセキュリティグループと二重管理になるため、どちらが実際の境界かをチーム内で共有しておくと障害時に早いです。
8 ターミナルと apt のプロキシ例
Mihomo はデスクトップ全体のプロキシを勝手には書き換えません。シェルで試すなら環境変数が手早いです。CI や一時シェルなら export、常時利用なら ~/.bashrc か systemd user ユニットに分離します。
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export no_proxy="localhost,127.0.0.1,::1"
apt 全体をプロキシ経由にする場合は /etc/apt/apt.conf.d/95proxies に Acquire::http::Proxy などを書く方法があります。社内ルールで禁止されていないか、変更管理とセットで確認してください。
9 よくある詰まりと切り分け
- すぐ exiting する： journal の直近数十行を確認。購読 URL が 403 のときは UA やクッキー要求が原因のことがあります。
- ポート競合：
sudo ss -lntpで 7890 や 9090 の占有プロセスを特定し、片方の設定を変えます。 - DNS が循環参照： systemd-resolved と競合しやすいので、まずは Mihomo の DNS を 127.0.0.1 に縛り、ホスト側の仮想化環境ではゲストだけ 1053 を使う形にします。
- providers が更新されない： ディスク容量と
/etc/mihomo/providersの書き込み権、さらにintervalの待ち時間を疑います。
10 FAQ
Ubuntu 24.04 だけ切り出す意味は？
バージョン付き検索とドキュメント整合がしやすく、UFW やクラウドイメージの前提を文章冒頭で固定できます。中身のコア手順は他ディストリでも流用できますが、読者体験として「この LTS で」の明示が違います。
snap 版や PPA は使わないの？
再現性と取得経路の単純さを優先し、公式バイナリ直置きを基準にしました。組織ポリシーでパッージングが必須なら、社内テンプレに合わせた派生手順を足してください。
11 まとめ
Ubuntu 24.04 LTS では、Mihomo を gzip 版から配置し、最小 YAML で mixed ポートと購読取得を回し、systemd に再起動とブート時起動を任せる流れが短く構築できます。Clash Meta 互換の宣言的設定は後からルールやプロバイダを足しやすく、サーバーとワークステーションの両方で同じ方言を保てる利点があります。
一方、ヘッドレス構成はルール編集や購読の差し替えがターミナル頼みになりがちで、ダッシュボードを直接晒すと攻撃面も増えます。汎用スクリプトだけだとクライアント側の体験を均一化しづらく、更新タイミングもバラけがちです。
その点、メンテの行き届いた GUI クライアントなら購読インポートやルール調整が視覚的に済み、Windows や macOS と同じ感覚で運用を揃えやすいです。とはいえサーバーでは systemd 常驻＋YAML が依然として堅実なので、作業端末と役割分担できれば一番ラクになります。デスクトップ側を試すなら 公式のダウンロードページ からビルドを選ぶと、本文で触れた Mihomo コアの長所を GUI で活かしやすくなります。
