AdGuard Home DNS-suodatus: 13 Vaihetta, 60 Min [2026]

Joka kerta kun puhelin tai läppäri hakee verkko-osoitteen, se lähettää DNS-kyselyn ulos kotiverkosta. Operaattorin tai julkisen resolverin näkökulmasta tämä kysely paljastaa, mitä sivustoja käytät, milloin ja kuinka usein. AdGuard Home ratkaisee tämän ajamalla DNS-suodatuksen omalla laitteella ja salaamalla liikenteen ylävirran palvelimille asti. Tässä oppaassa asennetaan AdGuard Home versio 0.107.79 (GitHub-julkaisu 30.9.2026) Dockerilla, otetaan käyttöön salattu DNS-over-HTTPS- ja DNS-over-TLS-yhteys ja ohjataan koko kotiverkko käyttämään sitä. Koko prosessi vie noin 60 minuuttia ja etenee 13 vaiheessa.

Oppaassa käydään läpi myös yleisimmät sudenkuopat, kymmenen vianmääritystapausta ja täydellinen esimerkkiprojekti, jolla koko kotiverkko saadaan suojattua alusta loppuun. Lopussa on vertailu AdGuard Homen, Pi-holen, NextDNS:n ja Quad9:n välillä, jotta valinta oman verkon tarpeisiin on helpompi tehdä.

Opas sopii niin kokeneelle kotiverkon rakentajalle kuin ensikertalaiselle. Komennot toimivat sellaisenaan Debian- ja Ubuntu-pohjaisilla järjestelmillä, ja Raspberry Pi -käyttäjät löytävät erillisiä huomioita SD-korttien kulumisesta ja muistin riittävyydestä. Jos käytössä on ennestään Pi-hole tai NextDNS, oppaan lopun vertailutaulukko auttaa päättämään, kannattaako siirtyä AdGuard Homeen vai pitää nykyinen ratkaisu. Kaikki esimerkit, komennot ja porttinumerot perustuvat AdGuard Homen viralliseen dokumentaatioon ja GitHub-julkaisulistaan, ei kolmannen osapuolen arvailuihin.

Salattu DNS ei ole enää kapean harrastajaryhmän erikoisuus. Selainvalmistajat ja käyttöjärjestelmät ovat lisänneet DoH- ja DoT-tukea oletusasetuksiin viime vuosina, ja moni kotikäyttäjä käyttää salattua DNS:ää jo tietämättään, kun selain valitsee sen automaattisesti. Ongelma on, että tällöin valinta ylävirran resolverista tehdään selaimen tai käyttöjärjestelmän puolesta, ei käyttäjän. Oma AdGuard Home -asennus palauttaa tämän valinnan käyttäjälle: resolveri, lokien säilytysaika ja suodatussäännöt päätetään kotiverkon tasolla, ei sovelluskohtaisesti joka laitteessa erikseen.

Miksi DNS-suodatus kannattaa ottaa omiin käsiin 2026

Tavallinen kotireititin ohjaa DNS-kyselyt suoraan operaattorin resolveriin tai johonkin julkiseen palveluun kuten Google DNS:ään. Kysely kulkee usein salaamattomana, jolloin kuka tahansa samassa verkkopolussa voi lukea, mitä verkkotunnuksia laite kysyy. Salattu DNS (DoH, DoT tai uudempi DoQ) estää tämän välimatkalla, mutta ei poista sitä, että valittu resolveri näkee kyselyt. Oman AdGuard Home -palvelimen etu on, että suodatus ja lokit pysyvät omalla laitteella, ja ylävirran yhteys resolveriin salataan erikseen.

AdGuard Home on ilmainen, avoimen lähdekoodin DNS-palvelin ja mainosesto, joka toimii Linuxilla, macOS:llä, Windowsilla ja Raspberry Pi -laitteilla. Suomessa hakutermi “adguard” kerää DataForSEO:n lokakuun 2026 datan mukaan noin 1 300 hakua kuukaudessa ja “adguard dns” noin 480 hakua, molemmat matalan kilpailun avainsanoja. Kiinnostus on kasvussa, kun yhä useampi kotikäyttäjä ja pieni toimisto haluaa hallita omaa DNS-liikennettään sen sijaan, että luottaa oletusasetuksiin.

Syy kiinnostuksen kasvuun on yksinkertainen: julkiset DNS-palvelut ja operaattorien omat resolverit ovat ulkopuolisia toimijoita, joiden lokitus- ja säilytyskäytäntöjä käyttäjä ei voi itse valvoa. Kun DNS-palvelin pyörii omalla laitteella, kysely­historia ei poistu talosta ollenkaan, ellei sitä itse lähetä eteenpäin. Tämä ei tee verkosta täysin anonyymiä, mutta se siirtää valvonnan käyttäjälle itselleen sen sijaan, että se olisi kolmannella osapuolella. Samalla DNS-pohjainen suodatus estää mainos- ja seurantaverkkojen kyselyt jo ennen kuin selain tai sovellus ehtii latata sisältöä niistä, mikä nopeuttaa sivujen latautumista ja vähentää datan kulutusta mobiiliverkossa.

Mikä AdGuard Home on ja miten se eroaa Pi-holesta

AdGuard Home toimii DNS-proxyna: se vastaanottaa kyselyt kotiverkon laitteilta, suodattaa niitä estolistojen ja sääntöjen perusteella ja lähettää sallitut kyselyt eteenpäin valitulle ylävirran resolverille. Tekninen ero moniin kilpaileviin ratkaisuihin on se, että salattu ylävirran yhteys on rakennettu suoraan ohjelmistoon, ei vaadi erillistä apuohjelmaa.

Käytännössä AdGuard Home koostuu kolmesta osasta: DNS-palvelimesta, joka vastaa kyselyihin, hallintapaneelista, joka pyörii web-selaimessa, ja suodatusmoduulista, joka vertaa joka kyselyä estolistoihin ja omiin sääntöihin. Kaikki kolme osaa ovat samassa binäärissä tai samassa Docker-kontissa, joten ylläpidettävää on vain yksi prosessi. AdGuardin oma tuotesivu kuvaa ohjelmiston toimivan Linuxin, macOS:n, Windowsin ja Raspberry Pi:n lisäksi myös useilla reitittimien laiteohjelmistoilla, kuten OpenWrt:llä.

Projekti on avoimen lähdekoodin, ja koko lähdekoodi sekä julkaisuhistoria ovat seurattavissa suoraan GitHubin julkaisusivulta. Tämä tekee version todentamisesta helppoa: kuka tahansa voi tarkistaa, mikä muutos tuli mihin julkaisuun, ja mahdolliset tietoturvakorjaukset näkyvät julkaisutiedoissa ilman, että niitä pitää etsiä erillisistä tiedotteista.

Sisäänrakennettu DoH, DoT ja DoQ

