1. 블로그
  2. Clash DNS 설정 항목별 분석
예상 읽기 시간 9분

Clash DNS 설정 항목별 분석: nameserver, fallback, DNS 하이재킹 대응 파라미터 작성법

DNS 항목은 Clash/Clash Meta 설정 파일에서 가장 흔하게 복사-붙여넣기 되지만 제대로 이해되는 경우는 드문 부분입니다. 이 글에서는 enhanced-mode의 두 가지 동작 방식부터 시작해 nameserverfallback이 각각 어떤 역할을 하는지, fallback-filter가 도메인 오염 여부를 어떻게 판단하는지 살펴보고, 마지막으로 줄별 주석이 달린 그대로 적용 가능한 템플릿을 제공합니다.

DNS 항목이 해결하는 문제

프록시 소프트웨어 자체는 도메인을 해석하지 않습니다. 프록시는 트래픽을 전달할 뿐이며, 트래픽이 프록시로 들어가기 전에 시스템이나 애플리케이션이 먼저 도메인을 IP로 변환해야 합니다. 이 단계에서 현지 통신사 DNS를 사용하면 두 가지 대표적인 문제가 발생합니다. 첫째, 해석 결과가 오염되거나 하이재킹되어 잘못된 IP가 반환됩니다. 둘째, 해석 동작 자체가 접속 의도를 노출시킵니다. 이후 트래픽이 프록시를 통과하더라도 DNS 요청은 평문 UDP 53번 포트로 전송될 수 있어 중간 장비에 기록되거나 차단될 수 있습니다. Clash의 dns 설정 항목은 바로 이 해석 과정을 인계받아, 도메인 해석과 트래픽 전달을 동일한 규칙 체계 안에서 처리하도록 만들어줍니다.

이 모듈은 두 부분으로 구성됩니다. enhanced-mode는 도메인을 IP로 변환하는 방식을 결정하고, nameserver/fallback 파라미터 그룹은 실제 해석 요청을 보낼 때 어떤 상위 서버를 어떤 순서로 시도할지를 결정합니다. 두 가지가 함께 작동해야 규칙 분기가 정확하게 매칭되면서도 해석 결과가 오염되는 것을 막을 수 있습니다.

enhanced-mode: fake-ip와 redir-host, 무엇을 선택할까

enhanced-mode는 값이 두 가지뿐이지만 동작 방식은 크게 다릅니다.

  • fake-ip: Clash가 DNS 쿼리를 가로챈 뒤 즉시 실제 IP를 요청하지 않고, 전용 주소 대역(기본값 198.18.0.0/16)에서 가짜 IP를 할당해 애플리케이션에 반환합니다. 애플리케이션이 이 가짜 IP로 연결을 시도하면 Clash가 연결이 수립되는 순간 실제 도메인을 역으로 조회하여 규칙에 따라 어떤 프록시 그룹을 사용할지 결정합니다. 이 방식은 분기 기준이 항상 도메인이며 변할 수 있는 IP가 아니기 때문에 규칙 매칭이 가장 정확하며, 현재 주요 클라이언트(mihomo 커널 계열)의 기본값이자 공식 권장 설정이기도 합니다.
  • redir-host: 상위 서버에 직접 실제 IP를 요청하고 그대로 반환합니다. 호환성이 더 좋으며, 특히 실제 IP로 지역을 판단하는 일부 애플리케이션(특정 동영상, 지도 앱)은 가짜 IP 대역을 받으면 동작이 비정상적으로 되는데, 이런 경우에만 redir-host로 전환하면 됩니다. 대신 규칙 매칭이 IP 대역 기준으로 후퇴하기 때문에 도메인 기반의 세밀한 분기 효과는 떨어집니다.

특별한 호환성 문제가 없다면 fake-ip를 일괄적으로 사용하고, fake-ip-filter를 통해 로컬 네트워크 주소, 내부망 서비스, 실제 IP를 적극적으로 사용하는 도메인(일부 은행, 로컬 네트워크 기기 탐색 프로토콜 등)을 가짜 IP 할당 대상에서 제외해 해당 도메인은 계속 실제 해석을 거치도록 하는 것이 좋습니다.

nameserver와 fallback의 역할 분담

