Fake-IP 모드 원리 완전 정리: DNS 응답 방식, 장단점, fake-ip-filter 설정

Fake-IP는 예약된 사설 대역의 가상 주소로 DNS 질의에 즉시 응답해 해석 대기를 없애고 도메인 규칙 매칭을 정확하게 만듭니다. 이 글에서는 동작 흐름, redir-host와의 차이, 주의할 함정, 그리고 fake-ip-filter 제외 목록 작성법을 분석합니다.

DNS 모드가 왜 선택 문제가 되는가

일반적인 네트워크 환경에서 애플리케이션은 요청을 보내기 전에 먼저 도메인 해석을 거칩니다. 시스템은 도메인을 DNS 서버에 넘겨 실제 IP를 받고, 그 IP로 목적지 서버에 연결합니다. Clash가 도메인 기반 분기 처리(예: "특정 사이트는 프록시로, 특정 사이트는 다이렉트로")를 하려면 바로 이 단계에 개입해야 합니다. 문제는 분기 규칙에 적히는 것은 대개 도메인(DOMAIN-SUFFIX, DOMAIN-KEYWORD)이지만, 실제 네트워크 연결에 쓰이는 것은 IP라는 점입니다. 특별한 처리 없이는 규칙 엔진이 연결 시점에 볼 수 있는 것은 순수한 IP뿐이라, 그것이 어떤 도메인에 대응하는지, 어떤 규칙에 매칭돼야 하는지 역추적하는 것이 항상 안정적이지는 않습니다.

이것이 Clash Meta(mihomo)가 DNS 계층에서 여러 모드를 제공하는 이유입니다. 그중 가장 많이 쓰이는 두 가지가 Fake-IP와 redir-host(fake-ip 이외의 리다이렉트 방식)입니다. 두 방식 모두 본질적으로는 같은 문제를 해결합니다. "도메인 규칙"이 "IP 계층 연결"이 일어나는 순간에도 계속 대응되도록 만드는 것입니다. 다만 접근 방식이 완전히 다르고, 그로 인한 동작 차이도 적지 않습니다.

Fake-IP의 동작 방식

Fake-IP의 아이디어는 이렇습니다. 애플리케이션이 어떤 도메인의 DNS를 질의하면, Clash는 그 도메인을 실제로 해석하지 않고 예약된 사설 대역(기본적으로 흔히 198.18.0.0/16)에서 아직 할당되지 않은 주소 하나를 골라 즉시 애플리케이션에 반환합니다. 동시에 내부적으로 "가상 IP ↔ 실제 도메인" 매핑 테이블을 관리합니다.

애플리케이션이 example.com의 A 레코드를 질의;
Clash의 DNS 모듈이 이 질의를 가로채 fake-ip(예: 198.18.0.23)를 할당하고, "198.18.0.23은 example.com에 대응"으로 기록;
애플리케이션이 198.18.0.23을 받아 TCP/UDP 연결을 시작;
연결이 Clash를 경유(시스템 프록시 포트든 TUN 가상 네트워크 카드든)하며 Clash가 테이블을 조회해 원래 도메인 example.com을 복원;
규칙 엔진이 복원된 도메인으로 DOMAIN 계열 규칙을 매칭해 어느 프록시 노드로 보낼지 결정;
정책이 확정되면 Clash가 실제 도메인에 대해 실제 해석을 수행(목적지가 다이렉트 노드인 경우)하거나, SNI를 지원하는 프록시 프로토콜에 도메인을 그대로 넘겨 실제 아웃바운드 연결을 수립.

이 전체 과정에서 애플리케이션이 체감하는 것은 "즉시 응답"하는 DNS입니다. Fake-IP는 애초에 네트워크를 거쳐 권한 있는 DNS 서버에 물어보지 않기 때문에, 로컬 예약 주소 하나를 할당하는 데는 거의 지연이 없습니다. 이것이 redir-host에 비해 가장 직접적인 장점입니다. DNS 질의 지연이 거의 0에 가깝고, 동시에 규칙 매칭 단계에서 얻는 것이 IP가 아닌 완전한 도메인이므로 DOMAIN 규칙의 매칭 정확도도 더 높습니다.

Fake-IP와 redir-host의 차이

