Clash Fake-IP 모드 원리 총정리: Redir-Host와의 차이 및 활용 시나리오

Fake-IP는 공인 대상 주소를 위조하는 방식이 아니라 도메인 정보를 보존하는 방식입니다

애플리케이션이 웹사이트에 접속할 때는 일반적으로 먼저 도메인에 해당하는 IP 주소를 조회한 다음 해당 주소로 TCP 또는 UDP 연결을 설정합니다. 기존 DNS 흐름에서는 애플리케이션에 실제 주소를 직접 전달합니다. 예를 들어 example.com을 공인 IPv4 주소로 조회하는 방식입니다. 트래픽이 프록시 코어로 들어오면 코어가 확인하는 대상은 이 IP만 남는 경우가 많습니다. 규칙이 도메인, GEOSITE 또는 도메인 접미사를 조건으로 사용할 때는 코어가 스니핑, DNS 매핑 기록 또는 추가 조회를 통해 도메인을 다시 복원해야 합니다.

Fake-IP가 바꾸는 부분은 로컬 DNS 응답 과정입니다. mihomo는 애플리케이션의 도메인 조회를 받으면 예약 주소 풀에서 합성 주소를 할당합니다. 기본적으로 흔히 사용하는 범위는 198.18.0.1/16이며, 이후 ‘합성 주소—원래 도메인’ 대응 관계를 코어의 매핑 테이블에 저장합니다. 애플리케이션은 이 합성 주소로 연결하고, TUN·투명 프록시 또는 제어된 네트워크 스택을 통해 트래픽이 다시 코어로 전달됩니다. mihomo는 테이블을 조회해 원래 대상 도메인을 확인할 수 있습니다.

애플리케이션이 www.example.com을 조회
        ↓
mihomo DNS가 198.18.0.23을 반환
        ↓
애플리케이션이 198.18.0.23:443에 연결
        ↓
mihomo가 매핑 테이블에서 www.example.com을 확인
        ↓
도메인 규칙에 따라 정책 그룹과 노드 선택
        ↓
프록시 노드를 통해 실제 대상에 연결

198.18.0.0/15는 네트워크 장비 벤치마크 테스트에 사용하는 예약 주소 대역으로, 인터넷 웹사이트가 실제로 사용하는 공인 주소가 아닙니다. mihomo는 이 중 198.18.0.1/16을 Fake-IP 풀로 사용하는 경우가 많습니다. 합성 주소는 로컬 프록시 경로에서 인덱스로만 사용되며, 일반 게이트웨이로 직접 전송되거나 코어를 우회해 계속 라우팅될 수 없습니다.

Fake-IP가 Redir-Host보다 일반적으로 더 직접적인 이유

Redir-Host 모드에서는 애플리케이션에 실제 DNS 결과를 반환합니다. 애플리케이션은 실제 IP를 받은 뒤 연결을 시작하고, 코어는 기존 DNS 기록이나 트래픽의 호스트명, 스니핑 결과를 바탕으로 도메인을 연결합니다. 시스템 DNS와 비슷한 네트워크 동작을 유지해 로컬 네트워크 장비, 일부 게임 및 실제 주소만 인식하는 프로그램과의 호환성이 좋다는 장점이 있습니다. 반면 최초 조회 시 상위 DNS의 응답을 기다려야 하며, 캐시·CDN 다중 주소·동시 요청 때문에 도메인과 연결의 대응 관계가 복잡해질 수 있습니다.

Fake-IP는 로컬 주소 풀에서 즉시 응답할 수 있으므로 공인 DNS 조회가 완료된 뒤 그 결과를 애플리케이션에 전달할 때까지 기다릴 필요가 없습니다. 여기서 말하는 ‘조회 한 번을 줄인다’는 것은 애플리케이션이 연결을 시작하기 전에 실제 주소 조회를 기다리지 않아도 된다는 뜻이지, 전체 경로에서 DNS가 영원히 필요 없다는 의미는 아닙니다. 프록시 서버가 로컬 조회 노드에서 노드 도메인을 확인해야 하거나 최종 아웃바운드 연결에 대상 IP가 필요하다면 mihomo는 proxy-server-nameserver, nameserver 및 정책 설정에 따라 계속 조회를 수행합니다.

