Fake-IP는 Clash와 mihomo에서 널리 사용하는 향상된 DNS 처리 방식입니다. 도메인 조회 결과를 대상 서버의 공인 IP 주소로 바로 바꾸는 대신, 전용 주소 범위에서 가상 주소를 할당하고 코어에 ‘도메인—가상 주소’ 매핑을 저장합니다. 이후 애플리케이션이 이 가상 주소에 연결하면 Clash가 매핑을 바탕으로 도메인을 복원한 뒤 도메인 규칙, 정책 그룹 선택, 원격 DNS 확인을 차례로 처리합니다.
이 방식의 핵심은 대상 웹사이트를 바꾸는 것이 아니라 트래픽 진입점에 정확한 도메인 정보를 유지하는 데 있습니다. TUN 가상 네트워크 어댑터가 가로채거나 운영체제에 IP 연결만 제출하는 프로그램의 경우, Fake-IP는 앞서 수행한 DNS 조회의 도메인을 연결에 다시 연결할 수 있습니다. 따라서 규칙 엔진이 DOMAIN, DOMAIN-SUFFIX, 규칙 세트 같은 도메인 규칙을 더 쉽게 적용하고, 로컬 DNS 결과와 프록시 출구에서 실제로 접속하는 결과가 서로 달라지는 문제도 줄일 수 있습니다.
Fake-IP의 DNS 매핑 과정
일반적인 접속은 DNS 조회와 연결 수립이라는 두 단계로 나눌 수 있습니다. 이 두 단계를 이해해야 문제가 도메인 확인, 트래픽 가로채기, 규칙 매칭, 프록시 출구 중 어디에서 발생했는지 판단할 수 있습니다.
- 애플리케이션이 시스템 DNS에 도메인 조회를 요청합니다. 예를 들어 특정 서비스의 A 레코드나 AAAA 레코드를 요청할 수 있습니다.
- 시스템 조회 요청은 Clash의 DNS 모듈로 전달됩니다. TUN을 사용할 때는 일반적으로
dns-hijack를 통해 지정된 포트의 DNS 요청을 수신합니다. 다른 라우팅 방식을 사용할 때는 운영체제의 DNS 설정이 로컬 리스닝 주소를 직접 가리킬 수도 있습니다. - Fake-IP 모듈은 도메인에 가상 주소를 할당하고 매핑 관계를 기록합니다. 주소 풀은 보통 벤치마크 용도로 예약된 네트워크 대역에 있으며, 실제 범위는
fake-ip-range로 결정됩니다. - 애플리케이션은 가상 주소를 받은 뒤 TCP 또는 UDP 연결을 시작합니다. 이 연결은 계속 Clash로 들어가야 합니다. 트래픽이 Clash를 우회하면 가상 주소만으로는 공인 인터넷에 직접 연결할 수 없습니다.
- Clash는 대상 가상 주소를 기준으로 원래 도메인을 조회하고, 도메인을 규칙 엔진에 전달한 뒤 직접 연결, 프록시, 거부 또는 지정된 정책 그룹을 선택합니다.
- 실제 연결을 수립해야 할 때 Clash는 설정에 따라 업스트림 DNS, 프록시 측 DNS 확인 또는 대상 프로토콜에 필요한 방식으로 실제 주소를 확인합니다.
따라서 Fake-IP는 독립적인 프록시 모드가 아닙니다. DNS 요청과 이후 연결이 모두 동일한 Clash 인스턴스로 들어와야 작동합니다. DNS 조회는 Clash로 들어오지만 연결이 TUN을 우회하거나, 연결은 Clash로 들어오지만 DNS 조회를 다른 프로그램이 가로채면 매핑 경로가 끊깁니다. 문제를 점검할 때는 ‘DNS가 Clash를 거치는가’와 ‘대상 연결이 Clash를 거치는가’를 나누어 확인해야 합니다.
도메인 규칙 매칭은 일반적으로 매핑을 복원한 뒤 이루어집니다. 예를 들어 규칙에 특정 도메인 접미사가 있으면 Clash는 복원된 호스트 이름으로 바로 판단할 수 있으므로, 먼저 일반 공인 IP로 처리해 IP 규칙에 넘길 필요가 없습니다. IP 주소를 직접 입력한 연결은 사전에 도메인을 조회하지 않으므로 Fake-IP 매핑도 없습니다. 이런 연결은 IP, 포트 및 기타 사용 가능한 정보에 따라 계속 처리됩니다.
mihomo의 기본 설정과 필드 관계
클라이언트마다 그래픽 스위치로 설정을 생성하거나 구독 덮어쓰기를 통해 DNS 섹션을 기록할 수 있습니다. 최종적으로는 클라이언트가 실제로 불러온 설정을 기준으로 판단해야 합니다. 다음은 필드 간 관계를 이해하기 위한 간소화된 예시이며, 리스닝 주소·업스트림 DNS·주소 풀은 기기 환경에 맞게 조정해야 합니다.
dns:
enable: true
listen: 0.0.0.0:1053
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "time.*.com"
nameserver:
- 1.1.1.1
- 8.8.8.8
tun:
enable: true
stack: mixed
dns-hijack:
- any:53enhanced-mode: fake-ip는 Fake-IP 향상 모드를 선택합니다. fake-ip-range는 가상 주소 풀을 정의하고, fake-ip-filter는 가상 주소를 반환하면 안 되는 도메인을 지정합니다. 필터 항목과 일치하면 DNS 모듈은 해당 도메인에 Fake-IP 매핑을 만들지 않고 실제 DNS 확인 결과를 반환합니다.
dns-hijack와 Fake-IP의 역할은 서로 다릅니다. 전자는 기기의 DNS 요청이 Clash로 들어오게 하고, 후자는 들어온 요청에 어떤 방식으로 응답할지 결정합니다. Fake-IP만 켜고 조회 요청이 Clash에 도달하도록 설정하지 않으면 우회된 DNS 요청에는 적용되지 않습니다. 반대로 DNS 하이재킹만 설정하고 일반 DNS 확인 모드를 사용하면 가상 주소 매핑이 생성되지 않습니다.
mihomo에서 Fake-IP 매핑은 기본적으로 실행 중인 연결을 연관시키는 데 사용됩니다. 일부 설정은 profile에서 Fake-IP 데이터 영속화를 활성화하여 코어를 재시작한 뒤에도 저장된 매핑을 계속 사용할 수 있습니다. 영속화가 필요한지는 클라이언트의 설정 관리 방식에 따라 달라집니다. 주소 풀을 변경했거나 기존 매핑이 비정상적이거나 설정을 전환한 뒤 동작이 일관되지 않다면 코어를 종료하고 클라이언트가 제공하는 DNS/Fake-IP 캐시를 삭제한 다음 설정을 다시 불러올 수 있습니다.
Fake-IP를 사용하기 적합한 환경
데스크톱 기기의 TUN 전체 트래픽 라우팅
TUN은 가상 네트워크 인터페이스를 만들어 시스템 HTTP 프록시 설정을 따르지 않는 TCP·UDP 및 일부 시스템 서비스 트래픽을 수신합니다. 많은 프로그램은 연결을 만들 때 네트워크 스택에 이미 확인된 IP만 전달하므로, 규칙 엔진이 연결 자체에서 도메인을 얻지 못할 수 있습니다. Fake-IP는 앞선 DNS 조회를 통해 도메인 정보를 보완하므로 TUN과 직접적으로 함께 사용하기 좋습니다.
브라우저, 명령줄 도구, 게임 플랫폼과 백그라운드 업데이트 서비스는 서로 다른 네트워크 인터페이스와 프록시 방식을 사용할 수 있습니다. DNS 조회와 연결을 모두 TUN을 통해 통일하면 한 프로그램은 시스템 프록시를 따르고 다른 프로그램은 우회하면서 트래픽 분기가 달라지는 문제를 줄일 수 있습니다. 사용 후에도 라우팅 테이블, DNS 하이재킹 및 클라이언트 로그를 확인하여 브라우저 트래픽만 적용된 것은 아닌지 점검해야 합니다.
도메인 규칙에 의존하는 대규모 규칙 세트
구독 설정에는 많은 도메인 접미사, 도메인 키워드와 규칙 세트가 포함되는 경우가 많습니다. Fake-IP를 사용하면 코어가 연결 시점에 조회 도메인을 복원하고 해당 규칙을 우선 적용할 수 있습니다. 도메인 규칙은 서버 IP만으로 판단하는 것보다 안정적입니다. 같은 서비스가 CDN, 동적 라우팅 또는 공유 주소를 사용할 수 있고, 하나의 공인 IP가 전혀 다른 여러 도메인을 호스팅할 수도 있기 때문입니다.
특정 규칙으로 LAN 서비스를 직접 연결하거나 공개 사이트를 프록시로 보내거나 특정 도메인을 거부하려는 경우 Fake-IP는 규칙 대상을 더 명확하게 만들어 줍니다. 다만 규칙 순서는 여전히 적용됩니다. 범위가 넓은 규칙을 앞에 두면 뒤에 있는 정확한 도메인 규칙이 계속 덮어써질 수 있습니다. Fake-IP는 매칭 정보를 제공할 뿐 규칙 우선순위를 자동으로 수정하지 않습니다.
로컬 DNS 차이를 줄이고 싶은 프록시 연결
일반 DNS 모드에서는 대개 로컬에서 실제 IP를 먼저 확인한 다음 규칙 엔진이 도메인 또는 IP를 기준으로 판단합니다. 프록시 출구와 로컬 네트워크에서 확인되는 CDN 주소가 다르면 우회 경로가 선택되거나 연결 결과가 일치하지 않을 수 있습니다. Fake-IP는 실제 대상 주소의 결정을 늦추고 코어가 정책과 업스트림 설정에 따라 DNS 확인 경로를 선택하도록 하므로, 도메인 기반 분기와 프록시 측 후속 연결이 필요한 환경에 적합합니다.
LAN·게임·특수 도메인에서 자주 발생하는 문제
LAN 호스트 이름과 기기 검색
프린터, NAS, TV 화면 공유 및 라우터 관리 페이지는 .local, .lan 또는 제조사 고유의 호스트 이름을 자주 사용합니다. 일부 이름은 mDNS, LLMNR, 라우터의 로컬 DNS 서비스 또는 검색 도메인으로 확인되며 공용 업스트림 DNS에 맡기기 적합하지 않습니다. 이런 이름에 Fake-IP가 할당되면 애플리케이션이 같은 네트워크 대역의 기기를 찾지 못하거나, 원래 직접 연결해야 하는 관리 요청이 프록시 규칙으로 전달될 수 있습니다.
먼저 해당 이름이 어떤 프로토콜로 확인되는지 파악한 다음 정확한 제외 항목을 추가해야 합니다. 고정된 기기라면 DHCP 호스트 이름 확인을 우선 유지하거나 명확한 LAN 도메인 접미사를 사용할 수 있습니다. 로컬 확인이 필요한 접미사만 fake-ip-filter에 추가하고, LAN IP 대역에는 직접 연결 규칙이 있는지 확인하세요. 도메인만 제외하고 직접 연결 라우팅을 설정하지 않으면 연결 단계에서 잘못된 정책이 선택될 수 있습니다.
게임 로그인·음성 채팅·UDP 세션
일부 게임은 계정 로그인 도메인, 콘텐츠 다운로드 도메인, 대전 서버 IP, 음성 UDP 및 NAT 탐색 서비스를 동시에 사용합니다. 로그인 웹페이지가 정상이라고 해서 전체 게임 경로가 정상인 것은 아닙니다. 런처가 도메인을 조회한 뒤 결과를 별도 프로세스에 전달하고 후속 프로세스가 동일한 TUN으로 가로채지지 않으면 가상 주소가 연결에 필요한 전달 경로를 잃을 수 있습니다.
로그인 반복, 지역 서버 목록 공백 또는 음성 연결 실패가 발생하면 먼저 코어 로그에 해당 UDP/TCP 연결이 표시되는지 확인한 다음 프로세스가 TUN에 들어갔는지 점검해야 합니다. 로그에서 특정 도메인이 Fake-IP와 맞지 않는다는 사실이 확인된 경우에만 해당 도메인을 필터 목록에 추가하세요. 게임은 보통 여러 서비스 도메인을 사용하므로 최상위 도메인 전체를 제외하거나 Fake-IP를 전부 끄면 기존 도메인 분기가 쉽게 무너질 수 있습니다.
시간 동기화·네트워크 감지·강제 포털
시스템 시간 동기화, 네트워크 연결 상태 확인, 학교나 호텔의 로그인 포털은 실제 DNS 결과를 요구하거나 프록시 코어가 시작되기 전에 접속해야 할 수 있습니다. 이런 요청에 가상 주소가 반환되지만 연결이 아직 Clash로 들어오지 않으면 시스템이 오프라인으로 잘못 판단할 수 있습니다. 시간 동기화 도메인, 운영체제 네트워크 감지 도메인 및 포털 인증 도메인은 제외 규칙의 일반적인 후보입니다.
제외 항목은 실제 로그와 캡처 결과를 바탕으로 정해야 하며, 긴 범용 목록을 그대로 복사해서는 안 됩니다. 운영체제 버전, 지역과 네트워크 환경에 따라 감지 도메인도 달라집니다. 먼저 문제를 재현하고 조회 도메인을 기록한 뒤 최소 범위의 규칙을 추가하면 일반 업무 트래픽까지 실제 IP로 되돌리는 일을 피할 수 있습니다.
IP 주소를 설정에 기록하거나 다른 기기에서 재사용하는 경우
일부 프로그램은 DNS 결과를 장기간 캐시하거나 확인한 주소를 설정 파일에 기록하기도 합니다. Fake-IP는 매핑을 보유한 Clash 인스턴스 안에서만 유효하므로 이 주소를 다른 기기로 복사해도 의미가 없습니다. 게이트웨이 우회 환경에서도 주의해야 합니다. 보조 라우터 A가 가상 주소를 반환했지만 실제 연결이 게이트웨이 B를 통과하면 게이트웨이 B는 해당 가상 주소가 어떤 도메인에 대응하는지 알 수 없습니다.
동일한 LAN에서 여러 기기에 Fake-IP DNS를 제공한다면 이후 트래픽이 같은 코어 인스턴스를 안정적으로 통과하고 가상 주소 풀의 라우팅도 해당 인스턴스를 가리키도록 해야 합니다. 그렇지 않다면 실제 주소를 반환하는 DNS 모드를 사용하거나 로컬 클라이언트에서만 Fake-IP를 사용하는 편이 적합합니다.
Fake-IP 제외 규칙 작성 방법
제외 규칙의 목적은 호환되지 않는 소수의 도메인에 실제 주소를 반환하는 것이지, 모든 서비스를 포괄하는 예외 목록을 만드는 것이 아닙니다. ‘정확한 도메인, 제한된 와일드카드, 접미사 범위’ 순서로 범위를 단계적으로 넓히세요.
| 규칙 유형 | 적용 상황 | 주의 사항 |
|---|---|---|
host.example.com |
문제가 특정 호스트 이름 하나로 확인된 경우 | 영향 범위가 가장 작으므로 우선 사용 |
*.example.com |
같은 서비스의 여러 하위 도메인에 실제 주소가 필요한 경우 | 와일드카드 의미가 현재 코어 버전과 일치하는지 확인 |
*.local |
LAN 기기 검색 및 로컬 이름 확인 | mDNS 또는 로컬 DNS 경로를 계속 유지해야 하는 경우 |
time.*.com |
고정된 명명 패턴을 사용하는 시간 서비스 | 너무 넓은 와일드카드로 일반 사이트까지 포함하지 않기 |
mihomo의 구체적인 매칭 기능은 버전과 설정 형식에 따라 달라질 수 있으며, 클라이언트가 구독과 덮어쓰기를 병합하는 과정에서 필드를 변경할 수도 있습니다. 수정 후에는 클라이언트의 최종 설정 화면을 열어 fake-ip-filter가 구독 업데이트로 덮어써지지 않았는지 확인하고, 코어 시작 로그에서 필드 오류가 보고되지 않는지도 살펴보세요.
일부 최신 mihomo 설정은 Fake-IP 필터에 블랙리스트 또는 화이트리스트 방식을 지정할 수 있습니다. 블랙리스트 방식은 목록에 포함된 도메인에 실제 DNS 확인을 사용하고 나머지 도메인에는 Fake-IP를 사용합니다. 화이트리스트 방식은 반대로 목록과 일치하는 도메인에만 Fake-IP를 사용합니다. 일반적인 데스크톱 환경에서는 소수의 제외 항목부터 시작하는 편이 더 적합합니다. 화이트리스트를 사용한다면 목록과 일치하지 않는 많은 도메인에 실제 주소를 반환하는 것이 의도한 설계인지, 필드 의미를 반대로 이해한 것은 아닌지 확인해야 합니다.
Fake-IP 문제 점검 순서
- 설정이 로드되었는지 확인합니다. 클라이언트의 실행 설정에서 DNS가 활성화되어 있고 향상 모드가 Fake-IP인지 확인한 뒤 코어 시작 로그를 점검하세요. 구독 파일, 덮어쓰기 파일과 클라이언트 스위치가 DNS 섹션을 동시에 수정할 수 있습니다.
- DNS 조회가 코어로 들어오는지 확인합니다. 연결 로그 또는 DNS 로그를 확인하여 대상 도메인이 표시되는지 살펴보세요. 시스템에서 암호화 DNS, 브라우저의 독립 DNS 또는 다른 DNS 도구를 사용한다면 로컬 리스닝을 우회하고 있지 않은지 확인해야 합니다.
- 가상 주소가 설정한 주소 풀에 속하는지 확인합니다. 조회 결과는
fake-ip-range안에 있어야 합니다. 여전히 일반 공인 IP가 반환된다면 필터 항목과 일치했거나 조회가 Clash를 거치지 않았을 수 있습니다. - 후속 연결도 가로채졌는지 확인합니다. 애플리케이션이 가상 주소를 받은 뒤 로그에 해당 연결이 표시되어야 합니다. 연결 기록이 전혀 없다면 우선 TUN 권한, 시스템 라우팅과 애플리케이션의 우회 설정을 확인하세요.
- 매핑으로 도메인을 복원할 수 있는지 확인합니다. 연결 로그에는 원래 도메인 또는 일치한 도메인 규칙이 표시되어야 합니다. 가상 IP만 표시된다면 DNS 및 Fake-IP 캐시를 삭제하고 조회와 연결을 같은 코어가 처리하는지 확인하세요.
- 규칙 순서와 정책 그룹을 확인합니다. 도메인은 복원되었지만 출구가 잘못된 경우 문제는 대개 Fake-IP 자체가 아니라 규칙 우선순위, 규칙 세트 업데이트 또는 정책 그룹 선택에 있습니다.
- 마지막으로 제외 항목을 추가합니다. 대상 서비스가 실제 DNS 결과를 반드시 요구한다는 사실을 확인한 뒤에만 정확한 도메인을 필터 목록에 추가하세요.
DNS 설정을 변경한 뒤에도 브라우저, 운영체제와 애플리케이션이 기존 캐시를 계속 사용할 수 있습니다. 먼저 Clash 설정을 다시 불러온 다음 시스템 DNS 캐시를 삭제하고 관련 애플리케이션을 완전히 종료하세요. 클라이언트에 ‘DNS 캐시 삭제’ 또는 ‘Fake-IP 캐시 새로 고침’ 기능이 있다면 관련 연결을 중지한 후 실행할 수 있습니다. 여러 코어 인스턴스를 자주 전환한다면 시스템 DNS와 기본 라우팅이 현재 인스턴스를 가리키는지도 확인해야 합니다.
Fake-IP와 Redir-Host 선택하기
Fake-IP는 가상 주소를 통해 도메인 매핑을 유지하는 방식으로, TUN 라우팅을 사용하고 도메인 규칙이 많으며 DNS와 연결 경로를 통일해 제어할 수 있는 기기에 적합합니다. Redir-Host처럼 실제 주소를 반환하는 방식은 일반 DNS 동작에 가깝고, 실제 주소가 필요한 LAN 서비스·여러 기기에서 공유하는 DNS·일부 특수 애플리케이션과의 호환성이 더 좋을 수 있습니다. 다만 도메인 연관과 확인 경로는 클라이언트 구현 및 연결 유형의 영향을 받습니다.
선택할 때 특정 웹페이지가 열리는지만 비교하지 마세요. 브라우저, 시스템 업데이트, LAN 기기, 게임 UDP, 절전 모드 복귀와 네트워크 전환을 함께 확인해야 합니다. 단일 데스크톱 기기라면 먼저 Fake-IP를 사용한 뒤 명확한 문제에 대해서만 소규모 필터를 추가할 수 있습니다. 라우터가 여러 기기에 서비스를 통합 제공한다면 먼저 DNS 요청과 반환 트래픽 경로를 설계하여 가상 주소가 항상 같은 인스턴스로 돌아오도록 해야 합니다.
최종 판단 기준은 연결 경로가 완전한지 여부입니다. DNS 조회가 Clash로 들어오고, 가상 주소가 현재 코어에서 할당되며, 후속 연결이 다시 같은 코어로 들어오고, 도메인 규칙이 올바르게 적용되며, 정책 그룹이 실제 연결을 수립해야 합니다. 이 순서대로 로그를 확인하면 Fake-IP 문제를 전체 DNS 설정을 반복해서 바꾸지 않고도 구체적인 단계로 좁혀낼 수 있습니다.