redir-host 모드는 다른 길을 갑니다. Clash가 실제로 도메인을 사용 가능한 IP로 해석해 애플리케이션에 반환하지만, 프록시 전달 단계에서 HTTP Host 헤더나 TLS SNI 필드를 읽어 도메인을 다시 식별한 뒤 규칙을 매칭합니다. 장점은 애플리케이션이 항상 실제 IP를 받는다는 점으로, 실제 IP에 강하게 의존하는 일부 시나리오(예: 프로그램이 자체적으로 IP 화이트리스트를 판단하는 경우)에서 문제가 덜 생깁니다. 대가는 매번 질의마다 실제 해석이 이뤄져 DNS 지연이 그대로 남고, 평문 도메인 정보를 담지 않는 프로토콜(일부 UDP 애플리케이션, 비표준 포트 트래픽)에 대한 식별 능력이 제한적이라는 점입니다.

비교 항목	Fake-IP	redir-host
DNS 응답 속도	로컬에서 즉시 생성, 지연 거의 없음	실제 해석 필요, 상류 DNS에 따라 지연 변동
규칙 매칭 근거	복원된 완전한 도메인	Host / SNI 필드 역추적
애플리케이션이 받는 IP	가상 예약 주소	실제 IP
비 HTTP/TLS 트래픽 식별	프로토콜 특징에 의존하지 않아 더 안정적	프로토콜 안에서 도메인을 읽어야 해 일부 상황 무력화
전형적인 부작용	일부 앱의 IP 화이트리스트/인증서 바인딩 검증에서 이상 동작 가능	DNS 계층 지연이 누적, 콜드 스타트 체감이 떨어짐

대부분의 Clash Meta(mihomo) 커널 기본 배포판은 Fake-IP를 기본값 또는 권장 모드로 설정합니다. 특히 TUN 모드와 함께 쓸 때 더 그렇습니다. TUN이 시스템의 모든 네트워크 계층 트래픽을 인수하므로, Fake-IP의 도메인 복원 메커니즘이 시스템 프록시 포트를 경유하는 트래픽뿐 아니라 다양한 애플리케이션의 연결 요청을 더 포괄적으로 커버할 수 있습니다.

Fake-IP에서 자주 걸리는 함정

Fake-IP도 대가가 없는 것은 아닙니다. 커뮤니티에서 자주 제보되는 문제는 다음과 같습니다.

내부망 서비스 해석 이상: NAS, 라우터 관리 페이지, 사내망 프린터 등 장치의 도메인까지 Fake-IP가 인수하면 애플리케이션은 가상 주소를 받게 되고, 이 연결이 Clash를 거치지 않는 경우(예: 직접적인 내부망 통신, 프록시 우회) 연결이 실패합니다.
실제 IP 검증이 필요한 프로그램: 일부 클라이언트 소프트웨어는 애플리케이션 계층에서 해석된 IP를 기록/대조합니다(일부 기업용 VPN 클라이언트, 인증서 바인딩 검증이 엄격한 서비스에서 흔함). Fake-IP가 반환하는 가상 주소는 이런 검증을 곧바로 실패시킵니다.
IP 기반 지역 판단 오류: 프로그램이 DNS가 반환한 IP를 직접 가져와 지역 판단을 수행하는 경우(표준 도메인 연결 흐름을 따르지 않는 경우), Fake-IP의 예약 대역은 지리 정보를 담고 있지 않으므로 판단 결과가 왜곡됩니다.
일부 mDNS/내부망 디스커버리 프로토콜과의 충돌: 내부망 기기 검색은 실제 대역 내 주소 브로드캐스트에 의존하는데, Fake-IP가 인수하면 기기 검색이 실패할 수 있습니다.

이런 사례들의 공통점은 원래 "다이렉트로 처리돼야 하며 Clash의 분기 처리 영향을 받지 않아야 할" 도메인이 Fake-IP의 기본 인수 범위에 들어가버려 문제가 생긴다는 것입니다. 해법은 Fake-IP를 끄는 것이 아니라, 이런 도메인들을 인수 범위에서 정밀하게 제외하는 것입니다. 이것이 바로 fake-ip-filter가 존재하는 이유입니다.

fake-ip-filter 제외 목록 작성법

이 설정 항목은 DNS 설정 블록 아래에 위치하며, "Fake-IP 모드라도 응답을 조작하지 말고 실제 해석을 거치라"고 선언하는 도메인 규칙 묶음입니다. 와일드카드를 지원하며 기본 구조는 다음과 같습니다.

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 8.8.8.8
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.market.xiaomi.com"
    - "time.*.com"
    - "ntp.*.com"
    - "*.msftncsi.com"
    - "www.msftconnecttest.com"

자주 쓰는 작성 요령은 다음과 같습니다.

