Clash TUNモードとシステムプロキシの仕組みを比較

システムプロキシの仕組み：アプリ側が設定を読み取る

システムプロキシ（System Proxy）はOSが提供する標準的なインターフェースで、Windowsの「ネットワークとインターネット-プロキシ」、macOSの「システム設定-ネットワーク-プロキシ」がこの層に該当します。Clashクライアントでシステムプロキシを有効にすると、実際にはシステムのHTTP/HTTPSプロキシアドレスをローカルの127.0.0.1:7890（ポート番号は実際の設定に依存）に書き換え、レジストリやシステム設定ファイルに反映する処理が行われます。

ポイントは、これはあくまで「推奨設定」であり、実際に反映されるかどうかは各アプリケーションがこの設定を読み取るかどうかに完全に依存するという点です。ブラウザや大半のGUIソフトはシステムプロキシ設定を自動的にチェックして従うため、ブラウジングでは即座にプロキシが効きます。しかし、システムプロキシに従わないプログラムも少なくありません。例えば：

• システムのネットワークライブラリを使わず独自のネットワークスタックを実装したコマンドラインツール（Goで静的コンパイルされたCLIツールなど）。
• ゲームクライアント。特にUDPプロトコルでリアルタイム同期を行うゲームは、多くのゲームエンジンがシステムプロキシのインターフェースを経由しません。
• バックグラウンド更新サービス、ドライバ、システムレベルのコンポーネント。これらのプロセスはより高い権限や独立したネットワークコンテキストで動作していることが多いです。
• 一部のElectronアプリも、プロキシ環境変数を明示的に読み取っていない場合はシステムプロキシを経由しないことがあります。

つまりシステムプロキシは「アプリケーション層での紳士協定」であり、Clashがアドレスを設定した後、実際に従うかどうかはアプリケーション側の判断に委ねられます。これが「クライアントは接続済み、ブラウザは問題なくネットにつながるのに、特定のソフトだけつながらない」という報告が多い理由です。本質的にはそのソフトがシステムプロキシを経由していないだけです。

TUNモードの仕組み：仮想ネットワークアダプタがネットワーク層を制御

TUNモード（Clash Meta / mihomoコアではTun Modeとも呼ばれます）は完全に異なる方式を採用しています。有効化すると、クライアントはシステム内に仮想ネットワークインターフェース（仮想ネットワークアダプタ）を作成し、ローカルのルーティングテーブルを変更することで、通信をネットワーク層（IP層）でこの仮想ネットワークアダプタに誘導し、Clashコアが受信・解析してルールに従って転送します。

傍受がアプリケーション層ではなくルーティング層で行われるため、通信がプロキシ経由になるかどうかは特定のプログラムがプロキシプロトコルをサポートしているかどうかに依存しなくなります。そのプロセスがIPパケットを生成してシステムのネットワークスタックに渡す限り、仮想ネットワークアダプタによって捕捉されます。これは以下を意味します：

• システムプロキシ設定を認識しないCLIツールも、TUNモードでは制御対象になります。
• 大半のゲームのUDP通信も、TUNモードで制御対象になります（実際の効果はゲームが使う通信方式やIPv6を使用しているかどうかにも関係します）。
• システムのバックグラウンドサービスやブラウザ以外のプロセスからの通信も、同様に仮想ネットワークアダプタを経由します。

システムプロキシは「入口に案内を貼り、入ってくる人が自主的に検査に協力する」ようなものだとすれば、TUNモードは「入口を必ず通る検査ゲートに変え、出入りする全員が検査される」ようなものだと考えると分かりやすいでしょう。前者は相手の協力に依存し、後者は依存しません。

TUNモードの主な設定項目

mihomoコアの設定ファイルでは、TUNモードの主な項目はおおむね以下のようになります（YAMLの例として示しています。実際のフィールド名は使用するクライアントの設定構造に依存します）：

