VPN avec AdGuard Home ou Pi-hole : si les publicités reviennent, regardez d’abord qui répond au DNS

J’avais justement déplacé le blocage des publicités hors du navigateur pour ne plus dépendre du navigateur.

Mon Pi-hole tournait sur le réseau depuis des mois. Sur le portable, les pages d’actualité étaient plus propres, plusieurs applications bavardaient moins avec leurs régies publicitaires, et le journal DNS me permettait de voir ce qui était bloqué.

Le 31 août 2026, Google avait franchi la dernière étape de sa transition Manifest V2 en retirant du Chrome Web Store les dernières extensions concernées. Cela ne rend pas un bloqueur réseau équivalent à une extension de contenu, mais cela confortait mon choix : au moins, mon filtrage ne dépendait pas d’un module installé dans le navigateur.

J’étais donc plutôt satisfait de mon installation. Puis j’ai activé mon VPN. J’ai rechargé exactement la même page. Deux emplacements publicitaires sont revenus.

J’ai pensé à une liste Pi-hole trop vieille. J’ai forcé la mise à jour. Aucun changement. J’ai vérifié un second site dont je connaissais bien le résultat habituel : mêmes encarts revenus.

C’est seulement quand j’ai ouvert le journal des requêtes que j’ai vu l’indice utile.

Mon portable avait presque cessé de parler au Pi-hole.

Je coupais le VPN : les requêtes réapparaissaient dans le journal et certains domaines étaient bloqués.

Je rallumais le VPN : le journal devenait presque silencieux et les publicités revenaient. Le bloqueur n’était pas tombé en panne. Je venais simplement de l’enlever du chemin sans m’en rendre compte.

Pi-hole et AdGuard Home ne peuvent bloquer que les questions DNS qu’on leur pose

C’est la partie que j’avais mal comprise malgré des mois à regarder le tableau de bord.

AdGuard Home fonctionne comme un serveur DNS capable d’envoyer les domaines publicitaires ou de suivi vers une impasse. Pi-hole repose sur la même logique générale : pour profiter de son filtrage, l’appareil doit lui envoyer ses requêtes DNS. La documentation Pi-hole montre d’ailleurs comment utiliser WireGuard pour continuer à profiter de ce filtrage lorsqu’on se trouve à l’extérieur du réseau domestique.

Le moyen le plus simple de l’imaginer est de voir Pi-hole comme un standardiste.

Quand mon ordinateur lui demande : « Où se trouve exemple-publicite.com ? », il peut regarder sa liste et refuser de lui donner la bonne destination.

Mais s’il ne reçoit jamais la question, il ne peut rien bloquer.

Sa liste peut contenir dix mille ou dix millions de domaines : si le DNS passe ailleurs, Pi-hole reste assis derrière son bureau pendant que la connexion le contourne.

C’était exactement ce qui se produisait devant moi.

Dans mon cas, le VPN ne cassait pas Pi-hole : il changeait le DNS

Au début, j’avais traité ce comportement comme un bug.

En regardant de plus près, le changement avait beaucoup plus de sens.

Chez Proton, par exemple, les requêtes DNS passent normalement dans le tunnel vers les résolveurs du fournisseur afin d’éviter qu’elles ne sortent séparément. Le service permet d’utiliser un DNS personnalisé, mais cela devient alors un choix explicite dans la configuration.

Vu depuis mon bureau, la situation était presque comique. Le navigateur passait bien dans le tunnel. Mon IP publique avait bien changé. Le Pi-hole fonctionnait parfaitement pour les autres appareils de la maison.

Mais mon portable demandait désormais à quelqu’un d’autre où se trouvaient les domaines publicitaires.

Le résultat ressemblait à un bloqueur désactivé alors que le vrai changement s’était produit une étape plus tôt.

J’ai d’ailleurs reconnu exactement ce symptôme dans une discussion d’août 2026 sur AdGuard Home : les appareils locaux étaient filtrés normalement, tandis que des appareils connectés à distance par WireGuard contournaient les filtres et disparaissaient du journal des requêtes.

C’est le détail qui m’intéressait. Le journal vide. Je n’avais plus besoin d’ajouter une nouvelle blocklist. Je devais savoir qui répondait au DNS une fois le tunnel actif.

Ma première réparation a fonctionné à la maison — puis j’ai regardé mon téléphone

Le réflexe évident consistait à forcer l’adresse locale de mon Pi-hole comme DNS personnalisé.

192.168.1.53.

Sur mon réseau domestique, c’était logique. Avec un client VPN qui autorise un DNS personnalisé tout en laissant accéder au réseau local, cette configuration peut très bien fonctionner.

Après quelques réglages, j’ai retrouvé mon filtrage. Problème réglé. Ou presque. J’ai fermé le portable et regardé mon téléphone. En 5G, 192.168.1.53 ne voulait plus rien dire.

Cette adresse n’existe que chez moi. Pour continuer à utiliser le même Pi-hole depuis l’extérieur, il fallait rendre ce DNS accessible de façon sûre à travers un tunnel — précisément le type de montage que documente Pi-hole avec WireGuard.

