なぜ「ブラウザは通るのにゲームだけ別ルート」になりやすいのか

多くの読者が最初につまずくのは、HTTP／HTTPS のブラウザ通信は問題なく経由するのに、オンラインゲームや一部ランチャーだけが迂回しない／不安定というパターンです。背景には、HTTP ユーザーエージェントではなく OS のソケット API を直接叩く実装が多いこと、そして対戦系ではUDP（ユーザデータグラム）や複数ポートへの同時発火が前提になりやすいことがあります。

このときシステムプロキシ（環境変数や OS のプロキシ設定）だけに頼る構成だと、「プロキシ欄を読まないアプリ」から見れば通信経路が変わらないままになります。ブラウザは親切にプロキシを参照しますが、ゲーム側はそうとは限りません。結果として「VPN っぽい挙動が欲しいのに一部だけ直結」のような体感になります。

TUN（トンネル／仮想ネットワークインタフェース）は、ここで役割が変わります。OS に一枚の「仮想 NIC」を立て、その背後で Clash／Mihomo コアがパケットを受け取り、ルールどおりにプロキシグループへ振り分けるイメージです。アプリ側は自分から見て通常のデフォルトゲートウェイ経由に見えるため、プロキシ未対応でも通信がコア側に集約されやすくなるのが利点です。

ただし万能ではありません。権限（管理者／システム拡張）、既存の VPN 製品、セキュリティソフトのフィルタ、DNS の設計がずれたときの名前解決ブレなど、障害要因は増えます。本稿では2026 年時点で現場で効く切り分け順と、購読 YAML を読むときに見るべきポイントを中心に整理します。利用は各国の法令とサービス側の規約に沿ってご判断ください。

システムプロキシと TUN の違いを実務で一言ずつ

システムプロキシは、HTTP CONNECT や SOCKS を理解できるアプリが OS の設定を参照するときに効きます。開発ツールやブラウザ、一部の同期クライアントではこれで十分なことが多いです。一方で、ゲームやカスタムプロトコル、ローカル検証用ツールはプロキシ設定を無視して外向きUDPをそのまま撃つことがあります。

TUNは、その手の「設定を読まないけれどデフォルト経路には乗る」通信をルールエンジンの上流に引き上げるための仕組みです。ここでいう「全文面」や「グローバルな振る舞い」とは、細かい語源よりアプリ種別を問わずまずコアへ集めるという運用上の意味に近いです（実際には除外リストや DIRECT ルールで国内や LAN は迂回します）。

運用の現実的なラインは次のとおりです。

  • ブラウザ中心・CLI は自分でプロキシ指定できる：システムプロキシだけで摩擦が少ない
  • ゲーム／ボイスチャット／独自ランチャー／システム同期が絡む：TUN を検討する価値が高い
  • 社内 VPN と同居させたい：競合が出やすいので設計が必要（後述）
💡
まずは Rule モードのまま問題のアプリだけがどの宛先へ向かっているかをログで確認すると、ルール不足なのかノード側なのかが切り分けやすくなります。いきなり Global に固定しないほうが日常運用では安全です。

UDP が絡むときに起きやすいこと（ゲーム視点）

UDP はコネクション志向が薄く、再送や順序保証はアプリ側次第です。対戦ゲームではレイテンシを削るために選ばれやすい一方、プロキシ連鎖ではNAT のかけ方やポートマッピングが絡むと失敗しやすくなります。購読側で Shadowsocks のように udp: true が明示されている例もありますが、それでもローカルのファイアウォールやセキュリティ製品が UDP を別扱いしていると表面化します。

また、名前解決がIPv4／IPv6で分岐した結果、意図しない経路へ出ていくケースも見られます。UDPそのものが悪いのではなく、名前解決・デフォルトルート・除外ルールがセットで崩れると症状として現れやすい点を押さえておくと調査が速くなります。

前提チェックリスト（入る前に読む）

  1. GUI が Meta／Mihomo コアに対応しているか：古い Premium 専用構文だけを前提にした購読だと読み込みに失敗することがあります。
  2. 管理者権限やドライバ許可が必要か：Windows は昇格プロンプト、macOS はシステム設定側の許可が絡むことがあります。
  3. 競合する仮想 NIC／VPN が無いか：複数が同時にデフォルト経路を握ろうとするとループや断線が出ます。
  4. 購読が推奨する DNS モードに寄せられるか：fake-ip と redir-host のどちらかで説明が分かれていることがあります。
⚠️
TUN は強力なので、社用端末では情報システムの方針に照らしてから有効化してください。証明書検査やデータ損失防止ツールと衝突すると接続だけが落ちることもあります。

YAML で見るべきマーカー（コピペではなく「読む」）

