Installer Pi-hole sur un NAS UGREEN : le guide complet (avec les pièges)

Bloquer les publicités et le tracking au niveau du réseau entier plutôt qu’appareil par appareil : c’est la promesse de Pi-hole. Voici comment l’installer sur un NAS UGREEN sous UGOS, avec une Freebox comme routeur, et surtout les pièges que les tutoriels génériques oublient.

Table des matières

Le principe

Pi-hole est un serveur DNS. Quand un appareil de votre réseau veut joindre un domaine, il demande d’abord son adresse IP. Pi-hole intercepte la question et répond 0.0.0.0 si le domaine est dans sa liste noire. La connexion n’a jamais lieu.

L’avantage sur un bloqueur navigateur : ça fonctionne partout, sur toutes les apps, sans rien installer sur les appareils. L’inconvénient, on y reviendra, c’est que le DNS ne distingue pas une pub d’un contenu quand les deux viennent du même domaine.

Étape 1 : vérifier le port 53

C’est le premier piège. UGOS fait tourner dnsmasq, qui occupe déjà le port DNS. En SSH sur le NAS :

sudo ss -tulpn | grep ':53 '

Résultat typique sur un UGREEN :

udp  UNCONN  127.0.0.1:53   users:(("dnsmasq",pid=2613,fd=4))
tcp  LISTEN  127.0.0.1:53   users:(("dnsmasq",pid=2613,fd=5))

Bonne nouvelle : dnsmasq n’écoute que sur 127.0.0.1 (la boucle locale), pas sur l’IP du NAS. Le port est donc libre côté réseau.

Mais attention : si vous laissez Docker binder 0.0.0.0:53 comme le font tous les tutoriels, ça inclut 127.0.0.1 et vous entrez en conflit avec dnsmasq. La solution est de binder explicitement sur l’IP du NAS.

Étape 2 : le docker-compose

Créez le dossier :

mkdir -p /volume1/docker/pihole/etc-pihole
cd /volume1/docker/pihole

Puis le fichier docker-compose.yml :

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    restart: unless-stopped
    ports:
      - "192.168.1.54:53:53/tcp"
      - "192.168.1.54:53:53/udp"
      - "8053:80/tcp"
    environment:
      TZ: 'Europe/Paris'
      FTLCONF_webserver_api_password: 'VOTRE_MOT_DE_PASSE'
      FTLCONF_dns_listeningMode: 'all'
    volumes:
      - /volume1/docker/pihole/etc-pihole:/etc/pihole
    cap_add:
      - NET_ADMIN

Remplacez 192.168.1.54 par l’IP de votre NAS.

Trois points à noter. Le port web est en 8053 pour ne pas entrer en collision avec l’interface UGOS (80/443) ni vos autres containers. Le FTLCONF_dns_listeningMode: all est indispensable en Docker, sinon Pi-hole refuse les requêtes venant du réseau local. Et NET_ADMIN est requis pour les fonctions réseau.

Lancez :

docker compose up -d

Testez immédiatement :

dig @192.168.1.54 google.com
dig @192.168.1.54 doubleclick.net

Le premier doit renvoyer une IP normale, le second 0.0.0.0 avec le flag aa (réponse autoritaire : c’est bien Pi-hole qui répond).

Étape 3 : configurer Pi-hole

Interface sur http://192.168.1.54:8053/admin.

Upstream DNS

Settings puis DNS. Décochez Google (coché par défaut) et choisissez un seul upstream.

C’est un piège classique : en cocher plusieurs semble prudent, mais Pi-hole répartit les requêtes entre eux. Si vous mélangez Quad9 (qui filtre les domaines malveillants) et Cloudflare (qui ne filtre pas), votre filtrage de sécurité devient aléatoire.

Recommandation : Quad9 (filtered, DNSSEC) seul. Cochez aussi « Use DNSSEC ». Ne cochez les colonnes IPv6 que si votre réseau est en IPv6 natif.

Listes de blocage

