Clash 全プラットフォームインストール・設定ガイド

共通の準備とクライアントの選び方

クライアント、コア、サブスクリプションを区別する

Clashの日常利用には、互いに独立した3つの要素があります。クライアントはウィンドウやメニュー、切り替えボタンを備えたGUIで、設定の追加、プロキシモードの切り替え、システム権限の管理を担当します。Mihomoなどのコアは設定の解析、接続の確立、ルールによる振り分けを担当します。サブスクリプションはサービス提供元が発行する設定の入口で、通常はプロキシノード、プロキシグループ、ルール、DNSパラメーターが含まれます。クライアントをインストールしても利用可能なサブスクリプションが自動生成されるわけではなく、サブスクリプションだけでローカルクライアントの代わりにはなりません。問題が起きたら、まずどの層に属するかを判断すると、不要な再インストールを避けられます。

当サイトのダウンロードページでは、プラットフォーム別にクライアントを掲載しています。一般的なデスクトップとモバイル端末では、まずClash Plusを選ぶとよいでしょう。WindowsとmacOSではClash Verge Rev、FlClashも選択でき、WindowsにはClash Nyanpasuとメンテナンス終了済みのClash for Windows、macOSにはメンテナンス終了済みのClashX Metaもあります。AndroidではClash Meta for Android、FlClash、Surfboard、Linuxでは主にClash Verge RevまたはFlClashを利用します。サーバー、ソフトウェアルーター、自分でサービスを構成する場合はMihomoコアをダウンロードできます。GUIクライアントと単体コアでは設定方法が異なるため、コアの圧縮ファイルをデスクトップ用インストーラーとして扱わないでください。

システムアーキテクチャとインストール権限を確認する

ダウンロード前にOSのバージョンとプロセッサーのアーキテクチャを確認します。Windowsの一般的なPCはx64を使用し、Windows on ARMの端末だけARM64版が必要です。Appleチップ搭載MacはApple SiliconまたはARM64ビルド、旧来のIntel Macはx64ビルドを選びます。Androidのインストールパッケージはarm64、arm、汎用版に分かれる場合があり、近年のスマートフォンやタブレットの多くはarm64です。確認できない場合は、ダウンロードページで汎用版と明記されたものを優先してください。Linuxはアーキテクチャに加えてパッケージ形式も確認します。Debian、Ubuntuとその派生版は通常deb、Fedora、Rocky Linuxなどはrpmを使用し、コアの圧縮版ではサービスを手動で設定する必要があります。

インストールやプロキシの有効化では、システム権限を求められることがあります。デスクトップ版のシステムプロキシは通常、システムのネットワーク設定を変更するだけです。TUNモードでは仮想ネットワークインターフェースを作成するため、管理者権限が必要になることがあります。AndroidとiOSにはVPN接続の許可画面が表示されます。これはローカル通信を取り込むためのシステム共通インターフェースであり、従来型の企業VPNへの接続を意味するものではありません。権限ダイアログで拒否すると、クライアント上では設定済みに見えても、実際のアプリ通信はプロキシを経由しません。その場合はサブスクリプションを再追加するのではなく、システム設定でVPN、ネットワーク拡張、バックグラウンド実行の権限を復元してください。

復旧に必要な最小条件を保存する

変更を始める前に、正常に動作している設定のコピーを残し、サブスクリプションのURLを控え、端末の日時、タイムゾーン、ネットワーク接続が正常であることを確認してください。システム時刻のずれはHTTPS証明書の検証に影響し、サブスクリプション更新の失敗、Webサイトの証明書エラー、ノードのハンドシェイク失敗として現れます。公共Wi-Fiでは、ブラウザーで先に認証を完了しなければならない場合があります。認証前にグローバルプロキシを有効にすると、認証ページが表示されないことがあります。最も確実なのは、まずシステムプロキシとTUNを無効にして通常のネットワークにアクセスできることを確認し、その後設定を追加して一つずつ有効にする手順です。

初回設定は、変更要素を最小限にするのが基本です。まずデフォルトのルールモードを使い、確実に有効なサブスクリプションを1つだけ追加します。システムプロキシを有効にしてブラウザーをテストし、必要に応じてTUN、DNSの上書き、カスタムルールを追加してください。プロキシモード、DNS、ポート、ルールファイルを同時に変更すると、原因の特定が難しくなります。簡単な手順はClashの使い方ガイドを、プラットフォーム別のインストール詳細と復旧方法は本ガイドの後続章を参照してください。

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

ダウンロードして初回インストールを完了する

Windowsダウンロードからクライアントを選びます。IntelまたはAMDプロセッサー搭載PCの多くはx64インストーラーを使用します。インストール前に旧クライアントを終了し、旧プロセスがmixed-portや仮想ネットワークアダプターを占有しないようにしてください。Clash for Windowsから移行する場合、別のクライアントをそのまま上書きインストールすることはおすすめしません。先にサブスクリプションURL、カスタムルール、バイパスリストを控え、旧クライアントのシステムプロキシを解除してから、Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuをインストールします。クライアントごとにデータディレクトリや拡張フィールドが完全には一致しないため、旧ディレクトリ全体をコピーすると、期限切れのキャッシュや補助サービスまで引き継ぐおそれがあります。

インストーラーがシステムにブロックされた場合は、当サイトの該当ダウンロード入口から取得したファイルか、拡張子が完全かを確認し、Windowsのセキュリティ警告で発行元とファイルの入手元を確認してください。企業や学校が管理する端末では、ドライバーのインストール、サービスの作成、プロキシ設定の変更が制限されている場合があります。この制限は端末管理者が対応する必要があります。ポータブル版は通常そのまま解凍して実行できますが、TUNサービスでは管理者権限が必要になることがあります。設定更新時のロックを避けるため、保存先は一般的なローカルフォルダーとし、同期ソフトが管理するフォルダーは避けてください。