実際の鍵は購読全体を暗記することではなく、自分のクライアントがどのフィールドを尊重しているかを画面ログと突き合わせることです。とはいえ現場では次のブロックが議論の起点になりやすいです。

tun セクションの一例

tun:
  enable: true
  stack: system
  auto-route: true
  strict-route: false
  dns-hijack:
    - any:53

stack は OS／実装差があり、挙動が変わります。strict-route を強めると漏れは減りやすい反面、特定アプリだけ異常になることがあります。購読提供者の推奨値を初期値にし、自分の環境でだけ微調整するのが無難です。

DNS と fake-ip の読みかた

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.cloudflare.com/dns-query
  fallback:
    - https://dns.google/dns-query

fake-ip は体感では速くなりやすい一方、対象アプリがローカル検証や証明書ピニングに敏感だとトラブルのように見えることがあります。その場合でもすぐオフにせず、ルールで対象ドメインだけ迂回するなど段階的に調べると原因が特定しやすいです。

プロキシ側の UDP フラグの典型

proxies:
  - name: "tokyo-ss"
    type: ss
    server: jp.example.com
    port: 8388
    cipher: aes-256-gcm
    password: "***"
    udp: true

udp: true が無い／サービス側が UDP を閉じている場合、ゲームが落ちても不思議ではありません。別リージョン／別プロトコルで一度だけ試すのが現実的な切り分けです。

GUI での有効化イメージ（一般手順）

画面名称はクライアントごとに変わりますが、流れは共通です。

  1. プロファイルをアクティブ化し、接続ログが出る状態にする
  2. TUN／仮想アダプタ／Enhanced Tun など同名のトグルをオンにする
  3. 初回のみドライバやシステム拡張のインストールを完了させる
  4. 再起動を促されたら従う（途中までだとNICが中途半端に残る）
  5. 問題アプリを起動し、ログに SYN／UDP の痕跡が出るかを確認する

Windows と macOS でつまずきやすい差

Windows

昇格プロンプトや SmartScreen、ウイルス対策のリアルタイム防御が TUN ドライバを止める例があります。会社支給機ではホワイトリスト申請が必要になることも珍しくありません。ルーティングテーブルが複数製品で競合すると「ランダムに切れる」ように見えるので、競合を止めて再現するのが早いです。

macOS

メニューバー型クライアントでも TUN は利用できますが、システム設定での許可ダイアログや Full Disk Access に相当する要件が絡むことがあります。Apple Silicon と Intel でパッケージが分かれている場合は、公式の該当ビルドを選び直してください。

トラブルシュートの優先順

  • ログが空／ドロップが多い：まず競合 VPN とセキュリティ製品を疑う
  • TCP は通るが UDP だけ落ちる：ノードの UDP 可否とローカル UDP フィルタを疑う
  • 名前は取れるが繋がらない：DNS の上流と fake-ip の組み合わせを疑う
  • 国内サイトだけ遅い：ルール誤適用で遠回りしていないか確認する
ℹ️
「一度だけ Global で試す」は切り分けには有効ですが、日常運用ではリスト設計が崩れやすいので長時間固定しないほうがよいです。

よくある質問

Q. システムプロキシだけではゲームが繋がらないのはなぜ？

A. ゲーム側がプロキシ設定を参照しないためです。TUN はそのギャップを埋めるアプローチのひとつです。

Q. UDP はどのノードでも安定しますか？

A. サービス実装とネットワーク経路に依存します。YAML とログを見ながら別ノードや別協定で短時間だけ検証してください。

Q. 企業 VPN と同居できますか？

A. 可能な場合もありますが衝突も多いです。どちらがデフォルトルートを握るかを整理し、社内帯は DIRECT に寄せるなど設計が必要です。

まとめ｜全文面を誤解しないための心構え

TUN は「すべてをプロキシへ強制する魔法」ではなく、ルールエンジンの手の届く位置までトラフィックを引き上げる装置です。だからこそ Rule モードとセットで効き、ゲーム UDP のようなシビアな要件でも観測可能性（ログ）が高まるという実務上のメリットがあります。

単体のブラウザ拡張や軽量プロキシだけを足し合わせる構成は、はじめは簡単でも、アプリが増えるほど更新サイクルと権限ダイアログがバラバラになりがちです。一方で Mihomo を背負えるクライアントは、購読からグループ・DNS・TUN までを一枚の画面で切り替えられることが多く、長期運用ではその統合が摩擦削減になります。古いビルドや出所不明の改造パッチに依存している場合は、配布元と署名を確認して正規チャネルへ寄せるだけでも、UDP まわりの切り分け速度が上がります。

まだ自分の OS に合うパッケージやコア世代を決めかねている場合は、開発元のリリースノートとあわせて各プラットフォーム向けバイナリがまとめられたダウンロード導線から選ぶと安全です。

ダウンロードページで Clash クライアントを入手する →