비교 항목	Fake-IP	Redir-Host
애플리케이션에 반환되는 주소	`198.18.x.x` 등의 합성 주소	상위 DNS가 반환한 실제 주소
최초 DNS 응답	로컬 매핑 풀에서 빠르게 생성 가능	일반적으로 상위 조회가 완료될 때까지 대기
도메인 규칙 매칭	Fake-IP 매핑을 직접 사용	DNS 기록 또는 스니핑 보완에 의존
로컬 네트워크 도메인 호환성	필터 목록을 적절히 설정해야 함	일반적으로 기존 조회 동작에 가까움
투명 프록시 연동	합성 주소 대역을 코어가 인계받도록 보장해야 함	트래픽 대상 자체는 실제 주소
대표적인 용도	TUN 전체 인계, 도메인 분할 라우팅, 최초 조회 대기 시간 단축	특수 애플리케이션, 로컬 네트워크 서비스 및 디버깅 환경 호환

한 번의 요청에서 실제로 일어나는 과정

애플리케이션이 시스템 DNS로 A 또는 AAAA 조회를 보냅니다. 일반적인 대상 포트는 UDP 또는 TCP 53입니다.
시스템 DNS 트래픽은 제어 없이 라우터나 통신사 DNS로 전송되지 않고 mihomo의 DNS 모듈로 전달됩니다.
mihomo가 도메인에 Fake-IP를 할당하고 매핑을 메모리 캐시에 기록합니다.
애플리케이션이 해당 주소에 연결합니다. 예: 198.18.0.23:443.
TUN 라우팅 또는 투명 프록시 규칙이 연결을 mihomo로 돌려보냅니다.
코어가 도메인을 복원한 뒤 DOMAIN-SUFFIX, 규칙 세트, 프로세스 규칙 등의 순서로 매칭합니다.
DIRECT 또는 프록시 정책을 선택한 다음에야 코어가 해당 실제 아웃바운드 연결을 실행합니다.

mihomo Fake-IP 기본 설정 및 필드 설명

코어 설정을 사용할 때는 YAML의 dns 항목에서 Fake-IP를 활성화할 수 있습니다. 그래픽 클라이언트에서 설정 덮어쓰기를 지원한다면 보통 ‘설정’ → ‘구성’ 또는 ‘설정’ → ‘매개변수 설정’으로 이동한 뒤 DNS나 전역 확장 설정을 찾습니다. 클라이언트마다 메뉴 이름은 버전에 따라 달라질 수 있으므로, 최종적으로는 mihomo에 전달되는 실제 YAML을 기준으로 확인해야 합니다.

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-mode: blacklist
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
    - "time.*.com"
    - "time.*.gov"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

기본 필드별 역할

enable: mihomo 내장 DNS 모듈을 활성화합니다. enhanced-mode만 작성하고 DNS 모듈이 작동하지 않으면 애플리케이션 조회가 시스템 상위 DNS로 우회될 수 있습니다.
listen: DNS가 수신할 주소와 포트입니다. 예시에서는 1053을 사용해 일반 사용자 권한으로 53을 직접 점유하는 문제를 피합니다. 라우터에 배포할 때는 dnsmasq가 해당 포트로 요청을 전달하도록 설정해야 합니다.
enhanced-mode: fake-ip: 조건에 맞는 도메인에 합성 주소를 반환합니다. redir-host로 바꾸면 실제 조회 결과를 반환합니다.
fake-ip-range: 합성 주소 풀입니다. 변경한 뒤에는 TUN 라우팅, 방화벽 및 라우터 우회 정책을 함께 점검해 전체 주소 대역이 mihomo로 들어오는지 확인해야 합니다.
default-nameserver: 일반적으로 직접 연결할 수 있는 IP 주소를 입력합니다. DoH 또는 기타 DNS 서버 자체의 도메인을 조회해 조회 체인이 순환하는 것을 방지합니다.
nameserver: 일반 도메인 조회에 사용하는 상위 서버입니다. 실제 요청이 프록시를 통과할지는 DNS 추적 정책과 아웃바운드 설정의 영향도 받습니다.
proxy-server-nameserver: 프록시 노드 서버의 도메인을 전담 처리합니다. 노드 주소를 도메인으로 작성한 경우 노드 조회와 일반 대상 조회를 분리할 수 있습니다.
fake-ip-filter-mode: blacklist: 목록에 있는 도메인에는 Fake-IP를 사용하지 않고 실제 결과를 반환합니다. 화이트리스트 방식으로 바꾸면 목록의 의미가 반대가 되므로 설정을 이전할 때 함께 확인해야 합니다.

fake-ip-filter에서 필터링할 도메인

