macOS で Clash Verge Rev のリアルタイム転送量と接続ログを読むステップガイド（2026）
macOSでClash Verge Rev（Mihomo コアの GUI）は、すでに代理が機能している状態でも「どのアプリがどの出口へ」「いま名前解決で止まっているのか」を画面上のカウンターと接続リストとログから追えます。初回セットアップやウィザード直後の許可確認ではなく運用観測に焦点を置いた読み解きです。
検索されている状況に合わせた読み方
「Clash Verge Rev macOS リアルタイム 通信量」「接続ログ 見方」「トラフィック 統計」などでここへ来たとき、多くの方はブラウザの砂時計だけが回り、アイコンの点灯は変わらない状態を切り分けたいはずです。macOS はシステムプロキシ経由のアプリと、独自 DNS over HTTPS で逃げるアプリが混在しやすいので、カウンターが増え続けているのに目的ドメインの行だけ動かない、という光景が現場では珍しくありません。
Mihomo ベース製品共通の語彙（プロファイル、アウトバウンド、RULE / GLOBAL / DIRECT）がまだ頭に入っていない場合は、橋渡しとしてClash チュートリアルを横においてください。TUN とシステムプロキシの性質だけ押さえるならTUN モード解説記事の前半で十分です。
本稿が扱わないもの（読み分け）
ネットワーク拡張機能のオンオフや購読 URL のインポート、初回のみの許可ウィザードまで含んだ道順は、macOS Clash Verge 初回セットアップ記事に譲ります。ここでは権限済み・アクティブなプロファイルがある前提で、その先の転送カウンター、接続（Connections）、ログの三つの窓を同時運用するときに迷わない並べ方だけを説明します。
類似ワークフローの Windows 視点が欲しければ、同一思考を別 UI で観ているWindows 11 版ログ／接続読み記事とセットで読むと並び順の読み込み癖が転用しやすくなります。
ステップ 1 観測対象を一つだけ残す
問題のサイトやアプリだけを再起動して残し、その他のアプリによるトラフィックを極限まで絞ってください。Viscosity など別系統の VPN と二重化しているときは競合側をオフにし、復現開始の時刻（分粒度）をメモしておくと、後から並べた接続リストとログ行の順序対応が一気に楽になります。
音声通話など UDP が混ざるケースには別ルールセットが効くため、その場合だけはDiscord と UDP に関する切り分け記事へ迂回するのが安全です。本記事では主にブラウザ系のTCP と DNSに焦点を当てます。
ステップ 2 ダッシュボードのカウンターで勢いを掴む
Clash Verge Revのメイン画面やサイドナビにある転送カウンター（送受のアップロード・ダウンロード総量および瞬間速度）では、ネットワークに「何も流れていない」のか、「流れているのに体感が無い」のかがすぐ見えます。数値がゼロストップしたままページが読み込めないときは、アプリ側がプロファイルに達していませんまたはブラウザがシステムプロキシより先に自分の名前解決を使っていることを疑ってください。
カウンターが伸び続けているのに UI が進まないケースでは、増分がyoutube.comの広告だけなどユーザーの体感ドメインと無関係に偏っていることが多いので、ステップ 3 で一覧のソート順を変えてから読み込みます。GUI の項目名やタブ順序はビルドでわずかに変わりますが、考え方は「累積と瞬時をまず眺める」の一点に集約できます。
ステップ 3 接続一覧でホスト名とアウトバウンドを固定する
「Connections」「セッション」「アクティブ接続」と呼ばれるビューを開けば、現在アライブなソケットが宛先ホスト・アウトバウンド経路経過時間送受バイトの列で並びます。この表示がMihomo エンジンの観察窓そのものなので、ログを読む前にここで目的ホストがどの出口グループへ送られているかを確定させると読み込み時間が縮みます。
並び順を送受增量か開始時刻へ切り替え、増え続けている行だけをチェックしましょう。ルール順の誤解釈はカスタムルールの練り方記事を参照すると、どのアウトバウンドに落ちるべきだったか説明できるようになります。
注意：proxy-groups で指定した遅延テスト URLだけがタイムアウトしても、別ドメインの実業務サイトは健在、という状態は日常茶飯事です。url-test と実ページのログ行を混同しないでください。
カウンターと一覧の両方から増分があるのに体感が進まないときは、アプリ側が HTTPS CONNECT の途中で証明書や ALPNの往復だけを伸ばしている、あるいは上流ノード側の QoSで頭打ちされている可能性が並びます。ここまで来たらステップ 4 以降のログでフェーズ順に読みます。
ステップ 4〜5 ログを開いて短時間だけ詳しくする
ログウィンドウを並べて先にバッファを空にし、自動追従を止められる UI では止めてから再読み込みひと撃ちを試します。既定のログレベルが静かだと並び順の意味が読めませんのでwarning固定では足りず、問題のある数分だけinfoまたはdebugへ緩め、終われば必ず戻してください。HDD とプライバシー双方に配慮するのが鉄則です。
読むときは英単語単位よりフェーズ順が重要です。名前解決の往復だけが赤く増えれば DNS 側、dial が始まってから止まれば遠側のトンネル、TLS だけ遅ければ環境側の DPI も視野です。一覧でアウトバウンドまで確定したあとだけが伸びるなら、そのグループ単位での健全性チェック結果と突き合わせます。チュートリアルで policy の概念を頭に描いておくと同じ並びでも迷いません。
ステップ 6〜7 RULE／GLOBAL／DIRECT の短文実験
読み順が頭に入ったら、恒久設定を書き換えず短文で試します。DIRECTのみ速ければ規則送りまたはローカルの DNS と実ドメインの食い違いが優先順位調査を促します。GLOBALでだけ安定するとルールの順番や GEO 条件への誤ヒットなど上流ロジックを疑ってください。恒久運用はRULEへ戻し、ログは観察のための短期的なものにします。
メニューバー側の状態表示とウィンドウ内のカウンターが食い違うときは、macOS がバックグラウンドで自分の名前解決を挟んでいないか、別プロファイルのアクティブ切り替えが残っていないかなどコンテキストを疑います。ここでの判断に迷えば前述の初期セット記事のトラブル節だけに一瞬戻るのが効率的です。
購読鮮度と共通要因への外部リンク
ログだけを読み込んでもsubscription userinfoが枯れているときは頭打ちになりますので、リスト更新の共通パターンは購読 URL FAQ側で整理します。異常終了ログがEOFやi/o timeoutばかりなら上流ノードのローテーションも検討し、UI の健全性チェックより問題ドメイン専用のログ行を優先しましょう。
一部ドメインでだけ sniff 設定が期待とズレているケースについてはMihomo の sniff と DNS 記事で例外を頭に描いてください。無闇に機能を無効化するよりログ行で当たりが付いた範囲だけを調整すると安全です。
短い質問だけ
メニューバーからは細部まで見られるか
総量／モード状態の確認とクイック切り替えが主で、一覧の複数列比較は本体ウィンドウを開いた方が速い構成が多いです。
ClashX 系とも比較したい
レイテンシテストやポリシーグループ中心のワークフローを知りたい場合はClashX Pro の遅延テスト記事が近い観察軸になります。
ログが流れすぎる
ドメインフィルタとウィンドウ幅を活用し増分のあった数十行だけをテキスト化して別デバイスで確認すると視認性が安定します。
締め
接続リストと転送カウンターを先に並べログは後からフェーズ順に読めば、「どのウィンドウを信用するか」を迷わずに済みます。Open Clash を含むクラスタはルーター側でも一覧とログが同居する設計が多く、デスクトップの Verge と同様の頭の運び方が転用されます。
一方で従来型の単一サーバー VPN クライアントの多くは、ドメイン単位で何が詰まったかユーザーに細かく見せず、体感が悪くなると国や地域だけを総入れ替えする運用になりがちです。Mihomo レイヤーを前面にした Clash Verge Revはこの観察の深さをデスクトップで再現できるため、ノード総取り換えより先にカウンターとリストとログの三窓ワークフローを一度回した方が手戻りが少なく済みます。最新チャネルを押さえるならClash をダウンロードできる公式導線から入手元を確認し、本稿で説明した観察手順だけで異常経路がかなり絞れるはずです。