Pi-hole auf Proxmox installieren: LXC-Anleitung in 20 Minuten

Kurz gesagt: Am Ende läuft Pi-hole in einem eigenen Linux-Container auf deinem Proxmox-Server: feste IP, eigenes Passwort, Autostart, und die zwei Fehler, die im LXC fast jeder sieht, sind vorher abgeräumt. Dauer rund 20 Minuten, Stufe Standard. Stand: Pi-hole 6.4.3 (FTL 6.7), Proxmox VE 9.2, geprüft am 07-09-2026.

Pi-hole im LXC in drei Schritten: Vorlage laden, Container anlegen, Pi-hole installieren — Der ganze Weg auf einen Blick: Schritt 2 ist der, an dem es ohne Nesting hängt.

Pi-hole braucht 512 MB Arbeitsspeicher und einen Prozessorkern, den es fast nie auslastet. Eine virtuelle Maschine dafür anzulegen ist, als würdest du für den Rauchmelder ein eigenes Zimmer bauen. Ein LXC-Container ist die Steckdose in der Wand: Er nutzt den Kernel des Proxmox-Hosts mit, startet in zwei Sekunden und kann trotzdem alles, was Pi-hole braucht.

Die Pi-hole-Doku kennt Proxmox nicht. Kein Wort zu LXC, kein Wort zu Nesting, kein Wort zur Systemuhr. Die zwei Fehler, die daraus folgen, stehen dafür seit 2023 und 2024 im Pi-hole-Forum, und beide sind mit einem Häkchen erledigt, wenn man weiß, mit welchem. Genau die zwei Häkchen sind der Grund für diese Anleitung.

LXC? Ein Linux-Container auf Proxmox. Eine virtuelle Maschine ist ein eigenes Haus mit eigenem Fundament, also eigenem Betriebssystemkern. Ein LXC ist eine Wohnung im Haus des Hosts: eigene Tür, eigene Möbel, eigene IP-Adresse, aber das Fundament teilt er sich mit Proxmox. Darum braucht er kaum Speicher und startet sofort.

Handy, Laptop, TV→ fragt Port 53 →Pi-hole im LXC→ Werbung: 0.0.0.0 / Rest →Upstream-DNS (z. B. Quad9)

Was du brauchst, bevor der erste Container entsteht

Proxmox VE 8 oder 9, aktuell gehalten. Die Debian-13-Vorlage verlangt das Paket pve-container mindestens in Version 6.0.10 (Proxmox 9) oder 5.3.1 (Proxmox 8); ältere Stände lehnen sie ab. Warum, steht unten bei den Stolpersteinen.
Eine freie IP-Adresse in deinem Heimnetz, außerhalb des Bereichs, den dein Router per DHCP verteilt. Pi-hole ist ein Server; wandert seine Adresse, verliert jedes Gerät den DNS.
Zugang zur Proxmox-Shell als root: in der Web-Oberfläche links deinen Knoten anklicken, dann oben rechts Shell.
Zugang zum Router für den Schluss, wenn das Netz auf Pi-hole umgestellt wird. Für die FritzBox gibt es das als eigenen Beitrag.

So liest du diese Anleitung: Alles, was du selbst tun sollst, steht in einem farbigen Kasten. [ per klick ] heißt: Das erledigst du mit der Maus in einer Web-Oberfläche, hier Proxmox oder das Pi-hole-Dashboard. [ über die shell ] heißt: Den Befehl kopieren, ins Terminal einfügen, Enter. Stehen beide Kästen direkt untereinander, führen sie zum selben Ergebnis. Du gehst EINEN davon, nicht beide.

Beides kannst du vorher prüfen. Die Version in der Proxmox-Shell:

pveversion -v | grep -E "^(proxmox-ve|pve-container)"

proxmox-ve: 9.2.0 (running kernel: ...)
pve-container: 6.0.1x

Steht bei pve-container etwas Kleineres als 6.0.10 (oder 5.3.1 auf Proxmox 8), erst Updates einspielen. Und die freie IP von deinem PC aus anpingen; auf Windows ohne das -c 2:

ping -c 2 192.168.178.53

Antwortet niemand („Zielhost nicht erreichbar“ oder 100 % Paketverlust), ist die Adresse frei. Antwortet jemand, nimm eine andere. Diese Werte benutze ich im ganzen Beitrag; ersetze sie durch deine:

