Clashのよくある質問

クライアントは設定のインポートやプロキシの選択、システムプロキシなどの画面操作を担当し、コアは実際の接続や名前解決、ルール判定を処理します。Clash Metaは関連するコアプロジェクトで使われていた名称で、後継の名称がmihomoです。古いガイドにあるMetaは、独立したクライアントを指すとは限りません。クライアントによって搭載するコアのバージョンや設定の管理方法が異なるため、トラブルシューティングではクライアント名とコアのバージョンを記録しましょう。画面が似ているだけで、設定項目が使えると判断しないでください。

クライアントをインストールしただけでは、通信を処理するツールが用意されたにすぎません。利用可能なプロキシ設定またはサブスクリプションと、接続先サーバーへアクセスできるネットワーク環境も必要です。設定を読み込んだら、プロキシノードとプロキシグループが含まれているか確認し、ノードを選んで接続をテストします。その後、システムプロキシを有効にし、必要に応じてTUNを使います。クライアントに「実行中」と表示されても、コアが起動したことを示すだけです。サブスクリプションの有効性やノードへの到達、Webサイトの表示は別々に確認してください。

通常はルールモードを使い、設定したルールに従って接続を各プロキシグループへ振り分けます。グローバルモードでは、コアに届いた接続をグローバルポリシーに通すため、短時間の比較テストに便利ですが、すべてのアプリの通信を自動で取り込むわけではありません。DIRECTモードは、主にローカルネットワークが正常か確認するために使います。モードを切り替えたら、新しい接続でテストしてください。既存の長時間接続は、以前のポリシーを使い続ける場合があります。グローバルモードで改善しても、ルールやグループの確認が必要だと分かるだけで、原因を特定できたとは限りません。

インストール済みのものは引き続き動作する場合がありますが、アーカイブされたクライアントには互換性修正やセキュリティ更新が継続して提供されません。新しい設定項目やプロトコルに対応できないこともあります。移行前に、サブスクリプションの取得元、プロキシグループの選択、ローカルルールをバックアップし、保守されているクライアントへ一つずつ読み込みましょう。古いプログラムのフォルダー全体をそのまま上書きしたり、複数のクライアントを同時に起動して通信を取り込ませたりしないでください。移行後は、まずシステムプロキシと基本的な接続を確認してから、TUNやオーバーライドなどの設定を戻します。

サブスクリプションURLにはアクセス用の認証情報が含まれていることが多く、完全なURLを知られると、ノード情報を見られたりサービスの通信量を使われたりするおそれがあります。スクリーンショットやログを共有する前に、サブスクリプションのパスやクエリパラメーター、ノードのパスワード、コントロールインターフェースのキーを隠してください。アカウント名を隠すだけでは不十分です。変換が必要な場合は、サービス提供元が用意する互換形式を優先するか、信頼できるローカル環境で処理します。見知らぬ変換サイトにURLを渡すことは、設定へのアクセス権を渡すのと同じです。URLが漏れた場合は、公開メッセージを削除するだけでなく、サービス提供元の管理画面で再発行してください。

まず、アカウントのプラン、有効期限、通信量の残りを確認します。次にサービス提供元の管理画面からURLを完全な形でコピーし、余分な空白や改行、URLの欠落がないか確認してください。エラーがリクエストのタイムアウト、アクセス拒否、設定の解析失敗のどれかを見分けます。アクセス拒否なら認証を確認し、Webページが返る場合はログイン画面やエラーページの可能性があります。プロキシ経由でしかURLにアクセスできない場合は、接続できる状態で更新するか、サービス提供元が認める別の方法を使います。レート制限を避けるため、短時間に何度もリクエストしないでください。

まずシステム情報でプロセッサのアーキテクチャとOSのバージョンを確認し、対応するインストーラーを選びます。一般的なx64またはAMD64は、IntelやAMDのデスクトップ向けプロセッサ用です。ARM64は対応するARMデバイス向けです。macOSではApple SiliconとIntelを区別してください。形式がサポートされていないというエラーが出たら、ファイルの拡張子を何度も変更するのではなく、OSとアーキテクチャを確認しましょう。最低対応OSバージョンや必要なコンポーネント、サービスのインストール要件はクライアントごとに異なります。ダウンロードページの説明とインストーラーの案内を確認してください。

