Clash よくある質問とトラブル対処

クライアントでは、設定のインポート、プロキシグループの選択、システムプロキシの切り替え、ログの確認などを画面上で操作します。コアはポートの待ち受け、ルールの適用、DNS 処理、通信の転送を担当し、サブスクリプションサービスは設定内容やプロキシノードを提供します。クライアントをインストールしてもサブスクリプションは自動的に取得されず、サブスクリプション提供元がクライアント開発者と同じとは限りません。問題を切り分ける際は、画面操作、コアの動作、サブスクリプション内容のどこに原因があるかを先に確認します。

このサイトは独立した中国語の使い方ガイドで、クライアントのダウンロード先、設定手順、トラブル対処法を整理しています。特定のクライアント、コア、サブスクリプションサービスを代表するものではありません。ダウンロード前に、ダウンロードページでクライアント名、対応システム、メンテナンス状況を確認してください。機能の違いについては、使用するクライアントとコアのバージョンで実際に表示される設定項目を基準にしてください。

いいえ。サブスクリプションのインポートでクライアントに保存されるのは、通常、リモート設定だけです。さらに、その設定を選択し、コアを起動して、ルールモードまたはグローバルモードを選び、システムプロキシや TUN などの通信取り込み機能を有効にする必要があります。設定後は、通信経路を確認できるページにアクセスし、クライアントのログに対応する接続が記録されているかも確認してください。サブスクリプション名が表示されているだけでは、通信がコアを経由しているとは限りません。

ルールモードでは、設定ファイルのルールを上から順に評価し、最初に一致したルールによって DIRECT、REJECT、またはプロキシグループが選ばれます。グローバルモードでは、通常、取り込み可能な通信を選択したプロキシグループへ送ります。ルールが原因でアクセスできないかを一時的に確認する場合に便利です。直結モードでは、通信が接続先へ直接アクセスします。グローバルモードは速度を上げる機能ではないため、常用する前に、LAN、システムサービス、必要な直結ルールが正しく設定されているか確認してください。

まずブラウザーでサブスクリプションURLを開き、ログインページ、有効期限切れの通知、エラーページではなく設定内容が返ることを確認します。次に、URLを完全にコピーできているか、サブスクリプションの期限が切れていないか、端末の時刻が正確か、クライアントからサブスクリプションのドメインへアクセスできるかを確認してください。ブラウザーでは開けるのにクライアントで失敗する場合は、更新ログの HTTP ステータス、TLS、タイムアウト情報を確認し、サブスクリプション更新専用のプロキシが設定されていないかも確認します。ローカルの上書き設定を失わないよう、設定を何度も削除するのは避けてください。

まずエラーが発生した行番号を記録し、その行と直前の行について、インデント、コロン、ハイフン、引用符が正しく対応しているか確認します。YAML のインデントにはスペースを使い、Tab とスペースを混在させないでください。同じ階層のフィールドは同じ幅でインデントする必要があります。手動編集後にエラーが出た場合は、直近の変更を一時的に取り消して再読み込みします。サブスクリプション設定とローカルの上書き設定は分けて管理してください。そうしないと、サブスクリプション更新時に元ファイルへ直接書き込んだ内容が上書きされる可能性があります。

まず端末自体が直結でインターネットにアクセスできることを確認し、システム時刻、サブスクリプションの有効期限、ノード情報が最新か確認します。次にノードを1つだけ選んでテストし、ログで DNS 解決失敗、接続拒否、ハンドシェイク失敗、単純なタイムアウトのどれに該当するかを確認します。すべてのノードで同時に異常が起きている場合は、ローカルネットワーク、サブスクリプション内容、コア設定に原因がある可能性が高くなります。1つのノードだけ異常なら、サブスクリプション提供元にそのノードの状態を確認してください。遅延テストに失敗しても、実際の通信がすべて失敗するとは限りません。

アプリコンテナーによるネットワーク分離を使用する一部の Windows アプリは、ローカルホストのプロキシ待ち受けアドレスへ直接アクセスできません。この場合、クライアントが提供する UWP ループバックツールで、対象アプリのループバック制限を解除する必要があります。まずブラウザーなど通常のデスクトップアプリがシステムプロキシ経由でアクセスできることを確認し、問題のあるアプリだけを選択して再起動してください。クライアントにループバックツールがない場合は、付属ドキュメントに従って Windows の対応機能を使用し、すべてのアプリを無差別に追加しないでください。

まずクライアントの HTTP または mixed の待ち受けポートが動作しているか確認し、次にシステムプロキシのアドレスとポートがクライアントと一致しているか確認します。その後、ブラウザー独自のプロキシ拡張機能、個別のプロキシ設定、システムプロキシを無視するポリシーが有効になっていないか確認してください。これらの上書き設定を一時的に無効にして再試行し、クライアントのログで対象ドメインを検索します。ログにまったく記録がない場合、ブラウザーの通信はまだコアに到達していないため、ノードを切り替え続けても切り分けには役立ちません。

