初回起動は設定から。通信の取り込みはその後
Clashを初めて使うときは、まずサブスクリプションを追加して有効化し、コアの起動とポートの待ち受けを確認します。次にルールモードとノードを選び、最後にシステムプロキシまたはVPNで通信を取り込みます。デスクトップでは、まずシステムプロキシを使ってブラウザーで動作を確認しましょう。対象アプリがシステムプロキシを使わない場合に限り、TUNモードを検討します。手順ごとの確認対象を絞れば、サブスクリプション・DNS・仮想NICを一度に調べずに済みます。
Clashクライアントは操作画面、コアは通信処理を担い、サブスクリプションからノードやプロキシグループ、場合によってはルールを取得します。mihomo(Clash Metaとも呼ばれます)コアを使うクライアントと、オリジナルのClashでは対応する設定項目が完全には一致しません。ダウンロードが完了し、画面が開いても、サブスクリプションが有効になったことやプロキシが機能していることにはなりません。
- コアの状態を確認:ホーム画面に実行中と表示されていることを確認します。ログに設定の解析失敗やポートのバインド失敗が繰り返し出ていないことも確認してください。
- サブスクリプションを追加:更新が成功したら、該当する設定カードをクリックして現在の設定に指定します。
- ポートを確認:実際の混合ポートを確認します(例:
7890)。ほかの解説記事にあるポート番号をそのまま使わないでください。 - 接続先を選択:ルールモードに切り替え、ルールで参照されているプロキシグループから利用可能なノードを選びます。
- 通信を取り込んで確認:取り込み方法を1つ有効にしてWebページにアクセスし、接続履歴と適用されたルールを確認します。
サブスクリプションの追加:更新後に設定を有効化する
サブスクリプションURL・ノードリンク・WebページのURLを区別する
サブスクリプションURLは通常、トークンを含むHTTPSリンクで、クライアントが設定を取得するために使います。サービス事業者の管理画面、決済ページ、利用ガイドのページはサブスクリプションURLではありません。個別のノードリンクも、クライアントに変換機能やノード管理機能があるかどうかによっては、完全なClash設定としてそのまま追加できないことがあります。
一般的なデスクトップクライアントでは、「サブスクリプション」または「設定」→「新規作成/インポート」→サブスクリプションURLを貼り付け→「保存/ダウンロード」の順に操作します。メニュー名はクライアントごとに異なるため、実際の画面に従ってください。ダウンロード後、設定一覧から該当項目を選択します。「更新成功」と表示されても現在の設定が初期設定のままでは、ノードは自動的に切り替わりません。
- ノード一覧が空:追加したばかりの設定が選択されているか、取得した内容がクライアントの対応する設定形式か確認してください。
- HTTP 401または403が表示される:まずサブスクリプションの有効期限、トークンの有効性、サーバー側のリクエスト制限を確認します。最初にDNSを変更する必要はありません。
- 解析エラーが表示される:ログに記載された項目名と行番号を確認します。mihomo専用のプロトコルや項目を含む設定は、オリジナルのコアでは動作しない場合があります。
- ダウンロードがタイムアウトする:まずサブスクリプションのドメインにアクセスできるか確認します。「プロキシ経由でサブスクリプションを更新」する機能を使う場合、この方法を利用するには動作中の設定が必要です。
追加後に確認する3つのポイント
1つ目は、設定カードが選択中になっていること。2つ目は、プロキシ画面にノードまたはプロキシグループが表示されること。3つ目は、ログに設定の読み込み完了が記録され、コアが再起動を繰り返していないことです。ルールや自動選択グループが含まれるかどうかは設定の提供元によって異なります。ノード数が多いだけでは、通信の振り分けが適切に設定されているとは限りません。
混合ポート:7890を覚えるのではなく、実際の値を確認する
混合ポート(mixed-port)は、1つの待ち受けポートでHTTPプロキシとSOCKSプロキシの接続を受け付けます。7890はよく使われる値ですが、すべてのクライアントで固定されているわけではありません。クライアントの「設定」→「ポート」または「設定」→「混合ポート」で実際の値を確認し、アプリ側のプロキシ設定と一致させてください。
| 項目 | 例 | 確認ポイント |
|---|---|---|
| 混合ポート | 127.0.0.1:7890 | ローカルのアプリがこのポートに接続し、HTTPまたはSOCKSプロキシを使用します。 |
| HTTP専用ポート | port: 7890 | 混合ポートとは別の設定項目です。2つの待ち受けポートが重複しないようにしてください。 |
| SOCKS専用ポート | socks-port: 7891 | この待ち受け設定が有効な場合にのみ使用します。必ず存在するとは限りません。 |
| コントロールAPI | 127.0.0.1:9090 | 画面からコアを操作するためのもので、ブラウザーやアプリのプロキシポートではありません。 |
以下の設定例は基本項目を確認するためのもので、そのままインポートできる完全なサブスクリプションではありません。クライアントによっては実行時設定がこれらの値を上書きするため、最終的に適用されている値を確認してください。例に合わせるために、既存のノード、ルール、プロキシグループを上書きしないでください。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ポートが使用中なら、まず古いプロセスを確認する
ログにaddress already in useと表示されたり、ポートのバインドに失敗したりする場合、通常は同じアドレスのポートを別のプロセスが使用しています。古いプロキシクライアントを終了してから、現在のクライアントを起動してください。それでも競合する場合は、混合ポートを17890に変更し、手動で設定したアプリのプロキシアドレスも更新します。コアのポートだけ変更して、アプリが7890に接続し続けると、リクエストは失敗します。
初めて使うときは、「LANからの接続を許可」をオフのままにしてください。スマートフォンからPCのプロキシを使う場合、スマートフォン上の127.0.0.1が示すのはスマートフォン自身であり、PCではありません。LAN共有には、待ち受けアドレス、アクセス制御、ファイアウォールの別途設定が必要です。初回起動時の設定と同時に行うのは避けましょう。
プロキシモード:ルール・グローバル・DIRECTの選び方
普段使いにはルールモードがおすすめです。ルールモードでは、設定内のルールに基づいて、接続ごとにDIRECT、プロキシグループ、拒否などの出力先を選びます。「海外のWebサイトはすべてプロキシ経由」という意味ではありません。実際の動作はルールの順序とプロキシグループの選択によって決まります。ルールは通常上から順に照合され、どのルールにも一致しない接続は最終的にMATCHで処理されます。
- ルール(Rule):普段の通信振り分けに使います。どのルールに一致したかだけでなく、対応するプロキシグループで何が選択されているかも確認してください。
- グローバル(Global):コアに入った接続をグローバルポリシーで処理します。ルールやノードの問題を一時的に比較するのに便利です。グローバルグループで具体的な出力先も選択してください。
- DIRECT:コアに入った接続を直接接続します。一時的な切り分けに使えますが、「プロキシが有効」という意味ではありません。
モードが決めるのはコアに入った後の通信の出力先であり、システムプロキシやTUNが決めるのはどの接続をコアに取り込むかです。そのため、「グローバルに切り替えたのにアプリがプロキシを使わない」ことはあり得ます。そのアプリがシステムプロキシを使っていない可能性があります。
ノードの速度テストだけでは実際の接続を確認できない
レイテンシテストでは通常、指定されたテスト用アドレスにのみアクセスします。120 msと表示されても、目的のWebサイトや動画、UDP通信が利用できるとは限りません。手動選択のグループではノードが選択済みか、自動選択グループでは現在どのノードが使われているかを確認します。調査時は候補ノードを1つに固定し、テストのたびに出力先が変わって比較できなくなるのを防ぎましょう。
OS別の通信取り込み:デスクトップのシステムプロキシとスマホのVPN
| OS | 最初に行う設定 | 見落としやすい点 |
|---|---|---|
| Windows | 設定を有効化し、クライアントのシステムプロキシを有効にします。 | 「設定」→「ネットワークとインターネット」→「プロキシ」でローカルアドレスとポートを確認します。 |
| macOS | クライアントによるネットワークプロキシの変更を許可し、現在のネットワークサービスを確認します。 | 「システム設定」→「ネットワーク」→接続中のネットワーク→「詳細」→「プロキシ」で確認します。項目名はOSのバージョンによって異なります。 |
| Linux | デスクトップのプロキシ、またはアプリ内プロキシが設定されているか確認します。 | ターミナルのプログラムがデスクトップのシステムプロキシを使うとは限りません。個別に設定するか、コマンドで明示的にプロキシを指定してください。 |
| Android | 設定を選択して接続を開始し、システムのVPN接続要求を許可します。 | 既存のVPN、アプリ別の振り分けリスト、バックグラウンドのバッテリー制限が通信の取り込みに影響する場合があります。 |
| iOS | 対応する設定を使えるクライアントを選び、システムの案内に従ってVPN設定を追加します。 | デスクトップ版のメニューをそのまま当てはめることはできません。ノードのプロトコルと設定形式がクライアントの対応範囲内か確認してください。 |
Windows・macOS:まずブラウザーでシステムプロキシを確認
システムプロキシと拡張機能のプロキシ設定が競合しないよう、まずブラウザー拡張機能で個別に設定したプロキシを無効にしてください。Windowsファイアウォールの警告が出ても、すべてのネットワークからの受信接続を許可する必要はありません。必要なネットワークだけに許可します。ローカルのループバックプロキシを使うだけなら、トラブルシューティングのためにファイアウォール全体を無効にしないでください。
Linux:ブラウザーが使えても、ターミナルの設定が済んだとは限らない
ターミナルのダウンロードツール、パッケージマネージャー、開発ツールは、それぞれ独自のプロキシ設定を使う場合があります。まずコマンドでプロキシを明示し、コアが使えることを確認してから、環境変数への設定を検討してください。HTTPS_PROXYを設定するとき、変数名のHTTPSは宛先リクエストの種類を示します。一般的なHTTPプロキシのアドレスはhttp://127.0.0.1:7890のままで構いません。https://に変更する必要はありません。
Android・iOS:VPNの競合と対象アプリを確認
Androidでは、VPNサービスを使うプロキシクライアントは、別の同種VPNと同時に動作できないのが一般的です。アプリ一覧で「選択したアプリのみ」が指定されている場合、テストするブラウザーも対象に含めてください。iOSではVPNの接続状態と、クライアントのバイパスルールを確認します。画面上部のVPN表示だけでは、リクエストがどのノードを通ったか判断できません。
接続確認:ポート・接続履歴・Webページを照合する
確認作業では、一度に変更する設定を1つに絞ってください。まずコアのログに問題がないことを確認し、次に通常は直接接続できるWebサイトを開き、最後に目的の出力先が必要なサービスへアクセスします。同時にクライアントの「接続」または「ログ」を開き、対象ドメイン、適用ルール、出力先のポリシーを確認してください。Webページが開いても接続履歴がない場合、直接接続、キャッシュ、別のプロキシ、または現在のコアに取り込まれていない接続を使った可能性があります。
プロキシを明示したコマンドでシステムプロキシの問題を切り分ける
以下のコマンドでは、混合ポートを7890と仮定しています。WindowsではPowerShellでcurl.exeを使うと、環境によって異なるcurlのエイリアスを避けられます。macOSとLinuxではcurlを使用できます。ポート番号が異なる場合は、コマンド内の数字を置き換えてください。
curl.exe -I --connect-timeout 10 --max-time 20 -x http://127.0.0.1:7890 https://example.com
curl -I --connect-timeout 10 --max-time 20 -x http://127.0.0.1:7890 https://example.com
ここでの10秒は接続確立までのタイムアウト、20秒はリクエスト全体の最長時間で、速度テストの結果ではありません。例のドメインはリクエスト経路の確認用です。特定のサービスをテストする場合は、そのサービスのHTTPSアドレスに置き換えてください。HTTPプロキシの出力にある200 Connection establishedは、トンネルが確立したことを示すだけです。引き続き、接続先サーバーの応答とクライアントの接続履歴を確認してください。
- ローカルポートへの接続にすぐ失敗する:コアが動作中か、アドレスが正しいか、ポート番号が一致しているかを確認します。
- 明示的なプロキシ指定では接続できるが、ブラウザーでは使えない:システムプロキシ、ブラウザー独自のプロキシ設定、拡張機能を確認します。サブスクリプションは最初に変更しないでください。
- 接続履歴はあるが、リクエストがタイムアウトする:選択中のノード、適用されたポリシー、接続先サービスへの到達性を確認し、別のノードでも比較します。
- ドメイン名のアクセスだけに問題がある:ログを見てDNSを確認します。名前解決エラーが1回あっただけで、TUNを有効にする必要があるとは限りません。
- Webページで証明書エラーが表示される:まずシステム時刻、証明書の発行者、接続先ドメインを確認します。証明書検証を無効にしてログインを続けないでください。
初期設定後に保存と復元を確認する
接続確認が終わってから、サブスクリプションの自動更新とスタートアップ時の自動起動を設定します。まずクライアントを手動で再起動し、現在の設定、モード、プロキシグループの選択が復元されることを確認してください。デスクトップクライアントの自動起動には、「画面の起動」「コアの起動」「システムプロキシの自動有効化」があります。これらは必ずしも連動していません。
- 動作する設定の組み合わせを記録:クライアント名、コアの種類、現在のサブスクリプション、混合ポート、プロキシモード、通信の取り込み方法。
- ローカルでの変更を保護:サブスクリプションの更新で直接編集した内容が上書きされる場合があります。変更を維持するには、クライアントが対応するオーバーライド機能またはマージ機能を使ってください。
- 終了後の復元を確認:通常の方法で終了した後、システムプロキシが無効になるか元の設定に戻ることを確認します。復元されないと、待ち受けを停止したポートにアプリが接続し続ける場合があります。
- トラブルシューティング用の情報を保存:エラーが発生した時刻と、機密情報を伏せたログを保存します。サブスクリプショントークン、認証情報、アクセス記録全体は公開しないでください。
「設定が有効」「ポートが待ち受け中」「プロキシグループが選択済み」「通信がコアに取り込まれている」「対象リクエストが正しい出力先を使っている」の5点を確認できれば、初期設定の検証は完了です。その後、特定のアプリだけがプロキシを使わない場合は、そのアプリの通信取り込み方法を見直します。すべてのスイッチを何度も切り替える必要はありません。設定項目やルールを詳しく知りたい場合はClash設定ガイドを、明確なエラーが表示された場合はよくある質問を参照して、問題の範囲を絞り込んでください。