Clash Fake-IP 모드 설정과 원리: DNS 매핑 및 redir-host 비교
Clash Fake-IP가 예약 주소 대역으로 도메인을 매핑하는 원리, redir-host와의 차이, fake-ip-filter 설정법과 사용하기 어려운 환경을 정리합니다.
Fake-IP 작동 원리: 매핑 주소를 먼저 반환한 뒤 도메인에 따라 연결 처리
Fake-IP를 켠 상태에서 웹사이트 도메인을 조회했을 때 198.18.x.x가 표시되는 것은 일반적으로 정상입니다. 웹사이트가 실제로 해당 주소로 이전한 것은 아닙니다. Clash DNS 모듈은 지정된 주소 풀에서 합성 IPv4 주소를 할당하고, 내부에 도메인과 합성 주소의 매핑 정보를 저장합니다. 앱이 이 주소로 연결을 시작하면 코어가 연결을 가로채고, 매핑 정보를 이용해 원래 도메인을 찾아냅니다.
일반적인 처리 과정은 네 단계로 나눌 수 있습니다. enhanced-mode: fake-ip만 외우는 것보다 전체 흐름을 이해해야 문제를 더 쉽게 찾을 수 있습니다.
- 앱이
www.example.com의 A 레코드를 조회하면 요청이 코어의 DNS 서비스로 전달됩니다. - DNS 모듈은 주소 풀에서
198.18.0.2와 같은 주소를 할당하고 해당 주소에 대응하는 도메인을 기록합니다. 할당 결과는 고정되어 있지 않습니다. - 앱은 이 합성 주소의 TCP 443 포트로 연결을 시작하고, 트래픽은 TUN 또는 다른 투명 프록시 처리 방식을 통해 코어로 전달됩니다.
- 코어가 도메인을 복원한 뒤 규칙에 따라 아웃바운드를 선택합니다. 직접 연결 또는 프록시 아웃바운드는 각자의 방식으로 실제 주소를 조회하고 연결을 완료합니다.
Fake-IP를 사용하면 연결이 시작될 때 도메인 규칙이 도메인 정보를 바로 활용할 수 있어, 일부 환경에서는 로컬의 실제 DNS 조회 결과에 덜 의존하게 됩니다. 그렇다고 모든 연결에서 실제 DNS 조회가 필요 없어지는 것은 아닙니다. 직접 연결 대상, IP 정보가 필요한 규칙, 프록시 노드 도메인 조회에서는 여전히 DNS 요청이 발생할 수 있습니다. 또한 Fake-IP는 암호화 프로토콜이 아니므로 일반 DNS를 암호화 DNS로 자동 변환하지 않습니다.
Fake-IP와 redir-host의 차이: DNS 응답과 도메인 복원 방식
redir-host는 상위 DNS 서버에서 조회한 실제 주소를 반환하고, fake-ip는 해당하는 조회에 합성 주소를 반환합니다. 두 방식 모두 규칙 기반 트래픽 분기에 사용할 수 있지만 앱에 표시되는 주소와 코어가 도메인을 알아내는 방식은 서로 다릅니다.
| 비교 항목 | fake-ip | redir-host |
|---|---|---|
| 앱에 반환되는 A 레코드 | 일반적으로 주소 풀의 합성 IPv4 주소 | 상위 DNS 서버가 반환한 실제 IPv4 주소 |
| 도메인 연결 방식 | 합성 주소 매핑으로 도메인 복원 | DNS 캐시 연결 정보 등에 의존하며 필요에 따라 스니핑을 함께 사용 |
| 로컬 실제 DNS 조회 의존도 | 일부 프록시 연결은 실제 주소 조회를 미루거나 원격에서 처리 가능 | 앱에 응답하기 전에 실제 주소 조회가 필요한 경우가 일반적 |
| 일반적인 호환성 문제 | 주소를 검증하는 프로그램, 로컬 네트워크 기기 검색, 트래픽 미가로채기 | 여러 도메인이 같은 IP를 공유하면 도메인 연결이 모호해질 수 있음 |
| 우선 테스트하기 좋은 환경 | TUN이 안정적으로 작동하고 브라우저와 일반 네트워크 앱을 주로 사용하는 환경 | 앱이 실제 주소를 확인해야 하거나 현재 네트워크에서 합성 주소 트래픽을 가로채기 어려운 환경 |
두 모드를 고정된 속도 순위로 생각하지 마세요. 최초 DNS 조회 지연, 프록시 노드의 DNS 환경, 규칙에서 IP 조회가 발생하는지에 따라 연결 시간이 달라집니다. 비교하려면 같은 네트워크와 노드, 대상 사이트를 사용해 여러 번 테스트하세요. 웹페이지를 한 번 열어 본 결과만으로 어느 모드가 더 빠른지 판단하면 안 됩니다.
mihomo DNS 설정: 최소 구성과 적용 조건
아래는 mihomo에서 사용할 수 있는 DNS 설정 예시입니다. 노드와 규칙까지 포함한 전체 설정은 아닙니다. 예시에서는 독립적으로 확인할 수 있도록 DNS를 로컬의 127.0.0.1:1053에서 수신합니다. 일반적인 시스템 DNS 설정은 서버 주소만 입력받고 기본 포트로 53을 사용하므로, 1053 포트를 시스템 DNS 주소로 바로 지정할 수 없습니다.
dns:
enable: true
listen: 127.0.0.1:1053
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "localhost"
- "*.lan"
- "*.local"
nameserver:
- 223.5.5.5
- 1.1.1.1enable은 내장 DNS를 활성화합니다. DNS를 켜지 않고 모드만 설정하면 기대한 매핑 응답을 받을 수 없습니다.listen은 수신 주소와 포트를 지정합니다. 루프백 주소는 로컬 기기에서만 접속할 수 있으며, 로컬 네트워크 전체에 서비스를 제공하지 않습니다.ipv6: false는 이 예시에서 AAAA 조회 처리를 단순화하기 위한 설정입니다. 운영체제의 IPv6 네트워크 어댑터나 라우팅을 끄는 설정은 아닙니다.fake-ip-range는 합성 IPv4 주소 풀을 정의합니다. 기존 VPN, 테스트 네트워크, 라우팅 계획의 주소 대역과 겹치지 않는지 확인하세요.nameserver는 실제 주소 조회가 필요할 때 사용할 상위 DNS 서버를 지정합니다. 예시의 IP 주소는 일반 DNS 방식이므로 현재 네트워크에서 해당 서버에 접속할 수 있어야 합니다. 암호화 DNS는 별도로 설정해야 합니다.
설정을 적용하기 전에 확인할 세 가지
- 실행 중인 코어를 확인하세요. 클라이언트의 코어 정보와 시작 로그를 살펴보세요. Clash, Clash Meta, mihomo는 지원하는 설정 항목이 서로 완전히 같지 않습니다. 새 코어에서 지원하는 추가 항목을 구버전에 그대로 적용하면 안 됩니다.
- 실제로 적용되는 설정을 수정했는지 확인하세요. 구독 파일은 업데이트할 때 덮어쓰일 수 있습니다. 클라이언트의 오버라이드 또는 병합 기능을 우선 사용하고, 다시 불러온 뒤 최종 설정을 확인하세요.
- DNS와 연결이 모두 코어를 통과하는지 확인하세요. 1053 포트로 조회해 DNS 서비스가 작동하는 것을 확인했더라도, 합성 주소를 향하는 앱의 연결은 TUN 또는 다른 투명 전달 방식으로 가로채야 합니다.
fake-ip-filter: 실제 주소가 필요한 도메인만 제외
mihomo의 기본 블랙리스트 필터 방식에서는 fake-ip-filter에 해당하는 도메인에 Fake-IP를 반환하지 않고 실제 주소를 조회합니다. 이는 프록시 규칙 목록이 아니며 DIRECT나 특정 프록시 그룹을 선택하지 않습니다. 최종 트래픽 경로는 아웃바운드 규칙과 다른 라우팅 설정으로 결정됩니다.
앞선 예시에서는 흔히 쓰이는 로컬 네트워크 도메인 접미사로 *.lan과 *.local을 사용했습니다. 도메인 패턴과 특수 규칙 지원 여부는 실제 코어 문서를 기준으로 확인하세요. 설정에서 fake-ip-filter-mode를 따로 지정했다면 필터 목록의 효과를 해석하기 전에 해당 모드의 의미부터 확인해야 합니다.
문제가 확인된 항목만 추가하고 긴 목록을 통째로 복사하지 마세요
- 기업 내부망 도메인: 내부 서비스에서
10.20.0.15를 반환해야 한다면 해당 도메인의 전체 이름을 먼저 필터에 추가할 수 있습니다. 필터 적용 후에는 조회 요청이 기업 DNS로 전달되도록 해야 합니다. 그렇지 않으면 존재하지 않거나 잘못된 주소가 반환될 수 있습니다. - 주소를 검증하는 프로그램: 일부 원격 연결 도구, 기기 검색 기능, 게임 구성 요소는 DNS 응답을 검사합니다. 실제 문제가 발생하는 도메인부터 테스트한 다음 패턴 범위를 넓힐지 결정하세요.
- 로컬 네트워크 기기 이름: 프린터, NAS, 화면 전송 기기는 로컬 도메인을 사용할 수 있지만, 기기 검색에는 mDNS 멀티캐스트, 브로드캐스트 또는 다른 프로토콜도 쓰일 수 있습니다. 도메인을 필터링해 해결되는 것은 그중 DNS 응답 문제뿐입니다.
nas.home.arpa 하나만 실패한다면 접미사 전체를 제외하기보다 해당 전체 이름만 먼저 추가해 확인하세요. 필터 범위가 넓을수록 더 많은 연결이 실제 주소 조회 경로를 사용하므로 내부 DNS와 트래픽 분기 정책을 올바르게 관리해야 합니다. NTP도 무조건 필터링할 필요는 없습니다. 기기나 앱에서 재현 가능한 호환성 문제가 발생할 때 실제로 조회하는 시간 서버 도메인만 처리하세요.
확인 방법: DNS 응답, 연결, 규칙을 각각 점검
브라우저에서 웹페이지가 열리는지만 확인해서는 안 됩니다. 브라우저가 자체 보안 DNS를 사용하거나 주소를 캐시했을 수 있습니다. 페이지가 열린다고 해서 Fake-IP 경로를 거쳤다는 뜻은 아닙니다. 먼저 로컬에서 테스트 DNS를 명시적으로 지정해 조회한 뒤 앱의 연결을 확인하세요.
1단계: 코어에 A 레코드를 직접 조회
# macOS / Linux: dig가 설치되어 있어야 함
dig @127.0.0.1 -p 1053 www.example.com A
# AAAA 응답도 확인해 예시의 IPv6 설정을 점검
dig @127.0.0.1 -p 1053 www.example.com AAAAA 레코드가 설정한 198.18.0.0/16 주소 풀에 포함되어 있다면 해당 조회에서 매핑 주소를 받은 것입니다. 항상 198.18.0.2가 반환되어야 하는 것은 아니며, 응답 주소를 hosts 파일에 직접 입력해서도 안 됩니다. 필터 목록에 해당하는 도메인은 별도로 테스트하세요. 예상되는 결과는 주소 풀의 응답이 아니라 상위 DNS 서버가 반환한 실제 주소 또는 해당 DNS 상태입니다.
2단계: 이전 캐시를 비우고 같은 대상을 다시 테스트
# Windows: 터미널에서 실행
ipconfig /flushdns
# systemd-resolved를 사용하는 Linux
sudo resolvectl flush-caches
# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder이 명령은 시스템의 DNS 캐시를 지우지만 브라우저, 앱, 코어 자체의 캐시까지 모두 삭제한다고 보장할 수는 없습니다. 테스트 앱을 종료한 뒤 다시 열고, 필요한 경우 클라이언트에서 DNS 캐시를 비운 다음 새 연결로 테스트하세요. 코어를 재시작하면 기존 합성 주소와 매핑이 더 이상 일치하지 않을 수 있으므로 이전 브라우저 연결을 복구할 때 잠시 실패할 수 있습니다.
3단계: 연결 기록에서 도메인과 아웃바운드 확인
클라이언트의 연결 목록이나 로그에서 대상 도메인, 적용된 규칙, 아웃바운드 정책이 예상과 맞는지 확인하세요. 더 자세한 정보가 필요하면 log-level을 잠시 debug로 설정한 뒤 테스트를 마치면 평소 사용하는 수준으로 되돌리세요. 로그를 공유하기 전에 구독 주소, 액세스 토큰, 노드 인증 정보와 민감한 도메인을 삭제해야 합니다.
자주 발생하는 문제: 흐름에 따라 원인 찾기
| 증상 | 먼저 확인할 항목 | 해결 방향 |
|---|---|---|
| 198.18 주소가 반환되고 모든 사이트가 시간 초과됨 | 합성 주소로 향하는 트래픽이 코어에 전달되는지 | TUN 라우팅, 실행 권한, 다른 VPN이 경로를 덮어쓰는지 확인 |
| 1053 포트로 직접 조회하면 시간 초과됨 | DNS 모듈이 실행 중인지, 포트가 올바른지 | 설정 로드 오류, 수신 주소, 포트 충돌 확인 |
| 내부망 서비스만 열리지 않음 | 필터 규칙, 기업 DNS, 내부망 라우팅 | 문제가 있는 도메인만 정확히 제외하고 올바른 내부 DNS 조회 경로 설정 |
| 브라우저는 정상이지만 특정 프로그램만 실패함 | 프로그램 자체 DNS, 주소 캐시, 프록시 사용 방식 | 보안 DNS와 캐시, 트래픽 가로채기를 우회하는지 확인 |
| 모드를 바꾼 뒤 간헐적으로 실패함 | 앱이 이전 주소나 연결을 계속 사용 중인지 | 관련 캐시를 지우고 기존 연결을 끊은 뒤 다시 테스트 |
실제 DNS 조회도 실패한다면 fake-ip-filter 범위를 넓히기 전에 상위 DNS 서버에 접속할 수 있는지 확인하세요. DNS는 정상이고 연결 기록에도 올바른 도메인이 표시되는데 프록시 연결이 시간 초과된다면 노드 연결 상태와 아웃바운드 규칙을 점검해야 합니다. Fake-IP는 연결 흐름의 앞부분을 처리할 뿐, 작동하지 않는 노드나 잘못된 프록시 인증 정보를 해결하지는 못합니다.
브라우저의 보안 DNS, Android 비공개 DNS 또는 앱 내장 DoH를 사용하면 코어의 일반 DNS 경로를 우회할 수 있습니다. 53 포트 가로채기만으로 모든 HTTPS 기반 DNS 요청을 처리할 수는 없습니다. 테스트할 때는 먼저 DNS 조회 경로를 하나로 통일한 다음 장기적으로 사용할 DNS 방식을 결정하세요. 여러 설정을 동시에 바꾸면 원인을 찾기 어렵습니다.
사용 환경과 되돌리는 순서
TUN을 안정적으로 사용하고 도메인별 트래픽 분기가 필요한 데스크톱 환경이라면 Fake-IP를 우선 검증해 볼 만합니다. 기업 VPN이나 복잡한 로컬 네트워크 환경, 앱에 실제 대상 IP가 표시되어야 하는 도구를 사용한다면 라우팅과 DNS 요구사항을 먼저 확인하고 필요하면 redir-host를 유지하세요. Android에서는 VPN 인터페이스를 다른 VPN 앱과 함께 사용할 때 충돌하는 경우가 많으므로 DNS 모드만 바꿔서는 인터페이스 충돌을 해결할 수 없습니다.
- 먼저 문제가 있는 부분만 수정: 특정 도메인에서만 문제가 발생하면 재현 방법을 기록하고, 해당 도메인만 정확히 필터링한 뒤 실제 DNS 조회 결과를 확인하세요.
- 다음으로 트래픽 가로채기 범위 확인: 합성 주소 연결이 대량으로 시간 초과된다면 필터 항목을 추가하기보다 라우팅, DNS 가로채기, 권한 문제부터 해결하세요.
- 마지막으로 모드 전환 검토: 앱이 실제 주소를 반드시 받아야 하거나 현재 네트워크에서 합성 주소를 안정적으로 가로채기 어려운 경우에
enhanced-mode: redir-host를 테스트하세요.
전환 전에 설정을 복구할 수 있도록 저장하고, 전환 후에는 설정을 다시 불러온 뒤 캐시를 지우세요. DNS 응답이 해당 모드에 맞는지, 연결에 올바른 규칙이 적용되는지, 일반 앱과 내부망 서비스가 안정적으로 작동하는지 세 가지를 확인해야 합니다. 출처가 불분명한 필터 목록을 계속 추가하기보다 최소한의 설정을 유지하고 각 항목의 역할을 명확히 해두는 편이 관리하기 쉽습니다.