Adlists puis Add a new adlist. La liste StevenBlack est présente par défaut (environ 76 000 domaines). Un socle solide et sans faux positifs excessifs :

https://big.oisd.nl/ — généraliste, très bien maintenue
https://raw.githubusercontent.com/hagezi/dns-blocklists/main/domains/pro.txt — HaGeZi Pro, référence anti-tracking
https://raw.githubusercontent.com/hagezi/dns-blocklists/main/domains/tif.txt — HaGeZi Threat Intelligence, sécurité (phishing, malware)

Piège à connaître : prenez bien les versions /domains/ et non /wildcard/. Le format wildcard (*.exemple.com) n’est pas chargé par la Gravity de Pi-hole : les domaines sont comptés « ignored » et la liste ne bloque rien, alors que le rapport affiche quand même « Retrieval successful ».

Après ajout : Tools puis Update Gravity, sinon les listes ne sont jamais chargées.

Résistez à la tentation d’empiler quinze listes : ça multiplie les faux positifs sans gain réel, et c’est vous qui devrez débloquer à la main quand un site professionnel ne s’affichera plus.

Conditional forwarding

Settings puis DNS, tout en bas. Sans ça, votre dashboard n’affichera que des adresses IP au lieu des noms d’appareils, et les noms locaux ne se résoudront pas.

Network Range : 192.168.1.0/24
Server IP : 192.168.1.254 (l’IP de votre Freebox, à vérifier avec ip route | grep default)
Domain : lan

Piège d’interface : remplissez les trois champs, cliquez sur le bouton + pour ajouter la ligne au tableau, cochez Enabled, et seulement ensuite Save & Apply. Si vous sauvegardez sans avoir cliqué sur +, vous obtenez une erreur de validation obscure.

Étape 4 : la Freebox

Freebox OS puis Paramètres de la Freebox puis DHCP puis onglet Serveur DHCP. Dans la section DNS :

Serveur DNS 1 : 192.168.1.54
DNS 2 à 5 : videz-les

Pensez aussi à réserver l’IP du NAS dans l’onglet Baux Statiques, sinon vous perdrez votre DNS au premier renouvellement de bail.

Pourquoi ne pas mettre de DNS de secours

C’est contre-intuitif, mais laisser 8.8.8.8 en DNS 2 sabote votre installation. Les clients n’interrogent pas le DNS 1 en priorité avec bascule en cas de panne : ils choisissent souvent au hasard, ou interrogent en parallèle. Une bonne partie de vos requêtes partirait donc chez Google, en contournant Pi-hole. Vous auriez un blocage aléatoire et un Pi-hole à moitié inutile.

Le risque de tout casser est faible : Freebox OS reste accessible via http://192.168.1.254, une IP directe qui ne dépend d’aucune résolution DNS. Si Pi-hole tombe, vous remettez 8.8.8.8 en trente secondes. Mettez cette adresse en favori dès maintenant.

Étape 5 : le piège des DNS manuels

Vous avez tout configuré, vous naviguez, et les pubs sont toujours là. Vérifiez ce que votre machine utilise vraiment. Sur macOS :

scutil --dns | grep nameserver

Si vous voyez encore 8.8.8.8, deux causes possibles.

Le bail DHCP n’a pas été renouvelé. Coupez et rallumez le Wi-Fi, ou forcez :

sudo ipconfig set en0 DHCP

Vous avez des DNS saisis manuellement. C’est le cas le plus fréquent et le plus sournois : une configuration manuelle dans Réglages puis Réseau puis DNS écrase totalement ce que la Freebox distribue. Videz la liste (bouton moins), laissez vide pour que le DHCP reprenne la main.

Notez que dscacheutil -flushcache ne sert à rien ici : ça vide le cache des résolutions, pas la liste des serveurs.

Étape 6 : le piège IPv6

Celui-là est le plus sournois de tous. Vous avez tout réglé en IPv4, et pourtant des pubs passent encore. Regardez les DNS de votre téléphone : à côté de votre 192.168.1.54, vous verrez probablement une adresse IPv6 du type fd0f:ee:b0::1.