サブスクリプションを追加して設定を有効化する

クライアントを開き、設定、サブスクリプション、Profilesなどのページで、URLから追加する項目を選びます。完全なサブスクリプションURLを入力欄に貼り付けて更新してください。ダウンロードに成功しても有効化済みとは限らず、通常は追加した設定をクリックして現在の設定にする必要があります。その後、プロキシグループで手動選択が必要なグループのノードを指定するか、自動選択を利用します。設定名だけが表示され、プロキシグループがない場合は更新結果とログを確認してください。サブスクリプションがログインページ、HTMLエラーページ、空の内容を返している場合、クライアントはYAML設定として解析できません。

サブスクリプションの更新間隔は短くしすぎないでください。更新では設定を再取得し、クライアントによってはコアも再読み込みします。頻繁に更新してもノード品質は向上せず、サービス側のアクセス制限を受ける可能性があります。日常利用ではサービス提供元の推奨値に設定し、すぐに同期したいときだけ手動更新してください。更新失敗時のネットワーク、リンク、サーバー側の確認方法はClashのサブスクリプション更新失敗のトラブル対応で解説しています。

システムプロキシの適用範囲

「システムプロキシ」を有効にすると、ClashはWindowsのHTTPおよびHTTPSプロキシをローカルの待受ポートへ向けます。システムプロキシ設定に従うブラウザーやデスクトップアプリは自動的に接続しますが、独自のネットワークスタックを使うアプリ、一部のストアアプリ、ゲーム、コマンドラインツールは設定を無視することがあります。この場合、ノードが必ず無効なのではなく、該当プログラムが通信をClashへ渡していません。ブラウザーはアクセスできるのに特定のアプリだけが直接接続する場合は、典型的にこの状態です。

システムプロキシを有効にした状態で突然の電源断や強制終了が起きると、ローカルポートを指すプロキシ設定が残ることがあります。クライアント終了後、すべてのWebページにアクセスできなくなるのが典型的な症状です。復旧するには、クライアントを再度開いてシステムプロキシを正常に無効化するか、Windowsの「ネットワークとインターネット—プロキシ」で手動プロキシをオフにします。クライアント動作中に複数のプロキシソフトでシステムプロキシを同時に管理しないでください。後から起動したソフトがアドレスを上書きし、終了順によっては古い値に戻ることがあります。

TUNモードと仮想ネットワークアダプター

TUNモードは仮想ネットワークアダプターでより多くの種類の通信を受け取るため、システムプロキシに従わないアプリに適しています。初回有効化時は、クライアントによる関連サービスのインストールまたは起動を許可し、管理者権限の要求を承認してください。有効化後は、まずデフォルトのルートとDNSでテストし、第三者の高速化ツール、仮想マシンブリッジ、パケットキャプチャードライバー、別のVPNをすぐに重ねないでください。複数のネットワークフィルタードライバーが同時に動くと、ドメインを解決できない、LAN機器に到達できない、スリープ復帰後に通信できないといった症状が起きやすくなります。

TUNの起動に失敗した場合は、まずクライアントを終了し、管理者として一度実行してサービスが正常に作成されたか確認します。次に、Hyper-V、WSL、Docker、セキュリティソフトが作成した仮想ネットワークアダプターによってデフォルトルートが占有されていないか確認してください。TUNは使えるのにLANプリンターやNASへ接続できない場合は、LANのアドレス範囲を直接接続のままにし、厳格なルーティングが有効になっていないか確認します。家庭内ネットワークでよく使われるプライベートアドレスには192.168.0.0/16、10.0.0.0/8、172.16.0.0/12がありますが、実際のルールは現在のLANアドレス設定に合わせてください。

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,PROXY

Windowsで設定が完了したら、通常のブラウザー、TUNが必要なアプリ、LANアクセスの順に確認します。システムプロキシだけで動作する場合は、そのまま維持してください。UDP、ストアアプリ、ゲームの通信を取り込む必要がある場合に限り、TUNを有効にします。これにより仮想ネットワークアダプターとシステムのセキュリティポリシーの衝突を減らし、問題発生時も通常のネットワークへ戻しやすくなります。

macOSのインストール、ネットワーク拡張、権限設定

チップに合うインストーラーを選ぶ

macOSダウンロードを開き、「このMacについて」でチップを確認します。Apple Mシリーズチップと表示される端末はApple SiliconまたはARM64ビルド、Intelプロセッサーと表示される端末はx64ビルドを選びます。Clash Plusを第一候補とし、Clash Verge RevやFlClashも利用できます。ClashX Metaはメンテナンスが終了しているため、既存環境からの移行時の参考にはなりますが、新しい端末での第一選択にはおすすめしません。ダウンロード後は通常、アプリを「アプリケーション」フォルダーへ移動してから起動します。これにより権限や更新状態をシステムが正しく保存できます。

初回起動時にmacOSのセキュリティ機能でブロックされた場合は、「システム設定—プライバシーとセキュリティ」でブロックされたアプリを確認し、入手元を確認したうえで開くことを許可します。一度の警告を回避するために、システムのセキュリティ属性をすべて削除したり、保護機能を長期間無効にしたりしないでください。アプリをダウンロードフォルダーや読み取り専用のディスクイメージから直接実行すると、補助サービスやネットワーク拡張を正しくインストールできない場合があります。まずアプリを「アプリケーション」へコピーし、旧インスタンスを終了してから再起動してください。

サブスクリプション、メニューバー、現在の設定

