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

Clash DNS 설정 완벽 가이드: nameserver, fallback 및 DNS 하이재킹 대응

Clash DNS 요청 경로, 주·보조 리졸버 역할, fallback 필터 조건과 주요 오류의 점검 순서를 정리합니다.

먼저 DNS 요청이 실제로 어디를 거치는지 확인하세요

Clash의 프록시 규칙은 연결을 직접 연결, 프록시 또는 차단 중 어디로 보낼지 결정하지만, 규칙을 판단하기 전에 일반적으로 도메인 조회 과정이 먼저 진행됩니다. 브라우저가 도메인에 접속하면 운영체제 리졸버를 호출할 수도 있고, 내장 암호화 DNS로 직접 조회를 보낼 수도 있습니다. 운영체제 리졸버는 다시 네트워크 카드에 지정된 DNS, 라우터 또는 Clash의 로컬 리스닝 포트로 요청을 전달합니다. 요청이 실제로 Clash DNS 모듈에 들어온 경우에만 설정의 nameserver, fallback, fake-ip가 적용됩니다.

일반적인 요청 경로는 다음과 같습니다. 애플리케이션이 도메인을 제출하면 시스템 또는 TUN이 DNS 조회를 가로채고, Clash가 정책에 따라 업스트림 리졸버를 선택합니다. 주소를 받은 뒤 프록시 규칙을 매칭하고, 마지막으로 직접 연결 또는 프록시 연결을 수립합니다. 애플리케이션이 시스템 리졸버를 우회하거나 로컬 네트워크 장치가 여전히 라우터로 DNS를 보내고 있다면, Clash 설정을 바꿔도 해당 요청의 결과는 달라지지 않습니다.

시스템 프록시만 활성화하면 HTTP 및 HTTPS 트래픽은 Clash로 들어올 수 있지만 DNS까지 함께 전달된다고 단정할 수는 없습니다. 일부 브라우저는 로컬에서 조회를 완료하고, 일부 SOCKS 클라이언트는 도메인 조회를 프록시 서버에 맡깁니다. TUN 모드는 적용 범위가 더 넓어 라우팅과 DNS 하이재킹으로 시스템 프록시 설정을 따르지 않는 프로그램까지 가로챌 수 있습니다. 다만 브라우저 보안 DNS, 가상 머신의 독립 네트워크, 로컬 네트워크의 다른 장치 같은 예외는 별도로 처리해야 합니다.

한 번의 조회를 구성하는 네 가지 계층

  1. 애플리케이션 계층: 브라우저, 명령줄 도구 또는 기타 소프트웨어가 시스템 DNS, 내장 DoH를 사용할지, 아니면 도메인을 SOCKS 프록시에 맡길지 결정합니다.
  2. 시스템 계층: 운영체제 캐시, 네트워크 카드 DNS, VPN 인터페이스 우선순위와 로컬 hosts 파일이 Clash보다 먼저 결과를 만들 수 있습니다.
  3. Clash DNS 계층: 리스닝 포트, 향상 모드, 주·보조 리졸버와 도메인 정책이 조회 방식과 반환 결과를 결정합니다.
  4. 연결 계층: Clash는 도메인, 대상 주소와 규칙 세트를 바탕으로 아웃바운드를 선택하며, 노드 도메인 자체에도 추가 조회가 필요할 수 있습니다.

문제를 점검할 때는 공용 DNS를 계속 바꾸기보다 계층별로 아래로 내려가며 확인하는 편이 효과적입니다. 특히 캐시에 주의하세요. 브라우저, 운영체제와 Clash가 모두 조회 결과를 저장할 수 있습니다. 설정을 바꾼 직후 같은 도메인을 테스트하면 이전 결과가 변경 사항을 가릴 수 있습니다. 먼저 설정을 다시 불러온 뒤 관련 캐시를 비우거나 레코드가 만료될 때까지 기다리세요.

dns, default-nameserver와 nameserver의 역할

이해하기 쉬운 기본 설정은 다음과 같습니다. 지원 필드는 기본 Clash, Clash Meta(현재는 보통 mihomo라고 부름) 및 클라이언트 통합 버전에 따라 달라질 수 있으므로, 실제 사용 시에는 현재 커널 문서와 설정 검증 결과를 기준으로 삼아야 합니다.

dns:
  enable: true
  listen: 0.0.0.0: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://cloudflare-dns.com/dns-query

enable 및 listen

