1. Clash Meta、mihomo、クライアントの関係は？

Clash MetaはClashをベースに発展したコアプロジェクトで、後にmihomoという名称が使われるようになりました。コアは設定の読み込み、プロキシプロトコルの処理、ルールによる振り分け、DNSの名前解決を担当します。デスクトップ画面、サブスクリプション管理、トレイメニュー、システムプロキシの切り替えなどは、通常GUIクライアントが提供します。クライアントをダウンロードしただけでは、接続可能なプロキシノードは手に入りません。

問題を調べるときは、クライアントのバージョン、コアのバージョン、OSのバージョンをそれぞれ記録してください。「Clashの最新版」だけでは設定の互換性を判断できません。同じクライアントでも、バージョンによって組み込まれているmihomoのバージョンが異なる場合があります。

  • GUIでの確認場所：まず「設定」→「このアプリについて」でクライアントのバージョンを確認し、続いてコア情報または起動ログを確認します。メニュー名はクライアントによって異なります。
  • コマンドラインでの確認方法：mihomoの実行ファイルがあるディレクトリで mihomo -v を実行します。Windows PowerShellでは .\mihomo.exe -v を使えます。
  • 互換性の確認：「不明なフィールド」や「未対応のプロキシタイプ」と表示されたら、サブスクリプションを何度も追加し直すのではなく、実際に起動しているコアを確認してください。

2. サブスクリプションはどこで入手する？インストール後にノードがないのはなぜ？

サブスクリプションは、サービス提供元や設定の管理者が用意する設定取得用の入口です。アクセス用トークンを含むHTTPS URLが一般的です。クライアントはこのURLからノードや設定一式を取得します。クライアント自体がサーバー、アカウント、通信量を自動で用意するわけではありません。

確認場所：利用中のサービスのアカウントページで「サブスクリプション」または「Clash / Clash Meta」形式のリンクを探し、クライアントの「サブスクリプション」または「プロファイル」画面に戻ります。mihomo対応が明記された形式を優先してください。他のプロトコルのリンクだけが含まれるテキストを、完全なYAML設定として読み込まないようにしましょう。

サブスクリプションの取得失敗と、ノードへの接続失敗は別の問題です。前者は設定のダウンロード時、後者は設定を読み込んだ後のプロキシ接続時に発生します。まずクライアントが設定を正常に取得できたか確認し、その後ノードの状態を調べてください。

3. サブスクリプションの追加方法と、更新しても反映されない理由

Clash Verge Revなどのデスクトップクライアントでは、「サブスクリプション」→「新規作成」→リモートサブスクリプションを選択→URLを入力→保存、という手順が一般的です。バージョンによっては、サブスクリプション画面にURL入力欄が直接表示されます。ボタン名よりも、ダウンロード、選択、適用の3つを完了することが重要です。

  1. サブスクリプションURLを省略せずにコピーし、前後に空白や改行が入っていないか確認します。
  2. リモートサブスクリプションを追加してダウンロードし、HTTPエラーやYAMLの解析エラーが出ていないことを確認します。
  3. 追加した設定を選択し、「プロキシ」画面でプロキシグループが表示されるか確認します。
  4. 手動で更新し、更新時刻とログを確認します。別の古い設定が有効になっていないかも確認してください。

ダウンロード結果が 401 または 403 の場合は、トークン、アカウントの状態、サービス側の制限を確認します。設定ではなくWebページが返る場合は、ログインページのURLをコピーした可能性があります。解析エラーに表示された行番号はダウンロードした設定内の位置であり、ローカルのオーバーライドファイルを指すとは限りません。

更新時の注意：サブスクリプションのキャッシュ内にあるノードやルールを直接編集すると、次回の更新で上書きされることがあります。継続的な変更は、クライアントのオーバーライド、設定のマージ、スクリプト機能などに反映し、最終的に生成された実行設定を確認してください。

4. ルール・グローバル・DIRECTモードの選び方

普段使いにはルールモードがおすすめです。設定の rules は上から順に照合され、一致したルールに応じて接続が指定のポリシーに渡されます。グローバルモードでは、コアに入った接続がグローバルポリシーに渡されます。DIRECTモードでは、コアに入った接続が宛先へ直接接続されます。いずれも「通信がすでにコアに入っている」ことが前提です。