많은 사람이 nameserverfallback 모두에 그냥 여러 DNS 서버 주소를 채워 넣지만, Clash가 실제로 이들을 어떻게 사용하는지는 잘 모릅니다. 실제 동작 로직은 다음과 같습니다.

  1. nameserver가 먼저 조회

    모든 도메인은 기본적으로 nameserver에 지정된 서버로 먼저 해석을 시도합니다. 여기에는 보통 신뢰할 수 있는 현지 공용 DNS를 지정하며, 통신사가 전송 계층에서 쿼리 내용을 그대로 보고 하이재킹하는 것을 막기 위해 평문 UDP 대신 DoH/DoT 사용을 권장합니다.

  2. fallback-filter로 재검증 필요 여부 판단

    nameserver가 반환한 결과를 받은 뒤, fallback-filtergeoip 검사가 활성화되어 있으면 Clash는 이 IP가 geoip-code에 지정된 국가/지역(일반적으로 CN)에 속하는지 판단합니다. 속한다면 결과를 그대로 채택하고, 속하지 않는다면 이 도메인이 해외 리소스인데 잘못되었거나 비정상적인 IP로 해석되었을 가능성이 크다고 보고 다음 단계를 트리거합니다.

  3. fallback으로 재검증 확정

    재검증이 필요하다고 판단되면 Clash는 fallback 목록에 있는 서버로 다시 해석을 시도합니다. 여기에는 보통 해외 서버이거나 오염 방지 능력이 더 강한 DoH/DoT 서버를 지정하며, 이때 얻은 결과가 그대로 최종 해석 결과로 사용됩니다.

nameserver는 기본 채널로서 효율을 담당하고, fallback은 검증 채널로서 오류 수정을 담당하며, fallback-filter는 이 둘 사이의 심판 역할을 합니다. 셋 중 하나라도 빠지면 DNS 항목의 오염 방지 능력이 떨어집니다. nameserver만 있고 fallback이 없으면 오염이 발생해도 수정할 수 없고, fallback만 있고 nameserver가 없으면 모든 요청이 해외 서버로 전송되어 현지 사이트 해석 지연이 눈에 띄게 늘어납니다.

주의

fallback-filtergeoip 판단은 내장되거나 다운로드된 GeoIP 데이터베이스에 의존합니다. 최초 실행 시나 데이터베이스가 만료된 경우 이 기능이 일시적으로 작동하지 않을 수 있으며, 일부 해외 도메인의 해석 결과가 비정상적으로 나타나는 형태로 드러납니다. 클라이언트의 GeoIP 데이터베이스가 정상적으로 사용 가능한 상태인지 확인하는 것이 DNS 관련 문제를 진단하는 첫 단계입니다.

DNS 하이재킹의 증상과 fallback-filter 외의 대응 방법

일부 네트워크 환경에서는 통신사 장비를 거치는 평문 DNS 쿼리(UDP 53번 포트)에 하이재킹이나 캐시 포이즈닝을 가합니다. 흔한 증상은 해외 사이트에 접속할 때 관련 없는 국내 IP로 해석되거나, 존재하지 않는 주소가 그대로 반환되어 연결이 타임아웃되는 것입니다. 이런 하이재킹은 전송 계층에서 발생하며 Clash의 규칙 설정과는 무관합니다. 유일하게 효과적인 대응 방법은 DNS 쿼리 자체를 암호화 채널로 전송하는 것입니다.

  • https:// 접두사를 사용하는 DoH(DNS over HTTPS) 주소를 사용하면 쿼리가 443번 포트를 통해 전송되어 일반 HTTPS 트래픽과 섞이므로 단독으로 식별해 차단하기 어렵습니다.
  • tls:// 접두사를 사용하는 DoT(DNS over TLS) 주소를 사용하면 쿼리가 853번 포트를 통해 암호화되어 전송되어 마찬가지로 평문 하이재킹을 회피할 수 있지만, 853번 포트 자체가 별도로 속도 제한이나 차단을 당하는 경우가 있어 호환성은 DoH보다 다소 떨어집니다.
  • nameserver/fallback에 평문 UDP 주소(프로토콜 접두사 없는 8.8.8.8 형태)를 섞어 쓰지 않도록 합니다. 일부 네트워크 환경에서는 평문 주소가 있어도 없는 것과 마찬가지로 보호 효과가 없습니다.

