Clash DNS 유출 점검 및 보호 설정: 테스트 결과부터 규칙 수정까지

먼저 DNS 요청 우회가 무엇인지 판단하기

도메인에 접속하기 전에 기기는 보통 도메인 이름을 IP 주소로 변환해야 합니다. Clash가 이 과정을 직접 처리할 수도 있지만, 이미 완료된 DNS 조회 이후의 TCP 또는 UDP 연결만 프록시할 수도 있습니다. 웹 트래픽은 프록시를 통과하는데 도메인 조회가 로컬 네트워크의 DNS 서버로 직접 전송되면 조회 경로와 실제 서비스 트래픽이 분리됩니다. DNS 테스트 사이트는 일반적으로 이러한 현상을 DNS 유출로 표시합니다.

다만 테스트 결과에 국내 통신사, 공용 DNS 또는 다른 지역의 리졸버가 표시되었다고 해서 반드시 설정이 실패한 것은 아닙니다. 공용 DNS는 애니캐스트 네트워크를 사용하는 경우가 많아 같은 서버 주소가 여러 도시에 분산되어 응답할 수 있습니다. 또한 DNS 서비스가 조회를 다른 출구 노드로 전달할 수도 있습니다. 테스트 페이지에 표시되는 것은 재귀 리졸버나 출구 인프라일 뿐, 설정 파일에 입력한 주소와 항상 일치하는 것은 아닙니다.

정확히 판단하려면 세 가지 질문에 답해야 합니다. 애플리케이션은 누구에게 조회를 전달했는가, Clash 코어는 상위 리졸버에 어떻게 접속하는가, 그리고 해석된 서비스 연결은 어떤 프록시 규칙과 일치하는가입니다. 테스트 페이지의 국가·도시·서버 이름만으로는 이 전체 경로를 복원할 수 없습니다.

테스트 증상	가능한 원인	우선 확인할 항목
로컬 네트워크 DNS가 표시됨	시스템 조회가 Clash로 들어오지 않았거나, 직접 연결 정책이 시스템 리졸버를 사용함	시스템 DNS, TUN DNS 하이재킹, 현재 실행 모드
여러 공용 리졸버가 동시에 표시됨	여러 상위 서버가 설정되었거나 브라우저에서 독립 보안 DNS가 활성화됨	브라우저 설정, nameserver 및 fallback
노드를 바꿔도 DNS 지역이 바뀌지 않음	상위 서버 연결이 고정된 직접 연결이거나 DNS 연결이 프록시 규칙을 따르지 않음	respect-rules, 프록시 정책, 코어 버전
특정 프로그램에서만 이상한 결과가 나타남	프로그램 자체 DoH, 캐시 또는 독립 네트워크 스택을 사용함	앱 내부 DNS, 캐시 및 프로세스 연결

재현 가능한 Clash DNS 유출 점검 절차 만들기

문제 해결에 앞서 테스트 조건을 고정하세요. 설정·노드·브라우저 설정을 동시에 바꾼 뒤 계속 페이지를 새로 고치면 어떤 변경이 결과에 영향을 주었는지 확인하기 어렵습니다. 현재 설정을 복사해 보관하고 코어 유형, 실행 모드, 시스템 프록시 상태, TUN 상태, 브라우저 보안 DNS 상태를 기록하는 것이 좋습니다.

1단계: 프록시를 사용하지 않을 때 기준선 만들기

먼저 시스템 프록시와 TUN을 잠시 끄고 테스트 페이지에 접속해 리졸버 이름, 개수, 대략적인 위치를 기록합니다. 이 결과가 현재 네트워크의 일반적인 DNS 경로를 보여줍니다. 그런 다음 Clash를 활성화하고 새 시크릿 브라우저 창에서 다시 테스트하세요. 두 결과가 완전히 같다면 시스템 조회가 여전히 기존 경로를 사용하고 있을 가능성이 있지만, 캐시와 앱 자체 DoH도 함께 확인해야 합니다.

2단계: 캐시를 삭제하고 새 도메인 사용하기