fake-ip-filter의 목적은 자주 사용하는 웹사이트를 전부 제외하는 것이 아니라 실제 주소가 필요한 조회만 실제 조회 과정으로 되돌리는 것입니다. 필터 범위가 지나치게 넓으면 Fake-IP가 도메인을 빠르게 연결하는 이점이 줄어들고, 너무 좁으면 로컬 네트워크 검색·시간 동기화·로그인 확인·실시간 통신에서 직접 사용할 수 없는 합성 주소를 받을 수 있습니다.

로컬 네트워크 호스트와 내부 도메인

NAS, 프린터, 라우터 관리 페이지 및 홈 자동화 장치는 .lan, .local 또는 사용자 정의 내부 접미사를 사용하는 경우가 많습니다. 장치가 192.168.1.20을 반환한다면 애플리케이션은 대개 이 실제 로컬 네트워크 주소로 직접 연결해야 합니다. 해당 접미사를 필터 목록에 추가하고 로컬 DNS 서버가 이 이름에 응답할 수 있도록 하세요.

.local은 mDNS와 함께 사용되는 경우도 많습니다. mDNS는 멀티캐스트 주소와 UDP 5353을 사용하며 일반 유니캐스트 DNS와는 다릅니다. 필터 규칙만 추가해서는 네트워크 간 검색 문제가 해결되지 않을 수 있으므로 VLAN, 무선 게스트 네트워크 및 라우터 우회 환경에서 멀티캐스트 전달과 방화벽 경계도 확인해야 합니다.

STUN, 게임 및 실시간 통신

일부 게임, 음성 통화 및 WebRTC 프로그램은 STUN을 통해 공인 네트워크 출구와 NAT 유형을 확인합니다. 이러한 프로그램은 DNS 반환값을 UDP 탐색에 직접 사용하거나 서버가 반환한 후보 주소를 대조할 수 있습니다. Fake-IP를 활성화한 뒤 음성 통화는 연결되지만 소리가 나지 않거나, 방 매칭 후 연결이 끊기거나, NAT 유형이 개방형에서 엄격형으로 바뀐다면 모든 DNS를 즉시 Redir-Host로 되돌리기보다 관련 STUN 도메인부터 필터링해 보세요.

게임 가속을 ‘Fake-IP를 반드시 꺼야 하는 경우’로 단정할 수는 없습니다. HTTPS 로그인, 콘텐츠 다운로드 및 도메인 분할 라우팅을 기반으로 하는 게임 런처 대부분은 Fake-IP를 정상적으로 사용할 수 있습니다. 실제로 확인할 부분은 게임 본체가 UDP에 의존하는지, 서버 주소를 고정 검증하는지, 관련 트래픽이 TUN에 완전히 인계되는지입니다. 문제를 확인할 때는 런처 로그인, 리소스 다운로드, 매칭 서비스 및 실시간 대전을 나누어 테스트해야 합니다.

네트워크 탐색, 시간 동기화 및 장치 로그인

시스템 연결 상태 확인 도메인은 특정 상태 코드나 고정 주소를 기준으로 인증 페이지를 열어야 하는지 판단할 수 있습니다.
NTP는 보통 UDP 123을 사용하며, 일부 장치는 반환 주소를 직접 검증하거나 시스템 프록시를 우회합니다.
스마트 TV, 게임 콘솔 및 IoT 장치는 실제 A 레코드만 허용하고 이후 트래픽을 컴퓨터의 mihomo로 보내지 않을 수 있습니다.
기업 내부 도메인은 분할 DNS를 사용할 수 있습니다. 같은 도메인이라도 회사 네트워크와 공인 네트워크에서 서로 다른 결과를 반환하므로 지정된 내부 DNS에 맡겨야 합니다.

필터는 장애가 발생한 도메인을 하나씩 추가하고 추가 이유를 기록해야 합니다. 관리하기 좋은 목록에는 일반적으로 내부 도메인, 호환성 문제가 확인된 서비스 도메인 및 필요한 탐색 도메인이 포함되며, 출처가 불분명한 규칙 수백 개를 그대로 복사하지 않습니다.

TUN 모드에서 Fake-IP가 작동하는지는 트래픽 인계가 완전한지에 달려 있습니다

