Clash Meta（mihomo）설정에서 DNS 모드는 도메인 확인, 규칙 매칭 및 연결 수립에 직접적인 영향을 줍니다. Fake-IP는 그중 널리 사용되는 방식으로, 클라이언트가 대상 도메인을 실제 공인 IP로 즉시 확인하지 않고 전용 주소 풀의 가상 IP를 할당합니다. 내부에는 도메인과 가상 IP의 매핑이 저장됩니다. 앱에는 이 가상 주소가 보이고, 프록시 코어는 이후 연결 단계에서 원래 도메인을 복원한 뒤 규칙에 따라 직접 연결, 프록시 또는 거부를 결정할 수 있습니다.

이 과정은 TUN 모드와 함께 사용하는 경우가 많지만, 두 개념은 서로 다릅니다. Fake-IP는 DNS 응답과 도메인 보존을 처리하고, TUN은 시스템과 앱에서 발생한 네트워크 트래픽을 어떻게 전달받을지 처리합니다. 두 기능의 경계를 이해해야 문제가 DNS, 규칙, 라우팅 또는 앱 자체 중 어디에서 발생했는지 판단할 수 있습니다. 이 글에서는 확인 과정, 설정 선택, 활용 사례와 문제 해결 순서에 따라 설명합니다.

Fake-IP가 실제로 바꾸는 것

일반적인 redir-host 방식에서는 앱이 시스템 리졸버에 도메인을 조회하고, 리졸버가 실제 IP를 반환하면 앱이 해당 IP로 연결합니다. 프록시 코어가 대상 IP만 확인할 경우 도메인 스니핑, 추가 규칙 또는 알려진 주소 대역에 의존해 접속 대상을 추정해야 합니다. HTTPS 트래픽은 TLS의 SNI에서 도메인을 얻을 수 있지만, 일부 암호화 프로토콜이나 비표준 프로토콜에서는 이러한 추정이 항상 가능하지 않습니다.

Fake-IP 모드는 순서를 “도메인을 먼저 보존한 다음 연결 수립”으로 바꿉니다. 앱이 example.com을 조회하면 DNS 모듈은 주소 풀의 가상 주소(예: 198.18.0.23)를 반환합니다. 이 주소는 대상 서버의 실제 주소가 아니라 코어가 해당 도메인을 식별하기 위한 인덱스입니다. 앱이 198.18.0.23으로 연결하면 프록시가 트래픽을 인계받고, 코어는 매핑 테이블을 통해 example.com을 복원한 뒤 도메인 규칙을 적용합니다.

일반적인 Fake-IP 주소 풀에는 198.18.0.1/16과 같은 별도 예약 테스트 네트워크가 사용됩니다. 이러한 주소를 공인 인터넷 대상처럼 사용해서는 안 됩니다. 주소 풀의 크기, 제외 목록과 매핑 유지 기간은 코어와 설정에 따라 결정됩니다. 가상 IP와 도메인의 매핑은 보통 캐시에 유지되므로 같은 도메인이 일정 시간 동일한 주소를 받을 수 있습니다. 캐시 삭제, 설정 재로드 또는 주소 풀 변경 후에는 새 주소가 할당될 수도 있습니다.

하나의 요청이 처리되는 과정

  1. 앱이 DNS 조회를 시작하며, 조회 대상은 최종 IP가 아니라 도메인입니다.
  2. Clash가 조회를 수신하고 nameserver, fallback, fake-ip-filter 등의 설정에 따라 요청을 처리합니다.
  3. Fake-IP 모듈이 도메인 매핑을 생성하고 주소 풀의 가상 IP를 앱에 반환합니다.
  4. 앱이 가상 IP에 연결하면 시스템 프록시, 투명 프록시 또는 TUN이 이 연결을 Clash로 전달합니다.
  5. Clash가 매핑을 바탕으로 도메인을 복원한 뒤 도메인 규칙, 프로세스 규칙, IP 규칙과 최종 규칙을 차례로 적용합니다.
  6. 정책 그룹을 선택한 다음 코어가 직접 연결 또는 프록시 경로를 통해 실제 대상에 연결합니다.

여기서 핵심은 “규칙이 확인하는 대상”입니다. 매핑이 유효하고 트래픽이 Clash를 통과하면 도메인 규칙이 연결 초기에 적용될 수 있습니다. 앱이 시스템 DNS를 우회하거나 IP를 하드코딩해 사용하거나, 트래픽이 Clash로 들어오지 않으면 Fake-IP가 도메인을 자동으로 복원할 수 없으며 라우팅 인계를 대신할 수도 없습니다.

