Clash Fake-IP 모드 완벽 해설: Redir-Host와의 차이 및 활용 시나리오

DNS 해석이 프록시 경로에서 맡는 역할

Fake-IP를 논하기 전에 자칫 간과하기 쉬운 문제를 먼저 짚어봐야 합니다. 클라이언트가 도메인에 접속할 때 실제로는 먼저 실제 IP를 해석한 뒤 어떤 경로를 탈지 결정하는 걸까요, 아니면 그 반대일까요? 이 순서가 프록시 소프트웨어의 분기 정확도와 응답 속도를 직접 좌우합니다. 전통적인 운영체제의 네트워크 스택은 "먼저 해석, 그다음 연결"이라는 순서를 따릅니다. 애플리케이션이 시스템의 DNS 해석 함수를 호출해 실제 IP를 얻은 뒤, 그 IP로 TCP나 UDP 연결을 시작하는 방식입니다. 프록시 소프트웨어가 이 순서를 그대로 따른다면 곤란한 상황이 발생합니다. 도메인 해석 단계는 대개 프록시를 거치지 않고 로컬 네트워크의 DNS 서버에 그대로 노출되는데, 이후의 연결은 프록시 규칙에 따라 분기 판단을 해야 하는 상황이 벌어지는 것입니다.

Clash 코어(Clash Premium과 Clash Meta/mihomo 포함)는 규칙 매칭을 설계할 때 대부분의 규칙 유형을 도메인 기반으로 구성합니다. 예를 들어 DOMAIN-SUFFIX, DOMAIN-KEYWORD 같은 규칙은 연결이 시작되는 단계에서 이미 매칭을 완료할 수 있으며 IP에 의존하지 않습니다. 하지만 GEOIP, IP-CIDR처럼 IP에 의존하는 규칙도 있으며, 이런 규칙은 분기 결정을 내리기 전에 클라이언트가 사용 가능한 IP 주소를 먼저 확보해야 합니다. 여기서 모순이 발생합니다. 일반적인 흐름대로 실제 DNS 해석을 먼저 수행하면 해석 요청 자체가 이미 현지 통신사나 사설망의 DNS 서버에 노출될 수 있는데, 이것이 바로 DNS 유출입니다. 반대로 해석을 전혀 하지 않고 도메인을 원격 프록시 노드에 넘겨버리면 로컬의 IP 기반 규칙이 무력해집니다. Fake-IP는 바로 이 둘 사이에서 절충점을 찾기 위해 설계된 메커니즘입니다.

Fake-IP는 가상 주소로 어떻게 속도와 프라이버시를 얻는가

Fake-IP의 핵심 원리는 한 문장으로 요약할 수 있습니다. 클라이언트가 로컬에서 "도메인 → 가상 IP" 매핑 테이블을 유지하며, 애플리케이션이 특정 도메인 해석을 요청하면 Clash 코어는 실제로 공용 DNS에 질의하지 않고 예약된 사설 대역(보통 198.18.0.0/16)에서 한 번도 사용되지 않은 주소를 하나 할당해 그대로 애플리케이션에 반환합니다. 애플리케이션은 겉보기에 정상적인 이 IP를 받아 그대로 연결을 시작하고, 데이터 패킷은 로컬 라우팅이나 TUN 가상 네트워크 카드에 의해 가로채입니다. 코어는 이 가상 IP를 통해 원래의 도메인을 역으로 조회하고, 그 도메인을 원격 프록시 노드에 넘겨 실제 DNS 해석과 연결을 진행합니다.

이 방식이 가져다주는 첫 번째 이점은 속도입니다. 애플리케이션이 가상 IP를 받는 과정은 거의 지연 없는 로컬 연산이라 실제 네트워크 왕복을 기다릴 필요가 없고, 첫 패킷 확립까지의 대기 시간이 크게 줄어듭니다. 두 번째 이점은 프라이버시입니다. 로컬 네트워크 환경에서는 사용자가 실제로 접속하는 도메인에 대응하는 실제 IP가 무엇인지 전혀 알 수 없으며, DNS 조회 요청도 실제로 로컬 네트워크의 해석 서버로 전송되지 않기 때문에 DNS 계층에서의 정보 노출이 줄어듭니다. 세 번째 이점은 규칙 호환성입니다. 각 가상 IP가 원래 도메인으로 고유하게 매핑되므로, 도메인 기반 규칙은 원격 해석 결과를 기다리지 않고 로컬에서 그대로 매칭을 완료할 수 있습니다.

