Vad är ett DNS-läckage — och hur testar du för ett på riktigt

Kortversionen: en VPN-tunnel krypterar de IP-paket din enhet skickar till andra servrar. DNS är uppslaget som sker innan paketet skickas — din enhet frågar "vilket IP-adress tillhör example.com?" Om det uppslaget går till din ISP:s resolver istället för genom VPN:n, ser din ISP domänen trots att den aldrig ser den krypterade trafiken som följer. Det är ett läckage. Det omintetgör det viktigaste löftet om integritet som en VPN ger, av den enklast möjliga anledningen: fel DNS-resolver tillfrågades. De goda nyheterna är att läckage är lätt att upptäcka, oftast lätt att åtgärda, och att de flesta välbyggda VPN-appar förhindrar dem som standard. De dåliga nyheterna är att "de flesta" inte är "alla," och ett fåtal vanliga konfigurationer orsakar läckage även i annars korrekta VPN-uppsättningar.

Vad DNS faktiskt gör och varför det läcker

DNS — Domain Name System — är internets adressbok. Varje gång din enhet ansluter till en webbplats måste den först översätta det läsbara värdnamnet (example.com) till en numerisk IP-adress (något i stil med 93.184.216.34) som routrar faktiskt kan vidarebefordra paket till. Det översättningssteget är en DNS-förfrågan, och det är en separat nätverksoperation från den faktiska webbförfrågan som följer efter.

Med en vanlig hemuppkoppling tilldelas din DNS-resolver av din ISP via DHCP — samma mekanism som delar ut din IP-adress. När du ansluter till Wi-Fi talar routern om för din enhet: "din DNS-server är 192.168.1.1, som vidarebefordrar till din ISP:s rekursiva resolver." Varje domän du slår upp flödar genom den resolvern. ISP:n kan logga det, sälja det till en datamäklare (i USA är detta lagligt), eller lämna ut det till brottsbekämpande myndigheter.

När du ansluter en VPN bör två saker hända. För det första krypteras din nätverkstrafik och dirigeras genom VPN-tunneln. För det andra bör din DNS-resolver ändras — från ISP:ns resolver till en som drivs av VPN-leverantören (eller en tredjeparts integritetscentrerad resolver), nåbar enbart genom den krypterade tunneln. Om bara den första halvan sker har du ett DNS-läckage. Trafiken är krypterad men uppslagens som föregick trafiken flödar fortfarande till ISP:n och berättar för dem varje sajt du är på väg att besöka.

Ur integritetssynpunkt är DNS-förfrågan nästan lika avslöjande som trafiken i sig. Förfrågan avslöjar den exakta domänen (ner till subdomänen — mail.example.com är urskiljbar från www.example.com) och tidpunkten. Kombinerat med den krypterade trafikvolymen omedelbart efteråt ger en DNS-läckande VPN en observatör tillräckligt med metadata för att rekonstruera din surfsession på nästan alla meningsfulla sätt.

De fyra sätten ett DNS-läckage uppstår

DNS-läckage är inte en enskild bugg. Det är en familj av relaterade felkonfigurationer, var och en med en annan grundorsak och en annan lösning. I ungefärlig frekvensordning:

1. OS-kringgående — Windows delad DNS / Smart Multi-Homed Name Resolution

Windows har en funktion kallad Smart Multi-Homed Name Resolution som, när den är aktiverad, skickar DNS-förfrågningar parallellt till alla tillgängliga DNS-resolvrar — inklusive ISP:ns resolver på det fysiska gränssnittet, även när en VPN är aktiv. Vilken resolver som svarar snabbast vinner och de övriga ignoreras, men förfrågningarna har redan skickats. På de flesta Windows-datorer är detta aktiverat som standard. Lösningen är att inaktivera funktionen via Grupprincip eller genom att konfigurera VPN-klienten att göra det vid anslutning. Linux har ett liknande problem med systemd-resolved om det inte är korrekt konfigurerat; macOS och iOS hanterar detta bättre men inte perfekt.