AdGuard Homen asetuksissa ylävirran osoite kirjoitetaan suoraan URI-muodossa: https://osoite/dns-query DNS-over-HTTPS-yhteydelle, tls://osoite DNS-over-TLS-yhteydelle ja quic://osoite uudemmalle DNS-over-QUIC-yhteydelle. Ohjelmisto hoitaa salauksen itse, eikä käyttäjän tarvitse pystyttää erillistä cloudflared-tyyppistä aputunnelia. Tämä on ollut osa AdGuard Homen virallista konfiguraatiota useiden vuosien ajan, ja sama tuki kattaa myös DNS-over-QUIC-protokollan, joka määritellään IETF:n RFC 9250 -standardissa.

Asennusmallit: natiivi binääri vai Docker

Pi-hole yleensä tarvitsee erillisen taustaresolverin, kuten Unboundin, tai valmiin DoH-tunnelin saadakseen salatun ylävirran yhteyden. AdGuard Home ei tarvitse tätä väliohjelmaa, koska salaus on sisäänrakennettu. Tämä ei tarkoita, että Pi-hole olisi heikompi tuote, mutta asennuspolku on erilainen: AdGuard Homessa salatun DNS:n käyttöönotto on yksi asetuskenttä, Pi-holessa se vaatii yleensä toisen palvelun asentamisen rinnalle. Molemmat voi asentaa natiivisti palvelinta hallinnoivalla skriptillä tai Dockerilla, tässä oppaassa käytetään Dockeria, koska se pitää ympäristön siistinä ja päivitykset helppoina.

Natiiviasennus sopii tilanteisiin, joissa käytössä on jo kevyt Linux-pohjainen laite eikä halua lisätä Dockerin kerrosta päälle. Docker-malli sopii paremmin silloin, kun samalla palvelimella pyörii muitakin kotiverkon palveluita, kuten tiedostopalvelin tai mediasovellus, ja halutaan pitää ne toisistaan erillään omissa konteissaan. Kummassakaan tapauksessa itse AdGuard Home -binääri ei muutu, vain käyttöönottotapa.

Suodatuslogiikka ja arkkitehtuuri

Kun laite lähettää DNS-kyselyn, AdGuard Home käy sen läpi muutamassa vaiheessa. Ensin se tarkistaa, onko laitteelle määritetty oma asiakasprofiili ja sen mukaiset säännöt. Sitten se vertaa verkkotunnusta omiin sallittuihin ja estettyihin sääntöihin, ja vasta sen jälkeen käytetään ladattuja estolistoja. Jos mikään näistä ei estä kyselyä, se lähetetään ylävirran resolverille valitulla salatulla protokollalla, ja vastaus tallennetaan välimuistiin seuraavia kyselyjä varten. Tämä järjestys tarkoittaa, että omat säännöt voittavat aina yleiset listat, mikä tekee poikkeusten hallinnasta ennustettavaa.

Esivaatimukset: laitteisto, versiot ja verkko-oikeudet

Ennen asennusta kannattaa varmistaa, että käytössä on seuraavat osat. Taulukko kokoaa suositellut versiot ja vähimmäisvaatimukset, ja jokaisella rivillä on syy, miksi juuri se asia kannattaa tarkistaa etukäteen eikä vasta asennuksen puolivälissä.

Osa	Suositus	Huomio
Käyttöjärjestelmä	Debian 12/13, Ubuntu 24.04/26.04 LTS tai Raspberry Pi OS (64-bit)	64-bittinen asennus suositellaan aina 32-bittisen sijaan
AdGuard Home	v0.107.79 (GitHub-julkaisu 30.9.2026)	Tuoteversiosivulla näkyy vanhempi 0.107.76, käytä GitHub-julkaisua ajantasaisimpana
Docker Engine	Uusin vakaa versio jakelun virallisesta arkistosta	Tarkista versio komennolla docker --version asennuksen jälkeen
Laitteisto	Raspberry Pi 4/5 (1 Gt+ RAM), mini-PC tai pieni VPS	Kotiverkon kokoluokassa prosessori ei ole pullonkaula
Verkko-oikeudet	Kiinteä IP-osoite palvelimelle, pääsy reitittimen DHCP-asetuksiin	Tarvitaan vaiheessa 10
Tallennustila	Vähintään 2 Gt vapaata tilaa lokeille ja estolistoille	SD-kortilla kannattaa rajata lokien säilytysaika

Käyttäjätunnuksen on hyvä kuulua docker-ryhmään, jotta komennot eivät vaadi jatkuvaa sudo-etuliitettä. Varaa myös 60 minuuttia aikaa: itse asennus on nopea, mutta reitittimen ja kotiverkon laitteiden ohjaaminen uuteen DNS-palvelimeen vie oman hetkensä. Karkea aika-arvio jakautuu niin, että Dockerin asennus ja kontin käynnistys vievät noin 15 minuuttia, estolistojen ja salatun DNS:n asetukset toiset 15 minuuttia, ja loput 30 minuuttia kuluu reitittimen DHCP-asetusten löytämiseen ja kaikkien laitteiden testaamiseen. Jos reitittimen hallintapaneelin salasana on hukassa tai mallia ei muisteta tarkkaan, sen etsiminen etukäteen säästää turhautumista kesken asennuksen.

Docker-asennuksen jälkeen kannattaa tarkistaa versio, jotta tietää, mitä komentoja ja ominaisuuksia on käytettävissä:

$ docker --version
Docker version 27.x.x, build xxxxxxx

Jos komento palauttaa “command not found”, Docker-asennus ei onnistunut ja kannattaa palata jakelun viralliseen asennusohjeeseen ennen jatkamista.

Käyttöjärjestelmän valinta kannattaa tehdä sen mukaan, mitä muita palveluita laitteella aiotaan ajaa. Debian 13 (Trixie) ja Ubuntu 24.04/26.04 LTS saavat molemmat pitkän tukisyklin ja toimivat vakaasti ympäri vuorokauden pyörivällä palvelimella. Raspberry Pi OS perustuu Debianiin ja on suositeltava valinta nimenomaan Raspberry Pi -laitteille, koska se sisältää valmiiksi oikeat ajurit laitteen GPIO- ja verkkolaitteistolle. Älä valitse työpöytäkäyttöön tarkoitettua, raskasta jakelua palvelinkäyttöön, koska ylimääräinen graafinen käyttöliittymä syö muistia ja prosessoriaikaa turhaan.

Palvelimen fyysinen sijainti kotiverkossa kannattaa myös suunnitella. Kiinteä Ethernet-kaapeli reitittimeen on aina luotettavampi kuin Wi-Fi, koska DNS-palvelu on herkkä verkkoyhteyden katkoille: jos yhteys palvelimeen pätkii hetkeksi, kaikki laitteet, jotka käyttävät sitä DNS-palvelimena, kokevat samalla hetkellä hitaita tai epäonnistuvia sivulatauksia. Jos Ethernet ei ole mahdollinen, laite kannattaa sijoittaa mahdollisimman lähelle reitittimen Wi-Fi-kantamaa ja seurata yhteyden vakautta ensimmäisen viikon ajan.