Fake-IP, 실제 DNS 응답과 TUN 모드의 관계

Fake-IP와 redir-host는 DNS 응답 방식의 서로 다른 두 방향입니다. Fake-IP는 도메인 정보를 유지하는 데 중점을 두므로 안정적인 도메인 규칙 매칭이 필요한 환경에 적합합니다. redir-host는 일반 DNS의 동작에 가까워 앱이 실제 IP를 받으며, 실제 주소에 의존하는 일부 프로그램과의 호환성이 더 좋을 수 있습니다. 두 방식 모두 올바른 DNS 가로채기, 시스템 프록시 또는 트래픽 인계가 필요하며, 어느 한쪽이 반드시 더 빠르다고 단정할 수 없습니다.

TUN 모드는 다른 계층에 해당합니다. TUN을 활성화하면 시스템에 가상 네트워크 인터페이스가 생성되고, 라우팅 조건에 맞는 트래픽이 Clash로 전달됩니다. 이를 통해 HTTP 또는 SOCKS 시스템 프록시를 따르지 않는 프로그램과 일부 백그라운드 서비스 및 UDP 트래픽을 인계할 수 있습니다. TUN을 켠다고 DNS가 자동으로 올바르게 처리되는 것은 아닙니다. 시스템이 계속 외부 DNS로 조회를 보내거나 앱이 자체 암호화 DNS를 사용하면 Fake-IP 매핑이 전체 요청 과정에 참여하지 못할 수 있습니다.

구성 요소 주요 역할 흔한 오해
Fake-IP 도메인에 가상 주소를 할당하고 매핑을 유지합니다 원격 DNS 서버도 아니며 프록시 노드도 아닙니다
DNS 모듈 조회 요청을 받고 리졸버를 선택한 뒤 결과를 반환합니다 nameserver만 바꾸면 모든 DNS 유출 문제가 해결됩니다
TUN 시스템 라우팅의 네트워크 트래픽을 인계합니다 TUN을 켜면 모든 앱이 반드시 프록시를 사용합니다
규칙 시스템 도메인, IP, 포트 등의 조건에 따라 정책을 선택합니다 코어에 전혀 들어오지 않은 연결은 규칙으로 처리할 수 없습니다

데스크톱에서는 시스템 프록시만으로도 브라우저와 시스템 설정을 따르는 앱을 대체로 지원할 수 있습니다. 더 많은 프로그램을 포괄해야 한다면 TUN을 고려할 수 있습니다. Android에서는 VpnService가 일반적인 트래픽 인계 기반이며, 시스템 VPN 권한, 배터리 절전 정책과 다른 VPN 앱의 상태가 결과에 영향을 줍니다. iOS의 네트워크 확장 권한과 클라이언트 기능에도 고유한 제한이 있으므로 데스크톱용 TUN 설정을 그대로 적용해서는 안 됩니다.

Fake-IP 설정 전에 먼저 확인할 항목

설정 파일의 필드명과 사용 가능한 옵션은 현재 mihomo 버전의 문서와 클라이언트 인터페이스를 기준으로 확인해야 합니다. 클라이언트마다 DNS, TUN 및 오버라이드 설정의 편집 경로가 다를 수 있습니다. 아래 내용은 모든 플랫폼에 동일한 설정을 복사하라는 뜻이 아니라 점검 방법을 제시합니다.

1. DNS 요청을 누가 수신하는지 확인

먼저 클라이언트에서 코어 DNS가 활성화되어 있는지, 시스템 DNS 조회가 Clash로 전달되는지 확인합니다. 데스크톱 클라이언트는 로컬 수신 주소로 조회를 받을 수 있고, TUN 클라이언트는 DNS 가로채기로 UDP 또는 TCP 조회를 처리할 수 있습니다. 브라우저에서 “보안 DNS”를 활성화해 지정된 사업자에 직접 연결하면 시스템 DNS 설정이 적용되지 않을 수 있습니다. 테스트할 때는 앱 자체의 암호화 DNS를 잠시 끄거나 명확한 네트워크 정책에 포함하세요.

2. Fake-IP 주소 풀 계획

