全プラットフォーム対応 Clash導入・設定ガイド

事前準備：アーキテクチャ、サブスクリプション、通信の振り分け方式

クライアント、コア、設定ファイルの違い

クライアントは画面表示、サブスクリプション管理、システム連携、権限の要求を担当します。mihomoコアは設定の解析、接続の確立、ルールの実行を担当します。画面が似ていても、対応する設定機能が同じとは限りません。同じClash設定でも、特定のコアでしか使えない項目が含まれる場合があります。インポート前に、サブスクリプションの提供元が案内する対応環境を確認してください。ClashXはmacOS向けクライアントの名称であり、Windows、スマートフォン、Linux共通のインストーラーではありません。あるプラットフォームのアプリを別のプラットフォームで実行することはできません。

設定には通常、ノードまたはプロキシプロバイダー、プロキシグループ、ルール、DNS設定が含まれます。サブスクリプションURLはこれらの情報を取得するための入口であり、URLの末尾だけで形式を判断することはできません。ブラウザーでリンクを開けても、解析可能なYAMLが返るとは限りません。ログイン画面、通信量の期限切れ通知、Webエラーなどが返るとインポートに失敗します。サブスクリプションには認証情報が含まれるため、公開コメント、オンライン変換サイト、トラブル画面のスクリーンショットに掲載しないでください。

システムのアーキテクチャと既存のネットワーク設定を確認

Windowsでは「設定 → システム → バージョン情報」でシステムの種類を確認します。macOSでは「このMacについて」でチップを確認し、Linuxでは uname -m を実行します。Apple SiliconとIntelでは対応するパッケージが異なり、Linuxではディストリビューションに合った形式を選ぶ必要があります。AndroidのインストーラーにもARM64、ARMなどの違いがあるため、まずダウンロードページの案内を確認してください。ダウンロードできても、端末に適合しているとは限りません。インストールエラーが出た場合は、再ダウンロードの前にアーキテクチャを確認しましょう。

開始前に、既存のプロキシ、VPN、DNS、ネットワークフィルタリングソフトの設定を記録しておきます。会社の端末では、管理ポリシーによってプロキシや証明書が指定されている場合があります。権限の制限がある場合は、システム設定を繰り返し上書きせず、端末の管理者に相談してください。最初のトラブルシューティングでは、通信を制御するクライアントを1つだけ起動し、複数のアプリが同時にシステムプロキシやデフォルトルートを変更しないようにします。業務用VPNを併用する場合は、共存できるか先に確認してからテストしてください。

再現できる初回接続の手順

まずクライアントをインストールして正常に起動することを確認し、サブスクリプションを追加します。設定が選択され、プロキシグループに利用可能なメンバーがあることを確認したら、ルールモードを選び、ノードを1つ指定します。最後にシステムプロキシまたはモバイル端末の接続を有効にしてください。各手順の後にログと画面を確認し、ポート、DNS、ルート、ルールを一度に変更しないようにします。初回テストに失敗した場合は設定を変えず、サブスクリプション取得、コア起動、ローカルの待ち受け、外向き接続のどの段階で問題が起きているかを切り分けます。

テストでは、プロキシを使わない想定のWebサイトと、プロキシが必要なWebサイトの2つを確認します。ブラウザーでページが開くかだけでなく、接続一覧で実際に適用されたプロキシグループも確認してください。キャッシュ、接続の再利用、ブラウザーのセキュアDNSによって、一度の表示結果が誤解を招くことがあります。基本動作を確認してから、自動更新、自動起動、TUNを有効にすれば、問題が起きた際に戻すべき設定が明確になります。端末を移行する場合は、元の設定のコピーとカスタムルールも保管してください。

Windows：インストール、システムプロキシ、TUN

インストーラーを選び、初回起動を完了する

Windowsでは Clash Plusをおすすめします。デスクトップ機能を比較する場合は、Clash Verge Rev、FlClash、Clash Nyanpasuも順に確認できます。Clash for Windowsは開発が終了したアーカイブ版クライアントのため、新規インストールにはおすすめしません。Windows用インストーラーからシステムの種類に合ったファイルを選び、設定を保存してから旧クライアントを置き換えると、移行時にサブスクリプションやローカルルールを失うリスクを減らせます。

