初回設定は、OSに合ったクライアントをインストールし、有効な設定を読み込み、接続できるノードを選び、ルールモードにしてからシステムプロキシを有効にする順で進めます。ブラウザーで目的のサイトにアクセスできることを確認してから、TUN、自動起動、ルールの上書きを設定しましょう。各段階で動作を確認できるため、問題が起きても直前の設定に戻しやすくなります。

1. ClashのサブスクリプションURLはどこで入手する？そのまま設定として読み込める？

サブスクリプションURLは、利用しているネットワークサービスの提供元や設定の管理者から入手します。通常はアカウントページのサブスクリプション欄からコピーできます。エクスポート形式がClashまたはmihomoで読み込める設定かどうか確認してください。ログインページや購入ページのURL、ほかのクライアント専用形式のノード一覧は使えません。

読み込む前に確認する3つのポイント

  • 内容の種類：設定一式には通常、proxies または proxy-providers に加えて、proxy-groups や rules などが含まれます。ノード情報だけのサブスクリプションは、メイン設定と組み合わせて使います。
  • URLの有効性：サブスクリプションは、アカウントの有効期限、アクセストークン、デバイス制限などの影響を受ける場合があります。コピー時に改行や空白、チャットアプリが付けた句読点が混ざらないようにしてください。
  • 形式の互換性：ブラウザーにログインページやエラーページが表示される場合、HTTPリクエストが成功していてもYAML設定として読み込むことはできません。

サブスクリプションURLにはアクセストークンが含まれることが多いため、パスワードと同様に扱ってください。URL全体を公開コメントに貼ったり、よく知らないオンライン変換サービスに送ったりしないでください。サポートを求める際は、トークン、アカウント情報、ノードのパスワードを隠し、エラーメッセージと必要な設定構造だけを共有しましょう。

2. サブスクリプションを読み込んでも反映されない・更新に失敗する場合は？

「ダウンロード済み」でも「有効」とは限りません。Clash Verge Revの一般的な画面では、「サブスクリプション」ページにリモート設定を追加したあと、その設定を選択する必要があります。次に「プロキシ」ページで、プロキシグループが表示されているか確認してください。ノードが古いままなら、読み込んだ設定が現在選択されているか確認しましょう。

  1. 手動更新を一度実行し、ダウンロード・解析・読み込みのどの段階でエラーが起きるか記録します。
  2. ダウンロードに失敗する場合は、サブスクリプションの期限、サブスクリプションのドメインへの接続可否、システムの日付と時刻を確認してください。
  3. 解析に失敗する場合は、取得した内容がYAMLかどうか確認し、ログに記録された行番号、インデントの誤り、未対応の項目を調べます。
  4. 読み込みに失敗する場合は、カーネルのログを確認してください。ノードのプロトコルが未対応の場合や、プロキシグループが存在しない名前を参照している場合、設定を利用できないことがあります。

直接接続ならサブスクリプションをダウンロードできるのに、プロキシ経由の更新に失敗する場合は、クライアントに該当する設定があれば直接接続で更新してください。反対に、サブスクリプションのドメインへ既存のプロキシ経由でしか接続できない場合は、まず更新に使える設定を確保しましょう。新しい設定を検証する前に、唯一使える古い設定を削除しないでください。

3. ルール・グローバル・ダイレクトの各モードはどう使い分ける？

普段はルールモードを選びましょう。ルールを上から順に照合し、該当した接続を指定のプロキシグループ、ダイレクト接続、拒否のいずれかに振り分けます。グローバルモードは短時間の切り分けに、ダイレクトモードはカーネルが受け取った通信を一時的に直接接続させる場合に適しています。

モード通信の処理方法用途
ルール（Rule）ルールを上から順に照合し、一致したルールのポリシーを適用日常利用、ドメインやIPアドレスによる振り分け
グローバル（Global）通常はGLOBALプロキシグループで選択した出口を一律に使用振り分けルールが原因で接続に失敗しているか確認
ダイレクト（Direct）カーネルから接続先へ直接接続ローカルネットワークと直接接続の可否を確認

