Clashのよくある質問

クライアントは設定のインポート、システムプロキシの切り替え、接続履歴の確認など、画面上の操作を担います。mihomoカーネルはプロトコル接続、DNS名前解決、ルールの適用を担当します。サブスクリプションは、サービス提供元から配布される設定またはノード情報です。クライアントをインストールしても、利用可能なノードが自動で提供されたり、サービスアカウントが作成されたりするわけではありません。問題を切り分ける際は、画面、カーネルの動作、サービスのどこに原因があるかを確認します。カーネルが起動しない場合はログを、設定を読み込めない場合は形式を確認し、アカウントの期限切れやノードの停止についてはサブスクリプションの提供元に問い合わせてください。

Clash for Windowsはサポートを終了しています。移行先には、現在もメンテナンスされており、利用中のOSに対応したクライアントを選びましょう。まずサブスクリプションURL、ポート、ルールモード、ローカルの上書き設定を控えます。旧クライアントのシステムプロキシを無効にして終了し、新しいクライアントを起動してサブスクリプションを読み込みます。ネットワークを制御するクライアントを同時に起動したり、旧プログラムのフォルダーを新しいプログラムにそのまま上書きしたりしないでください。移行後はまず1つのノードと普段使うアプリで動作を確認し、その後カスタムルールを1つずつ戻します。旧設定の実験的な項目は、新しいカーネルのドキュメントで対応状況を確認してください。

普段はルールモードを選び、カーネルに届いた接続をルールの順に対応するポリシーへ振り分けます。グローバルモードでは、これらの接続をグローバルポリシーにまとめて振り分けるため、短時間の比較や切り分けに適しています。ダイレクトモードでは、接続先へ直接アクセスします。モードと通信の取り込み方法は別の設定です。グローバルに切り替えても、すべてのアプリの通信が自動で取り込まれるわけではありません。まずシステムプロキシまたはTUNが対象アプリをカバーしていることを確認してから、モードの違いを比較してください。グローバルでは接続できるのにルールモードで失敗する場合は、クライアントをすぐ再インストールせず、適用されたルールとポリシーグループを確認しましょう。

システムプロキシが適用されるのは、OSのプロキシ設定に従うアプリだけです。ゲーム、一部のコマンドラインツール、独自に接続を確立するソフトまでカバーできるとは限りません。ブラウザー拡張機能がシステムプロキシの設定を上書きすることもあります。まずクライアントの接続履歴で、対象アプリから新しいリクエストが届いているか確認してください。履歴に表示されない場合は、ノードを変更する前にアプリ内プロキシ、拡張機能の設定、通信の取り込み方法を確認しましょう。より広い範囲の通信をカバーするにはTUNを検討できますが、ルーティング、除外設定、OSごとの制限も確認が必要です。カーネルに届いた接続でも、ルールによって直接接続される場合があります。

クライアントの設定またはサブスクリプション画面でURLのインポートを選び、サービス提供元から受け取ったURLをすべて貼り付けます。保存後、ダウンロードと解析が完了するまで待ちます。読み込みに成功しても、使用中の設定に切り替わったとは限りません。読み込んだ設定を現在の設定に指定し、ポリシーグループが表示されることを確認して、利用するポリシーを選びます。続いて通信を取り込む方法を有効にし、対象サイトへアクセスして接続履歴を確認してください。サブスクリプションURLにはアカウント情報が含まれる場合があります。スクリーンショット、公開ログ、グループチャットなどに掲載しないでください。URLが漏えいした場合は、提供元の管理画面で再発行してから読み込み直しましょう。

ClashのYAML設定全体、ノードの一覧、Base64でエンコードされた共有リンクの一覧は、それぞれ形式が異なります。完全な設定には通常、プロキシ、ポリシーグループ、ルールが含まれます。ノード一覧だけの場合はプロキシの集合として参照する必要があり、メイン設定として直接読み込めないことがあります。Base64はあくまでエンコード方式であり、現在のクライアントでそのまま使えることを意味しません。サブスクリプションの提供元に、Clashまたはmihomoに対応した設定URLを確認し、対応プロトコルも確かめてください。アカウント情報を含むサブスクリプションを、信頼できない変換サイトに渡さないでください。形式エラーを解消するためにポートを何度も変更する必要はありません。

まずカーネルが正常に動作していることを確認し、クライアントの案内に従ってサービスモードをインストールまたは起動し、OSの許可を与えます。Windowsでは通常、管理者権限または正しくインストールされたバックグラウンドサービスが必要です。macOSでは、案内に従って関連するネットワークコンポーネントを許可します。Linuxでは通常、TUNデバイスへのアクセスとネットワーク管理権限が必要です。セキュリティソフトによるブロックや、別のVPNがルーティングを制御していないかも確認してください。提供元が不明なプログラムに管理者権限を与えたり、システム保護を長期間無効にしたりしないでください。許可後に関連サービスを再起動します。それでも失敗する場合は、仮想アダプターの作成段階のログを記録して原因を調べましょう。

AppContainerのサンドボックスで動作する一部のアプリにはローカルループバックの制限があり、クライアントが待ち受けるローカルプロキシのポートに直接接続できません。まず同じプロキシ経由でブラウザーにアクセスできることを確認し、特定のアプリだけで問題が起きるかを切り分けます。クライアントにループバックの除外ツールがある場合は、用途を確認したうえで対象アプリだけに適用し、案内に従って管理者権限を許可してください。ツールがない場合は、WindowsのCheckNetIsolationの使い方を確認できます。すべてのMicrosoft Storeアプリに同じ制限があるわけではありません。TUNが有効なら、関係のない除外設定を追加する前に接続履歴とルーティングを確認しましょう。

