Clash Fake-IP 모드 원리: DNS 매핑 과정·사용 사례·제외 항목

Clash, Clash Meta 및 후속 유지보수 분기인 mihomo의 DNS 설정에서 Fake-IP는 쉽게 오해하는 옵션입니다. 반환되는 주소는 실제 IP처럼 보이지만, 주된 목적은 원격 서버를 직접 나타내는 것이 아니라 커널이 연결을 가로챌 때 원래 도메인을 다시 찾아낼 수 있도록 하는 데 있습니다. 이 점을 이해해야 연결 실패의 원인이 DNS인지, 규칙인지, 프록시 노드인지, 아니면 애플리케이션 자체의 네트워크 동작인지 판단할 수 있습니다.

Fake-IP는 도메인 규칙 중심의 설정에 특히 적합하며 TUN 모드와 함께 사용하는 경우도 많습니다. 애플리케이션이 미리 도메인을 해석해 규칙 정보가 사라지는 문제를 줄일 수 있지만, 모든 기기·프로토콜·LAN 이름이 매핑 주소를 사용하기에 적합한 것은 아닙니다. 무작정 제외 목록을 늘리기보다 조회와 연결이 어떤 경로를 거치는지 먼저 확인한 뒤, 실제 주소가 필요한 대상에만 필터를 설정하는 것이 올바른 방법입니다.

Fake-IP가 해결하는 핵심 문제

일반 DNS 조회는 도메인을 실제 IP로 변환합니다. 이후 애플리케이션이 이 IP에 연결할 때 프록시 커널이 대상 주소만 확인하면 원래 도메인이 연결 정보에서 이미 사라졌을 수 있습니다. 그러면 DOMAIN-SUFFIX, DOMAIN-KEYWORD 및 특정 도메인 규칙을 직접 매칭하기 어려워지고 IP, GeoIP 또는 기본 규칙으로 대체됩니다. 하나의 IP에서 여러 사이트를 제공하는 콘텐츠 전송 네트워크에서는 이러한 성능 저하가 특히 두드러집니다.

Fake-IP는 Clash 내장 DNS가 조회를 받아 도메인에 임시 매핑 주소를 할당하고, ‘도메인—매핑 주소’ 관계를 저장하는 방식입니다. 애플리케이션은 이 주소를 받아 연결을 시작하고 트래픽은 다시 커널로 들어옵니다. 커널은 매핑 테이블로 원래 도메인을 식별한 뒤 도메인 규칙에 따라 정책을 선택합니다. 실제 원격 서버에 접속할 때는 설정에 따라 사용 가능한 실제 주소를 다시 조회하고, 직접 연결하거나 선택한 프록시를 통해 연결합니다.

많은 설정에서 198.18.0.1/16을 기본 주소 풀로 사용합니다. 이 대역은 벤치마크 테스트 용도로 예약되어 있어 일반적으로 공용 인터넷에서 라우팅되지 않습니다. 커널은 공개 인터넷에서 사용되지 않아야 하는 이 주소 범위로 매핑을 구성해 일반 공인 대상과 충돌할 가능성을 줄입니다. 로컬 테스트 네트워크가 같은 대역을 이미 사용하고 있다면 라우팅 판단이 겹치지 않도록 주소 풀을 변경해야 합니다.

Fake-IP와 Redir-Host의 차이

redir-host 모드는 일반적으로 실제 조회 결과를 애플리케이션에 반환하므로 연결 대상이 기존 네트워크 동작에 더 가깝습니다. 실제 IP에 의존하는 일부 프로그램에서는 이해하기 쉽지만, 도메인 규칙이 정확히 매칭되는지는 트래픽 진입점, 스니핑 기능 및 애플리케이션의 조회 경로에 영향을 받습니다. Fake-IP는 매핑 관계로 도메인 컨텍스트를 능동적으로 보존하므로 세밀한 도메인 라우팅이 필요한 설정에 더 적합합니다.

비교 항목	Fake-IP	Redir-Host
애플리케이션에 반환되는 주소	주소 풀의 매핑 주소	상위 DNS의 실제 결과
도메인 정보 보존	커널 매핑 테이블에 의존, 경로가 명확함	진입점·스니핑 또는 기타 컨텍스트에 의존
도메인 규칙 매칭	대체로 안정적	IP 매칭으로 먼저 전환될 수 있음
특수 기기 호환성	제외 설정이 필요할 수 있음	일반 DNS 동작에 더 가까움

DNS 조회부터 규칙 매칭까지의 전체 과정

