目次
同じ機器にIPではアクセスできても、完全なドメイン名では失敗するなら、名前解決を確認する必要があります。ルーターとローカルネットワークの機器では問い合わせ先のリゾルバーが異なる場合があるため、別々にテストします。元の設定と管理手段を確保したうえで、どの変更で必要なサービスが使えるようになるか比較します。
Tailscale は接続中なのに、ルーターで名前解決できないのはなぜ？
OpenClashとTailscaleが同じOpenWrtルーターで動作していることを確認し、機器のIPと完全なts.net名でのアクセス結果を記録します。Tailscale DNSを受け入れた後にルーター自身のドメイン名へのリクエストが異常になる場合は、ルーター自身のDNSとローカルネットワークの機器の結果も記録してください。
OpenClash は 2026 年 10 月 12 日に v0.48.002 を公開しました。リリース説明では、ルーター自身の通信をプロキシ経由にしたときに accept-dns を有効にすると起きる可能性のある問題に対応するため、標準の Tailscale モジュールを追加したとしています。実際のモジュールは ts.net ドメインの問い合わせ先に Tailscale DNS を指定するだけです。あらゆる DNS、ルーティング、ファイアウォールの問題を解決するものではありません。
ルーター上の tailscaled が動作し、Tailscale に接続済みである必要があります。パソコンだけでデスクトップ版 Clash を使う場合や、別の LAN 端末で Tailscale を動かす場合に、ルーターのモジュール設定をそのまま使わないでください。未ログイン、MagicDNS 無効、端末オフライン、アクセス規則による拒否は、それぞれの問題を解決してから進めます。
デバイスの IP、完全なドメイン名、二つの DNS 応答を比較する
まず LAN アドレスから LuCI にアクセスします。OpenWrt と OpenClash の設定のバックアップ、現在のサブスクリプション、独自モジュールを保存し、プラグインと Tailscale のバージョン、ルーター自身の通信をプロキシ経由にする設定、変更前の accept-dns の値、モジュールの有効・無効を記録してください。管理手段が Tailscale 経由のリモート接続だけの場合は、再起動や DNS の変更を保留し、ローカルで管理できる方法を先に用意します。
ルーター上で Tailscale の状態を確認します。自分の管理コンソールから、オンラインのデバイス一台の完全な MagicDNS 名と IP を取得してください。同じサービスに IP とドメイン名の両方でアクセスして比較します。IP でも失敗する場合は、デバイス、サービス、ルーティング、アクセス権限を調べます。DNS モジュールだけで原因を判断したり、修復したりはできません。
以下の二回の nslookup では、例の名前を自分の完全な名前に置き換えてください。二回目の問い合わせ先には、現在のルーターのローカル DNS アドレスを使います。127.0.0.1 はよくある例にすぎないため、そのアドレスで実際に DNS サービスが動いていることを先に確認します。テストはすべてルーター上で行います。Tailscale DNS のアドレスを一般の公開 DNS と同じように全デバイスへ配布しないでください。
ルーターの DNS ハイジャックによって、指定したサーバーへの問い合わせがリダイレクトされることがあります。100.100.100.100 を指定しても、プラグインを迂回できたとは限りません。必要ならローカルで管理できる状態で元の設定を記録し、OpenClash を一時的に停止して、Tailscale は動かしたまま再テストした後、元に戻します。この間は LAN のプロキシにも影響するため、通信を中断してよい時間帯に行ってください。
Fake-IP モードでは、ローカル DNS が 198.18.x を返しただけで名前解決が壊れているとは判断できません。完全な名前で同じサービスにアクセスし、コアのログと合わせて実際の接続先を確認します。タイムアウト、SERVFAIL、NXDOMAIN、または IP では成功するのに名前では失敗することが、名前解決の経路をさらに調べる手がかりになります。
tailscale version
tailscale status
nslookup device.your-tailnet.ts.net 100.100.100.100
nslookup device.your-tailnet.ts.net 127.0.0.1比較結果に応じて次の確認へ進む
| 観察結果 | 次の手順 |
|---|---|
| デバイスの IP に到達でき、Tailscale DNS で名前解決できることも確認済みだが、ローカルでは名前によるアクセスに失敗する | 問い合わせが OpenClash DNS に渡っているか、動作中の設定で ts.net の名前解決ポリシーが欠落したり上書きされたりしていないかを確認してから、内蔵モジュールを試します。 |
| DNS ハイジャックの影響を除いても、Tailscale DNS で完全な名前を解決できない | まず tailscaled、ログイン状態、MagicDNS、名前の綴りを確認します。モジュールは Tailscale DNS サービスそのものの代わりにはなりません。 |
| ドメイン名は正しく解決できるが、サービスへの接続に失敗する | 接続先のサービス、Tailscale のルーティング、アクセス制御を調べます。当てずっぽうで DNS を変更し続けないでください。 |
| ルーターだけが通常の公開ドメインにアクセスできず、LAN デバイスは正常にアクセスできる | 両者の違いを記録し、ルーター自身の DNS と accept-dns を確認します。ts.net モジュールがないことを、そのまま原因と決めつけないでください。 |
動作状況ページから内蔵 Tailscale モジュールを有効にする
旧版にこの内蔵の入口がなければ、不明なスクリプトで更新を代用しないでください。今回の調整では、ルーター全体のファームウェア更新や設定の全リセットも必要ありません。
モジュールを現在の動作設定に反映する
実際のプラグインバージョンを確認する
文末の公式 v0.48.002 Release と従来の更新方法でプラグインを更新し、更新前のバックアップを残します。完了後は LuCI で実際の版を確認し、元のサブスクリプションで起動できるか調べてください。インストールに失敗した場合は、エラーとバックアップに応じて戻します。
動作状況ページから上書きモジュールを開く
サービス → OpenClash の動作状況ページに入り、上部の「上書きモジュール」ボタンを押します。開いたウィンドウの左側で、内蔵の Tailscale を選択してください。メニュー内の「上書き設定」ページとは別の入口です。
適用範囲を確認してからモジュールを有効にする
新規インストール時の内蔵 Tailscale モジュールは、既定で無効、適用範囲はすべての設定です。アップグレードで以前の設定を引き継ぎ、「未設定」と表示されてスイッチがない場合は、先にモジュールの歯車ボタンから、すべての設定または現在の設定ファイルのフルパスを指定してから有効にします。変更前の値を記録してください。内容の編集、コピーの作成、リモートサブスクリプションの更新は不要です。
再起動して動作中の設定を確認する
エディターを閉じ、動作状況ページで OpenClash を再起動します。実際に使われている dns.nameserver-policy で、+.ts.net が 100.100.100.100#DIRECT を指しているか確認してください。保存するだけ、またはファイアウォールを再読み込みするだけでは、モジュールは再適用されません。
公式モジュールの内容は以下のとおりです。既存のモジュールとの照合にだけ使ってください。[YAML] と nameserver-policy+ は OpenClash の上書き形式で、動作中の Mihomo 設定では nameserver-policy を使います。この全体をサブスクリプションの YAML に直接コピーしたり、同じモジュールを重複して追加したりしないでください。
[YAML]
dns:
nameserver-policy+:
'+.ts.net':
- 100.100.100.100#DIRECT100.100.100.100 は、この機器上の Tailscale が提供する DNS サービスのアドレスです。#DIRECT は、該当する DNS 問い合わせを直接接続にします。このモジュールは tailscaled を起動せず、Tailscale のルーティング、アクセス制御、accept-dns も変更しません。別のモジュールに同じドメインのポリシーがある場合は、エディター内の記述だけで判断せず、最終的に動作中の設定を確認してください。
accept-dns は無効にすべき？元の値を記録して比較する
モジュールを有効にするために、Tailscale DNS を一律に無効にしないでください。変更前の accept-dns が true で、その設定に合わせて通常のドメインへのアクセスに問題が発生する場合に限り、LAN 経由で管理できる状態で一度だけ無効にして比較します。元の値を先に記録してください。無効にすると、このデバイスは tailnet DNS 設定を受け入れなくなり、システムでの MagicDNS の短い名前や独自ドメインの名前解決に影響する可能性があります。
対応する Tailscale CLI では、tailscale get accept-dns で現在の値を確認できます。旧版では先にヘルプを確認し、コマンドが使えない場合は既存の設定記録から値を確かめてください。不明な値を true とみなしてはいけません。元の値を確認した後、以下のコマンドは今回の比較だけに使います。すべてのデバイスで false を使い続けることを勧めるものではありません。
tailscale set --accept-dns=falsetailscale set は明示したパラメーターだけを更新します。reset、再ログイン、経路の受け入れ、出口ノードのパラメーターを追加しないでください。無効にした後、同じ公開ドメイン、完全な ts.net 名、サービスへのアクセスを再テストし、違いを保存します。改善しなければ元の値へ戻し、DNS の変更を重ねないでください。
元の値が true なら、戻すコマンドは tailscale set --accept-dns=true です。元の値が false なら false のままにします。システムのリゾルバーが Tailscale DNS を受け入れる設定と、OpenClash が ts.net の問い合わせをこの機器の DNS に送る設定は別です。モジュールを有効にしても、システムの短い名前、ほかのプライベートドメイン、すべての LAN デバイスが自動的に使えるようになるわけではありません。
完全なドメイン名で復旧したら、ルーターと LAN も確認する
同じ実在する完全な ts.net 名を使い、先ほどの二つの DNS テストを繰り返してから、同じデバイスの同じサービスにアクセスします。Tailscale DNS が返す実際のアドレスは、そのデバイスの記録と一致する必要があります。ローカルの Fake-IP 応答は、実際のリクエストとログを合わせて確認してください。サービスへのリクエストが成功して初めて、そのアクセス経路が復旧したと判断できます。
モジュールが対象とするのは ts.net サフィックスだけです。短い名前、ほかのプライベートドメイン、Tailscale を使わないデバイスで失敗する場合は、それぞれの DNS、検索ドメイン、ネットワーク経路を引き続き確認します。LAN デバイスの問い合わせでも、設定済みのリゾルバーへ実際に渡されて初めてこのポリシーが使われます。ネットワーク全体のすべてのアプリが自動的に復旧すると考えないでください。
今回の変更の確認項目
- tailscaled が接続中で、テスト対象のデバイスとサービスに元の IP でアクセスできる
- 動作中の設定に想定した ts.net の名前解決ポリシーがあり、別のモジュールに上書きされていない
- ルーターで完全な MagicDNS 名を解決でき、実際のサービスへのリクエストも成功する
- 通常の公開ドメインは引き続き利用できる。実際に使うLAN端末から、名前解決とサービスへのアクセスを別途テストする
- OpenClash を通常どおり再起動してもポリシーが残り、同じ一連のテストが成功する
- 変更前のモジュールの状態と accept-dns の値を記録し、別途バックアップを保存した
復旧しない、またはほかのデバイスに影響した場合の戻し方
上書きモジュールのウィンドウに戻り、Tailscale モジュールの有効・無効と適用範囲を変更前の状態に戻します。OpenClash を再起動し、動作中の設定のポリシーが元に戻ったことを確認してください。accept-dns も一時的に変更した場合は、記録した元の値に戻し、通常のインターネット接続と従来の Tailscale 経由のアクセスを再テストします。設定ディレクトリ全体を削除する必要はありません。
アップグレード自体に失敗した場合は、インストール時のエラーと現在のデータを保管し、更新前のバックアップから元のプラグイン設定、サブスクリプション、独自リソースを復元します。設定の復元とプログラムのダウングレードは別の操作です。旧版プラグインが新版の設定をすべて読み込めるとは限りません。互換性を確認できない場合は、まず今回のモジュールを無効にし、以前使えていた方法へ戻してください。
それでも失敗する場合は OpenClash のデバッグログを生成し、プラグイン、コア、Tailscale のバージョン、ルーター自身のプロキシと DNS の設定、最終的なドメインポリシー、ルーターと LAN の結果の違い、IP・完全な名前・二つのリゾルバーによる比較結果を報告します。共有前にサブスクリプションのトークン、パスワード、デバイスの識別情報、プライベートドメインを削除してください。未加工のログ全体を公開してはいけません。