사이트 간헐적 접속 안됨 | 됐다 안됐다 반복되는 원인과 8.8.8.8 DNS의 원리까지

결론부터 말하면, 됐다 안 됐다 하는 간헐적 접속 장애는 십중팔구 DNS, 브라우저 캐시, 또는 서버 커넥션 중 하나에서 나온다. 그래서 원인을 따지기 전에 먼저 시도할 응급 조치가 있다. 아래 다섯 가지를 순서대로 해보면 대부분의 증상은 5분 안에 잡힌다.

첫째, 명령 프롬프트를 관리자 권한으로 열고 ipconfig /flushdns를 실행해 PC에 쌓인 옛 DNS 기록을 비운다. 둘째, DNS 서버를 통신사 기본값에서 구글의 8.8.8.8과 8.8.4.4로 바꾼다. 셋째, 브라우저 캐시와 쿠키를 삭제하고 브라우저를 완전히 껐다 켠다. 넷째, 시크릿 모드나 다른 브라우저로 같은 주소에 접속해본다. 다섯째, 휴대폰 와이파이를 끄고 모바일 데이터로 접속해본다. 이 다섯 단계는 단순한 임시방편이 아니라, 각 단계가 동시에 진단 도구이기도 하다. 어느 단계에서 증상이 사라지는지가 곧 범인을 가리키기 때문이다.

예를 들어 모바일 데이터에서는 멀쩡히 열리는데 집 와이파이에서만 안 된다면, 사이트가 아니라 내 통신 경로나 DNS가 범인이다. 시크릿 모드에서 정상이면 브라우저에 쌓인 캐시·쿠키·확장 프로그램이 문제다. 직접 운영하는 사이트의 데이터베이스가 방금은 됐다가 잠시 뒤 거부된다면, 이건 클라이언트가 아니라 서버 쪽 커넥션 관리의 신호다.

이 문서는 그 응급 조치가 왜 효과가 있는지를 계층별로 파고든다. 특히 거의 모든 DNS 해결책에 등장하는 8.8.8.8이라는 주소가 대체 무엇이고, 구글은 어떻게 이 외우기 쉬운 번호를 손에 넣었으며, 왜 통신사 DNS가 못 찾는 사이트를 이 주소는 곧잘 찾아내는지 그 작동 원리까지 끝까지 설명한다. 단순히 따라 하는 수준을 넘어, 다음에 비슷한 장애를 만났을 때 스스로 진단할 수 있는 안목을 남기는 것이 목표다.

1. 간헐적 장애가 유독 까다로운 이유

완전히 죽은 사이트는 오히려 진단이 쉽다. 항상 안 되니 원인이 한정된다. 반면 됐다 안 됐다 하는 증상은 접속 사슬을 이루는 여러 계층 중 하나가 불안정하다는 뜻이고, 그 불안정한 계층이 어디인지 가만히 있으면 드러나지 않는다.

웹사이트 하나에 접속하는 과정은 생각보다 길다. 내 PC가 사이트 이름을 IP로 바꾸기 위해 DNS에 묻고(DNS 단계), 그 응답을 받아 통신사 회선과 공유기를 거쳐(네트워크 단계), 목적지 서버와 암호화 연결을 맺고(HTTPS 단계), 서버는 다시 내부 데이터베이스에서 데이터를 꺼내(서버 단계) 응답을 돌려준다. 이 네 단계 중 어느 하나만 간헐적으로 흔들려도 사용자 눈에는 똑같이 됐다 안 됐다로 보인다.

그래서 간헐적 장애는 추측이 아니라 소거법으로 푼다. 한 계층씩 잘라내며 범위를 좁히는 것이 정석이고, 도입부의 다섯 가지 응급 조치가 바로 그 소거 도구다.

2. 1단계 의심: DNS의 불안정

DNS(Domain Name System)는 min-inter.co.kr 같은 사이트 이름을 실제 서버의 IP 주소로 바꿔주는 인터넷의 전화번호부다. 사람은 이름을 외우지만 컴퓨터는 숫자 주소로만 통신하므로, 이 변환이 없으면 어떤 사이트에도 닿을 수 없다. 그리고 간헐적 접속 장애의 가장 흔한 범인이 바로 이 변환 과정의 불안정이다.

2.1. DNS가 흔들리면 생기는 일

