1. Clash、クライアント、mihomoコアの違いは？

まずOSに合ったクライアントを選び、コアとサブスクリプション設定の互換性を確認しましょう。クライアントはサブスクリプション管理、プロキシ選択、各種設定の画面を提供し、コアは設定の読み込み、ルールの照合、接続の確立を担います。クライアントをインストールしただけでは、利用可能なプロキシサーバーは使えません。利用権限のあるサブスクリプションまたは設定を別途読み込む必要があります。

Clashは、この種のツールや設定エコシステムで広く使われている名称です。オリジナルのClashコアと後続の派生版は、同じ機能を持つとは限りません。Clash Metaは後にmihomoへ名称変更されました。新しいプロトコル、ルール、DNS機能が利用できるかどうかは、実際に動作しているコアのバージョンで確認してください。クライアント名にClashとあっても、使用しているコアまでは判断できません。

  • Windows：設定管理機能を備えたデスクトップクライアント、たとえばClash Verge Revから始めるとよいでしょう。インストール前に「設定」→「システム」→「バージョン情報」でシステムの種類を確認し、x64とARM64を見分けてください。
  • macOS：Appleメニューから「このMacについて」を開き、AppleシリコンかIntelかを確認して対応するインストーラーを選びます。クライアントが対応する最低OSバージョンも確認してください。
  • Android：Clash Meta for Androidなど、メンテナンス状況、コア、システム要件が明記されたクライアントを選びましょう。インストールパッケージのアーキテクチャが端末に対応していることも確認してください。
  • iOS：クライアントが実際に対応しているサブスクリプション形式を基準に選びましょう。すべてのプロキシアプリがClash YAMLをそのまま読み込めるわけではありません。

インストーラーの入手先はクライアントダウンロードページをご覧ください。設定内の項目を認識できない場合は、クライアントのバージョン、コア名、エラー行番号を記録してから互換性を確認しましょう。見慣れない項目をむやみに削除しないでください。

2. サブスクリプションURLの読み込み方と、形式エラーが出る原因は？

サブスクリプションURLは設定を取得するためのアドレスであり、クライアントそのものではありません。また、Clash形式の設定が返されるとは限りません。デスクトップクライアントの「サブスクリプション」または「設定」画面でURLの読み込み機能を開き、URL全体を貼り付けてダウンロードした後、その設定を選択します。Clash Verge Revの一般的な画面では、「サブスクリプション」ページのURL入力欄に貼り付けて「インポート」をクリックします。画面の表示はバージョンによって異なる場合があります。

  1. サブスクリプション提供元からClashまたはmihomo向けのURLをコピーし、クエリパラメーターを残してください。余分な引用符や空白は加えないでください。
  2. 読み込み後、設定が一覧に表示されるだけでなく、有効になっているか確認してください。
  3. プロキシ画面を開き、ポリシーグループで選択肢を選べることを確認します。設定名が表示されていても、リソースの読み込みが完了したとは限りません。
  4. ローカルの.yamlまたは.ymlファイルの場合は、ファイル読み込みを使います。ディスク上のパスをサブスクリプションURLとして入力しないでください。

一般的な完全形式の設定にはproxies、proxy-groups、rulesなどの項目があり、proxy-providersで外部リソースを参照する場合もあります。ss://、vmess://などの共有リンクだけのテキストや、Base64でエンコードされたノード一覧は、通常そのまま完全なYAML設定として読み込めません。

3. システムプロキシを有効にすると、どのアプリがプロキシを使う？

システムプロキシの影響を受けるのは、システムのプロキシ設定を参照するアプリだけです。端末のすべての通信が自動的にプロキシ経由になるわけではありません。デスクトップブラウザーは通常システム設定を参照しますが、コマンドラインツール、ゲーム、独自の通信処理を実装したプログラムは従わない場合があります。クライアントでシステムプロキシが有効と表示されていても、すべての通信がコアを経由するとは限りません。

アドレスと待ち受けポートを確認する

ここでは、クライアントが実際にmixed-port: 7890で待ち受けている場合を例にします。このポートはHTTPとSOCKSのプロキシ要求を受け付けます。7890はあくまで例であり、すべてのクライアントで共通の固定値ではありません。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスが127.0.0.1であること、ポートがクライアントと一致することを確認してください。

