Fake-IP 모드 원리와 설정: DNS enhanced-mode, Redir-Host 비교

1. Fake-IP가 바꾸는 것은 DNS 응답이지, 노드의 출구가 아닙니다

Clash 또는 Clash Meta(현 mihomo)의 설정에서 dns.enhanced-mode는 내장 DNS의 응답 방식을 지정합니다. 주로 사용하는 값은 fake-ip와 redir-host입니다. 이 설정은 구독을 선택하거나 노드 프로토콜을 바꾸지 않으며, 규칙 모드나 TUN 모드를 대신하지도 않습니다.

Fake-IP는 도메인에 합성 주소를 할당하고 ‘도메인 ↔ 합성 주소’ 매핑을 저장합니다. 앱이 이 주소로 연결하면 코어가 먼저 도메인을 복원한 뒤 규칙을 매칭하고 연결을 처리합니다. 이 주소는 웹사이트 서버의 실제 주소도, 프록시 노드의 IP도 아닙니다.

주소가 흔히 198.18로 시작하는 이유는?

일반적인 설정에서는 198.18.0.1/16을 Fake-IP 주소 풀로 사용합니다. 이 주소는 네트워크 장비 성능 테스트용으로 예약된 198.18.0.0/15 대역에 속하며, 공용 웹사이트에 직접 접속할 때 쓰는 주소가 아닙니다. 설정에 /16을 지정하면 예약 대역 중 일부를 사용한다는 뜻이지, 예약된 전체 대역이 이 범위뿐이라는 뜻은 아닙니다.

따라서 DNS 조회 결과가 198.18.x.x라고 해서 곧바로 DNS 변조를 의미하지는 않습니다. 중요한 것은 이후 연결이 매핑 정보를 가진 동일한 코어로 돌아오는지입니다. 앱이 합성 주소를 받은 뒤 TUN이나 다른 투명 프록시 경로를 거치지 않고 바로 연결하면 대개 접속에 실패합니다.

2. 도메인 조회부터 연결까지: 두 모드의 차이

Fake-IP의 일반적인 처리 순서

앱이 example.com 같은 도메인을 조회하면 요청이 코어의 DNS로 전달됩니다.
코어가 합성 IPv4 주소를 할당하거나 기존 주소를 재사용해 앱에 응답합니다.
앱이 해당 주소로 연결하면 트래픽은 TUN 등의 경로를 통해 코어로 전달됩니다.
코어가 매핑을 바탕으로 도메인을 찾아 규칙을 차례로 확인하고, 직접 연결 또는 프록시 출구를 선택합니다.
실제 IP가 필요한 시점에 도메인을 조회합니다. 프록시 프로토콜과 출구 설정이 도메인 전달을 지원하면 원격 서버에서 조회할 수도 있습니다.

이 방식은 앱이 연결을 시작하기 전에 실제 DNS 응답을 기다리는 시간을 줄이고, 코어가 원래 도메인을 파악하기 쉽게 해줍니다. 그렇다고 ‘연결 내내 DNS 조회가 전혀 없다’는 뜻은 아닙니다. 직접 연결, IP 기반 규칙, 일부 출구 프로토콜이나 특정 DNS 정책에서는 실제 DNS 조회가 발생할 수 있습니다.

Redir-Host의 일반적인 처리 순서

Redir-Host는 보통 먼저 상위 DNS 서버에 실제 주소를 조회한 뒤 앱에 응답합니다. 코어는 DNS 캐시에 저장된 연관 정보를 바탕으로 연결이 들어올 때 도메인을 복원할 수 있습니다. DNS 요청이 코어를 거치지 않았거나 캐시가 사라졌거나 여러 도메인이 같은 주소를 공유하면 도메인을 완전히 복원하지 못할 수 있습니다. 트래픽 스니핑으로 일부 프로토콜의 정보를 보완할 수 있지만 모든 연결에 적용되는 것은 아닙니다.

