Fake-IP 모드란? DNS 하이재킹 원리와 장단점, 활용 시나리오 분석

프록시 소프트웨어가 DNS 해석에 개입하는 이유

평소 인터넷을 이용할 때 기기가 어떤 도메인에 접속하려면 먼저 DNS 해석 과정을 거칩니다. 시스템이 도메인을 DNS 서버에 넘겨 실제 IP를 받아온 뒤, 그 IP로 연결을 맺는 방식입니다. 문제는 Clash처럼 규칙 기반으로 트래픽을 분류하는 프록시 도구는 많은 분류 규칙이 도메인 단위로 매칭된다는 점입니다. 예를 들어 GeoSite 규칙으로 특정 도메인이 프록시를 거칠지 직접 연결할지를 판단합니다. 만약 프록시 소프트웨어가 DNS 해석에 전혀 개입하지 않고 연결 요청 시점에 순수한 IP만 보게 된다면, 그 IP가 어떤 도메인이었는지 역추적할 방법이 없고, 규칙에 적어둔 도메인 매칭 조건도 무용지물이 됩니다.

이 문제를 해결하기 위해 Clash/mihomo 코어는 여러 가지 DNS 처리 모드를 제공하며, Fake-IP는 그중 기본값이자 가장 널리 쓰이는 방식입니다. 원리는 단순합니다. 클라이언트가 도메인을 조회하면 실제 IP를 앱에 넘기지 않고, 코어가 임의로 만들어낸(실제로 어디에도 할당된 적 없는) 가상 주소를 반환합니다. 동시에 코어 내부에서는 이 가상 주소가 어떤 도메인에 대응하는지 기억해둡니다. 앱이 실제로 연결을 시도하는 순간 코어는 기억해둔 도메인으로 규칙 매칭을 수행해 프록시를 거칠지 직접 연결할지를 결정하며, 이 과정은 상위 애플리케이션에는 완전히 투명하게 진행됩니다.

Fake-IP 모드의 동작 원리: 예약 주소 대역과 매핑 테이블

Fake-IP가 반환하는 주소는 무작위로 지어낸 것이 아니라, 실제 네트워크에서 라우팅되지 않도록 별도로 떼어둔 프라이빗 주소 대역에서 할당됩니다. 대표적인 설정에서는 198.18.0.0/16 같은 예약 대역을 기본값으로 사용합니다. 이 대역은 공개 인터넷에서 실제로 쓰이지 않으며, 코어는 이를 "임시 번지수"처럼 활용합니다. 대략적인 흐름은 다음과 같습니다.

애플리케이션이 특정 도메인에 대해 DNS 조회를 요청합니다.
Clash/mihomo의 DNS 모듈이 이 조회를 가로채, 실제 상위 DNS 서버에 묻는 대신 예약 주소 풀에서 아직 사용되지 않은 가상 IP를 꺼내옵니다.
코어는 메모리 안에 "가상 IP ↔ 도메인" 매핑 테이블을 유지하면서 대응 관계를 기록하고, 이 가상 IP를 애플리케이션에 반환합니다.
애플리케이션이 가상 IP로 연결을 시도하면 코어는 연결 수립 단계에서 매핑 테이블을 조회해 실제 도메인을 복원하고, 규칙 세트에 따라 어떤 정책과 프록시 노드를 거칠지 판단합니다.
규칙상 프록시를 거쳐야 한다면 코어는 도메인 정보를 프록시 노드 측으로 넘겨 그곳에서 실제 해석과 연결이 이루어지도록 하며, 실제 IP 해석 단계는 연결 경로의 다른 쪽 끝으로 미뤄집니다.

이 방식의 직접적인 장점은 해석 지연이 눈에 띄게 줄어든다는 점입니다. 대부분의 경우 코어가 실제로 상위 DNS에 조회할 필요 없이 로컬 주소 풀에서 가상 주소 하나를 즉시 내주기 때문입니다. 동시에 도메인 정보가 코어 내부에 계속 유지되므로 도메인 기반 분류 규칙이 정밀하게 작동하며, "IP 대역으로만 추측하는" 방식으로 후퇴하지 않습니다.

