2026-09-12 DNS 해석 예상 읽기 시간 10분

Fake-IP과 redir-host 비교

Clash Fake-IP의 가상 IP 할당 방식과 redir-host의 차이를 속도·호환성 측면에서 비교하고 fake-ip-filter 활용법을 살펴봅니다.

먼저 DNS 모드와 트래픽 가로채기를 구분하세요

dns.enhanced-mode는 Clash 내장 DNS가 도메인 조회에 어떻게 응답할지 결정합니다. fake-ip는 매핑에 사용하는 가상 IP를 반환하고, redir-host는 상위 DNS 서버에서 받은 실제 IP를 반환합니다. 두 방식은 규칙 모드나 전역 모드를 대신하지 않으며, 연결이 최종적으로 어느 프록시 노드를 이용할지도 결정하지 않습니다.

트래픽 가로채기는 별개의 문제입니다. 시스템 프록시는 보통 프록시 설정을 따르는 프로그램에만 적용되지만, TUN은 가상 네트워크 어댑터와 라우팅을 통해 더 많은 IP 트래픽을 처리합니다. DNS 조회가 코어로 전달되는지, 앱 연결이 코어로 돌아오는지는 각각 따로 확인해야 합니다. 설정에서 모드를 Fake-IP로 바꾸기만 해서는 모든 프로그램이 자동으로 프록시를 거치지 않습니다.

도메인 정보를 활용해 트래픽을 분류하고 DNS와 연결 모두 코어가 처리한다면 Fake-IP부터 테스트하세요.
앱에서 실제 IP가 필요하거나 LAN 기기 검색이 필요한 경우, 먼저 해당 도메인만 필터링한 뒤 redir-host를 검토하세요.
시간 초과가 발생하면 DNS, 라우팅, 아웃바운드 연결 중 원인을 먼저 찾으세요. 모드와 노드, 규칙을 한꺼번에 바꾸지 마세요.

Fake-IP 가상 IP의 작동 방식

Fake-IP의 핵심은 도메인과 가상 IP를 매핑하는 것입니다. 웹사이트 주소를 영구적으로 바꾸는 방식이 아닙니다. 흔히 사용하는 주소 풀은 198.18.0.1/16이며, 보존된 벤치마크 테스트용 주소 대역입니다. 실제 웹사이트가 공인망에 배포된 주소가 아닙니다. 이 주소는 프록시 코어가 해석해야 하며, 일반 목적지처럼 인터넷으로 직접 보내면 안 됩니다.

앱이 도메인 조회를 요청하면 해당 요청이 Clash 내장 DNS로 전달됩니다.
코어는 주소 풀에서 가상 IP를 할당하거나 기존 IP를 재사용하고 도메인 매핑을 저장합니다. 조건에 맞는 A 레코드 조회는 보통 도메인의 실제 A 레코드 응답을 기다리지 않아도 됩니다.
앱이 가상 IP로 연결을 시도하면 TUN 등 트래픽을 처리하는 경로가 연결을 코어로 전달합니다.
코어는 매핑을 통해 도메인을 복원하고 규칙을 적용한 뒤 해당 아웃바운드로 연결을 넘깁니다. 직접 연결은 보통 실제 목적지의 IP를 조회해야 합니다. 프록시 아웃바운드에서 원격으로 DNS를 조회하는지는 프로토콜과 아웃바운드 구현에 따라 다릅니다.

첫 연결이 더 빨라질 수 있는 이유

일반적인 경로에서는 연결을 시작하기 전에 실제 DNS 응답을 기다리는 경우가 많습니다. Fake-IP는 이 대기 시간을 줄이고 도메인 기반 규칙에서 도메인 정보를 활용하기 쉽게 합니다. 그렇다고 모든 요청이 빨라지는 것은 아닙니다. 프록시 핸드셰이크, TLS 연결, 원격 DNS 조회, 대상 서버 응답에는 여전히 시간이 걸리며 IP 규칙을 적용하면 실제 DNS 조회가 필요할 수도 있습니다.

