Clash Fake-IP이란? DNS 매핑, fake-ip-filter 설정과 활용 사례

핵심부터 보기: Fake-IP는 도메인 매핑 방식이지, 프록시 출구가 아닙니다

Fake-IP 모드에서는 Clash 코어가 먼저 앱에 합성 주소를 반환하고, 연결을 가로챌 때 이 주소를 도메인으로 복원합니다. 앱에는 198.18.0.2 같은 주소가 보일 수 있지만, 실제 웹사이트나 프록시 출구가 이 주소에 있는 것은 아닙니다. 이 주소가 보인다는 사실만으로 DNS 오염 여부를 판단하거나 요청이 프록시를 거쳤다고 단정할 수 없습니다.

이 방식이 작동하려면 두 단계가 모두 충족되어야 합니다. DNS 조회가 코어에서 처리되고, 합성 주소로 향하는 연결도 같은 코어로 되돌아와야 합니다. 데스크톱에서는 주로 TUN으로 트래픽을 가로채고, 라우터에서는 투명 프록시 규칙을 사용할 수 있습니다. 설정에 enhanced-mode: fake-ip를 입력하는 것만으로 운영체제의 전체 라우팅과 DNS 전달이 자동으로 구성되지는 않습니다.

DNS 매핑부터 연결 복원까지, 5단계

앱이 example.com:443에 접속하는 상황을 예로 들어 보겠습니다. DNS 조회와 연결이 모두 같은 mihomo 인스턴스에서 처리된다고 가정할 때 순서는 다음과 같습니다.

앱이 DNS 조회를 시작합니다. 앱이 example.com의 IPv4 주소를 요청하면 조회가 코어의 DNS 서비스로 들어갑니다. 앱에서 별도의 암호화 DNS를 사용하고 해당 트래픽이 가로채지지 않으면 이 단계는 코어를 우회할 수 있습니다.
코어가 합성 주소를 할당합니다. 도메인이 필터 목록에 없으면 코어는 Fake-IP 주소 풀에서 198.18.0.2와 같은 주소를 할당하고, 도메인과 주소의 매핑을 저장합니다. 유효한 매핑이 이미 있으면 재사용할 수 있습니다.
앱이 합성 주소에 연결합니다. 앱은 일반적인 네트워크 절차에 따라 198.18.0.2:443로 연결을 시작합니다. TUN 또는 투명 프록시 규칙이 이 연결을 코어로 전달하므로 공용 인터넷으로 바로 나가지 않습니다.
코어가 원래 도메인을 찾아냅니다. 코어는 매핑 테이블을 조회해 example.com을 복원한 뒤 도메인 규칙을 적용하고, 정책 그룹을 선택해 후속 연결을 처리합니다.
출구에 맞춰 실제 연결을 만듭니다. 프록시를 이용할 때는 프로토콜과 구현이 도메인 전달을 지원하면 프록시 서버 측에서 DNS를 조회할 수 있습니다. 직접 연결에서는 일반적으로 로컬 코어가 실제 주소를 조회해야 합니다. 구체적인 동작은 규칙과 DNS 설정에 따라서도 달라집니다.

198.18.0.0/15는 네트워크 장비 벤치마크용 특수 목적 주소 대역이며, 웹사이트가 실제로 사용하는 공인 IP 대역이 아닙니다. 일반적인 설정에서는 이 대역 가운데 198.18.0.1/16을 주소 풀로 사용합니다. 기업 네트워크에서 이미 이 대역을 사용 중이라면 라우팅 충돌부터 해결해야 하며, 기본값을 그대로 적용하면 안 됩니다.

도메인을 유지하면 규칙별 트래픽 분류에 유리한 이유

공유 CDN 주소만 보이면 코어는 그 주소만으로 여러 웹사이트를 구분하기 어렵습니다. Fake-IP 매핑은 연결에 도메인 정보를 유지해 DOMAIN, DOMAIN-SUFFIX 등의 규칙을 적용할 수 있게 합니다. 다만 규칙은 여전히 위에서부터 순서대로 적용됩니다. 앞에 있는 프로세스 규칙이나 대역 규칙, 다른 일치 항목이 먼저 출구를 결정할 수 있습니다.

초기 연결 지연: 기다리는 시간을 어디서 줄일까