*.lan, *.local 같은 와일드카드 접미사는 내부망 기기에서 흔히 쓰이는 로컬 도메인 접미사를 제외하는 데 쓰입니다;
라우터, NAS 관리 패널이 고정 도메인(예: 제조사가 할당한 DDNS 도메인)을 사용한다면 별도로 한 줄씩 정확히 제외하는 것을 권장합니다;
시스템 수준 연결 감지 도메인(Windows의 msftncsi.com, msftconnecttest.com 등)은 실제 해석을 유지시켜 시스템이 "네트워크 연결 없음"으로 오판하는 것을 방지합니다;
시간 동기화(NTP) 관련 도메인은 제외를 권장합니다. 일부 클라이언트는 시간 동기화 응답 지연에 민감합니다;
특정 앱의 로그인/검증 도메인에서 연결 이상이 반복적으로 발생한다면, 먼저 해당 도메인만 filter에 넣어 테스트해보고 문제가 사라지는지 확인해도 좋습니다.

순서와 출처에 주의

Clash Meta(mihomo) 프런트엔드(Clash Verge, Clash for Windows 파생판, CFW 등)마다 설정 파일 병합 정책이 완전히 같지는 않습니다. 구독으로 생성된 설정을 쓰는 경우, 직접 추가한 fake-ip-filter가 구독 갱신 후 덮어써질 수 있습니다. 자주 쓰는 제외 항목은 구독 원본 파일을 직접 수정하지 말고 로컬 오버라이드(override) 설정에 작성하는 것을 권장합니다.

redir-host로 전환하거나 Fake-IP를 꺼야 하는 경우

Fake-IP는 대부분의 사용 시나리오에 적합한 기본 선택이며, 특히 규칙 기반 분기 처리와 TUN 모드를 함께 쓸 때 더 일관된 체감을 줍니다. 다만 다음과 같은 상황이라면 전환이나 조정을 고려할 수 있습니다.

전체 네트워크 환경이 내부망 다중 기기 간 도메인 상호 접근에 크게 의존하고 있어(가정용 NAS 클러스터, 자체 구축 내부망 서비스가 많은 경우) 제외 목록 유지 비용이 이미 이익보다 커진 경우;
사용 중인 클라이언트 소프트웨어가 "DNS 결과는 반드시 실제 공인 IP여야 한다"고 명시적으로 요구하며, 해당 소프트웨어가 Fake-IP 대역을 전혀 허용하지 않는 경우;
매우 기본적인 분기 처리 기능만 필요하고 DNS 지연에 민감하지 않으며, "보이는 그대로"의 실제 IP로 점검하는 경험을 더 중시하는 경우(ping, nslookup 같은 도구로 바로 대조하기 편함).

전환 방법은 간단합니다. enhanced-mode를 fake-ip에서 redir-host로 바꾸기만 하면 되고, 규칙 세트 자체는 손댈 필요가 없습니다. DOMAIN 계열 규칙은 두 모드 모두에서 정상 작동하며, 차이는 오직 하위의 응답 메커니즘에만 있습니다.

점검 순서 정리

"특정 도메인에 연결이 안 되는데 다이렉트는 정상이고 프록시 규칙도 문제없어 보이는" 상황을 만나면 다음 순서로 점검해볼 수 있습니다.

현재 DNS 모드를 확인(설정 파일의 enhanced-mode 필드 또는 클라이언트 화면의 DNS 설정을 확인);
Fake-IP 모드라면 해당 도메인 또는 그 대역이 원래 내부망 다이렉트로 처리돼야 하는데 fake-ip-filter에 추가되지 않았는지 확인;
클라이언트 로그나 연결 패널을 확인해, 이 연결의 목적지 IP가 fake-ip-range에 선언된 대역(기본적으로 대개 198.18.0.0/16) 내에 있는지 확인;
의심되는 도메인을 임시로 fake-ip-filter에 추가한 뒤 커널을 재시작해 테스트하고, 문제가 사라지는지 확인;
여전히 해결되지 않으면 enhanced-mode를 임시로 redir-host로 전환해 대조 테스트를 진행하며 문제 범위를 좁혀나갑니다.

Fake-IP의 응답 메커니즘을 이해하고 나면, 대부분의 "DNS 관련 연결 이상"은 결국 "이 도메인이 Fake-IP 인수 대상이어야 하는가"라는 단 하나의 질문으로 귀결되며, 점검 경로가 처음 생각했던 것보다 훨씬 명료해집니다.