macOSクライアントは通常、メインウィンドウとメニューバーの入口を備えています。サブスクリプションを追加するには、Profiles、設定、サブスクリプションのページでURLから新しい設定を作成し、更新します。更新後にその設定を選択し、プロキシグループでポリシーを確認してください。メニューバーのアイコンが動作中を示していても、システムプロキシが有効とは限りません。クライアントのシステムプロキシスイッチとmacOSのネットワーク設定を個別に確認します。複数のクライアントを残す場合は、ログイン時に起動するクライアントも、システムプロキシを管理するクライアントも1つだけにしてください。

設定の保存先は、ユーザーライブラリ内のディレクトリにある場合があります。端末を移行するときは、まずサブスクリプションを再追加し、明示的に記述したルールの上書きファイルだけを移行してください。キャッシュ全体をコピーすると、古いコアのパス、補助サービスの状態、適用できないネットワークインターフェース名まで持ち込むおそれがあります。サブスクリプションにサービス提供元独自のフィールドが含まれる場合は、手動で設定を組み立てるより、クライアントの通常のインポート手順を使う方が安定します。

システムプロキシとネットワークサービス

システムプロキシを有効にすると、クライアントは現在のネットワークサービスのWebプロキシとセキュアWebプロキシを変更します。MacでWi-Fiから有線ネットワーク、テザリング、新しいネットワークロケーションへ切り替えると、新しいネットワークサービスに独自のプロキシ設定が作られる場合があるため、再確認が必要です。クライアント終了後にSafariや他のアプリがインターネットへ接続できない場合は、「システム設定—ネットワーク—現在の接続—詳細—プロキシ」でHTTP、HTTPS、SOCKSプロキシがローカルアドレスを指していないか確認します。クライアントのシステムプロキシを正常に無効化すれば、通常はこれらの値も自動的に削除されます。

一部のコマンドラインプログラムは、macOSのGUIにあるシステムプロキシを読み取りません。ターミナルのコマンドで一時的にローカルプロキシを使う場合は、現在のターミナルセッションで環境変数を設定します。ポートはクライアントの実際のmixed-portまたはHTTPポートと一致させ、コマンドの実行後に解除してください。そうしないと、後から終了済みのローカルポートへ接続しようとします。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

# 現在のターミナルで操作後に削除
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

TUN、ネットワーク拡張、補助サービス

TUNモードを初めて有効にすると、macOSは管理者パスワードの入力を求め、VPN構成、ネットワーク拡張、補助ツールの追加を通知する場合があります。システムダイアログで該当する権限を許可してください。有効化してもすぐ元に戻る場合は、「プライバシーとセキュリティ」「ネットワーク—VPNとフィルタ」で拡張機能が無効になっていないか確認し、クライアントを完全に終了して再起動します。クライアントのアップグレードや変更後に旧補助サービスが動作していると、新しいサービスのインストールに失敗することがあります。まず旧クライアントのアンインストール機能でサービスを削除してから、新しいクライアントをインストールしてください。未知のシステムディレクトリを手動で削除するのは避けます。

TUNを有効にした後、AirDrop、プリンター、LAN共有、開発用デバイスへ接続できなくなった場合、LAN通信が誤って取り込まれている可能性があります。まずTUNだけを無効にし、システムプロキシだけで復旧するか確認します。復旧したら、設定のプライベートアドレス範囲への直接接続ルール、ルートの自動検出、DNSハイジャックの範囲を確認してください。macOSのiCloud Private Relay、他のVPN、コンテンツフィルター、企業向けセキュリティソフトも通信経路に関与する場合があります。トラブル対応では、Clashによる通信の取り込み方法を一度に1つだけ残してください。

macOSで重要なのは、何度も再インストールすることではなく、アプリのアーキテクチャ、現在のネットワークサービス、ネットワーク拡張の状態が一致しているか確認することです。ブラウザーは使えるのにターミナルだけ使えない場合は環境変数を確認し、システムプロキシは使えるのに特定のアプリだけ使えない場合はTUNを検討します。TUN有効化後にLANで問題が起きたら、ルールとルーティング範囲に戻って項目ごとに絞り込んでください。

Androidのインストール、VPN許可、バックグラウンド維持

インストーラーを選び、インストールを許可する

Androidダウンロードでは、Clash Plus、Clash Meta for Android、FlClash、Surfboardを選択できます。近年の端末の多くはarm64パッケージを使用し、古い端末ではarmの場合があります。確認できない場合は、クライアントが提供する汎用ビルドを利用してください。ダウンロード後は、システムのインストーラーでAPKを開きます。Androidは入手元ごとに「不明なアプリのインストール」権限を管理するため、現在使うブラウザーやファイルマネージャーだけ一時的に許可すれば十分です。インストール後はその入手元の権限をオフにでき、すべてのアプリで一括して有効にする必要はありません。

システムがインストールパッケージを解析できないと表示した場合は、ファイルが完全にダウンロードされ、拡張子がAPKのままであることを確認し、Androidのバージョンとプロセッサーのアーキテクチャも確認します。既存アプリと署名が一致しないと表示される場合、通常は端末に別の入手元で署名された同名アプリが存在します。まずサブスクリプションとカスタムルールを保存または記録し、旧アプリをアンインストールしてから再インストールしてください。署名の違いは上書きインストールでは解消できません。メーカー独自のシステムでは、インストール確認がセキュリティスキャン画面の下に隠れている場合があるため、表示を最後まで確認して進めます。

サブスクリプションを追加して接続を開始する

初めてクライアントを開いたら、設定またはサブスクリプションページでURLからインポートし、URLを貼り付けて更新します。追加後にその設定を選択し、プロキシグループでポリシーを確認してから、ホーム画面に戻って開始をタップします。AndroidにはVPN接続を作成するシステムダイアログが表示されるため、必ず許可してください。この権限は端末の通信をローカルのClashサービスへ送るために使われます。拒否すると、設定を読み込めてもシステム全体の接続は確立できません。ステータスバーに鍵またはVPNの表示が出れば、通常はシステムトンネルが確立されています。

