Clashのよくある質問

クライアントは設定のインポート、ポリシーの切り替え、システムプロキシの設定を担当します。コアは設定の解析、接続の確立、通信の振り分けを行います。サブスクリプションは、サービス提供元からノードや設定を受け取るためのものです。クライアントをインストールしただけでは、利用可能な接続先が手に入るわけではありません。利用権限のある設定をインポートする必要があります。Clashのエコシステムでは、クライアントごとに異なるコアを採用している場合があり、mihomoも継続的に開発されているコアの一つです。機能が使えない場合は、アプリ名だけで判断せず、クライアント名と実際に使用しているコアのバージョンを記録してください。当サイトではダウンロード情報と設定方法を案内していますが、サブスクリプションの発行やサービス提供元アカウントの復旧には対応していません。

通常はRuleを選び、プロキシ経由になった通信を設定内のルールに従って振り分けます。Globalでは、プロキシ経由の通信をグローバルポリシーで処理します。利用可能なノードが選択されていることも確認してください。Directでは、プロキシ経由の通信を直接接続します。モードを切り替えても、通信をプロキシに取り込む範囲は広がりません。また、システムプロキシを使わないアプリが、切り替えだけでプロキシ経由になるわけでもありません。切り分けには、一時的にGlobalに切り替えて同じURLへアクセスします。Globalでは正常でRuleでは失敗する場合、ルールの一致状況とポリシーの選択を確認してください。どちらも失敗する場合は、ノード、名前解決、通信の取り込み経路を調べ、テスト後は元のモードに戻します。

遅延テストの成功は、その時点でノードがクライアント指定のテストリクエストに応答したことを示すだけです。すべてのサイト、プロトコル、出口が利用できるとは限りません。まずテストに使われたURLを確認し、接続先サイトへの通信が実際にどのポリシーグループに振り分けられたかを調べます。別のノードのテスト結果を、現在の接続結果と取り違えないようにしてください。次に、通常のサイトと目的のサイトで結果を比べ、ログに名前解決失敗、ハンドシェイク失敗、接続先からの拒否がないか確認します。接続先が出口IPアドレスを制限している場合や、アプリがUDPに依存している場合もあります。遅延の数値だけを見て設定を何度も変えるのではなく、通信の取り込み失敗、ノードの利用不可、接続先サイト側の制限を切り分けましょう。

YAML形式というだけで互換性があるとは限りません。クライアントによって、使用するコア、対応プロトコル、ルールの種類、設定の上書き方法が異なります。特に古いコアでは、新しい項目を認識できない場合があります。移行前に元の設定を保存し、移行先クライアントのコアに関する説明を確認してください。インポート後は設定チェックを実行し、最初に表示された明確な解析エラーを確認します。一度に設定を複数削除するのは避けましょう。モバイル端末では、システムVPNインターフェースを使って通信を取り込む場合があり、設定画面もデスクトップ版とは異なります。サブスクリプションで複数の形式が提供されている場合は、移行先のコアに合った形式を選びます。設定を変換する際は、サブスクリプションURLにアクセス認証情報が含まれるため、見知らぬ変換サービスに安易に送信しないでください。

まず、ダウンロードの失敗と設定の解析エラーを切り分けます。接続タイムアウト、証明書エラー、HTTPステータスの異常はダウンロード段階の問題です。ダウンロードはできても、項目、インデント、プロキシの種類に関するエラーが出る場合は、内容の解析段階に問題があります。URLがすべて正しくコピーされているか、空白や改行が混ざっていないか、アカウントページのURLをサブスクリプションURLと取り違えていないか確認してください。現在のネットワークからサブスクリプションのドメインにアクセスできない場合は、利用可能な接続経由で更新を試せますが、ネットワーク設定を次々と変更するのは避けましょう。ログインページやエラーの説明が返される場合は、サービス提供元のアカウントでリンクの状態を確認します。エラー画面を共有する際は、サブスクリプションURL全体、アカウント情報、ノードの認証情報を隠してください。