비교 항목	Fake-IP	Redir-Host
앱이 받는 IPv4 응답	일반적으로 주소 풀의 합성 주소	일반적으로 상위 DNS 서버가 반환한 실제 주소
응답 전에 실제 DNS 조회를 기다리는지	일반적인 합성 응답은 기다릴 필요가 없습니다	캐시가 없으면 보통 기다려야 합니다
도메인 규칙에 필요한 정보	주로 합성 주소 매핑에서 가져옵니다	DNS 연관 정보, 명시적 프록시 정보, 스니핑 등에 의존합니다
주요 호환성 고려 사항	주소 검증, 로컬 네트워크 검색, 프록시를 우회하는 연결	실제 DNS 조회 지연, DNS 응답과 출구의 일치 여부

HTTP CONNECT 또는 SOCKS의 도메인 요청을 사용하는 명시적 프록시 연결에서는 코어가 대상 도메인을 바로 알 수 있어 위와 같은 시스템 DNS 과정을 거치지 않을 수도 있습니다. 따라서 브라우저에 프록시를 설정한 뒤 웹페이지에 접속되는 것만으로 Fake-IP의 DNS 가로채기가 정상 작동한다고 단정할 수는 없습니다.

3. 상황에 맞게 선택하세요. Fake-IP는 속도 설정이 아닙니다

TUN으로 일반 앱을 연결하는 경우: 먼저 Fake-IP를 테스트해 볼 수 있습니다. DNS와 이후 연결이 모두 코어로 전달되고 주소 풀이 기존 네트워크와 충돌하지 않아야 합니다.
기업 내부망, 학교 네트워크, NAS, 프린터: 먼저 내부 DNS에 접속할 수 있는지 확인한 뒤 관련 도메인에 예외를 설정하세요. 호환되지 않는 도메인이 몇 개뿐이라면 곧바로 전체 모드를 바꿀 필요는 없습니다.
DNS에서 실제 주소를 요구하는 앱: 먼저 필요한 도메인만 정확히 필터에 추가하세요. 이런 앱이 많거나 예외 목록을 관리하기 어렵다면 Redir-Host와 비교해 볼 수 있습니다.
브라우저의 시스템 프록시만 사용하는 경우: 브라우저가 실제로 사용하는 프록시 프로토콜과 DNS 경로부터 확인하세요. 모드 이름만 보고 TUN을 켜거나 전체 DNS 설정을 바꿀 필요는 없습니다.

Fake-IP는 첫 연결 시 DNS 응답을 기다리는 시간을 줄일 수 있지만 구독 대역폭을 늘리거나 노드의 트래픽 배수를 낮추거나 혼잡한 회선을 고쳐 주지는 않습니다. 다운로드 속도가 느리다면 DNS 조회 시간, 연결 설정 시간, 실제 전송 속도를 각각 확인해 서로 다른 문제를 혼동하지 마세요.

4. fake-ip-filter: 필요한 도메인만 실제 주소로 응답하기

기본 블랙리스트 방식에서 fake-ip-filter는 목록에 있는 도메인에 합성 주소를 사용하지 않고 일반 DNS 조회로 응답한다는 뜻입니다. 프록시 우회 목록은 아닙니다. 필터 목록에 도메인을 추가해도 연결은 계속 rules와 매칭됩니다. 해당 트래픽을 직접 연결해야 한다면 관련 규칙이 DIRECT를 가리키는지도 확인하세요.

다음은 mihomo용 일부 설정 예시입니다. 127.0.0.1:1053은 수동으로 확인하기 편한 로컬 리스닝 주소일 뿐, 시스템 DNS로 자동 지정되지는 않습니다. 기존 설정에 합칠 때는 최상위 dns: 항목을 하나만 남기고, 기존 설정에 필요한 DNS 분기, 상위 서버 주소 및 기타 항목도 유지하세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - localhost
    - "+.lan"
    - "+.home.arpa"
  nameserver:
    - 1.1.1.1
    - 9.9.9.9

여기에 적힌 상위 DNS 주소는 설정 구조를 보여 주기 위한 예시입니다. 실제로는 현재 네트워크에서 접속 가능하고 내부망 요구 사항에 맞는 DNS 서버를 선택하세요. mihomo의 도메인 매칭 문법에서 +.home.arpa는 해당 도메인과 하위 도메인을 모두 포함합니다. 구버전 Clash 코어를 사용한다면 먼저 지원하는 필드와 매칭 문법을 확인하세요. 구버전 코어가 fake-ip-filter-mode를 지원한다고 단정할 수 없습니다.

