1. よくある症状
Clash（Mihomo コア）の TUN モードは、ブラウザだけでなくアプリ全体のトラフィックを仮想インターフェース側に流すための仕組みです。Windows では管理者権限や Wintun ドライバ、既存 VPN や仮想スイッチと競合しやすく、初めて有効にしたときに「一気に全ポートが塞がった」ように感じることがあります。
代表的な訴えは次のとおりです。どれに近いかをメモしておくと、後の対照表と照合しやすくなります。
- TUN をオンにした瞬間、ブラウザも更新も一切繋がらない（完全断線）
- 国内サイトや一部ドメインだけ開き、特定のサービスだけタイムアウトする
- しばらくすると復旧するが、スリープ復帰や VPN 切り替えのたびに再発する
- クライアント画面では「接続中」だが、実際のパケットは通っていない
システムプロキシのみのときと違い、ルートテーブルとファイアウォールが直接絡むため、「設定 YAML は正しいのに繋がらない」状態が起きやすい点がポイントです。同じく Windows でポート共有や LAN を扱う場合は、ミックスドポートとファイアウォールの記事と併せて読むと、ポート系と TUN 系の違いが整理しやすくなります。
2. TUN が Windows で変えること
TUN を有効にすると、コアは通常のプロキシ待受に加え、OS に 仮想ネットワークアダプタを見せ、既定ルートや例外ルートを書き換えてトラフィックを引き寄せます。Clash Verge や Clash for Windows などの GUI は、その手前で Wintun のインストールやサービス再起動を案内しますが、管理者として実行されていない、古い Wintun が残っている、といったケースではアダプタが正しく立ち上がりません。
また、ルールで「プロキシに行かない」トラフィックを DIRECT に落としても、TUN レイヤで DNS が先にコア側へ向いてしまい、結果として名前解決だけが失敗する、といった見かけ上はルートの問題に見える DNS 問題も混ざります。ここを切り分けるには、症状が「名前解決の失敗」か「TCP 自体の失敗」かを意識するとよいです。
3. 切り分けの順番
本稿では次の順で見ていきます。上ほど「よくある原因」に当たりやすく、ログも取りやすい順です。
- クライアントがコアを起動できているか、ログに致命的エラーがないか
route printや設定画面で、仮想アダプタとデフォルトルートの優先度がおかしくないか- DNS（fake-ip / redir-host / システム DNS）が意図どおりか
- Windows Defender ファイアウォールやサードパーティ製品がコアや仮想 NIC をブロックしていないか
- 別 VPN、Hyper-V 仮想スイッチ、企業ポリシーなど「特殊環境」に当たっていないか
設定の全体像は Clash のドキュメントを参照しつつ、本記事は Windows に特化した実機チェックに絞ります。
4. クライアント・コア・ログ
まず GUI から「コアが起動しているか」「TUN スイッチを入れたタイミングでクラッシュしていないか」を確認します。Mihomo／Clash Meta 系では、ログに Start TUN listening error や Wintun 関連のメッセージが出ていないかを見ます。管理者権限が足りない場合、ここで明確に失敗することが多いです。
ログで見るポイント
DNS クエリがルールにマッチしているか、選択したポリシー（PROXY／DIRECT／REJECT）に流れているかを追います。すべて REJECT や誤ったルールに吸い込まれていると、ルートやファイアウォールを触る前に YAML 側の修正が必要です。
更新系（購読）だけが死んでいる場合は、トンネルより上流の TLS やノード側の問題であることもあります。その場合は TUN をオフにしても同様の不具合が出るかを比較してください。
5. ルートテーブルと仮想アダプタ
管理者権限のコマンドプロンプトまたは PowerShell で route print を実行し、デフォルトゲートウェイ（0.0.0.0）がどのインターフェースに付いているかを確認します。TUN 利用時は、仮想アダプタのメトリックや優先度が極端に悪く、ローカル LAN への通信まで遠回りしている例があります。
また、複数の VPN クライアントを入れていると、同じタイミングでデフォルトルートを奪い合い、一見「Clash のせい」に見える症状が出ます。他社 VPN を完全に終了し、ネットワークアダプタの一覧で「不要な WAN Miniport」や重複した仮想 NIC が残っていないかも見ておくとよいでしょう。
IPv6
IPv6 が有効な回線では、IPv4 だけコアに流れ、IPv6 が直出しになり、サービスによっては「一部だけ繋がらない」ように見えることがあります。切り分けとして一時的に IPv6 をオフにする、またはルールと DNS で IPv6 を意識的に扱う、といった方針を検討できます。
6. DNS
TUN ではしばしば fake-ip や redir-host が絡みます。設定とクライアントの「DNS ハイジャック」オプションが一致していないと、ブラウザだけ名前解決に失敗する、といった症状が出ます。クライアントのドキュメントに従い、推奨される DNS セクションと TUN の組み合わせを揃えてください。
Windows の「ネットワークアダプタの DNS」を手動で固定している場合、コアが期待するフローと衝突することもあります。一時的に「自動取得」へ戻して挙動を比較するのが有効です。
7. ファイアウォールとセキュリティ製品
Windows Defender ファイアウォールは、実行ファイル単位とポート単位の両方でブロックがかかります。Clash 本体に加え、コアのバイナリ名（例：mihomo 系）が別プロセスとして立ち上がる構成では、許可リストに片方しか入っていないと片方向だけ通る、といった現象が起きます。
「セキュリティが強い」サードパーティ製品は、未知の実行ファイルを自動隔離するため、更新直後だけ通信が止まることもあります。インストール済みの場合は、一時的に無効化して挙動を切り分け、必要なら除外パスを登録します。
8. 競合と特殊環境
Hyper-V や WSL2、Docker Desktop を有効にしていると、仮想スイッチとメトリックが複雑になり、TUN と相性が悪い組み合わせが出ます。ゲーム用アンチチートや帯域制御ツールも、仮想 NIC を疑似的に挿入するため、同様のトラブルが報告されています。
こうした環境では「最小構成」に落とすことが近道です。他 VPN を終了し、不要な仮想アダプタを無効化し、Clash だけを残して再起動する。それでも改善しないときは、クライアントのバージョンと Wintun の再インストールを検討します。
9. 症状対照表
次の表は、典型的なパターンと最初に疑う箇所の対応です。あくまで目安なので、ログとセットで判断してください。
| 症状のイメージ | まず疑う場所 | 試すこと |
|---|---|---|
| TUN オン直後に全断 | コア起動失敗・Wintun・管理者権限 | ログ確認、管理者で再実行、ドライバ再導入 |
| 名前は通るがページが開けない | DNS 設定・fake-ip 不一致 | DNS セクションと TUN オプションの整合 |
| 国内は速いが海外だけ遅い／不通 | ルール・ノード・上流 | ルール順、プロキシグループ、ノード切替 |
| 特定アプリだけ直結してしまう | プロセスが TUN をバイパス | クライアントの「プロセスモード」やルールの確認 |
| VPN 併用時だけ不安定 | デフォルトルートの競合 | 他 VPN の完全終了、ルートの再確認 |
10. まとめ
Clash TUN で Windows が断線したように見えるとき、原因は「コアが落ちている」「ルートテーブルが競合している」「DNS が意図とズレている」「ファイアウォールがプロセスを止めている」のいずれかに収束しやすいです。上から順にログと route print で事実を固め、設定をいじる前に「TUN をオフにしたときと何が変わるか」を比較すると、迷いが減ります。
ルールとログが読めるクライアントであれば、ブラックボックスな VPN より再現と調整がしやすく、同じトポロジでもトラブル時の手戻りが少なくなります。安定したビルドと分かりやすい UI を求めるなら、メンテナンス頻度の高い公式配布を起点に選ぶのが無難です。