enable: true는 커널 DNS 모듈을 활성화합니다. listen은 로컬 리스닝 주소와 포트를 지정합니다. 0.0.0.0에서 수신하도록 설정하면 모든 네트워크 인터페이스에서 요청을 받을 수 있으므로, 데스크톱 장치에서는 방화벽으로 외부 접근도 제한해야 합니다. 로컬에서만 명시적으로 사용할 경우에는 루프백 주소에서 수신하는 방법을 고려할 수 있습니다. TUN DNS 하이재킹을 커널이 전달하는 경우 구체적인 리스닝 방식은 클라이언트와 커널 구현에 따라 달라집니다.

포트 충돌은 설정을 시작하지 못하는 흔한 원인입니다. 53번 포트는 시스템 서비스, 컨테이너 도구 또는 다른 DNS 프로그램이 이미 사용 중일 수 있습니다. 따라서 데스크톱 클라이언트는 1053과 같은 비특권 포트를 사용한 뒤 TUN이나 시스템 설정으로 요청을 전달하는 경우가 많습니다. 사용 현황을 확인하지 않은 채 로컬 DNS 서비스를 두 개 동시에 실행하지 마세요.

default-nameserver: 업스트림 도메인을 위한 초기 조회

nameserver가 DoH 또는 DoT 도메인을 사용할 때는 암호화 연결을 수립하기 전에 해당 업스트림 호스트의 IP를 알아야 합니다. default-nameserver는 주로 이 초기 조회를 담당하며, 프록시 노드 도메인의 최초 조회에도 사용될 수 있습니다. ‘DNS 서버를 조회하려면 먼저 같은 DNS 서버에 접속해야 하는’ 순환을 피하려면, 호환성을 우선하는 설정에서는 직접 접근 가능한 IP 주소를 여기에 입력하는 경우가 많습니다.

default-nameserver는 일반 도메인 조회의 주요 응답 소스가 아닙니다. 많은 리졸버를 이 목록에 넣는다고 속도가 자동으로 빨라지지는 않으며, 오히려 결과 차이와 점검 난이도만 커질 수 있습니다. 네트워크에서 접근 가능하고 응답이 안정적인 리졸버를 소수만 선택하세요.

nameserver: 기본 주 리졸버

nameserver는 일반 조회에 사용하는 주요 업스트림입니다. 일반 UDP DNS를 사용할 수도 있고, 커널이 지원한다면 DoH나 DoT 같은 방식도 사용할 수 있습니다. 리졸버마다 CDN 주소, IPv6 레코드와 오염된 네트워크 환경에서의 동작이 다를 수 있습니다. 여러 업스트림을 하나의 목록에 넣으면 커널이 병렬 또는 내부 정책에 따라 요청하는 경우가 많지만, 이것이 고정 순서로 하나씩 시도하는 예비 방식과 같은 의미는 아닙니다.

리졸버 수는 필요 이상으로 늘리지 않는 것이 좋습니다. 업스트림이 많을수록 같은 도메인에서 서로 다른 CDN 주소가 반환되거나, 장애 재현이 어려워지거나, 일부 요청이 예상 경로를 우회할 가능성이 커집니다. 초기 설정에서는 주 리졸버 하나와 별도의 보조 리졸버 하나만 유지하고, 경로가 안정된 뒤 중복 구성을 추가하세요.

fallback과 fallback-filter의 조합 방식

fallback은 단순히 ‘주 서버가 시간 초과되면 보조 서버에 다시 묻는’ 기능이 아닙니다. 클래식 Clash 설정의 의미에서는 주 리졸버와 보조 리졸버가 동시에 조회에 참여할 수 있으며, 이후 fallback-filter가 현재 도메인이나 주 조회 결과를 보조 응답으로 바꿀지 판단합니다. 따라서 보조 주소를 무작정 추가하기보다 필터 조건을 이해하는 것이 중요합니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://cloudflare-dns.com/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    geosite:
      - gfw
    ipcidr:
      - 240.0.0.0/4
    domain:
      - "+.google.com"
      - "+.githubusercontent.com"

geoip 및 geoip-code

