Fake-IP와 redir-host 차이: Clash DNS 모드 원리와 설정 가이드

먼저 구분하기: DNS 모드와 프록시 모드는 다릅니다

dns.enhanced-mode는 DNS 요청을 처리하는 방식과 이후 연결을 도메인에 연결하는 방식을 정합니다. mode: rule은 연결을 어떤 규칙으로 분기할지 결정합니다. 두 설정은 서로 다른 기능입니다. Fake-IP를 선택해도 모든 트래픽이 프록시를 거치는 것은 아니며, redir-host를 선택해도 연결이 반드시 직접 연결되는 것은 아닙니다.

이 글에서는 Clash Meta(현 mihomo)에서 흔히 사용하는 설정 항목을 예로 듭니다. 구버전 Clash나 클라이언트에 따라 지원 범위가 다를 수 있으니, 수정하기 전에 클라이언트의 커널 정보에서 실제 사용 중인 커널을 확인하세요. GUI의 설정이 구성 파일을 덮어쓸 수도 있으므로 구독 원문만 보지 말고 커널이 실제로 불러온 설정을 확인해야 합니다.

DNS 계층: 도메인 조회를 처리하고 앱에 주소를 반환합니다.
트래픽 진입점: 시스템 프록시, TUN 또는 라우터의 투명 프록시가 연결을 커널로 전달합니다.
규칙 계층: rules의 순서에 따라 직접 연결, 프록시 그룹 또는 연결 거부를 선택합니다.

Fake-IP는 트래픽 가로채기와 함께 사용해야 합니다. 앱이 가상 주소를 받은 뒤 연결이 해당 매핑을 보유한 커널로 돌아오지 않으면 의도한 대로 대상에 접속할 수 없습니다.

Fake-IP 작동 원리: 가상 주소를 먼저 반환한 뒤 도메인으로 연결

앱이 www.example.com을 조회한다고 가정해 보겠습니다. Fake-IP 모드에서는 커널이 설정된 주소 풀에서 가상 IPv4 주소를 할당하고 ‘가상 주소 → 도메인’ 매핑을 저장할 수 있습니다. 이후 앱이 해당 주소로 연결하면 커널이 연결을 받아 원래 도메인을 찾아 분기 규칙을 적용합니다.

앱이 DNS 요청을 Clash 또는 mihomo DNS 서비스로 보냅니다.
커널이 주소 풀의 주소를 반환합니다. 예를 들면 198.18.0.2이며, 할당되는 주소는 고정되어 있지 않습니다.
앱이 해당 주소로 연결을 시작하고, TUN 등의 진입점을 통해 연결이 같은 커널로 전달됩니다.
커널이 도메인을 복원하고 규칙을 적용한 뒤, 선택된 출구를 통해 실제 연결을 설정합니다.

흔히 198.18로 시작하는 주소를 사용하는 이유

198.18.0.0/15는 네트워크 장비 성능 시험용으로 지정된 특수 목적 주소 대역이며, 대상 웹사이트의 공인 IP가 아닙니다. 설정에서 자주 보이는 198.18.0.1/16도 이 범위에 속합니다. 일반 가정 LAN에서 주로 사용하는 RFC 1918 사설 IP 대역과도 다릅니다. 기업 네트워크나 실험 환경에서 같은 대역을 사용한다면 먼저 라우팅 충돌 여부를 확인하세요.

응답이 빨라도 모든 요청에서 DNS 조회가 생략되는 것은 아닙니다

Fake-IP를 사용할 수 있는 요청이라면 커널은 보통 대상의 실제 주소 응답을 기다리지 않고 앱에 가상 주소를 반환할 수 있습니다. 앱의 DNS 대기 시간을 줄이고 도메인 정보를 명확하게 유지할 수 있다는 장점이 있습니다. 다만 직접 연결 출구에서는 최종적으로 실제 주소가 필요합니다. 프록시 출구에서 원격 DNS 조회를 하는지는 노드 프로토콜과 연결 방식에 따라 달라집니다. 첫 페이지 로딩 속도도 핸드셰이크, 네트워크 경로, 서버 응답의 영향을 받으므로 일정한 속도 향상을 보장할 수는 없습니다.