Laitevalinta kannattaa tehdä käyttötarkoituksen mukaan. Jos kotiverkossa on alle kymmenen laitetta, Raspberry Pi 4 riittää hyvin ja kuluttaa sähköä vain muutaman watin verran ympäri vuorokauden. Suuremmassa taloudessa, jossa on kymmeniä älylaitteita, IoT-antureita ja useita käyttäjiä, kannattaa harkita tehokkaampaa mini-PC:tä tai olemassa olevaa NAS-laitetta, jossa on jo Docker-tuki valmiina. VPS-vuokraus on järkevä vaihtoehto, jos kotiverkossa ei ole tilaa tai halua pitää omaa laitetta päällä jatkuvasti, mutta silloin kannattaa muistaa, että DNS-palvelin sijaitsee fyysisesti eri verkossa kuin laitteet, joita se suojaa, mikä lisää hieman viivettä jokaiseen kyselyyn.

Askeleet 1-3: Palvelimen valinta, Docker ja työhakemistot

Vaihe 1. Valitse laite, jolla AdGuard Home pyörii ympäri vuorokauden. Raspberry Pi riittää hyvin tavalliseen kotiverkkoon, mutta myös pieni NAS tai halvin VPS-vuokraus toimii, kunhan laite on aina päällä ja sillä on kiinteä paikallinen IP-osoite. Valintaan kannattaa vaikuttaa myös äänettömyys ja virrankulutus, koska laite jää usein näkyville olohuoneeseen tai eteiseen muiden verkkolaitteiden joukkoon, ja jatkuva käyttö tarkoittaa sähkölaskua ympäri vuoden.

Vaihe 2. Asenna Docker jakelun virallisesta ohjeesta, jos sitä ei ole vielä koneella. Debian- ja Ubuntu-pohjaisilla järjestelmillä komento on tyypillisesti sudo apt install docker.io docker-compose-plugin, mutta tarkista ajantasaiset komennot omasta jakelusta. Jos palvelimella on aktiivinen palomuuri, kuten ufw, avaa tässä vaiheessa myös tarvittavat portit paikallisverkolle, jotta et joudu etsimään syytä yhteysongelmiin myöhemmin: sudo ufw allow from 192.168.1.0/24 to any port 53,80,443,853,3000 on turvallinen lähtökohta kotiverkolle.

Vaihe 3. Luo pysyvät hakemistot asetuksille ja työtiedostoille. Nämä kannatta pitää kontin ulkopuolella, jotta päivitykset eivät pyyhi asetuksia pois. Hakemisto /opt/adguardhome/work säilyttää tilastot ja kyselylokin, ja hakemisto /opt/adguardhome/conf säilyttää varsinaisen konfiguraatiotiedoston. Jos nämä kaksi hakemistoa varmuuskopioi säännöllisesti, koko palvelun voi palauttaa toiselle laitteelle muutamassa minuutissa.

sudo mkdir -p /opt/adguardhome/work
sudo mkdir -p /opt/adguardhome/conf
sudo docker pull adguard/adguardhome

Komento lataa AdGuard Homen virallisen Docker-kuvan. Tarkista lataus komennolla sudo docker images | grep adguardhome, jonka pitäisi näyttää vastaanotettu kuva ja koko. Virallinen kuva julkaistaan Docker Hubissa osoitteessa adguard/adguardhome, ja se päivittyy aina, kun projekti julkaisee uuden vakaan version.

Askeleet 4-6: Kontin käynnistys ja asennusvelho

Vaihe 4. Käynnistä kontti joko suoralla docker run-komennolla tai Compose-tiedostolla. Compose on suositeltavampi, koska portit ja asetukset pysyvät yhdessä tiedostossa ja ovat helposti versioitavissa. Ennen käynnistystä kannattaa tietää, mitä kukin julkaistu portti tekee: 53/tcp ja 53/udp hoitavat tavallisen DNS-liikenteen, 3000/tcp on ensimmäisen käynnistyksen asennusvelho, 80/tcp on hallintapaneeli HTTP:n yli, 443/tcp ja 443/udp toimivat hallintapaneelin HTTPS-yhteydelle ja DNS-over-HTTPS-palvelulle, ja 853/tcp on varattu DNS-over-TLS-yhteydelle.

Molemmissa esimerkeissä käytetty restart: unless-stopped -asetus kannattaa pitää aina mukana. Se varmistaa, että kontti käynnistyy automaattisesti uudelleen palvelimen uudelleenkäynnistyksen tai odottamattoman virran katkoksen jälkeen, mikä on tärkeää, koska koko kotiverkon DNS-liikenne on riippuvainen tästä yhdestä kontista.

sudo docker run --name adguardhome \
  --restart unless-stopped \
  -v /opt/adguardhome/work:/opt/adguardhome/work \
  -v /opt/adguardhome/conf:/opt/adguardhome/conf \
  -p 53:53/tcp -p 53:53/udp \
  -p 3000:3000/tcp \
  -p 80:80/tcp \
  -p 443:443/tcp -p 443:443/udp \
  -p 853:853/tcp \
  adguard/adguardhome

Sama asia Compose-tiedostona on helpompi ylläpidettävä, erityisesti jos palvelimella pyörii muitakin kontteja.

services:
  adguardhome:
    image: adguard/adguardhome:latest
    container_name: adguardhome
    restart: unless-stopped
    volumes:
      - /opt/adguardhome/work:/opt/adguardhome/work
      - /opt/adguardhome/conf:/opt/adguardhome/conf
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "3000:3000/tcp"
      - "80:80/tcp"
      - "443:443/tcp"
      - "443:443/udp"
      - "853:853/tcp"

Käynnistä Compose-tiedosto komennolla sudo docker compose up -d. Tarkista, että kontti pyörii:

$ sudo docker ps --filter name=adguardhome
CONTAINER ID   IMAGE                   STATUS         PORTS
3f91a2c7b0e4   adguard/adguardhome    Up 8 seconds   0.0.0.0:53->53/tcp, 0.0.0.0:3000->3000/tcp ...

Vaihe 5. Avaa selaimella osoite http://palvelimen-ip:3000 ja käy läpi asennusvelho: valitse hallintapaneelin ja DNS-palvelun kuunteluosoitteet, aseta pääkäyttäjän tunnus ja vahva salasana. Velho kysyy myös, mille verkkoliitännälle ja portille DNS-palvelu sidotaan, oletusarvo kaikki liitännät porttiin 53 toimii useimmissa kotiverkoissa.

Vaihe 6. Kun velho on valmis, kirjaudu hallintapaneeliin osoitteessa http://palvelimen-ip ja testaa, että etusivun tilastot alkavat kertyä muutaman testihaun jälkeen. Tee testihaku esimerkiksi komennolla nslookup example.com palvelimen-ip toiselta laitteelta ja tarkista, että hallintapaneelin Dashboard-näkymässä kysely­määrä kasvaa reaaliajassa. Jos luku ei liiku, siirry suoraan vianmääritysosioon ennen kuin jatkat seuraaviin vaiheisiin.

Askeleet 7-8: Suodatuslistat ja mukautetut säännöt

