Clashのよくある質問

クライアントは設定の読み込みやモード切り替え、接続状況の表示を担当し、カーネルは設定の解析、ルール判定、プロキシ接続を担います。Clash Metaは拡張カーネルの旧称で、後継プロジェクトではmihomoという名称が使われています。オリジナル版Clashとは、対応プロトコルや設定項目が完全には一致しません。トラブルの切り分け前に、クライアントの「情報」やカーネル情報で両方の名称を確認しましょう。ウィンドウのタイトルだけで互換性を判断することはできません。メニューの場所もクライアントによって異なる場合があります。

クライアントは接続や通信の振り分けに使うツールで、インストールしただけではプロキシサービスを利用できません。自分で管理するサーバー設定、またはサービス提供元から受け取った有効なサブスクリプションを読み込み、該当する設定を有効にしてください。読み込み後も一覧が空の場合は、設定にルールしかないか、まだ読み込まれていないプロキシプロバイダーを参照していないか、設定が実際に使用中かを確認します。出所が不明な公開設定を既定の設定にするのは避けてください。

普段はルールに応じてDIRECTまたはプロキシのポリシーへ振り分けるルールモードが基本です。グローバルモードは、カーネルに入った通信をグローバルポリシーで処理するため、短時間の比較テストに向いています。DIRECTモードでは、カーネルに入った通信が接続先へ直接接続します。いずれもカーネル内の処理方法を変えるもので、クライアントを経由していないアプリの通信まで自動で取り込むわけではありません。グローバルモードでも、すべてのアプリがプロキシ経由になるとは限りません。システムプロキシやTUNの通信経路も確認してください。

遅延テストで確認できるのは、通常、指定されたテスト先への1回のリクエストだけです。Webサイトの名前解決、ルール判定、ログイン用API、継続的なデータ転送までは確認できません。まず接続パネルを開き、対象サイトへのアクセス時に接続が記録されるか、どのルールと出口が使われているかを確認します。テストに成功しても利用できない場合は、同じノードで複数の接続先を試し、DIRECT接続時の結果と比較してください。遅延の数値だけでノード全体の利用可否を判断したり、低遅延ならダウンロードも速いと考えたりしないようにしましょう。

基本的な設定の一部は新しいクライアントでも使える可能性がありますが、互換性を左右するのは設定ファイルの拡張子ではなく、使用するカーネルです。移行前に元の設定とカスタムルールをバックアップし、別の設定で試してから、プロトコル、プロキシグループの参照、ルールセットのパス、DNS関連の項目を確認してください。Clash for Windowsはメンテナンスが終了しているため、継続的な更新を前提に使うのはおすすめできません。移行先を選ぶ際は、開発状況と現在のサブスクリプション形式との互換性を確認しましょう。

まず、リクエストの失敗と設定の解析エラーを切り分けます。タイムアウトは接続経路、401や403は認証・リクエスト制限・リンク切れ、解析エラーは返却内容がWebページになっていないか、設定形式に対応しているかを確認します。期限切れやリンクの欠落、余分な空白も確認してください。リクエスト方法を変更するのは、サービス提供元が対応を案内している場合に限ります。ブラウザーで開けても、クライアントからのリクエストが成功するとは限りません。問い合わせ時は、サブスクリプションURL全体と認証情報を必ず伏せてください。

まずエラーの行番号、プロトコル名、現在のカーネル名を記録し、サブスクリプション提供元が指定する形式を確認します。mihomo向けの設定は、オリジナル版Clashや他のクライアントでそのまま読み込めるとは限りません。同じプロトコル名でも、拡張パラメーターにバージョン要件がある場合があります。エラー項目を一つずつ削除するより、使用するクライアントに対応したサブスクリプションを取得し直すのが先です。変換サービスを使う場合は、設定内容や認証情報にアクセスできるため、サービスの信頼性を確認してください。