198.18.x.x 주소가 조회 결과에 보여도 웹사이트에 문제가 있다는 뜻은 아니며 실제 외부 통신 IP도 아닙니다. 해당 주소에 직접 ping을 보내도 노드 지연 시간을 판단할 수 없습니다. 실제 서비스 연결을 테스트하고 코어의 연결 패널에서 적용된 규칙과 정책, 오류 내용을 확인하세요.

redir-host의 DNS 조회 경로와 한계

redir-host에서는 내장 DNS가 설정된 상위 DNS 서버에 질의한 뒤 실제 IP를 앱에 전달합니다. 코어는 조회 과정에서 얻은 도메인과 IP의 관계를 기록해 이후 트래픽에서 도메인을 추정할 수 있습니다. 하지만 여러 도메인이 같은 IP를 공유할 수 있고 앱이 내장 DNS를 우회할 수도 있어, 이 관계만으로 원래 도메인을 항상 정확하게 복원할 수 있는 것은 아닙니다.

실제 IP를 받는 편이 나은 앱도 있습니다. 예를 들어 앱에서 DNS 조회 결과를 비교하거나 IP를 다른 프로세스에 직접 전달하는 경우, 또는 특정 LAN 주소에 접속해야 하는 기기가 이에 해당합니다. 다만 실제 IP를 반환한다고 해서 반드시 직접 연결되는 것은 아닙니다. TUN이 트래픽을 처리하면 규칙에 따라 아웃바운드가 선택됩니다.

비교 항목	Fake-IP	redir-host
일반적인 A 레코드 조회 결과	주소 풀에서 할당한 가상 IPv4 주소	상위 DNS 서버가 반환한 실제 IPv4 주소
연결 전 DNS 조회	먼저 매핑 주소를 반환하고 실제 조회는 나중에 진행할 수 있음	보통 실제 DNS 조회를 기다리거나 캐시를 사용함
도메인 정보의 출처	가상 IP와 도메인의 매핑	DNS 기록, 프로토콜에서 제공하는 도메인 정보 등
흔히 발생하는 호환성 문제	가상 IP 트래픽이 코어를 우회하거나 앱이 예약 주소를 거부함	공유 IP만으로 도메인을 특정하기 어려움, DNS 조회 경로와 프록시 출구가 맞지 않음
우선 적용하기 좋은 환경	DNS와 연결을 모두 처리하는 일반적인 규칙 기반 트래픽 분류	실제 DNS 조회 결과가 명확히 필요한 앱 환경

두 모드 모두 DNS 유출을 막아 주는 기능은 아닙니다. 앱 자체 DoH, 처리되지 않는 IPv6 트래픽, 외부 DNS에 직접 접속하는 프로그램은 각각 따로 확인해야 합니다. 웹페이지의 DNS 테스트에서 특정 DNS 서버가 표시되더라도 모든 프로그램이 같은 경로로 조회한다고 단정할 수는 없습니다.

Fake-IP 기본 설정 및 연결 조건

아래 예시는 기존 설정에 추가할 dns 섹션만 보여 주며, 노드와 프록시 그룹은 포함하지 않습니다. 구독 설정의 나머지 항목은 그대로 유지하세요. 클라이언트에서 설정 덮어쓰기나 병합을 지원한다면 해당 설정을 유지할 수 있는 위치에서 수정해야 구독이 갱신될 때 설정이 덮어써지는 일을 피할 수 있습니다.

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

listen의 1053은 이 글에서 예시로 사용하는 DNS 수신 포트이며 HTTP 또는 SOCKS 프록시 포트가 아닙니다. 루프백 주소에만 바인딩하므로 LAN에 DNS 서비스를 제공하지 않습니다.
default-nameserver는 DNS 서버 자체의 도메인을 조회하는 등 초기 연결에 필요한 조회에 사용됩니다. 여기서 일반 DNS로 수행하는 초기 조회는 DoH처럼 암호화되지 않습니다.
nameserver는 일반적인 상위 DNS 서버를 지정하는 항목입니다. HTTPS 주소를 사용한다고 해서 모든 DNS 트래픽이 자동으로 프록시를 통과하는 것은 아니므로 실제 경로를 확인해야 합니다.
운영체제의 일반 DNS 설정에서는 보통 1053 포트를 직접 지정할 수 없습니다. 실제로 연결하려면 클라이언트의 DNS 처리 기능이나 TUN의 DNS 가로채기, 또는 로컬 포워더를 함께 사용해야 합니다. 127.0.0.1만 입력했다고 설정이 완료된 것은 아닙니다.