Vaihe 7. Siirry kohtaan Filters > DNS blocklists ja lisää valmiit estolistat tietojenkalastelua, haittaohjelmia ja seurantaa vastaan. Useimmat käyttäjät lisäävät vähintään yhden yleisen mainos- ja seurantalistan sekä yhden tietojenkalastelulistan. Listat ovat yksinkertaisia tekstitiedostoja, jotka AdGuard Home lataa määrävälein uudelleen, joten niiden lisääminen ei vaadi muuta kuin listan osoitteen liittämistä kenttään ja tallennusta.

Kannattaa välttää kymmenien listojen lisäämistä kerralla. Mitä useampi lista on päällä, sitä todennäköisemmin joukossa on päällekkäisiä sääntöjä ja vanhentuneita merkintöjä, jotka hidastavat päivitystä ja kasvattavat väärien positiivisten riskiä. Kaksi tai kolme hyvin ylläpidettyä listaa riittää tavalliseen kotiverkkoon paremmin kuin kymmenen satunnaista.

Listat jaetaan yleensä kolmeen ryhmään: mainos- ja seurantalistat estävät markkinointiverkkojen ja kävijäseurannan verkkotunnuksia, tietojenkalastelulistat estävät tunnetuiksi tulleita huijaussivustoja, ja haittaohjelmalistat estävät komentoyhteyksiä tunnetuille haittaohjelmaverkoille. Kotiverkkoon riittää yksi lista kustakin ryhmästä. Jos myöhemmin huomaa, ettei estoprosentti kasva juurikaan lisäämällä uusia listoja, kannattaa pysähtyä siihen määrään, koska lisähyöty jää pieneksi suhteessa ylläpitovaivaan.

Vaihe 8. Kohdassa Filters > Custom filtering rules voi kirjoittaa omia sääntöjä. Esimerkiksi tietyn verkkotunnuksen pysyvä esto ja toisen sallinta onnistuu näin:

||mainosverkko.esimerkki^
@@||pankki.esimerkki^$important

Ensimmäinen rivi estää kaikki kyselyt annettuun verkkotunnukseen, toinen sallii sen poikkeuksetta, mikä on hyödyllistä esimerkiksi pankkisovellusten kanssa, jos jokin laajempi lista estäisi niiden toiminnan. Samaa sääntösyntaksia käytetään myös suositussa uBlock Origin -selainlaajennuksessa, joten valmiita sääntöjä löytyy helposti sivustoilta, jotka ylläpitävät avoimen lähdekoodin estolistoja.

Säännöt tukevat myös jokerimerkkejä ja säännöllisiä lausekkeita monimutkaisempiin tapauksiin. Esimerkiksi kaikki alidomainit yhden verkkotunnuksen alta saa estettyä merkinnällä ||mainosverkko.esimerkki^, kun kahden pystyviivan etuliite tarkoittaa domainin ja sen alidomainien täsmäystä. Yksittäisen täsmän sijaan voi myös kirjoittaa listan muotoon, jossa yksi rivi vastaa yhtä verkkotunnusta, mikä pitää ison sääntöjoukon luettavana ja helposti ylläpidettävänä ajan myötä.

Askeleet 9-10: Salatun ylävirran DNS:n käyttöönotto

Vaihe 9. Siirry kohtaan Settings > DNS settings > Upstream DNS servers ja korvaa oletusarvo salatulla osoitteella. AdGuard Home tunnistaa protokollan URI-etuliitteestä.

https://valittu-resolveri.esimerkki/dns-query
tls://valittu-resolveri.esimerkki
quic://valittu-resolveri.esimerkki

Kirjoita oikean palveluntarjoajan julkaisema osoite, älä kopioi esimerkkiä tuotantoon. Monet julkiset resolverit julkaisevat omat DoH- ja DoT-osoitteensa dokumentaatiossaan, ja ne kannattaa tarkistaa suoraan palveluntarjoajalta ennen käyttöönottoa. Valintaa kannattaa tehdä kolmen kriteerin perusteella: minkä maan lainkäyttöalueelle resolveri kuuluu, kuinka pitkään se säilyttää kyselylokeja oman tietosuojaselosteensa mukaan, ja tukeeko se kaikkia kolmea protokollaa (DoH, DoT, DoQ) vai vain osaa niistä. AdGuard Homen virallinen aloitusopas listaa tuetut URI-muodot ja niiden tarkan kirjoitusasun.

Vaihe 10. Aseta myös varajärjestelmä kohtaan Fallback DNS servers, jotta yhteys ei katkea, jos ensisijainen resolveri ei vastaa. Tallenna asetukset ja avaa kysely­loki (Query Log) varmistaaksesi, että kyselyt kulkevat läpi virheittä. Loki näyttää jokaisen kyselyn kohdalla, käytettiinkö salattua yhteyttä, kuinka kauan vastaus kesti millisekunteina ja estikö jokin suodatin kyselyn. Tämä on helpoin tapa varmistaa, että salaus todella toimii, eikä jää vain asetusnäytölle.

Salatun yhteyden voi testata myös suoraan palvelimen komentoriviltä itse AdGuard Homea kohti, ennen kuin luottaa hallintapaneelin näyttämään tilaan:

$ curl -H 'accept: application/dns-json' \
  'https://palvelimen-ip/dns-query?name=example.com&type=A' -k
{"Status":0,"Answer":[{"name":"example.com.","type":1,"TTL":300,"data":"93.184.216.34"}]}

Vastauksessa "Status":0 kertoo, että kysely onnistui ja DNS-over-HTTPS-rajapinta vastaa odotetusti.

Askeleet 11-13: Reititin, HTTPS-varmenne ja varmuuskopiointi

Vaihe 11. Kirjaudu reitittimen hallintaan ja muuta LAN-verkon DHCP-asetuksista ensisijaiseksi DNS-palvelimeksi AdGuard Home -palvelimen kiinteä IP-osoite. Jos reititin tukee vain yhtä DNS-osoitetta, jätä toissijainen kenttä tyhjäksi, koska julkisen varaosoitteen lisääminen voi johtaa siihen, että osa laitteista ohittaa suodatuksen kokonaan.

Muista myös IPv6-puoli. Jos reititin jakaa IPv6-osoitteita reititys­ilmoituksilla (Router Advertisement), laitteet voivat saada erillisen IPv6-DNS-osoitteen, joka ohittaa AdGuard Homen kokonaan. Useimmissa kotireitittimissä IPv6-DNS-asetus löytyy samalta sivulta kuin IPv4-DHCP, mutta eri välilehdeltä. Jos reititin ei tue IPv6-DNS:n ohjaamista, yksinkertaisin ratkaisu on poistaa IPv6 käytöstä kotiverkon laitteilla tai rajata se palomuurisäännöllä, kunnes AdGuard Home saa IPv6-tuen kuntoon.

Mesh-Wi-Fi-järjestelmät, kuten useista tukiasemista koostuvat kotiverkkoratkaisut, tuovat oman mutkansa mukaan. Osa niistä sallii DNS-asetuksen muokkaamisen vain pääyksiköstä, ja osa synkronoi asetuksen kaikkiin tukiasemiin automaattisesti. Jos mesh-järjestelmän sovellus ei näytä DNS-kenttää ollenkaan, DHCP-palvelu kannattaa siirtää AdGuard Homen omaan DHCP-toimintoon, joka käydään läpi edistyneiden vinkkien osiossa.