geoip를 활성화하면 커널은 주 조회 결과의 IP가 어느 지역에 속하는지 판단해 fallback 결과를 사용할지 결정합니다. 예를 들어 geoip-code: CN을 설정하면 주 조회 결과가 지정 지역과 일치하지 않을 때 보조 응답으로 전환될 수 있습니다. 이 방식은 지역에 따른 일부 조회 차이를 처리하는 데 유용하지만 GeoIP 데이터베이스의 정확성에 의존합니다. 클라우드 서비스, Anycast, CDN과 새로 할당된 주소는 예상과 다른 지역으로 분류될 수 있으므로, 지리적 판단을 절대적인 기준으로 보아서는 안 됩니다.

geosite 및 domain

geosite는 도메인 집합별로 fallback 사용 경향을 지정할 수 있으며, 실제 집합 지원 여부는 커널과 규칙 데이터에 따라 달라집니다. domain은 보조 리졸버를 반드시 사용해야 하는 소수의 도메인을 추가할 때 적합합니다. +. 접두사를 붙인 형식은 일반적으로 루트 도메인과 하위 도메인까지 매칭한다는 뜻이지만, 도메인 매칭 형식의 호환 범위는 버전에 따라 다르므로 설정 검증으로 확인해야 합니다.

많은 사이트를 domain에 하나씩 복사해 넣는 방식은 권장하지 않습니다. 목록이 길어질수록 유지 관리 비용이 커지고 nameserver-policy, 규칙 세트 또는 구독 설정과 충돌하기도 쉽습니다. mihomo를 사용한다면 도메인별로 리졸버를 지정하는 정책 필드를 먼저 검토해 용도를 명확히 표현하세요.

ipcidr

ipcidr은 특정 주소 범위를 비정상 결과 또는 fallback이 필요한 결과로 취급할 때 사용합니다. 예를 들어 예약 주소 대역이 일반 공용 도메인의 유효한 응답으로 반환되어서는 안 되는 경우 필터 조건에 추가할 수 있습니다. 이 필드는 명확히 관찰된 문제를 대상으로 사용해야 하며, 출처가 불분명한 대량의 네트워크 대역을 그대로 복사해서는 안 됩니다. 필터 범위가 지나치게 넓으면 정상적인 CDN 주소까지 계속 보조 경로로 빠져 지연이 늘고 결과가 불안정해질 수 있습니다.

fallback 사용 시 고려할 점

mihomo에서 세분화된 리졸버 역할 나누기

mihomo는 Clash 설정 체계에 DNS 제어 필드를 확장했으며, 대표적으로 nameserver-policy, proxy-server-nameserver, direct-nameserver가 있습니다. 이 필드들은 ‘업무 도메인, 프록시 노드 도메인과 직접 연결 도메인이 같은 조회 경로를 사용하면 안 되는’ 문제를 해결하는 데 적합하지만, 모든 구형 클라이언트가 이를 인식하는 것은 아닙니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  direct-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "+.example.net":
      - https://cloudflare-dns.com/dns-query

proxy-server-nameserver는 주로 프록시 노드 서버 자체의 도메인을 조회할 때 사용합니다. 노드 연결이 아직 수립되지 않은 상태에서 해당 노드를 통해서만 접근 가능한 DNS에 의존하면 시작 과정이 순환할 수 있습니다. 노드 도메인 조회에는 현재 네트워크에서 직접 접근 가능한 업스트림을 선택해야 합니다.

direct-nameserver는 직접 연결 아웃바운드와 관련된 도메인 조회에 사용하며, 직접 연결 사이트가 로컬 네트워크에 더 적합한 응답을 사용하도록 할 수 있습니다. 활성화 여부와 호출 시점, 규칙 매칭과의 관계는 커널 버전과 DNS 설정의 영향을 받습니다. 설정을 이전할 때는 YAML을 불러올 수 있는지만 보지 말고 실행 로그를 확인하세요.

nameserver-policy는 도메인이나 규칙 집합에 따라 업스트림을 지정하며, 통합 주·보조 구조보다 의도를 직접적으로 표현할 수 있습니다. 예를 들어 한국 국내 도메인은 로컬 리졸버로, 특정 업무 도메인은 별도의 암호화 리졸버 그룹으로 보낼 수 있습니다. 정책 사이에 적용 범위가 겹칠 수 있으므로 설정 전에 예상 매트릭스를 작성하세요. 어떤 도메인 유형이 어떤 업스트림을 거치고 어떤 아웃바운드를 사용하는지 정리한 뒤 항목별로 검증하면 됩니다.

fake-ip와 redir-host 선택하기

