前提：CfW と Windows 11、まず準備済み項目

この記事は「Windows 11 で Clash for Windows（略称 CfW） が起動できる」「購読またはローカルの YAML からノード一覧が表示される」状態を出発点にします。初回セットアップだけを知りたい場合は同じプラットフォーム向けに執筆した Windows 11 で CfW に購読を取り込む手順 を先に進め、そのあと本章へ戻ると頭のなかでの区切りがはっきりします。とはいえ CfW はコミュニティ全体で開発が停滞しがちなクライアントでもあるので、画面上の項目名やアイコン位置は使用中のビルドに合わせて読み替えてください。ここでの記述では「画面上の名前が分からなくても、探すべき機能のグループ」を中心に並べています。

CfW が古い構成の実装でも、根っこにあるのは profiles＝適用すべき構成ファイル一式、proxy providers＝インポートしたノード、proxy-groups＝UI で触るグループ類、というレイヤーの積み上げです。GUI の Proxies（プロキシ） タブ／パネルは基本的にグループ一覧を開く入口であり、その下に並ぶ丸いラジオの集合が「海外出口をどれに載せ換えるか」という日々の運用レイヤーになります。この記事でも「ノード一覧ではなくグループ」の順で見ないと、自動選択グループとの兼ね合いで期待と違う出口に載ってしまう、という経験を減らす狙いがあります。なお CfW と別クライアントの比較は クライアントの選び方 にまとめていますので、機能差で迷うときに参照するとスッキリします。

⚠ 注意：CfW では入手元によりメニューラベルや言語セットが異なる場合があります。また保守が追いついていないときは、アンチウィルスの隔離や古いランタイムで UI が読み込まれない問題が起きやすいです。UAC などの許可だけを安易に与え続けるのではなく、ファイルの検証結果と利用目的をセットで評価してください。

CfW で「ルール」「グローバル」「グループ」をつなぐ考え方

まず Rule（ルール） モードは、設定ファイルの DOMAIN／GEOIP／FINAL などの優先順位にしたがって、通信ごとの出口を自動で振り分けます。画面上は「全体スイッチ」ではなく上流のグループチェーンの入口をどこに載せているかという話なので、「Rule にしたのにサイトが繋がらない」ときはグループ側で REJECT まで落ちていないか、あるいは国内向けリストが広すぎて意図せずダイレクトに落ちているかを疑うのが定石です。一方 Global（グローバル） は、ルール評価の手前でまとめて一つの上流グループへ投げ込む運用になりがちです。短期間だけ「すべて同じサーバー経由でテストしたい」「ストリームのログイン状態を単純に揃えたい」といったときに便利ですが、国内アプリまで重い経路へ流れることもあり得るので、普段張りっぱなしには向きません。

Direct（ダイレクト） は名前どおり強い直進を意味することが多く、ルール評価以前にすべてをキャリア直結側へ載せ換えるような期待を持ちがちです。実際にはビルドと設定により「Global と同列の単純化スイッチ」寄りであったり、「最終的出口がすべて DIRECT」のように見えるまでに上流の自動選択グループを挟んでいたりすると差が出ます。こうしたときの切り分けは Connections 相当の一覧で現在のチェーンが何段あるか俯瞰するのが早いので、レイテンシ数字だけ見て決めないでください。また「システム全体をプロキシする」レイヤーの話になると General の System Proxy（システムプロキシ） と絡むため、モードだけ切り替えてもブラウザが反応しない、という状態とセットで頭に置く必要があります。こうした順序認識を誤らないだけで、「ルールだけ切り替えたのになぜか出口が変わらない」といった誤認はかなり減ります。

ℹ️ CfW が表示する名前は購読 YAML の proxy-groups セクションの name をそのまま流用しているだけのケースが多いです。そのため画面上に英語しか出なくても、プロバイダが付けた 自動選択／手動選択／フォールバック といった意図を読んでおくと、後述のグループ運用でも迷わなくなります。

Proxies とレイテンシ一括計測の実務手順