1. 캐시 만료 주기(TTL): 내 PC와 통신사 DNS는 한 번 조회한 결과를 일정 시간 저장해두고 재사용한다. 이 보관 시간을 TTL(Time To Live)이라 부른다. TTL이 만료되어 다시 조회할 때 응답이 늦거나 실패하면 멀쩡하던 사이트가 갑자기 안 열리고, 잠시 뒤 캐시가 새로 채워지면 다시 된다. 됐다 안 됐다의 가장 전형적인 모양이다.
2. 통신사 DNS의 부하와 오류: 기본값으로 쓰는 통신사 DNS 서버가 일시적으로 느려지거나, 일부 도메인에 대해 잘못되거나 불완전한 응답을 반환하면, 같은 사이트가 시점에 따라 다르게 동작한다. 통신사의 노후 서버나 불안정한 인프라가 원인이 되는 경우가 실제로 보고된다.
3. 여러 DNS 간 결과 불일치: 어떤 DNS는 최신 IP를, 다른 DNS는 옛 IP를 들고 있는 과도기에는 조회할 때마다 결과가 달라진다.

핵심 포인트: 모바일 데이터로는 되는데 집 와이파이로만 안 된다면, 사이트가 아니라 내 통신 경로나 DNS가 범인일 확률이 매우 높다. 이 한 가지 테스트로 책임 소재의 절반이 갈린다.

2.2. 공용 DNS로 바꾸면 왜 풀리는가

통신사 DNS가 못 찾는 사이트를 구글이나 클라우드플레어의 공용 DNS는 곧잘 찾아낸다. 이유는 단순하지 않고 몇 가지가 겹친다. 첫째, 공용 DNS는 전 세계에서 막대한 양의 질의를 처리하므로 방대한 캐시를 항상 데우고 있어 응답이 빠르고 누락이 적다. 둘째, 통신사 서버보다 자원이 넉넉해 부하로 인한 일시적 실패가 드물다. 셋째, 통신사 DNS가 특정 도메인에 엉뚱한 응답을 주던 문제 자체를 우회한다. 그래서 통신사 DNS를 구글 DNS로 바꾸는 것만으로 특정 사이트 접속 문제가 해결되는 경우가 많은 것이다.

3. 8.8.8.8이라는 주소의 정체

거의 모든 DNS 해결책에 8.8.8.8이 등장한다. 이 주소가 왜 이렇게 유명하고, 구글은 어떻게 이 번호를 차지했으며, 8.8.4.4와는 무엇이 다른지 제대로 짚어보자. 이 배경을 알면 단순히 외워 쓰는 것을 넘어 DNS의 작동 자체를 이해하게 된다.

3.1. 구글은 어떻게 이 번호를 선점했나

구글은 2009년 12월 Google Public DNS를 출시하면서 8.8.8.8을 대표 주소로 내세웠다. 핵심은 외우기 쉬운 번호를 의도적으로 골랐다는 점이다. 사실 8.0.0.0/8 대역, 즉 8로 시작하는 거대한 IP 블록은 통신 인프라 기업 레벨3(Level 3, 현 루멘)가 보유하고 있었다. 구글은 이 블록 중 8.8.8.0/24와 8.8.4.0/24라는 작은 구간을 임대·확보해 자사 DNS 서비스에 배정했다. 즉 8 대역 전체를 구글이 소유한 것이 아니라, 사람들이 기억하기 쉬운 8.8.8.8과 8.8.4.4라는 상징적인 번호만 골라 쓴 것이다. 결과적으로 이 주소는 전 세계에서 가장 유명한 IP 주소가 됐고, 오늘날 Google Public DNS는 세계 최대 규모의 공용 DNS 리졸버로 하루 수백억 건의 질의를 처리한다.

3.2. 8.8.8.8과 8.8.4.4의 차이

두 주소의 관계는 의외로 단순하다. 둘 다 같은 Google Public DNS 서비스로 연결되며 기능과 정책은 동일하다. 차이는 역할이다.

둘은 성능이 다른 등급의 서버가 아니라, 장애 대비용 이중화를 위한 한 쌍이다. 기본 주소인 8.8.8.8이 어떤 이유로 응답하지 못하면 운영체제가 자동으로 대체 주소인 8.8.4.4로 질의를 넘긴다. 그래서 둘을 함께 입력해두는 것이 권장된다. 한쪽만 넣어도 동작은 하지만, 대체 주소가 비어 있으면 기본이 실패할 때 받아줄 백업이 없다.

