AdGuard Home cu Docker Compose: DNS criptat si fara reclame

Aproape orice face telefonul tau online incepe cu o interogare DNS: “unde e site-ul asta?”, “unde e serverul asta de reclame?”, “unde e tracker-ul asta?”. Cine raspunde la intrebarile astea vede o lista foarte sincera cu ce faci toata ziua, iar pe date mobile, pe Wi-Fi-ul hotelului sau la cafenea, acela e cineva pe care nu l-ai ales niciodata. In tutorialul asta luam inapoi controlul. Instalam AdGuard Home cu Docker Compose pe un VPS, ii dam un certificat TLS real si activam DNS-over-HTTPS si DNS-over-TLS, ca telefonul si laptopul tau sa primeasca DNS privat, fara reclame si fara trackere, de oriunde din lume, fara nicio aplicatie instalata pe ele.

Explicam fiecare pas, inclusiv partile pe care multe ghiduri le sar: de ce nu trebuie sa expui niciodata portul 53 in clar catre internet, de ce Docker ignora firewall-ul tau si cum te asiguri ca doar dispozitivele tale pot folosi serverul.

Ce este AdGuard Home si ce legatura are DNS-ul cu reclamele

DNS (Domain Name System) este cartea de telefon a internetului. Cand o aplicatie vrea sa vorbeasca cu ads.example-tracker.com, intreaba mai intai un resolver DNS care e adresa IP a acelui nume. In mod normal, resolverul apartine operatorului mobil sau furnizorului de internet de acasa.

AdGuard Home este un server DNS open source scris in Go, publicat de echipa AdGuard pe github.com/AdguardTeam/AdGuardHome , sub licenta GPL-3.0. Se aseaza intre dispozitivele tale si restul DNS-ului din internet. La fiecare interogare verifica un set de liste de blocare: daca numele apartine unei retele de reclame sau de tracking, raspunde cu 0.0.0.0 (o fundatura) si reclama pur si simplu nu se mai incarca. Tot restul e trimis catre un resolver upstream si pus in cache. Il administrezi dintr-un dashboard web curat, cu statistici, jurnal de interogari, setari per dispozitiv si filtre parentale.

Pentru ca blocarea se face la nivel de DNS, functioneaza in toate aplicatiile de pe dispozitiv, nu doar in browser. Compromisul: nu poate elimina reclamele servite de pe acelasi domeniu ca si continutul (reclamele video de pe YouTube sunt exemplul clasic).

De ce conteaza DNS-ul criptat

DNS-ul clasic circula in clar pe portul 53 (un port e doar o “usa” numerotata a unui server, ca o singura masina sa poata oferi mai multe servicii). Oricine se afla pe traseu il poate citi si chiar modifica raspunsurile. Trei protocoale mai noi impacheteaza DNS-ul in criptare TLS, aceeasi tehnologie din spatele lacatului din browser:

• DNS-over-TLS (DoT): DNS intr-o conexiune TLS pe portul 853/tcp. Asta foloseste setarea “DNS privat” din Android.
• DNS-over-HTTPS (DoH): DNS in interiorul unui HTTPS obisnuit, pe portul 443/tcp. Arata ca trafic web normal, deci e greu de blocat. Il suporta browserele, Windows 11 si dispozitivele Apple.
• DNS-over-QUIC (DoQ): DNS peste protocolul QUIC pe portul 853/udp. Rapid pe retele mobile instabile, dar suportat de mai putini clienti.

AdGuard Home le vorbeste pe toate trei, dar doar daca ii dai un certificat valid pentru un hostname pe care il detii. Asta e miezul tutorialului.

De ce pe un VPS si nu pe un Raspberry Pi acasa

Un dispozitiv de acasa te protejeaza doar in reteaua de acasa. Un VPS are IP public fix, sta intr-un data center cu alimentare si conectivitate redundante si e accesibil de oriunde, deci telefonul ramane protejat pe 4G, 5G si pe orice Wi-Fi. AdGuard Home e usor: ruleaza confortabil langa alte servicii mici pe un VPS de intrare.

De ce ai nevoie