2. Felaktig konfiguration av delade tunnlar

Delade tunnlar (split tunneling) låter dig dirigera vissa appar genom VPN:n och andra via din vanliga anslutning. Ett vanligt konfigurationsfel är att ställa in appbaserad delad tunnel utan att också konfigurera per-app DNS — vilket innebär att en app som dirigeras utanför VPN-tunneln ändå försöker använda VPN:ns DNS-resolver, eller tvärtom, och hamnar i ett läckage via den väg som OS:t tillhandahåller. En värre variant: den delade tunneln dirigerar korrekt appens TCP-trafik utanför tunneln, men OS-bred DNS-resolver är fortfarande ISP:ns resolver, så alla appar — tunnlade eller inte — läcker sina DNS-förfrågningar till ISP:n. Vi täcker det bredare ämnet i vår genomgång av vad delade tunnlar faktiskt gör.

3. IPv6-återfall

Många VPN-klienter designades när IPv4 var det enda routingproblemet. De installerar IPv4-brandväggsregler och routingregler som korrekt dirigerar DNS genom tunneln, men de installerar inte matchande IPv6-regler. Om ditt nätverk har IPv6-anslutning väljer OS ibland IPv6 för DNS-förfrågningar — och dessa förfrågningar flödar ut via det nakna gränssnittet och kringgår VPN:n helt. Detta är ett av de vanligaste läckagelägena 2026 och är särskilt vanligt på bostadsbredband med dubbel-stack IPv4/IPv6 från ISP:n. Lösningen är antingen att inaktivera IPv6 globalt (drastiskt men pålitligt), eller att använda en VPN-klient som explicit hanterar IPv6-rutter.

4. WebRTC och webbläsarlöst DNS

Moderna webbläsare — Chrome, Edge, Firefox, Safari — kan utföra DNS-uppslag själva istället för att använda OS-resolvern. Det mest kända fallet är WebRTC, peer-to-peer-protokollet som används av videochatt. WebRTC använder STUN-servrar för att identifiera dina riktiga lokala och offentliga IP-adresser, och historiskt sett sänder det ut båda även när en VPN är aktiv. Den "riktiga" IP:n från WebRTC har länge varit ett webbläsarsidigt läckage som kräver explicit motåtgärd. Separat kan webbläsare som använder DNS-over-HTTPS (DoH) dirigera DNS-förfrågningar direkt till Cloudflare, Google eller NextDNS oavsett OS-resolverinställningen — vilket ibland hjälper (DoH till offentlig resolver är mer privat än klartext till ISP) och ibland skadar (den offentliga resolvern ser fortfarande dina förfrågningar och webbläsaren kringgår VPN:ns DNS-regler).

Hur du testar för ett DNS-läckage på under en minut

Att testa för ett DNS-läckage tar längre tid att beskriva än att göra. Anslut din VPN och besök sedan något av dessa tre verktyg. De avslöjar var och ett lite olika aspekter av läckageytan.

dnsleaktest.com

Det klassiska verktyget. Besök dnsleaktest.com, klicka på "Extended test" och vänta ungefär 20 sekunder. Verktyget utfärdar en serie DNS-förfrågningar för unika värdnamn det kontrollerar och visar sedan vilka resolvrar som faktiskt utförde dessa uppslag. Om du ser din ISP:s namn (Comcast, Verizon, BT, etc.) i resolverinlistan läcker du. Om du bara ser VPN-leverantörens resolver (eller en integritetscentrerad offentlig resolver som Quad9 eller Cloudflares 1.1.1.1) är OS DNS-vägen korrekt.

browserleaks.com/dns

Mer detaljerat än dnsleaktest. Det visar dig inte bara vilka resolvrar som hanterade förfrågan, utan också deras geografiska plats, ASN (nätverksoperatören) och om de stöder DNS-over-HTTPS eller DNS-over-TLS. Användbart för att fånga subtila läckage där rätt typ av resolver används men befinner sig i fel land, eller för att bekräfta att ett krypterat DNS-protokoll faktiskt används.