Container-ID: 110, Hostname: pihole
IP-Adresse für Pi-hole: 192.168.178.53/24, Gateway (dein Router): 192.168.178.1
Netzwerkbrücke: vmbr0
Speicher für die Vorlage: local, Speicher für die Container-Platte: local-lvm
Vorlage: debian-13-standard_13.1-2_amd64.tar.zst (bei dir kann eine neuere Punktversion stehen, nimm den Namen aus deiner Liste)
Ressourcen: 1 Kern, 512 MB RAM, 512 MB Swap, 4 GB Platte

Schritt 1: Die Debian-Vorlage laden

Ein Container entsteht aus einer Vorlage, einer fertig gepackten Debian-Grundinstallation von rund 120 MB. Proxmox pflegt die Liste selbst; du lädst einmal herunter und baust daraus so viele Container, wie du willst.

Warum Debian 13 und nicht 12: Pi-hole nennt in seiner Doku keine Versionsnummern, nur „aktiv gepflegte Versionen“ von Debian, und der Installer prüft seit Version 6 keine Liste mehr, das habe ich im Skript nachgesehen. Die Community-Skripte für Proxmox setzen Pi-hole ebenfalls auf Debian 13 auf. Das reicht mir als Beleg.

Links im Baum unter deinem Knoten den Speicher local anklicken, dann CT Templates. Oben auf Templates, ins Suchfeld debian tippen, die Zeile debian-13-standard markieren und Download. Ein Fenster zeigt den Fortschritt; bei „TASK OK“ schließen. Die Vorlage steht jetzt in der Liste unter CT Templates, mit Größe um 120 MB (Stand Proxmox VE 9.2).

pveam update
pveam available --section system | grep debian-13
pveam download local debian-13-standard_13.1-2_amd64.tar.zst
pveam list local

Die zweite Zeile zeigt dir den genauen Dateinamen; den setzt du in die dritte ein. Die letzte Zeile ist die Kontrolle: Sie muss die Vorlage mit ihrer Größe auflisten.

Schritt 2: Den Container anlegen

Hier fallen die beiden Entscheidungen, die später über Laufen oder Nicht-Laufen entscheiden. Erstens bleibt der Container unprivilegiert. Zweitens bekommt er Nesting.

Unprivilegiert? Der Root-Benutzer im Container ist außerhalb des Containers ein Niemand: Proxmox bildet ihn auf eine Nummer wie 100000 ab, die auf dem Host nichts darf. Bricht jemand aus dem Container aus, steht er als Gast ohne Schlüssel im Hausflur. Proxmox macht das seit Jahren zum Standard, und das LXC-Team nennt privilegierte Container in der Proxmox-Doku ausdrücklich „unsicher“.

Nesting braucht Pi-hole nicht, weil es Container in Container starten will. Der Dienst pihole-FTL, also der eigentliche DNS-Server, schützt sich per systemd mit eigenen, abgeschotteten Dateisystem-Bereichen. Ein unprivilegierter LXC darf solche Bereiche nur anlegen, wenn Nesting an ist. Ohne das Häkchen installiert Pi-hole fehlerfrei, und dann startet FTL nicht. Im Pi-hole-Forum ist das seit Februar 2023 ein eigener Thread, gelöst mit genau diesem Häkchen. Dass die Pi-hole-Doku es bis heute nicht erwähnt, wundert mich.

Oben rechts Create CT. Der Assistent hat sieben Reiter (Stand Proxmox VE 9.2):

General: CT ID 110, Hostname pihole, Unprivileged container angehakt lassen, Nesting anhaken (neuere Proxmox-Versionen setzen den Haken schon; dann so lassen), ein Root-Passwort vergeben.
Template: Storage local, Template debian-13-standard.
Disks: Storage local-lvm, Disk size 4 GiB.
CPU: Cores 1.
Memory: Memory 512, Swap 512.
Network: Bridge vmbr0, bei IPv4 Static wählen, IPv4/CIDR 192.168.178.53/24, Gateway 192.168.178.1.
DNS: leer lassen, der Container übernimmt die Einstellungen des Hosts.
Confirm: Start after created anhaken, Finish.