시스템, 브라우저, Clash 코어, 상위 서버 모두 조회 결과를 캐시할 수 있습니다. 같은 페이지를 새로 고치는 것만으로는 새로운 DNS 조회가 발생하지 않을 수 있습니다. 테스트할 때는 운영체제의 DNS 캐시를 삭제하고 브라우저를 완전히 종료한 뒤 다시 열어, 테스트 도구가 제공하는 새 무작위 도메인을 사용하세요. 클라이언트에 DNS 캐시 삭제나 코어 재시작 기능이 있다면 설정을 수정한 뒤 실행하는 것도 좋습니다.

3단계: 시스템 프록시와 TUN 구분하기

시스템 프록시는 주로 HTTP 또는 SOCKS 프록시 설정을 따르는 프로그램에 영향을 줍니다. 일반적인 UDP 53번 DNS 조회는 시스템 프록시를 켰다고 해서 자동으로 Clash에 들어가지 않습니다. TUN 모드는 네트워크 계층에서 더 많은 트래픽을 받고, DNS 하이재킹 규칙을 통해 기존 DNS 조회를 코어에 전달할 수 있습니다. 따라서 같은 설정이라도 시스템 프록시 모드와 TUN 모드에서 테스트 결과가 다를 수 있습니다.

4단계: 코어 로그와 연결 기록 확인하기

테스트 중 클라이언트 로그를 열고 테스트 도메인, DNS, UDP, DoH 또는 규칙 일치 기록을 검색하세요. 로그에는 도메인이 fake-ip로 매핑되었는지, 특정 nameserver로 조회가 전송되었는지, 연결이 DIRECT·PROXY 같은 정책과 일치했는지가 표시됩니다. 이는 테스트 페이지의 지역 태그보다 직접적인 근거가 됩니다. 로그에 테스트 도메인이 전혀 없다면 조회가 현재 코어로 들어오지 않았을 가능성이 큽니다.

설정 파일 하나와 프록시 노드 하나를 고정합니다.
시스템 프록시, TUN, IPv6 및 브라우저 보안 DNS 상태를 기록합니다.
캐시를 삭제한 뒤 한 번 테스트를 실행합니다.
한 번에 하나의 옵션만 변경하고 다음 테스트를 진행합니다.
코어 로그, 연결 목록, 테스트 결과를 서로 대조합니다.

fake-ip와 redir-host의 경로 차이

Clash에서 자주 사용하는 향상된 DNS 모드에는 fake-ip와 redir-host가 있습니다. 두 모드 모두 코어가 도메인 조회에 관여하게 하지만 작동 방식은 다릅니다. 모드를 선택할 때는 규칙 일치, 로컬 네트워크 기기 호환성, 애플리케이션 동작을 함께 고려해야 하며, 테스트 페이지에 몇 개의 리졸버가 표시되는지만 봐서는 안 됩니다.

fake-ip: 예약 주소를 먼저 반환한 뒤 코어가 도메인을 복원

fake-ip 모드에서 Clash는 전용 주소 대역에서 매핑된 주소를 반환합니다. 애플리케이션이 이 주소로 연결을 만들면 코어가 매핑 테이블에서 원래 도메인을 찾아 도메인 규칙에 따라 정책을 선택합니다. 이를 통해 시스템이 실제 대상 IP를 먼저 얻은 뒤 프록시에 전달하는 상황을 줄이고, 도메인 규칙도 안정적으로 적용할 수 있습니다.

fake-ip라고 해서 모든 DNS 트래픽이 자동으로 가로채지는 것은 아닙니다. 애플리케이션이 Clash의 DNS 수신 포트로 조회를 보내거나 TUN의 DNS 하이재킹 규칙이 조회를 코어로 전달해야 합니다. 브라우저가 외부 DoH 서비스에 직접 접속하면 조회가 HTTPS 안에 캡슐화되므로, 일반적인 53번 포트 하이재킹으로는 그 안의 DNS 내용을 확인할 수 없습니다.