redir-host와 비교하려면 enhanced-mode를 잠시 redir-host로 바꾸고 나머지 조건은 그대로 두세요. 이 모드에서는 Fake-IP 주소 풀과 필터 목록이 가상 IP 할당에 사용되지 않습니다. 먼저 백업한 다음 설정을 다시 불러오세요. 클라이언트가 DNS 설정을 관리한다면 생성된 실행 설정에도 변경 사항이 반영됐는지 확인하세요.

fake-ip-filter로 특정 도메인 예외 처리하기

일반적인 기본 블랙리스트 방식에서 fake-ip-filter는 지정한 도메인에 Fake-IP를 할당하지 않고 실제 조회 결과를 반환하도록 합니다. 해당 도메인의 프록시 사용 여부를 결정하는 설정은 아닙니다. 직접 연결 여부는 rules에서 정합니다. 필터 모드 변경을 지원하는 mihomo 버전은 다른 방식으로 동작할 수도 있으므로 목록을 복사하기 전에 화이트리스트 모드가 별도로 설정되어 있지 않은지 확인하세요.

도메인을 구체적으로 지정한 뒤 범위를 넓히세요

예를 들어 홈 NAS 도메인이 nas.home.arpa이고 앱이 가상 IP를 받은 뒤 연결을 거부한다면, 먼저 해당 도메인만 예외로 추가하세요. 같은 영역의 기기에서도 문제가 발생하면 코어가 지원하는 도메인 와일드카드 문법으로 범위를 넓힐 수 있습니다. mihomo에서 일반적으로 +.home.arpa는 루트 도메인과 하위 도메인을 모두 가리킵니다. 모든 구형 코어에서 사용할 수 있는 문법은 아닙니다.

dns:
  fake-ip-filter:
    - "localhost"
    - "nas.home.arpa"
    - "+.home.arpa"
    - "*.lan"
    - "*.local"

다음은 일부 항목만 수정하는 예시입니다. 앞서 나온 기존 dns 섹션에 병합해야 하며 YAML 최상위에 같은 이름의 dns 키를 하나 더 만들면 안 됩니다. 필요에 따라 정확한 도메인 항목이나 이를 포함하는 와일드카드 항목 중 하나를 선택하고, 장기적으로 사용할 설정에서는 불필요한 항목을 삭제하세요.

필터는 내부 DNS 응답을 제공하지 않습니다

NAS 도메인을 필터 목록에 추가해도 상위 DNS 서버가 실제 IP를 알아야 합니다. 공용 DNS 서버는 일반적으로 가정 내부 도메인을 알지 못합니다. 이때는 해당 도메인의 조회를 라우터나 내부 DNS 서버로 보내고, 필요하면 nameserver-policy로 조회 경로를 지정하세요. 필터만 추가하고 올바른 상위 DNS 서버를 설정하지 않으면 가상 IP 호환성 문제가 도메인 조회 실패로 바뀔 뿐입니다.

.local은 보통 LAN 멀티캐스트에 의존하는 mDNS에 사용됩니다. *.local을 추가하면 관련 조회에 가상 IP가 할당되지 않도록 할 수는 있지만, 코어가 시스템을 대신해 mDNS 기기 검색을 수행하는 것은 아닙니다. 프린터나 화면 전송 기기를 검색하려면 멀티캐스트 경로와 LAN 라우팅을 계속 사용할 수 있어야 합니다.

DNS 응답과 연결 경로 확인하기

문제 해결은 세 단계로 진행하세요. 실행 설정을 확인하고, 내장 DNS에 직접 질의한 다음, 앱 연결을 점검합니다. 설정 편집기에 보이는 내용만 확인하거나 브라우저에서 웹페이지가 열리는지만으로 결론을 내리지 마세요.

1. 1053 포트에 직접 질의하기

