Windows 11 で Clash Verge Rev のログパネルを使い、接続タイムアウトを切り分ける手順ガイド（2026）
Windows 11 で Clash Verge Rev は動いているが、特定サイトだけ 接続タイムアウト や真っ白の読み込みが続く──そんなときに、クライアント付属の ログ／ログパネルから DNS・TLS 握手・ノード（プロキシ） のどこで詰まっているかを見分ける手順です。インストール自体やシステムプロキシと TUN の初回選択は Windows 11 初回セットアップ記事 に任せ、本稿は 使い方としてのログ読みに絞ります。ビルドによりメニュー名は多少違いますが、出てくる語彙のパターンは共通です。
この記事が向いている検索意図
「Clash Verge Rev ログ 見方」「接続タイムアウト 原因」「Windows 11 で DNS なのかノードなのか知りたい」といった query は、だいたい (1) 全部は繋がるが一部ドメインだけ遅い／落ちる、(2) しばらくすると復活する、(3) ノードを変えると直るが理由が分からない、(4) ブラウザ拡張や別 VPN を疑いたい、のどれかです。本稿は「ゼロから入れる」ではなく、すでにプロキシ経路が動いている前提で、ログ一行の意味を仮説に変換することを目的にします。
ルールとグループの整理は proxy-groups とルールのガイド、語彙の揃え方は チュートリアル索引 が役立ちます。購読 URL まわりの典型症状は 購読 FAQ にまとめています。
初回セットアップ記事との棲み分け
Windows 11 での Clash Verge Rev 初回セットアップ は、インストール後の システムプロキシ と TUN のどちらを主に使うか、全体が繋がらないときの OS 側チェックまでを扱います。本稿はその一段先で、「経路は通っているが特定接続だけタイムアウトする」ときに ログパネル をどう覗くかに特化します。全体オフラインのときは先に初回記事のチェックリストを潰すほうが早いです。
準備：ログ画面を開き、情報量を足す
Verge 系ではサイドバーやメニューに ログ、Log、コンソール に近い項目があります。まずその画面を開き、(1) 自動スクロールがオンなら流れを止めずに全体を眺めやすい状態にする、(2) ログレベル が info だけなら debug に近い値へ上げる（ビルドにより名称が異なる）、(3) ドメインや rule 名で検索できるなら、その入力欄を空にしておく、の三要を済ませます。
レベルを上げすぎると行数が爆増するので、再現操作の直前にクリアしてから問題サイトを開く、というリズムを覚えると読みやすいです。個人情報がログに混ざるビルドもあるため、共有・貼り付けの前にホスト名やトークンをマスクする習慣も有用です。
手順 1：タイムアウトを再現し、同じ秒の行に寄せる
ブラウザで失敗する URL を開き、読み込みが止まったまたはエラー表示が出たタイミングでログを止めて巻き戻します。見るべきは そのドメイン または IP を含む行、そして直前後の [Rule] や proxy 名が付いた行です。ここで「どのルールにマッチしたか」「実際に使われた プロキシ／DIRECT はどれか」が一致しているかを確認します。ルールの見方の骨格は カスタムルール入門 とも繋がります。
手順 2：DNS っぽい詰まりの見分け
次のような兆候は DNS または名前解決ポリシーを疑います。ドメインに対するクエリが失敗・タイムアウトと出る、fake-ip まわりの警告が続く、期待した DNS サーバー名ではなく別の resolver が使われている、などです。Clash では dns セクションと enhanced-mode、ルールの DOMAIN 判定順序が絡むため、ログに出る「解決結果」とルールに渡るホスト名がズレていると、プロキシを変えても改善しないことがあります。
切り分けの実務は、一時的にブラウザの 安全 DNS をオフにし、別ブラウザで再現する、System 側の他 DNS ツールを止める、fake-ip か redir-host かをプロファイルの意図と照合する、の三段が古典的です。OS 全体の DNS 取りこぼしは Docker Desktop と Clash を併用する記事 の「DNS の取り違え」に近い発想も参考になります。
手順 3：TLS ／握手周りの見分け
TLS、handshake、certificate、SNI、x509 などの語が近くに出る場合は、プロキシ越しの HTTPS でサーバ証明書の検証や中間機器のインスペクションが邪魔している可能性があります。社内プロキシやセキュリティ製品の HTTPS スキャンとぶつかる典型パターンです。逆に、行が進んでから初めて i/o timeout となるなら、帯域・RTT・ノード側の落ちやすさを疑ったほうがよいことが多いです。
手順 4：ノード（upstream）側のタイムアウト
dial や proxy 名の直後に timeout、connection reset、特定のリモート ip:port への失敗が続く場合は、選択中のサーバー またはその上流の混雑・メンテを疑います。別ノードへ切り替えてログの失敗行が途切れるかを一発試し、改善するならルールより出口品質の問題寄りです。購読期限やノード枯れは 購読 FAQ の領域とも重なります。
接続一覧やトラフィック表示がある場合
ビルドによっては Connections や Traffic に近い一覧があり、生きているセッションのプロセス名・宛先・プロキシチェーンが表形式で見えます。ログだけでは「どのアプリがプロキシを無視しているか」が分かりにくいとき、ここに行が出ないアプリは プロキシ非対応 か TUN 未使用 を疑います。Windows でアプリ単位の取りこぼしを掘る場合は PROCESS-NAME ルールの記事 も参照できます。
Windows 11 特有のすれ違い
他社 VPN、フィルタドライバ、セキュリティスイートが同時に有効だと、ログ上は正常でも実パケットが別インターフェースに流れることがあります。疑わしいときは VPN をいったん終了し、管理者権限で Verge を起動し直し、ログをクリアしてから再現します。また UWP／Microsoft Store アプリだけ取りこぬける場合は UWP ループバックとシステムプロキシ の論点が混ざることがあります。
よくある質問
debug にすると重くなる・フリーズしそう
切り分けが終わったら info に戻す運用で十分です。長時間 debug のままにするとディスクやメモリを圧迫するビルドもあるため、再現手順が決まったらレベルを下げてください。
ログの英語メッセージが分からない
行の先頭付近の動詞（dial, resolve, match）と、続くドメインや IP を拾えば十分なことが多いです。全文翻訳より、同一操作をくり返したときに増える語をメモして検索するほうが早いです。
Mihomo の公式ドキュメントと何が違う？
コア側のログ形式は Mihomo（Clash Meta）に準じますが、GUI のフィルタや「どの画面から辿るか」は Verge 側の実装次第です。本稿は OS が Windows 11 で、Verge の画面操作に寄せた読み方です。
まとめ
接続タイムアウト の切り分けは、「ログレベルを上げる → 再現操作の数秒だけを読む → DNS・TLS・upstream のどれに語が寄っているか決める → 仮説を一つずつ試す」の反復でほぼ足ります。ログパネル は万能診断ではありませんが、ルールと実際の出口のズレを一発で可視化できるため、感覚でノードを入れ替え続けるより再現性が高くなります。
従来の「全体を一本のトンネルに載せるだけ」の VPN クライアントは、アプリごとの経路や DNS の細かい挙動をログから追いにくく、トラブル時になぜそのドメインが失敗したかまで手元で確かめづらい場面があります。Clash／Mihomo 系はルールファーストの設計とテキストログの文化が揃っており、同じ考え方を 他 OS の Clash クライアント に持ち替えやすいのも実務的な強みです。長く運用するなら、公式導線で入手先を揃えたうえで自分向けの GUI を選ぶと更新追従も楽になります。