Clashのよくある質問.

Clashはプロキシコアとその設定エコシステムの名称です。オリジナルのコアは開発が終了しています。Clash Metaはオリジナルをベースにプロトコルやルール振り分け機能を拡張し、後にmihomoへ改称されました。Clash Verge RevなどのGUIクライアントは、サブスクリプション管理、トレイアイコン、システム設定画面を提供します。実際の接続処理は通常コアが担います。互換性を調べる際は、ウィンドウのタイトルにClashと表示されているかだけでなく、クライアント名とコアのバージョンを記録してください。古い設定は移行できることが多いものの、新しいプロトコルやDNS項目、TUN設定は移行先コアのドキュメントで確認が必要です。

普段はルールモードを選び、設定したルールに従って接続をDIRECTまたはプロキシへ振り分けます。グローバルモードは、コアが受け取った接続をグローバルのプロキシグループに渡すため、ルールが原因かを短時間で切り分ける際に便利です。ただし、システム上のすべてのアプリがプロキシ経由になるわけではありません。DIRECTモードでは、コアが処理する接続を宛先へ直接送信するため、比較テストに使えます。モードを切り替えたら、該当するプロキシグループの選択先も確認してください。グローバルグループでもDIRECTが選ばれている場合があります。既存の接続は切り替え前の経路を使い続けることがあるため、テスト時は接続し直してください。

システムプロキシは、デスクトップ環境やOSの設定にローカルプロキシのアドレスを登録します。主にその設定を参照するアプリに適用され、通常は仮想ネットワークインターフェースを作成しません。TUNは仮想インターフェースとルーティングを使い、より多くの接続を処理します。システムプロキシに対応していないアプリに適していますが、サービスコンポーネントや追加の権限が必要になることがあります。どちらの方式でも、すべての通信が必ずプロキシを通るとは限りません。ルート、除外設定、アプリの動作によって結果は異なります。まずシステムプロキシでサブスクリプションとノードが使えることを確認し、必要に応じてTUNを有効にしてください。複数の設定を同時に変更すると、原因を特定しにくくなります。

サブスクリプションURLにはアカウント情報やアクセス用の認証情報が含まれていることが多く、URLを知る人がノード情報を取得できる場合があります。フォーラムやチャットグループへの投稿、公開スクリーンショットへの掲載は避けてください。相談時はクライアント名、コアのバージョン、エラーの発生時刻、機密情報を隠したログを共有すれば十分です。ノードのパスワード、サブスクリプションURL、コントロールAPIのキーも必ず伏せてください。クライアント自体がノードアカウントを提供するわけではありません。有効期限、通信量、サービスの状態はサブスクリプション提供元に確認してください。URLを公開してしまった場合は、提供元の管理画面でURLを再発行し、クライアントの登録情報も更新してください。

クライアントの設定またはサブスクリプション画面を開き、URLから設定を追加する項目を選んで、提供元から案内されたURL全体を貼り付けます。ダウンロードが完了したら、その設定を使用中に切り替えてください。ボタン名はクライアントによって異なりますが、設定のダウンロードと有効化は別の操作です。項目不足や解析エラーが表示されたら、提供元がClashまたはmihomoに対応した形式を提供しているか確認してください。WebサイトへのログインURLや、他のクライアント専用の形式では利用できません。まず対応形式を提供元に問い合わせましょう。変換が必要な場合は、変換サービスがサブスクリプション全体を読み取る可能性を確認し、出所不明のオンラインサービスに個人用URLを渡さないでください。

まず、クライアントの手順に従ってサービスコンポーネントをインストールし、起動していることを確認します。次にログを調べ、仮想インターフェースの作成失敗や権限拒否が記録されていないか確認してください。Linuxでは利用可能なTUNデバイスも必要になるため、/dev/net/tun が存在するか確認します。コンテナや制限付きの仮想環境では、デバイスや必要なネットワーク権限が許可されていない場合があります。GUIクライアント全体を常時管理者権限で実行したり、デバイスの権限を安易に緩めたりしないでください。サービスが正常に動作してからTUNを有効にします。それでも失敗する場合は、ディストリビューション、インストール形式、エラーの原文を記録し、クライアントの権限設定手順を一つずつ確認してください。

まず、パッケージがディストリビューションとCPUアーキテクチャに合っているか確認します。DEBは主にDebian・Ubuntu系、RPMはFedoraなどで使われます。ファイル名にLinuxとあるだけでインストールしないでください。uname -m の結果を確認し、x86_64とaarch64を区別します。起動しない場合は端末からクライアントを実行し、依存関係の不足やサンドボックスに関するエラーを記録してください。ポータブル形式でも、システムのランタイムが必要な場合があります。詳細はプロジェクトの説明を確認してください。セキュリティ機能を先に無効にするのではなく、ディストリビューションに適したパッケージを使い、ダウンロードページで現在提供されている形式を確認しましょう。

AppContainerで動作する一部のWindowsアプリには、ループバック接続の制限があります。システムプロキシがローカルポートを指していても、ローカルプロキシに接続できない場合があります。その場合はクライアント付属のループバック免除ツールを使い、必要なアプリだけを許可してください。実行時に管理者の確認が求められることがあります。すべてのストアアプリが同じ実行方式とは限らず、接続失敗の原因が常にループバック制限とは限りません。操作前に、通常のブラウザーでプロキシを使えることと、対象アプリがシステムプロキシを参照していることを確認してください。TUNで通信を処理する場合も、すべてのアプリを一括で許可するのではなく、改めて動作を確認しましょう。