대표적인 Fake-IP DNS 설정 구조는 대략 다음과 같습니다(mihomo 코어 기준):

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'time.*.com'
    - 'ntp.*.com'
    - '+.push.apple.com'
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query

여기서 enhanced-mode: fake-ip는 Fake-IP 강화 해석 모드를 명시적으로 활성화하는 항목이고, fake-ip-range는 가상 주소 풀의 대역 범위를 지정합니다. fake-ip-filter는 어떤 도메인을 Fake-IP를 거치지 않고 실제 해석 결과를 바로 사용할지 결정하는 핵심 설정 항목이며, 뒤에서 그 필요성을 별도로 다룹니다.

Fake-IP와 Redir-Host의 본질적 차이

Fake-IP가 등장하기 전, Clash 생태계에서 더 먼저 널리 쓰였던 것은 Redir-Host 모드입니다. 둘 다 "강화 DNS 모드"(enhanced-mode)의 값 옵션이지만 동작 방식이 전혀 다르며, 이 차이를 이해해야 어떤 시나리오에서 어느 쪽을 써야 할지 판단할 수 있습니다.

• Redir-Host의 방식: 클라이언트가 DNS 요청을 받으면 실제로 상위 서버에 해석을 요청해 도메인에 대응하는 실제 IP를 얻고, 이 실제 IP를 그대로 애플리케이션에 반환합니다. 규칙 매칭은 주로 이후 트래픽 리다이렉션 단계에서 기록된 도메인을 근거로 판단하며, 연결 확립 시에는 실제 IP가 사용됩니다.
• Fake-IP의 방식: 앞서 설명한 대로 실제 해석을 하지 않고 가상 주소를 바로 반환하며, 실제 해석은 연결이 실제로 확립되어 트래픽이 프록시 노드에 진입한 이후 원격에서 이루어지도록 지연됩니다.

이 차이는 실제로 체감할 수 있는 몇 가지 결과를 낳습니다. 먼저 속도입니다. Redir-Host는 매번 해석할 때마다 실제 DNS 왕복을 기다려야 하지만, Fake-IP는 이 과정을 생략해 첫 연결 속도가 더 빠르며, 특히 국경을 넘는 네트워크 환경에서 체감 차이가 뚜렷합니다. 다음은 프라이버시 경계입니다. Redir-Host 모드에서는 기기가 여전히 실제 도메인을 상위 DNS 서버에 넘겨 해석하는데, 이 상위 서버가 신뢰할 수 있는 암호화 DNS라 해도 해석 기록은 로컬 네트워크 출구를 거치게 됩니다. Fake-IP는 이 해석 단계를 프록시 노드 이후로 완전히 옮겨서, 로컬 네트워크에서는 실제 도메인에 대응하는 해석 행위를 전혀 볼 수 없습니다. 세 번째는 호환성입니다. "애플리케이션 계층에서 실제 IP를 직접 얻어야 하는" 일부 시나리오(예를 들어 어떤 게임 클라이언트는 서버 IP를 연결 품질 검사에 사용하거나, 일부 내부망 터널링 도구는 검증을 위해 실제 주소가 필요함)에서는 Fake-IP를 사용할 때 이상 동작이 나타날 수 있습니다. 애플리케이션이 얻는 값이 항상 가상 주소이기 때문이며, Redir-Host는 적어도 애플리케이션 계층이 보는 IP가 실제 주소임을 보장합니다.

따라서 현재 주류 클라이언트(mihomo 코어 기반의 각종 GUI 클라이언트 포함)는 기본적으로 Fake-IP를 권장하고, Redir-Host는 호환성 문제 발생 시의 대체 수단으로 남겨두는 것이 일반적이며, 그 반대가 아닙니다. 사용 중 특정 앱에서 연결 이상, 주소 표시 오류, 핸드셰이크 실패가 발생한다면 먼저 Fake-IP 메커니즘 때문에 실제 IP가 보이지 않는 문제인지 확인한 뒤, 필요하다면 임시로 Redir-Host로 전환해 원인을 좁혀가는 것이 좋습니다.

fake-ip-filter를 올바르게 설정해야 하는 이유