Testaa muutos laitteella komennolla:

$ resolvectl status
Link 2 (eth0)
    Current DNS Server: 192.168.1.10
    DNS Servers: 192.168.1.10

$ dig example.com +short
93.184.216.34

Vaihe 12. Jos osa laitteista tarvitsee eri säännöt, luo kohtaan Settings > Client settings asiakaskohtaiset profiilit. Esimerkiksi lasten tablettiin voi liittää tiukemman estolistan kuin työkoneeseen. Profiili tunnistetaan joko laitteen IP-osoitteesta, MAC-osoitteesta tai hallintapaneelissa annetusta nimestä, ja jokaiselle profiilille voi asettaa oman estolistayhdistelmän, oman ylävirran resolverin ja oman aikataulun, jolloin suodatus on päällä tai pois.

Vaihe 13. Suojaa hallintapaneeli HTTPS-varmenteella, jos käytät AdGuard Homea muualtakin kuin paikallisverkosta, ja ota käyttöön säännöllinen varmuuskopiointi. Kohdassa Settings > Encryption settings voi liittää olemassa olevan varmenteen ja yksityisen avaimen, tai ohjata liikenteen käänteisproxyn (esimerkiksi Caddy tai Nginx) läpi, jolloin proxy hoitaa varmenteen uusimisen automaattisesti. Paikallisverkon sisäiseen käyttöön riittää itse allekirjoitettu varmenne, mutta silloin jokainen selain näyttää varoituksen ensimmäisellä kerralla. Natiiviasennuksessa palvelua hallitaan seuraavilla komennoilla:

sudo AdGuardHome -s status
sudo AdGuardHome -s start
sudo AdGuardHome -s stop
sudo AdGuardHome -s restart

Docker-ympäristössä varmuuskopio on yksinkertaisesti kopio /opt/adguardhome/conf-hakemistosta. Ajoita se esimerkiksi cron-tehtävällä kerran viikossa ja säilytä kopio eri levyllä kuin itse palvelin. Ennen isompia päivityksiä kannattaa ottaa ylimääräinen varmuuskopio käsin, koska pääversion vaihtuessa konfiguraatiotiedoston skeema voi muuttua, ja vanhan asetustiedoston palauttaminen uuteen versioon epäonnistuu, jos skeemat eivät täsmää.

Etäkäyttö kodin ulkopuolelta

Monet käyttäjät haluavat hyötyä omasta DNS-suodatuksesta myös matkoilla tai kesämökillä. Turvallisin tapa on yhdistää laite kotiverkkoon VPN-tunnelin, esimerkiksi WireGuardin, kautta ja antaa VPN-yhteyden jakaa AdGuard Homen osoitteen DNS-palvelimeksi. Tällöin DNS-kysely kulkee salattuna aina kotiverkkoon asti, eikä AdGuard Homen hallintapaneelia tai DNS-porttia tarvitse avata suoraan julkiseen verkkoon. Suoraan julkiseen verkkoon avaaminen on mahdollista, mutta se vaatii vähintään vahvan salasanan, kelvollisen HTTPS-varmenteen ja mielellään myös IP-osoitteiden rajaamisen palomuurilla tunnettuihin verkkoihin.

Seitsemän yleisintä sudenkuoppaa asennuksessa

Suurin osa AdGuard Home -asennuksen ongelmista ei liity itse ohjelmistoon, vaan ympäröivään verkkoon: reitittimeen, käyttöjärjestelmän omaan DNS-palveluun tai liian kiireellä tehtyihin suodatusasetuksiin. Nämä seitsemän tapausta toistuvat eniten käyttäjien kysymyksissä.

• Portti 53 on varattu. Debian- ja Ubuntu-pohjaisilla järjestelmillä systemd-resolved kuuntelee usein osoitetta 127.0.0.53:53, mikä estää AdGuard Homea käynnistymästä samalla portilla.
• Reititin jakaa yhä omaa osoitettaan DNS-palvelimena. Osa reitittimistä palauttaa oman IP-osoitteensa DHCP-vastauksessa uudelleenkäynnistyksen jälkeen, vaikka asetus olisi vaihdettu.
• IPv6-kyselyt ohittavat suodatuksen. Jos reititin jakaa IPv6-DNS-osoitteita erikseen, laite voi käyttää niitä AdGuard Homen ohi, ellei IPv6-DHCP:tä ole ohjattu samaan osoitteeseen. Tämä huomataan usein vasta, kun estolistan pitäisi estää jokin sivusto, mutta se latautuu silti normaalisti IPv6-yhteyden kautta.
• Liian tiukat estolistat rikkovat pankki- tai työsovelluksia. Useiden laajojen listojen yhdistäminen kasvattaa väärien positiivisten määrää, joten testaa tärkeimmät sovellukset käyttöönoton jälkeen.
• Hallintapaneeli jää avoimeksi julkiseen verkkoon. Oletusportit 80 ja 3000 eivät sisällä pääsynhallintaa oletuksena yhtä käyttäjätunnusta lukuun ottamatta, joten palomuurisäännöt on rajattava erikseen. Heikko tai oletusarvoinen pääkäyttäjän salasana yhdistettynä avoimeen porttiin on yksi yleisimmistä tavoista, joilla kotiverkon laitteita löydetään skannauksilla julkisesta internetistä.
• SD-kortti kuluu nopeasti Raspberry Pi -asennuksessa. Tiheä lokikirjoitus pienelle muistikortille lyhentää kortin elinikää. Rajaa kyselylokin säilytysaika kohdassa Settings > General settings tai siirrä työhakemisto USB-SSD:lle.
• Varmuuskopiota ei ole otettu ennen päivitystä. Jos palvelin vaihtaa laitetta tai kontti tuhoutuu vahingossa, kaikki estolistat ja säännöt pitää rakentaa uudelleen, jos konfiguraatiotiedostosta ei ole tallennettua kopiota muualla.

Vianmääritys: kymmenen yleisintä ongelmaa

Kun jokin ei toimi odotetusti, kannattaa aina tarkistaa ensin kysely­loki ja sen jälkeen edetä taulukon järjestyksessä. Suurin osa ongelmista löytyy näistä kymmenestä tapauksesta, jotka on kerätty AdGuard Homen virallisesta dokumentaatiosta ja käyttäjien yleisimmistä kysymyksistä.

