Clash Fake-IP 모드 가이드: DNS 매핑 원리, fake-ip-filter 설정과 활용법

먼저 DNS와 트래픽이 모두 커널을 거치는지 확인하세요

Fake-IP를 설정하기 전에 두 가지를 확인하세요. 앱의 DNS 요청이 Clash 커널에 도달하고, 이어지는 연결도 같은 커널이 처리해야 합니다. DNS만 설정하고 연결은 물리 네트워크 인터페이스로 빠져나가면, 앱이 공용 인터넷에서 접근할 수 없는 가상 주소를 받아 웹페이지가 계속 로딩될 수 있습니다.

클라이언트의 설정 상세 정보나 실행 중인 설정에서 dns.enable이 true이고 dns.enhanced-mode가 fake-ip인지 확인하세요.
현재 시스템 프록시를 쓰는지, TUN으로 트래픽을 처리하는지 확인하세요. 시스템 프록시는 프록시 설정을 따르는 앱의 트래픽만 처리합니다. TUN은 더 많은 IP 트래픽을 가로챌 수 있지만, 라우팅과 DNS도 올바르게 설정해야 합니다.
클라이언트의 연결 패널을 열고 새 도메인에 접속해 도메인, 매칭된 규칙, 출구가 표시되는지 확인하세요. 메뉴 이름은 클라이언트마다 다르므로 첫 화면의 ‘연결됨’ 상태만 믿지 마세요.
Clash Meta(현재 이름: mihomo)를 사용한다면 현재 커널에 적용된 유효 설정을 기준으로 확인하세요. 클라이언트 편집기에 표시된 구독 원문이 병합 및 덮어쓰기 후의 실행 설정과 다를 수 있습니다.

DNS 매핑은 어떻게 규칙 기반 분기로 이어질까요?

실제 주소 대신 로컬 매핑 사용

일반적인 방식에서는 앱이 먼저 DNS에 질의해 대상의 실제 IP를 받은 뒤 해당 IP로 연결합니다. Fake-IP는 주소 풀에서 198.18.0.2 같은 가상 IPv4 주소를 먼저 할당하고, 커널에 ‘도메인 ↔ 가상 주소’ 매핑을 저장할 수 있습니다. 이 주소는 작동 방식을 설명하기 위한 예시이며, 질의할 때마다 같은 주소가 반환된다는 뜻은 아닙니다.

앱이 www.example.com의 A 레코드를 조회합니다.
커널이 도메인과 Fake-IP의 매핑을 저장하고 앱에 가상 주소를 반환합니다.
앱이 해당 주소로 연결을 시작하면 시스템 프록시나 TUN 등의 경로를 통해 커널에 전달됩니다.
커널은 대상 주소에 연결된 도메인을 찾아 도메인 규칙에 따라 정책 그룹을 선택하고, 선택된 출구를 통해 연결합니다.

일반적인 설정에 쓰이는 198.18.0.1/16은 성능 측정용으로 예약된 198.18.0.0/15 주소 블록에 속하며 대상 웹사이트의 공인 IP가 아닙니다. 이 범위는 ‘무료 노드 주소’도 아닙니다. 기업 네트워크, 테스트 환경 또는 다른 VPN에서 겹치는 대역을 사용한다면 먼저 라우팅 충돌을 해결하세요.

대기 시간이 줄어들 수 있는 이유

도메인 규칙으로 분기할 수 있고 프록시 프로토콜이 도메인 전달을 지원하는 연결이라면, 로컬에서 대상 도메인의 실제 DNS 응답을 기다리지 않고 프록시 연결을 시작할 수 있습니다. 실제 DNS 조회를 원격에서 처리하면 로컬 DNS 요청이 연결의 병목이 되는 상황을 줄일 수 있습니다.

모든 연결이 빨라진다는 뜻은 아닙니다. 직접 연결하는 경우에는 대체로 실제 IP가 필요하고, IP 기반 규칙과 매칭될 때도 DNS 조회가 발생할 수 있습니다. 노드 왕복 지연 시간, 원격 DNS, 핸드셰이크, 대상 사이트의 응답이 주요 지연 원인일 수도 있습니다. Fake-IP로 작동하지 않는 노드를 살려낼 수는 없으며 노드 지연 시간 측정 결과가 자동으로 낮아지는 것도 아닙니다.

