DNS 누수 확인 및 설정

먼저 DNS 누수의 판단 기준 정하기

Clash DNS 누수란 지정된 리졸버를 사용하거나 프록시를 통해 전송해야 하는 도메인 조회가 예상한 경로를 벗어나 로컬 네트워크, 통신사 또는 다른 DNS 서비스로 전송되는 상황을 말합니다. 누수 여부를 판단하려면 먼저 기대하는 동작을 분명히 해야 합니다. 예를 들어 한국 도메인은 직접 조회하고, 그 외 도메인은 프록시를 통해 지정된 DoH 서비스에 접속하도록 설정할 수 있습니다. 기준이 없다면 검사 페이지에 표시된 국가나 서비스 제공업체 이름만으로 누수라고 결론 내릴 수 없습니다.

한 번의 접속에도 서로 독립적인 경로가 세 가지 이상 관여합니다. 앱이 조회를 어디에 전달하는지, Clash가 어느 업스트림으로 조회를 보내는지, 업스트림 연결에 직접 연결과 프록시 중 무엇을 사용하는지 확인해야 합니다. nameserver-policy는 도메인에 따라 업스트림을 선택하는 기능일 뿐입니다. 트래픽을 가로채거나 DNS 연결을 프록시로 보내는 기능은 아닙니다.

재현 가능한 DNS 검사 절차

1. 기준 상태를 기록한 뒤 프록시 켜기

1. 다른 VPN, 프록시, 네트워크 가속 프로그램을 끄고 현재 네트워크 어댑터의 DNS 주소를 기록합니다. Windows에서는 ipconfig /all, macOS에서는 scutil --dns, systemd-resolved를 사용하는 Linux에서는 resolvectl status를 실행합니다.
2. 브라우저에서 보안 DNS를 사용 중인지 기록합니다. 먼저 시스템 DNS 모드로 테스트한 다음 브라우저 DoH를 별도로 테스트해 두 경로를 혼동하지 않도록 합니다.
3. Clash를 켜지 않은 상태에서 DNS 검사를 한 번 실행하고 서비스 제공업체, 리졸버 주소, 검사 시간을 기록합니다. Clash를 켠 뒤 같은 네트워크와 브라우저로 다시 검사합니다.
4. 검사 중에는 클라이언트 로그나 연결 목록도 열어 도메인, 대상 주소, 적용된 규칙과 송신 정책을 확인합니다. 검사 페이지는 단서일 뿐이며, 실제 경로를 파악하려면 로컬 기록을 확인해야 합니다.

공용 DNS는 애니캐스트 주소를 사용할 수 있으며 재귀 리졸버의 위치가 프록시 출구 위치와 다를 수도 있습니다. 검사 페이지에 여러 리졸버 주소가 표시되는 이유는 업스트림이 여러 개이거나 같은 서비스의 노드 풀을 사용하기 때문일 수 있습니다. 주소 개수나 지리적 위치를 누수 횟수로 단정하지 마세요.

2. Clash DNS 리스너 별도 확인

뒤에 나오는 설정은 DNS를 127.0.0.1:1053에서 수신합니다. 이 주소는 로컬 기기에서만 접속할 수 있고, 1053은 DNS 포트이지 HTTP 프록시 포트가 아닙니다. 앱이 여전히 라우터의 53번 포트로 조회한다면 여기서 리스너를 켜도 자동으로 경로가 바뀌지 않습니다.

# macOS / Linux, dig 설치 필요
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

# Windows
nslookup -port=1053 example.com 127.0.0.1

명령이 결과를 반환하면 로컬 기기에서 Clash DNS 엔드포인트까지 연결할 수 있다는 뜻입니다. 시스템 DNS가 가로채지고 있다는 의미는 아닙니다. 시간 초과가 발생하면 설정 로드 여부, 코어 실행 상태, 1053 포트 충돌 여부부터 확인하세요. 곧바로 프록시 노드를 바꾸지 마세요.

3. 물리 네트워크 어댑터에서 평문 조회 확인