Cette adresse, c’est la Freebox qui s’annonce elle-même comme DNS IPv6, via les Router Advertisements (un mécanisme distinct du DHCPv6 : désactiver le DHCPv6 ne suffit donc pas à le couper). Comme l’IPv6 est souvent prioritaire, une partie de vos requêtes part par là et échappe totalement à Pi-hole.

La solution propre : faire écouter Pi-hole en IPv6, puis l’annoncer à la place de la Freebox. Récupérez l’adresse IPv6 globale du NAS :

ip -6 addr show dev eth0 | grep 'scope global'

Ajoutez les bindings IPv6 dans le compose (en remplaçant par votre adresse) :

    ports:
      - "192.168.1.54:53:53/tcp"
      - "192.168.1.54:53:53/udp"
      - "[VOTRE_IPV6]:53:53/tcp"
      - "[VOTRE_IPV6]:53:53/udp"
      - "8053:80/tcp"

Relancez le container et vérifiez qu’il répond en IPv6 :

docker compose up -d
dig @VOTRE_IPV6 doubleclick.net

Enfin, dans Freebox OS puis Configuration IPv6 puis onglet DNS IPv6 : cochez « Forcer l’utilisation de serveurs DNS IPv6 personnalisés » et saisissez l’IPv6 du NAS en primaire.

Note : la Freebox ne permet pas de réserver une IPv6 fixe par appareil comme en IPv4 (l’IPv6 fonctionne par auto-configuration SLAAC). Pour une adresse vraiment stable, il faut la fixer côté NAS dans la configuration réseau d’UGOS.

Étape 7 : les contournements à traquer

Trois mécanismes permettent à un appareil d’ignorer complètement Pi-hole.

Le DNS-over-HTTPS des navigateurs. Firefox, Chrome et Brave chiffrent leurs requêtes DNS vers leur propre résolveur. Dans Brave : Paramètres puis Confidentialité et sécurité puis Utiliser un DNS sécurisé, à désactiver.
Le DNS privé Android. Le plus silencieux : Paramètres puis Réseau et Internet puis DNS privé. S’il est sur « Automatique », le téléphone ignore votre Freebox. Mettez-le sur Désactivé.
Les DNS codés en dur. Beaucoup de TV connectées, Chromecast, Fire TV et objets connectés embarquent 8.8.8.8 en fallback et y basculent si votre DNS tarde à répondre.

Le seul test fiable reste le Query Log de Pi-hole : si les requêtes d’un appareil n’y apparaissent pas, il ne passe pas par lui.

Comprendre le taux de blocage

Une fois Pi-hole en route, le dashboard affiche vite un chiffre spectaculaire : 40, 50, parfois 60 % de requêtes bloquées. La tentation est de lire ça comme « la moitié de mon trafic Internet est de la pub ». C’est faux, et comprendre pourquoi évite un contresens répandu.

Ce pourcentage porte sur les requêtes DNS, pas sur le volume de données. Une requête DNS, c’est simplement un appareil qui demande « quelle est l’adresse IP de ce domaine ». Ça pèse quelques octets. Le contenu réel que vous téléchargez ensuite (une vidéo, une page, un jeu) représente des millions de fois plus d’octets, mais ne compte que pour une poignée de requêtes.

Autrement dit : un film de 3 Go tiré d’un seul domaine, c’est une requête. Une application qui « appelle la maison » toutes les dix secondes vers son serveur de télémétrie, c’est des centaines de requêtes pour zéro contenu utile. Le tracking et la télémétrie sont bavards par nature : ils réinterrogent le DNS en boucle, ce qui gonfle mécaniquement le compteur de blocage bien au-delà de leur poids réel dans votre bande passante.

Un taux de 50 % ne veut donc pas dire « la moitié de mon Internet est pourrie ». Il veut dire « la moitié des sollicitations DNS de mon réseau partent vers des domaines de pub, de tracking ou de télémétrie ». C’est déjà énorme, et c’est exactement ce que Pi-hole est là pour couper. Mais ne cherchez pas à maximiser ce chiffre : un taux très élevé peut aussi trahir une liste trop agressive qui casse des services légitimes. Tant que rien n’est cassé, le pourcentage est une curiosité, pas un objectif.

