まずはクライアントの画面とプロキシコアの違いを理解する
Clashクライアントは通常、GUIとプロキシコアで構成されています。GUIではサブスクリプションの追加、プロキシグループの表示、システムプロキシの切り替えを行い、コアは設定の読み込み、ルールの照合、接続の確立を担います。Clash Verge RevやFlClashなど、クライアントによってメニューの位置は異なります。また、mihomoを使うクライアントには、オリジナルのClashにはない設定機能が備わっている場合もあります。画面に「Clash」と表示されているだけで、すべての項目や機能が同じとは限りません。
この記事では、デスクトップクライアントで一般的な画面構成に沿って操作を説明します。「プロキシ」「設定」「ログ」はそれぞれ該当する機能画面を指します。クライアントによっては「設定」を「サブスクリプション」と呼ぶこともあります。Clash Verge Revでよく見られるレイアウトを例にすると、左側の「設定」からファイルを読み込み、「プロキシ」でグループを選び、最後に「設定」でシステムプロキシを確認します。バージョンによってボタン名が変わる場合があるため、現在の画面表示と実際に適用されている設定を確認してください。
| 画面・エリア | 主な役割 | 最初に確認する項目 |
|---|---|---|
| プロキシ画面 | モードやプロキシグループを確認し、接続先を切り替える | 現在のモードと、ルールから実際に参照されているグループ |
| 設定画面 | 設定の追加・更新・選択 | 現在有効な設定と直近の更新結果 |
| ログ画面 | コアのイベントやエラーを確認する | エラー発生時刻、レベル、接続先アドレス |
| 接続画面 | アクティブな接続と適用されたルールを確認する | 接続がDIRECTか、どのプロキシグループを経由しているか |
| 設定画面 | プロキシの入口、サービス、起動時の動作を管理する | システムプロキシ、TUN、待ち受けポート |
プロキシ画面：モード、プロキシグループ、ノードの選択
ルール・グローバル・ダイレクトは、3種類のノードではない
プロキシモードによって、通信の経路が決まります。rule は設定内の rules を上から順に照合します。global は通常、コアに入った接続をグローバル設定のプロキシグループに渡します。direct では、コアに入った接続を直接接続します。サイトごとに接続先を振り分ける場合は、まず「ルール」モードを選びましょう。「グローバル」にしても、そもそもクライアントを経由していないアプリの通信まで自動で取り込まれるわけではなく、TUNが有効になるわけでもありません。
- ルールモード：LAN内や指定したサイトへの直接接続を維持しながら、それ以外の接続をプロキシ経由にしたい場合に適しています。
- グローバルモード：問題の原因がルールによる振り分けかどうかを一時的に確認する場合に使います。確認後は元のモードに戻してください。
- ダイレクトモード：ローカルネットワークとの比較に使えます。ただし、DNS処理はコアを経由する場合があり、クライアントを完全に終了した状態とは異なります。
まずルールから参照されているプロキシグループを確認する
「ノード」は個々のプロキシ接続先、「プロキシグループ」は接続先を選ぶ仕組みです。select タイプのグループでは手動選択ができ、url-test はヘルスチェックの結果に応じて接続先を自動選択します。fallback は利用可能かどうかと優先順位に基づいて選択します。プロキシグループのカードが複数あっても、すべてを変更する必要はありません。まず接続画面で対象の通信がどのグループに振り分けられたかを確認し、そのグループの接続先を変更しましょう。
以下は画面間の関係を説明するための設定例で、完全なサブスクリプションではありません。手動選択 の候補は DIRECT のみのため、海外向けのプロキシ接続先はありません。実際のサブスクリプションでは、定義済みのノードやプロキシプロバイダーがここから参照されます。
mode: rule
proxy-groups:
- name: 手動選択
type: select
proxies:
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,手動選択
- MATCH,DIRECTこの設定では、example.com とそのサブドメインへのアクセスは「手動選択」に一致します。それ以外の接続先は最後の MATCH に一致します。画面上にほかのグループが表示されていても、ルールから参照されていなければ、そのグループを切り替えても今回の接続先は変わりません。
遅延テストの結果は、テスト対象への応答を示すもの
プロキシ画面の「速度テスト」は、指定したURLへの接続性や遅延を測るもので、通常はダウンロード速度の測定ではありません。たとえば80 msと表示されても、それはその時点でテスト対象に接続した結果を示すだけです。動画の読み込み速度を保証したり、すべてのサイトにアクセスできると判断したりはできません。「タイムアウト」はテスト先に接続できない、DNSに問題がある、ノードに障害があるなど、さまざまな原因で発生するため、ログもあわせて確認してください。
設定画面：サブスクリプションの追加・有効化・更新
設定を追加しただけでは、現在の設定として有効にならない
設定画面では、コアに読み込ませる設定の取得元を管理します。リモートサブスクリプションは通常、URLからYAMLを取得します。ローカル設定はファイルから読み込みます。クライアントによってはノード単体のリンクや別形式のサブスクリプションにも対応しますが、Clash YAMLのみを受け付けるものもあります。読み込みに失敗した場合は、何度も更新するのではなく、まず形式を確認してください。
- 「設定」または「サブスクリプション」画面を開き、URL入力欄かリモート設定の追加メニューにサブスクリプションURLを貼り付けます。
- 「追加」または「ダウンロード」を実行し、設定のカードが表示されるまで待ちます。解析エラーが出ていないか確認してください。
- 追加した設定を選び、「現在」「有効」などの表示や選択中のマークを確認します。カードが追加されても、現在の設定が自動で切り替わるとは限りません。
- 「プロキシ」画面に戻り、目的のプロキシグループが表示されているか確認します。古いグループのままなら、設定の切り替えに失敗していないか確認してください。
サブスクリプションURLにはアクセストークンが含まれていることが多いため、認証情報として扱ってください。トラブルの相談では、ドメイン名やステータスコード、エラーの種類だけを伝え、URL全体を公開コメントに貼らないようにしましょう。クライアントに表示されるQRコードにも、同じ認証情報が含まれている場合があります。
サブスクリプションの更新とクライアントのアップデートは別
設定カードの「更新」は通常、リモートの設定を再ダウンロードし、ノードやルール、プロキシグループを更新します。ソフトウェアのアップデートはクライアント本体の更新、コアのアップデートはプロキシエンジンの更新です。それぞれ役割が異なります。特定のプロトコルがサポートされない場合、サブスクリプションを更新しても解決するとは限りません。現在のコアがそのプロトコルや項目に対応しているか確認してください。
リモート設定を手動で編集しても、次回のサブスクリプション更新で変更が上書きされる場合があります。ポート、DNS、ルールの変更を継続して使うには、クライアントに用意されているオーバーライド、マージ、拡張設定の機能を優先して利用してください。保存後は「実行中の設定」や「適用中の設定」も確認しましょう。元ファイルに項目が記載されていても、クライアントで統合された後に同じ値が適用されるとは限りません。
- HTTP 401 または 403：サブスクリプションの認証情報、サービスの稼働状況、アクセス権限を確認してください。
- HTTP 404：URL全体が正しいか、パスの有効期限が切れていないかを確認してください。WebページのURLをサブスクリプションURLとして使っていないかも確認しましょう。
- YAMLの解析エラー：インデントや項目の型、サーバーからHTML形式のエラーページが返されていないかを確認してください。
- ダウンロードのタイムアウト：ローカルネットワークからサブスクリプションのドメインに接続できるか確認してください。プロキシ経由で更新できるクライアントでは、更新に使うプロキシが利用可能かも確認しましょう。
設定画面：システムプロキシ、ポート、TUNの設定
Clash Verge Revでよく見られるレイアウトでは、システムプロキシとTUNの設定は「設定」内の該当項目にあります。クライアントによってはホーム画面に切り替えボタンがあります。設定を探すときは項目名を確認し、「起動時に開始」と「プロキシ有効」を混同しないようにしましょう。起動時に開始する設定はプログラムを起動するだけです。サービスモードは通常、コアの実行に必要なシステム権限を提供します。
システムプロキシはOSの設定に従うアプリで利用できる
システムプロキシを有効にすると、OSのHTTPプロキシがローカルの待ち受けアドレスを指すようになります。以下の 127.0.0.1:7890 は説明用の例で、すべてのクライアントのデフォルトポートではありません。有効な設定の mixed-port が 7897 なら、プロキシを手動設定するアプリにも 7897 を指定します。解説記事にある 7890 をそのまま使わないでください。
# ローカル接続用の設定例。完全な設定ではありません
mixed-port: 7890
allow-lan: false
mode: rule
log-level: infomixed-port は、同じポートでHTTPとSOCKSのプロキシ接続を受け付けます。allow-lan: false はLANからのアクセスを制限します。ほかのデバイスからこのPCのプロキシを利用するには、待ち受けアドレスやファイアウォール、認証の設定も必要です。試しに使うだけの目的で、LAN共有を有効にしないでください。
TUNはより多くの通信を取り込む機能
TUNは仮想ネットワークインターフェースとルーティングを使って、より多くの通信をコアに渡します。システムプロキシに従わないアプリでよく使われます。OSの権限、仮想ネットワークインターフェース、コアの対応が必要で、システムプロキシの切り替えと同じ機能ではありません。初めて使う場合は、まず通常のブラウザーがシステムプロキシ経由でアクセスできることを確認してからTUNを試してください。ネットワークに接続できなくなった場合は、TUNをオフにして基本的な接続が戻るか確認します。
ログ画面：レベルの絞り込みとエラーの特定
表示レベルの絞り込みと、ログの記録レベルを区別する
ログ画面ではコアの動作イベントを確認できます。サブスクリプションのノード一覧ではありません。一般的なログレベルには debug、info、warning、error があり、設定で silent を指定すると通常のログ出力を停止できます。画面上のレベル絞り込みは、受信済みのログのうち何を表示するかを決めます。一方、コア設定の log-level は、どのレベルのログを記録するかを決めます。コアが info 以上のみを出力している場合、画面でDebugを選んでも、生成されなかったデバッグ情報は表示されません。
通常の利用なら info で十分です。複雑な問題を再現する場合は、一時的にコアのログレベルを debug に設定し、設定を再読み込みしてから同じ操作をもう一度行い、終わったら元に戻してください。デバッグログにはドメイン名、IPアドレス、接続の詳細が含まれることがあります。共有する前に、サブスクリプションのトークンや認証情報、公開する必要のないアクセス履歴を削除しましょう。
エラーを具体的な操作と照らし合わせる
- 14:32のように時刻を記録し、問題のサイトに一度だけアクセスします。
- ログ画面でその時刻付近の記録を探し、接続先のドメイン、出口の名前、エラーの原因を優先して確認します。
- 接続画面で適用されたルールとプロキシグループの経路を確認し、想定したノードを経由しているか調べます。
- ノードを変更するなど条件を1つだけ変え、もう一度アクセスして結果を比べます。
| ログの内容 | よくある原因 | 次に行うこと |
|---|---|---|
address already in use | 待ち受けアドレスまたはポートが使用中 | 重複して起動しているコアを終了し、ローカルの待ち受けポートを確認する |
connection refused | 接続先が接続を拒否した、またはサービスが待ち受けていない | 接続先のアドレスとポート、サービスの稼働状況を確認する |
i/o timeout | 接続または読み書きがタイムアウトした | 接続先と出口を確認し、ノードを切り替えて比較する |
| DNSクエリに関するエラー | 名前解決が完了しない、または異常な応答が返された | DNS設定とDNSサーバーへの接続性を確認する |
| 設定の解析に失敗 | 項目、インデント、参照先に問題がある | 設定画面に戻り、エラー行と項目の互換性を確認する |
エラーメッセージは手がかりであり、原因を確定するものではありません。たとえばタイムアウトは、プロキシサーバー側でも接続先サイト側でも起こり得ます。一度のtimeoutだけでサブスクリプションが無効だと判断せず、発生時刻や失敗する範囲、比較テストの結果もあわせて確認してください。
接続画面と初回利用時の確認手順
「このサイトの通信がどこを経由したか」を調べるには、遅延テストより接続画面が役立ちます。一般的には、接続先のドメインやIPアドレス、送受信量、適用されたルール、プロキシグループの経路が表示されます。プロセス名が表示されるかどうかは、プラットフォームや権限、コアの設定によって異なります。アプリが接続画面に表示されない場合、新しい接続が発生していないか、通信がコアに入っていない可能性があります。すぐにクライアントの故障と判断しないでください。
4つの画面で一通り動作を確認する
- 設定画面：対象の設定が有効で、読み込み時にエラーがなかったことを確認します。
- プロキシ画面：ルールモードを選び、対象のプロキシグループで接続先が利用可能か確認します。
- 設定画面：システムプロキシを有効にしてローカルポートを確認します。初回の確認ではTUNを同時に有効にしないでください。
- 接続画面とログ画面：対象サイトにアクセスし、新しい接続に適用されたルールと出口を確認してから、同じ時間帯のエラーを調べます。
ブラウザーは正常で特定のアプリだけ動作しない場合は、まずそのアプリがシステムプロキシに従うか確認してください。必要に応じてHTTPまたはSOCKSの接続先を個別に設定し、その後TUNを検討します。すべてのアプリで接続できない場合は、設定の読み込み、コアの動作、ポートの競合を確認してから、ノードやDNSを調べましょう。各画面の役割に沿って確認すると、サブスクリプションを何度も変更したりクライアントを再インストールしたりするより、問題の範囲を絞り込みやすくなります。
クライアントを終了する前に、システムプロキシが元に戻っているか確認してください。異常終了後にブラウザーがインターネットへ接続できない場合、Windowsでは「設定」→「ネットワークとインターネット」→「プロキシ」で手動プロキシを確認できます。macOSでは「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」を確認してください。クライアントが残したローカルのプロキシ設定だけを解除し、会社や学校で指定されたプロキシ設定はむやみに変更しないでください。