システムプロキシとTUNの違い：通信の入口は異なっても、ルールによる振り分けは有効

ブラウザーにはアクセスできるのに、ターミナルやゲームランチャーが接続できない場合、Windowsのシステムプロキシ設定を参照していないことがよくあります。システムプロキシは 127.0.0.1:7890 のようなプロキシアドレスを提供し、利用するかどうかはアプリ側が決めます。PC上のすべての通信を自動的にClashへ転送する機能ではありません。

TUNは仮想ネットワークインターフェースを作成し、ルーティングによって条件に合うIP通信をコアへ転送します。アプリがHTTPプロキシやSOCKSプロキシに対応していなくても、通信を取り込める場合があります。この記事ではWindows 10／11と、mihomoコアを使うClashクライアントを対象に説明します。旧バージョンのClashコアでは設定項目やドライバー、画面が異なることがあるため、すべての設定をそのまま適用できるとは限りません。

比較項目システムプロキシTUN仮想NIC
通信を取り込む入口アプリがローカルのHTTPまたはSOCKSポートに接続システムルートがIP通信を仮想インターフェースへ転送
アプリ側の対応システム設定の参照、またはプロキシの手動設定が必要通常、アプリ内でのプロキシ設定は不要
UDP通信一般的なHTTPシステムプロキシでは直接取り込めない取り込み可能。ただしノードとプロトコルの対応が必要
必要な権限通常は現在のユーザー権限で設定可能インターフェース作成やルート変更には、通常、権限の昇格が必要
通信の振り分けコアに入った後、現在のモードとルールに従って処理コアに入った後も、現在のモードとルールに従って処理

事前準備：サブスクリプション、コア、ネットワークの基準状態

サブスクリプションの初回読み込み、ノード切り替え、DNS変更、TUN有効化を一度に行わないでください。まず正常に動作する状態を作っておけば、問題が起きたときに原因の範囲を切り分けやすくなります。

  1. クライアントとコアの情報を確認します。「設定」→「バージョン情報」またはクライアントのコア情報画面でバージョンを確認してください。クライアント名だけで判断せず、実際にmihomoが動作していることを確認します。
  2. サブスクリプションが使えることを確認します。設定を更新して接続可能なノードを選びます。一時的にシステムプロキシを有効にし、ブラウザーでプロキシが必要なサイトと、直接接続するサイトの両方にアクセスしてください。
  3. ローカルポートを確認します。たとえば混合ポートが 7890 の場合、これはHTTP／SOCKSの接続口です。仮想NICのポートでも、DNSの待ち受けポートでもありません。
  4. ほかのネットワーク関連ソフトを確認します。企業VPN、ゲーム用の通信最適化ツール、ほかのプロキシクライアントに加え、Hyper-V、WSL、Dockerが作成した仮想インターフェースも確認してください。
  5. 復旧手段を用意します。TUNのスイッチの場所を把握しておきます。リモートデスクトップで接続中にルートを変更する場合は、現地での操作手段や別の管理経路を確保し、接続が切れて復旧できなくなる事態を防いでください。

初回テストでは、ほかのプロキシや通信最適化ツールを終了し、必要なネットワーク接続だけを残すのがおすすめです。会社管理のデバイスでは、まずネットワークポリシーを確認してください。スイッチを有効にするために、セキュリティソフトやファイアウォール、組織で定められたアクセス制御を無効にしてはいけません。

サービスモードを導入してTUN仮想NICを有効にする

手順1：コアに必要な権限を付与する

WindowsでTUNインターフェースを作成したりルートを変更したりするには、適切な権限が必要です。一般的には、クライアント付属のバックグラウンドサービスを導入し、権限昇格が必要な処理をサービスに実行させます。サービスモードが解決するのは実行権限とバックグラウンド管理の問題であり、ノードの品質を改善したり、TUNを自動で有効にしたりするものではありません。

  1. クライアントの「設定」を開き、「サービスモード」「Service Mode」または「Clash サービス」を探します。クライアントによっては「設定」→「Clash設定」にあります。メニュー名や場所は使用中のバージョンに表示される内容を確認してください。
  2. 「インストール」または「サービスをインストール」をクリックし、Windowsのユーザーアカウント制御の確認に応じます。インストール中はクライアントの配置フォルダーを移動しないでください。
  3. 画面に「インストール済み」または「実行中」と表示されるまで待ちます。コアやクライアントの再起動を求められた場合は、設定を保存してから再起動してください。
  4. インストールに失敗した場合は、まずインストールログとセキュリティソフトの記録を確認します。管理者として一時的に起動すれば権限の問題か切り分けられますが、出所不明のドライバーパッケージを何度もインストールしないでください。