他のアプリからサブスクリプションURLをコピーする場合、前後の空白、改行、チャットアプリが付けた余分な文字が混ざらないよう注意してください。更新後にプロキシグループがない場合は、ログのHTTPステータス、解析エラー、設定パスを確認します。ブラウザーでURLを開いてログイン画面が表示されても、クライアントが設定を取得できるとは限りません。専用のリクエストパラメーターが必要なURLや、すでに無効になったURLもあります。更新に失敗し続ける場合は、サブスクリプション更新のトラブル対応手順に沿って層ごとに確認してください。

アプリごとの振り分けとバイパス設定

AndroidのVPNインターフェースは大半のアプリ通信を取り込めます。クライアントには通常、「選択したアプリのみプロキシ」または「選択したアプリをバイパス」という2つの振り分け方式があります。前者は少数のアプリだけをClashへ通したい場合、後者は銀行アプリ、LAN制御アプリ、互換性のないアプリを直接接続したい場合に適しています。2つの方式は論理が逆なので、変更後は接続を停止して再起動し、システムにアプリ範囲を再構築させてください。システムコンポーネント、仕事用プロファイル、デュアルアプリは異なるパッケージ名で動作する場合があり、ユーザー領域ごとに設定が必要です。

アプリごとの振り分けは、通信をClashへ入れるかどうかだけを決めます。Clashに入った後は、ルールモード、プロキシグループ、DNSの判定が続きます。アプリがVPN対象になっているのに直接接続される場合、アプリ振り分けの失敗ではなく、ルールがDIRECTに一致している可能性があります。接続履歴でプロセス、ドメイン、適用ルール、最終ポリシーを確認し、まず通信がどの層を通っているかを判断してからルールを変更してください。

バッテリー最適化、バックグラウンド制限、ネットワーク切り替え

Androidメーカーはバックグラウンドアプリに独自の制限を加えることがあります。画面ロック後に接続が切れる、最近使ったアプリを消すとVPNが消える、Wi-Fiとモバイルネットワークの切り替え後に復旧しない場合は、クライアントをバッテリー最適化の対象外にし、バックグラウンド実行、自動起動、必要なフォアグラウンドサービス通知を許可してください。通知バーに常駐する表示は、システムが認識するフォアグラウンドサービスを維持するために使われます。通知チャンネルを無効にしたまま、長時間の安定動作を期待するのは避けてください。設定項目の名称はブランドによって異なりますが、重要なのは省電力による停止とバックグラウンド通信の制限を解除することです。

Wi-Fiからモバイルデータへ切り替えた後、短時間だけ接続できない場合は、まずシステムのネットワーク切り替えが完了するまで待ち、クライアントで一度停止して再起動します。特定のWi-Fiだけで問題が起きる場合は、Web認証が必要か、プライベートDNSを使っているか、IPv6のルートに違いがないかを確認してください。公共ネットワークでは、認証前にClashを一時停止し、認証後に起動します。Androidの「常時接続VPN」または「VPN未接続時の接続をブロック」が有効だと、クライアント停止中はすべての通信がシステムに遮断されます。通常のネットワークを確認するときは、この2つの設定も確認してください。

Androidのトラブル対応では、設定が有効化されているか、VPN権限が許可されているか、対象アプリが接続対象に含まれているか、バックグラウンドサービスがシステムに維持されているかの4点を確認します。この順番で確認すれば、「画面上は正常なのにアプリが通信できない」問題の多くを特定でき、頻繁にアプリデータを消去する必要はありません。

iOSとiPadOSのインストール、VPN構成、オンデマンド接続

App Storeからクライアントをインストールする

iPhoneとiPadのユーザーは、iOSダウンロードからClash PlusのApp Storeページへ移動できます。公式サイトはclashplus.ioです。インストール後に初めてアプリを開いたら、必要なネットワーク構成の要求を許可してからサブスクリプションを追加します。iOSはシステムのネットワーク拡張を一元管理しており、クライアントが接続を開始するとVPN構成の追加を求めます。端末のパスコード、Face ID、Touch IDによる確認が必要になる場合があります。許可が完了すると、システム設定のVPN一覧に該当する構成が表示されます。

インストールボタンが使えない場合は、端末のOSバージョン、App Storeアカウントの状態、スクリーンタイムの制限、組織による管理ポリシーを確認してください。組織管理端末ではVPN構成の追加が禁止されている場合があります。その場合、クライアントはインストールできても通信を取り込む権限を取得できません。再インストールを繰り返しても端末管理ポリシーは回避できないため、管理者にポリシーの変更を依頼してください。

サブスクリプションを追加してポリシーを選ぶ

設定またはサブスクリプションページで、サービス提供元のURLを追加し、更新して新しい設定を選択します。ポリシーページに戻り、よく使うプロキシグループに選択肢があることを確認してから接続を開始します。更新が成功したのにポリシー一覧が空の場合は、設定が本当に現在の設定へ切り替わっているか、サブスクリプションにプロキシグループが含まれているかを確認してください。iOSの共有メニューからURLをアプリへ渡せる場合もありますが、長いサブスクリプションURLはパラメーターの欠落を避けるため、直接コピーしてクライアントの入力欄に貼り付ける方が安全です。

ルールモードは多くの用途に適しており、設定内のルールによって直接接続かプロキシかが決まります。グローバルモードは大半の通信を指定したプロキシグループへ渡すため、短時間の診断に向いていますが、すべての問題に対する恒久的な解決策として使うのはおすすめしません。直接接続モードはプロキシ処理を一時停止するために使いますが、ローカルのネットワーク拡張が動作中であれば、システムのVPNアイコンが残ることがあります。プロキシの有無はステータスバーのアイコンだけで判断せず、クライアントの現在のモード、接続履歴、適用ポリシーも確認してください。

