Fake-IP 모드 원리와 DNS 가상 IP 매핑, 로컬 네트워크 기기 호환성

1. Fake-IP의 역할: 가상 IP로 대상 도메인 유지

Fake-IP는 Clash 계열 코어에서 사용하는 DNS 동작 모드입니다. 앱이 도메인의 IPv4 주소를 조회하면 코어가 지정된 주소 풀에서 IP를 할당하고, 도메인과 가상 IP의 대응 관계를 기록할 수 있습니다. 이 IP는 로컬 기기나 관리 대상 네트워크에서 연결을 가로채는 데 사용되며, 웹 서버의 공인 IP 주소가 아닙니다.

일반적인 설정에서는 198.18.0.1/16을 주소 풀 값으로 사용하며, 이는 벤치마크용으로 예약된 198.18.0.0/15 주소 공간에 속합니다. 192.168.0.0/16 같은 사설 로컬 네트워크 대역과는 다르며, 공용 인터넷으로 직접 전송해서도 안 됩니다. 이런 DNS 응답이 보인다고 해서 DNS 조회에 문제가 있다는 뜻은 아닙니다.

연결 처리 순서

앱이 example.com을 조회하면 요청이 코어의 DNS 서비스로 전달됩니다.
코어가 주소 풀에서 IP 하나를 할당하고 매핑을 만듭니다. 예를 들어 198.18.0.2가 할당될 수 있지만, 구체적인 주소는 고정되어 있지 않습니다.
앱이 이 가상 IP로 연결을 시작하면 TUN 또는 다른 투명 프록시 경로를 통해 연결이 같은 코어로 전달됩니다.
코어가 매핑 테이블에서 대상 도메인을 확인한 뒤 규칙에 따라 직접 연결 또는 프록시 출구를 선택합니다.
직접 연결은 대개 실제 IP를 조회해야 합니다. 프록시 출구에서 도메인 처리를 원격 서버에 맡길 수 있는지는 아웃바운드 프로토콜과 설정에 따라 달라집니다.

핵심은 DNS 조회와 후속 연결이 하나의 흐름으로 이어져야 한다는 점입니다. 기기에 Clash가 가상 IP를 할당하도록 설정했더라도 해당 IP로 향하는 트래픽이 연결된 코어로 돌아오지 않으면 “DNS 응답은 있지만 웹페이지가 열리지 않는” 문제가 발생합니다. DNS 수신 포트만 열어 둔다고 이 연결 흐름이 완성되는 것은 아닙니다.

속도 향상의 범위

Fake-IP는 앱이 실제 DNS 조회 결과를 기다리는 시간을 줄이고, 코어가 원래 도메인을 기준으로 규칙을 적용하기 쉽게 해 줍니다. 네트워크 경로의 물리적 지연 시간을 줄이는 기능은 아니며, 모든 웹사이트의 속도가 빨라지는 것도 아닙니다. 직접 연결을 위한 DNS 조회, 프록시 핸드셰이크, TLS 연결, 서버 응답이 여전히 주요 지연 요인일 수 있으므로 가상 IP 할당 속도를 웹페이지 로딩 속도와 같다고 볼 수 없습니다.

2. Fake-IP와 redir-host: 응답 내용과 연결 가로채기 조건

비교 항목	Fake-IP	redir-host
DNS 응답	조건에 맞는 조회에 주소 풀의 매핑 IP를 반환	상위 DNS 서버에서 조회한 실제 IP를 반환
도메인 연결 방식	가상 IP 매핑을 통해 도메인을 확인	DNS 기록 연결 등의 방식으로 도메인을 식별하지만, 공유 IP 등의 제약이 있음
연결 전 대기 시간	대상 도메인의 실제 IP를 먼저 조회하지 않고 가상 IP를 할당할 수 있음	일반적으로 실제 IP 조회를 먼저 완료해야 함
네트워크 요구 사항	가상 IP로 향하는 트래픽이 해당 코어로 돌아와야 함	실제 IP는 정상적으로 라우팅되지만, 트래픽 분기는 여전히 가로채기 설정과 규칙에 따라 달라짐
호환성 확인 항목	IP 주소 확인, 기기 간 연결, 오래된 매핑 캐시	상위 DNS 조회 결과, 도메인 연결 방식, DNS 경로