• Un VPS proaspat cu Debian 13 sau Ubuntu 24.04, 1 vCPU si 1 GB RAM sunt mai mult decat suficiente. Un VPS KVM e cea mai simpla alegere. Intr-un container LXC neprivilegiat, Docker merge doar daca nesting-ul (si de obicei keyctl) e activat pentru container; daca docker run hello-world esueaza acolo, cere suportului sa-l activeze sau alege KVM.
• Un utilizator cu sudo si acces SSH (folosim utilizator si IP-ul 203.0.113.10 ca exemple).
• Un domeniu in care poti crea inregistrari DNS. Folosim dns.example.com; inlocuieste-l peste tot cu al tau.
• O adresa de email pentru notificarile Let’s Encrypt.
• Cam 45 de minute.

Cum se leaga piesele intre ele

Inainte sa scriem ceva, sa ne uitam la arhitectura. Un container este un pachet izolat care contine aplicatia plus tot ce ii trebuie ca sa ruleze, folosind kernelul gazdei, dar nu si fisierele ei. Docker Compose ne lasa sa descriem containerul (imagine, porturi, stocare) intr-un singur fisier YAML mic, deci totul e reproductibil. Un volum sau un bind mount este un folder de pe VPS pe care containerul il vede ca disc propriu, ca configuratia sa supravietuiasca actualizarilor.

Un detaliu prinde multa lume pe picior gresit: cand Docker publica un port (sectiunea ports: din Compose), scrie propriile reguli de firewall, evaluate inaintea celor din ufw. Deci ufw deny 53 nu ar proteja un port pe care Docker il publica pe toate interfetele. De aceea decidem expunerea chiar in fisierul Compose: porturile criptate (443 si 853) sunt publice intentionat, iar DNS-ul in clar (53) si wizard-ul de administrare (3000) sunt legate de 127.0.0.1, accesibile doar de pe VPS. ufw conteaza in continuare, dar doar pentru serviciile care ruleaza direct pe gazda: SSH si portul 80 pentru certbot.

Planul: AdGuard Home cu Docker Compose in opt pasi

Procedura are opt pasi. Pasii 1 la 4 pregatesc serverul, pasii 5 la 8 configureaza AdGuard Home si dispozitivele. Fiecare pas de mai jos are un titlu cu acelasi numar ca in diagrama.

Pasul 1: Indreapta un hostname catre VPS

DNS-ul criptat are nevoie de un nume, pentru ca certificatele TLS se emit pentru nume, nu pentru IP-uri. In panoul DNS al domeniului tau, creeaza inregistrarile de mai jos (inlocuieste IP-ul cu adresa VPS-ului tau):

Prima inregistrare e hostname-ul principal. Inregistrarea wildcard (*) face ca nume precum phone.dns.example.com si laptop.dns.example.com sa duca la acelasi server. Vom folosi aceste nume per dispozitiv in pasul 7, ca sa identificam fiecare dispozitiv. O inregistrare DNS wildcard nu costa nimic si nu cere, prin ea insasi, un certificat special.

Asteapta cateva minute, apoi verifica de pe orice calculator:

nslookup dns.example.com
nslookup phone.dns.example.com

Ambele trebuie sa intoarca IP-ul VPS-ului. Daca nu, asteapta propagarea inainte sa mergi mai departe, altfel pasul 3 va esua.

Pasul 2: Instaleaza Docker si configureaza firewall-ul

Mai intai, actualizeaza sistemul:

sudo apt update && sudo apt full-upgrade -y

Pe Ubuntu, daca actualizarea cere un restart, apare fisierul /var/run/reboot-required; il verifici cu [ -f /var/run/reboot-required ] && echo "Restart necesar". Debian nu creeaza intotdeauna acest fisier, asa ca fa pur si simplu restart daca s-a instalat un pachet linux-image nou. Restart cu sudo reboot, apoi te reconectezi.

Acum instalam Docker din repository-ul oficial Docker. Blocul de mai jos merge pe ambele distributii: citeste /etc/os-release ca sa aleaga debian sau ubuntu si numele de cod corect (trixie sau noble) si scrie repository-ul in formatul deb822 actual:

sudo apt install -y ca-certificates curl
. /etc/os-release
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL "https://download.docker.com/linux/${ID}/gpg" -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/${ID}
Suites: ${VERSION_CODENAME}
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Verifica daca functioneaza:

sudo docker run --rm hello-world
docker compose version

Trebuie sa vezi “Hello from Docker!” si o versiune Compose care incepe cu v2 sau mai noua. Daca hello-world esueaza intr-un container LXC neprivilegiat, nesting-ul nu e activat (vezi “De ce ai nevoie”).