まず現在の設定が正常に読み込まれ、カーネルが動作していることを確認します。次に、システムプロキシが正しいローカルアドレスと待ち受けポートを参照しているか確認してください。ポートはクライアントで実際に有効なmixed-portまたはHTTPポートと一致させます。HTTPプロキシにSOCKS専用ポートを指定しないでください。ブラウザー拡張機能、アプリ内の独自プロキシ、システムのプロキシ除外リストを確認し、リクエストを再送して接続履歴を見ます。履歴にDIRECTと表示される場合、リクエストはカーネルに届いているものの、ルールによって直接接続に振り分けられた可能性があります。適用されたルールを確認してください。履歴に何も表示されない場合は、通信の取り込み設定を確認しましょう。

ルールは上から順に評価されます。個別のルールは、最後に適用されるMATCHより前に置き、現在の設定に実在するポリシーグループまたは組み込みポリシーを指定してください。クライアントが用意する上書き、マージ、永続化ルールの機能を使うのがおすすめです。サブスクリプションから生成されたファイルを直接編集すると、更新時に変更が失われることがあります。保存後に設定を再読み込みし、接続履歴で実際に適用されたルールを確認してください。既存の接続には以前のポリシーが使われ続ける場合があります。必要に応じて対象の接続だけを切断し、再試行しましょう。ドメインルールを使う場合は、カーネルが接続先のドメイン名を認識できることも確認してください。

クライアントの遅延テストで分かるのは、主に指定したテスト先への接続状況です。ダウンロード速度と同じではなく、すべてのサイトに接続できる保証にもなりません。まずテスト先にアクセスできることを確認し、同じ条件で同じノード群をテストしてください。一度に大量のノードを測定すると、結果に影響することがあります。普段使うノードは、対象サイトへの接続、安定性、サービス提供元の通信量制限を踏まえて選びましょう。遅延が低いのにサービスを利用できない場合は、対象サイトの制限とプロトコルの互換性を確認します。テストがタイムアウトしても実際のアクセスに問題がない場合は、テスト先とタイムアウト設定を見直してください。

DNSの項目を変更したら設定を再読み込みし、クライアントの画面設定や上書き設定によって値が元に戻っていないか確認してください。ログに上流DNSの名前解決エラーがないか確認し、クライアントが対応する方法でDNSキャッシュを消去してから対象への接続をやり直します。GeoIPなどの地理データを更新する場合は、現在のカーネルが対応するデータ形式と設定パスを使い、読み込みが成功したことを確認してください。GeoIPが影響するのは関連するIPルールであり、ドメイン名の名前解決が自動的に直るわけではありません。特定のドメインだけで問題が起きる場合は、DNSの結果、適用ルール、ポリシーの選択をあわせて確認しましょう。

まず、引き続き使える現在の設定を残し、何度も削除して原因を調べる手がかりを失わないようにします。401または403は、認証情報、URLに含まれる認証情報、アクセス制限に関係することが一般的です。404はURLが変更された可能性がありますが、提供元の案内を確認してください。HTMLが返る場合は、ログインページのURLをコピーした、またはWeb上の認証画面が表示されたことがよくある原因です。提供元の管理画面から専用のサブスクリプションURLをコピーし直し、アカウントの有効期限と通信量を確認してから手動で更新します。レスポンス全体やサブスクリプションURLを公開しないでください。単なるネットワークタイムアウトであれば、まず更新リクエストの通信経路を確認しましょう。

まず通信の取り込みを無効にした状態で、通常のネットワーク接続が使えることを確認します。次に端末の時刻、アカウントの状態、サブスクリプションの更新結果を確認してください。その後、ノードを1つだけ選んで対象へリクエストを送り、同じ時間帯のログを確認します。ドメイン名の名前解決失敗、接続拒否、ハンドシェイク失敗、テスト先のタイムアウトを区別しましょう。すべてのノードが同じサービスのものなら、提供元にサービス状況を確認します。特定のプロトコルだけ失敗する場合は、カーネルが対応しているか、必要なパラメーターがそろっているか確認してください。DNS、ポート、ルールを同時に変更すると原因を特定しにくくなります。ログを共有する前に、サブスクリプションの認証情報、ノードのパスワード、その他のアカウント情報を削除してください。

まずログで待ち受けに失敗していることを確認します。次にWindowsのnetstat、macOSまたはLinuxのlsofで7890番ポートを使用中のプロセスを調べます。正体の分からないシステムプロセスを終了しないでください。旧クライアントが動作中なら、通常の手順で終了します。ポートを変更する必要がある場合は、現在のクライアントのポート設定または有効な設定でmixed-portを変更し、未使用のポートを指定して再読み込みしてください。サブスクリプションのファイルは上書き設定の影響を受ける場合があるため、実際に動作している値を確認します。変更後はシステムプロキシ、ブラウザー、コマンドラインツールのポートも合わせ、ログに待ち受けエラーが出なくなったことを確認しましょう。

よくある原因は、停止したローカルプロキシをシステムが引き続き参照していることです。まずクライアントをもう一度起動し、システムプロキシとTUNを無効にしてから通常の手順で終了します。その後、OSのネットワーク設定に手動プロキシが残っていないか確認してください。アプリ内で個別のプロキシを設定している場合や、コマンドラインにプロキシ環境変数を設定している場合も、それぞれ元に戻します。TUN、手動DNS、別のVPNを使っていた場合は、ルートとDNSが復元されているか確認し、必要であればネットワークに再接続してください。最初からネットワークをリセットしたり、ネットワークアダプターをすべて削除したりせず、現在の設定を記録してから、プロキシ、DNS、ルーティングの順に確認しましょう。