1 なぜ「分流」以前に壊れて見えるか
Clash の rules はアプリケーションがソケットを開いたあと、どのプロキシへ送るかを決めるレイヤです。一方、Tailscale はカーネルに宛先プレフィックス向きの経路を追加し、場合によってはデフォルトゲートウェイやインターフェースのメトリックまで変えます。両者が同時に有効だと、「名前解決がどこへ行ったか」「パケットがどの NIC から出たか」が、GUI のログだけでは追いにくい組み合わせになります。
典型例としては、Tailscale のサブネットルートやExit Nodeが広い宛先へ経路を広げている一方で、Clash の TUN が別の仮想アダプタでパケットを取り込む——このとき最長一致ルートとメトリックの結果、意図しないネクストホップが選ばれることがあります。また DNS では、Tailscale の MagicDNS が独自の検索ドメインやフォワーダを挟み、Clash の dns ブロックや FakeIP の前提と解決チェーンがずれると、ルールは合っているのに実トラフィックだけ別出口になる、という見え方になります。
2 Tailscale 側で押さえる設定（管理コンソールとクライアント）
Tailscale はノードごとに 100.x.y.z のCGNAT レンジアドレスを持ち、ピア間はコントロールプレーン経由で鍵交換されます。ここにSubnet Router（公開した LAN プレフィックス）やExit Node（インターネット出口を別ノードに任せる）が加わると、ローカルのルート表は「普段の ISP」とは別の論理的な構成になります。MagicDNS をオンにすると、クラスタ内ホスト名や検索サフィックスが OS のリゾルバ設定へ反映され、通常の「ISP の DNS のみ」という前提が崩れます。
トラブル時はまず Tailscale の公式クライアントで、Exit Node を止める／サブネット経由を一時オフにするなど、広い宛先へ作用する機能を切り分けます。社内ポリシーやチーム運用で無断変更できない場合は、読み取り専用として「どのルートが追加されているか」だけをメモし、後述の OS コマンドと突き合わせてください。
3 調べる順番（この順が無駄が少ない）
次の順で確認すると、原因の切り分けが速くなります。① Tailscale を切った状態で Clash 単体が期待どおりか（逆も試す）。② OS のデフォルトルートと、問題の宛先に対するネクストホップ（どのインターフェースか）。③ DNS がどのアドレスへ問い合わせているか（MagicDNS／システム／Clash のスタブ）。④ Clash の TUN スタックや dns.enable、listen アドレス。⑤ 必要なら YAML の rules とプロキシグループ。
① で「片方を止めると直る」なら、競合はほぼ経路か DNSです。⑤ だけいじっても再現する場合は、まだ②③に戻った方が早いです。企業 VPN と似た整理はWindows の企業 VPN と Clash の記事にも共通しますが、Tailscale はユーザー管理下でポリシーが読みやすい一方、Exit Node など出口を広げる機能がポイントになります。
4 Windows：ルートテーブルとメトリック
管理者権限のコマンドプロンプトまたは PowerShell で、IPv4 の経路一覧を取得します。クラシックには次のコマンドが使われます。
route print -4
PowerShell では Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric, DestinationPrefix のように並べ替えると、デフォルト（0.0.0.0/0）や広いプレフィックスがどのインターフェースに載っているかが把握しやすいです。Tailscale アダプタと Clash／Mihomo の TUN アダプタが両方見えたら、メトリックが低い方が優先されやすいという大雑把な法則と、より長いプレフィックス一致が先に当たることの両方を意識してください。
インターフェースの一覧は Get-NetIPInterface でメトリックも確認できます。変更はネットワーク設定やレジストリに依存するため、恒久変更よりどのアダプタが競合しているか特定するための観察に留めるのが安全です。Wi-Fi と有線の切り替え、VPN／Tailscale の再接続のたびにルートが書き換わることもあるため、スナップショットは接続直後と再現操作後の二枚取りが実務的です。
5 macOS：経路一覧とサービス順
ターミナルではルーティングテーブルを次のように確認できます。
netstat -rn -f inet
default の行が複数ある場合、参照順やインターフェースごとのスコアが重要になります。Tailscale がインストールすると Network 環境設定や DNS の順序にも影響することがあり、システム設定の「詳細」や scutil --dns の出力とあわせて、どのリゾルバが先に試されるかを確認します。再接続では短時間で経路が切り替わることがあるため、問題が「特定アプリだけ」のときは、そのアプリがキャッシュしている名前解決結果も疑ってください。
Apple のプラットフォームでは独自のネットワークスタックやプライバシー機能も絡むため、トンネル製品を複数載せるほど再現手順のログが重要になります。プロキシ設定がシステム／ユーザー単位で異なる場合は、メニューバーからプロキシを一時無効にして挙動が変わるかも試してください。
6 DNS：MagicDNS と Clash の「DNS ハイジャック」の両立
Tailscale の MagicDNS は、ノード名や検索パスをチーム内で解決しやすくする一方、OS の DNS サーバー一覧や検索ドメインを変えます。Clash／Mihomo は通常 127.0.0.1 や TUN 側のアドレスへスタブリゾルバを置き、そこから DoH／FakeIP などへ二段で処理します。この二段構えが、MagicDNS のフォワーダや検索ドメインと順序が逆転すると、「ブラウザだけ別 DNS」「CLI だけ名前が変」といった症状になります。
まず OS のリゾルバ設定で、上位 DNS が誰かを確認します。次に Clash の dns セクションで listen と enhanced-mode（FakeIP）を見直します。細かな設定パターンはMihomo の DNS／FakeIP の実務記事に譲りますが、Tailscale 併用時は「MagicDNS を一時オフにして再現するか」が切り分けの一本になります。ブラウザだけおかしい場合はChrome／Edge のセキュア DNSもセットで疑ってください。
7 Clash 側：TUN とシステムプロキシの段階導入
経路競合が強い環境では、いきなり TUN ではなくシステムプロキシのみでブラウザや対応アプリを試し、問題が限定されるかを見ます。そのうえで TUN を使う場合は、クライアントの「自動ルート」「スタック」などのオプションがあれば、Tailscale の経路とどちらが先にパケットを受けるかの説明に役立ちます。詳細な TUN の挙動はClash Verge Rev の TUN ガイドと併読すると、ログの読み方が揃いやすいです。
tun の auto-route や除外インターフェースに関する項目がある場合は、Tailscale のインターフェース名を除外リストに入れる――といった運用がドキュメントやコミュニティに例として出ることがあります。実際の名前は環境依存なので、前述の route print／netstat で確認したラベルと突き合わせてください。設定ファイルを増やすほど将来の自分が読みにくくなるため、変更は一つずつコミットするイメージが安全です。
8 「ループ」や異常に見えるときの見分け
パケットが同じトンネルを往復したり、デフォルトが二重に載ったりすると、タイムアウトや「繋がったり切れたり」に見えます。経路ループの疑いがあるときは、ICMP や traceroute が期待するインターフェースから出ているか、外向きの第一ホップがどこかを確認します。DNS に関しては、FakeIP の IP が実サーバと混線していないか、fallback と nameserver-policy が意図どおりかをDNS 記事の観点から追います。
「Tailscale のピアには ping が通るがインターネットだけ不通」など、スコープで症状が分かれるときは、Exit Node やサブネットルートの対象プレフィックスが広すぎないかを整理します。ここは組織のルーティング設計に近い領域であり、個人の YAML だけでは完結しないことがあります。
9 すぐ使えるチェックリスト
- Tailscale をオフにしたとき／Clash をオフにしたとき、どちらで症状が消えるか。
- デフォルトルートと問題の宛先のネクストホップが、想定の NIC か（Windows／macOS で確認）。
- MagicDNS と Clash のスタブのどちらが先に名前解決を受け持っているか。
- TUN とシステムプロキシを切り替えたときの挙動差。
- ブラウザのセキュア DNS が別経路になっていないか。
- Exit Node／サブネットルートを狭める・止めると改善するか。
このリストは「ルールの行を増やす前」の停止観察用です。ログに残すときは、個人の実 IP や組織の内部プレフィックスが映らないようマスクしてください。
10 まとめ
Tailscale と Clash はどちらも「ネットワークの見え方」を大きく変えるツールです。併用時に問題が出たら、まずルートの優先順位（どの仮想 NIC がデフォルトや広い宛先を握っているか）と、次にDNS の入口（MagicDNS／OS／Clash のスタブの順）を確認すると、分流ルールに手を入れる前にかなりの事象を説明できます。Windows は route print／Get-NetRoute、macOS は netstat と scutil --dns が手に取りやすい出発点です。
長期的には、チーム内で Tailscale の Exit／サブネットをどう配るかと、手元の Clash プロファイルを同じ文脈で設計すると運用が楽になります。クライアントの選択では、ログが読みやすく Mihomo と組み合わせやすい Clash Verge Rev を使うと、経路が変わったあとも接続履歴で追いやすいというメリットがあります。インストールや入手経路は本站のダウンロードページからどうぞ。ソースや Issue は GitHub でも参照できますが、パッケージの第一入手先として本站をおすすめします。
