QUICK START / config → rule → connect → verify

Clashの使い方ガイド

サブスクリプションの追加、モード選択、接続開始、通信の振り分け確認。初期設定はこの4ステップで進めます。

クライアントのインストールと有効なサブスクリプションの準備が済んでいれば、基本設定は通常10分ほどで完了します。まずブラウザーの接続を確認し、個別のアプリはその後に設定しましょう。初回接続の前にDNS、ポート、ルーティングをまとめて変更するのは避けてください。

BEFORE YOU START

事前準備:クライアントとサブスクリプション

使用するOSに対応したクライアントと、サービス提供元から発行された有効なサブスクリプションURLを用意します。クライアントは設定を読み込み、コアを実行して通信を処理します。サブスクリプションにはノードや関連設定が含まれます。クライアントをインストールしただけでは、利用可能な接続先は作成されません。また、このサイトのインストーラーページでは個人用サブスクリプションを提供していません。すでに契約している場合は、サービス提供元のページで有効期限と残りの通信量を確認し、URLを全てコピーしてください。

初期設定では、ほかのプロキシクライアントをいったん終了し、ブラウザーで手動設定したプロキシ拡張機能も無効にしておくと、複数の設定が競合しにくくなります。業務用VPNや企業のネットワーク管理ソフトを使用中の場合は、ルーティングやDNSを勝手に変更せず、ネットワークの利用条件を先に確認してください。旧クライアントを残す場合も、新しいクライアントを起動する前に旧接続を停止すればよく、移行時に設定をすぐ削除する必要はありません。

インストーラーをまだ選んでいない場合は、クライアントダウンロードページでプラットフォームに合ったものを選んでください。インストール権限、システムアーキテクチャ、サービスモード、仮想NICなど、プラットフォーム固有の情報は全プラットフォームガイドにまとめています。ここでは、クライアントを起動できる状態から始め、有効な接続に必要な操作に絞って説明します。

STEP 01 / SUBSCRIPTION

サブスクリプションを追加して設定を有効にする

クライアントを開き、サイドバーの「サブスクリプション」または「設定」画面から、「新規作成」「インポート」、またはプラス記号のボタンを探します。URLから追加する項目を選び、サービス提供元からコピーしたURLを全て貼り付けます。画面上部にURL入力欄があるクライアントでは、URLを入力して「インポート」を押してください。名前は設定を見分けるためのものなので、識別しやすい名称を付けても接続方法には影響しません。

貼り付けたら、URLの先頭と末尾を確認し、説明文や改行、余分な空白が混ざっていないかチェックします。サブスクリプションURLには認証情報が含まれることが多いため、公開コメントに投稿したり、トラブル相談用のスクリーンショットにURL全体を写したりしないでください。サービス提供元がクライアント別の形式を複数案内している場合は、アカウントページのURLではなく、使用中のクライアントまたはコアに対応する形式を選びます。

インポートを実行したら、クライアントが設定をダウンロードして解析するまで待ちます。完了すると、新しい設定項目や更新日時、ノード情報が表示されます。項目が表示されただけでは、設定は有効になっていません。項目をクリックするか、メニューから「使用」「有効化」などを選び、現在の設定として表示されていることを確認します。次に「プロキシ」画面を開き、ポリシーグループが表示されるか確認してください。以前の設定内容が残っている場合は、戻って有効な設定を確認します。

ローカルの .yaml または .yml ファイルを受け取った場合は、同じ画面で「ファイルからインポート」を選び、ファイルを指定して有効にします。拡張子を変更して、通常のウェブページやエラーメッセージを設定ファイルとして保存しないでください。ローカル設定は通常、自動更新されません。更新できるかどうかは設定内のリモートリソースやクライアントの設定によるため、サブスクリプションURLと全く同じものとして扱うことはできません。

インポートに失敗したら、まずどの段階で失敗したか確認する

タイムアウト、認証失敗、解析エラーが発生した場合は、まず該当項目のエラーメッセージを確認し、「ログ」画面で同じ時刻の記録を探します。認証失敗は、サブスクリプションURLの期限切れ、認証情報の変更、アカウント状態が原因の場合があります。解析エラーは、取得した内容がウェブページである、サブスクリプション形式に互換性がない、ファイルの構文に誤りがある、といった可能性を示します。インポートを連打して重複項目を作ったり、すぐにクライアントを再インストールしたりしないでください。

ネットワークによっては、サブスクリプションサーバーに直接接続できないことがあります。更新時に接続方法として直接接続またはプロキシを選べるクライアントでは、サービス提供元の案内に従って設定してください。利用できる既存の接続がない場合、まだインポートしていない新しい設定を更新経路として使うことはできません。インポートの問題を解決したら、有効な設定を一つに整理してから動作モードを選びます。

STEP 02 / ROUTING

ルールモードとプロキシポリシーを選ぶ