권한이 있는 기기에서는 패킷 캡처 도구의 필터에 udp.port == 53 || tcp.port == 53를 입력해 확인할 수 있습니다. Linux에서는 아래 명령도 사용할 수 있습니다. any는 가상 인터페이스도 포함하므로 결과를 판독할 때 물리 네트워크 어댑터와 TUN 인터페이스를 구분해야 합니다.

sudo tcpdump -ni any '(udp port 53 or tcp port 53)'

로컬 네트워크의 DNS로 향하는 조회가 보이면 해당 도메인이 직접 연결 허용 대상인지 확인하세요. 53번 포트 트래픽이 보이지 않는다고 모든 DNS가 프록시를 거친다고 볼 수는 없습니다. DoH는 보통 HTTPS의 443번 포트를, DoT는 보통 TCP 853번 포트를 사용하므로 이 필터에 잡히지 않습니다.

nameserver와 조회 경로 이해하기

dns.enable은 코어의 DNS 서비스를 켜고, listen은 수신 주소를 지정하며, nameserver는 일반 조회에 사용할 업스트림을 설정합니다. 업스트림에는 일반 DNS 주소나 코어가 지원하는 암호화 DNS URL을 지정할 수 있습니다. 일반 DNS를 DoH로 바꾸면 클라이언트와 DoH 서비스 사이의 전송은 보호되지만, 해당 리졸버 서비스에는 조회 내용이 공개됩니다.

• default-nameserver: 주로 DNS 업스트림의 도메인을 조회할 때 사용합니다. 리졸버 주소를 먼저 알아야 하는 초기 연결 문제를 해결하기 위한 설정이지, 모든 일반 도메인의 기본 그룹을 지정하는 항목은 아닙니다.
• proxy-server-nameserver: mihomo에서 프록시 노드 도메인을 조회할 전용 경로를 지정합니다. 노드에 연결하기도 전에 해당 노드를 통해 노드 주소를 조회해야 하는 상황을 방지합니다.
• nameserver: 별도 정책이 적용되지 않는 일반 조회를 처리합니다.
• nameserver-policy: 지정한 도메인이나 지원되는 도메인 집합에 특정 리졸버를 사용하도록 설정합니다.

아래 예시는 IP 형식의 DoH 주소를 사용해 초기 조회를 수행합니다. 현재 네트워크에서 해당 주소에 연결할 수 있어야 하며 코어의 TLS 인증도 성공해야 합니다. 네트워크에서 해당 서비스를 차단한다면 현지에서 접속할 수 있고 신뢰할 수 있는 리졸버를 선택한 뒤 직접 연결 범위를 다시 검토하세요. 인증서 검증을 끄는 방식으로 문제를 우회하지 마세요.

바로 적용할 수 있는 mihomo DNS 설정

기존 설정에 병합해 사용하는 예시이며, 노드와 구독 설정은 포함하지 않습니다. 일반 도메인은 Cloudflare DoH로 보내고 .cn으로 끝나는 도메인은 Alibaba DoH로 보내며, 규칙으로 DNS 서비스 연결의 송신 경로를 구분합니다. .cn은 도메인 접미사일 뿐 중국 본토의 모든 웹사이트를 뜻하지 않습니다.

적용하기 전에 기존 설정에 이름이 정확히 PROXY인 정책 그룹이 있는지 확인하고 사용 가능한 노드를 선택하세요. 정책 그룹 이름이 다르면 규칙에 있는 PROXY를 해당 이름으로 바꿔야 합니다. 아래 규칙은 기존 rules 목록 앞부분에 넣고 기존 서비스 규칙과 마지막 기본 규칙은 유지하세요. 같은 이름의 YAML 키를 중복해서 만들지 마세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true
  default-nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query
  nameserver:
    - https://cloudflare-dns.com/dns-query
  nameserver-policy:
    "+.cn":
      - https://dns.alidns.com/dns-query

# 기존 rules 앞부분에 병합하고 뒤에 있는 서비스 규칙은 덮어쓰지 마세요.
rules:
  - DOMAIN,cloudflare-dns.com,PROXY
  - DOMAIN,dns.alidns.com,DIRECT
  - IP-CIDR,1.1.1.1/32,DIRECT,no-resolve

