システムプロキシとTUNの違い｜アプリがプロキシを使わない原因と対処法 | Clash Hub

まず整理：通信の取り込みと出口の選択は別の話

ブラウザーではWebページを開けるのに、ゲームは接続できない。Clashを「全プロキシ」に切り替えても、ターミナルからのダウンロードは直接接続のまま。こうした場合、ボタンの不具合ではなく、通信がプロキシのコアに届いていない可能性があります。まず「通信が取り込まれているか」、次に「取り込まれた通信がどのルールを通るか」を確認しましょう。

システムプロキシとTUN：アプリの通信をコアに取り込む方法を決めます。
ルール、全プロキシ、DIRECT：コアが受け取った通信の出口を決めます。
プロキシグループとノード：最終的に使うプロキシサーバー、または宛先への直接接続を決めます。

つまり、TUNを有効にしても、すべての通信がプロキシ経由になるわけではありません。TUNで取り込んだ通信も、ルールが DIRECT なら直接接続されます。逆に「全プロキシ」に切り替えただけでは、システムプロキシを無視するアプリの通信は取り込めません。

システムプロキシ：アプリがローカルポートに通信を渡す

HTTP・HTTPSリクエストがClashに届く仕組み

クライアントで「システムプロキシ」を有効にすると、通常はOSのプロキシ設定が変更され、その設定に対応したアプリがローカルのプロキシポートに接続します。流れを簡略化すると、アプリ → 127.0.0.1:7890 → コアでルールを照合 → 直接接続またはプロキシ経由、となります。

HTTPリクエストはHTTPプロキシ経由で転送できます。HTTPSでは通常、まず CONNECT でトンネルを確立し、その中でTLS通信を行います。通常のHTTPSプロキシトンネルに復号証明書は不要です。システムプロキシを有効にしただけで、Clashが暗号化されたWebページの本文を読み取ることもありません。

システムプロキシが効かないアプリがある理由

システムプロキシはアプリが参照する設定であり、すべてのネットワーク通信を強制的に切り替える機能ではありません。ブラウザーはこの設定を参照する場合もあれば、拡張機能や独自のプロキシ設定を使う場合もあります。コマンドラインツールは環境変数や個別設定を参照することが多く、ゲームはTCPやUDPで直接接続することもよくあります。

Windows：「設定」→「ネットワークとインターネット」→「プロキシ」でユーザーのプロキシ設定を確認できます。一部のサービスは独立したWinHTTP設定を使うため、ここに表示される状態だけでは判断できません。
macOS：「システム設定」→「ネットワーク」→使用中のネットワークサービス→「詳細」→「プロキシ」で確認します。ネットワークサービスごとに設定が異なる場合があります。
Linux：デスクトップ環境のプロキシ設定、Shellの環境変数、アプリ独自の設定は連動しない場合があります。それぞれ個別に確認してください。

システムプロキシは変更範囲が小さく、アプリごとに原因を調べやすいのが利点です。普段使うのがブラウザーやプロキシ対応の開発ツールだけなら、まずはこちらを試すと問題を切り分けやすくなります。

TUNモード：仮想NICでIPパケットを受け取る

TUNはレイヤー3の仮想ネットワークインターフェースです。TUNに対応したコアは、OSのルーティングを利用して、取り込み対象のIPパケットを仮想NICに送り、通信を識別してルールエンジンに渡します。アプリ側でHTTPやSOCKSのプロキシプロトコルに対応する必要はありません。

ただし、前提があります。パケットが実際にTUNインターフェースへルーティングされている必要があります。自動ルーティング、除外するネットワーク、インターフェースのバインド、ほかのVPNのルート優先度などによって対象範囲は変わります。「TUNを有効にしたから、すべてのプロセスやインターフェースの通信が必ず取り込まれる」とは限りません。

比較項目	システムプロキシ	TUNモード
アプリ側の対応	アプリがシステムプロキシを参照するか、プロキシを手動で設定する必要がある	通常、アプリがプロキシプロトコルに対応している必要はない
主な接続先	ローカルのHTTP、SOCKSなどの待ち受けポート	仮想NICとOSのルーティング
UDP通信	通常のHTTPシステムプロキシでは取り込めない。SOCKS5でもアプリ側のUDP転送対応が必要	ルーティングされたUDPを受信可能。出口側もUDPに対応している必要がある
必要な権限	通常、現在のユーザーのプロキシ設定を変更するだけでよい	通常、サービスモードや管理者権限、ネットワーク管理権限が必要
よくある問題	アプリが設定を無視する、ポート番号の誤り、プロキシ設定が残っている	ルートの競合、DNSの異常、権限不足、出口がUDPに非対応

mihomoの設定項目の見方

Clashはクライアントやコアのエコシステムを指す一般的な呼称で、Clash Metaは後継のmihomoとして開発が続いています。コアによって機能は異なります。以下はmihomoのTUN設定例です。各項目の関係を示すものであり、既存の設定全体を置き換えるためのものではありません。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

