目次
両方の管理画面が稼働中でも、家庭内の端末では接続が不安定になることがあります。DNS ポートを何度も変えるだけでは原因を絞れません。問い合わせが最初に届くサービスと、その転送先を確認し、端末別のフィルタリング統計を残すか、ドメインを先にプロキシルールへ渡すかを選びます。その後、サービス停止時の名前解決の復旧も確かめます。
AdGuard と OpenClash の上流を互いに向けない
OpenClash と AdGuard Home はどちらも DNS を処理しようとしますが、役割は異なります。AdGuard Home はフィルタリング、書き換え、クエリ記録を担当し、OpenClash のカーネル DNS はドメイン解決とプロキシルールを連携させます。両者は共存できますが、一つのクエリを一方向にだけ進める必要があります。
各端末が DHCP から取得した DNS、ルーターの 53 番ポートでクエリを受け取るサービス、AdGuard の上流サーバー、OpenClash カーネルの待ち受けポートを書き出します。クエリが最終的に以前のサービスへ戻る経路が一つでもあれば、ループが発生します。
同じクエリは選んだ方向に転送します。別のプラグインも 53 を取り込むか DNS を転送する場合は、競合する取り込み設定の一方を無効にし、二つのサービスの順序を決めます。dnsmasq の上流も、その経路に合わせてください。
残したい機能に合わせて経路を選ぶ
| パス | クエリの方向 | 利点 | トレードオフ |
|---|---|---|---|
| AdGuard を前段にする | LAN の DNS 入口 → AdGuard → OpenClash DNS → 外部の上流 | AdGuard で端末ごとの記録を取りやすく、先にフィルタリングできる | OpenClash による LAN 53 の先行ハイジャックを無効にする必要がある |
| OpenClash を前段にする | LAN / dnsmasq → OpenClash → AdGuard → 外部の上流 | ドメインが先に OpenClash へ入り、Fake-IP とルールの経路を一元化しやすい | AdGuardには通常、ルーター/コアからの問い合わせしか見えず、端末ごとの区別が難しくなります |
LuCI のスイッチだけで判断せず、実際の待ち受けと転送を確認する
まず主な入口を特定する
| 受信箇所 | 一般的な役割 | 混同してはいけない点 |
|---|---|---|
| ルーターの TCP/UDP 53 | LAN デバイスが既定でアクセスする DNS の入口 | 同じアドレスとポートを dnsmasq と AdGuard が同時に占有することはできない |
| AdGuard Home の DNS 待ち受け | クエリを受け取り、フィルタリングして上流へ転送する | 3000 などの Web 管理ポートは DNS ポートではない |
| OpenClash カーネルの DNS | モードに従って名前を解決し、ルールと連携する | 一般的な内部待ち受けは 127.0.0.1:7874 だが、実際の値は稼働状況画面とログで確認する |
| ブラウザーの DoH / Android のプライベート DNS | 端末から外部へ直接名前を解決する | ルーター上の二つのサービスを迂回する可能性がある |
SSH で OpenWrt へログインし、53、OpenClash の内部 DNS ポート、AdGuard 用に設定したポートを、それぞれどのプロセスが待ち受けているか確認します。53 がすでに使われていれば、もう一方のサービスは起動できていない可能性があります。両方の画面で稼働中と表示されても、ファイアウォールのリダイレクトによって想定した順序が迂回されている場合があります。
ss -lntup | grep -E '(:53|:7874|:5335)'
uci show dhcp | grep -E 'server|port|noresolv'
logread | grep -Ei 'dnsmasq|AdGuardHome|OpenClash.*DNS' | tail -n 80まず次の結果を記録する
- TCP 53 と UDP 53 を待ち受けるプロセス
- AdGuard Home が実際に DNS を待ち受けるアドレスとポート
- OpenClash の状態画面に表示される DNS 待ち受けポート
- dnsmasq の現在の server の転送先
- ファイアウォールに DNS redirect / hijack が存在するか
- 変更前の状態へ復元できる OpenWrt と AdGuard の設定バックアップ
AdGuard のクライアント統計を残すなら、最初にクエリを受け取るようにする
この経路は「端末の 53 入口 → AdGuard Home → 127.0.0.1:7874 → OpenClash の外部上流」と表せます。OpenClash の DNS 設定でローカル DNS ハイジャックを無効にし、ファイアウォールが LAN の 53 クエリを先に横取りしないようにします。
AdGuard Home の「設定 → DNS 設定 → 上流 DNS サーバー」で、経路を分岐させるほかの上流を削除し、現在の OpenClash カーネルが DNS を待ち受けているアドレスだけを残します。
127.0.0.1:7874 は OpenClash のドキュメントでよく使われる例であり、そのまま使える固定値ではありません。OpenClash の状態、設定、ss の出力から実際のポートを確認してください。
AdGuard が 53 を使い dnsmasq を別のポートに移すか、dnsmasq から AdGuard に転送するかは、既存の OpenWrt 構成によります。転送を経由すると AdGuard には転送元しか見えず、端末ごとの統計を保持できない場合があります。同じ LAN クエリが AdGuard を通るのは一度だけにします。
変更後、クエリの順序に沿って各項目を確認する
AdGuard を起動できる
ログに bind: address already in use がなく、TCP と UDP の待ち受けがいずれも想定どおりである。
OpenClash DNS が内部ポートで待ち受けている
ローカルマシンで、7874 または実際のポートを Mihomo/OpenClash が使用していることを確認できる。
OpenClash による LAN DNS ハイジャックを無効にする
再起動後にファイアウォールと起動ログを確認し、AdGuard より先に横取りする規則がないことを確認する。
AdGuard から OpenClash だけへ転送する
クエリログにクライアントアドレスが表示され、新しい許可対象ドメインでレスポンスが得られる。
Fake-IP とルールの一貫性をより重視するなら、OpenClash が先にクエリを受け取るようにする
この経路では、OpenClash のローカル DNS ハイジャックを維持し、AdGuard Home 自身による LAN 53 のリダイレクトまたはハイジャックを無効にします。AdGuard は、たとえば 127.0.0.1:5335 のような競合しないローカルポート一つだけで待ち受けるようにします。次に OpenClash の「オーバーライド設定 → DNS 設定」にあるカスタム上流へ、この実際のアドレスを入力してください。
AdGuard の上流は、引き続き本当の外部 DNS を参照する必要があります。127.0.0.1:7874、ルーターの LAN:53、その他 OpenClash へ再び入るアドレスを指定してはいけません。
OpenClash が端末のクエリを受け取り、実際の名前解決が必要なときに AdGuard へ問い合わせます。Fake-IP クエリには仮想アドレスが直接返される場合があり、プロキシを使うドメインは接続先で名前解決される場合もあるため、AdGuard がすべてのドメインをフィルタリングするとは限りません。AdGuard のログでは、クライアントがルーターだけになることがよくあります。
LAN client
-> dnsmasq / OpenClash DNS hijack
-> OpenClash DNS
-> AdGuard Home 127.0.0.1:5335
-> external upstream DNS循環、ポート競合、フィルタリングの迂回の見分け方
ログに同じドメインが繰り返し現れ、その後 SERVFAIL になる
主な原因：OpenClash と AdGuard が互いを上流にしており、クエリのループが発生している
対処方法：問い合わせの順に各上流アドレスを記録し、前のサービスへリクエストを戻している設定を削除してください。
AdGuard のクエリログは空だが、Web ページは開ける
主な原因：クエリが AdGuard に届く前に OpenClash やファイアウォールで 53 に対する傍受を受けているか、Fake-IP、キャッシュ、端末独自の DNS で処理されている可能性があります
対処方法：AdGuard を前段にする場合は、競合するハイジャックを無効にし、NAT/nftables の規則順を確認する。
AdGuard の起動に失敗し、address already in use と表示される
主な原因：dnsmasq または別のインスタンスが、同じアドレスとポートをすでに使用している
対処方法：53 を待ち受けるサービスを一つに決め、内部転送には別のローカルポートを選ぶ。
コンピューターは正常だが、スマートフォンがときどきフィルタリングを迂回する
主な原因：IPv6 DNS、Android のプライベート DNS、ブラウザーの DoH が外部へ直接クエリを送っている
対処方法：テスト中は個別の暗号化 DNS をすべて無効にし、DHCPv6/RDNSS の配布内容も確認する。
OpenClash の停止後、家全体で DNS が機能しなくなる
主な原因：唯一の上流が、待ち受けを停止したカーネルポートを参照している
対処方法：変更前の記録を基に dnsmasq と AdGuard の上流設定を戻し、停止したポートを参照していないことを確認します。LAN 端末からキャッシュされていないドメインを問い合わせ、名前解決が復旧したか調べてください。
キャッシュによって問題が見えなくなることがあります。サービスの順序を調整した後は関連サービスを再起動し、テスト端末の DNS キャッシュを消去するか Wi-Fi へ接続し直して、アクセスしたことのないドメインを問い合わせてください。キャッシュ済みのサイトを繰り返し開いても、以前のレスポンスが残っていることしか確認できません。
フィルタリング、振り分け、停止後の名前解決を検証する
テスト用コンピューター一台から検収を完了する
端末の DNS を確認する
nslookup の出力にある Server は、予定したルーターまたは AdGuard のアドレスである必要があり、意図しない公開 DNS であってはいけません。
許可対象のドメインを問い合わせる
キャッシュされていないドメインで試し、クエリが実際に AdGuard へ転送されたか確認します。実際の名前解決が必要な場合、AdGuard/OpenClash は選んだ方向に処理するはずです。Fake-IP の応答だけでは、両方がクエリを処理した証拠にはなりません。
フィルタールールを確認する
AdGuard にテスト用ルールを一時的に追加し、実際に通過するクエリだけを対象にフィルタリング結果を確認してから、ルールを削除します。これだけでは、プロキシを使うすべてのドメインがフィルタリングされるとは確認できません。
プロキシルールの動作を確認する
プロキシが必要なドメインへアクセスし、OpenClash の接続記録でドメインが維持され、想定したポリシーに一致することを確認する。
各サービスを個別に再起動する
実際の起動順に AdGuard、dnsmasq、OpenClash を再起動し、待ち受けと上流の方向が変わらないことを確認する。
ロールバックを実行する
OpenClash を停止する前に、それに依存しない到達可能な上流を記録し、動作を確認します。停止後は dnsmasq と AdGuard の上流をその設定に戻し、LAN 端末からキャッシュされていないドメインを問い合わせてください。
nslookup example.com 192.168.1.1
nslookup www.iana.org 192.168.1.153 番ポートで待ち受けているのが、想定した一つのサービスだけであることを確認してください。選択した処理順序で AdGuard に問い合わせが届き、OpenClash がドメインを取得してルールを適用でき、新しいドメインの問い合わせがループでタイムアウトしないことも確認します。どちらかのコンポーネントを停止しても、事前に用意した手順で名前解決を復旧できる必要があります。両方の画面に「稼働中」と表示されるだけでは、これらは確認できません。