Fake-IP 모드 원리와 설정: 198.18 예약 주소, fake-ip-filter, 사용 사례

Fake-IP 작동 원리: 먼저 매핑 주소를 반환한 뒤 실제 연결 처리

Fake-IP를 켰을 때 도메인 조회 결과로 198.18.x.x가 반환되더라도 보통 DNS 오류는 아닙니다. mihomo가 로컬 매핑에 사용할 주소를 돌려준 것입니다. 이를 이해하려면 두 가지 동작을 구분해야 합니다. DNS는 “앱이 다음에 어느 주소로 연결할지” 알려 주고, 프록시 규칙은 “그 연결이 어느 경로로 나갈지” 결정합니다. 서로 연동되지만 같은 설정은 아닙니다.

이 글의 설정 예시는 Clash Meta의 후속 프로젝트인 mihomo 커널을 기준으로 합니다. 클라이언트마다 메뉴 이름과 설정 병합 방식이 다르며, 구형 Clash 커널은 모든 DNS 확장 필드를 지원하지 않을 수 있습니다. 설정을 바꾸기 전에 편집기에 저장된 파일만 확인하지 말고, 클라이언트의 커널 정보와 실제 적용 중인 설정을 확인하세요.

도메인에 접속할 때 거치는 단계

앱이 example.com의 IPv4 주소를 조회하면 요청은 mihomo DNS 서비스로 전달됩니다.
커널은 Fake-IP 주소 풀에서 주소를 할당해 “도메인 ↔ 가상 주소” 매핑을 만들고, 가상 주소를 앱에 반환합니다.
앱이 해당 주소로 연결합니다. 이 연결은 올바르게 설정된 TUN 라우팅 등을 통해 같은 커널이 다시 받아 처리해야 합니다.
커널은 매핑을 이용해 도메인을 복원하고 규칙을 적용한 다음, 직접 연결하거나 프록시를 통해 실제 대상과 연결합니다.

핵심 장점은 Fake-IP를 바로 할당할 수 있는 조회라면 실제 주소를 받기 위해 상위 DNS 응답을 기다리지 않아도 된다는 점입니다. 도메인 정보도 트래픽 분기 단계까지 유지할 수 있습니다. 다만 직접 연결, IP 기반 규칙 매칭, 일부 프록시 프로토콜에서는 실제 주소 조회가 필요할 수 있습니다. 이는 규칙과 연결 경로, 커널 동작에 따라 달라집니다. “DNS 응답이 빨라진다”는 것이 “모든 웹페이지가 빨라진다”는 뜻은 아닙니다.

198.18.0.1/16이란? 주소 풀과 예약 대역

198.18.0.0/15는 네트워크 장비 성능 측정용 특수 목적 IPv4 대역입니다. 범위는 198.18.0.0부터 198.19.255.255까지이며, 일반 웹사이트에서 사용하는 전 세계 라우팅 가능 공인 IP 주소가 아닙니다. 흔히 설정에 쓰이는 198.18.0.1/16은 이 중 /16 주소 풀을 Fake-IP에 사용한다는 뜻입니다. /16과 전체 /15를 혼동하지 마세요.

설정에 198.18.0.1/16이라고 적혀 있어도 모든 도메인에 198.18.0.1이 반환되는 것은 아닙니다. 커널이 주소 풀과 매핑을 관리하므로 도메인마다 서로 다른 주소를 받을 수 있습니다. 이 주소는 노드 서버 주소가 아니므로 노드 속도 측정에 사용하거나 구독 주소 입력란에 넣으면 안 됩니다.

예약 주소가 보일 때: DNS를 바로 바꾸기 전에 Fake-IP 응답인지 확인하세요.
기업망이나 테스트망에서 이미 해당 대역을 사용하는 경우: 라우팅 충돌이 발생할 수 있으므로 라우팅 테이블과 주소 풀 구성을 확인하세요.
주소 풀을 변경할 때: TUN 라우팅, 게이트웨이 경유 전달, 앱 캐시도 함께 점검해야 합니다. YAML 한 줄만 바꾸면 끝나는 문제가 아닙니다.

