目次
クライアントを開いたら、最初に Profiles へ進む
Clash Verge Rev のホーム画面にあるスイッチは、設定を作成してくれるものではありません。Profiles を開いてください。ここで Mihomo が読み込む YAML を決めます。リモートサブスクリプション、ローカル設定、上書きは共存できますが、初回利用では配布元が明確なリモート Profile を一つだけ残すと、その後のノードとルールの出所も明確になります。
サービス提供元の Clash または Mihomo 互換 HTTPS リンクを貼り付け、自分で配布元を識別できる名前を付けます。サブスクリプションには token が含まれるため、完全なアドレスをスクリーンショット、Profile 名、公開チケットへ載せないでください。
リモート Profile を追加する
完全なサブスクリプション URL をコピーする
疑問符以降のパラメータを省略せず、余分な空白もコピーしないでください。
Profiles でリモート設定を追加する
通常のリンクインポート項目を使い、保存後も現在の画面に留まります。
手動で更新する
ステータス表示と新しい更新日時を待ちます。
現在の設定として選択する
直前に更新した項目へ選択マークが付いている必要があります。
サブスクリプション名が表示されるだけでは成功ではない。更新日時が変わる必要がある
リモートアドレスを保存しても、クライアントはローカルに項目を作っただけの場合があります。更新をクリックすると、成功時に設定がダウンロード、解析され、時刻も変わります。download failed、client error(Connect)、401、403、parse error は、それぞれダウンロード、接続、認証、解析の失敗に対応します。
401 / 403
サブスクリプションサービスへサインインし、アカウントと token を確認してください。クライアントはすでにサーバーへ到達しています。
client error(Connect) / timeout
別のネットワーク、またはクライアントのドキュメントに記載された別のインポート方法と比較してください。
parse / yaml error
返された内容は届いていますが、形式またはフィールドが現在のコアと互換性を持ちません。
200 が返ってもノードがない
応答がサインイン用 HTML ではないことと、設定にプロキシとポリシーグループが含まれていることを確認してください。
古い設定で通信できても、今回の更新が成功したとは限りません。Clash Verge Rev は以前のローカルコピーを使い続けるため、更新の調査では時刻とエラーを確認してください。唯一動作する設定を先に削除しないでください。
Proxies では、ポリシーグループから特定のノードまで選択する
更新後に Proxies を開きます。上位には通常、「ノード選択」「自動選択」「フェイルオーバー」などのポリシーグループがあり、展開すると特定のノードが表示されます。グループ名はサブスクリプション側で決まるため、サービスごとに異なります。
最初のテストでは、メインの select グループで特定のノードを選びます。url-test または fallback は、ネットワークが動作してから使用してください。自動グループは確認中に送信経路を変える場合があります。ノード横の遅延値から分かるのは、テスト URL が応答したことだけです。実際のWebページは別に確認します。
プロキシ画面で明確に確認すべき内容
- メインのポリシーグループが空ではない
- 手動選択グループが特定ノードを参照している
- 利用するサービスグループが最終的にそのノードまたは上位グループを参照している
- 現在のモードが Rule であり、誤って Direct のままになっていない
System Proxy を有効にすると、システムにローカルプロキシアドレスが表示される
ホーム画面または設定領域へ戻り、System Proxy を有効にします。Clash Verge Rev が Windows または macOS のシステム設定へローカルプロキシアドレスを書き込み、ブラウザとシステムプロキシに従うプログラムがリクエストを Mihomo へ送るようになります。
古い Clash、VPN、またはプロキシ拡張がコンピュータに残っている場合は、先にすべて終了してください。二つのクライアントがシステムプロキシを変更できると、画面では有効でも、別のプログラムが古いポートをシステムへ書き戻す場合があります。ポートは、現在の Clash Verge Rev に設定されている mixed-port または HTTP ポートを使用します。

ブラウザでページを開いたら、そのリクエストを Connections で探す
システムプロキシが実際にトラフィックを取り込んでいるか確認する
使い慣れたサイトを開く
直前に固定したノードと Rule モードを使います。
Connections 画面へ進む
時刻またはドメインから、直前に作成された記録を探します。
Rule を確認する
接続が DIRECT、REJECT、ポリシーグループのどれに一致したか確認します。
Chains / 送信経路を確認する
最終的に使用したノードが Proxies の選択内容と一致することを確認します。
ページが開き、記録も一致すれば、システムプロキシは動作しています。ページが失敗して Connections が空なら、システムプロキシの書き込みを確認してください。記録が DIRECT ならルールを読み、固定ノードを使用した後に timeout になるなら別ノードと比較します。この三つの結果には、それぞれ異なる修正方法があります。
システムプロキシを有効にして通信できなくなった場合は、そのリクエストがどこで止まるかだけを確認する
Profiles に新しい更新日時がない
サブスクリプションリンク、アカウント状態、ダウンロードエラーへ戻ってください。システムプロキシが使える設定はまだありません。
Proxies にポリシーグループまたはノードがない
Profile が選択され、応答が Clash / Mihomo 形式であることを確認してください。
ブラウザが失敗し、Connections が空
System Proxy が現在の mixed-port を参照していることを確認し、古いプロキシクライアントを終了してください。
接続に DIRECT と表示される
Rule モードがサブスクリプションのルールに従って直接接続を選んでいます。対象サイトにとって想定どおりか確認してください。
接続が固定ノードを使った後に timeout になる
動作確認済みの別ノードへ切り替え、同じWebページで比較してください。
修正後、直前のWebリクエストを繰り返します。ページが開き、Connections に想定ルールと選択したノードが表示されれば、サブスクリプションのインポート、ノード切り替え、システムプロキシが一つの流れとして完成しています。この単純な設定をしばらく使えば十分で、すぐに TUN や上書きを追加する必要はありません。
