Clash グローバルなのにブラウザだけ通る？システムプロキシと TUN を Windows／macOS で切り分ける

なぜ「グローバル」なのにブラウザだけが通るのか

Clash や Mihomo 系クライアントで「グローバルモード」や「システムプロキシを自動設定」をオンにしたつもりなのに、Chrome や Edge ではサイトが開けるのに、Steam や特定のゲームランチャー、Windows Store 系アプリ、あるいは macOS の一部ユーティリティだけがつながらない——こうした状況は、検索でも非常に多い相談です。まず押さえておきたいのは、「グローバル」が意味するのはClash 内部のルーティング（どのノードに出すか）であり、OS 上のすべてのプロセスに対して自動的にプロキシを強制することとは別レイヤーだという点です。

多くの GUI は、ワンクリックで「システムの HTTP／HTTPS プロキシ」を Windows のインターネット設定や macOS のネットワーク設定に書き込みます。ところが、WinHTTP スタックで直接ソケットを開くゲーム、独自ネットワークライブラリを抱えるランチャー、UWP アプリのサンドボックスなどは、この「システムプロキシ設定」をそもそも参照しません。結果として「ブラウザは WinINET／NSURLSession 経由で設定を見るから通るが、そのほかは直結のまま」という部分的成功に見えてしまいます。本稿では、このミスマッチを系統立てて切り分ける手順を、Windows と macOS に分けて整理します。TUN の基礎は TUN モード完全ガイド と合わせて読むと理解が早くなります。

よくある誤解：グローバル＝すべてのアプリが代理経由

設定画面の「Global」は、Clash が名前解決と接続先選定をどのポリシーで行うかを指すことがほとんどです。すでにアプリから Clash のリスニングポートへトラフィックが届いていれば、その時点でグローバルグループのノードが使われます。一方、そもそもアプリのパケットが Clash に入ってこない場合は、どれだけ GLOBAL でも効果はありません。切り分けの第一段階は、「出口ルールの問題」ではなく「トラフィックが Clash に乗っているか」です。

第二に、システムプロキシはあくまで OS が提供する「既定のプロキシ情報」であり、アプリがそれを読むかどうかは実装依存です。Unix 系のターミナルが環境変数 HTTPS_PROXY を見る／見ない問題と本質は同じです。TUN モードは仮想インターフェースとルーティングでトラフィックを取り込むため、「システムプロキシを読まないタイプ」にも届きやすくなりますが、その代わり権限・競合 VPN・DNS の取り扱いという別の課題が乗ります。

システムプロキシがカバーする範囲と限界

Windows では従来、WinINET を利用するアプリがユーザーの「LAN の設定」のプロキシを参照しやすい一方、WinHTTP を直接使うサービス系や一部のゲームは、別の手順でプロキシを設定するか、そもそも直結です。macOS でも、システム環境設定に書かれた Web プロキシを自動で使うのは、NSURLSession や一部フレームワーク経由のアプリに限られ、サンドボックス外の常駐ツールや古いネイティブ向け API だけでは不十分なことがあります。

したがって症状が「ブラウザだけ快適・特定のデスクトップ製品だけおかしい」のとき、まず疑うべきはルール不足ではなく、経路が Clash に乗っていないことです。ここで必要になるのが、次節以降の OS 固有要因と、必要に応じた TUN への移行判断です。

Windows での段階的チェック項目

ステップ 1：本当にシステムプロキシが有効か

設定アプリの「ネットワークとインターネット」→「プロキシ」あるいは「インターネット オプション」を開き、Clash が書き込んだアドレス（多くの場合 127.0.0.1 と mixed または HTTP ポート）が実際にオンになっているか確認します。別プロファイルの VPN クライアントや企業ポリシーが上書きしていると、GUI ではオンに見えて OS 側がオフ、ということもあります。

ステップ 2：UWP と「localhost の壁」

Microsoft Store から入れた UWP／Microsoft Store アプリは、セキュリティモデル上、ループバック（同一マシン上のローカルサーバー）への接続がデフォルトで制限されることがあります。Clash が 127.0.0.1 で待ち受けている典型構成では、ブラウザ（デスクトップ版）は問題なくても、UWP 側だけ接続できない、という片側不通が起き得ます。開発者向けにはチェックコマンドでアプリごとのループバック許可を切り替える方法が案内されていますが、一般利用では「該当アプリが UWP かどうか」を見極め、システムプロキシではなく TUN で外向きのトラフィックをまとめて取り込むほうが早いケースもあります。

ステップ 3：権限とサービス／TUN ドライバ