Fake-IP 문제를 점검할 때는 한 번의 DNS 조회만 확인해서는 안 됩니다. 전체 경로에는 최소한 애플리케이션의 조회 요청, 내장 DNS 응답, 애플리케이션의 매핑 주소 연결, 커널의 도메인 복원, 규칙 매칭, 상위 DNS 조회라는 여섯 단계가 포함됩니다. 어느 한 단계라도 Clash를 우회하면 결과가 예상과 달라질 수 있습니다.

애플리케이션이 도메인을 조회합니다. 브라우저, 게임 클라이언트 또는 시스템 서비스가 설정된 DNS 주소에 A 또는 AAAA 레코드를 요청합니다. 조회가 Clash 내장 DNS로 들어오지 않으면 Fake-IP 설정은 적용되지 않습니다.
커널이 제외 규칙을 확인합니다. 도메인이 fake-ip-filter에 매칭되면 커널은 실제 조회 결과를 반환하고, 매칭되지 않으면 매핑 주소를 할당합니다.
매핑을 생성하거나 읽습니다. 커널이 Fake-IP 주소 풀에서 주소를 가져와 원래 도메인과 연결합니다. 같은 도메인을 다시 조회하면 기존 매핑을 재사용할 수 있으며, 구체적인 수명은 커널 캐시가 관리합니다.
애플리케이션이 연결을 시작합니다. 애플리케이션은 매핑 주소를 대상으로 TCP 또는 UDP 세션을 수립합니다. 시스템 프록시 모드와 TUN 모드는 가로채는 경로가 다르지만, 핵심은 연결이 다시 Clash로 들어와야 한다는 점입니다.
대상 도메인을 복원합니다. 커널이 매핑 테이블을 읽어 대상을 조회 당시의 도메인으로 되돌린 뒤 규칙 매칭을 수행합니다.
정책과 조회 경로를 선택합니다. 규칙에 따라 직접 연결, 프록시 또는 특정 정책 그룹을 사용합니다. 실제 연결이 필요할 때는 DNS 설정에 따라 원격 서버의 실제 주소를 조회합니다.

이 메커니즘은 흔히 발생하는 한 가지 현상도 설명해 줍니다. 명령줄에서 nslookup을 실행해 매핑 주소가 보인다고 해서 접속이 프록시를 통해 이루어진다는 뜻은 아닙니다. DNS 응답은 매핑 단계만 완료한 것이며, 최종 정책은 이후 연결과 규칙이 결정합니다. 반대로 애플리케이션이 내장 DoH, 고정 IP 또는 자체 DNS 채널을 사용하면 시스템 조회 자체가 나타나지 않을 수 있으므로 Fake-IP가 도메인 정보를 저절로 확보할 수도 없습니다.

시스템 프록시와 TUN 모드의 차이

시스템 프록시 모드에서는 프록시 설정을 따르는 HTTP 또는 SOCKS 애플리케이션이 도메인을 프록시 측에 직접 전달할 수 있어 일부 환경에서는 Fake-IP에 의존하지 않습니다. 시스템 프록시 설정을 읽지 못하는 애플리케이션은 별도의 투명 가로채기 방안이 없으면 직접 연결할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스 계층에서 더 많은 시스템 트래픽을 수신하므로 DNS 하이재킹, Fake-IP 및 라우팅 설정과 함께 사용하는 경우가 많습니다.

TUN을 사용한다고 해서 모든 DNS가 자동으로 커널에 들어오는 것은 아닙니다. 운영체제가 암호화 DNS를 사용할 수 있고 브라우저가 별도의 보안 DNS를 활성화할 수도 있습니다. 설정할 때는 DNS 하이재킹 범위, 수신 포트, LAN 공유 방식 및 시스템 방화벽 상태를 확인해야 합니다. 조회가 외부 DNS로 나가고 연결만 TUN에 의해 가로채인다면 커널에는 대개 실제 IP만 보이며, 도메인 규칙은 스니핑을 통해 복원해야 할 수 있습니다.

mihomo 기본 설정 방법

다음은 필드 간 관계를 이해하기 위한 간소화된 예시입니다. 실제 클라이언트는 그래픽 인터페이스로 일부 필드를 생성하거나 사용자 재정의 설정과 구독 내용을 병합할 수 있습니다. 수정하기 전에 원본 설정을 보관하고, 클라이언트 로그에서 현재 어떤 파일을 불러오는지 확인해야 합니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
    - "time.*.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

