Clash for Windows の通信統計とコアログを読む：詰まり・遅延・未プロキシの切り分け

なぜ Connections とログを見るのか

体感の遅さや接続エラーには、大きく分けて「出口であるプロキシノードやプロトコル」「ローカルのルール・モード・DNS」「アプリ側がプロキシを無視している」という三系統があります。ブラウザのキャッシュ削除や再起動だけを繰り返す前に、Clash がその通信をどう解釈したかを一度スナップショットで掴むと、無意味な試行錯誤が減ります。

Connections は「今 Clash が握っているフローの一覧」であり、ホスト名・プロトコル・最終的に通したプロキシチェーン・転送量の目安が同時に見えます。ログ はコアが内部で出す診断行で、タイムアウト・拒否・証明書・ルール評価のヒントがタイムスタンプ付きで残ります。どちらも正確には「すべてのパケットキャプチャ」ではないため、Windows 本体の別ドライバや他製品 VPN と競合すると、画面上の行と実体が食い違うこともあります。それでも日常のほとんどの Web 閲覧では、最初の切り分けに十分な解像度があります。

Connections（通信）タブで確認する項目

CFW の左サイドバーから Connections を開くと、現在アクティブなコネクションがテーブルまたはリストで並びます。UI の細部はバージョンで多少異なりますが、押さえるべき列は共通です。ホスト／宛先 で問題のドメインが載っているか、プロセスや送信元 が表示される構成ならどのアプリ由来か、チェーンまたはポリシー名 でどのプロキシグループ経由になったか、DIRECT と書かれていないか を優先して読みます。

ブラウザだけが対象なら、問題ページを開いた直後に一覧を更新し、同名ホストで複数行が増えることがあります。静的ファイル用 CDN のホストが別ドメインになる場合、見えている遅さが「メイン HTML ではなくサブリソース」由来かもわかります。下り方向の転送量が異常に伸びている行は、動画や大きな JSON の取得に時間がかかっているサインになり得ますが、計測値はあくまで Clash が中継した範囲の近似として扱うのが無難です。

• DIRECT が続く：ルールで国内扱いになっている、アプリがプロキシ経路に乗っていない、モードが Direct、などを疑う。
• 期待しないセレクタ名：手動で選んだグループや、MATCH まで落ちた結果を確認する。
• 行が現れない：システムプロキシ未適用（UWP は例外的）、TUN 未使用でプロキシ非対応アプリ、別プロファイルがアクティブ、の可能性。

体感が重いときの実務ワークフロー

この流れで「ルールどおりプロキシに乗っているがタイムアウトが多い」のか「そもそも DIRECT のまま」のかがほぼ確定します。前者はノード／回線／プロバイダ制限側、後者はルール順序・GEOIP・ドメイン記法・モード・アプリ側の経路が候補です。Clash は同一ドメインでもサブドメインごとに別行になるため、「トップページは速いが API だけ詰まる」といった分割現象も一覧で説明しやすくなります。

ログ（Logs）とコア出力の読み方

Logs タブでは、コアがイベント駆動で出力する行がスクロール表示されます。設定によっては冗長さを抑えるため既定が warning になっていることがあり、初期状態では情報が足りず「何も起きていないように見える」ことがあります。切り分け中だけ info や debug に上げ、問題が再現する数十秒だけ様子を見てから元に戻す運用が現実的です。ログを長期間 debug のまま放置するとディスクやメモリ負荷が増えるので注意してください。

典型としては タイムアウト系（上流への TCP／TLS 確立や読み取りで時間切れ）、証明書／TLS アラート（ミッドルボックスや不正な傍受、まれにスニファ設定との相互作用）、拒否やポリシー不一致（ルールプロバイダの読み込み失敗など）がログに現れます。日本語 UI のメッセージと英語メッセージが混在しても、ホスト名やエラーコードが同一なら同一クラスの事象です。複数行が同じ秒に並ぶときは、DNS クエリと実接続のペアになっていることが多く、名前解決は速いが上流が遅い、という切り分けに使えます。

