고급 설정 예상 읽기 시간 14분

Clash DNS 설정 가이드: nameserver·fallback·fake-ip 및 DNS 하이재킹

Clash DNS 설정에서 nameserver와 fallback의 차이, fallback-filter 판정 기준, fake-ip와 redir-host 비교, TUN DNS 하이재킹 방법을 알아봅니다.

먼저 커널을 확인한 뒤 DNS를 설정하세요

Clash DNS 설정이 제대로 적용되려면 현재 커널이 해당 필드를 지원하는지, 앱의 DNS 요청이 실제로 커널에 전달되는지 확인해야 합니다. dns.enable을 true로 바꿔도 Windows의 모든 앱이 이 DNS를 사용하는 것은 아닙니다. 시스템 프록시를 켜도 시스템의 UDP 53 요청이 자동으로 처리되지는 않습니다.

Clash for Windows는 더 이상 유지 관리되지 않습니다. 이 프로그램은 클라이언트 인터페이스이며, 실제 연결 처리는 내장된 커널이 담당합니다. 구형 Clash, Clash Premium, Clash Meta(현재 명칭 mihomo)는 지원 기능이 서로 다릅니다. 이 글에서는 먼저 일반적인 DNS 필드를 설명한 다음 mihomo의 TUN 예제를 별도로 소개합니다. 새 커널용 설정 전체를 구형 클라이언트에 그대로 덮어쓰지 마세요.

  1. 클라이언트의 General(일반) 화면에서 커널 정보를 확인하세요. 화면에 표시되지 않으면 Logs(로그)에서 시작 기록을 살펴보세요.
  2. Profiles(프로필)에서 현재 선택된 프로필을 확인하고 먼저 복사본을 저장하세요. 구독을 업데이트하면 직접 수정한 내용이 덮어써질 수 있습니다.
  3. Mixin 또는 설정 덮어쓰기가 활성화되어 있는지 확인하세요. 문제를 해결할 때는 구독 원본 파일만 보지 말고 최종 적용된 설정을 확인해야 합니다.
  4. 한 번에 한 묶음의 설정만 변경하고, 다시 불러온 뒤 로그를 확인하세요. 알 수 없는 필드, 시작 실패 또는 리스닝 실패가 발생하면 이전에 정상 작동한 설정으로 되돌리세요.

DNS 기본 필드: 리스닝, 업스트림, 부트스트랩 DNS

아래는 문제 해결에 활용할 수 있는 기본 DNS 설정 예제입니다. 실제 주소를 반환하는 redir-host 모드를 사용합니다. 완성된 구독 설정이 아니므로 기존 설정의 최상위 항목에 병합해야 합니다. 덮어쓰기나 파싱 오류를 방지하려면 파일에 dns: 매핑을 하나만 두세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
필드 예시 값 기능 및 유의 사항
enable true 커널의 DNS 모듈을 활성화합니다. 이것만으로 모든 앱의 DNS 요청 경로가 바뀌지는 않습니다.
listen 127.0.0.1:1053 로컬 DNS 리스닝 주소이며, 이 컴퓨터에서만 사용할 수 있습니다. 이 글에서는 테스트 포트로 1053을 사용합니다.
ipv6 false 커널 DNS의 AAAA 응답 방식을 제어합니다. 시스템 IPv6 네트워크 어댑터를 비활성화하는 설정은 아닙니다.
default-nameserver 223.5.5.5 주로 DNS 업스트림 서버의 도메인을 확인해 암호화된 DNS 서버의 부트스트랩 문제를 해결하는 데 사용합니다.
nameserver DoH 주소 두 개 일반 도메인 조회에 사용하는 주요 업스트림입니다. 목록 순서대로 하나씩 재시도하는 방식은 아닙니다.

1053, 53, 7890은 서로 다른 용도입니다