インストーラーを実行する際は、権限に関する確認を読み、インストール後はまず通常のユーザーとして起動してください。クライアントの画面が開いても、ポートの競合、設定エラー、セキュリティポリシーによってコアが起動していない場合があります。コアのログで状態を確認しましょう。サービスコンポーネントや仮想ネットワークアダプターが必要な場合は、クライアントのインストール機能から管理者権限を要求してください。日常の操作すべてを管理者アカウントで行う必要はありません。組織の管理下にある端末では、ネットワークサービスのインストールが禁止されている場合がありますが、サブスクリプションの内容とは無関係です。

サブスクリプションを追加し、選択状態を確認

「設定」「サブスクリプション」などの項目からリモート設定を追加し、URLをすべて貼り付けて更新します。設定が一覧に表示されたら現在の設定として選び、プロキシグループを開いてノードを1つ指定してください。サブスクリプションを追加しただけで現在の設定に切り替えていない場合、古いファイルが引き続き使われることがあります。プロキシグループが空の場合は、システムプロキシを何度も切り替えるのではなく、サブスクリプションの応答と解析ログを確認してください。

Clash for Windowsから移行する場合は、サブスクリプションURLや自分で追加したルールを引き継げますが、新しいクライアントのアプリデータを旧版のデータで丸ごと置き換えないでください。旧版の画面設定、サービスのパス、拡張スクリプトは移行できない場合があります。まず新しいクライアントに元のサブスクリプションを追加して基本接続を確認し、その後、上書き設定を1つずつ戻してください。旧スクリプトの構文やコア固有の項目については、新しいクライアントの設定チェック結果を優先してください。

システムプロキシの動作確認後にアプリごとの差を調べる

まずルールモードのまま、クライアントのシステムプロキシを有効にします。Windowsの「設定 → ネットワークとインターネット → プロキシ」で、手動プロキシのアドレスとポートが通常はローカルの待ち受け先を指していることを確認してください。ブラウザーでアクセスできたら、開発ツールなど他のアプリもテストします。アプリ独自のプロキシ設定を使うものや、WinHTTPの設定を参照するバックグラウンドサービスもあります。デスクトップのシステムプロキシを有効にしても、自動的に経路が変わるとは限りません。

コマンドラインから接続先を明示して確認できます。次のコマンドはローカルのHTTPプロキシ経路をテストするもので、接続先サイトにノードを使うかどうかは設定のルールで決まります。PowerShellでは curl.exe を使うと、旧環境で同名の別名コマンドが異なる引数として処理する問題を避けられます。実際のポートが7890ではない場合は、コマンド内のポートも合わせて変更してください。

curl.exe -I --proxy http://127.0.0.1:7890 https://example.com

接続拒否と表示されたら、まずクライアントが起動しているか、ポートが一致しているか、待ち受けが成功しているかを確認します。ローカルには接続できるものの、接続先がタイムアウトする場合は、プロキシグループ、ノード、DNSを確認してください。一部のUWPアプリにはループバック制限があります。クライアントに専用の管理機能があれば確認し、通常の対処として全アプリを一括で許可しないでください。必要なアプリだけ個別に設定し、元に戻せるよう変更内容を記録しましょう。

TUN、自動起動、終了後の設定復元

ゲーム、独自のネットワークスタックを使うアプリ、システムプロキシを参照しないアプリには、TUNの利用を検討できます。まずクライアントの案内に従ってサービスをインストールし、拡張モードを有効にして仮想ネットワークアダプターとルートが作成されたか確認してください。TUNで対象アプリの通信を制御できている場合、設定項目を増やすためだけに他のプロキシツールを重ねて使う必要はありません。有効化後にローカルプリンター、LAN内のサービス、社内ネットワークに問題が起きた場合は、プライベートネットワークの除外ルールや既存VPNのルートを確認してください。

自動起動とコアの起動は別の処理です。ログイン後に画面が表示されても、サービスが利用可能とは限りません。サービスが起動していても、サブスクリプションが読み込まれたり、プロキシ設定が復元されたりしているとは限りません。再起動後はこの順に確認してください。クライアントを終了する前にシステムプロキシを無効にします。異常終了後にWebへ接続できなくなった場合は、システムプロキシの設定を開いて残った設定を解除し、直接接続をテストしてください。自動起動の詳細は自動起動に関するFAQ、クライアントの比較はWindowsクライアント比較をご覧ください。