enable은 내장 DNS를 제어하고, enhanced-mode는 향상 모드를 선택하며, fake-ip-range는 매핑 주소 풀을 정의하고, fake-ip-filter는 실제 결과를 반환할 도메인을 결정합니다. nameserver는 주요 상위 리졸버입니다. default-nameserver는 DoH, DoT 등 상위 서버 자체의 도메인을 해석할 때 주로 사용되므로 일반적으로 직접 접근 가능한 IP 주소 형식의 리졸버를 지정해야 합니다.

설정 형식은 커널 버전과 클라이언트 패키징 방식에 따라 달라집니다. mihomo는 다양한 DNS 필드와 규칙 표현을 지원하지만, 구버전 Clash 클라이언트가 모든 새 필드를 인식하는 것은 아닙니다. 여러 클라이언트에서 구독을 사용한다면 각 클라이언트에 연결된 커널과 버전을 먼저 확인해야 합니다. 특정 화면에서 필드를 저장할 수 있다고 해서 실제 실행 중인 커널이 그 값을 적용했다고 단정해서는 안 됩니다.

상위 DNS와 라우팅의 관계

상위 DNS의 선택은 실제 주소 획득, 오염 회피 및 연결 지연에 영향을 주지만 프록시 규칙과는 다른 계층입니다. 특정 도메인을 해외 DoH로 해석한다고 해서 연결이 반드시 프록시를 거치는 것은 아니며, 로컬 DNS를 사용한다고 해서 해당 연결이 반드시 직접 연결되는 것도 아닙니다. 최종 정책은 규칙 순서와 매칭 결과에 따라 결정됩니다.

일부 mihomo 설정에서는 nameserver-policy를 사용해 도메인 규칙별로 서로 다른 상위 DNS를 지정할 수도 있습니다. 예를 들어 LAN 또는 특정 지역 도메인은 로컬 리졸버를 사용하고, 그 외 도메인은 암호화 리졸버를 사용하게 할 수 있습니다. 이 기능은 조회 요구 사항을 명확히 파악한 설정에 적합하지만 규칙이 많아지면 문제 해결이 어려워집니다. 문제가 발생하면 먼저 사용 가능한 단일 상위 DNS로 줄여 Fake-IP 흐름이 정상인지 확인한 뒤 라우팅을 다시 추가하세요.

적합한 환경과 그대로 적용하면 안 되는 환경

도메인 규칙 중심의 구독에 적합

많은 구독 규칙은 도메인 접미사, 키워드 및 규칙 집합을 중심으로 구성됩니다. Fake-IP는 연결이 규칙 엔진에 들어올 때 도메인을 보존해 하나의 CDN 주소가 여러 서비스를 제공할 때 발생하는 오판을 줄일 수 있습니다. 브라우저, 데스크톱 애플리케이션 및 모바일 애플리케이션을 함께 사용하는 기기에서는 단순히 대상 IP에 의존하는 것보다 일반적으로 예측 가능하게 작동합니다.

TUN 가로채기에 적합한 데스크톱 환경

일부 애플리케이션은 시스템 프록시를 읽지 않고, 어떤 프로그램은 TCP와 UDP를 동시에 사용합니다. TUN 모드는 더 넓은 범위의 트래픽을 가로챌 수 있고 Fake-IP는 커널이 DNS 조회와 이후 연결을 연결하는 데 도움을 줍니다. 두 기능을 함께 사용할 때는 ‘조회가 내장 DNS로 들어오는가’와 ‘연결이 TUN을 통과하는가’를 별도의 항목으로 점검해야 합니다. TUN이 실행 중이라는 사실만으로 DNS 경로가 올바르다고 판단해서는 안 됩니다.

LAN 게이트웨이에서는 더 신중해야 합니다

Clash 또는 mihomo를 라우터, 보조 게이트웨이 또는 홈 서버에 배포하면 클라이언트 기기가 게이트웨이를 DNS로 사용할 수도 있고, 통신사 DNS·라우터가 배포한 IPv6 DNS·애플리케이션 내장 DoH를 계속 사용할 수도 있습니다. 게이트웨이가 전체 LAN에 Fake-IP를 반환한다면 이러한 매핑 연결이 모두 같은 커널로 되돌아오는지 확인해야 합니다. 그렇지 않으면 클라이언트가 매핑 주소를 다른 라우터로 직접 보내 연결 시간이 초과될 수 있습니다.

LAN 기기 검색, 프린터, NAS, 스마트홈 및 미디어 캐스팅은 .local, 단일 레이블 호스트명, mDNS, LLMNR 또는 제조사 자체 도메인에 의존하는 경우가 많습니다. 이러한 이름은 공용 DNS가 처리해야 하는 대상이 아닐 수 있습니다. 게이트웨이 환경에서는 보통 로컬 리졸버를 유지하고 내부 도메인에 실제 조회 또는 전용 상위 DNS를 지정해야 합니다.