VPN構成と他のネットワークツールの競合

iOSでは通常、同時に1つの主要なVPNトンネルだけが通信を取り込めます。企業VPN、他のプロキシクライアント、コンテンツフィルター、セキュリティソフトがある場合、後から起動した構成が先の構成を置き換えたり、オンデマンド接続ルールによって自動的に接続を奪い返したりします。Clashが接続直後に切断される場合は、「設定—一般—VPNとデバイス管理—VPN」で実際に有効な構成を確認し、他のオンデマンド接続を一時的に無効にして再試行してください。

アプリを削除する前にVPN構成を削除しないと、システム一覧に古い名前が残る場合があります。古い構成が動作し続けることは通常ありませんが、トラブル対応の妨げになります。クライアントを移行するときは、まず接続を停止し、システムのVPN設定で旧構成が無効になっていることを確認してから、新しいクライアントで構成を追加してください。複数のプロキシクライアントで「オンデマンド接続」を同時に有効にすると、Wi-Fi、モバイル通信の切り替えや端末のロック解除時に接続を奪い合う可能性があります。

オンデマンド接続、LAN、モバイルデータ

オンデマンド接続はネットワーク変更後にトンネルを自動復旧する機能で、長期利用に適しています。ただし、手動接続が安定してから有効にしてください。Web認証が必要なWi-Fiでは、自動接続によって認証ページを読み込めないことがあります。その場合はオンデマンド接続と現在のVPNを一度無効にし、Wi-Fi認証を完了してから戻します。家庭内LANの画面ミラーリング、プリンター、スマートホーム、ファイル共有にはプライベートアドレス範囲への直接接続が必要です。有効化後に機器を検出できない場合は、LANのドメインやプライベートアドレスが誤ってプロキシへ送られていないか確認してください。

クライアントがモバイルネットワーク上でサブスクリプションを更新し接続を確立するには、モバイルデータ通信の権限が必要です。Wi-Fiでは正常でモバイル通信だけ失敗する場合は、システムのモバイル通信設定でクライアントの権限を確認し、サービス提供元のノードが現在の通信事業者ネットワークに対応しているかも確認します。低データモードや低電力モードではバックグラウンド更新の頻度が下がることがありますが、通常は前面での接続まで完全に妨げることはありません。問題がバックグラウンドだけで起きる場合は、ノードのルールではなく、Appのバックグラウンド更新とオンデマンド接続を確認してください。

DNSと接続履歴

iOSのネットワーク拡張におけるDNSは、通常、現在の設定で一元的に処理されます。Webページでサーバーが見つからないのに、既知のIPアドレスへは応答がある場合は、まずDNSを確認してください。最初はサブスクリプションのデフォルト設定を使い、システムに追加した暗号化DNSプロファイルやコンテンツフィルターを一時的に無効にします。特定のドメインだけが異常な場合は、接続履歴でリクエストが生成されたか、どのルールに一致したか、結果がfallbackへ進んだかを確認してください。設定のDNSパラメーターは、本ページの「サブスクリプションと設定」章およびClash DNS設定の詳しい解説を参照してください。

iOSではローカルプロキシポートを手動設定する必要はありません。主な確認点は、現在の設定、システムVPNの許可、オンデマンド接続、他のネットワーク拡張です。問題が起きたら、まずシステム設定で実際に有効なVPNを確認し、その後クライアントでモードとログを確認してください。アプリのホーム画面にある接続ボタンだけを見ると、別の構成に置き換えられている状態を見落としやすくなります。

LinuxのGUIクライアント、デスクトッププロキシ、コアサービス

GUIクライアントをインストールする

デスクトップLinuxではLinuxダウンロードからClash Verge RevまたはFlClashを選択できます。Debian、Ubuntu、Linux Mintなどでは通常debパッケージ、Fedora、Rocky Linux、openSUSEなどではクライアントの提供状況に応じてrpmを使います。インストール前にシステムアーキテクチャを確認してください。デスクトップPCの多くはamd64です。ローカルdebをパッケージマネージャーでインストールする場合は、低レベルの解凍コマンドだけを使わず、パッケージマネージャーに依存関係を処理させることをおすすめします。

sudo apt install ./client-package.deb

# rpm系ディストリビューションは本機のパッケージマネージャーでインストール
sudo dnf install ./client-package.rpm

上記のファイル名は、現在のディレクトリにあるインストールパッケージの例です。ターミナルには、実際にダウンロードしたファイル名を入力してください。GUIクライアント起動後のサブスクリプション追加はWindowsやmacOSと同様で、設定ページからURLを追加し、更新して現在の設定を選択し、システムプロキシまたはTUNを有効にします。WaylandとX11ではトレイアイコンの対応が異なります。トレイアイコンが表示されなくても、コアが動作していないとは限らないため、メインウィンドウ、プロセス、ログを総合的に確認してください。

デスクトップ環境のシステムプロキシ

GNOMEやKDEなどのデスクトップ環境では、HTTP、HTTPS、SOCKSプロキシを保存できますが、アプリによって読み取り方が異なります。ブラウザーは通常デスクトッププロキシに従いますが、ターミナルコマンド、コンテナ、Snap、Flatpakアプリは独自の環境を使うことがあります。クライアントでシステムプロキシを有効にしたら、まずブラウザーでテストしてください。ターミナルがまだプロキシを経由しない場合は、現在のshellにHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを設定し、ポートをクライアントの待受設定に合わせます。一時的なプロキシ変数をすべてのシステムサービスのグローバル環境へ直接書き込まないでください。クライアント停止後も、ソフトウェア更新やバックグラウンドタスクが無効なポートへ接続し続けるおそれがあります。