Fake-IP가 반환하는 주소는 공인 라우팅 의미가 없으므로 애플리케이션 연결이 mihomo로 들어가야 합니다. 데스크톱 클라이언트에서 TUN을 활성화하면 코어가 일반적으로 가상 네트워크 인터페이스를 만들고 라우팅을 추가합니다. 라우터 투명 프록시는 정책 라우팅, nftables 또는 iptables에 의존할 수 있습니다. DNS 강화 모드만 켜고 198.18.0.0/16을 인계하지 않으면 도메인 조회는 빠르지만 웹페이지가 계속 시간 초과되는 결과가 흔히 발생합니다.

동시에 확인해야 할 네 가지 경로

DNS 조회 경로: 애플리케이션의 조회가 실제로 mihomo에 도달하는지 확인합니다. 브라우저 내장 보안 DNS, Android 비공개 DNS 및 로컬 네트워크의 수동 DNS가 경로를 바꿀 수 있습니다.
Fake-IP 라우팅:198.18.0.0/16이 기본 게이트웨이가 아니라 TUN 또는 투명 프록시 처리 경로를 가리키는지 확인합니다.
규칙 매칭: 연결에서 복원된 도메인이 예상 규칙에 매칭되는지, 최종 정책 그룹이 사용 가능한 노드를 선택했는지 확인합니다.
실제 아웃바운드: 노드 도메인, 대상 도메인 및 IPv4·IPv6 경로가 올바르게 조회되고 접속되는지 확인합니다.

시스템에서 IPv6를 활성화했지만 설정이 IPv4만 인계하도록 되어 있으면 애플리케이션이 AAAA 결과를 우선 사용해 다른 경로로 나갈 수 있습니다. 테스트 단계에서는 ipv6: false를 임시로 설정해 범위를 좁히고, IPv4 Fake-IP 경로가 정상임을 확인한 뒤 IPv6 라우팅과 DNS 정책을 보완하세요. 장기적으로는 옵션을 끄는 것만으로 라우팅 문제를 가리지 말고 로컬 네트워크에 안정적인 IPv6 출구가 있는지에 따라 결정해야 합니다.

구체적인 명령어로 Fake-IP와 규칙 매칭 확인

웹페이지가 열리는지만으로 설정을 판단하지 마세요. 먼저 mihomo의 DNS 수신 포트를 직접 조회한 다음 시스템 라우팅과 코어 로그를 확인합니다. 아래 예시는 DNS 수신 포트가 로컬 1053, 혼합 프록시 포트가 일반적인 7890이라고 가정합니다.

nslookup www.example.com 127.0.0.1
dig @127.0.0.1 -p 1053 www.example.com A
curl -x http://127.0.0.1:7890 https://www.example.com/

dig가 198.18.x.x을 반환하면 해당 도메인이 Fake-IP 경로에 들어간 것입니다. 실제 공인 주소가 반환되면 도메인이 fake-ip-filter에 매칭되었는지, 현재 실행 중인 설정이 여전히 redir-host인지, 조회가 설정된 수신 포트로 실제 전송되었는지 확인하세요.

로컬 조회 응답 시간은 일반적으로 밀리초 수준이어야 합니다. 같은 장치와 네트워크에서 조회를 10회 연속 실행해 최초 응답을 비교해 보세요. 예를 들어 Fake-IP 로컬 응답은 2~8ms, 실제 DoH 최초 조회는 30~150ms일 수 있습니다. 수치는 장치 성능, 상위 서버와의 거리 및 캐시의 영향을 받으므로 같은 환경에서의 차이를 비교하는 것이 중요하며, 특정 지연 시간을 보편적인 기준으로 삼아서는 안 됩니다.

일반적인 장애와 점검 순서

증상	우선 확인할 항목	처리 방향
조회는 Fake-IP를 반환하지만 연결 시간 초과	Fake-IP 주소 대역 라우팅	TUN, 정책 라우팅 또는 투명 프록시가 전체 트래픽을 인계하는지 확인
모든 조회가 실제 주소를 반환	현재 실행 중인 DNS 모드	설정 덮어쓰기, 필터 규칙 및 실제 수신 포트 확인
웹사이트는 열리지만 로컬 NAS가 작동하지 않음	내부 도메인과 로컬 DNS	로컬 네트워크 접미사를 필터링하고 내부 레코드를 조회할 수 있는 서버 지정
브라우저는 정상이지만 게임 UDP가 실패	TUN의 UDP 인계와 STUN	UDP 지원, 라우팅 및 필요한 STUN 도메인 필터 확인
설정 변경 후 간헐적으로 이전 대상에 접속	시스템 및 애플리케이션 DNS 캐시	캐시를 초기화하고 관련 애플리케이션을 재시작한 뒤 설정을 다시 불러오기
노드 도메인을 조회할 수 없음	`proxy-server-nameserver`	접속 가능한 상위 DNS를 제공하고 아직 구성되지 않은 프록시 체인에 의존하지 않기

