Clash DNS 누수 테스트 및 차단 설정: fake-ip·nameserver-policy 사용법

DNS 누수 판단 기준

DNS 누수란 도메인 조회가 예상한 경로를 따르지 않는 상황을 말합니다. 예를 들어 브라우저 연결은 프록시를 통해 이루어지지만, 도메인 조회는 여전히 로컬 네트워크 사업자의 재귀 DNS 서버로 전송될 수 있습니다. 웹페이지가 열리거나 외부 IP가 바뀌었다는 사실만으로 DNS 요청도 프록시를 거쳤다고 단정할 수는 없습니다.

문제를 확인할 때는 세 단계를 따로 살펴봐야 합니다. 앱이 조회를 어디로 보내는지, Clash 코어가 어떤 상위 DNS를 선택하는지, 상위 DNS에 연결하는 트래픽이 어떤 경로를 이용하는지 확인하세요. fake-ip는 코어가 앱에 반환하는 주소를 주로 바꾸고, nameserver-policy는 DNS 서버를 선택하며, respect-rules는 DNS 서버 연결이 라우팅 규칙을 따를지 결정합니다. 각 기능이 해결하는 문제는 서로 다릅니다.

점검 순서: 시스템·코어·브라우저 DNS 확인

1단계: 현재 상태 기록하기

현재 네트워크와 클라이언트 모드, 시스템 프록시 및 TUN 사용 여부, 브라우저의 보안 DNS 설정을 먼저 기록하세요. 테스트 중에는 프록시 노드를 하나로 고정하고 자동 정책 그룹 전환은 잠시 중지하세요. 그래야 두 번의 테스트 결과가 서로 다른 출구에서 나온 결과가 되는 일을 피할 수 있습니다. 회사 VPN이나 다른 프록시 클라이언트도 테스트 중에는 함께 실행하지 마세요.

• Windows: PowerShell에서 Get-DnsClientServerAddress를 실행하고 사용 중인 네트워크 어댑터와 DNS 주소를 기록하세요.
• macOS: scutil --dns를 실행해 기본 리졸버와 도메인별 리졸버를 확인하세요. 시스템에 여러 리졸버가 동시에 설정되어 있을 수 있습니다.
• systemd-resolved를 사용하는 Linux: resolvectl status를 실행해 연결별 DNS를 확인하세요. /etc/resolv.conf만 확인해서는 부족합니다.

네트워크 어댑터에 라우터 주소가 표시된다고 해서 반드시 누수가 발생한 것은 아닙니다. TUN을 사용하면 해당 주소의 53번 포트로 향하는 조회를 코어가 가로챌 수 있습니다. 반대로 어댑터에 공용 DNS 주소가 표시되어도 조회가 암호화됐다는 뜻은 아닙니다. 실제 연결을 추가로 확인해야 합니다.

2단계: 코어의 수신 포트에 직접 조회하기

아래 예시에서는 코어의 DNS가 127.0.0.1:1053에서 요청을 받도록 설정합니다. 설정을 적용한 뒤 다음 명령을 실행하세요. 첫 번째 명령은 nslookup이 설치된 시스템용이고, 두 번째 명령은 dig가 설치된 환경용입니다.

nslookup -port=1053 example.com 127.0.0.1
dig @127.0.0.1 -p 1053 example.com A

Fake-IP 필터 규칙에 해당하지 않는 경우 A 레코드 조회는 설정한 주소 풀의 매핑 주소를 반환해야 합니다. 이는 예상되는 결과를 설명한 것이며, 이 문서에서 실제 테스트를 마쳤다는 뜻은 아닙니다. 시간 초과가 발생하면 DNS 모듈이 활성화됐는지, 설정이 적용됐는지, 1053 포트를 다른 프로세스가 사용 중인지부터 확인하세요. 모든 라우팅 규칙을 한꺼번에 바꾸지는 마세요.

그다음 nslookup example.com을 실행해 시스템 기본 조회와 코어에 직접 보낸 조회 결과를 비교하세요. 시스템 프록시만 켜져 있다면 두 결과가 다른 경우가 흔합니다. 명령줄의 DNS 조회는 보통 HTTP 시스템 프록시를 사용하지 않기 때문입니다. TUN을 켠 뒤 다시 테스트해야 시스템 DNS가 가로채지는지 확인할 수 있습니다.

3단계: 브라우저의 별도 DNS 조회 확인하기