Ongelma	Todennäköinen syy	Ratkaisu
Kontti ei käynnisty, portti 53 varattu	systemd-resolved kuuntelee samaa porttia	Tarkista ss -lntup | grep ':53' ja vapauta portti tai vaihda kuunteluosoite
Selain näyttää DNS_PROBE_FINISHED_NXDOMAIN	Laite käyttää yhä vanhaa DNS-osoitetta	Tyhjennä laitteen DNS-välimuisti ja tarkista DHCP-vuokrasopimus uudelleen
Kyselyloki pysyy tyhjänä	Reititin ei ohjaa liikennettä AdGuard Homeen	Varmista DHCP-asetus ja testaa suoraan dig @palvelimen-ip example.com
Hallintapaneeli ei avaudu HTTPS:llä	Varmenne puuttuu tai portti 443 on toisen palvelun käytössä	Lisää kelvollinen varmenne tai siirrä AdGuard Home käänteisproxyn taakse
DoH-ylävirta ei vastaa	Väärä URI-muoto tai palomuuri estää ulosmenevän 443/853-liikenteen	Tarkista URI-etuliite ja avaa tarvittavat portit palomuurista
Osa laitteista ohittaa suodatuksen	IPv6-DNS tai VPN-sovellus ohjaa liikenteen muualle	Ohjaa IPv6-DHCP samaan osoitteeseen tai poista VPN:n omat DNS-asetukset käytöstä
Estolistojen päivitys epäonnistuu	Palvelimella ei ole ulospäin suuntautuvaa HTTPS-yhteyttä	Testaa curl -I https://osoite palvelimelta ja tarkista palomuuri
Raspberry Pi hidastuu käytössä	SD-kortin kirjoitusnopeus ei riitä lokikirjoitukseen	Lyhennä lokien säilytysaikaa tai siirrä työhakemisto USB-SSD:lle
Varmuuskopio ei palaudu päivityksen jälkeen	Konfiguraatiotiedoston skeemaversio on muuttunut	Tarkista muutosloki ja päivitä asetustiedosto uuden skeeman mukaiseksi
Pankkisovellus ei toimi suodatuksen jälkeen	Laaja estolista blokkaa sovelluksen käyttämän verkkotunnuksen	Lisää poikkeussääntö @@||verkkotunnus^$important

Jos ongelma ei löydy tästä listasta, seuraava askel on tarkistaa kontin lokit komennolla sudo docker logs adguardhome, joka näyttää käynnistysvirheet ja mahdolliset asetustiedoston jäsennysvirheet selkeällä tekstillä. Suurin osa jäljellä olevista tapauksista ratkeaa, kun lokiviesti yhdistetään kysely­lokin aikaleimaan hallintapaneelissa, jolloin näkee tarkalleen, mikä kysely ja mikä sääntö liittyivät toisiinsa.

AdGuard Home vs Pi-hole vs NextDNS vs Quad9

Nämä neljä ratkaisua ratkaisevat samaa ongelmaa eri tavoin. AdGuard Home ja Pi-hole pyörivät omalla laitteella, NextDNS ja Quad9 ovat pilvipalveluita, joihin ei tarvita omaa palvelinta. Taulukko kokoaa keskeisimmät erot, jotta vertailu ei jää vain tuotenimien listaamiseksi.

Ominaisuus	AdGuard Home	Pi-hole	NextDNS	Quad9
Ajoympäristö	Oma laite (Docker/natiivi)	Oma laite (Docker/natiivi)	Pilvipalvelu	Pilvipalvelu
Sisäänrakennettu DoH/DoT/DoQ ylävirtaan	Kyllä, suoraan asetuksista	Yleensä tarvitsee erillisen forwarderin	Kyllä, sisäänrakennettu	Kyllä, sisäänrakennettu
Paikalliset lokit pysyvät omalla laitteella	Kyllä	Kyllä	Ei, lokit pilvessä	Rajoitetusti
Asiakaskohtaiset profiilit	Kyllä	Rajoitetusti	Kyllä	Ei
Vaatii oman laitteen ylläpidon	Kyllä	Kyllä	Ei	Ei
Hinta	Ilmainen, avoin lähdekoodi	Ilmainen, avoin lähdekoodi	Ilmainen perustaso, maksullisia lisäosia	Ilmainen

Jos tavoite on pitää lokit täysin omassa hallinnassa ja ottaa salattu ylävirran DNS käyttöön ilman erillistä aputunnelia, AdGuard Home on suorin reitti. Jos oman laitteen ylläpito ei kiinnosta, NextDNS tai Quad9 hoitavat salauksen ja perussuodatuksen pilvipuolella, mutta silloin kyselyt näkee kolmas osapuoli, ei vain oma reititin. Ennen pilvipalvelun valintaa kannattaa lukea sen tietosuojaseloste läpi ja tarkistaa, missä maassa palvelu käsittelee lokitietoja ja kuinka pitkään niitä säilytetään, koska tämä tieto vaihtelee palveluntarjoajien välillä.

Pi-hole kannattaa valita, jos kotiverkossa on jo valmiiksi Unbound-resolveri pystyssä tai jos tutuksi tullut Pi-hole-ekosysteemi ja sen laajennukset ovat tärkeämpiä kuin sisäänrakennettu salaus. AdGuard Home sopii paremmin, kun halutaan yksi paketti, jossa suodatus, salattu ylävirta ja asiakasprofiilit ovat samassa hallintapaneelissa alusta asti. Molemmat ovat avoimen lähdekoodin projekteja, joten valinta ei lukitse käyttäjää mihinkään kaupalliseen sopimukseen.

Käyttötapaus ratkaisee usein enemmän kuin tekninen yksityiskohta. Perheelle, joka haluaa yksinkertaisen tavan rajoittaa lasten laitteiden pääsyä haitalliseen sisältöön eikä halua ylläpitää omaa laitetta, NextDNS on nopein tie käyttöön muutamassa minuutissa. Yksityisyydestä kiinnostuneelle harrastajalle, joka haluaa nähdä ja hallita jokaisen kyselyn itse, AdGuard Home tai Pi-hole ovat oikea valinta. Pienelle toimistolle, jossa on kymmeniä työasemia ja tarve erotella laiteryhmiä omiin profiileihin, AdGuard Homen sisäänrakennetut asiakasprofiilit tekevät siitä käytännöllisimmän vaihtoehdon neljästä.

Edistyneet vinkit: suorituskyky, tilastot ja automaatio

Kun perusasennus on pystyssä, kannattaa hienosäätää muutama asia. Ensinnäkin kysely­välimuisti: AdGuard Home tallentaa vastauksia muistiin, jolloin toistuvat kyselyt eivät kulje ylävirtaan asti. Välimuistin kokoa voi kasvattaa kohdassa Settings > DNS settings > Cache size, mikä nopeuttaa selailua kotiverkossa huomattavasti. Suuremmassa taloudessa, jossa useat laitteet kysyvät samoja suosittuja verkkotunnuksia toistuvasti, kasvatettu välimuisti näkyy suoraan sivujen latautumisnopeudessa, koska vastaus tulee paikallisesta muistista millisekunneissa sen sijaan, että se haettaisiin uudelleen ylävirran resolverilta.

Tilastosivu näyttää laitekohtaisen kyselymäärän ja estoprosentin. Tätä kannattaa seurata ensimmäisen viikon ajan, jotta näkee, mikä estolista aiheuttaa enemmän vääriä positiivisia kuin todellista hyötyä. DNS-uudelleenkirjoitussäännöillä (DNS rewrites) voi lisäksi ohjata paikallisia laitenimiä omiin IP-osoitteisiin, mikä on hyödyllistä kotiverkon palvelimille ja NAS-laitteille.