まず現在の設定と更新エラーを保存し、サービス提供元のアカウントでサブスクリプションの有効期限、通信量、URLのリセット有無、サービスのお知らせを確認します。HTTP 401や403は認証やアクセス制限が原因の場合によく見られますが、最終的にはサービス提供元から返された内容を確認してください。更新に失敗するたびに、アカウントの期限切れと決めつけないようにしましょう。新しい設定が空、またはノード名が変わった場合、ポリシーグループが古い名前を参照している可能性があります。現在選択されている項目を確認してください。古い設定に戻しても復元できるのはローカルの設定だけで、サービスの有効期限は延長できません。サービス提供元がURLの変更を求めていることを確認してから差し替え、使えなくなったURLを削除して、定期更新で利用可能な設定が上書きされ続けないようにします。

まずシステム情報でOSのバージョンとプロセッサのアーキテクチャを確認し、ダウンロードページで対応するインストーラーを選びます。x64とARM64は異なるアーキテクチャです。macOSではApple SiliconとIntelをそれぞれ確認してください。Linuxではdebやrpmなど、ディストリビューションに合ったパッケージ形式を選ぶ必要があります。OSのバージョンが非対応と表示された場合は、そのクライアントの最低要件を確認してください。ファイル名の変更やシステム保護の無効化で、無理にインストールするのは避けましょう。インストール後に起動できない場合は、エラー全文を記録し、古いプロセスの残存、必要な実行環境、セキュリティソフトによるブロックを確認します。更新前に設定とローカル上書きをバックアップしておけば、アンインストール時に原因調査に必要な情報まで消えるのを防げます。

まずTUNを無効にし、通常のシステムプロキシで接続できることを確認してから、仮想ネットワークアダプターの問題を個別に調べます。デスクトップクライアントでは、サービスのインストールまたは起動と管理者権限が必要な場合があります。macOSでは関連するシステム権限の許可を求められることもあるため、クライアントの案内に従ってください。ログを確認し、サービスの未起動、アダプターの作成失敗、ルートの競合などがないか調べます。スイッチを何度も押すだけでは解決しません。他のVPN、通信高速化ツール、同種のTUNツールを一時的に終了してから再試行し、ルートを同時に変更しないようにします。有効化後に端末全体がインターネットに接続できなくなった場合は、まずTUNを無効にしてネットワークを復旧し、エラー情報を保存してから、アダプター、デフォルトルート、DNSを確認してください。正体のわからないシステムアダプターをまとめて削除しないでください。

まずクライアントのコアが実行中か確認し、システムプロキシの接続先であるローカルアドレスとポートが、現在の待ち受けポートと一致しているか調べます。ブラウザーの拡張機能、独自のプロキシ設定、個別のネットワーク設定がシステム設定を上書きしていることがあります。関連する拡張機能を一時停止し、システムプロキシに従うブラウザーウィンドウで比較してください。目的のURLにアクセスしながら接続一覧も確認します。新しい記録がなければ、通信の取り込み経路を優先して調べます。記録があり、DIRECTと表示される場合はルールとモードを確認します。ノード経由でも失敗する場合は、ノードと接続先サイトを調べてください。システムプロキシの変更とTUNの有効化は同じではありません。また、Webページの表示言語だけでプロキシ経由かどうかを判断しないでください。

多くのコマンドラインツールはデスクトップのシステムプロキシを自動で読み取りません。プロキシの引数や環境変数を個別に設定する必要があります。まず、curl --proxy http://127.0.0.1:7890 https://example.com を使って明示的にテストしてください。7890は例なので、クライアントが実際に提供しているHTTPまたはmixedポートに置き換えます。テストに成功したら、使用するシェルに応じてhttp_proxyとhttps_proxyを設定し、no_proxyで接続先が除外されていないか確認してください。Git、パッケージマネージャー、コンテナにも独自のプロキシ設定がある場合があります。WSLやコンテナ内の127.0.0.1はホスト側を指すとは限りません。環境をまたいだ接続ではネットワークの境界も確認し、ホスト側のアドレスをそのまま使わないようにしてください。

エディターに保存したファイルだけでなく、コアが実際に読み込んでいる設定を確認してください。ルールは通常、上から順に評価されます。広すぎるルールやMATCHが前にあると、それ以降のルールに到達しないことがあります。指定したポリシーグループが実在し、名前も完全に一致しているか確認しましょう。完全なドメイン名にはDOMAIN、ドメインのサフィックスにはDOMAIN-SUFFIXを使います。URLのプロトコルやパスまで一緒に記述していないかも確認してください。保存後、クライアントの手順に従って設定を再読み込みし、新しい接続を作成してログを確認します。既存の接続は以前の経路を引き続き使用する場合があります。サブスクリプションの更新でリモート設定が上書きされる場合は、クライアントが提供するローカル上書きやマージ機能を使ってください。