일반 DNS 요청은 보통 53번 포트를 사용합니다. 이 예제에서는 기존 서비스와의 충돌을 피하기 위해 1053을 사용하지만, Windows 네트워크 어댑터의 DNS 주소 입력란에는 보통 사용자 지정 포트를 지정할 수 없습니다. 포트를 지정할 수 있는 조회 도구로 테스트하거나 TUN을 통해 DNS 요청을 커널에 전달하세요. 7890 같은 프록시 포트는 HTTP/SOCKS 등의 프록시 연결용이므로 DNS 포트로 사용할 수 없습니다.

DoH는 전송을 암호화하지만 연결 가능성까지 보장하지는 않습니다

https://dns.alidns.com/dns-query는 DNS over HTTPS 주소입니다. 커널은 먼저 DNS 서버 도메인의 IP 주소를 알아낸 뒤 HTTPS 연결을 설정해야 하므로 부트스트랩 DNS가 필요합니다. DoH는 조회 내용을 HTTPS로 암호화하지만, 서버는 자신에게 전송된 조회 내용을 볼 수 있습니다. 라우팅이 되지 않거나 인증서 검증에 실패하거나 시스템 시간이 잘못된 경우에는 DNS 조회도 실패합니다.

더 빠른 속도를 기대하며 업스트림 서버를 한 번에 10개 넘게 추가하지 마세요. 먼저 현재 네트워크에서 안정적으로 접속할 수 있는 DNS 서버 한두 개만 설정하고 응답을 확인한 뒤 다른 기능을 추가하세요. 여기에 나온 주소는 올바른 설정 형식을 보여 주기 위한 예시이며, 모든 통신사 네트워크에서 사용할 수 있거나 지연 시간이 낮다는 보장은 없습니다.

nameserver와 fallback: 시간 초과 시 대체만 하는 기능은 아닙니다

fallback은 첫 번째 DNS 서버가 응답하지 않을 때 두 번째 서버를 조회하는 기능으로 오해하기 쉽습니다. 하지만 Clash는 fallback-filter와 함께 결과를 판단해 어느 쪽을 채택할지 결정합니다. 업스트림을 두 그룹으로 설정하면 커널은 보통 두 그룹에 동시에 조회합니다. 일반 조회에서는 우선 nameserver 결과를 고려하고, 필터 조건에 따라 fallback 결과를 채택할지 결정합니다.

아래 설정은 기존 방식의 GeoIP 필터링 예제입니다. 앞 절의 dns 항목에 병합하고, 최상위에 두 번째 dns 항목을 만들지 마세요. GeoIP 판정은 커널에서 실제로 불러온 데이터베이스를 사용합니다.

  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - '+.example.com'

fallback-filter의 판정 순서 이해하기

  • domain: 지정한 도메인 조건에 일치하면 fallback 조회 결과를 우선 사용합니다. 여기의 +.example.com은 문법 설명을 위한 예시용 예약 도메인입니다. 실제 설정에서는 필요한 도메인으로 바꾸거나 이 항목을 삭제하세요.
  • ipcidr: nameserver가 반환한 IP 주소가 지정한 대역에 포함되면 fallback 결과로 바꿀 후보로 판단합니다. 240.0.0.0/4는 흔히 쓰이는 예시일 뿐, 모든 비정상 주소 대역을 포함하지는 않습니다.
  • geoip: 활성화하면 geoip-code를 기준으로 주요 조회 결과가 지정한 지역에 속하는지 확인합니다. CN으로 설정하면 주요 결과가 CN에 속하지 않을 때 fallback 결과를 채택하는 로직이 작동합니다.

예를 들어 특정 도메인을 nameserver로 조회했을 때 데이터베이스에서 CN 주소로 판정되고 다른 필터 조건에 해당하지 않으면 일반적으로 해당 결과를 유지합니다. CN이 아닌 주소가 반환되면 fallback 결과를 사용합니다. 이는 판정 과정을 설명하기 위한 예시이지 실제 측정 결과가 아닙니다. CDN 주소, 데이터베이스의 지역 정보, 조회 결과는 달라질 수 있습니다.

