コミュニティソリューション

ZimaOS上のPi-hole:ポート67、DNSエラー、Webポートの競合、クリーン再インストールの制限

A Pi-hole troubleshooting thread covering a system-owned port 67, DNS resolution failures during Gravity updates, a port 80 conflict with the ZimaOS dashboard, and persistent Pi-hole state after an unexpected power outage.

2025年12月のこのスレッドでは、複数のPi-holeの問題が組み合わさっていました。ポート67がすでに使用中だったこと、Gravityの更新時にDNS解決を利用できないと報告されたこと、ポート80がZimaOSダッシュボードと競合したこと、そしてその後の停電によって、それまで正常に動作していた環境が再び機能しなくなったことです。

このスレッドは、単純な1ステップの解決策を示すものではありませんでした。初期のコミュニティによる推測の一部は、後に発生したユーザーの症状を説明できませんでした。重要な教訓は、DHCP、DNS、Webインターフェースのポートマッピング、上流DNSによる名前解決、永続的なコンテナ状態を、単一のポート問題として扱わず、それぞれ分けて確認することです。

ポート67はDHCP用であり、通常のDNSフィルタリング用ではない

元のユーザーは、ポート67にすでにバインドされているdnsmasqプロセスを見つけましたが、終了させることができませんでした。コミュニティからの返信では、Pi-holeがDHCPサーバーとして動作する場合にのみ、ポート67が必要だと説明されました。ユーザーのルーターがすでにDHCPを提供していたため、Pi-holeがその役割を引き受ける必要はありませんでした。

Pi-holeをDNSフィルタリングだけに使用する場合は、Pi-hole DHCPが必要となる明確なネットワーク設計上の理由がない限り、DHCPはルーターで処理してください。

DNSはポート53を使用する

Pi-holeのDNSサービスは、TCPおよびUDPのポート53を使用します。このスレッドのコミュニティ設定では、DHCPを無効にしたまま、DNSをポート53で公開することに重点が置かれていました。

2025年のすべてのZimaOSコンテナテンプレートが同一だと仮定せず、現在のサービス要件とポート要件についてはPi-holeの公式ドキュメントを確認してください。

現在のPi-holeのサービス要件とポート要件

ポート80はZimaOSダッシュボードとの別個の競合だった

ユーザーがPi-holeをクリーンインストールしようとした際、ZimaOSはポート80がすでに使用中だと報告しました。Zima-Jerryは、ZimaOS WebUIのポートを変更できることを確認しました。

ポート53は使用可能だが、ホストポート80が利用不可と表示されているZimaOSのPi-holeカスタムアプリ設定
元のスクリーンショットでは、DNSポート53は使用可能である一方、ホストポート80がZimaOSホスト上の別サービスと競合しています。

スレッドで説明された、より簡単なコンテナ側の代替方法は、ZimaOSダッシュボードを既存のポートに残し、別のホストポートをPi-hole内部のWebポートにマッピングすることでした。これはPi-hole管理ページへのアクセス方法だけを変更するもので、ポート53のDNSトラフィックは変更しません。

TCPおよびUDPの53番ポートと、ホストポート8081をコンテナポート80にマッピングしたZimaOSのPi-holeポート設定
後のスクリーンショットでは、DNSにTCP/UDPの53番ポートを使用し、Pi-holeコンテナのWebポート80にホストポート8081を割り当てるコミュニティ設定が示されています。

正しいポートマッピングだけではGravityの問題は自動的に解決しなかった

ポートマッピングを整理した後も、元のユーザーには「DNS解決を利用できません」というメッセージが表示されました。そこでスレッドの焦点は、ポート競合から上流DNSへの到達性へと移りました。重要な診断上の違いは次のとおりです。

  • ポートマッピングは、クライアントがPi-holeサービスに接続できるかどうかを制御します。
  • 上流DNSは、Pi-hole自体が名前を解決し、Gravityデータを更新できるかどうかを制御します。

このスレッドでは、すべてのDNS障害についてIceWhaleが確認した根本原因は公表されていません。そのため、Gravityの更新失敗をポート67だけで説明できると断定しないでください。

停電後に環境が再び機能しなくなった

その後、ユーザーは、停電前はPi-holeが正常に動作していたものの、停電後に再び機能しなくなったと報告しました。コミュニティからは、通常のアンインストール後も永続的なAppDataが残り、再インストール時に壊れた状態を引き継ぐ可能性があるという助言がありました。

AppDataディレクトリを削除すると、永続的なアプリケーション状態が失われるため破壊的な操作になります。元の推奨事項はコミュニティによるトラブルシューティングであり、IceWhaleの公式復旧手順ではありません。永続データを削除する前に、設定をバックアップし、正確なアプリケーションパスを確認してください。

Pi-holeを再構築する前にZimaOSの状態を確認する

同じ停電によって、マシンの起動動作にも影響が出ました。オペレーティングシステム自体が不安定になると、スレッドではその問題をPi-holeコンテナの問題から正しく切り分けました。ホストが正常に起動できない、またはDockerサービスが正常な状態でない場合、コンテナが通常どおり動作することは期待できません。

ZimaOSでのPi-holeに関するFAQ

ルーターがすでにDHCPを提供している場合、Pi-holeにポート67は必要ですか?

このスレッドで説明されたDNSフィルタリングのみの構成では、必要ありません。ポート67はDHCPサービスに関係し、DNSフィルタリングにはポート53を使用します。

ZimaOSがすでにポート80を使用している場合はどうすればよいですか?

Zima-Jerryは、ZimaOS WebUIのポートを変更できることを確認しました。別の方法として、Pi-holeの内部Webポートを異なるホストポートにマッピングすることもできます。

ブロックリストが「DNS解決を利用できません」というメッセージの原因になることはありますか?

このスレッドのトラブルシューティングでは、ブロックリストの内容ではなく、Pi-holeが上流リゾルバーに接続できるかどうかに重点が置かれていました。

Pi-holeをアンインストールすれば、必ずクリーンインストールできますか?

永続的なAppDataが残っている場合は、できません。スレッドでは後に、突然の停電後に古い、または破損した永続状態が残っている可能性について検討されました。ただし、その状態を削除する場合は、破壊的な復旧手順として扱ってください。