macOS：チップの種類、ネットワーク権限、メニューバー

チップに合ったクライアントを選び、設定を移行する

macOSでは Clash Plusをおすすめします。Clash Verge RevやFlClashも選べます。ClashX Metaは開発が終了しています。アーカイブ版は明確な互換性要件がある旧環境向けであり、新機能への対応を期待するクライアントではありません。「このMacについて」でAppleシリコンかIntelかを確認し、macOSのダウンロードページで対応するアーキテクチャを選んでください。同じ年に発売されたモデルでもチップが異なる場合があるため、発売年だけで判断しないでください。

ディスクイメージを開いたら、アプリを「アプリケーション」フォルダにドラッグし、そのフォルダから起動してください。ディスクイメージ内のアプリを使い続けないようにします。旧アプリを置き換える前に、旧クライアントを正常に終了してください。ファイルが使用中と表示された場合は、メニューバーのプロセスも終了したか確認します。初回起動時にシステムのセキュリティ警告が表示されたら、まずファイルの入手元を確認し、システムが案内する手順で許可してください。個別のアプリを起動するために、システム全体のセキュリティ機能を無効にしないでください。

サブスクリプションを追加し、メニューバーの状態を確認

クライアントの設定からサブスクリプションを追加するか、ローカルのYAMLファイルをインポートします。保存後にその設定を選び、プロキシグループで現在使うメンバーを確認してください。メニューバーの「ルール」「グローバル」「直接」は通常、ルーティングモードを示します。ノード名はプロキシグループで選択する項目であり、両者は置き換えられません。ルールモードを選んだ後も、ルールが参照するプロキシグループに適切なメンバーが設定されていることを確認してください。そうでないと、画面上は正常でも、通信が準備できていない経路に送られることがあります。

ClashXまたはClashX Metaから別のクライアントに移行する場合は、まずサブスクリプションを追加し、その後、自分で管理しているルールを移します。メニューバーの設定、ショートカット、補助サービス、ローカルスクリプトはアプリ固有のため、フォルダ全体を上書きしないでください。リモート設定の更新で直接編集した内容が上書きされる場合があります。長期的に使うカスタムルールは、クライアントが対応する上書きまたはマージ機能に追加し、編集画面だけでなく最終的な有効設定を確認してください。

システムプロキシ、補助サービス、ネットワーク環境

システムプロキシを有効にした後、「システム設定 → ネットワーク → 現在のネットワークサービス → 詳細 → プロキシ」でHTTPとHTTPSの設定を確認できます。macOSのバージョンによって名称が多少異なる場合があります。一覧にある未使用のネットワークではなく、現在接続中のWi-FiまたはEthernetを確認してください。ネットワークアダプターの交換、ドッキングステーションの接続、ネットワーク環境の切り替え後は、現在のサービスにプロキシが適用されているか再確認しましょう。

ターミナルでシステムプロキシの状態を確認できます。出力される有効化の状態、サーバー、ポートがクライアントの設定と一致するか確認してください。このコマンドは状態を表示するだけで、システム設定は変更しません。プロキシが有効なのにブラウザーの接続記録が残らない場合は、ブラウザー独自のプロキシ拡張機能や、ローカルアドレス・指定ドメインを除外するリストを確認してください。

scutil --proxy
curl -I --proxy http://127.0.0.1:7890 https://example.com

TUNやネットワーク補助サービスを初めて有効にするとき、システムから許可や管理者パスワードを求められる場合があります。クライアントで操作を開始してからシステムの確認画面を見て、現在のアプリからの要求であることを確認してください。サービスのインストールに失敗した場合は、アプリのパス、システム権限、ログを確認します。同じサービスを複数のアプリのコピーに繰り返しインストールしないでください。メニューバーにアイコンが表示されていても、補助サービスが動作しているとは限りません。接続画面と起動ログも判断材料になります。

スリープ復帰、ターミナルツール、ローカル開発

