目次
リモートアクセスと普段のプロキシを同時に使うときは、端末のアドレスに接続できないのか、名前で見つからないのか、インターネットに接続できないのかが分かりにくいことがあります。それぞれの結果を記録すると、ルーティング、名前解決、既定の接続経路のどこを調べるべきか判断できます。単独では動く二つのツールも、同じ端末上で併用時の動作を確認する必要があります。
同時起動でだけ切断する場合のルートと名前解決の比較
Tailscale と Clash TUN を同時に動かしたときだけ失敗する場合に、下の表で共通のルート、DNS、既定の接続経路を確認します。どちらかが単独でも失敗する場合は、そのツール自体の設定を調べてください。併用による競合として扱わないようにします。
三つの状態を個別に記録します。Tailscale だけ、Clash だけ、両方を有効にした状態で、それぞれ一つの tailnet IP、一つの tailnet デバイス名、一つのローカルネットワークアドレス、一つの公開アドレスをテストします。IP とデバイス名で結果が異なれば、ルーティングと MagicDNS の問題をすでに切り分けられます。
三組の比較から分かること
| 結果 | 可能性の高い問題 |
|---|---|
| 100.x アドレスにもデバイス名にも到達できない | Tailscale サブネットが TUN またはデフォルトルートに取り込まれている |
| 100.x アドレスには到達できるが、デバイス名では到達できない | MagicDNS または Clash DNS の取り込み順 |
| tailnet は正常だが、公開インターネットが切断される | 二つのツールがデフォルト出口または exit node を奪い合っている |
| 特定のローカルサブネットだけに到達できない | Tailscale のサブネットルートとローカルサブネットが重複している |
ルーティングテーブルを見れば、対象サブネットを奪ったネットワークアダプターが分かる
Tailscale はデバイスへ 100.64.0.0/10 の範囲からアドレスを割り当て、管理者が承認したサブネットルートを受け取る場合もあります。exit node を選ぶとデフォルトルートも追加されます。Clash TUN もルートを書き込むため、二つのスイッチだけを見ても競合は診断できません。
問題が起きている状態で、OS に応じて下のコマンドの結果を保存し、各ツールを単独で動かした結果と比較します。Linux では ip route show table all と ip rule を使い、メインテーブルだけでなくポリシールーティングも確認します。
100.64.0.0/10、公開したサブネット、家庭内 LAN、既定ルートが指すインターフェースと、テーブルやルールによる選択を調べてください。同じテーブル内では、同じプレフィックスの metric を比較します。
# Windows
route print
# Linux
ip route show table all
ip rule
# macOS
netstat -rnデフォルトのインターネット出口は一つのツールだけに任せる
Tailscale exit node と Clash TUN はどちらもデフォルトのインターネット通信へ影響します。目的が Tailscale 経由で自宅の NAS へアクセスし、公開通信の振り分けを Clash に任せることだけなら、このデバイスで Tailscale exit node を選ばないでください。
会社がすべてのインターネット通信を指定の Tailscale exit node に通すよう求めている場合は、Clash の対象を特定のアプリやプロキシポートに限定し、この組み合わせが組織のポリシーに合うか確認します。両方が既定の出口を設定していると、ときどき接続できても、経路の優先順位（metric）が一時的に機能しているだけかもしれません。設定が安定している証拠にはなりません。
tailnet の除外範囲とサブネット重複への対処
Clash Verge Rev など、TUN から任意のサブネットを除外できるクライアントでは、100.64.0.0/10、実際に使う家庭内 LAN、Tailscale の管理コンソールで承認した advertised routes を除外範囲へ追加できます。
他人のプライベートサブネットをすべてコピーしないでください。除外範囲が広すぎると、本来 Clash で処理すべき接続まで直接外へ出てしまいます。
Mihomo のルールでこれらのサブネットを明示的に DIRECT にすることもできますが、ルーティング層の除外とルール層の DIRECT は完全に同じではありません。ルールが判断するには、接続が先にコアへ入る必要があります。100.x のリクエストが Clash の接続記録に現れない場合はシステムルートを直接確認し、記録に現れてプロキシへ一致する場合はルールを調整してください。
自分のネットワークに合わせて入力する
- 100.64.0.0/10 の tailnet アドレス範囲
- 自宅またはオフィスで実際に使う LAN サブネット
- Tailscale コンソールで承認済みのサブネットルート
- Docker、WSL、仮想マシンで実際に tailnet と重複するサブネット
Tailscale のサブネットルートが 192.168.1.0/24 を公開し、現在いるカフェや自宅も 192.168.1.0/24 を使用している場合、システムはアドレスだけではどちらへアクセスするか判断できません。Docker と WSL2 も独自のプライベートサブネットを追加するため、競合がコンテナやサブシステム内だけで発生する場合があります。
ネットワーク範囲が重なる場合は、自分で管理できる LAN、Docker、仮想マシンのアドレス設計を優先して変更します。同じ範囲の経路優先順位を繰り返し上げ続けても、ネットワークの切り替え、スリープ復帰、更新後に再び動作しなくなる可能性があります。
IP では到達できるのにデバイス名で失敗する場合は、ルーティングではなく MagicDNS を修正する
100.x アドレスへ直接アクセスできれば、tailnet へのルートは概ね存在しています。それでもデバイス名の名前解決に失敗する場合、Clash DNS、ブラウザの DoH、システム resolver のいずれかが tailnet の名前を Tailscale の DNS 設定へ渡していない可能性があります。
tailscale status で対象デバイスのアドレスを取得し、OS 標準の名前解決ツールで短い名前と完全な tailnet 名を比較します。プラットフォームによっては nslookup がシステムの DNS 設定を参照しないため、その結果だけで MagicDNS が機能していないとは判断できません。
macOS では dscacheutil -q host -a name DEVICE_NAME を実行します。DEVICE_NAME を短い名前に置き換え、name と ip_address を確認します。返された完全な tailnet 名でもう一度照会し、アドレスを対象デバイスと照合してください。
調査中はブラウザー独自の DoH を無効にし、Clash の nameserver-policy またはローカルドメインの除外を確認してください。tailnet 名を公開 DNS へ転送しないでください。
スリープ復帰や Wi-Fi 切り替え後の障害は、再接続後のルートと名前解決を比較する
ノートパソコンのスリープ復帰、有線から Wi-Fi への切り替え、スマートフォンのテザリングへの接続後は、両クライアントの再接続を待ち、ルーティングテーブルと名前解決の結果を比較します。決まった順序で片方を再起動して復旧するなら、起動や再接続の処理を調べる手掛かりになります。ただし、復旧しただけで原因は断定できません。前後のルートと名前解決の記録から、何が変わったか確認してください。
両方のクライアントを更新しても繰り返し発生する場合は、自動起動時の競合を減らします。システムのネットワークが準備できてから必要なトンネルを起動し、Tailscale exit node を同時に自動選択しないでください。障害と無関係な設定まで消去されるため、毎回ネットワーク全体をリセットしないでください。
Tailscale での内部ネットワークへのアクセスと、Clash でのインターネット通信の振り分けは、どちらも正常？
同じテスト周期で検証する
tailnet IP へアクセス
100.x のルートが引き続き Tailscale に割り当てられていることを証明します。
tailnet 名へアクセス
MagicDNS または専用の名前解決が引き続き機能することを証明します。
公開済みサブネットへアクセス
承認済みの subnet route が Clash に取り込まれていないことを確認します。
公開インターネットへアクセスして Clash の記録を確認
通常の振り分けが引き続き想定したポリシーで処理されることを証明します。
tailnet IP、デバイス名、公開したサブネット、インターネットへの要求のうち失敗した項目に応じて、ルート、DNS、サブネット、既定の出口を確認します。