Fake-IP과 Redir-Host 비교: Clash DNS 강화 모드와 사용 시나리오

두 DNS 강화 모드의 핵심 차이

Fake-IP과 Redir-Host는 Clash가 DNS 조회를 처리한 뒤 앱에 어떤 주소를 반환하고, 이후 연결을 도메인과 어떻게 연결할지를 결정합니다. 두 모드는 규칙 모드나 전역 모드를 대체하지 않으며, 노드 프로토콜에도 영향을 주지 않습니다. 문제를 진단할 때는 DNS 응답, 트래픽 가로채기, 규칙 매칭, 아웃바운드 연결을 나눠 확인하세요.

아래 설정 예시는 주로 Clash Meta(mihomo)를 기준으로 합니다. 클래식 Clash, ClashX의 커널 버전, 각종 GUI 클라이언트는 지원 필드와 설정 덮어쓰기 방식이 서로 다를 수 있습니다. 먼저 클라이언트의 ‘정보’ 또는 커널 정보에서 이름을 확인한 다음 실행 중인 설정을 살펴보세요. 앱 이름만으로 설정 호환 여부를 판단해서는 안 됩니다.

비교 항목	Fake-IP	Redir-Host
앱에 전달되는 주소	일반적으로 IP 풀에서 할당한 가상 IPv4 주소	업스트림 DNS가 조회한 실제 주소
도메인 연결 방식	가상 주소와 도메인의 매핑 사용	DNS 캐시의 도메인·주소 연결 정보 등을 사용
주요 사용 시나리오	TUN으로 트래픽을 가로채며 도메인 정보를 안정적으로 유지하려는 연결	앱에서 실제 DNS 주소를 읽어야 하는 호환성 시나리오
주요 점검 항목	DNS와 연결이 같은 커널에서 처리되는지, 매핑이 유효한지	업스트림 조회가 정상인지, 도메인 연결 정보가 완전한지

Fake-IP: 가상 주소를 먼저 할당한 뒤 도메인과 연결

연결 처리 순서

앱이 도메인의 A 레코드를 조회하고, 요청이 커널의 DNS 서비스에 도달합니다.
커널이 설정된 가상 IP 풀에서 주소를 할당하고 ‘도메인 ↔ 가상 주소’ 매핑을 저장합니다.
앱이 해당 가상 주소로 연결을 시작하면 TUN 또는 다른 트래픽 가로채기 방식이 연결을 커널로 전달합니다.
커널은 매핑을 통해 도메인을 확인하고 규칙에 따라 아웃바운드를 선택합니다. 실제 주소를 로컬에서 추가로 조회할지는 규칙, 아웃바운드 유형, 프로토콜 지원 여부에 따라 달라집니다.

일반적으로 사용하는 fake-ip-range: 198.18.0.1/16은 예약된 네트워크 벤치마크 주소 대역입니다. 이 주소는 대상 웹사이트의 공인 IP나 노드 주소가 아닙니다. 브라우저에서 페이지가 열리고 시스템 조회 결과에 198.18.x.x가 표시되는 것은 이 처리 과정에서 정상적인 현상입니다.

Fake-IP의 장점은 앱이 연결하려는 주소를 도메인과 명확하게 연결해 실제 IP만으로 접속 대상을 추정할 필요가 없다는 점입니다. 여러 도메인이 같은 CDN 주소를 사용할 수 있어 실제 주소와 도메인은 일대일로 대응하지 않습니다. 가상 주소 매핑은 이런 모호성을 줄여줍니다. 다만 모든 요청이 더 빨라지는 것은 아니며, 만료된 구독이나 연결할 수 없는 노드, 잘못된 규칙 문제를 해결해 주지는 않습니다.

Redir-Host: 실제 주소를 반환하고 DNS 연결 정보를 유지