Automaation puolella konfiguraatiotiedoston versionhallinta kannattaa ottaa käyttöön vaikka yksinkertaisella git-repolla /opt/adguardhome/conf-hakemistossa. Näin asetusmuutokset jäävät historiaan, ja virheellisen säännön voi kumota yhdellä komennolla. Päivitykset kannattaa ajoittaa, esimerkiksi kerran kuukaudessa, komennolla docker pull adguard/adguardhome && docker compose up -d, jolloin kontti vaihtuu uuteen versioon ilman asetusten katoamista.

Jos kotiverkossa on useampi AdGuard Home -asennus, esimerkiksi yksi pääpalvelimella ja toinen varalla, kannattaa ottaa käyttöön DHCP-palvelu suoraan AdGuard Homesta kohdassa Settings > DHCP settings. Tällöin AdGuard Home jakaa IP-osoitteet ja DNS-asetukset samalla kertaa, eikä reitittimen omaa DHCP-palvelua enää tarvita. Tämä on edistyneempi vaihtoehto, joka vaatii huolellista testausta, ennen kuin reitittimen omasta DHCP-palvelusta luovutaan kokonaan, jotta verkko ei jää hetkeksi kokonaan vaille osoitteenjakoa.

Teknisemmälle käyttäjälle AdGuard Home tarjoaa myös rajapinnan, jonka avulla tilastoja voi viedä ulkopuoliseen seurantajärjestelmään. Kyselymääriä, estoprosenttia ja vastausaikoja voi seurata ajan mittaan esimerkiksi Grafana-kojelaudalla, jos data kerätään säännöllisesti hallintapaneelin rajapinnan kautta. Tämä on hyödyllistä erityisesti, jos AdGuard Home palvelee useampaa kotitaloutta tai pientä toimistoa, jolloin yksittäisen päivän tilastointi hallintapaneelista ei riitä pitkän aikavälin seurantaan.

Täydellinen esimerkkiprojekti: kotiverkon suojaus alusta loppuun

Kootaan edellä käydyt vaiheet yhdeksi toimivaksi kokonaisuudeksi tavallista kolmen hengen kotitaloutta varten. Palvelimeksi valitaan Raspberry Pi 5, jossa on 4 Gt muistia ja USB-SSD-levy työhakemistolle SD-kortin sijaan.

1. Asenna Raspberry Pi OS 64-bit ja Docker, kytke USB-SSD ja liitä se hakemistoon /opt/adguardhome. USB-SSD valitaan tietoisesti SD-kortin sijaan, koska se kestää paremmin jatkuvan lokikirjoituksen.
2. Käynnistä AdGuard Home Compose-tiedostolla, kuten vaiheissa 4-5, ja aseta kiinteä IP-osoite 192.168.1.10 reitittimen DHCP-varauksella, jotta osoite ei muutu laitteen uudelleenkäynnistyksen yhteydessä.
3. Lisää kaksi estolistaa: yksi yleinen mainos- ja seurantalista, yksi tietojenkalastelulista. Tarkoituksella vain kaksi, jotta väärien positiivisten määrä pysyy hallittavana ensimmäisellä viikolla.
4. Aseta ylävirran DNS:ksi salattu DoH-osoite ja varaosaksi toinen salattu resolveri, kuten vaiheessa 9 ja 10 kuvattiin.
5. Luo kolme asiakasprofiilia: vanhempien laitteet, lasten tabletti tiukemmalla listalla ja kodin IoT-laitteet omalla, rajoitetulla profiililla, jolla estetään oletuksena kaikki muu paitsi tarvittavat pilvipalveluyhteydet.
6. Vaihda reitittimen DHCP-asetuksista ensisijaiseksi DNS-palvelimeksi 192.168.1.10 ja testaa jokaisella laitetyypillä, myös älytelevisiolla ja pelikonsolilla, jotka usein unohtuvat testauksesta.
7. Ajoita viikoittainen varmuuskopio /opt/adguardhome/conf-hakemistosta ulkoiselle levylle, ja merkitse kalenteriin muistutus tarkistaa AdGuard Homen versio kerran kuukaudessa.

Tuloksena on kotiverkko, jossa kaikki DNS-kyselyt kulkevat salattuina ylävirtaan, lokit pysyvät omalla laitteella ja eri laiteryhmillä on omat suodatussäännöt. Koko projektin pystyttäminen tästä pohjasta vie kokeneelle käyttäjälle noin tunnin, aloittelijalle hieman kauemmin reitittimen asetusten etsimisen vuoksi.

Projektin onnistumisen voi todentaa hallintapaneelin Dashboard-näkymästä: siellä näkyy kyselymäärä laitekohtaisesti, estoprosentti kokonaisuudessaan ja lista viimeksi estetyistä verkkotunnuksista. Ensimmäisen vuorokauden jälkeen tyypillinen kotiverkko näyttää estoprosentin, joka vaihtelee laajasti käytettyjen estolistojen ja laitteiden sovellusten mukaan, joten yksittäistä “normaalia” lukua ei kannata odottaa, vaan seurata oman verkon kehitystä ajan myötä.

Kun projekti on pyörinyt viikon ajan häiriöittä, seuraava luonnollinen askel on dokumentoida asetukset lyhyesti: mikä laite on palvelimena, mikä on sen kiinteä IP-osoite, mitä estolistoja on käytössä ja mihin varmuuskopio tallentuu. Tämä muistiinpano säästää aikaa, jos palvelin pitää joskus vaihtaa toiseen laitteeseen tai jos joku muu taloudessa joutuu ylläpitämään asennusta.

Tietosuoja, GDPR ja sääntely Suomessa ja EU:ssa

DNS-suodatus on tekninen suojakeino, ei oikeudellinen ratkaisu. Oma AdGuard Home -palvelin vähentää sitä, kuinka moni ulkopuolinen taho näkee kotiverkon DNS-kyselyt, mutta se ei poista kaikkea seurantaa, joka tapahtuu sovellusten omien yhteyksien, selaimen sormenjäljen tai IP-osoitteen kautta. Tämä kannattaa pitää mielessä, jos AdGuard Home markkinoidaan talouden sisällä täydellisenä yksityisyysratkaisuna: se on yksi kerros monesta, ei koko suojan muodostava yksittäinen tuote.

Jos AdGuard Homea käytetään kodin ulkopuolella, esimerkiksi yhdistyksessä, koulussa tai pienessä yrityksessä, kyselylokit voivat sisältää henkilötietoja, kuten laitekohtaisia käyttötottumuksia. Tällöin kannattaa noudattaa GDPR:n periaatteita: lokien säilytysaika rajataan tarpeeseen, käyttöoikeudet hallintapaneeliin rajataan ja käyttötarkoitus kirjataan ylös. Suomessa toimivaltainen valvoja tietosuoja-asioissa on tietosuojavaltuutetun toimisto, ja viestintäverkkoihin liittyvissä kysymyksissä toimivaltainen virasto on Liikenne- ja viestintävirasto Traficom, jonka alaisuudessa Kyberturvallisuuskeskus julkaisee ohjeistusta myös DNS-liikenteen suojaamisesta.