Apoi instalam uneltele de care avem nevoie mai tarziu: firewall-ul, certbot (clientul Let’s Encrypt) si doua unelte de test DNS (dig si kdig):

sudo apt install -y ufw certbot bind9-dnsutils knot-dnsutils

Pe Ubuntu, ufw e de obicei deja instalat; pe Debian nu, comanda acopera ambele cazuri. Acum il configuram doar pentru serviciile gazdei:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw enable
sudo ufw status verbose

Portul 22 iti pastreaza sesiunea SSH (schimba-l daca SSH-ul tau ruleaza pe alt port si permite-l mereu inainte de ufw enable). Portul 80 e pentru validarea certificatului de catre certbot. Intentionat nu adaugam 443 sau 853 aici: Docker le deschide singur cand le publica, iar ufw oricum nu le-ar putea inchide.

Pasul 3: Obtine un certificat TLS pentru hostname-ul DNS

Folosim certbot in modul standalone: pentru cateva secunde porneste propriul server web minuscul pe portul 80, Let’s Encrypt se conecteaza la el ca sa verifice ca tu controlezi numele (“provocarea HTTP-01”) si certificatul e emis. Nimic altceva nu asculta pe portul 80, deci nu exista conflict.

Include numele principal plus cate un nume pentru fiecare dispozitiv care va folosi DNS-over-TLS (DNS privat pe Android, Linux). Dispozitivele care folosesc DoH nu au nevoie de nume propriu:

sudo certbot certonly --standalone \
  -d dns.example.com \
  -d phone.dns.example.com \
  -d laptop.dns.example.com \
  -m tu@example.com --agree-tos --no-eff-email

Rezultatul asteptat se termina cu ceva de genul:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/dns.example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/dns.example.com/privkey.pem

Certificatele Let’s Encrypt sunt valabile 90 de zile. Pachetul certbot, atat pe Debian cat si pe Ubuntu, instaleaza un timer systemd care le reinnoieste automat. Verifica-l si fa o rulare de test:

systemctl list-timers | grep certbot
sudo certbot renew --dry-run

AdGuard Home trebuie sa reincarce certificatul nou dupa reinnoire, asa ca adaugam un deploy hook, un script pe care certbot il ruleaza doar cand un certificat chiar a fost reinnoit:

sudo tee /etc/letsencrypt/renewal-hooks/deploy/restart-adguardhome.sh > /dev/null <<'EOF'
#!/bin/sh
/usr/bin/docker restart adguardhome
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/restart-adguardhome.sh

Containerul adguardhome nu exista inca; nu e nicio problema, hook-ul va rula abia la prima reinnoire reala, peste cateva saptamani.

Daca adaugi mai tarziu un dispozitiv DoT, extinzi certificatul cu toate numele vechi plus cel nou: sudo certbot certonly --standalone --expand -d dns.example.com -d phone.dns.example.com -d laptop.dns.example.com -d tablet.dns.example.com. Daca preferi un certificat wildcard (*.dns.example.com), ai nevoie de provocarea DNS-01 si de un plugin certbot pentru furnizorul tau DNS; functioneaza, dar iese din scopul acestui tutorial.

Pasul 4: Scrie fisierul AdGuard Home docker compose

Creeaza un folder pentru proiect si deschide fisierul Compose:

sudo mkdir -p /opt/adguardhome
cd /opt/adguardhome
sudo nano compose.yaml

Lipeste continutul de mai jos (Docker Compose accepta si numele mai vechi docker-compose.yml, dar compose.yaml e numele implicit actual):

services:
  adguardhome:
    image: adguard/adguardhome:latest
    container_name: adguardhome
    restart: unless-stopped
    ports:
      # DNS in clar si interfata de administrare: doar de pe VPS
      - "127.0.0.1:53:53/tcp"
      - "127.0.0.1:53:53/udp"
      - "127.0.0.1:3000:3000/tcp"
      # DNS criptat: accesibil din internet
      - "443:443/tcp"   # DNS-over-HTTPS
      - "853:853/tcp"   # DNS-over-TLS
      - "853:853/udp"   # DNS-over-QUIC
    volumes:
      - ./work:/opt/adguardhome/work
      - ./conf:/opt/adguardhome/conf
      - /etc/letsencrypt:/etc/letsencrypt:ro

