Fake-IP 모드 동작 원리:DNS 매핑 풀, 우회 흐름, 적용 시나리오

DNS 해석이 프록시 체인에서 차지하는 위치

모든 네트워크 접속은 도메인 해석에서 시작합니다. 애플리케이션은 먼저 시스템이나 클라이언트에 내장된 DNS 모듈에게 특정 도메인이 어떤 IP에 대응하는지 물어본 뒤, 그 답을 받아 TCP나 UDP 연결을 시작합니다. 프록시 소프트웨어가 개입하지 않은 상태라면 이 IP는 실제 주소이며 라우팅과 트래픽 분리에 곧바로 사용할 수 있는 정보입니다. 그러나 Clash / mihomo처럼 규칙 기반으로 트래픽을 분배하는 도구에게는 IP만 의존하는 방식이 골칫거리가 됩니다. 많은 도메인이 CDN을 사용하기 때문에 같은 사이트라도 시간과 지역에 따라 해석되는 IP가 완전히 달라지고, IP 대역을 고정해서 작성한 규칙은 금방 무용지물이 됩니다. 그래서 규칙 엔진은 계속 바뀌는 IP보다 도메인 자체를 받는 것을 더 선호합니다. 이것이 바로 DNS 모드 설계가 풀어야 하는 핵심 문제입니다—어떻게 "도메인 정보"를 연결 수립과 규칙 매칭의 모든 단계까지 전달할 것인가.

Clash의 DNS 모듈은 여러 동작 모드를 제공하며, 그중 가장 자주 논의되고 동시에 가장 오해받기 쉬운 것이 Fake-IP입니다. 이를 이해하려면 먼저 "DNS로 해석된 IP가 실제로 연결할 주소다"라는 기본 가정을 내려놓아야 합니다.

Fake-IP의 매핑 풀 메커니즘

Fake-IP 모드의 아이디어는 다음과 같습니다. 클라이언트가 로컬의 DNS 요청을 가로채고, 애플리케이션이 특정 도메인을 조회할 때 실제 상위 DNS 서버에 문의해서 진짜 IP를 받아오지 않고, 예약된 사설 대역(기본값 198.18.0.0/16)에서 순서대로 혹은 캐시 전략에 따라 아직 사용되지 않은 IP를 하나 골라 애플리케이션에 곧바로 돌려줍니다. 이 IP 자체는 어떤 실제 서버도 가리키지 않으며, 단지 하나의 "자리표시자"일 뿐입니다. 클라이언트는 내부적으로 매핑 테이블을 유지하면서 "이 가짜 IP가 어떤 도메인에 대응하는지"를 기록합니다.

전체 흐름은 세 단계로 나눌 수 있습니다:

1. 애플리케이션이 DNS 조회를 시작하면 이 요청은 TUN이나 시스템 DNS에 의해 Clash 내부의 DNS 서버 컴포넌트로 가로채집니다.
2. Clash가 매핑 풀을 확인해, 해당 도메인에 아직 Fake-IP가 배정되지 않았다면 사용되지 않은 주소를 하나 골라 "도메인 ↔ 가짜 IP"의 양방향 기록을 만들고 메모리 테이블에 기록합니다.
3. Clash가 이 가짜 IP를 DNS 응답으로 애플리케이션에 돌려주고, 애플리케이션은 이 IP로 연결을 시작합니다.

핵심은 세 번째 단계 이후입니다. 애플리케이션이 가짜 IP로 연결을 시작하면 이 연결은 TUN 네트워크 인터페이스나 시스템 프록시를 거쳐 Clash의 전달 엔진으로 들어갑니다. 이때 Clash는 실제로 198.18.x.x 이 주소로 패킷을 보내지 않고, 먼저 매핑 테이블을 조회해 가짜 IP를 도메인으로 역추적한 뒤, 실제 도메인을 얻으면 프록시 규칙에 따라 어느 프록시 그룹으로 보낼지 결정하고, 실제 도메인에 대해 다시 실제 DNS 해석을 수행하거나(또는 SNI/HTTP Host를 지원하는 하위 프록시에 도메인을 그대로 넘겨) 처리합니다. 이 단계를 "연결 단계 복원"이라 부르며, Fake-IP가 정상 작동하는 핵심입니다—도메인 정보는 전체 과정에서 계속 보존되고, 가짜 IP는 임시 매개체일 뿐 실제 네트워크 전송에는 참여하지 않습니다.

