Mihomo Party（Windows）でリアルタイムログと接続（Connections）を読み解く：現在のノードとトラフィックを確認する手順

想定読者と、この記事で手に入るスキル

検索の段階が「インストール手順」から一段進んで、挙動の証拠を画面から取りたいときに読む記事です。ブラウザは開けるが遅い、特定サービスだけ失敗する、いま本当にその国の出口か不安──こうした問いは、最終的にはログ行と生きている接続行の突き合わせが早いです。Mihomo Party は Mihomo（Clash Meta）コアを前提にしたデスクトップ向けクライアントの一つであり、メニュー語彙は英語混在になりがちですが、他の Mihomo 系 GUI と同じくLogs／Connections／Proxiesの三つが運用の主戦場になります。

本稿のゴールは、次を説明できるようになることです。ログに出る代表メッセージの意味をざっくり説明できる。接続一覧の列（送信先、ルール、チェーン、転送量など）から出口ノードを辿れる。体感の遅さを「DNS っぽい」「TLS まで行っていない」「プロキシ先が死んでいる」のどれかへ寄せられる。ここまで揃うと、購読の更新不備なのか、ノード単体の問題なのか、ルールが思ったポリシーを見ていないのかを切り分けやすくなります。

ログや接続を開く前に：前提だけ整える

アクティブなプロファイルが意図した購読マージ結果であること、日常はRule（ルール）モードで運用していること、必要ならシステムプロキシまたは TUN がオンであること──この三点は接続行が出る土台です。ここがズレたままログだけ眺めても、「実際のトラフィックがそもそもコアを通っていない」パターンで空振りしやすいです。複数プロファイルを試している場合は、いま選択されている名前をタスクトレイメニューか設定画面で再確認してください。

また、Windows ではブラウザのセキュア DNSや別製品のフィルタ、会社の透明プロキシが割り込むと、ログ上では期待したルールに刺さらないように見えることがあります。まずは当該ブラウザだけ別プロファイルで試す、拡張機能を無効化したウィンドウで試すなど、変数を一段減らしてからログを読むと解釈がぶれにくいです。

リアルタイムログの見方：何が嬉しいか

リアルタイムログは、コアが判断した出来事の時系列です。典型は、ルールマッチ（どのルール行に当たったか）、DNS 応答、プロキシチェーンの選択、TLS／TCP 失敗、認証エラーなどです。画面によってはログレベルを下げられるので、まずは情報量を抑えてノイズを減らし、必要になったら詳細に上げるのがおすすめです。常に最大詳細のままだと行が流れ、原因行を取り逃がします。

実務では、失敗したホスト名をログの検索欄に入れて絞り込み、直前後の数行だけを読む運用が効きます。HTTPS サイトでは接続先が IP 化している場合もありますが、SNI やルールの説明行が併記されることがあるため、Connections 側のホスト列と往復で照らすと辻褄が合いやすいです。外部ダッシュボード（Yacd 系の導線を使う場合）と併用すると、より長い履歴を一覧化できますが、日々の切り分けはクライアント内蔵のログで足りることが多いです。

接続パネル（Connections）の列を読む

Connections は、実際に張られたフローごとのスナップショットです。表の意味づけはクライアント実装で列名が違っても、だいたい次の軸で理解できます。送信先（ドメインや IP／ポート）、プロセスや発信元（取得できる場合）、適用されたルール名、チェーン（どのプロキシ系列を辿ったか）、上り・下りの転送量とスピード、接続状態です。ここで一番知りたいのはしばしばチェーン列で、末尾近くに現れる名前が実際に外向きへ出た出口ノードとして扱ってよいことが多いです。

チェーンが二段以上になるのは、ポリシーグループの入れ子や、親グループが子グループを指しているためです。Proxies 画面の折りたたみ構造と同じ階層イメージで捉えると混乱が減ります。どうしても名前が合わないときは、proxy-groups 定義を YAML で直接見るのが最短ですが、日々の運用では「Connections の行を一つ掴んで Proxies の該当カードへ戻る」往復で十分なことが多いです。

トラフィック統計は、一覧の速度列や累積転送、あるいはダッシュボードの合計表示として出ることがあります。数字はあくまでそのクライアントが握っているフローに限定されるので、別経路の直接接続や OS の別スタックとは一致しません。目安として使い、乖離が大きいときは「そもそもこのアプリがコア経由か」を先に疑うのが安全です。

「いまどのノードか」を確実に掴む手順

