この記事のゴールと前提
Fedora Workstation（41／42 系など、ローリングに近い更新サイクル）でClash Meta コア（実行体が mihomo である配布が一般的）を常駐させ、systemd でログイン後またはブート直後に自動起動し、必要なら TUN でカーネルレベルの転送経路へトラフィックを載せる——という流れを、Ubuntu 手順との差分がわかるように書きます。パッケージ管理は dnf が中心で、デスクトップでは SELinux が enforcing のまま運用されることが多い点が典型です。
すでに当サイトでは Debian 系を想定したUbuntu＋systemd＋TUN の記事を公開しています。本稿はその「型」を借りつつ、Fedora 側で追加で踏むべき確認（ワークグループとツールチェーン、コンテキストラベル、firewalld との距離感）を厚めにします。コアのバージョン運用やキー変更の追い方はMihomo アップグレード解説と併読すると安全です。
本稿は技術セットアップの共有であり、利用するネットワーク方針・契約・法令はご自身の環境で必ず確認してください。職場端末では情報システム部門の許可とセキュリティ基準に従ってください。
ステップ0：dnf で土台を確認する
Fedora ではユーザー空間のツール群が比較的新しく、ip や nft 系がデフォルトで揃っていることが多いです。とはいえ、ヘッドレス構成や最小インストールでは不足が出るため、次を軽く確認します。（1） uname -r でカーネル世代。（2） ip route でデフォルト経路。（3） TUN を使う予定なら ls -l /dev/net/tun でデバイスノードの存在。ここでノード自体が無い場合は、仮想化レイヤやコンテナ内実行の制約を疑う方が早いです。
任意ではありますが、ログ調査で SELinux を触るなら policycoreutils-python-utils や setroubleshoot-server を入れておくと、拒否ログの読み下しが楽になります。コア本体は多くの場合配布アーカイブから直接配置する運用になるため、dnf install mihomo のような「公式リポジトリ一本」の前提にはしません。代わりに、後述のパスに対して restorecon が通るかを見る、というのが Fedora 流の sanity check になります。
ステップ1：SELinux と配置パスを先に決める
Ubuntu で問題になりにくい 実行ファイルのラベル不一致が、Fedora では起動失敗や「動くが一部機能だけ拒否」の原因になります。バイナリを /usr/local/bin/mihomo に置く構成が扱いやすい典型です。配置後に次のように再ラベルすると、テスト環境ではこれだけで通ることが多いです。
# Run as root; adjust path if you use a different install location
sudo restorecon -Rv /usr/local/bin/mihomoそれでも拒否が出る場合は journalctl -xe と ausearch -m avc -ts recent をセットで見ます。恒久対応はポリシー改変になり得るため、組織端末では自己判断での緩和禁止が普通です。設定ディレクトリを /etc/mihomo に置くなら、その配下のファイル所有者をサービスユーザーに揃え、秘密情報を含む YAML のパーミッションを絞る、という基本は他ディストリと同じです。
ホーム直下に展開する場合でも、systemd の ReadWritePaths や SELinux のユーザホーム向けルールが絡みます。迷う場合は専用ユーザー＋/etc/mihomoに寄せると、説明と再現性の両方が楽になります。
ステップ2：バイナリと設定ディレクトリ
アーキテクチャに合ったリリース物を取得し、sha256sum などで改竄検知できる状態にしてから配置します。クライアント／コアの入手導線は、当サイトのダウンロードページを第一候補にし、実行ファイル名を systemd の ExecStart と一致させてください。ソースや Issue の参照はMihomo の GitHubを別用途として切り離すと、読者が取り違えにくくなります。
config.yaml では、少なくともポート、DNS、プロキシ定義、グループ、ルールが矛盾なく繋がっている必要があります。TUN を有効にする前に、mixed ポートだけでブラウザ疎通を確認するのが安全です。DNS 周りの切り分けはログと DNS の記事、TUN の一般論はTUN モード解説に譲ります。
ステップ3：手動起動で一次確認（TUN はまだオフ）
systemd 化の前に、フォアグラウンドでログを目視します。TUN はこの段階では false のままにしておき、ルールとプロバイダ取得が安定していることを先に確定させます。
# Example: run as the same user you will use in the unit file
sudo -u mihomo /usr/local/bin/mihomo -d /etc/mihomo別ターミナルから ss -lntp で待受を確認し、curl -x http://127.0.0.1:PORT https://example.com -I のように疎通を見ます。ここで失敗する場合は、YAML 文法、到達不能な購読 URL、証明書ストア、プロキシチェーンの誤りを先に潰してください。TUN を先に有効化してから原因探しを始めると、切り分けが一気に難しくなります。
ステップ4：systemd ユニットで自動起動
手動起動が安定したら /etc/systemd/system/mihomo.service を作成します。Fedora でも基本形は Ubuntu と同型ですが、ネットワーク待ち合わせは network-online.target を使う例が多く、VPN や Wi‑Fi 認証と競合する環境では起動順の調整が必要になることがあります。TUN を一般ユーザーで操作する場合、AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE を付けるパターンが実用的です。
# /etc/systemd/system/mihomo.service — replace User and paths
[Unit]
Description=Mihomo (Clash Meta) for Fedora
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 -b --no-pager を見て、SELinux の拒否が混ざっていないかを確認します。設定更新後の反映は運用ポリシーに合わせて systemctl restart mihomo か API リロードを選びます。
ステップ5：TUN を有効化する順序と Linux 権限
TUN は「システムプロキシを参照しないアプリ」や「DNS の取りこぼし」を減らす一方、ルーティングと名前解決に深く入り込みます。推奨順序は次のとおりです。（1） mixed ポートのみで日常運用が安定していることを確認。（2） 検証プロファイルで tun.enable: true にし、スタック（system や gvisor など）をドキュメント推奨に合わせて試す。（3） 社内 VPN や別の仮想インタフェースとルートが競合しないかを ip rule とログの両方で確認してから本番適用。
Linux TUN 権限の典型エラーは「デバイスを開けない」「interface create に失敗」といったログに現れます。capabilities を付けてもダメな場合は、単純にルート特権で動かす構成へ寄せる判断もありますが、その場合は管理 API のバインド先やファイル権限をより厳しく絞ってください。コンテナや Flatpak では /dev/net/tun の渡し方自体が別問題になるため、本稿の systemd 直起動とは切り分けて考えます。
firewalld が有効なワークステーションでは、TUN インタフェースがゾーンにどう見えるかが環境依存です。症状が「一部ドメインだけ不通」に偏るときは、まず TUN をオフに戻して回線を復旧し、ルールと DNS をドキュメントの推奨に沿って組み直す方が安全です。
ステップ6：GNOME とシェル環境変数の整合
Fedora Workstation では GNOME の「ネットワークプロキシ」とシェルの http_proxy が二重管理になりがちです。TUN でほぼ全体を覆う場合でも、コンテナツールチェーンや dnf 自体の挙動を切り分けるには、シェル側に明示的なプロキシ変数を残しておくと楽なことがあります。
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"ポート番号は手元の mixed-port に合わせて置き換えてください。NO_PROXY に社内ドメインや localhost を列挙しておくと、ブラウザは通るのに CLI だけ失敗、というズレを減らせます。
よくあるつまずき（Fedora 寄り）
サービスは active だが通信が片側だけ落ちる場合、ルールより先に SELinux の拒否や firewalld のゾーンを疑います。更新直後だけ失敗する場合はカーネルとユーザ空間のバージョン差が疑わしいので、コアを最新方針に揃えたうえで再現手順を残してください。
TUN オン後に全不通へ落ちる典型は、DNS ループとローカルサブネット例外不足です。まず設定で TUN を切り、systemctl restart NetworkManager などで経路を戻してから、ルールと DNS を見直します。Ubuntu から移行した読者は、同じ YAML を持ち込んでもホスト側のセキュリティスタックだけが違うことで挙動が変わる点に注意してください。
まとめ
Fedora Workstation で Clash Meta を「再起動後も同じ姿勢で立ち上がるサービス」にするには、dnf で土台を確認し、配置パスと SELinux のコンテキストを先に固め、手動起動でログを潰してから systemd に載せる順序が安全です。TUN は便利ですがルートと DNS に触れるため、capabilities の付与と併せて、VPN やコンテナネットワークとの競合を先に潰してください。
Ubuntu 向けの常駐ガイドと本稿を対にして読むと、「どこまでがコア設定で、どこからがディストリ固有か」が線引きしやすくなります。GUI クライアントに慣れた方でも、Linux 版コアはバージョン管理と複数マシン展開に強く、インフラ寄りのワークフローと相性がよいのが長所です。
同種ツールのなかでも Mihomo 系はルール表現が豊富で、ログから挙動を追いやすい点が実務では助かります。手元の構成が固まったら、購読とルールの更新ポリシーを決め、クライアントを当サイトの入手導線から最新に保つと長期運用が楽になります。