Fedora に Clash Meta（mihomo）を導入：systemd での起動登録と mixed-port を軸にした初回構成（2026）

1. Ubuntu 稿との違いと Fedora 側の前提

当サイトの Ubuntu に Clash Meta を deb で載せる記事は、dpkg と apt の流れに最適化されています。一方 Fedora では RPM パッケージとして公式に揃っているとは限らないため、多くの人が 上流リリースの静的バイナリを /usr/local/bin などへ展開するか、信頼できる第三者の COPR を自分で評価して使う、という二極になります。本稿は前者の「静的バイナリ＋自前ユニット」を基準に書きます。第三者リポジトリを使う場合は更新鍵とメンテ状況を必ず確認してください。

また Fedora は SELinux が enforcing であることが多く、将来 TUN や透明プロキシ寄りの構成に広げるときに ラベルとポートの組み合わせがボトルネックになることがあります。最初の一歩としては ループバック上の mixed-port だけを立てる構成にしておくと、カーネル側の要件を段階的に足せます。

購読 URL の扱いやプロファイルの考え方は、サブスクリプション導入ガイドと共通です。ルールの評価順は ルールルーティング解説を併読すると、mihomo 特有の挙動も追いやすくなります。

2. 依存パッケージとバイナリの配置

まず展開と転送に必要な最低限を dnf で入れます。例は Workstation 想定です。

# Install common tools on Fedora
sudo dnf install -y curl tar gzip

バイナリ本体は、利用するリリースのアーキテクチャ（amd64 か aarch64 か）に合わせて取得します。ファイル名はリリースごとに変わるため、ここではプレースホルダにしています。日々のクライアント入手の第一候補は ダウンロードページに寄せ、そこから Linux 向けビルドやドキュメントへ辿る運用が説明も追いやすいです。ソースや Issue を確認したいときだけ GitHub を別タブで開く、という住み分けにすると、リリース資産のリネームに手順全体が引きずられにくくなります。

# Example layout: adjust archive name and path
sudo tar -C /usr/local/bin -xzf ./mihomo-linux-amd64-v*.gz
sudo mv /usr/local/bin/mihomo /usr/local/bin/clash-meta
sudo chmod 755 /usr/local/bin/clash-meta

実際の圧縮形式やトップレベルディレクトリの有無はビルドによって異なります。tar tf で中身を覗いてから mv するのが安全です。ARM 機ではファイル名のサフィックスが変わるので、CPU アーキテクチャを uname -m で確認してからダウンロードしてください。

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

mixed-port は、単一の TCP ポートで HTTP プロキシと SOCKS をまとめて待ち受けるための設定です。ブラウザの手動プロキシ、シェルの http_proxy／https_proxy、一部アプリの「システムと同じ」設定を、同じ番号に揃えやすいのが利点です。初回はポート競合を避けるため、例では 7890 に固定します。すでに別の VPN や開発ツールが同番号を掴んでいないか、ss -lntp で確認してから決めてください。

以下は動作確認用のミニマム例です。実運用ではプロバイダから配られる購読を proxy-providers や proxies に差し替え、ルールセットを足してください。ダミーのノード名は読み替えが必要です。

# Minimal skeleton — replace proxies and rules with your profile
mixed-port: 7890
bind-address: '*'
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: ""

dns:
  enable: true
  listen: 0.0.0.0:1053
  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 を空にしないのが鉄則です。上記は説明用に空文字を置いているだけなので、実機ではランダムな文字列を設定し、API へはループバックからだけ届くようにしてください。bind-address を広げると LAN 共有の布石になりますが、allow-lan まわりの整理とセットで設計しないと、意図せず外向きのプロキシが露出します。

4. 設定ディレクトリと専用ユーザー

systemd で非対話ユーザとして動かすなら、ホームを設定ディレクトリにした専用ユーザーを作る方法が扱いやすいです。以降 /etc/clash-meta を例にします。

sudo mkdir -p /etc/clash-meta
sudo cp /path/to/your/config.yaml /etc/clash-meta/config.yaml
sudo useradd --system --home /etc/clash-meta --shell /usr/sbin/nologin clash 2>/dev/null || true
sudo chown -R clash:clash /etc/clash-meta

GeoIP や rule-providers のキャッシュがディレクトリ内に伸びる構成では、ディスククォータとローテーションも視野に入れてください。更新失敗の切り分けは rule-providers／GEOIP 更新の記事と補完関係にあります。

5. 手動起動での疎通確認

ユニット化の前に、サービスと同じユーザー・同じ -d でフォアグラウンドまたは短時間のバックグラウンド起動を試し、ログに致命的エラーがないことを確認します。

sudo -u clash -H /usr/local/bin/clash-meta -d /etc/clash-meta