Der Container erscheint links im Baum als 110 (pihole), und nach ein paar Sekunden zeigt das Symbol ihn als laufend.

pct create 110 local:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst \
  --hostname pihole \
  --unprivileged 1 \
  --features nesting=1 \
  --password \
  --rootfs local-lvm:4 \
  --cores 1 --memory 512 --swap 512 \
  --net0 name=eth0,bridge=vmbr0,ip=192.168.178.53/24,gw=192.168.178.1 \
  --onboot 1 --start 1
pct status 110

Der Befehl fragt nach einem Root-Passwort für den Container, legt ihn an und startet ihn. Die Kontrolle ist die letzte Zeile:

status: running

Und jetzt derselbe Ping wie oben, von deinem PC aus. Diesmal antwortet die Adresse. Das ist der erste Ping, der zurückkommt, und der zählt: Netzwerk, Brücke, Gateway, alles stimmt. Der Rest ist Software.

Schritt 3: In den Container und Debian auffrischen

Die Vorlage ist so alt wie ihr Erstellungsdatum. Vor dem Installer holst du die aktuellen Pakete und curl, das in der Vorlage fehlt.

Links im Baum 110 (pihole) anklicken, oben Console. Am Prompt pihole login: als root mit dem Passwort aus Schritt 2 anmelden. Bleibt die Konsole schwarz, unter Options den Console mode auf shell stellen und die Konsole neu öffnen; Mark Himsley beschreibt in seinem Blog denselben Handgriff.

pct enter 110

Beide Wege enden am selben Ort: einer Root-Shell im Container, erkennbar am Prompt root@pihole:~#. Dort weiter:

apt update && apt full-upgrade -y && apt install -y curl
curl --version | head -n 1

curl 8.14.1 (x86_64-pc-linux-gnu) libcurl/8.14.1 ...

Steht da eine curl-Version, ist der Container bereit. Die Zahl darf abweichen; sie ist nur der Beweis, dass das Paket da ist.

Schritt 4: Pi-hole installieren

Der offizielle Weg ist ein Einzeiler, der ein Skript aus dem Netz direkt an die Shell reicht. Die Pi-hole-Doku nennt das selbst „ein umstrittenes Thema“ und bietet als Alternative an, das Skript erst mit wget zu laden und anzusehen. Ich würde den Umweg gehen, wenn du wissen willst, was auf deinem Server läuft; das Ergebnis ist dasselbe.

curl -sSL https://install.pi-hole.net | bash

Der Installer stellt in blauen Dialogen nacheinander diese Fragen; mit Tab springst du zwischen den Knöpfen, mit Enter bestätigst du:

Static IP Address: ein Hinweis, dass Pi-hole eine feste Adresse braucht. Hast du, weiter mit Continue.
Interface: eth0, es gibt nur die eine.
Upstream DNS Provider: der Dienst, an den Pi-hole alles weiterreicht, was es nicht selbst blockt. Quad9 oder Cloudflare sind vernünftige Wahlen; dein Router geht auch, dann bleibt die Entscheidung bei ihm.
Blocklists: die vorgeschlagene Liste von StevenBlack angehakt lassen. Sie ist der Grund, warum Pi-hole am ersten Tag schon etwas blockt.
Query logging: Yes. Ohne Protokoll siehst du später nicht, welche Domain deine Fernseh-App gerade ruft.
Privacy mode: Show everything. Es ist dein Netz, und beim Fehlersuchen willst du alles sehen.

Upstream-DNS? Pi-hole ist der Türsteher, aber kein Telefonbuch. Fragt ein Gerät nach einer Adresse, die nicht auf der Sperrliste steht, ruft Pi-hole beim Upstream an, etwa bei Quad9, und reicht die Antwort durch. Dein Router hat bisher denselben Job gemacht, nur ohne Sperrliste.

Am Ende zeigt der Installer eine Zeile Web Interface password: mit acht Zufallszeichen. Notieren oder gleich ersetzen, dazu kommen wir in einer Minute. Ob alles läuft, sagt dir Pi-hole selbst:

pihole status

  [✓] FTL is listening on port 53
     [✓] UDP (IPv4)
     [✓] TCP (IPv4)
     [✓] UDP (IPv6)
     [✓] TCP (IPv6)

  [✓] Pi-hole blocking is enabled