C’était faisable.

Je pouvais garder mon VPN commercial, créer un accès sécurisé vers la maison, ajuster les routes et m’assurer que le DNS revenait vers mon réseau domestique quand j’étais dans un train, un hôtel ou simplement en 5G.

À ce moment-là, j’ai réalisé que je construisais une architecture beaucoup plus compliquée que mon problème.

Je ne cherchais pas à administrer mon Pi-hole depuis le train.

Je voulais activer un VPN et ne pas voir revenir les domaines publicitaires que j’avais déjà choisi de filtrer.

C’est là que mon critère a changé. La question n’était plus : « Quel VPN me laisse conserver exactement mon DNS local ? » Elle devenait : « Si le VPN prend le contrôle du DNS, est-ce que le filtrage peut partir avec lui ? »

J’ai laissé le tunnel garder le DNS — et déplacé le filtre avec lui

C’est pour cette raison que j’ai essayé le petit service que j’avais jusque-là considéré surtout comme un VPN de voyage.

Je n’ai pas cherché un serveur particulier.

Je n’ai pas commencé à modifier les protocoles.

J’ai activé son mode destiné à réduire les requêtes publicitaires et de suivi, puis j’ai rouvert les deux pages utilisées depuis le début.

Le tunnel est resté actif. L’adresse IP publique est restée celle du VPN. Le journal de mon Pi-hole, lui, est resté presque silencieux. Cette fois, je savais pourquoi. Je ne lui demandais plus de résoudre ces domaines.

La différence, c’est que les encarts qui étaient revenus avec mon ancien tunnel ne se sont pas rechargés dans cette configuration de test.

J’ai continué à naviguer quelques minutes. Puis j’ai regardé le compteur intégré des requêtes bloquées. Il montait. C’est ce petit compteur qui a fini de remettre les pièces dans le bon ordre. Je n’avais pas réparé Pi-hole. Je n’avais pas non plus forcé toutes mes requêtes à faire un détour par la maison.

J’avais simplement déplacé le point de filtrage vers la connexion qui gérait déjà le tunnel.

Et pour le problème que j’avais devant moi, c’était beaucoup plus propre.

Au lieu d’envoyer mon trafic dans un VPN tout en essayant de ramener le DNS jusqu’à mon réseau domestique, je laissais le tunnel gérer sa propre résolution et son propre filtrage.

Pas de modification du routeur. Pas de seconde route à maintenir. Pas d’adresse locale à rendre accessible depuis l’extérieur. Et surtout, je pouvais voir le résultat sur la page qui avait déclenché tout le diagnostic. Les publicités qui réapparaissaient lorsque j’activais l’ancien tunnel ne revenaient plus.

Il reste une limite que changer de VPN ne fera pas disparaître

Il y avait malgré tout une chose que je ne voulais pas confondre avec le problème précédent.

Un filtre DNS ne peut pas supprimer toutes les publicités.

AdGuard Home explique notamment qu’une publicité servie depuis le même domaine que le contenu voulu ne peut pas être bloquée proprement au niveau DNS : bloquer le domaine supprimerait aussi le contenu. C’est pourquoi certaines publicités vidéo, comme celles intégrées à certains flux, ou certains contenus sponsorisés résistent à ce type de filtrage.

Ce n’est pas le même problème que celui que j’avais observé.

Dans mon cas, les domaines publicitaires concernés étaient normalement arrêtés par mon bloqueur domestique. Ils revenaient précisément lorsque le tunnel détournait les requêtes DNS ailleurs.

C’est cette différence que je garderais pour le prochain diagnostic.

Si AdGuard Home ou Pi-hole fonctionne parfaitement jusqu’au moment où le cadenas VPN s’allume, je ne commencerais plus par ajouter des listes.

Je regarderais le journal DNS.

S’il cesse brutalement de recevoir les requêtes de l’appareil, le bloqueur n’a probablement rien oublié.

La conversation a simplement changé d’interlocuteur.

Un grand fournisseur peut résoudre le problème en permettant de remettre un DNS personnalisé. Une installation WireGuard maison peut, elle aussi, ramener proprement les requêtes vers Pi-hole. Si je voulais absolument conserver mon infrastructure domestique partout, ce seraient des solutions parfaitement cohérentes.

Moi, je voulais précisément arrêter d’avoir à transporter cette infrastructure avec moi.

Le petit service offre moins de localisations qu’un géant du secteur. C’est une limite réelle si l’on choisit son VPN principalement pour obtenir des dizaines de pays de sortie.

Mais devant les deux pages que j’avais ouvertes, ce n’était pas le nombre de drapeaux dans une liste qui décidait si les encarts publicitaires revenaient.

C’était l’endroit où se trouvait le filtre après l’ouverture du tunnel.

J’avais commencé par croire que mon VPN désactivait Pi-hole.

Le journal m’a montré quelque chose de beaucoup plus simple : Pi-hole n’était plus dans la conversation.

Depuis, mon test tient en une seule question : quand le cadenas VPN s’allume, qui répond maintenant au DNS — et est-ce que le filtrage est parti avec lui ?