グローバルモードにしても、デバイス全体の通信が自動的にプロキシされるわけではありません。システムプロキシやTUNを経由していない通信は、モードを切り替えてもカーネルに渡りません。また、グローバルプロキシグループでは実際に使えるノードを選ぶ必要があります。グループ内でダイレクトが選ばれていれば、グローバルモードに切り替えても直接接続される場合があります。

ルールモードでは失敗し、グローバルモードでは成功する場合は、「接続」一覧で対象ドメイン、適用されたルール、実際のポリシー経路を確認してください。DIRECT に誤って一致していないか、REJECT で拒否されていないか、対象のプロキシグループで出口を誤選択していないかを調べましょう。ノードを次々に切り替えるだけでは解決しません。

4. ノードはどう選ぶ？低遅延なら必ず速い？

遅延は、あるテストリクエストの往復時間を示すだけで、通信速度、安定性、目的のサイトへの接続結果までは分かりません。クライアントに表示される遅延は、テストURL、タイムアウト、測定方法にも左右されるため、異なるクライアントの数値をそのまま比べるのは避けましょう。

条件をそろえてノードを比較する

  1. 同じ接続先サイトを決め、同じネットワーク、クライアント、テストURLを使います。
  2. 同じプロキシグループからノードを2～3個選び、順番にサイトを開いて実際の用途も試します。
  3. ダウンロード速度を比べる場合は同じファイルを使い、毎回約30秒間測定して、瞬間的な最大速度だけでなく途中で途切れないかも確認します。
  4. 接続先サービスに地域の条件がある場合は、ノード名ではなくサービスが実際に判定する出口の地域を基準にします。

たとえば、テスト一覧で一方のノードが80ミリ秒、もう一方が160ミリ秒と表示されても、その測定時の遅延に差があったことしか分かりません。前者のダウンロード速度が必ず速いとは限りません。数値は比較方法を示す例であり、本サイトがノードを実測した結果ではありません。初心者はまず手動選択のグループで出口を固定し、問題を切り分けてから設定に含まれる自動選択やフェイルオーバーのグループを使うとよいでしょう。

5. ノードがタイムアウトする・接続できないとき、最初に確認すること

まず「すべてのノードで失敗する」のか「特定のノードだけ失敗する」のかを切り分けます。前者ではローカルネットワーク、設定、カーネルの動作状態を優先して確認し、後者ではノードの状態、アカウント権限、プロトコル設定を確認します。遅延テストが一度失敗しただけで、すべての通信ができないとは限りません。

  • すべてのノードで失敗する：クライアントのカーネルが起動していること、サブスクリプションの期限が切れていないこと、ノードサーバーのドメインを名前解決できること、システム時刻に大きなずれがないことを確認します。
  • 特定のノードだけ失敗する：サブスクリプションを更新してから再試行し、サービス提供元がアドレス、ポート、認証情報を変更していないか確認します。
  • Webページは開くが、特定のアプリだけ使えない：アプリがシステムプロキシに従うか、UDPが必要か、ドメインに想定どおりのルールが適用されているかを確認します。
  • Wi-Fiとスマートフォンのテザリングで結果が異なる：違いを記録し、現在のネットワークで接続先ポート、プロトコル、UDPが制限されていないか確認します。

ログに表示されるエラーの見方

connection refused は通常、接続先のポートで接続が拒否されたことを示します。timeout は指定時間内に該当の処理が完了しなかったこと、no such host は多くの場合、ドメインの名前解決に問題があることを示します。TLSや認証のエラーでは、システム時刻、プロトコル設定、アカウント情報を確認してください。「ネットにつながらない」という表示より、エラーが発生した段階のほうが原因の特定に役立ちます。

切り分けのためにファイアウォールを恒久的に無効にしたり、証明書の検証を省略したりしないでください。ファイアウォールの許可が必要な場合は、プログラムのパスとネットワーク範囲を確認し、必要な権限だけを許可します。ログを共有する前に、サブスクリプショントークン、認証情報、機密性の高いアクセス履歴を隠してください。

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

システムプロキシは、OSのプロキシ設定に従うアプリにローカルのプロキシポートを使わせる仕組みです。TUNは仮想ネットワークインターフェースから通信を取り込み、ルーティングやDNSの設定と組み合わせて処理します。ブラウザーが問題なく使えるなら、「機能が多いから」という理由だけでTUNを有効にする必要はありません。

