SETUP ROUTE

手順へ移動

一部の設定が済んでいる場合は、該当する確認ポイントへ直接移動できます。初めて使う場合は、最初から順番に操作することをおすすめします。

Windowsクライアントの入口

まず設定画面でサブスクリプションを取り込み、プロキシ画面でポリシーを選択します。接続時はクライアントのコアが起動していることを確認し、「システムプロキシ」を有効にします。ブラウザーやWindowsのプロキシ設定に従う多くのアプリが、この設定を使って通信します。クライアントを終了する前にシステムプロキシを無効にすると、古いプロキシアドレスがシステムに残るのを防げます。

BEFORE OPENING

開始前の準備

操作を始める前に、インストール済みのClash GUIクライアントと、現在も有効なサブスクリプションURLを用意します。クライアントは設定の読み込み、プロキシコアの実行、システムプロキシの適用を担当します。サブスクリプションURLはノードサービス提供元が発行するもので、通常はプロキシノード、ポリシーグループ、ルール、更新情報が含まれます。クライアントだけをインストールして設定がない場合、プロキシ一覧は空のままです。

まだクライアントをインストールしていない場合は、先にクライアントの入手ページへ進み、使用中のOSに合うバージョンを選択してください。インストール後は一度通常どおり起動し、出所が不明な設定や用途が重複する設定を同時に複数取り込まないでください。複数の設定を入れると、ポリシー名、ルールの出所、更新日時が混在し、初回のトラブルシューティングで実際にどの設定が有効なのか判断しにくくなります。

サブスクリプションURLをコピーするときは、ノードサービス提供元の管理画面でClash、Mihomo、または汎用サブスクリプションとして明示された入口を使用します。コピー後にパラメーターを手動で削除したり、WebアカウントのURLをサブスクリプションURLとして使ったりしないでください。有効なサブスクリプションは通常、https://で始まる長いURLで、パスやクエリパラメーターを含むことがあります。URLは完全にコピーしてください。チャットツールによる自動切り詰めや余分な空白でダウンロードに失敗する場合があります。

01SUBSCRIPTION

サブスクリプション設定を取り込む

設定またはサブスクリプション画面を見つける

クライアントを開き、「設定」「サブスクリプション」「Profiles」など、近い名前の画面を探します。ここは設定の取得元を保存する場所で、ノードを選ぶ画面ではありません。デスクトップでは左側のナビゲーションに独立した入口があることが多く、モバイルではメイン画面の上部またはサイドメニューに配置されている場合があります。画面を開くと、URLからの取り込み、新規設定、設定の更新、QRコードのスキャンなどが表示されます。

URLからの取り込みを選び、先ほどコピーした完全なサブスクリプションURLを入力欄に貼り付けます。クライアントによっては設定名の入力も求められるため、サービス名や用途を区別できる名前を付けてください。たとえば「日常用ルール設定」のようにし、設定名欄へサブスクリプションURLを再入力しないでください。入力欄の前後に空白がないことを確認し、「ダウンロード」「取り込み」「保存」「確認」などのボタンをクリックして処理を待ちます。

設定が正常にダウンロードされたことを確認する

取り込みに成功すると、設定一覧に新しい項目が表示され、識別しやすい設定名が示されます。その項目をクリックして現在の設定にし、プロキシまたはポリシー画面で内容を確認します。通常は複数のポリシーグループが表示され、グループ内にノード名、自動選択、DIRECT、その他のサブポリシーが表示されます。設定項目が1つ表示されただけでは有効化済みとは限らないため、現在選択されている印が取り込んだ設定に付いていることも確認してください。

取り込み後すぐに読み込まれるクライアントもあれば、「使用」「有効化」または対応するラジオボタンをもう一度クリックする必要があるクライアントもあります。読み込みが完了すると、ログには設定の読み込み、プロキシポートの起動、ルールの読み込みに関する記録が表示されることがあります。YAMLの解析失敗、未対応フィールド、設定が空と明確に表示された場合は、接続を開始しないでください。まずサブスクリプションの種類を提供元で確認し、URLをコピーし直して再度取り込みます。

更新に失敗したら、まずエラーの発生箇所を切り分ける