Salveaza cu Ctrl+O, Enter si iesi cu Ctrl+X. Ce face fiecare parte:

• image: imaginea oficiala. Tag-ul latest urmeaza mereu cea mai noua versiune stabila, ceea ce e comod pentru un serviciu sensibil la securitate, dar o actualizare poate schimba comportamentul. Daca preferi actualizari controlate, uita-te pe pagina de release-uri AdGuard Home si fixeaza tag-ul exact de acolo (arata ca vX.Y.Z). In ambele cazuri, verifica pagina din cand in cand pentru cea mai noua versiune.
• restart: unless-stopped: containerul porneste din nou dupa un crash sau dupa restartul VPS-ului.
• ports: formatul e adresa_gazda:port_gazda:port_container. Prefixul 127.0.0.1 tine portul 53 si portul de administrare departe de internet. Liniile fara prefix asculta pe toate adresele publice.
• volumes: conf contine fisierul de configurare AdGuardHome.yaml, work contine jurnalul de interogari, statisticile si listele descarcate. /etc/letsencrypt e montat doar pentru citire (:ro), ca AdGuard Home sa poata citi certificatul, dar sa nu-l poata modifica. Montam tot folderul pentru ca fisierele din live sunt link-uri simbolice catre archive.

Pasul 5: Porneste containerul si ruleaza wizard-ul de instalare

Porneste AdGuard Home in fundal (-d inseamna detached) si verifica starea:

cd /opt/adguardhome
sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs --tail 20

ps trebuie sa arate containerul ca running (sau Up), iar log-urile trebuie sa mentioneze ca interfata web de instalare e disponibila pe portul 3000. Daca vezi address already in use pentru portul 53, sari la sectiunea de depanare.

Portul 3000 e legat de 127.0.0.1, asa ca ajungem la el printr-un tunel SSH: o conducta criptata care trimite un port de pe calculatorul tau catre un port de pe VPS. Ruleaza comanda asta pe calculatorul tau (nu pe VPS) si lasa fereastra deschisa:

ssh -N -L 3000:127.0.0.1:3000 utilizator@203.0.113.10

Acum deschide http://localhost:3000 in browser. Wizard-ul pune cateva intrebari:

1. Admin Web Interface: interfata “All interfaces”, portul 3000. Important: wizard-ul propune portul 80, dar fisierul nostru Compose mapeaza 3000, deci schimba-l in 3000. “All interfaces” inseamna aici in interiorul containerului; Docker il limiteaza oricum la 127.0.0.1 pe gazda.
2. DNS server: “All interfaces”, portul 53.
3. Autentificare: alege un nume de administrator si o parola lunga si unica. In pasul 6 vei vedea de ce conteaza.
4. Ignora orice sugestie despre configurarea unui IP static: in Docker nu se aplica.

Dupa ce wizard-ul se termina, autentifica-te pe http://localhost:3000. Inapoi pe VPS, testeaza DNS-ul in clar local:

dig @127.0.0.1 example.com +short
dig @127.0.0.1 doubleclick.net +short

Prima comanda intoarce o adresa IP reala. A doua ar trebui sa intoarca 0.0.0.0: lista inclusa “AdGuard DNS filter”, activa implicit, tocmai a blocat o retea de reclame. Serverul tau de filtrare functioneaza.

Pasul 6: Activeaza DNS-over-HTTPS si DNS-over-TLS

In dashboard mergi la Settings > Encryption settings si completeaza:

• Enable Encryption: bifat.
• Server name: dns.example.com. Trebuie completat; AdGuard Home il foloseste ca sa recunoasca nume de dispozitive precum phone.dns.example.com in pasul 7.
• Redirect to HTTPS automatically: lasa-l nebifat, ca tunelul SSH spre portul 3000 sa mearga in continuare.
• HTTPS port: 443. DNS-over-TLS port: 853. DNS-over-QUIC port: 853.
• Certificates: alege “Set a certificates file path” si scrie /etc/letsencrypt/live/dns.example.com/fullchain.pem.
• Private key: alege “Set a private key file” si scrie /etc/letsencrypt/live/dns.example.com/privkey.pem.