項目システムプロキシTUNモード
通信の取り込み方法アプリがプロキシ設定に従う必要がある仮想インターフェースとルーティングを使って通信を取り込む
主な用途ブラウザーやシステムプロキシに対応したアプリシステムプロキシに従わないアプリや、一部のUDP通信
必要な権限通常はユーザーのプロキシ設定を変更通常は管理者権限またはサービスモードが必要
主な確認ポイントプロキシのオン・オフ、待ち受けアドレスとポート仮想インターフェース、ルーティング、DNS、ソフトウェア間の競合

クライアントによっては両方を同時に有効にできますが、初期設定では通信の入口を1つだけ有効にしてください。Clash Verge Revの一般的な画面では、「設定」から「システムプロキシ」と「仮想NICモード」を探します。必要なサービスのインストール項目はバージョンによって異なります。TUNを有効にしてインターネットに接続できなくなったら、まずTUNを無効にし、システムプロキシで接続できるか確認してからカーネルログを調べましょう。

TUNを有効にしても、すべてのアプリやプロトコルをプロキシできるとは限りません。ノードがUDPに対応しているか、ルールがどう設定されているか、アプリが特定のインターフェースにバインドされているかなどが影響します。ほかのVPNと同時に使うと、ルーティングが競合する場合もあります。

7. ローカルプロキシのポートを確認する方法と、ターミナルがプロキシを経由しない原因

クライアントの設定または最終的に反映された設定で、待ち受けアドレスとポートを確認してください。Web上のポート番号をそのまま使わないようにしましょう。よくある例は 127.0.0.1:7890 ですが、実際のポートは異なる場合があります。mixed-port は同じポートでHTTPとSOCKSのプロキシ接続を受け付ける設定であり、ノードサーバーのリモートポートではありません。

# ローカル待ち受けの例。統合する前に、クライアント側に同じ設定がないか確認してください
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

ターミナルのツールは、デスクトップのシステムプロキシ設定を読み取らないことがあります。HTTPプロキシのポートが実際に7890の場合は、PowerShellで次のコマンドを使い、明示的にプロキシ経由でテストできます。このコマンドは今回のリクエストにだけ適用され、システム全体の設定は変更しません。

curl.exe --proxy http://127.0.0.1:7890 --head https://example.com/

例のURLは、リクエストがローカルプロキシ経由で処理されるか確認するためのもので、目的のサービスが利用できることを示すものではありません。127.0.0.1 に接続できない場合は、カーネルが起動しているか、ポート番号が正しいか、ほかのプロセスが使用していないかを確認します。ローカルポートに接続できてもリモートへのリクエストに失敗する場合は、ノードとルールを確認してください。自分のデバイスだけで使う場合は、LANからのアクセスを無効にしておきましょう。プロキシを共有する必要がある場合は、待ち受け範囲、認証、ファイアウォールを個別に設定します。

8. DNS・ルール・サブスクリプションの関係は？Webページが開かないときはDNSを変更すべき？

サブスクリプションは設定の取得元、ルールは接続に適用するポリシー、DNSはドメイン名の解決を担います。互いに影響しますが、同じ設定ではありません。Webページが開かない場合は、まず接続履歴で対象の通信がカーネルに届いているかを確認し、次に名前解決の失敗、ポリシーの誤り、ノードの接続不良のどれかを切り分けましょう。

変更する前に元に戻せる設定を残す

  • 接続一覧に対象が表示されない：システムプロキシまたはTUNで通信を取り込めているか確認します。
  • ドメインの名前解決エラーが表示される：有効なDNS設定と、DNSサーバーへの接続可否を確認します。
  • ダイレクト接続のルールに一致しているが、接続先にはプロキシが必要：該当するルールまたはプロキシグループを調整します。
  • ルールとポリシーに問題がない：別のノードやネットワークでも結果を比較します。

mihomoの fake-ip モードでは通常、設定された仮想アドレスプールからアプリにアドレスを返し、カーネルが元のドメイン名に戻して接続を転送します。このアドレスはノードの出口アドレスではないため、通常のパブリックDNSの結果と同じように異常と判断しないでください。名前解決モードを切り替えたあとも、アプリやシステムに以前の結果がキャッシュされている場合があります。影響を受けているアプリを再起動してから確認しましょう。

