クライアント、サブスクリプションURL、システム時刻を確認
操作を始める前に、端末へ現在もメンテナンスされているClash GUIクライアントがインストールされていることを確認します。クライアントによって似た設定形式を使えますが、画面構成は完全には同じではありません。サブスクリプションの入口が「設定」画面にあるものもあれば、「サブスクリプション」画面が独立しているものもあります。接続スイッチを「システムプロキシ」と呼ぶものもあり、モバイル端末では通常、システムのVPNネットワーク権限を使ってローカルの経路制御を行います。名称が異なっていても、本記事の操作の流れは変わりません。
次に、サービス提供元から発行されたサブスクリプションURLを用意します。通常は https:// で始まる完全なリンクなので、そのままコピーし、パラメーター、空白、末尾の文字を手動で削除しないでください。サブスクリプションURLは設定への入口であり、チャットグループ、スクリーンショット、公開Webページに掲載するものではありません。YAMLテキストやローカル設定ファイルを受け取った場合は、「ファイルから追加」でも設定できますが、本記事では一般的なURL方式で説明します。
最後に、端末の日付、時刻、タイムゾーンが正しいか確認します。時刻のずれはHTTPS接続失敗の原因となり、サブスクリプションを更新できない、Webページの証明書エラーが出る、ノードがすべて利用できないといった症状につながります。WindowsとmacOSでは時刻の自動設定を、AndroidとiOSではネットワーク提供時刻を有効にすることをおすすめします。準備ができたら、まず直接接続でネットワークが使えることを確認してから最初の手順へ進みます。これにより、「元のネットワークの問題」と「プロキシ設定の問題」を分けて判断できます。
サブスクリプションを追加し、設定の読み込みを確認
クライアントを開いたら、「設定」「Profiles」または「サブスクリプション」画面へ移動します。Clash for Windowsでは、左側のナビゲーションにProfilesが表示されることが一般的です。Clash Verge Revなどでは、設定画面の上部にサブスクリプション管理が置かれていることが多く、モバイルクライアントでは右上のプラスボタンから設定を追加する場合があります。「URLから追加」「新しいサブスクリプション」またはリンクアイコン付きの入力欄を見つけたら、先ほどコピーした完全なサブスクリプションURLを貼り付けます。
クライアントによっては設定名の入力を求められます。「日常用」やサービス名など、見分けやすい名前を付ければ十分で、ノードの地域や有効期限をすべてタイトルに入れる必要はありません。自動更新間隔が表示される場合は、まず初期値のままで構いません。基本接続を確認した後、利用頻度に合わせて調整します。「追加」「保存」「ダウンロード」などをクリックすると、クライアントは現在の直接接続を通じて設定を取得します。この時点ではシステムプロキシをすぐに有効にせず、ダウンロードが完了するまで待ちます。
追加できたかどうかは、「保存しました」という表示だけで判断しないでください。設定一覧に新しい項目が表示され、通常は名前、更新時刻、更新ボタンなどが確認できます。その項目をクリックすると、現在の設定として選択されるはずです。続いて「プロキシ」または「Proxies」画面を開き、ノード選択、自動選択、フォールバックなど、設定で定義された複数のプロキシグループが表示されることを確認します。プロキシグループが表示されていれば、YAML設定が解析され、読み込まれたと判断できます。
保存後も一覧に項目が追加されない場合は、まず貼り付け欄に改行、前後の空白、説明文が混ざっていないか確認し、ブラウザーでサブスクリプションURLへ直接アクセスしてみます。ブラウザーでは内容をダウンロードできるのにクライアントだけ失敗する場合は、クライアントを終了して再起動し、ファイアウォールがネットワークアクセスを遮断していないか確認します。ブラウザーでも開けない場合、原因は通常、サブスクリプションURL、アカウント状態、現在のネットワークにあります。まず提供元へ確認し、クライアントのポートを何度も変更しないでください。
設定項目は表示されたのにプロキシ画面が空の場合、WebページのURL、変換ページのURLを追加したか、設定自体に利用可能なプロキシやプロキシグループが含まれていない可能性があります。その場合は誤った設定を削除し、正しいサブスクリプションURLをコピーし直して追加します。サブスクリプション、設定ファイル、プロキシグループの関係は用語解説で確認できます。複雑なYAMLのマージやローカル上書きは上級設定で扱います。
ルールモードと実際の出口を選択
設定を読み込んだら、「一般」「設定」またはモード選択エリアに戻り、Rule、Global、Directの3つの代表的なモードを探します。初回は「ルール」またはRuleモードがおすすめです。ルールモードは設定内のルール一覧を読み込み、ドメイン、IP、アプリの種類、ルールセットなどに応じて、接続を直接接続、プロキシ、指定したプロキシグループへ振り分けます。日常的な標準モードに適しており、LANや普段使うサービスまですべて同じプロキシ出口を経由するのを防げます。
「グローバル」またはGlobalモードでは、接続可能な大半の通信を1つのグローバルプロキシグループへ送ります。特定のWebサイトが強制的なプロキシ経由でアクセスできるか一時的に確認する用途には向いていますが、標準設定として常用するのはおすすめしません。「ダイレクト」またはDirectモードではプロキシを経由せず、元のネットワークを使います。接続前後の比較や、問題がルールに起因するかの切り分けに便利です。3つのモードが変えるのは通信の振り分け方法であり、接続スイッチではありません。Ruleを選んだだけでブラウザーが自動的にプロキシを使い始めるわけではありません。
Ruleモードを選んだら、「プロキシ」またはProxies画面へ移動します。通常、主要な手動選択用プロキシグループがあります。名称は「ノード選択」「PROXY」、またはサブスクリプション提供元が設定した名前などです。そのプロキシグループをクリックし、次の一覧からノードを選びます。初回テストでは、地理的に近く、名前が明確で、「DIRECT」ではないノードを選ぶとよいでしょう。「自動選択」プロキシグループがある場合は、先に遅延テストを実行し、自動選択グループを出口にすることもできます。
遅延テストが示すのは、クライアントからテスト先までの接続時間だけです。Webページのダウンロード速度を意味するものではなく、ノードの安定性を単独で判断することもできません。遅延が低いノードでも実際のページを開けない場合は、同じプロキシグループ内の別のノードに切り替えて再試行します。すべてのノードがタイムアウトする場合も、すぐにTUN、DNS、ルール上書きなどの高度な設定へ進まず、最初の手順に戻ってサブスクリプションを手動更新し、端末の元のネットワークとシステム時刻を確認してください。
プロキシグループは階層化されている場合があります。1階層目で「自動選択」を選び、2階層目で速度テストの結果に基づいてノードを選ぶ構成や、1階層目で地域を選び、2階層目で具体的な回線を選ぶ構成です。現在ハイライトされている項目を追いながら、最終的な出口がDIRECTまたはREJECTではなくなるまで、各階層を確認します。ルールモード、グローバルモード、ダイレクトモードの通信の違いを詳しく知りたい場合はトラブルシューティングの一般的なケースを確認してください。プロキシグループやルールセットのカスタマイズは上級設定で扱います。
ルールモード
設定ルールに従って直接接続とプロキシ接続を振り分ける、標準モードに適した設定です。
グローバルモード
指定した出口を集中して使い、アクセス失敗が振り分けルールに関係するかを確認するのに適しています。
ダイレクトモード
プロキシ出口を経由せず、結果の比較やプロキシ経路の影響を素早く切り分けるために使います。
システムプロキシを有効にして接続を確立
クライアントのホーム画面または一般設定画面に戻り、現在の設定名、Ruleモード、選択中のプロキシグループが変わっていないことを確認してから、「システムプロキシ」または「System Proxy」スイッチを探します。WindowsとmacOSのデスクトップアプリでは通常、このスイッチをオンにするとシステムプロキシのアドレスがClashのローカル待受ポートに向けられます。ブラウザーやシステムプロキシに従う多くのデスクトップアプリは、その後クライアントへリクエストを送り、ルールに基づいて出口が決まります。
スイッチをクリックしたら、オンの状態が維持されるか確認します。すぐにオフへ戻る場合は、他のプロキシ、ネットワークデバッグ、パケットキャプチャーソフトを終了してください。複数のプログラムが同時にシステムプロキシを変更している可能性があります。Windowsではシステムの「ネットワークとインターネット—プロキシ」画面を開き、手動プロキシがクライアントの状態に応じて変化しているか確認できます。ただし、ここで見慣れないポートを手入力するのはおすすめしません。クライアント終了後に使えない設定が残る可能性があるためです。グラフィカルなクライアントにシステムプロキシを管理させ、終了前にスイッチを正常にオフにするのが適切です。
モバイル端末では通常、「システムプロキシ」は表示されず、接続ボタンを押すとVPNネットワーク権限を求められます。これはAndroidのVpnServiceやiOSのネットワーク拡張機能が、ローカルの通信経路制御を開始するときに表示するシステム通知です。インストールしたクライアントが正しいことを確認してから、この権限を許可します。接続に成功すると、通常はシステムのステータスバーにVPNアイコンが表示されます。「同時に実行できるVPNは1つだけ」と表示された場合は、他のVPNやローカルネットワークツールを終了し、クライアントに戻って再接続してください。
一部のゲーム、コマンドラインプログラム、独自のネットワークスタックを使うアプリはシステムプロキシを読み取りません。この場合、デスクトップクライアントにTUNモードがあれば、仮想ネットワークインターフェースを使ってより多くの通信を制御できます。初回設定では、まずシステムプロキシだけを有効にしてブラウザーをテストし、TUN、DNS、ポート、ルートを同時に変更しないでください。通常のWebページがプロキシ経由で開けることを確認してから、必要なアプリに応じてTUNを有効にします。管理者権限、ネットワーク拡張、ファイアウォールの確認が表示された場合は、対象の権限を確認して許可し、クライアントに戻ってTUNが自動的にオフになっていないことを確認します。
システムプロキシを有効にした後、すべてのWebページにアクセスできなくなった場合は、すぐにスイッチをオフにして直接接続を復旧し、現在のノードが利用可能か確認します。次にクライアントを再起動してサブスクリプションを手動更新し、別のノードへ切り替えて再テストします。ネットワークが完全に切断された状態で十数個の設定を続けて変更すると、原因を特定しにくくなります。基本的な接続確認は、設定を解析できる、出口となるプロキシがある、ノードに接続できる、システムプロキシがオンになっている、という順番で行います。
出口、振り分けルール、接続ログを確認
接続後は、スイッチの色だけで動作を判断しないでください。まず普段から直接接続できる通常のWebページを開き、基本的なネットワークが切断されていないことを確認します。次に現在の公開出口アドレスを表示する確認ページへアクセスし、接続後の出口地域とネットワーク情報を記録します。その後、一時的にシステムプロキシをオフにして同じページを更新し、接続前後の結果を比較します。出口が想定どおり変化すれば、ブラウザーがクライアントの経路制御下に入っていることが分かります。
システムプロキシを再びオンにしてRuleモードを維持し、直接接続すべきサイトとプロキシが必要なサイトへそれぞれアクセスします。クライアントの「接続」「Connections」またはログ画面に戻り、直前に発生したドメインの記録を探します。各記録には通常、適用されたルール、使用されたプロキシグループ、最終的な出口が表示されます。直接接続すべきリクエストがDIRECTになり、プロキシが必要なリクエストが先ほど選んだプロキシグループに入っていれば、基本的な振り分けは想定どおりです。
出口が変化しない場合は、ブラウザーで独自のプロキシ拡張機能が有効になっていないか、システムプロキシを迂回していないか確認します。ブラウザーを完全に終了して再起動するか、システムプロキシに従う別のブラウザーでテストしてください。Webページは開けても出口地域がノード名と一致しない場合は、別のノードへ切り替えて確認ページを更新します。サブスクリプション内のノード名は提供元が定義したものなので、最終的には実際の出口結果を基準にします。
特定のWebサイトだけ開けない場合は、接続ログのルール結果を確認します。REJECTなら、設定ルールがリクエストを明示的に拒否しています。DIRECTなのにプロキシが必要なサイトであれば、一時的にGlobalモードへ切り替えて比較できます。Globalではアクセスでき、Ruleでは失敗する場合、問題は通常、ルールまたはプロキシグループにあり、システムプロキシのスイッチではありません。確認後はRuleに戻し、すべての通信を長期間グローバル出口へ送らないようにします。ルール変更、ルールセットのサブスクリプション、ローカル上書きの具体的な方法は上級設定で確認できます。
すべてのノードに接続できないのにサブスクリプションは正常に更新できる場合は、ノード選択、システム時刻、ファイアウォール、現在のネットワーク制限を順番に確認します。TUN使用後にLAN機器へアクセスできない、DNS解決がおかしい、アプリの通信が途切れるといった症状が出た場合は、まずTUNをオフにし、システムプロキシだけで再確認します。これにより、問題が基本的なプロキシ経路にあるのか、仮想ネットワークアダプター、DNS、ルーティング層にあるのかを素早く切り分けられます。症状別の対処手順はトラブルシューティングにまとめています。初回設定で複雑なパラメーターを先に変更する必要はありません。
通常のWebページ
プロキシをオンにしてもネットワーク全体が切断されていないことを確認します。
出口アドレス
接続前後で公開出口が想定どおり変化したか比較します。
ルールの適用結果
接続ログでDIRECT、プロキシグループ、最終出口を確認します。
特定サイトの再テスト
失敗するサイトだけノードまたはモードを切り替え、問題の範囲を絞ります。
サブスクリプションを更新し、決めた順番で切り分ける
4つの手順が終わったら、日常利用で確認する場所は3つだけです。現在の設定、主要なプロキシグループ、接続スイッチを確認します。サブスクリプション提供元がノードやルールを更新したら、設定画面で更新を実行し、以前のプロキシグループの選択が引き続き有効か確認します。自動更新に対応しているクライアントでは適切な間隔を設定できますが、ネットワークに異常がある場合は、成功または失敗を明確に確認できるよう手動更新もおすすめします。
家庭のブロードバンドからスマートフォンのテザリングへ切り替えるなど、ネットワーク環境を変更した後は、まず元のネットワークが復旧するまで待ってからプロキシ接続をテストします。端末のスリープ、システム更新、クライアントの異常終了後にWebページを開けなくなった場合は、システムプロキシをオフにして直接接続を確認し、クライアントを再起動して「サブスクリプション更新—ノード選択—システムプロキシ有効化—出口確認」の順番で復旧します。DNS、ポート、ルールを同時に調整するより、決めた順番で進める方が原因を特定しやすくなります。
基本利用の段階でYAMLを頻繁に編集する必要はありません。ルール不足、DNS解決が想定と異なる、特定のアプリでTUNが必須、複数のサブスクリプションを統合したい、といった明確な理由がある場合にのみ上級設定へ進みます。プロキシグループの種類、ルールセット管理、DNS、Fake-IP、TUN、ドメインスニッフィング、外部コントロールパネルなどは上級設定で学べます。具体的なエラーが出た場合は、まずトラブルシューティングの症状別分類から該当する手順を探してください。