デスクトップのプロキシスイッチをオフにしてもアプリがプロキシを使う場合は、shellの起動ファイル、Git設定、パッケージマネージャーの設定、デスクトップのネットワーク設定に古い値が残っていないか確認します。Linuxのプロキシ状態は複数の場所に分散していることが多く、クライアントが復元できるのは自分で変更した部分だけです。トラブル対応では新しいターミナルを開いて環境変数を確認し、変更前の状態を保持した古いターミナルの影響を避けてください。

TUNの権限とルーティング

LinuxのTUNでは/dev/net/tunへのアクセス、ルートの変更、ファイアウォールルールの変更が必要です。GUIクライアントは通常、権限昇格用の補助サービスを通じてこれらを実行します。スイッチの有効化に失敗したら、ログで権限不足、デバイス不在、nftables/iptablesコマンドの失敗がないか確認してください。コンテナ、最小構成のディストリビューション、制限された仮想マシンではTUNデバイスが存在しない場合があり、ホスト側での許可が必要です。クライアントを動かすためにデスクトップへ常時rootでログインせず、クライアントが提供するサービスのインストール方法で必要最小限の権限を付与してください。

TUN起動後にLAN、コンテナブリッジ、仮想マシンへ接続できない場合は、直接接続するネットワーク範囲と自動ルートを確認します。Dockerは172.17.0.0/16などのブリッジネットワークを作成するため、リモートネットワークや設定内のプライベートアドレス範囲と重複することがあります。この場合は、本機のip routeの実際の結果に基づいてバイパス範囲を決め、別のマシンのルートをそのままコピーしないでください。ファイアウォール管理ツールが再起動後にクライアントのルールを上書きすることもあります。再起動後だけ問題が起きる場合は、サービスの起動順を確認してください。

Mihomoコアを直接実行する

サーバー、ソフトウェアルーター、GUIのない環境ではMihomoコアを直接利用できます。アーキテクチャに合ったファイルをダウンロードし、実行ファイルを管理対象のディレクトリへ置き、設定ファイルを用意して、まず設定チェックを実行します。設定には少なくとも、待受ポート、プロキシまたはプロキシプロバイダー、プロキシグループ、ルールが必要です。サブスクリプションサービスが完全なYAMLを提供する場合は設定ファイルとして保存できます。プロキシ一覧だけが提供される場合は、プロキシグループとルールを自分で補う必要があります。サーバーへ導入する前にフォアグラウンドで実行し、設定を解析できることを確認してからサービスマネージャーへ渡してください。

mkdir -p ~/.config/mihomo
cp config.yaml ~/.config/mihomo/config.yaml
mihomo -t -d ~/.config/mihomo
mihomo -d ~/.config/mihomo

-tで設定を確認し、成功してから起動します。コアをLANアドレスで待ち受けさせる前に、allow-lan、待受アドレス、ファイアウォールの意味を理解してください。本機だけで使う場合は、ループバックアドレスにしてアクセス範囲を小さくします。LAN機器から接続させる場合に限り、該当ポートを開放し、信頼できるネットワーク範囲に制限してください。コントロールインターフェースも、信頼できないネットワークへ直接公開しないでください。サービスマネージャーには明確な作業ディレクトリ、設定ディレクトリ、再起動ポリシーを指定し、対話型shellの終了でサービスが停止しないようにします。

サブスクリプション、プロキシモード、ルール、DNS

サブスクリプションの追加と設定の更新

サブスクリプションURLはリモート設定への入口です。クライアントが更新すると内容をダウンロードし、ローカルの設定ディレクトリへ書き込みます。通常、更新の成功には、ネットワーク要求が有効な内容を返すこと、YAMLの構文解析が通ること、設定が現在の使用項目に指定されることの3段階があります。画面に「ダウンロード完了」とだけ表示された場合も、プロキシグループとルールが表示されているか確認してください。更新に失敗したら、まず要求エラーと解析エラーを区別します。タイムアウトや接続拒否はネットワーク層、404や403はリンクまたは認証状態、HTMLやインデントエラーは内容層の問題です。

複数のクライアントで同じサブスクリプションを高頻度に更新しないでください。端末を移行するときはサブスクリプションを再追加できますが、サービス提供元が定める端末数と更新頻度の条件を確認します。クライアントの自動更新間隔は設定の取得頻度だけを制御し、ノードの自動速度測定やプロキシグループの選択を代替するものではありません。ローカル設定を変更しても、リモートサブスクリプションを再更新すると変更が上書きされる場合があります。長期的に保持するルールは、キャッシュファイルを直接編集せず、クライアントの上書き、スクリプト、マージ機能を利用してください。

ルール、グローバル、直接接続モード

ルールモードでは、ルールを上から順に照合し、最初に一致したルールが接続先のポリシーを決めます。ドメインルールは通常、ドメインを識別できる段階で処理され、IPルールはDNS解決後に判定される場合があります。そのためルールの順序が重要です。具体的なルールを広範なルールより前に置き、どれにも一致しない通信は最後にMATCHで処理します。グローバルモードは大半のルール判定を迂回して、通信をグローバルプロキシグループへ渡します。「ルールが原因で通信できない」のか「ノード自体が使えない」のかを判断するのに便利です。直接接続モードは基礎ネットワークの確認に使います。診断後はルールモードに戻し、LAN、システム更新、本来直接接続すべき通信まで長期間プロキシへ送らないようにしてください。

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

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - DOMAIN-KEYWORD,example,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致し、DOMAIN-KEYWORDはより広い範囲に一致するため、慎重に使います。IP-CIDRはネットワーク範囲に使用し、no-resolveと組み合わせると、IPルールの判定だけを目的とした追加のドメイン解決を避けられます。MATCHはフォールバックルールなので、ルール一覧の末尾に置きます。ポリシー名はプロキシグループ名と完全に一致させてください。大文字・小文字や空白の違いだけでも、設定の読み込みに失敗することがあります。