Macがスリープから復帰した後や、Wi-Fiからテザリングに切り替えた後は、既存の接続が無効になることがあります。まず設定を再読み込みするか接続を再確立し、ノードの変更が必要か判断してください。TUNを有効にした場合だけ問題が起きるなら、一時的にシステムプロキシに切り替えて、サブスクリプションと仮想ネットワークアダプターのルートのどちらに原因があるか切り分けます。クライアントを終了しても直接接続できない場合は、現在のネットワークサービスに手動プロキシが残っていないか、他のVPNが接続中でないか確認してください。

ターミナルツールは、GUIのシステムプロキシ設定を完全には引き継がないことがあります。必要に応じて現在のターミナルで環境変数を設定し、一時的にテストしてからシェルの設定ファイルに追加するか判断してください。NO_PROXY にはローカル開発用のアドレスを追加し、ローカルサービスがプロキシを経由しないようにできます。意味を把握していない広範囲のドメインを除外リストに追加しないでください。Git、パッケージマネージャー、コンテナにも独自の設定がある場合があります。システム設定を繰り返し切り替えるより、それぞれを確認するほうが効果的です。

Android：インストール権限、VPNインターフェース、バックグラウンド動作

アーキテクチャを選び、アプリのデータを保持

Androidでは Clash Plusをおすすめします。ほかの選択肢は、Clash Meta for Android、FlClash、Surfboardです。クライアントによって、サブスクリプション形式、ルール構文、拡張項目への対応状況が異なります。特にmihomo向けの複雑な設定が、すべてのクライアントで使えるとは限りません。Android用インストーラーの案内でアーキテクチャと設定の互換性を確認してから、ダウンロードしてインストールしてください。

ローカルのインストーラーを実行する際、ブラウザーやファイル管理アプリに「不明なアプリのインストール」を許可するよう求められる場合があります。実際に使用するアプリだけ、一時的に許可してください。解析エラーが発生した場合は、ファイルを最後までダウンロードできたか、アーキテクチャが合っているか、システム要件を満たしているか確認します。アップデート時に署名が一致しないと表示されても、すぐにアンインストールしないでください。移行を決める前に、保存可能な設定やローカルルールを書き出し、現在のアプリの入手元を確認しましょう。アンインストールすると、通常はアプリのデータも削除されます。

サブスクリプションの追加と初回VPN許可

サブスクリプションURLを設定画面に貼り付け、ダウンロード後にその設定を選択します。クライアントによっては、設定を追加した後に別途更新操作が必要です。タイトルが表示されても、ノードを取得できたとは限りません。インポートに失敗したら、現在のネットワークからサブスクリプションのサーバーにアクセスできるか確認します。URLへのアクセスにプロキシが必要な場合は、信頼できる別のネットワークか、提供元が案内するインポート方法を使ってください。非公開のURLを公開変換サービスに送らないでください。

プロキシグループとノードを選んで接続を開始すると、AndroidにVPNの許可画面が表示されます。インストールしたクライアントからの要求であることを確認して許可し、システムのVPNアイコンとクライアントの接続状態を確認してください。このインターフェースは通信をローカルのクライアントに渡すためのもので、すべての通信がリモートノードを経由するという意味ではありません。ルールによって一部の接続が直接通信になる場合があります。起動に失敗したら、まず許可が拒否されていないか確認し、次に他のVPN、ネットワークフィルター、ファイアウォールアプリとの競合を調べてください。

アプリごとの振り分けとシステムネットワーク設定

一部のアプリだけを制御する場合は、クライアントのアプリ別アクセス制御を使い、現在のモードが「選択したアプリのみ」か「選択したアプリを除外」か確認してください。2つのモードは意味が反対です。同じアプリを選んでも結果はまったく異なります。変更後は通常、VPN接続の再確立が必要です。既存の接続はすぐに経路が切り替わらないことがあります。テストの際は対象アプリを終了してから再起動し、接続記録で通信がクライアントに渡されたか確認してください。

AndroidのプライベートDNS、ブラウザーのセキュアDNS、クライアントのDNS設定が同時に有効な場合があります。ドメイン名の解決に問題があるときは、まず現在の設定を記録し、項目ごとに確認してください。複数の設定を一度に変更しないでください。IPアドレスでの接続は成功し、ドメイン名でのアクセスだけ失敗する場合は、名前解決の経路を重点的に確認します。すべてのリクエストがタイムアウトする場合は、ノードとルートも調べる必要があり、「ページが開かない」だけでDNSの問題と決めつけないでください。仕事用プロファイルのアプリには、独自のポリシーが適用される場合もあります。