別シェルから curl -x http://127.0.0.1:7890 https://example.com -I のように叩き、期待する経路に出ているかを見ます。ここで失敗しているのに systemd だけ整えても、同じ失敗がループするだけです。購読 URL が拒否されている、証明書ストアが古い、など OS 周辺の問題もこの段階で切り分けます。

6. systemd ユニット例と enable

/etc/systemd/system/clash-meta.service を作成します。パスは環境に合わせて必ず置き換えてください。

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

[Service]
Type=simple
User=clash
Group=clash
WorkingDirectory=/etc/clash-meta
ExecStart=/usr/local/bin/clash-meta -d /etc/clash-meta
Restart=on-failure
RestartSec=3
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

読み込みと有効化は次のとおりです。

sudo systemctl daemon-reload
sudo systemctl enable --now clash-meta.service
sudo systemctl status clash-meta.service

enable --now はブート時自動起動と即時起動を一度に行います。ノート PC ではサスペンド復帰後だけ挙動が変わることがあるため、その場合は NetworkManager の再接続フックや、手動の systemctl restart clash-meta.service を運用に織り込む余地もあります。

7. journalctl と失敗時の止め方

ログは journal に集約されるため、journalctl -u clash-meta.service が第一の観測口になります。ブート単位で切り出すなら -b、追従なら -f を付けます。

journalctl -u clash-meta.service -b --no-pager
journalctl -u clash-meta.service -f

設定ミスで高速に落ちるループに入ったら、sudo systemctl stop clash-meta.service で一旦止め、文法とポートを直してから再開します。Restart=always は便利ですが、障害が長引くとログが埋め尽くされるので、初期検証では on-failure の方が安全です。

8. SELinux・firewalld・ローカル待受の整理

127.0.0.1 のみで mixed-port をListenする構成であれば、外向きの firewalld 穴あけは通常不要です。逆に bind-address を LAN 側に広げたり、別マシンから管理 API を触りたい場合は、ゾーンと rich ruleを明示的に設計する必要があります。

SELinux が enforcing のとき、将来 TUN デバイスやカスタムパスへバイナリを置くと 実行コンテキストで止まることがあります。典型対処は restorecon やモジュール生成ですが、ポリシー変更は影響範囲が広いので、まずはループバック mixed-port の範囲で安定運用を確認してから広げるのが現実的です。

TUN やゲームクライアントまで一括で掴みたい場合の枠組みは TUN モード解説を参照しつつ、Fedora カーネルと競合しがちな他製品 VPN の有無を先に洗い出してください。

9. GNOME／KDE などデスクトップ代理の足場

コアが systemd で立っていても、アプリがプロキシを知らなければトラフィックは流れません。GNOME では設定アプリのネットワーク／プロキシから 127.0.0.1 と mixed-port で指定した番号を手動プロキシに入力するのが素直です。シェルだけ通したい場合は export http_proxy=http://127.0.0.1:7890 のように環境変数をプロファイルへ追記します。

Flatpak や Snap 封じのアプリは、サンドボックス側のネットワーク設定が別レイヤになる点に注意してください。Wayland セッションでもプロキシ設定そのものは多くの場合に有効ですが、挙動がアプリごとに分かれるため、切り分けでは「ブラウザのみ」「ターミナルのみ」と順に試すと早いです。

GUI クライアントを併用したい場合の選び方は CFW 代替・移行ガイドとも読み替え可能です。コアは systemd、操作は GUI、という二段構えもよくある構成です。

10. よくあるつまずき

ポート競合：以前の手動起動や別プロキシが残っていないか ss -lntp で確認します。権限エラー：namei -l /etc/clash-meta で所有者を追い、サービスユーザーに書き込みが必要なパスを揃えます。DNS だけおかしい：設定の DNS セクションと、systemd-resolved や NetworkManager が握っているリゾルバの関係を整理します。

dnf update 後にだけ壊れる：カーネルや libc の更新でセキュリティポリシーが変わった可能性があります。journal の AVC ログを確認し、必要なら一時的に permissive で再現するなど、影響範囲を限定した検証を行ってください。

11. まとめ

Fedora では deb 一本ではない導線のぶん、最初に バイナリの実体と作業ディレクトリ、systemd のユニットを自分で揃える必要があります。その代わり、mixed-port を中心に据えたローカル代理から始めれば、ブラウザ・シェル・デスクトップ設定を同じ番号に寄せやすく、後から TUN や LAN 共有へ広げるときの軸もブレにくいです。

Ubuntu 向け手順と対照しながら読むと、パッケージマネージャの差の外側では同じ mihomo の設定言語が続いていることが把握しやすくなります。安定した入手導線とドキュメントがあると、試行錯誤のストレスも小さくなります。

まずは自分のアーキテクチャに合ったビルドを選び、購読を取り込んだうえで mixed-port とログを確認するのが確実です。Windows や macOS 向けの GUI ビルドも含め、 → 無料で Clash をダウンロードし、快適な接続体験を試す から環境にあったクライアントを選べます。