DNSの変更、TUNの有効化、ノードの切り替え、ルールの変更を一度に行わないでください。変更は一度に1項目に絞り、元の値も記録しておきましょう。社内ドメイン、プリンター、LAN内のサービスでは、内部DNSが必要か、そのドメインをダイレクト接続にすべきかも確認してください。

9. Clashを自動起動する方法と、終了後にネットにつながらなくなる原因

「OS起動時に起動」「起動後にシステムプロキシを有効化」「起動後にTUNを有効化」は、それぞれ別の設定です。「OS起動時に起動」だけを有効にしても、ネットワーク通信が自動的にプロキシされるとは限りません。前回のプロキシ状態を復元しても、利用可能なノードがあるとは限りません。

  1. クライアントの「設定」で「自動起動」または「ログイン時に起動」を探し、有効にして保存します。
  2. Windowsでは「設定」→「アプリ」→「スタートアップ」で登録項目を確認できます。macOSでは「システム設定」→「一般」→「ログイン項目と機能拡張」で許可した項目を確認できます。名称はOSのバージョンによって異なる場合があります。
  3. TUNを使う場合は、クライアントの説明に従ってサービスをインストールするか、必要な権限を設定してください。ログイン時に表示される権限昇格の確認だけに頼らないようにしましょう。
  4. 再起動してログインしたら、クライアント、カーネル、現在の設定、プロキシの通信経路を確認し、目的のサイトに実際にアクセスしてみましょう。

ウィンドウを閉じても、システムトレイに最小化されるだけの場合があります。プログラムを終了するには、メニューから「終了」を選んでください。異常終了後もシステムプロキシがローカルポートを指したままだと、そのポートで待ち受けるプログラムがなくなり、ブラウザーに接続できないことがあります。Windowsでは「設定」→「ネットワークとインターネット」→「プロキシ」、macOSでは現在のネットワーク接続の「詳細」→「プロキシ」を確認してください。

10. クライアントとmihomoカーネルの更新方法、古い設定を引き続き使えるか

まず更新対象がグラフィカルクライアントなのかカーネルなのかを確認してください。クライアントとカーネルのバージョンは別々に管理されており、画面のプログラムを更新してもカーネルが同時に更新されるとは限りません。クライアントの「バージョン情報」、カーネル情報、起動ログで現在のバージョンを記録し、そのクライアントが対応する方法で更新しましょう。

更新前後に動作を確認する

  1. サブスクリプションURL、ローカル設定、上書き用ファイル、必要な設定をバックアップします。バックアップファイルも安全に保管してください。
  2. クライアントが対応する更新機能、または該当プロジェクトの配布元から更新を入手し、OSとCPUアーキテクチャが合っていることを確認します。
  3. まずはクライアントに用意されたカーネル更新機能を使いましょう。入手元が不明な実行ファイルを、プログラムのフォルダーに直接上書きしないでください。
  4. 更新後は設定を読み込めるか確認し、ダイレクト接続先とプロキシ接続先をそれぞれ1つずつテストします。以前使っていたTUNやUDPの利用場面も確認してください。
  5. 互換性の問題が発生した場合は、エラーログを保存して以前の安定した組み合わせに戻し、設定の差分を1項目ずつ確認します。

Clash Metaとmihomoにはプロジェクトの継続性がありますが、Clashを冠するすべてのクライアントが同じプロトコルや設定項目に対応しているわけではありません。旧版のオリジナルカーネルでは、新しいノードのプロトコルや設定項目を認識できない場合があります。mihomoの拡張項目がほかのカーネルでも使えるとは限りません。クライアントで複数のカーネルを選べる場合は、実際に有効なカーネルの対応状況を確認してください。

この10項目を確認したら、検証済みの基本設定を残しておきましょう。有効なサブスクリプション、明確なプロキシグループ、接続できるノード、確認済みのローカルポート、単一の通信経路をそろえます。あとからTUN、自動選択、カスタムルールを追加するときは、一つずつ変更して検証すると、不明な設定をまとめて読み込むより管理しやすくなります。