モード用途確認場所
ルール ruleドメインやIPなどの条件で通信を振り分ける「プロキシ」画面のルール適用先グループ、接続の詳細
グローバル globalルールによる振り分けが原因か一時的に切り分けるグローバルポリシーで現在選択中のノード
DIRECT direct宛先に直接アクセスできるか確認する接続の詳細と宛先ネットワークへの到達性

設定場所：クライアントの「プロキシ」画面、またはトレイメニューからモードを選択します。グローバルモードに切り替えた後も、グローバルポリシーで利用可能なノードを選ぶ必要があります。DIRECTを選ぶと接続は直接通信になります。また、グローバルモードにしても、すべてのアプリが自動的にプロキシを経由するわけではありません。

5. 7890ポートとは？ノードのポートとの違い

7890は設定例でよく使われるローカルプロキシの待ち受けポートです。必須の値ではなく、リモートサーバーのポートでもありません。mixed-port: 7890と設定すると、同じローカルポートでHTTPプロキシとSOCKSプロキシの接続を受け付けます。実際のポートはクライアントの実行設定で確認してください。

ローカル待ち受け設定の例
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

確認場所：クライアント設定の「ポート」または「混合ポート」、あるいは現在の実行設定にある mixed-port を確認します。外部コントローラーのポートをプロキシポートと混同しないでください。external-controllerは管理用インターフェースであり、ブラウザーのHTTPプロキシアドレスには指定できません。

Windowsでは次のコマンドを実行し、このPCで7890を待ち受けているプロセスがあるか確認できます。結果が表示されても、待ち受けプロセスがあることを示すだけで、現在のクライアントとは限りません。PIDも確認してください。

Windows PowerShell
netstat -ano | findstr ":7890"

起動ログに address already in use と表示されたら、他のプロキシプロセスを終了するか、ローカルの待ち受けポートを変更します。そのポートを使うアプリの設定も合わせて変更してください。

6. システムプロキシを有効にしても、ターミナルやゲームがプロキシを経由しないのはなぜ？

システムプロキシはOSがアプリに提供するプロキシ設定であり、通信を強制的にすべて取り込む機能ではありません。設定を参照するかどうかはアプリによって異なります。ブラウザーは通常システムプロキシを利用できますが、コマンドラインツールは環境変数を参照する場合もあれば、独自のプロキシ引数が必要な場合もあります。UDP通信が中心のゲームは、通常のHTTPシステムプロキシだけでは対応できないことがあります。

確認場所：まずクライアントの「システムプロキシ」を有効にし、Windows 11の「設定」→「ネットワークとインターネット」→「プロキシ」でローカルプロキシのアドレスを確認します。次に、クライアントの「接続」画面で対象アプリからの接続を確認します。macOSでは「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」で確認できます。

ターミナルでは、まず一度だけプロキシを明示してテストし、すぐに環境変数全体を変更するのは避けましょう。以下のコマンドは混合ポートが実際に7890であることを前提としています。Windowsでは curl.exe を使うと、PowerShellのコマンドエイリアスによる違いを避けられます。

HTTPプロキシを明示的に指定
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

macOSまたはLinuxでは、コマンド内の curl.exe を curl に置き換えてください。プロキシを明示すれば成功するのに通常のアクセスでは失敗する場合は、コアを再インストールするのではなく、アプリがプロキシ設定を参照しているかを確認します。

7. TUNモードを有効にする場面

TUNは仮想ネットワークインターフェースとルーティング設定を使って通信を取り込みます。システムプロキシを参照しないプログラムや、より多くの通信を処理する必要がある場合に適しています。ノードを高速化するスイッチではなく、サブスクリプションの無効化、サーバー障害、誤った振り分けを自動で修復する機能でもありません。

設定場所：クライアントの「設定」にある「TUNモード」または「仮想NIC」から有効にします。Windowsクライアントでは、先にサービスモードのインストールや管理者権限が必要な場合があります。Androidでは通常、システムのVPN許可を通じて接続するため、デスクトップ版のメニュー操作をそのまま当てはめることはできません。

  1. まずTUNをオフにして、プロキシを明示した状態でノードが使えることを確認します。
  2. 現在のシステムプロキシ、DNS、他のVPNの状態を記録してからTUNを有効にします。
  3. 対象のアプリで通信をテストし、「接続」画面に該当する記録が表示されることを確認します。
  4. ローカルネットワークや社内VPNに問題が起きた場合は、まずTUNをオフにして比較し、ルートの競合やバイパス範囲を確認します。

8. DNSとfake-ipとは？手動で変更する必要はある？