규칙 매칭이 더 정확해지는 이유

Fake-IP는 "도메인"이 연결 수립 단계까지 계속 전달되도록 해주기 때문에, 규칙 엔진이 DOMAIN-SUFFIX, DOMAIN-KEYWORD, RULE-SET 같은 도메인 기반 매칭을 수행할 때 언제나 신뢰할 수 있는 원본 도메인을 받게 되며, 언제든 바뀔 수 있는 CDN 출구 IP를 받지 않습니다. 이는 CDN이 밀집된 시나리오에서 특히 중요합니다—같은 도메인이 오늘은 A 레코드로 해석되고 내일은 전혀 다른 IP 무리로 해석될 수 있는데, 규칙을 IP 대역으로 작성하면 "어제는 맞았는데 오늘은 안 맞는" 상황이 쉽게 발생합니다. 도메인은 상대적으로 훨씬 안정적이며, 도메인 기반 규칙 세트는 현재 mihomo 생태계에서 가장 자주 업데이트되고 가장 넓게 커버되는 형태입니다.

또한 Fake-IP 모드에서는 클라이언트가 프록시 여부를 판단하기 위해 매번 시스템 차원에서 실제 DNS 조회를 발생시킬 필요가 없습니다—가짜 IP 배정과 규칙 매칭이 로컬 메모리 안에서 완료될 수 있어 네트워크 왕복 한 번을 줄일 수 있으며, 이는 많은 사용자가 Fake-IP를 켠 후 페이지 로딩 속도가 약간 향상됐다고 느끼는 이유 중 하나입니다.

Fake-IP와 Redir-Host의 차이

Fake-IP가 등장하기 전에 흔히 쓰인 또 다른 방식이 Redir-Host입니다. 클라이언트가 DNS 요청을 가로챈 뒤 가짜 주소를 돌려주지 않고 실제 상위 DNS 서버에 그대로 조회해서 진짜 IP를 받아 애플리케이션에 그대로 돌려줍니다. 규칙 매칭 단계는 클라이언트가 DNS 조회 시점에 "어떤 도메인이 어떤 IP에 대응하는지"를 기록해 두고, 이후 연결 단계에서 이 기록을 이용해 도메인을 역추적하는 방식에 의존합니다. 표면적으로는 둘 다 "도메인이 규칙 매칭에 참여한다"는 목표를 이루지만, 세부 동작과 적용 범위는 서로 다릅니다.

간단히 말해 Fake-IP는 속도와 규칙 정확도 면에서 더 유리해 현재 TUN 모드의 기본 선택으로 쓰이며, Redir-Host는 애플리케이션이 항상 실제 IP를 받는다는 특성 때문에 IP 통신에 직접 의존하고 도메인 해석 관행을 따르지 않는 일부 시나리오에서 더 안정적인 호환성을 보이지만, 전체적으로는 Fake-IP에 화이트리스트 제외를 더한 조합 방식으로 점차 대체되고 있습니다.

fake-ip-filter로 제외해야 하는 시나리오

가짜 IP는 어디까지나 "Clash 내부에서만 쓰이는 자리표시자"이므로, 특정 애플리케이션이 Clash의 연결 가로채기 로직을 거치지 않고 이 IP를 실제 주소처럼 그대로 사용하면 문제가 생깁니다. 다음과 같은 몇 가지 대표적인 시나리오에서는 fake-ip-filter를 명시적으로 설정해 해당 도메인을 Fake-IP 배정 대상에서 제외하고 실제 DNS 해석을 거치게 해야 합니다:

