Clashの始め方：
サブスクリプションの追加と接続確認
「設定を追加 → モードを選択 → 接続を有効化 → 通信を確認」の順に進めます。クライアントをインストール済みで、互換性のあるサブスクリプションを用意できている場合は、初期設定を約10分で進められます。
事前に、サービス提供元から受け取ったClash互換のサブスクリプションURL、または利用可能なYAML設定ファイルを用意します。クライアントは設定を読み込み、通信を振り分けてプロキシ接続を確立します。クライアントをインストールしただけでは、サブスクリプションは作成されず、ノードも自動で提供されません。サーバーアドレスだけでは、プロトコル、ポート、認証情報が不足して接続できないことがあります。
サブスクリプションURLにはアクセス用の認証情報が含まれる場合があります。公開コメントやオンライン変換サイト、スクリーンショットに貼り付けないでください。問題を他の人に相談する際は、URLのパラメーター、ノードのパスワード、個人情報を隠してください。以下の例は設定方法を示すもので、実際に利用できるプロキシサービスは含まれていません。
サブスクリプションを追加して現在の設定にする
クライアントを開き、「設定」「Profiles」「サブスクリプション」などの画面に移動します。「新規作成」「追加」「URLから読み込み」などを選び、サブスクリプションURL全体を入力欄に貼り付けます。「普段使い」など、見分けやすい名前を付けてもかまいません。名前は一覧での表示にのみ使われ、接続には影響しません。入力欄に前後の空白や改行、チャットアプリからコピーした記号が混ざっていないことを確認し、「追加」または「ダウンロード」をタップします。
クライアントのダウンロードと解析が完了するまで待ちます。成功すると、通常は設定名、取得元、更新日時などが一覧に表示されます。新しい項目が表示されただけでは、設定が有効になったとは限りません。その項目を選び、「有効化」「この設定を使用」などの操作で現在の設定にします。選択中の項目にマークが付くクライアントもあれば、概要画面に使用中の設定名が表示されるクライアントもあります。
読み込み後は、接続する前にプロキシグループを確認
「プロキシ」画面に切り替え、Proxy、ノード選択、自動選択など、設定ファイルで定義されたプロキシグループが表示されているか確認します。名称は設定の作成者が決めるため、このページと異なる場合があります。グループを1つ開き、ノードまたは別のサブグループが表示されることを確認してください。画面が空、DIRECTしか表示されない、または以前の設定のグループが残っている場合は、まず設定画面に戻って現在の設定を確認します。システムプロキシを何度も切り替える必要はありません。
ローカルファイルを受け取った場合は、「ファイルから読み込み」または「設定をインポート」を選び、ファイル選択画面で該当する .yaml または .yml ファイルを指定して、同じ手順で有効にします。ローカルファイルは読み込んでもリモートサブスクリプションにはなりません。ノードが更新された場合は再度読み込むか、設定に定義済みのリモートプロバイダー更新機能を利用してください。
ダウンロードエラーと解析エラーを分けて確認
「ダウンロードがタイムアウトしました」「サブスクリプションを取得できません」などのエラーは、設定を取得する前に発生します。端末のネットワーク、URLの有効期限、サービス提供元の稼働状況を確認してください。特定のネットワークからアクセスできないサブスクリプションURLもあるため、サービス提供元が案内する有効な取得方法を使います。認証情報を含むURLを不明な変換サービスに渡さないでください。ブラウザーでページが表示されないだけで、サブスクリプションが無効だと決めつける必要もありません。取得用インターフェースが特定のリクエスト方法を必要とする場合があります。
「解析に失敗しました」「未対応のフィールド」などのエラーは、内容を取得できたものの、現在の形式をクライアントが読み込めないことを示します。よくある原因は、ウェブページのURLを読み込んだ、ログイン画面が返された、またはサブスクリプションの形式がコアと互換性がないことです。まずサービス提供元にClashまたはmihomo互換形式か確認してください。インデントやフィールドが原因の場合はYAMLガイドを確認します。初回接続のために設定ファイル全体を書き直す必要はありません。
設定が有効で、プロキシグループを開けることを確認してから次へ進みます。リモートサブスクリプションの更新で、直接編集したノードやルールが上書きされる場合があります。初期設定では元の内容を残してください。ルールを継続的にカスタマイズする必要がある場合は、クライアントのオーバーライド機能やマージ機能を確認します。サブスクリプションの提供元や更新時の問題については、サブスクリプションに関するよくある質問をご覧ください。
ルールモードを選び、プロキシの出口を指定
「プロキシ」または「概要」画面でモード切り替えを見つけ、現在のモードを「ルール / Rule」に設定します。ルールモードでは、現在の設定にあるルールを上から順に適用します。宛先によって直接接続する場合と、プロキシグループに転送する場合があります。初回はサブスクリプションに含まれるルールをそのまま使い、まず通信経路全体が動作することを確認してから、独自の振り分け設定を追加します。
モードとノードは別々の設定です。モードはルールに従って通信を処理するかどうかを決め、プロキシグループはプロキシルールに一致した通信の出口を決めます。ルールモードのままデフォルトのプロキシグループを開き、利用可能と分かっているノードを選択します。グループに「自動選択」や「フェイルオーバー」がある場合は、該当するサブグループを選んでもかまいません。グループによっては初期状態でDIRECTが選択されています。DIRECTを選ぶと、そのグループは直接接続になります。
実際に使われるグループで選択されているか確認
1つの設定にウェブ、メディア、メッセージなど複数のプロキシグループが含まれる場合があり、1つのグループを変更してもすべての通信に反映されるとは限りません。他のグループから参照されているメインのプロキシグループを探すか、サブスクリプションの説明に従ってデフォルトの出口を選びます。参照関係が分からない場合は、むやみに各グループを変更しないでください。あとで接続ログから対象リクエストのプロキシチェーンを確認し、該当するグループを調整できます。
クライアントの接続テストは、明らかに使えない選択肢を除外するのに役立ちます。ただし、テストの成功は特定のテストリクエストに応答があったことを示すだけで、すべてのウェブサイトにアクセスできる保証にはなりません。まずテストに成功する出口を選び、実際に利用したいページで動作を確認します。テストの連打や頻繁なノード変更は、問題の原因を特定しにくくします。一度に変更する項目は1つにし、比較できるよう結果を記録してください。
ルール・グローバル・直接接続の使い分け
「グローバル / Global」では、コアに入った通信をすべてグローバルポリシーに従って処理します。端末上のすべてのアプリの通信を自動的に捕捉する機能ではなく、TUNを有効にする設定とも異なります。通信振り分けルールが原因かを切り分ける場合は、一時的にグローバルモードに切り替え、グローバル用のプロキシグループで利用可能なノードを選択します。テスト後はルールモードに戻し、本来は直接接続する通信までプロキシ経由にならないようにします。
「直接接続 / Direct」は、コアに入った通信を宛先に直接接続させる設定です。クライアントの終了や、OSのプロキシ設定の解除を意味するものではありません。プロキシによる通信の取り込みを完全に停止するには、モードをDirectにするだけでなく、ステップ4の手順でシステムプロキシを無効にするか、モバイル接続を切断してください。
「ノード」「プロキシグループ」「ルール」などの用語が分からない場合は、用語集をご覧ください。rules の記述、マッチ順序の調整、リモートルールセットの設定が必要な場合は、YAMLガイドを確認します。いずれも初回接続の前提条件ではありません。
システムプロキシまたはモバイル接続を有効にする
クライアントの概要画面に戻り、コアの起動エラーがないことを確認してから通信の入口を有効にします。デスクトップではまず「システムプロキシ」を使い、モバイルでは「接続」または起動ボタンをタップします。初回は接続方法を1つだけ使い、ほかのVPNやプロキシクライアント、ブラウザー独自のプロキシ設定を同時に有効にしないでください。複数のツールが同じシステム設定を上書きするおそれがあります。
デスクトップ：まずシステムプロキシを有効にする
Windows、macOS、Linuxのクライアントで「システムプロキシ」を見つけて有効にします。補助サービスのインストールやネットワーク設定の変更を求められた場合は、OSの許可画面に従ってください。使用中のクライアントからの要求であることを確認します。必要な権限を拒否すると、画面上のスイッチがオンでもシステム設定に反映されていない場合があります。OSのネットワークプロキシ画面でも確認してください。
システムプロキシを有効にすると、通常はOSの設定を参照するアプリがローカルのプロキシポートに接続します。多くのブラウザーはこの方法で接続できますが、アプリによって実装は異なります。コマンドラインツール、ゲーム、独自のネットワーク機能を持つソフトは、システムプロキシに従わない場合があります。まずブラウザーで確認し、特定のプログラムがプロキシを使わないだけでノードの障害と判断しないでください。ターミナルでの個別確認方法は次のステップで説明します。
クライアントにポートの競合が表示された場合は、まず同じポートで待ち受けている可能性のある別のプロキシツールを終了し、現在のコアを再起動します。ポートを変更する必要がある場合は、設定画面でHTTPポートまたは混合ポートの実際の値を確認し、手動で設定したアプリのプロキシアドレスも更新してください。例のポート番号をそのまま使わず、現在のクライアントに表示されている値を確認します。
Android・iOS：システムのVPN接続を許可
モバイル端末で現在の設定を選択し、接続ボタンをタップします。初回起動時は、システムからVPN接続の作成やVPN構成の追加を許可するよう求められる場合があります。許可したらクライアントに戻り、接続状態を確認してください。このVPN権限はシステム通信の入口を作るためのもので、サブスクリプションが自動的に利用可能になることを意味しません。有効な設定、利用可能な出口、接続の許可がすべて必要です。
接続ボタンを押してすぐにオフになる場合は、まずクライアントのエラーメッセージを確認し、ほかのVPNアプリが接続を使用していないか調べます。Androidでアプリごとのプロキシ設定を有効にしている場合は、テストに使うブラウザーが対象に含まれているか確認します。バックグラウンド実行が制限されていないかも確認してください。iOSでは、選択中の設定を起動していることを確認します。エラーの確認をせず、何度も再インストールして対処しないでください。
TUNは必要な場合にのみ有効にする
ブラウザーは正常に使えるものの、対象のプログラムがシステムプロキシを参照しない場合は、TUNを検討できます。TUNは仮想ネットワークインターフェースを使って通信を取り込みます。サービス権限、ルーティング、DNS設定が関係することもあり、スイッチを入れるだけですべてのプログラムをカバーできるとは限りません。初回はシステムプロキシとTUNを同時に有効にする必要はありません。まず基本の接続を確認し、その後クライアントの説明に従って段階的に設定します。
社内ネットワーク、リモートデスクトップ、LAN内の機器は特定のルートに依存している場合があります。TUNを有効にする前に、現在の接続情報を控えてください。DNSやFake-IPを変更する場合は、DNS設定ガイドとFake-IPの説明をそれぞれ確認します。接続の入口を有効にしたら、スイッチがオンになっただけで設定を終えず、実際の通信を確認してください。
ブラウザーとターミナルで確認し、切断後の復旧も確認
まず、普段から直接アクセスできるページを開き、基本のネットワーク接続に問題がないことを確認します。次に、プロキシ経由でアクセスする必要があるページを開きます。ブラウザーのキャッシュだけが表示されないよう、新しいタブで開くかページを再読み込みしてください。テスト中は同じノードと同じモードを維持します。結果に差が出た場合に、どの設定が原因か判断しやすくなります。
接続ログで通信経路を確認する
クライアントの「接続」または「Connections」画面を開き、ブラウザーからページに再アクセスして対象ドメインを探します。短時間で終了するリクエストは、検索、履歴、ログを使うと見つけやすくなります。確認するのは対象、適用されたルール、プロキシチェーンです。クライアントに「実行中」と表示されるだけでは、通信の確認になりません。該当する記録があれば、そのリクエストがコアに届いたことを確認できます。
記録にDIRECTと表示された場合は、設定の意図に沿った動作か確認します。ルールモードでは一部のサイトを直接接続することがあり、必ずしも接続失敗ではありません。プロキシ経由にすべき対象がDIRECTになっている場合は、適用ルールと関連するプロキシグループを確認します。プロキシチェーンが記録されているのにアクセスできない場合は、ノードの状態、接続先サービス、ログの具体的なエラーを調べます。すぐにDNSを変更する必要はありません。
ブラウザーのリクエストがまったく見つからない場合は、まずシステムプロキシの設定が反映されたか、ブラウザーが独自のプロキシ設定を使っているか、拡張機能がプロキシの入口を変更していないか確認します。モバイルでは、テストするアプリが通信の取り込み対象に含まれているかも確認してください。リクエストがクライアントに届いていない可能性があるため、この段階でノードを切り替えても解決しないことがあります。
ターミナルは個別に確認する
コマンドラインツールは、システムプロキシを参照しない場合があります。クライアントの混合ポートが 7890 の場合は、次のコマンドで1回だけテストできます。ポートが異なる場合は、先に設定画面に表示された値に置き換えてください。このコマンドは今回のリクエストに限ってHTTPプロキシを指定します。ターミナル環境を恒久的に変更せず、管理者権限も必要ありません。
curl --proxy http://127.0.0.1:7890 --head https://example.comexample.com はコマンドの書き方を示す例のドメインであり、プロキシサービスではありません。実際の対象サイトで確認する場合は、アクセスするHTTPSアドレスに置き換え、クライアントの接続ログも確認してください。レスポンスヘッダーが返ってくれば、そのリクエストに応答があったことが分かります。出口の確認には、接続ログのプロキシチェーンを使います。対象サイトによっては、独自の制限により異なるステータスコードが返されます。
プロキシを明示して成功し、ターミナルから直接実行すると失敗する場合は、サブスクリプションではなく、ターミナルにプロキシの設定がない可能性があります。必要に応じて、使用するツールのドキュメントに従ってプロキシ引数や環境変数を設定してください。汎用コマンドをすべてのシェルの起動ファイルに書き込むのは避けます。ツール、ポートの種類、変数の適用範囲はそれぞれ異なるため、具体的な要件を確認してから設定してください。
順番に原因を切り分ける
ブラウザーでアクセスできない場合は、まずリクエストが記録されているか確認します。記録があれば適用されたポリシーを調べ、ポリシーに問題がなければ利用可能と分かっている別のノードに切り替えます。ルールモードでのみ失敗する場合は、一時的にグローバルモードに切り替えて比較し、グローバル用グループで有効なプロキシが選ばれていることを確認します。グローバルでは使えてルールモードでは使えない場合は、ルールとグループの選択を確認します。どちらでも失敗する場合は、ノード、ネットワーク、ログを引き続き確認してください。
モード、DNS、ポート、TUNを一度に変更しないでください。毎回1つだけ変更して同じリクエストを再実行し、結果を記録します。こうすることで、差分を原因の切り分けに役立てられます。詳しい問題別の説明はよくある質問をご覧ください。設定フィールドまで原因を特定できたら、YAMLガイドで該当箇所を確認します。
最後に切断して復旧を確認
接続を確認できたら、デスクトップでは先にシステムプロキシを無効にしてからクライアントを終了します。モバイルでは接続を切断します。普段から直接アクセスできるページを開き直し、ネットワークが復旧したことを確認してください。クライアント終了後にブラウザーがインターネットへ接続できない場合は、システムにローカルプロキシの設定が残っていないか確認し、不要な手動プロキシ設定を無効にします。別のクライアントに乗り換える際も、旧クライアントの通信の入口を先に解除してください。
サブスクリプションを更新した後は、まず正しい設定を使用中か確認します。次に、元のプロキシグループが残っているか、選択内容が変わっていないかを調べ、最後に同じ対象へ再度アクセスして動作を確認します。この一連の手順を覚えておけば、特定のクライアントのボタン位置に頼らず、端末の移行や問題の切り分けを進められます。