게임과 실시간 통신은 증상에 따라 판단해야 합니다

일부 게임 런처는 도메인으로 리소스를 다운로드하지만 실제 대전 단계에서는 UDP, 고정 IP 또는 지역별 조정 서비스를 통해 통신합니다. Fake-IP가 런처 웹 인터페이스에서는 정상 작동해도 지연 측정, 서버 목록 또는 안티치트 구성 요소의 주소 판단에 영향을 줄 수 있습니다. 문제가 발생했다고 DNS 기능 전체를 바로 끄기보다 로그에서 실패한 도메인을 확인한 뒤 실제 주소가 필요한 도메인만 필터 목록에 추가하세요.

Fake-IP 제외 항목 설계 방법

fake-ip-filter의 목적은 특정 도메인이 매핑을 건너뛰고 실제 IP를 애플리케이션에 직접 반환하도록 하는 것입니다. 제외 범위가 넓을수록 도메인 규칙 매칭에 사용할 수 있는 연결이 줄어들므로, 제외 목록은 출처를 설명할 수 없는 긴 목록을 복사하기보다 구체적인 호환성 요구를 중심으로 구성해야 합니다.

LAN 및 로컬 도메인

*.lan, *.local 및 가정 내 사용자 지정 접미사는 우선 확인할 가치가 있습니다. NAS가 storage.home.arpa를 사용한다면 로컬 DNS와 실제 접미사를 함께 고려해 해당 규칙을 설정해야 합니다. 도메인만 제외하고 조회에 응답할 로컬 리졸버를 마련하지 않으면 올바른 주소를 얻을 수 없습니다.

시간 동기화 및 네트워크 연결 확인

일부 시스템 서비스는 특정 도메인으로 NTP 서버를 찾거나 네트워크 사용 가능 여부를 확인하고, 현재 인증 포털 로그인이 필요한지 판단합니다. 이러한 프로그램은 실제 주소를 필요로 할 수 있으며 DNS와 HTTP 응답을 비교하기도 합니다. 기기에 ‘네트워크에 연결되지 않음’이 자주 표시되지만 브라우저는 정상적으로 접속된다면 시스템 연결 확인 도메인과 시간 동기화 도메인부터 로그를 확인하세요.

기기 검색, 음성 및 게임 서비스

LAN 브로드캐스트에 의존하는 기기는 일반적으로 로컬 이름을 Fake-IP로 매핑해서는 안 됩니다. 게임과 음성 프로그램은 로그인·업데이트·매칭·실시간 통신 도메인을 구분하고, 지나치게 넓은 와일드카드로 제조사 전체 도메인을 제외하지 않아야 합니다. 제외 범위가 넓으면 다운로드 도메인이 기존 프록시 규칙을 잃고 실제 IP 또는 기본 규칙으로만 처리될 수 있습니다.

dns:
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.home.arpa"
    - "localhost"
    - "time.windows.com"
    - "time.apple.com"

와일드카드, 규칙 집합 및 추가 매칭 문법의 지원 여부는 커널 버전에 따라 다를 수 있습니다. 가장 안전한 방법은 먼저 명확한 전체 도메인으로 검증한 뒤 로그를 바탕으로 필요한 하위 도메인 범위만 확장하는 것입니다. 설정을 불러온 후에는 시스템 DNS 캐시를 비우고 애플리케이션의 기존 장기 연결을 종료한 다음 다시 조회해야 변경 사항이 이전 캐시에 가려지지 않습니다.

일반적인 장애와 점검 순서

조회 결과가 여전히 실제 IP로 표시됨

먼저 클라이언트에 표시된 실행 모드와 실제 커널 설정에 enhanced-mode: fake-ip가 지정되어 있는지 확인한 다음 도메인이 필터 항목에 매칭되었는지 점검하세요. 이어서 테스트 도구가 어떤 DNS 서버를 사용하는지 확인합니다. 브라우저 보안 DNS, 시스템 DoH, VPN 프로그램 또는 LAN DHCP가 배포한 다른 DNS가 조회를 Clash에서 우회시킬 수 있습니다.

조회는 되지만 연결이 계속 시간 초과됨