모드는 실제 트래픽을 가로채는 방식에 따라 선택해야 합니다. 데스크톱에서 TUN을 활성화하고 같은 코어가 DNS 조회를 처리한다면 Fake-IP의 흐름을 파악하기 쉽습니다. 프린터, TV, 게임 콘솔은 네트워크 동작이 복잡하므로 DNS만 바꾸고 투명 프록시 라우팅은 설정하지 않았다면 데스크톱 설정을 그대로 적용할 수 없습니다.

시스템 프록시는 또 다른 연결 경로입니다. HTTP 프록시 요청에는 도메인이 직접 포함될 수 있어 로컬 DNS 조회 결과를 사용하지 않을 수도 있습니다. 브라우저에서 웹사이트가 열린다고 시스템 DNS와 TUN이 정상 작동한다는 뜻은 아닙니다. 반대로 진단 명령 하나가 실패했다고 HTTP 프록시까지 작동하지 않는 것은 아닙니다.

3. 최소 DNS 설정과 fake-ip-filter 작성법

아래는 DNS 설정 일부이며, 노드·프록시 그룹·규칙을 포함한 전체 설정이 아닙니다. 예시에서는 시스템에서 흔히 사용하는 53 포트를 직접 점유하지 않도록 로컬 1053 포트를 사용합니다. TUN의 DNS 가로채기나 시스템 DNS 전달은 별도로 설정해야 합니다. 운영체제의 일반 DNS 주소 입력란에는 보통 사용자 지정 포트를 지정할 수 없습니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '+.lan'
    - '+.local'
    - '+.home.arpa'
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

필드의 의미와 적용 범위

enable: 코어의 DNS 서비스를 활성화합니다. 클라이언트 화면에 별도의 DNS 재정의 옵션이 있을 수 있으므로 최종 적용 설정을 확인하세요.
listen: 여기서는 로컬 기기의 조회만 받으며, 로컬 네트워크에 DNS 서비스를 공개하지 않습니다.
ipv6: false: 해당 DNS 모듈이 AAAA 조회를 처리하는 방식을 제어합니다. 운영체제의 IPv6를 끄는 설정은 아니며, 다른 리졸버가 IPv6 주소를 반환하지 않는다는 보장도 없습니다.
enhanced-mode: DNS 향상 모드를 지정합니다. 예시에서는 fake-ip를 선택합니다.
fake-ip-filter: 일반적인 기본 블랙리스트 방식에서는 목록에 일치하는 도메인에 가상 IP를 할당하지 않고 실제 DNS 조회 결과를 가져옵니다.
nameserver: 예시에는 상위 DNS 주소 두 개가 나와 있습니다. 목록 순서는 “중국 본토 우선, 해외 대체”와 같은 트래픽 분기 정책을 뜻하지 않습니다. 실제 동작은 코어 구현과 다른 DNS 필드의 영향을 받습니다.

+.home.arpa는 해당 도메인과 하위 도메인을 일치시킵니다. home.arpa는 가정용 네트워크 도메인 공간입니다. .local은 mDNS와 관련이 있는 경우가 많으며, 요청 일부는 UDP 5353 멀티캐스트로 전송되어 이 일반 DNS 리스너를 거치지 않습니다. 필터 목록에 추가해도 mDNS 전달이나 기기 검색 기능을 대신할 수는 없습니다.

mihomo는 fake-ip-filter-mode 같은 세부 필터 모드를 제공합니다. 설정을 복사하기 전에 코어가 해당 옵션을 지원하는지 확인하세요. 화이트리스트 모드에서는 필터 목록의 의미가 달라지므로 목록의 모든 항목을 계속 “제외 대상”으로 해석하면 안 됩니다. 오리지널 Clash와 여러 포크 및 배포 버전은 지원하는 필드가 서로 다를 수 있습니다.

4. 로컬 네트워크 기기 호환성: DNS 조회, 라우팅, 기기 검색을 구분하세요

NAS 도메인에 가상 IP가 반환되는 경우

예를 들어 NAS의 실제 IP가 192.168.1.20이고 가정용 도메인이 nas.home.arpa라고 하겠습니다. 조회 결과가 198.18로 시작하는 주소라면 먼저 해당 도메인이 필터에 일치하는지, 다음으로 가정용 DNS에서 조회되는지 확인하세요. 사설 IP를 안정적으로 얻으려면 두 가지를 모두 해결해야 합니다.