Chrome에서는 ‘설정’ → ‘개인 정보 보호 및 보안’ → ‘보안’ → ‘보안 DNS 사용’에서 DoH 설정을 확인할 수 있습니다. 메뉴 이름은 버전에 따라 조금 다를 수 있습니다. 처음 점검할 때는 이 기능을 잠시 꺼 브라우저가 시스템 DNS를 사용하도록 하세요. 기본 테스트를 마친 뒤 다시 켜고 브라우저의 DoH 연결이 어떤 경로를 이용하는지 별도로 확인하세요.

DNS 누수 테스트 페이지는 보통 임의의 하위 도메인을 이용해 재귀 DNS 서버를 확인합니다. 프록시를 켜기 전과 후에 표시되는 DNS 서비스 제공자를 비교하고 코어의 연결 기록도 함께 확인하세요. DNS 서버의 위치와 프록시 출구의 위치가 같을 필요는 없습니다. 공용 DNS의 애니캐스트 주소와 재귀 질의 출구가 서로 다른 위치에 있을 수도 있으므로 국가나 도시만 보고 판단하면 오해하기 쉽습니다.

Fake-IP 및 DNS 상위 서버 설정 예시

아래는 mihomo 설정에 병합할 수 있는 dns 항목입니다. 기존 노드와 구독 공급자, 정책 그룹은 유지하세요. 파일에 최상위 dns: 항목이 이미 있다면 해당 필드를 교체하거나 병합해야 합니다. 같은 이름의 항목을 하나 더 추가하지 마세요. 설정을 적용하기 전에 뒤에 나오는 상위 서버 라우팅 요건을 먼저 확인하세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
  respect-rules: true
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - https://cloudflare-dns.com/dns-query
  nameserver-policy:
    "+.qq.com":
      - https://dns.alidns.com/dns-query#DIRECT
    "+.weixin.qq.com":
      - https://dns.alidns.com/dns-query#DIRECT

필드별 역할과 한계

• listen은 로컬 루프백 주소에만 바인딩합니다. 여기서 1053은 예시 수신 포트일 뿐이며 운영체제의 DNS 포트를 자동으로 바꾸지 않습니다. 또한 LAN 기기에 그대로 제공하기 위한 설정도 아닙니다.
• enhanced-mode: fake-ip는 도메인에 매핑 주소를 할당해 이후 연결에서도 도메인 정보를 유지하고 규칙을 적용하기 쉽게 합니다. 이 기능 자체가 상위 DNS 조회를 암호화하지는 않습니다.
• fake-ip-filter에 등록된 도메인은 일반적인 Fake-IP 매핑 방식으로 응답하지 않습니다. 필터 항목은 직접 연결 라우팅 규칙이 아니므로 rules를 대신할 수 없습니다.
• ipv6: false는 이번 DNS 점검 범위를 좁히기 위한 설정입니다. 시스템 IPv6를 끄는 것은 아니며 앱이 이미 알고 있는 IPv6 주소에 접속하는 것도 차단하지 않습니다.
• proxy-server-nameserver는 프록시 노드의 도메인을 전용으로 조회합니다. 노드 주소를 조회할 때 해당 노드에 연결해야 하는 상황을 방지하기 위한 설정입니다. 노드 도메인 조회는 별도의 경로로 확인해야 합니다.

여기서는 첫 설정 적용 시 문제를 쉽게 찾을 수 있도록 명확한 초기 조회 경로를 유지합니다. 현재 네트워크에서 선택한 DNS 서비스에 접속할 수 없다면 실제로 연결 가능한 상위 서버로 바꾸고 라우팅을 다시 확인하세요. DoH는 기기와 DNS 서비스 사이의 DNS 전송 내용을 보호할 뿐입니다. DoH에 직접 연결하면 네트워크에는 대상 DNS 서버의 주소가 노출됩니다.

nameserver-policy와 respect-rules 함께 사용하기

DNS 서버를 선택한 뒤 연결 경로 지정하기

nameserver-policy는 조회하는 도메인에 따라 상위 DNS를 선택하며, 웹사이트 연결이 어느 노드를 사용할지는 결정하지 않습니다. 예시에서는 qq.com과 하위 도메인의 조회를 지정된 중국 본토 DNS 서버에 맡기고, #DIRECT로 해당 DNS 서버 연결을 직접 연결하도록 지정합니다. weixin.qq.com 항목은 이 설정에서 앞선 규칙과 중복됩니다. 세부 도메인 지정 방법을 보여주기 위해 남겨둔 것이므로 별도 요구가 없다면 삭제해도 됩니다.