로컬 네트워크 이름, 프린터 검색, 네트워크 연결 확인, 일부 게임 플랫폼은 fake-ip와 호환되지 않을 수 있습니다. 이러한 도메인은 fake-ip-filter에 추가해 코어가 실제 주소를 반환하도록 하세요. 필터 범위는 실제 장애가 발생한 항목만 추가해야 하며, 지나치게 넓으면 fake-ip의 도메인 매핑 효과가 약해집니다.

redir-host: 실제 주소를 반환하면서 도메인 처리 유지

redir-host는 애플리케이션에 실제 해석 주소를 반환합니다. 실제 IP에 의존하는 일부 프로그램과는 호환성이 더 좋지만, 조회가 더 일찍 이루어지고 상위 DNS의 연결 가능 여부와 응답 결과에 더 크게 영향을 받습니다. 구형 Clash 클라이언트에서 흔히 사용된 모드이며, mihomo에서도 관련 설정을 처리할 수 있지만 새 설정은 클라이언트 기능과 네트워크 환경을 함께 테스트해야 합니다.

상위 DNS와 규칙 경로 수정하기

아래 설정은 각 필드의 역할을 설명하기 위한 예시이며, 기존 구독 설정을 그대로 덮어쓰면 안 됩니다. 지원되는 필드는 Clash 분기마다 완전히 같지 않습니다. 원본 Clash의 구형 코어는 일반적으로 enable, enhanced-mode, nameserver, fallback, fake-ip-filter 같은 기본 필드를 지원합니다. proxy-server-nameserver, direct-nameserver, nameserver-policy, respect-rules 등은 주로 최신 mihomo 코어에서 제공됩니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1

  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

  nameserver-policy:
    "geosite:private":
      - system
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query

  fake-ip-filter:
    - "*.lan"
    - "localhost"

default-nameserver는 시작 단계의 조회를 담당합니다

암호화된 DNS 주소 자체에는 보통 dns.alidns.com처럼 도메인 이름이 포함됩니다. 코어는 DoH 연결을 만들기 전에 먼저 해당 도메인의 주소를 알아내야 합니다. default-nameserver는 이러한 초기 조회를 주로 담당하며, 프록시 서버 도메인의 초기 해석에도 사용될 수 있습니다. 모든 서비스 도메인의 최종 상위 서버를 의미하는 것은 아니므로, 설정한 뒤에도 nameserver를 구성해야 합니다.

nameserver는 일반 조회의 진입점입니다

nameserver는 일반적인 도메인 조회에 사용할 상위 서버를 정의합니다. 여러 서버를 지정하면 연결 가능성이 높아지지만, 테스트에서는 여러 DNS 인프라가 동시에 관찰될 수도 있습니다. 요청이 어디에서 출발하는지 확인하는 것이 목적이라면 먼저 안정적인 상위 서버 하나만 남겨 경로를 확인한 뒤 예비 서버를 추가하세요.

DoH 또는 DoT를 사용하면 기존 DNS 패킷이 로컬 구간에서 평문으로 전송되는 것을 막을 수 있지만, 암호화 여부만으로 연결이 DIRECT인지 프록시인지 결정되지는 않습니다. 상위 서버 연결이 직접 연결로 나가면 출구는 여전히 현재 네트워크에 있습니다. 규칙에 따라 출구를 선택하게 하려면 코어가 해당 규칙 추적 기능을 지원하고 활성화했는지 확인해야 합니다.

proxy-server-nameserver는 노드 도메인을 처리합니다

구독에 포함된 프록시 서버는 고정 IP가 아니라 도메인 이름을 사용할 수 있습니다. 코어는 프록시 연결을 만들기 전에 노드 도메인을 먼저 해석해야 합니다. 노드 도메인 해석이 아직 연결되지 않은 프록시에 의존하면 순환이 발생합니다. mihomo의 proxy-server-nameserver는 이러한 조회에 사용할 리졸버를 명확히 지정합니다. 현재 네트워크에서 직접 접근할 수 있고 안정적인 상위 서버를 선택하세요.

nameserver-policy는 리졸버만 선택합니다