DoH 서버를 fallback에 넣었다고 해서 반드시 프록시를 통해 연결되는 것은 아닙니다. DNS 업스트림의 아웃바운드 동작은 커널 종류, 버전 및 관련 설정에 따라 달라집니다. 현재 네트워크에서 해당 DNS 서버에 직접 연결할 수 없다면 먼저 연결 경로를 확인하세요. 문제 해결 대신 '해외 DNS로 변경'하는 방법에 의존하지 마세요. 별도의 필터링이 필요하지 않다면 nameserver만 사용해야 문제를 더 쉽게 찾을 수 있습니다.

fake-ip와 redir-host: 가상 주소와 실제 주소의 차이

두 모드의 핵심 차이는 앱에 반환되는 DNS 응답입니다. redir-host는 보통 업스트림에서 조회한 실제 주소를 반환하고 도메인과 주소의 관계를 기록합니다. 반면 fake-ip는 도메인에 가상 IP를 할당합니다. 커널은 해당 주소로 들어온 연결을 매핑해 도메인을 찾아낸 뒤 규칙을 적용하고 아웃바운드 연결을 처리합니다.

비교 항목 fake-ip redir-host
앱에 표시되는 주소 일반적으로 커널이 할당한 가상 주소입니다. 일반적으로 업스트림에서 반환한 실제 주소입니다.
도메인 식별 가상 주소 매핑으로 도메인을 복원하므로 투명하게 트래픽을 처리하는 환경에 적합합니다. DNS 조회 기록으로 매핑을 구성합니다. IP 주소를 여러 도메인이 공유하는 경우 판정이 복잡해질 수 있습니다.
호환성 확인 사항 DNS 결과를 직접 사용해 탐지하거나 LAN 장치를 찾는 프로그램은 예외 설정이 필요할 수 있습니다. 일반적인 DNS 동작에 가깝지만, 실제 주소를 더 일찍 확인해야 합니다.
테스트 방법 연결이 커널에 전달되는지와 도메인 매핑을 확인하세요. ping 성공 여부만으로 판단하지 마세요. 실제 조회 주소, 적용된 규칙, 이후 연결 상태를 확인하세요.

fake-ip 기본 설정 예제

  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'

198.18.0.0/16은 벤치마크 전용 주소 공간에 속하며, 대상 웹사이트의 실제 공인 IP 주소가 아닙니다. 조회 결과로 198.18.x.x가 표시되어도 DNS 오염으로 단정하지 마세요. fake-ip 모드에서는 의도된 결과일 수 있습니다. 앱의 연결은 이 매핑을 인식하는 커널을 계속 거쳐야 합니다. 그렇지 않으면 가상 주소로 정상적인 연결을 할 수 없습니다.

fake-ip-filter를 사용하면 지정한 도메인에는 가상 주소를 할당하지 않습니다. 하지만 해당 도메인에 직접 연결 규칙을 자동으로 만들지는 않습니다. LAN 도메인을 필터링한 뒤에도 이름을 확인할 수 있는 경로가 있어야 합니다. 특히 .local은 mDNS에 자주 사용됩니다. 멀티캐스트 검색의 정상 작동 여부는 시스템과 LAN 환경에도 영향을 받으므로 필터 목록에 추가하는 것만으로 해결되지는 않습니다.

fake-ip를 사용한다고 TUN이 반드시 필요한 것은 아닙니다. 중요한 점은 DNS 결과에 해당하는 연결이 커널로 전달되는지입니다. 반대로 TUN은 redir-host와 함께 사용할 수도 있습니다. 두 모드 사이를 전환한 뒤에는 시스템 DNS 캐시를 비우고 영향을 받는 앱을 다시 시작하세요. 이전에 저장된 실제 주소나 가상 주소가 계속 사용되는 것을 방지할 수 있습니다.

TUN DNS 하이재킹: 포트 53 요청을 커널에 전달하기

TUN은 가상 네트워크 인터페이스를 만들고 라우팅 조건에 맞는 IP 트래픽을 커널로 전달합니다. dns-hijack은 그중 DNS 요청을 감지해 내장 DNS 모듈로 전달합니다. 모든 DNS 패킷을 수정하거나 암호화된 트래픽을 해독하는 기능은 아닙니다. 먼저 요청이 TUN으로 들어와야 하이재킹 규칙이 처리할 수 있습니다.