Dann von deinem PC aus im Browser http://192.168.178.53/admin öffnen: Die Anmeldeseite von Pi-hole erscheint. Und noch ein Test, der nicht am Router hängt, ebenfalls vom PC:

nslookup doubleclick.net 192.168.178.53

Server:  192.168.178.53
Address: 192.168.178.53#53

Name:    doubleclick.net
Address: 0.0.0.0

Die Null-Adresse ist die Antwort, die Pi-hole für gesperrte Domains gibt. Damit ist der Container fertig installiert, und wenn ich ehrlich bin, ging das zu glatt. Der Teil, an dem es im Forum hakt, kommt jetzt.

Die ersten Einstellungen: fünf Dinge, die der Installer dir überlässt

1. Ein eigenes Passwort. Das Zufallspasswort stand einmal auf dem Bildschirm; wer die Konsole geschlossen hat, hat keins mehr. Der Befehl fragt zweimal nach und zeigt die Eingabe nicht an.

pihole setpassword

Kontrolle: im Browser abmelden und mit dem neuen Passwort wieder anmelden.

2. Den Zeitabgleich abschalten. Pi-hole 6 stellt standardmäßig einmal pro Stunde die Systemuhr nach pool.ntp.org. In einem unprivilegierten Container darf es das nicht, der Kernel verweigert den Aufruf, und FTL schreibt jede Stunde Failed to adjust time during NTP sync: Insufficient permissions ins Protokoll. Im Proxmox-Forum lief dazu ein Thread von April bis September 2025, im Pi-hole-Forum hat Entwickler DL6ER dieselbe Antwort gegeben: Funktion aus, der Host stellt die Uhr ohnehin für alle Container. Die Alternative, den Container privilegiert zu machen, wäre der falsche Preis für eine Uhr, die schon geht.

Im Pi-hole-Dashboard links Settings, dann oben rechts den Schalter von Basic auf Expert. Jetzt erscheint All settings; dort der Reiter Network Time Sync, den Haken bei ntp.sync.active entfernen und unten Save (Stand Pi-hole 6.4).

pihole-FTL --config ntp.sync.active false

Kontrolle: Derselbe Befehl ohne das false am Ende zeigt den aktuellen Wert, und der heißt jetzt false. In /var/log/pihole/FTL.log taucht die Zeile ab jetzt nicht mehr auf.

3. Autostart und Startreihenfolge in Proxmox. Über die Shell hast du den Autostart schon gesetzt, der Assistent nicht: Dort ist Start at boot aus. Nach einem Stromausfall käme Proxmox hoch, Pi-hole bliebe liegen, und für die Familie ist „das Internet kaputt“. Die Reihenfolge sorgt dafür, dass der DNS vor allen anderen Containern da ist, die beim Start Namen auflösen wollen.

110 (pihole) anklicken, Options. Doppelklick auf Start at boot, Haken setzen, OK. Doppelklick auf Start/Shutdown order, bei Start/Shutdown order eine 1 eintragen, OK. Die Liste zeigt danach Yes und order=1.

pct set 110 --onboot 1 --startup order=1
pct config 110 | grep -E "^(onboot|startup)"

onboot: 1
startup: order=1

4. Ein Backup-Auftrag für den Container. Ja, schon jetzt, wo noch fast nichts drin ist. Proxmox legt von allein keine Sicherung an, und in diesem Container wohnen bald deine eigenen Sperr- und Freigabelisten, lokale DNS-Namen und drei Monate Abfrageprotokoll. Ein Container-Backup dauert Sekunden und bringt bei einem Fehlgriff alles in einem Rutsch zurück.

Ganz oben im Baum Datacenter, dann Backup, Add. Storage local, Schedule zum Beispiel daily um 03:00, Selection mode Include selected VMs und in der Liste 110 anhaken, Create. Kontrolle: den neuen Auftrag markieren und Run now; unter local → Backups liegt danach eine Datei mit vzdump-lxc-110 im Namen.

vzdump 110 --storage local --mode snapshot --compress zstd
ls -lh /var/lib/vz/dump/ | grep lxc-110

Der Shell-Weg ist eine einmalige Sicherung; den wiederkehrenden Auftrag legst du trotzdem per Klick an.