주소 풀에는 가상 매핑에 적합한 예약 네트워크를 사용하고, 실제 로컬 네트워크·회사 내부망·컨테이너 네트워크·일반적인 VPN 네트워크 대역은 피해야 합니다. 예를 들어 로컬 네트워크가 192.168.1.0/24라면 Fake-IP 주소 풀을 같은 대역으로 설정하지 마세요. 주소가 충돌하면 시스템이 가상 주소를 로컬 네트워크 호스트로 잘못 인식해 연결 시간 초과, 라우팅 오류 또는 일부 내부 서비스 접속 불가가 발생할 수 있습니다.

Fake-IP 주소 풀을 흔한 가정용 네트워크 대역으로 임의 설정해서는 안 됩니다. 설정 전에 현재 기기의 라우팅 테이블, Docker 브리지, 가상 머신 네트워크 카드와 회사 VPN이 사용하는 대역을 확인하세요. 주소 풀이 실제 네트워크와 겹친다면 프록시 노드를 반복해서 바꾸기보다 먼저 주소 풀을 변경하고 캐시를 삭제한 뒤 다시 테스트해야 합니다.

3. fake-ip-filter 설정

모든 도메인이 Fake-IP 응답에 적합한 것은 아닙니다. 로컬 네트워크 호스트명, 라우터 관리 주소, 실제 IP 판단이 필요한 서비스와 로컬 확인에 의존하는 일부 도메인은 보통 제외 목록에 추가해야 합니다. 필터링된 도메인은 실제 DNS 응답을 사용하거나 클라이언트 구현에 따라 원래 결과를 반환합니다. 처음부터 필터 범위를 지나치게 넓히면 많은 도메인이 실제 DNS로 돌아가 규칙 매칭과 DNS 동작을 파악하기 어려워집니다.

필터 목록은 실제 오류에 따라 추가하고, 변경할 때마다 목적을 기록하세요. 프린터 검색에 실패했다면 먼저 로컬 네트워크 도메인과 멀티캐스트 이름 확인을 점검할 수 있습니다. 특정 기업 내부망 도메인이 열리지 않는다면 해당 기업 DNS가 특정 네트워크에서만 사용 가능한지 확인하세요. 한 번의 요청 실패만으로 전체 최상위 도메인이나 모든 중국 본토 도메인을 제외해서는 안 됩니다.

4. nameserver와 fallback의 역할 확인

nameserver는 일반 리졸버이고, fallback은 보조 리졸버 또는 특정 판단에 사용하는 조회 소스입니다. 구체적인 동작은 코어 버전과 설정에 따라 달라집니다. 리졸버를 설정할 때는 접근 가능 여부, 응답 속도, 필요한 레코드 유형 지원 여부와 요청을 프록시를 통해 보낼지 확인해야 합니다. 리졸버에 접근할 수 없어도 Fake-IP가 캐시 결과를 반환할 수 있지만, 새 도메인은 조회 지연이나 연결 실패가 발생할 수 있습니다.

nameserver-policy를 설정했다면 규칙 문법과 도메인 범위가 정확한지 확인하세요. 이 정책의 목적은 도메인별로 적절한 리졸버를 선택하는 것이며 프록시 규칙을 대신하는 것이 아닙니다. DNS 조회가 성공해도 대상 연결 성공이 보장되는 것은 아니므로, 최종적으로는 규칙이 선택한 정책 그룹, 노드 상태와 원격 서비스의 응답도 확인해야 합니다.

Fake-IP 사용에 적합한 환경

설정이 도메인 규칙 기반 라우팅에 의존한다면 Fake-IP가 규칙의 맥락을 유지하는 데 더 유리한 경우가 많습니다. 예를 들어 도메인 접미사에 따라 직접 연결과 프록시를 구분하거나, 여러 서비스 그룹에 별도 정책 그룹을 적용하거나, 대상 IP만으로 판단할 때 발생하는 잘못된 라우팅을 줄이고 싶은 경우에 적합합니다. 연결 초기에 도메인 정보를 계속 사용할 수 있어 규칙 관리도 사용자가 실제로 보는 사이트명에 더 가깝습니다.

TUN 모드에서는 시스템 프록시를 따르지 않는 프로그램에 Fake-IP가 특히 도움이 됩니다. 프로그램이 시스템 네트워크 스택을 통해 DNS 조회를 보내고 반환된 주소에 연결하기만 하면 코어가 매핑으로 대상을 식별할 가능성이 있습니다. 하지만 프로그램이 자체 DNS, DoH, DoT를 사용하거나 도메인 조회 결과를 자체 캐시에 고정하면 별도 처리가 필요합니다. 일부 앱은 QUIC, IPv6 또는 자체 네트워크 프로토콜을 사용하므로 테스트할 때 프로토콜 차이도 고려해야 합니다.