AppContainerで分離された一部のアプリは、ローカルのループバックプロキシに直接アクセスできません。そのためブラウザーは正常でも、一部のストアアプリが失敗する場合はループバック制限を確認できます。ただし、ストアアプリがすべてUWPとは限りません。まず、そのアプリがシステムプロキシを使用するか、クライアントにループバック除外ツールがあるかを確認します。許可が必要な場合は、対象アプリだけを有効にしてください。手動で操作する場合は、管理者としてCheckNetIsolation LoopbackExempt -sを実行し、現在の一覧を確認してから、アプリの実際のパッケージ識別子に基づいて変更します。表示名をパッケージ識別子として使わないでください。企業の管理対象端末では、まず管理者に相談してください。接続がすでにログに記録されている場合は、ルールやノードも確認し、ループバックだけを原因と決めつけないようにしましょう。

まずプロキシを無効にし、基本ネットワークで正常にアクセスできることを確認してから、サブスクリプションのアカウントと設定が有効か調べます。ノードを一つ選んで実際にリクエストを送り、同じ時刻のログを確認して、ドメインの名前解決失敗、TCP接続のタイムアウト、認証失敗、TLSハンドシェイクエラーを切り分けます。それぞれ対処方法が異なります。次に、ネットワークを変える、または利用可能とわかっているノードに切り替えるなど、変更する条件を一つに絞って結果を比較します。遅延テストだけ失敗し、実際のアクセスは正常な場合は、テスト用URLに到達できるか確認してください。複数のノードが同じ入口ドメインやサービス提供元を共有している場合、同時に失敗しても端末側の問題とは限りません。発生時刻とエラーの種類を記録してから、サービス提供元に問い合わせましょう。

まず、システムDNS、コアのDNS、ブラウザーの暗号化DNSのどれを使っているか確認します。3か所を同時に変更すると結果を比較できなくなります。現在のネットワークから上流のDNSリゾルバーに到達できるか調べてください。ノードサーバー自体がドメイン名を使っている場合は、プロキシ接続を確立する前に必要な名前解決ができることも確認します。Fake-IPが仮想アドレスを返すのは通常の動作です。仮想ネットワーク帯のアドレスが見えるだけで、名前解決エラーと判断しないでください。一部のドメインだけで問題が起きる場合は、まずログと互換性を確認し、使用中のコアがサポートするフィルター方式で必要最小限の調整を行います。変更後は関連するキャッシュを消去し、接続を作り直してください。LAN内のデバイス名を使う場合は、ローカルネットワークに適した名前解決経路も維持します。

まず、システムプロキシが停止済みのローカルポートを参照したままになっていないか確認してください。システムのネットワーク設定で手動プロキシを無効にします。自動プロキシスクリプトを使っていた場合は、その設定も確認してください。次に、TUNが無効になっていること、関連サービスと仮想ネットワークアダプターが正常な状態であることを確認し、手動設定したDNSが残っていないか調べます。ターミナルでは、今回設定したプロキシ環境変数を削除するか、新しいターミナルを開いて再テストしてください。順に復旧してからネットワーク接続の再起動が必要か判断します。最初からネットワーク設定全体をリセットするのは避けましょう。企業の端末では、組織のプロキシが必要な場合があります。変更前に元の値を記録し、組織で必要なネットワーク設定を誤って削除しないようにしてください。

同じブラウザーと同じ確認ページを使い、有効化前後の結果を比較しながら、クライアントで今回のリクエストが接続一覧に記録されているか確認します。出口IPは判断材料の一つにすぎません。確認サイトがルールで直接接続に設定されていたり、ページのキャッシュで誤った結果が表示されたりすることがあります。ブラウザーの接続は記録されているのに、対象アプリの記録がない場合は、そのアプリがシステムプロキシに対応しているか、UDPを使っているか、独自のネットワーク設定があるかを確認してから、TUNが必要か判断してください。IPv4とIPv6で異なる経路を使う場合もあるため、アドレスが違うだけで全体設定を変更せず、実際の接続をそれぞれ確認します。TUNは通信を取り込む範囲を広げられますが、ルートとルールの影響を受けるため、すべての接続が自動的に同じ出口を使うとは限りません。