redir-host의 차이: 실제 주소를 반환해 IP에 의존하는 앱과 호환

redir-host는 상위 DNS에 실제 주소를 조회해 앱에 반환하고, DNS 요청 기록을 이용해 도메인과 주소의 연결 정보를 관리합니다. 이후 연결이 커널에 들어오면 이 정보를 활용해 도메인 규칙을 적용할 수 있습니다. 다만 여러 도메인이 같은 주소를 쓰거나 앱이 자체 DNS를 사용하거나 DNS 캐시 출처가 다르면 연결 관계를 명확히 파악하기 어려울 수 있습니다.

비교 항목	Fake-IP	redir-host
앱에 반환되는 주소	주소 풀의 가상 주소(필터 항목 제외)	상위 DNS에서 조회한 실제 주소
DNS 응답 대기	대개 가상 주소를 먼저 반환할 수 있음	실제 조회 결과 또는 기존 캐시 필요
도메인 연결 방식	가상 주소 매핑으로 도메인 복원	DNS 기록 등의 정보로 연결 관계 보조
자주 발생하는 호환성 문제	앱이 실제 IP를 확인하거나 가상 주소가 가로채지지 않음	적절하지 않은 조회 결과, 불완전한 도메인 연결 정보
우선 사용해 볼 상황	트래픽이 빠짐없이 가로채지는 일반 웹 서핑과 규칙 기반 분기	실제 DNS 응답에 의존하는 도구 또는 호환성 문제 진단

redir-host가 ‘프라이버시 모드’인 것은 아니며, Fake-IP를 쓴다고 모든 DNS 요청이 자동으로 프록시를 거치는 것도 아닙니다. DoH·DoT 사용 여부, 상위 DNS 요청의 출구, 앱이 시스템 DNS를 우회하는지는 각각 별도로 확인해야 합니다. 브라우저의 보안 DNS를 켜면 DNS 요청이 커널의 DNS 서비스로 전달되지 않을 수 있습니다. enhanced-mode 값만으로 DNS 유출 여부를 판단하지 마세요.

Fake-IP 설정: 먼저 DNS 진입점을 확인하고 필터 목록 설정하기

다음은 설정 항목 간의 관계를 설명하기 위한 mihomo DNS 예시입니다. 노드와 규칙까지 포함한 완성 설정이 아니므로, 이미 정상 작동하는 설정에 합쳐서 사용하세요. 기존 파일에 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
    - 119.29.29.29

listen: 이 예시는 로컬 루프백 주소의 1053 포트에서만 DNS 요청을 받습니다. 시스템 DNS를 자동으로 변경하지 않으며 LAN 기기에 대한 수신도 허용하지 않습니다.
enhanced-mode: 이 DNS 모드를 사용하려면 fake-ip로 설정합니다.
fake-ip-range: 가상 주소 풀을 지정합니다. 프록시 노드 주소나 상위 DNS 주소가 아닙니다.
fake-ip-filter: 이 예시는 기본 블랙리스트 방식으로 사용하며, 목록에 일치하는 항목에는 실제 DNS 조회 결과를 반환합니다.
nameserver: 예시에서는 일반 DNS 서버 두 개를 사용합니다. 실제 네트워크에서 접속 가능한지와 개인정보 보호 요구에 맞춰 조정하세요.

일부 최신 mihomo 버전은 fake-ip-filter-mode로 필터 동작을 바꿀 수 있습니다. 기존 설정에서 whitelist를 명시했다면 목록의 의미가 반대가 되므로, 이 글의 제외 목록을 그대로 적용하면 안 됩니다. 커널을 바꿀 때는 먼저 해당 설정 항목의 지원 여부를 확인하세요.

fake-ip-filter는 DNS가 가상 주소를 반환할지 정할 뿐, DIRECT 규칙을 추가하지는 않습니다. 직접 연결해야 하는 대상은 rules에 적절한 분기 규칙을 별도로 설정해야 합니다.

TUN의 DNS 가로채기와 수신 포트는 별개로 확인하세요