Organisaatiolle, joka kuuluu NIS2-sääntelyn piiriin, oma DNS-palvelin tuo mukanaan myös vastuun sen ylläpidosta: tietoturvapäivitykset, pääsynhallinta ja lokien suojaus on dokumentoitava osana organisaation yleistä riskienhallintaa. DNS-suodatus voi olla yksi osa kerrostettua suojausta, mutta se ei korvaa muita NIS2:n edellyttämiä toimia, kuten häiriöilmoitusprosesseja tai toimittajahallintaa.

Samat periaatteet pätevät myös muualla Pohjoismaissa. Ruotsissa, Norjassa ja Tanskassa GDPR:ää sovelletaan samalla tavalla kuin Suomessa, joten lokien säilytysaikaa ja käyttötarkoitusta koskevat perusteet ovat yhteiset kaikissa Pohjoismaissa, vaikka valvovat viranomaiset ovat kansallisia. Kotikäyttäjän näkökulmasta tämä tarkoittaa, että samaa AdGuard Home -asennusta ja samoja asetuksia voi käyttää Helsingissä, Tukholmassa tai Oslossa ihan samoin perustein, sääntely ei muuta teknistä toteutusta kotiverkossa.

Kotikäytössä sääntely ei aseta erityisvaatimuksia, mutta vastuullinen tapa on silti pitää lokien säilytysaika lyhyenä ja hallintapaneeli pois julkisesta verkosta. Salattu DNS-over-HTTPS-protokolla on standardoitu IETF:n RFC 8484 -dokumentissa, mikä tarkoittaa, että toteutus on yhteentoimiva eri valmistajien ohjelmistojen välillä.

Käytännön tarkistuslista tietosuojan osalta on lyhyt: aseta kysely­lokin säilytysaika kohdassa Settings > General settings niin lyhyeksi kuin oma vianmääritystarve sallii, vaihda hallintapaneelin oletussalasana ensimmäisten minuuttien aikana, älä jaa pääkäyttäjän tunnuksia muille kuin niille, jotka todella tarvitsevat pääsyn, ja dokumentoi lyhyesti, miksi palvelu on pystytetty ja kuka sitä ylläpitää, jos laite palvelee useampaa kuin yhtä taloutta.

Usein kysytyt kysymykset

Onko AdGuard Home ilmainen?
Kyllä, AdGuard Home on avoimen lähdekoodin ohjelmisto, ja sen ajaminen omalla laitteella ei maksa lisenssimaksuja. Kustannukseksi jää vain laitteen sähkönkulutus ja mahdollinen VPS-vuokra, jos sitä käytetään ajoalustana.

Tarvitsenko Raspberry Pi:n, vai riittääkö tavallinen tietokone?
Mikä tahansa laite, joka pyörii jatkuvasti ja tukee Dockeria, riittää. Raspberry Pi on suosittu matalan virrankulutuksen takia, mutta myös mini-PC, NAS tai VPS toimivat yhtä hyvin.

Toimiiko AdGuard Home Windowsilla tai macOS:llä?
Kyllä, AdGuard Home julkaisee binäärit myös Windowsille ja macOS:lle, mutta kotiverkon pääasialliseksi DNS-palvelimeksi se kannattaa asentaa laitteelle, joka pysyy päällä ympäri vuorokauden. Windows- tai Mac-tietokone, joka sammutetaan öisin, ei sovellu tähän tarkoitukseen yhtä hyvin kuin aina päällä oleva Raspberry Pi, NAS tai VPS.

Mikä on AdGuard Homen uusin versio lokakuussa 2026?
GitHub-julkaisulistan uusin vakaa versio on 0.107.79, julkaistu 30.9.2026. AdGuardin omalla tuoteversiosivulla näkyy tätä hieman vanhempi 0.107.76, joten GitHub-julkaisu kannattaa tarkistaa ajantasaisimpana lähteenä.

Voiko AdGuard Homea käyttää Pi-holen rinnalla?
Molempia samanaikaisesti samalla porttiosoitteella ei kannata ajaa, koska ne kilpailevat samasta DNS-portista. Valitse yksi pääratkaisu kotiverkkoon, jotta suodatuslogiikka ei mene ristiin. Jos haluaa testata molempia rinnakkain, kannattaa ajaa toista eri laitteella tai eri portissa ja vaihtaa reitittimen DHCP-osoite väliaikaisesti testin ajaksi.

Miksi jokin verkkosivu ei toimi käyttöönoton jälkeen?
Yleisin syy on liian laaja estolista, joka blokkaa sivuston käyttämän kolmannen osapuolen verkkotunnuksen. Tarkista kyselyloki, löydä estetty verkkotunnus ja lisää sille poikkeussääntö kohdassa Custom filtering rules.

Toimiiko AdGuard Home myös matkapuhelinverkossa kodin ulkopuolella?
Vain, jos laite yhdistetään kotiverkkoon VPN:n kautta tai AdGuard Home on julkaistu turvallisesti ulkoverkkoon HTTPS-varmenteella ja pääsynhallinnalla. Suojaamattomana julkiseen verkkoon avaaminen ei ole suositeltavaa. Käytännössä suurin osa käyttäjistä rajaa AdGuard Homen palvelemaan vain kotiverkkoa ja käyttää erillistä VPN-sovellusta reissussa ollessaan.

Kuinka paljon AdGuard Home kuluttaa resursseja?
Tavallisessa kotiverkon kuormassa prosessorin ja muistin käyttö on pientä, ja Raspberry Pi 4 tai 5 riittää hyvin usean kymmenen laitteen verkkoon. Pullonkaulaksi muodostuu yleisimmin tallennusmedian kirjoitusnopeus, ei suorituskyky.

Mitä tapahtuu, jos AdGuard Home -palvelin kaatuu tai jää pois verkosta?
Jos reitittimessä on vain yksi DNS-osoite ja se osoittaa AdGuard Homeen, laitteet eivät saa DNS-vastauksia ja uudet yhteydet verkkosivuille katkeavat, kunnes palvelin palaa käyttöön. Tämän vuoksi kannattaa määrittää toimiva Fallback DNS servers -asetus vaiheessa 10 ja harkita restart-politiikkaa unless-stopped, joka käynnistää kontin automaattisesti uudelleen palvelimen uudelleenkäynnistyksen jälkeen.

Miten AdGuard Home päivitetään turvallisesti uuteen versioon?
Ota ensin varmuuskopio /opt/adguardhome/conf-hakemistosta, lue projektin julkaisutiedot GitHubista mahdollisten rikkovien muutosten varalta, ja aja sitten docker pull adguard/adguardhome && docker compose up -d. Kontti vaihtuu uuteen kuvaan muutamassa sekunnissa, ja asetukset pysyvät tallessa, koska ne sijaitsevat kontin ulkopuolisessa hakemistossa. Jos jokin menee pieleen, vanha konfiguraatio on aina varmuuskopiossa palautettavissa.