핵심 포인트Fake-IP가 반환하는 주소는 오직 로컬 프록시 프로세스 내부에서만 의미가 있습니다. 이 기기를 벗어나는 순간(예: 다른 프로그램에 기록되거나 다른 기기로 전달되는 경우) 이 가상 주소는 실제로 할당되거나 라우팅된 적이 없기 때문에 아무런 쓸모가 없어집니다.

Fake-IP, Redir-Host, 일반 해석 모드의 선택 기준

Fake-IP 외에도 코어는 보통 두 가지 DNS 처리 방식을 추가로 지원합니다. 이들의 차이를 이해하면 자신의 환경에 맞는 모드를 고르는 데 도움이 됩니다.

Fake-IP 모드: 앞서 설명한 대로 가상 주소를 반환하고 코어 내부에서 도메인 기반 규칙 매칭을 수행합니다. 지연이 낮고 도메인 매칭이 정밀하다는 장점이 있지만, 가상 주소는 실제 IP가 필요한 상황(예: 일부 앱이 해석된 IP를 캐시해 헬스체크나 화면 표시에 직접 사용하는 경우)에는 쓸 수 없다는 단점이 있습니다.
Redir-Host 모드: 마찬가지로 앱에 반환된 주소를 이용해 규칙 판단을 트리거하지만, 목적지 포트 기준의 리다이렉트 전달에 더 치중된 방식이며 구현 세부사항과 적용 범위가 Fake-IP보다 제한적입니다. 현재 주요 클라이언트들은 이를 기본값으로 잘 채택하지 않습니다.
일반 해석(Fake-IP를 사용하지 않는 직접 해석) 모드: 매번 실제 상위 DNS 서버에 조회를 보내 실제 IP를 받아옵니다. 애플리케이션이 항상 사용 가능한 실제 주소를 받는다는 장점 덕분에 호환성이 가장 좋지만, 도메인 기반의 정밀한 규칙 매칭 능력을 잃어(IP 대역으로만 판단 가능) 매번 조회할 때마다 실제 네트워크 왕복 지연이 발생한다는 단점이 있습니다.

웹 브라우징, 동영상 시청, 소셔셜 앱 등 대부분의 일상적인 사용 환경에서는 Fake-IP가 지연이 더 낮고 매칭이 더 정확한 선택입니다. 그래서 대부분의 클라이언트가 이를 기본 모드로 설정해두는 것입니다.

로컬 네트워크 서비스와 게임 멀티플레이에서 fake-ip-filter 설정이 필수인 이유

Fake-IP의 가상 주소 방식은 기기 간 통신 시나리오에서 명확한 한계를 드러냅니다. 대표적으로 두 가지 상황이 있습니다.

로컬 네트워크의 자체 구축 서비스나 라우터 관리 페이지. 예를 들어 집에 NAS나 라우터가 있고 도메인 해석이 내부 DNS를 거친다면, 원래는 192.168.x.x 같은 실제 내부 주소를 받아야 합니다. 하지만 이런 도메인이 Fake-IP 처리 대상에서 제외되지 않으면 코어는 여전히 198.18.x.x 같은 가상 주소를 반환하고, 앱은 이 가상 주소로 연결을 시도합니다. 코어가 규칙에 따라 전달을 시도하지만 결과적으로 연결이 실패하거나 우회 경로를 거쳐야만 연결되는 경우가 많아, 체감상 "내부 기기 접속이 느려지거나 아예 타임아웃되는" 현상으로 나타납니다.

게임 멀티플레이 및 실시간 대전형 애플리케이션. 많은 게임 클라이언트가 서버 도메인 해석 결과를 UDP 연결 수립이나 지연 측정에 직접 사용하며, 심지어 해석된 IP를 화면에 표시해 사용자가 서버(노드)를 선택하는 기준으로 삼기도 합니다. 이런 환경에서 가상 주소는 연결 실패, 지연 값 이상, 혹은 게임 내 서버 목록이 아예 제대로 불러와지지 않는 문제를 일으킵니다.