まずTUNを無効にし、システムプロキシで基本的な接続ができることを確認します。そのうえでクライアントの説明に従い、サービスモードをインストールするか、仮想ネットワークアダプターの作成に必要な権限を付与してください。Windowsでは管理者の承認、Linuxではサービスの権限やネットワーク機能、モバイル端末ではシステムのVPN接続要求への許可が必要な場合があります。許可後、サービスが実際に動作しているか確認し、コアのログで具体的なエラーを調べます。組織のポリシーで管理されている端末では、制限を回避しないでください。適切にサービスを設定する代わりに、関係のないプログラムを常に高い権限で実行するのも避けましょう。

mixed-portはHTTPとSOCKSのプロキシ接続を受け付け、external-controllerは管理画面からの操作に使います。用途が異なるため、ブラウザーやターミナルのプロキシ設定には、実際に有効になっている混合ポートを指定してください。コントロール用ポートは使えません。クライアントで待ち受けアドレスとポートを確認し、アプリにも同じ値を入力します。この端末だけで使う場合は、ループバックアドレスでの待ち受けを優先してください。変更後はコアに設定を再読み込みさせ、手動でプロキシを設定したアプリも更新します。古いポートに接続し続けないよう注意してください。

サブスクリプションの設定ファイルは、通常、リモートの内容で全体が更新されます。ダウンロードした設定を直接編集すると、更新時に上書きされることがあります。個人の変更はサブスクリプション本体と分けて管理できるよう、クライアントのオーバーライド、マージ、ローカルルール機能を使いましょう。利用できる項目やマージの順序はクライアントによって異なります。保存後はエディターの表示だけでなく、実行中の最終設定を確認してください。まず確認しやすいルールを一つ追加し、配置と振り分け先が正しいことを確かめてから、ほかの設定を移行します。元に戻せるようバックアップも残しておきましょう。

遅延テストで分かるのは通常、指定されたテスト先への1回のリクエストにかかる時間であり、継続的な通信速度ではありません。実際の速度は、回線の混雑、サーバーの負荷、接続先による制限、ローカルのWi-Fi環境にも左右されます。ノードを比較するときは、近い時間帯に同じ接続先へアクセスし、Webページの応答と継続的なデータ転送をそれぞれ確認してください。複数の速度測定を同時に実行するのは避けましょう。特定のサイトだけ遅い場合は、そのサイトに適用されたルールと接続経路を先に確認します。遅延の数値だけで、あらゆる用途に最適なノードだと判断しないでください。

クライアントの接続一覧またはログを開き、対象のWebサイトに再度アクセスします。新しい接続をドメイン名で絞り込み、適用されたルール、プロキシグループ、最終的な出力先を確認してください。ルールは通常、上から順に評価されるため、先にある範囲の広いルールが後ろの細かいルールより先に適用されることがあります。変更後は該当する古い接続を閉じるか、テストするアプリを再起動し、既存接続の再利用による誤判定を防ぎます。一つのWebページから複数のドメインへリクエストが送られることもあります。メインサイトは開くのに画像が表示されない場合は、静的ファイルやログイン用APIの接続も個別に確認してください。

一部のクライアントは同時に有効にできますが、初めて設定する際は、まずどちらか一方だけで動作を確認するのがおすすめです。システムプロキシはシステムのプロキシ設定に従うアプリに影響します。TUNは仮想ネットワークアダプターとルーティングを使い、対象となる通信を取り込みます。両者は同じ仕組みではありません。併用する場合は、ルーティング、DNSの横取り、ほかのVPNとの競合を確認し、通信がループしないようにしてください。切り替える前に元の設定を記録し、まず個別に有効にした場合の動作を確認します。問題が起きたら、複数のスイッチを一度に変更するより、動作確認済みの一方に戻すほうが原因を特定しやすくなります。

更新前に、現在の設定名、プロキシグループの選択、ローカルのオーバーライドを記録し、残しておきたいファイルをバックアップします。サブスクリプションの更新とルールセットの更新は別の操作です。前者ではノードやプロキシグループが変わることがあり、後者では主にルールの照合データが更新されます。更新後は設定が正常に読み込まれたことを確認し、よく使うWebサイトやローカルサービスをテストしてください。ノード名が変わると、以前の選択が復元されない場合があります。自動更新の間隔はサービス提供元の推奨を参考にし、必要以上に短く設定しないでください。問題が発生したら、エラーと更新時刻を記録してから、バックアップを戻すか判断しましょう。

