Clashのよくある質問
サブスクリプション・プロキシ・接続のトラブル対処

Clashはプロキシコアと設定エコシステムで広く使われる名称です。mihomoはそのエコシステムに属するオープンソースのコア実装で、GUIクライアントはサブスクリプション、プロキシグループ、ログ、システム設定などの操作画面を提供します。画面上の名称が似ていても、同じコアを使っているとは限らず、すべての設定項目に対応するわけでもありません。クライアントを選ぶ際は、対応プラットフォームやメンテナンス状況、コアとの互換性を確認し、TUNやネットワーク共有が必要かどうかも検討しましょう。問題を調べるときは、クライアント名とコアの情報を併せて記録してください。「Clashを使っている」という情報だけでは、設定項目が対応しているか判断できないことがあります。

通常は必要です。クライアントは設定を読み込み、接続を処理するもので、インストールしただけで利用可能なプロキシサービスが手に入るわけではありません。サブスクリプションURLは通常、サービス提供元から発行されます。個人用の認証情報が含まれる場合があるため、機密情報として管理してください。読み込む前に、設定形式が現在のコアに対応しているか、サブスクリプションの有効期限が切れていないか、アカウントに利用可能な残量があるかを確認しましょう。当サイトではクライアントのダウンロード先と設定方法を案内していますが、サブスクリプションやノードは提供していません。問い合わせの際はエラーメッセージだけを共有し、サブスクリプションURL全体やQRコード、個人情報を含む設定ファイルは送信しないでください。

ルールモードはrulesの記述順に接続先を決めるため、普段使いに適しています。グローバルモードは通常、コアに入る接続をグローバルプロキシグループに振り分けるため、一時的な比較やテストに向いています。DIRECTモードでは、コアに入った接続が宛先へ直接アクセスします。グローバルモードでもPC全体の通信が必ずプロキシ経由になるとは限りません。システムプロキシやTUNを経由しないアプリは、クライアントを迂回することがあります。テスト後はルールモードに戻し、接続一覧で対象ドメインに適用されたルールを確認しましょう。モードを切り替えても、無効なサブスクリプションや期限切れのアカウント、接続不能なノードは直りません。ネットワーク自体の確認も必要です。

mixed-portは、HTTPとSOCKS5のプロキシ接続をコアで受け付ける共通ポートです。設定例では7890がよく使われますが、実際の値は現在の設定を確認してください。システムプロキシはプロキシのアドレスをOSの設定に登録し、その設定に従うアプリに適用されます。TUNは仮想ネットワークインターフェースを使い、ルーティング条件に合う通信を取り込みます。そのため、必要な権限やネットワークコンポーネントが異なります。初めて使う場合は、まずシステムプロキシを設定してブラウザーで接続を確認し、必要に応じてTUNを試しましょう。両方を常に有効にする必要はありません。問題が起きたら個別にテストすると、ポート、権限、ルートの競合を特定しやすくなります。

クライアントの設定またはサブスクリプション画面を開き、新しいサブスクリプションを追加する機能にURL全体を貼り付けます。保存後に更新し、新しい設定を使用中のプロファイルに指定してください。ローカルファイルを読み込む場合は、ファイルからインポートを選び、拡張子だけでなく中身もYAMLであることを確認します。ダウンロードに失敗して保存されたWebページを読み込まないよう注意してください。読み込みに成功したら、プロキシグループで利用可能なポリシーを選び、システムプロキシを有効にします。ローカルファイルを編集した場合は、元のファイルを保管し、インデントを確認してください。タブとスペースを混在させないようにしましょう。ボタン名はクライアントによって異なりますが、「読み込み」「設定の有効化」「ポリシーの選択」「通信の取り込み」の順に進めます。