ipleak.net

Det mest omfattande — det testar DNS-läckage, WebRTC-läckage, IPv4- och IPv6-synlighet och visar vad din geolokalisering verkar vara. WebRTC-avsnittet är kritiskt: om du ser en "lokal IP"-adress i intervallet 192.168.x.x eller 10.x.x.x exponerad bredvid en "offentlig IP" som matchar din VPN-slutpunkt, gör din VPN sitt jobb men din webbläsare läcker via WebRTC. IPv6-avsnittet fångar IPv6-återfallsläckage som dnsleaktest ibland missar.

Hur ett rent resultat ser ut jämfört med ett läckande

På dnsleaktest.coms utökade test med en korrekt konfigurerad VPN bör du se något i stil med detta:

Test results (clean): Server: 1.2.3.4 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands Server: 1.2.3.5 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands Conclusion: No DNS leak detected. All queries went to the VPN's resolver.

Och så här ser ett läckage ut:

Test results (leaking): Server: 1.2.3.4 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands Server: 75.75.75.75 Hostname: cdns01.comcast.net ISP: Comcast Country: United States Server: 75.75.76.76 Hostname: cdns02.comcast.net ISP: Comcast Country: United States Conclusion: DNS leak detected. ISP resolver (Comcast) received queries.

Den viktigaste signalen är ISP-kolumnen. Om något annat än din VPN-leverantör (eller en medvetet vald offentlig resolver) visas, läcker din DNS. Om landskolumnen visar ditt riktiga land bredvid VPN-utreselandet läcker du. Om bara VPN-slutpunktens land visas är du ren.

Läckagetyper jämförda

Var och en av de fyra läckagetyperna har ett distinkt fingeravtryck i testresultaten, en distinkt uppsättning observatörer som kan utnyttja det, och en distinkt lösning:

Åtgärda de fyra vanliga orsakerna

Åtgärda OS-kringgående läckage (Windows)

På Windows 10 och 11 inaktiverar du Smart Multi-Homed Name Resolution antingen via Grupprincip (Datorkonfiguration → Administrativa mallar → Nätverk → DNS-klient → "Stäng av smart multi-homed name resolution" → Aktiverad) eller via PowerShell: Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name "DisableParallelAandAAAA" -Value 1. Starta om. Vissa välunderhållna VPN-klienter gör detta automatiskt vid anslutning — om din inte gör det, gör det manuellt.

Åtgärda läckage i delade tunnlar

Granska din regeluppsättning för delad tunnel. För varje app som ska vara skyddad, verifiera att både dess TCP-trafik och dess DNS-förfrågningar dirigeras genom tunneln. Vissa VPN-klienter låter dig konfigurera per-app DNS; de flesta gör det inte. Om din inte gör det, är det säkrare standardalternativet att inaktivera delade tunnlar helt och använda en full tunnel — som dirigerar allt (inklusive all DNS) genom VPN:n. För de flesta användare är bekvämlighetsvinsten med delade tunnlar inte värd läckagerisken.

Åtgärda IPv6-läckage

Den mest tillförlitliga lösningen är att använda en VPN-klient som stöder IPv6 inuti tunneln (eller åtminstone installerar matchande IPv6-brandväggsregler som blockerar IPv6-trafik när tunneln är aktiv). Om du inte kan byta klient, inaktivera IPv6 på det fysiska nätverksgränssnittet: på Windows i adapteregenskaperna; på macOS i Systeminställningar → Nätverk → Avancerat → TCP/IP. Detta är drastiskt (du förlorar IPv6-anslutning helt) men det eliminerar läcksvektorn.

Åtgärda WebRTC-läckage

