Configurer AdGuard Home sur un VPS
Installer AdGuard Home sur Ubuntu, terminer l’assistant de premier lancement, verrouiller l’interface web, activer DNS-over-HTTPS et DNS-over-TLS, pointer les appareils vers votre résolveur, et éviter d’exploiter un serveur DNS ouvert que tout Internet peut abuser.

AdGuard Home est un puits DNS auto-hébergé et un résolveur de type récursif avec interface web. Il peut bloquer publicités, traqueurs et domaines malveillants pour chaque appareil qui l’utilise comme DNS — téléphones, ordinateurs portables, téléviseurs connectés et autres projets VPS. Contrairement à une extension de navigateur, il fonctionne même pour les applications qui ignorent les fichiers hosts. Le faire tourner sur un VPS est utile quand vous voulez le même filtrage en déplacement, ou quand vous ne voulez pas de Raspberry Pi sur le réseau domestique.
Le défaut dangereux à ne surtout pas livrer est un résolveur ouvert : si UDP/TCP 53 est joignable depuis tout Internet sans contrôle d’accès, des inconnus utiliseront votre VPS pour de l’amplification DNS et vous recevrez des plaintes d’abus. Ce guide installe AdGuard Home sur Ubuntu, lie le DNS à localhost ou à une interface WireGuard privée sauf si vous exposez délibérément le DNS chiffré, place le tableau de bord en HTTPS, et montre comment ordinateurs et téléphones peuvent utiliser DNS-over-HTTPS (DoH) ou DNS-over-TLS (DoT) sans ouvrir le port 53 classique au monde entier.
À quoi AdGuard Home convient bien
Pi-hole est la comparaison habituelle. AdGuard Home est un binaire unique avec interface web intégrée, frontaux DNS chiffrés optionnels et réglages par client. Vous pouvez le faire tourner dans Docker ou comme service systemd. Sur un VPS Hiddence, il s’associe bien à un VPN privé : les appareils rejoignent WireGuard, envoient le DNS au VPS dans le tunnel, et n’exposent jamais le port 53 publiquement.
- Blocage à l’échelle du réseau sans installer une application sur chaque appareil
- DoH (443) et DoT (853) pour que le DNS ne circule pas en clair sur le Wi-Fi public
- Journal des requêtes et statistiques pour voir quel appareil parle à quel domaine
- Upstreams personnalisés (Quad9, Cloudflare, ou votre propre Unbound)
- Empreinte légère — un VPS de 1 Go peut filtrer un foyer plus quelques clients supplémentaires
Prérequis
Il vous faut un domaine si vous voulez un certificat de confiance pour DoH/DoT et pour le tableau de bord. Vous pouvez tester en HTTP et avec l’IP du serveur d’abord, mais ne laissez pas les choses ainsi. Si systemd-resolved occupe déjà le port 53 sur Ubuntu, nous le libérerons avant qu’AdGuard Home ne lie le DNS.
- VPS Ubuntu 22.04 ou 24.04 avec root/sudo
- 1 Go de RAM suffit pour un usage personnel
- Un domaine ou sous-domaine (dns.example.com) avec un enregistrement A vers le VPS
- Accès SSH ; WireGuard optionnel si vous voulez le DNS uniquement dans un tunnel
Étape 1 : Libérer le port 53 et installer AdGuard Home
Ubuntu Server fait souvent tourner systemd-resolved comme stub sur 127.0.0.53:53. AdGuard Home veut le 53 sur les interfaces que vous choisissez. L’installeur peut s’en charger, mais le faire explicitement évite un DNS à moitié cassé sur le VPS lui-même (le serveur doit encore résoudre les paquets).
ssh root@YOUR_VPS_IP
apt update && apt -y upgrade
apt -y install curl ca-certificates
# See who owns port 53:
ss -tulpn | grep ':53'
# Typical Ubuntu fix: stop stub listener, point the OS at a temporary resolver
mkdir -p /etc/systemd/resolved.conf.d
cat >/etc/systemd/resolved.conf.d/adguardhome.conf <<'EOF'
[Resolve]
DNS=1.1.1.1
DNSStubListener=no
EOF
ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved
curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -vÉtape 2 : Assistant de premier lancement
L’installeur affiche une URL, en général http://YOUR_IP:3000/. Ouvrez-la, créez un utilisateur administrateur avec un long mot de passe, et choisissez les adresses d’écoute. Pour un VPS public, une première config sûre est : Admin Web sur 127.0.0.1:3000 (Caddy devant) ou sur 80/443 après TLS ; écoute DNS sur 127.0.0.1:53 plus une interface VPN, pas sur 0.0.0.0:53. Si vous avez vraiment besoin d’un DNS de type LAN pour des amis, préférez DoH/DoT sur 443/853 avec authentification, pas un 53/udp ouvert.
Choisissez des serveurs DNS amont auxquels vous faites confiance. Beaucoup utilisent https://dns.quad9.net/dns-query ou Cloudflare. Activez les requêtes parallèles si vous voulez un basculement plus rapide. Activez les listes de filtres par défaut, puis ajoutez-en plus tard — cinquante listes dès le premier jour rendent le débogage impossible quand un site casse.
Étape 3 : Reverse proxy et HTTPS pour le tableau de bord
Une fois l’assistant terminé, AdGuard Home déplace en général l’interface vers le port 80. Cela entre en conflit avec Caddy ou Nginx si vous hébergez aussi des sites. Un schéma propre : interface web AdGuard Home sur 127.0.0.1:8080, DNS sur 127.0.0.1:53, Caddy sur 443 pour le tableau de bord et le DoH.
# In AdGuard Home settings, bind the web UI to 127.0.0.1:8080
# Example Caddyfile:
dns.example.com {
reverse_proxy 127.0.0.1:8080
}
# After Caddy is up:
curl -I https://dns.example.comÉtape 4 : Activer DNS-over-HTTPS et DNS-over-TLS
Dans les paramètres de chiffrement, activez le chiffrement, réglez le nom de serveur sur dns.example.com, et pointez AdGuard Home vers vos fichiers de certificats — ceux que Caddy stocke, ou des certificats qu’AdGuard Home obtient lui-même s’il écoute sur 443. Le DoH est en général https://dns.example.com/dns-query. Le DoT est dns.example.com:853. Si Caddy possède déjà 443, laissez Caddy terminer le TLS et reverse-proxier le chemin DoH vers le port DoH HTTP en clair d’AdGuard Home, ou laissez AdGuard Home écouter sur 443 et placez le tableau de bord sur un autre sous-domaine.
Vérifiez avec un client avant de changer tous les appareils. Sur un ordinateur avec un curl moderne :
curl -H 'accept: application/dns-json' 'https://dns.example.com/dns-query?name=example.com&type=A'
# DoT test (kdig from knot-dnsutils, if installed):
# kdig @dns.example.com +tls-ca +tls-host=dns.example.com example.comÉtape 5 : Pointer de vrais appareils vers votre résolveur
Windows 11 et les versions récentes d’Android peuvent utiliser un modèle DoH. iOS peut utiliser un profil de configuration ou un client compatible DoH. Firefox et Chromium autorisent aussi une URL DoH personnalisée. Pour un routeur domestique, ne réglez le DNS WAN que si le routeur prend en charge DoT/DoH ; sinon faites tourner WireGuard et réglez le DNS sur l’IP VPN du VPS pour que le DNS classique ne traverse jamais Internet.
- Android 9+ : DNS privé (DoT) → dns.example.com
- Firefox : Paramètres → Réseau → DNS over HTTPS → URL personnalisée https://dns.example.com/dns-query
- Appareils Apple : un mobileconfig signé ou une application compatible DoH/DoT
- Autres VPS : régler resolv.conf ou systemd-resolved sur l’IP WireGuard de cette instance AdGuard
- Évitez de définir l’IP de ce VPS comme DNS sur des réseaux publics aléatoires sans chiffrement
Étape 6 : Pare-feu — fermer le DNS récursif ouvert
Cette section évite une mauvaise surprise. Autorisez SSH, HTTPS, et éventuellement 853/tcp pour le DoT. N’autorisez pas 53/udp depuis 0.0.0.0/0 sauf conception très spécifique, limitée en débit et authentifiée — et même dans ce cas, vous ne le devriez probablement pas.
ufw allow OpenSSH
ufw allow 443/tcp comment 'dashboard + DoH'
ufw allow 853/tcp comment 'DoT'
# If DNS is only on WireGuard (example iface wg0, 10.8.0.1):
# ufw allow in on wg0 to any port 53 proto udp
ufw enable
ufw status verbose
# Confirm 53 is not public:
ss -tulpn | grep ':53'Filtres, listes blanches et clients
Commencez par le filtre DNS par défaut d’AdGuard et une liste malveillante. Quand un site se comporte mal, consultez le journal des requêtes, puis ajoutez une règle de liste blanche précise plutôt que de tout débloquer. Utilisez des noms de clients (par IP ou par ClientID dans l’URL DoH) pour appliquer des listes plus strictes à une smart TV et plus souples à un ordinateur professionnel. N’activez la recherche sécurisée que si vous la voulez vraiment — elle surprend ceux qui n’ont pas demandé des résultats Google réécrits.
- Journal des requêtes : trouver le domaine bloqué, puis le mettre en liste blanche s’il s’agit d’un faux positif
- Paramètres client : listes de blocage différentes par appareil
- Clients interdits : bloquer des plages que vous ne possédez pas
- Limitation de débit : l’activer si vous exposez un jour plus qu’une poignée d’utilisateurs
Dépannage
Si le VPS lui-même ne peut plus faire apt update, vous avez cassé le DNS local en libérant le port 53 — mettez un résolveur statique dans resolved.conf comme indiqué plus haut. Si les appareils « ont Internet » mais que les publicités se chargent encore, ils contournent votre DNS (résolveurs en dur, DoH dans le navigateur, ou une application avec son propre DNS). Si le tableau de bord est vide, vous regardez la mauvaise instance ou vous frappez encore le port 3000 après que l’assistant a déplacé l’interface.
- apt échoue : vérifier /etc/resolv.conf et systemd-resolved
- Port 53 occupé : ss -tulpn, désactiver le listener stub
- Erreurs de certificat DoH : le nom d’hôte doit correspondre au SAN du certificat
- Publicités encore visibles : le DoH du navigateur vers un autre fournisseur remplace celui du système
- RAM élevée : journal des requêtes + trop de listes de filtres — réduire les listes et raccourcir la conservation des journaux
Liste de contrôle sécurité
L’interface web est un panneau d’administration. Mot de passe unique, HTTPS uniquement, et ne publiez pas l’URL. Gardez AdGuard Home à jour ; le script d’installation et l’interface exposent tous deux un chemin de mise à jour. Restreignez 443 si seuls vos appareils doivent utiliser le DoH — une authentification HTTP basic sur le chemin DoH ou un accès uniquement via WireGuard est bien plus sûr qu’un résolveur ouvert célèbre.
- Pas de 53/udp public
- HTTPS sur le tableau de bord
- Mot de passe administrateur fort, stocké dans un gestionnaire de mots de passe
- Préférer WireGuard + DNS interne pour les appareils familiaux
- Sauvegarder AdGuardHome.yaml hors du serveur
Conseils
- Sauvegardez /opt/AdGuardHome/AdGuardHome.yaml avant chaque mise à niveau
- Utilisez un sous-domaine dédié ; ne le partagez pas avec un CMS sans rapport
- Si Caddy tourne déjà, laissez Caddy posséder 443 et gardez AdGuard Home sur localhost
- Documentez l’URL DoH pour vos appareils — vous l’oublierez
- Associez aux guides de durcissement SSH et de pare-feu pour que le VPS ne soit pas seulement « sûr côté DNS »
AdGuard Home sur un VPS est simple : libérer le port 53 en local, lancer l’installeur, terminer l’assistant avec un mot de passe administrateur fort, placer l’interface en HTTPS, activer DoH/DoT, et garder le DNS classique hors d’Internet public. Pointez les appareils vers votre extrémité chiffrée ou vers une IP VPN, commencez avec un petit jeu de filtres, et utilisez le journal des requêtes quand quelque chose casse. C’est un résolveur privé que vous contrôlez vraiment — pas un DNS ouvert public qui fera lister votre VPS dans les bases d’abus.