Clash DNS 설정 완전 해설: nameserver·fallback와 DNS 하이재킹 파라미터 작성법

Clash가 DNS를 직접 처리하는 이유

일반적인 인터넷 이용 과정에서는 기기가 도메인 요청을 보내면 시스템이나 라우터에 설정된 DNS 서버가 이를 IP로 변환하고, 그 IP로 목적지 서버에 접속합니다. 이 단계의 DNS 요청 자체가 프록시를 거치지 않는다면 통신사나 중간 네트워크 장비가 어떤 도메인을 조회하는지 파악하거나, 심지어 잘못된 해석 결과를 돌려줄 수 있습니다. 흔히 말하는 DNS 오염이나 DNS 하이재킹이 바로 이 지점에서 발생합니다. 규칙 기반 분기 역시 정확한 도메인 정보에 의존합니다. 클라이언트가 받은 도메인의 IP를 신뢰할 수 없다면 DOMAIN-SUFFIX, GEOIP 같은 규칙으로 내린 분기 판단도 왜곡됩니다.

Clash와 Clash Meta(mihomo 코어)는 설정 파일 안에 독립적인 DNS 모듈을 내장하고 있어, 도메인 해석 단계까지 프록시 체계 안에서 통합 관리할 수 있으며, 해석 권한을 시스템 네트워크 설정에 완전히 넘기지 않아도 됩니다. 이 모듈은 dns 필드로 전체를 제어하며, 그중 nameserver, fallback, enhanced-mode가 가장 핵심적인 세 가지 설정 항목입니다. 이 셋을 제대로 조합해야 해석 속도를 보장하면서도 오염이나 하이재킹을 피할 수 있습니다.

nameserver와 fallback: 두 그룹의 DNS 서버가 담당하는 역할

Clash의 DNS 항목에서는 보통 두 그룹의 서버 주소를 볼 수 있는데, 각각 nameserver와 fallback 필드에 적습니다. 이 둘은 단순한 주-보조 관계가 아니라 서로 다른 역할을 맡는 두 개의 해석 통로입니다.

nameserver: 기본 해석 경로

nameserver는 일상적인 해석이 지나가는 첫 번째 통로입니다. 여기에 적힌 서버 주소가 대부분의 도메인 요청을 처리하며, 규칙 판단 자체도 이 결과를 사용합니다. 한국 국내 환경이라면 통신사 DNS나 공공 DNS(예: KT/ISP 제공 DNS, 8.8.8.8 등)를 적어 국내 사이트 접속 시 해석 속도가 충분히 빠르도록 하는 것이 일반적이며, 굳이 프록시를 한 바퀴 거쳐 돌아올 필요가 없습니다.

fallback: 백업 및 해외 도메인 해석 경로

fallback은 일종의 백업 통로입니다. fallback-filter와 함께 쓸 때 흔한 방식은, 먼저 nameserver로 도메인을 해석하고 반환된 IP가 fallback-filter.geoip-code에 지정한 국가 범위(보통 KR이나 CN)에 속하는지 확인하는 것입니다. 만약 해당 IP가 국내 IP 범위가 아니라면 이 도메인은 프록시를 거쳐야 하는 해외 사이트일 가능성이 높으므로, 이때는 fallback에 설정한 해외 DNS(예: 1.1.1.1, 8.8.8.8)로 다시 해석해, 국내 DNS로 해외 도메인을 해석할 때 생기는 응답 지연이나 부정확한 해석 결과를 피할 수 있습니다.

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.8.8:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

여기서 default-nameserver는 더 기초적인 통로로, nameserver와 fallback 필드에 도메인 형태로 적힌 DNS 서버 주소(예: 일부 DoH 주소가 도메인으로 표기된 경우)를 해석하는 데만 쓰입니다. 이 필드는 반드시 순수 IP만 적어야 하며, 아직 구축되지 않은 해석 경로에 의존해 자기 자신을 해석하는 순환 구조를 만들면 안 됩니다.

fake-ip와 redir-host: 두 해석 모드 중 무엇을 선택할까

enhanced-mode는 Clash가 해석해낸 도메인 정보를 이후의 프록시·규칙 모듈에 어떻게 넘길지를 결정합니다. 흔히 쓰는 값은 fake-ip와 redir-host인데, 두 모드의 동작 방식과 적합한 상황은 크게 다릅니다.

fake-ip 모드

