Alt text via PUT request for Pi-hole dashboard

Monta Pi-hole en Docker: bloquea anuncios en toda tu red paso a paso

por

¿Qué necesitas?

Pi-hole es una de esas herramientas que parecen pequeñas, pero cuando la pones a funcionar te das cuenta de la cantidad de ruido que hay en tu red: publicidad, rastreadores, telemetría de Smart TV, dominios sospechosos, llamadas constantes de dispositivos IoT… Todo eso pasa por DNS, y ahí es donde Pi-hole hace su magia.

La idea es sencilla: en lugar de que cada dispositivo de tu casa pregunte directamente a Cloudflare, Google, tu operador o el DNS que tenga configurado, todos preguntan a Pi-hole. Y Pi-hole decide: esto lo dejo pasar, esto lo bloqueo.

Para montarlo en Docker necesitas:

  • Docker y Docker Compose instalados. Si no los tienes, en el artículo de Docker para tu empresa explico cómo montarlos.
  • Un servidor, mini PC, NAS o Raspberry Pi donde ejecutar el contenedor. Yo lo montaría en un equipo que esté siempre encendido.
  • Acceso al router para cambiar el DNS que entrega por DHCP. Es opcional, pero es lo más cómodo si quieres proteger toda la red.
  • Una IP fija o reserva DHCP para el equipo donde corre Pi-hole. Esto es importante: si cambia la IP, los dispositivos dejarán de encontrar el DNS.
  • Puerto 53 libre en el equipo donde lo montes, porque DNS usa el puerto 53 TCP/UDP.

Mi consejo: no montes Pi-hole en una máquina que apagas cada dos por tres. Si Pi-hole cae y todos tus dispositivos lo usan como DNS único, tu red “parece” que no tiene Internet aunque realmente lo que ha caído es la resolución DNS.

Paso 1: Prepara el terreno

Antes de lanzar el contenedor, comprueba si el puerto 53 está ocupado:

sudo ss -ltnup | grep ':53'

En Ubuntu puede aparecer systemd-resolved escuchando en 127.0.0.53:53. No siempre te va a bloquear el despliegue, pero si Docker intenta publicar Pi-hole en todas las interfaces y hay conflicto con el puerto 53, tendrás que ajustar la configuración.

Antes era muy habitual recomendar directamente:

sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved

Pero hoy prefiero no darlo como primera opción universal. Funciona, sí, pero también puede romper la resolución DNS del propio host si no sabes exactamente lo que estás haciendo.

La forma prudente sería:

  1. Comprobar si realmente hay conflicto con el puerto 53.
  2. Si lo hay, decidir si quieres desactivar el stub listener de systemd-resolved, usar otra IP, usar network_mode: host, usar macvlan o mover otros servicios.
  3. No tocar nada si no hace falta.

Para este artículo voy a usar el caso más habitual: Pi-hole en Docker publicando el puerto 53 en el host.

Creamos la carpeta:

mkdir -p ~/docker/pihole
cd ~/docker/pihole

Paso 2: Crea el docker-compose.yml actualizado

Crea el archivo:

nano docker-compose.yml

Y pega este contenido:

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    hostname: pihole
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "8080:80/tcp"
      # Si quieres usar HTTPS nativo de Pi-hole v6, puedes publicar también:
      # - "8443:443/tcp"
    environment:
      TZ: "Europe/Madrid"

      # Pi-hole v6: esta es la variable correcta para fijar la contraseña web.
      # Cambia esta contraseña antes de levantar el contenedor.
      FTLCONF_webserver_api_password: "pon-tu-contrasena-aqui"

      # Necesario en Docker bridge para que Pi-hole escuche correctamente.
      FTLCONF_dns_listeningMode: "ALL"

      # DNS upstream. Puedes usar Cloudflare, Quad9, Google, OpenDNS, etc.
      # Yo suelo usar Cloudflare o Quad9 según el objetivo.
      FTLCONF_dns_upstreams: "1.1.1.1;1.0.0.1"

      # DNSSEC valida firmas DNSSEC cuando el dominio lo soporta.
      FTLCONF_dns_dnssec: "true"

    volumes:
      - "./etc-pihole:/etc/pihole"

    restart: unless-stopped

Desglose rápido:

Variable Qué hace
TZ Define la zona horaria. En España peninsular: Europe/Madrid.
FTLCONF_webserver_api_password Contraseña del panel web en Pi-hole v6. Sustituye a los ejemplos antiguos con WEBPASSWORD.
FTLCONF_dns_listeningMode En Docker bridge conviene poner ALL para que Pi-hole escuche correctamente las consultas DNS.
FTLCONF_dns_upstreams DNS a los que Pi-hole preguntará cuando un dominio no esté bloqueado.
FTLCONF_dns_dnssec Activa DNSSEC. No cifra el DNS, pero ayuda a validar respuestas DNS cuando el dominio lo soporta.

He mapeado el panel web como 8080:80 para evitar conflictos si ya tienes otro servicio usando el puerto 80. Así entrarás por:

http://IP-DE-TU-SERVIDOR:8080/admin

Si prefieres que Pi-hole use directamente el puerto 80, cambia:

- "8080:80/tcp"

por:

- "80:80/tcp"

Paso 3: Arranca Pi-hole

Levanta el contenedor:

docker compose up -d

Comprueba que está corriendo:

docker ps | grep pihole

Y revisa logs si algo falla:

docker logs pihole

Si no has fijado contraseña, Pi-hole puede generar una aleatoria y mostrarla en los logs. Aun así, para un entorno doméstico serio prefiero dejar la contraseña definida en el Compose o, mejor todavía, gestionarla con un secreto o variable externa.

Si cambias la contraseña en el docker-compose.yml, aplica los cambios con:

docker compose up -d

Paso 4: Accede al panel web

Abre el navegador y entra en:

http://IP-DE-TU-SERVIDOR:8080/admin
Pantalla de inicio de sesión del panel de administración de Pi-hole

Introduce la contraseña que has puesto en FTLCONF_webserver_api_password.

Lo primero que verás es el panel con estadísticas: consultas DNS totales, consultas bloqueadas, clientes, dominios más consultados y dominios más bloqueados.

Al principio puede parecer poca cosa, pero dale unas horas. Cuando empieces a ver qué dispositivos consultan qué dominios, entiendes rápidamente por qué merece la pena tener un DNS propio en casa.

Paso 5: Añadir listas de bloqueo

Pi-hole ya es útil con una lista base, pero donde realmente empieza a limpiar la red es cuando eliges buenas listas de bloqueo.

Y aquí viene una advertencia importante: no gana quien mete más listas. Meter 40 listas sin criterio puede darte más falsos positivos, más dominios duplicados y más problemas. Es mejor usar pocas listas buenas, mantenidas y con reputación.

Mi enfoque sería este:

  • Una lista principal equilibrada para anuncios, tracking y telemetría.
  • Una lista de seguridad para malware, phishing y dominios peligrosos.
  • Alguna lista específica si tienes una necesidad concreta: Smart TV, contenido adulto, apuestas, redes sociales, etc.
  • Una lista orientada a España/español si navegas mucho por medios españoles, webs locales o contenido en castellano.

Ve a Group Management → Adlists y añade las URLs que te interesen. Después ejecuta Tools → Update Gravity o lanza:

docker exec -it pihole pihole -g

Mi selección recomendada para España

Estas son las listas que yo usaría como punto de partida. No son “las únicas buenas”, pero sí una base razonable y mantenible.

1. HaGeZi Multi Pro — mi lista principal recomendada

https://raw.githubusercontent.com/hagezi/dns-blocklists/main/adblock/pro.txt
  • Qué bloquea: publicidad, tracking, métricas, telemetría, phishing, malware, scams, criptominería y dominios basura.
  • Por qué la usaría: HaGeZi es de las blocklists más cuidadas actualmente. La versión Pro es un buen equilibrio entre protección y falsos positivos.
  • Para quién: redes domésticas donde hay alguien que sabe revisar el Query Log si algo falla.

Si quieres algo más suave, usa HaGeZi Normal:

https://raw.githubusercontent.com/hagezi/dns-blocklists/main/adblock/multi.txt

Y si quieres algo más agresivo, puedes probar Pro++, pero no lo pondría de entrada en una red familiar sin estar dispuesto a revisar bloqueos:

https://raw.githubusercontent.com/hagezi/dns-blocklists/main/adblock/pro.plus.txt

2. OISD Big — equilibrada y con pocos falsos positivos

https://big.oisd.nl/
  • Qué bloquea: publicidad, trackers, malware, phishing y dominios molestos.
  • Por qué la usaría: OISD tiene fama de ser muy cuidadosa con falsos positivos. Es una lista muy cómoda para redes donde quieres bloquear bastante sin estar arreglando cosas cada dos días.
  • Para quién: usuarios que quieren algo potente pero estable.

