Arch Linux に Clash Meta（mihomo）を導入：systemd 自起動と mixed-port 初手順（2026）

1. 既存の Ubuntu・Fedora 向け手順との棲み分け

本サイトの Ubuntu に Clash Meta を deb／apt で導入する解説は、パッケージ名と systemd の導線が dpkg 前提で揃っています。Fedora 向けの稿は dnf や静的バイナリ、SELinux との相性を扱います。一方 Arch 系では、公式リポジトリに「そのままの名前の安定版」が常にあるとは限らず、AUR 上の *-bin 系 PKGBUILD や、自分でバイナリを置く構成が主戦場です。挙動の芯は同じ mihomo ですが、ファイルの置き場と systemd ユーザ／システムの使い分けが、Ubuntu や RHEL 系の読者には最初だけ違和感を与えます。

以降の例ではバイナリ名を clash-meta として扱います。AUR パッケージによっては mihomo というまま /usr/bin へ入ることも多いため、実際のパスは導入方法ごとに必ず command -v や pacman クエリで確かめてください。ローリングのため glibc や iptables 周辺の挙動が週次で前後することも忘れない方が、トラブル時の当たりが付きやすくなります。

2. AUR / yay 経路と手動配置の比較

yay や paru といった AUR ヘルパーが入っているなら、代表例として mihomo や clash-meta 系の、ビルド不要な *-bin 系パッケージを候補にできます。毎日のように中身のハッシュは変わり得るため、PKGBUILD のメンテと upstream の GPG 方針を読んでから導入する習慣を付けてください。AUR のメタ情報は信頼の置けるメンテナーか、更新頻度とコメント欄の健全さで一次判断するのが現実的です。

# Example: review PKGBUILD on AUR before installing
yay -S mihomo-bin
# or: paru -S ...

手動配布物を /usr/local/bin に展開する場合は、アーキテクチャ（x86_64／aarch64 など）を uname -m で確認し、圧縮解凍後の最終パスを一本化してから exec bit を付与します。日常の受け口としては、まず ダウンロードページ から各環境向けの入手導線を把握し、必要に応じてリリースノートを追う、という二段階にすると、バージョン表記のブレに手順全体が巻き込まれにくくなります。ソースの参照やバグ追跡は、別途 GitHub などの公開情報に任せ、本ページが案内する「配布物の主たる導線」は本站に寄せるのが読み手にも運用者にも扱いやすい形です。

3. mixed-port を軸にした初回 config

mixed-port は、1 つの待受先番号に HTTP プロキシと SOCKS をまとめて受けられる設定です。ブラウザ手動、シェル環境変数、IDE の「システムと同じ」欄に 同じ数字を与えやすいのが利点で、Linux デスクトップの初回導入に向いています。例として 7890 を取り、既に ss -lntp や lsof -i :7890 で空いているか確認してから採用してください。

下記は 学習用の最小スケルトンです。実戦では proxi-providers や既存の購読に差し替え、サブスクリプション導入ガイドの流れに沿ってノード定義を置き換えます。ルールの評価順序は ルールルーティング解説 も併せて読むと、後から mihomo 拡張を足しても破綻しにくいです。

# Minimal example — replace proxies with your real nodes
mixed-port: 7890
bind-address: '127.0.0.1'
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: "change-me"

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1

proxies:
  - name: placeholder
    type: ss
    server: 127.0.0.1
    port: 1
    cipher: dummy
    password: dummy

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - placeholder

rules:
  - MATCH,PROXY

external-controller を有効化する以上、secret の空文字回避は必須レベルです。LAN 外へ API を露呈させる場合は、 allow-lan とファイアウォール まわりの専用稿と併せて、受け口の最小化を設計してください。Arch では nftables や ufw 相当の枠を自前で持っている人も多いため、外向き 9090 開放は誤作動と侵害リスクの両方で扱いが重くなります。

4. 購読（サブスクリプション）取り込みの考え方

多くの利用者は proxy-providers に HTTPS 購読 URL を書き、path へキャッシュを持たせます。Arch のホーム配下に置くとバックアップと相性が良く、/etc 系に集約すると 専用 UNIX ユーザで動かす systemd と相性が良いです。更新が詰まる例は 購読と TLS ログ や rule-providers の稿 を参照し、DNS 再帰とTLS 握手中の自参照を切り分けます。ローカル mixed-port へ自分自身が誤って乗ると、更新もブラウザも同時に不調という古典的なループに入りがちなので、ルール上段に購読ドメインを直結させる、といった作り方が有効です。

5. systemd ユーザユニットで常駐する

一般ユーザ権限のまま常駐させるなら ユーザユニットが扱いやすいです。設定は例として ~/.config/mihomo/config.yaml に置き、ユニットは ~/.config/systemd/user/clash-meta.service にします。実際の ExecStart はパス差し替え必須です。