Fake-IP가 속도와 프라이버시라는 두 가지 이점을 가져다주지만 모든 도메인에 적합한 것은 아닙니다. 일부 시나리오에서는 애플리케이션이 실제 IP를 얻어야만 정상 동작하는데, 이 경우 반드시 해당 도메인을 fake-ip-filter 목록에 추가해 Fake-IP 로직을 건너뛰고 실제 해석을 사용하도록 해야 합니다.

사설망 및 내부 서비스

가정이나 회사 내부망에서 도메인으로 접속하는 NAS, 라우터 관리 페이지, 내부망 터널링 서비스 등이 있다면 이 도메인들은 사설망 내의 실제 IP로 해석되어야 하며 가상 주소가 되어서는 안 됩니다. 그렇지 않으면 기기가 내부망의 실제 호스트를 찾지 못합니다. 흔한 방법은 *.lan, *.local 및 사용자가 정의한 내부망 도메인 접미사를 통일해서 필터 목록에 추가하는 것입니다. 일부 기업 내부망은 자체 구축한 도메인을 사설 대역으로 해석하기도 하는데, 이런 도메인도 필터 범위에 포함해야 합니다.

시간 동기화 및 저지연 감지 서비스

운영체제의 시간 동기화 프로토콜(NTP)은 보통 프록시 전달에 의존하지 않고 IP로 직접 통신하는데, Fake-IP에 의해 처리되면 오히려 시간 동기화 실패나 지연 이상이 발생할 수 있습니다. 이와 비슷하게 일부 시스템 수준의 네트워크 품질 감지 서비스도 프록시를 거칠 필요가 없고 가상 주소로 방해받아서는 안 되는 요청이라서, 일반적인 설정 템플릿에는 ntp.*.com, time.*.com 같은 규칙이 미리 포함되어 있습니다.

푸시 서비스 및 실시간 통신

일부 운영체제 수준의 푸시 채널(예: 기기와 제조사 푸시 서버 간에 유지되는 장기 연결)은 연결 안정성과 실제 주소에 대한 요구가 높은데, Fake-IP에 의해 처리되면 푸시 지연이나 연결 끊김이 발생할 수 있습니다. 설정 템플릿에서 흔히 보이는 +.push.apple.com 같은 와일드카드 규칙은 바로 이런 상황을 피하기 위한 것입니다.

게임 플랫폼 및 실시간 대전 서비스

일부 온라인 게임 클라이언트는 서버에 연결하기 전 목표 IP에 대해 능동적으로 네트워크 품질을 탐지하거나, 게임 내에서 서버의 실제 지연과 주소 정보를 표시합니다. 이런 시나리오에서 애플리케이션 계층이 가상 IP를 받으면 탐지 결과가 왜곡되고, 심지어 게임 클라이언트 자체의 비정상 연결 판정을 유발할 수도 있습니다. 연결 이상이나 매칭 실패가 자주 발생하는 게임 플랫폼 도메인이라면 먼저 fake-ip-filter에 추가해 문제가 사라지는지 관찰한 뒤, 해당 게임을 위한 별도의 분기 규칙이 필요한지 판단하는 것을 권장합니다.

실제 사용 중 흔한 의문과 점검 방향

Fake-IP를 활성화한 뒤 일부 사용자는 사용 경험에서 다소 이상해 보이는 현상을 겪곤 합니다. 여기서는 몇 가지 대표적인 상황과 그에 맞는 점검 방향을 정리합니다.

일부 앱에 표시되는 서버 IP가 왜 198.18로 시작하는 낯선 주소인가

이것이 바로 Fake-IP 대역이 작동하고 있다는 증거입니다. 애플리케이션의 연결 정보에 198.18.x.x 형태의 주소가 나타난다면, 대개 이 연결이 Fake-IP에 의해 처리되고 있으며 도메인 해석 결과가 실제 IP가 아닌 가상 주소라는 뜻입니다. 해당 앱에 기능적 문제가 생기지 않는 이상, 이 자체는 정상적인 현상이며 설정 오류를 의미하지 않습니다.

네트워크를 전환한 뒤 주소 매핑을 정리해야 하는가

Fake-IP의 매핑 테이블은 클라이언트 로컬에서 유지되며, 보통 프로세스 재시작이나 DNS 캐시 수동 삭제와 함께 초기화됩니다. 네트워크 환경을 전환한 뒤 연결 이상이 발생한다면 클라이언트 화면에서 "Fake-IP 캐시 지우기" 또는 유사한 옵션을 찾아 시도해 보세요. 일부 GUI 클라이언트는 이 기능을 DNS 설정이나 고급 설정 영역에 배치합니다.