Redir-Host는 실제 DNS 조회를 마친 뒤 그 결과를 앱에 반환합니다. 앱에는 실제 조회 주소가 표시되고, 커널은 관찰한 DNS 레코드 등의 정보를 이용해 도메인을 연결합니다. 모든 연결마다 공용 DNS에 PTR 역방향 조회를 하는 방식은 아닙니다. 여기서 ‘도메인 연결’은 주로 기존 매핑에서 도메인 정보를 복원하는 것을 뜻합니다.

이 방식은 조회 결과를 확인하거나 인터페이스 주소를 비교하고, 자체적으로 네트워크 연결을 처리하는 앱에서 더 직관적입니다. 반면 앱이 자체 암호화 DNS를 사용하거나 IP를 직접 지정해 연결하거나, DNS 조회가 커널을 거치지 않으면 도메인 연결 정보가 누락될 수 있습니다. 여러 도메인이 같은 주소를 사용한다면 IP 하나를 유일한 도메인 식별자로 볼 수도 없습니다.

Redir-Host로 바꾸기 전에 대상부터 확인

프린터 한 대나 내부 도메인만 문제가 있는 경우: 우선 해당 대상에 Fake-IP 예외와 올바른 내부 DNS를 설정하세요. 바로 전체 모드를 바꿀 필요는 없습니다.
앱에서 실제 DNS 결과를 명시적으로 요구하는 경우: Redir-Host로 비교 테스트를 진행하고, 적용된 규칙과 조회 결과를 함께 기록하세요.
노드 연결 시간이 초과되는 경우: 먼저 아웃바운드 주소와 네트워크 연결 가능 여부를 확인하세요. DNS 강화 모드를 바꿔도 노드 핸드셰이크 결과가 달라지지 않을 수 있습니다.

TUN 모드에서 Fake-IP을 함께 쓰는 이유

TUN은 시스템 네트워크 계층에서 가상 네트워크 인터페이스로 라우팅된 IP 패킷을 받으므로 시스템 HTTP 프록시를 따르지 않는 앱의 트래픽을 처리하기에 적합합니다. 하지만 IP 패킷에는 원래 도메인이 직접 포함되지 않는 경우가 많습니다. Fake-IP 매핑을 사용하면 가상 대상 주소를 받은 커널이 도메인을 찾아낼 수 있어, TUN 환경에서 도메인 기반 규칙 분기에 자주 활용됩니다.

두 설정은 여전히 별개입니다. TUN을 켰다고 DNS 요청이 반드시 커널로 들어가는 것은 아니며, Fake-IP을 선택했다고 모든 앱 연결이 가로채지는 것도 아닙니다. 브라우저의 보안 DNS, 다른 VPN의 라우팅, 회사에서 배포한 DNS 정책에 따라 조회와 연결이 서로 다른 경로를 사용할 수 있습니다.

mihomo 설정 예시

아래 예시는 DNS와 TUN 설정만 보여 줍니다. 노드, 정책 그룹, 전체 규칙은 포함되어 있지 않으므로 그대로 연결할 수 있는 구독 설정으로 사용할 수 없습니다. 기존 설정에 합칠 때는 같은 이름의 섹션을 수정해 최상위 dns 또는 tun 키가 중복되지 않도록 하세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

여기서 1053은 로컬 DNS 테스트용 리스닝 포트이며 HTTP, SOCKS 또는 혼합 프록시 포트가 아닙니다. 예시의 업스트림 DoH 주소는 현재 네트워크와 커널의 DNS 아웃바운드 정책에서 연결할 수 있어야 합니다. 연결할 수 없다면 클라이언트를 반복해서 재시작하지 말고 현재 환경에서 사용할 수 있는 DNS 서비스로 바꾸세요.

dns-hijack은 TUN이 수신한 트래픽 중 지정 포트를 대상으로 하는 DNS 요청에 적용됩니다. 브라우저가 HTTPS로 보내는 DoH 요청을 자동으로 복호화하지 않으며, 모든 시스템의 로컬 DNS 통신을 가로챈다고 보장하지도 않습니다. TUN을 사용하려면 해당 시스템 권한이나 서비스 지원도 필요합니다. 권한이 없다면 먼저 시작 로그의 오류를 해결하세요.

