誰がまず stack を疑うべきか
症状が「プロキシ全体が遅い」よりも、TUN を有効にした直後から限定的に悪化したときにスタックの切り分けは効きやすいです。具体例としては、オンライン対戦のアイテム入力遅れ、ボイスチャットと画面更新のタイミングずれ、ブラウザの QUIC がオフでも改善しない体感、企業ネットワークで 一部アプリのみ証明書／接続順序でコケるなどです。これらは出口ノードだけの問題ではなく、ローカルの仮想スタックとの相性にも依存します。FEC 付き転送経路や HTTP/3 全般の設計論は Hysteria2 と TUIC の QUIC 評価記事 が補助線になりますが、本稿の焦点は「Mihomo の TUN がパケットをどう処理するか」の切り替えです。
gvisor と system は何が違うか
ざっくり言うと、gvisor は Go ランタイム上でユーザー空間の TCP/IP／パケット処理を担うモデルであり、プラットフォーム差を自分たちで実装側で吸収しやすい一方、転送ひとつひとつにソフトウェア処理が乗りやすい傾向があります。system（名称は設定やビルドで表記ゆれがありますが「OS 側の処理をより直接使う側」という意味で読む）は、経路構成次第で体感レイテンシがシャープになりやすい場面がありますが、そのぶんOS のバージョン・他のフィルタ・サードパーティ VPN と干渉しやすくなることもあります。どちらが万能かではなく、「CPU に余裕がないノートか」「すでに WFP／企業証明書／別 VPN が居座っているか」といったコンテキストで選ぶイメージです。
レイテンシとカクツキの軸
レイテンシは往復だけでなく、ジッター（ゆらぎ） とセットで体感されます。gvisor は負荷が高いと CPU スケジューリングの影響でジッターが目立つことがあり、対戦ゲームやリモートデスクトップのカーソル追従のように一定間隔のレスポンスが欲しい用途では最初に system へ寄せて比較する読者が多いです。逆に、同じマシンでもバックグラウンド負荷が低く、かつ system 側で奇妙なドロップだけが出る場合は gvisor が安定板になることもあります。数字の絶対値はマシンと OS で変わるため、本稿では「同一 Wi‑Fi・同一ノード・同一ルールのもとで数分ずつ交互に試す」ことだけを推奨します。
互換性の軸（仮想 NIC と他製品）
system 寄りの経路は OS のネットワークスタックと深く噛み合うぶん、二重トンネル（別 VPN、ゼロトラスト、フィルタドライバ）と順序が衝突しやすいです。症状は「接続は張れるが数秒で切れる」「特定プロセスだけ SYN が出ない」などバラエティに富みます。こうしたとき gvisor は隔離層が厚く、衝突が緩むケースがあります。Linux で systemd と常駐させる話は Linux・Mihomo・TUN の稿 に具体例があるため、デスクトップ Linux 利用者はあわせて読むと理解が早いです。
QUIC・UDP・ゲームへの当たり方
QUIC（多くの場合 UDP 上）は、スタックがパケットをどうバッファリングし、どのタイミングでユーザーランドへ上げるかでラグの見え方が変わります。ブラウザは HTTP/3 を切ってもアプリ側の実装差で残るため、まず TUN の stack を切り替え、次に ルールで UDP が意図したポリシーに載っているかをログで確認するのが筋が良いです。ゲームはタイトルによって TCP 中心／UDP 中心が混在するため、接続ログに udp が出ているかを Discord 稿の「UDP の見方」 と同じ要領で眺めると、スタック変更の前後比較がしやすくなります。
目安：「スタックを変えたら別の症状に化けた」場合、しばしば DNS（FakeIP／DoH） や ルール順 の副作用です。スタックを固定したうえで ルール順の稿 に戻ると切り分けが直線的になります。
設定上の置き場所（概要）
Mihomo 系のプロファイルでは、tun ブロック内の stack で指定するのが一般的です。GUI によっては「TUN スタック」などのラベルで露出します。実際のキー集合はバージョンで変わり得るため、最終判断は利用中のリリースノート／ドキュメントに合わせてください。スケッチ例は次のとおりです（説明用です）。
# Example sketch — keys may differ by Mihomo / client version
tun:
enable: true
stack: gvisor # try: system
# auto-route, dns-hijack, strict-route, etc. follow your environment
strict-route や auto-route をいじると「スタックを替えたつもりが経路全体が変わった」という錯覚が起きやすいので、一度に触る変数は一つに絞るのが安全です。クライアントが生成する上書き（mixin など）を併用している場合は mixin の稿 も参照し、最終的にどの YAML が勝っているかを確認してください。
スタックを決めたあと：DNS・ルール・環境変数
スタック自体は「パケットの入口処理」に近く、名前解決の設計ミスは別レイヤーで残ります。FakeIP と実接続の整合、DoH のフォールバック順、nameserver-policy の穴は Meta コア DNS リーク防止ガイド の手順に沿って一度まとめると、スタック比較のノイズが減ります。ルールは GEOIP／GEOSITE の稿 で地図を描いたうえで、ゲームタイトルやランチャー用の PROCESS-NAME を足すかどうかはオプションです。
環境変数でプロキシを読むアプリ（ターミナルや一部 IDE）が混ざる場合、TUN と HTTP(S)_PROXY の二重指定で挙動が不思議になることがあります。基本は「TUN で全体を覆うならプロキシ環境変数は最小限」に寄せ、必要なシェルだけ例外を作ると理解しやすいです。
切り分けチェックリスト（推奨順）
- 前提固定：同一ノード・同一ルール・同一 DNS 設定のまま比較する。
- stack 切替：
gvisorとsystemをそれぞれ数分ずつ試し、ゲーム／ブラウザ／VoIP の体感をメモする。 - CPU 使用率：カクツキ時にコアが張り付いていないかを OS のモニタで眺める（gvisor 負荷の手掛かり）。
- 競合ソフト：別 VPN やフィルタを一時停止し、system 側の改善度を見る。
- ログで UDP／QUIC：意図しない DIRECT や別ポリシーに落ちていないか確認する。
- DNS・ルール：スタック側が落ち着いたら FakeIP／ルール順を整える。
注意：プロキシやゲームの利用は、各サービスの規約と居住地域の法令を遵守してください。職場・学校のネットワークではポリシー違反にならない範囲で設定してください。
まとめ
Clash Meta／Mihomo の TUN では、gvisor と system の stack 選択が、レイテンシ・CPU・互換のトレードオフに直結します。ゲームや QUIC 感受性の高いアプリで悩む場合は、DNS 総取り替えの前にスタックの A/B テストを挟むと時間を節約しやすいです。落ち着いたら DNS と 分流ルール を整え、長期運用に移るのがおすすめです。クライアントの入手は 公式ダウンロードページ を第一にし、用語の整理には ドキュメント・チュートリアル も活用してください（ソースは GitHub で確認できますが、配布物の主たる導線はサイト側と取り違えないようにすると安全です）。
同種ツールの中でも、Clash 系はルールとログを同じ画面で追いやすいため、スタックという地味なスイッチでも再現性のある比較がしやすいのが強みです。