まず通信の取り込み方法を選び、次にルールを確認

ブラウザーではWebページを開けるのに、ターミナルでは接続がタイムアウトする。システムプロキシを有効にしても、ゲームの通信経路が変わらない。こうした場合、ノードの障害とは限りません。アプリがシステムプロキシの設定を参照していないことがよくあります。システムプロキシとTUNの主な違いは、ノードの速度やサブスクリプションの品質ではなく、通信がどのようにClashのコアへ渡されるかです。

  • 主にブラウザーを使う場合：まずはシステムプロキシを有効にしましょう。設定が簡単で、問題が起きても元に戻しやすい方法です。
  • コマンドラインの特定タスクだけをプロキシ経由にしたい場合：コマンドにHTTPまたはSOCKSプロキシを明示的に指定しましょう。すぐにTUNを有効にする必要はありません。
  • プロキシ設定に対応していないアプリを使う場合や、一部のUDP通信を処理したい場合：TUNを検討し、ルーティング、DNS、ノードのプロトコルを確認しましょう。
  • 会社のVPNに接続中の場合：まず社内ネットワークの要件を確認し、複数のツールが同時にデフォルトルートを変更しないようにしてください。

システムプロキシ：アプリからローカルポートへ接続

システムプロキシは、OSのプロキシ設定にローカルプロキシのアドレスを書き込みます。対応するアプリはそのアドレスを読み取り、リクエストをクライアントに送ります。たとえば、クライアントが127.0.0.1:7890で待ち受けている場合、ブラウザーはこのローカルポートを通じてプロキシ接続を確立できます。実際のポート番号はクライアントの表示を確認してください。7890はこの記事での例です。

システムプロキシで処理できる通信

EdgeやChromeなどのブラウザーは通常、システムプロキシの設定に従います。ただし、組織のポリシー、拡張機能、起動オプションによって動作が変わることがあります。Firefoxではシステムプロキシを使うか、接続方法を個別に設定できます。ダウンローダー、開発ツール、ゲームの実装はそれぞれ異なるため、タスクバーに「システムプロキシ有効」と表示されているだけで、すべてのアプリがプロキシ経由になったとは限りません。

  • HTTPプロキシはWebリクエストによく使われ、HTTPSでは通常、HTTP CONNECTでトンネルを確立します。これは、クライアントがHTTPSの内容を復号するという意味ではありません。
  • SOCKS5はTCPを処理できます。UDPを使えるかどうかは、アプリ、クライアント、ノードまでの経路がすべて対応している必要があります。
  • mixed-portを使うと、同じポートでHTTPとSOCKSのプロキシリクエストを受け付けられます。ただし、プロキシ設定を参照しないアプリの通信経路が自動的に切り替わるわけではありません。

システム設定でプロキシのアドレスを確認する

Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシまたはセットアップスクリプトの状態を確認できます。macOSでは「システム設定」→「ネットワーク」→使用中のネットワークサービス→「詳細」→「プロキシ」を開きます。ここでは設定内容を確認し、日常的な切り替えにはクライアントを使いましょう。両方から変更を繰り返すと、設定が上書きされるおそれがあります。

0.0.0.0をアプリのプロキシサーバーアドレスに指定しないでください。このアドレスは、IPv4のすべてのインターフェースで待ち受けることを表す場合によく使われます。同じPC上のアプリから接続する場合は、通常127.0.0.1を指定します。LAN内で共有する必要がある場合に限り、待ち受けアドレス、ファイアウォール、アクセス制限を別途検討してください。

TUNモード：仮想ネットワークインターフェースでIP通信を受け取る

TUNは仮想ネットワークインターフェースを作成または使用し、ルーティングなどの仕組みを通じて、条件に合うIPパケットをコアへ渡します。アプリ側にHTTPプロキシの設定がなくても使えるため、プロキシを手動設定できないプログラムに適しています。Clash Metaから発展したmihomoコアも関連機能を備えていますが、クライアントごとに使用するコア、サービスのインストール方法、画面上のスイッチは異なります。

「TUNを有効にする」だけで「すべての通信を捕捉する」わけではありません。実際の捕捉範囲は、IPv4・IPv6のルート、インターフェースの除外設定、LANのバイパス、他のVPN、システムファイアウォールによって変わります。仮想マシン、コンテナー、WSLには別のネットワーク経路があるため、ホスト上のアプリと同じように扱うことはできません。