ルール命中と「思ったプロキシに行かない」ケース

Clash のルールは上から順に評価され、最初に一致した行で振り分けが決まります。購読に同梱された巨大なルールセットと自作ルールを併用している場合、思い込みのドメイン表記（ワイルドカードの位置、小文字化の有無）や RULE-SET の更新失敗 で、意図せず下流の MATCH まで落ちることがあります。Connections に出るポリシー名と、設定ファイル上のセレクタの対応を頭に置きながら見ると、手動選択を変えても別の自動グループが上書きしていないか判断しやすくなります。

GEOIP 系の行は、mmdb の鮮度や到達 IP の実体が CDN エッジであることで「国の期待とズレる」ことがあります。その場合、Connections にはビジネスロジック上のドメインが出ていても、GEOIP 判定だけが別大陸へ飛ぶ、といった不思議な振る舞いが起きます。根本はルール設計またはデータ更新ですが、まず一覧で実際に選ばれたチェーンが何かを確認することが改修の前提になります。

DNS・fake-ip とログの見分け（入口だけ）

fake-ip を有効にしているプロファイルでは、ブラウザが最初に見る IP と実際の宛先との関係が直感とずれやすく、ログに DNS 関連の行が増えがちです。ページ全体が開かないのに Connections に行が少ないときは、名前解決の段階で止まっている可能性を考えます。詳しい手順と定石は「接続されているのにインターネットにならない：DNS と fake-ip」に譲りますが、本稿の枠組みでは「Connections にドメイン行が出る前にログで DNS エラーが立っていないか」をまず確認してください。

Connections に出てこないときに疑うもの

通信行が増えないのにブラウザだけ通信しているように見える場合、システムプロキシがオフ か 別のプロキシソフトが OS 設定を握っている ケースが多いです。Clash を終了したあとブラウザが逆に繋がらなくなったときは、「終了後にシステムプロキシを戻す」で Windows 側の残留設定を確認してください。ゲームクライアントや一部の開発ツールは自前で直結するため、必要なら TUN モードを検討しますが、企業 VPN やセキュリティ製品との競合に注意が必要です。

ターミナルからの curl や git が経路を無視する話は、「ターミナル HTTP／Git プロキシ」で環境変数レベルまで踏み込めます。CFW の画面だけでは足りない層なので、症候に応じて併読してください。

よくある質問

Connections に該当サイトの行が全く出ません

システムプロキシや TUN がオフ、アプリがプロキシ設定を無視している、別プロファイルがアクティブ、などが典型です。CFW の General とモードを確認し、必要なら TUN や対象アプリ側のプロキシ設定を検討してください。UWP だけ別挙動のときは関連稿も参照してください。

ログに DNS や fake-ip の記述ばかり出ます

名前解決とルール評価が絡んだ状態です。tun／mixed／DNS の設定と fake-ip の挙動は「DNS と fake-ip」で整理しつつ、Connections のホストが期待どおりかと突き合わせます。

ルールで MATCH まで落ちているように見えるのに遅いです

MATCH でプロキシに載っても、上流が混雑している・GEOIP が意図と異なる地域へ振っている・チェーンが長く別経路になっている、などがあります。セレクタとノードを変えた対照実験で出口側か設定側かを切り分けてください。

まとめ：日常のチェックリスト

遅さや不達を感じたら、(1) モードとシステムプロキシの状態、(2) Connections でホストと DIRECT／プロキシの別、(3) ログのレベルとエラー種別、(4) ノード変更の対照実験、の四点を順に見るだけで大半の相談は半分に絞り込めます。大量のノードを試すより、まず「その通信が Clash に見えているか」「見えているならどのチェーンか」を確定させる方が早いです。Windows 11 で新しいクライアントに移行する場合も、Connections とログという観点はそのまま移植できます。

安全なバイナリと更新情報の追いやすさの観点では、入手経路を固定しておく意味があります。Clash のダウンロードページ から案内されているクライアントは、説明とリリース履歴を追いやすく、トラブル時にバージョン差分を疑う際にも有利です。