サービスの状態を補助的に確認するには、PowerShellで以下の読み取り専用コマンドを実行できます。クライアントごとにサービス名が異なるため、検索結果は手がかりとして扱い、最終的にはクライアントのログやサービス実行ファイルのパスと照合してください。

Get-Service | Where-Object {
  $_.Name -match 'clash|mihomo|verge' -or
  $_.DisplayName -match 'clash|mihomo|verge'
} | Format-Table Status, Name, DisplayName -AutoSize

手順2：RuleモードのままTUNを有効にする

  1. クライアントの設定画面またはホーム画面のスイッチ一覧から「TUNモード」を探します。サブページにある場合は、その画面を開いて仮想NICを有効にしてください。
  2. 初回はクライアント推奨のプロトコルスタックを使い、自動ルートを有効にします。MTU、インターフェース名、インターフェースのバインドは同時に変更しないでください。
  3. Ruleモードのまま、先ほど接続を確認したノードまたはプロキシグループを使います。
  4. ログにインターフェースの作成やルート設定の成功が記録されているか確認します。画面のスイッチがオンになっただけでは、実際に通信を取り込めているとは限りません。

Win + Rを押して ncpa.cpl と入力すると、「ネットワーク接続」が開き、新しいインターフェースを確認できます。インターフェース名はクライアントや設定によって異なり、必ずしも「TUN」とは限りません。共有設定を変更したり、デフォルトゲートウェイを手動で設定したりしないでください。

DNSハイジャックとfake-ip：ドメイン名の解決も確認する理由

通信がTUNに入っていても、DNSが想定どおりに処理されるとは限りません。アプリがルーターへDNSクエリを送信し続ける場合や、ブラウザーのセキュアDNSでHTTPS経由の名前解決を行う場合があります。コアが接続先IPとドメイン名を関連付けられないと、ドメイン名を使う一部の振り分けルールが想定どおり適用されないことがあります。

mihomoの dns-hijack を使うと、TUNを通過する指定DNS通信を内蔵DNSモジュールで処理できます。一般的にはUDP 53とTCP 53を対象にしますが、あらゆる名前解決方式を一律に遮断するものではありません。DoHは通常HTTPSの443番ポート、DoTは通常853番ポートを使用するため、一般的な53番ポートのDNSとは異なります。

mihomoの設定項目例

以下は設定項目を理解するための抜粋で、完全なサブスクリプション設定ではありません。ノード、プロキシグループ、振り分けルールは含まれていません。既存の設定に tun: や dns: がある場合は、元のセクションに統合してください。同じ階層に同名のキーを重複して貼り付けないでください。

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  • auto-route：通信の取り込みに必要なルートをコアに設定させます。無効にするとルートを自分で設計する必要があるため、初回のトラブルシューティングには向きません。
  • auto-detect-interface：通信の出口となるインターフェースの自動検出を試みます。複数のNICがある環境や企業VPNの利用環境では、実際のインターフェースに合わせた調整が必要な場合があり、常に正しく認識されるとは限りません。
  • stack: system：システムプロトコルスタックを使用します。クライアントが別のスタックを推奨している場合は、まず既定値に従ってください。スタックの切り替えは主に互換性の切り分けに使うもので、速度の優劣が固定されるわけではありません。
  • listen: 127.0.0.1:1053：内蔵DNSのローカル待ち受けアドレスです。Windowsの通常のDNS設定欄にはポート番号を入力できないため、「システムDNSアドレスにポートを付けたもの」としてそのまま使うことはできません。
  • fake-ip：ドメイン名に対応するマッピング用アドレスを割り当て、通信とドメイン名を関連付けやすくします。例にある 198.18.0.0/16 は想定されるマッピング用アドレス範囲であり、接続先サイトの実IPアドレスではありません。