まず更新時のメッセージを確認し、HTTPステータスコード、接続タイムアウト、設定の解析エラーを切り分けます。401や403の場合は、アクセス権限、URLに含まれる認証情報、アカウントの状態を確認しましょう。404の場合は、URLが正しいか、提供元が接続先を変更していないかを確認します。ただし、これらのステータスは中継ゲートウェイが返す場合もあるため、サービス提供元の案内も参照してください。タイムアウトの場合は、ネットワークの状態と、サブスクリプションの取得に使うDIRECTまたはプロキシ経由の経路を確認します。HTMLが返る、またはYAMLの解析エラーが出る場合は、ログインページを取得しているか、形式が正しくない可能性があります。URLを公開の場に何度も貼り付けて試さないでください。認証情報の漏えいが疑われる場合は、提供元の管理画面でサブスクリプションURLを再発行します。

まずTUNを無効にし、通常のシステムプロキシが使えることを確認します。次に、クライアントにサービスのインストール、修復、ネットワーク拡張の許可に関する項目があるか確認してください。Windowsでは通常、管理者の許可を得てサービスをインストールまたは起動する必要があります。macOSではシステムの案内に従って対象のネットワークコンポーネントを許可します。Linuxではクライアントのインストール方法によって必要な権限やルーティング設定が異なります。許可したらクライアントを再起動し、ログに権限エラーやデバイス作成エラーが残っていないか確認しましょう。問題を解決するためにファイアウォールを常時無効にするのは避けてください。他のVPN、仮想NICツール、別のTUNクライアントも使っている場合は、順番に終了して再テストし、ルートの競合を防ぎます。

設定の読み込みと、システムのVPN許可は別の操作です。前者はプロキシやルールを設定し、後者はクライアントがシステムのネットワークトンネルを作成することを許可します。初回接続時は、使用中のクライアントが許可ダイアログを表示したことを確認し、システムの案内に従って承認とデバイス認証を完了してください。Clash Plusの場合は、ダウンロードページからApp Storeに進めます。製品情報はclashplus.ioで確認できます。許可後も接続できない場合は、設定が有効か、プロキシグループが選択されているか、ほかのVPNが接続を使用していないかを確認しましょう。サブスクリプション形式の対応範囲はクライアントごとに異なります。ファイル名だけで互換性を判断しないでください。

まず、クライアントにオーバーライドまたは拡張設定の追加機能があるか確認し、サブスクリプションの更新で上書きされない場所にルールを追加します。ルールは上から順に評価されます。たとえばDOMAIN-SUFFIX,github.com,PROXYは、そのドメインに先に一致する可能性のある広範なルールより上に配置します。また、PROXYが実際に存在するポリシー名と一致していることも確認してください。保存後に設定を再読み込みし、新しい接続を発生させて適用されたルールを確認します。既存の長時間接続には、変更後のルールがすぐ反映されないことがあります。それでも適用されない場合は、アプリの通信がコアを経由しているか、ログに記録された実際のドメインが正しいかを確認しましょう。Webページのメインドメインと、読み込まれるリソースのドメインを混同しないよう注意してください。

レイテンシテストで分かるのは、主に特定のテスト先への応答時間です。継続的な通信速度を示すものではなく、すべてのWebサイトが同じ経路を通る保証もありません。まず、同じネットワーク、テスト先、近い時間帯でDIRECTとプロキシを比較し、接続一覧で想定したプロキシグループが使われているか確認します。次に、Wi-Fiの電波状況、バックグラウンドのダウンロード、サーバーの混雑、アカウントの速度制限、アクセス先の地域別配信の違いを調べてください。1回の最低レイテンシだけを見て、ノードを何度も切り替えるのは避けましょう。再生中の動画は以前のポリシーで接続を続ける場合があるため、切り替え後に再接続してください。速度テスト用サイトにアクセスできなくても、ノード自体が無効とは限りません。

まずスマートフォンとPCを、信頼できる同じLANに接続します。PCのクライアントでLAN接続を許可し、allow-lanがtrueになっていること、待ち受けアドレスがLANからの接続を受け付けることを確認して、mixed-portの実際の番号を控えます。スマートフォンのWi-Fi設定で手動プロキシを選び、PCのLAN内IPアドレスとポート番号を入力してください。127.0.0.1はスマートフォン自身を指すため、入力しないでください。PCのファイアウォールでは、必要なネットワークプロファイルに限り、該当ポートへの受信を許可します。この方法が適用されるのは、主にWi-FiのHTTPプロキシ設定に従うアプリです。すべての通信を取り込めるとは限りません。使い終わったら共有を無効にし、プロキシポートをインターネットに公開しないでください。

