インストール・設定・トラブル対処

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

設定の参照元から通信の出口まで、システムごとに各設定を確認します。

このページは、各プラットフォームのインストール、サブスクリプション管理、通信のプロキシ経由設定、固有の問題を解説するガイドです。初めて使う場合は、まずクイックスタートに沿って接続を確認し、その後このページに戻って権限、DNS、ルーティングの詳細を確認してください。クライアントとインストーラーはダウンロードページにまとめています。特定のバージョンには依存しません。

共通の事前準備

クライアント、コア、接続設定

Clashの利用では、クライアント、コア、接続設定の3つを区別する必要があります。クライアントは画面表示、設定管理、システム連携を担当し、コアはプロトコル接続、ルール判定、DNSを処理します。サブスクリプションやローカル設定には、サーバー、プロキシグループ、ルールが含まれます。インストールが完了しても、利用可能な接続先があるとは限りません。このページのデスクトップ向け設定例はmihomoを対象としています。他の実装では対応フィールドを確認し、名前が似ているだけで設定を流用しないでください。

クライアント選びはClash Plusから始め、OSや使い方に合わせて他のクライアントと比較してください。Windows、macOS、Android、iOSにはそれぞれ対応アプリがあります。LinuxではClash Verge RevやFlClashを選べます。同じ機能でも、画面によって「設定」「サブスクリプション」「プロファイル」など名称が異なります。名称ではなく役割で判断しましょう。リモートアドレスを保存するものが設定の参照元、通信の出口を選ぶものがプロキシグループ、どのアプリの通信をプロキシ経由にするか決めるものが通信のプロキシ経由設定です。

アーキテクチャと設定の参照元を確認する

まずシステム情報でOS、プロセッサのアーキテクチャ、空き容量を確認します。Intel・AMDのデスクトップ向けCPUでは通常x64またはAMD64版、Apple SiliconではARM64版を使います。WindowsのARMデバイスも個別に確認してください。ファイルの拡張子で分かるのは配布形式であり、アーキテクチャではありません。アプリが起動しない場合は、ネットワーク設定を変更する前に、インストーラーとシステムの組み合わせを確認しましょう。

信頼できるサービスから提供されたClash対応サブスクリプションURL、または検証済みのYAMLファイルを用意します。サブスクリプションURLにはアカウント情報が含まれる場合があります。ログ、スクリーンショット、設定を共有する前に、クエリパラメーターやサーバーの認証情報を削除してください。ブラウザーでURLを開けても、クライアントにインポートできるとは限りません。ログイン画面や通信量の案内など、別の形式が返ることもあります。クライアントの解析結果と設定内の実際のフィールドを確認してください。

項目確認する内容よくある誤解
システムアーキテクチャx64、ARM64、またはクライアントが対応するその他のアーキテクチャインストーラーの名前だけで選ぶ
設定の参照元対応形式、アクセス権、有効なアカウントWebページのURLをサブスクリプションURLだと思い込む
通信のプロキシ経由設定システムプロキシまたは仮想ネットワークインターフェースコアを起動すれば、すべてのアプリの通信が自動的に経由すると考える
元に戻すための準備元のプロキシ、DNS、その他のVPN設定問題が起きたら、すべてのネットワーク設定を一度にリセットする

状況を説明できる接続テストの基準を作る

初回のテストでは、他のプロキシクライアントを終了し、不要なVPNを一時的に切断して、元のシステムプロキシとDNS設定を記録します。設定をインポートしたらルールモードを選び、利用可能と分かっている接続先を手動で指定します。同じブラウザーで、直接接続できるサイトとプロキシが必要なサイトにアクセスし、接続ログも確認してください。2つのアクセス例で直接接続とプロキシ接続をそれぞれ検証すると、遅延の数値だけを見るより原因を判断しやすくなります。

システムプロキシは、OSのプロキシ設定に従うアプリ（ブラウザーなどのデスクトップアプリが代表例）に接続経路を提供します。TUNは仮想インターフェースとルーティングを使って、より広範なIP通信を受け取ります。管理者権限が必要になることがあり、DNSの横取りや他のVPNとの競合も起こり得ます。どちらも接続先を変更する機能ではなく、サーバー側の障害も解決できません。まずプロキシの出口を確認してから対象範囲を広げれば、出口の問題を仮想ネットワークアダプターの問題と取り違えにくくなります。

以下は、この端末での診断用に用意した最小構成です。プロキシノードは含まず、対応する通信を直接接続させます。YAMLを読み込めるか、待ち受けポートを作成できるかの確認には使えますが、海外プロキシへの接続テストには使えません。実際に使う場合はサービス提供元の設定を読み込み、ポートがクライアントによって上書きされていないか確認してください。現在の設定に同じ名前のトップレベルフィールドがある場合は、そのフィールドを編集します。ファイル末尾に同名の項目を重複して追加しないでください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