Si prefieres una versión más ligera:

https://small.oisd.nl/

Mi consejo: elige HaGeZi Pro u OISD Big como lista principal. Puedes usar ambas, pero habrá solapamiento. No pasa nada grave, Pi-hole deduplica dominios, pero tampoco hace falta inflar Gravity porque sí.

3. StevenBlack Hosts — la clásica

https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
  • Qué bloquea: dominios de anuncios, tracking y malware procedentes de varias fuentes consolidadas.
  • Por qué la usaría: es una lista clásica, muy conocida y estable.
  • Para quién: quien quiere una base sencilla y conservadora.

Si ya usas HaGeZi Pro u OISD Big, puede que StevenBlack aporte menos porque hay mucho solapamiento. Pero como lista base sigue siendo perfectamente válida.

4. EasyList Spanish convertida a formato Pi-hole — para webs en español

https://codeberg.org/ZingyAwesome/easylists-for-pihole/raw/branch/master/language/easylistspanish.txt
  • Qué bloquea: dominios publicitarios usados en webs en español.
  • Por qué la usaría: si navegas mucho por medios españoles, blogs, foros y webs hispanas, una lista específica de idioma puede cubrir cosas que las listas globales no priorizan.
  • Matiz importante: la EasyList Spanish original es una lista de filtros para bloqueadores de navegador, no una lista DNS pura. Por eso aquí uso una versión convertida a formato compatible con Pi-hole.

Esta es la parte más enfocada a España. Aun así, no esperes milagros: muchos anuncios modernos se sirven desde dominios compartidos, CDNs o scripts que un DNS no puede distinguir tan bien como una extensión de navegador tipo uBlock Origin.

5. Blocklist Project Smart TV — para callar televisores demasiado habladores

https://raw.githubusercontent.com/blocklistproject/Lists/master/smart-tv.txt
  • Qué bloquea: telemetría y tracking de Smart TV y dispositivos multimedia.
  • Por qué la usaría: las Smart TV son de los dispositivos más pesados en telemetría. Algunas hacen consultas constantemente aunque apenas las uses.
  • Advertencia: puede romper funciones concretas de apps de TV, recomendaciones, login o servicios integrados. Si pasa, toca revisar el Query Log y permitir lo necesario.

6. Stalkerware Indicators — seguridad extra

https://raw.githubusercontent.com/Te-k/stalkerware-indicators/master/generated/hosts
  • Qué bloquea: dominios asociados a stalkerware y software de espionaje.
  • Por qué la usaría: no es una lista de publicidad, es una lista de seguridad. Me parece interesante en una red familiar o doméstica.
  • Matiz: no sustituye a un antivirus, EDR o buenas prácticas. Solo añade una capa DNS.

Listas opcionales según el caso

Estas no las activaría en todas las redes, pero pueden tener sentido según la casa.

Contenido adulto

https://nsfw.oisd.nl/

Útil si quieres filtrar contenido adulto a nivel DNS. Ojo: ningún filtro DNS es perfecto y no sustituye a controles parentales bien configurados.

Apuestas y gambling

https://raw.githubusercontent.com/hagezi/dns-blocklists/main/adblock/gambling.txt

Útil si quieres bloquear webs de apuestas. En España puede tener mucho sentido si quieres reducir exposición a casas de apuestas o proteger ciertos perfiles de la red.

Threat Intelligence de HaGeZi

https://raw.githubusercontent.com/hagezi/dns-blocklists/main/adblock/tif.mini.txt

Añade protección frente a phishing, malware, scams y dominios maliciosos. Yo empezaría por la versión mini para no meter una lista enorme sin necesidad. Si tienes un homelab más serio y recursos de sobra, puedes valorar versiones más completas.

Mi combinación recomendada

Para una red doméstica en España, yo empezaría con esto:

https://raw.githubusercontent.com/hagezi/dns-blocklists/main/adblock/pro.txt
https://big.oisd.nl/
https://codeberg.org/ZingyAwesome/easylists-for-pihole/raw/branch/master/language/easylistspanish.txt
https://raw.githubusercontent.com/blocklistproject/Lists/master/smart-tv.txt
https://raw.githubusercontent.com/Te-k/stalkerware-indicators/master/generated/hosts

Y si quiero algo más conservador:

https://big.oisd.nl/
https://codeberg.org/ZingyAwesome/easylists-for-pihole/raw/branch/master/language/easylistspanish.txt
https://raw.githubusercontent.com/blocklistproject/Lists/master/smart-tv.txt

Si algo se rompe, no añadas más listas: haz justo lo contrario. Revisa qué lista lo ha bloqueado, decide si necesitas permitir ese dominio o si esa lista es demasiado agresiva para tu casa.

Listas que no recomiendo para “bloquear YouTube Ads”

Pi-hole bloquea dominios DNS. El problema es que YouTube sirve muchos anuncios desde la misma infraestructura que el vídeo. Si bloqueas el dominio, muchas veces bloqueas también el contenido. Por eso no considero honesto prometer “bloqueo de anuncios de YouTube” con Pi-hole.

Para YouTube, lo más realista es:

  • En navegador: usar un bloqueador tipo uBlock Origin.
  • En Smart TV: asumir que Pi-hole no lo va a resolver de forma fiable.
  • Si quieres algo oficial y sin guerra técnica: YouTube Premium.

Pi-hole es muy bueno bloqueando publicidad y tracking a nivel DNS, pero no hace magia.

Paso 6: Configura tu router para que use Pi-hole

Este es el paso clave. Si solo configuras Pi-hole pero tus dispositivos siguen usando el DNS del router o del operador, no habrás conseguido gran cosa.

La opción ideal es cambiar el DNS que entrega el router por DHCP.

En la mayoría de routers

  1. Entra en la configuración del router, normalmente 192.168.1.1 o 192.168.0.1.
  2. Busca DHCP Server, LAN, Red local o DNS.
  3. Pon como DNS primario la IP del servidor donde corre Pi-hole.
  4. Guarda cambios.
  5. Renueva DHCP en los dispositivos o reinícialos.
Configuración DHCP del router con la IP de Pi-hole como DNS primario

¿Pongo un DNS secundario como 1.1.1.1?

Esta es una duda típica. Técnicamente puedes poner 1.1.1.1, 8.8.8.8 o cualquier otro DNS como secundario, pero hay trampa: muchos dispositivos no esperan a que falle el primero para usar el segundo. Pueden repartir consultas entre ambos.

Eso significa que si pones:

  • DNS primario: Pi-hole
  • DNS secundario: Cloudflare

algunas consultas pueden saltarse Pi-hole. Resultado: menos bloqueo y estadísticas incompletas.

Mi recomendación:

  • Opción simple: pon solo Pi-hole como DNS.
  • Opción robusta: monta dos Pi-hole y pon ambos como DNS primario/secundario.
  • Opción avanzada: fuerza en el firewall/router que todo DNS de la red pase por Pi-hole.

Si tu router no permite cambiar el DNS por DHCP, puedes configurar Pi-hole como servidor DHCP, pero eso ya lo dejaría para una segunda parte. Funciona bien, pero conviene entenderlo antes de tocarlo.

Paso 7: Verifica que funciona

Después de configurar el router, entra en:

http://IP-DE-TU-PIHOLE:8080/admin

Y revisa:

  • Total queries: consultas DNS totales.
  • Queries blocked: consultas bloqueadas.
  • Top clients: dispositivos que más consultan.
  • Top blocked domains: dominios más bloqueados.

También puedes probar desde un equipo de la red:

nslookup doubleclick.net IP-DE-TU-PIHOLE

O:

dig doubleclick.net @IP-DE-TU-PIHOLE

Si Pi-hole está funcionando y el dominio está bloqueado, deberías ver una respuesta bloqueada o una resolución alterada según el modo de bloqueo configurado.

Si ves 0 consultas después de un rato, revisa:

  • ¿El router está entregando como DNS la IP correcta de Pi-hole?
  • ¿El servidor tiene IP fija o reserva DHCP?
  • ¿El firewall permite el puerto 53 UDP/TCP?
  • ¿El contenedor está corriendo?
  • ¿Algún dispositivo usa DNS privado, DoH o DNS manual?

En Android, por ejemplo, revisa si tienes activado DNS privado. En navegadores modernos también puede estar activo DNS-over-HTTPS. Si el dispositivo usa DoH directamente contra un proveedor externo, puede saltarse Pi-hole.

Paso 8: Whitelist — cuando Pi-hole bloquea algo que no debería