出口IPで分かるのは特定の接続の出力先であり、DNSクエリも同じ経路を通ったことの証明にはなりません。まず実行中の設定でDNSサーバー、上流の名前解決先、ルーティングを確認します。ブラウザーのセキュアDNS、OSの暗号化DNS、ほかのVPNが別の名前解決経路を作っていないかも確認してください。テストサイトに表示されるリゾルバーの場所が、実際のクエリ経路と一致するとは限りません。ログを確認し、必要に応じてパケットキャプチャで分析しましょう。設定を変更したら、関連するキャッシュを消去して新しい接続を確立します。古い名前解決結果を、現在の設定に問題がある証拠と誤解しないようにしてください。

まずプロキシを無効にして、基本的なネットワーク接続が使えるか確認します。次に、サブスクリプションの有効期限、ノードの読み込み状況、システム時刻が正確かを確認してください。その後、少数のノードを手動でテストし、ログでドメインの名前解決失敗、接続拒否、ハンドシェイクのタイムアウトのどれが発生しているかを調べます。共通のテスト先だけに接続できない場合、テストのタイムアウトがすべての接続先にアクセスできないことを意味するとは限りません。実際のWebサイトでも確認しましょう。異なるネットワークでもすべて失敗する場合は、DNSやルール、ポートを一度に変更せず、サービス提供元にノードの状態を確認してください。

まず、システムプロキシのアドレスとクライアントの実際の待ち受けポートが一致しているか確認し、コアが動作中であることを確かめます。次に、ブラウザーで独自のプロキシ拡張機能や手動設定、組織のポリシーが有効になっていないか確認してください。アクセス時に新しい接続が表示されるかも確認します。接続記録がない場合は、通信がクライアントに届いているかを先に調べます。記録がある場合は、適用されたポリシーとノードを確認してください。ターミナルやゲームなど、システムプロキシを参照しないアプリは、個別の設定かTUNが必要な場合があります。トラブルシューティング中はプロキシツールを一つだけ使い、ほかのプログラムがシステム設定を繰り返し上書きしないようにしましょう。

一部のUWPアプリにはアプリコンテナーのループバック制限があり、ローカルのループバックアドレスで待ち受けているプロキシに接続できない場合があります。まず通常のブラウザーで接続できることを確認し、対象アプリが実際にそのプロキシ経路を使っているか調べます。そのうえでクライアントのドキュメントに従い、該当アプリに限ってループバック接続を許可してください。操作には管理者権限が必要な場合があります。すべてのアプリを一括で許可したり、ストアアプリだからといって原因を決めつけたりしないでください。アプリがシステムプロキシを参照していない場合は、ネットワークの仕組みを確認するか、権限が許す範囲でTUNを使って比較テストを行います。

まず、競合しているのが混合プロキシ用ポートなのか、コントロールインターフェース用ポートなのか確認します。Windowsではnetstat -anoで待ち受けポートとプロセスIDを確認でき、Linuxではss -lntpを使えます。プロセスの詳細表示には追加の権限が必要な場合があります。使用中のプロセスを特定してから、重複して起動しているクライアントを終了するか、現在の設定に空いているポートを割り当ててください。正体の分からないシステムプロセスを安易に終了しないでください。変更後は設定を再読み込みし、アプリのプロキシアドレスも更新します。起動のたびに競合する場合は、古いサービスやスタートアップ項目がバックグラウンドで動作していないかも確認しましょう。

接続中は、サブスクリプション、ノード、モード、通信の取り込み、DNSの順に確認します。接続記録を使い、リクエストがコアに届いていないのか、届いた後に失敗しているのかを切り分けてください。終了後に通信できなくなった場合は、システムプロキシが停止済みのローカルポートを指していないか、TUNやほかのVPNのルートが影響していないかを優先して確認します。まずクライアントからプロキシとTUNを正常に無効にし、その後システムのネットワーク設定を確認してください。必要に応じて関連アプリを再起動します。すべての設定を最初に消去して手がかりを失わないよう、ログを保存してからリセットを検討しましょう。