Pi-hole convierte tu servidor en un filtro de anuncios y rastreadores para toda la red: en lugar de instalar un bloqueador en cada dispositivo, bloqueas por DNS en un único punto, y con Docker lo levantas con un solo archivo. En esta guía instalas Pi-hole con su docker-compose.yml de la versión 6, entiendes por qué ahora se configura con variables FTLCONF_, resuelves el clásico conflicto del puerto 53 con systemd-resolved, apuntas tu router para proteger todos los dispositivos de golpe y repasas las listas de bloqueo y las estadísticas del panel. La misma explicación está disponible en inglés.

Puntos clave

  • Pi-hole es un servidor DNS de bloqueo de anuncios de código abierto (licencia EUPL), creado por Jacob Salmela en 2014; se ha convertido en la herramienta de referencia para filtrar publicidad y telemetría en toda una red doméstica.
  • Pi-hole v6, publicada el 18 de febrero de 2025, fue un cambio de arquitectura: fundió la antigua pila de lighttpd y PHP en un solo binario pihole-FTL con servidor web embebido, lo que reduce la huella y acelera el panel.
  • La versión estable más reciente es FTL v6.7, Web v6.6 y Core v6.4.3, de julio de 2026; la imagen oficial pihole/pihole se etiqueta por fecha con el formato AAAA.MM.parche.
  • Escucha el DNS en el puerto 53 (TCP y UDP) y publica el panel de administración en el puerto 80 (ruta /admin), con HTTPS opcional en el 443.
  • La configuración cambió por completo: las variables llevan el prefijo FTLCONF_ y mapean a las claves de pihole.toml; toda opción fijada por variable de entorno queda de solo lectura en la interfaz.

¿Qué es Pi-hole y cómo bloquea por DNS?

Pi-hole es un servidor DNS que se coloca entre tus dispositivos e Internet y, cuando alguno pide la dirección de un dominio de publicidad o rastreo, responde con una dirección nula en lugar de la real. El resultado es que el anuncio nunca llega a descargarse: no se bloquea el hueco donde iba a aparecer, sino la propia petición de red. Como el filtrado ocurre en la capa DNS, protege a la vez el móvil, la televisión inteligente, la consola y el portátil, sin instalar nada en cada uno.

La diferencia frente a una extensión del navegador es precisamente esa cobertura. Un bloqueador de navegador solo actúa dentro de ese navegador y en ese dispositivo; Pi-hole actúa para toda la red y también frente al tráfico que las aplicaciones y los aparatos generan por su cuenta, que es justo donde más telemetría se escapa. A cambio, un bloqueo por DNS es de grano más grueso: bloquea o permite un dominio entero, así que no elimina anuncios servidos desde el mismo dominio que el contenido y a veces hay que añadir excepciones.

Pi-hole guarda la lista de dominios que debe bloquear (las llamadas listas o blocklists), resuelve el resto de nombres consultando a un DNS de subida (upstream) que tú eliges, y registra cada consulta para mostrarte estadísticas. Todo eso, desde la versión 6, lo hace un único proceso.

¿Cómo es el docker-compose.yml de Pi-hole?

En la versión 6 el archivo es más corto que en las anteriores porque ya no hay servidor web aparte y basta con un volumen. Este docker-compose.yml levanta Pi-hole, fija la contraseña del panel con la nueva variable y persiste la configuración en un volumen con nombre:

services:
  pihole:
    image: pihole/pihole:2026.07.1
    container_name: pihole
    hostname: pihole
    restart: unless-stopped
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
      - "443:443/tcp"
    environment:
      TZ: "Europe/Madrid"
      FTLCONF_webserver_api_password: "cambia-esta-contrasena"
      FTLCONF_dns_listeningMode: "all"
      FTLCONF_dns_upstreams: "1.1.1.1;9.9.9.9"
    volumes:
      - pihole_data:/etc/pihole
    cap_add:
      - SYS_NICE

volumes:
  pihole_data:

Conviene entender cada pieza. La imagen se fija a una versión concreta, pihole/pihole:2026.07.1, en lugar de a la etiqueta móvil :latest, para que una recreación del contenedor no te cambie de versión sin avisar. La variable FTLCONF_webserver_api_password sustituye a la antigua WEBPASSWORD de la v5 y define la clave del panel; si la dejas vacía, Pi-hole genera una aleatoria y la escribe en los logs. FTLCONF_dns_listeningMode: "all" es necesario en la red bridge por defecto de Docker, porque las peticiones llegan con la dirección de la pasarela y de otro modo Pi-hole las descartaría. Con FTLCONF_dns_upstreams eliges a quién pregunta Pi-hole por los dominios que no bloquea (en el ejemplo, Cloudflare y Quad9). El único volumen, /etc/pihole, guarda pihole.toml, la base de datos de consultas y las listas: en la v6 ya no hace falta el segundo volumen /etc/dnsmasq.d de versiones anteriores. La capacidad SYS_NICE es opcional y solo mejora la prioridad de proceso; NET_ADMIN únicamente hace falta si vas a usar Pi-hole como servidor DHCP.

Levanta la pila y sigue el arranque en los logs:

docker compose up -d
docker compose ps
docker compose logs -f pihole

Abre http://localhost:80/admin (o la IP del servidor) y entra con la contraseña que fijaste. El panel es el nuevo, servido directamente por pihole-FTL. Si prefieres publicarlo con un dominio y HTTPS, ponlo detrás de un proxy inverso como Traefik; ten en cuenta que solo se enruta el panel web, no el puerto 53 del DNS, que debe seguir expuesto en la máquina. Para repasar cómo se comunican los contenedores y cuándo publicar cada puerto, viene bien la guía sobre redes en Docker.

¿Por qué falla el puerto 53 y cómo arreglarlo?

El error más habitual al arrancar es que el contenedor no consiga enlazar el puerto 53 porque ya lo ocupa otro proceso. En Ubuntu, Debian moderno y Fedora, ese proceso suele ser systemd-resolved, el resolvedor local del sistema, que mantiene un pequeño DNS de caché escuchando en 127.0.0.53:53. Como Pi-hole necesita el 53 para hacer de servidor DNS, hay que liberar ese puerto en el anfitrión.

La solución recomendada es desactivar solo el listener de systemd-resolved, sin apagar el servicio entero. Crea un archivo de anulación y reinicia el servicio:

sudo mkdir -p /etc/systemd/resolved.conf.d
printf '[Resolve]\nDNSStubListener=no\n' | sudo tee /etc/systemd/resolved.conf.d/no-stub.conf
sudo systemctl restart systemd-resolved

Con DNSStubListener=no el sistema deja de escuchar en el puerto 53, pero sigue resolviendo nombres para la propia máquina a través de /etc/resolv.conf, así que no pierdes conectividad. Tras el reinicio, vuelve a levantar Pi-hole con docker compose up -d y el enlace del puerto 53 dejará de fallar. Si tu servidor no usa systemd-resolved, comprueba qué proceso ocupa el puerto con sudo ss -tulpn | grep :53 y libéralo antes de arrancar.

¿Cómo apuntar tu router a Pi-hole?

Tener Pi-hole en marcha no basta: los dispositivos solo lo usarán si les dices que él es su servidor DNS. La forma más limpia y la que protege toda la red de golpe es configurarlo en el router, no en cada aparato. En la configuración de red o de DHCP del router, busca el campo de servidores DNS y sustituye el que venga por la IP fija de tu servidor Pi-hole (por ejemplo 192.168.1.10). A partir de ahí, cada dispositivo que reciba una IP por DHCP heredará ese DNS y sus consultas pasarán por el filtro.

Dos condiciones son importantes. La primera es que el servidor Pi-hole tenga una IP fija en tu red local (por reserva DHCP o dirección estática): si su IP cambia, los dispositivos se quedan sin resolver nombres. La segunda es dejar un DNS de respaldo sensato; si pones un segundo DNS público como respaldo, muchos dispositivos alternarán entre ambos y colarán consultas sin filtrar, así que para un bloqueo real conviene que Pi-hole sea el único DNS anunciado. Si tu router no permite cambiar el DNS que reparte por DHCP, la alternativa es activar el propio servidor DHCP de Pi-hole (recuerda añadir NET_ADMIN y el puerto 67/udp) y desactivar el del router.