mihomo에서는 nameserver-policy를 사용해 가정용 도메인에 전용 리졸버를 지정할 수 있습니다. 아래 설정은 라우터 DNS가 192.168.1.1이고 코어를 실행하는 기기에서 해당 주소에 접근할 수 있다고 가정합니다. 기존 설정의 같은 dns 객체에 합쳐야 하며, 최상위 dns 키를 중복해서 만들지 마세요.

dns:
  nameserver-policy:
    '+.home.arpa': '192.168.1.1'

이 설정에는 앞서 나온 필터 목록이 포함되어 있지 않으므로 병합할 때 fake-ip-filter를 유지해야 합니다. 라우터가 같은 조회를 다시 Clash로 전달해 DNS 포워딩 루프가 생기지 않는지도 확인하세요.

프린터·TV·화면 전송 기기가 검색되지 않는 경우

기기 검색에는 일반 DNS뿐 아니라 mDNS, SSDP, 브로드캐스트가 사용될 수 있습니다. mDNS는 보통 224.0.0.251:5353, SSDP는 239.255.255.250:1900을 사용합니다. 클라이언트가 게스트 Wi-Fi에 연결되어 있거나 다른 VLAN에 속해 있거나 무선 클라이언트 격리가 활성화되어 있으면 도메인 조회가 정상이어도 기기를 찾지 못할 수 있습니다.

먼저 기기의 실제 사설 IP로 관리 페이지에 접속해 기본 연결이 되는지 확인합니다.
그런 다음 기기 도메인을 조회해 예상한 사설 IP가 반환되는지 확인합니다.
자동 검색만 실패했다면 멀티캐스트, 브로드캐스트, 네트워크 대역 간 격리를 확인하세요. DNS 필터 목록을 계속 확대하지 마세요.

휴대폰에 가상 IP가 할당됐지만 연결은 다른 게이트웨이로 전송되는 경우

가상 IP 매핑은 특정 코어 인스턴스에 속합니다. 휴대폰이 게이트웨이 A에 DNS를 질의한 뒤 게이트웨이 B로 연결을 보내면, 일반적으로 B에는 A의 매핑이 없습니다. A를 재시작한 뒤 휴대폰이 이전 캐시를 계속 사용하는 경우에도 비슷한 문제가 생길 수 있습니다. 가정용 네트워크에서는 DNS 경로와 투명 프록시 경로를 통일해야 합니다. 특정 PC의 Fake-IP DNS를 독립적인 공용 DNS처럼 모든 기기에 배포해서는 안 됩니다.

5. 문제 해결 단계: DNS 응답부터 실제 출구까지 확인

1단계: 코어 DNS에 직접 조회

Linux 또는 macOS에 dig가 설치되어 있다면 예시의 로컬 포트에 직접 요청할 수 있습니다. 아래 명령은 확인 방법이며, 고정된 출력 결과를 전제로 하지 않습니다.

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

첫 번째 조회는 정상적인 Fake-IP 할당 경로에서 주소 풀에 속한 IP를 반환해야 합니다. 두 번째 조회는 필터와 가정용 DNS 정책이 올바르게 설정된 경우 실제 가정용 레코드를 반환해야 합니다. 시간 초과가 발생하면 먼저 DNS 수신 상태와 프로세스를 확인하세요. NXDOMAIN이 반환되면 레코드가 존재하는지, 잘못된 리졸버를 선택하지 않았는지 확인하세요.

2단계: 시스템에서 실제 사용하는 리졸버 확인

Windows에서는 ipconfig /all로 네트워크 어댑터의 DNS 주소를 확인하고, nslookup example.com으로 기본 조회 경로를 점검할 수 있습니다. 브라우저의 보안 DNS, 앱에 내장된 DoH, VPN, 다른 가상 네트워크 어댑터가 조회 경로를 바꿀 수 있습니다. 명령 프롬프트와 브라우저가 서로 다른 리졸버를 사용한다면 결과가 달라지는 것은 드문 일이 아닙니다.

ipconfig /all
nslookup example.com
ipconfig /flushdns