ネットワーク要求に失敗したと表示された場合は、まず通常のネットワークで他のWebページを開けるか確認し、次にサブスクリプションの有効期限を確認します。ブラウザーのアドレスバーにURLを貼り付けて接続テストもできますが、共有端末にURLを保存したり、完全なURLを公開の掲示板に投稿したりしないでください。ブラウザーでも開けない場合は、サブスクリプションの状態または現在のネットワークに問題がある可能性が高いです。ブラウザーでは取得できるのにクライアントで失敗する場合は、クライアントのネットワーク権限、システム時刻、既存のプロキシ設定を確認します。

取り込み後にノード一覧が空の場合は、まず手動で一度更新し、設定を選び直します。それでも内容が表示されない場合は、クライアントのエラーメッセージを確認し、ソフトを何度も削除して再インストールするのは避けてください。サブスクリプションの失効、返却形式の不一致、ローカルコアによる設定の読み込み失敗では表示が異なります。順に確認するほうが再インストールを繰り返すより原因を特定しやすくなります。詳しい対応関係はトラブルシューティングで確認できます。

02ROUTING MODE

プロキシモードとポリシーを選択する

初回接続ではルールモードを優先する

設定、一般、またはモード画面を開き、プロキシモードの項目を探します。一般的なモードにはルール、グローバル、DIRECTがあります。初期設定では「ルール」モードがおすすめです。クライアントが設定内のルールに従って通信先を判定し、プロキシが必要な接続をポリシーグループへ渡す一方、ローカルサービスや指定ドメインは直接接続にできます。これによりサブスクリプションが正常か確認しながら、提供元が設計したルーティングも維持できます。

グローバルモードでは、多くの通信を1つのプロキシポリシーへまとめて送るため、特定ノードが接続できるか短時間で確認する用途に向いています。ただし影響を理解しないまま、長時間の唯一の切り分け手段として使うのはおすすめしません。DIRECTモードでは通信がプロキシを経由しないため、プロキシ停止時との比較に使えます。モード名はルールの処理方法を示すもので、システムプロキシが有効とは限りません。モード選択後も、手順3の接続スイッチを有効にする必要があります。

主要ポリシーグループで出口を選択する

「プロキシ」「Proxies」またはポリシー画面へ移動し、主な外部通信を処理するポリシーグループを探します。名前は「ノード選択」「プロキシ」「Proxy」などの場合もあれば、設定提供元が独自に付けている場合もあります。グループを展開すると、特定のノードや「自動選択」「フォールバック」「負荷分散」などのサブグループを選べます。初回接続では、状態が明確な特定ノードまたは設定済みの自動選択グループを選べば十分で、すべてのポリシーグループを個別に変更する必要はありません。

クライアントに遅延テストがある場合は、基本テストを1回実行できます。遅延結果は、その時点でテスト先が応答できたかを示すだけで、すべてのWebサイトへのアクセスやノード品質を保証するものではありません。特定のノードがタイムアウトしたら別のノードで再テストします。すべてのノードがタイムアウトする場合は、手順1に戻ってサブスクリプションの更新日時を確認し、ローカルネットワーク、ファイアウォール、システム時刻に異常がないか確認してください。

設定には、ストリーミング、インスタントメッセージ、ダウンロード、フォールバックなど、用途の異なる複数のポリシーグループが含まれる場合があります。初回は主要なプロキシグループに選択先があることだけ確認し、他のグループはサブスクリプションの初期値のままにします。一度に多くのポリシーを変更すると、後の検証で比較しにくくなり、接続失敗の原因がノード、ルール、手動選択のどれか判断できなくなります。

DNSとTUNは一時的に初期値のままにする

クライアントによっては、設定にDNS、TUN、混合ポート、バイパスリスト、設定オーバーライドなどの項目があります。これらは複雑なアプリ互換性、全通信の取り込み、ドメイン解決の問題に対応するためのもので、初回接続に必須ではありません。まず現在の設定提供元が指定した初期値のままにし、基本的なプロキシ確認が終わってから変更を検討します。

特にTUNモードは仮想ネットワークインターフェースを作成したりルーティングを変更したりするため、追加のシステム権限が必要になることがあります。また、他のVPN、仮想マシンのネットワーク、セキュリティソフトと競合する場合もあります。通常のシステムプロキシでブラウザーやよく使うアプリを利用できるなら、このガイドではTUNを有効にする必要はありません。システムプロキシに従わないアプリを取り込む必要がある場合は、設定ファイルリファレンスで関連項目と仕組みを確認してください。

