Homelab

3 Errores que Hacen que tu Pi-hole NO Esté Bloqueando Nada

By July 14, 2026No Comments

Instalaste Pi-hole, apuntaste el DNS de tu router, y aun así siguen apareciendo anuncios. ¿Te suena? Aquí están los 3 errores más comunes — y cómo arreglar cada uno.

Error #1: Tu navegador tiene DNS encriptado activado

Chrome (y la mayoría de los navegadores modernos) traen una opción llamada “Secure DNS” o DNS-over-HTTPS (DoH). Cuando está activada, el navegador le pregunta directamente a Google o Cloudflare por la IP de un sitio, viajando disfrazado de tráfico HTTPS normal (puerto 443) — sin pasar por tu Pi-hole en ningún momento.

Resultado: tu Pi-hole no ve la consulta, y por lo tanto no puede bloquear nada.

Cómo arreglarlo:

  • En Chrome: ve a chrome://settings/security → busca “Use secure DNS” → apágalo.
  • En Firefox (que además trae DoH activado por defecto): ve a Configuración → Privacidad y seguridad, baja hasta la sección “DNS sobre HTTPS” y selecciona “Desactivado” (o entra a about:config y pon network.trr.mode en 5, si prefieres el método técnico).
  • Forzado a nivel de organización (si administras varios equipos, como en un hogar con varios usuarios o una oficina):
    • Windows (Registro):
      • Chrome: HKLM\SOFTWARE\Policies\Google\Chrome → DnsOverHttpsMode = "off"
      • Firefox: HKLM\SOFTWARE\Policies\Mozilla\Firefox\DNSOverHTTPS → Enabled = 0
    • macOS/Linux (managed policy JSON, Chrome): { "DnsOverHttpsMode": "off" }
  • A nivel de DNS (complemento, no solución completa): suma a tu Pi-hole el blocklist de HaGeZi que bloquea los dominios de los proveedores de DoH conocidos: 
    https://raw.githubusercontent.com/hagezi/dns-blocklists/main/wildcard/doh-vpn-proxy-bypass.txt

    Esto no bloquea el puerto 443 en sí (no se puede, sin romper el resto de internet), pero bloquea el dominio/bootstrap que el navegador necesita para “encontrar” el resolver DoH.

Error #2: Tus equipos “smart” tienen DNS interno hardcoded

Google Home, Chromecast, Roku y muchas smart TVs vienen con su propio servidor DNS programado de fábrica. No importa lo que configures en el router — estos equipos ignoran por completo esa configuración y le preguntan directamente a su propio servidor, a veces incluso usando DNS-over-TLS (DoT) o DNS-over-QUIC (DoQ) por el puerto 853.

La única forma real de pararlos es a nivel de firewall, no de configuración de red.

Cómo arreglarlo:

Paso 1 — Redirige por la fuerza el puerto 53 hacia tu Pi-hole, así cualquier consulta DNS normal que no vaya dirigida a tu Pi-hole se reencamina hacia allá:

UniFi (Network → Settings → Firewall & Security → Create New Rule):

 

TP-Link Omada (línea empresarial, no la Archer de consumo):

  • Ve al Omada Controller → Settings → Transmission → Firewall/ACL
  • Crea una nueva regla ACL: Action: Deny, Protocol: TCP/UDP, Destination Port: 853, Source: LAN
  • Nota: los Archer de consumo normales (sin Omada) no traen control granular de puertos — solo filtrado básico por HomeShield.

ASUS (AsusWRT):

  • Ve a Firewall → Network Services Filter
  • Actívalo, y agrega una regla bloqueando el puerto de destino 853 (TCP y UDP) para el rango de IPs de tu LAN.

pfSense / OPNsense:

  • Ve a Firewall → Rules → LAN
  • Crea una regla: Action: Block, Protocol: TCP/UDP, Destination: any, Destination Port: 853
  • Ponla arriba de cualquier regla “Allow all” existente, ya que pfSense evalúa las reglas en orden.

MikroTik RouterOS:

/ip firewall nat add chain=dstnat protocol=udp dst-port=53 src-address=!<IP_DE_TU_PIHOLE> action=dst-nat to-addresses=<IP_DE_TU_PIHOLE> to-ports=53 comment="Force DNS -> Pi-hole (UDP)"
/ip firewall nat add chain=dstnat protocol=tcp dst-port=53 src-address=!<IP_DE_TU_PIHOLE> action=dst-nat to-addresses=<IP_DE_TU_PIHOLE> to-ports=53 comment="Force DNS -> Pi-hole (TCP)"

OpenWrt / Linux como gateway (si Pi-hole corre en el mismo router):