• 로컬 네트워크 내부 서비스와 라우터 관리 페이지——*.lan, router.asus.com 같이 로컬 네트워크 기기를 가리키는 도메인은 가짜 IP가 배정되면 브라우저가 존재하지 않는 주소로 연결을 시도해 관리 페이지가 열리지 않게 됩니다.
• 정확한 실제 IP를 얻어야 하는 애플리케이션——일부 클라우드 스토리지 클라이언트, 스트리밍 송출 도구, P2P 애플리케이션은 애플리케이션 계층에서 DNS가 반환한 IP를 직접 읽어 표시하거나 P2P 연결을 수립하는데, 가짜 IP는 이런 용도에는 의미가 없습니다.
• 사내망과 VPN 환경의 사설 도메인——회사 내부 시스템 도메인은 대체로 사설 대역으로 해석되므로, 이런 도메인도 제외 목록에 넣어야 프록시 로직과의 충돌을 피할 수 있습니다.
• Fake-IP와 호환 문제가 알려진 클라이언트 컴포넌트——예를 들어 일부 시스템 기본 네트워크 검사, 연결 상태 확인 서비스는 공식 문서나 커뮘니티가 관리하는 규칙 세트를 따라 일괄 제외하는 것이 개별로 하나씩 추가하는 것보다 낫습니다.

실무에서는 이 제외 목록을 처음부터 직접 작성할 필요가 없습니다. 주요 규칙 세트 저장소에는 이미 상당히 완성도 높은 fake-ip-filter 추천 목록이 관리되어 있고, 클라이언트도 기본 설정을 생성하거나 규칙 구독을 사용할 때 기본 버전을 함께 제공하므로, 특정 애플리케이션이 열리지 않는 경우에만 필요한 만큼 추가하면 됩니다.

언제 켜고 언제 끌지

Fake-IP 모드의 기본 사용 권장은 다음과 같습니다:

• TUN 모드에서는 켜두는 것을 권장합니다. TUN 모드는 전체 네트워크 스택을 인수하기 때문에 규칙 엔진과 맞물려 작동할 효율적이고 정확한 도메인 복원 메커니즘이 필요하며, Fake-IP는 바로 이런 시나리오를 위해 설계된 것으로 대부분 클라이언트에서 TUN 모드의 기본 DNS 유형으로 채택되어 있습니다.
• 순수 시스템 프록시 모드(HTTP/SOCKS)에서는 상황에 따라 선택할 수 있습니다. 브라우저처럼 시스템 프록시 설정을 지원하는 애플리케이션만 Clash를 거치게 한다면, Redir-Host나 상위 DNS로의 직접 조회도 대체 방안으로 충분하며, 차이는 주로 규칙 매칭의 정밀도에서 나타납니다.
• 로컬 기기나 사내 시스템 접속에 문제가 생기면 먼저 fake-ip-filter를 확인하고, Fake-IP 전체를 끄지는 마세요. "프록시를 켰더니 로컬 기기가 안 잡힌다"는 문제는 대부분 제외 목록이 해당 도메인을 커버하지 못한 것이 원인이므로, 규칙을 대상에 맞춰 추가하는 쪽이 전체 메커니즘을 포기하는 것보다 이득입니다.
• 정확한 IP에 크게 의존하는 소수 애플리케이션은 직접 연결이나 도메인 제외로 개별 처리하세요. 일부 애플리케이션의 특수한 요구 때문에 전역 Fake-IP를 끌 필요는 없으며, 규칙 기반 트래픽 분리 자체가 도메인이나 프로세스 단위의 예외 처리를 지원합니다.

전체적으로 Fake-IP는 "켤지 말지"를 고르는 단순한 이분법 스위치가 아니라 제외 목록과 함께 유지 관리해야 하는 동적 메커니즘입니다. 규칙 세트 커뮤니티는 제외가 필요한 도메인을 계속 업데이트하고 있고, 클라이언트도 가짜 IP 풀의 배정과 회수 전략을 꾸준히 개선하고 있습니다. 동작 원리를 이해하고 나면 구체적인 문제가 생겼을 때 어느 방향으로 점검해야 할지 빠르게 판단할 수 있으며, 전체 DNS 모드를 분해 불가능한 블랙박스로 취급하지 않게 됩니다.