03CONNECT

プロキシ接続を確立する

デスクトップ：コアを起動してシステムプロキシを有効にする

Windows、macOS、一般的なLinux GUIクライアントには、通常2つの関連する状態があります。プロキシコアが動作しているか、システムプロキシが有効かです。まずクライアントのメイン画面またはステータスバーで、コアが起動し、設定読み込みエラーが継続していないことを確認します。次に「システムプロキシ」「Set as system proxy」などのスイッチを有効にします。有効になると、クライアントがOS設定にローカルプロキシアドレスを書き込み、ブラウザーやシステム設定に従う多くのアプリがClashへリクエストを送るようになります。

Windowsではクライアントがシステムトレイに格納されたまま動作することがあります。macOSではメインウィンドウを閉じても、メニューバーのプロセスが接続を維持する場合があります。テスト中にプロセスを直接終了すると、システムプロキシの状態とクライアントの待受ポートが一致しなくなる可能性があります。終了するときは、先にシステムプロキシを無効にしてから、クライアントメニューの終了コマンドを使用してください。停止したローカルポートをOSが参照し続けるのを防げます。

macOSで関連機能を初めて有効にすると、ネットワーク拡張、補助サービス、管理者権限を求められることがあります。システムのダイアログに従って許可し、クライアントに戻って接続スイッチをもう一度有効にします。以前に権限を拒否した場合は、同じスイッチを何度もクリックするのではなく、システム設定から許可し直してください。詳しい権限の場所は、トラブルシューティングでプラットフォーム別に確認できます。

モバイル：ローカルVPNの許可を確認する

AndroidとiOSのクライアントは通常、OSが提供するローカルVPNインターフェースで通信を取り込みます。現在の設定とポリシーを選択し、メイン画面の起動ボタンをタップします。初回接続時はVPN構成または接続の許可が表示されるため、システムの説明を確認して許可してください。接続に成功すると、システムのステータス領域にVPNマークが表示され、クライアントのメイン画面も停止状態から実行状態へ変わります。

Androidで接続がすぐ自動停止する場合は、まずバックグラウンド動作が制限されていないか確認します。クライアントをバックグラウンド活動の許可対象またはバッテリー最適化の対象外にし、必要な通知権限も残すと、画面オフ後にシステムが停止させるのを防ぎやすくなります。メーカーによって設定項目の名称は大きく異なるため、端末設定の「バッテリー」「アプリの起動」「バックグラウンド活動」などから該当項目を探してください。

iOSではWi-Fiとモバイルデータ通信を切り替えると、ネットワーク経路が再確立されます。ページを一時的に読み込めない場合は、クライアントに戻って接続が有効なままか確認し、停止してから再接続します。システムVPNインターフェースを使う別のアプリを同時に実行しないでください。通常、システムが現在の通信を取り込める主要VPN構成は1つだけです。

初回テストは1つのアプリだけで行う

接続が確立したら、まず普段使うブラウザー1つでテストします。ダウンロードツール、ゲーム、仮想マシン、他のVPNをすぐ同時に起動しないでください。アプリを1つに絞ると接続履歴を確認しやすく、バックグラウンド通信の影響も減らせます。普段アクセスできるページを開いて基本通信を確認し、次にプロキシルールの対象となるページへアクセスして、手順4で一致結果を確認します。

システムプロキシを有効にしてすべてのページが開けなくなった場合は、まずシステムプロキシを無効にして通常のネットワークへ戻し、クライアントのログを確認します。よくある原因は、コアが起動していない、現在のノードに到達できない、システムプロキシのポートが使用中、セキュリティソフトがローカル待受を阻止していることです。すぐにTUNモードへ変更して問題を回避するのではなく、まず通常のシステムプロキシ経路を動作させてください。

04VERIFY

プロキシが有効か確認する

スイッチの色だけでなく、接続履歴を確認する

クライアントに「接続済み」と表示されても、コアまたはローカルVPNが起動したことしか示さず、対象リクエストがプロキシを使用した証明にはなりません。クライアントの「接続」「Connections」またはログ画面を開き、ブラウザーで先ほどのテストページを更新します。接続一覧に新しいドメインまたはIPの記録が現れ、一致したルール、使用したポリシーグループ、最終的な出口が表示されるはずです。記録が増え続ければ、アプリの通信がClashに到達しています。