iptables -t nat -A PREROUTING -p udp --dport 53 ! -s <IP_DE_TU_PIHOLE> -j DNAT --to-destination <IP_DE_TU_PIHOLE>:53
iptables -t nat -A PREROUTING -p tcp --dport 53 ! -s <IP_DE_TU_PIHOLE> -j DNAT --to-destination <IP_DE_TU_PIHOLE>:53

pfSense / OPNsense:

  • Ve a Firewall → NAT → Port Forward
  • Crea una regla: Interface: LAN, Protocol: TCP/UDP, Destination: any, Destination Port: 53, Redirect target IP: <IP_DE_TU_PIHOLE>, Redirect target port: 53
  • Agrega una excepción (arriba de esta regla) para que el tráfico que ya viene de tu Pi-hole no se redirija a sí mismo.

TP-Link Omada / ASUS: estos no traen NAT/redirección de puerto DNS de forma nativa en la interfaz estándar — para forzar el puerto 53 en estos equipos generalmente es más práctico simplemente configurar el DNS de la red (DHCP) para que apunte directo a tu Pi-hole, y usar las reglas de bloqueo del Paso 2 como respaldo para los equipos que ignoren esa configuración.

Paso 2 — Bloquea DoT/DoQ (puerto 853) saliendo directo a internet:

MikroTik RouterOS:

/ip firewall filter add chain=forward protocol=tcp dst-port=853 action=drop comment="Block DoT bypass"
/ip firewall filter add chain=forward protocol=udp dst-port=853 action=drop comment="Block DoQ bypass"

 

OpenWrt / Linux como gateway:

iptables -A FORWARD -p tcp --dport 853 -j DROP
iptables -A FORWARD -p udp --dport 853 -j DROP

 

Error #3: O tienes muy pocas blocklists, o tienes demasiadas

Y ojo con esto: si usas 1 sola lista, no bloqueas nada. Si usas 15, ahora ni tu banco carga. El balance está en 2 a 6 listas bien elegidas — no en coleccionarlas todas como Pokémon.

Más listas no significa más protección. Significa más solapes, más falsos positivos, y un dolor de cabeza cuando algo se rompe y no sabes cuál de tus 15 listas fue la culpable.

La base que recomiendo: el repositorio hagezi/dns-blocklists, que organiza las listas por nivel de agresividad:

Nivel Para quién es
Light Casi no genera restricciones — ideal si no hay un admin cerca para desbloquear cosas
Normal El punto de partida recomendado para la mayoría de los hogares
Pro Para hogares técnicos o quien quiera un filtrado más estricto
Pro++ Más agresivo, ya requiere mantenimiento activo
Ultimate Solo si estás dispuesto a whitelistear seguido

Además del nivel base, puedes sumar listas especializadas según tu caso:

  • Threat Intelligence Feeds (TIF) — dominios de malware, phishing y C2 conocidos. Casi siempre vale la pena sumarla.
  • DoH/VPN/TOR/Proxy Bypass — la misma que mencionamos en el Error #1.
  • Gambling, Anti Piracy, NSFW, Social Networks — si estás filtrando para toda la familia.

Mi recomendación práctica:

  • Casa “normal”: HaGeZi Multi Normal + Threat Intelligence Feeds
  • Homelab técnico: HaGeZi Multi Pro + TIF + DoH/VPN/Proxy Bypass
  • Protección familiar: HaGeZi Multi Normal o Pro + Gambling/Anti Piracy/NSFW según aplique

Eso te deja entre 2 y 4 listas activas — lejos de los dos extremos.

Cómo instalarlas:

  1. Entra a tu panel de Pi-hole → Adlists (bajo Group Management).
  2. Pega la URL raw de la lista. Por ejemplo, para Multi Normal: 
    https://raw.githubusercontent.com/hagezi/dns-blocklists/main/adblock/multi.txt
  3. Corre pihole -g para reconstruir gravity.
  4. Agrega las listas de una en una, dale unos días de uso normal antes de sumar la siguiente — así, si algo se rompe, sabes cuál revisar.

Resumen

Si tu Pi-hole no está bloqueando lo que debería, revisa estas tres cosas en orden:

  1. DoH apagado en los navegadores (o filtrado a nivel de DNS)
  2. Puerto 53 redirigido a la fuerza y puerto 853 bloqueado en tu firewall, para atrapar los equipos con DNS hardcoded
  3. 2 a 6 blocklists bien elegidas — ni muy pocas, ni una colección de Pokémon

Con estos tres puntos resueltos, tu Pi-hole finalmente ve — y bloquea — el 100% del tráfico DNS de tu red.