[Unit]
Description=Clash Meta (mihomo) for user session
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
WorkingDirectory=%h/.config/mihomo
ExecStart=/usr/bin/clash-meta -d %h/.config/mihomo
Restart=on-failure
RestartSec=3
LimitNOFILE=65535

[Install]
WantedBy=default.target

有効化はユーザセッションで systemctl --user daemon-reload ののち systemctl --user enable --now clash-meta.service です。GUI セッションに入る前に立ち上げたい場面は loginctl enable-linger <username> の検討余地があります。Arch Wiki の systemd ユーザ節を読み、自分の使用形態に linger が要るかを判断してください。 linger は常駐デーモンを常時許可するため、端末紛失時の影響も含め、メリットとトレードオフの両方を知ったうえで使います。

6. システム横断で動かす場合のユニット

専用システムユーザ（例: clash）を作り、設定を /etc/clash-meta に置く流れは Fedora 向け解説の形と揃えやすいです。Arch 公式パッケージのパスではなく、AUR 由来の /usr/bin/clash-meta か手動 /usr/local/bin かを一か所に決め切るのが、後述の journalctl -u を素直にするコツです。

sudo mkdir -p /etc/clash-meta
sudo chown -R clash:clash /etc/clash-meta
# place config.yaml, then
sudo systemctl enable --now clash-meta.service

/etc 集約の利点は、複数人端末や 同機にログインする別ユーザへ同じ常駐を与えたいケースに効きます。逆に専用ノート PC 一人利用なら、~/.config 中心のユーザユニットの方が更新やバックアップのメンタルモデルと合いがちです。

7. journalctl・ログで落ち着かせる手順

システムユニットは journalctl -u clash-meta.service -b -f、ユーザユニットは journalctl --user -u clash-meta.service -b -f といった形で追えます。Arch は /var/log 併用型の導入も可能ですが、systemd 一本で観測しておくと、boot 区間とサービス再試行の相関を取りやすいです。起動直後の DNS 名・証明書エラーは多くの場合、log-level: debug を一時的に上げると mihomo 固有の行が増え、原因に辿れます。落ち着いたら戻し、高頻度リスタート + info 全開でディスクを埋めない注意もセットです。

8. デスクトップ環境のプロキシに繋げる

KDE Plasma や GNOME では、設定 UI の 手動プロキシに 127.0.0.1:7890 形式で mixed-port を突き合わせます。シェルだけ通したい場合は ~/.bashrc 等へ export http_proxy=http://127.0.0.1:7890 を記載。Wayland セッションでも大枠は同様ですが、サンドボックス化された AppImage や Flatpak は内部プロキシ設定を別持ちにすることがあり、切り分けでは「ブラウザ／ターミナル／IDE」を順に試すのが定石です。GUI 系クライアントの選び方は 移行・代替ガイド とも参照できます。コア常駐は systemd、日々の切替はフロントエンド、という分業も有効です。

9. Manjaro 利用時の心構え

Manjaro は同じ pacman 族ですが、ミラー遅延と安定ブランチの都合で純粋な Arch より一歩遅い更新になることがあります。AUR から入れた mihomo が期待する glibc バージョンに届いていない、という不整合は、ローリング全般のトラブルとして覚えておくと、journal の version GLIBC_* not found 的な行に心当たりが付きます。解決策は 公式ミラー追従の遅延を意識して pacman 更新するか、一時的に手動バイナリを合わせる、の二択に収束しがちです。

10. よくある躓き

ポート奪合い：残プロセスの掃除。 権限：作業ディレクトリの所有者と UNIX ユーザの食い違い。 DNS だけ不調：systemd-resolved と mihomo の DNS 節、ブラウザの DoH 設定を切り分け。 TUN へ拡げたい： TUN 解説 へ進む前に、まず ループバック mixed-port 単体で挙動を固めると、カーネルモジュールや権能の話題に集中できます。

11. まとめ

Arch 系は AUR や手展開でコアの実体を自ら選ぶ手間の代わりに、rolling であるがゆえの鮮度を活かしやすい土地柄です。初回の足場を mixed-port に寄せ、systemd ユーザかシステムのどちらの物語にするかを先に決めておくと、購読・ルール拡張・TUN への拡大も一本の線で辿れます。Ubuntu や Fedora の同テーマ解説を横断で読めば、外側のパッケージ形式の差の奥で同じ mihomo 設定言語が続いていることも把握しやすくなります。安定導線と図入り手順のある配布体は、再現時の心の支えになるでしょう。

まず手元のアーキテクチャに合うビルドを選び、ループバックで疎通し、次に常駐とログ、最後にデスクトップ連携、という段取りを踏むのが最も衝突が少ないです。GUI 同梱の他 OS 向けバイナリも → 無料で Clash をダウンロードし、快適な接続体験を試す から辿ると、家族や別端末向けの補足説明もしやすくなります。