mihomo의 UDP·TCP 53 설정 예제

아래는 mihomo에서 자주 사용하는 필드 조합이며, 활성화된 dns 설정과 함께 사용해야 합니다. 먼저 현재 커널이 해당 옵션을 지원하는지 확인하세요. 구형 Clash for Windows에 포함된 커널에는 그대로 적용하면 안 됩니다. Windows에서는 인터페이스와 라우팅을 설정하기 위해 클라이언트 서비스나 충분한 권한이 필요할 수 있습니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53
  • stack: mixed는 혼합 프로토콜 스택을 선택합니다. 커널 기능 옵션이며 모든 구형 버전에서 지원되는 범용 스위치는 아닙니다.
  • auto-route: true는 관련 라우팅을 자동 설정하지만 모든 앱과 네트워크 어댑터, 다른 VPN이 만든 경로까지 처리한다고 보장하지는 않습니다.
  • auto-detect-interface: true는 아웃바운드 인터페이스를 자동으로 감지합니다. 네트워크 어댑터가 여러 개이거나 가상 어댑터를 함께 사용하는 경우에는 별도로 확인해야 합니다.
  • any:53은 UDP 53 조회를 처리하고, tcp://any:53은 TCP 53을 추가로 처리합니다. 응답이 크거나 재시도하는 경우 TCP를 사용할 수 있습니다.

하이재킹을 켜도 다른 DNS 연결이 나타날 수 있는 이유

브라우저의 '보안 DNS'는 DoH 서버에 직접 연결할 수 있고, Android의 '비공개 DNS'는 보통 DoT를 사용합니다. 이는 일반적인 UDP/TCP 53 조회가 아니므로 위의 두 규칙이 해당 요청을 커널 DNS로 전환한다고 기대할 수 없습니다. 앱이 직접 보내는 DoH 요청은 일반 HTTPS 연결로 프록시에 전달될 수도 있습니다. 하지만 트래픽이 프록시를 거치는 것과 DNS 조회가 커널 DNS에 전달되는 것은 서로 다른 문제입니다.

문제를 확인할 때는 먼저 브라우저의 보안 DNS를 잠시 끄고 시스템 DNS 경로로 비교한 뒤 필요하면 다시 켜세요. 온라인 DNS 검사 페이지의 결과 한 번만으로 DNS 유출을 판단하지 마세요. 해당 페이지에는 재귀 DNS 서버의 외부 IP가 표시될 수 있으며, 이는 이 컴퓨터나 프록시 노드의 주소가 아닙니다. 연결 기록, 실제 아웃바운드 경로, 시스템 설정, 패킷 캡처 결과를 함께 확인하세요.

순서대로 점검하기: 리스닝, 조회, 트래픽 전달, 규칙

TUN을 켠 뒤 웹페이지가 열리지 않는다고 해서 노드, DNS, 프로토콜 스택을 한꺼번에 바꾸지 마세요. 아래 순서대로 확인하면 문제 발생 지점을 좁히고 DNS 조회 실패를 노드 문제로 오해하는 일을 줄일 수 있습니다.

  1. 리스닝 확인: 설정이 다시 불러와졌는지, 로그에 주소 사용 중 또는 권한 오류가 없는지 확인하세요. 이 글의 테스트 포트는 127.0.0.1:1053입니다. 실제 설정에서 다른 포트를 사용한다면 테스트 명령의 포트도 변경해야 합니다.
  2. 커널 DNS 직접 조회: 로컬 서버와 포트를 명시해 시스템 기본 DNS를 우회하세요. 조회에 실패하면 먼저 업스트림 연결, 부트스트랩 DNS, 설정 문법을 확인하세요.
  3. 기본 경로 확인: TUN을 켠 다음 서버를 지정하지 않고 조회해 보세요. 커널 로그와 비교하면 시스템 요청이 전달되는지 확인할 수 있습니다.
  4. 실제 연결 확인: 클라이언트의 연결 목록에서 대상 도메인, 적용된 규칙, 정책 그룹, 아웃바운드 노드를 확인하세요. DNS 조회는 성공했지만 연결 시간이 초과되면 규칙, 노드, 네트워크 경로를 계속 점검해야 합니다.