TUN モードや WFP／パケットフィルタに相当する機能を使うクライアントでは、管理者権限やサービスとして登録されたコアが前提のことがあります。権限不足だと TUN インターフェースの作成が失敗し、結果としてシステムプロキシだけ残り「ブラウザは通るが取り込みは弱い」状態になります。Clash Verge Rev などのサービスモード有無も併せて、公式ドキュメントに沿って確認してください。Clash Verge Rev のチュートリアルは、GUI と権限まわりの対応付けに便利です。

ステップ 4：DNS がルールの外で解決していないか

システムプロキシ経由でも、名前解決だけが ISP 側へ出てしまうと、挙動が「一部アプリだけおかしい」に見えることがあります。Fake-IP や DNS ハイジャックの設定は TUN 運用とセットで語られることが多く、詳細は前述の TUN ガイドや Clash の dns セクション解説に譲りますが、Windows では「プロキシは通っているつもりで DoH をブラウザだけが使っている」といった差分にも注意してください。

macOS での段階的チェック項目

ステップ 1：ネットワーク設定の「自動プロキシ構成」

システム設定のネットワークから、使用中のインターフェース（Wi-Fi 等）を開き、プロキシの各トグルとアドレスが Clash の指示どおりか確認します。プロファイルや MDM が別値を押し付けている環境では、ユーザーが GUI で保存してもすぐ戻されることがあります。

ステップ 2：ネットワーク拡張とシステム拡張の承認

TUN モードやパケットフィルタを使う macOS クライアントは、「ネットワーク拡張」やシステム拡張（System Extension）の許可、場合によっては再起動やセキュリティ設定からの手動承認が必要です。ここが未完だと、システムプロキシだけは動き、カーネル近くまで届かないトラフィックが残る、というギャップが生じます。Apple Silicon と Intel で手順が微妙に異なる場合があるため、利用中のアプリの macOS 向け README を一度通してください。

ステップ 3：別 VPN・iCloud プライベートリレーとの競合

複数の「仮想インターフェース＋ルート差し替え」を同時に有効にすると、優先度によって意図しない直結や逆に全不通が起きます。切り分けのときは、一時的に他方をオフにし、ルートテーブルとログを見ながら最小構成に戻すのが実務的です。

TUN を選ぶべきタイミング

まとめると、次のいずれかに当てはまるならシステムプロキシだけに固執せず、TUN（または OS が要求する VPN プロファイルに相当するモード）を検討する価値が高いです。(1) プロキシ非対応のゲームやランチャーが対象、(2) UWP／サンドボックスアプリで localhost が使えない、(3) UDP や QUIC を含むフローをルールの下に置きたい、(4) DNS の取り込みを一貫させたい。逆に、ブラウザ中心の短時間利用で権限ダイアログを避けたい場合は、システムプロキシのままでも十分なことは多いです。

TUN を有効化したうえで出口がおかしいときは、GUI のモードが GLOBAL か RULE か、そのルールが期待どおりマッチしているか、を続けて確認します。分流の書き方自体は ルール分流ガイド の考え方と直結します。

実務向けチェックリスト（どちらの OS でも共通）

1. Clash のログで、問題のアプリ通信が一度でもコアに入っているか（入っていなければ経路の問題）。
2. ファイアウォールが Clash の実行ファイルや仮想 NIC をブロックしていないか。
3. 別の VPN／フィルタ製品が常駐していないか。
4. ゲームやランチャーが独自のプロキシ設定欄を持たないか（あれば手動で 127.0.0.1 とポートを指定する選択肢）。
5. TUN 使用時は DNS（Fake-IP／hijack） がルールと整合しているか。

オープンソース情報とパッケージの入手

Mihomo／Clash 系の挙動や Issue はオープンソースのリポジトリで追えます。一方、日々利用するクライアントの入手と更新は、説明が一貫している配布元のページを使うと、バージョンや署名の取り違えを防ぎやすくなります。設定の全体像は チュートリアル・ドキュメント も参照してください。

まとめ

「グローバルやシステムプロキシをオンにしたのに、ブラウザだけが通る」現象は、多くの場合Clash のルールの誤りではなく、OS とアプリのスタックの差が原因です。Windows では UWP のループバック制限や WinHTTP 系の直結、macOS ではネットワーク拡張の未承認や別 VPN との競合を、それぞれ疑うと切り分けが速くなります。必要なら TUN モードでトラフィックを先に取り込み、そのうえでグローバル／ルールを調整する流れが現実的です。

同種のツールのなかでも、Clash／Mihomo はルール表現と可視性のバランスに優れ、システムプロキシと TUN を併用する運用設計がしやすいのが強みです。環境に合ったビルドは ダウンロードページで一覧できるため、まずは公式に近い導線でクライアントを揃え、本稿の順に症状を切り分けてみてください。シンプルなプロキシ専用ツールよりも、長期的な安定性とトラブル時の追いやすさでは体験が大きく変わりやすいものです。→ Clash クライアントを無料でダウンロードし、接続経路を思い通りに整える