nameserver-policy는 도메인이나 규칙 세트에 따라 상위 서버를 선택할 수 있습니다. 예를 들어 사설 도메인은 시스템 리졸버에 맡기고, 특정 지역 도메인은 해당 리졸버를 사용하게 할 수 있습니다. 이 설정이 제어하는 것은 “어떤 DNS 서버에 조회할지”이지 “웹사이트 연결이 최종적으로 어떤 정책 그룹을 사용할지”가 아닙니다. 서비스 트래픽은 여전히 rules의 도메인·IP·규칙 세트·최종 규칙에 따라 결정됩니다.

예시에 사용된 geosite는 코어가 해당 규칙 데이터를 로드했다는 전제에 기반합니다. 클라이언트에 규칙 세트가 없거나 데이터 버전이 오래되었거나 규칙 이름이 존재하지 않으면 정책이 예상대로 일치하지 않을 수 있습니다. 이런 경우 먼저 명확한 도메인 접미사로 테스트한 다음 규칙 데이터의 출처와 업데이트 시점을 확인하세요.

fallback과 필터 조건은 신중하게 처리하기

기존 설정에서는 fallback과 지리적 IP 판정을 함께 사용해 해석 결과를 선택하는 경우가 많습니다. 잘못 설정하면 일반 상위 서버와 예비 상위 서버가 동시에 조회되어 테스트 페이지에 여러 DNS 서비스가 표시될 수 있습니다. 이는 반드시 우회가 아니라 병렬 조회 방식 때문일 수 있습니다. mihomo로 전환했다면 필요에 따라 nameserver-policy로 도메인을 명확히 나누어 해석하기 어려운 병렬 결과를 줄일 수 있습니다.

운영체제·브라우저·앱 내부 DNS 처리하기

Clash 코어 설정이 올바르다고 해서 모든 프로그램이 이를 사용하는 것은 아닙니다. DNS 요청은 시스템 리졸버, 브라우저 보안 DNS, 앱 내장 DoH, 가상 머신, 컨테이너 또는 로컬 네트워크의 다른 기기에서 발생할 수 있습니다. 문제를 해결할 때는 요청 출처를 기준으로 단계별 확인이 필요합니다.

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

시스템 프록시를 활성화하면 브라우저는 보통 HTTP 또는 HTTPS 연결을 프록시에 전달하지만, 시스템 서비스와 프록시 설정을 따르지 않는 프로그램은 여전히 직접 인터넷에 연결할 수 있습니다. 기존 DNS 조회는 주로 UDP 또는 TCP 53번 포트로 전송되며 HTTP 프록시로 자동 진입하지 않습니다. 사용하는 클라이언트가 시스템 프록시만 활성화하는 경우 일부 시스템 수준 조회가 네트워크 어댑터에 설정된 DNS를 계속 사용할 수 있음을 예상해야 합니다.

일부 클라이언트는 TUN을 활성화할 때 시스템 DNS를 자동으로 변경하거나 네트워크 서비스를 설치합니다. 이때 여러 네트워크 어댑터를 수동으로 서로 다른 DNS에 동시에 설정하면 충돌이 발생할 수 있습니다. 먼저 클라이언트 문서와 실행 로그를 확인해 DNS 설정을 클라이언트가 관리하는지 파악한 뒤 수동 변경 여부를 결정하세요.

브라우저 보안 DNS가 독립 경로를 만들 수 있습니다

최신 브라우저는 지정된 DoH 서비스에 직접 연결할 수 있습니다. 이 연결은 일반 HTTPS 트래픽처럼 보이므로 시스템 리졸버를 우회할 수 있고 dns-hijack: any:53에도 포착되지 않습니다. Clash 내장 DNS를 테스트할 때는 브라우저 보안 DNS를 잠시 시스템 설정 따르기로 바꾸고, 브라우저 DNS 캐시를 삭제한 뒤 다시 테스트하세요.

브라우저 DoH를 계속 사용해야 한다면 독립적인 DNS 방식으로 취급해야 합니다. 이 경우 DoH 서비스 도메인에 적용되는 프록시 규칙, 연결 출구, 실패 시 대체 동작을 확인해야 하며, Clash의 fake-ip 설정이 브라우저 내부 조회까지 가로챌 것이라고 기대해서는 안 됩니다.

