1. Clashクライアント、コア、サブスクリプションの違いは？
クライアントは操作画面、コアは通信処理、サブスクリプションは設定を提供します。この3つが連携して動作します。クライアントをインストールしただけでは、利用可能なプロキシノードは手に入りません。
- クライアント：設定のインポート、ノード選択、ログ確認、システムプロキシの切り替えなどを行います。メニュー名やデフォルトのポートはクライアントによって異なります。
- コア：設定を読み込み、ルールを照合して接続を確立します。Clash Metaの後継はmihomoという名称で使われています。初期のClashコアとは、設定項目や対応プロトコルの範囲が完全には一致しません。
- サブスクリプション：通常はアクセス用の認証情報を含むURLで、ノードやグループ、ルールなどを取得できます。ノード一覧のみを提供する場合もあります。
「設定を読み込めない」ときは、まずクライアント名、コア名とバージョンを控え、サブスクリプションの要件を確認しましょう。インストーラーの名前だけでは、設定内のすべての項目に対応しているか判断できません。クライアント選びにはクライアント比較を参考にし、OSとアーキテクチャに合ったものをインストールしてください。
2. サブスクリプションURLはどこで入手する？なぜ安易に共有してはいけない？
サブスクリプションURLは、プロキシサービスの事業者、またはノードや設定を自分で管理する管理者から提供されます。このサイトのダウンロードセンターではクライアントを案内していますが、インストールしてもサブスクリプションが自動で発行されるわけではありません。
URLを入手した後の確認手順
- サービス事業者のアカウントページで、契約が有効で通信量の残量があることを確認し、現在のコアに対応したサブスクリプション形式を選びます。
- URLを最後までコピーしてください。疑問符以降のパラメーターを落とさないようにし、ページ上の説明文を一緒にコピーしないでください。
- クライアントの設定またはサブスクリプション管理画面でリモート設定を追加します。更新が成功したら、使用する設定として選択してください。
更新に失敗しても、すべてのノードが使えなくなったとは限りません。サブスクリプションサーバーに接続できない、トークンの有効期限が切れている、ログインページが返されたなどの可能性があります。サブスクリプションに関するFAQを参考に順番に確認し、同じURLを何度も追加しないでください。
3. インポートは成功したのにノードが表示されないのはなぜ？
まず設定が有効になっているか確認し、完全な設定ファイルかノードプロバイダーかを見分けましょう。「ダウンロード成功」は内容を取得できたことを示すだけです。コアへの読み込みや、選択可能なノードが現在のグループに含まれていることまでは保証しません。
- 別の設定が選択されている：設定一覧に複数のファイルが保存され、インポート後も元の空設定を使っている可能性があります。現在有効な設定とコアのログを確認してください。
- 形式が合っていない：プロトコルのURLだけが並んだテキストは、完全なClash YAML設定としてそのまま使えるとは限りません。
- プロバイダーが未更新：設定で
proxy-providersを使っている場合、メイン設定の読み込み後にリモートのノード一覧を別途取得する必要があります。 - ノードがグループに含まれていない：ノード定義があっても、現在のグループから参照されていなければ、一覧に期待した内容が表示されません。
調査中は元のサブスクリプションを残し、エラーにYAMLの解析失敗、不明な項目、リモート取得失敗などが含まれているか確認してください。設定を「保存できる」状態にするために、項目のまとまりをむやみに削除しないでください。項目の階層やインデントはYAMLガイドを参照してください。
4. ルール・グローバル・DIRECTはどれを選べばいい？
普段はルールモード、短時間の比較テストにはグローバルモード、コアに届いた通信を直接接続するにはDIRECTを使います。モードはコアが通信をどう処理するかを決めるもので、アプリの通信がコアに渡されているかどうかは決めません。
| モード | 処理方法 | 初心者向けの確認ポイント |
|---|---|---|
| ルール（Rule） | ルールを上から順に照合し、該当するポリシーまたはポリシーグループに転送する | 対象の通信に適用されたルールを確認する |
| グローバル（Global） | コアに届いた通信をグローバルポリシーに転送する | グローバルグループでDIRECTではなく、利用可能なプロキシが選択されているか確認する |
| 直接接続（Direct） | コアに届いた通信を宛先へ直接接続する | システムプロキシが自動で無効になったり、クライアントが終了したりするわけではない |
ルールは通常、上から順に確認され、一致すると後続の照合は行われません。そのため、個別ドメインのルールはフォールバック用ルールより前に配置します。グローバルモードではアクセスできるのにルールモードではできない場合は、まずルールとポリシーグループを確認してください。サブスクリプションが無効だとすぐに判断する必要はありません。モードの詳細はプロキシモードの設定をご覧ください。
5. クライアントは接続済みなのに、ブラウザーでサイトを開けないのはなぜ？
「接続済み」は、コアの起動、VPNインターフェースの確立、またはノードの接続テスト成功を示しているだけの場合があります。いずれもブラウザーのリクエストが正常に通っている証拠にはなりません。「ローカルの入口 → ルールとポリシー → リモート接続」の順に切り分けましょう。
- サブスクリプションが有効で、ポリシーグループにノードが選択され、コアが繰り返し終了していないことを確認します。
- デスクトップでシステムプロキシを使っている場合、クライアントの待ち受けポートとシステムプロキシのポートが一致しているか確認します。実際のポートが
7897なのに、システム側が7890を指定していると、接続先が誤ります。 - ブラウザーのプロキシ拡張機能を確認してください。拡張機能がシステムプロキシを上書きしたり、使わなくなった別のポートを指定したままになっていたりする場合があります。
- クライアントの接続一覧を開き、新しいページを更新して、該当ドメイン、適用されたルール、送信先ポリシーが表示されるか確認してください。
接続一覧にリクエストがまったく表示されない場合は、まず通信の入口を確認します。リクエストがありタイムアウトする場合は、ノードと宛先ネットワークを調べてください。テスト時は古いタブの長時間接続を閉じるか、新しいセッションを使い、切り替え前の接続結果と混同しないようにしましょう。最初に行う確認はクイックスタートガイドに沿って進められます。
6. ブラウザーは使えるのに、ターミナルでシステムプロキシが使われないのはなぜ？
コマンドラインツールの中には、デスクトップのシステムプロキシではなく、独自の引数や環境変数を参照するものがあります。そのため、ブラウザーは使えるのにターミナルでは失敗することがあります。まず1回限りのコマンドでプロキシを明示し、問題の範囲を確認してから、環境変数を常時設定するか判断してください。
以下はテスト用コマンドであり、このサイトでの実測結果ではありません。クライアントのHTTPまたは混合ポートが7890である例です。実行前に、クライアントに表示されている実際のポートに置き換えてください。
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.comWindows PowerShellではcurl.exeを使ってcurlを明示的に呼び出すと、旧バージョン環境で同名のエイリアスによる引数の違いを避けられます。「接続が拒否されました」と表示されたら、まずローカルポートとコアの状態を確認してください。ローカルプロキシへの接続後にタイムアウトする場合は、リモートノードと宛先アドレスを確認します。
- HTTPプロキシ経由でHTTPSの宛先に接続する場合も、プロキシアドレスは
http://127.0.0.1:7890と記述できます。クライアントがCONNECTでトンネルを確立します。 - HTTPポートとSOCKSポートは異なる場合があります。プロトコルの接頭辞だけを書き換えて、相互に使えると判断しないでください。
- 環境変数を全体に設定すると、ほかのツールにも影響します。単発コマンドで動作を確認してから、使用するシェルやツールのドキュメントに沿って設定してください。プロキシを解除した後は、該当する環境変数も削除します。
プロキシの入口、プロトコル、ポートの関係は用語集で確認できます。
7. TUNモードは必ず有効にする必要がある？
必須ではありません。システムプロキシを認識するアプリなら、まずはシステムプロキシを使えます。TUNは仮想ネットワークインターフェースとルーティングで通信を取り込みます。システムプロキシを使わないアプリには便利ですが、権限、ルート、DNSの確認事項が増えます。
プラットフォームごとの通信取り込み方法を確認
- Windows・macOS：クライアントによってはサービスやネットワーク拡張機能のインストール、管理者権限の許可が必要です。スイッチをオンにしただけで、認証や許可が完了していなければ通信は取り込まれません。
- Android：一般的なクライアントはシステムのVPNインターフェースを使って通信を転送します。VPNの許可を確認してください。アプリごとの振り分けや除外リストも、対象範囲に影響します。
- 複数のネットワークツールを併用している：別のVPN、仮想ネットワークアダプター、セキュリティソフトがルートやDNSを変更している場合があります。一度に変更する項目は1つにして、結果を比較してください。
TUNを有効にしても、すべての通信がリモートノードを通るとは限りません。コアに届いた後も、モードとルールに応じてプロキシ、直接接続、拒否のいずれかが選ばれます。UDP、IPv6、対象となるネットワーク範囲も、設定とプラットフォームの実装によって異なります。ダウンロード速度を上げる機能としてTUNを有効にしないでください。設定前にDNS設定ガイドを確認しましょう。
8. ノードの遅延は低いのに、ダウンロードや動画の再生が遅いのはなぜ？
遅延テストでわかるのは、特定のテスト先への往復時間やリクエスト時間であり、継続的な通信速度ではありません。テスト方法、対象URL、タイムアウトの基準はクライアントによって異なるため、異なる環境の数値をそのまま比較できません。
たとえば、ノードの遅延が40 msでも、ダウンロード速度が1 MB/sということはあり得ます。前者は時間、後者は転送速度です。10進法で換算すると、1 MB/s ≈ 8 Mbpsです。実際の速度は回線の混雑、サーバー側の制限、パケットロス、端末の性能にも左右されます。ここでの数値は単位の説明用です。
- 同じネットワークと同じテスト用ファイルを使い、ほかの大容量通信を一時停止します。
- 2つのノードを選び、それぞれ約30秒間テストして、開始直後の最高値ではなく、速度が安定したときの値を記録します。
- 混雑する時間帯とそうでない時間帯にそれぞれ再テストし、時間帯との関連があるか確認します。
- サービス事業者の通信量倍率を確認します。2倍で課金される場合、通常は1 GBの利用でプランの残量が約2 GB差し引かれます。詳細はサービス事業者の規約を確認してください。
地域ラベルだけでは、接続先サイトから見える出口の所在地やコンテンツの利用可否は保証されません。実際の出口と対象サービスの規約を確認し、何度もノードを切り替えたうえで、ページを一度開いたときの速度だけで結論を出さないでください。日常の切り分けにはよくある質問の確認方法も役立ちます。
9. DNSやFake-IPのエラーが出たら、すぐ無効にすべき？
まず名前解決の失敗、ルーティングの誤り、ノードへの接続失敗を切り分けてから、DNSモードを変更するか判断しましょう。サイトを開けない原因が必ずDNSとは限りません。設定全体をすぐに入れ替えると、比較検証の手がかりを失います。
Fake-IPでは、アプリに対応付け用の合成IPを返し、コアが実際のドメインと関連付けて接続を処理します。設定によく見られる198.18.0.1/16は、この仕組みで使われるアドレス範囲の例です。このような名前解決結果が表示されても、ドメインが一般のインターネット上のサーバーに誤って解決されたとは限りません。具体的な動作はコアとDNSの設定に照らして判断してください。
- 名前解決エラーのログがある：上流DNSに接続できるか、名前解決のリクエストが循環依存していないか確認します。
- LAN内のデバイス名だけに問題がある：ローカルドメイン、検索ドメイン、Fake-IPのフィルター設定を確認してください。すべてのドメインを除外しないようにします。
- 特定のブラウザーだけ挙動が違う：セキュアDNSやDoHの設定を確認してください。別の名前解決経路を使っている可能性があります。
- 設定を変えても状況が変わらない：対象のアプリを再起動するか、DNSキャッシュを削除してください。古い結果が引き続き使われている可能性があります。
変更は一度に1項目だけ行い、変更前後のログを記録してください。モードの定義と設定の範囲はFake-IPの説明をご覧ください。
10. クライアント終了後にネットにつながらないときの復旧方法と、問い合わせに必要な情報は？
まずシステムプロキシの設定が残っていないか確認し、次にTUNのルートとDNSを確認します。システムが終了済みのローカル待ち受けポートへリクエストを送っていると、システムプロキシを使うアプリは接続できず、ほかのアプリは正常に使える場合があります。
復旧手順
- 元のクライアントを再度開き、システムプロキシをオフにします。TUNを有効にしていた場合は、TUNもオフにしてから通常の手順で終了してください。
- Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」で手動プロキシを確認します。macOSでは「システム設定」→「ネットワーク」→現在の接続→「詳細」→「プロキシ」を確認してください。組織管理の端末では、先に管理者の要件を確認しましょう。
- ターミナルだけに問題がある場合は、コマンドの引数とプロキシ関連の環境変数を確認してください。これらはシステムプロキシの切り替えと連動して解除されるとは限りません。
- 復旧しない場合は、ログを保存してからネットワークに再接続し、DNSとデフォルトルートを確認してください。仮想ネットワークアダプターをすべて削除したり、ネットワーク設定を一括リセットしたりしないでください。
初回設定後は、現在の設定 → プロキシモード → ポリシーグループの選択内容 → 通信の入口 → テスト先の順に状態を記録しておくと便利です。次に問題が起きたとき、変化した箇所だけを比較できます。インストールや権限の設定はクイックスタートガイドで確認できます。最初からクライアントを再インストールする必要はありません。