enhanced-mode는 Clash가 DNS 조회와 이후 연결을 어떻게 연결할지 결정합니다. 대표적인 모드는 fake-ip와 redir-host입니다. 두 방식 모두 커널이 도메인 정보를 유지하도록 돕지만 동작 방식은 다릅니다.

fake-ip: 예약 주소를 반환하고 도메인 매핑을 생성

fake-ip 모드에서 Clash는 조회 요청에 예약 주소를 할당합니다. 예를 들어 198.18.0.0/16 대역의 주소를 사용하고, 이 주소와 원래 도메인의 매핑을 기록합니다. 이후 애플리케이션이 해당 주소에 연결하면 트래픽을 Clash가 가로채고, 커널이 매핑에서 도메인을 복원해 규칙을 적용합니다. 일반적으로 도메인 규칙 매칭이 우수하며, 실제 주소를 먼저 받은 뒤 판단해야 하는 모호함도 줄일 수 있습니다.

fake-ip 주소는 Clash가 경로를 가로채는 환경에서만 의미가 있습니다. 트래픽이 Clash로 들어오지 않으면 시스템이나 다른 장치가 이 예약 주소에 직접 접속하려다 연결에 실패합니다. 로컬 네트워크 검색, 프린터, 게임 콘솔, 기업 인증, 시간 동기화와 실제 DNS 응답에 의존하는 일부 프로그램도 fake-ip와 호환되지 않을 수 있습니다.

dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "time.*.com"
    - "time.*.gov"

fake-ip-filter에 등록된 도메인은 fake-ip 반환 방식을 건너뛰고 실제 주소를 받습니다. 필터 항목은 실제 장애를 기준으로 조금씩 추가하세요. 지나치게 넓은 와일드카드를 사용하면 fake-ip의 도메인 매핑 장점이 약해지고, 일부 요청이 연결 전에 로컬 조회를 수행할 수도 있습니다.

redir-host: 실제 주소 반환

redir-host 모드는 일반적으로 클라이언트에 실제 IP를 반환하고 연결 단계에서 도메인을 최대한 연결합니다. 실제 주소가 필요한 장치와 프로그램에는 더 친화적이지만, 복잡한 전달, 연결 재사용 또는 대상 IP만 남는 상황에서는 도메인 규칙 인식이 fake-ip보다 불안정할 수 있습니다. 구체적인 동작은 sniffing, TUN 스택과 커널 버전의 영향도 받습니다.

데스크톱의 일반적인 사용 환경에서는 먼저 fake-ip를 테스트하세요. 로컬 네트워크 서비스, 기업 네트워크 또는 특정 애플리케이션과 호환되지 않으면 정확한 필터 항목을 우선 추가합니다. 문제가 광범위하고 안정적으로 필터링할 수 없다면 redir-host를 검토하세요. 모드를 전환한 뒤에는 DNS 캐시를 비우고 관련 애플리케이션을 다시 시작해야 합니다. 기존 fake-ip 기록이 모든 캐시 계층에서 즉시 사라지지는 않기 때문입니다.

TUN 모드에서 DNS 하이재킹 처리

여기서 말하는 ‘DNS 하이재킹’은 TUN 설정의 트래픽 가로채기 기능을 뜻합니다. 지정 포트로 향하는 DNS 요청을 Clash DNS 모듈로 리디렉션하는 것이며, 통신사가 조회 결과를 변조한다는 의미가 아닙니다. 애플리케이션이 네트워크 카드의 DNS나 라우터로 53번 포트 조회를 보내는 문제를 해결하는 기능입니다.

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

any:53은 대상 주소가 무엇이든 53번 포트로 향하는 기존 DNS 요청을 가로챈다는 뜻입니다. 커널 버전에 따라 다른 형식도 지원할 수 있습니다. 클라이언트 GUI가 이미 TUN 설정을 자동 생성한다면 여러 위치에서 동시에 같은 설정을 정의하지 마세요. 설정이 덮어써지거나 시작에 실패할 수 있습니다.

기존 DNS 하이재킹은 일반적으로 UDP 또는 TCP 53번 포트만 대상으로 하며, 브라우저가 외부 HTTPS 주소로 직접 접속하는 DoH를 자동으로 가로채거나 모든 DoT 요청을 투명하게 다시 쓸 수는 없습니다. 브라우저에서 독립적인 보안 DNS를 활성화하면 조회 결과가 시스템 도구와 다를 수 있습니다. 문제를 점검할 때는 먼저 브라우저가 시스템 리졸버를 사용하도록 임시 설정해 Clash 경로가 안정적인지 확인한 다음 브라우저 내장 설정을 유지할지 결정하세요.