クライアントがシステムプロキシを自動管理する場合は、クライアントのスイッチで設定しましょう。Windowsの設定画面とクライアントが互いの設定を上書きし合うのを避けられます。テスト中はプロキシクライアントを1つだけ起動し、ブラウザーで別のプロキシサーバーを指定する拡張機能は無効にして、設定同士の干渉を減らしてください。

  • ブラウザーではアクセスできるのにターミナルでは失敗する場合は、ノードをすぐに変更せず、ターミナルのプログラムにプロキシが設定されているか確認します。
  • どのブラウザーでも失敗する場合は、コアが起動しているか、ポートが待ち受けているか、設定が有効かを確認します。
  • クライアントを終了した後にWebサイトへ接続できなくなった場合は、停止済みのローカルプロキシポートをシステムがまだ参照していないか確認します。

4. TUNモードとシステムプロキシの違いは？両方を有効にするべき？

TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込み、システムプロキシではカバーできない場合に役立ちます。デスクトップOSでは、適切な権限、サービス、ドライバーが必要になることがあります。Androidでは通常、クライアントがシステムのVPNインターフェースを使って通信を取り込みます。TUNはノードを高速化する機能ではなく、サブスクリプションの期限切れやリモートサーバーへの接続不能を解決するものでもありません。

方式主な通信経路初めて使う場合のおすすめ
システムプロキシアプリがシステムのHTTPなどのプロキシ設定に従うまずブラウザーで設定の読み込みとノードの利用可否を確認する
TUNモード仮想インターフェースにルーティングとDNS設定を組み合わせて通信を取り込む次にシステムプロキシに従わないアプリをテストする

クライアントによっては両方を併用できますが、初心者が問題を切り分けるときは、一度に変更する項目を1つにするのがおすすめです。まずTUNをオフにし、システムプロキシ経由でブラウザーが使えることを確認します。その後、クライアントの要件に従ってサービスをインストールし、必要な権限を付与してTUNを有効にしてください。TUNを有効にしたときだけ問題が起きる場合は、ノードのせいと決めつけず、ルーティング、DNS、他のVPN、仮想ネットワークアダプターとの競合を確認しましょう。

会社のVPN、別のプロキシクライアント、仮想化ソフトウェアがルーティングを変更する場合があります。テスト前にそれぞれの状態を記録し、TUNを有効にするためにシステムのネットワークアダプターをむやみに削除したり、セキュリティ対策をすべて無効にしたりしないでください。

5. ルール・グローバル・ダイレクトモードはどう選ぶ？

通常の利用では、まずルールモードを選び、どのポリシーグループに振り分けられたかを確認します。モードはコアが接続先を選ぶ方法を決め、ポリシーグループはルールに一致した通信でどのプロキシまたはダイレクト接続を使うかを決めます。

  • ルールモード（rule）：ルール一覧を上から順に照合し、通常は最初に一致したルールで接続先が決まります。末尾のMATCHは、他のルールに一致しない通信の受け皿として使われることがよくあります。
  • グローバルモード（global）：グローバルポリシーで接続先を選びます。グローバルグループで実際に何が選択されているかも確認してください。モードを切り替えただけでは、通信がリモートノードを経由している証明にはなりません。
  • ダイレクトモード（direct）：コアがリモートプロキシサーバーを経由せず、接続先に直接接続します。

あるWebサイトがグローバルモードでは使えるのにルールモードでは失敗する場合は、接続ログでドメイン名、適用されたルール、ポリシーの経路を確認します。たとえば、そのドメインにDIRECTが適用され、現在のネットワークから直接接続できない場合は、該当する振り分けルールを見直す必要があります。1つのサイトを直すために、すべての通信をグローバルモードにしたままにしないでください。

カスタムルールは、更新後も設定が保持される方法で管理しましょう。ダウンロードしたサブスクリプション設定を直接編集すると、次回の更新時に上書きされることがあります。クライアントが対応しているオーバーライドまたはマージ機能を使い、更新後に実際に適用されている設定を確認してください。各項目の詳細は設定リファレンスをご覧ください。

6. ノードの遅延は小さいのに、Webサイトの表示が遅いのはなぜ？

遅延テストでわかるのは特定のテスト要求の結果であり、ダウンロード速度、継続的な転送速度、接続先サイトの利用可否とは別の指標です。たとえば一覧に45 msと表示されても、その回の測定でクライアントがその数値を得たことを示すだけです。大きなファイルが一定の速度でダウンロードできる保証にはなりません。この数値は判断方法を説明するための例であり、本サイトでの実測値ではありません。