比較項目 システムプロキシ TUNモード
通信の入口 アプリがプロキシの待ち受けポートに接続 仮想インターフェースとルーティングでIP通信を受信
アプリ側の要件 システム設定に従うか、プロキシを個別に設定 通常、アプリがプロキシプロトコルに対応している必要はない
UDPの処理 一般的なHTTPシステムプロキシでは通常のUDP通信を処理できない 捕捉したUDPを処理できるが、ノードの対応も必要
権限とサービス 通常、仮想インターフェースの作成は不要 通常、権限の昇格または特権サービスの事前インストールが必要
トラブルシューティングの要点 アドレス、ポート、アプリが設定を参照しているか ルーティング、DNS、サービスの権限、インターフェースの競合

TUNで管理者権限が必要になる理由

インターフェースの作成やルートの変更は、システムのネットワーク操作にあたります。Windowsクライアントはサービスモードで処理する場合があり、macOSでは補助プログラムの認証が必要になることがあります。Linuxでは通常、/dev/net/tunと適切なネットワーク管理権限が関係します。特権サービスをインストールした後は、GUIを毎回管理者として起動する必要がない場合もあります。

ログに権限不足が表示された場合は、使用中のクライアントの手順に従ってサービスをインストールまたは修復してください。TUNのオン・オフを何度も繰り返しても解決しません。トラブルシューティングのためにシステムファイアウォールを長期間無効にするのも避けましょう。まずサービスの状態を確認し、次にブロックされているプログラムやルールを特定してください。

コマンドラインとゲームは、スイッチではなくアプリごとに確認

コマンドラインが接続できない場合は、まずプロキシを明示してテスト

ターミナルで使うツールが、OSのプロキシ設定を参照するとは限りません。HTTP_PROXY、HTTPS_PROXY、ALL_PROXYを認識するツールもありますが、対応範囲や大文字・小文字の扱いは異なります。切り分けには、環境変数を全体に設定するより、コマンドにプロキシを明示するほうが影響範囲を確認しやすくなります。

# Windows PowerShell では、旧バージョンのエイリアスとの競合を避けるため curl.exe を使用
curl.exe --proxy http://127.0.0.1:7890 --noproxy "" -I https://example.com

# macOS / Linux では curl を使用
curl --proxy http://127.0.0.1:7890 --noproxy "" -I https://example.com

# SOCKS5を使用し、接続先のドメイン名をプロキシ側で解決
curl --proxy socks5h://127.0.0.1:7890 --noproxy "" -I https://example.com

これらのコマンドは、7890が該当プロトコルに対応したmixedポートであることを前提としています。HTTPレスポンスが返れば、そのプロキシリクエストの接続には成功しています。ただし、ステータスコードだけでは、どのパブリックIPアドレスから接続したかは判断できません。プロキシを明示したコマンドは成功するのに通常のコマンドが失敗する場合は、サブスクリプションを変更する前に、そのツールのプロキシ引数や環境変数を確認してください。

ゲームはUDPを使うことが多く、TUNでも遅延が保証されるわけではない

ゲームでは、TCPによるログイン、UDPによる対戦、独立したボイスチャット接続が同時に使われることがあります。TUNを有効にしても、ルーティングで捕捉され、ノードが対応している接続だけがプロキシ経由になる可能性があります。ノードのプロトコル、サーバー側の設定、ルールの適用結果、地域制限も影響します。

  1. まずクライアントの接続一覧でゲームのプロセスや接続先アドレスを探し、通信がコアに入っているか確認します。
  2. 適用されたルールとプロキシグループを確認し、ログイン通信はプロキシ経由なのに対戦通信だけ意図しない直結ルールに一致していないか調べます。
  3. ノードがUDP転送に対応しているか確認してください。Webサイトの速度測定結果だけでは判断できません。
  4. 同じサーバー、同じ時間帯で直結とプロキシを比較し、ゲーム内の遅延、パケットロス、切断の状況を記録します。

経路が長いノードを使うと遅延が増えることがあります。TUNは通信を捕捉できる範囲を広げる機能であり、自動的にゲームを高速化するものではありません。ゲームの利用規約やアンチチートの制限も別途確認してください。

DNS処理：プロキシ経由の名前解決とシステムDNSを区別する

システムプロキシとTUNのもう一つの重要な違いは、ドメイン名の問い合わせがどこを通るかです。HTTPプロキシでHTTPSサイトに接続する場合、アプリは接続先のドメイン名をプロキシに渡して処理できます。一方、アプリによる事前の名前解決、ほかのバックグラウンド通信、セキュアDNS機能は別の経路を使うことがあります。そのため、「Webページがプロキシ経由で開けた」だけでは、すべてのDNS問い合わせが同じ経路を使っているとは限りません。