fake-ip-filter 설정법과 LAN 예외

일반적인 기본 블랙리스트 방식에서는 fake-ip-filter에 등록한 도메인에 Fake-IP를 할당하지 않고 실제 DNS 조회 경로에 따라 결과를 반환합니다. 최신 mihomo에는 필터 모드와 같은 확장 필드도 있습니다. 설정에 fake-ip-filter-mode가 명시되어 있다면 먼저 해당 옵션의 의미를 확인하고 기본 동작을 그대로 적용하지 마세요.

필요한 도메인만 예외로 지정

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "printer.home.arpa"

printer.home.arpa는 설명을 위한 LAN 이름이므로 실제 기기 도메인으로 바꿔야 합니다. 기기 하나만 지정할 때는 정확한 이름을 사용하세요. *.lan과 같은 항목은 해당 접미사의 하위 도메인에 적용됩니다. 와일드카드 범위는 커널마다 다를 수 있으므로 이 문자열을 정규식으로 취급하거나 규칙 목록 문법에 그대로 섞지 마세요.

필터링은 직결 설정이 아닙니다: 가상 주소를 반환하지 않도록 DNS 응답 방식만 바꿉니다. 연결을 직결할지는 여전히 규칙과 아웃바운드 정책에 따라 결정됩니다.
필터링은 DNS 지정이 아닙니다: 내부 도메인은 보통 라우터나 회사 DNS에서 조회해야 합니다. 필요한 경우 커널이 지원하는 nameserver-policy를 사용해 해당 DNS 서버를 설정하세요.
필터링은 서비스 검색을 대신하지 않습니다: .local은 mDNS를 사용하는 경우가 많습니다. 프린터 검색에는 멀티캐스트, 네트워크 인터페이스 선택, 방화벽도 영향을 줄 수 있으므로 도메인 예외를 추가해도 검색 기능이 복구된다고 보장할 수 없습니다.

모드 변경 후 확인 절차

한 번에 변수 하나만 바꾸세요. 현재 작동하는 설정을 저장하고 기존 강화 모드, DNS 업스트림, TUN 상태, 문제가 있는 도메인을 기록합니다. GUI 클라이언트는 구독 설정을 화면 설정이나 덮어쓰기 파일로 덮을 수 있습니다. 구독 원본 파일을 수정했다면 실행 설정에서 최종 값이 실제로 바뀌었는지 확인하세요.

설정을 다시 불러오고 로그 확인: DNS 리스닝과 TUN 생성이 성공했는지, 포트 충돌이나 필드 파싱 오류가 없는지 확인하세요.
커널 DNS에 직접 질의: dig가 설치된 macOS 또는 Linux 환경에서 아래 명령으로 예시 도메인을 조회하세요.
시스템 DNS 조회 경로 비교: 이어서 서버를 지정하지 않고 조회하세요. 두 결과가 다르면 시스템 조회가 실제로 커널을 거치는지 먼저 확인하세요.
앱 연결을 새로 시작: 해당 앱을 완전히 종료한 뒤 다시 실행하세요. 필요하면 시스템 DNS 캐시를 비워 이전의 실제 주소나 가상 주소가 판단에 영향을 주지 않도록 하세요.
연결 기록 확인: 페이지가 열리는지만 보지 말고 대상 도메인, 적용된 규칙, 실제 아웃바운드를 확인하세요.

# 위에서 설정한 커널 DNS에 직접 질의
dig @127.0.0.1 -p 1053 example.com A +short

# 시스템 기본 DNS 조회 경로 확인
dig example.com A +short