Proxies 画面へ移動したあと最初に確認したいのは、現在有効になっているプロファイルが意図したものであることです。購読を更新したばかりでノード増減があると、画面上の並び順が変わっていることがあります。そのうえで、多くの CfW 系デスクトップクライアントが備える一括レイテンシ計測機能（画面上は「レイテンシ」「Delay」「チェック」のような総称になりがち）は、画面上部〜ツールバー付近にあるボタンか、コンテキストメニューの「グループすべてをチェック」のような名前で公開されています。押下すると一覧の待ち時間欄へ数値または「timeout」の文字が流れ込み、その瞬間でもっとも体感が軽そうな候補を短期間だけピン固定するときに使えます。このときのレイテンシはあくまで「テスト対象へ小さなリクエストを投げて帰ってきたまでの体感」であり、細かい QUIC 経路や帯域飽和までは読めないので、ストリーム用途なら別途ブラウザで実測するのが確実です。

グループ単位にも同種のチェック項目があり、親グループ側で子ノードだけを並列で叩けるビルドもあります。典型は URL-Test と呼ばれるタイプです。親が自動で「いま勝っている子」を選んでいる最中でも、親自身のチェック結果と子個別の数値にはズレがあることがあるので、両方見たうえで手動グループへ切り替えるかどうかを決めると運用ミスが減ります。もし親側の自動更新間隔が長すぎると、購読のメンテ直後だけ古い並び順のまま出口が固定される体感になるため、その場合は手動グループ側で明示的に切り替えるか、YAML で間隔調整という発想に進みます。このセクションだけでは YAML の構文までは深追いしないので、自動選択グループの概念整理は ポリシーグループの概念ガイド と併せて読んでください。また計測先 URL がブロックされると一覧が「全部赤」にも見えるため、環境側の検閲との切り分けも忘れないでください。

proxy-groups excerpt (conceptual YAML) 
proxy-groups:
  - name: "自動選択海外"
    type: url-test
    proxies:
      - ノード A
      - ノード B
    url: https://example.com/generate204
    interval: 300

  - name: "海外手動ピン留め"
    type: select
    proxies:
      - 自動選択海外
      - ノード A
      - DIRECT

上記のような階段構造を頭に描いておくと、GUI で丸を押しているのが「終端サーバーそのものなのか、別の親グループの入口なのか」が読みやすくなります。また FALLBACK／health-check という別種の自動選択グループでは、異常検知のアルゴリズムや URL が違うため、同じ一覧でも並び順の意味づけが変わってきます。ここでのコツは、レイテンシ数字を盲信しないことと、並び順が購読の生成仕様により入れ替わるときは自分が使いたい親グループだけをスクロール位置にピンすることです。ウィンドウ幅が狭いモバイル環境での CfW 利用は標準とは言いがたいので、本稿でも Windows のマウス操作前提で書いています。

Selector／URL‑Test／Fallback／Relay が GUI にどう出るか

Selector（選択／手動グループ） は画面上でラジオやドロップダウンになり、ユーザーが自分で現在の上流を載せ換えます。YouTube でだけこのノードへ固定したいときに向きやすく、親がダウンしていたら別の親へ読み替えるといった自由度も確保できる反面、自動更新でいつも最短を追い続ける運用とは相性が違うので、その役割分担を誤らないようにします。URL-Test（レイテンシベース自動選択） は多くの購読で「自動選択」の実体になっており、GUI 側ではロックアイコンが付かない単純一覧として見えるだけのケースがあります。親を触れないときは直下の Selector を触ってエスケープする、という二段構成が一般的です。Fallback はしきい値以下になったときに自動で並び順を読み込み直す、といった復旧志向の並びになりがちで、体感としてはほかの自動選択タイプとの差が細かく、YAML の tolerance やチェック対象によって数字の意味が微妙に異なってきます。

Relay（チェーン） は画面上も入れ子のように見えることが多く、特定のサービスだけ「入口と出口が固定された二段」を走らせたいようなカスタム構成から出現します。このタイプだけは自動選択グループと混線しやすいので、親の自動選択グループ直下に自分で手組みした Relay がぶら下がっているのかどうかを一度 Connections で確認しましょう。もし画面上に表示されない名前が設定ファイル側には見えるときは、アクティブなプロファイル／購読の反映が終わっていないか、アプリ側の再起動が必要になっているだけのケースがあります。並び順のリフレッシュを忘れるとレイテンシ計測の結果がキャッシュにより古いように見えることもあり、Windows 側のウィルス対策によるローカルループへの干渉と混ざりやすいので注意がいります。そのあたりのネットワーク層での不可解ログは timeout と TLS のログ解読 に寄せられるパターンが多く、数字が悪くても必ずノード側の異常とは限らないので落ち着いて観察してください。

Rule／Global／Direct を切り替えるタイミング