プロキシグループと自動選択

プロキシグループは、ルールが最終的に使用するノードまたは下位ポリシーを決めます。よくあるグループタイプには、手動選択、遅延テスト、フォールバック、負荷分散があります。自動テストの結果は、その時点でテスト先がどの程度応答したかを示すだけで、すべてのWebサイトやプロトコルで同じ品質を保証するものではありません。特定のサービスに接続できない場合は、プロキシグループでノードを切り替え、ログと合わせて判断してください。順位だけに頼らないことが重要です。上位のプロキシグループが別のグループを参照している場合、最終経路が複数段の選択になるため、各階層を展開して確認します。

ノード名、プロキシグループ名、ルールポリシーはサブスクリプションの管理元が決めます。クライアントは画面上の選択機能を提供できますが、サブスクリプションに存在しないグループ名を自動修復することはありません。「proxy group not found」のようなエラーが出た場合は、ルールが参照する名前と現在のサブスクリプションが一致しているか確認してください。特に、ローカルの上書き設定が古いグループ名を参照していないか注意します。サブスクリプション更新後に突然読み込めなくなり、ローカルの上書きを無効にすると復旧する場合は、リモート側のグループ名が変更された可能性があります。

DNS、Fake-IP、fallback

ClashのDNSモジュールは、ドメインをどこで解決するかを決め、ルール判定に必要なドメイン情報とIP情報を提供します。Fake-IPモードではドメインに対応するマッピングアドレスを返し、アプリがそのアドレスへ接続すると、コアが元のドメインに基づいてルールを適用します。これによりドメイン情報を維持できますが、一部のLAN機器検出、ゲーム、実アドレスを必要とするアプリでは互換性の問題が起きることがあります。その場合はFake-IPの除外や直接接続ルールで対応します。Redir-hostは従来の名前解決に近く、互換性の経路が異なります。モードを切り替えた後は、システムとアプリのDNSキャッシュを消去してからテストしてください。

nameserverは主要な名前解決サーバー、fallbackは条件に応じて別の結果を提供するサーバー群、fallback-filterはその結果を採用する条件を決めます。DNS設定ではサーバーを大量に並べるだけにしないでください。結果の取得元が増えるほど、汚染、タイムアウト、ルーティングの問題を判断しにくくなります。まずサブスクリプションのデフォルト値でプロキシ経路が正常なことを確認し、その後、利用地域と目的に合わせて調整します。パラメーターの書式とハイジャック範囲はnameserver、fallback、DNSハイジャックの解説を参照してください。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

ポート、LANアクセス、ログレベル

mixed-portはHTTPとSOCKSの接続を同時に受け付けられるため、本機のアプリに手動設定する用途に適しています。allow-lanを有効にした場合は、バインドアドレスとシステムのファイアウォールを組み合わせて、どの端末がアクセスできるかを決めます。本機だけで使うなら無効のままにする方が簡単です。ログレベルは日常利用ならinfoで十分です。debugは診断情報を増やせるため短時間のトラブル対応に適しますが、常時有効にするとログ量が増えます。確認が終わったらinfoへ戻し、「接続失敗」の4文字だけでなく、重要なエラー行を保存してください。

設定に関するよくある問題と段階的なトラブル対応

再現可能な確認手順を先に作る

Clashの問題に最も効果的なのは、設定を次々に切り替えることではなく、層ごとに検証することです。第1層は基礎ネットワークです。システムプロキシとTUNを無効にした状態で、端末がLANや普段使うWebサイトへ正常にアクセスできるか確認します。第2層は設定です。サブスクリプションの更新、現在の設定の有効化、プロキシグループの選択肢を確認します。第3層はコアです。ログに設定構文、ポート占有、権限、DNSのエラーがないか確認します。第4層は通信の取り込みです。対象アプリがシステムプロキシに従っているか、TUN、AndroidのVPN、iOSのネットワーク拡張に含まれているかを確認します。第5層で初めてノードとルールを確認します。

テストごとに変更する条件は1つだけにし、変更前後の結果を記録してください。たとえばルールモードでブラウザーが失敗した場合、同じノードのままグローバルモードへ切り替えます。グローバルモードで復旧すれば、ノードと通信の取り込み経路はおおむね正常で、問題はルールにある可能性が高くなります。グローバルモードでも失敗するならノードを変更し、別のノードで復旧したら元のノードを確認します。すべてのノードで失敗する場合は、DNS、サブスクリプションの状態、ローカルネットワークを確認します。こうすると「まったく開けない」という症状を検証可能な分岐に分解できます。

クライアントは動作中だがWebページを開けない

まずシステムプロキシのアドレスとクライアントの待受ポートが一致しているか確認します。mixed-portを変更したのにシステム側が古いポートを指していると、ブラウザーは存在しないローカルサービスへ接続します。次にクライアントの接続履歴を確認します。新しい接続がまったくない場合は、通信がClashへ入っていないため、システムプロキシ、ブラウザー独自のプロキシ、TUN権限、モバイル端末のVPNを確認します。接続はあるがDNSエラーならDNSを確認し、接続がありプロキシグループにも一致するのにハンドシェイクがタイムアウトするなら、別のノードでテストしてください。