Fake-IP와 redir-host의 차이

비교 항목	fake-ip	redir-host
A 레코드 응답	제외되지 않은 도메인에는 보통 가상 주소를 반환합니다.	상위 DNS에서 조회한 실제 주소를 반환합니다.
도메인 연결 정보	Fake-IP 매핑을 이용해 대상 도메인을 복원합니다.	DNS 캐시 등의 정보로 도메인을 연결할 수 있지만, 실제 IP 하나에 여러 도메인이 연결될 수 있습니다.
로컬 DNS 조회 대기	일부 프록시 연결은 로컬의 실제 DNS 조회를 미루거나 생략할 수 있습니다.	DNS 응답 전에 보통 실제 주소를 조회해야 합니다.
자주 발생하는 호환성 문제	앱의 실제 IP 확인, 매핑 손실, 연결이 프록시 경로로 전달되지 않는 문제.	로컬 DNS 응답 품질, 공유 IP의 도메인 판별, 트래픽 분기 판단.
도입하기 좋은 상황	도메인 규칙으로 주로 트래픽을 분기하고 DNS와 연결 경로를 제어할 수 있는 경우.	앱이 실제 DNS 응답에 의존하거나 호환성이 우선인 경우.

redir-host를 쓴다고 도메인 규칙이 비활성화되는 것은 아니며, Fake-IP를 쓴다고 상위 DNS를 전혀 조회하지 않는 것도 아닙니다. 커널의 연결 메타데이터, DNS 캐시, 스니핑 설정, 규칙 순서에 따라 실제 동작이 달라집니다. 문제를 진단할 때는 모드 이름만으로 추측하지 말고 연결 패널에서 실제 도메인과 매칭된 규칙을 확인하세요.

게임 하나나 NAS 한 대에서만 접속 문제가 발생한다면 모든 트래픽을 redir-host로 바꾸기보다 먼저 해당 도메인을 제외하세요. 실제 주소를 필요로 하는 앱이 많고 예외 목록을 합리적으로 관리하기 어렵다면 전체 모드 전환을 검토하고, 같은 네트워크와 같은 출구에서 결과를 비교하세요.

fake-ip-filter 설정과 주의할 점

기존 Clash와 mihomo의 블랙리스트 필터 방식에서는 fake-ip-filter에 등록된 도메인에 Fake-IP를 할당하지 않고 실제 DNS 조회를 사용합니다. 흔히 ‘화이트리스트’라고 부르지만, 정확히는 ‘Fake-IP 제외 목록’입니다. 프록시 허용 목록이 아니며 직접 연결 여부를 결정하지도 않습니다.

아래는 동작을 확인하기 위한 DNS 설정 예시이며, 전체 구독 설정은 아닙니다. 예시에서는 시스템에서 흔히 사용하는 53 포트를 직접 점유하지 않도록 로컬 1053 포트를 사용합니다. 공용 DNS 서버 두 곳은 문법을 보여주기 위한 예시이므로 실제 환경에서 접속할 수 있고 사용 목적에 맞는 DNS 서버로 바꾸세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - 'localhost'
    - '*.lan'
    - '+.home.arpa'
  nameserver:
    - 1.1.1.1
    - 9.9.9.9

listen은 수신 주소만 설정합니다. 이 항목만 설정한다고 시스템 DNS가 자동으로 1053 포트를 사용하지는 않습니다. 클라이언트나 시스템에서 전달 및 트래픽 처리를 별도로 설정해야 합니다.
ipv6: false는 이 예시의 AAAA 응답 경로를 단순화하기 위한 설정입니다. 모든 네트워크에서 IPv6를 끄라는 뜻도, 운영체제의 IPv6를 비활성화한다는 뜻도 아닙니다.
'*.lan'은 해당 패턴에 맞는 로컬 네트워크 하위 도메인을 대상으로 합니다. 지원되는 도메인 매칭 문법에서 '+.' 형식은 도메인 자체와 하위 도메인을 모두 포함할 수 있습니다. 작은따옴표를 사용하면 YAML이 와일드카드를 잘못 해석하는 것도 방지할 수 있습니다.
mihomo는 fake-ip-filter-mode 등의 확장 기능도 제공합니다. 실행 설정이 whitelist로 지정되면 목록의 의미가 반대로 바뀝니다. 사용하기 전에 커널의 지원 여부와 현재 모드를 확인하고, 서로 다른 모드의 설정 예시를 섞지 마세요.

