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

DNS 조회 시간이란 무엇이며 왜 중요한가요?

DNS 조회 시간은 기기가 도메인 이름(예: example.com)을 IP 주소로 바꾸는 데 걸리는 시간입니다. 이 과정이 끝나기 전에는 연결도, TLS도, 다운로드도 시작할 수 없습니다.

캐시된 답은 공유기 캐시에서는 몇 밀리초, 가까운 공개 리졸버에서는 대략 10~30 ms 안에 옵니다. 리졸버가 한 번도 본 적 없는 이름은 해당 도메인의 네임서버에 직접 물어봐야 해서 수십 밀리초 이상 걸립니다. 여러 도메인에서 파일을 가져오는 페이지는 새 도메인마다 이 시간을 치르게 됩니다.

DNS 조회가 느려지는 원인

기기나 네트워크에서 DNS 조회가 느려지는 흔한 원인은 다음과 같습니다.

• 느리거나 과부하된 리졸버 — ISP나 공유기의 DNS 서버가 답하는 데 오래 걸립니다. 캐시에 없는 이름에서 특히 두드러집니다. (아예 답이 없다면 DNS 서버가 응답하지 않을 때를 참고하세요.)
• 거리 — 네트워크상 멀리 있는 리졸버는 조회할 때마다 왕복 시간이 더해집니다.
• 캐시된 답이 없는 리졸버 — 근처에서 최근에 아무도 조회하지 않은 이름은 해당 도메인의 네임서버에서 직접 가져와야 합니다.
• 긴 CNAME 체인(사이트 운영자) — 리졸버가 따라가야 하는 별칭이 하나 늘 때마다 조회가 한 번 더 필요할 수 있습니다.
• 아주 짧은 TTL(사이트 운영자) — 답이 금방 만료되어 리졸버가 도메인 서버에 더 자주 물어봅니다.
• VPN 또는 프록시 — 조회를 나와 먼 리졸버로 보낼 수 있습니다.
• Wi-Fi나 혼잡한 공유기의 패킷 손실 — 유실된 DNS 패킷은 재시도를 기다려야 해서 1초 이상 지연될 수 있습니다.

현재 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)

nslookup은 쿼리 시간을 보여 주지 않지만, PowerShell로 근삿값을 얻을 수 있습니다. -Server와 -Type A를 붙여 몇 번 실행한 뒤 중앙값을 비교하세요.

# Approximate lookup time in PowerShell (times the whole command)
Measure-Command { Resolve-DnsName example.com -Type A } | Select-Object TotalMilliseconds