TUNは仮想ネットワークインターフェイスの作成とルート設定を行うため、通常はクライアントのサービスモード、システムの許可、または管理者権限が必要です。まずカーネルが正常に動作しているか確認し、クライアントの案内に従ってサービスをインストールまたは修復します。関連コンポーネントがシステムにブロックされていないかも確認してください。それでも解決しない場合は、ログに記録されたネットワークアダプターやルートのエラーを確認し、他のVPNや仮想ネットワークツールとの競合を調べます。ネットワーク設定を一度に複数変更せず、毎回一項目だけ変更し、TUNを無効にした場合の結果も記録しましょう。

Windowsは「システム情報」でプロセッサーとシステムの種類を確認します。一般的なIntelまたはAMD搭載のデスクトップPCではx64、ARM端末ではネイティブ版の有無や互換実行への対応を確認してください。macOSは「このMacについて」でAppleシリコンかIntelかを確認します。Androidは端末が対応するABIに合わせて選び、OSのビット数だけで判断しないでください。ダウンロードページで実際に提供されているビルドを確認し、プロジェクトのシステム要件と照らし合わせましょう。別のプラットフォーム用パッケージのファイル名を変えて使うことはできません。

まずログで、使用中のポートがプロキシポート、混合ポート、コントロールインターフェイスのどれかを確認し、待ち受け中のプロセスを特定します。別のプロキシクライアントが動作中なら、正体の分からないプロセスを強制終了するより、クライアントを通常の方法で終了するほうが安全です。ポートを変更する場合は、実際に適用されている設定またはクライアントのオーバーライドで変更し、ブラウザー、ターミナル、システムプロキシの接続先も合わせて更新してください。変更後は関連する接続を再起動し、古いポートが使われていないことを確認します。画面上だけ変更され、カーネルが古い設定を読み続ける状態に注意してください。

接続パネルを開き、対象アプリで新しいネットワークリクエストを実行します。該当するドメイン、接続先アドレス、プロセスが記録されるかを確認し、適用されたルールと出口もチェックしてください。既存の長時間接続はノードを切り替えてもすぐには再接続されないことがあるため、ページを更新するか、アプリの接続をやり直します。システムプロキシが有効でも、すべてのアプリがその設定に従うとは限りません。記録がないアプリは、まず通信の取り込み方法を確認し、ノードやルールを変更するのはその後にしましょう。

ルールは通常、上から順に評価され、最初に一致した項目のポリシーが適用されます。後ろにある詳細なルールが、前方の広いルールに先に一致して隠れていることがあります。ルールモードになっているか、カスタムルールが最終設定に反映されているか、ポリシー名がプロキシグループ名と完全に一致するかを確認し、接続パネルで実際に適用されたルールを調べてください。クライアントがオーバーライドに対応している場合は、設定の結合順も確認します。リモートサブスクリプションから生成されたファイルを直接編集すると、次回の更新で上書きされることがあります。継続して使う変更は、永続化されるオーバーライドに設定しましょう。

ほかのデバイスでは、プロキシサーバーにクライアントを実行している端末のLAN内アドレスを設定し、実際のプロキシポートを指定します。127.0.0.1は指定しないでください。待ち受けアドレスがLANからの接続を許可していること、システムファイアウォールで該当ポートが許可されていること、ルーターでクライアント間の通信が遮断されていないことも確認します。この機能は信頼できるネットワークでのみ有効にし、必要に応じて認証やアクセス制限を設定してください。プロキシポートやコントロールインターフェイスをインターネットに公開しないでください。システムプロキシを設定しても、接続先端末のすべてのアプリが自動で対象になるわけではありません。

プロキシグループの選択は通常、新しく作られる接続に適用されます。すでに開始しているダウンロード、動画、メッセージアプリの接続は、元の出口を使い続ける場合があります。対象の接続に適用されているポリシーグループを確認し、必要に応じて接続を閉じるか、アプリからリクエストをやり直してください。設定に複数のポリシーグループがある場合、既定のグループだけを切り替えても特定のサイトには反映されないことがあります。ブラウザーに表示される出口はキャッシュやバックグラウンド接続の影響を受ける可能性もあるため、ノードを何度も選び直すのではなく、接続パネルも確認しましょう。