Ninguna lista es perfecta. Puede pasar que una web legítima deje de funcionar porque Pi-hole está bloqueando algún dominio necesario.

Para solucionarlo:

  1. Ve a Tools → Query Log.
  2. Filtra por el dispositivo que tiene el problema.
  3. Reproduce el fallo.
  4. Mira qué dominios aparecen bloqueados justo en ese momento.
  5. Permite solo el dominio necesario.

No hagas whitelist a lo loco. La gracia está en permitir lo mínimo necesario.

Ejemplos de dominios que pueden aparecer en problemas reales:

  • connectivitycheck.gstatic.com — comprobación de conectividad en Android.
  • ocsp.digicert.com — validación de certificados.
  • api.whatsapp.com — enlaces y funciones de WhatsApp.

No significa que tengas que permitirlos siempre. Significa que, si algo falla, son dominios que pueden aparecer en el diagnóstico.

Monitorización básica

Una vez que Pi-hole lleva unas horas funcionando, el dashboard empieza a contar una historia bastante interesante de tu red.

  • Top blocked domains: qué dominios intenta consultar más tu red y están bloqueados.
  • Top clients: qué dispositivos hacen más consultas DNS.
  • Query types: tipos de registros consultados: A, AAAA, HTTPS, SVCB, etc.
  • Recent queries: útil para saber qué pasa justo cuando una app falla.

Lo más revelador suele ser ver qué hacen los dispositivos IoT. Una bombilla, una cámara o una Smart TV haciendo consultas cada pocos segundos a dominios de telemetría es una de esas cosas que no ves hasta que tienes un DNS que te lo enseña.

Dashboard principal de Pi-hole con gráfico de consultas bloqueadas y permitidas en tiempo real

Para mí, esta parte es casi más valiosa que el bloqueo de anuncios. Pi-hole te da visibilidad. Y cuando ves lo que ocurre en tu red, empiezas a tomar mejores decisiones.

Qué puedes y qué no puedes esperar de Pi-hole

Pi-hole no es un antivirus, no es un firewall completo y no sustituye a una buena configuración de seguridad. Es una capa DNS. Muy útil, pero una capa.

Pi-hole sí ayuda con Pi-hole no resuelve del todo
Bloqueo de muchos dominios publicitarios Anuncios servidos desde el mismo dominio que el contenido
Reducción de tracking DNS Tracking integrado dentro de apps o conexiones directas por IP
Bloqueo de dominios de malware/phishing conocidos Malware que usa dominios nuevos, IP directa o DoH propio
Telemetría de Smart TV e IoT Dispositivos que ignoran el DNS de la red
Visibilidad de consultas DNS Inspección completa de tráfico cifrado

La forma correcta de verlo es esta: Pi-hole no lo bloquea todo, pero reduce muchísimo el ruido y te da control.

Resumen y siguientes pasos

En muy poco tiempo puedes tener Pi-hole funcionando y filtrando DNS para toda tu red. No necesitas instalar extensiones en cada dispositivo, no dependes de cada navegador y puedes ver desde un único panel qué dominios se consultan y cuáles se bloquean.

Lo que consigues:

Antes Después
Cada dispositivo resuelve DNS por su cuenta DNS centralizado y controlado
Muchos anuncios y rastreadores pasan sin control Bloqueo a nivel de red
Smart TV e IoT envían telemetría sin que lo veas Visibilidad y bloqueo de dominios sospechosos
Cada navegador necesita su extensión Una capa común para toda la red
No sabes qué consulta cada dispositivo Dashboard con estadísticas y logs

Siguiente paso lógico: si quieres más control granular, perfiles por dispositivo, DoH integrado y una interfaz diferente, échale un ojo al artículo de cómo montar AdGuard Home en Docker.

Y si quieres acceder a tu red desde fuera de forma segura, el artículo de WireGuard en tu homelab te cubre esa parte.

¿Te ha sido útil? ¿Has encontrado alguna lista que funcione especialmente bien en España? Cuéntalo en los comentarios — las experiencias reales son las que más enseñan.

Nota editorial: Las URLs de las listas de bloqueo estaban verificadas en el momento de revisar este artículo. El ecosistema de blocklists cambia mucho: proyectos que hoy funcionan pueden moverse, fusionarse o abandonarse. Por eso recomiendo revisar periódicamente las listas activas, usar pocas fuentes fiables y no convertir Pi-hole en un vertedero de URLs.

Artículos relacionados

Deja un comentario