Tailscale と Clash を同時に使うときのルーティングと DNS：MagicDNS・サブネットルート・分流例外の段階チェック（2026）
Tailscale（フルトンネル、MagicDNS、サブネットルート／Exit Node など）と Clash（TUN やシステムプロキシ、細かい 分流ルール）を同じ端末でオンにすると、「ブラウザで何も開けない」「国内サイトだけ妙に遅い／海外出口のように見える」「社内の *.ts.net だけ名前解決が変」といった相談がよく寄せられます。原因は単一のトグルではなく、OS のルーティングテーブルでどちらが優先されているか、DNS の問い合わせ先がどこへ流れているか、Clash のルールが Tailscale 向けトラフィックを誤ってプロキシへ送っていないか、という三層に分かれがちです。本稿はその三層を上から順に潰すチェックリストに整理します。WSL2 や Docker Desktop、Hyper-V、Linux の systemd-resolved 単体に偏った稿とは棲み分けし、ゼロトラストのオーバーレイとルール型プロキシが同居するときの典型だけに絞ります。利用は法令と各サービスの利用規約の範囲で行ってください。
この記事で分かること
Tailscale 側で Use Tailscale subnets／Exit Node／フルトンネル的な挙動の有無を確認し、OS が見ているデフォルトルートが Clash の仮想インタフェース側に寄りすぎていないかを切り分けできます。MagicDNS（多くは *.ts.net や関連ゾーン）と Clash の dns セクション（fake-ip、プロファイル内の nameserver）が二重になっていないかを、問い合わせ経路の観点で整理できます。最後に、Tailscale のオーバーレイ帯域（典型は 100.64.0.0/10 系の広いレンジ）や制御プレーン向けホスト名を DIRECT へ寄せる分流例外の考え方と、ルール順の落とし穴を持ち帰れます。
他のトラブルシュート記事との棲み分け
WSL2 で Git や npm がホストの Clash を無視する話は、Linux ディストリビューションと Windows ホストのループバックの取り違えが主役です。Docker Desktop と Windows 11 の Clashはエンジンが別スタックな点が中心で、Hyper-V の VM がホストの Clash に届かない件は NAT とファイアウォールの層が厚いです。Linux 単体の systemd-resolved と Clash DNSは、オーバーレイ VPN が無い前提の話が多いです。本稿は「Tailscale の Control Plane や peer へ行くべき経路」と「Clash が握っている fake-ip／TUN のデフォルト」が同じ端末の同じ宛先で衝突するケースにフォーカスします。
起きやすい症状の型（三つに分類する）
(A) 全体的に不通・激遅：Clash の TUN がデフォルト経路を握り、Tailscale のトンネルや サブネットルートの方へパケットが届かない／逆に Tailscale が広い経路を持ちすぎて Clash の期待と逆転する、というルート優先度の話になりやすいです。(B) 国内向けだけ海外ノードに吸われる：GEOIP や巨大な RULE-SET、MATCH の締め方と、実際の宛先 IP の見え方がズレ、結果として意図しない出口へ流れる——ここは 国内向け直結を核对する GEOIP チェックリスト と思想が近いですが、Tailscale の DNS が返す IPがその判定を歪めることがあります。(C) 名前解決だけ妙：MagicDNS が有効なのに OS や Clash の DNS が別のリゾルバへ流れ、*.ts.net が期待どおり解けない、逆に一般ドメインだけ Clash 側の fake-ip に寄ってしまう、といった層です。
ステップ1：Tailscale 側のスイッチを「言葉のまま」確認する
管理コンソールや端末アプリのラベルは版で変わりますが、確認の芯は一定です。Exit Node を他ノードに委ねているか、サブネットルート（自宅 LAN やクラウド VPC を Tailscale 側から広げる設定）をこの端末が受け入れているか、Use Tailscale DNS／MagicDNS 相当がオンか。フルトンネルに近い挙動では 0.0.0.0/0 のような広い経路がオーバーレイに乗り、OS のルート表に複数の「デフォルトに見える行」が並ぶことがあります。ここをメモだけでも残すと、後から Clash を切ったときとの差分が比較しやすくなります。
ステップ2：OS のルーティングテーブルで「誰が勝っているか」を見る
Windows なら route print や新しい Get-NetRoute 系、macOS／Linux なら netstat -rn や ip route（ip -4 route）が定番です。見るべきは default に相当する行のインタフェースとメトリック、および Tailscale の utun／tailscale0／Windows の Tailscale 仮想アダプタにぶら下がる特定プレフィックスです。Clash の TUN が別の仮想 NIC を立てている場合、メトリックが低い（優先される）側へデフォルトが寄ると、「Tailscale では届く筈のサブネット」や「Exit Node 経由の広い経路」が期待とズレます。
ここでの結論は「片方をオフにせよ」ではなく、どの送信元アプリケーションがどのテーブルエントリに乗るかを分ける材料を集めることです。例えば「Tailscale だけ別テーブルにいるはず」が実際には統合テーブルで負けている、など。企業端末では管理者ポリシーでルートが固定されていることもあり、その場合はローカル調整の前に運用ルールの確認が先です。
ステップ3：Clash の TUN／システムプロキシと「重なり」を整理する
TUN モードはカーネルの転送経路に近いところで動くため、Tailscale のオーバーレイと同じ「既定経路を握る役」の層に来やすく、衝突の体感が大きくなります。システムプロキシ中心の構成は表面だけ見ると穏やかでも、プロキシ非対応のプロセスは別経路へ落ちるため、症状がアプリによってブレます。まずはクライアントのドキュメントに沿って、strict route 相当や auto route 相当、stack の選択（実装依存）がどうデフォルトルートに作用するかを読み、一時的に TUN を外して再現が消えるかを見ると切り分けが速いです。
TUN を切ると別の問題が露出する場合は、それはそれで手がかりです。「TUN ありきでしか再現しない」のか「プロキシだけでも再現する」のかをメモしてから、YAML の rules に進みます。
ステップ4：MagicDNS と Clash DNS を「上流の取り違え」で見る
MagicDNS を有効にしていると、Tailscale が名前解決の一部を担い、*.ts.net のようなゾーンがインターネットの通常 DNS とは別経路で応答されることがあります。一方 Clash は dns で fake-ip を使うと、アプリが最初に見る IP と実トラフィックの SNI／証明書の組が複雑になります。両方が「自分が権威だ」と主張するわけではありませんが、OS のリゾルバ設定（Wi‑Fi の DNS、DHCP、VPN インタフェース付き DNS）と、Clash が listen するローカル DNS、Tailscale が挿入する DNSの三本が食い違うと、ブラウザでは動くのに CLI だけ死ぬ、などのブレが出ます。
切り分けの実務的な順番は、(1) OS で *.ts.net（または社内で使っている MagicDNS の実例名）を問い合わせ、期待するレンジに解けるか、(2) Clash を一時停止した同じ問い合わせと比較、(3) Clash 再開後に DNS ログ（実装があれば）で upstream がどこか、です。sniffing まわりで SNI とドメインルールが噛み合わない話は Mihomo の sniffing と DNS に寄ります。MagicDNS 側は設定変更後、端末のキャッシュが残るので、検証のたびにシークレットウィンドウや短い TTL の検証ホストを使うと迷子になりにくいです。
ステップ5：Clash の分流例外——オーバーレイと制御プレーンを DIRECT へ
ルールは環境ごとに異なりますが、方向性としては次の二つです。(1) Tailscale のオーバーレイアドレス空間。多くの環境で-peer 間は 100.64.0.0/10（RFC 6598 共有アドレス空間）に収まることがあり、ここを誤ってプロキシへ送るとレイテンシだけでなく経路自体が成立しません。(2) 制御プレーン・認証・設定配信に使うホスト名。ドメインは版と運用で変わるため、公式の一覧や自分のテナントで実際に見えた FQDN を Rule ログから拾って育てるのが安全です。
# Conceptual — replace DIRECT and refine CIDR per your tailnet
rules:
- IP-CIDR,100.64.0.0/10,DIRECT,no-resolve
- DOMAIN-SUFFIX,tailscale.com,DIRECT
- DOMAIN-SUFFIX,ts.net,DIRECT
# ... your normal GEOIP / RULE-SET / MATCH ...
no-resolve を付ける行は実装と順序の解釈に注意が必要です。上から先にマッチした行が勝つ前提で、より広い RULE-SET が先に食い込んでいないかを カスタムルールの優先順位 の視点で確認してください。国内サイトが海外へ流れる典型は GEOIP と「中国本土バイパス」 と合わせ読みすると、Tailscale 絡みの取り違いか純粋なルール順の問題かが切り分けやすくなります。
ステップ6：ログを正にした一段ずつの A/B
-
1
再現手順を固定する
同じ URL、同じアプリ、可能なら同じネットワーク。Tailscale の Exit／サブネットのオンオフも含め、変数を一つに絞ります。
-
2
Clash の接続ログでポリシー名を確認
問題のフローが DIRECT か、どの proxy-groups か。Tailscale peer 宛のフローまでプロキシに落ちていないかが第一検知です。
-
3
ルート表のメトリックを Before / After で比較
Clash TUN のオンオフ、Tailscale の Exit のオンオフで default がどう入れ替わるか。写真やテキストログで十分です。
-
4
DNS の問い合わせ経路を二系統で比較
Clash 停止時と稼働時で同じ名前を引き、返ってくるアドレス種別が fake-ip か実 IP かを確認します。
補足：Exit Node と「全トラフィック」の誤解
Exit Node を使うと、インターネット向けの出口が物理的な自宅回線ではなく別拠点に見えるようになります。これ自体が悪いわけではありませんが、国内限定のサービスの判定や、企業のゼロトラスト製品のログと期待がズレる原因になります。国内ドメインを DIRECT に戻すルールと併用するときは、Exit がオンでも国内は直結、といった意図の優先順位を YAML の上からの順に正直に書く必要があります。proxy-groups の名称と rules の綴りが一致しているかは proxy-groups ガイド で押さえてください。
セキュリティとコンプライアンス
ルートや DNS をいじる作業は、企業端末では情報システム部門のポリシーに抵触しやすいです。split tunneling を広げすぎるとデータ損失防止の前提が崩れる場合もあります。本稿は個人の検証端末でのトラブルシュートを想定し、組織の許可なくインフラ側の設定を改変する手順は扱いません。不正な通信の隠蔽や規約違反の回避を目的とした記述は意図していません。
まとめ
Tailscale と Clash の同居トラブルは、多くの場合 ルーティングテーブルでの優先度争い、MagicDNS と Clash DNS（fake-ip を含む）の取り違え、オーバーレイ帯域や制御系ドメインを誤ってプロキシへ送る分流の三つに分解できます。仮想化や別ホスト向けの話は WSL2・Docker・Hyper-V、Linux 単体の話は Linux DNS に任せ、本稿の順に確認すると手戻りが減ります。
用語とログの読み方は チュートリアル で整え、ルールの書き方は カスタムルール と併読すると、このチェックリストを自分のプロファイルに写し替えやすくなります。クライアントは 本サイトのダウンロードページ から揃えると、記事どうしの対応関係が追いやすく、トラブル時にログベースで戻せる運用につながります。