画面ロック後の切断、ネットワーク切り替え、バッテリー設定

画面を表示している間は正常でも、ロック後に切断する場合は、バッテリー最適化、バックグラウンド動作、自動起動の権限を確認してください。設定画面の場所はメーカーによって異なり、バッテリー、アプリ管理、セキュリティなどにあります。機能を手がかりに探してください。まずクライアントに必要なバックグラウンド動作を許可し、画面をロックしてテストします。すべてのアプリの省電力制限を解除する必要はありません。常時表示の通知がフォアグラウンドサービスの状態表示を兼ねるシステムもあります。通知を非表示にした後に接続が不安定になった場合は、標準設定に戻して比較してください。

Wi-Fiからモバイルデータ通信に切り替えると、既存の接続を再確立する必要がある場合があります。クライアントに接続中と表示されていても、新しいリクエストが通るか確認してください。接続をいったん停止して再開し、同じ接続先でテストできます。特定のネットワークだけで失敗する場合は、DNS、IPv6、ネットワーク側の制限を比較してください。ノード一覧のテスト結果だけで、すべてのアプリが使えるとは限りません。

通常、1台のスマートフォンで複数の一般的なVPNアプリが同じユーザーの通信を同時に制御することはできません。広告ブロッカー、ファイアウォール、業務用VPNとの競合時は、用途に応じて通信を制御するアプリを選び、スイッチを素早く交互に切り替えないでください。テレビなどからスマートフォンやPCのプロキシを使う場合は、ホットスポットの端末間通信制限、待ち受けアドレス、ファイアウォールも確認する必要があります。スマートフォンでVPNを有効にしても、ホットスポット接続中の端末の通信がプロキシ経由になるとは限りません。LAN共有の手順はmixed-portとLAN接続の設定をご覧ください。

iOS：Clash Plus、設定のインポート、ネットワーク拡張

ストアからインストールし、設定の入手元を確認

iPhoneとiPadでは Clash Plusをおすすめします。App StoreのClash Plusページからインストールできます。製品情報は公式サイトのclashplus.ioをご覧ください。当サイトのiOSダウンロードページにも同じリンクを掲載しています。インストール後にクライアントを起動し、システム権限の案内を確認してからサブスクリプションを追加してください。Apple Accountの情報や端末のパスコードを、サブスクリプションサービスのWebフォームに入力しないでください。

iOS版とデスクトップ版では、画面構成、ネットワーク拡張機能、設定の互換性が異なる場合があります。デスクトップで使っているサブスクリプションがある場合は、提供元が現在のクライアントに対応しているか確認してください。特にスクリプト、外部リソース、コア固有の項目に注意が必要です。設定名が同じでも、解析方法が完全に一致するとは限りません。複数の形式が提供されている場合は、未知の変換URLを順に試すのではなく、対応クライアントが明記された形式を選んでください。

設定を追加してプロキシグループを選び、接続を許可

クライアントの設定またはサブスクリプションからURLを追加し、更新後に対象の設定を選びます。プロキシグループを開いてメンバーを確認してください。まずノードを1つ手動で選んで基本動作をテストし、成功した後で自動選択などのルールを使います。自動選択はテスト先、間隔、候補となるメンバーに左右されます。一度のテスト結果が示すのはテスト先への応答だけであり、動画、業務システム、他のサービスが同様に利用できる保証にはなりません。

接続を初めて開始すると、iOSからVPN構成の追加を求められます。システムの案内に従って端末認証を完了してください。許可した後、クライアントに戻って接続が実際に開始されたことを確認します。このVPN構成はローカルのネットワーク拡張に通信を渡すためのもので、サブスクリプションのアカウントとは別です。ノード情報の代わりにもなりません。システムからVPN構成を誤って削除した場合は、通常クライアントから再度許可を求めます。サブスクリプションを買い直したり、すべてのネットワーク設定をリセットしたりする必要はありません。

テストではまずSafariで、直接接続する想定のサイトを開き、次にプロキシが必要なサイトを開きます。その後、クライアントの接続一覧やログを確認し、ルールが想定どおり適用されたか調べてください。ブラウザーに表示されているページがキャッシュの場合や、アプリが古い接続を再利用している場合があります。プロキシグループを切り替えた後は、新しいリクエストを送ってください。ステータスバーのアイコンだけでは、対象の通信が選択したノードを経由したか判断できません。