ホーム画面、プロキシ画面、または設定画面で動作モードを探し、初めて使う場合は「ルール」を選択します。英語表示では通常 Rule です。ルールモードでは、現在の設定に基づいてリクエストを直接接続するか、プロキシ経由にするかを決めます。日常利用に適したモードです。ここで選ぶ「モード」は通信の振り分け方法を決めるもので、ブラウザーの通信をコアに送る機能ではありません。通信の入口を有効にする操作は次のステップで行います。

「グローバル」モードでは通常、コアに届いた一般的な接続がグローバルポリシーに従いますが、システム上のすべてのアプリが対象になるわけではありません。「ダイレクト」モードは、コアに届いた一般的な接続を宛先へ直接つなぐためのものです。初期設定後もグローバルモードを使い続けることはおすすめしません。また、アクセスできない問題を解決するためにグローバルへ切り替えるだけでは、ルールやポリシーグループの選択ミスが隠れてしまうことがあります。

続いて「プロキシ」画面を開き、設定で定義されたメインのポリシーグループを探します。グループ名はサブスクリプションの設定によって異なり、「プロキシ選択」と表示される場合も、別の名前の場合もあります。名前だけで用途を判断しないでください。グループを展開し、利用可能なノードまたはサブスクリプションに用意された自動選択グループを選びます。グループが入れ子になっている場合、メイングループの次の階層に実際の出口ノードがあることがあります。

「テスト」「接続確認」や速度測定のアイコンがあれば、一度実行して目安を確認できます。テスト結果が示すのは、設定されたテスト先にそのノードから接続できるかどうかです。すべてのウェブサイトで使えることや、回線速度を保証するものではありません。タイムアウトした場合は別のノードを試せますが、数値が最小のノードがすべてのアプリに最適とは限りません。最終的には、実際の接続先での動作を基準に判断してください。

選択後、ポリシーグループの選択状態が変わったことを確認します。プロキシ経由にしたい通信では、該当グループが DIRECT になっていないか確認してください。これは直接接続を意味します。url-test や fallback などの自動選択グループは、サブスクリプションの初期設定をそのまま利用できます。今回はテスト間隔や許容差を変更する必要はありません。詳しくはポリシーグループの種類と仕組みをご覧ください。

STEP 03 / TRAFFIC ENTRY

コアを起動して接続を開始する

クライアントのホーム画面に戻り、コアが実行中で、現在の設定がエラーなく読み込まれていることを確認します。起動時にコアを自動で実行するクライアントもあれば、「起動」や接続ボタンを押す必要があるものもあります。ログに設定の読み込みエラーがある場合は、システムプロキシを何度も切り替えるのではなく、前のステップに戻って設定を確認してください。コアが正常に待ち受けて初めて、プロキシポートに送られたリクエストを受け付けられます。

デスクトップ版:システムプロキシでブラウザーを確認

クライアントの「システムプロキシ」を有効にし、状態がオンになるまで待ちます。これにより、システムプロキシの接続先がクライアントのローカル待ち受けアドレスに設定されます。システムプロキシ設定に従うアプリで利用できます。ブラウザーに個別のプロキシ設定やプロキシ拡張機能があると、新しいシステム設定が反映されないことがあります。初回のテスト前に、ブラウザーがシステムプロキシを使う状態に戻してください。

初回接続でポートを変更する必要はありません。現在有効なポートはクライアント画面に表示されます。ガイドに記載された一般的なポート番号を固定値として使わないでください。ログにポートの競合が明記されている場合は、ほかのプロキシプロセスが動作していないか確認します。ポートを変更する必要がある場合はクライアントの設定から変更し、システムプロキシにも反映されたことを確認してください。ほかのアプリにプロキシを手動で設定する場合も、変更後の実際のポート番号を使います。

モバイル版:システムのVPN接続を許可する

クライアントのホーム画面で接続ボタンを押します。初回起動時は通常、システムからVPN構成の追加またはVPN接続の許可を求められます。起動したばかりのクライアントからの要求であることを確認して許可し、システムの指示に従ってロック解除や認証を行います。クライアントに戻り、接続状態が変わるまで待ってください。ステータスバーのVPNアイコンが示すのはトンネルが確立したことだけです。ノードやルールが正しいとは限らないため、次のステップで確認します。

システムで別のVPNを使用中の場合は、古い接続を停止してから現在のクライアントを起動します。VPNアプリを頻繁に切り替えると、確立した接続が別のアプリに置き換えられることがあります。モバイル端末のバックグラウンド制限によって接続が切れることもあります。前面では正常に通信でき、バックグラウンドにしたときだけ切断されると確認できた場合に、プラットフォームガイドを参照してバッテリー設定やバックグラウンド実行を調整してください。

TUN:必要な通信を取り込む場合に有効にする

システムプロキシに従わないアプリがある場合に、TUNモードを検討します。TUNは仮想ネットワークインターフェースとルーティング設定を使って通信を取り込み、通常は管理者権限、サービスモード、または追加ドライバーが必要です。システムプロキシとTUNの連携方法はクライアントによって異なります。初回のトラブル対応では、どの経路で通信を取り込んでいるか分かる状態を保ち、複数のクライアントで同時にTUNを有効にしないでください。