“실제 IP처럼 보이게” 하려고 주소 풀을 192.168.1.0/24로 함부로 바꾸지 마세요. 집의 라우터, 프린터, NAS가 사용하는 네트워크와 겹칠 가능성이 큽니다. 예약 주소를 사용하는 이유는 매핑 주소를 분리하기 위해서이지, 화면의 숫자를 익숙하게 보이게 하려는 것이 아닙니다.

Fake-IP와 redir-host: DNS 모드 선택하기

redir-host는 일반적으로 상위 DNS에서 조회한 실제 주소를 앱에 반환한 뒤 DNS 매핑 등의 정보를 활용해 연결을 처리합니다. fake-ip는 주로 로컬 매핑 주소를 반환합니다. 두 모드 이름은 DNS 확장 모드를 뜻하며, 클라이언트 첫 화면의 “규칙·전역·직접 연결” 모드와는 다릅니다.

비교 항목	fake-ip	redir-host
앱에 반환되는 A 레코드	일반적으로 주소 풀의 매핑 주소	일반적으로 상위 DNS가 반환한 실제 IPv4 주소
첫 DNS 응답	먼저 매핑 주소를 할당해 상위 DNS 응답 대기 시간을 줄일 수 있음	캐시에 없으면 대체로 실제 주소 조회를 기다려야 함
연결 처리 요건	가상 주소로 연결하려면 매핑을 보유한 커널로 돌아와야 함	연결을 올바르게 처리해야 하지만 실제 주소는 일반 네트워크에서도 인식 가능
자주 발생하는 호환성 문제	주소 탐지, LAN 장치 검색, 트래픽 가로채기를 우회하는 프로그램	공유 IP, DNS 캐시, 불완전한 도메인 연계 등의 문제
우선 사용해 볼 만한 환경	트래픽 가로채기가 제대로 설정되어 있고 도메인 규칙으로 분기하는 일반적인 인터넷 사용	실제 DNS 조회 결과에 의존하거나 Fake-IP 예외가 많은 환경

둘 중 하나를 무조건 선택할 필요는 없습니다. 일반 웹 브라우징과 TUN 트래픽 가로채기에는 Fake-IP를 먼저 사용하고, 실제 문제가 있는 서비스만 예외로 설정할 수 있습니다. 기업 VPN이나 복잡한 LAN, 주소 탐지에 의존하는 서비스는 실제 주소를 반환하는 모드가 관리하기 쉬운지 먼저 확인하세요. 한 번의 DNS 조회 시간만 볼 것이 아니라 서비스 접속 결과와 로그, 라우팅이 일치하는지를 기준으로 판단해야 합니다.

mihomo DNS 설정: 최소 구성과 확인 방법

아래는 dns 설정 일부만 보여 주는 예시이며, 전체 구독 설정이 아닙니다. 기존 설정에 병합하고 최상위 dns:가 중복되지 않도록 하세요. 예시는 로컬 검증을 위해 127.0.0.1:1053에서 수신하도록 설정했습니다. 이 설정만으로 시스템 DNS가 해당 포트로 바뀌거나 TUN이 자동으로 켜지지는 않습니다.

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'
    - '+.local'
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

nameserver는 상위 DNS 설정 예시일 뿐, 현재 네트워크에서 두 서버 모두 연결 가능하다는 뜻은 아닙니다. 암호화 DNS가 설정된 것도 아닙니다. 네트워크 위치와 조회 목적에 맞는 상위 DNS를 선택하세요. DoH나 DoT를 사용한다면 서버 도메인의 부트스트랩 조회, 서버 연결 가능 여부, 기존 DNS 분기 정책도 고려해 요청이 순환하지 않도록 해야 합니다.

먼저 커널을 테스트하고, 그다음 시스템 경로를 확인하세요

설정을 저장하고 커널에 정상적으로 적용된 것을 확인한 뒤, dig가 설치된 환경에서 다음 명령을 실행하세요. -p 1053으로 테스트 포트를 지정해 시스템이 사용 중인 다른 DNS 서비스에 잘못 질의하지 않도록 합니다.

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