クライアントが異常終了すると、システムにプロキシ設定が残ることがあります。Windowsではシステムプロキシ画面で手動プロキシをオフにし、macOSでは現在のネットワークサービスのプロキシ設定を削除します。Linuxではデスクトッププロキシと環境変数を同時に確認してください。AndroidとiOSでは、システムVPNが停止済みの設定を指していないか確認します。通常のネットワークを復旧してからクライアントを正常に起動し、通信の取り込みを再度有効にしてください。残った状態に設定を重ねないことが重要です。

サブスクリプションの更新に失敗する、または内容が空

更新がタイムアウトする場合は、現在のネットワークからサブスクリプションサービスへアクセスできるかを確認します。プロキシを有効にしたときだけ更新できる場合は、利用可能な設定を動作させた状態で更新してください。404は通常、パスが無効になったことを示します。403は認証、アクセス制限、リクエスト条件に関係する可能性があるため、サブスクリプション提供元に確認します。内容が空、または解析に失敗する場合は、応答が実際にはWebページのテキストではないか確認してください。WebアカウントページのURLをサブスクリプションURLとして使ったり、長いリンクのパラメーターを手動で削除したりしないでください。

自動更新は失敗するのに手動更新は成功する場合、バックグラウンド権限、更新間隔、端末のスリープ状態を確認します。モバイル端末の省電力設定がバックグラウンド要求を止めたり、デスクトップではシステム起動時にネットワークがまだ準備できていなかったりすることがあります。自動更新は便利な機能にすぎないため、現在のローカル設定が使えるなら、1回のバックグラウンド失敗だけで設定を削除する必要はありません。詳しい確認手順はサブスクリプション更新失敗と自動更新の設定を参照してください。

DNSリーク、名前解決の失敗、証明書エラー

DNSの問題は、ドメインを開けない、同じWebサイトの結果がネットワークによって異なる、ドメインルールが一致しないといった形で現れます。まずサブスクリプションのデフォルトDNSへ戻し、システムの追加プライベートDNS、暗号化DNS設定、ブラウザー独自のDNSを無効にしてテストします。復旧したらカスタム設定を1つずつ戻します。TUNを使う場合は、DNSハイジャックの待受範囲とポートが他のプログラムに占有されていないかも確認してください。Fake-IPモードでマッピングアドレスが表示されるのは仕様であり、アドレスの形式だけでDNSリークと判断しないでください。

ブラウザーが証明書無効と表示しても、すぐにルールが原因だと決めつけないでください。まずシステムの日付とタイムゾーンを確認し、Clashを無効にして同じWebサイトを試します。無効にしてもエラーが続くなら、システム時刻、Webサイトの証明書、ネットワーク認証、ローカルのセキュリティソフトが原因である可能性が高くなります。特定のノードを有効にしたときだけ起きる場合はノードを切り替え、接続の改変がないか確認します。パケットキャプチャーツール、ローカルHTTPSフィルター、企業証明書も証明書チェーンを変更します。詳しい判断方法はHTTPS証明書エラーとプロキシの関係を参照してください。

TUNの起動に失敗する、または有効化後に通信できない

デスクトップでは、まず管理者権限、補助サービス、仮想ネットワークアダプターを確認します。Windowsでは旧プロキシソフトのサービスとセキュリティソフトのブロック、macOSではネットワーク拡張とVPN・フィルタ、LinuxではTUNデバイス、ルート、ファイアウォールツールを確認してください。TUNを有効にすると完全に通信できなくなる場合は、まずTUNを無効にし、システムプロキシだけでコアとノードを確認します。システムプロキシが使えるなら基礎的なプロキシ経路は正常で、問題は仮想アダプター、ルーティング、DNSハイジャックに絞られます。

LANで問題が起きる場合は、プライベートアドレス範囲への直接接続を確認します。Docker、仮想マシン、リモートワーク用ネットワークでは同じプライベートアドレス範囲を使うことがあるため、実際のルートに応じて細かく分ける必要があります。スリープ復帰後に通信できない場合は、端末全体を再起動する前にTUNを再起動してみてください。毎回スリープ後に再現するなら、クライアントのバックグラウンド権限、補助サービスがシステム復帰時に再開しているか、別のネットワークツールが復帰時にルートを書き換えていないかを確認します。

ルールが反映されない、ログを読む

ルールモードでは、接続履歴にある宛先ドメイン、適用ルール、最終ポリシーを確認します。ルールは上から順に一致するため、広範なDOMAIN-KEYWORD、GEOIP、MATCHを前に置くと、後ろの具体的なルールは適用されません。アプリがIPアドレスへ直接接続すると、ドメインルールに一致しない場合があります。QUIC、IPv6、独自DNSを使うアプリでも経路が変わることがあります。まずログで実際のリクエスト形式を確認し、その後にドメイン、IP-CIDR、プロセス、ルールセットの条件を選んでください。

ログのエラーは前後の文脈と合わせて読んでください。設定解析エラーには通常、フィールド名や行番号が示されます。接続タイムアウトは要求が送信されたものの、時間内に完了しなかったことを意味します。connection refusedは対象が明示的に拒否したか、ローカルポートでサービスが動作していないことを示します。no such hostは名前解決の失敗、permission deniedはファイル、ポート、ネットワーク権限を優先して確認します。エラーの種類と対処の方向性を結び付けるには、Clashの実行ログでよくあるエラーを参照してください。

トラブル対応が終わったら、一時的に有効にしたdebugログ、グローバルモード、テスト用DNSを日常設定へ戻します。システムプロキシまたはTUNを管理するクライアントが1つだけであることを確認し、不要になった自動起動項目を削除してください。安定した設定では頻繁な調整は必要ありません。復元可能な設定を1つ保持し、サブスクリプションの入手元を明確にし、現在の通信の取り込み方法を理解しておけば、プラットフォーム間の違いの多くに対応できます。