Fake-IP는 앱이 주소를 더 일찍 받아 연결 단계로 넘어가게 해 줍니다. 실제 A 레코드 응답을 기다린 뒤에야 앱에 사용할 주소를 주는 방식이 아닙니다. 실제 DNS 조회 결과를 기다려야 하는 경로와 비교하면 연결 시작 전 대기 시간이 줄어들 수 있지만, 모든 웹사이트의 속도가 항상 빨라지는 것은 아닙니다.

처리 단계	실제 주소를 반환하는 방식	Fake-IP 방식
앱이 DNS 응답을 받는 시점	캐시 적중이 아니라면 일반적으로 실제 DNS 조회 결과가 필요합니다	주소 풀에서 합성 주소를 할당해 반환할 수 있습니다
도메인 규칙 매칭	사용 가능한 도메인 연관 정보가 필요합니다	합성 주소 매핑으로 도메인을 복원할 수 있습니다
직접 연결 웹사이트	실제 주소로 연결합니다	코어에서 실제 주소를 조회해야 할 수 있습니다
프록시 접속	조회 위치는 프로토콜과 설정에 따라 달라집니다	도메인 전달을 지원하면 프록시 서버 측에서 조회할 수 있습니다

예를 들어 캐시되지 않은 실제 DNS 조회에 80ms가 걸린다고 가정해 보겠습니다. Fake-IP를 사용하면 앱이 연결을 시작하기 전에 이 80ms를 먼저 기다리지 않아도 됩니다. 이는 작동 방식을 설명하기 위한 가정일 뿐, 실제 측정 결과가 아닙니다. 이후 직접 연결을 위한 DNS 조회, 프록시 핸드셰이크, TLS 핸드셰이크와 서버 응답에는 여전히 시간이 걸립니다.

의미 있는 비교 방법

같은 네트워크, 같은 노드, 같은 규칙 모드를 유지한 채 캐시가 없는 경우와 캐시가 있는 경우를 각각 테스트하세요. 두 결과를 한데 섞어 비교하면 안 됩니다.
브라우저 개발자 도구의 네트워크 패널에서 DNS, 연결, TLS 단계를 확인하고 코어 로그도 함께 살펴보세요. 브라우저에 표시되는 DNS 시간에는 코어가 이후에 수행하는 조회 시간이 포함되지 않을 수 있습니다.
페이지 요청을 여러 차례 측정해 중앙값을 기록하고, DNS 응답 속도와 페이지 첫 바이트 시간을 구분하세요. 한 번의 속도 테스트 다운로드 결과로 DNS 성능을 비교하면 안 됩니다.

최소 DNS 설정 및 검증 명령

아래는 설정 일부이며, 인터넷에 연결할 수 있는 완성된 설정 파일이 아닙니다. 코어 DNS를 활성화하고 로컬 장치의 1053 포트에서 수신하도록 하는 내용만 포함되어 있습니다. 프록시 노드, 규칙, TUN, 시스템 DNS 가로채기는 기존 설정에서 제공해야 합니다. 여기서는 검증 범위를 IPv4 A 레코드로 한정하기 위해 IPv6을 비활성화했습니다. 일반적으로 사용할 때는 네트워크의 IPv6 가로채기 지원 여부에 따라 활성화 여부를 결정하세요.

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"
    - "+.local"
    - "+.home.arpa"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

두 업스트림 DNS 주소에 현재 네트워크에서 접근할 수 있어야 합니다. 회사, 학교 또는 가정에서 분리 DNS를 사용하는 환경이라면 해당 내부 DNS 서버를 사용하세요. 모든 조회를 공용 DNS로 보내면 내부 도메인이 해석되지 않을 수 있습니다. 127.0.0.1에서 수신하도록 설정하면 로컬 장치의 조회만 받으므로 다른 LAN 기기가 직접 이용할 DNS 서버로는 적합하지 않습니다.

먼저 코어를 테스트한 다음 시스템 DNS 경로를 확인하세요

코어가 실행 중인 장치에서 다음 명령으로 DNS 서버와 포트를 명시해 테스트합니다. Windows에서는 첫 번째 명령을, dig가 설치된 macOS 또는 Linux에서는 두 번째 명령을 사용할 수 있습니다. 두 명령은 대체 관계이므로 둘 다 실행할 필요는 없습니다.

nslookup -port=1053 example.com 127.0.0.1

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