3.3. 하나의 IP로 전 세계를 받는 비결, 애니캐스트

여기서 자연스러운 의문이 생긴다. 8.8.8.8은 하나의 주소인데, 어떻게 한국에서도 미국에서도 호주에서도 빠르게 응답할까. 비밀은 애니캐스트(anycast)라는 라우팅 기법이다.

보통 하나의 IP는 하나의 서버를 가리킨다(유니캐스트). 그러나 애니캐스트에서는 같은 IP 주소(8.8.8.8)를 전 세계 수많은 데이터센터의 서버들이 동시에 광고한다. 사용자가 8.8.8.8에 질의를 보내면, 인터넷의 라우팅 체계가 그 사용자에게 네트워크적으로 가장 가까운 서버로 자동으로 안내한다. 한국 사용자는 한국이나 인근의 구글 노드로, 미국 사용자는 미국 노드로 향한다. 덕분에 같은 주소를 쓰면서도 지연이 짧고, 특정 지역의 한 노드가 죽어도 다른 노드가 같은 주소로 질의를 받아내므로 사실상 항상 살아 있는 주소처럼 동작한다.

이것이 구글 DNS가 빠르고 안정적인 핵심 이유 중 하나다. 다만 단일 애니캐스트 주소가 서로 다른 두 개의 독립 IP만큼의 완전한 이중화를 제공하지는 않기 때문에, 구글은 8.8.8.8과 8.8.4.4라는 별개 대역의 두 주소를 함께 제공해 한 단계 더 두꺼운 안전망을 만든다.

3.4. 보안과 무결성: DNSSEC와 DoH

구글 DNS를 권하는 이유는 속도만이 아니다. Google Public DNS는 DNSSEC 검증을 지원해, 응답에 서명이 있을 때 그 진위를 확인하고 위조된 응답(캐시 포이즈닝)을 걸러낸다. 또한 DNS over HTTPS(DoH)를 지원해, 어떤 사이트를 조회하는지 자체를 암호화한다. DoH를 쓰면 일반 DNS와 똑같은 8.8.8.8 주소를 그대로 쓰면서도 더 낮은 지연으로 암호화 조회를 받을 수 있고, 중간에서 누가 질의를 엿보거나 조작하기 어려워진다. 구글 DNS의 DoH 템플릿 주소는 https://dns.google/dns-query다.

핵심 포인트: 8.8.8.8과 8.8.4.4는 우열 관계가 아니라 기본·대체로 짝을 이루는 이중화 구성이다. 둘을 함께 입력하고, 보안까지 챙기려면 DoH를 켜서 조회를 암호화하는 것이 가장 견고한 설정이다.

4. 2단계 의심: 공유기와 통신사 경로 차단

DNS가 정상인데도 특정 사이트로 가는 길 자체가 간헐적으로 막힐 수 있다. 특히 보안 기능이 강한 공유기일수록 정상 트래픽을 위협으로 오인해 차단하는 일이 생긴다.

1. 공유기 방화벽·보안 필터: 일부 패킷을 위협으로 오탐해 끊었다가, 세션이 새로 열리면 다시 통과시키는 식으로 동작하면 접속이 들쭉날쭉해진다. 공유기 재부팅과 보안 설정 점검이 첫 조치다.
2. 경로상 패킷 손실: 통신사 백본의 일시적 혼잡이나 라우팅 변경으로 특정 목적지로 가는 패킷이 간헐적으로 유실되면, 같은 사이트가 시간대별로 다르게 열린다.
3. 차단 방식의 변화: 최근 한국에서는 해외 사이트 접근 차단이 인프라 업체 레벨에서 처리되는 방향으로 바뀌면서, 과거에 통하던 단순 DNS 변경 우회가 무력화된 사례도 보고된다. 본인 운영 도메인이 국내 정상 사이트라면 이 항목 해당은 적지만, 증상 구분을 위해 알아둘 가치가 있다.

5. 3단계 의심: HTTPS 보안 인증 오류

서버 자체는 살아 있는데 보안 인증서 문제로 연결이 거부되는 경우다. 브라우저는 인증서가 만료됐거나 신뢰할 수 없으면 접속을 막는다.