運用フェーズでの典型は、日中はほぼすべて Rule に置きつつ、アプリ側の問題切り分けやストリーム端末側のログイン検証のみ短時間 Global へ載せ換えるという住み分けです。Global へ切り替えたときに国内の銀行アプリだけ反応が遅くなる、という現象も起こりやすく、それ自体がすべての経路が海外出口側へ載せられたサインです。そのため切り替えたら必ず時間をセットして最初の Rule に戻す習慣を付けるとヒューマンエラーによるトラフィック増を避けられます。Direct へ落としたいシナリオは、開発用途で明示的にトンネルを外したいときや、アンチウィルスの通信検査と干渉するから一時停止したいときなどに限られます。永続運用させるよりはログを取り終えてすぐモード復帰を推奨します。

どのモードでも最後に確認すべきなのが FILTER 相当のウィジェットであり、画面上部に「プロキシ」「すべて」「ブロック」のような絞り込みタブがあるビルドなら、その状態でグループリストが別物に読み替わっていないかチェックしましょう。ここでの誤操作はレイテンシ計測の対象リストそのものも狭めてしまい、「全部タイムアウト」への誤解を増幅させます。UWP アプリ／Microsoft Store アプリなどはシステムプロキシ非対応のままだったりすると、CfW が正常でも通信経路だけが読み込まれなかったり別アダプタへ流れたりすることがあり、この場合モード問題ではなく下流の適用問題です。細かくは TUN とドライバ周りになりますが、まず本章で述べたモードレイヤーを固め、そのうえで上級トピックとして TUN の詳解 へジャンプすると迷子になりにくいです。

General：システムプロキシと Mixed Port で日常運用を固める

General で触る項目のうち読者への影響が大きいのは System Proxy（システムプロキシ） と Mixed Port です。System Proxy をオンにすると、Edge や Chromium ベースブラウザの「プロキシを自動検出」や「システム既定を利用」設定と素直につながりやすく、日常のウェブ閲覧では最初にここへ寄せます。ポート番号はインストーラーや競合サービスとの兼ね合いで変えるため、画面上の実際の値（例：7890 のような桁）だけを自分の環境としてメモしましょう。別アプリ側でポートを明示指定するワークフローではその数字を転記するとシステム側のウィンドウをあまり開かずに済みます。競合ポートの典型は別記事でも触れている Mixed Port 競合 なので、起動ログにポート占有が出ていたらリンク先の流れへ移るのが効率的です。

Allow LAN（LAN アクセス） をオンにすると、同一 LAN 上の端末へプロキシ待受ポートを開けやすくなる機能もあります。家庭ネットワーク内の開発やテストだけでなく、ゲストの端末に一時的に代理を経由させたいケースにも使われますが、誤った公開経路になりかねないため不要なときはオフ運用したほうが安全です。UAC やサービスログオンが絡んだときは CfW が管理者権限を要求するウィンドウを出しますが、そのたびに安易に承認しないで、自分が今どの機能をオンにしているのかだけを頭に繰り返すクセをつけてください。また企業環境では グループポリシー によりシステムプロキシの書き換え自体がロックされている場合があります。許可されていないときに回避しようとするのではなく、申請側から整えるしかありませんので、読者のみなさんにはそこだけは強く伝えます。

ブラウザと Connections で最終確認する

グループ変更とモード変更、システムプロキシのオンオフまで一通り済ませたら、最後はConnections 相当で実際に流れたドメイン名と上流チェーンが想定どおりかをスクロールしながら確認します。この一覧はテストサイトを開いた直後だけが活性化するログではなく、ほかの自動更新アプリにも反応することがあるので、一度スナップショットのように頭に入れたあと時間をおいて増えた項目だけを読む運用になると読み間違いが減ります。並びを見ていたら自分が触ったはずがない親グループ経由で表示されるときは、アプリ側の自動選択が再評価したサインだったり、アクティブなプロファイル自体がユーザー操作以外で切り替わったときのヒントだったりすることがあります。ブラウザはシークレットウィンドウを開いたうえで外部サイトだけを順に読み込み、アプリ側の広告フィルター拡張を一時的に無効にしてログを汚さないと切り分けが早くなります。