AdGuard Home valideaza fisierele imediat si ar trebui sa afiseze un mesaj ca lantul de certificate e valid, cu numele tale si data expirarii. Apasa Save configuration. Caile sunt cele din interiorul containerului, identice cu cele de pe gazda datorita volumului montat.

Bine de stiut: AdGuard Home serveste DoH si dashboard-ul web de pe acelasi server HTTPS, deci de acum pagina de login e accesibila si la https://dns.example.com. De aceea conteaza parola puternica din pasul 5. Daca ai nevoie doar de DoT (de exemplu doar telefoane Android), poti scoate linia 443:443/tcp din compose.yaml si rula din nou sudo docker compose up -d; dashboard-ul ramane atunci accesibil doar prin tunel.

Acum testeaza de pe VPS sau de pe orice masina Linux cu curl si kdig. Intai DNS-over-HTTPS: ii cerem lui curl sa rezolve example.com prin serverul tau DoH si sa afiseze codul HTTP:

curl -sS --doh-url https://dns.example.com/dns-query https://example.com -o /dev/null -w "%{http_code}\n"

Rezultat asteptat: 200. Apoi DNS-over-TLS:

kdig @dns.example.com +tls-ca +tls-hostname=dns.example.com example.com

Rezultatul incepe cu o linie ;; TLS session (TLS1.3) si contine o sectiune ANSWER SECTION. +tls-ca face ca kdig sa verifice certificatul fata de autoritatile de incredere ale sistemului, deci un succes aici dovedeste si ca certificatul e corect.

Pasul 7: Securizeaza serverul cu ClientID-uri

In acest moment, oricine descopera dns.example.com ar putea folosi serverul tau. Asta iti consuma resursele si iti umple jurnalele cu straini. AdGuard Home rezolva problema cu ClientID-uri: identificatori scurti pe care fiecare dispozitiv ii include in conexiune. La DoH, ClientID-ul se pune la finalul URL-ului (/dns-query/laptop), la DoT si DoQ e prima eticheta din hostname (phone.dns.example.com). Un ClientID poate contine litere mici, cifre si cratime.

1. Mergi la Settings > Client settings > Add client. Nume: Telefon, identificator: phone. Salveaza. Repeta pentru laptop, iphone si asa mai departe.
2. Mergi la Settings > DNS settings > Access settings. In Allowed clients, scrie cate un ClientID pe linie:

phone
laptop
iphone

3. Apasa Save.

De acum, orice interogare care nu poarta un ClientID permis e refuzata. Asta include si testele dig @127.0.0.1 de mai devreme, care ajung la container de la adresa bridge-ului Docker. Daca vrei in continuare sa testezi de pe VPS, cauta in Query log IP-ul de la care au venit acele teste (de obicei ceva de genul 172.18.0.1) si adauga-l si pe el in Allowed clients.

Testeaza cu ClientID-uri:

curl -sS --doh-url https://dns.example.com/dns-query/laptop https://example.com -o /dev/null -w "%{http_code}\n"
kdig @phone.dns.example.com +tls-ca +tls-hostname=phone.dns.example.com +tls-sni=phone.dns.example.com example.com

Ambele trebuie sa reuseasca, iar Query log ar trebui sa arate acum cererile sub “Laptop” si “Telefon”. Aceeasi comanda curl fara /laptop trebuie sa esueze cu “Could not resolve host”, ceea ce dovedeste ca restrictia functioneaza.

Pasul 8: Conecteaza dispozitivele

Android 9 sau mai nou (DoT): Setari > Retea si internet > DNS privat > “Nume de gazda al furnizorului DNS privat” si scrie phone.dns.example.com. Android verifica certificatul, de aceea numele trebuia inclus in pasul 3.

iPhone, iPad si Mac (DoH): dispozitivele Apple folosesc un profil de configurare. In dashboard-ul AdGuard Home deschide Setup guide > DNS Privacy, alege sectiunea iOS, completeaza ClientID-ul (de exemplu iphone) si descarca fisierul .mobileconfig. Deschide-l pe dispozitiv si instaleaza-l din Configurari > General > VPN si gestionare dispozitiv.

Windows 11 (DoH): Setari > Retea si internet > adaptorul tau > Atribuire server DNS > Editare > Manual. Activeaza IPv4, pune 203.0.113.10 ca DNS preferat, seteaza “DNS over HTTPS” pe “Activat (sablon manual)”, sablonul https://dns.example.com/dns-query/laptop si dezactiveaza revenirea la text simplu.