1. 인증서 갱신 과도기: 무료 인증서는 자동 갱신되는데, 갱신 직후 일부 노드 반영이 늦으면 오류가 잠깐 보였다 사라진다.
2. PC 시계 오차: 내 컴퓨터 시계가 크게 어긋나 있으면 멀쩡한 인증서도 만료·미발효로 판정되어 접속이 막힌다. 시간 자동 동기화를 확인한다.
3. 브라우저별 신뢰 정책 차이: 다른 브라우저나 시크릿 모드로 접속해보면 인증서 문제인지 브라우저 데이터 문제인지 갈린다.

6. 4단계 의심: 브라우저 캐시·쿠키 오류

브라우저에 쌓인 오래된 정보 때문에 특정 사이트 접속만 꼬이는 경우도 흔하다. 서버는 정상인데 브라우저만 옛 데이터를 붙들고 엉뚱하게 동작한다.

1. 오래된 캐시 리소스: 사이트가 업데이트됐는데 브라우저가 옛 파일을 재사용하면서 충돌이 나면 페이지가 깨지거나 안 열린다.
2. 손상된 세션 쿠키: 쿠키가 꼬이면 로그인 페이지에서 무한 반복하거나 접근이 거부된다. 해당 사이트 쿠키만 지워도 풀리는 경우가 많다.
3. 확장 프로그램 간섭: 광고 차단기나 보안 확장이 특정 요청을 막아 간헐적 장애를 만든다. 시크릿 모드에서 정상이면 확장 프로그램이 유력하다.

7. 본인 운영 사이트와 서버 DB가 불안정할 때

직접 만든 사이트와 그 뒤의 데이터베이스가 됐다 안 됐다 한다면, 위의 클라이언트 측 원인 외에 서버 측 원인을 반드시 함께 봐야 한다. DB 접속이 방금은 됐다가 잠시 뒤 거부되는 패턴은 서버 자원이나 커넥션 관리에서 나오는 전형적 신호다. 특히 관리 도구(phpMyAdmin 등)로는 접속이 되는데 애플리케이션에서만 간헐적으로 실패한다면, DB 서버 자체보다 그 사이의 커넥션 풀과 네트워크 규칙을 먼저 의심해야 한다.

7.1. 데이터베이스 커넥션 한도와 타임아웃

MySQL이나 MariaDB는 동시에 받을 수 있는 연결 수와 유휴 연결을 끊는 시간이 정해져 있다. 이 설정이 트래픽이나 인프라와 어긋나면 간헐적 거부가 발생한다.

1. 최대 연결 수 초과: 동시 접속이 max_connections 한도를 넘으면 새 연결이 거부된다(too many connections). 트래픽이 몰리는 순간에만 터지고 잦아들면 다시 되므로 정확히 됐다 안 됐다의 모양이 된다.
2. 유휴 타임아웃 불일치: 데이터베이스의 wait_timeout과 그 앞단 방화벽·로드밸런서·애플리케이션 커넥션 풀의 유휴 타임아웃이 어긋나면, 한쪽은 살아 있다고 믿는 연결을 다른 쪽이 끊어 간헐적 오류가 난다. 이는 커넥션 드롭의 가장 흔한 원인으로 꼽힌다.
3. 커넥션 누수: 애플리케이션이 다 쓴 연결을 제때 반납하지 않으면 풀이 서서히 고갈되어, 일정 시간 운영 후부터 간헐적으로 실패한다. 재시작하면 잠깐 멀쩡해지는 것이 단서다.

7.2. 서버 자원과 네트워크 규칙, DNS 전파

데이터베이스 자체는 정상인데 주변 인프라가 간헐적 장애를 만들기도 한다.

1. 서버 자원 고갈: CPU·메모리·디스크 I/O가 순간 포화되면 응답이 지연되거나 거부되고, 부하가 빠지면 다시 정상이 되어 간헐적으로 보인다. 시계열 모니터링으로 장애 시각과 포화 구간이 겹치는지 본다.
2. 방화벽·접근 제어 규칙: 클라우드 환경에서는 보안 그룹이나 네트워크 ACL의 포트 범위 설정이 잘못되면 일부 응답 패킷만 막혀 간헐적 타임아웃이 발생한 사례가 보고된다. 특히 응답용 임시 포트(ephemeral port) 범위를 허용하지 않으면 응답이 간헐적으로 차단된다.
3. DNS 전파 과도기: 도메인의 IP나 네임서버를 최근에 바꿨다면, 전 세계 DNS에 반영되는 동안(보통 수 시간에서 최대 24~48시간) 어떤 경로는 새 서버로, 어떤 경로는 옛 서버로 향한다. 옛 서버가 이미 꺼졌다면 접속이 됐다 안 됐다 한다. 평소 TTL 값을 낮게 설정해두면 다음 변경 때 전파가 빨라진다.