CfW と外部 VPN を同時常駐させているときは一覧の親子関係だけでは足りず、Wi‑Fi プロパティのプロキシ欄にも目を通してください。ウィンドウ側でオフでもレジストリ残りだけが残っている例はそれなりにあるので、この段階で一度 OS の設定ページを読み込み直せば「クリーンな Rule 状態」へ戻しやすいです。問題が再現しないときだけ Global を短時間オンにして同じサイトを読み込み、その差からルール評価のどの段が怪しいか追うという逆算も有効です。ここまで来ると CfW が提供するだけの GUI で足りなくなり気味なので、将来的には継続的にメンテナンスされているクライアントを選び、そのクライアントならフィルターとログ読み込み軸が同じ画面上で揃う方が総コストとして安いという判断にもつながります。

よくある質問

Q. レイテンシ一括チェックだけ全部タイムアウトになります。
 A. 計測先 URL が社内検閲で遮断されていないか、または親グループ側で自動的にダイレクト判定へ落ちてテスト自体が機能していないことを疑ってください。Global へ載せ換えて同じチェックだけを単体で試してください。親の状態が怪しいときはブラウザで任意のサイトを開いたうえで再度試すと正常化することがあります。

Q. Proxies で固定したノードが Connections に反映されません。
 A. そのノードより上位の親 URL-Test がすぐ読み換えているパターンが典型です。また自動プロファイル選択が別ウィンドウで切り替わっているとリストが読み換わりますので、画面上部の構成名だけを確認し直してください。必要な場合は親ではなく自分用の Selector を新設した YAML で改善できます。

Q. Rule にいるつもりが一部アプリだけ直進します。
 A. アプリ側が独自のプロキシや DNS を持っているかどうかを疑います。ストアアプリほど System Proxy と相性問題が見えやすいので、このケースだけ TUN やプロセス別経路まで踏む必要があります。とはいえ本稿ではまず CfW の基本 GUI の範囲に留めるのが順序です。

Q. CfW と新しいブラウザ版の自動更新が競合しました。
 A. CfW が OS のプロキシレジストリを握ったままシャットダウンされずに残っていると、アップデート直後のみ通信がぶらぶらすることがあります。タスクトレイから完全終了し、ブラウザを再起動し、続けて System Proxy をワンセットでオンオフすると正常化することが多いです。深刻なときは競合サービス一覧を洗います。

⚠ コンプライアンス：学校・会社・公共のネットワークでプロキシやトンネルが明示的に禁止されている場合、手順自体を転用しないでください。本稿は同意のある環境での診断と安全な自分用運用のみを対象とします。

まとめ

Windows 11 と Clash for Windows の組み合わせでは、日常の体感はおよそプロファイル適用確認 → Proxies でのレイテンシ一括計測と手動グループ運用 → Rule と Global と Direct を短時間だけ切り替える判断 → General のシステムプロキシとの整合 → Connections で親子チェーンの再確認、という流れになります。この順番を頭のチェックリストにすると「数字は良さそうなのにつながらない」「モードだけ切り替えたのに挙動が変わらない」といった齟齬をかなり早く分解できます。また購読の自動生成仕様との住み分けがあるので URL-Test と Selector が二段にあるケースだけは何度でも YAML のイメージに立ち返るのが実務では安全です。このあたりの概念を文章ベースでもう一段深めるなら前述のグループ説明ページが役に立ちます。

CfW が更新停止気味だったり特定ビルドに依存し続ける状況は、見た目の懐かしさの裏側でセキュリティ修正の遅延やログ表示の粒度不足として跳ね返りやすく、結局グループ単位での切り分けに時間を取られがちです。さらに CfW と後継ブランドが混線した検索結果のなかでは、画面上の名前が異なるだけで同じ機能がどこにあるのか検索コストだけが増えます。結果として「GUI で迷わなくなったときに初めて快適になる」ワークフロー設計でも、プラットフォーム側の選択は軽視できません。こうした視点での比較は 選択肢一覧 の記事側に詳しくあるので、この記事だけで CfW が向いているかどうかの最終判断も兼ねられるはずです。

Clash V.CORE は、サイト側で入手経路を揃えやすく、長期的に検証済みコンポーネントへ載せ換えやすい形でレイテンシ計測とプロキシグループ切り替え、そしてログの粒度をひとつのデスクトップ画面に収められるよう設計思想が寄っている製品側の提案です。CfW のレガシー実行ファイルだけにロックされるリスクや、画面上の名前揺れに振り回される時間を確実に減らせるなら、「同じワークフローを現行ブランチ側へ移す」のは合理的です。機能差を見極めたうえで、まずは ダウンロードページ から自身の構成に適したビルドを確認し、試験環境で一度だけセットアップ手順全体を並べ替えると、その後の日々の切り替え負荷はかなり下がります。