システムの制限と接続の競合を確認

iOSでは通常、ネットワーク拡張を使って接続します。デスクトップのように「システムプロキシとTUNを同時に有効にする」手順をそのまま適用する必要はありません。クライアントによって用語が異なるため、現在の画面に表示される説明を確認してください。Wi-FiにHTTPプロキシを手動設定する方法は別の経路であり、その設定が適用される通信だけに影響します。モバイルデータ通信の代替にもなりません。基本動作の確認では、通信を制御する経路を1つに絞り、手動のWi-Fiプロキシとネットワーク拡張を併用しないでください。

端末に他のVPN、コンテンツフィルター、組織の管理構成がある場合、接続が置き換えられたりブロックされたり、ネットワーク切り替え後に別の設定へ戻ったりすることがあります。システムの「設定」でVPNを検索し、現在の接続をどのアプリが管理しているか確認してください。組織管理端末では、業務用の設定を削除せず、管理者に確認してください。システムのプライベートリレーなどの専用機能、ブラウザーのプライバシー機能、アプリ内のネットワーク設定もアクセス経路に影響する場合があります。トラブルシューティングでは、それぞれの状態を記録しましょう。

ネットワーク切り替え、アップデート、バッテリー消費の確認

自宅のWi-Fiからモバイル通信に切り替えたら、まず新しいリクエストが成功するか確認してから、接続を再確立するか判断してください。ホテルや公共Wi-Fiだけで失敗する場合は、先にネットワークへのログイン認証が必要なことがあります。一時的にクライアントを切断し、ネットワーク認証を完了してから再接続してテストしてください。認証ページが開かない場合は、サブスクリプションのノードを何度も切り替えるのではなく、システムのネットワーク設定に残った手動プロキシを解除してください。

安定したネットワークでサブスクリプションを更新し、完了後に現在のプロキシグループが有効なメンバーを参照していることを確認してください。ノードが削除または改名されると、以前選択したメンバーが無効になる場合があります。その場合は選び直してください。更新に失敗しても、現在使える設定をすぐ削除する必要はありません。接続を維持したまま、応答形式とサービスの状態を確認してください。詳しい手順はサブスクリプション更新失敗時の確認項目をご覧ください。URLの有効性やYAMLの確認はモバイル端末でも同様に役立ちます。

VPNアイコンが表示され続けているだけでは、バッテリー消費を判断できません。近い使用条件でシステムのバッテリー使用状況を比較し、接続の頻繁な失敗、短すぎるテスト間隔、ログの大量出力がないか確認してください。まずクライアントのテスト頻度を標準に戻し、不要な詳細ログを無効にしてから様子を見ます。LAN機器の検出に問題がある場合は、ローカルネットワークの振り分けとアプリに必要な権限も確認してください。プリンター1台にアクセスするために、すべての通信を常時グローバルプロキシにする必要はありません。

Linux：デスクトップクライアントとsystemdでの実行

デスクトップ版はパッケージ形式とアーキテクチャを確認

Linuxデスクトップでは Clash Verge Revをおすすめします。FlClashも選べます。Linuxのダウンロードページでディストリビューションに合うパッケージを選んでください。Debian・Ubuntu系では通常DEB、RPMを採用するディストリビューションでは対応する形式を選びます。まず uname -m を実行してアーキテクチャを確認し、ダウンロードページに実際に用意されているファイルと照合してください。パッケージ形式とCPUアーキテクチャを混同しないでください。また、デスクトップ向けパッケージをサーバーに無理にインストールしないでください。

依存関係の管理とアンインストールを容易にするため、まずディストリビューションのパッケージマネージャーを利用してください。起動後にサブスクリプションを追加し、現在の設定とプロキシグループを選択してからシステムプロキシを有効にします。GNOME、KDE、ターミナルアプリではプロキシの参照方法が異なります。デスクトップのブラウザーで接続できても、コマンドラインが設定済みとは限りません。TUNが必要な場合は、クライアントの案内に従ってサービスと権限を設定してください。GUI全体をrootで実行し続けないでください。GUIのないサーバーでは、コアを直接実行する方法を使います。