ブラウザーはシステムプロキシで正常に動作するのに、特定のアプリだけ使えない場合は、全プラットフォームガイドで該当OSのTUN設定を確認します。有効にした後、LAN内サービスや業務ネットワークに問題が起きた場合は、まずTUNを無効にして結果を比べてください。ルーティング、DNS、ルールを同時に変更しないようにしましょう。一度に一つだけ変更すれば、どの操作が結果に影響したか判断できます。

STEP 04 / CHECK THE RESULT

アクセス、適用ルール、出口を確認する

クライアントを起動したまま、ブラウザーでアクセス可能なHTTPSページを開きます。まず、設定上プロキシ経由になることが明確な接続先を選んでください。テストでは、開いたままのページを眺めるだけでなく、新しいリクエストを送信します。必要なら新しいタブを開くか、ページのリソースを再読み込みします。キャッシュされたページ、実行中のダウンロード、再利用された既存の接続によって、結果が変わらないように見えることがあります。

同時にクライアントの「接続」画面を開き、新しいリクエストが表示されるか確認します。対象のリクエストを見つけたら、ドメイン、適用ルール、ポリシーグループ、実際の出口を確認してください。表示される項目はクライアントによって異なりますが、リクエストがコアに届き、最終的な出口がノードか DIRECT かは確認する必要があります。テスト対象のドメインが想定したポリシーグループに表示され、ページも正常に読み込めれば、プロキシ経路の一次確認は完了です。

次に、現在の設定で直接接続される想定のウェブサイトを開き、接続ログに直接接続と表示されるか確認します。ルールモードでは接続先ごとに出口が異なるのが正常です。ローカルサービスに以前と同じ出口アドレスが表示されても、プロキシが動作していないとは限りません。IPアドレス確認ページで分かるのは、そのページへのリクエストが通った経路だけです。端末上のすべての通信が同じ出口を使っている証明にはなりません。

接続ログに表示されない場合:通信の入口を確認する

新しいリクエストが接続一覧に表示されない場合は、まずクライアントでログ記録が停止していないか、ブラウザーが実際にネットワークリクエストを送っているか確認します。次に、システムプロキシが有効か、ブラウザーがシステム設定に従っているか、モバイル版のVPNが接続中かを確認してください。特定のアプリだけ記録されない場合は、そのアプリがシステムプロキシを迂回していないか調べます。リクエストがまだコアに届いていない段階で、ノードを次々に変更しないでください。

ログはあるのに接続できない場合:実際の経路を確認する

ログに記録されているのにアクセスできない場合は、まず出口が想定どおりか確認し、同じ時刻のログを調べます。ポリシーグループの選択が誤っていれば修正します。ノードがタイムアウトする場合は、別のノードで比較してください。特定のドメインだけ失敗する場合は、接続先のサービス自体が正常か確認します。DNSエラーは実際のログと合わせて判断してください。ページが開かないという理由だけでFake-IPを無効にしたり、DNS設定全体を置き換えたりしないでください。

最後に、条件をそろえて比較テストを行います。ほかの作業に影響しないことを確認したうえで、直前に有効にしたシステムプロキシまたはVPNを無効にし、同じリクエストを新しく送信します。その後、接続を元に戻して再試行してください。ボタンの色だけでなく、アクセス結果と接続ログを比較します。トラブル相談用のスクリーンショットにはエラー発生時刻、接続先、エラーの種類を残し、サブスクリプションURL、認証情報、個人情報は隠してください。

DAILY USE

終了と日常の使い方

動作確認が済んだら、有効な設定、ルールモード、利用できることを確認した通信の入口を維持すれば、通常の利用を続けられます。サブスクリプションを更新すると、利用可能なノードやポリシーグループが変わることがあります。更新後に接続できなくなった場合は、以前選択していたノードが削除されていないか確認し、必要に応じて選び直してください。OS起動時にクライアントが自動起動しても、通信が自動的に取り込まれるとは限りません。クライアントの起動と、システムプロキシや接続の復元設定をそれぞれ確認してください。

プロキシを停止する場合は、クライアントでシステムプロキシ、TUN、またはモバイル端末の接続を無効にしてから、通常の方法で終了します。終了時にシステム設定を元に戻すクライアントもありますが、すべてが同じ動作をするとは限りません。終了後もブラウザーがインターネットに接続できない場合は、停止したローカルプロキシがシステムの接続先に残っていないか確認します。自動設定または元のネットワーク設定に戻してから、再度接続を試してください。

これで基本の流れがつながります。設定が有効で、ポリシーグループに明確な出口が選ばれ、通信の入口が想定どおりの状態にあり、接続ログから実際のリクエストを確認できることが目安です。カスタムルール、DNSやFake-IP、サービス権限、プラットフォーム固有の問題については、全プラットフォーム対応インストール・設定ガイドをご覧ください。クライアントごとの機能差はクライアント比較で確認できます。初回接続の段階で、すべての詳細設定を済ませる必要はありません。