enable：TUNを有効にします。ただし、OS側で必要な権限を満たす必要があります。
stack：プロトコルスタックの実装を選びます。mihomoには system、gvisor、mixed などがあります。実際に利用できる選択肢は使用中のコアによって異なり、すべてのデバイスで最速の方式はありません。
auto-route：通信を取り込むためのルートを自動で追加します。ルートの例外がすべて無視されるわけではありません。
auto-detect-interface：送信インターフェースを自動検出します。会社のVPNを同時に使用する場合は、実際の出口も確認してください。
dns-hijack：ここでの any:53 は、対象となるUDP 53番ポートのDNSリクエストを取り込みます。リクエストが該当する経路に入っていることが前提です。

デスクトップクライアントでは、画面上の設定からこれらの項目が生成されることがあります。また、サブスクリプションの更新で手動変更が上書きされる場合もあります。クライアントのTUN設定や設定オーバーライド、マージ機能を優先して使い、最終的に適用された設定を確認してください。

DNSの違い：Web通信がプロキシ経由でも、名前解決が同じ経路とは限らない

システムプロキシ使用時、ドメイン名はどこで解決される？

DNSの処理はアプリとプロキシプロトコルによって異なります。HTTPSの CONNECT では宛先のドメイン名を渡し、プロキシ側で処理できます。一方、アプリが先にシステムDNSを呼び出す場合もあります。SOCKS5もドメイン名を渡す方法と、名前解決済みのIPアドレスを渡す方法があり、どちらになるかはアプリの実装次第です。

同じSOCKS5ポートでも、コマンドラインから socks5:// と socks5h:// でテストすると結果が異なることがあります。curlでは後者を使うと、宛先ドメイン名の解決をプロキシ側に任せます。外部から見えるIPアドレスが変わっただけで、すべてのDNSリクエストがClashを経由したとは判断できません。

TUNのDNSハイジャックとFake-IPは別の設定

DNSハイジャックは、対象となるDNSリクエストをコアのDNSモジュールに渡す機能です。一方、Fake-IPは応答方式の一つで、まずアプリに対応するIPアドレスを返し、その後の接続をコアが元のドメイン名に対応付けます。mihomoでよく使われるFake-IPアドレスプールは 198.18.0.1/16 ですが、実際の値は設定によります。これはプロキシサーバーのグローバルIPアドレスではありません。

前述のDNS取り込み設定を使う場合は、既存の dns.enable、上流DNSサーバー、関連ルートも確認し、DNSモジュールが無効になっていないか確かめてください。
any:53 を設定しても、ブラウザーのDoHが自動的に復号されるわけではありません。また、TLSで暗号化されたDoTのリクエストが通常のDNSとして扱われることもありません。
ドメインルールを適用するには、コアがドメイン名を把握している必要があります。宛先IPアドレスしか確認できない場合、ルールの判定結果が想定と異なることがあります。
LAN内のデバイス検出、社内ドメイン、Fake-IPに対応しない特定のアプリがある場合は、DNS設定をすべて消去するのではなく、フィルターや名前解決ルールを個別に調整してください。

アプリ別の設定：ブラウザー、コマンドライン、ゲームの場合

ブラウザー：まずブラウザー独自のプロキシ設定を確認

ブラウザーは通常、まずシステムプロキシを利用できます。特定のブラウザーだけプロキシが効かない場合は、プロキシ拡張機能、個別のプロキシ設定、セキュアDNS、切り替え前に確立した接続の再利用を確認してください。Firefoxでは「設定」→「一般」→「ネットワーク設定」→「接続設定」を開き、「システムのプロキシ設定を利用する」が選択されているか確認できます。

コマンドライン：ポートを明示して再現性のあるテストを行う

以下のコマンドでは、直接接続、HTTPプロキシ、プロキシ側で名前解決するSOCKS5を比較できます。Windows PowerShellでは、古い環境で curl が別のコマンドのエイリアスとして解釈されるのを避けるため、curl.exe と入力してください。テスト先に接続できただけではプロキシの成功を証明できません。クライアントの接続履歴もあわせて確認しましょう。

curl --noproxy "*" -I --connect-timeout 10 https://example.com
curl --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 https://example.com
curl --noproxy "" --proxy socks5h://127.0.0.1:7890 -I --connect-timeout 10 https://example.com

1つ目のコマンドは明示的なプロキシを使いませんが、TUNが通信を取り込んでいればTUN経由になる場合があります。システムプロキシを検証するときは先にTUNを無効にし、TUNを検証するときは明示的なプロキシ指定を外してください。2つの経路を混同せずにテストできます。

現在のShellで、環境変数に対応するツールからプロキシを使いたい場合は、次の変数を一時的に設定します。影響するのはこれらの変数を参照するプロセスだけで、デバイス全体の通信経路が変更されるわけではありません。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1

ここで https_proxy に http:// を指定しても問題ありません。HTTPプロキシを使ってHTTPSトンネルを確立するという意味です。Git、パッケージマネージャー、コンテナツールには個別のプロキシ設定がある場合もあります。コンテナ内の 127.0.0.1 はコンテナ自身を指すため、そのままホストのアドレスとしては使えません。

