クライアントとカーネルの選び方
1. Clashをダウンロードするときは、クライアント名とOSのバージョンのどちらを先に確認すべきですか？
まず OS とプロセッサのアーキテクチャを確認し、次にクライアントが使用するカーネルを見ます。Clash はプロキシ設定とルール体系を指す一般的な呼び方で、実際には GUI クライアントまたはコマンドラインプログラムが必要です。Windows、macOS、Android、iOS、Linux ではインストール方法が異なり、同じ名前のインストーラーでも x64、ARM64 などに分かれている場合があります。
Windows の一般的な PC では x64 版を使うことが多く、ARM プロセッサ搭載端末には ARM64 版が必要です。macOS では Intel と Apple シリコンを区別します。合わないパッケージを選ぶと、インストールできない、起動直後に終了する、追加の互換変換が必要になるといった問題が起こります。アーキテクチャが分からない場合は、端末の発売年ではなく、システム情報の「システムの種類」または「チップ」を確認してください。
カーネルについては、現在も保守されているクライアントの多くが Mihomo を採用しています。これは Clash Meta を発展させたカーネルで、一般的な Clash 設定構造に対応し、プロキシプロトコル、ルール、DNS、TUN の機能を拡張しています。クライアントの画面とカーネルは別の層です。画面はサブスクリプション管理、オン・オフ操作、ログ表示を担い、カーネルは接続の確立、ルールの実行、通信の処理を担います。そのためクライアントを比較する際は、カーネルのバージョン、更新状況、設定の互換範囲も確認しましょう。
2. インストール後、すぐにネットワークへ接続できないのはなぜですか？
クライアントのインストール完了は、プログラムが起動できることを示すだけで、プロキシ経路が確立したことを意味しません。有効な設定、接続可能なノード、アプリの通信を Clash に渡す接続方式が必要です。一般的な流れは、サブスクリプションまたはローカル設定を読み込み、設定を更新し、プロキシノードを選び、システムプロキシを有効にしてからブラウザでテストすることです。
画面に空の設定ページしか表示されない、またはプロキシグループにノードがない場合、利用可能なリモート出口がありません。ノードを選んでいてもシステムプロキシが無効なら、ブラウザは直接接続する可能性があります。一部のアプリは OS のプロキシ設定を無視するため、通常のシステムプロキシでは通信を取り込めません。その場合はアプリ内にプロキシアドレスを個別に入力するか、必要性を確認したうえで TUN モードを有効にします。
サブスクリプションの登録と更新を確認する方法
3. サブスクリプションURLはブラウザに貼り付けますか、それともクライアントに登録しますか？
サブスクリプションURLは、クライアントの設定、サブスクリプション、または Profiles ページに追加します。ブラウザでURLを開くのは、サーバーが内容を返すか確認するためだけで、クライアントへの登録の代わりにはなりません。サービスによって返される内容は YAML 設定、エンコードされたノード一覧、サーバー側で変換が必要な専用形式など異なります。ノードとプロキシグループを生成するには、クライアントが対応する構造を認識できなければなりません。
登録時はURL全体をコピーし、前後の空白、改行、チャットアプリが付けた句読点を混入させないでください。サブスクリプションURLにはアカウント識別用のパラメータが含まれることが多いため、機密情報として扱い、公開ページ、スクリーンショット、ログに掲載しないでください。サービスに Clash または Mihomo 専用の登録入口がある場合は、他クライアント向け形式をそのまま貼り付けず、専用入口を優先します。
登録後は3点を確認します。設定項目に更新時刻が表示されているか、プロキシグループにノードがあるか、ログに解析エラーがないかです。「ダウンロード成功」と表示されただけでは、設定を読み込めるとは限りません。ダウンロードに成功しても YAML 構造が互換性を持たなければ、カーネルが有効化を拒否することがあります。
4. サブスクリプションの更新に失敗した、または更新後もノードが変わらない場合、最初に何を確認しますか？
まず「内容を取得できなかった」のか、「取得したが反映されていない」のかを切り分けます。前者ではタイムアウト、接続失敗、異常な HTTP ステータスがよく見られます。後者では設定解析エラー、空のプロキシグループ、現在のアクティブ設定が旧版のままといった症状が現れます。次の順で確認してください。
- 端末自体がサブスクリプションサーバーへアクセスできることを確認し、システムの日付、時刻、タイムゾーンが正しいか確認します。
- サブスクリプションURL全体をコピーし直し、アカウント状態と有効期限に変更がないか確認します。
- クライアントのログを確認し、エラーがダウンロード、解析、設定切り替えのどの段階で発生したか判断します。
- 更新完了後、新しい設定が現在のアクティブ設定になっていることを確認します。リストに保存されただけでは不十分です。
- プロキシグループの選択を確認します。設定更新でノード一覧が再構築されても、プロキシグループが以前の選択を保持したり、デフォルト項目に戻ったりすることがあります。
自動更新の間隔は、クライアントまたは設定内のサブスクリプションプロバイダーのパラメータで決まり、すべてのクライアントが起動時に即時更新するわけではありません。手動更新でも短時間に連続クリックしないでください。並行リクエストがサーバー側の制限を招く可能性があります。更新後もノード名が同じだからといって内容が変わっていないとは限りません。サーバーアドレス、ポート、通信パラメータは、名前を変えずに更新されることがあります。
完全なリモート設定を使っている場合、更新によってローカルで直接編集したルールが上書きされることがあります。長期的に残したいカスタムルールには、クライアントが対応するオーバーライド、マージ、スクリプト機能を使い、変更前に元の設定を復元用として保存してください。オーバーライド構文の実装はクライアントごとに完全には一致しないため、クライアントを移行する際は再検証が必要です。
Rule、Global、Direct、TUN の使い分け
5. Rule、Global、Direct の3つのモードにはどのような違いがありますか？
普段は Rule、つまりルールモードを選ぶのが一般的です。カーネルはルールを上から順に確認し、条件に一致すると、指定されたプロキシグループへ渡す、直接接続する、または拒否します。ルールはドメイン、ドメインサフィックス、IPネットワーク、プロセスなどの条件で照合でき、具体的な機能はカーネルとクライアントによって異なります。ルール一覧の末尾には、前のルールに一致しなかったリクエストを処理するフォールバック項目が置かれることが一般的です。
Global はグローバルモードです。Clash に入った接続は一律でグローバルプロキシグループに渡されますが、LAN アドレスやカーネル内部の接続などは、設定や実装上の制限を受ける場合があります。そのため「グローバル」はすべてのルール境界を無視する意味ではありません。ルール分岐の誤りでサイトに接続できないか一時的に判断したい場合や、短時間だけ出口を統一したい場合に適しています。あらゆる問題の切り分けを Global だけで行うことはおすすめしません。
Direct はダイレクト接続モードです。カーネルに入った接続は通常、リモートプロキシへ渡されず、ローカルネットワークから直接アクセスします。プロキシノードが原因かどうかを素早く確認するのに役立ちます。Direct でもアクセスできない場合は、ローカルネットワーク、DNS、対象サービス、アプリ自体に問題がある可能性が高くなります。Direct が正常で Rule が異常なら、ルールの一致結果とプロキシグループを確認します。
| モード | 処理方法 | 適した場面 | 主な確認ポイント |
|---|---|---|---|
| Rule | ルールを順番に照合 | 日常的な振り分け | ルールの一致結果、プロキシグループの選択 |
| Global | 一律でグローバルプロキシグループへ渡す | 出口の一時テスト | グローバルグループで選択中のノード |
| Direct | ローカルネットワークから直接接続 | 比較による切り分け | ローカルネットワークと DNS |
6. TUN モードはいつ有効にすべきですか？
まずはシステムプロキシを使い、アプリがシステムプロキシを読み取らない場合、より多くの種類の通信を取り込みたい場合、または複数のプログラムを一括して処理したい場合に TUN を検討します。システムプロキシは主に OS のプロキシ設定に従うアプリへ HTTP または SOCKS 接続を提供します。一方 TUN は仮想ネットワークインターフェースで IP 通信を受け取るため、対応範囲が広い反面、ルーティング、DNS、権限、ファイアウォールに関する追加要素が生じます。
TUN を有効にする前に、通常のノードテストが成功し、Rule モードでブラウザ接続を正常に処理できることを確認してください。そうしないと「ノードの障害」と「仮想 NIC の障害」が重なります。Windows では管理者権限やサービスのインストールが必要になる場合があります。macOS ではネットワーク拡張の許可が表示されることがあり、Linux ではネットワークデバイスの権限とルーティングルールが関係します。権限を許可していないと、画面上のスイッチがオンでも実際のインターフェースが確立されないことがあります。
TUN を他の VPN、仮想マシンのネットワーク、コンテナネットワーク、セキュリティソフトと同時に動かすと、ルート優先度が競合する可能性があります。ネットワーク全体が切断される、LAN 機器に届かない、クライアント終了後も異常が続く場合は、まず TUN を無効にし、他の仮想ネットワークプログラムを終了してからシステムネットワークを再テストします。DNS とルートのパラメータを一度に大量に変更しないでください。毎回1項目だけ調整すれば、どの層が結果に影響したか判断できます。
ノード、システムプロキシ、DNS、ログのトラブルシューティング
7. ノードの遅延は正常なのに、なぜウェブページを開けないのですか？
遅延テストで確認できるのは、特定のテスト方法でクライアントが応答を受け取れたことだけで、対象サイトへの接続全体を示すものではありません。クライアントによって、TCP ハンドシェイク、HTTP リクエスト、指定されたテストアドレスなど、遅延の測定方法が異なります。テストに成功しても、実際のアクセスはノードの出口、対象サイト、DNS 解決、ルール分岐、通信プロトコルの状態に左右されます。
アクセス時のログに対象ドメインが表示されるか確認します。ログがまったく出ない場合、通信が Clash に入っていない可能性が高いため、システムプロキシ、ブラウザプロキシ、TUN の状態、アプリ独自のネットワーク設定を確認します。ログにドメインが出ているのに想定外のプロキシグループへ割り当てられているなら、問題はルールまたはプロキシ選択にあります。タイムアウト、ハンドシェイク失敗、接続拒否が表示される場合は、同じプロキシグループ内の別ノードに切り替え、単一ノードの障害か比較します。
遅延の数値を帯域幅や安定性とそのまま同一視することもできません。低遅延のノードでも混雑している場合があり、高遅延でも継続通信では安定する場合があります。ノードは一覧の最小値だけでなく、接続成功率、連続アクセス時の挙動、ダウンロード速度を合わせて選びましょう。
8. システムプロキシを有効にしても通信されない場合、どのポートを確認すべきですか？
まず、クライアント設定のプロキシ待受ポートと、OS に現在入力されているポートが一致しているか確認します。一般的な設定には HTTP ポート、SOCKS ポート、または両方の通信を受け付ける mixed-port があります。コントローラーポートはクライアント画面とカーネルの通信に使うもので、ブラウザ用のプロキシポートではありません。混同しないでください。
たとえば次の設定では、ローカルのアプリが 7890 の混合ポートへ接続できます。LAN 端末からの接続を許可するかどうかは、allow-lan と待受アドレスで決まります。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info自分の端末だけで使う場合は、待受範囲を限定し、トラブルシューティングのためだけに LAN アクセスを公開しないでください。ポートを別のプログラムが使用していると、カーネルログに bind、listen、address already in use などのエラーが表示されます。その場合は使用中のプログラムを終了するかポートを変更し、システムプロキシの設定も合わせて更新します。YAML だけを変更して設定を再読み込みしなければ、実行中の待受ポートは変わりません。
ブラウザ拡張機能、開発者ツール、他のプロキシソフトがシステム設定を上書きすることがあります。切り分けの際は追加のプロキシ入口を一時的に無効にし、接続方式を1つだけ残してください。そうしないと、ブラウザが古いポートへ接続したり、「ブラウザプロキシが別のプロキシソフトを経由し、そこから Clash に戻る」ループが発生したりします。
9. DNS が原因と考えられる症状は何ですか？
IP アドレスではサービスにアクセスできるのにドメインでは失敗する、一部のドメインが異常なアドレスへ繰り返し解決される、ネットワークを切り替えても古い結果が残る場合は、DNS を確認します。Clash の設定ではカーネルに DNS 処理を任せ、ルールに応じて fake-ip や redir-host などのモードを使えます。具体的な項目と挙動はカーネルのバージョンによって異なります。初心者は出所不明の DNS 設定を大量にそのままコピーしないでください。待受アドレス、上流 DNS の種類、拡張モードは現在の接続方式と組み合わせる必要があります。
トラブルシューティングでは、まずログ上のドメインが正常に解決されているかを確認し、次に OS の DNS リクエストが Clash に入っているかを確認します。システムプロキシは主にアプリが作るプロキシ接続を処理するもので、すべての独立した DNS リクエストを取り込むとは限りません。TUN モードでは DNS ハイジャックと仮想アドレスのルーティングも確認します。Clash を終了しても名前解決が異常な場合は、OS の DNS キャッシュを消去し、ネットワーク接続を再起動して、ルーターやローカルネットワークが提供する DNS が正常か確認してください。
fake-ip を使用すると、アプリには予約アドレス範囲の仮想的な結果が表示され、カーネルがそのアドレスをドメインへ対応付けてルール照合します。これらの仮想アドレスを、実際のサーバーアドレスとして長期保存しないでください。一部の LAN サービス、ゲーム、特殊な DNS 動作に依存するプログラムでは互換性リストへの追加が必要な場合がありますが、ログと実際の症状を確認しながら1項目ずつ追加し、多数のドメインを一度に除外しないでください。
10. まったく接続できない場合、最も効果的な確認手順は？
効果的なトラブルシューティングには段階的な切り分けが必要で、クライアントの再インストールを繰り返すだけでは解決しません。設定、ノード、通信の取り込み、ルール、システムネットワークのどの層に問題があるか特定できるよう、変数の少ない状態から始めます。
- ローカルネットワークを確認：Direct に切り替えるか一時的にプロキシを無効にし、通常のウェブサイトへ直接アクセスできるか確認します。基礎ネットワークが切断されている場合は、Wi-Fi、有線 LAN、モバイル通信を復旧させます。
- 設定の読み込みを確認：現在のアクティブ設定名と更新時刻を確認し、ログに YAML 解析エラー、未対応フィールド、ファイル読み込みエラーがないか調べます。
- ノード接続を確認：現在のプロキシグループに確実に存在するノードを選び、遅延テストを実行して、ウェブページへのアクセス中にリアルタイムログを確認します。
- 通信の取り込みを確認：システムプロキシを有効にし、OS のプロキシアドレスとポートを確認します。リクエストログが1件もない場合は、まず接続方式の問題に対処します。
- ルール結果を確認：Rule モードで対象ドメインがどのルールに一致し、どのプロキシグループへ渡されたかを確認し、そのグループの現在の選択を照合します。
- Global と Direct を比較：Global はルールが誤った出口を選んでいるか、Direct はローカルネットワークから直接アクセスできるかを判断するのに役立ちます。
- 最後に TUN と DNS を確認：基本的なプロキシ経路が利用できることを確認してから、TUN、DNS 拡張、アプリ単位の互換設定を有効にします。
ログレベルは通常 info で初期判断に十分です。さらに詳しく調べる必要がある場合は、短時間だけ詳細度を上げてもよいでしょう。ただしログにはアクセス先ドメイン、ノード名、サーバーアドレス、ローカルネットワーク情報が含まれる可能性があります。共有する前にアカウントパラメータと機密設定を削除してください。調査後は通常のログレベルに戻し、大量の記録を長期間残さないようにします。
変更後に新たな問題が発生した場合は、設定を追加し続けるより、最後に正常動作していた設定へ戻るほうが効率的です。サブスクリプション、オーバーライドルール、DNS、TUN は分けて検証します。まず元のサブスクリプションが読み込めることを確認してからローカルオーバーライドを追加し、システムプロキシが使えることを確認してから TUN を有効にします。この順序なら、「登録は成功したのに接続できない」問題の大半を具体的な工程まで絞り込めます。
OS に合ったクライアントを選ぶ
OS のアーキテクチャ、クライアントのカーネル、サブスクリプション形式を確認してから、ダウンロードして設定を登録します。基本接続ができたら、ガイドに沿ってルールモード、システムプロキシ、TUN を設定できます。