respect-rules: true를 설정하면 일반 DNS 업스트림 연결에 라우팅 규칙이 적용됩니다. 예시에서는 명시적인 도메인 규칙을 사용해 Cloudflare DoH는 PROXY로 보내고 Alibaba DoH는 직접 연결합니다. IP 규칙은 초기 연결에 필요한 주소를 직접 연결 경로로 유지합니다. 프록시 노드 도메인을 조회하는 전용 경로도 연결 초기화에 사용되므로, 이 설정으로 모든 DNS 조회가 프록시를 거친다고 볼 수는 없습니다.

ipv6: false는 여기서 코어 DNS의 AAAA 응답을 제한하는 설정입니다. 운영체제의 IPv6를 끄거나 IPv6 트래픽의 누수를 방지하지는 않습니다. IPv6가 필요한 환경에서는 IPv6 라우팅, TUN 가로채기, 업스트림 지원 여부를 별도로 확인한 다음 활성화 여부를 결정하세요.

nameserver-policy의 매칭 방식과 적용 범위

mihomo의 도메인 매칭 문법에서 "+.example.com"은 해당 도메인과 하위 도메인에 모두 적용할 수 있습니다. 특수 문자가 포함된 정책 키는 따옴표로 감싸고 들여쓰기는 공백 두 칸을 사용하는 것이 좋습니다. 정책 값에는 리졸버 목록을 지정할 수 있습니다. 여러 리졸버를 설정해도 목록 순서를 엄격한 기본·보조 순서로 해석하면 안 됩니다.

dns:
  nameserver-policy:
    "+.example.com":
      - https://cloudflare-dns.com/dns-query
    "+.cn":
      - https://dns.alidns.com/dns-query

이 구문은 정책 작성법을 보여주는 예시일 뿐입니다. 새 키를 중복으로 만들지 말고 앞서 나온 dns 항목 안에 병합하세요. example.com은 매칭을 확인하기 위한 예시 도메인이므로 실제 서비스 도메인에 맞게 바꿔야 합니다. 범위가 넓고 겹치는 정책을 여러 개 만들어 우선순위를 추측하지 마세요. 적용 범위를 명확히 하고 기본 도메인과 하위 도메인을 각각 테스트하세요.

기업 내부 도메인은 별도로 처리

회사 내부 도메인은 보통 사내 네트워크의 DNS로만 조회할 수 있습니다. 실제 내부 도메인 접미사를 사내 DNS에 연결하고 해당 DNS 주소로 가는 경로를 직접 연결로 유지할 수 있습니다. Fake-IP를 사용한다면 앱 요구사항에 따라 fake-ip-filter에 추가할지도 검토하세요. 내부 도메인을 공용 리졸버에 보내지 말고 공용 DNS가 반환한 조회 실패를 노드 장애로 오해하지 마세요.

도메인을 fake-ip-filter에 추가하면 실제 주소와 매핑 주소 중 어떤 응답을 반환할지만 바뀝니다. 업스트림을 자동으로 지정하거나 직접 연결을 강제하지는 않습니다. 리졸버 선택, Fake-IP 예외, 연결 라우팅은 서로 다른 설정 계층이므로 각각 확인해야 합니다.

fallback은 누수 방지 스위치가 아닙니다

fallback은 별도의 업스트림 리졸버 그룹을 제공하고, fallback-filter는 응답 선택에 관여합니다. 이를 “기본 DNS가 완전히 실패한 뒤에만 보조 DNS에 접속한다”라고 단순하게 이해하면 안 됩니다. 관련 조회가 동시에 발생할 수 있으며 실제 동작은 코어와 필터 조건에 따라 달라집니다. 두 업스트림의 신뢰 경계가 서로 다르면 조회 내용이 양쪽 모두에 전달될 수도 있습니다.

아래는 비정상적인 주소 응답을 처리하는 별도 설정 예시입니다. 전체 설정을 교체하지 말고 기존 dns 항목에 추가하세요. Quad9을 사용한다면 해당 연결의 송신 정책도 함께 확인해야 합니다. HTTPS 주소를 지정하는 것만으로 프록시 사용이 자동 설정되지는 않습니다.

  fallback:
    - https://dns.quad9.net/dns-query
  fallback-filter:
    geoip: false
    ipcidr:
      - 0.0.0.0/32
      - 127.0.0.0/8