レイテンシテストは通常、指定されたテスト先にリクエストを送り、その時点の応答状況を測るものです。継続的なダウンロード速度を示すものではなく、すべてのWebサイトの表示速度を保証するものでもありません。まずテスト先と実際の接続先が近い条件か確認し、同じノード、Webサイト、ネットワークで比較してください。ページの読み込みにはDNS、接続先サーバー、パケットロス、接続の再利用も影響します。短時間に大量の速度テストを行うと、接続負荷が増えることもあります。ノードを選ぶ際は、レイテンシの安定性を確認してから、実際のページ表示やファイル転送を試してください。一覧で最も低い数値だけを追い求める必要はありません。

ルールは通常、上から順に評価されます。まずクライアントがルールモードになっているか確認し、接続ログで実際に一致したルールとプロキシグループを調べてください。自作ルールは、先に一致する可能性のある広範なルールより上に置きます。特にMATCHより後ろに置かないでください。次に、ドメインルールとIPルールのどちらを使っているか、コアがドメイン情報を取得できているかを確認します。設定を変更したら再読み込みし、対象への接続もやり直してください。既存の接続では経路が変わらないことがあります。サブスクリプション更新で編集内容が上書きされる場合は、クライアントの上書き・マージ機能でローカルルールを保存し、ダウンロードした元ファイルを繰り返し編集しないようにしましょう。

リモートのサブスクリプションファイルと、クライアントのローカル上書き設定を区別してください。前者は更新時に全体が置き換わることがあります。ポート、ルール、個別のプロキシ設定を保存するには、後者を使います。自動更新を設定する前に、クライアントが上書き設定のマージに対応しているか、リスト形式の項目が追加されるのか置き換えられるのかを確認しましょう。ノートPCがスリープ中、またはクライアントが終了していると、定期更新が予定どおり実行されない場合があります。復帰後に更新されるかどうかも実装によって異なります。更新後は現在の設定、プロキシグループの選択、ログを確認し、読み込みが成功したことを確かめてください。バックアップには上書き設定ファイルと関連する設定を含め、個人用サブスクリプションURLを含むファイルは安全に保管しましょう。

多くのコマンドラインツールはデスクトップ環境のシステムプロキシを自動では参照しません。プロキシ環境変数またはツール独自の設定が必要です。まずクライアントでローカルの待ち受けアドレスとポートを確認し、現在のターミナルでHTTP_PROXY、HTTPS_PROXY、またはツールが対応するALL_PROXYを一時的に設定してください。他の人のポート番号をそのまま使わないでください。環境変数の大文字・小文字、SOCKS、DNS名前解決の場所への対応はツールによって異なるため、各ツールのドキュメントを確認しましょう。テストが成功してから永続化を検討してください。プロキシを解除する場合は、古い環境変数やGit専用の設定も削除し、クライアント終了後にターミナルが使えないローカルポートへ接続し続けないようにします。

まずエラーの種類を記録し、システム時刻、現在のネットワーク、サブスクリプション提供元のアカウント状態を確認します。401や403はアクセス権、URLの状態、提供元の制限が関係することがあります。404はパスの変更を示す場合がありますが、ステータスコードだけで原因を断定できません。タイムアウトやTLSエラーの場合は、ネットワーク、証明書、端末の時刻も確認してください。応答内容がログインページになっている場合、設定ファイルを取得できていません。クライアントがプロキシ経由で更新する設定になっているか確認し、すでに使えないノードに更新を依存させないようにします。最後に使えた設定をすぐ削除せず、まずバックアップを取ってから、URLの再発行が必要か提供元に問い合わせてください。

まずプロキシを無効にして、基本のネットワーク接続を確認します。次にサブスクリプションが有効か、端末の時刻が正しいか、現在の設定が実際に読み込まれているかを確認してください。ノードを一つ選び、接続ログでドメインの名前解決失敗、接続タイムアウト、ハンドシェイク失敗、認証失敗を区別します。エラーによって対処方法は異なります。速度テストだけがタイムアウトし、Webサイトには接続できる場合は、判断する前にテスト先を変更してください。複数のノードに接続できない場合は、別のネットワークでも試し、ルーティングの競合を避けるため、他のVPNやネットワークフィルターを一時的に終了します。再インストールを繰り返すより、具体的なエラーを記録する方が役立ちます。DNS、TUNのスタック、ノードのプロトコルを同時に変更しないでください。

まずコアが実行中であることと、ローカルプロキシのポートがシステム設定と一致していることを確認します。次にクライアントの接続ログに対象アプリが表示されるか確認してください。記録がない場合、アプリがシステムプロキシを参照していないか、独自のプロキシ設定が残っている可能性があります。記録はあるのに直結する場合は、一致したルールとプロキシグループの選択を確認しましょう。Linuxでは、デスクトップ環境、ブラウザー、ターミナルによってプロキシ設定の参照方法が異なります。クライアントが異常終了すると、停止したポートを指すシステムプロキシ設定が残ることがあります。その場合はシステムプロキシを無効にしてネットワークを復旧してから、クライアントを再起動してください。アプリを十分にプロキシ経由にできないと確認できた場合に限り、TUNを検討しましょう。複数のプロキシツールを同時に重ねるのは避けてください。

名前解決の経路を確認する必要があるサインですが、IPアドレスへの直接アクセスとドメイン名へのアクセスでは、異なる証明書や仮想ホストが使われることがあります。一度のテストだけで原因を断定しないでください。まずOSの名前解決ツールで対象ドメインを解決できるか調べ、コアのログに記録されたDNSリクエストやエラーと照合します。ブラウザーのセキュアDNS、OSの暗号化DNS、クライアントのDNS処理が同時に有効になっていないか確認し、各段階でどの経路が使われているか把握してください。設定を変更したら関連するキャッシュを消去して再接続します。fake-ipを使う場合は、出所不明の設定を混在させないよう特に注意してください。まずクライアントの既定のDNS設定に戻して比較し、カスタム設定を一つずつ追加しましょう。