クライアント名、カーネル情報、OS、問題が起きた時刻、再現手順と、発生時刻前後のエラーログを用意します。TUN、システムプロキシ、ほかのVPNを使っているかも伝えてください。ログレベルを上げるのは再現中だけにし、終わったら通常の設定に戻します。共有前に、サブスクリプションURL、認証パラメーター、ノードのパスワード、コントロールインターフェイスのキー、個人用ドメインを隠してください。再現に必要な最小限の情報を提出し、設定全体を公開の場に貼ったり、確認していないスクリーンショットをアップロードしたりしないでください。

まずプロキシを無効にして、通常のネットワーク接続が使えるか確認します。次に、サブスクリプションの期限、システム時刻、カーネルログの名前解決エラーやハンドシェイクエラーを確認してください。同じ設定を現在のネットワークと別の信頼できるネットワークで試すと、原因を絞り込めます。1つのノードだけ失敗する場合は、そのノードの状態を優先して確認します。すべてのノードが同時にタイムアウトしても、テスト先に到達できない可能性があるため、サーバー側の全障害とは限りません。各テストでは設定と接続先を固定し、DNS・モード・ノードを同時に変更しないようにしましょう。

まずシステムプロキシのアドレスとポートが現在のカーネルを指しているか確認します。ブラウザー拡張機能、アプリ独自のプロキシ設定、除外リストがシステム設定を上書きしていないかも調べてください。一部のターミナルツールはシステムプロキシを参照せず、プロキシの引数や環境変数を個別に設定する必要があります。起動済みのプロセスが以前の設定を保持していることもあります。接続パネルに記録がまったくない場合は、まず通信の取り込み経路を解決します。グローバルモードは通信を取り込むスイッチではありません。カーネルに入った接続だけを処理するため、すべてのアプリにシステムプロキシの利用を強制することはできません。

アプリコンテナーによる分離のため、一部のWindowsアプリは既定でローカルのループバックアドレスに接続できません。そのため、ブラウザーは使えるのにストアアプリだけ失敗することがあります。まずアプリがシステムプロキシを使用していることと、プロキシポートが使えることを確認します。次にクライアント付属のループバック除外ツール、またはWindowsのCheckNetIsolationを使って、該当アプリのパッケージを確認してください。除外設定は必要なアプリだけに適用し、すべてのアプリを一括で許可するのは避けましょう。TUNを有効にすると解決する場合は、2つの通信経路の違いも記録します。すべての接続エラーをループバック制限のせいにしないでください。

まず、ドメイン名をどのDNSで名前解決したいかを明確にします。そのうえで、アプリ内蔵のセキュアDNS、システムのリゾルバー、クライアントのDNS、TUNによるDNS制御が想定どおりか確認してください。ブラウザーのテストサイトに表示されるDNSの出口は手がかりにすぎず、すべてのアプリの名前解決経路を証明するものではありません。ドメインごとに通信ルールが異なる場合もあります。カーネルログ、接続記録、管理できるドメインへのテストを組み合わせて、一項目ずつ確認しましょう。DNS設定をそのまま丸ごとコピーせず、上流DNSへの到達性やプロキシノードのドメインを解決するためのDNS設定も確認してください。

そのまま無視したり、出所不明のルート証明書をインストールしたりしないでください。通常のプロキシ転送で、ブラウザーのHTTPS通信を復号する必要はありません。証明書エラーが出たら、システム時刻、接続先ドメイン、証明書チェーンを確認し、セキュリティソフトによるHTTPS検査、ポータルのログイン画面、異常な名前解決がないか調べます。プロキシを無効にした場合、信頼できる別のノードに切り替えた場合、ほかのサイトに接続した場合を比較し、ブラウザーのエラーコードを記録してください。アカウントや決済画面でエラーが出た場合は、機密情報を入力せず、エラーの種類に沿って原因を特定しましょう。