IPv6는 별도로 확인해야 합니다

Clash DNS 설정에서 ipv6를 끄는 것은 일반적으로 애플리케이션에 AAAA 결과를 반환하지 않는다는 뜻일 뿐, 운영체제의 IPv6 네트워크를 자동으로 끄지는 않습니다. 애플리케이션이 캐시에 있는 IPv6 주소를 계속 사용하거나 자체 리졸버로 AAAA 레코드를 가져올 수도 있습니다. IPv6 환경에서만 테스트 이상이 발생한다면 시스템 IPv6, 코어의 IPv6 지원, 프록시 노드 기능, 규칙의 IPv6 경로를 각각 확인하세요.

테스트 페이지에 하나의 결과만 표시되게 하려고 시스템 전체의 IPv6를 영구적으로 끄는 방법은 권장하지 않습니다. 먼저 통제된 테스트로 문제가 실제 IPv6에서 비롯되었는지 확인한 뒤, 노드와 네트워크의 지원 여부에 맞게 조정하는 편이 더 안전합니다.

로컬 네트워크와 컨테이너는 호스트 리졸버를 사용하지 않을 수 있습니다

가상 머신, Docker 컨테이너, Android 에뮬레이터와 로컬 네트워크 기기는 별도의 DNS 설정을 사용하는 경우가 많습니다. 호스트에서 실행 중인 Clash가 조회를 올바르게 가로채더라도 이러한 환경은 라우터나 외부 서버로 직접 요청을 보낼 수 있습니다. 다른 기기에서 Clash DNS를 사용하게 하려면 수신 주소, 방화벽, 로컬 네트워크 접근 권한도 확인해야 합니다. 루프백 주소에만 바인딩한 뒤 다른 기기가 접속할 수 있다고 기대해서는 안 됩니다.

TUN 모드에서 DNS 하이재킹과 라우팅 순서 확인하기

TUN 모드는 시스템 프록시를 따르지 않는 트래픽도 받을 수 있어 시스템 수준의 DNS 우회를 처리하는 일반적인 방법입니다. mihomo 설정에서는 dns-hijack로 기존 53번 포트 조회를 가로채 내장 DNS 모듈로 전달할 수 있습니다. 실제 필드 동작은 클라이언트가 생성한 설정과 실행 권한의 영향도 받습니다.

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

auto-route는 라우팅을 자동으로 설정하고, auto-detect-interface는 코어가 현재 출구 네트워크 어댑터를 선택하도록 돕습니다. 유선·무선 네트워크, 다른 VPN 또는 가상 어댑터가 동시에 연결되어 있으면 자동 감지가 예상과 다른 인터페이스를 선택할 수 있습니다. DNS 시간 초과나 TUN 활성화 후 전체 네트워크 단절이 발생하면 nameserver만 바꾸지 말고 기본 경로와 인터페이스 변경을 확인하세요.

any:53은 주로 기존 DNS를 처리합니다. 외부 DoH를 복호화할 수 없으며 QUIC, 비공개 DNS 또는 애플리케이션이 직접 만든 터널이 내장 리졸버로 들어온다고 보장하지도 않습니다. 이러한 프로토콜은 앱 설정에서 DNS 동작을 통일하거나 도메인 및 네트워크 정책으로 관련 연결을 제어해야 합니다.

TUN을 활성화한 뒤에는 Clash가 상위 DNS에 접속할 때의 연결이 잘못 TUN으로 다시 전달되어 순환하지 않는지도 확인해야 합니다. 성숙한 클라이언트는 보통 코어 프로세스, 라우팅 마크 또는 아웃바운드 인터페이스를 별도로 처리합니다. 같은 DNS 요청이 로그에 반복해서 나타나다가 시간 초과되면 클라이언트의 서비스 모드, 코어 권한, 제외 규칙을 확인하세요.

테스트 증상에 따라 규칙과 설정 수정하기

테스트 결과에 여전히 로컬 통신사 DNS가 표시되면 무엇부터 바꿔야 하나요?