Windows에서 DNS 조회 및 캐시 비우기

명령 프롬프트에서 nslookup을 입력해 대화형 모드로 진입한 다음 아래 세 줄을 차례로 실행하세요. 기본 조회 예제로 example.com을 사용하며, 응답 값은 미리 정해 두지 않았습니다.

server 127.0.0.1
set port=1053
example.com

대화형 모드를 종료한 뒤 아래 명령으로 Windows DNS 캐시를 비울 수 있습니다. 브라우저에 별도의 캐시가 있을 수 있으므로 필요하면 완전히 종료한 후 다시 실행하세요.

ipconfig /flushdns

macOS 또는 Linux 조회 예제

dig가 설치된 시스템에서는 UDP와 TCP를 각각 테스트할 수 있습니다. 두 명령 모두 로컬 포트 1053에 직접 조회하므로 시스템 기본 DNS가 변경됐는지 확인하는 용도는 아닙니다.

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com A +tcp

자주 묻는 질문과 설정 마무리

시스템 프록시만 켰는데 DNS는 왜 시스템 설정을 따르나요?

시스템 프록시는 주로 프록시 설정을 따르는 앱에 영향을 주며, 시스템 DNS를 일괄 처리하지는 않습니다. 앱에 따라 로컬에서 DNS를 조회하거나 프록시에 조회를 맡길 수 있습니다. 일반 DNS 요청도 처리하려면 TUN과 DNS 하이재킹을 올바르게 설정하고 브라우저에 내장된 암호화 DNS도 별도로 확인하세요.

구독 업데이트 후 직접 수정한 nameserver가 사라지는 이유는 무엇인가요?

구독 파일은 새로 다운로드한 내용으로 교체되는 경우가 많습니다. 로컬 설정을 유지하려면 현재 클라이언트에서 지원하는 Mixin 또는 설정 덮어쓰기 기능을 사용하고 최종 병합 결과를 확인하세요. 클라이언트마다 목록을 교체하거나 추가하는 방식이 다를 수 있으므로 편집 화면에 내용이 저장되어 있는지만 확인해서는 안 됩니다.

fallback을 설정하면 모든 비정상 DNS 응답을 막을 수 있나요?

아니요. 필터링은 반환된 주소, 도메인 조건, GeoIP 데이터베이스, 업스트림 연결 가능 여부에 따라 달라집니다. 잘못된 응답이 필터 조건에 걸리지 않을 수 있고 정상적인 CDN 주소가 지역 필터에 걸릴 수도 있습니다. fallback 서버를 계속 추가하기보다 해당 도메인의 조회 기록을 확인해 설정을 조정하세요.

fake-ip에서 LAN 프린터나 NAS가 제대로 작동하지 않으면 어떻게 하나요?

먼저 장치의 실제 주소, LAN 도메인의 DNS 조회 경로, 직접 연결 규칙을 확인하세요. 호환성 문제가 확인된 도메인에만 fake-ip-filter를 설정하세요. 네트워크에서 mDNS, 브로드캐스트 검색 또는 사내 DNS를 사용하는 경우 로컬 검색 및 조회 경로도 유지해야 합니다.

마지막으로 네 가지를 확인하세요. DNS 리스너에 접속할 수 있는지, 업스트림 DNS 서버에 연결되는지, 앱의 DNS 요청이 예상한 경로로 전달되는지, 연결에 올바른 규칙이 적용되는지 점검합니다. 이 네 가지를 하나씩 검증한 다음 fallback 필터링, fake-ip 예외, 복잡한 도메인별 조회 설정을 추가하세요. 재현 가능한 기본 설정을 유지하면 구독을 업데이트하거나 클라이언트를 바꾼 뒤에도 설정을 쉽게 복구할 수 있습니다.

Clash 다운로드