dig가 설치된 환경에서 아래 명령 두 개를 실행하세요. 루프백 주소의 1053 포트를 지정해 조회하므로 운영체제의 DNS 설정에 따라 다른 DNS 서버를 잘못 테스트할 일이 없습니다.

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

Fake-IP에서는 필터링되지 않은 도메인이 보통 설정된 주소 풀의 IP를 반환합니다. 구체적인 할당 주소는 고정되어 있지 않습니다. NAS 도메인은 필터에 해당하고 내부 DNS 서버를 사용할 수 있을 때 실제 주소를 반환해야 합니다. 조회 시간이 초과되면 수신 상태와 설정 로드 오류를 확인하세요. 실제 공인 IP가 반환된다면 모드, 필터 규칙, 클라이언트의 설정 덮어쓰기를 점검하세요.

2. 규칙과 아웃바운드 확인하기

클라이언트의 연결 패널을 열고 테스트할 웹사이트에 접속한 뒤 대상 도메인, 적용된 규칙, 선택된 정책을 확인하세요. 가상 IP를 받았는데 연결 기록이 없다면 트래픽이 코어를 우회하는지, 라우팅이 충돌하는지, 앱이 다른 미관리 기기에서 해당 주소를 사용하고 있는지 살펴보세요.

3. 이전 상태를 지우고 다시 테스트하기

모드를 바꾼 뒤에도 앱에서 이전 캐시를 사용하거나 기존 연결을 유지할 수 있습니다. 먼저 해당 앱을 종료하고 시스템 DNS 캐시를 비운 다음 앱을 다시 실행하세요. Windows에서는 ipconfig /flushdns를 실행하면 됩니다. systemd-resolved를 사용하는 Linux에서는 resolvectl flush-caches를 실행하세요. 앱 자체 DNS 캐시는 시스템 캐시와 함께 지워지지 않을 수 있습니다.

profile.store-fake-ip를 활성화하면 일부 코어에서 매핑을 저장합니다. 기존 매핑을 복원하는 데 유용하지만 모든 시간 초과 문제를 해결하는 설정은 아닙니다. 주소 풀을 바꾸기 전에 클라이언트에서 지원하는 방법으로 이전 매핑을 지우고 연결을 다시 설정하세요. 용도를 모르는 설정 파일을 함부로 삭제하지 마세요.

오류 증상에 따라 모드 선택하기

일반 웹사이트와 자주 쓰는 앱이 정상적으로 작동: 현재 모드를 유지하세요. 막연히 더 빠를 것이라는 이유만으로 모드를 반복해서 바꿀 필요는 없습니다.
NAS, 프린터 또는 내부 도메인만 문제 발생: 전체 환경의 모드를 바꾸기보다 필터와 내부 DNS, LAN 라우팅부터 확인하세요.
앱에서 가상 IP를 명확히 거부: 먼저 앱이 실제로 조회하는 도메인을 예외로 추가하세요. 필요한 도메인이 많아 관리하기 어렵다면 redir-host를 테스트해 보세요.
Fake-IP 연결이 모두 시간 초과: 가상 IP 대역의 라우팅과 트래픽 처리 여부부터 확인하세요. DNS 조회가 성공했다고 해서 연결까지 TUN으로 전달된 것은 아닙니다.
redir-host에서 일부 사이트에 부적절한 IP가 반환: DNS 조회 경로와 프록시 출구가 맞는지 확인하고, 상위 DNS 서버를 무작정 늘리기보다 도메인별 조회 정책을 설정하세요.

최종 판단은 반복해서 확인할 수 있는 실제 연결 결과를 기준으로 하세요. 같은 기기와 노드, 도메인을 사용해 DNS 응답, 적용 규칙, 연결 성공 여부를 각각 확인합니다. Fake-IP는 매핑으로 도메인 정보를 유지하고 DNS 조회 시점을 조정하는 데 중점을 두며, redir-host는 앱에 실제 IP를 제공하는 방식입니다. 모드는 실제 트래픽 처리 방식과 앱 요구 사항에 맞춰 선택해야 합니다. 어느 한쪽이 모든 환경에 정답인 것은 아닙니다.