バックアップにはノード一覧だけでなく、通信のプロキシ経由設定や権限の状態も含めてください。この章の準備ができたら、使用するプラットフォームの章だけを確認します。5つすべてのプラットフォームのコマンドを実行する必要はありません。コア、プロキシグループ、fake-ipなどの用語を先に確認したい場合は用語集を参照し、画面上の項目と一つずつ照らし合わせてください。

Windowsのインストールと設定

インストーラーを選んで初回起動する

WindowsのダウンロードページからClash Plusを選びます。他の画面を使いたい場合は、Clash Verge Rev、FlClash、Clash Nyanpasuの順に比較してください。Clash for Windowsは開発が終了しているため、旧環境向けの選択肢として扱い、新しい端末には推奨しません。クライアントを切り替えるときは旧アプリを終了し、複数のプロセスが同時にシステムプロキシを変更したり、ローカルの待ち受けポートを使用したりしないようにしてください。

設定のシステム情報ページでシステムの種類を確認し、x64とARMデバイスを区別します。インストール時は識別しやすい保存先を選び、起動後にメインウィンドウとタスクトレイの両方が使えることを確認してください。セキュリティ警告が表示された場合は、ダウンロード元とリリース情報を確認し、OSに表示された具体的な説明に従ってください。アプリを起動するためにセキュリティ機能全体を無効にしないでください。組織が管理する端末では、インストールやサービス登録が制限されている場合もあるため、端末の管理ルールに従ってください。

初回起動時は、コアの動作状態と設定一覧を確認します。クライアントによっては、画面を起動した後に設定を選ぶまでコアが利用可能になりません。ウィンドウは表示されるのにログでポートの競合が続く場合は、他のプロキシアプリを終了し、古いプロセスがバックグラウンドに残っていないか確認してください。競合の原因が常駐サービスの場合、何度インストールし直しても解決しません。

サブスクリプションを追加してプロキシグループを確認する

設定またはサブスクリプションの管理画面を開き、リモート設定の追加を選んで、名前とサブスクリプションURLを入力して保存します。取得と解析が終わったら、この設定を手動で選択してください。追加に成功しても、自動的に切り替わるとは限りません。プロキシ画面にノードとプロキシグループが表示されることを確認し、実際にルールから参照されているグループで接続先を選びます。DIRECTなど組み込みの選択肢しか表示されない場合は、システムプロキシを有効にするのではなく、設定ログでサブスクリプションの内容を確認してください。

リモート更新に失敗したら、ダウンロードエラーと解析エラーを切り分けます。前者はURLの無効化、認証、アクセス経路が原因となることが多く、後者はWebページが返された場合、インデントの誤り、コアが未対応のフィールドなどが原因です。前の利用可能な設定を残し、すぐに削除して作り直すのは避けてください。クライアントにプロキシ経由で更新するオプションがある場合は、現在のプロキシが使えるときだけ試します。使える接続を確立しないと接続設定をダウンロードできない、という循環を避けるためです。

システムプロキシ、TUN、権限

まずシステムプロキシを有効にし、ブラウザーでルールモードを確認します。システムプロキシのアドレスは、実際に待ち受けているローカルポートを指定してください。このページの例にある7890がすべてのクライアントで共通とは限りません。Windowsの手動プロキシと自動構成スクリプトは別の設定です。古いスクリプトが残っていると、意図した設定が上書きされることがあります。クライアントのプロキシを無効にした後も、特に異常終了後は、システム設定が元に戻っていることを確認してください。

システムプロキシに従わないアプリの通信も経由させる必要がある場合は、クライアントがTUNに対応しているか確認します。通常、サービスのインストールや関連コンポーネントの起動に許可された昇格権限が必要です。サービスのインストールと、毎回の画面操作に管理者権限が必要かどうかは別の話です。まずクライアント標準のサービス管理機能を使い、案内に従ってコアを再起動してください。有効化後は仮想インターフェース、デフォルトルート、DNSのログを確認します。スイッチの色だけで通信が経由していると判断しないでください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

この設定例はmihomoのTUNパラメーターだけを示しており、サブスクリプション全体の代わりにはなりません。クライアントがこれらのフィールドを管理している場合があるため、ファイルを手動編集する前に画面から上書きされないか確認してください。auto-routeはルートを追加し、auto-detect-interfaceは出口インターフェースの検出に使います。dns-hijackは該当するDNS通信をコアに処理させます。有効化後に通信できなくなった場合は、まずTUNを無効にして元の状態に戻し、その後ルートとDNSを個別に確認してください。

Windows特有の問題と終了手順

ブラウザーでは接続できるのにコマンドラインでは失敗する場合、コマンドラインツールがシステムプロキシを参照していないことがあります。1回のリクエストにプロキシを明示して、アプリ側の対応状況とノードの問題を切り分けてください。以下のコマンドではWindows標準のcurl実行ファイルを使います。ポートは実際の待ち受けポートに置き換えてください。テスト先への接続だけで出口が正しいとは限らないため、ログでリクエストに適用されたプロキシグループも確認します。

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