IPv6 환경에서 주의할 점

Fake-IP는 기본 시나리오에서 주로 IPv4 주소 풀을 다루므로, 로컬 네트워크에서 IPv6도 함께 활성화되어 있고 시스템이 IPv6 연결을 우선 시도하는 경우, 일부 트래픽이 Fake-IP 로직을 건너뛰고 직접 IPv6 연결을 시작할 수 있습니다. 대부분의 설정 템플릿은 DNS 설정의 ipv6 항목을 명시적으로 false로 지정하거나, 규칙 세트를 함께 사용해 IPv6 트래픽을 별도로 처리함으로써 프록시 판단을 우회하는 연결 경로가 생기지 않도록 합니다.

DNS 유출 개선 여부를 어떻게 확인하는가

DNS 해석 출처를 확인할 수 있는 온라인 검사 도구를 활용해 Fake-IP를 켜기 전과 켠 후 각각 한 번씩 검사하고, 해석 기록의 소속 위치가 바뀌었는지 비교해 보면 됩니다. 정상적인 경우 Fake-IP를 활성화하고 신뢰할 수 있는 원격 DNS 해석과 함께 사용하면 검사 결과가 프록시 노드가 위치한 네트워크에서 해석이 이루어진 것으로 표시되어야 하며, 현지 통신사의 DNS 서버가 아니어야 합니다.

Fake-IP와 TUN 모드의 협업 관계

Fake-IP는 흔히 TUN 모드와 함께 언급되지만, 둘이 해결하는 문제의 층위는 서로 다르므로 혼동하지 않아야 합니다. TUN 모드는 시스템 네트워크 계층에 가상 네트워크 카드를 하나 만들어 모든 아웃바운드 트래픽(브라우저나 개별 앱뿐 아니라)이 Clash 코어를 거치도록 하는 것으로, "어떤 트래픽이 프록시 대상에 포함될 수 있는가"라는 커버리지 문제를 해결합니다. 반면 Fake-IP는 "도메인 해석 단계를 어떻게 처리할 것인가"라는 문제를 해결하며, 둘은 독립적으로 켜거나 함께 사용할 수 있습니다. 실제 설정에서는 TUN 모드를 켤 때 대개 Fake-IP도 함께 활성화하도록 권장하는데, 그래야 TUN 카드가 가로챈 트래픽이 도메인 규칙 매칭 단계에서 충분한 정보를 얻을 수 있고, 동시에 시스템 수준의 DNS 요청이 가상 네트워크 카드를 건너뛰고 로컬 네트워크로 직접 전송되는 것을 막아 완결된 흐름을 이룰 수 있기 때문입니다.

TUN 모드만 켜고 DNS 강화 모드를 비워두거나 시스템 기본 해석을 그대로 쓴다면, DNS 요청이 프록시를 건너뛰고 로컬에 설정된 DNS 서버로 직접 전송되는 상황이 여전히 발생할 수 있습니다. 이는 "TUN 모드를 켰는데도 해석 실패나 DNS 유출이 표시된다"는 문제를 점검할 때 가장 먼저 확인해야 할 설정 항목입니다.

설정 권장 사항 정리

지금까지의 원리를 종합해 바로 적용할 수 있는 몇 가지 권장 사항을 정리합니다. 특별한 내부망 요구가 없는 일반 사용자는 클라이언트의 기본 Fake-IP 설정을 그대로 유지하면 되고 추가 조정이 필요 없습니다. 내부망 서비스나 기업 도메인 해석 요구가 있는 사용자는 fake-ip-filter 목록을 능동적으로 점검하고 내부망 도메인 접미사를 추가해야 합니다. 게임이나 실시간 통신 앱에서 연결 이상이 발생하면 먼저 Fake-IP의 영향을 의심하고, 해당 도메인을 임시로 필터링하거나 Redir-Host로 전환해 비교 테스트를 진행해 원인을 좁혀야 합니다. TUN 모드를 사용하는 사용자는 DNS 강화 모드와 Fake-IP 대역 설정이 함께 제대로 적용되었는지 확인해, 트래픽은 가로채졌지만 해석은 여전히 로컬 기본 DNS를 거치는 절반짜리 설정 상태가 되지 않도록 해야 합니다.