ルールモード
設定ルールに従って、各リクエストをプロキシ、ダイレクト、その他のポリシーへ振り分けます。初回接続と日常利用に適しています。
10 MINUTE START
サブスクリプションの取り込み、プロキシモードの選択、接続の確立、結果の確認という4段階で進めます。各ステップは前の状態を前提とするため、クライアントをインストール済みで初回設定を始める方に適しています。
INPUT → RULE CORE → SYSTEM ROUTE → RESULT
PRE-FLIGHT CHECK
このガイドでは、クライアントのインストールが完了し、利用可能なサブスクリプションURLまたはローカルのYAML設定ファイルが用意されていることを前提とします。まだクライアントをインストールしていない場合は、まずクライアントの取得ページを開き、OSに合った入口を選んでください。Windows、macOS、Android、iOS、Linuxでは画面上の名称が異なる場合がありますが、設定の流れは基本的に共通です。設定がカーネルに入り、ルールが通信の行き先を決め、システムプロキシまたはTUNがアプリのリクエストをカーネルへ渡します。
クライアントを開いたら、まずホーム画面にカーネルの状態、設定入口、プロキシ入口が正常に表示されるか確認します。一部のデスクトップクライアントでは初回起動時にネットワーク、ファイアウォール、管理者権限を求められます。モバイル版では接続時にシステムVPNの許可画面が表示されます。これらの許可はローカルネットワークインターフェースの作成やシステムプロキシ状態の変更に使われます。現在の利用方法に必要な権限を確認してから進み、許可画面を処理しないまま接続スイッチを何度も操作しないでください。
旧クライアントから移行した設定を使う場合、初回操作では複数のClashクライアントを同時に起動しないことをおすすめします。複数のプログラムが同じリスニングポートを取り合ったり、システムプロキシを交互に変更したりすると、画面上は接続済みでも実際の通信が別のプロセスに入ることがあります。他のプロキシツールを終了し、現在のクライアントだけを残して以下の手順を進めてください。
ホーム画面にカーネル、設定、プロキシ関連の入口が表示される。
サブスクリプションURLにアクセスできる、またはローカル設定ファイルを読み込める。
システムプロキシの上書きやローカルリスニングポートの競合を避ける。
PROFILE INPUT
クライアントの設定ページを開きます。デスクトップクライアントでは通常、左側のナビゲーションにProfilesまたは設定の入口があります。モバイルクライアントでは、ホーム画面の設定名付近にある場合があります。URLからの取り込み、サブスクリプションの追加、設定の新規作成などの操作を見つけ、完全なサブスクリプションURLを入力欄に貼り付けます。貼り付けたら、先頭と末尾に空白、改行、日本語以外の全角句読点などが混入していないか確認し、取り込み、ダウンロード、保存のいずれかを実行します。
クライアントがサブスクリプションの読み込みを始めると、設定一覧に新しい項目が表示されます。項目には通常、設定名、更新日時、更新ボタンなどが表示されます。ただし、一覧に表示されたことは「使用中になった」ことを意味しません。項目をクリックするか横の切り替えボタンを使い、現在のProfileに設定する必要があります。切り替えに成功すると、ホーム画面やステータスバーの現在の設定名も変わります。次のプロキシモードとポリシーグループはすべてこの現在の設定から読み込まれるため、必ず先に選択を完了してください。
設定元がローカルのYAMLファイルの場合は、ファイルからの取り込みを選ぶか、設定エリアへファイルをドラッグします。ファイルの拡張子は通常、.yaml または .yml です。取り込み後は、設定一覧で同じファイルを現在の項目に設定します。クライアントに解析失敗と表示された場合は、すぐに接続手順へ進まないでください。エラー位置を確認しながら、YAMLのインデント、コロンの後の空白、リストの階層を確認します。設定をカーネルが完全に読み込めない状態では、システムプロキシを操作できても、利用可能なルールやポリシーは得られません。
取り込みが完了したら、設定ページにとどまり状態を確認します。現在の設定に明確な選択済みマークがあり、設定の詳細にプロキシポリシーグループとルールが表示されていることを確認してください。空の項目だけが表示されてはいけません。クライアントに設定チェックや再読み込みボタンがある場合は、一度実行できます。正常に読み込めたことを確認してからプロキシページへ進むと、「設定の問題」と「接続の問題」を分けて対処でき、後の手順で複数の要因を同時に調べずに済みます。
サブスクリプションの自動更新間隔はメンテナンス設定であり、今回の初回接続には影響しません。ここでの目的は、設定を読み込んでアクティブな項目に切り替えられることを確認することです。設定ファイルの構造、ルールプロバイダー、サブスクリプション更新の関係、多設定管理については、接続に成功した後でシステムガイドを最初から学ぶことができます。このページではまず操作の流れを簡潔に保ちます。
設定一覧に新しい項目があり、現在の設定名に切り替わり、ページに解析エラーが表示されていない。
RULE SELECTION
現在の設定を読み込んだら、プロキシまたはProxiesページを開きます。まずモード選択エリアを探します。一般的な選択肢はルール、グローバル、ダイレクトです。初回の普段使いにはルールモードをおすすめします。このモードでは、リクエストが設定内のルールに上から順に照合され、対応するポリシーグループで処理されます。プロキシが必要な通信はプロキシポリシーへ、不要な通信はダイレクトへ振り分けられ、動作は設定内容によって決まります。
グローバルモードでは、ほとんどのリクエストを1つの統一ポリシーに渡します。「ルールが原因で特定のサイトがプロキシを経由していないか」を一時的に判断するのに適していますが、設定内容を理解していない場合の標準設定には向きません。ダイレクトモードでは通信がプロキシポリシーを迂回するため、プロキシを一時停止したり、ネットワーク状態を比較したりできます。モードを変更しても通信の判断方法が変わるだけで、設定の取り込みや利用できないポリシーの修正は行われません。
設定ルールに従って、各リクエストをプロキシ、ダイレクト、その他のポリシーへ振り分けます。初回接続と日常利用に適しています。
リクエストを指定したポリシーに集約し、アクセス問題がルールの照合に関係するかを判断できます。
リクエストを対象へ直接接続し、通常のネットワーク経路へ戻したり、変更前後の結果を比較したりできます。
ルールモードを選択したら、すぐにホーム画面へ戻らず、プロキシページのポリシーグループを確認します。設定によって名称は異なり、ノード選択、プロキシ、自動選択、手動選択などがあります。主要なプロキシ通信を担当するグループを開き、利用可能なポリシーが1つ選択されていることを確認してください。グループが未選択の状態だったり、失効した項目が選ばれていたりすると、ルールが正しく一致しても最終的な接続に失敗することがあります。
クライアントに遅延テストがある場合は、明らかに接続できない項目を見つけるため、基本テストを一度実行できます。遅延値はテスト対象への1回のリクエスト結果にすぎず、すべてのサイトでの実際の使用感を示すものではありません。この段階で最低値を何度も追求する必要はありません。まずテストを完了でき、状態が安定したポリシーを選んで基本接続を確立し、その後で長期的な調整を行います。
設定によっては、相互に参照する複数のポリシーグループが含まれています。その場合は、まずルールから直接参照される最上位の主要グループを処理し、その内部で参照される下位グループにも選択済みの項目があることを確認します。DIRECTやREJECTなどはルールのアクションまたは組み込みポリシーであり、通常のプロキシ項目ではありません。初回操作では主要なプロキシグループに利用可能な選択肢が明確に設定されていれば十分で、すべてのグループを1つずつ変更する必要はありません。
現在のモードがルールモードで、主要なポリシーグループに明確な選択があり、基本テストでも接続失敗が継続して表示されていない。
SYSTEM ROUTE
クライアントのホーム画面に戻り、まずカーネルが動作中であることを確認します。インストール後にカーネルが自動起動するクライアントもあれば、サービス起動や実行ボタンをクリックする必要があるクライアントもあります。カーネルが動作すると、通常は動作中、起動済みなどの状態が表示され、ローカルリスニングポートも確認できます。カーネルが正常に待ち受けている場合に限り、ブラウザーや他のアプリがシステムプロキシへ切り替わった際の受け口が用意されます。
続いてシステムプロキシのスイッチを有効にします。デスクトップOSでは、HTTPまたはHTTPSリクエストをクライアントのローカルリスニングアドレスへ向ける操作です。有効にすると、クライアントにシステムプロキシ設定済みと表示され、OSのプロキシ設定にもローカルアドレスが表示されます。この時点では複数の取り込み方式を同時に有効にせず、「カーネルが動作中+システムプロキシが有効」という最も確認しやすい状態を保って、次の検証へ進みます。
AndroidとiOSのクライアントは通常、システムVPNインターフェースを通じて通信を取り込みます。初めて接続をタップするとシステムの許可画面が表示され、承認後はステータスバーにVPNマークが現れます。このマークはシステムインターフェースが確立したことを示しますが、対象へアクセスできるかどうかは設定、ポリシー、DNSにも左右されるため、4つ目のステップまで確認が必要です。許可を取り消した場合、クライアントが未接続状態に戻ることがあります。その場合は再度接続をタップし、システムの案内に対応してください。
一部のデスクトップアプリはシステムプロキシを読み取らず、独自のネットワークスタックを使用します。このような通信をClashへ取り込むにはTUNモードが必要になる場合があります。システムプロキシをまだ確認していない段階で、いきなりTUNを重ねて有効にすることはおすすめしません。TUNには仮想ネットワークアダプター、管理者権限、ルーティング、DNSの取り込みも関係するためです。まずブラウザーで基本経路を確認し、特定のアプリがシステムプロキシを経由していないことが分かった場合に、重複する取り込み方式を無効にしてクライアントの案内に従いTUNを有効にします。
TUNを有効にした後、システムが管理者権限を求めたりサービスコンポーネントのインストールを要求したりした場合は、まず案内に従って処理し、TUNの状態が有効なまま維持されるか確認します。スイッチを押すとすぐに元へ戻る場合は、権限、サービスコンポーネント、仮想ネットワークアダプターの準備が整っていない可能性があります。TUNの仕組み、厳格ルート、DNSハイジャック、OSごとの差異については、システムガイドのTUN章で詳しく確認できます。
接続を確立したら数秒待ち、カーネルが継続して動作しているか、接続スイッチが有効なままか、ログにポート使用中、権限不足、設定読み込みエラーが繰り返し表示されていないか確認します。スイッチがすぐにオフになる場合は、まずログにある最初の明確なエラーを処理してください。起動を連続してクリックしても、ポート競合や権限の問題は解消しません。
状態が安定しているなら、この時点でモード、ポリシー、DNSを次々に変更しないでください。現在の設定を変えずに検証へ進むことで、テスト結果を明確な状態の組み合わせに対応付けられます。検証に成功してから他の機能を1つずつ学べば、問題が起きたときもこの基本構成へ戻しやすくなります。
カーネルが継続して動作し、システムプロキシまたはモバイル端末のVPNインターフェースが有効で、起動エラーが繰り返し表示されていない。
RESULT CHECK
クライアントをバックグラウンドで動作させたまま、新しいブラウザーウィンドウを開きます。まず、もともと正常に開ける通常のページへアクセスし、プロキシ設定によってシステム全体のネットワークが切断されていないことを確認します。その後、プロキシポリシーを経由する対象ページへアクセスします。テスト時は新しいウィンドウを使うかページを更新し、ブラウザーのキャッシュで古い内容が表示され続ける可能性を避けてください。
ページの読み込み中にクライアントへ戻り、接続記録またはログを確認します。正常であれば、ブラウザーが行ったドメインリクエスト、ヒットしたルール、使用したポリシーグループ、最終的なポリシーが表示されます。接続記録を確認するほうが、Webページの結果だけを見るより確実です。リクエストが現在のクライアントに入ったことを確認できるからです。ページを開けてもクライアントに記録がまったくない場合、ブラウザーが独自のプロキシ設定や別のネットワークツールを使用しているか、現在のシステムプロキシを経由していない可能性があります。
接続記録に直前にアクセスしたドメインが表示され、システム通信がClashカーネルへ到達したことを示している。
記録に表示されたルールの種類と対象が一致し、リクエストが想定したポリシーグループへ渡されている。
対象ページの読み込みが完了し、クライアントにタイムアウト、拒否、DNSエラーが継続して表示されていない。
クライアントに新しい接続記録がまったくない場合は、まずシステムプロキシまたはVPNインターフェースが有効なままか確認し、次にブラウザーが別のプロキシを個別指定していないか確認します。接続記録はあるものの、プロキシを経由するはずのリクエストがDIRECTになっている場合は、ルールの一致または現在のモードに問題がある可能性が高いです。一時的にグローバルモードへ切り替えて比較します。グローバルモードではアクセスでき、ルールモードではできない場合は、ルールまたはポリシーグループを確認します。両方のモードで失敗する場合は、現在のポリシー自体とネットワーク接続を確認します。
記録上はプロキシポリシーが選択されているのにタイムアウトする場合は、まずプロキシページへ戻り、基本テストに合格した別のポリシーへ切り替えて再アクセスします。ドメイン解決失敗やホストを解決できないといった情報が表示される場合は、DNS設定、システムネットワーク、設定内のDNSセクションを重点的に確認します。ルール、ポリシー、DNS、TUNを同時に変更しないでください。一度に1つだけ調整し、対象ページを更新して新しいログを確認することで、再現可能な判断ができます。
検証が完了したら、モードをルールモードへ戻し、動作確認済みのポリシーを保持します。これで基本的な接続経路が確立されました。設定がルールとポリシーを提供し、モードが判断方法を決め、システムプロキシまたはTUNが通信を取り込み、接続記録がどの経路を通ったかを示します。以後、サブスクリプションを更新したりポリシーを変更したりするときも、この確認順序を利用できます。
設定、モード、システムによる通信の取り込み、リクエスト結果をすべて確認しました。今後は必要に応じて、カスタムルール、DNS、TUN、複数設定の管理を学べます。
QUICK DIAGNOSIS
4つのステップで期待した結果が得られない場合は、いきなり再インストールしたり大量の設定を同時に変更したりせず、手順の最初に戻って各層を確認します。Clashの基本経路は、設定、ポリシー、カーネル、システムによる通信の取り込み、対象リクエストの5層に分けられます。前の層が不完全なままだと、次の層のスイッチが有効と表示されても、実際の接続は成立しません。
設定ページを開き、アクティブマークが取り込んだばかりの項目に付いているか確認し、解析エラーがないことも確認します。サブスクリプションが一覧にダウンロードされただけで、現在の設定に切り替わっていないことは、初回利用でよくある中断原因です。
プロキシページに戻り、ルールモードと主要なポリシーグループを確認します。ポリシーテストが継続して失敗する場合は、複雑なルールを調整する前に、接続できる項目へ切り替えます。
動作状態とログを確認します。ポートが使用中の場合は、同じポートを使っているプログラムを終了するか、設定でリスニングポートを変更してから再起動します。変更後は、システムプロキシが新しいポートを向いていることも確認してください。
デスクトップではシステムプロキシを、モバイル端末ではVPNの許可とステータス表示を確認します。特定のアプリがシステムプロキシを読み取らない場合に限り、TUNを個別に検討してください。ブラウザーの基本テストとTUNのトラブル対処を混同しないようにします。
対象ページへ再度アクセスし、該当ドメインが表示されるか、どのルールに一致したか、どのポリシーを使ったかを確認します。記録がない、ルールが一致しない、ポリシーがタイムアウトするという3つの状態は、それぞれ異なる対処が必要です。
基本的なトラブル対処を終えても、ポート、DNS、ルールの適用範囲、TUNルート、旧クライアントからの移行を確認する必要がある場合は、Clashシステムガイドを最初から学ぶことができます。このページでは、基本概念、クライアント選び、インストール、サブスクリプション、プロキシモード、ルールによる振り分け、TUN、日常メンテナンスを章ごとに整理しています。基本接続を確立した後、問題に応じて参照するのに適しています。