GUIなしで実行する場合は、まず設定を手動で検証

サーバーやルーターでは、コアのダウンロードページからアーキテクチャに合ったmihomoを選べます。解凍後、実行ファイル本体を /usr/local/bin/mihomo に配置し、設定用のディレクトリを別に用意してください。以下の手順は実行ファイルが配置済みであることを前提としています。圧縮ファイルを実行パスにそのままコピーしないでください。ルールセットやプロキシプロバイダーに相対パスを使う場合は、リソースが正しい作業ディレクトリにあることも確認します。

既存の完全な設定を /etc/mihomo/config.yaml に保存し、読み取り権限を制限してから設定をテストします。テストに成功したら、まずフォアグラウンドで起動し、待ち受け、DNS、外向き接続のログを確認してください。最初はローカルだけで待ち受ける設定にし、正常動作を確認してから他の端末からのアクセスを検討します。コアを起動しただけでは、ターミナル、ブラウザー、システムサービスにプロキシ設定は適用されません。サーバーで「プロセスは正常だがリクエストが直接接続される」原因としてよくある点です。

sudo install -d -m 700 /etc/mihomo
sudo chmod 600 /etc/mihomo/config.yaml
sudo /usr/local/bin/mihomo -t -d /etc/mihomo
sudo /usr/local/bin/mihomo -d /etc/mihomo

専用ユーザーでsystemdに管理させる

フォアグラウンドでの検証が済んだらプロセスを停止してからサービスを設定し、同じポートを複数のプロセスが使わないようにします。以下の例はsystemdに対応し、対応するユーザー管理コマンドを使うディストリビューション向けです。ローカルプロキシのみを提供し、TUNは含みません。専用ユーザーを作成してディレクトリの所有者を設定してください。設定ディレクトリに書き込みが必要な場合も、そのサービスユーザーだけに許可します。他のディストリビューションでは、同等のシステムアカウント作成方法を利用してください。

sudo useradd --system --home-dir /etc/mihomo --shell /usr/sbin/nologin mihomo
sudo chown -R mihomo:mihomo /etc/mihomo

次の内容を /etc/systemd/system/mihomo.service に保存します。サービスは固定の設定ディレクトリを使い、プロセスが失敗した場合に再起動し、ネットワークの起動後に動きます。ネットワークが起動していてもサブスクリプションサーバーに接続できるとは限らないため、リモートリソースは別途確認してください。この例ではネットワーク管理権限を付与していません。設定でTUNを有効にする場合は、先に無効にするか、導入環境に合わせて最小権限を別途設計してください。

[Unit]
Description=mihomo local proxy
Wants=network-online.target
After=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=5
UMask=0077
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
systemctl status mihomo --no-pager
journalctl -u mihomo -b --no-pager -n 80

待ち受け、環境変数、アクセス範囲の確認

ss -lntp で7890が待ち受けているか確認し、プロキシを明示してリクエストをテストします。サービスの起動直後に終了する場合は、まず設定をテストし、ログでパスの権限やポートのエラーを確認してください。サービスユーザーが設定を読み取れない場合、すべてのユーザーに読み取りを許可するのではなく、所有者とディレクトリ権限を修正します。設定を更新したら、まずテストを行ってください。構文エラーで稼働中のサービスを停止させないよう、確認後に sudo systemctl restart mihomo を実行します。

curl -I --proxy http://127.0.0.1:7890 https://example.com
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

環境変数は現在のシェルとその子プロセスにだけ適用され、すでに動作しているsystemdサービスには自動で引き継がれません。コンテナ内の 127.0.0.1 はコンテナ自身を指し、ホストのアドレスとしてそのまま使うことはできません。コンテナ間やLANからアクセスする場合は、待ち受けインターフェース、アクセス元のネットワーク、ファイアウォールルールを明確にしてください。外部の制御インターフェースをインターネットに直接公開しないでください。リモート管理には保護された管理経路を利用します。詳しい導入方法はLinuxデスクトップ版とGUIなしでの実行方法をご覧ください。

よくある設定の問題：ポート、ルール、DNS、復元

mixed-portとLANでの待ち受け