구독을 업데이트하면 원본 파일이 바뀔 수 있습니다. 장기간 유지할 수정 사항은 클라이언트에서 지원하는 덮어쓰기 또는 병합 설정에 넣고 최종 실행 설정을 확인하세요. 특히 목록 병합 방식을 주의해야 합니다. 클라이언트에 따라 기존 필터 목록에 항목을 추가하는 대신 목록 전체를 교체할 수 있습니다.

제외 목록에 추가할 만한 도메인

로컬 네트워크 서비스와 내부 DNS 도메인

NAS, 프린터 관리 페이지, 기업 내부 시스템부터 확인하세요. 예를 들어 내부 DNS가 nas.home.arpa를 192.168.1.20으로 조회하고 앱에서 이 사설 주소를 인식해야 한다면, 해당 이름을 제외 목록에 넣고 내부 DNS에서 조회하도록 할 수 있습니다. 올바른 로컬 네트워크 규칙과 트래픽 처리 경로가 이미 있다면 제외가 필요하지 않을 수도 있으니 실제 증상을 기준으로 판단하세요.

.local은 mDNS와 관련된 경우가 많습니다. mDNS는 일반 유니캐스트 DNS와 다른 멀티캐스트 검색 경로를 사용하므로, 필터 목록에 추가해도 네트워크 간 검색이나 멀티캐스트 라우팅, 방화벽 문제까지 자동으로 해결되지는 않습니다. IP 주소로 기기 관리 페이지를 열 수 있지만 기기 검색 목록에 표시되지 않는다면 멀티캐스트와 네트워크 인터페이스 선택도 확인하세요.

응답 주소를 직접 확인하는 앱

일부 게임, 기기 페어링 도구, 네트워크 진단 프로그램은 DNS 응답을 주소 검증이나 지역 판별, 후속 프로토콜 협상에 사용합니다. 로그나 비교 테스트로 Fake-IP가 원인이라고 확인된 경우에만 해당 앱이 실제로 조회하는 도메인을 제외하세요. 알 수 없는 출처의 목록 수백 개를 복사하는 것보다 한 번에 도메인 하나를 추가하고 앱을 재시작해 확인하는 편이 원인을 찾기 쉽습니다.

도메인이 중국 본토 사이트라는 이유만으로 모두 제외하지 마세요. 직접 연결과 프록시 사용 여부는 규칙이 결정하며 Fake-IP 주소가 결정하는 것이 아닙니다.
최상위 도메인 전체를 기본 해결책으로 제외하지 마세요. 제외 범위가 지나치게 넓으면 많은 DNS 요청의 조회 경로가 바뀝니다.
노드 서버 도메인의 조회 문제를 무조건 Fake-IP 탓으로 돌리지 마세요. mihomo에서는 노드 도메인 조회에 proxy-server-nameserver 같은 별도 설정이 관여할 수 있습니다.
필터는 보통 도메인 기준으로 설정합니다. 192.168.1.20 같은 대상 IP를 추가한다고 모든 로컬 네트워크 접속 문제가 해결되는 것은 아닙니다.

DNS 응답과 연결 결과 확인

먼저 설정을 백업한 뒤 수정 사항을 적용하세요. 아래 명령은 예시의 수신 포트에 직접 질의하므로 ‘커널이 올바르게 응답하는지’와 ‘시스템이 실제로 해당 DNS를 사용하는지’를 나눠 확인할 수 있습니다. macOS 또는 Linux에 dig가 설치되어 있다면 다음을 실행하세요.

dig @127.0.0.1 -p 1053 www.example.com A +short
dig @127.0.0.1 -p 1053 nas.home.arpa A +short

이 예시 설정에서는 첫 번째 명령이 보통 198.18.0.0/16 범위의 주소를 반환합니다. 구체적인 주소는 고정되어 있지 않습니다. 내부 DNS가 올바르게 연결되어 있다면 두 번째 명령은 내부 서비스의 실제 주소를 반환해야 합니다. 공용 DNS 서버가 빈 결과를 반환하거나 도메인이 존재하지 않는다고 응답해도 필터 기능이 고장 났다는 뜻은 아닙니다.