ゲーム・ボイスチャット：UDPの出口を重点的に確認

ゲームのログインにはHTTPSを使い、対戦やボイスチャットにはUDPを使う場合があります。「ログインできるのにルームに入れない」ときは、Webページだけで判断できません。TUNで該当するUDPパケットを取り込めても、選択中のノード、プロキシプロトコル、サーバー、通信経路のすべてが必要なUDP転送に対応している必要があります。

プロキシを使えば必ず遅延が下がるわけではありません。ノード名より、対戦サーバーの設置地域、経由する経路、パケットロス、ジッターのほうが判断材料になります。テスト時はサーバーとノードを固定し、直接接続とプロキシ接続の結果をそれぞれ記録してください。速度測定サイトの帯域値だけでゲームの快適さを判断しないようにしましょう。

アプリがプロキシを使わない場合：接続履歴から原因を2つの経路に分ける

最小限のテスト環境を用意する。ほかのVPN、ゲーム用ネットワーク最適化ツール、プロキシ拡張機能を一時停止し、クライアントを1つだけ起動します。現在の設定を記録し、会社のネットワークを使っている場合はネットワーク管理上のルールを先に確認してください。
コアが起動しているか確認する。混合ポートが本当に 7890 か確認してください。Windowsでは netstat -ano | findstr :7890 を実行すると待ち受け状態を確認できます。ただし、ポートが使用中でも現在のクライアントが待ち受けているとは限らないため、プロセスも確認してください。
システムプロキシだけをテストする。TUNを無効にしてシステムプロキシを有効にし、ブラウザーまたは前述のプロキシ指定付きコマンドで新しい接続を開始します。同時に「接続 / Connections」と「ログ / Logs」を確認してください。
続いてTUNだけをテストする。システムプロキシを無効にし、クライアントで必要なサービスモードや管理者権限を有効にしてから、TUNをオンにします。Androidでは通常、システムのVPN許可が必要です。Linuxでは必要なネットワーク管理権限が必要になることが多く、Windowsと同じ手順は使えません。
適用ルールと実際の出口を確認する。接続履歴があり、出口が DIRECT と表示される場合は、ルールの順序、プロセスの照合、プロキシグループの選択状態を確認してください。ルールは上から順に評価されるため、想定しているルールより前のルールが先に適用されることがあります。
最後にDNSと互換性を確認する。ログに名前解決のタイムアウト、Fake-IPのマッピング異常、特定のUDP通信の失敗が記録されている場合は、該当する項目を調整してください。一度に変更するのは1項目にしましょう。

確認できる症状	優先して確認する項目
アプリを操作してもコアに該当する接続が表示されない	アプリがシステムプロキシを無視している、TUNルートの対象外、プロセスまたはインターフェースが除外されている
接続はあるが、出口がDIRECTになっている	ルールの順序、DIRECTモード、プロキシグループの現在の選択
接続はあるが、プロキシ出口がタイムアウトする	ノードへの到達性、プロトコル設定、サーバーの状態、宛先側の制限
Webは使えるが、ゲームのボイスチャットが失敗する	UDPの取り込みと転送への対応、関連ドメインの名前解決、ゲーム専用ルール
TUNを有効にすると社内ネットワークに接続できない	VPNルートの競合、社内DNS、プライベートネットワーク範囲の除外設定

短時間で終了する接続は、接続パネルに履歴が表示されないことがあります。必要に応じてログを有効にして再現してください。ログを共有する前に、サブスクリプションURL、アクセストークン、ノードの認証情報、プライベートなドメイン名を削除してください。設定ファイル全体を公開してスクリーンショットを撮るのは避けましょう。

最終的な選び方：取り込む通信を最小限にして始める

ブラウザーや一部のプロキシ対応アプリだけを使うなら、まずシステムプロキシを選びましょう。開発ツールで安定した再現性が必要な場合は、ツール独自のプロキシ設定を優先します。ゲーム、ボイスチャット、プロキシ設定を参照しないアプリの通信を取り込む必要がある場合に、TUNを検討してください。

システムプロキシとTUNは同時に有効にできます。必ずしも競合するわけではありませんが、原因を調べるときは分けてテストするのがおすすめです。ネットワークに接続できなくなっても、すぐに再インストールする必要はありません。まずTUNを無効にしてルートが戻るか確認し、次にシステムプロキシを無効にして、終了したクライアントのローカルポートがシステムに残っていないか確認してください。TUNが通信を取り込んでいるのに出口へ接続できない場合、取り込み方式を切り替えてもノード自体の問題は解決しません。

確認の順番はこれだけです。入口で通信を取り込めているか → DNSは正しいか → どのルールが適用されたか → 出口に接続できるか。この4段階に分ければ、「プロキシを有効にしても効かない」という問題を検証可能な形で切り分けられます。ルールの各項目は設定・プロトコルガイドを、初めてインストールする場合はクイックスタートガイドをご覧ください。