1. 対象読者と本稿で扱わないこと
ここではバイナリの入手方法やパッケージ署名の詳細には踏み込みません。必要なら公式ドキュメントや配布元の README とあわせて、当サイトの ダウンロードページから環境に合ったクライアントへ進んでください。また購読 URL の TLS ハンドシェイク失敗や DNS の張り方そのものは、ログの読み方こそ共通でも「設定ファイル側の直し手順」が長くなるため、Windows 向けの 購読・TLS・DNS をログで追う記事に任せます。external-controller にシークレットを載せるか、LAN でだけダッシュボードを開くかといった話題は、セキュリティ寄りの判断が絡むので 外部コントローラとシークレットのガイドでまとめています。
逆に本稿が狙うのは、Verge Rev のウィンドウを開いたまま「今この一秒にどんな通信が流れているか」を俯瞰する習慣です。mihomo は背面でルールと DNS と実際の転送を担当しますが、GUI 側では数字が増える/増えない、一覧にホストが並ぶ/並ばない、ログに警告が出る/出ないという三本柱だけでも、根本原因がプロファイルにあるのか OS のプロキシ適用にあるのか、体感だけよりずっと早く分岐できます。
アプリのメニュー名やタブ名はリリースで微妙に変わり得ますが、「ホームでグラフ」「接続」「ログ」の三区画という役割分担は安定しているので、名称が違っても同じ見方に写し替えてください。
2. リアルタイムのトラフィック(送受信)を読む
たいていのビルドでは起動直後からホーム/ダッシュボードに近い画面に、短い間隔で更新されるアップロードとダウンロードのグラフ、または瞬間レートと累計に近い数値が載っています。ここがまず見るべきリアルタイム監視の入口です。ブラウザでどこか軽いページを開いたときに片方または両方のカーブが動くかだけでも、「コアが実際にパケットを扱っているか」「そもそもアプリがプロキシへ流していないか」を切り分けられます。
グラフがほぼフラットなまま通信しているつもりでも動かない場合は、(1)コア停止やプロファイル未適用、(2)システムプロキシ/TUN がオフでブラウザだけ別経路、(3)対象アプリがプロキシを読まないタイプのどれかが多いです。ここでいきなりルール YAML を疑うより、モードがルールになっているか、アクティブなノードが選択されているかといった GUI の左上付近によくあるインジケータから確認すると早いです。
速度表示はバースト的な接続では瞬間値が跳ねやすく、長めのダウンロードでは滑らかに見える、といった視覚差があります。数字をシビアに読むより「通信イベントが起きたタイミングで反応があるか」を優先してください。内部では mixed-port や別途指定したポートへアプリが実際に載っているかは接続一覧側で後から裏付けできます。
3. 接続一覧で確認する列と見る順番
接続/Connections と名付けられた画面は、現在コアが把握しているフローのスナップショットです。典型では宛先ホストまたは IP、ポート、プロトコル、アウトバウンド(プロキシや DIRECT のラベル)、遅延や転送量の近似が並びます。読む順番のおすすめはホスト名 → アウトバウンド → ルールやチェーンに相当する表示があればそれ → エラー相当のマークやタイムアウトです。
「ドメインだけ見えてパスが無い」状態でも、どの広告ドメインや CDN に繋がっているかはトラブルの種類を絞れます。特定サービスだけ開けないときは、そのサービスの認証ドメインや静的 CDN が意図しないノードへ載っていないかを一覧で確認し、ルール側の DOMAIN-SUFFIX や策略グループの選択と突き合わせます。
Sniffer を有効にしている構成では HTTPS のSNI 由来のホスト表示が増えます。HTTPS が期待ノードに行っていないときは、一覧とログをセットで見る運用が定番です。詳しいログ読みは Sniffer・SNI・ルーティングの記事も参照してください。
| 確認する項目 | 期待どおりか見る観点 |
|---|---|
| 宛先ホスト | 問題のサービスに対応する名前か。別ドメインへ誘導されていないか。 |
| アウトバウンド | ルールで決めたノード/自動選択/直結が表示と一致しているか。 |
| 転送量・所要時間 | ほとんど進まない場合は上流の遅さかブロックかをログ側で補足する。 |
| プロセス/アプリ名(表示される場合) | どのソフトがトラフィックを吐いているか切り分けに使える。 |
一覧が賑やかすぎて読みにくいときは、まずフィルタや検索があればサービス名のサフィックスで絞り込み、無ければブラウザを一度閉じて再接続し直してノイズを減らします。開発ツールや同期クライアントは常駐で細かいホストを大量に出すので、「異常かどうか」は普段と比べてエラー行や奇妙な地域のノードが混じったかで見ると現実的です。
4. ログビューアとログレベル
Verge Rev にはコアが stderr や内部バッファへ吐くメッセージをその場で読めるビューアが用意されていることが多く、設定画面やツールメニュー側にログレベル(silent/error/warning/info/debug など)を切り替える項目もあります。平常運転では info 前後で十分なことが多く、ノイズだらけになるまで上げない方がトリアージは速いです。どうしても DNS やルールマッチの細部が見えないときだけ、短時間 debug を試し、終わったら戻す運用がおすすめです。
ログに現れる語で典型なのはタイムアウト、証明書/TLS、名前解決失敗、上流プロキシ認証エラー、ポート競合などです。購読更新まわりで TLS と DNS を見る読み方は前述の Windows 向け記事に寄せつつ、本稿では日常的なブラウジングが詰まった瞬間のログを追う用途を想定しています。メッセージにホスト名が出ている行は、接続一覧の行とタイムスタンプを近い順に並べて突き合わせると因果が掴みやすいです。
ログファイルをOS のユーザー領域にエクスポートする/別エディタで開く機能があるビルドもあります。長いセッションを後から検索するときに便利ですが、認証トークンや接続先が残り得るので共有マシンでは保存場所に注意してください。
5. Windows と macOS での探し方のコツ
Verge Rev はクロスプラットフォームですが、システムプロキシや TUN を誰が適用するかは OS ごとに違います。Windows では初回セットアップ時に システムプロキシと TUN/Wintun の切り替えが絡みやすく、一覧には Win32 アプリとストア系で挙動差が出ます。流れ全体は Windows 11 向け Clash Verge Rev の初回設定や Windows 10 版がベースになります。
macOS ではネットワーク拡張まわりの権限承認や、ブラウザがシステム設定のプロキシを読むタイミングがポイントになります。macOS における初回構成の記事とセットで読むと、「グラフは動くがブラウザだけ妙」「一部アプリだけ直結」のときにどこを開けばよいかが腹落ちします。
どちらの OS でも共通するのは、GUI の三本柱(トラフィック・接続・ログ)と OS 側のプロキシ設定画面を往復することです。ブラウザだけがおかしいときは Chrome/Edge のセキュア DNS とシステムプロキシの記事も参照すると、ログに出ないレイヤの典型に早く当たれます。
6. 症状別の短いトリアージ表
現場では次の順で見ると迷いが減ります。(1)コア稼働とプロファイル適用を確認し、(2)ホームのグラフがイベントに反応するかを見る。(3)反応が薄いならシステムプロキシ/TUN と対象アプリのプロキシ無視を疑う。(4)グラフは動くが特定サイトだけ失敗なら接続一覧でホストとアウトバウンドを確認し、(5)それでも理由が見えなければログレベルを上げて短時間再現する、という流れです。
「ブラウザは快適だが CLI ツールが失敗」は環境変数 HTTP_PROXY が空だったり、ツールが独自のネットワークスタックを使っているパターンです。「ゲームだけ不安定」は TUN をオンにして一覧へ載せられるか試し、競合 VPN が無いかも見ます。「寝たあとだけ壊れる」は仮想アダプタの復帰順なので、ログに再接続エラーがないかを寝る前にメモしておくと再現時に楽です。
DNS モードが fake-ip のときは、一覧・ログ・実ブラウザの挙動が一見矛盾して見えることがあるので、モード理解が必要です。fake-ip と redir-host の比較記事で設計思想を押さえてからログを読むと、行の意味がブレにくくなります。
7. よくある質問
ログ画面がほとんど動かないのは正常ですか? 通信が無い時間帯やログレベルが低いとそう見えます。軽いサイトを開いてイベントを作り、必要ならログレベルを上げてください。
トラフィックの数値がほぼゼロのままです。 コア停止、プロファイル未選択、プロキシ適用オフ、対象アプリのプロキシ非対応の順に疑います。Windows ブラウザではセキュア DNS がプロキシとは別レイヤで効いているケースがあります。
接続一覧に大量の行が出ます。 常駐アプリやブラウザのサブリソースでは普通に起きます。問題かどうかはホストが信頼できるサービスか、ログにエラーがペアで出ていないかで判断してください。
購読や外部コントローラの話はどこ? 購読取得と TLS/DNS は専用記事、外部コントローラとシークレットはセキュリティ寄りのガイドへ回しています。本稿はあくまで稼働中クライアントのモニタリング UIにフォーカスしています。
9. まとめ
Clash Verge Rev におけるリアルタイム監視の中心は、送受信グラフ・接続一覧・ログの三本です。インストールや購読が終わったあとであっても、この順に眺めるだけで「コアが動いているか」「どのホストがどのアウトバウンドに載っているか」「ログに決定的なエラーがないか」まで一気に狭められます。細かい文言はバージョンで変わっても、役割さえ押さえれば迷いません。
外部コントローラの公開や購読取得の例外処理など、セキュリティと運用の境界に触れる話題は意図的に別記事へ分けました。日常のブラウジングや開発ツールのつまずきは、まずこのウィンドウの上で事実を拾ってから設定ファイルへ戻ると、試行錯誤の回数を大きく減らせます。
環境に合ったクライアントを固定し、ログを読む導線まで含めて習慣化すると安定運用につながります。 → 無料で Clash をダウンロードし、快適な接続を試す
関連記事 · 同じテーマ
トピックの近さで選んだ関連記事 — 同じカテゴリの Clash 実践ガイド。
Intel Mac に Clash Verge Rev を入れる:購読・システムプロキシ・TUN を一度に通す初回ガイド(x86_64・mihomo・2026)
x86_64 Mac で dmg 選択から購読、mihomo 起動、システムプロキシ検証後に TUN とネットワーク拡張の許可まで一連で。
続きを読むApple Silicon Mac に Clash Verge Rev をインストール:システムプロキシと TUN の初回設定、権限とネットワーク拡張
M1〜M4 の Mac に Clash Verge Rev を導入。システムプロキシ・TUN・ネットワーク拡張まで初回の流れを整理。
続きを読むWindows 11 に Clash Verge Rev:システムプロキシと TUN の初回設定、Wintun・UAC・よくあるエラー
Win11 で Verge Rev をゼロから。インストールと SmartScreen、購読取り込み、システムプロキシだけで足りるケースと TUN が要るケース、Wintun・管理者承認、DNS・UWP・LAN まわりの切り分け。macOS 稿・CFW 移行稿・UWP 稿と補完。
続きを読む