スリープからの復帰後やWi-Fi・有線ネットワークの切り替え後は、出口インターフェースが変わる場合があります。システムプロキシは正常でTUNだけに問題がある場合は、まずコアを再起動してインターフェースを再検出し、他のVPN、仮想マシンのネットワーク、ファイアウォールルールを確認してください。終了時は通信のプロキシ経由設定を無効にし、システムプロキシが復元されたことを確認してからアプリを終了します。仮想ネットワークアダプターの削除やネットワーク全体のリセットは避けてください。影響範囲が広がり、原因調査に使える状態も失われます。

macOSのインストールと設定

チップのアーキテクチャとインストール形式を確認する

Appleメニューの「このMacについて」でチップ情報を確認します。Apple SiliconにはARM版、Intel搭載Macにはx64版を選びます。まずmacOSのダウンロードページからClash Plusを選んでください。他の選択肢にはClash Verge RevやFlClashがあります。ClashX Metaは開発が終了しています。以前の設定を確認する用途には使えますが、現在のすべての設定フィールドにコアが対応しているとは限りません。

ディスクイメージをダウンロードした場合は、開いてから配布元の説明に従い、アプリをアプリケーションフォルダに移動して起動します。イメージ上から直接使い続けると、更新、補助コンポーネントの参照、再起動後のパスに違いが生じることがあります。初回起動時にセキュリティ制限が表示された場合は、「プライバシーとセキュリティ」の該当項目を読み、入手元を確認してください。出所不明のターミナルコマンドでセキュリティ制限を一括解除しないでください。

デスクトップクライアントによってはメニューバーに常駐するため、ウィンドウを閉じてもコアが終了するとは限りません。設定を始める前にメニューバーとアクティビティモニタを確認し、他のプロキシがバックグラウンドで動いていないことを確かめてください。画面に設定が表示されない場合は、まず現在のユーザーにデータフォルダへのアクセス権があるか確認します。アプリケーションフォルダと設定フォルダを混同しないでください。端末を移行するときは、クライアントから設定をエクスポートするか指定フォルダをバックアップします。アプリ本体をコピーするだけでは不十分です。

サブスクリプションの追加と設定の保持

設定管理からリモートURLを追加し、取得が完了するまで待ってから現在の設定として選択します。ノード一覧とプロキシグループが表示されたら、接続先を選んでください。macOSクライアントのメニューバーにあるショートカットは、プロキシグループの切り替えだけを行い、設定の参照元は変更しないことがあります。ノードが変わらない場合は、同じグループを何度もクリックするのではなく、現在の設定名を確認してください。設定名は用途を区別できるものにし、同じ名前による選び間違いを防ぎましょう。

ローカルYAMLの相対パスは通常、クライアントの設定フォルダを基準にします。ダウンロードフォルダが基準とは限りません。設定からルールセット、証明書、その他のファイルを参照している場合は、コアが実際に読み取れることを確認してください。リモートサブスクリプションでは更新機能を維持し、独自フィールドはクライアントが対応するオーバーライド機能で管理します。更新のたびに最終的な設定のルール順を確認してください。ローカルで追加したルールがMATCHの後に置かれると、適用されないことがあります。

ネットワークサービスのプロキシと補助コンポーネント

まずシステムプロキシを有効にし、ブラウザーで接続を確認します。macOSのプロキシ設定はネットワークサービスごとに管理されます。Wi-Fi、有線アダプター、その他のネットワークサービスで設定が異なることがあります。接続方法を切り替えた後に急に使えなくなった場合は、現在有効なサービスが正しいローカルアドレスとポートを参照しているか確認してください。クライアント終了後もネットワークに問題が残る場合は、DNSを変更する前に、そのサービスのプロキシ設定を確認します。

以下の読み取り専用コマンドで、現在のシステムプロキシの概要を確認できます。有効状態、ホスト、ポートを確認してください。設定は変更されず、アプリごとのプロキシ動作も表示されません。概要とクライアント画面が一致しない場合は、まずシステムプロキシを一度オフにしてからオンにし、他のネットワークツールが設定を書き戻していないか確認します。組織が管理する構成プロファイルによって、設定がロックされている場合もあります。

scutil --proxy

TUNでは通常、仮想インターフェースやルートの操作を行うために、クライアントの特権ヘルパーが必要です。ヘルパーをインストールするときは、システムの認証画面を読み、使用中のクライアントからの要求であることを確認してください。認証に失敗した場合は、アプリのログで具体的なサービスエラーを確認します。パスワードを何度も入力するのは避けてください。学校や職場の端末ではネットワーク拡張やシステムサービスのインストールが制限される場合があります。その場合は許可された接続方法を使い、管理ポリシーを回避しようとしないでください。

スリープ復帰、LAN、アプリごとの差

