使い方ガイド / 初回接続
Clashの使い方ガイド:サブスクリプションの追加と接続確認
まずは設定ファイル、接続先、アプリをそれぞれ一つに絞って正常に動作させてから、TUN、DNS、高度なルーティングを検討しましょう。初回利用の手順に沿って進めれば、基本設定は通常10分ほどで完了します。サブスクリプションやネットワークに問題がある場合は、別途トラブルシューティングが必要です。
ステップ1:サブスクリプションを追加して設定を有効にする
まず結論から説明します。クライアントをインストールしただけでは、利用できる接続先はありません。作業を始める前に、サービス提供元から案内されたClash対応のサブスクリプションURL、または利用可能なYAML設定ファイルを用意してください。サブスクリプションには通常、ノード、プロキシグループ、ルーティングルールが含まれ、クライアントがそれらを読み込んで適用します。サービスのログインページや注文ページ、一般的な共有ページのURLをサブスクリプションとして使わないでください。ウェブページの内容が返され、形式エラーになることがあります。
リモートサブスクリプションを追加する
クライアントを開き、「設定」「サブスクリプション」または「Profiles」に進んで、「追加」「インポート」やプラスアイコンのメニューを探し、「リモートサブスクリプション / URL」を選びます。URL全体を入力欄に貼り付け、わかりやすい名前を付けてから「保存」「インポート」または「ダウンロード」をタップします。「保存」と「更新」が別の操作になっている場合は、保存後に更新も実行し、ダウンロードが完了するまで待ってください。
貼り付ける際は、URLの前後に空白や改行、チャットアプリが付けた句読点が入っていないか確認してください。クリップボードからインポートできるクライアントでも、読み込み後にURLを確認しましょう。サブスクリプションのトークンはアクセス情報にあたります。URL全体を公開コメントやスクリーンショットに載せないでください。下記のアドレスはURLの形式を示す例であり、接続先ではありません。アクセスする必要はありません。
https://example.com/sub?token=xxxx
サービス提供元が複数のサブスクリプション形式を案内している場合は、現在のClashまたはmihomoコアに対応すると明記された形式を選んでください。ブラウザーでURLを開けるからといって、利用可能な設定が返るとは限りません。「解析に失敗しました」「unsupported」と表示される、またはプロキシノードが見つからない場合は、まずサブスクリプションの形式を確認してください。個人用のURLを見知らぬオンライン変換サイトに入力するのは避けましょう。原因についてはトラブルシューティングもご覧ください。
インポート結果を確認して、現在の設定にする
更新が完了すると、設定一覧に名前や更新日時、状態が表示されます。該当する設定の「使用」「有効化」をクリックするか、カードを選択してください。次に「プロキシ」画面を開き、プロキシグループとノードが表示されていることを確認します。よくあるのが、ダウンロードだけ済ませて古い設定を使い続けているケースです。設定が一覧にあるだけでは、有効になったとは限りません。ダウンロード完了の通知だけでなく、現在選択中の表示とプロキシ画面の内容で判断してください。
ローカルのYAMLファイルを使う場合は、「ファイルからインポート」を選び、実際の設定ファイルを指定してください。圧縮ファイルは選ばないでください。初回は元のファイルを残し、内容を手動で書き換えないようにします。設定が正常に読み込まれ、プロキシグループが表示されたらステップ2に進めます。ここでつまずく場合は、システムプロキシやDNSを変更する前に、まずインポートの問題を解決してください。
後からノードが変わった場合は、同じサブスクリプションの「更新」をクリックすればよく、通常は追加し直す必要はありません。更新によってサブスクリプションファイルに直接加えた変更が上書きされることがあるため、この記事では元の内容を編集しません。独自ルールを保持したい場合は、YAMLガイドの上書き・マージの説明を確認してください。初回接続時にこれらの設定も同時に変更するのは避けましょう。
ステップ2:ルールモードとプロキシノードを選ぶ
設定を有効にしたら、「プロキシ / Proxies」画面を開き、「ルール」「グローバル」「DIRECT」の3つから、まずルール / Ruleを選びます。モードは、コアに届いたリクエストの出口を決めるものです。すべてのアプリが自動的にプロキシを使うようになるわけではありません。ここではルーティングを選択し、次のステップでシステムプロキシまたはVPN接続を有効にします。この2つを混同しないようにしましょう。
普段はルールモードを選ぶ
ルールモードでは、現在の設定ファイルにあるルールに従って、リクエストごとに直接接続するか、プロキシグループを経由するかが決まります。グローバルモードでは、コアに届いたリクエストがグローバルの出口を使いますが、すべてのアプリの通信が自動的に取り込まれるわけではありません。DIRECTモードは、コアに届いたリクエストを宛先へ直接接続します。システムプロキシを無効にするモードではありません。特別な要件がなければ、初回はルールモードのままで構いません。何度も切り替える必要はありません。
「グローバルモードなら必ず速い」というのはよくある誤解です。速度は接続先の品質、アクセス先のサービス、ネットワークの混雑、ローカル接続にも左右されます。モードを切り替えても、こうした条件が改善するわけではありません。特定のサイトに問題がある場合は、一時的にグローバルモードで比較できますが、テスト後は元のルールモードに戻してください。戻さないと、本来直接接続するサービスの出口も変わる可能性があります。詳しくはルール・グローバル・DIRECTモードの違いをご覧ください。
実際に使うプロキシグループでノードを選ぶ
モードを選んだら、メインのプロキシグループを開き、使用するノードを選択します。グループ名はサブスクリプションによって異なり、「ノード選択」「プロキシ」などの場合もあれば、必ずしもPROXYとは限りません。設定によってはサービスごとにプロキシグループが分かれているため、全体の入口ではない別のグループを選んでも、現在のサイトの出口が変わらないことがあります。初回接続では、設定が標準で使うメインのグループを見つけ、複数のグループを同時に変更しないようにしましょう。
「遅延テスト」や「接続テスト」を実行し、タイムアウトするか確認できます。テスト先はクライアントで指定されたアドレスです。遅延の数値はダウンロード速度を表すものではありません。テストに成功しても、すべてのサイトに接続できるとは限りません。特定のノードがタイムアウトしたら、別のノードでも試してください。すべて失敗する場合は、設定全体をすぐに変更せず、サブスクリプションの有効期限、ローカルネットワーク、クライアントのログを確認しましょう。速度テストの違いについてはノードの遅延と接続トラブルに関するQ&Aもご覧ください。
自動選択グループでは、テスト結果に応じてクライアントが出口を切り替えることがあります。手動選択グループでは、通常、選択したノードがそのまま使われます。問題を切り分けやすくするため、初回の確認では利用可能なノードを一つ選び、名前を覚えておくとよいでしょう。ここまでで、使用中の設定、選択したモード、リクエストの送信先となるプロキシグループが明確になっているはずです。確認できたら接続を開始します。
ステップ3:システムプロキシまたはVPN接続を有効にする
次に、アプリのリクエストがクライアントに届くようにします。コアの起動と通信の取り込みは別のことです。デスクトップではクライアント起動時にコアが動作していても、ブラウザーがまだコアを使っていない場合があります。モバイルでも、設定をインポートした後に接続ボタンを押す必要があります。初回操作では他のプロキシクライアントを終了し、システム設定の競合を防いでください。複数のVPN接続を同時に有効にしても、通信が重なるわけではありません。
デスクトップ:コアの動作を確認してシステムプロキシを有効にする
クライアントのホーム画面または「設定」でコアが動作中であることを確認し、「システムプロキシ / System Proxy」を有効にします。補助サービスのインストールやネットワーク設定の変更を求められた場合は、案内元を確認してから、クライアントの手順に従って許可してください。システムプロキシを有効にすると、システム設定に従うブラウザーやアプリのリクエストがローカルのリスニングポートに送られます。ターミナルツール、ゲーム、独自のネットワーク設定を持つアプリなどは、自動的にプロキシを使わない場合があります。
初回接続ではクライアントの標準ポートを使い、「LAN内からの接続を許可」は有効にしないことをおすすめします。以下はローカルリスニング設定の例です。項目を確認するためのものであり、サブスクリプション全体に貼り付けて置き換える必要はありません。実際のポートはクライアントの現在の設定に従ってください。この記事に7890と書かれていても、システム内のすべての設定をその値に変更しないでください。
config.yaml · ローカルリスニング設定の例
mixed-port: 7890
allow-lan: false
mode: rule
mixed-portはHTTPとSOCKSで共用するリスニングポートです。allow-lan: falseはLANからのアクセスを制限します。ログにポートが使用中と表示された場合は、別のクライアントや古いプロセスが起動していないか確認してください。正体のわからないシステムプロセスを安易に終了しないでください。ポートを変更する必要がある場合は、クライアントの設定から変更し、システムプロキシも再適用して両方を一致させます。詳しくはポート競合の対処法をご覧ください。
Linuxのデスクトップ環境では、システムプロキシへの対応が一様ではありません。クライアントでシステムプロキシを有効にしてもブラウザーが接続しない場合は、デスクトップ環境とブラウザーのネットワーク設定を確認してください。TUNはシステムプロキシとは異なる方法で通信を取り込む場合に使えますが、権限、ルーティング、DNSに関わることがあります。まずブラウザーの基本的な接続を確認し、必要に応じてYAMLガイドをご覧ください。この段階でTUNの有効化、DNSの変更、ルートの変更を同時に行わないでください。
モバイル:システムのVPN接続を許可する
Androidではホーム画面の起動または接続ボタンをタップします。初回は通常、システムからVPN接続の許可を求められます。許可した後、クライアントに接続済みと表示されるまで待ち、システムのステータスバーのアイコンと常駐通知を確認してください。ここでいうVPNは、システムが提供する通信の取り込み方法です。クライアントが別の接続先を提供するという意味ではありません。実際の出口は、先ほど追加した設定と選択したノードによって決まります。
iOSでは接続をタップした後、VPN構成の追加を許可し、システムが求める認証を行う場合があります。完了したらクライアントに戻り、接続状態を確認してください。許可しなかった場合は、システム設定でクライアントのVPN権限を確認してから、もう一度接続します。権限の問題を解決するために、サブスクリプションを何度もインポートし直す必要はありません。Androidで画面ロック後にだけ切断される場合は、バックグラウンド実行とバッテリー制限を確認してください。詳しくはバックグラウンド切断とバッテリー最適化の設定をご覧ください。
ステップ4:実際の通信とルーティング結果を確認する
接続アイコンが点灯していても、スイッチや接続状態が有効になったことしかわかりません。完了の判断基準は、目的のページにアクセスでき、リクエストが想定どおりにルーティングされていることです。現在の設定とノードは変更せず、まずブラウザーで簡単なテストを行い、接続ログと照らし合わせます。ページが開かないからといって、ノード、モード、DNSを一度に変更しないでください。どの変更が効いたのか判断しにくくなります。
2つのページと接続ログで確認する
まず、普段からアクセスできる一般的なサイトを再読み込みし、ローカルネットワークが正常であることを確認します。次に、プロキシ経由でのアクセスを想定したサイトを開いてください。キャッシュの影響を減らすには、新しいシークレットウィンドウから再度アクセスできます。ただし、シークレットウィンドウですべてのDNSキャッシュやシステムキャッシュを回避できるわけではありません。ページが読み込めたら、クライアントの「接続 / Connections」画面に戻り、該当するリクエストのドメイン、適用ルール、出口の設定を確認します。
表示項目はクライアントによって多少異なります。ルールから出口までの経路全体が表示される場合もあれば、宛先と出口だけが表示される場合もあります。確認するのは、該当リクエストがDIRECTなのか、選択したプロキシグループとノードを経由しているのかです。ルールモードでは、一部のサイトが直接接続されるのは正常です。すべての接続にプロキシが適用される必要はありません。DIRECTのログが1件見つかっただけで、クライアント全体が動作していないとは判断できません。ページは複数の異なるドメインからリソースを読み込むことがあります。
IP確認サイトに表示されるのは、そのページへアクセスしたときの出口だけです。すべてのアプリやドメインの通信を示すものではありません。確認サイトが直接接続に設定されている場合や、ブラウザーと他のアプリで通信の取り込み方法が異なる場合もあります。IPが変わらないだけでクライアントを再インストールしたり、IPが変わっただけで全アプリの通信が取り込まれていると判断したりしないでください。実際のアクセス先と対応する接続ログを合わせて確認することが大切です。
症状から問題の範囲を絞り込む
クライアントにブラウザーからの新しいリクエストがまったく表示されない場合は、システムプロキシが有効か、ブラウザーに個別のプロキシ設定がないか、リスニングポートが一致しているかを確認します。モバイルではVPN接続が確立しているか、アプリの除外ルールが有効になっていないか確認してください。リクエストが表示されるのにタイムアウトする場合は、まず別のノードで再テストします。特定のドメインだけ失敗する場合は、そのドメインに適用されたルールとログを確認してください。一つのサイトの問題だけでネットワーク設定全体を切り替えないようにしましょう。
プロキシをオフにしても一般的なサイトに接続できない場合は、クライアントでシステムプロキシを無効にするかVPNを切断し、システムにローカルポートを指定するプロキシ設定が残っていないか確認してください。ローカルネットワークが復旧したことを確認してから、プロキシ接続の違いを調べましょう。名前解決エラー、証明書エラー、頻繁な切断が発生した場合は、エラーメッセージの原文と発生時刻を記録し、症状に応じてトラブルシューティングを確認してください。設定項目の意味を知りたい場合はYAML設定リファレンスをご覧ください。初めて使う段階で、すべての項目を読む必要はありません。
動作確認後の日常的な使い方
接続に問題がなければ、ルールモードを維持し、必要に応じてサブスクリプションを更新してください。更新後にノード名やプロキシグループが変わった場合は、選択中の項目を確認しましょう。以前の選択がそのまま残っているとは限りません。使用を終えるときは、デスクトップでは先にシステムプロキシを無効にしてからクライアントを終了し、モバイルでは先にVPN接続を切断してください。クライアントのリスニングが停止した後も、アプリがローカルのプロキシポートへリクエストを送り続ける事態を防げます。
最後に、次の順序を覚えておきましょう。設定を確認 → 出口を選択 → 通信を取り込む → 実際に確認。一度に一項目だけ変更してすぐ再テストすると、何度も再インストールするより原因を特定しやすくなります。問題を他の人に相談する際は、クライアント名、OS、失敗した手順、個人情報を伏せたエラー内容を伝えてください。サブスクリプションのトークン、アカウント情報、個人用設定ファイル全体は共有しないでください。