핵심 포인트: 관리 도구로는 DB가 열리는데 애플리케이션에서만 간헐적으로 실패하면, DB 서버 자체보다 애플리케이션의 커넥션 풀 설정과 그 사이 네트워크 규칙을 먼저 점검해야 한다.

8. 범인을 좁히는 진단 순서

간헐적 장애는 소거법으로 푼다. 아래 세 질문에 차례로 답하면 문제 위치가 자연스럽게 드러난다.

1. 모바일 데이터에서는 되는가: 와이파이를 끄고 LTE/5G로 접속한다. 모바일에서 되면 내 집 회선·공유기·DNS 문제다. 모바일에서도 안 되면 사이트나 서버 쪽이다.
2. 다른 기기에서는 되는가: 같은 와이파이의 다른 기기에서 시도한다. 다른 기기에서 되면 원래 기기의 캐시·확장 프로그램·DNS 캐시 문제다.
3. 다른 브라우저나 시크릿 모드에서는 되는가: 시크릿에서 되면 캐시·쿠키·확장이 범인이고, 시크릿에서도 안 되면 더 아래 계층(DNS·네트워크·서버)이다.

이 세 질문은 각각 다른 계층을 잘라낸다. 클라이언트가 의심되면 ipconfig /flushdns → 공용 DNS(8.8.8.8·8.8.4.4) 및 DoH 설정 → 캐시·쿠키 삭제 → 확장 프로그램 점검 순으로 조치한다. 서버가 의심되면 DB·웹서버의 에러 로그에서 too many connections·connection refused·timeout 메시지와 발생 시각을 확인한 뒤, 연결 한도와 타임아웃을 일관되게 정렬하고 자원과 네트워크 규칙을 점검한다.

9. 마무리

위에서 살펴본 사이트 간헐적 접속 장애의 핵심 내용을 정리하면 다음과 같습니다.

핵심 요약:

• 됐다 안 됐다 하는 증상은 단일 원인이 아니라 DNS·네트워크·브라우저·서버 중 한 계층이 불안정하다는 신호이며, ipconfig flushdns·공용 DNS 전환·캐시 삭제·시크릿 모드·모바일 데이터의 다섯 가지 응급 조치가 곧 진단 도구다.
• 모바일 데이터, 다른 기기, 다른 브라우저(시크릿 모드)에서 되는지 차례로 확인하면 문제 위치가 거의 좁혀진다.
• 8.8.8.8은 구글이 2009년 출시한 Google Public DNS의 대표 주소로, 레벨3가 보유한 8 대역 중 외우기 쉬운 구간만 골라 쓴 것이며, 8.8.4.4는 같은 서비스의 대체 리졸버다.
• 8.8.8.8과 8.8.4.4는 우열이 아니라 기본·대체로 짝을 이루는 이중화 구성이고, 애니캐스트 덕분에 하나의 주소로 전 세계에서 빠르고 끊김 없이 응답한다.
• 공용 DNS가 통신사 DNS보다 잘 되는 이유는 방대한 캐시, 넉넉한 자원, 통신사 서버의 잘못된 응답 우회, DNSSEC·DoH 같은 무결성·보안 기능이 겹치기 때문이다.
• 본인 운영 사이트와 서버 DB가 간헐적으로 끊기면 maxconnections 초과, waittimeout 불일치, 커넥션 누수, 자원 고갈, 네트워크 ACL의 임시 포트 규칙, DNS 전파 과도기를 우선 의심한다.

간헐적 장애를 만나면 가장 먼저 할 일은 고치는 것이 아니라 범위를 좁히는 것입니다. 도입부의 다섯 가지 응급 조치로 응급 대응과 진단을 동시에 끝내고, 그래도 남으면 모바일·다른 기기·다른 브라우저 테스트로 클라이언트인지 서버인지를 가른 뒤, 클라이언트면 DNS와 캐시를, 서버면 로그와 커넥션 설정을 파고드세요. 이 순서만 지켜도 추측에 쓰는 시간을 크게 줄이고 진짜 원인에 빠르게 도달할 수 있습니다.