mixed-port は同じポートでHTTPとSOCKSのプロキシリクエストを受け付けます。7890はよく使われる初期値であり、変更できない固定値ではありません。ポートを変更した場合は、システムプロキシ、ターミナルの環境変数、アプリ内設定、LAN内の端末も同じ値に変更してください。以下は既存設定に追加する基本項目の例で、ノードやプロキシグループは含みません。完全なサブスクリプションの代わりにはなりません。クライアントの上書き設定を使う場合は、該当する画面で変更し、実行時に有効な値も確認してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

ローカル端末だけで使う場合は、LANからの接続を無効にしたままにします。スマートフォンやテレビと共有する場合に限り、LANアクセスを有効にし、待ち受けアドレス、ファイアウォール、端末間の通信制限を確認してください。他の端末では 127.0.0.1 ではなく、PCのLAN内アドレスを指定します。信頼できるネットワークだけにアクセスを許可し、外部ネットワークから接続できる状態を避けてください。allow-lan とコントロールパネルのインターフェースは別の設定です。プロキシポートを公開しても、制御インターフェースまで公開する必要はありません。

ルールの順序、上書き、プロキシグループの参照

ルールは通常、上から順に照合され、最初に一致したルールで通信先が決まります。特定のドメインを対象とするルールは、最後に適用されるルールより前に置きます。MATCH は通常、末尾に配置します。以下の例は、完全な設定に Proxy という名前のプロキシグループがすでにあることを前提としています。大文字・小文字を含め、名称を一致させてください。ルールの追加後は設定を再読み込みし、新しい接続の適用結果を確認します。既存の接続には古いルールが適用され続ける場合があります。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-KEYWORD,adservice,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

サブスクリプションの更新後にルールが消える場合、リモート設定ファイルを直接編集している可能性があります。クライアントが対応する上書きまたはマージ機能を使い、ルールを挿入する位置も確認してください。YAMLのインデントにはスペースを使い、タブを混在させないでください。コロンなどの特殊文字を含む文字列は適切に引用します。エラーが表示された行が原因の行とは限りません。直前の行でリスト記号や階層が欠けていても、解析に影響します。ルール構文とプロキシグループの参照を確認してから、ネットワークのトラブルシューティングに進んでください。

DNSと証明書のエラーは分けて対処

DNSはドメイン名の解決方法を決め、ルーティングルールは接続の送信先を決めます。両者は関係しますが、互いの代わりにはなりません。一部のドメインで問題が起きる場合は、ログで名前解決の失敗、ルールの適用、接続の確立状況を確認してください。fake-ipモードでは合成アドレスを通信の識別に使うため、公共DNSと異なるアドレスが返るだけで異常と判断しないでください。DNSモードを切り替えた後は、システムやアプリにキャッシュが残る場合があります。接続を再確立してからテストしてください。

HTTPS証明書の警告が出た場合は、まずシステム時刻、接続先ドメイン、証明書の発行元、ネットワークのフィルタリング設定を確認してください。「証明書エラーを無視する」を復旧手順として使わないでください。特定のノードだけで発生する場合はそのノードの使用を中止し、信頼できる経路でテストします。直接接続でも発生する場合は、端末と現在のネットワークを確認してください。具体的な確認方法はHTTPS証明書エラーへの対処をご覧ください。端末のポートを何度も変更して証明書の問題を隠さないでください。

ログの収集と設定の戻し方

トラブルシューティングでは、システム、クライアント名、現在のモード、通信の制御方法、問題が起きた時刻を記録し、該当する時間帯のログを保存してください。ログにはドメイン名、サブスクリプションURL、アカウント情報が含まれる場合があります。共有前に機密情報を削除してください。まず問題を一度再現してから、設定を1つずつ変更します。TUNを一時的に無効にしてシステムプロキシを使えば、ルート制御とノード接続を切り分けられます。プロキシを明示したリクエストを送れば、ローカルの待ち受けも確認できます。

直接接続に戻す場合は、まずシステムプロキシとTUNを無効にしてからクライアントを正常に終了し、最後にシステムにプロキシ、VPN、手動DNSの設定が残っていないか確認してください。最初からネットワーク設定をすべてリセットすると、原因の手がかりや業務用の設定を失うおそれがあります。まだ疑問がある場合はサブスクリプションに関するFAQをご覧ください。接続手順を最初からやり直す場合は、クイックスタートガイドに沿って進めてください。