Clash Fake-IP 모드 원리: redir-host와의 차이 및 사용 시나리오
Fake-IP가 예약 주소 대역으로 도메인을 매핑해 DNS 왕복을 줄이는 원리, fake-ip-filter의 역할, LAN 기기와 충돌할 때의 해결 방법을 알아봅니다.
Fake-IP: 먼저 매핑 주소를 반환하고 실제 연결을 처리
Clash 또는 mihomo 설정에서 enhanced-mode: fake-ip를 사용하면 코어의 DNS 모듈이 도메인에 가상 주소를 할당합니다. 이 주소는 웹 서버의 공인 IP가 아니라, 코어가 도메인 매핑을 찾기 위한 인덱스입니다. 앱이 이 주소로 연결하면 트래픽은 반드시 같은 코어를 다시 거쳐야 도메인을 복원하고 다음 처리를 진행할 수 있습니다.
일반적인 설정에서는 198.18.0.1/16을 fake-ip-range로 사용합니다. 이 주소는 네트워크 벤치마크용으로 예약된 198.18.0.0/15 대역에 속하며, 일반 공인 웹사이트 주소도 192.168.0.0/16 같은 사설 LAN 주소도 아닙니다. DNS 결과에 이 주소가 보인다고 해서 곧바로 DNS 오류라고 판단할 수는 없습니다.
접속은 어떤 순서로 이루어질까요?
- 앱이
example.com을 조회하면 요청이 코어의 DNS로 전달됩니다. - 코어는 도메인과 가상 주소를 매핑한 뒤 앱에 해당 주소를 반환합니다. 예를 들어
198.18.0.10이 반환될 수 있습니다. 숫자는 설명을 위한 예시이며 실제 할당 주소는 고정되어 있지 않습니다. - 앱이 해당 주소로 연결을 시작하면 TUN 등의 트래픽 처리 경로를 통해 연결이 코어로 전달됩니다.
- 코어는
example.com을 복원하고 규칙에 따라 직접 연결하거나 프록시를 사용합니다. 실제 주소가 필요한 경우에는 해당 아웃바운드 및 DNS 설정에 따라 다시 조회합니다.
Fake-IP와 redir-host의 핵심 차이
redir-host는 보통 먼저 상위 DNS에 질의한 뒤 앱에 실제 IP를 반환합니다. 코어는 DNS 기록을 이용해 도메인과 연결하려고 하지만, 하나의 IP에서 여러 도메인이 호스팅될 수 있고 연결 정보가 누락되기도 합니다. Fake-IP는 별도의 매핑으로 도메인을 보존하므로 도메인 기반 분기에 유리한 경우가 많지만, 연결 경로 전체가 코어를 거쳐야 합니다.
| 비교 항목 | Fake-IP | redir-host |
|---|---|---|
| 앱이 받는 DNS 주소 | 대개 주소 풀에서 할당한 가상 주소입니다. 필터에 걸린 도메인은 예외입니다. | 대개 상위 DNS에서 조회한 실제 주소입니다. |
| DNS 응답을 반환하기 전 | 필터 규칙에 일치하지 않으면 보통 실제 A 레코드를 먼저 기다릴 필요가 없습니다. | 대개 실제 DNS 조회 결과를 기다리거나 캐시를 사용합니다. |
| 도메인 식별 | 가상 주소 매핑을 통해 도메인을 복원할 수 있습니다. | DNS 연결 정보, 요청에 포함된 도메인 또는 스니핑 등의 정보에 의존합니다. |
| 호환성 확인 사항 | 앱이 가상 주소를 허용하는지, 연결이 코어로 되돌아오는지 확인해야 합니다. | 상위 DNS의 응답 품질, 실제 주소 연결 가능 여부, 도메인 연결 정보의 완전성을 확인해야 합니다. |
‘DNS 왕복 감소’가 ‘DNS 조회가 전혀 없음’을 뜻하지는 않습니다
Fake-IP는 일부 상황에서 앱이 실제 주소를 조회하느라 기다리는 단계를 줄여 줍니다. 규칙이 도메인만으로 프록시를 선택하고 아웃바운드 프로토콜이 도메인 처리를 원격 서버에 맡길 수 있다면, 로컬에서 대상의 실제 IP를 얻기 위한 조회를 한 번 생략할 수 있습니다. 하지만 직접 연결에서는 보통 실제 주소가 필요합니다. IP 기반 규칙, 필터에 걸린 도메인 및 기타 조회 조건에서도 상위 DNS 질의가 발생할 수 있습니다.
따라서 몇 밀리초가 절약된다고 단정할 수는 없습니다. 캐시 적중률, 상위 DNS 응답 지연, 노드 위치, 연결 재사용 여부가 모두 결과에 영향을 줍니다. 두 모드를 비교할 때는 같은 네트워크, 같은 노드, 같은 도메인을 사용하고 DNS 응답 시간과 웹페이지 첫 바이트 수신 시간을 각각 기록하세요. 한 번의 속도 측정 결과를 일반적인 결론으로 받아들이지 마세요.
mihomo 설정: DNS 리스닝 포트와 프록시 포트 구분하기
아래 YAML 조각은 해당 항목을 설명하기 위한 예시이며, 해당 필드를 지원하는 mihomo 설정에 사용할 수 있습니다. 노드, 프록시 그룹, 규칙은 포함되어 있지 않으므로 완전한 구독 설정으로 사용할 수 없습니다. 기존 설정에 항목을 추가할 때는 현재 아웃바운드 설정을 유지하세요. GUI 클라이언트는 설정 덮어쓰기 기능으로 최종 설정을 생성할 수 있으므로 현재 적용 중인 설정을 기준으로 확인해야 합니다.
mixed-port: 7890
mode: rule
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
- 119.29.29.29mixed-port: 7890: HTTP와 SOCKS를 함께 받는 프록시 진입점이며 DNS 포트가 아닙니다. 실제 포트는 클라이언트에 표시된 값을 확인하세요.listen: 127.0.0.1:1053: 로컬에서만 DNS 요청을 받으므로 특정 경로를 테스트하기에 편리합니다. Windows 네트워크 어댑터의 DNS는 보통 53번 포트를 사용합니다.127.0.0.1만 지정한다고 해서 1053번 포트에 자동으로 연결되는 것은 아닙니다.ipv6: false: 이 DNS 모듈의 AAAA 질의 처리 방식을 제어합니다. Windows의 IPv6 프로토콜 스택을 비활성화하는 설정은 아닙니다.nameserver: 상위 DNS 서버를 지정합니다. 예시는 일반 DNS를 사용하며, 암호화 DNS가 활성화된다는 뜻도 모든 네트워크에서 연결을 보장한다는 뜻도 아닙니다.
구독을 업데이트하면 직접 수정한 설정이 덮어써질 수 있습니다. 클라이언트에 ‘오버라이드’ 또는 설정 병합 기능이 있다면 해당 기능으로 DNS 항목을 수정하는 것이 좋습니다. 저장한 뒤 설정을 다시 불러오고 로그에서 YAML 파싱 오류, 리스닝 실패, 상위 DNS 요청 시간 초과 여부를 확인하세요. 화면에 표시된 스위치 상태만으로 설정이 적용됐다고 판단할 수는 없습니다.
fake-ip-filter: 실제 주소가 필요한 도메인만 예외 처리
일반적인 필터 동작에서는 fake-ip-filter에 일치하는 도메인에 Fake-IP를 할당하지 않고 실제 주소를 조회합니다. mihomo는 fake-ip-filter-mode로 매칭 방식을 조정하는 기능도 지원합니다. 이 항목을 설정했다면 현재 버전의 문서와 실제 값을 먼저 확인하고, 기본 블랙리스트 방식이라고 가정해 판단하지 마세요.
먼저 해당 도메인을 확인한 뒤 필터에 추가하세요
- LAN 관리 페이지: 먼저 실제로 사용하는 호스트 이름(예:
nas.home.arpa)을 확인한 뒤 해당 이름이나 필요한 접미사에 예외를 추가하세요. - 사내 서비스: 회사 DNS가 내부 도메인을 조회할 수 있는지 확인하고, 필요한 경우
nameserver-policy로 회사 DNS 서버를 지정하세요. - 실제 DNS 조회 결과가 필요한 앱: 로그에서 실패한 도메인을 찾아 하나씩 추가하고, 나머지 도메인에는 Fake-IP 동작을 유지하세요.
+.lan은 해당 접미사와 관련된 도메인에 일치하는 규칙이지, 모든 로컬 기기를 자동으로 식별하는 기능은 아닙니다. .local은 멀티캐스트 검색에 쓰이는 mDNS에서 흔히 사용됩니다. +.local을 필터에 넣어도 일반 상위 DNS가 mDNS 전달기로 바뀌지는 않습니다. 프린터 검색에 실패한다면 앱의 기기 검색 방식, 방화벽, 연결된 네트워크 대역도 확인하세요.
필터 규칙은 직접 연결 규칙과 다릅니다. 필터는 DNS가 가상 주소를 반환할지 결정할 뿐, 연결을 DIRECT로 지정하지 않습니다. NAS 도메인을 직접 연결해야 한다면 해당 도메인 규칙을 별도로 설정하세요. 실제 주소를 회사 DNS에서만 확인할 수 있다면 DNS 서버 선택도 올바르게 설정해야 합니다. 필터 목록을 모든 도메인으로 확대하면 Fake-IP의 이점만 줄어들고 실제 라우팅 문제는 해결되지 않을 수 있습니다.
TUN, 시스템 프록시, 암호화 DNS 함께 사용하기
Fake-IP는 DNS 동작 모드이고 TUN은 트래픽을 가로채는 방식이므로 같은 설정이 아닙니다. TUN 모드는 가상 주소로 앱이 연결을 시작할 때 트래픽을 처리하기에 대체로 적합합니다. 시스템 프록시는 Windows 프록시 설정을 따르는 앱에 주로 영향을 줍니다. 시스템 프록시만 켜도 모든 프로그램의 DNS 요청과 연결이 코어로 전달되는 것은 아닙니다.
요청 경로의 네 지점 확인하기
- Windows DNS: Windows 11에서 「설정」→「네트워크 및 인터넷」→ 현재 연결의 「속성」→「DNS 서버 할당」을 열어 사용 중인 DNS 서버를 확인하세요. 시스템 버전에 따라 메뉴 이름이 조금 다를 수 있습니다.
- 클라이언트 TUN: 가상 네트워크 어댑터가 생성되었는지, 서비스가 정상인지, 라우팅에 사용 중인 Fake-IP 주소 풀이 포함되는지 확인하세요. 서비스 권한이 필요한 클라이언트는 해당 서비스를 먼저 설치해야 합니다.
- DNS 하이재킹: 적용 중인 설정에서
tun.dns-hijack을 확인하세요. 일반적인 53번 포트 하이재킹만으로는 앱에 내장된 모든 DoH 요청을 자동으로 가로챌 수 없습니다. - 브라우저 보안 DNS: Microsoft Edge에서 「설정」→「개인 정보, 검색 및 서비스」→「보안」을 열고 ‘보안 DNS 사용’ 관련 옵션을 확인하세요. 조직에서 관리하는 기기는 정책에 따라 설정이 제어될 수 있습니다.
브라우저가 외부 DoH 서버에 직접 질의하면 실제 IP를 받아 코어의 Fake-IP 할당을 우회할 수 있습니다. 웹사이트는 열리더라도 해당 연결에 기대했던 DNS 매핑이 적용되지 않을 수 있습니다. 도메인 스니핑으로 정보를 보완할 수는 있지만 모든 프로토콜에서 도메인을 복원할 수 있는 것은 아닙니다. 원인을 확인하려면 앱 자체의 보안 DNS를 잠시 꺼서 비교해 보세요. 확인 후에는 DNS 경로를 통일할지 별도 조회를 유지할지 결정하면 됩니다.
Windows에서 확인하기: DNS 질의, 연결, 로그를 따로 점검
먼저 코어 DNS가 예상대로 응답하는지 확인한 뒤 앱의 연결을 테스트하세요. 위의 1053 리스닝 예시를 테스트하려면 PowerShell 또는 명령 프롬프트에서 nslookup을 실행하고 아래 명령을 차례로 입력합니다. 대화형 모드에서 설정한 포트는 이번 테스트에만 적용되며 Windows 네트워크 어댑터의 DNS를 변경하지 않습니다.
nslookup
server 127.0.0.1
set port=1053
set type=A
example.com
exit필터 규칙에 일치하지 않고 설정이 올바르게 적용됐다면 응답 주소는 설정된 Fake-IP 주소 풀 안에 있어야 합니다. 특정 끝자리 숫자가 반드시 반환되어야 하는 것은 아닙니다. 시간 초과가 표시되면 DNS 활성화 여부, 리스닝 주소의 일치 여부, 코어 로그를 먼저 확인하세요. 실제 IP가 반환되면 필터 규칙과 적용 중인 enhanced-mode를 확인하세요.
모드 전환 후 이전 상태 정리하기
ipconfig /flushdns이 명령은 Windows DNS 클라이언트 캐시를 비우지만 모든 브라우저 캐시, 앱 연결 풀, 코어 매핑까지 지우지는 않습니다. Fake-IP와 redir-host 사이를 전환한 뒤에는 영향을 받는 앱의 기존 연결도 종료하고 필요하면 앱을 다시 시작하세요. 설정을 다시 불러와 매핑이 무효화됐는데 앱이 이전 가상 주소를 계속 보유하면 일시적인 연결 실패가 발생할 수 있습니다.
그다음 클라이언트의 「연결」 페이지에서 대상 도메인, 일치한 규칙, 정책 그룹, 아웃바운드 노드를 확인하세요. DNS가 가상 주소를 반환했는데 연결 목록에 해당 기록이 없다면 트래픽이 코어에 전달되는지 확인해야 합니다. 연결 기록은 있지만 실패한다면 실제 DNS 조회, 노드 연결 상태, 아웃바운드 오류를 확인하세요. ping 결과만으로 웹 프록시가 정상인지 판단하지 마세요. ICMP와 브라우저의 TCP·UDP 요청은 서로 다른 경로를 사용합니다.
LAN 충돌 및 모드 선택
VPN, 테스트 환경 또는 회사 네트워크에서 이미 198.18.0.0/15 대역의 주소를 사용한다면 Fake-IP 라우팅이 실제 대상과 충돌할 수 있습니다. 먼저 route print를 실행해 대상 네트워크, 인터페이스, 메트릭을 확인한 뒤 VPN 설정에서 해당 주소의 용도를 확인하세요. 예약 주소라는 이유만으로 시스템 경로를 바로 삭제하지 마세요.
| 증상 | 우선 확인할 사항 |
|---|---|
| 공인 웹사이트는 열리지만 NAS 도메인은 접속되지 않음 | NAS 도메인의 실제 DNS 서버, 필터 예외, 직접 연결 규칙을 확인하세요. |
| 가상 주소를 받았지만 모든 연결이 실패함 | TUN 라우팅, 앱의 우회 여부, 코어 매핑의 유효성을 확인하세요. |
| 회사 VPN을 켜면 일부 주소에 연결할 수 없음 | 주소 풀이 VPN 경로와 겹치는지 확인하고 네트워크 관리자 지침에 따라 조정하세요. |
| 특정 앱만 가상 주소를 거부함 | 먼저 최소 범위의 필터 예외를 추가한 뒤 redir-host를 검토하세요. |
fake-ip-range를 변경할 때는 새 주소 대역이 실제 네트워크와 겹치지 않는지 확인하고, 트래픽 처리 경로와 제외 규칙도 함께 갱신해야 합니다. 현재 사용 중인 가정용 LAN 대역으로 임의 변경하지 마세요. 회사 VPN과 가상 네트워크 어댑터 정책을 함께 조정할 수 없다면 호환성 비교를 위해 redir-host로 전환해 볼 수 있습니다. 이 경우에도 도메인 규칙, DNS 응답 품질, 내부 서비스 접속을 검증해야 합니다.
도메인 기반 분기에 주로 의존하고 DNS와 연결을 모두 제대로 가로챌 수 있는 Windows 환경이라면 Fake-IP를 먼저 테스트해 볼 수 있습니다. 실제 DNS 응답을 유지해야 하거나 특수한 LAN 기기 검색 방식이 있거나 기업 네트워크 정책의 제약을 받는 환경에서는 먼저 도메인별 예외를 설정하세요. 예외로도 해결되지 않으면 redir-host를 검토할 수 있습니다. 어떤 모드가 항상 정답이라고 보기보다 실제 요청 경로와 앱 호환성을 기준으로 선택해야 합니다.