I Firefox sätter du media.peerconnection.enabled till false i about:config. I Chrome och Edge installerar du ett tillägg som WebRTC Network Limiter eller uBlock Origins WebRTC-blockeringsalternativ. Safari hanterar WebRTC mer konservativt som standard men du kan fortfarande läcka lokala IP:er i vissa konfigurationer; Safari 17+ förbättrade detta avsevärt. Testa efter ändringen med ipleak.net.

Varför "använd en VPN" ensamt inte garanterar inga läckage

Det finns ett vanligt antagande att anslutning till en VPN automatiskt förhindrar DNS-läckage. Det gör det inte — förebyggandet beror på att VPN-klienten gör en serie saker korrekt: ändrar systemets DNS-resolver, installerar brandväggsregler för att blockera direkt-till-ISP DNS, hanterar IPv6, inaktiverar Windows SMHNR (eller motsvarande OS-nivå kringgångsåtgärder) och överlever nätverksändringar (Wi-Fi-byte, sömn/vakna-cykler) utan att återintroducera läckaget.

En välbyggd VPN-klient gör allt detta automatiskt och du behöver aldrig tänka på det. En dåligt byggd — eller en "gratis" VPN som använder OS:ts inbyggda VPN-profil utan extra läckageskydd — gör ett delmängd av det och lämnar läckvektorer öppna. Det enda sättet att veta vilken kategori du befinner dig i är att faktiskt köra ett läckagetest efter anslutning. Om testet kommer tillbaka rent kan du sluta oroa dig; om det visar läckage har du specifika problem att åtgärda och du vet nu vilka de är.

DNS-läckageförebyggande på iOS, Android, Mac och Windows

iOS

iOS hanterar DNS via NetworkExtension-ramverket. En välbyggd VPN-app använder NEDNSSettings-objektet för att ange en anpassad resolver som används medan tunneln är aktiv. iOS tillämpar detta på OS-nivå — appar kan inte kringgå den konfigurerade DNS utan uttrycklig tillåtelse. Den viktigaste läckvektorn på iOS är iCloud Private Relay, som (när det är aktiverat tillsammans med en VPN) kan dirigera DNS via Apples resolver istället för VPN:ns. Om du använder en VPN för integritet, inaktivera iCloud Private Relay för att förhindra att de två konfliktar. iOS 14 lade till flaggan includeAllNetworks (ofta använd tillsammans med kill-switch-beteende) som säkerställer att även DNS på systemnivå går genom tunneln.

Android

Androids VpnService API låter VPN-klienten ange DNS-servrar som gäller för all tunnlad trafik. Systeminställningen "Always-on VPN" med "Block connections without VPN" aktiverad ger den starkaste garantin — ingen app kan lösa upp DNS utan att tunneln är aktiv. Android stöder också system-brett privat DNS (Inställningar → Nätverk och internet → Privat DNS), vilket tvingar all DNS att använda DNS-over-TLS till en vald leverantör. Att kombinera Always-on VPN med privat DNS ger dubbelt skydd mot DNS-läckage.

macOS

macOS använder scutil och System Configuration-ramverket för att hantera DNS-inställningar. En VPN-klient som körs via NetworkExtension-ramverket kan installera DNS-inställningar som tar företräde medan tunneln är aktiv. Den viktigaste läckvektorn på macOS är DNS-over-HTTPS på webbläsarnivå, som kringgår systemresolvern helt — inaktivera DoH på webbläsarnivå eller konfigurera den att peka på samma resolver som VPN:n. Testa med scutil --dns i Terminal för att se de aktiva resolvrarna; enbart VPN:ns resolver bör visas i det högst prioriterade avsnittet.

Windows

Windows har den största läckytan av alla stora operativsystem, främst på grund av Smart Multi-Homed Name Resolution. Utöver att inaktivera SMHNR (täckt ovan), kontrollera att VPN:ns virtuella adapter har högre metrikprioritet än din fysiska adapter, att IPv6 antingen är inaktiverat eller korrekt tunnlat, och att ingen app är konfigurerad med egna DNS-åsidosättanden. Windows 11 lade till förbättrat gränssnitt för DNS-inställningar men det underliggande beteendet liknar Windows 10. Kommandot ipconfig /all visar de aktiva resolvrarna per gränssnitt.