로컬 네트워크 기기에는 Fake-IP를 신중하게 적용해야 합니다. 프린터, NAS, 스마트홈 컨트롤러, 라우터 관리 페이지와 로컬 게임 검색은 실제 로컬 주소, 멀티캐스트 또는 브로드캐스트에 의존하는 경우가 많아 이러한 트래픽이 프록시를 거치기에 적합하지 않을 수 있습니다. 관련 도메인을 fake-ip-filter에 추가하고 로컬 네트워크 대역에는 직접 연결 규칙을 설정하는 것이 안정적인 출발점입니다.

자주 발생하는 오류와 문제 해결 순서

브라우저에 DNS_PROBE_FINISHED_NXDOMAIN이 표시되거나 조회 시간이 초과됨

먼저 모든 도메인에서 문제가 발생하는지 특정 도메인에서만 발생하는지 확인합니다. Clash 로그에 DNS 요청이 기록되는지, 클라이언트의 DNS 수신이 시작되었는지 확인한 뒤 시스템이나 브라우저가 해당 수신 경로를 우회하지 않는지 점검하세요. 다음으로 접근 가능한 리졸버로 잠시 전환하고 클라이언트 DNS 캐시를 삭제한 뒤 설정을 다시 불러옵니다. 한 도메인만 실패한다면 nameserver-policy, 도메인 철자, 필터 목록과 해당 도메인의 레코드 유형을 확인합니다.

웹페이지는 열리지만 규칙이 잘못된 직접 연결 또는 프록시로 매칭됨

연결 세부 정보에서 대상 도메인, 대상 IP와 매칭된 규칙을 확인하세요. 연결 세부 정보에 Fake-IP 주소만 표시된다면 매핑이 올바르게 복원되지 않은 것입니다. 연결이 Clash에서 수신되지 않았거나 앱이 캐시된 IP를 사용하고 있을 수 있습니다. 실제 도메인이 표시되는데도 예상과 다른 규칙이 적용된다면 규칙 순서를 확인하세요. 더 구체적인 DOMAIN, DOMAIN-SUFFIX 또는 DOMAIN-KEYWORD 규칙은 더 포괄적인 규칙보다 앞에 배치하고, MATCH 최종 규칙은 맨 마지막에 둬야 합니다.

규칙을 변경한 뒤에는 저장하고 설정을 재로드해야 합니다. 파일만 편집하고 재로드하지 않으면 실행 중인 코어가 이전 규칙을 계속 사용할 수 있습니다. 테스트에는 새 연결을 사용하세요. 기존 연결과 캐시는 전체 DNS 조회 및 매칭 과정을 다시 거치지 않을 수 있습니다.

TUN 활성화 후 로컬 네트워크 기기 또는 회사 내부망이 작동하지 않음

먼저 TUN을 끄고 비교 테스트를 진행합니다. 끈 뒤 정상으로 돌아온다면 TUN 라우팅, 자동 라우팅, 엄격한 라우팅, DNS 가로채기와 우회 네트워크 대역 설정을 확인하세요. 가정용 라우터, 회사 내부망과 프린터가 있는 네트워크 대역이 잘못 프록시 정책으로 전달되지 않는지도 확인해야 합니다. 로컬 트래픽에는 규칙과 라우팅 모두 직접 연결을 허용해야 하며, IP-CIDR 규칙 하나만 작성하고 트래픽이 코어에 들어오지 않는다면 문제가 해결되지 않습니다.

여러 VPN, 가상 머신, 컨테이너와 보안 프로그램이 동시에 라우팅 테이블을 변경할 수 있습니다. 문제를 해결할 때는 불필요한 VPN이나 가상 네트워크 카드를 잠시 비활성화하고, TUN을 켜기 전후의 기본 경로와 DNS 서버를 기록하세요. Windows, Linux, Android는 권한 모델이 서로 다르므로 클라이언트에 “활성화됨”으로 표시되어도 시스템이 필요한 권한을 모두 부여했다는 뜻은 아닙니다.

일부 앱에서 인터넷 연결이 전혀 되지 않음