例では通常のDNSサーバーを指定しています。到達できるかどうかはネットワーク環境に依存し、暗号化された名前解決にも対応していません。実際の運用では、動作確認済みのDNS構成を使ってください。ノードサーバーのドメイン名、社内ドメイン、振り分け用DNSは個別設定が必要な場合があり、この2行のサーバーアドレスを置き換えるだけですべて解決するわけではありません。

設定を反映してキャッシュをクリアする

サブスクリプション更新のたびに上書きされるファイルを直接編集せず、クライアントのオーバーライド、拡張設定、またはTUN／DNS設定画面を優先して使います。設定を反映してコアを再起動したら、コマンドプロンプトでWindowsのDNSキャッシュを消去します。

ipconfig /flushdns

その後、テスト対象のアプリを完全に終了してから開き直します。ブラウザーが独自のDNSキャッシュを保持していることもあります。結果が変わらない場合は、ブラウザーの「セキュアDNS」を一時的にオフにして比較し、結果を記録してから必要な設定に戻してください。TUNの有効化にあたって、暗号化DNSをすべて恒久的に無効にする必要はありません。

通信の取り込みを確認：ターミナル、ゲーム、接続ログを照合

ターミナルでのテスト：明示的なプロキシを使わずTUNは有効のままにする

WindowsのPowerShellでは curl.exe を明示して実行するのがおすすめです。環境によっては curl が別のコマンドとして解釈されることがあります。まずクライアントのシステムプロキシをオフにしてから、次を実行します。

curl.exe --noproxy "*" --connect-timeout 10 -I https://example.com/

--noproxy "*" を指定すると、一般的なプロキシ環境変数を含め、このcurlリクエストでは明示的なプロキシを使いません。ただし、システムルートやTUNを回避する指定ではありません。そのため、システムプロキシに対応していない、または利用しないアプリの通信がTUN経由でコアに入るかを確認するテストに適しています。HTTPレスポンスが返っても、どのノードを最終的に使ったかまでは判断できません。

  • クライアントの「接続」画面を開き、対象ドメイン、接続先IP、またはプロセス情報で今回のリクエストを絞り込みます。
  • 適用されたルールとプロキシグループの経路を確認します。DIRECTと表示されても、現在のポリシーが直接接続を指定しているだけで、TUNが動作していないとは限りません。
  • TUNをオフにして同じコマンドをもう一度実行し、結果を比較します。もともと直接接続できるサイトなら、どちらも成功するのが正常です。
  • プロキシ経由の通信を確認するには、プロキシ接続が必要で、かつアクセスが許可された宛先を使います。そのうえで、該当ルールが実際にプロキシ方針を選択していることを確認してください。

インターフェースやルートを確認するには、以下の読み取り専用コマンドを実行できます。出力は変化を確認するために使い、ほかのPCのインターフェース番号を参考に手動でルートを追加する必要はありません。

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status -AutoSize
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object InterfaceIndex, DestinationPrefix |
  Format-Table InterfaceIndex, DestinationPrefix, NextHop, RouteMetric -AutoSize

ゲームのテスト：TCPログインとUDP対戦を分けて確認

ゲームランチャー、ログイン、ダウンロード、実際の対戦では、異なるドメインやプロトコルが使われることがあります。ログインできるのに対戦へ参加できない場合は、ブラウザーの速度だけで判断せず、対戦時のUDP通信を確認してください。TUNでUDP通信をコアに送れても、選択中のノード、転送プロトコル、サーバー、設定がUDP転送に対応している必要があります。

  1. ゲームとランチャーを完全に終了し、TUNを有効にしてから再起動します。これにより、新しい接続が現在のルートを使うようになります。
  2. 「接続」画面で、ゲームに関連するTCP／UDPの記録、宛先アドレス、適用ルールを確認します。
  3. ゲーム通信がLANルール、宛先IPルール、またはプロセスルールによってDIRECTに振り分けられていないか確認します。
  4. UDP対応が明確な別のノードに切り替えて比較します。ノードの遅延テストが成功しても、ゲームのUDP通信が使えるとは限りません。

TUNはゲーム専用の通信最適化回線ではありません。地域をまたぐ経路、ノードの混雑、ゲームサーバーの場所、アンチチートとの互換性などによって結果は変わります。有効にすれば遅延が下がると断言することはできません。管理対象のゲームや職場環境では、各サービスのルールにも従ってください。