매핑 주소가 보인다면 DNS 단계는 커널에 들어왔을 가능성이 있지만 이후 연결까지 가로채였다고 볼 수는 없습니다. 시스템 프록시 모드에서는 프록시 설정을 따르지 않는 애플리케이션이 198.18.x.x에 직접 접속할 수 있습니다. TUN 모드에서는 가상 네트워크 인터페이스, 라우팅 테이블, 방화벽 권한 및 DNS 하이재킹 설정을 확인해야 합니다. 게이트웨이에 배포한 경우에는 Fake-IP 주소 풀의 트래픽이 게이트웨이 커널로 올바르게 돌아오는지도 확인하세요.

규칙이 도메인 기준으로 매칭되지 않음

로그의 대상 유형을 확인하세요. 로그에 실제 IP만 표시된다면 조회가 내장 DNS를 우회했거나, 애플리케이션이 고정 IP에 직접 연결했거나, 해당 도메인이 Fake-IP 필터에 추가되었을 가능성이 있습니다. 로그에 도메인이 표시되는데도 정책이 잘못 적용된다면 규칙 순서를 점검하세요. Clash는 일반적으로 위에서 아래 순서로 매칭하므로 더 포괄적인 규칙이 앞에 있으면 연결을 먼저 가로챕니다.

LAN 기기 이름으로 접속할 수 없음

이름이 어떤 방식으로 해석되는지 확인하세요. .local은 mDNS와 관련된 경우가 많아 일반 유니캐스트 DNS를 거치지 않을 수 있고, 사용자 지정 NAS 도메인은 라우터 DNS가 응답할 수 있습니다. 해당 도메인을 내부 주소를 반환할 수 있는 리졸버로 전달하고 필요하면 Fake-IP 제외 항목에 추가해야 합니다. DIRECT 규칙만 설정해서는 잘못된 DNS 응답을 고칠 수 없습니다. 규칙 매칭은 조회 경로 이후에 일어나기 때문입니다.

설정을 바꿨지만 결과가 변하지 않음

DNS 결과는 운영체제, 브라우저, 애플리케이션 및 커널에 캐시될 수 있습니다. 테스트할 때는 설정을 다시 불러오고 시스템 DNS 캐시를 비운 뒤 애플리케이션을 완전히 종료했다가 다시 실행하세요. 웹페이지 새로고침만으로는 부족할 수 있습니다. 브라우저가 기존 연결을 계속 재사용할 수 있기 때문입니다. 클라이언트에서 현재 설정을 확인할 수 있다면 구독 업데이트 또는 재정의 과정이 수동 변경 사항을 덮어쓰지 않았는지도 확인하세요.

권장 최소 점검 목록

현재 실행 중인 커널과 버전이 사용 중인 DNS 필드를 지원하는지 확인합니다.
내장 DNS가 활성화되어 있고 테스트 조회가 해당 수신 주소로 실제 전송되는지 확인합니다.
복잡한 DNS 라우팅의 영향을 배제하기 위해 임시로 사용 가능한 상위 DNS 하나만 유지합니다.
대상 도메인이 fake-ip-filter에 매칭되는지 확인합니다.
매핑 주소에 대한 연결이 시스템 프록시 또는 TUN으로 들어가는지 확인합니다.
로그에서 도메인, 규칙 이름, 최종 정책 및 연결 오류를 대조합니다.
마지막으로 노드 연결성, UDP 지원 및 원격 서비스 상태를 확인합니다.

설정 결론: 먼저 전체 경로를 완성한 뒤 제외 항목을 추가하세요

Fake-IP의 핵심은 ‘특수한 IP 하나를 반환하는 것’이 아니라 DNS 조회와 이후 연결 사이에 매핑 경로를 완성하는 데 있습니다. 조회가 Clash로 들어오고, 연결이 다시 Clash로 들어오며, 매핑 테이블이 도메인을 복원하고, 규칙이 정책을 선택하는 네 단계가 모두 갖춰져야 도메인 라우팅이 안정적으로 작동합니다. 어느 한 단계라도 커널을 우회하면 조회는 정상인데 연결되지 않거나, 연결은 성공해도 잘못된 규칙에 매칭되는 문제가 발생할 수 있습니다.

데스크톱 기기에서 mihomo와 TUN을 사용할 때는 기본 Fake-IP 설정부터 시작한 뒤 로그를 바탕으로 LAN, 시간 동기화, 게임 및 기기 검색 도메인을 추가하세요. 라우터와 보조 게이트웨이에서는 DHCP, IPv6 DNS, 주소 풀 라우팅 및 클라이언트 암호화 DNS도 추가로 확인해야 합니다. 제외 항목은 작고 명확하게 유지하고 각각 재현 가능한 호환성 요구와 연결해야 구독 업데이트, 커널 업그레이드 및 기기 이전 후에도 설정을 쉽게 관리할 수 있습니다.