スリープから復帰したら、ネットワークへの再認証が必要か、コアが認識している出口に変化がないか確認します。TUNだけが使えない場合は、サブスクリプションを再インポートせず、まずコアを再起動してください。プリンター、ネットワークストレージ、LAN内のサービスに問題がある場合は、通信がプロキシ経由になっているか、適用されたルールを確認します。使っているネットワークに必要な直接接続ルールを正確に追加し、判断せずにすべてのプライベートアドレスをリモートの出口へ送らないでください。

ターミナルのプログラムがプロキシを使うかどうかは、メニューバーのアイコンではなく、プログラム自体と環境変数で決まります。プロキシを明示した単発のテストを行い、その後ターミナルの環境を設定するか判断してください。使用を終えるときはTUNとシステムプロキシを無効にしてからクライアントを終了し、ネットワークサービスの設定が元に戻ったか確認します。アンインストール前に、不要な補助サービスをクライアントの機能で削除してください。アプリだけ削除すると、コンポーネントが動作したまま残る場合があります。

Androidのインストールと設定

入手元、アーキテクチャ、アップデート

AndroidのダウンロードページからClash Plusを選びます。Clash Meta for Android、FlClash、Surfboardも比較できます。アプリによって対応する設定形式や高度なフィールドが異なります。すべてのアプリでmihomoの完全なYAMLをそのまま使えるわけではありません。まず手持ちのサブスクリプション形式に対応するアプリを選び、その後に画面の使いやすさを比較すると、設定の変換やトラブル対処を減らせます。

最近のスマートフォンの多くはARM64を使いますが、古い端末、エミュレーター、特殊なOSでは異なる場合があります。判断できない場合は端末の仕様を確認するか、ダウンロードページの対応情報を参照してください。アプリパッケージをインストールする際は、使用するブラウザーやファイル管理アプリに必要な範囲でインストール権限を許可し、完了後に必要なら取り消せます。インストール済みアプリとの競合が表示された場合は、パッケージ名、署名、入手元を確認します。設定やローカルルールを失う可能性があるため、すぐに旧アプリを削除しないでください。

アップデート前に、サブスクリプションURL、プロキシグループの選択、アプリごとの設定を記録します。上書きアップデートでデータが保持されるかどうかは、アプリのIDと署名が一致するかによって変わります。アイコンや表示名だけで判断しないでください。クライアント間ではアプリ内の設定を完全に移行できないことが多く、同じサブスクリプションをインポートしても、VPNの許可、アプリの除外設定、バックグラウンド実行の権限を確認し直す必要があります。インポート前に旧クライアントの動作状態を保存してください。

設定のインポートとシステムVPNの許可

設定管理画面でサブスクリプションURLを追加し、ダウンロード完了後に設定を選択します。プロキシまたはプロキシグループの画面で接続先を確認してください。返された内容を解析できない場合は、まずクライアントが対応する形式を確認し、設定の提供元に対応方法を問い合わせます。アカウント情報を含むURLを、出所不明の変換サイトに入力しないでください。ダウンロード経路の確認にはオフラインファイルを使えますが、その後はリモートサブスクリプションの更新が反映されません。管理方法を明確にしておきましょう。

接続をタップすると、通常AndroidからVPN接続の作成許可を求められます。この許可でアプリがローカルの仮想インターフェースを作成できますが、従来型のVPNサービス事業者に接続するという意味ではありません。実際の出口は設定内のプロキシグループによって決まります。ステータスバーにVPNアイコンが表示されるのはインターフェースが作成されたことを示すだけです。Webページにアクセスし、接続ログも確認して、対象アプリの通信が意図した接続先を経由しているか確かめてください。

Androidでは通常、一般的なVPNサービスを同時に1つしか有効にできません。他のVPNアプリが現在のクライアントに置き換わることがあります。ローカルファイアウォール、通信フィルター、一部の通信最適化アプリも同じ仕組みを使う場合があります。接続直後に切断される場合は、ノードを変更する前に、それらのアプリとOSの「常時接続VPN」設定を確認してください。デスクトップのシステムプロキシの手順をスマートフォンにそのまま適用することはできません。通信を経由させる仕組みが異なります。

アプリごとのプロキシ設定とバックグラウンド動作

アプリごとの設定には、選択したアプリだけをプロキシ経由にする方法と、選択したアプリを除外する方法があります。意味が逆なので、設定前に現在のモードを確認し、まず1つのアプリでテストしてください。除外したアプリの通信はコアを通らないため、ログに接続が表示されなくても正常です。ルールが読み込まれていないとは限りません。アプリ一覧を変更した後は、VPNインターフェースの再作成が必要になることがあります。クライアントの案内に従って切断し、再接続してください。

画面点灯中は正常で、ロック後に接続が切れる場合は、バッテリー最適化、バックグラウンド動作の制限、メーカー独自の自動起動管理を確認します。使用中のクライアントに必要な権限だけを許可し、問題が解消するか確認してください。すべてのアプリの制限を一括で緩和する必要はありません。省電力モード、長時間の待機、メモリ不足によりサービスが終了するOSもあります。切断時刻とシステムの状態を照らし合わせ、接続先の不安定さだけが原因だと決めつけないでください。