하나씩 확인해 볼 만한 예외 대상

직접 관리하는 로컬 네트워크 도메인: 예를 들어 nas.home.arpa가 있습니다. 라우터 DNS에만 등록되어 있다면 해당 도메인이 내부 DNS를 사용하도록 설정해야 합니다.
실제 주소 검증이 필요한 앱의 도메인: 앱이 DNS 응답과 서버에서 받은 주소를 비교할 수 있습니다. 먼저 로그에서 실제 조회 도메인을 확인한 뒤 정확한 항목을 추가하세요.
특정 게임이나 기기 검색 서비스: DNS 합성 주소 때문에 문제가 발생한 것을 확인한 경우에만 예외로 설정하세요. 게임 연결에는 UDP, NAT, 중계 서버도 관여할 수 있으므로 도메인 필터링만으로는 이런 별도 문제를 해결할 수 없습니다.

.local은 일반적인 유니캐스트 DNS와 다른 mDNS를 사용하는 경우가 많습니다. 관련 이름을 필터 목록에 넣더라도 TUN이 멀티캐스트 검색 트래픽을 자동으로 전달한다는 뜻은 아닙니다. 화면 전송이나 프린터 검색이 되지 않는다면 로컬 네트워크 접근 권한, 멀티캐스트 경로, 방화벽도 함께 확인하세요.

5. 내부 DNS와 규칙 분기는 따로 설정해야 합니다

‘실제 주소를 반환할지’, ‘어떤 DNS 서버에 조회할지’, ‘연결을 어느 출구로 보낼지’는 서로 다른 문제입니다. 예를 들어 NAS의 도메인이 nas.home.arpa이고 라우터 주소가 192.168.1.1이라면 위 예시에 DNS 정책을 추가하고, 직접 연결 규칙을 먼저 매칭될 수 있는 포괄적인 규칙보다 앞에 배치할 수 있습니다.

# 다음 항목을 기존 dns에 병합하세요. 두 번째 dns 항목을 만들지 마세요.
dns:
  nameserver-policy:
    "+.home.arpa": "192.168.1.1"

# 다음 규칙을 기존 rules에 추가하고 매칭 순서를 확인하세요.
rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT

이 예시는 설정을 병합할 위치를 보여 줄 뿐, 구독 설정을 그대로 대체할 수 있는 완성된 구성은 아닙니다. 예시의 192.168.1.1은 실제 내부 DNS 주소로 바꿔야 합니다. 현재 네트워크에서 해당 주소에 접속할 수 없다면 필터 목록이 정확해도 올바른 응답을 받을 수 없습니다.

구독을 업데이트하면 수동으로 변경한 내용이 덮어써질 수 있습니다. 클라이언트의 오버라이드, 확장 설정 또는 병합 기능을 사용할 때는 최종 실행 설정을 먼저 확인하세요. 필터 항목이 유지됐는지, DNS 정책이 병합됐는지, 직접 연결 규칙이 기본 규칙보다 앞에 있는지 점검해야 합니다. 화면에 ‘저장 완료’라고 표시되어도 코어가 새 설정을 불러왔다는 뜻은 아닙니다.

6. DNS 조회와 연결 기록으로 설정 확인하기

1단계: 현재 실행 중인 코어 설정 확인

클라이언트에 표시된 코어 이름과 버전을 기록하고 실행 설정에서 enhanced-mode, listen, 필터 목록, TUN의 DNS 가로채기 설정을 확인하세요. 클라이언트가 설정을 다시 생성할 수 있으므로 실제로 불러온 설정과 로그를 기준으로 판단해야 합니다. 코어에서 알 수 없는 필드 오류가 발생하면 호환성 문제부터 해결하고 테스트를 진행하세요.

2단계: 로컬 DNS 리스닝 포트에 직접 조회

실제 리스닝 주소가 앞의 예시와 같다면 dig가 설치된 시스템에서 다음 명령을 실행하세요:

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

Windows에서는 nslookup 대화형 모드에서 포트를 지정할 수 있습니다:

nslookup
> server 127.0.0.1
> set port=1053
> set type=A
> example.com
> nas.home.arpa
> exit

