目次
OpenClash と AdGuard Home を同時に有効にするとネットワークが切れる場合は、まず DNS の経路を図にする
OpenClash と AdGuard Home はどちらも DNS を処理しようとしますが、役割は異なります。AdGuard Home はフィルタリング、書き換え、クエリ記録を担当し、OpenClash のカーネル DNS はドメイン解決とプロキシルールを連携させます。両者は共存できますが、一つのクエリを一方向にだけ進める必要があります。
「国内サイトは開けるが一部のドメインはタイムアウトする」「AdGuard のクエリログが空になる」「OpenClash を有効にすると家全体で SERVFAIL が発生する」といった場合も、すぐに上流サーバーを変更しないでください。
各端末が DHCP から取得した DNS、ルーターの 53 番ポートでクエリを受け取るサービス、AdGuard の上流サーバー、OpenClash カーネルの待ち受けポートを書き出します。クエリが最終的に以前のサービスへ戻る経路が一つでもあれば、ループが発生します。
まず主な入口を特定する
| 受信箇所 | 一般的な役割 | 混同してはいけない点 |
|---|---|---|
| ルーターの TCP/UDP 53 | LAN デバイスが既定でアクセスする DNS の入口 | 同じアドレスとポートを dnsmasq と AdGuard が同時に占有することはできない |
| AdGuard Home の DNS 待ち受け | クエリを受け取り、フィルタリングして上流へ転送する | 3000 などの Web 管理ポートは DNS ポートではない |
| OpenClash カーネルの DNS | モードに従って名前を解決し、ルールと連携する | 一般的な内部待ち受けは 127.0.0.1:7874 だが、実際の値は稼働状況画面とログで確認する |
| ブラウザーの DoH / Android のプライベート DNS | 端末から外部へ直接名前を解決する | ルーター上の二つのサービスを迂回する可能性がある |
LuCI のスイッチだけで判断せず、実際の待ち受けと転送を確認する
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 の設定バックアップ
どちらの接続方法も動作するが、方向は一つだけを選ぶ
OpenClash の公式 DNS 説明が示す原則は明快です。これを dnsmasq の唯一の上流にします。別のプラグインも 53 をハイジャックする、または DNS を転送する場合は、どちらか一方のハイジャックを停止し、二つのサービスの処理順を明確にしてください。
実際には、AdGuard を OpenClash の前に置く方法と、OpenClash がクエリを受け取った後で AdGuard を呼び出す方法のどちらも使用できます。
残したい機能に合わせて経路を選ぶ
| パス | クエリの方向 | 利点 | トレードオフ |
|---|---|---|---|
| AdGuard を前段にする | LAN の DNS 入口 → AdGuard → OpenClash DNS → 外部の上流 | AdGuard で端末ごとの記録を取りやすく、先にフィルタリングできる | OpenClash による LAN 53 の先行ハイジャックを無効にする必要がある |
| OpenClash を前段にする | LAN / dnsmasq → OpenClash → AdGuard → 外部の上流 | ドメインが先に OpenClash へ入り、Fake-IP とルールの経路を一元化しやすい | 通常 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 統合方法によって異なります。どの方法でも、LAN の 53 から 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 に実際の上流結果を問い合わせます。AdGuard のログにルーター自身しかクライアントとして表示されなくなることが多いのは、この構成で受け入れる必要がある点です。
LAN client
-> dnsmasq / OpenClash DNS hijack
-> OpenClash DNS
-> AdGuard Home 127.0.0.1:5335
-> external upstream DNSよくある三つの問題はいずれも「DNS が遅い」ように見えるが、対処方法は異なる
ログに同じドメインが繰り返し現れ、その後 SERVFAIL になる
主な原因：OpenClash と AdGuard が互いを上流にしており、クエリのループが発生している
対処方法：上流アドレスを一つずつ矢印でつなぎ、前の層へ戻る項目を削除する。
AdGuard のクエリログは空だが、Web ページは開ける
主な原因：OpenClash またはファイアウォールが AdGuard より前で 53 をハイジャックしている
対処方法：AdGuard を前段にする場合は、競合するハイジャックを無効にし、NAT/nftables の規則順を確認する。
AdGuard の起動に失敗し、address already in use と表示される
主な原因：dnsmasq または別のインスタンスが、同じアドレスとポートをすでに使用している
対処方法：53 を待ち受けるサービスを一つに決め、内部転送には別のローカルポートを選ぶ。
コンピューターは正常だが、スマートフォンがときどきフィルタリングを迂回する
主な原因：IPv6 DNS、Android のプライベート DNS、ブラウザーの DoH が外部へ直接クエリを送っている
対処方法：テスト中は個別の暗号化 DNS をすべて無効にし、DHCPv6/RDNSS の配布内容も確認する。
OpenClash の停止後、家全体で DNS が機能しなくなる
主な原因：唯一の上流が、待ち受けを停止したカーネルポートを参照している
対処方法：到達可能な外部 DNS へワンクリックで戻す手順を用意するか、停止スクリプトで dnsmasq の上流も同時に復元する。
キャッシュによって問題が見えなくなることがあります。サービスの順序を調整した後は関連サービスを再起動し、テスト端末の DNS キャッシュを消去するか Wi-Fi へ接続し直して、アクセスしたことのないドメインを問い合わせてください。キャッシュ済みのサイトを繰り返し開いても、以前のレスポンスが残っていることしか確認できません。
最後にフィルタリング、ルーティング、停止時のロールバックをまとめて確認する
テスト用コンピューター一台から検収を完了する
端末の DNS を確認する
nslookup の出力にある Server は、予定したルーターまたは AdGuard のアドレスである必要があり、意図しない公開 DNS であってはいけません。
許可対象のドメインを問い合わせる
キャッシュされていないドメインを使い、応答時間が正常で、AdGuard/OpenClash のログが選択した順序で表示されることを確認する。
フィルタールールを確認する
AdGuard にテストルールを一時的に追加し、フィルター設定どおりのレスポンスが返ることを確認してから、そのルールを削除する。
プロキシルールの動作を確認する
プロキシが必要なドメインへアクセスし、OpenClash の接続記録でドメインが維持され、想定したポリシーに一致することを確認する。
各サービスを個別に再起動する
実際の起動順に AdGuard、dnsmasq、OpenClash を再起動し、待ち受けと上流の方向が変わらないことを確認する。
ロールバックを実行する
OpenClash を無効にする際は、計画に従って DNS を到達可能な上流へ戻し、LAN デバイスが一般的なドメインを引き続き解決できるようにする。
nslookup example.com 192.168.1.1
nslookup www.iana.org 192.168.1.1検収に合格した状態は具体的です。53 には想定した入口が一つだけあり、AdGuard では選択した構成に従ってクエリを確認でき、OpenClash はドメインを取得してルールを実行できます。新しいドメインでループによるタイムアウトがなく、どちらかのコンポーネントを停止しても明確なロールバック手段があります。二つの画面をともに「稼働中」にするより、これらを実現することが重要です。