TUNはDNSの捕捉と組み合わせて、条件に合う53番ポートの問い合わせをコアのDNSモジュールに渡せます。mihomoでよく使われるdns-hijackは、この処理のための設定です。任意の暗号化DNSを復号する機能ではありません。アプリが独自に送信するDoHはHTTPSを使い、DoTは通常853番ポートを使うため、53番ポートを対象にした設定だけで自動検出・書き換えできるわけではありません。

mihomoの設定例を読み解く

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

これは各項目を説明するための一部抜粋であり、単独で動作する完全な設定ファイルではありません。auto-routeは関連するルートを自動設定し、auto-detect-interfaceは外向きのインターフェースを自動検出します。listenの1053はローカルDNSの待ち受けポートで、ノードのポートではありません。また、DNSの捕捉とこの待ち受けポートは別の概念です。

Fake-IPモードでは、ドメインに対応するアドレスを割り当て、その対応関係を使って後続の接続を処理します。198.18.0.1/16はこの用途のアドレスプールであり、実在するWebサーバーのアドレスではありません。既存の設定では、適切な上流DNSなどの設定も必要です。この抜粋をサブスクリプションのファイルにそのまま上書きしたり、同じ階層に2つ目のdnsやtunキーを追加したりしないでください。

有効化の手順：まず基準となる状態を確認し、その後TUNを追加

システムプロキシとTUNを同時に有効にしても、必ず競合するわけではありませんが、効果が倍増するわけでもありません。HTTPプロキシ接続と仮想インターフェースによる捕捉が同時に動作する場合、クライアントは自分自身の通信やルートの除外を適切に処理する必要があります。トラブルシューティングでは入口を1つに絞ると、問題がどの層で起きているか判断しやすくなります。

  1. ノードと設定を確認：サブスクリプションを追加してノードを1つ選び、Ruleモードに設定します。まずシステムプロキシ経由でWebページを開けることを確認してください。
  2. ローカルポートを確認：クライアントでHTTP、SOCKS、またはmixedポートを確認します。コントローラAPIのポートをプロキシポートと取り違えないようにしてください。
  3. サービスの権限を準備：クライアントの説明に従ってサービスをインストールするか、必要な認証を済ませます。ネットワークを捕捉中のほかのプロキシツールは終了してください。
  4. TUNだけでテスト：一時的にシステムプロキシを無効にしてTUNを有効にします。対象アプリを再起動し、接続一覧とログを確認してください。
  5. 普段使うサービスを確認：Webページ、コマンドライン、LAN内のデバイス、社内サイトにアクセスし、直結が必要なアドレスにルールが誤適用されていないか確認します。

Androidクライアントは通常、システムVPNインターフェースを使って通信を捕捉します。同じユーザーで同時に有効にできるVPNサービスは通常1つです。PCでHTTPシステムプロキシを設定する操作とは異なります。iOSのネットワーク拡張にも独自の仕組みがあるため、デスクトップ版のYAML項目やスイッチの場所をそのままモバイル版に当てはめないでください。

TUNを有効にしてネットに接続できない場合は、症状から原因を絞り込む

システムプロキシは動作するのに、TUNだけ失敗する

  • サービスが起動しているか、ログにインターフェースの作成、ルートの設定、権限エラーが記録されていないか確認します。
  • ほかのVPN、仮想ネットワークアダプター、セキュリティソフトが同時にルートを変更していないか確認します。要因は一度に1つだけ無効にして、再テストしてください。
  • IPv6の捕捉設定を確認します。IPv4のリクエストが成功しても、すべての接続が同じ経路に入っているとは限りません。

一部のWebサイトは開けるが、特定のアプリでドメインエラーが発生する

  • DNSモジュールが有効か、上流DNSに到達できるか、アプリに独自のDoH設定がないか確認します。
  • Fake-IPのフィルターと直結ルールを確認します。特にLAN内のドメイン、社内ドメイン、実IPアドレスが必要なサービスに注意してください。
  • 接続ログを確認し、名前解決の失敗、ルールの選択ミス、ノードへの接続失敗のどれが原因か切り分けます。すべてのタイムアウトをDNSの問題と決めつけないでください。

クライアントを終了した後もネットに接続できない

まずTUNとシステムプロキシを正しく無効にしてから、クライアントを終了します。異常終了した場合は、システムプロキシが待ち受けを停止した127.0.0.1:7890を指したままになっていないか、元のVPNやネットワークサービスが復旧しているか確認してください。関連するネットワークサービスやシステムを再起動する前に、作業内容を保存します。元の設定を記録せずにルートをまとめて削除しないでください。

原因を特定できない場合は、インターネットに接続できない場合の対処と設定ファイルの確認もご覧ください。ログを共有する際は、サブスクリプションURL、ノードのパスワード、アクセストークンを伏せ、発生時刻、コアの情報、エラー行、再現手順だけを記載してください。