첫 번째 도메인이 필터에 포함되지 않았다면 보통 주소 풀의 IPv4 주소가 반환되어야 합니다. 두 번째 도메인은 내부 DNS에 해당 레코드가 설정된 경우에만 관련 내부 주소를 반환해야 합니다. 특정 198.18.x.x 주소를 정답으로 그대로 사용하지 마세요. 주소는 매핑 상태에 따라 달라집니다.

3단계: 시스템에서 실제 사용하는 DNS와 연결 경로 확인

앱의 기존 연결을 끊고 다시 접속한 다음, 클라이언트의 ‘연결’ 화면에 대상 도메인, 매칭된 규칙, 출구 정책이 표시되는지 확인하세요.
직접 실행한 DNS 조회는 정상인데 앱 접속이 실패한다면 시스템 DNS 요청이 코어로 전달되는지, TUN이 합성 주소 연결을 가로채는지 확인하세요.
앱이 자체 암호화 DNS를 사용한다면 설정을 기록한 뒤 해당 기능을 잠시 끄고 비교하세요. 앱 내 DoH 조회는 코어의 일반 DNS 리스닝 포트를 거치지 않을 수 있습니다.
IPv6 경로에서만 문제가 발생한다면 AAAA 조회, IPv6 라우팅, 트래픽 가로채기 설정을 따로 확인하세요. A 레코드 테스트 한 번으로 IPv6까지 정상이라고 판단할 수는 없습니다.

모드를 바꾼 뒤 Windows에서 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 지우고 테스트 앱을 다시 시작할 수 있습니다. 브라우저, 앱, 코어가 각각 캐시나 기존 연결을 유지할 수도 있으므로 웹페이지 새로고침만으로는 DNS를 새로 조회하지 않을 수 있습니다.

7. 자주 발생하는 문제: 어느 단계에서 실패하는지 먼저 확인

클라이언트를 종료했는데도 웹사이트가 198.18 주소로 연결을 시도함

DNS 캐시가 남아 있거나 기존 연결이 유지되거나 시스템 네트워크 설정이 복구되지 않았는지 확인해야 합니다. 정상 DNS 및 프록시 설정을 복원하고 시스템 캐시를 비운 뒤 앱을 완전히 종료했다가 다시 실행하세요. 합성 주소에 공용 게이트웨이를 추가하려고 하지 마세요. 매핑과 트래픽 가로채기가 없으면 이 주소는 직접 접속할 수 있는 웹사이트 주소가 아닙니다.

필터를 추가했는데도 내부 사이트가 열리지 않음

먼저 필터 적용 후 실제 DNS 응답을 조회하세요. 존재하지 않는다는 응답이 오거나 시간이 초과되면 DNS 경로에 문제가 있습니다. 올바른 내부 IP가 반환된다면 연결 규칙, 라우팅, 방화벽을 확인하세요. 필터 목록은 ‘합성 주소를 반환하지 않도록’ 할 뿐, 내부 DNS를 자동으로 찾거나 로컬 네트워크 접근을 허용하지는 않습니다.

웹페이지는 열리지만 합성 주소로 ping이 되지 않음

ping은 ICMP를 사용하므로 웹페이지의 TCP 또는 QUIC 요청과 같지 않습니다. 코어와 트래픽 가로채기 방식에 따라 ICMP 처리 방법도 다르며, 합성 주소에 대한 ping 결과는 노드 지연 시간을 나타내지 않습니다. 실제 앱 접속, 연결 기록, 대상 서비스에 맞는 테스트를 기준으로 확인하세요.

Redir-Host로 바꾸자 문제가 해결됐다면 계속 사용해야 할까요?

먼저 정상 작동하는 설정을 유지하고 차이를 찾아보세요. 영향을 받는 서비스가 하나뿐이라면 해당 도메인만 정확히 필터링하고 내부 DNS를 올바르게 설정하는 방법을 우선 시도하세요. 많은 앱이 실제 DNS 주소에 의존한다면 Redir-Host를 장기적으로 사용해도 됩니다. 어떤 모드가 더 고급스러운지가 아니라 연결이 재현 가능하게 작동하고, 규칙 매칭이 예상대로이며, 관리 부담을 감당할 수 있는지를 기준으로 판단하세요.