スタートアップ起動は通常、クライアントの起動だけを行います。システムプロキシの有効化、TUNの復元、前回の設定の選択まで自動で行うとは限りません。これらの動作はクライアントの各設定で制御され、すべてに共通するYAMLの自動起動スイッチはありません。まずログイン時の起動、起動時の接続、サービスの状態を確認し、PCを再起動して動作を確かめましょう。サブスクリプションのルールやプロキシ設定は、更新時に置き換わることがあります。ローカルの変更は、クライアントが対応するオーバーライド、マージ、独立した設定機能を使って保存してください。変更前に使えるコピーを書き出し、変更した項目を記録します。クライアントの更新後に動作が変わった場合は、設定が保持されているか確認し、サブスクリプションの元ファイルへ同じ内容を何度も追加しないでください。

まずコアが起動していて、現在の設定が有効になっていることを確認します。次に、システムプロキシのアドレスと実際の待ち受けポートが一致しているか確認してください。システムプロキシの接続先を127.0.0.1にするには、クライアントが同じPC上で待ち受けている必要があります。続いて、ブラウザー拡張機能、アプリ独自のプロキシ、自動設定スクリプト、別のプロキシツールがシステム設定を上書きしていないか確認します。接続一覧を開いて新しいリクエストを発生させてください。記録があればルールとポリシーを確認し、記録がなければアプリがシステムプロキシを参照しているかを調べます。コマンドラインツール、一部のゲームやストアアプリは個別設定またはTUNのテストが必要な場合があります。システムプロキシのスイッチだけで、すべての通信が取り込まれたと判断しないでください。

アプリコンテナーの制限を受ける一部のUWPアプリは、ローカルのループバックプロキシへの接続が制限される場合があります。ただし、ストアアプリがすべて同じ条件とは限りません。まず通常のブラウザーが同じプロキシで接続できることを確認し、対象アプリが本当にローカルプロキシを必要としているか調べましょう。クライアントにUWPループバックツールがある場合は、必要なアプリだけに免除を追加できます。通常は管理者権限が必要です。既存の設定はCheckNetIsolation LoopbackExempt -sで確認できます。すべてのアプリをまとめて許可するのは避けてください。TUNを使っている場合は、ルーティングやDNSの問題を別途確認します。ループバックの免除は、Windowsアプリの通信障害すべてに有効な解決策ではありません。

まずプロキシを無効にして、基本的なネットワーク接続を確認します。次に、サブスクリプションが更新されているか、アカウントが有効か、対象のプロキシグループで無効なノードを選んでいないかを確認してください。timeoutは、所定の時間内に接続が完了しなかったことを示します。パケットロス、接続先への到達不能、サーバーの状態、名前解決などが原因として考えられます。connection refusedは通常、接続先のポートが拒否したことを示しますが、ローカルのプロキシポートが待ち受けていない場合もあります。エラーに表示された接続先がノードサーバー、Webサイト、ローカルのループバックアドレスのどれかを確認してから、調べる箇所を決めましょう。利用できる別の接続と比較し、エラーが発生した時刻も記録してください。すべてのタイムアウトをルールの問題と決めつけたり、ポート、DNS、モードを同時に変更したりしないでください。

まず障害が特定のドメインだけで発生するか確認し、ログに名前解決の失敗、上流DNSのタイムアウト、ルールの誤適用がないか調べます。Fake-IPが有効な場合、予約アドレスが返されるのは仕様上の動作である可能性があります。それだけで名前解決のエラーと判断せず、その後の接続がコアに取り込まれているか確認してください。LAN内のドメイン、ゲーム、特定のアプリで互換性の問題が起きる場合は、設定を理解したうえで必要なドメインをfake-ip-filterに追加するか、対応する別のDNSモードと比較します。変更後は設定を再読み込みし、OSの方法に従ってDNSキャッシュを消去して、アプリの接続を作り直してください。複数のDNS制御ツールを同時に使ったり、上流DNSをすべて不用意に置き換えたりしないでください。