다른 필터나 정책이 적용되지 않았다면 첫 번째 명령의 응답 영역에 198.18.x.x가 표시되고, 두 번째 명령은 주소만 출력해야 합니다. 실제 할당 주소는 커널 상태에 따라 달라지므로 특정 스크린샷과 일치할 필요는 없습니다. 연결이 거부되면 노드를 바꾸기 전에 DNS 기능, 수신 포트, 커널 로그부터 확인하세요.

커널에 직접 질의해 예상한 A 레코드를 받을 수 있는지 확인하세요.
클라이언트의 TUN DNS 하이재킹이나 시스템 DNS 전달이 실제로 커널을 가리키는지 확인하세요.
앱에서 새 연결을 만들고 연결 패널에서 도메인, 적용된 규칙, 연결 경로를 확인하세요.
이전 결과가 남아 있으면 앱과 시스템의 DNS 캐시를 지운 뒤 새 연결로 다시 테스트하세요.

fake-ip-filter 설정: 실제 주소 반환과 직접 연결은 별개

예시에서 명시한 blacklist 모드에서는 fake-ip-filter에 해당하는 도메인에 Fake-IP를 할당하지 않고 실제 주소를 조회합니다. 이 필드를 지원하는 mihomo에는 다른 필터 모드도 있으며 동작이 반대일 수 있습니다. 설정을 옮길 때는 필터 모드와 목록을 함께 확인하세요. 구형 커널에서 필드가 지원되지 않는다는 오류가 나면 해당 커널 문서에 맞게 조정해야 합니다. 오류만 없애고 설정 의미를 확인하지 않으면 안 됩니다.

예시의 '+.lan'은 lan 도메인과 하위 도메인에 적용되며 '+.local'도 같은 방식입니다. 이는 mihomo의 도메인 매칭 문법이지, 임의로 이어 붙일 수 있는 정규식이 아닙니다. 따옴표를 유지하면 관리하기 쉽고 YAML 특수 문자로 인한 파싱 문제도 줄일 수 있습니다.

세 가지 설정을 구분해서 관리하기

어떤 주소를 반환할지: Fake-IP 모드와 필터 정책으로 결정됩니다.
어떤 DNS에 조회할지: 상위 DNS와 nameserver-policy 등의 설정으로 결정됩니다.
연결을 어디로 보낼지: rules와 프록시 그룹 선택으로 결정됩니다.

따라서 NAS 도메인을 필터 목록에 추가해도 자동으로 집의 라우터에 조회하거나 DIRECT 규칙을 추가하지는 않습니다. 도메인이 라우터 DNS에만 등록되어 있다면 해당 도메인의 조회를 올바른 LAN DNS로 보내고, 연결이 대상 네트워크에 직접 도달하도록 설정해야 합니다.

목록을 관리할 때는 한 번에 서비스에 필요한 도메인 범위 하나만 추가하고, 변경 전후의 DNS 조회 결과와 접속 결과를 기록하는 것이 좋습니다. 범위가 지나치게 넓은 공용 도메인 접미사를 추가하면 원래 Fake-IP로 처리할 수 있었던 요청까지 실제 주소 조회로 바뀌고, 이후 문제를 추적하기도 어려워집니다.

LAN과 게임: 실제 문제에 맞춰 예외 추가하기

NAS, 프린터, .local 장치 검색

LAN 서비스는 보통 두 가지 방식으로 장치를 찾습니다. 하나는 라우터가 제공하는 유니캐스트 DNS로 장치 이름을 조회하는 방식이고, 다른 하나는 로컬 네트워크에서 mDNS로 장치를 검색하는 방식입니다. .local은 mDNS에 자주 사용되며, mDNS는 보통 UDP 5353을 사용합니다. 일반 DNS의 53 포트와는 다릅니다. +.local을 필터 목록에 추가해도 모든 멀티캐스트 검색 문제가 해결되는 것은 아닙니다.

NAS의 LAN IP로는 접속되지만 호스트 이름으로는 안 된다면 먼저 DNS 조회 경로를 확인하세요. 장치 목록에 아예 표시되지 않는다면 방화벽, 네트워크 격리, 멀티캐스트, TUN 라우팅도 확인해야 합니다. 문제 발생 계층에 따라 적절한 도구도 달라집니다.

게임 로그인, 대전 UDP, 지연 시간 표시