또한 default-nameserver 필드에 주의해야 합니다. 이 필드는 nameserver/fallback에 지정된 DoH/DoT 서버 자체의 도메인을 해석하는 데 전용으로 사용됩니다(예: doh.pub이라는 도메인이 어떤 IP를 가리키는지 해석). 반드시 순수 IP 주소만 입력해야 하며 도메인 형태의 DoH 주소를 다시 지정하면 순환 해석이 발생해 DNS 모듈이 시작되지 못합니다.

그대로 적용 가능한 dns 설정 템플릿

다음 템플릿은 mihomo 커널(Clash Meta 계열 클라이언트는 모두 이 커널을 기반으로 함)에 적용되며, 각 필드의 역할을 줄마다 주석으로 설명했습니다. 설정 파일의 dns 항목 전체를 이 내용으로 바로 교체할 수 있습니다.

dns:
  enable: true                      # DNS 인계 활성화, 끄면 시스템 기본 해석으로 되돌아감
  ipv6: false                       # IPv6 네트워크를 사용하지 않는다면 꺼서 불필요한 쿼리를 줄이는 것을 권장
  enhanced-mode: fake-ip            # 규칙 매칭이 가장 정확한 모드, 호환성 문제 시 redir-host로 변경
  fake-ip-range: 198.18.0.1/16      # 가짜 IP 할당 대역, 실제 로컬 네트워크 대역과 충돌하지 않으면 됨
  fake-ip-filter:                   # 아래 도메인은 실제 해석을 사용, 가짜 IP 미할당
    - "*.lan"
    - "+.local"
    - "time.*.com"
    - "*.market.xiaomi.com"
  default-nameserver:                # 아래 DoH/DoT 서버 자체의 도메인 해석 전용, 순수 IP여야 함
    - 223.5.5.5
    - 119.29.29.29
  nameserver:                        # 기본 해석 채널, 국내 DoH 우선
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  fallback:                          # 검증/오류 수정 채널, 해외 도메인 해석 이상 시 사용
    - https://1.1.1.1/dns-query
    - tls://8.8.8.8:853
  fallback-filter:
    geoip: true                      # 지리적 위치 검증 활성화
    geoip-code: CN                   # 해석 결과가 해당 지역에 속하지 않으면 fallback 재검증 트리거
    ipcidr:                          # 아래 대역에 해당하면 비정상으로 간주, 즉시 fallback 트리거
      - 240.0.0.0/4
    domain:                          # 아래 도메인은 nameserver 판단을 거치지 않고 항상 fallback 사용
      - "+.google.com"
      - "+.youtube.com"

사용할 때는 fake-ip-filterfallback-filter.domain의 예시 항목을 실제로 특별 처리가 필요한 도메인으로 교체하면 됩니다. 나머지 필드는 대부분의 경우 수정할 필요가 없습니다.

자주 발생하는 문제 진단 방법

dns 설정을 변경한 후 인터넷 연결이 전혀 되지 않는다면?

먼저 default-nameserver에 순수 IP가 입력되어 있는지, 도메인 형태의 DoH 주소가 들어가 있지 않은지 확인하세요. 이는 가장 흔한 순환 해석 문제입니다. 다음으로 YAML 들여쓰기가 올바른지 확인하세요. dns 항목은 계층 구조 요구가 엄격해서 공백 하나만 어긋나도 전체 설정이 무시될 수 있습니다.

fake-ip 모드에서 특정 앱이 계속 연결에 실패하는데, DNS 문제일까요?

대부분 해당 앱이 서버 주소를 자체 검증하거나 IP 대역을 화이트리스트로 판단하기 때문입니다. 해당 도메인을 fake-ip-filter에 추가해 실제 해석을 사용하도록 하면 대개 해결됩니다. 비슷한 문제가 반복적으로 발생한다면 전체적으로 redir-host로 전환하는 것도 고려할 수 있습니다.

해외 사이트 접속이 여전히 느린데, fallback이 작동하지 않는 걸까요?

먼저 프록시 규칙 자체가 올바른 프록시 그룹에 매칭되는지 확인하세요. DNS 해석은 정상인데 잘못된 정책 그룹으로 연결되어도 마찬가지로 느리게 느껴질 수 있습니다. 규칙 문제가 아니라면 fallback 서버의 연결 상태를 점검하고, 필요하면 다른 사용 가능한 DoH/DoT 주소로 교체하세요.

Clash 클라이언트 다운로드