tun:
  enable: true
  stack: system     # または gvisor / mixed、仮想ネットワークアダプタの実装方式を決定
  dns-hijack:
    - any:53
  auto-route: true   # システムのルーティングテーブルを自動的に制御
  auto-detect-interface: true

auto-routeはルーティングテーブルを自動的に変更するかどうかを決定し、dns-hijackはDNSクエリも合わせてClash内部での解決に横取りするかどうかを決定します。これはfake-ipなどのDNS処理機構と組み合わせて使うことで、一部のアプリがプロキシを迂回して直接DNSリクエストを送るのを防げます。

2つのモードの違いを比較

重要な違いを表にまとめ、直接比較できるようにしました。

コマンドラインツールとゲームでどちらを選ぶか

上記の仕組みの違いを踏まえると、比較的明確な判断基準を導き出せます。

コマンドラインツールの場合

普段ターミナルで使うパッケージマネージャー、バージョン管理ツール、スクリプトのリクエストライブラリを使う場合、まずHTTP_PROXY / HTTPS_PROXY環境変数を読み取れるかどうかを確認してください。対応している場合は、システムプロキシを有効にして環境変数を設定すれば通常はそれで十分で、追加でTUNモードを有効にする必要はありません。ツールが明らかにプロキシ環境変数に対応していないのにネット接続が必要な場合にのみ、フォールバック手段としてTUNモードの有効化を検討します。

# 現在のターミナルセッションに一時的にプロキシ環境変数を設定する（ポート番号は実際の設定に合わせてください）
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

ゲームの場合

ゲームクライアントの大半はシステムプロキシ設定を読み取りません。特に独自のネットワークプロトコルやUDPで直接サーバーに接続するゲームでは、システムプロキシはほとんど効果がなく、ネットワーク層で強制的に制御するTUNモードに頼る必要があります。TUNモードを有効にした後は、クライアントのルールでゲーム関連のドメインやIPレンジ用に専用のポリシーグループを設定することをおすすめします。ゲームの通信を他の通信と同じノードに混在させて遅延の変動を招くのを避けられます。

日常的な閲覧・作業の場合

主にブラウザでのネット利用、動画視聴、システムプロキシに従う数個のデスクトップアプリだけを使う場合は、システムプロキシモードで十分であり、追加でTUNモードを有効にする必要はありません。TUNモードは対象範囲が広い一方、より高い権限が必要でルーティングテーブルへの変更も大きく、異常が発生した際の調査コストも高くなります。「機能は強力だが負荷も大きい」方式なので、必要に応じて有効にすれば十分です。

モード切り替え時によくある問題

TUNモードを有効にした後、完全にネットに繋がらない

多くの場合、権限不足で仮想ネットワークアダプタの作成に失敗しているか、他のネットワークツール（一部のVPNクライアントなど）がルーティングテーブルを同時に占有して衝突が起きています。まず同様にルーティングテーブルを変更する他のネットワークツールを終了し、管理者/root権限でClashクライアントを再起動してみてください。

TUNモードを有効にした後、一部のサイトへのアクセスがおかしい

通常はDNSハイジャックや振り分けルールに関係しています。dns-hijackの設定や、直接接続すべきドメインが誤ってプロキシノードにルーティングされていないかを確認してください。

システムプロキシは有効なのに特定のソフトだけ直接接続している

これは記事の冒頭で説明した通常の現象で、そのソフトがシステムプロキシ設定を読み取っていないためです。解決策としては、そのソフト専用にプロキシ環境変数を設定するか、TUNモードに切り替えるかのいずれかです。

2つのモードを同時に有効化できるか

技術的には同時に有効化できますが、あまり意味はありません。TUNモードがすでにネットワーク層でほとんどの通信を制御しているため、システムプロキシの働きは上書きされたり冗長な判定を生んだりします。一般的には場面ごとにどちらか一方を選び、トラブル調査時の変数を減らすことをおすすめします。