¿Prefieres proteger también fuera de casa? Combina Pi-hole con una VPN WireGuard mediante wg-easy: al conectarte desde el móvil por la VPN, el tráfico sale por tu red y usa el mismo filtro de Pi-hole estés donde estés.

¿Cómo se gestionan las listas de bloqueo y las estadísticas?

Pi-hole no bloquea por arte de magia: consulta listas de dominios de publicidad y rastreo que se descargan y actualizan. Recién instalado trae una lista por defecto (la lista de StevenBlack), y desde la sección de listas del panel puedes añadir las que quieras pegando su URL; el contenedor incluye una tarea programada (cron) que refresca esas listas de forma periódica, por lo que el bloqueo se mantiene al día sin que hagas nada. Cuantas más listas añadas, más dominios bloqueas, pero también sube el riesgo de falsos positivos, así que conviene ir con cabeza y tener a mano la lista blanca (allowlist) para permitir un dominio concreto cuando algo deje de funcionar.

El panel es también un cuadro de mando de tu red. Muestra el porcentaje de consultas bloqueadas, el total de peticiones DNS del día, los dominios y los clientes que más consultan y una línea temporal de la actividad. Esas estadísticas son útiles más allá de la publicidad: revelan qué aparato de casa habla más con servidores externos, algo que suele sorprender la primera vez que lo miras. Como el equipo de Pi-hole resumió al presentar la versión 6, la nueva arquitectura integra una API REST y un servidor web embebido "directamente en el binario pihole-FTL", de modo que ese mismo panel y esos datos están ahora disponibles por API para automatizar consultas o integrarlos en otro tablero.

Si dudas entre Pi-hole y su alternativa más directa, compáralo con AdGuard Home, otro DNS de bloqueo self-hosted: cubren el mismo hueco y la elección suele reducirse a qué interfaz y qué opciones de DNS cifrado prefieras.

Preguntas frecuentes

¿Por qué no debo usar la etiqueta latest de Pi-hole?

Porque pihole/pihole:latest apunta siempre a la última versión publicada, así que una recreación del contenedor (por ejemplo tras un docker compose pull) puede saltar a una versión mayor con cambios de configuración sin que lo decidas tú. En un servicio de red tan central como el DNS eso es arriesgado. Fija una etiqueta por fecha concreta, como pihole/pihole:2026.07.1, revisa las notas de versión antes de subir y actualiza recreando el contenedor cuando te venga bien.

¿Pierdo la configuración y las estadísticas si borro el contenedor?

No, siempre que uses el volumen con nombre de esta guía. El contenedor es efímero, pero el volumen pihole_data montado en /etc/pihole conserva pihole.toml, la base de datos de consultas y tus listas, y sobrevive a docker compose down. Al recrear el servicio, todo vuelve a su sitio. Solo lo perderías con docker compose down -v, que elimina también los volúmenes, así que evita esa opción salvo que quieras empezar de cero.

¿Puedo cambiar la contraseña del panel desde la interfaz?

En la v6, si fijas FTLCONF_webserver_api_password en el docker-compose.yml, esa opción queda de solo lectura en el panel y la contraseña se gestiona desde el archivo: cámbiala ahí y recrea el contenedor. Si prefieres administrarla desde la interfaz, deja la variable fuera del Compose y usa el comando docker exec -it pihole pihole setpassword para establecerla dentro del contenedor.

Conclusión

Con un único docker-compose.yml tienes un Pi-hole persistente que filtra anuncios y rastreadores para toda tu red desde la capa DNS, con el panel embebido de la versión 6 y toda la configuración en variables FTLCONF_. El camino completo es: levantar el contenedor, liberar el puerto 53 de systemd-resolved, apuntar el router a la IP fija del servidor y afinar las listas de bloqueo desde el panel. A partir de ahí, cada dispositivo de casa queda protegido sin instalar nada en él. Si quieres comparar interfaces, mira también AdGuard Home; y para llevar el filtro fuera de casa, súmale una VPN WireGuard.

Fuentes

  1. Documentación oficial de Pi-hole para Docker
  2. Imagen oficial docker-pi-hole en GitHub
  3. Anuncio de Pi-hole v6 en el blog oficial
  4. Imagen oficial pihole/pihole en Docker Hub

Ruta: Redes y acceso remoto seguro con Docker