Doar browserul: Firefox (Setari > Confidentialitate si securitate > DNS over HTTPS > Protectie maxima > Personalizat) si Chrome (Setari > Confidentialitate si securitate > Securitate > Foloseste DNS securizat > furnizor personalizat) accepta https://dns.example.com/dns-query/laptop.

Linux cu systemd-resolved (DoT): creeaza /etc/systemd/resolved.conf.d/adguard.conf:

[Resolve]
DNS=203.0.113.10#laptop.dns.example.com
DNSOverTLS=yes
Domains=~.

Apoi ruleaza sudo systemctl restart systemd-resolved. Partea de dupa # e numele trimis in TLS si poarta ClientID-ul tau.

Deschide cateva site-uri pe fiecare dispozitiv si urmareste-le cum apar in Query log, cu cererile blocate marcate cu rosu.

Alegerea listelor de blocare si a resolverelor upstream

La Settings > DNS settings > Upstream DNS servers, foloseste upstream-uri criptate, ca si drumul de la VPS mai departe sa fie privat:

https://dns.quad9.net/dns-query
https://cloudflare-dns.com/dns-query

Alege “Load-balancing” sau “Parallel requests”, pune 9.9.9.9 si 1.1.1.1 la Bootstrap DNS servers (folosite doar ca sa rezolve numele upstream-urilor), activeaza DNSSEC si apasa Test upstreams.

La Filters > DNS blocklists > Add blocklist > Choose from the list poti adauga mai multe liste din catalogul inclus. Mai multe reguli blocheaza mai mult, dar costa memorie si cresc sansa sa strici un site. Graficul arata valori tipice.

Pentru cateva dispozitive personale, lista implicita plus una sau doua liste suplimentare bine intretinute sunt echilibrul ideal. Chiar si configuratia cea mai mare incape lejer pe un VPS cu 1 GB RAM.

Actualizari si backup

Butonul de “update” din AdGuard Home nu se aplica in Docker; actualizezi descarcand o imagine mai noua:

cd /opt/adguardhome
sudo docker compose pull
sudo docker compose up -d
sudo docker image prune -f

Configuratia sta in conf/AdGuardHome.yaml. Fa-i backup impreuna cu fisierul Compose:

cd /opt
sudo tar czf ~/adguardhome-backup-$(date +%F).tar.gz adguardhome/compose.yaml adguardhome/conf
sudo chown "$USER": ~/adguardhome-backup-*.tar.gz

Pentru ca tar a rulat cu sudo, arhiva apartinea lui root; chown ti-o da inapoi ca s-o poti copia de pe server, de exemplu cu scp utilizator@203.0.113.10:adguardhome-backup-*.tar.gz . rulat pe calculatorul tau. Adauga si adguardhome/work daca vrei sa pastrezi statisticile si jurnalul de interogari.

Depanare si greseli frecvente

• address already in use pe portul 53: alt program asculta deja pe 127.0.0.1:53. Il gasesti cu sudo ss -lntup | grep ':53 '. Pe Ubuntu, systemd-resolved asculta pe 127.0.0.53 si 127.0.0.54, care nu se ciocnesc cu legarea noastra pe 127.0.0.1; conflictul apare doar daca schimbi maparea in 53:53 pe toate interfetele, ceea ce oricum nu trebuie sa faci. Pe Debian, suspectul obisnuit e un dnsmasq sau bind9 ramas instalat.
• Portul 443 e deja ocupat: un server web (nginx, Apache, Caddy) il foloseste deja. Fie rulezi AdGuard Home pe un VPS separat, fie renunti la DoH si pastrezi doar DoT si DoQ pe 853.
• Dashboard-ul a disparut dupa wizard: ai pastrat portul 80 in wizard. Editeaza conf/AdGuardHome.yaml, pune address de sub http: pe 0.0.0.0:3000, apoi sudo docker compose restart.
• certbot esueaza cu timeout: portul 80 nu e permis in ufw sau inregistrarile DNS din pasul 1 nu s-au propagat inca.
• “Certificate file not found” in Encryption settings: ai folosit o cale de pe gazda care nu exista in container sau ai uitat volumul /etc/letsencrypt. Recreeaza containerul cu sudo docker compose up -d dupa ce corectezi compose.yaml.
• Android spune “Nu s-a putut conecta”: numele dispozitivului (de exemplu phone.dns.example.com) lipseste din certificat, ClientID-ul nu e in Allowed clients sau reteaua blocheaza portul 853 (unele hoteluri si retele de firma fac asta). Pentru astfel de retele, DoH pe 443 e varianta de rezerva.
• Totul e refuzat dupa pasul 7: dispozitivul nu trimite ClientID sau identificatorul a fost scris diferit in Client settings fata de Allowed clients.
• Docker nu porneste pe un VPS LXC: containerul nu are nesting activ; cere suportului sa-l activeze sau foloseste un VPS KVM.