条件をそろえて比較する

  1. 同じWebサイト、同じ接続方法、同じ時間帯で、2つのノードをそれぞれテストします。
  2. 各ノードを3回ずつ試し、接続の成否、ページの読み込み開始までの時間、途中で切断されたかを記録します。
  3. バックグラウンドのダウンロードとクラウドストレージの同期を一時停止します。他のWebサイトも比べて、特定サイトの問題か全体的な問題かを切り分けます。
  4. ノードを変えずにWi-Fiとスマートフォンのテザリングを比較し、接続元ネットワークの影響を確認します。

テストがタイムアウトしても、ノードが完全に使えないとは限りません。テスト用URLに到達できない場合や、テスト要求と実際のアクセス先で異なる経路を使う場合があります。反対に、速度テストに成功しても、接続先サイトの地域制限、アカウント制限、リモート側の出口制限がないとはいえません。実際の要求結果とクライアントの接続ログを併せて確認してください。

7. ポートが使用中と表示される。7890と9090は何に使う？

まずポートを使用しているプロセスを調べ、重複しているサービスを停止するか、ポートを変更するかを決めましょう。mixed-portはアプリがプロキシ接続に使うポートです。external-controllerは管理インターフェースのアドレスで、ブラウザー用のプロキシポートとしては使えません。以下は項目の意味を説明するためのもので、そのまま読み込める完全なサブスクリプション設定ではありません。

mixed-port: 7890
external-controller: 127.0.0.1:9090
allow-lan: false
mode: rule

Windowsのログにaddress already in useと表示された場合は、ターミナルで次のコマンドを実行できます。1つ目で待ち受け中のプロセスを探し、2つ目で1つ目の出力の最後の列にあるPIDからプロセス名を確認します。

netstat -ano | findstr ":7890"
tasklist /FI "PID eq 1234"

1234は説明用のPIDです。実行時は実際に見つかった番号に置き換えてください。macOSではlsof -nP -iTCP:7890 -sTCP:LISTENで待ち受けているプロセスを確認できます。正体のわからないシステムプロセスを強制終了しないでください。

別のプロキシクライアントがポートを使用している場合は、重複して起動しているインスタンスを終了してください。プロキシポートを7891に変更する場合は、システムプロキシ、ブラウザー独自の設定、ターミナルのプロキシ環境変数も同じ値に変更します。管理インターフェースはローカルに限定し、認証を設定してください。問題の切り分けを目的に、LANやインターネットへ直接公開しないでください。

8. Webサイトに接続できないとき、どの順番で調べる？

「元のネットワーク→コア→接続経路→ルール→DNS」の順に確認し、1回に変更する項目は1つにします。まず、接続できないサイト、ブラウザーのエラー、クライアントログの時刻を記録しましょう。以下のテストを順に行えば、設定をすべて変えて原因がわからなくなるのを防げます。

  1. 元のネットワークを確認：クライアントのシステムプロキシとTUNをオフにし、通常のネットワークから直接アクセスできるサイトを試します。それでも失敗する場合は、Wi-Fiのログイン、ブロードバンド接続、OSのネットワーク問題を先に解決してください。
  2. コアを確認：現在の設定が選択されていること、ログに設定の解析エラーがないこと、プロキシポートが待ち受けていることを確認します。
  3. 接続経路を確認：システムプロキシだけを有効にしてブラウザーから対象サイトにアクセスし、クライアントに新しい接続ログが記録されるか確認します。
  4. 接続先を確認：ルールで最終的にどのノードが選ばれたか確認し、別のノードに切り替えてテストを繰り返します。必要なら一時的にグローバルモードと比較し、テスト後はルールモードに戻してください。
  5. DNSを確認：ログに名前解決のタイムアウトがある場合や、TUNのオン・オフで結果が変わる場合は、DNS設定、リゾルバーへの到達性、DNS通信の取り込み方法を確認します。

プロキシを明示したリクエストで原因を絞り込む

ローカルのHTTPポートまたは混合ポートが7890の場合、Windowsでは次のコマンドを実行できます。macOSとLinuxではcurl.exeをcurlに置き換えてください。例のURLは、実際に接続できないサイトに置き換えられます。

curl.exe -I --max-time 15 --proxy http://127.0.0.1:7890 https://example.com/