モバイル通信、DNS、テザリングの範囲

Wi-Fiからモバイルデータに切り替えると、ネットワークアドレスやルートが変わり、既存の接続が切れることがあります。まず少し待って再接続を確認し、クライアントがネットワークを認識し直したか調べてください。特定のネットワークだけで使えない場合は、ネットワーク認証、DNSへの到達性、プロキシサーバーへの到達性を切り分けます。空港やホテルなど、Webページでログインするネットワークでは、プロキシを使う前に認証が必要な場合があります。認証前はすべてのノードが使えないように見えることがあります。

OSのプライベートDNS、アプリ独自のセキュアDNS、クライアントのDNSが同時に存在する場合があります。スイッチを1つ変更しただけで、名前解決経路が統一されたと判断しないでください。クライアントのログとテスト結果を照合し、どの機能がドメインを処理しているか確認します。検査ページに表示された名前解決の地域だけで、DNS漏えいと判断しないでください。プロキシサーバーのネットワーク、再帰リゾルバーの出口、検査ページの判定方法が表示結果に影響することがあります。

常用する前に、画面ロック後に接続が復帰するか、ネットワーク切り替え後に手動で再接続が必要か、除外したアプリが想定どおり直接接続するかの3点を確認します。通常のルールモード設定を基準として残してください。問題が起きたら、まずアプリごとの設定など追加オプションを無効にし、一つずつ戻します。これにより、原因が基本接続、OSのバックグラウンド制限、アプリ選択ルールのどれか判断しやすくなります。

iOSのインストールと設定

App Storeからのインストールと機能の範囲

iPhoneとiPadではClash Plusをおすすめします。App StoreのClash Plusページからインストールし、公式サイトのclashplus.ioで製品情報を確認できます。ダウンロード先はiOSのプラットフォームページにもまとめています。インストール前にApp Storeのシステム要件を読み、実際に表示される端末情報を確認してください。クライアント名から対応範囲を推測しないでください。

iOSアプリはシステムのネットワーク拡張機能とサンドボックスの制約を受けるため、デスクトップクライアントとは操作方法が異なります。このページでは設定、プロキシグループ、接続などの機能名を使って説明します。実際のボタン名はアプリの画面で確認してください。デスクトップの設定にmihomoのフィールドがあっても、スマートフォンアプリが同じフィールドを解釈できるとは限りません。インポート結果、アプリの説明、実際の接続動作を基準に判断してください。デスクトップ用TUN設定をそのまま貼り付けて、スマートフォンの接続設定の代わりにしないでください。

サブスクリプションの追加、選択、更新

アプリに対応したサブスクリプションURLを用意し、設定管理からリンクで追加を選びます。見分けやすい名前を付けて保存してください。取得が完了したら設定を選択し、想定したプロキシグループと接続先が表示されるか確認します。ファイルからのインポートに対応している場合も、文字コードと形式が正しいことを確認してください。チャットアプリからコピーすると改行が失われる場合があります。アカウント情報を含むURLを公開メモに保存したり、グループチャットに送ったりしないでください。

インポートの成功と、現在の設定への適用は別です。追加後に現在選択されている設定を確認し、プロキシグループが利用可能な接続先を選んでいるか確認してください。ノード一覧だけのサブスクリプションでは、アプリ対応のルールや設定テンプレートが別途必要な場合があります。ルールがないという案内が出た場合は、アプリの説明に従ってください。他のクライアントの設定ファイル全体をそのまま結合するのは避けましょう。同じ設定を何度もインポートしても、未対応フィールドは解決せず、同名の設定が増えて選びにくくなります。

サブスクリプションを更新するときは、以前の利用可能な設定を残し、まず取得の成否を確認してからノードやプロキシグループに変化があるか調べます。接続中だけ更新できる場合は、更新リクエストの経路を確認してください。現在使える接続先がない場合は、設定を取得できるネットワークで先に更新する必要があります。手動変更は次回の更新で置き換わることがあります。独自設定を継続する場合は、アプリが明示的に対応する保存方法を使い、更新後にもう一度確認してください。

接続の許可と通信を経由する範囲

初回接続時、システムからVPN構成の追加を求められ、端末認証が必要になる場合があります。許可したらアプリに戻って接続を開始し、システムの状態とアプリのログを確認してください。VPNアイコンはネットワーク拡張が動作していることを示すだけで、ノードに接続できたことや、すべてのアプリの通信が同じ方法で処理されることを保証しません。直接接続用とプロキシ接続用のアクセス先を用意して動作を確認し、プロキシグループの選択も照合してください。スイッチの状態だけで判断しないでください。

iOSには、デスクトップとまったく同じシステム全体のHTTPプロキシ切り替え機能はありません。Wi-Fiの詳細画面にあるHTTPプロキシは、そのWi-Fiネットワーク固有の設定です。アプリのトンネル接続はネットワーク拡張が担うため、両者を混同しないでください。通常はアプリ内の接続手順を使います。Wi-Fiの手動プロキシも使う場合は、用途を記録し、プロキシの二重適用やアプリ終了後もアクセスに影響が残る問題がないか確認してください。

