1 なぜ Termux か（限界も含めて）
Android でプロキシを使う代表的な経路は、VPN 権限を持つアプリに任せる方法です。一方で、SSH やスクリプトに慣れたユーザーは、設定ファイルをそのまま git 管理したり、curl で購読を引いたり、ログをその場で tail したりしたいと考えます。Termux は非ルートの Linux 風環境を端末内に用意するため、Mihomo の単一バイナリと config.yaml さえ揃えば、PC の Linux で systemd 運用する例に近い運用感を狙えます。
ただし Android はアプリを積極的にスリープさせ、バッテリー最適化でバックグラウンド実行を止めます。したがって「常に VPN で端末全体をフックする」快適さは、GUI クライアント側の VPN 実装に軍配が上がりがちです。Termux 路線はローカル HTTP／SOCKS プロキシとしてコアを立て、利用アプリ側でプロキシ指定する前提に置くと現実的です。図らずも FlClash のグラフィカル設定が苦手な人と、コマンドで詰めたい人のすき間を埋めるのが本稿の位置づけです。
2 前提：Termux とストレージ
可能なら公式配布に近いビルドを拾う目的で、F-Droid 版 Termuxの利用を検討してください（古い Google Play 版は更新が止まっている例があり、パッケージ整合性でつまずきやすいです）。初回に pkg update と pkg upgrade を済ませ、curl や wget、エディタ（vim や nano）を入れておきます。購読 URL を端末外からコピーして貼りたい場合は、ストレージ許可や termux-setup-storage により ~/storage/ 配下を使えるようにしておくと、ダウンロードフォルダ経由の YAML 受け渡しが楽です。
config.yaml のバックアップ取り扱いには十分注意してください。公的 Wi-Fi などでは端末盗見リスクも忘れずに。
3 Mihomo バイナリの配置
Mihomo のリリースから Android 向け arm64 の圧縮アーカイブを取得し、例として ~/mihomo/ に展開します。実行権限を付与し、同じディレクトリに config.yaml を置くと、カレントをそのディレクトリにしたうえで -d オプションを使う運用が素直です。CPU アーキテクチャが異なる端末では別名のバイナリになるため、必ず自分の端末に合わせて選びます。
# After extracting the mihomo binary into ~/mihomo/
cd ~/mihomo && chmod +x mihomo
./mihomo -d .初回はフォアグラウンドで起動し、標準出力にエラーが出ていないか確認します。ポート競合や設定不備があれば、ここで気づけます。
4 購読の取り込みと設定ディレクトリ
購読そのものは proxy-providers に HTTPS の URL を書く方法が一般的です。プロバイダが生成する YAML を wget／curl で ~/mihomo/profiles/ に保存し、proxy-providers: の path をローカルに向ける運用もあります。いずれにせよ、Mihomo は config.yaml を単一起点にするため、GUI に頼らず reload や再起動で反映する流れを覚えておきます。ルール集合が大きいほど起動時の読み込みに時間がかかる点は、デスクトップの Clash 運用と同じです。
ルールや DNS の細部は、端末の電池消費や接続断に直結します。Meta 系 DNS の記事で書いている fake-ip と DoH の扱いを、スマホでも過不足なく持ち込んでください。特に「アプリはプロキシを見ているのに名前解決だけ別経路」という状態を避けるのが安定運用の鍵になります。
5 .bashrc で PATH と起動エイリアス
毎回長いパスを打たないよう、~/.bashrc（Zsh を既定にしている場合は ~/.zshrc）に export PATH と エイリアスを定義します。これにより「シェルを開いたらすぐに Mihomo を起動コマンドへアクセスできる」状態が作れます。自動常駐にしたい場合は、エイリアスとは別に、後述の Termux:Boot 用スクリプトから同じコマンドを呼び出すと齟齬が減ります。
export MIHOMO_DIR="$HOME/mihomo"
export PATH="$MIHOMO_DIR:$PATH"
alias mihomo-run='cd "$MIHOMO_DIR" && ./mihomo -d .'
シェル起動時に無条件でプロセスを立ち上げると、複数のセッションから二重起動しやすいため、実運用では「必要なときだけ mihomo-run」「既に動いていれば何もしない」といったガードを足すか、mihomo 側の単一インスタンス前提を確認してください。
6 Wake Lock と Termux:API
画面消灯後に作業を続けさせたいとき、Termux では partial wake lock を取得する手段があります。termux-api パッケージと、端末側の Termux:API（F-Droid 等）を組み合わせ、シェルから termux-wake-lock を実行するのが定番です。これは端末を永久にフル稼働させる魔法ではなく、省電力施策に対抗するためのひとつの武器だと理解しておくと期待値がずれません。
実際の運用では、長時間バックグラウンドで動かす前に、メーカー設定のバッテリー最適化の除外や 最近使用したアプリでのロックも併用する例が多いです。Wake Lock だけに依存せず「止まったらもう一度コマンドで立ち上げる」運用も視野に入れておくと、精神的な負担が減ります。
termux-wake-unlock などで解放する習慣をつけてください。
7 ブート／復帰時の自動起動
端末再起動後も手を抜きたい場合は、Termux:Boot のような拡張を使い、~/.termux/boot/ にシェルスクリプトを置いて初期化します。ここで termux-wake-lock を呼び出してから Mihomo を起動する、という順序がよく取られます。スクリプトは実行権限を付け、標準エラーをログファイルに残すと、後から原因追跡がしやすくなります。
Android のバージョンやメーカー実装によっては、バックグラウンド制限によりスクリプトが思ったタイミングで動かないことがあります。そのときは「手動で Termux を一度開いてから走らせる」運用や、通知を出してユーザーに復帰を促すテクニックが議論に上がりますが、根本はモバイル OS の省電方針なので完璧には揃いません。
8 External Controller と健全性
ダッシュボードから切り替えたい場合は、external-controller をLAN 内だけにバインドするなど露出範囲を限定したうえで External Controller と yacd のパターンを持ち込めます。スマホ単体運用なら、ローカルホストに縛るのが無難です。疎通確認には curl で REST を叩く手もあります。
9 無 Root でできないこと（期待値の調整）
ルート無しの Termux で Mihomo を動かしても、システム全体の透過プロキシ化や TUN で全アプリを強制 VPN といった振る舞いは、基本的に別レイヤーの実装（VPN 権限付きアプリ等）が担います。ターミナル内の git／npm／ブラウザの一部設定でプロキシを向ける、あるいはルーティング可能なアプリだけを選ぶ、というスタンスが現実的です。これは「欠点」というより権限モデルの差として受け取ってください。
10 まとめ
本稿では Termux 上で Mihomo を配置し、購読を取り込み、.bashrc で操作しやすくし、Wake Lock と起動スクリプトでバックグラウンド維持を狙う道筋を整理しました。GUI に頼らない利点は再現性とスクリプト化のしやすさにありますが、Android の省電仕様は一筋縄ではいきません。FlClash 入門で端末全体を VPN として扱う快適さと、本稿のターミナル運用を、用途に応じて使い分けるのがよいでしょう。
デスクトップでは GUI の Clash クライアントの方がルール編集やログ閲覧が楽な場面も多く、両方そろえると外出先は Termux／自宅は PC クライアントといった役割分担もしやすくなります。クライアントの入手は当サイトのダウンロードページを第一候補にし、ソースコードの参照や Issue は別途公式ホストへ、という分け方が安全です。
ターミナルでコアを触り慣れているほど、Mihomo は「設定ファイル＋ログ」というインターフェースの素朴さが強みになります。一方でモバイルでは電源管理が横槍に入るため、Wake と OS 設定をセットで設計するのが長期戦では有利です。
