Clash Verge Rev
スイッチを変える前に、失敗した段階を特定しましょう。ページを開けない原因は、名前解決、接続、TLS 検証、アプリケーション応答のいずれにもあり得ます。その通信が実際に Clash Verge Rev を通ったかも確認が必要です。ブラウザーで成功しても、別のアプリが同じリゾルバーや経路を使っている証拠にはなりません。
対象は Windows、macOS、Linux のデスクトップ版です。公開資料を基に組み立てた診断手順であり、すべての環境で実測したという意味ではありません。表示名はバージョンにより異なります。会社や学校の DNS、VPN、セキュリティ設定は、管理者に相談してください。
1. 変更前の状態を記録する
アクセスが許可され、問題を繰り返し確認できる宛先を一つ選びます。クライアントとコアのバージョン、OS、プロファイル名、System Proxy と TUN の状態、対象アプリ、発生時刻、エラー全文を記録してください。購読更新、ノード変更、DNS 変更を同時に行うと、直っても原因が分かりません。
同じ宛先で、ブラウザー、元のアプリ、クライアントの接続記録を比較します。許可された別ネットワークでも試せますが、ほかの条件は固定します。社内などの非公開ホスト名を、公開 DNS や診断サイトへ送信しないでください。
2. 四つの層でエラーを整理する
- 名前解決のタイムアウト：リゾルバー、到達性、hosts、キャッシュを調べます。一度の失敗だけで DNS 汚染とは断定できません。
- アドレス取得後の接続失敗：宛先サービス、経路、ノード、ファイアウォールを確認します。名前解決と接続成功は別です。
- TLS・証明書エラー：時刻、ホスト名、信頼チェーン、中間装置を確認します。証明書検証を無効にして隠さないでください。
- HTTP 403・404・429：何らかの HTTP 応答元には到達しています。ただし宛先、プロキシ、ゲートウェイのどれが返したかを確かめる必要があります。
これは調査用の分類で、すべてのエラーの唯一の説明ではありません。一つのサービスだけが失敗するなら、PC 全体を初期化する前に、その宛先に固有の証拠を残します。
3. 名前解決と通信経路を別々に確認する
接続記録やログから、通信がコアに入っているか確認します。すべてのアプリがシステムプロキシに従うとは限りません。TUN についても、経路と DNS の取り込みを別々に検証し、オン表示だけで完全な適用を判断しないでください。
nslookup example.com は、そのツールの問い合わせ結果を観察する方法です。ブラウザーのキャッシュやアプリ独自の名前解決全体を再現するものではありません。Firefox の DoH 設定も独立した確認項目です。コアの処理順序と取り込み範囲は、末尾の Mihomo 資料で確認できます。
4. Fake-IP の特殊なアドレスを誤判定しない
Fake-IP では、宛先の公開 IP ではなくマッピング用アドレスが返ることがあります。198.18.x.x などが出たら、稼働中の fake-ip-range と照合してください。見慣れないという理由で汚染と判断したり、システムの hosts に固定したりしないでください。
重要なのは、その後の接続もマッピングを担当するコアへ届くかです。アプリの別経路、古いキャッシュ、プロファイル変更後の接続再利用などは、解決成功と接続失敗が両立する仮説になります。アドレスだけで断定せず、ログで確かめます。
特定アプリだけの問題なら、まず設定を保存して互換性を調べます。必要性が確認できたドメインだけを例外にし、DNS 全体の置換や全ドメインの除外は避けてください。
5. DoH と IPv6 は比較して判断する
独自の DoH を使うブラウザーでは、コマンドラインと異なる結果になる可能性があります。通常のポート 53 の取り込みは、HTTPS 内の DNS を復号することとは異なります。セキュア DNS と管理ポリシーを記録し、許可された一時的な比較後は元に戻します。暗号化 DNS の恒久的な無効化を定番の対処にしないでください。
IPv6 では、AAAA 応答があることと利用可能な IPv6 経路があることを分けます。Mihomo の dns.ipv6 は AAAA 応答を制御し、OS 全体の IPv6 スイッチではありません。IPv4 と IPv6 の結果に実際の差が見られた場合に、経路、ノード対応、アプリの選択を調べます。
6. 明示的なプロキシ経由で一度比較する
次の例は、既存のローカル SOCKS または mixed リスナーが必要です。PORT を画面に表示された実際のポートに置き換え、許可されたトークンを含まない宛先を使います。例を動かすためだけに LAN 公開を有効にしないでください。
curl --proxy socks5h://127.0.0.1:PORT --noproxy "" --connect-timeout 10 --max-time 20 -I https://example.comWindows PowerShell では curl.exe で実行できます。socks5h は宛先名の解決を SOCKS プロキシへ委ねます。これは指定経路の比較であって、元のアプリの完全な再現ではありません。HEAD 非対応によるメソッドエラーだけで通信障害とは判断できません。
このテストだけ成功するなら、アプリの経路やキャッシュを優先確認します。両方失敗するなら、コアのログで宛先解決、ノード接続、ルール選択を分けます。断続的なら、スリープ復帰、ネットワーク変更、接続再利用との時刻の関係を記録します。
7. 必ず戻せる変更にする
- 設定をバックアップし、検証する仮説を一つ決めます。
- 関係する設定だけ変更し、対応する適用方法で反映してエラーを確認します。
- 対象アプリを再起動します。キャッシュの処理は各資料に従い、設定ディレクトリ全体を削除しません。
- 元の宛先、正常な比較対象、元のアプリ操作を再テストします。
- 効果がなければ戻します。改善した場合も、クライアント再起動や再接続後に確認します。
リゾルバー自身やノードのホスト名が解決できない場合は、起動に必要な名前解決の依存関係を調べます。ファイアウォールの無効化、TLS 検証の省略、コントローラーの公開で解決しようとしないでください。
8. ケース例と問い合わせ用チェックリスト
仮想例：ブラウザーは正常、デスクトップアプリはタイムアウトし、対応する接続がコアに見えません。System Proxy への対応と TUN の対象範囲を確認するのが次の一手です。明示的プロキシの成功は経路の仮説を強めますが、アプリに別の問題がない証明にはなりません。
問い合わせにはバージョン、OS、モード、伏字済みのエラー、再現時刻、変更前後の比較を添えます。購読 URL、クエリーのトークン、ノード認証情報、コントローラーの秘密情報を除いてください。元の操作と比較対象が再接続後も正常であることが完了条件です。一度の遅延測定だけでは不十分です。
関連記事
- TUN モードの使用法とトラブルシューティング ガイド
- ルールの迂回: 異なるトラフィックを独自の方向に通過させる
- ログと診断情報を安全に共有する方法
- 安全な更新・バックアップ・ロールバック
- ダウンロードとビルド選択
参考資料
参考資料の確認日：2026-10-14。以下はプロジェクトとプラットフォームの公式資料です。本稿は当サイト独自の編集ガイドです。