가로채기에 실패하는 흔한 상황

게이트웨이 우회 라우터 환경에서는 DHCP로 내려오는 게이트웨이와 DNS도 확인해야 합니다. DNS 주소만 우회 라우터로 지정한다고 모든 연결이 우회 라우터를 거치는 것은 아닙니다. 게이트웨이만 우회 라우터로 지정해도 단말이 사용자 지정 암호화 DNS를 사용하지 않는다는 보장은 없습니다. 게이트웨이, DNS, 전달 규칙과 방화벽을 하나의 경로로 묶어 점검하세요.

DNS 오류를 단계별로 점검하는 순서

DNS 오류는 비슷한 증상으로 나타나지만 원인은 서로 다른 계층에 있을 수 있습니다. 다음 순서는 설정 로드, 리스닝 상태, 업스트림 접근성부터 규칙과 캐시까지 차례로 확인하는 방식으로, ‘웹페이지가 열리지 않음’, ‘일부 도메인 시간 초과’, ‘TUN 활성화 후 조회 불가’, ‘같은 사이트의 결과가 계속 바뀜’ 같은 문제에 적합합니다.

1단계: 현재 커널이 설정을 수락했는지 확인

먼저 클라이언트 로그와 설정 상태를 확인해 YAML 들여쓰기, 필드 형식과 프로토콜 주소에 오류가 없는지 점검하세요. 특히 목록 들여쓰기, 콜론 뒤 공백, 도메인 규칙의 특수 문자와 구형 커널이 지원하지 않는 새 필드에 주의해야 합니다. GUI 클라이언트에는 구독 원본 설정, 오버라이드 설정과 런타임 병합 설정이 동시에 존재할 수 있으므로 최종 적용 설정을 기준으로 확인하세요.

2단계: 로컬 DNS 포트가 리스닝 중인지 확인

설정에 지정한 주소와 포트에 리스닝 프로세스가 있는지 확인하세요. 포트를 다른 프로그램이 사용 중이면 Clash DNS 모듈은 시작에 실패해도 프록시 코어의 다른 기능은 계속 실행될 수 있습니다. 이때 시스템 프록시는 정상처럼 보이지만 도메인 조회가 필요한 연결은 실패합니다. 포트를 바꾼 뒤에는 시스템 DNS 전달 또는 TUN 가로채기 설정도 함께 수정해야 합니다.

3단계: 주 리졸버와 보조 리졸버를 각각 테스트

일시적으로 nameserver 하나만 남기고 복잡한 필터 정책을 끈 뒤 일반 도메인이 안정적으로 조회되는지 확인하세요. 그런 다음 fallback 업스트림을 따로 테스트합니다. DoH에 연결할 수 없다면 해당 호스트 이름이 default-nameserver로 초기 조회되는지, 현재 네트워크가 해당 주소와 포트에 접근할 수 있는지 확인하세요.

4단계: 노드 도메인의 시작 순환 확인

프록시 노드가 도메인을 사용하고 DNS 업스트림도 해당 노드를 통해서만 접근할 수 있다면, 커널 시작 시 노드를 조회하지 못할 수 있습니다. 그러면 프록시 연결을 만들 수 없고 DNS 업스트림에도 접근하지 못합니다. 노드 도메인에는 현재 네트워크에서 직접 연결 가능한 초기 리졸버를 사용하세요. mihomo 사용자는 proxy-server-nameserver도 확인할 수 있습니다.

5단계: fallback-filter 범위가 너무 넓지 않은지 확인

geosite, domain과 광범위한 ipcidr을 일시적으로 제거하고 최소 설정만 남기세요. 문제가 사라지면 조건을 그룹별로 다시 추가합니다. 특정 도메인이 서로 다른 조회 결과 사이에서 자주 바뀐다면 보조 서버를 계속 늘리기보다 주·보조 업스트림이 각각 반환한 주소와 필터 판정을 기록하세요.

6단계: fake-ip 트래픽이 실제로 Clash에 들어오는지 확인