응답 주소가 설정한 Fake-IP 주소 풀에 포함되는지 확인하세요. 요청 시간이 초과되면 코어가 실행 중인지, 포트가 이미 사용 중인지, 최종 설정에서 DNS가 활성화되어 있는지부터 점검합니다.
다음으로 시스템 기본 DNS 조회 방식에서 같은 도메인을 조회합니다. 포트를 지정한 조회는 성공했지만 시스템 조회 결과가 다르다면 앱이나 시스템이 아직 이 DNS 경로를 사용하지 않는 것입니다.
클라이언트의 연결 페이지에서 방금 시작한 브라우저 요청을 찾아 대상 도메인, 적용된 규칙, 출구 정책 그룹을 확인하세요. DNS가 합성 주소를 반환했다는 사실은 조회 단계만 확인해 줄 뿐, 연결 가로채기가 성공했다는 뜻은 아닙니다.

fake-ip-filter: 실제 주소를 반환해야 하는 도메인

fake-ip-filter는 어떤 DNS 조회에 합성 주소를 할당하지 않을지 지정합니다. 일반적인 기본 블랙리스트 방식에서는 목록과 일치하는 도메인에 실제 조회 결과를 반환합니다. 최신 mihomo에는 필터 모드 등 추가 설정도 있습니다. 기존 설정에 fake-ip-filter-mode가 있다면 먼저 동작 방식을 확인하세요. 목록이 항상 제외 항목을 뜻한다고 단정하면 안 됩니다.

필터 목록은 직접 연결과 프록시 중 어느 쪽을 사용할지 결정하지 않으며, 내부 DNS 서버도 선택하지 않습니다. 도메인을 목록에 추가해도 규칙에 따라 프록시를 이용할 수 있습니다. 규칙에서 도메인을 DIRECT로 지정해도 Fake-IP가 자동으로 우회되는 것은 아닙니다.

상황	확인할 증상	조치 방법
NAS, 프린터 및 내부 서비스	앱에서 실제 LAN 주소를 요구하거나 내부 도메인이 해석되지 않음	실제 사용하는 도메인 접미사만 필터링하고 내부 DNS로 조회를 전달합니다
게임 로그인 및 온라인 플레이	프로그램이 조회 주소를 비교하거나 다른 기기에 주소를 전달함, 또는 연결이 가로채기를 우회함	로그에서 해당 도메인을 찾아 하나씩 필터 효과를 확인합니다
네트워크 연결 확인	시스템에서 오프라인으로 잘못 판단하거나 포털 인증 페이지가 열리지 않음	연결 확인용 도메인의 DNS 조회, 출구 규칙, HTTP 응답을 점검합니다
주소 일치 여부 확인	프로그램에서 DNS 결과와 서버 기록 또는 실제 주소가 일치해야 함	실제 주소가 필요한 것으로 확인된 도메인만 필터링합니다

LAN 도메인에는 올바른 업스트림 DNS도 필요합니다

+.home.arpa는 해당 도메인과 하위 도메인을 뜻하며, 이 이름 체계를 사용하는 가정 네트워크에 적합합니다. .lan은 흔히 쓰이는 로컬 도메인 규칙이지만 모든 라우터가 사용하는 것은 아닙니다. .local은 일반적으로 mDNS와 관련이 있습니다. 이를 필터 목록에 추가해도 일반 DNS 업스트림에 mDNS 검색 기능이 생기지는 않습니다. 프린터 검색에 문제가 있다면 멀티캐스트와 로컬 네트워크 접근 권한도 확인하세요.

게임 및 주소 검증 도메인은 근거를 확인한 뒤 추가하세요

게임 플랫폼 전체나 CDN 도메인을 통째로 필터링하지 마세요. 먼저 오류 발생 시간을 기록하고 연결 및 DNS 로그에서 요청을 찾은 다음, 문제가 확인된 도메인만 추가합니다. 아래의 login.example.com은 문법을 보여 주기 위한 예시 도메인입니다. 실제 게임 문제를 해결할 때 그대로 사용하지 말고 로그에서 확인한 대상 도메인으로 바꾸세요.

dns:
  fake-ip-filter:
    - "localhost"
    - "+.lan"
    - "+.local"
    - "+.home.arpa"
    - "login.example.com"

아래 항목은 기존 dns 객체에 합쳐야 합니다. 하나의 YAML 파일에서 최상위 dns 키를 중복으로 만들지 마세요. 구독이 서버에서 주기적으로 갱신된다면 클라이언트의 오버라이드 또는 병합 기능으로 수정 사항을 저장하고, 업데이트 후 최종 적용 설정을 확인하세요.

자주 겪는 문제: DNS 조회는 정상인데 왜 연결되지 않을까?