よくあるトラブル：権限、ルート、DNS、ルールの順に確認

症状まず確認する項目次に行うこと
スイッチが自動でオフになる、またはインターフェース作成エラーが表示されるサービスの状態、権限、コアの起動ログインストール済みサービスを再起動し、インストール先とセキュリティソフトの記録を確認
ブラウザーは使えるが、ターミナルは接続できないブラウザーがシステムプロキシを引き続き使っていないかシステムプロキシをオフにしてcurl.exeで比較し、接続ログを確認
有効化後、大半のドメインがタイムアウトするDNS設定、上流DNSへの到達性、出口ルート以前使えていたDNS設定に戻し、一度に変更する項目は1つにする
ゲームにはログインできるが、対戦できないUDP対応、振り分けルール、ほかの通信最適化ツールUDP接続を確認し、UDP対応ノードに切り替えて再テスト
社内ネットワークやプリンターに接続できないLANルート、社内DNS、厳格ルートの設定社内ネットワークへの直接接続と企業DNSを復元し、必要に応じてTUNを無効にする
一部のIPv6サイトで問題が起きるIPv6アドレス、ルート、DNSの整合性A／AAAAレコードの名前解決と接続を比較し、IPv4だけで判断しない

WSL、Docker、ほかのVPNは通常のデスクトップアプリと同じ扱いにならない

WSL 2、コンテナー、仮想マシンでは、独自の仮想スイッチ、NAT、またはミラーネットワークを経由することがあります。ホスト上のアプリがTUNに取り込まれても、ゲスト環境が同じ経路を使うとは限りません。それぞれの環境内でDNS、デフォルトルート、接続ログを確認してください。Windowsのブラウザーで接続できることだけを根拠に、通信の取り込み範囲を判断しないでください。

企業VPNを有効にしたときだけネットワークが切れる場合は、両方のソフトがルートやDNSを同時に変更していないか確認します。別のネットワーク構成を強制的に上書きしようと、安易に厳格ルートを有効にしないでください。LANやほかのインターフェースへの到達性が変わる可能性があります。複数NICの環境では、維持する社内ネットワーク経路を明確にしてから、インターフェースのバインドやバイパスルールを決めてください。

インターネットに接続できない場合の復旧手順

  1. TUNをオフにし、インターフェースとルートが復元されるまで待ってから、通常の直接接続をテストします。
  2. クライアントを終了する場合は、システムプロキシもオフにしてください。停止した 127.0.0.1:7890 をWindowsが参照し続けるのを防げます。
  3. 変更したDNS設定やオーバーライドを元に戻し、クライアントのコアを再起動します。
  4. 問題が続く場合は、ログとインターフェース情報を保存してからWindowsを再起動します。すべてのNICの削除やネットワークスタック全体のリセットを、最初の手段にしないでください。

有効化後の動作確認チェックリスト

TUN設定が正常に動作するには、「インターフェースが作成されている」「アプリ通信がコアに入る」「ルールが正しく適用される」「普段のネットワークも使える」の4点を満たす必要があります。スイッチの状態だけで判断しないでください。以下を確認してから、クライアントのWindows起動時自動実行を検討しましょう。

  • 権限：バックグラウンドサービスが正常に動作し、コアのログにインターフェース作成失敗や権限エラーが繰り返し記録されていない。
  • 通信の取り込み：システムプロキシをオフにした状態でも、テストしたターミナルのリクエストをクライアントの接続画面で確認できる。
  • ルール：プロキシが必要な宛先には想定したプロキシグループが適用され、直接接続先やLAN内リソースは想定した経路を維持している。
  • DNS：よく使うドメインを正常に名前解決でき、社内ドメインが誤ってパブリックDNSへ送られていない。
  • プロトコル：必要なUDP対応アプリを個別にテストし、TCPのダウンロード速度でゲームの動作を判断しない。
  • 復旧：TUNをオフにしてクライアントを終了した後、システムプロキシとネットワーク接続が想定どおりの状態に戻る。

以降、特定のアプリだけに問題が起きた場合は、まずそのアプリの接続記録と適用ルールを確認し、すぐに設定全体を入れ替えないでください。基本のポート、サブスクリプション、振り分け設定についてはClashの使い方ガイドをご覧ください。設定項目を確認する場合はプロトコルリファレンスを参照してください。