Note de securitate

• Nu publica niciodata portul 53 in clar catre internet. Un resolver deschis e folosit in cateva ore pentru atacuri de amplificare DNS, iar tu ai primi plangeri de abuz. Fisierul nostru Compose il leaga de 127.0.0.1 exact din acest motiv.
• Tine minte ca Docker ocoleste ufw. Tot ce pui in ports: fara 127.0.0.1 e public, indiferent ce spune ufw. Reverifica sectiunea dupa fiecare modificare.
• Protejeaza dashboard-ul. Cu DoH activ, pagina de login e publica pe 443. Foloseste o parola lunga si unica; AdGuard Home blocheaza temporar un IP dupa mai multe autentificari esuate. Scoate maparea 443 daca nu ai nevoie de DoH.
• Pastreaza lista de clienti permisi stricta. In Allowed clients trebuie sa stea doar ClientID-urile pe care chiar le folosesti. Sterge ID-ul unui dispozitiv cand il vinzi sau il pierzi.
• Limiteaza ce se logheaza. Jurnalul de interogari e o inregistrare detaliata a navigarii tale. La Settings > General settings, scurteaza retentia jurnalului si a statisticilor (de exemplu 24 de ore) sau activeaza anonimizarea IP-urilor clientilor.
• Actualizeaza regulat. Descarca imaginea cel putin lunar si tine gazda la zi cu apt.
• Trateaza backup-urile ca date sensibile. AdGuardHome.yaml contine hash-ul parolei de administrator si lista de clienti.

Deci, merita propriul DNS criptat?

Daca vrei ca toate aplicatiile de pe telefon sa nu mai vorbeasca cu retelele de reclame si tracking, pe orice retea te conectezi, fara sa instalezi nimic pe dispozitiv, atunci da. Cu AdGuard Home in Docker Compose, un certificat real si ClientID-uri, ai DNS privat pe care doar dispozitivele tale il pot folosi, care consuma cateva zeci de MB de RAM si aproape nu mai cere intretinere dupa prima zi.

Poti rula aceasta configuratie pe un VPS din data center-ul nostru din Romania in mai putin de o ora, sau poti lasa echipa noastra de administrare servere sa o instaleze, sa o securizeze si sa o tina la zi pentru tine.

Intrebari frecvente

Incetineste AdGuard Home navigarea?

De obicei, dimpotriva. Raspunsurile din cache vin in una sau doua milisecunde, iar reclamele blocate nici nu se mai incarca. Prima interogare pentru un nume nou adauga drumul pana la VPS, de regula cateva zeci de milisecunde in Europa.

Poate routerul de acasa sa foloseasca acest server?

Doar daca routerul suporta DoT sau DoH ca upstream. Sa indrepti un router catre portul 53 in clar al VPS-ului ar cere expunerea portului 53 in internet, lucru pe care il descurajam ferm.

Blocheaza reclamele de pe YouTube sau Facebook?

Nu. Acele reclame vin de pe aceleasi domenii ca si continutul, iar blocarea DNS nu le poate separa fara sa strice site-ul. In schimb, blocheaza majoritatea retelelor de reclame si a trackerelor terte din aplicatii si de pe site-uri.

Cat trafic consuma?

Foarte putin. Un utilizator activ genereaza cateva mii de interogari pe zi, adica cativa MB pe luna, mult sub orice limita de trafic a unui VPS.

Am nevoie de un certificat nou pentru fiecare dispozitiv?

Doar pentru dispozitivele care folosesc DoT sau DoQ, pentru ca ClientID-ul lor calatoreste in hostname. Dispozitivele DoH pun ClientID-ul in calea URL-ului si merg cu certificatul principal.