fake-ip 모드에서는 Clash가 도메인을 해석해낸 실제 IP를 애플리케이션에 바로 넘기지 않고, 먼저 사설 IP 범위 안에 있는 가짜 IP를 돌려줍니다. 애플리케이션이 이 가짜 IP로 연결을 시도하면 트래픽은 먼저 Clash로 들어오고, Clash 내부에서 가짜 IP를 원래 도메인으로 다시 매핑한 뒤 규칙에 따라 실제 출구와 목적지 주소를 결정합니다. 이 모드는 해석 속도가 빠르고 TUN 모드와 결합해 전역 투명 프록시를 구현하기 쉬워, 현재 대부분의 데스크톱 클라이언트와 라우터 환경에서 기본값으로 채택되어 있습니다. 다만 IP에 강하게 의존하는 일부 애플리케이션(예: 직접 연결 IP를 검증해야 하는 서비스, 로컬 네트워크 기기 탐색 등)에서는 문제가 생길 수 있어, 이런 경우 보통 해당 도메인이나 IP 범위에 별도의 직결 규칙을 두거나, fake-ip-filter 제외 목록에 추가해 가짜 IP 처리를 건너뛰게 합니다.

redir-host 모드

redir-host 모드는 예전 방식입니다. Clash가 도메인을 해석한 실제 IP를 그대로 애플리케이션에 돌려주고, 프록시 판단은 애플리케이션이 연결할 때 함께 보내는 Host 헤더나 SNI 정보에 의존합니다. 이 모드는 호환성이 더 좋아 가짜 IP로 인한 문제가 잘 생기지 않지만, 해석·전달 효율은 fake-ip보다 떨어지고, 명확한 도메인 정보를 담지 않는 프로토콜(예: 순수 IP 통신 기반의 일부 애플리케이션)에서는 분기 정확도가 낮아집니다. 현재 주류 Clash Meta / mihomo 코어 클라이언트는 fake-ip를 권장 설정으로 삼고 있으며, redir-host는 과거 설정이나 특수한 호환성 상황에서의 대안으로 남아 있습니다.

DNS 하이재킹 관련 파라미터, 어떻게 이해하고 설정할까

nameserver와 fallback의 기본 역할 외에도, Clash의 DNS 항목은 DNS 하이재킹에 대응하고 해석 안전성을 높이기 위한 몇 가지 전용 파라미터를 제공합니다. 이들의 역할을 이해하면 "웹페이지가 안 열리는데 프록시는 분명히 작동 중"인 유형의 문제를 파악하는 데 도움이 됩니다.

암호화 DNS 프로토콜 사용하기

평범한 udp:// 평문 DNS 요청을 그대로 쓰면 중간 네트워크 장비가 변조하거나 차단할 위험이 여전히 남습니다. nameserver나 fallback의 주소를 tls://(DNS over TLS)나 https://(DNS over HTTPS) 접두사로 바꾸면 DNS 요청 자체가 암호화된 통로를 지나게 되어 하이재킹·변조 가능성을 줄일 수 있습니다. 예를 들어 https://1.1.1.1/dns-query나 tls://8.8.8.8:853은 흔히 쓰는 표기법이며, 대부분의 mihomo 코어 클라이언트는 이 두 접두사를 기본으로 지원합니다.

listen과 로컬 네트워크 DNS 요청 하이재킹

dns.listen 필드는 Clash 내장 DNS 서비스가 대기할 로컬 포트(예: 0.0.0.0:1053)를 지정하는 데 씁니다. 시스템 프록시나 TUN 모드의 DNS 하이재킹 스위치와 함께 사용하면, 기기가 발생시키는 DNS 요청을 강제로 가로채 Clash로 넘길 수 있습니다. Clash를 우회해 시스템에 설정된 DNS 서버로 곧장 요청이 가는 일을 막아주는 것입니다. 특정 애플리케이션의 도메인 요청이 규칙을 전혀 거치지 않는다면, 이 하이재킹 단계가 작동하지 않아 애플리케이션이 하드코딩된 DNS 주소를 써서 시스템 해석 입구를 건너뛰고 있을 가능성이 큽니다.

nameserver-policy로 세밀하게 분기하기

특정 도메인만 별도의 DNS 서버로 해석해야 하는 상황(예: 회사 내부망 도메인은 반드시 내부 DNS를 써야 하고, 공공 DNS로 해석하면 잘못된 결과가 나오는 경우)에서는 nameserver-policy로 특정 도메인이나 도메인 접미사에 전용 해석 서버를 지정할 수 있습니다. 이 설정은 전역 nameserver보다 우선순위가 높습니다.

dns:
  nameserver-policy:
    "geosite:cn":
      - 223.5.5.5
    "+.corp.internal":
      - 10.0.0.53

