この2025年12月のスレッドで重要なのは、ZimaBoard 2へのAdGuard Homeの正常なインストールで終わったわけではないという点です。投稿者はコミュニティの提案を試した後、別のUmbrelサーバーではAdGuard Homeが動作したものの、ZimaOSへのデプロイは利用できないままだったと報告しています。つまり、これは解決済みのインストール手順ではなく、トラブルシューティングの記事です。
それでも、スクリーンショットと返信からはいくつか有用な確認事項が分かります。アプリケーションではDNSとWebインターフェースのポートマッピングが分けられており、ブリッジネットワークで動作していました。また、コミュニティではUniFiゲートウェイではなく、ポートの競合に焦点が当てられていました。
「Service Unavailable」が示すこと、示さないこと
「Service Unavailable」ページが表示されるということは、何らかのHTTP経路が応答したことを示します。しかし、AdGuardのプロセスが初期化を完了したか、リバースプロキシの経路が正しい内部ポートを指しているか、DNS用ポート53のバインドに成功したかまでは分かりません。
サービスがローカルのZimaOSホスト上で正常に動作していない段階で、ルーターの設定変更から始めないでください。
元の設定ではDNSポートとWebポートが分けて公開されていた
初回のAdGuard Homeセットアップでは3000番ポートを使用する
現在のAdGuard HomeのDockerガイダンスでは、初回セットアップウィザードと通常の管理インターフェースを区別しています。新しいコンテナでは、初回セットアップフローにTCPの3000番ポートを使用します。設定後、通常のHTTPインターフェースでは、ユーザーが変更しない限り、一般的に80番ポートを使用します。
これは、コミュニティの短い返信では触れられていなかった重要な点です。8080:80のようなホスト側のマッピングは、セットアップ後のUIには正しくても、新しいコンテナが必要とする初回セットアップ用エンドポイントを公開していない可能性があります。
ルーターを変更する前に、AdGuard Homeの現在のDockerポートおよびボリューム要件とアプリの設定を比較してください。
DNSにはTCPとUDPの両方で53番ポートが必要
コミュニティの回答者が指摘したとおり、通常のDNSサービスを提供するにはAdGuard Homeで53番ポートが必要です。コンテナがLANにDNSを提供する場合、TCPとUDPの両方を利用できるようにする必要があります。
別のPi-hole、AdGuard、システムリゾルバー、またはDNSコンテナがすでに53番ポートを使用している場合、新しいサービスは正常にバインドできません。WebUIのポートを何度も変更するより、ホスト上ですでにリスナーが存在するか確認するほうが有効です。
WebUIのポートとDNSポートは別の問題
80番または3000番ポートの競合があると、管理インターフェースを開けなくなる一方で、DNS自体は正常な場合があります。53番ポートの競合があると、ダッシュボードが開いてもDNSサービスの起動を妨げる可能性があります。診断中は、これらを別々の問題として扱ってください。
ホストモードは提案されたが、必須とは証明されていない
コミュニティの回答者は、ブリッジモードではDNSポートの扱いが複雑になる場合があるとして、ホストネットワークモードを試すよう勧めました。しかし、元の投稿者はその変更後にZimaOS上で正常に動作した結果を報告していません。
したがって、ホストネットワークを必須として説明しないでください。AdGuard Homeの保守されたDockerデプロイメントは、明示的なポートマッピングに対応しています。必要なポートが空いており、正しくマッピングされていれば、ブリッジモードでも動作する可能性があります。
UniFi Cloud Gatewayが原因とは特定されていない
ユーザーは、UniFi Cloud Gateway Maxに変更が必要かどうかを具体的に尋ねました。コミュニティの回答では、AdGuard Homeをローカルで開いて設定するだけなら、ルーターの変更は必要ないとされました。
ルーターの変更が必要になるのは、LAN上のクライアントにAdGuard HomeをDNSまたはDHCPとして使用させる段階です。ローカルで初期化を完了できないコンテナを、ルーターの変更で修復することはできません。
/opt/adguardhome/workと/opt/adguardhome/confを永続化する
AdGuard Homeは、ランタイムデータと設定を永続的なディレクトリに保存します。これらのパスが再作成されたり、読み取り専用でマウントされたり、想定外の場所を指していたりすると、コンテナが新規インストールのように動作したり、再作成後に設定を失ったりする可能性があります。
元のスクリーンショットにはすでに永続ボリュームが表示されているため、完全に再インストールする場合は、既存のフォルダーが再利用されているか確認してください。アプリケーションがまっさらな状態で起動していると決めつけないことが重要です。
より適切な診断の順序
- コンテナのログで起動エラーやバインドエラーを確認する。
- 初回セットアップに3000番ポートが必要か確認する。
- 通常のWebUIマッピングを個別に確認する。
- ホスト上でTCPとUDPの53番ポートが空いているか確認する。
- 永続化された設定ボリュームとworkボリュームが書き込み可能か確認する。
- その後で、ブリッジネットワークとホストネットワークを試す。
- ローカルサービスが正常になるまで、ルーターのDNS変更は行わない。
元の事例はZimaOS上で未解決のままだった
12月24日、ユーザーはUmbrelサーバーでAdGuard Homeを動作させることはできたものの、ZimaBoard 2へのデプロイは依然として実行できなかったと報告しました。ヘルプリクエストを終了したのは、サービスを別の場所で利用できるようになったためであり、ZimaOSのインストールが修正されたためではありません。
AdGuard Homeの「Service Unavailable」FAQ
初回セットアップにはどのポートを使用しますか？
現在のAdGuard Home Dockerの手順では、初回設定ウィザードにTCPの3000番ポートを使用します。
通常のDNSにはどのポートを使用しますか？
TCPとUDPの両方で53番ポートを使用します。
AdGuard HomeにはZimaOS上でホストネットワークが必要ですか？
元のスレッドでは、それは証明されていません。コミュニティによるトラブルシューティング上の提案でした。
元のZimaOSの事例は解決しましたか？
いいえ。ユーザーはサービスを別のサーバーに移し、ZimaOS上で動作する設定を得ないままスレッドを終了しました。
