Tailscale と Clash を同時に使うときの TUN 衝突・LAN 迂回・ルート優先度:段階的な直し方
Tailscale のような mesh VPN と Clash の TUN を両方オンにすると、「インターネットは行くのにプリンタに届かない」「NAS の Web UI だけ開かない」「片方を止めると直る」といった 二重トンネル特有の症状が出やすくなります。原因は単一ではなく、仮想アダプタの積み重ね、デフォルトルートの奪い合い、RFC1918 など私有アドレス空間をどちらが握るか、そして DNS の返答が絡み合います。本稿では推測で設定を総入れ替えせず、TUN スタックとキャプチャ範囲→LAN・私有アドレス空間の迂回(bypass-private-network など)→OS 側のルート優先度(メトリック)の順で切り分ける手順をまとめます。同様の挙動は ZeroTier や WireGuard を常時張っている環境でも起こり得ます。
なぜ「二つ目のトンネル」で壊れやすいのか
Clash の TUN はカーネルに近い位置でトラフィックを捕まえ、ルールに従ってプロキシへ送ります。一方 Tailscale は MagicDNS、サブネットルート、Exit Node を通じて別のオーバーレイを張ります。どちらも「システム全体のパケット」を意識し始めると、宛先が 192.168.x.x や 10.x のときにどのインターフェースへ出すかがぶれます。ブラウザやファイル共有はタイムアウトしやすく、逆に「Tailscale だけ切ると全部正常」のように見えることが多いです。
典型的には次のどれか、あるいは複合です。
- デフォルトルートが二重:どちらの TUN も 0.0.0.0/0 を握ろうとし、メトリック勝ちの片方に偏る。
- 私有レンジが「プロキシ側の仮想スタック」に吸われる:LAN のゲートウェイへ直行せず、意図しない経路に着地する。
- DNS の分裂:MagicDNS と Clash の
fake-ipが同居し、名前は解けるが実パスが食い違う。 - MTU・断片化:二重カプセル化で ICMP フラグメント周りが厳しく、表面上は「たまにだけ切れる」。
権限とポリシー
会社端末・学内ネットワークでは VPN やトンネルの二重化がポリシー違反になることがあります。自分が変更してよい機器の範囲で試し、契約と法令を守ってください。
ステップ 1:どちらの TUN が「外側」か把握する
まず起動順と優先度をメモします。同時起動ログインなら、ユーザが後からオンにしたクライアントが表の症状を押しやすい、という経験則もありますが確定ではありません。Windows なら「アダプタのメトリック」、Linux なら ip route の default、macOS ならネットワークサービスの順序、と OS ごとに見る場所は違います。
切り分けとして、一時的に Clash の TUN だけ、続けて Tailscale だけ、のように単独で動かし、LAN 192.168 系への ping や SMB が通るかを比べます。両方オンでだけ壊れるなら、以降の「迂回」と「ルート」に焦点を絞れます。Windows の初期セットアップ全体は 「Clash for Windows 完全設定ガイド」、macOS は 「Clash Verge Rev の初回設定」を先に完了させておくと、ここでの変数が減ります。
メモのしかた
症状ごとに「宛先 IP」「プロトコル」「Clash のログ上の policy」「Tailscale の ping / netcheck」の四点を残すと、あとから誰が勝ったルートか追いやすくなります。
ステップ 2:私有アドレスと LAN を Clash から「外す」
Clash Meta 系では TUN 設定の bypass-private-network(名称は実装・GUI 表記で揺れる)を true にし、RFC1918 相当の宛先を TUN で捕捉しないようにするのが定石です。これにより、家庭内 NAS やプリンタ、ルータ管理画面へは可能な限り物理 LAN のまま直行しやすくなります。
ただし「職場の 10.0.0.0/8 をプロキシ経由で触りたい」のような要件があると、単純な迂回と衝突します。その場合はケースごとの対象レンジを狭めるか、Clash のルール側で DIRECT を先に置くか、Tailscale のサブネットルートを 意図した順で OS に見せるか、とトレードオフになります。雑に広い MATCH だけ載せた購読を足すと、私有レンジまで誤ってプロキシに流すことがあるので、インポート直後はログで私有宛先が DIRECT に落ちているかざっと確認してください。
# Illustrative tun section — field names vary by client build
tun:
enable: true
stack: mixed
auto-route: true
strict-route: false
bypass-private-network: true
strict-route をむやみに強くすると、クライアント実装と OS の組合せで「ローカルサブネットも強く縛る」副作用が出る例があります。変更は一項目ずつ、都度 LAN 疎通を見ます。
mixed-port で LAN からのみプロキシを晒す話題は 「LAN から mixed-port を使う」の稿と役割が近いですが、本稿は TUN と mesh VPN のルート正面衝突に寄せています。
ステップ 3:Tailscale 側のサブネット・Exit Node を揃える
Tailscale で subnet router や Exit Node を使っていると、OS のルートテーブルに tailscale0 系のエントリが増えます。Clash も auto-route で似たことをするため、どちらが「自宅 LAN 192.168.1.0/24」用の経路を握るかがぶつかります。
実務的には次を順に確認します。
- そのマシン自身の LAN へのアクセスに subnet router が本当に要るか(不要ならオフに近づける)。
- Exit Node オン時のみ症状が悪化するなら、Exit を一時オフにしてデフォルトの奪い合いを見る。
- MagicDNS が返す A レコードが、LAN 実体と Tailscale のどちらを指しているか(ブラウザと
pingで比較)。
社内ドメインや機器名が Tailscale 名とローカル名の両方で解決できる環境では、名前解決の結果がルート選択を決めてしまうため、IP での疎通試験を一度挟むと早いです。
ステップ 4:OS のルート優先度(メトリック)を読む
TUN を二枚抜きすると、より低いメトリック(Windows の言い方)/高い優先度の default が勝ちます。症状が「Clash をオンにした直後だけ」なら、Clash が入れたルートが一時的に上に来ている可能性があります。逆に再起動後にだけ直るなら、ログオン時の起動順で毎回メトリックが変わっている可能性もあります。
ここでは OS ごとのコマンドの暗記より、「default が何本あるか」「LAN サブネットは interface 直結かオーバーレイか」を眺める習慣を優先してください。Linux であれば ip route show table main、Windows なら route print の IPv4 部、macOS ならネットワークユーティリティや netstat -rn が出発点になります。
| 観点 | 確認すること | おかしいときの匂い |
|---|---|---|
| default の本数 | TUN が複数あるか | 片方を外すと即直る「どちらか一方だけ」 |
| 192.168/10/172.16 | ローカル直 or tailscale | NAS や管理 UI だけ遅延・タイムアウト |
| DNS サーバ順 | MagicDNS / Clash DNS | 名前は ping できるがアプリだけ失敗 |
ステップ 5:DNS と fake-ip の食い違い
TUN 併用時、Clash の fake-ip と Tailscale の名前解決が別の宇宙を見ていると、ルール上は DIRECT でも実際のコネクト先がズレることがあります。切り分けは 「DNS と fake-ip」の流れを踏襲し、fake-ip オフの比較実験や、該当ドメインだけ redir-host 寄りに寄せる、などを検討します。
mesh VPN ではマシン名ベースの名前が増えるため、Clash のルールがドメイン前提だと取りこぼす場合があります。プロセスや IP 条件まで降りるなら Steam/Epic と TUNの稿の「プロセス優先」の考え方が参考になりますが、LAN 固定の私有 IP への通信ではそもそも TUN に載せない方が先です。
WSL2・仮想機との棲み分け
PC 上で WSL2 や仮想機を動かしていると、ブリッジ/NAT と TUN の組合せでさらに一段階ルートが増えます。ホスト側で直したつもりがゲストだけ壊れる、というパターンは 「WSL2 と Windows プロキシ」や 「VMware/Parallels とホスト」の各稿と合わせて読むと、どの「境界」でパケットが落ちているか整理しやすくなります。
うまくいかないときの安全な退避順序
全体が不安定なときは、次の順で影響範囲を狭めます。(1)Exit Node オフ(2)Clash TUN オフでシステムプロキシのみ(3)Tailscale オフで Clash のみ——のように、毎回一つだけ外して LAN・インターネット・社内オーバーレイのどれが戻るかを確認します。同時に二つ変えると原因が追えません。
最短チェックリスト
- 単独起動テスト(Clash TUN のみ/Tailscale のみ)。
bypass-private-network相当を有効化し、私有宛先が捕捉されていないかログで確認。- Tailscale の subnet・Exit が LAN と矛盾していないか。
- default ルートの本数とメトリック、DNS の先頭サーバ。
- fake-ip 実験と MagicDNS の併用条件の整理。
よくある質問
Tailscale 互換の Headscale でも同じ?
オーバーレイとルートを張る性質は同じため、症状の型は近いです。管理画面で誰が subnet を宣伝しているかを把握し、Clash 側のキャプチャ範囲と合わせてください。
Meta 以外の Clash でも?
TUN 実装と YAML キーはフォークで差があります。GUI の「私有アドレスをスキップ」「bypass LAN」などのラベルがそれに相当することが多いです。ドキュメントより実機ログを優先してください。
オンラインゲームだけ不安定
UDP と対称 NAT、カーネル型の反チートが絡みます。ゲーム本体は DIRECT に寄せ、二重 TUN を避けるのが先決です。ボイス UDP と TUN の相性は 「Discord ボイスと Clash TUN」の稿も参照してください。
まとめとクライアント選び
mesh VPN と Clash の共存は、どのトラフィックを TUN に載せるかがすべてです。購読ルールが巨大でも、私有レンジの扱い一つで家庭内機器が沈黙することがあります。ログを残しながら段階を踏めば、再発時の原因特定も速くなります。