그 밖의 조회는 cloudflare-dns.com으로 보냅니다. respect-rules를 켜면 상위 DNS 연결이 라우팅 규칙을 따르지만, ‘규칙을 따른다’고 해서 자동으로 프록시를 이용하는 것은 아닙니다. 해당 도메인이 최종적으로 DIRECT에 일치하면 DoH도 직접 연결됩니다.

기존 설정에 ‘프록시’라는 정책 그룹이 있고, 현재 사용할 수 있는 프록시 노드를 선택했다고 가정해 보겠습니다. 아래 두 규칙은 범위가 넓은 직접 연결 규칙과 마지막 MATCH 규칙보다 앞에 추가할 수 있습니다. 그룹 이름은 실제 설정과 일치해야 합니다. 기존 그룹 이름이 ‘노드 선택’이라면 참조 이름도 함께 바꾸세요.

rules:
  - DOMAIN,dns.alidns.com,DIRECT
  - DOMAIN,cloudflare-dns.com,프록시
  # 이후에는 기존 라우팅 규칙과 마지막 MATCH 규칙을 유지합니다

이 부분은 규칙을 병합할 위치만 보여주는 예시이며, rules를 통째로 대체할 내용이 아닙니다. 두 규칙을 복사하려고 구독에 포함된 나머지 규칙을 삭제하지 마세요. 프록시 그룹에서 DIRECT를 선택할 수 있다면 현재 선택 항목도 확인해야 합니다. 규칙 이름이 맞아 보여도 실제로는 직접 연결될 수 있습니다.

DNS 조회 의존성 순환 방지하기

흔한 순환 문제는 프록시에 연결해야 DoH 서비스 도메인을 조회할 수 있는데, 프록시 서버 도메인도 아직 연결되지 않은 DoH를 통해 조회하려는 상황입니다. 시작 후 조회 시간 초과가 잇따르고 노드 연결도 실패하는 것이 대표적인 증상입니다. 예시에서는 proxy-server-nameserver로 노드 도메인을 조회하고 해당 상위 서버는 직접 연결하도록 설정해 두 의존성을 분리합니다.

• 노드 주소가 도메인이라면 먼저 독립된 조회 경로로 노드 도메인을 확인할 수 있는지 확인하세요.
• 노드 주소가 IP라면 노드 호스트 이름을 조회할 필요는 없지만 DoH 서비스의 초기 조회는 여전히 필요할 수 있습니다.
• 아직 연결할 수 없는 프록시 경로를 모든 초기 조회에 강제로 적용한 뒤 자동 복구를 기대하지 마세요.
• 한 번에 하나의 의존성만 바꾸세요. 저장 후 설정 적용 결과를 확인하고 연결 로그를 점검하세요.

TUN 모드로 시스템 DNS 가로채기

시스템 프록시는 주로 시스템 프록시 설정을 따르는 앱에 영향을 줍니다. 운영체제에서 보내는 UDP DNS 조회까지 자동으로 가로채지는 않습니다. 더 많은 앱의 일반 DNS 요청을 코어로 보내려면 클라이언트의 TUN 기능을 켤 수 있습니다. 데스크톱 운영체제에서는 관련 권한이나 서비스, 가상 네트워크 어댑터가 필요할 수 있습니다. 화면 설정과 파일 설정이 서로 덮어쓰지 않도록 클라이언트에서 제공하는 스위치를 우선 사용하세요.

아래는 mihomo의 TUN 설정을 기존 구성에 병합하는 예시입니다. 클라이언트가 이미 tun 항목을 생성했다면 최종 적용 설정을 먼저 확인한 뒤 수정 여부를 결정하세요.

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

any:53은 TUN으로 들어오는 UDP 53번 포트 조회를 가로채며, 두 번째 항목은 TCP 53번 포트에 적용됩니다. 중요한 전제는 트래픽이 ‘TUN으로 들어와야 한다’는 점입니다. 라우팅 제외 설정, 다른 VPN, 가상 머신 네트워크, 플랫폼 제한으로 일부 트래픽이 이 경로를 우회할 수 있습니다. 특히 LAN DNS 주소를 사용할 때는 실제 조회를 통해 가로채기 여부를 확인하세요.

DoH는 보통 HTTPS의 443번 포트를 사용하고 DoT는 853번 포트를 사용합니다. 53번 포트 가로채기를 설정해도 이 트래픽이 자동으로 코어의 DNS 모듈에 들어가지는 않습니다. TUN은 라우팅에 따라 해당 네트워크 연결을 가로챌 수 있지만, 53번 포트 설정만으로 연결 내부의 조회 방식을 바꾸지는 못합니다. Android의 ‘비공개 DNS’와 브라우저의 보안 DNS도 각각 확인해야 합니다.