Fake-IP를 활성화하기 좋은 경우와 먼저 Redir-Host를 사용할 경우

Fake-IP를 우선 고려할 환경

데스크톱에서 TUN으로 대부분의 애플리케이션을 인계하고 도메인 규칙을 안정적으로 적용하려는 경우
구독에 도메인 규칙, 규칙 세트 및 도메인별 정책 그룹이 많은 경우
로컬 상위 DNS의 최초 조회 지연이 뚜렷해 애플리케이션이 실제 조회를 기다리는 시간을 줄이고 싶은 경우
시스템 프록시 설정을 따르지 않는 애플리케이션도 프록시로 연결하고 TCP와 UDP를 모두 mihomo가 관리하는 경우
로컬 네트워크, 게임 및 실시간 통신 상황에 맞춰 정밀한 필터 목록을 관리할 수 있는 경우

먼저 Redir-Host를 사용하는 편이 안정적인 환경

장치는 DNS만 mihomo에 전달하고 실제 연결은 TUN이나 투명 프록시를 통과하지 않는 경우
기업 내부망에서 분할 DNS, 고정된 실제 주소 및 내부 보안 장비를 광범위하게 사용하는 경우
로컬 네트워크에 오래된 장치가 많고 애플리케이션 동작을 확인하거나 도메인 필터를 항목별로 관리하기 어려운 경우
UDP, 게임 또는 장치 검색 장애를 점검 중이어서 일반 DNS에 가까운 비교 기준을 먼저 마련해야 하는 경우
현재 라우팅 규칙이 198.18.0.0/16을 항상 mihomo로 되돌린다고 보장할 수 없는 경우

두 모드는 코어의 신구 차이가 아니라 서로 다른 DNS 인계 방식입니다. mihomo는 기존 Clash Meta 코어를 이어받아 DNS, 규칙 세트 및 TUN 기능을 확장했지만, 모드 선택은 여전히 네트워크 토폴로지를 따라야 합니다. 단일 데스크톱, 라우터 우회 구성, 메인 라우터 및 컨테이너 환경은 DNS 진입점이 서로 다르므로 같은 설정을 그대로 복사해도 동일한 결과가 나오지 않을 수 있습니다.

설정 이전 및 조정 시 실용적인 순서

Redir-Host에서 Fake-IP로 전환할 때는 기존 프록시 규칙과 노드를 유지하고 DNS 강화 모드만 먼저 변경하는 것이 좋습니다. 여러 변수를 동시에 바꾸지 않기 위해서입니다. 설정을 불러온 뒤 일반 공인 도메인, 로컬 네트워크 도메인, 필터가 필요한 것으로 알려진 도메인 세 가지를 먼저 조회하세요. 공인 도메인은 합성 주소를 받아야 하고 나머지 두 유형은 설계에 따라 실제 주소를 반환해야 합니다.

현재 정상 작동하는 설정을 백업하고 DNS 수신 포트, TUN 활성화 여부 및 시스템 프록시 포트를 기록합니다.
enhanced-mode: fake-ip를 활성화하고 기본 주소 풀을 유지하거나 사용자 정의 범위를 명확히 계획합니다.
시스템 라우팅이 전체 Fake-IP 주소 대역을 빠짐없이 포함하는지 확인합니다.
먼저 *.lan, *.local 등 명확한 로컬 필터 항목을 추가합니다.
브라우저, 메신저, 게임, NAS 및 셋톱박스를 각각 테스트하고 웹사이트 하나만 확인하지 마세요.
로그를 바탕으로 최소 범위의 필터 규칙을 추가하고 각 규칙에 해당 장애를 기록합니다.
오래된 필터 항목을 정리해 목록이 계속 커지면서 사실상 Redir-Host처럼 변하지 않도록 합니다.

전환 후 문제가 많다면 Redir-Host로 되돌려 비교하는 것도 효과적인 엔지니어링 점검 방법입니다. 장애가 Fake-IP에서만 발생하는지 확인한 뒤 DNS 진입점, 주소 풀 라우팅, 필터 목록 및 UDP 인계를 차례로 점검하세요. 구독·노드·전체 설정을 반복해서 바꾸기보다 경로를 단계별로 확인하는 편이 실제 원인을 찾기 쉽습니다.