해당 설정 항목을 지원하는 mihomo 구성에서는 tun.dns-hijack으로 일반 DNS 트래픽을 커널에 전달할 수 있습니다. 다음 예시는 UDP와 TCP의 53 포트 요청을 가로채는 설정입니다. 앱 자체의 DoH를 직접 복호화할 수 있다는 뜻은 아닙니다. TUN 사용 권한, 라우팅, 클라이언트 설정의 덮어쓰기 여부도 별도로 확인해야 합니다.

tun:
  enable: true
  auto-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

이 설정을 시스템 프록시와 같은 진입 방식으로 생각하면 안 됩니다. HTTP 프록시를 사용하는 브라우저는 도메인을 프록시에 직접 전달할 수 있어 로컬 DNS를 거치지 않을 수 있습니다. 반면 TUN은 앱이 먼저 도메인을 조회하고 IP에 연결하는 전체 경로를 가로채야 하는 경우가 많습니다.

게임·로컬 네트워크 기기와 fake-ip-filter 적용 범위

로컬 네트워크 NAS·프린터: 먼저 로컬 도메인 조회부터 확인

라우터가 일반 DNS를 통해 nas.home.arpa를 제공한다면 해당 이름을 필터에 추가하고, 이 레코드를 실제로 알고 있는 라우터 DNS로 조회를 전달할 수 있습니다. 라우터 주소가 실제로 192.168.1.1인 경우, 기존 DNS 설정에 다음 항목을 합쳐 추가하세요.

  fake-ip-filter:
    - 'localhost'
    - '*.lan'
    - '*.local'
    - 'nas.home.arpa'
  nameserver-policy:
    'nas.home.arpa':
      - 192.168.1.1

라우터 주소는 현재 네트워크와 일치해야 합니다. 필터 목록이 로컬 DNS 레코드를 새로 만들어 주지는 않습니다. 192.168.1.20으로 NAS에 직접 접속할 때는 도메인 조회가 없으므로 Fake-IP 필터를 바꿔도 보통 효과가 없습니다. 사설망 라우팅, TUN 우회 설정, 방화벽을 확인하세요.

.local은 mDNS 검색에도 자주 사용됩니다. *.local을 필터 목록에 추가해도 mDNS 멀티캐스트가 자동으로 전달되거나 다른 서브넷의 프린터 검색 문제가 해결되지는 않습니다. ‘기기 검색 실패’와 ‘주소를 알고 있는데 접속되지 않음’을 구분해 진단하세요.

게임·음성 통화: 전체 범주를 직접 연결하지 말고 문제가 생긴 도메인만 제외

일부 게임, 음성 통화 또는 연결 상태 확인 도구는 DNS 응답 주소를 검사하거나 조회 결과를 다른 기기에서 사용합니다. 이런 과정은 가상 주소와 맞지 않을 수 있습니다. 먼저 로그에서 로그인, 매칭, 음성 통화 또는 STUN과 관련된 실제 조회 도메인을 찾고 정확한 이름만 필터 목록에 추가하세요. 서비스 이름만 보고 도메인을 무더기로 추측해 넣지 마세요.

로그인은 되지만 음성 통화가 안 됨: 노드의 UDP 지원, UDP 분기, NAT 상태도 확인하세요. DNS 필터로 UDP 지원을 보완할 수는 없습니다.
특정 검사만 실패함: 우선 해당 검사 도메인만 제외하고 나머지 트래픽은 Fake-IP 방식으로 유지하세요.
휴대폰에서 PC 공유 프록시 사용: 휴대폰이 가상 주소에 연결할 때 매핑을 생성한 PC의 커널을 계속 거치는지 확인하세요. DNS만 PC를 가리키게 해서는 충분하지 않습니다.

모든 호환성 문제를 해결하겠다며 '*'를 추가하는 것은 권장하지 않습니다. 블랙리스트 방식에서는 일치하는 모든 조회가 Fake-IP를 우회하게 되어 기존 주소 매핑 기능을 잃고, 이후 문제를 일으킨 항목을 찾기도 어려워집니다.

모드 전환 후 확인 절차와 자주 하는 오해