# Against a specific DNS server (skips Windows' own cache)
Measure-Command { Resolve-DnsName example.com -Type A -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 서버로 전환하기

측정해 보니 지금 리졸버가 느리다면, 서버를 바꾸는 것이 가장 큰 개선입니다. 전 세계 평균이 가장 좋은 서버가 아니라 내 회선에서 가장 빠른 서버를 고르세요. 플랫폼별 변경 방법은 다음과 같습니다.

Windows에서 DNS 변경하기

• 설정 열기 → 네트워크 및 인터넷 → Wi-Fi → 알려진 네트워크 관리 → 사용 중인 네트워크(유선은 이더넷 → 사용 중인 네트워크)
• DNS 서버 할당 옆의 편집을 클릭하고 수동으로 전환
• IPv4에서 기본 설정 DNS를 1.1.1.1, 대체 DNS를 1.0.0.1로 설정. IPv6에서는 2606:4700:4700::1111과 2606:4700:4700::1001
• 저장을 클릭하고 dig나 PowerShell로 다시 측정
• Windows 10의 설정에는 DNS 전용 항목이 없습니다. Win + R을 눌러 ncpa.cpl을 실행하고, 어댑터를 마우스 오른쪽 버튼으로 클릭 → 속성 → 인터넷 프로토콜 버전 4(TCP/IPv4) → 속성 → 다음 DNS 서버 주소 사용 순서로 엽니다

macOS에서 DNS 변경하기

• 시스템 설정 열기 → 네트워크 → Wi-Fi(또는 사용 중인 연결)
• 연결된 네트워크 옆의 세부사항 클릭
• 사이드바에서 DNS 클릭
• 기존 항목을 삭제하고 1.1.1.1과 1.0.0.1 추가(IPv6를 쓴다면 2606:4700:4700::1111도)
• 확인 클릭

Linux에서 DNS 변경하기

systemd-resolved를 쓰는 배포판(예: Ubuntu와 Fedora 데스크톱)에서는 NetworkManager에서 연결별로 DNS를 설정하거나, resolvectl로 다음 재연결 때까지만 설정합니다. /etc/systemd/resolved.conf에 DNS=를 추가하는 것만으로는 부족합니다. 그 서버는 네트워크가 내려 주는 서버와 함께 조회되기 때문입니다.

# NetworkManager: replace "Home Wi-Fi" with your connection name (nmcli con show)
nmcli con mod "Home Wi-Fi" ipv4.dns "1.1.1.1 1.0.0.1" ipv4.ignore-auto-dns yes \
  ipv6.dns "2606:4700:4700::1111 2606:4700:4700::1001" ipv6.ignore-auto-dns yes
nmcli con up "Home Wi-Fi"

# systemd-resolved, until the next reconnect (replace wlan0 with your interface)
sudo resolvectl dns wlan0 1.1.1.1 1.0.0.1
resolvectl status wlan0

해결법 2: DNS 캐시 플러시하기

캐시된 실패나 오래된 답은 만료될 때까지 계속 지연을 만듭니다. 플러시하면 저장된 답이 모두 지워지고 다음 조회가 새로 나갑니다(자세한 방법: DNS 플러시 방법).

운영체제에 맞는 명령을 실행하세요.

# Windows (Command Prompt)
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 프리페치 활성화하기

브라우저는 필요해지기 전에 이름을 미리 조회할 수 있습니다. Firefox는 페이지가 링크한 도메인을 확인하고, Chrome은 페이지 미리 로드가 켜져 있으면 다음에 열 만한 페이지를 확인하고 연결까지 해 둡니다. 사이트도 쓸 도메인에 dns-prefetch 힌트를 달 수 있습니다. Chrome은 더 이상 모든 링크의 도메인을 스스로 미리 조회하지 않으며, 일반 http: 페이지에서만 자동으로 그렇게 합니다.

이 설정들은 기본적으로 켜져 있지만 꺼져 있을 수도 있습니다. 확인하는 방법은 다음과 같습니다.

Chrome DNS 프리페치 설정

Chrome에서 DNS 프리페치는 페이지 미리 로드에 포함되어 있습니다.

• Chrome 열기 → 설정 → 성능 → 페이지 미리 로드
• 켜기(표준 미리 로드가 기본값입니다)
• 다음에 열 만한 페이지를 Chrome이 미리 확인하고, 연결하고, 때로는 미리 불러옵니다

Firefox DNS 프리페치 설정

Firefox는 DNS 프리페치를 지원하지만 실수로 비활성화될 수 있습니다:

• 주소 표시줄에 about:config를 입력하고 Enter 키 누르기
• 검색: network.dns.disablePrefetch
• false인지 확인(false = 프리페치 켜짐, 기본값)
• 함께 확인: network.dns.disablePrefetchFromHTTPS가 false(기본값)이면 HTTPS 페이지에서도 프리페치합니다

해결 4: Chrome 자체 DNS 캐시 삭제하기(오래된 답이 남았을 때만)

Chrome은 운영체제와 별개로 자체 DNS 캐시를 갖고 있습니다. 이 캐시가 조회를 느리게 하지는 않으며, 지워도 속도가 오래 달라지지는 않습니다. 다만 특정 사이트에 대해 Chrome이 오래되었거나 실패한 답을 들고 있다면, 시스템 캐시만 플러시해서는 그 사이트가 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입니다. 공유기 로그인 가이드에 80개 이상의 공유기와 통신사별 주소와 기본 비밀번호가 정리되어 있습니다
• 로그인: 공유기 관리자 계정을 사용합니다(바꾼 적이 없다면 공유기 뒷면 스티커를 확인하세요)
• DNS 설정 찾기 — 보통 WAN 설정, 인터넷 설정 또는 DHCP 설정에 있습니다
• 기본 DNS를 1.1.1.1, 보조 DNS를 1.0.0.1로 변경
• 저장 후 공유기를 재부팅해 변경 사항 적용

해결법 6: CNAME 체인 줄이기 (웹사이트 소유자용)

이 해결 방법은 웹사이트 운영자와 개발자를 위한 것입니다. 별칭(CNAME)은 캐시에 없을 때마다 조회를 한 번씩 늘릴 수 있습니다. 리졸버는 실제 IP 주소가 있는 A 또는 AAAA 레코드에 닿을 때까지 체인을 따라가야 합니다.

전형적인 CNAME 체인은 다음과 같습니다.

www.example.com   CNAME  example.com.cdn.example.net
example.com.cdn.example.net  CNAME  edge-123.cdn.example.net
edge-123.cdn.example.net     A      203.0.113.10

# Each alias may need its own lookup when it isn't cached,
# especially when the names sit on different DNS providers.

도메인 최상위의 체인을 줄이려면 CNAME 플래트닝(ALIAS 레코드라고도 함)을 사용하세요. DNS 제공업체가 체인을 직접 따라가 최종 IP 주소를 돌려주는 방식입니다. Cloudflare(CNAME 플래트닝)와 DNSimple(ALIAS)은 어떤 대상에든 이를 지원합니다. Route 53의 별칭 레코드는 AWS 리소스와 같은 호스팅 영역 안의 레코드에만 쓸 수 있습니다.

CNAME Lookup은 어떤 이름이든 체인 전체를 따라가며 각 홉을 보여 줍니다.

해결법 7: TTL 값 늘리기 (웹사이트 소유자용)

TTL(Time to Live)은 DNS 리졸버가 도메인의 레코드를 얼마나 오래 캐시할지 정합니다. TTL이 60초이면 리졸버는 누군가 그 이름을 물어볼 때만, 최대 1분에 한 번 네임서버에 문의합니다. 3600초(1시간)이면 캐시된 답을 1시간 동안 돌려줍니다.

TTL이 길수록 리졸버가 답을 오래 보관해 네임서버에 덜 자주 묻습니다. 대신 변경 사항이 모두에게 닿는 데 시간이 더 걸립니다.

주요 공개 DNS 서버 비교

주요 공개 리졸버의 DNSPerf 전 세계 평균(2026년 10월 4일 확인)과, 각 업체가 로그에 대해 밝힌 내용입니다. 실제 결과는 환경마다 다르니 직접 측정하세요.

전체 주소 목록과 설정 방법: Cloudflare DNS 서버 가이드와 Google DNS 서버 가이드.

내 위치에서 어느 쪽이 가장 빠른지는 DNS Robot의 DNS 속도 테스트를 브라우저에서 실행해 확인하세요. dig @1.1.1.1 example.com과 dig @8.8.8.8 example.com을 몇 번씩 실행해 비교해도 됩니다.

DNS가 빨라졌는지 확인하는 방법

위의 해결법을 적용한 후 DNS 속도를 다시 측정하여 개선 여부를 확인하세요.

# 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

새 수치를 처음 측정값과 비교하세요. 거의 달라지지 않았다면 예전 리졸버는 원인이 아니었던 것입니다. Wi-Fi 패킷 손실, VPN, 또는 사이트 자체를 살펴보세요.