プロキシを明示したリクエストが成功してブラウザーでは失敗する場合は、ブラウザー拡張機能、独自プロキシ設定、キャッシュの状態を優先して確認してください。ローカルポートに接続できないとすぐに表示される場合は、待ち受け状態とポート番号を確認します。403などのHTTP応答が返っているなら、サーバーから応答を受け取れています。ローカルポートの障害と即断しないでください。証明書エラーが出た場合は、システム時刻と証明書環境を確認し、証明書検証を無効にして問題を隠さないでください。

9. サブスクリプション・クライアント・コアの更新は同じ？

3種類の更新は対象が異なり、互いの代わりにはなりません。サブスクリプションを更新しても、通常は設定やリソースを再取得するだけです。古いコアが新しいプロトコルに対応するわけではありません。また、クライアントを新しいバージョンにしても、提供元のサーバーアドレスが更新されるとは限りません。

更新対象主な変更内容更新後の確認項目
サブスクリプション設定ノード、ポリシーグループ、ルールなどの設定内容選択中の設定、グループ内の選択、オーバーライドが保持されているか
クライアント管理画面、サービス連携、アプリ機能システムプロキシ、権限、既存の設定が正常に使えるか
コアプロトコルの実装、設定の解析、ネットワーク処理の機能起動ログ、項目の互換性、実際の接続

サブスクリプションの更新に失敗したら、DNSエラー、接続タイムアウト、HTTPステータスエラーのどれかを確認しましょう。401や403はアクセス権限またはサーバー側のポリシー、404はURLの無効化が関係している可能性があります。具体的な原因は提供元の案内も確認してください。サブスクリプションURLへのアクセスにプロキシが必要な場合は、クライアントに「プロキシ経由で更新」などの設定があるか確認できます。ただし、利用可能なプロキシがない状態でむやみに頼らないでください。

更新前に現在のバージョンと重要な設定を記録し、更新後は以前に動作確認済みの設定で試します。解決しない場合はサブスクリプション更新のトラブル対処をご覧ください。ログを共有する前に、アクセストークン、認証情報、個人用のパスを削除してください。

10. クライアント終了後にネットにつながらないときの復旧と初期設定

まず接続できなくなったプロキシ設定を解除してから、プログラムを終了してください。システムがまだ127.0.0.1:7890へ通信を送っていて、そのコアが停止している場合、ブラウザーにプロキシサーバーが接続を拒否したと表示されることがあります。多くの場合、接続設定が残っているだけです。OSの再インストールやネットワーク設定の全リセットが必要とは限りません。

復旧の手順

  1. クライアントを再起動できる場合は、まずシステムプロキシとTUNをオフにし、クライアントのメニューから通常の手順で終了します。
  2. Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、ローカルポートを指す手動プロキシが残っていないか確認します。自分で設定した項目だけを解除してください。
  3. macOSでは「システム設定」→「ネットワーク」→現在のネットワーク接続→「詳細」→「プロキシ」を開き、HTTP、HTTPS、SOCKSの設定を確認します。
  4. Androidでは、システムのVPN接続に加え、常時接続VPNや「VPNを使用しない接続をブロック」などの設定を確認します。接続を終了してから通常のネットワークをテストしてください。
  5. ターミナルだけで接続に失敗する場合は、そのターミナルセッションのHTTP_PROXY、HTTPS_PROXY、ALL_PROXYなどの環境変数が古いポートを指していないか確認します。

組織管理の端末では、組織が配布したプロキシ、証明書、VPN設定を勝手に削除せず、まず管理ポリシーを確認してください。最初からOSのネットワーク設定をリセットすることもおすすめしません。他のネットワークソフトにも影響し、復旧の手間が増える可能性があります。

初期設定が完了した状態

  • サブスクリプションが読み込まれて有効になり、コアに設定の解析エラーがない。
  • システムプロキシ経由で接続ログが記録され、対象サイトから正常な内容が返る。
  • ルールモードで、適用されたルールと接続先を説明できる。
  • TUNが必要な場合は個別に有効にし、スイッチの色を見るだけでなく対象アプリで動作を確認する。
  • プロキシをオフにしてクライアントを終了した後も、通常は直接アクセスできるサイトに接続できる。

この5項目を確認してから、自動更新、アプリごとの振り分け、OS起動時の自動起動を少しずつ設定しましょう。すべての機能を一度に有効にするより、動作確認済みの設定を記録しておくほうが、後で問題を切り分けやすくなります。