게임은 도메인 조회 결과를 지역 판정, 서버 목록, 연결 확인, 지연 시간 표시에 활용할 수 있습니다. 일부 확인 로직은 예약 주소를 처리하지 못할 수 있습니다. 이때 전체 Fake-IP를 끄기보다 문제가 있는 도메인만 실제 주소로 조회하도록 예외 처리하는 편이 원인을 찾기 쉽습니다.

로그인 실패: 로그인 도메인의 DNS 조회, HTTPS 연결, 적용 규칙을 확인하세요. 바로 UDP 문제라고 단정하지 마세요.
로그인은 되지만 대전에 참가할 수 없음: 게임 UDP 트래픽이 가로채기되고 있는지, 노드와 연결 경로가 필요한 UDP 트래픽을 지원하는지 확인하세요.
지연 시간 표시가 이상하지만 게임은 가능함: 게임이 ICMP나 별도의 탐지 도메인을 사용하는지 확인하세요. 표시된 값이 실제 대전 연결의 지연 시간을 나타내지 않을 수도 있습니다.
모드를 전환한 뒤에만 문제가 생김: 게임과 런처를 완전히 종료하고 캐시를 지운 다음 새로 연결하세요.

모든 게임 도메인을 기본적으로 필터 목록에 넣지 마세요. “UDP 허용”이 지연 시간 감소를 보장한다고 생각해서도 안 됩니다. Fake-IP는 주소 매핑만 처리합니다. 연결 경로의 거리, 노드 혼잡도, NAT 유형, 게임 서버 상태는 별개의 요소입니다.

Fake-IP 접속 문제 점검 순서

문제를 확인할 때는 한 번에 변수 하나만 바꾸고 실행 로그를 보관하세요. 아래 순서대로 설정부터 연결까지 점검하면 전역 모드를 반복해서 바꾸는 것보다 효과적입니다.

실행 중인 설정 확인: 현재 설정의 enhanced-mode가 fake-ip인지, 구독 업데이트가 로컬 변경 사항을 덮어쓰지 않았는지, 커널에서 설정 오류가 발생하지 않았는지 확인하세요.
DNS 조회 경로 확인: 먼저 127.0.0.1:1053에 직접 조회한 뒤 시스템이나 브라우저의 결과와 비교하세요. 브라우저의 보안 DNS나 앱 자체 DoH가 예상한 시스템 DNS 경로를 우회할 수 있습니다.
트래픽 가로채기 범위 확인: 일반적인 TUN DNS 하이재킹은 보통 기존 DNS 트래픽을 대상으로 설정합니다. 모든 HTTPS 암호화 DNS를 일반적인 53번 포트 조회처럼 자동으로 식별할 수는 없습니다. 앱이 가상 주소를 받은 뒤의 연결도 커널을 거쳐야 합니다.
매핑과 캐시 확인: 커널 재시작, 설정 전환, 주소 풀 변경 후에도 앱에 이전 가상 주소가 남아 있을 수 있습니다. 먼저 캐시를 지우고 관련 앱을 재시작한 다음, 커널의 Fake-IP 매핑 유지 설정을 조정해야 하는지 판단하세요.
규칙 확인: 연결에 도메인이 표시되는데도 잘못된 경로로 나간다면 DNS만 바꾸지 말고 규칙 순서와 프록시 그룹을 확인하세요. 대상 IP에 의존하는 규칙은 실제 주소 조회를 유발할 수도 있습니다.
IPv4와 IPv6 모두 확인: A와 AAAA 레코드를 각각 테스트하고 IPv6 트래픽 처리도 확인하세요. IPv4 조회가 한 번 성공했다고 IPv6 경로까지 올바르게 설정된 것은 아닙니다.

최종적으로는 각 설정의 이유를 설명할 수 있어야 합니다. DNS 요청이 어디서 들어오는지, 필터 항목이 필요한 이유는 무엇인지, 실제 주소 조회를 어느 서버에 맡기는지, 어떤 규칙이 연결을 처리하는지 정리해 두세요. Fake-IP의 장점은 DNS 조회 대기를 줄이고 도메인 정보를 유지하는 것입니다. 라우팅이나 규칙, 네트워크 품질 점검을 대신하지는 않습니다.