端末上の別のVPN、ネットワークフィルター、管理対象のネットワーク設定が現在の接続と競合することがあります。接続をタップしてすぐ切断される場合は、システムで別の設定が有効になっていないか確認し、アプリに表示された失敗理由を読んでください。職場や学校の端末では管理ルールに従ってネットワークを使用します。出所不明の構成プロファイルを削除して試すのは避けてください。設定の入手元と用途を把握している場合に限り、状態を変更してください。

ネットワーク切り替え、名前解決、復旧

Wi-Fiとモバイルデータを切り替えると、既存の接続を再確立する必要が生じる場合があります。まずアプリにモバイルデータの使用権限があるか確認し、同じ接続先で2種類のネットワークを比較します。Wi-Fiだけで失敗する場合はWeb認証が必要か確認し、モバイルデータだけで失敗する場合は通信権限とサーバーアドレスへの到達性を確認してください。1回のテストで接続先、モード、DNSを同時に変更すると、復旧しても原因が分からなくなります。

Webページに表示される出口情報は、リクエストの経路を踏まえて確認してください。iCloudプライベートリレーは、対応条件下でSafariの一部通信に影響することがあります。アプリ独自の名前解決や接続ルールも、確認結果に影響します。トラブル対処では各機能の元の状態を記録し、可能な範囲で一度に1つだけ変更して比較した後、元に戻してください。ブラウザー1つの結果を端末上のすべてのアプリに当てはめたり、DNSリクエストの全経路を判断したりすることはできません。

画面ロック後に切断される場合は、ネットワークの変化、接続先のタイムアウト、ネットワーク拡張の再起動を切り分けます。アプリを再び開いたとき自動復旧するか確認し、ログの時刻も照合してください。アプリの強制終了を日常的な接続維持策にしないでください。通常の接続に戻すときはアプリ内で切断し、システムのVPN状態とWi-Fiプロキシを確認します。古い設定を削除する場合は、システム設定で名前と入手元を確認し、他の業務に必要なネットワーク設定を誤って削除しないようにしてください。

Linuxのインストールと設定

GUIクライアントと独立したコア

Linuxデスクトップでは、まずダウンロードページからClash Verge Revを選びます。FlClashも利用できます。ディストリビューションのパッケージ管理方式、プロセッサのアーキテクチャ、デスクトップ環境を確認してから、適切なインストール形式を選んでください。mihomoコア単体は、サーバーやルーター、自分でサービスを管理したいユーザーに適しています。デスクトップ向けの設定画面は含まれないため、インストール後に設定、プロセス管理、ログ確認の方法を用意する必要があります。

DEBとRPMは汎用のアーカイブではなく、対応しないディストリビューション間で相互に使うことはできません。GUIアプリにはデスクトップ環境やランタイムライブラリも必要です。インストールに失敗した場合は、パッケージ管理ツールが示す依存関係の問題を確認し、ファイルの権限をむやみに変更しないでください。OSのパッケージ管理ツールからローカルパッケージをインストールすれば、依存関係とアンインストール情報を管理できます。依存関係のエラーを避けるために、デスクトップアプリ全体をrootで実行しないでください。

以下は、よく使われるローカルパッケージのインストールコマンドです。ファイル名は操作例であり、実際のダウンロード先ではありません。実行前にパスをダウンロード済みの該当ファイルに置き換え、現在のシステムに適合することを確認してください。インストール後はアプリメニューから起動し、トレイの表示、設定の読み込み、コアの起動を確認します。ウィンドウが表示されてもGUI層の動作を確認できただけで、プロキシの待ち受けやネットワーク権限が使えるとは限りません。

sudo apt install ./client.deb
sudo dnf install ./client.rpm

サブスクリプションの追加とデスクトッププロキシの違い

GUIクライアントでのサブスクリプション設定は、他のデスクトッププラットフォームと同様です。リモート設定を追加し、解析を待って設定を選び、プロキシグループで接続先を指定します。Linuxデスクトップ環境ではシステムプロキシの保存や参照方法が異なります。環境変数だけを見るアプリもあれば、デスクトップ設定やアプリ独自の設定を使うものもあります。システムプロキシを有効にした後、ブラウザーでは接続できてもターミナルで失敗することがあります。直ちにコアの問題と判断せず、ターミナルのツールが実際にどの経路を使っているか確認してください。

まず単一のリクエストにローカルプロキシを指定すれば、セッション全体の環境変数をすぐに変更する必要はありません。以下ではHTTPとSOCKSの入口をそれぞれテストします。SOCKS側ではホスト名を指定する形式により、curlが接続先のドメイン名をSOCKS側に渡します。ポートは現在の設定に合わせてください。接続が拒否された場合は、リモートノードを調べる前に、コアが動作しているか、正しいアドレスで待ち受けているか確認します。