앱이 IPv6, QUIC, 하드코딩된 IP, 내장 DoH 또는 독립 프록시를 사용하는지 확인하세요. Fake-IP는 주로 도메인 조회를 기반으로 매핑을 만들므로 IP를 직접 사용하는 연결은 IP 규칙에 의존해야 할 수 있습니다. 앱이 IPv6를 우선 사용하는데 현재 TUN, 노드 또는 규칙이 IPv6를 지원하지 않으면 브라우저는 정상인데 특정 앱만 실패할 수 있습니다. 테스트 단계에서 IPv4, IPv6, TCP와 UDP를 각각 확인한 뒤 프로토콜이나 라우팅 범위를 조정하세요.

# 문제 해결 방향 확인용이며, 실제 필드는 현재 클라이언트와 mihomo 버전에 맞춰 확인
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

tun:
  enable: true
  auto-route: true
  dns-hijack:
    - any:53

위 예시는 필드 간 관계만 보여 주며 모든 시스템에서 그대로 사용해야 한다는 뜻은 아닙니다. dns-hijack, TUN 라우팅과 필터 항목은 클라이언트 패키징 및 버전 차이의 영향을 받을 수 있습니다. 특히 로컬 네트워크 도메인, 기업 DNS와 IPv6 환경에서는 기존 네트워크를 먼저 파악한 뒤 설정을 하나씩 추가해야 합니다.

반복해서 사용할 수 있는 점검 목록

  1. 현재 클라이언트 버전, 코어 버전, 시스템 버전과 네트워크 환경을 기록하고 기존 설정을 보관합니다.
  2. 다른 VPN, 프록시 프로그램과 브라우저의 독립 DNS를 끄고 변수를 하나로 제한한 테스트 환경을 구성합니다.
  3. 일반 도메인이 정상적으로 조회되는지 확인하고 Clash에 해당 DNS 요청이 표시되는지 관찰합니다.
  4. 반환된 주소가 Fake-IP 주소 풀에 속하는지 확인하고 주소 풀이 로컬 네트워크와 겹치지 않는지 점검합니다.
  5. 연결 세부 정보를 확인해 매핑이 도메인을 복원하는지, 실제로 매칭된 규칙과 정책 그룹이 무엇인지 대조합니다.
  6. 일반 웹페이지, 로컬 네트워크 기기, 로그인이 필요한 앱, UDP 서비스와 IPv6 서비스를 각각 테스트합니다.
  7. 한 번에 한 항목만 변경하고 저장, 재로드와 캐시 삭제를 마친 뒤 같은 테스트를 반복합니다.

redir-host로 전환한 뒤 특정 앱이 정상화된다면 해당 앱이 실제 IP, 로컬 네트워크 조회 또는 특수 프로토콜에 의존할 가능성이 있습니다. 이것만으로 Fake-IP 설정이 잘못되었다고 볼 수는 없습니다. 먼저 해당 도메인을 필터 목록에 추가하거나 앱 트래픽에 명확한 직접 연결 정책을 설정해 보세요. 반대로 redir-host에서 도메인 규칙이 자주 어긋나고 Fake-IP에서 규칙이 안정적이라면 노드만 바꾸기보다 DNS 가로채기와 매핑 회수부터 확인해야 합니다.

마무리: 요청 흐름에 따라 문제를 찾기

Fake-IP의 핵심 가치는 DNS, 연결 인계와 규칙 매칭 전반에서 도메인 정보를 유지하는 데 있습니다. Fake-IP는 단독으로 속도를 높이는 기능이 아니며, 사용 가능한 리졸버와 올바른 라우팅, 유효한 프록시 정책을 대신할 수도 없습니다. 적합한 설정은 기기 유형, 앱 프로토콜, 로컬 네트워크 구조와 TUN 인계 필요 여부에 따라 달라집니다.

오류가 발생하면 “앱의 DNS 조회—Clash의 주소 반환—트래픽의 코어 진입—매핑을 통한 도메인 복원—규칙에 따른 정책 선택—노드 연결 수립” 순서로 확인하는 것이 DNS나 노드를 반복해서 바꾸는 것보다 원인을 빠르게 찾는 데 도움이 됩니다. 로컬 네트워크, 기업 내부망과 특수 앱에는 명확한 예외 처리를 적용하고, 로그와 연결 세부 정보로 변경 사항을 매번 검증하면 Fake-IP 설정을 안정적으로 유지할 수 있습니다.