Fake-IP 모드 원리 완전 해설: DNS 해석이 어떻게 가로채지는지, 켜고 꺼야 할 상황은
DNS 조회 흐름부터 시작해 Fake-IP가 예약 대역의 가상 주소로 규칙 매칭을 앞당기고 DNS 유출을 줄이는 원리를 설명하고, Redir-Host와의 차이를 비교하며, 로컬 네트워크 서비스나 게임 등 끄거나 예외 처리가 필요한 대표적인 상황을 정리합니다.
일반 DNS 해석 흐름과 프록시 환경에서 발생하는 문제
어떤 도메인에 접속하기 전에는 시스템이 먼저 도메인을 IP 주소로 변환해야 하는데, 이 단계를 DNS 해석이라고 부릅니다. 기본적으로 운영체제는 조회 요청을 통신사나 시스템에 설정된 DNS 서버로 보내고, 실제 IP를 받아온 뒤 연결을 시작합니다. 프록시가 없는 환경에서는 이 흐름에 별문제가 없지만, 프록시 소프트웨어가 끼어들면 적어도 두 가지 골칫거리가 생깁니다.
첫 번째 문제는 유출입니다. 프록시 소프트웨어가 TCP/UDP 트래픽만 가로채고 DNS 조회는 관리하지 않으면, 도메인 해석 요청이 프록시를 거치지 않고 로컬 네트워크로 그대로 나가버립니다. 통신사나 로컬 네트워크를 감시하는 쪽에서는 사용자가 어떤 도메인을 조회하는지 그대로 볼 수 있는데, 이것이 흔히 말하는 DNS 유출입니다—트래픽은 프록시를 탔지만 조회 기록은 그렇지 않은 상태입니다.
두 번째 문제는 매칭 시점입니다. Clash의 분기 규칙에는 도메인 기반 규칙(DOMAIN-SUFFIX, DOMAIN-KEYWORD 등)이 많고, 이런 규칙은 원래 도메인 문자열을 가지고 매칭하는 편이 자연스럽습니다. 하지만 전통적인 흐름은 먼저 IP로 해석을 끝내버리기 때문에, 애플리케이션 계층에 도달했을 때는 이미 숫자로만 이루어진 IP뿐이고 도메인 정보는 사라진 뒤입니다. 이 시점에 규칙 매칭을 하면 결국 IP 대역 기반 매칭으로 후퇴할 수밖에 없고, 규칙 목록의 유지 비용과 커버리지도 함께 떨어집니다.
Fake-IP란 무엇인가: 예약 대역의 가상 주소로 실제 해석을 대신하기
Fake-IP는 Clash / Clash Meta(mihomo) 커널이 제공하는 DNS 처리 모드입니다. 핵심 원리는 단순합니다. 클라이언트가 내부에 DNS 서버를 하나 두고, 시스템이 내보내는 모든 도메인 조회를 가로채서 실제 DNS에는 묻지 않은 채, 공인망에서 한 번도 쓰인 적 없는 예약된 사설 대역(기본값은 흔히 198.18.0.0/16)에서 도메인마다 가상 IP를 하나씩 배정하고, 커널 내부에 "도메인 ↔ 가상 IP" 매핑 테이블을 유지합니다.
애플리케이션이 이 가상 IP를 받으면 평소처럼 연결을 시도하고, 그 연결 요청은 Clash의 트래픽 가로채기 계층(TUN 모드 또는 시스템 프록시)으로 들어옵니다. 이때 커널이 매핑 테이블을 먼저 확인해 목적지가 가상 IP임을 발견하면 즉시 원래 도메인으로 역조회를 수행하고, 그 결과 규칙 매칭 단계는 맥락을 잃은 IP 숫자가 아니라 도메인 문자열을 다시 손에 넣게 됩니다. 실제 도메인 해석 동작은 "이 트래픽이 어느 프록시 노드를 거쳐야 하는지" 규칙이 판단된 이후로 미뤄지고, 해석 요청 자체도 프록시 노드를 통해 전달되기 때문에 로컬 네트워크에 그대로 노출되지 않습니다.
이렇게 하면 앞서 언급한 두 가지 문제가 동시에 해결됩니다. DNS 조회는 처음부터 끝까지 프록시 경로 안에서 이루어져 로컬 네트워크에 드러나지 않고, 규칙 매칭은 미리 고정된 IP가 아니라 항상 도메인을 근거로 판단하므로 매칭 정확도와 응답 속도가 함께 보장됩니다.
핵심 포인트: 가상 IP는 로컬 커널 안에서만 "임시로 존재"할 뿐, 실제로 공인망에 나가지도 않고 다른 기기가 인식하지도 못합니다. 유일한 역할은 도메인과 규칙 엔진 사이의 중간 토큰 역할을 하는 것입니다.
Fake-IP와 Redir-Host: 두 도메인 보존 방식의 차이
Clash의 DNS 강화 모드에는 Fake-IP 외에도 더 이전 방식인 Redir-Host가 있습니다. 둘의 목표는 같습니다—도메인 정보를 규칙 매칭 단계까지 가져오는 것—하지만 구현 방식이 다르고, 그 차이가 어느 것을 선택해야 하는지에 직접 영향을 줍니다.
| 비교 항목 | Fake-IP | Redir-Host |
|---|---|---|
| DNS 조회 처리 | 조회를 가로채고 로컬에서 생성한 가상 IP를 반환 | 조회를 정상적으로 통과시켜 실제 IP를 받음 |
| 규칙 매칭 근거 | 매핑 테이블 역조회로 얻은 도메인 | SNI/Host 헤더 등 애플리케이션 계층 필드로 도메인 복원 |
| 호환성 위험 | HTTP/TLS가 아닌 프로토콜은 도메인 필드가 없어 오판 가능성 | 실제 IP에 의존하는 상황(예: IP 인증서 검증)에서 문제가 적음 |
| 도메인 없는 프로토콜 지원 | Host 정보가 없는 일부 프로토콜은 분기가 부정확할 수 있음 | 실제 IP를 쓰므로 거의 영향받지 않음 |
| 현재 주류 권장 여부 | mihomo 기본 권장, 성능과 정확도가 균형적 | 점차 비주류화, 호환성 문제 대조용으로 주로 사용 |
간단히 말해 Fake-IP는 "일단 해석한 척하고 커널 매핑 테이블로 도메인을 복원"하는 방식으로 범용성과 속도가 뛰어나 현재 mihomo 커널의 기본 권장 방식입니다. Redir-Host는 "우직하게 실제 IP를 받고 프로토콜 헤더에서 도메인 필드를 뽑아내는" 방식으로, 안정성에서 강점이 있고 표준 TLS/HTTP를 쓰지 않는 일부 사설 프로토콜에서 문제가 덜 생기지만, 전체적으로는 더 이상 주류 선택이 아닙니다. 일상적으로는 Fake-IP를 그대로 사용하고, 특정 앱이 연결되지 않을 때만 개별적으로 원인을 찾으면 되며, 이 때문에 전체를 Redir-Host로 되돌릴 필요는 없습니다.
Fake-IP를 끄거나 예외를 추가해야 하는 상황
Fake-IP는 만능 스위치가 아닙니다. "모든 도메인 조회에 일단 가상 주소를 줄 수 있다"는 전제를 두고 있지만, 일부 상황은 정반대로 "반드시 실제 IP를 받아야" 동작합니다. 이런 경우에는 Fake-IP를 끄거나 해당 도메인을 예외 목록(보통 설정 항목은 fake-ip-filter)에 추가해야 합니다.
- 로컬 네트워크 서비스 검색: NAS, 프린터, 스마트홈 기기, 로컬 공유 디스크 등은 도메인이
192.168.x.x나*.local같은 내부망 주소로 해석되는 경우가 많습니다. 이런 도메인이 가상 IP 로직에 끌려 들어가면 연결이 프록시 경로로 잘못 보내져 실패하므로,*.local과 내부 기기의 커스텀 도메인은fake-ip-filter에 등록하는 것이 좋습니다. - 게임 온라인 연결과 로컬 검색 프로토콜: 많은 게임의 로비나 음성 서비스는 직접 연결이나 P2P 채널을 만들기 위해 실제 공인 IP를 필요로 합니다. 가상 IP는 "실제 주소를 봐야" 성립하는 핸드셰이크 로직을 깨뜨리므로, 게임 관련 도메인을 Fake-IP 대상에서 전부 제외하거나 게임 프로세스를 직결 규칙에 넣는 방법이 흔히 쓰입니다.
- 요청 IP를 직접 검증하는 일부 클라이언트: 소수의 사내 네트워크 도구나 일부 결제·금융 앱은 애플리케이션 계층에서 요청자 IP가 예상 범위 안에 있는지 검증합니다. 가상 IP는 이 검증을 실패시키므로, 해당 도메인만 따로 직결하거나 예외 목록에 넣어야 합니다.
- mDNS/멀티캐스트 검색에 의존하는 기기: 애플 생태계의 AirPlay, AirDrop 등은 멀티캐스트 브로드캐스트로 기기를 찾기 때문에 DNS 해석 경로와는 다르며 이론적으로는 Fake-IP의 영향을 받지 않습니다. 다만 이상이 보인다면 먼저 TUN 모드의 라우팅 가로채기 범위를 확인하고, 곧바로 Fake-IP를 끄는 쪽으로 가지 않는 것이 좋습니다.
주의: TUN 모드를 켜면 Fake-IP 대역이 시스템에서 실제 라우팅처럼 처리되는데, 이 대역이 기존 내부망 대역(예: 회사 VPN이 할당한 사설 대역)과 충돌하면 내부망 접속이 갑자기 안 되는 문제가 생길 수 있습니다. 이런 상황에서는 프록시 소프트웨어 결함으로 단정하기 전에 먼저 fake-ip-range가 기존 네트워크 환경과 충돌하는지 확인하세요.
설정 및 점검 가이드
Fake-IP 관련 설정을 손대기 전에 어느 계층이 문제인지부터 분명히 하는 것이 좋습니다. DNS 계층의 매핑 테이블인지, TUN 계층의 라우팅 가로채기인지 구분해서 점검하면 훨씬 효율적입니다.
- 클라이언트 DNS 설정에서
enhanced-mode가fake-ip인지 확인하세요.redir-host로 표시된다면 다른 논리로 동작하고 있는 것이므로, 앞서 다룬 비교 내용을 반대로 대입해서 봐야 합니다. fake-ip-range가 사용하는 대역이 현재 기기의 기존 네트워크(VPN, 가상 머신 네트워크 카드 포함)와 겹치는지 확인하세요. 대역 겹침은 내부망 접속 이상의 흔한 원인입니다.- 실제 IP가 꼭 필요한 도메인(내부망 서비스, 게임 로비, 멀티캐스트 기기)은 하나씩
fake-ip-filter에 추가하세요. 편하다는 이유로 Fake-IP를 전체적으로 꺼버리면 앞서 언급한 매칭 가속과 유출 방지 효과까지 함께 잃게 됩니다. - 특정 연결 이상이 Fake-IP와 관련 있다고 의심될 때는 먼저 클라이언트 로그 화면에서 해당 연결이 실제로 어떤 규칙과 목적지에 매칭되는지 확인해, 해석 단계 문제인지 규칙 자체가 잘못 작성된 것인지를 구분하세요.
- 설정을 바꾼 뒤에는 노드만 재연결하지 말고 프록시 커널을 재시작하세요. DNS 매핑 테이블과 라우팅 테이블은 보통 커널이 시작될 때 만들어지므로, 노드만 바꿔서는 다시 생성되지 않습니다.
정리하면, Fake-IP는 도메인 해석 단계를 "뒤로 미루고" "숨기는" 엔지니어링 기법으로, 목적은 규칙 매칭을 더 정확하게 하고 DNS 조회를 더 은밀하게 만드는 것입니다. 대부분의 사용 환경에서는 기본값 그대로 켜두면 충분합니다. 정말 신경 써야 할 부분은 실제 IP 의미에 의존하는 소수의 서비스이며, 이런 서비스만 골라 예외로 처리하면 되지, 일부 앱이 연결되지 않는다고 해서 전체 메커니즘을 꺼버릴 필요는 없습니다.