이런 설정은 재택·사무실 혼용 근무나 내부망과 외부망이 함께 존재하는 환경에서 흔히 쓰이며, 내부 서비스가 잘못된 경로로 해석되어 접속되지 않는 문제를 막아줍니다.

DNS 설정이 실제로 적용되는지 확인하기

설정을 마친 뒤 "웹페이지가 열리니 됐다" 같은 모호한 판단에만 의존하지 말고, 아래 단계를 따라 하나씩 확인해 보는 것이 좋습니다.

1. 클라이언트의 연결 로그나 DNS 조회 기록 확인하기: 대부분의 그래픽 클라이언트(예: Clash Verge Rev)는 "연결" 또는 "로그" 패널에서 실시간 도메인 해석 요청을 볼 수 있어, 목적 도메인이 실제로 Clash를 거쳤는지, 우회되지 않았는지 확인할 수 있습니다.
2. 명령줄 도구로 해석 결과 대조하기: 터미널에서 nslookup 목표도메인 127.0.0.1 -port=1053을 실행합니다(포트는 실제 dns.listen 설정값으로 바꿔야 합니다). 반환값이 가짜 IP인지 실제 IP인지를 보고 설정한 enhanced-mode와 일치하는지 확인합니다.
3. 국내·해외 사이트 분기가 예상대로 동작하는지 테스트하기: 명확히 국내 사이트 하나와 해외 사이트 하나에 각각 접속해, 규칙 로그를 함께 확인하며 전자는 직결, 후자는 프록시 노드를 거치는지 확인합니다. 둘 다 같은 경로를 타면 안 됩니다.
4. 해석 정보 유출 여부 점검하기: 일부 애플리케이션은 자체 DNS 로직을 내장해 시스템 설정을 우회합니다. 특정 애플리케이션이 실제 해석 요청을 유출한다고 의심되면, 해당 애플리케이션의 네트워크 권한을 일시적으로 끄거나 방화벽 규칙으로 DNS 트래픽만 따로 관찰해 실제로 Clash로 하이재킹되는지 확인할 수 있습니다.

흔한 오해와 문제 해결 방법

실제 설정 과정에서 반복적으로 나타나는 몇 가지 오해가 있는데, 미리 알아두면 문제 해결 시간을 크게 줄일 수 있습니다.

• fallback을 주 DNS처럼 쓰는 경우: fallback-filter 설정이 잘못되었거나 빠져 있으면 모든 요청이 fallback으로 판정될 수 있고, 그러면 국내 사이트 해석 속도가 오히려 느려집니다. 이때는 geoip-code가 제대로 적혀 있는지 확인해야 합니다.
• 암호화·비암호화 DNS를 섞어 쓰면서 타임아웃 정책을 통일하지 않은 경우: 암호화 DNS 요청은 평문 요청보다 보통 조금 더 오래 걸립니다. 클라이언트의 타임아웃 설정이 너무 짧으면 간헐적으로 해석이 실패할 수 있으니, 클라이언트의 DNS 타임아웃 값을 늘리거나 fallback 목록의 서버 수를 줄여보는 것이 좋습니다.
• IPv6이 해석 결과에 미치는 영향을 무시하는 경우: 일부 네트워크 환경은 IPv6을 활성화하고 있습니다. Clash의 ipv6 필드가 실제 네트워크 상태와 맞지 않으면 해석된 IP 유형과 실제로 연결 가능한 방식이 어긋날 수 있습니다. 자신의 네트워크 환경에 맞춰 ipv6: true 또는 false를 명시적으로 적고, 비워두지 않는 것을 권장합니다.
• 규칙에서 IP 범위 판단을 쓰는데 해석 모드는 fake-ip인 경우: fake-ip 모드에서는 애플리케이션이 받는 것이 가짜 IP입니다. 규칙이 실제 IP 범위(예: GEOIP)에 크게 의존한다면, 클라이언트 코어가 규칙 매칭 시 가짜 IP를 실제 IP로 되돌린 뒤 판단하는지 확인해야 합니다. 구현마다 처리 순서가 다를 수 있으니, 매칭이 이상하게 동작할 때는 일단 redir-host 모드로 전환해 비교해 보는 것도 방법입니다.

DNS 항목 설정은 한 번에 완벽하게 끝내지 않아도 됩니다. 먼저 기본적인 nameserver + fallback + fake-ip 조합으로 돌려보고, 실제 사용 중 마주치는 구체적인 문제(특정 애플리케이션이 연결되지 않음, 특정 내부망 서비스의 해석 오류 등)에 따라 파라미터를 하나씩 추가·수정하는 방식이 처음부터 모든 선택 필드를 한꺼번에 채우는 것보다 대체로 관리하기 쉽습니다.