手順は単純です。（1） Connections を開いた状態で、ブラウザから対象サイトを一度リロードする。（2） 新しく増えた行（または更新が激しい行）をホスト名で見つける。（3） その行のチェーン列を右から左へ辿り、Proxies 画面で同名がアクティブか確認する。（4） 必要なら同じタイミングでログを見て、ルール名とマッチ理由を拾う。この四拍子で、「ルールは刺さっているのに別出口だ」「DNS だけ直結している」などのパターンが区別しやすくなります。

• 動画・大容量サイトは一度に複数フローが立つので、ホスト名検索で絞り込む
• すでに張られた長寿命接続は別ノードに切り替えても残ることがあるため、再接続を促す（タブを閉じる／アプリ再起動）
• 特定アプリだけ違う挙動なら、その実行ファイル名が接続一覧に出るかを最初に見る

遅いときに見るもの：ログと接続の役割分担

体感が遅いとき、いきなり別ノードへ飛び移らず、まずその接続行の速度表示とチェーン先を見ます。一桁 kbps 台で張り付くなら、サーバ側の輻輳やピーク時の帯域制限の影響を疑います。一方で、遅延テストでは低いのに実効が悪い場合は、測定 URL と実サービスのルートが別である典型です。ログに timeout や i/o timeout が点在するなら、ノード単体の不調か測定先ブロックの線が濃厚です。

DNS が怪しいサインは、名前解決まわりのログが先に暴れること、あるいは接続は立っていても初回だけ極端に時間がかかることです。逆に、TLS ハンドシェイクで詰まるパターンは出口ではなく中間のフィルタやサーバの一時障害も見えます。ここでログの数行と接続行のホスト名さえ揃えば、推測ではなく証拠つきで次の打ち手（ノード変更、DoH オフ、別ブラウザ、IPv6 無効化など）を選べます。

つながらない／不安定：切り分けの順番

よく効く順番は次です。（1） コアとシステムプロキシ／TUN が期待どおりか。（2） 購読の更新時刻とプロファイル選択が正しいか。（3） Connections にフロー自体が生えるか。生えないならローカル経路の問題寄り、生えるがすぐ切れるなら出口・DNS・TLS の順で疑う。（4） ログでホスト名フィルタをかけ、直近のエラー種を分類する。（5） 単一ノードだけ不調なら別地域へ、全面不調なら購読全体やネットワークを疑う。この流れは他の Mihomo 系 GUI と同じ骨格で、Mihomo Party 固有の罠は主に UI ラベルの探しやすさ程度です。

Windows 特有の補足として、Microsoft Store 系アプリはシステムプロキシを拾わないことがあります。接続一覧に一切出てこないのにブラウザは通る、という切り分けが付いたら UWP ループバックや TUN の検討に進みます。Chrome の QUIC／セキュア DNS絡みで TLS の挙動が変わるケースもあるため、ブラウザ横断で再現するかも見ます。

よくある質問

Connections が空っぽに見える

一覧のフィルタや並びの都合で見えていないだけのこともありますが、本当にフローが無いならトラフィックがコアに入っていないサインです。システムプロキシ、TUN、対象アプリのプロキシ設定を上から疑ってください。

ログが溢れて目的の行が拾えない

レベルを下げ、検索欄でエラー語やドメインを限定するのが先です。どうしても難しい場合は短時間だけページ操作を行い、その間のログを保存できる実装ならエクスポートしてからテキスト検索すると楽です。

チェーン表示と Proxies の選択が一致しない

古い接続が残っている、入れ子グループの別階層を見ている、購読更新でノード名が置き換わった、といった場合があります。当該フローを閉じてから再度作り直し、ノード名の差分を確認します。

まとめ：見える化があるから運用が続く

ワンタップ型の商用 VPN は手軽ですが、どの接続がどのルールでどの出口へ行ったかを残しにくく、遅延や切断の原因をユーザー側で追いかけにくい面もあります。一方 Mihomo コア＋ GUI は、多少の学習コストの代わりにログと接続一覧で経路を説明可能にできます。Mihomo Party のように Windows 向けに整理された画面があれば、日々のノード確認やトラフィックのざっくり監視も現実的な負担になります。ルール型クライアントのなかでも長くメンテされる上流実装と噛み合わせたい方は、→ Clash を無料ダウンロードして、快適な接続体験を始める、公式の入手経路で環境を揃えてから、本稿の手順を当てはめるのが安心です。