curl --proxy http://127.0.0.1:7890 --head https://example.com
curl --proxy socks5h://127.0.0.1:7890 --head https://example.com
ss -lntp

環境変数を設定する場合は、まず現在のターミナルで一時的にテストし、大文字小文字の違いやアプリごとの対応を確認します。NO_PROXYの除外リストにより、一部のリクエストがプロキシを迂回する場合があります。sudoが環境変数を削除することもあります。トラブル対処では実際の実行環境を記録してください。通常ユーザーでのテストに成功しても、システムサービスやコンテナ内のプログラムが同じ設定を引き継ぐとは限りません。

独立したコアの設定とサービス権限

独立したコア用にデータフォルダを用意し、設定と必要なデータファイルを配置します。最初はフォアグラウンドで実行してログを読み、設定が正しいことを確認してからバックグラウンドサービスを作成してください。最初からログを非表示にして自動再起動を設定すると、構文エラーがプロセスの再起動ループとして現れることがあります。以下のコマンドは実行ファイルがインストール済みで、設定フォルダが存在することを前提としています。実際の環境に合わせてパスを変更してください。

mihomo -t -d "$HOME/.config/mihomo"
mihomo -d "$HOME/.config/mihomo"

-tは設定のテストに使い、構文や参照先の問題を見つけるのに役立ちます。ただし、テストに成功してもサーバーへの到達性やルーティングが正しいとは限りません。バックグラウンドサービスでは、作業ディレクトリ、実行ユーザー、ファイル権限も明確にしてください。認証情報を含む設定を読み込む場合は、アクセス範囲を制限します。別のユーザーが設定を作成した場合は、サービスアカウントが必要なファイルを読めるか確認してください。問題を解決するためにフォルダ全体の権限を開放しないでください。

TUN、DNS、ディストリビューションごとの差

LinuxのTUNは仮想デバイスとネットワーク管理の権限を必要とします。GUIクライアントでは、まずクライアント標準のサービスインストール機能を使ってください。独立した環境では、サービス管理の方法に従って必要な権限を付与します。すべてのプログラムを常に権限昇格して実行しないでください。コンテナや制限付きホストでは、仮想デバイスへのアクセス自体ができない場合があります。YAMLを変更するだけで環境上の制約を回避することはできません。先にホスト環境が対応しているか確認してから、コアの設定を調べてください。

システムではNetworkManager、systemd-resolved、その他の名前解決コンポーネントが使われている場合があります。/etc/resolv.confを直接編集すると、ネットワークサービスに上書きされたり、元のシンボリックリンクを壊したりする可能性があります。まず管理元を確認してから、DNSをコアに渡す方法を決めてください。TUNを有効にした後、IPアドレスへの通信は成功するのにドメイン名で失敗する場合は、DNSの入口、53番ポートの処理、上流DNSへの到達性を重点的に確認します。ノードのプロトコルをすぐに変更しないでください。

ローカルプロキシがコンテナ、仮想マシン、LAN上の別端末の通信まで自動的に経由させるわけではありません。それぞれ独立したネットワーク名前空間、ゲートウェイ、ファイアウォール経路を持つため、個別に転送方法を設計する必要があります。サービスを停止するときは、自動ルートが削除されたこと、デスクトップのプロキシとターミナルの環境変数が復元されたことを確認してください。リモートサーバーでデフォルトルートを変更する前に、別の管理経路を確保します。未検証のプロキシ経路に現在の管理接続まで流してしまうのを防ぐためです。

設定のよくある質問と段階的なトラブル対処

設定を読み込めるのに、インターネットに接続できないのはなぜ？

設定の取得、コアの動作、ローカルの待ち受け、アプリの通信経由設定、DNS名前解決、ルール適用、リモート接続の順に確認してください。各段階で検証するのは1つの問題だけにします。設定の解析に成功したか、ポートが待ち受けているか、対象アプリの接続ログがあるか、どのプロキシグループが適用されたか、リモート接続のハンドシェイクが完了したかを確認します。最初に失敗した段階を特定してから該当する設定を変更すると、サブスクリプションとネットワークモードを同時に変えるより、安定した結論を得やすくなります。

解析エラーが出た場合は、行番号と前後の内容を確認します。YAMLの階層はスペースで表すため、インデントにタブは使えません。同じマッピング内でdns、tun、rulesを重複して定義しないでください。特殊文字を含む文字列は正しく引用します。クライアント内の元のサブスクリプション、オーバーライドの断片、最終的な設定は別のデータである可能性があります。変更前に現在編集している対象を確認してください。保存に成功しても、コアが実際に読み込むファイルへ反映されない場合があります。

ルールモード、グローバルモード、プロキシグループの参照