多くのターミナルプログラムはデスクトップのシステムプロキシを自動的に読み取りません。現在の shell または対象プログラムに HTTP_PROXY、HTTPS_PROXY、ALL_PROXY を設定し、クライアントが実際に待ち受けているプロトコルとポートを指定してください。設定後にターミナルを開き直し、環境変数が反映されていることを確認してから、コマンドの詳細出力で接続先を確認します。プログラム独自のプロキシ引数が環境変数を上書きしていないかも確認してください。テスト後は一時的な環境変数を削除し、パッケージマネージャーや LAN へのアクセスに影響しないようにします。

TUN は仮想ネットワークインターフェースを作成し、システムのルーティングを変更するため、クライアントから管理者権限、VPN 構成、ネットワーク拡張機能、補助サービスの許可を求められることがあります。使用中のクライアントがシステム上で示す認証手順に従い、完了後にコアを再起動して仮想インターフェースが作成されたか確認してください。macOS ではネットワーク拡張機能と VPN 構成の通知にも注意し、Linux ではサービス権限と TUN デバイスが利用可能か確認します。通常の認証を回避するために、システムのセキュリティ機能を無効にしないでください。

同時に有効にするかどうかは、クライアントの実装によって異なります。システムプロキシは主に OS のプロキシ設定に従うアプリへ影響し、TUN は仮想インターフェースを通じてより多くの通信を取り込みます。TUN 有効後も、特定のアプリとの互換性のためシステムプロキシを維持するクライアントがありますが、状況によってはどちらか一方だけで十分です。初めて切り分ける場合は、まずシステムプロキシだけを確認し、その後 TUN を有効にしてください。2つの通信経路を同時に変更すると、ループバック、ルーティング、DNS のどこに問題があるか判断しにくくなります。

いいえ。no-resolve は通常、IP-CIDR などのルールに付けて使用し、その IP ルールを評価する際にコアがドメイン名を積極的に IP へ解決しないことを示します。余分な名前解決やルール評価経路の変化を避けるための指定です。すべての DNS を無効にするものではなく、nameserver、fallback、fake-ip などの DNS 設定の代わりにもなりません。ドメイン解決に問題がある場合は、DNS 設定、システムの名前解決経路、ログを確認し、すべての no-resolve 指定を削除しないでください。

まずシステムプロキシまたは TUN を無効にし、直結ネットワークが復旧することを確認します。次にクライアントのコアを再起動し、待ち受けポートが他のプログラムに使用されていないか確認してください。動作確認済みの設定とノードを1つ選び、グローバルモードで短時間の比較テストを行います。グローバルモードは使えるのにルールモードで失敗する場合は、ルールとプロキシグループを確認します。どちらも失敗する場合は、DNS、ノード接続、ハンドシェイクのログを確認してください。モード、DNS、ノードを同時に切り替えると結果を再現できなくなるため、毎回1つの設定だけを変更します。

まず TUN を無効にして問題がすぐ解消するか確認し、クライアントログでルート作成、インターフェース起動、DNS エラーを確認します。LAN に接続できない場合は、プライベートアドレス帯が DIRECT のままになっているか、TUN 設定でローカルゲートウェイ、プリンター、社内ネットワークのアドレス帯が除外されているか確認してください。端末上で別の VPN、仮想 NIC、ネットワークフィルタリングソフトを同時に実行している場合は、1つずつ一時停止して競合をテストします。ルートを変更する前に元の設定を記録し、復旧方法を確認してから続行してください。

サブスクリプションの更新では、通常、対象の設定がリモート内容で置き換えられるため、サブスクリプションファイルに直接記述したローカルルールやプロキシグループの選択がリセットされることがあります。まずクライアントに上書き、マージ、スクリプト処理、プロキシグループ選択の保持機能があるか確認し、個人用ルールは独立したローカル管理先に保存してください。更新前に重要なプロキシグループとルールを記録し、更新後にグループ名や参照先が変わっていないか確認します。リモート設定の構造が変わった場合は、古いグループ名を使い続けるのではなく、上書きルールも合わせて変更してください。

クライアントの接続履歴またはコアのログを開き、対象ドメインへ再度アクセスして、一致したルールの種類、内容、最終的なプロキシグループを確認します。ログの経路が想定と異なる場合は、DOMAIN、DOMAIN-SUFFIX、GEOIP、RULE-SET、IP-CIDR など、より前にあるルールを確認してください。ルールは上から順に一致するため、後続のルールで一致済みの結果を上書きすることはできません。一時的なカスタムルールで個別に検証し、確認後に安定したローカル上書き設定へ追加してください。サブスクリプション更新で置き換えられるファイルを直接編集するのは避けます。