Vad bra VPN-appar gör under huven för att förhindra läckage

En välkonstruerad VPN-klient ber dig inte tänka på DNS-läckage. Den hanterar dem som en grundläggande del av anslutningsprocessen. Specifikt:

• Konfigurerar en anpassad resolver vid anslutning. Klienten talar om för OS:t "medan jag är ansluten går alla DNS-förfrågningar till denna specifika IP-adress" — vanligtvis VPN-leverantörens egen resolver, nåbar enbart genom tunneln. Klienten återställer också de tidigare DNS-inställningarna vid frånkoppling.
• Installerar brandväggsregler för att blockera direkt DNS. Även om någon app försöker fråga en DNS-server på egen hand (t.ex. en hårdkodad förfrågan till 8.8.8.8), blockerar brandväggsregeln det utgående paketet på UDP port 53. Den enda DNS som kan lämna enheten är det som flödar genom tunneln.
• Använder krypterad DNS (DoT eller DoH) inuti tunneln. Även efter att förfrågan är inuti tunneln krypteras resolver-till-server-hoppet med DNS-over-TLS (RFC 7858) eller DNS-over-HTTPS så att den uppströms operatören inte kan se förfrågningens innehåll. Vår genomgång av DNS-over-HTTPS vs DNS-over-TLS täcker avvägningarna mellan de två protokollen.
• Hanterar IPv6 explicit. IPv6-rutter är antingen tunnlade genom VPN:n (att föredra) eller blockerade vid brandväggen för att förhindra IPv6-återfall. Klienten lämnar aldrig IPv6-routning okonfigurerad.
• Paras med en kill switch. Om tunneln tillfälligt tappar anslutningen blockerar kill switch all trafik — inklusive DNS — tills tunneln återupprättas. Detta förhindrar kapplöpningstillståndet "tunneln tappades, DNS läckte, tunneln kom tillbaka". Vi täcker detta i detalj i vad är en VPN kill switch.
• Testar vid varje anslutning. Vissa klienter kör ett inbyggt läckagetest efter varje anslutning och flaggar eventuella avvikelser för användaren. Detta är ovanligt men det är den starkast möjliga modellen.

Casper's Cloak använder en anpassad DNS-resolver nåbar enbart inuti WireGuard-tunneln, krypterad från slut till ände via DNS-over-TLS, med IPv6-rutter explicit tunnlade och Windows SMHNR inaktiverat vid installation. Hotskyddsfunktionen utför DNS-nivåfiltrering mot kända skadliga domäner vid samma resolver, så samma DNS som är skyddad mot läckage blockerar också aktivt nätfiske och skadlig programvara. Mekanismen dokumenteras i vår genomgång av hur DNS-nivåfiltrering faktiskt fungerar. Den samlade effekten: korrekt konfigurerat som standard, inga läckage under något av de fyra vanliga felscenariona, och aktiv filtrering utöver det.

För bakgrundsinformation om det underliggande protokollet dokumenteras IETF-specifikationen för DNS-over-TLS i RFC 7858, som täcker de kryptografiska och transportlagskraven för att skicka DNS över en TLS-säkrad kanal. Samma ramverk är vad integritetscentrerade offentliga resolvrar (Cloudflare, Quad9, NextDNS) använder för sina säkra DNS-slutpunkter.

Sammanfattningsvis: ett DNS-läckage är det vanligaste sättet en VPN:s integritetslöfte tyst misslyckas. Det är lätt att testa för, oftast lätt att åtgärda, och alla VPN du litar på bör klara ett läckagetest utan manuell åtgärd. Om din VPN inte gör det är det ett varningstecken — antingen felkonfigurerad eller dags att byta.