198.18 주소가 반환되지만 웹페이지가 계속 시간 초과됨

먼저 연결이 코어로 되돌아오는지 확인하세요. 시스템 프록시는 프록시 설정을 따르는 앱에만 적용되는 경우가 많으며, 합성 주소로 향하는 모든 연결을 자동으로 가로채지는 않습니다. TUN을 사용한다면 TUN이 실행 중인지, 라우트가 정상적으로 추가됐는지, 다른 VPN이 라우트를 선점하고 있지는 않은지 확인하세요. 테스트할 때는 네트워크 트래픽을 가로채는 도구를 하나만 사용해 DNS와 트래픽이 서로 다른 인스턴스로 나뉘지 않도록 합니다.

클라이언트를 종료한 뒤에도 일부 웹사이트에 접속할 수 없음

앱이나 운영체제에 합성 주소가 캐시되어 있지만 매핑을 복원할 코어는 이미 종료되었을 수 있습니다. 먼저 시스템 DNS와 라우팅을 복구한 다음 관련 앱을 종료하고 DNS 캐시를 비우세요. Windows에서는 ipconfig /flushdns를, systemd-resolved를 사용하는 Linux에서는 resolvectl flush-caches를 실행할 수 있습니다. 브라우저 자체에도 캐시가 있을 수 있으므로 시스템 캐시를 비운 뒤에도 브라우저를 다시 시작해야 합니다.

필터 목록에 추가했는데 달라진 점이 없음

수정한 설정이 현재 사용 중인 설정인지 확인하고, 다른 설정이나 전역 오버라이드가 변경 사항을 덮어쓰지 않았는지 점검하세요.
필터 모드와 도메인 표기를 확인하고, 주소 표시줄의 주 도메인만 보지 말고 실제로 조회된 도메인을 추가했는지 점검하세요.
설정을 적용한 뒤 앱과 시스템의 오래된 DNS 캐시를 비우고 다시 조회해 테스트하세요.
실제 주소가 반환되는데도 연결에 실패한다면 필터 범위를 더 넓히지 말고 규칙, UDP 지원 여부, 서버 상태 또는 내부 DNS를 확인하세요.

브라우저는 정상이지만 게임이나 명령줄 프로그램은 작동하지 않음

브라우저와 다른 앱이 서로 다른 DNS 경로를 사용하거나, 한쪽은 시스템 프록시를 따르고 다른 쪽은 직접 패킷을 보낼 수 있습니다. 앱 자체 DoH, 하드코딩된 IP, LAN 멀티캐스트는 동일한 처리 경로를 거치지 않을 수 있습니다. 도메인 스니핑으로 일부 연결 정보를 보완할 수는 있지만 모든 프로토콜에서 도메인을 복원할 수는 없으며, DNS와 라우팅을 온전히 가로채는 방식도 대신할 수 없습니다.

특히 IP 주소로 직접 연결하는 경우에는 원래 도메인 조회 후 가짜 주소를 할당하는 단계가 없습니다. 이때는 fake-ip-filter에 항목을 추가해 해결하려 하지 말고 IP 규칙, 프로세스 규칙, 연결 로그를 확인하세요.

적합한 사용 환경과 수정 전 점검 목록

일반적인 웹 브라우징, 도메인별 세밀한 트래픽 분류, TUN이 안정적으로 작동하는 기기라면 Fake-IP를 먼저 시험해 볼 만합니다. 내부 DNS, 특수 검색 프로토콜 또는 주소 일치 검사가 필요한 환경에서는 실제 DNS 조회, 내부 업스트림, 라우팅 설계를 함께 점검해야 합니다.

먼저 코어를 확인합니다. 클라이언트와 코어 버전을 기록하고 현재 코어가 설정 필드를 지원하는지 확인하세요.
두 경로를 확인합니다. DNS 조회가 코어로 들어오고, 합성 주소 연결도 같은 인스턴스로 돌아와야 합니다.
필터 범위를 최소화합니다. 실제 주소가 필요한 것으로 확인된 도메인만 추가하고, 추가 이유를 기록하세요.
구독 오버라이드를 확인합니다. 구독을 업데이트한 뒤 최종 설정을 점검해 수동으로 수정한 내용이 덮어써지지 않았는지 확인하세요.
한 번에 한 종류의 설정만 변경합니다. 먼저 필터만 바꾸고 결과를 확인하세요. DNS, 노드, 규칙, TUN 설정을 동시에 변경하지 마세요.