응답 확인. 응답이 없으면 커널이 127.0.0.1:1053에서 수신 중인지, 설정이 정상적으로 불러와졌는지 확인하세요. 실제 공인 IP가 반환된다면 필터 규칙과 현재 적용된 모드를 확인하세요.
앱의 연결 경로 확인. 브라우저에서 같은 도메인에 접속하고 연결 패널을 확인하세요. 직접 DNS 질의가 성공해도 테스트 명령이 커널에 도달했다는 뜻일 뿐, 브라우저가 같은 DNS 경로를 사용한다는 보장은 없습니다.
규칙과 출구 확인. 예상한 도메인 규칙과 정책 그룹이 매칭되는지 확인하세요. 도메인은 표시되지만 연결에 실패한다면 노드, 대상 포트, 원격 DNS를 추가로 확인하세요.
비교 결과 기록. 수정 전후의 DNS 응답, 연결 로그, 앱 동작을 기록하고 필터 목록, 모드, DNS 서버 중 한 번에 하나씩만 변경하세요.

ping으로 가상 주소에 응답하는지 확인해 노드 사용 가능 여부를 판단하지 마세요. ICMP는 브라우저에서 사용하는 TCP나 QUIC와 다른 연결 방식이고, TUN에서 ICMP를 처리하는 방식도 다를 수 있습니다. 실제 서비스 요청이 완료되는지 먼저 확인하세요.

자주 발생하는 문제의 점검 순서

모드를 바꾼 뒤에도 일부 사이트가 열리지 않음

먼저 캐시를 지우세요. Windows에서는 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 비운 다음 관련 앱을 완전히 종료하고 다시 시작할 수 있습니다. 브라우저, 런타임, 앱은 각각 별도의 캐시를 사용할 수 있으므로 시스템 캐시를 비워도 이전 주소가 모두 삭제되는 것은 아닙니다. 커널을 재시작하면 매핑이 바뀔 수 있으며, 앱이 이전 Fake-IP를 계속 사용하면 연결에 실패할 수 있습니다.

TUN을 켰는데도 DNS 요청이 커널을 우회함

지원되는 mihomo 설정에서 TUN의 dns-hijack에는 흔히 any:53을 지정합니다. 실제 적용 여부는 플랫폼, 라우팅, 권한에 따라 달라집니다. 이 설정은 주로 기존 DNS 요청 경로를 처리하며 브라우저가 HTTPS로 보내는 DoH 요청을 직접 복호화할 수는 없습니다. 문제를 진단할 때는 브라우저의 맞춤 보안 DNS를 잠시 끄고 응답과 연결 로그를 비교한 다음, DNS 조회 방식을 통일할지 결정하세요.

규칙에 DIRECT를 지정했는데도 로컬 기기에 연결할 수 없음

DIRECT는 연결 출구만 결정합니다. 내부 DNS 레코드를 자동으로 제공하지 않으며 다른 VPN과의 네트워크 대역 충돌도 해결하지 않습니다. 내부 도메인이 올바른 주소로 조회되는지, 해당 주소로 가는 시스템 경로가 올바른지, TUN이 불필요한 대역까지 처리하고 있지는 않은지, 기기의 포트에 접근할 수 있는지 순서대로 확인하세요.

어떤 모드를 사용할지 결정하는 방법

일반적인 웹 브라우징과 도메인 규칙 기반 분기에는 Fake-IP부터 적용해 볼 수 있습니다. 일부 앱에서만 호환성 문제가 발생하면 해당 도메인만 정확히 제외하세요. 실제 DNS 응답이 필요한 앱이 많다면 redir-host와 비교 테스트를 진행하세요. 최종 판단 기준은 DNS 응답이 공인 IP처럼 보이는지가 아니라 서비스 연결, 규칙 매칭, DNS 조회 경로가 모두 예상대로 작동하는지입니다. 트래픽 처리와 규칙 기초는 규칙 기반 분기 사용 가이드와 포트 설정 안내를 참고하세요.