DNSはドメイン名をIPアドレスに変換します。mihomoのDNSモジュールは、ドメインと接続の関連付けにも関わります。fake-ipモードでは、コアがアプリに仮想アドレスを返し、そのアドレスとドメインの対応を保持します。これらのアドレスは、接続先サーバーの実際のグローバルIPアドレスではありません。

一般的な設定では、fake-ipの範囲として 198.18.0.1/16 が使われます。この範囲のアドレスが表示されても、すぐにノードの汚染やサーバーアドレスの誤りと判断しないでください。まず enhanced-mode: fake-ip が有効か確認します。

確認場所：現在の実行設定の dns セクションと、クライアントのDNSオーバーライド設定を確認します。ブラウザー独自の暗号化DNS、システムDNS、コアのDNSは、同じ経路とは限りません。そのため、一度システムの名前解決結果を確認しただけでは、アプリが実際にどのリゾルバーを使ったかは分かりません。

  • 一部のドメインだけに問題がある場合は、まず接続ログでドメイン、適用されたルール、名前解決エラーを確認します。
  • 実際のIPアドレスを必要とするLANサービスでは、対象ドメインに応じて fake-ip-filter の設定を検討してください。除外範囲を一度に広げすぎないようにしましょう。
  • DNSを変更した後は、アプリの接続を確立し直してください。既存の接続やアプリのキャッシュに以前の結果が残っている場合があります。

9. カスタムルールの追加場所と、ルールが適用されない原因

ルールは通常、上から順に照合され、MATCHは最後のフォールバックとして使われます。以下はルール部分の例であり、単独で起動できる完全な設定ではありません。例のドメインはDIRECTにし、それ以外の接続は「プロキシ選択」というポリシーに渡します。このポリシーは proxy-groups で定義済みである必要があります。

ルール設定の例
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,プロキシ選択

設定場所：クライアントの設定オーバーライド機能でルールを追加し、マージ後の実行設定を確認して、新しいルールがフォールバックルールより前にあることを確かめます。編集後に設定を再読み込みし、「接続」画面でルールタイプ、ポリシーの経路、実際の出口を確認してください。

ルールが適用されない場合は、次の3点を順に確認します。ルールモードになっているか、アプリが実際に接続しているドメインが想定どおりか、通信がこのクライアントに入っているか。IPアドレスへの直接接続、アプリ独自の名前解決、既存の長時間接続などが確認結果に影響することがあります。

rule-providersを使う場合は、ルールセットのダウンロードが成功していることと、rulesに対応する RULE-SET の参照があることも確認してください。ルールセットの取得元を定義しただけでは、照合に使われるとは限りません。

10. ノードの遅延は正常なのにWebサイトが開かないときの確認手順

遅延テストで通常アクセスするのは、設定またはクライアントで指定されたテスト用アドレスだけです。特定のリクエストの結果は分かりますが、すべてのWebサイト、UDP通信、ログイン処理が正常とは限りません。「設定→入口→ルール→ノード→接続先」の順で切り分けましょう。

  1. 設定の読み込みを確認：「ログ」を確認し、YAMLの解析エラー、ポリシーグループの不足、ポート競合がないか調べます。コマンドラインでは mihomo -t -f config.yaml で設定を確認できます。チェックに通っても、リモートノードへの接続が保証されるわけではありません。
  2. 通信が取り込まれているか確認：プロキシを明示してリクエストし、「接続」画面を確認します。接続先の記録がない場合は、アプリのプロキシアドレス、実際の待ち受けポート、TUNによる取り込み状況を確認してください。
  3. ルールの接続先を確認：接続に適用されたルールと最終的なノードを確認します。一時的にグローバルモードへ切り替え、同じノードを明示的に選んで結果を比較してください。
  4. 接続先による違いを確認：同じノードで異なる2つのWebサイトをテストします。特定のサイトだけ失敗する場合は、接続先サービスの制限、DNS、出口からの到達性を確認します。
  5. 有効な情報を記録：クライアントとコアのバージョン、エラー発生時刻、モード、接続先ドメイン、個人情報を伏せたログを記録します。次の項目を変更するのは、1回のテストが終わってからにしてください。

操作手順を確認するには入門ガイドをご覧ください。エラーの症状から原因を探すにはトラブル対処をご利用ください。問い合わせの前に、サブスクリプションのトークン、ノードの認証情報、管理インターフェースのキーを削除してください。