느린 DNS 조회 해결 방법 — Chrome, Windows, Mac에서 DNS 속도 개선하기

DNS 조회 시간이란 무엇이며 왜 중요한가요?
DNS 조회 시간은 기기가 도메인 이름(예: example.com)을 IP 주소(예: 93.184.216.34)로 변환하는 데 걸리는 밀리초 수입니다. 이 조회는 데이터 전송 전에 수행되므로, DNS가 해석될 때까지 브라우저는 단 1바이트도 전송할 수 없습니다.
일반적인 DNS 조회는 DNS 서버, 네트워크 상태, 결과가 캐시되어 있는지에 따라 20~120ms가 소요됩니다. DNS가 느리면 모든 웹사이트, 모든 API 호출, 브라우저가 로드하는 모든 리소스에 지연이 발생합니다. 50개의 외부 리소스를 로드하는 페이지에서는 DNS 오버헤드만으로 총 1~5초가 추가될 수 있습니다.
Google의 연구에 따르면 페이지 로드 시간이 1초에서 3초로 증가하면 이탈 확률이 32%로 상승합니다. 5초에 달하면 90%까지 급증합니다. 느린 DNS는 이러한 문제를 일으키는 숨겨진 병목 현상인 경우가 많습니다.
DNS 조회가 느려지는 원인
근본 원인을 이해하면 올바른 해결책을 선택할 수 있습니다. 기기나 네트워크에서 DNS 조회가 느려지는 가장 일반적인 원인을 살펴보겠습니다.
느린 ISP DNS 서버 — 대부분의 ISP는 과부하된 DNS 리졸버를 운영하며, 쿼리당 80~200ms가 소요됩니다. 이것이 가정 사용자의 느린 DNS의 가장 큰 원인입니다.
오래되거나 손상된 DNS 캐시 — OS나 브라우저가 이전 항목을 캐시하고 있어, 즉각적인 캐시 히트 대신 반복적으로 느린 조회를 강제합니다.
지리적 거리 — DNS 서버가 다른 대륙에 있으면 모든 쿼리가 수천 킬로미터를 왕복해야 하며, 50~200ms의 지연이 추가됩니다.
CNAME 체인 — 각 CNAME 리디렉션은 추가 DNS 조회를 발생시킵니다. 3개의 CNAME 체인은 최종 IP에 도달하기까지 3회의 순차적 조회가 필요합니다.
낮은 TTL 값 — 60초와 같은 짧은 TTL(Time-to-Live) 값은 캐시된 결과를 사용하는 대신 기기가 끊임없이 DNS를 재쿼리하도록 강제합니다.
VPN 또는 프록시 간섭 — VPN은 DNS 쿼리를 자체 서버를 통해 라우팅하며, 이 서버가 일반 DNS보다 느리거나 멀리 있을 수 있습니다.
네트워크 혼잡 — 네트워크 트래픽이 많거나 라우터가 과부하되면 DNS 패킷 손실과 재전송이 발생하여 몇 초의 지연이 추가됩니다.
IPv6 폴백 문제 — 일부 네트워크는 먼저 IPv6 DNS를 시도하고 실패하면 IPv4로 폴백하여 모든 요청의 조회 시간이 2배로 늘어납니다.
현재 DNS 조회 시간을 측정하는 방법
수정하기 전에 현재 DNS 속도를 측정하여 수정 후와 비교할 수 있도록 합시다. DNS 조회 시간을 확인하는 세 가지 간단한 방법을 소개합니다.
방법 1: dig 사용 (Mac/Linux)
dig 명령어는 DNS 쿼리 시간을 밀리초 단위로 정확하게 표시합니다:
# Query your current DNS server
dig google.com
# Look for "Query time" at the bottom:
# ;; Query time: 24 msec
# Test a specific DNS server
dig @1.1.1.1 google.com
dig @8.8.8.8 google.com
dig @9.9.9.9 google.com방법 2: nslookup 사용 (Windows)
Windows의 nslookup은 기본적으로 쿼리 시간을 표시하지 않지만, PowerShell을 사용하면 측정할 수 있습니다:
# Measure DNS lookup time in PowerShell
Measure-Command { Resolve-DnsName google.com } | Select-Object TotalMilliseconds
# Test with a specific DNS server
Measure-Command { Resolve-DnsName google.com -Server 1.1.1.1 } | Select-Object TotalMilliseconds방법 3: Chrome DevTools 사용
Chrome은 모든 네트워크 요청에 대해 DNS 조회 시간을 표시합니다:
아무 웹사이트나 열고 → F12를 눌러 DevTools를 열고 → Network 탭으로 이동 → 아무 요청이나 클릭 → Timing 섹션을 확인합니다. DNS Lookup 행에 해당 도메인의 DNS 해석에 걸린 정확한 시간이 표시됩니다.
DNS 조회 시간이 지속적으로 100ms를 초과한다면 DNS 서버가 느린 것입니다. 아래 해결 방법이 도움이 될 것입니다.
해결법 1: 더 빠른 DNS 서버로 전환하기
이것은 가장 효과적인 해결법입니다. ISP DNS 서버는 보통 80~200ms로 응답하지만, Cloudflare나 Google 같은 공용 DNS 서버는 8~20ms로 응답합니다. 이는 모든 DNS 쿼리에 대한 10배의 속도 향상입니다.
각 플랫폼에서 DNS 서버를 변경하는 방법은 다음과 같습니다:
Windows 10/11에서 DNS 변경하기
설정 열기 → 네트워크 및 인터넷 → 고급 네트워크 설정
활성 연결 클릭 (Wi-Fi 또는 이더넷) → 하드웨어 속성
DNS 서버 할당 옆의 편집 클릭
자동에서 수동으로 전환 → IPv4 활성화
기본 설정 DNS를 `1.1.1.1`로 설정, 대체 DNS를
1.0.0.1로 설정저장을 클릭하고
dig또는 PowerShell로 테스트
macOS에서 DNS 변경하기
시스템 설정 열기 → 네트워크 → Wi-Fi (또는 활성 연결)
연결된 네트워크 옆의 세부 사항 클릭
사이드바에서 DNS 클릭
기존 항목 제거 후
1.1.1.1과1.0.0.1추가확인 클릭 후 적용
Linux에서 DNS 변경하기
systemd-resolved를 사용하는 대부분의 Linux 배포판에서:
# Edit the resolved config
sudo nano /etc/systemd/resolved.conf
# Add or modify these lines:
[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4
# Restart the service
sudo systemctl restart systemd-resolved
# Verify the change
resolvectl status해결법 2: DNS 캐시 플러시하기
오래되거나 손상된 DNS 캐시는 기기가 이전 항목을 사용하거나 실패 후 재시도하는 새 조회를 수행하도록 강제합니다. 캐시를 플러시하면 저장된 모든 DNS 항목이 지워지고 DNS 서버에 대한 새로운 쿼리가 강제됩니다.
운영 체제에 맞는 명령어를 실행하세요:
# Windows (Command Prompt as Administrator)
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux (systemd-resolved)
sudo resolvectl flush-caches
# Verify cache is empty (Windows)
ipconfig /displaydns해결법 3: 브라우저에서 DNS 프리페치 활성화하기
DNS 프리페치는 링크를 클릭하기 전에 브라우저가 도메인 이름을 미리 해석하도록 지시합니다. 링크 위에 마우스를 올리거나 페이지가 로드될 때 브라우저가 백그라운드에서 링크된 도메인의 DNS를 사전 해석합니다. 클릭할 때쯤이면 DNS가 이미 해석되어 있어 대기 시간이 없습니다.
대부분의 최신 브라우저는 DNS 프리페치가 기본적으로 활성화되어 있지만, 비활성화될 수 있습니다. 확인 및 활성화 방법을 알아보겠습니다.
Chrome DNS 프리페치 설정
Chrome에서 DNS 프리페치는 프리로드 기능의 일부입니다:
Chrome 열기 → 설정 → 개인정보 보호 및 보안 → 페이지 미리 로드
활성화 "더 빠른 탐색 및 검색을 위해 페이지 미리 로드"
이를 통해 방문 가능성이 높은 링크에 대해 DNS 프리페치, TCP 사전 연결, 페이지 사전 렌더링이 활성화됩니다
Firefox DNS 프리페치 설정
Firefox는 DNS 프리페치를 지원하지만 실수로 비활성화될 수 있습니다:
주소창에
about:config을 입력하고 Enter를 누릅니다검색란에
network.dns.disablePrefetch를 입력합니다`false`로 설정되어 있는지 확인합니다 (false = 프리페치가 켜져 있음)
추가로 확인
network.dns.disablePrefetchFromHTTPS— HTTPS 사이트에도false로 설정
해결법 4: Chrome 내부 DNS 캐시 지우기
Chrome은 운영 체제의 DNS 캐시와 별도로 자체 DNS 캐시를 유지합니다. OS의 DNS 캐시를 플러시한 후에도 Chrome은 내부 캐시의 오래된 항목을 계속 사용할 수 있습니다.
Chrome의 DNS 캐시를 지우려면:
Chrome을 열고 주소창에
chrome://net-internals/#dns를 입력합니다"Clear host cache" 클릭으로 Chrome의 내부 DNS 항목을 플러시합니다
추가로
chrome://net-internals/#sockets를 방문하여 "Flush socket pools"를 클릭해 잔여 연결을 닫습니다Chrome을 재시작하여 완전히 새로운 DNS 상태로 만듭니다
해결법 5: 공유기에서 DNS 설정하기
공유기에서 DNS를 변경하면 네트워크의 모든 기기(스마트폰, 태블릿, 스마트 TV, 게임 콘솔)에 빠른 DNS 서버가 적용됩니다. 각 기기를 개별적으로 설정할 필요가 없습니다.
대부분의 공유기에서 DNS를 변경하는 방법:
브라우저를 열고
192.168.1.1또는192.168.0.1(공유기 관리 페이지)로 이동합니다공유기 관리자 자격 증명으로 로그인합니다 (변경하지 않았다면 공유기 본체의 스티커를 확인하세요)
DNS 설정을 찾습니다 — 보통 WAN 설정, 인터넷 설정 또는 DHCP 설정 아래에 있습니다
기본 DNS를 `1.1.1.1`로, 보조 DNS를
1.0.0.1로 변경합니다저장하고 공유기를 재부팅하여 변경 사항을 적용합니다
해결법 6: CNAME 체인 줄이기 (웹사이트 소유자용)
CNAME 체인을 줄이려면 CNAME 플래트닝(ALIAS 레코드라고도 함)을 사용하세요. 이는 DNS 서버 수준에서 CNAME 체인을 해석하고 최종 IP 주소를 직접 반환합니다. Cloudflare, AWS Route 53, DNSimple 모두 CNAME 플래트닝을 지원합니다.
DNS Robot의 DNS 조회 도구를 사용하여 CNAME 체인을 확인할 수 있습니다. 도메인을 입력하고 CNAME 레코드를 확인하여 체인이 존재하는지 살펴보세요.
www.example.com → CNAME → example.com.cdn.cloudflare.net
→ CNAME → cdn-123.cloudflare.net
→ A → 104.21.55.123
# That is 3 DNS lookups instead of 1!
# Each adds 20-80ms of latency.해결법 7: TTL 값 늘리기 (웹사이트 소유자용)
TTL(Time to Live)은 DNS 리졸버가 도메인 레코드를 캐시하는 시간을 제어합니다. 60초와 같은 낮은 TTL은 모든 리졸버가 매분 권한 DNS 서버에 다시 쿼리해야 함을 의미합니다. 3600초(1시간)와 같은 높은 TTL은 결과가 1시간 동안 캐시되어 즉시 제공됩니다.
그 영향은 상당합니다. TTL을 60초에서 3600초로 늘리면 피크 시간대에 권한 서버에 대한 DNS 조회를 98%까지 줄일 수 있습니다.
| TTL 값 | 캐시 기간 | 적합한 용도 |
|---|---|---|
| 60 | 1분 | 자주 변경되는 레코드 (장애 조치, 부하 분산) |
| 300 | 5분 | 가끔 변경되는 레코드 |
| 3600 | 1시간 | 안정적인 레코드 (권장 기본값) |
| 86400 | 24시간 | 거의 변경되지 않는 레코드 (MX, TXT) |
DNS 서버 속도 비교 (2026년 벤치마크)
Cloudflare(1.1.1.1)는 전 세계에서 가장 빠른 공용 DNS 리졸버로 꾸준히 1위를 차지하고 있습니다. Google Public DNS가 근소한 차이로 2위입니다. 두 서비스 모두 암호화된 쿼리를 위한 DNS over HTTPS(DoH)와 DNS over TLS(DoT)를 지원합니다.
Windows에서는 GRC DNS Benchmark 도구를 사용하여 위치별로 DNS 서버를 벤치마크할 수 있습니다. Mac/Linux에서는 dig @1.1.1.1 google.com과 dig @8.8.8.8 google.com을 실행하여 응답 시간을 비교할 수 있습니다.
| DNS 제공업체 | 기본 IP | 보조 IP | 평균 응답 시간 | 개인정보 보호 | 보안 기능 |
|---|---|---|---|---|---|
| Cloudflare | 1.1.1.1 | 1.0.0.1 | ~11ms | IP 로깅 없음 | DNSSEC, DoH, DoT |
| Google Public DNS | 8.8.8.8 | 8.8.4.4 | ~14ms | 48시간 후 로그 익명화 | DNSSEC, DoH, DoT |
| Quad9 | 9.9.9.9 | 149.112.112.112 | ~20ms | IP 로깅 없음 | DNSSEC, 멀웨어 차단 |
| OpenDNS | 208.67.222.222 | 208.67.220.220 | ~23ms | 필터링용 로깅 | 콘텐츠 필터링, DNSSEC |
| 일반 ISP DNS | 환경에 따라 다름 | 환경에 따라 다름 | ~80-200ms | 환경에 따라 다름 | 기본 기능만 |
DNS가 빨라졌는지 확인하는 방법
DNS 조회 시간이 80~200ms(ISP DNS)에서 10~20ms(Cloudflare/Google)로 줄어들어야 합니다. DNS Robot의 Ping 도구를 사용하여 DNS 서버의 지연 시간을 직접 측정할 수도 있습니다. 1.1.1.1에 ping을 보내고 이전 ISP DNS 서버 IP와 비교해 보세요.
# Mac/Linux: Compare before and after
dig google.com # Should show lower query time
dig amazon.com # Test multiple domains
dig github.com
# Windows PowerShell
Measure-Command { Resolve-DnsName google.com } | Select-Object TotalMilliseconds
# Check Chrome DevTools
# Open any page → F12 → Network tab → look at DNS Lookup timing지금 DNS 속도를 확인하세요
DNS Robot의 무료 DNS 조회 도구를 사용하여 전 세계 여러 서버에서 DNS 해석 시간을 측정하세요. DNS가 전 세계에서 얼마나 빠르게 해석되는지 확인할 수 있습니다.
Try DNS 조회Frequently Asked Questions
50ms 이하가 양호, 20ms 이하가 우수합니다. 100ms를 초과하면 느린 것이며 브라우징 속도에 눈에 띄는 영향을 줍니다. dns 서버 추천 1순위인 Cloudflare(1.1.1.1) 같은 공용 DNS 서버는 보통 10~15ms로 응답합니다.