Ce que Pi-hole bloque vraiment

C’est là que les tutoriels sont malhonnêtes. La documentation officielle promet de « bloquer les pubs dans les apps mobiles et les smart TV ». C’est vrai, mais partiellement.

Ce qui marche bien : le tracking et la télémétrie (Firebase, Adjust, AppsFlyer, les remontées Samsung ou Android TV), les bannières AdMob dans les jeux, les pubs de l’écran d’accueil de certaines TV, et évidemment tout le tracking web.

Ce qui ne marche pas : les pubs pré-roll des replays (France TV et consorts), le streaming vidéo avec pub intégrée, YouTube. Raison structurelle : ces pubs sont servies depuis les mêmes domaines que le contenu. Bloquer le domaine casse l’application entière. Aucune liste ne résout ça, c’est une limite du DNS lui-même.

Ce qui marche mal : les pubs vidéo récompensées dans les jeux mobiles. Bloquées, elles ne chargent jamais, et beaucoup de jeux restent alors bloqués sur un écran de chargement plutôt que de passer à la suite. Vous remplacez trente secondes de pub par un jeu cassé.

Et hors du Wi-Fi maison, en 4G, Pi-hole n’a évidemment aucun effet.

Débloquer un faux positif

C’est le moment où la plupart des débutants abandonnent Pi-hole : un site pro ne s’affiche plus, un paiement échoue, une app tourne dans le vide, et on soupçonne tout sauf le filtrage DNS. Prenez le réflexe inverse : au premier comportement bizarre, ouvrez le Query Log.

Direction Query Log dans le menu. La liste défile en temps réel, chaque ligne étant une requête avec son statut. Les lignes en rouge (Blocked) sont celles que Pi-hole a refusées. Reproduisez l’action qui pose problème (rechargez la page, relancez le paiement) et regardez ce qui passe au rouge dans la foulée.

Une fois le domaine coupable identifié, deux façons de le débloquer.

Depuis le Query Log directement : chaque ligne bloquée a un bouton pour whitelister le domaine en un clic. Le plus rapide.
Depuis Domains (menu Domains puis Add a new domain) : ajoutez le domaine en Exact whitelist si vous connaissez son nom précis, ou en Regex whitelist pour couvrir tout un ensemble de sous-domaines d’un coup.

Un piège fréquent : le domaine bloqué n’est pas toujours celui qu’on croit. Un site de paiement légitime peut dépendre d’un domaine tiers d’antifraude ou d’analytics qui, lui, est sur une liste. Whitelistez le domaine techniquement bloqué au moment de l’échec, pas le domaine principal du site que vous avez sous les yeux.

Enfin, prévoyez de revenir dans le Query Log les premiers jours. C’est là que se règlent les rares faux positifs, et une fois cette phase de rodage passée, vous n’y touchez plus.

Pour aller plus loin

Une fois le socle en place, deux fonctions valent le détour.

Local DNS records (Settings puis Local DNS) : déclarez nas.lan vers 192.168.1.54 et accédez à vos services auto-hébergés par nom plutôt que par IP. Ça remplace avantageusement un fichier hosts sur chaque machine.
Groups et Clients : appliquez des listes différentes selon l’appareil. Filtrage strict sur la TV et les tablettes, permissif sur la machine de travail.

Pensez enfin à exporter votre configuration (Settings puis Teleporter) et à mettre le container à jour de temps en temps :

docker compose pull && docker compose up -d

En résumé

Pi-hole n’est pas la solution miracle vendue par son marketing, mais c’est un excellent outil de blocage du tracking à l’échelle du réseau, particulièrement utile pour les appareils sur lesquels vous ne pouvez rien installer. Comptez trente minutes d’installation, et prévoyez de revenir dans le Query Log les premiers jours pour débloquer les faux positifs.