먼저 코어 로그에 테스트 도메인이 나타나는지 확인하세요. 기록이 없다면 브라우저 보안 DNS, 시스템 DNS, TUN 하이재킹을 우선 점검하고, 기록은 있지만 상위 연결이 DIRECT라면 nameserver, 규칙 추적 설정, 현재 정책을 확인하세요. 먼저 여러 예비 DNS를 추가하지 마세요. 결과 변수가 늘어납니다.

fake-ip를 사용해도 여러 DNS가 표시되는 이유는 무엇인가요?

fake-ip는 애플리케이션이 받은 주소의 매핑을 관리할 뿐, 코어가 하나의 상위 서버만 사용하도록 제한하지 않습니다. nameserver, fallback, nameserver-policy, 브라우저 DoH, 다른 앱이 모두 조회를 만들 수 있습니다. 먼저 상위 서버 하나만 남기고 브라우저의 독립 DoH를 끈 다음 설정을 항목별로 다시 활성화하세요.

TUN을 켠 뒤 DNS 테스트는 정상인데 일부 웹사이트가 열리지 않으면 어떻게 해야 하나요?

fake-ip-filter, 도메인 규칙, IPv6, 노드 연결 가능 여부를 확인하세요. 웹사이트가 로컬 네트워크 조회나 실제 IP를 요구한다면 필요한 도메인을 정확한 필터 목록에 추가할 수 있습니다. 연결 기록에서 잘못된 정책과 일치했는지도 확인해야 하며, DNS 해석 성공이 서비스 연결 성공을 의미하는 것은 아닙니다.

DoH 상위 서버는 반드시 프록시를 거쳐야 하나요?

반드시 그렇지는 않습니다. 중요한 것은 경로가 사용 목적과 일치하고 상위 서버에 안정적으로 연결되는지입니다. 직접 연결 DoH는 로컬 구간에서 DNS 내용을 보호할 수 있지만 출구는 여전히 현재 네트워크에 있습니다. 프록시로 DoH에 접속하면 해석 출구를 프록시 경로에 맞출 수 있지만, 코어의 규칙 처리를 지원해야 하며 노드 도메인 해석이 순환하지 않도록 해야 합니다.

구독을 업데이트한 뒤 DNS 설정이 다시 원래대로 돌아오면 어떻게 해야 하나요?

구독 파일은 보통 원격에서 생성되므로 직접 편집한 내용이 업데이트 때 덮어써질 수 있습니다. 클라이언트가 제공하는 오버라이드, 믹스인 또는 설정 패치 기능을 사용해 수정이 필요한 DNS 필드만 관리하세요. 업데이트 후에는 패치 파일만 보지 말고 최종 병합 설정을 확인해야 합니다.

최종 확인 목록

현재 활성화된 Profile과 편집 중인 파일이 일치합니다.
코어 유형과 버전이 사용하는 DNS 필드를 지원합니다.
테스트 도메인을 코어 로그에서 찾을 수 있습니다.
시스템 프록시와 TUN의 적용 범위를 구분했습니다.
브라우저와 앱 내장 DoH 상태를 확인했습니다.
nameserver, fallback, 정책 규칙이 목적 없이 중복 조회를 만들지 않습니다.
노드 도메인에 독립적이고 연결 가능한 시작 단계 해석 경로가 있습니다.
설정 변경 후 코어를 재시작하고 관련 캐시를 삭제했습니다.
IPv4, IPv6, 로컬 네트워크 기기를 각각 테스트했습니다.

DNS 보호의 목표는 모든 테스트 페이지에 하나의 고정된 이름만 표시되게 하는 것이 아닙니다. 조회 경로를 설명하고 제어할 수 있으며 프록시 규칙과 일치하게 만드는 것이 핵심입니다. 먼저 요청이 Clash로 들어오는지 확인하고, 다음으로 코어가 어떤 상위 서버를 선택하는지 확인한 뒤, 상위 연결과 서비스 트래픽의 출구 정책을 점검하세요. 이 순서대로 진행하면 여러 DNS 필드 사이에서 무작정 반복 테스트하는 일을 줄일 수 있습니다.