설정 변경 후 확인 및 문제 발생 시 롤백

같은 조건으로 다시 테스트하기

1. 설정이 정상적으로 적용됐는지 확인하세요. 알 수 없는 필드나 존재하지 않는 정책 그룹 오류가 표시되면 먼저 설정을 수정한 뒤 브라우저 테스트를 진행하세요.
2. 노드를 고정한 뒤 127.0.0.1:1053에 직접 조회해 DNS 모듈이 응답하는지 확인하세요.
3. TUN을 켠 뒤 시스템 기본 DNS로 조회하면서 코어의 DNS 로그와 연결 기록을 확인하세요.
4. 새 도메인에 접속한 뒤 웹 연결만 확인하지 말고 cloudflare-dns.com의 상위 서버 연결이 예상한 프록시 그룹을 사용하는지도 확인하세요.
5. 브라우저 DNS 테스트를 다시 실행하세요. 마지막으로 보안 DNS 등 기존 설정을 복원하고 한 번 더 테스트해 결과 차이를 기록하세요.

Windows에서는 ipconfig /flushdns로 시스템 DNS 캐시를 비울 수 있습니다. systemd-resolved를 사용하는 Linux에서는 resolvectl flush-caches를 실행하세요. 브라우저와 코어에도 별도의 캐시가 있을 수 있으므로 필요하면 브라우저를 다시 시작하고 설정을 재적용하세요. Fake-IP 매핑은 저장될 수 있어 예전 주소가 나온다는 사실만으로 설정이 적용되지 않았다고 단정할 수는 없습니다.

롤백할 때는 먼저 저장해 둔 DNS 및 규칙 설정을 복원하고, 이번에 추가한 TUN 설정을 끄세요. 마지막으로 운영체제 프록시와 네트워크 어댑터의 DNS가 테스트용 값으로 남아 있지 않은지 확인합니다. 클라이언트 데이터 폴더 전체를 바로 삭제하지 마세요. 구독과 사용자 지정 규칙, 로그까지 함께 사라져 문제를 파악할 정보가 줄어들 수 있습니다.

자주 묻는 질문

Fake-IP를 켰는데 테스트 페이지에 ISP DNS가 계속 표시되는 이유는 무엇인가요?

브라우저가 별도의 DNS 서버를 사용하거나 코어의 상위 서버가 여전히 직접 연결 규칙에 따라 조회를 보낼 수 있습니다. Fake-IP는 특정 조회에 주소 매핑 기능이 관여했다는 사실만 보여줄 뿐, 모든 DNS 트래픽이 프록시를 거친다는 뜻은 아닙니다. 브라우저 설정과 상위 서버 연결, 초기 조회 경로를 각각 확인하세요.

nameserver를 전부 DoH로 바꾸면 충분한가요?

아닙니다. DoH는 조회 전송을 암호화하지만 프록시 출구는 라우팅 규칙에 따라 결정됩니다. 시스템이나 앱이 코어를 완전히 우회할 수도 있습니다. 요청 가로채기, 상위 서버 선택, 라우팅 규칙, 노드 조회 의존성을 모두 확인해야 합니다.

중국 본토 도메인의 DNS 조회를 직접 연결로 유지하면 반드시 누수인가요?

사전에 정한 목표를 기준으로 판단해야 합니다. 지정된 직접 연결 DNS 서버를 통해 해당 도메인을 조회하도록 정책에서 허용했다면 의도적인 분기입니다. 모든 조회가 프록시를 거쳐야 하는 것이 목표라면 이 설정은 목표에 맞지 않습니다. 허용할 예외를 먼저 명확히 정한 다음 로그로 확인하는 편이 테스트 페이지에 주소 하나만 표시되도록 하는 것보다 신뢰할 수 있습니다.

구독을 업데이트한 뒤 설정이 사라지면 어디를 수정해야 하나요?

원격 구독으로 덮어써질 수 있는 원본 파일을 계속 직접 편집하지 마세요. 클라이언트에서 지원하는 로컬 덮어쓰기, 설정 병합 또는 스크립트 기능을 사용하세요. 구체적인 메뉴 위치는 클라이언트 버전에 따라 다릅니다. 구독 업데이트 후에는 덮어쓰기 파일이 저장됐는지만 보지 말고 최종 적용된 DNS와 TUN 설정, 규칙 순서를 확인하세요.