Fake-IP 모드에서는 필터에 포함되지 않은 A 레코드 조회에 설정된 주소 풀의 주소가 반환되는 것이 일반적입니다. Redir-Host 모드에서는 업스트림이 반환한 실제 레코드가 표시되어야 합니다. example.com은 테스트 방법을 설명하기 위한 도메인이므로 실제 문제를 진단할 때는 오류가 발생한 도메인도 조회하세요. AAAA 조회 결과에 가상 IPv4 주소가 없다는 이유로 Fake-IP이 작동하지 않는다고 판단하지 마세요.

시스템별 DNS 캐시 비우기

Windows에서는 명령 프롬프트에서 ipconfig /flushdns를 실행할 수 있습니다. macOS에서는 아래 명령을 사용합니다. 두 번째 명령은 시스템 DNS 서비스에 신호를 보내며, 실행 시 안내에 따라 컴퓨터 관리자 암호를 입력하세요. systemd-resolved를 사용하는 Linux에서는 resolvectl flush-caches를 실행할 수 있습니다. 다른 배포판은 실제 DNS 서비스에 맞춰 처리하세요.

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

시스템 캐시를 비워도 브라우저 내부 캐시가 자동으로 삭제되지는 않으며, 만료된 Fake-IP 매핑이 유지된다고 보장할 수도 없습니다. 모드를 바꾼 뒤에는 기존 연결을 종료하고 다시 테스트하세요. 커널을 재시작한 후 오래된 가상 주소 문제가 자주 발생하면 클라이언트에서 Fake-IP 매핑 저장 기능을 지원하고 활성화했는지 확인하세요.

자주 발생하는 문제와 우선 점검 항목

증상	우선 확인할 항목	해결 방향
198.18.x.x로 조회되지만 연결 시간 초과	연결이 같은 커널로 돌아오는지, TUN 라우팅이 있는지	라우팅 제외 항목, 동시 실행 중인 VPN, 만료된 매핑 확인
브라우저는 정상인데 특정 앱만 실패	앱 자체 DNS, 주소 검사, 독립 네트워크 스택	해당 앱에서 사용하는 도메인만 정확히 필터링한 뒤 재시험
모드를 바꿨는데도 실제 주소가 반환됨	실행 중인 설정, 필터 항목, 질의 대상 DNS 서버	먼저 커널 리스닝 포트에 직접 질의한 다음 시스템 경로를 확인
프린터나 내부 사이트에 연결할 수 없음	내부 DNS, mDNS, 사설망 라우팅, 방화벽	실제 DNS 조회와 직결 규칙을 각각 확인
인증서 이름 불일치 발생	대상 도메인, 조회 결과, 포털 인증, 중간 프록시	인증서와 연결 대상을 확인하고 인증서 검증은 끄지 마세요

또한 ping 실패만으로 웹사이트에 접속할 수 없다고 단정할 수는 없습니다. ICMP와 브라우저의 TCP·QUIC 요청은 서로 다른 연결 방식이며, Fake-IP의 ICMP 처리도 커널과 트래픽 가로채기 방식에 따라 달라집니다. 실제 앱 요청과 연결 기록을 함께 확인하세요.

모드 선택과 최종 점검

TUN으로 트래픽을 주로 가로채고 도메인 기반 분기를 안정적으로 유지하려는 환경에서는 Fake-IP을 먼저 사용하고, 호환성 문제가 실제로 있는 도메인에만 제한적으로 예외를 추가할 수 있습니다. 실제 DNS 응답에 의존하는 앱은 Redir-Host로 비교 테스트하세요. 모드를 바꾼 뒤에도 올바른 DNS 업스트림과 도메인 규칙을 유지해야 합니다.

마지막으로 네 가지를 확인하세요. DNS 조회를 누가 처리하는지, 앱에 어떤 주소가 전달되는지, 연결을 누가 가로채는지, 규칙이 어떤 아웃바운드를 선택하는지입니다. 각 단계의 동작을 확인한 뒤 강화 모드, 필터 목록, 라우팅 중 무엇을 바꿀지 결정하세요. 프록시 포트와 규칙 개념은 사용 설명서와 용어집에서 확인할 수 있습니다.