システムのバックグラウンド通信に埋もれた記録ではなく、テスト対象ドメインの接続を重点的に確認します。ルールモードでDIRECTと表示される接続があっても、ローカルサービス、LANアドレス、指定サイトを直接接続にする設定なら正常です。確認すべきなのは、プロキシ経由の想定対象がプロキシポリシーに一致し、手順2で選択したノードまたはポリシーグループを最終的に使用していることです。

スイッチを切り替えて比較テストを行う

テストページを変えず、まず接続を有効にした状態で更新して結果を記録します。次にシステムプロキシまたはモバイルの接続を無効にし、同じページをもう一度更新します。2回の結果がルールの想定と一致することを確認してください。比較後は接続を再び有効にし、接続一覧をもう一度確認します。これにより、ブラウザーキャッシュ、既存接続の再利用、ページが偶然読み込めたことによる誤判定を除外できます。

ブラウザーが確立済みの長時間接続を再利用するため、プロキシを停止してもページの表示がすぐ変わらないことがあります。その場合は該当タブを閉じて開き直すか、既存接続が終了するまで待って新しい接続履歴を確認します。ページ上部に古い内容が表示されているだけでプロキシ状態を判断しないでください。動的リクエスト、画像の読み込み、新しい接続のほうが現在の経路を正確に反映します。

状況に応じて次の切り分け先を決める

接続一覧にブラウザーのリクエストがまったく表示されない場合、通信がまだクライアントに入っていません。デスクトップではシステムプロキシが実際に有効か、ブラウザーが独自のプロキシ設定を使っていないか確認します。モバイルではVPNマークとシステムの許可を確認します。接続履歴はあるのに最終ポリシーがDIRECTの場合は、ルールモード、ポリシーグループ、対象ドメインに一致するルールを確認してください。

想定したプロキシポリシーが使われているのにリクエストがタイムアウトする場合は、別のノードに切り替えて再テストし、ログに接続拒否、ハンドシェイク失敗、DNS関連のメッセージがないか確認します。複数ノードのうち一部だけが失敗するなら、まずノードへの到達性を疑います。すべてのノードと対象で失敗する場合は、サブスクリプションの状態、システム時刻、ネットワーク制限、ファイアウォール、DNSを確認します。

ブラウザーは使えるのに特定のアプリだけ使えない場合、そのアプリがシステムプロキシを読み取らないか、独自のネットワークスタックを使っている可能性があります。これは基本設定の失敗を意味しません。まずアプリ自身のプロキシ設定を探してください。すべてのアプリの通信を取り込む必要がある場合は、TUNモードを検討し、設定ファイルリファレンスでルーティング、DNS、権限への影響を確認します。

AFTER CONNECTION

完了後の日常設定

基本接続が安定してから、自動更新、スタートアップ起動、高度なルーティングを1つずつ追加します。設定を1種類変更するたびに、もう一度動作確認を行ってください。

日常のメンテナンス

サブスクリプション更新後にポリシーを再確認する

サブスクリプションの更新によって、ノードが追加・削除・改名されたり、ポリシーグループの構成が変わったりすることがあります。更新後はプロキシ画面に戻り、主要ポリシーに有効な選択先があることを確認します。以前選択したノードが削除されていた場合は、出口を指定し直してください。

必要に応じて有効にする

スタートアップ起動とシステムプロキシを設定する

クライアントが安定して起動・終了できることを確認してから、スタートアップ起動を検討します。「クライアントを起動する」と「システムプロキシを自動的に有効にする」は別の項目として確認し、設定が無効なときにシステムへプロキシ設定だけが自動適用されるのを避けてください。

高度な設定

DNS、TUN、オーバーライドを後から調整する

アプリがシステムプロキシを読み取らない、ドメイン解決に異常がある、カスタムルールが必要といった場合に限り、これらの項目を調整します。変更前に利用可能な設定を保存し、変更するたびにログと接続履歴を確認してください。

具体的なエラーを切り分ける

サブスクリプション、ノード、システムプロキシ、VPN権限、DNSなど、現象に応じた対処方法を確認します。

トラブルシューティングを見る

設定ファイルを変更する

YAML構造、共通フィールド、ポリシーグループ、ルール構文、オーバーライドとマージの方法を確認します。

設定リファレンスを開く

Clash 初心者向けガイド