10. 점검 도해 자료

자주 묻는 질문

• 사이트가 됐다 안 됐다 반복되는데 가장 먼저 뭘 해야 하나요?

  다섯 가지를 순서대로 시도하세요. 관리자 권한 명령 프롬프트에서 ipconfig /flushdns 실행, DNS를 8.8.8.8과 8.8.4.4로 변경, 브라우저 캐시·쿠키 삭제 후 재시작, 시크릿 모드나 다른 브라우저로 접속, 마지막으로 모바일 데이터로 접속해보기입니다. 어느 단계에서 증상이 사라지는지가 곧 원인을 가리키므로 응급 조치이자 진단 도구가 됩니다.

• 8.8.8.8과 8.8.4.4는 무슨 차이가 있나요?

  둘 다 같은 Google Public DNS 서비스로 연결되며 기능과 정책이 동일합니다. 차이는 역할인데, 8.8.8.8은 평소 질의를 처리하는 기본(Primary) 리졸버이고 8.8.4.4는 기본이 응답하지 못할 때 자동으로 넘어가는 대체(Secondary) 리졸버입니다. 성능 등급이 다른 게 아니라 장애 대비용 이중화를 위한 한 쌍이므로 둘을 함께 입력하는 것이 권장됩니다.

• 구글은 어떻게 8.8.8.8 같은 외우기 쉬운 주소를 차지했나요?

  8로 시작하는 거대한 IP 대역(8.0.0.0/8)은 통신 인프라 기업 레벨3가 보유하고 있었습니다. 구글은 2009년 12월 Google Public DNS를 출시하면서 이 블록 중 8.8.8.0/24와 8.8.4.0/24라는 작은 구간을 확보해, 사람들이 기억하기 쉬운 8.8.8.8과 8.8.4.4만 골라 배정했습니다. 8 대역 전체를 소유한 것이 아니라 상징적인 번호만 선점한 것입니다.

• 8.8.8.8은 하나의 주소인데 어떻게 전 세계에서 빠르게 응답하나요?

  애니캐스트(anycast)라는 라우팅 기법 덕분입니다. 전 세계 수많은 데이터센터의 서버가 같은 8.8.8.8 주소를 동시에 광고하고, 사용자가 질의를 보내면 인터넷 라우팅이 네트워크적으로 가장 가까운 서버로 자동 안내합니다. 그래서 같은 주소를 쓰면서도 지연이 짧고, 한 노드가 죽어도 다른 노드가 같은 주소를 받아내 사실상 항상 살아 있는 주소처럼 동작합니다.

• 통신사 DNS는 못 찾는 사이트를 왜 구글 DNS는 찾아내나요?

  몇 가지 이유가 겹칩니다. 공용 DNS는 전 세계의 막대한 질의를 처리하며 방대한 캐시를 늘 데우고 있어 응답이 빠르고 누락이 적습니다. 또 통신사 서버보다 자원이 넉넉해 부하로 인한 일시적 실패가 드물고, 통신사 DNS가 특정 도메인에 주던 잘못된 응답 자체를 우회합니다. 여기에 DNSSEC 검증으로 위조 응답까지 걸러내 정확도가 높습니다.

• 내가 운영하는 사이트의 데이터베이스가 방금은 됐는데 잠시 뒤 거부됩니다.

  서버 측 간헐적 거부는 대부분 동시 접속이 max_connections를 넘거나, 유휴 연결 종료 시간(wait_timeout)이 방화벽·커넥션 풀의 타임아웃과 어긋나거나, 연결을 제때 반납하지 않는 커넥션 누수에서 옵니다. DB·웹서버 에러 로그에서 too many connections, connection refused, timeout 메시지와 발생 시각을 확인하고, 트래픽 피크와 겹치는지부터 보세요.

• DNS over HTTPS(DoH)는 꼭 켜야 하나요?

  필수는 아니지만 권장됩니다. DoH는 어떤 사이트를 조회하는지 자체를 암호화해 중간에서 엿보거나 조작하기 어렵게 만듭니다. 구글 DNS는 일반 DNS와 동일한 8.8.8.8 주소를 그대로 쓰면서 더 낮은 지연으로 암호화 조회를 제공하며, DoH 템플릿 주소는 https://dns.google/dns-query 입니다. 보안과 통신사 간섭 우회를 동시에 노린다면 켜두는 것이 좋습니다.