ルールモードでは、リストの順番にルールを照合し、通常は最初に一致した時点で処理を終えます。グローバルモードでは、通信を経由させた接続をグローバルのプロキシグループに渡しますが、もともとコアを通らないアプリの通信まで自動的に取り込みません。直接接続モードも、クライアントや仮想ネットワークアダプターを停止する機能ではありません。モードを診断の変数として使います。グローバルモードで動作してルールモードで失敗する場合は、適用されたルールとプロキシグループを確認します。両方で失敗する場合は、まず出口と通信を経由させる設定を確認してください。

以下の例では、指定したドメインのサフィックスだけを手動選択用グループに送り、それ以外は直接接続します。選択グループには一時的にDIRECTしかないため、これはルール構造の例であり、リモートプロキシは提供しません。実際の設定では、既存のノードやサブスクリプションの接続先をグループに追加してください。ルールで参照するプロキシグループ名は、グループの定義名と一致させる必要があります。名前が異なると、読み込みに失敗したり意図しない動作になったりします。ルールの並べ方は国内・海外の通信を振り分けるルールの実践例も参照してください。

proxy-groups:
  - name: SELECT
    type: select
    proxies:
      - DIRECT
rules:
  - DOMAIN-SUFFIX,example.com,SELECT
  - MATCH,DIRECT

DNS、fake-ip、通信を経由させる範囲

DNSはドメイン名とアドレスを対応付け、プロキシは接続を確立します。連携はしますが、同じ層の機能ではありません。fake-ipは対応関係を保持するための仮想アドレスを返し、後続の接続でコアがドメイン名としての情報を復元します。接続先のWebサイトが実際にそのアドレスを使うという意味ではありません。アプリに古いキャッシュが残っている場合、コアを経由せずに名前解決する場合、アプリ独自の暗号化DNSを使う場合は、ルールから見える情報が異なることがあります。接続メタデータも含めて判断してください。

以下はmihomoのDNS設定の一部を示す例で、待ち受け先はローカルに限定しています。この設定だけでOSのDNS設定が自動的に変わるわけではなく、外部DNSへの問い合わせをすべて防げるわけでもありません。TUNによるDNSの横取りが処理するのは、主に対象となる従来型DNS通信です。アプリ独自の暗号化DNSは、ルーティングやアプリ設定と合わせて確認する必要があります。上流DNSに現在のネットワークから到達できないと、すべてのドメインが解決できなくなることがあります。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

名前解決モードを変更した後も、古いキャッシュの影響がしばらく残ることがあります。まずクライアントが対応する方法でDNSキャッシュを消去し、テストするアプリの接続を作り直して結果を比較してください。影響を受けるドメインに必要な例外だけを設定し、1つのアプリの問題を解決するためにすべてのルールを無効にしないでください。検査手順と結果の見方はDNS漏えいの検査と対処を、仮想インターフェースの設定はTUNモードの設定ガイドを参照してください。

確認できる現象優先して確認する項目比較テスト
アプリの接続ログがない通信を経由させる入口と除外リストローカルプロキシを明示して指定
ローカルポートへの接続が拒否されるコアの状態、ポートの競合実際の待ち受けアドレスを確認
ドメイン名では失敗するが、IPアドレスには接続できるDNSとキャッシュ名前解決エラーと上流DNSの状態を確認
グローバルモードは正常だが、ルールモードで失敗する適用されたルールとプロキシグループドメイン名を1つに絞って再現し、ログを確認
TUN使用時だけ問題が起きる権限、ルート、インターフェースの競合システムプロキシでの基本状態に戻す

状況を記録し、利用可能な状態に戻す

ログには発生時刻、対象アプリ、ネットワークの種類、モード、適用ルール、エラーの概要を残し、サブスクリプションURL、サーバー認証情報、個人のアクセス履歴は削除してください。調査中に一時的にログレベルを上げると手がかりを得られます。テスト後は通常のレベルに戻し、情報が不要に蓄積しないようにしてください。ノードの遅延テストで確認できるのは特定のプローブ通信だけです。実際のWebサイトへのアクセスの代わりにはならず、UDP、長時間接続、すべての接続先が正常だと証明するものでもありません。

直近の更新後に問題が起きた場合は、まず前の利用可能な設定に戻し、プロキシグループ名、ルールセット、上流DNS、クライアントのオーバーライドなどの変更点を一つずつ比較します。ルールセットのダウンロード失敗とノードへの接続失敗は別の問題です。GeoIPやGeoSiteのデータも独立した更新の仕組みを持っています。詳しくはデータベースの更新とルールでの参照方法を確認してください。エラーの起きた段階を見極める代わりに、何度も再インストールしないでください。

最初からやり直す場合は、まずクライアントによる通信の経由設定を解除し、システムプロキシと元のDNS設定を復元して、通常のネットワークが使えることを確認します。その後、保存した設定のコピーをインポートしてください。初回の接続手順はチュートリアルで順に確認できます。モードの違いはルール・グローバル・直接接続モードの比較を参照してください。このガイドの例はパラメーターと診断範囲を説明するもので、実際に接続できる設定の代わりにはなりません。