백업한 뒤 한 가지 항목만 변경하세요. 현재 설정을 저장하고 DNS 모드나 필터 항목 하나만 조정하세요. 노드, 규칙, TUN 라우팅을 동시에 바꾸지 마세요.
설정을 다시 불러오세요. 로그에서 YAML 들여쓰기 오류, 알 수 없는 설정 항목, 포트 사용 중 오류를 확인하세요. 설정을 불러오지 못하면 커널이 이전 설정을 계속 사용할 수 있습니다.
DNS 응답을 확인하세요. 이 글에 나온 수신 주소로 다음 조회를 실행해 요청이 실제로 커널에 전달되는지 확인합니다.
이전 조회 상태를 초기화하세요. 대상 앱을 완전히 종료한 뒤 다시 열고, 필요한 경우 시스템 DNS 캐시를 비우세요. 기존 연결과 앱 자체 캐시는 파일을 수정해도 바로 사라지지 않습니다.
실제 연결을 확인하세요. 클라이언트의 연결 기록에서 대상 도메인, 적용된 규칙, 출구를 확인한 다음 문제가 DNS 조회, 트래픽 분기, 연결 중 어느 단계에서 발생했는지 판단하세요.

dig @127.0.0.1 -p 1053 www.example.com A

# Windows PowerShell: 시스템 DNS 캐시 비우기
Clear-DnsClientCache

# Windows 명령 프롬프트: 같은 작업 수행
ipconfig /flushdns

dig를 사용하려면 해당 도구가 시스템에 설치되어 있어야 합니다. 이 명령은 1053 포트를 명시합니다. 일반 nslookup을 실행하면 보통 시스템에 설정된 DNS를 조회하므로, 이 글의 수신 서비스를 테스트하지 못할 수 있습니다. 필터에서 제외되지 않은 도메인의 경우 Fake-IP 모드에서 주소 풀의 A 레코드가 표시되는 것은 정상이며, 공인 DNS 응답이 변조됐다는 증거가 아닙니다.

redir-host로 바꿨는데도 198.18 주소로 연결되는 이유

앱에 이전 주소가 남아 있거나 클라이언트가 새 설정을 커널에 적용하지 않았을 가능성이 큽니다. 먼저 실제 실행 모드를 확인한 뒤 기존 연결을 닫고 캐시를 비운 다음 다시 시도하세요. 커널을 재시작해 Fake-IP 매핑이 사라졌는데 앱이 이전 가상 주소를 계속 사용하면 연결이 실패할 수도 있습니다. 지원되는 커널은 profile.store-fake-ip로 매핑을 유지할 수 있지만, 올바른 트래픽 가로채기를 대신하지는 않습니다.

IP 규칙은 계속 적용되나요?

Fake-IP를 사용해도 IP 규칙이 비활성화되는 것은 아닙니다. 커널은 필요한 경우 실제 대상 주소를 조회해 관련 규칙을 적용할 수 있으며, 동작은 규칙 순서, 캐시, no-resolve 등의 옵션에 영향을 받습니다. 가상 주소만 보고 대상의 지역을 판단하지 마세요. 웹사이트 접속 문제를 해결하려고 Fake-IP 주소 풀 전체에 직접 연결 규칙을 추가하는 것도 피해야 합니다.

설정 권장 사항: 일상 사용은 안정성 우선, 호환성 문제는 필요한 곳만 조정

일상적인 웹 서핑에서 트래픽 진입점이 명확하고 DNS가 커널에 전달된다면 Fake-IP부터 사용해 볼 수 있습니다. NAS, 게임 로그인 또는 특정 검사에서만 문제가 발생한다면 근거가 있는 필터 항목을 최소한으로 추가하고 로컬 DNS와 분기 규칙도 함께 점검하세요. 앱이 실제 주소를 반드시 필요로 하거나 가상 주소 트래픽을 완전히 가로채기 어려운 환경에서만 redir-host와 비교해 테스트하는 편이 좋습니다.

판단 기준은 DNS 조회 시간만이 아니라 대상 앱이 도메인 조회, 규칙 적용, 연결 설정, 데이터 전송까지 모든 과정을 안정적으로 완료하는지입니다. 작동하는 설정을 따로 보관하고 수정 항목과 재현 절차를 기록하면 여러 설정을 한꺼번에 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다. 처음 설정한다면 구독 가져오기 및 설정 가이드를 먼저 확인하세요. 연결 문제가 발생하면 문제 해결 가이드를 참고하세요.