ipconfig /flushdns는 Windows DNS 클라이언트 캐시만 지우며, 브라우저·앱·코어의 매핑 캐시까지 함께 삭제하지는 않습니다. 모드를 변경하거나 코어를 재시작한 뒤에는 이전 연결을 유지하는 앱도 재시작한 다음 같은 조회를 다시 실행하세요. 페이지 새로고침만으로 설정이 적용되지 않았다고 판단하지 마세요.

3단계: 규칙 일치와 사설 네트워크 대역 확인

클라이언트의 연결 목록이나 로그에서 대상 도메인, 대상 IP, 일치한 규칙, 출구를 확인하세요. 가정용 네트워크를 직접 연결로 처리하려면 다음 규칙을 참고해 범용 프록시 규칙과 마지막 MATCH보다 앞에 배치할 수 있습니다.

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve

이 예시는 완전한 규칙 목록이 아니므로 기존 rules 목록에 병합해야 합니다. no-resolve는 해당 IP 규칙을 일치시키기 위해 도메인 조회를 추가로 수행하지 않는다는 뜻입니다. 대상 IP가 이미 있으면 해당 IP는 계속 규칙과 일치할 수 있습니다. 코어가 이미 도메인을 확인한 연결은 앞에 배치된 도메인 규칙에 먼저 일치할 수 있으므로 IP 규칙을 대체 수단으로 사용할 필요가 없습니다.

Fake-IP 주소 풀 전체를 직접 연결 규칙에 넣어 운영체제가 해당 주소에 직접 접근하게 만들지 마세요. 가상 IP는 매핑을 관리하는 코어에 먼저 전달해야 하며, 실제 웹사이트 IP처럼 라우팅할 수 없습니다.

6. 자주 묻는 질문과 모드 전환 조건

198.18로 시작하는 IP에 ping이 되지 않으면 웹사이트에 문제가 있는 건가요?

아닙니다. 현재 도메인에 할당된 가상 IP일 수 있습니다. ICMP 처리 경로는 TCP·UDP 프록시와 다르므로 ping 결과만으로 웹 접속 상태를 판단할 수 없습니다. DNS 응답, 연결 로그, 실제 앱 요청을 함께 확인하세요.

fake-ip-filter로 모든 게임과 스마트 기기 오류를 해결할 수 있나요?

아니요. 일치하는 도메인의 IP 할당 방식만 바꿉니다. UDP 포워딩, NAT 유형, 앱에 고정된 IP 주소, 인증서 오류, 멀티캐스트 격리 문제는 각각 따로 점검해야 합니다. 앱이 실제 DNS 주소에 의존한다는 점을 확인한 뒤 해당 도메인만 필터에 추가하는 것이 좋습니다.

Fake-IP를 켜면 TUN도 반드시 켜야 하나요?

반드시 그런 것은 아닙니다. TUN은 연결을 가로채는 일반적인 방식이며 라우터의 투명 프록시도 같은 역할을 할 수 있습니다. 중요한 조건은 가상 IP로 향하는 관련 트래픽을 해당 매핑을 관리하는 코어가 처리하는 것이지, 화면의 특정 스위치가 켜져 있는지가 아닙니다.

언제 redir-host로 전환하는 것이 좋나요?

특정 기기가 DNS 주소를 계속 검증하거나, 조회 결과를 해당 코어를 거치지 않는 다른 기기에 전달해야 하거나, DNS와 연결 경로를 통일하기 어려운 경우 redir-host를 시험해 볼 수 있습니다. 전환 후 관련 캐시를 지우고 연결을 다시 설정한 다음 도메인 규칙과 실제 DNS 조회 경로를 다시 확인하세요.

안정적인 설정인지 판단하려면 세 가지가 일치해야 합니다. 도메인이 예상한 리졸버에서 처리되고, 연결이 올바른 코어에 전달되며, 출구가 규칙에 부합해야 합니다. DNS, TUN, 전체 구독 설정을 한꺼번에 바꾸기보다 앱 하나와 도메인 하나로 먼저 검증한 뒤 필터를 늘리거나 모드를 조정하는 편이 문제를 찾기 쉽습니다. 기본 필드는 프로토콜 참고 자료를, 네트워크 용어는 용어 간편 사전을 참조하세요.