조회 결과가 198.18.0.0/16과 같은 주소라면 fake-ip가 작동 중이라는 뜻입니다. 이후 연결에 실패한다면 해당 트래픽이 TUN, 투명 프록시 또는 시스템 프록시에 제대로 가로채지지 않았을 가능성이 큽니다. 이때는 DNS를 바꾸기보다 라우팅과 애플리케이션의 프록시 방식을 확인하세요. 일부 로컬 네트워크 또는 인증 도메인만 비정상이라면 해당 도메인을 fake-ip-filter에 정확히 추가할 수 있습니다.

7단계: IPv6 불일치 처리

ipv6: false는 일반적으로 Clash DNS가 AAAA 결과를 반환하지 않도록 제한하지만, 시스템·브라우저 또는 다른 리졸버가 여전히 IPv6 주소를 얻을 수 있습니다. 네트워크의 IPv6 연결성이 불완전하면 애플리케이션이 IPv6을 먼저 시도하다 시간 초과될 수 있습니다. 스위치 하나만 바꾸지 말고 시스템 IPv6, Clash DNS 설정, TUN 라우팅과 프록시 노드의 지원 여부가 서로 일치하는지 확인하세요.

8단계: 캐시를 비우고 동일한 조건으로 재검증

설정을 다시 불러온 뒤 브라우저와 운영체제의 DNS 캐시를 비우고 대상 애플리케이션을 종료했다가 다시 시작하세요. 테스트할 때는 네트워크, 도메인, 실행 모드와 정책 그룹을 고정해 여러 변수를 동시에 바꾸지 않도록 합니다. 먼저 DNS 반환 결과를 확인하고, 다음으로 Clash 로그에서 규칙 매칭과 아웃바운드 선택을 검증한 뒤 마지막으로 연결이 수립되는지 확인하세요.

장기간 안정적인 설정은 리졸버 수가 아니라 명확한 역할 구분에 달려 있습니다. 먼저 직접 접근 가능한 초기 리졸버 그룹, 기본 주 리졸버 그룹과 필요한 경우 fallback 그룹으로 최소 구조를 만든 뒤, 명확한 요구가 있을 때 정책 기반 조회와 fake-ip 필터를 추가하세요.

  1. 현재 클라이언트가 사용하는 커널 이름과 버전을 먼저 확인해 지원하지 않는 필드를 그대로 적용하지 않도록 하세요.
  2. default-nameserver는 짧게 유지하고 암호화 DNS와 노드 도메인의 초기 조회에 사용하세요.
  3. nameserver에는 안정적으로 접근 가능한 주요 업스트림을 선택하고, 용도가 불분명한 주소는 섞지 마세요.
  4. 실제로 조회 결과 차이가 있을 때만 fallback을 활성화하고, 각 필터 조건을 추가한 이유를 기록하세요.
  5. fake-ip를 사용할 때는 작고 정확한 필터 목록을 유지하며 더 이상 필요하지 않은 예외는 정기적으로 삭제하세요.
  6. TUN 환경에서는 DNS 가로채기, 라우팅, IPv6와 브라우저 내장 보안 DNS를 함께 확인하세요.
  7. 한 번에 한 그룹의 필드만 수정하고 되돌릴 수 있는 원본 설정을 보관한 뒤 로그로 실제 경로를 검증하세요.

구독에서 제공하는 설정에는 이미 DNS 섹션이 포함되어 있을 수 있습니다. 클라이언트 오버라이드 기능으로 같은 이름의 필드를 다시 추가하면 최종 결과가 교체, 병합 또는 완전 무시될 수 있으며, 구체적인 동작은 클라이언트 구현에 따라 달라집니다. 구독을 업데이트하기 전에 사용자 지정 DNS가 별도 오버라이드에 있는지 구독 사본에 직접 작성되어 있는지 확인하세요. 업데이트 후에는 최종 설정을 점검해 사용자 지정 내용이 덮어써지지 않았는지 확인해야 합니다.

대부분의 데스크톱 환경에서는 먼저 ‘요청이 Clash에 들어오는가’와 ‘업스트림에 접근 가능한가’라는 두 가지 문제를 해결한 뒤 fallback과 정책 분기를 최적화하세요. 게이트웨이 우회 라우터와 다중 장치 네트워크에서는 DHCP, 기본 게이트웨이, 단말의 사용자 지정 DNS와 IPv6 출구도 추가로 확인해야 합니다. 애플리케이션에서 업스트림까지의 조회 경로를 순서도로 그려 보면 설정 필드를 계속 늘리는 것보다 장애 원인을 찾기 쉽습니다.

Clash 다운로드