여기서는 GeoIP 기반 필터링을 끄고 지정된 비정상 주소 범위만 필터링하는 방법을 보여줍니다. 오염 탐지를 위한 완전한 규칙은 아닙니다. 일부 보안 필터링 서비스는 의도적으로 빈 주소를 반환하고, 테스트 도메인에 따라 루프백 주소를 정상적으로 가리킬 수도 있습니다. 꼭 필요한 경우에만 조건을 추가하세요. 필터 항목이 많다고 더 신뢰할 수 있는 것은 아닙니다.

시스템 프록시, TUN, 브라우저 DoH에서 놓치기 쉬운 점

시스템 프록시가 모든 DNS를 가로채지는 않습니다

HTTP 프록시는 요청에 포함된 대상 도메인을 프록시 서버에서 조회할 수 있지만, 시스템 프록시를 사용하지 않는 프로그램은 여전히 시스템 리졸버를 호출할 수 있습니다. SOCKS 앱이 도메인 조회를 프록시에 맡기는지는 원격 DNS 설정에 따라 다릅니다. 시스템 프록시를 켠 뒤 웹페이지가 열린다고 해서 명령줄 도구, 게임, 백그라운드 서비스도 같은 DNS 경로를 사용한다고 볼 수는 없습니다.

TUN의 DNS 가로채기에는 프로토콜 한계가 있습니다

시스템 프록시를 따르지 않는 앱까지 가로채려면 지원 플랫폼에서 TUN을 켤 수 있습니다. 아래는 일반적인 mihomo 설정 예시입니다. 자동 라우팅에는 운영체제 권한이 필요할 수 있으며, 로컬 네트워크 대상 DNS까지 가로챌 수 있는지는 플랫폼 라우팅과 클라이언트 구현에 따라 다릅니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

이 가로채기 설정은 기존 DNS의 UDP/TCP 53번 포트에 적용됩니다. 브라우저 DoH를 복호화하거나 모든 443번 포트 연결을 코어 DNS 조회로 바꾸지는 않습니다. 브라우저에 내장된 DoH는 별도의 연결입니다. TUN을 통해 프록시로 라우팅될 수는 있지만 조회 내용이 nameserver-policy에 전달되는 것은 아닙니다.

브라우저 캐시와 시스템 캐시는 별도로 확인

데스크톱 Chrome에서는 「설정」→「개인 정보 보호 및 보안」→「보안」에서 「보안 DNS 사용」을 확인할 수 있습니다. 메뉴 문구는 버전에 따라 달라질 수 있습니다. Clash 코어 DNS를 확인하려면 먼저 사용자 지정 보안 DNS를 잠시 끄세요. 브라우저 DoH를 계속 사용한다면 해당 DoH 서비스 연결의 송신 정책도 별도로 확인해야 합니다.

Windows에서는 ipconfig /flushdns를 실행해 시스템 캐시를 비울 수 있습니다. systemd-resolved를 사용하는 Linux에서는 resolvectl flush-caches를 실행하세요. 브라우저 캐시와 코어 캐시는 남아 있을 수 있으므로 해당 프로세스를 재시작한 뒤 다시 테스트합니다. 캐시에서 빠르게 응답한 한 번의 결과로 업스트림이 바뀌었다고 판단하지 마세요.

증상별 최종 재검사

마지막으로 같은 순서에 따라 다시 테스트합니다. 로컬 1053 리스너가 작동하는지 확인하고, 시스템이나 TUN이 대상 조회를 코어로 전달하는지 확인한 다음, 정책이 예상한 업스트림을 선택했는지, 해당 업스트림 연결에 올바른 송신 경로가 적용됐는지 확인하세요. 검사 시간, 조회 도메인, 리졸버, 정책 기록을 보관합니다. 네 단계의 결과가 모두 일치해야 해당 조회 경로가 예상대로 작동한다고 볼 수 있습니다. 검사 페이지의 스크린샷 한 장으로 모든 앱, 네트워크, IPv6 환경을 판단할 수는 없습니다.