해결 방법은 DNS 설정에 fake-ip-filter 항목을 추가해 해당 도메인이나 도메인 패턴을 Fake-IP 처리 대상에서 제외하고 실제 해석을 사용하도록 하는 것입니다. 일반적인 설정 예시는 다음과 같습니다.

dns:
  enable: true
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "192.168.*.*.*"
    - "router.asus.com"
    - "+.msftconnecttest.com"
    - "+.msftncsi.com"

여기서 *.lan, *.local 같은 와일드카드 표기는 대부분의 가정용 로컬 네트워크 기기에서 흔히 쓰이는 도메인 접미사를 포괄합니다. +. 접두사가 붙은 표기는 메인 도메인과 그 모든 서브도메인을 동시에 매칭한다는 뜻으로, 연결 상태 확인용 시스템 도메인을 제외할 때 자주 사용되며, 이를 통해 가상 주소로 인해 시스템이 "네트워크 사용 불가"로 잘못 판단하는 것을 막을 수 있습니다. 게임 관련 도메인은 공식 문서에 나온 서버 도메인 목록을 하나씩 추가하는 것을 권장하며, 큰 범주를 통째로 제외하는 방식은 Fake-IP가 본래 제공하는 분류 정밀도를 희생시키므로 피해야 합니다.

문제 해결 방법: "특정 서비스에 접속이 안 될 때" 원인 찾는 순서

Fake-IP가 원인일 가능성이 있을 때는 다음 순서로 확인해보세요.

먼저 현재 DNS 모드가 정말로 Fake-IP인지 확인해, 다른 모드로 인한 문제가 아닌지 배제합니다.
클라이언트의 연결 로그나 도메인 해석 기록을 확인해, 대상 도메인이 198.18.x.x 같은 예약 대역 주소로 해석되고 있는지 확인합니다.
만약 그렇다면 해당 도메인이 잘못 Fake-IP 처리 대상에 포함된 것이므로 fake-ip-filter에 추가해야 합니다.
설정 변경 후 코어를 재시작하거나 설정을 다시 불러옵니다(클라이언트마다 진입 경로가 다르지만 보통 설정 관리 페이지에 "다시 불러오기" 버튼이 있습니다). 이렇게 하면 이전 매핑 테이블이 계속 적용되는 것을 방지할 수 있습니다.
문제가 여전히 남아 있다면 DNS 모드가 아니라 규칙 세트 자체가 해당 도메인을 사용할 수 없는 프록시 노드로 분류하고 있는지 확인합니다.

참고fake-ip-filter를 수정한 뒤에도 이미 생성된 매핑 관계가 캐시에 남아 있을 수 있습니다. 설정 파일만 다시 불러오기보다는 프록시 코어를 재시작해 기존 가상 주소 매핑을 완전히 비우는 것을 권장합니다.

Fake-IP를 끄는 것을 고려해볼 만한 경우

모든 환경에서 Fake-IP를 반드시 써야 하는 것은 아닙니다. 사용 중인 네트워크 환경에서 실제 IP 검증에 의존하는 애플리케이션이 많거나, 로컬 네트워크 서비스가 특히 많아 필터 규칙을 하나씩 추가하는 유지 비용이 지나치게 높다면, 전체적으로 실제 해석 모드로 전환해 일부 지연 이점을 포기하고 호환성 문제를 줄이는 방법도 있습니다. 하지만 브라우저, 소셜 앱, 동영상 클라이언트가 정상적으로 분류되기만 하면 되는 대다수 사용자에게는 Fake-IP 기본 설정을 유지하면서 로컬 네트워크 도메인과 일부 특수 애플리케이션만 필터 목록에 추가하는 방식이 유지 비용과 사용 경험 사이에서 더 균형 잡힌 선택입니다.