5. Den Router auf Pi-hole zeigen lassen. Bis hierher benutzt genau ein Gerät den neuen DNS: das, auf dem du nslookup getippt hast. Alle anderen fragen weiter den Router. Das Umstellen ist bei jedem Router anders; für die FritzBox samt IPv6 und Gastnetz steht es im eigenen Beitrag. Eine Ausnahme würde ich machen: Der Proxmox-Host selbst behält seinen bisherigen DNS. Zeigt er auf den Container, und der Container ist gerade aus, findet der Host nicht einmal mehr die Vorlagen-Liste, um ihn zu reparieren.

Wo es im LXC erfahrungsgemäß klemmt

pihole-FTL startet nicht, im Status steht status=226/NAMESPACE. Das ist der Container ohne Nesting. Im Pi-hole-Forum ist es der Thread „LXC and FTL permissions“ von Februar 2023: Nutzer JGC hat die Ursache in den Schutzoptionen der systemd-Unit gefunden, andere haben das Nesting-Häkchen als Lösung bestätigt. Nachträglich geht es so:

110 (pihole) → Options → Doppelklick auf Features → Nesting anhaken → OK. Danach den Container über Reboot oben rechts neu starten.

pct set 110 --features nesting=1
pct reboot 110

Proxmox lehnt die Vorlage ab: unsupported debian version '13.1'. Ein zu alter Proxmox-Stand. Das Paket pve-container hatte eine feste Obergrenze für die Debian-Version eingebaut; als Debian von 13.0 auf 13.1 sprang, fiel die neue Vorlage darunter durch. Thomas Lamprecht von Proxmox hat den Fix im September 2025 im Forum bestätigt: pve-container 5.3.1 für Proxmox 8, 6.0.10 für Proxmox 9. Updates einspielen, fertig. Wer den Wert per Hand in der Perl-Datei ändert, wie es im Thread als Notlösung steht, verliert die Änderung beim nächsten Update ohnehin.

Der Download-Knopf findet die Vorlage nicht. Im Oktober 2025 meldete ein Nutzer im Proxmox-Forum, dass die Liste eine Version nannte, die auf dem Server noch nicht lag; anderthalb Stunden später war sie da. Einmal pveam update und die Liste stimmt wieder mit dem Server überein.

Port 53 ist schon belegt. Passiert mit der Debian-Vorlage nicht, wohl aber, wenn du eine Ubuntu-Vorlage nimmst: Dort lauscht systemd-resolved auf dem DNS-Port, und der Installer bricht ab. Die Pi-hole-Doku verlangt den Port ausdrücklich exklusiv. Wie du den Schuldigen findest, steht im eigenen Beitrag; einfacher ist, bei Debian zu bleiben.

Lohnt sich der Container gegenüber VM und Docker?

Für Pi-hole ja, und zwar ohne Wenn. Die VM kostet einen eigenen Kernel und einen halben Gigabyte RAM für nichts, was Pi-hole braucht. Docker im LXC ist die beliebteste Kombination in den Foren und zugleich die mit den meisten Threads zu UDP-Port 53 und Overlay-Dateisystemen. Ein unprivilegierter LXC mit Nesting und ohne Docker dazwischen ist der kürzeste Weg, und kurz heißt hier: weniger Stellen, an denen es klemmen kann.

Zwei Grenzen gehören dazu. Pi-holes eigenen DHCP-Server würde ich in diesem Container nicht einschalten; der Router macht das besser, und die dafür nötigen Rechte hat ein unprivilegierter Container nicht. Und der Zeitabgleich bleibt aus, dauerhaft. Wer beides braucht, ist mit einer VM richtig. Wer Werbung blocken will, ist mit dieser Anleitung fertig.

Läuft dein Pi-hole schon in einem LXC, oder hast du dich für Docker oder eine VM entschieden? Und falls LXC: Bist du damals auch über das Nesting-Häkchen gestolpert, oder gab es bei dir eine andere Hürde? Schreib's in die Kommentare, ich lese mit.

Der nächste Handgriff ist der Router. Pi-hole mit der FritzBox einrichten nimmt dir IPv4, IPv6 und das Gastnetz ab, in derselben Reihenfolge wie hier.