なぜ「二重代理」になるのか：TUN・システム代理・拡張の層

ネットワーク周りのトラブルは、どの層でパケットが拾われるかの誤解から起こりがちです。TUN モードを有効にしていると、多くのクライアントはカーネル近傍で流れを掴み、アプリの「OS に設定したプロキシ」以前に整流化できます。一方、GUI の「システムプロキシを ON にする」オプションは、Windows／macOS の システムの HTTP/HTTPS プロキシ欄を Clash の mixed-port 等に向けます。ここでブラウザ拡張の SwitchyOmega を 直接接続 相当にせず、PROXY 127.0.0.1:7890 のようにローカル待受へ二段目を挿し込むと、すでに TUN や OS 層で Clash の口を通したあと、同じ 7890 へ再度送るイメージになり、帯域・遅延・挙動が読みづらくなります。クライアントの選び方は 全プラットフォーム比較と合わせ、GUI が「TUN 時はシステム代理を外す」等の挙動を持つかを押さえておくと迷いにくいです。

まとめると、原則は「上が握っている層の数を増やしすぎない」ことです。TUN で全体を一括、あるいはシステム代理だけ、のどちらかを主にし、拡張は「OS の設定に従う」か、拡張の完全バイパスのどちらかに寄せるのが安全寄りの運用です。ルールの微調整は、二重化を直したルール分流の考え方のあとに回すと、切り分けの線が通ります。

想定される症状：くるくる、localhost、ルータ画面が壊れる等

典型的には、特定のサイトだけが無限に読み込み、192.168.x.1 の ルーター設定画面や 127.0.0.1 系の ローカル開発用 URL まで不自然に遅延する、といったパターンです。拡張のプロファイルを「すべてのリクエストを同じ PROXY へ」のように雑に当てると、本来 DIRECT にしたい帯域まで同じ中継に回り、Clash 側のルールと衝突します。macOS 上の TUN とシステム拡張・プロキシの切り分けは、OS のプロキシ欄と拡張の上書きの二重性を意識すると整理しやすいです。ノード遠隔側の不調は、症状が似ても層が異なるため、接続ログの timeout／TLS の話と取り違えないでください（まず拡張をオフ、または直結を外す一手が早いかを試すのが有効です）。

SwitchyOmega 側：Auto／システムプロキシ／直結の切り替え

まず取る行動

  1. 拡張のポップアップで、いったん 「システム プロキシ」 相当のシナリオ（名称はバージョンで「System Proxy」等）に切り替える。これでOS が指している口（Clash の mixed-port 等）にブラウザが従います。
  2. 従来 127.0.0.1:7890 を直書きしたシナリオ（例：proxy プロファイル）に依存しているなら、Auto Switch 内のデフォルトを「システム追従」に寄せるか、一時的に拡張を無効化して挙動を比較します。
  3. 企業内プロキシや PAC を使う職域では、Clash 側の分岐と Omega の 条件リストが二重に当たることがあります。IT 方針に従い、どちらか片方に寄せるのが望ましいです。

Firefox は Chrome 系と拡張 API の差があり、同じ「システムに従う」でも見え方が違う場合があります。他ブラウザ専用の拡張を複数同時に有効化していると、条件が衝突することもあるため、不調時は一つずつオフして当たりを付けます。WebRTC や真 IP 露出の話は、プロキシ二重化とは別軸の検証が必要な場面もあるため、WebRTC 漏れの検証手順を参照してください。

ループ（loopback）型の起き方と止め方

「ループ」でよく起きるのは、プロキシの出口がまた自分を指し、同じ 127.0.0.1:ポート へ戻る設計誤りです。Clash クライアントの「システム代理を設定」で OS は 127.0.0.1:7890 へ向いているのに、拡張も同じ 7890 へ さらに 送る、あるいは Clash 自身の仮想インタフェース上の扱いと帰り路が噛み合わない、といったケースです。疑わしければ、拡張を切る → 直結行を外すの順で挙動が戻るかを見てください。TUN 終了やアプリ退出後の「ネットに繋がらない」系は、システムプロキシの残りと混同しやすいため、今どの層のプロキシ欄が残っているかを OS 設定から併せて確認します。

⚠ 注意：loopback 上の中継をいじる設定は、誤ると一時的にブラウザ全体が不達になります。作業中のタブを退避し、拡張の無効化から入り、OS のプロキシ欄は Clash 公式 UI の導線に任せるのが安全です。

OS の「システムプロキシ」表記の確認手順

Windows 11 では「設定」→「ネットワークとインターネット」→「プロキシ」で、手動の HTTP/HTTPS/スクリプト欄に 127.0.0.1 や localhost が出ているかを確認します。Clash クライアントの「システム プロキシ」トグルと中身の数値が食い違っていないか併せて見てください（Verge 系の初回導入と併せて読むと、トレイからの一括制御のイメージが掴みやすいです）。

macOS では、該当するプロファイルの「詳細…」のプロキシ、または従来の「ネットワーク」環境設定で同様に確認します。TUN 利用時に「システム拡張」や承認周りを疑う局面は、承認とプロキシ衝突の記事と地続きの話題です。どちらの OS でも、拡張が OS の欄を上書きしていないか（別ツールの「VPN」スライダー等）を一度棚卸しします。

TUN 利用時：ブラウザだけ別ルールにしない

TUN で全体を一まとめに扱う設計のとき、ブラウザだけを Omega で別の出口に飛ばすと、DNS や仮想 IF の一貫性が崩れ、Fake-IP や国内直の例外が想定通り当たりません。分岐は Clash 側の ルールに寄せ、ブラウザ拡張は 透明（システム従属）にするか、完全に拡張オフに近い形がおすすめです。WSL2 や Docker から同じ口を奪い合うケースと似て、入口が複数であるほど帯域図が読みづらくなる点は、mixed-port 利用の整理の考え方と通じます。

まとめ

Clash を TUN や システム代理で動かしている際に SwitchyOmega を併用すると、二重代理 や loopback まわりの不整合で「くるくる」が出ることがあります。まず拡張を システム プロキシ追従に寄せるか一時的に 無効化し、OS のプロキシ欄が Clash の想定口と揃うかを確認するのが最も手早い実測です。TUN 利用時はブラウザだけ別出口に飛ばさず、ルールをコア側に集約すると安定しやすいです。導入と運用の全体感は、上記の他記事を線でつなぎ直すと再発が減ります。環境整備の次の一歩として、Clash を無料でダウンロードし、GUI からシステム代理と TUN の両方の状態が一目で分かるクライアントに寄せるのが実務的です。