Clash Verge Rev 윈도우 DNS 설정: fake-ip와 redir-host 전환·검증 절차

이 글이 맞는 상황인가요?

Windows에 Clash Verge Rev를 쓰면서 구독 프로필 안의 DNS 설명을 읽다 enhanced-mode: fake-ip와 redir-host(또는 문서·버전에 따라 표기만 조금 다른 동일 개념)라는 말이 반복되는데, 무엇을 고르는 게 맞는지, 바꾼 뒤 실제로 해석과 분할 규칙이 기대대로 도는지 확인하고 싶다면 이 문서가 바로 그 단일 기능 묶음을 따라가기 좋습니다.

TUN 전체 개요·관리자 권한·외부 대시보드 같은 넓은 주제는 TUN 모드 가이드와 Clash Verge Rev 가이드에 맡기고, 여기서는 프로필 YAML의 dns 블록에서 모드를 바꾸고, 로그·간단한 CLI로 검증하는 흐름만 다룹니다. 설치·SmartScreen·구독 URL 자체가 낯설다면 Windows 10 설치 글이나 구독 가져오기를 먼저 보고 오면 단계 번호가 더 선명합니다.

한 줄 요약: fake-ip는 도메인 단계에서 규칙 엔진이 빠르게 이름을 보도록 돕는 패턴이고, redir-host는 상대적으로 “전형적인” IP 해석 흐름에 가깝게 맞추고 싶을 때 쓰는 쪽으로 이해하면 됩니다. 둘 다 만능이 아니라서, 증상별로 잠시 바꿔 비교하는 전략이 실무에서 자주 쓰입니다.

fake-ip와 redir-host, Windows 사용자가 알아야 할 차이

Mihomo(Clash Meta)에서 말하는 enhanced-mode는 DNS 하위 시스템이 어떤 형태의 응답을 앱에 돌려주며 규칙 매칭과 연동할지를 정합니다. fake-ip를 켜 두면 특정 범위(예시로 흔한 198.18.0.0/16) 안의 임시 주소를 붙여 두었다가, 이후 연결 시점에 실제 목적지 정보와 맞추는 식으로 동작합니다. 덕분에 도메인 기반 규칙이 빨리 걸리는 경우가 많고, 체감 지연도 종종 좋아집니다.

반면 일부 앱·로그·스니퍼·스트리밍 조합에서는 “DNS 창에서 본 이름”과 “소켓이 붙는 이름/IP”가 어긋나 혼란이 생기기도 합니다. 이때 fake-ip-filter로 예외 도메인을 빼내거나, 아예 redir-host 쪽으로 옮겨 해석 결과가 규칙·로그에서 기대한 그림과 더 직선적으로 보이게 하는 식으로 문제를 가릅니다. 스니퍼와 DNS의 상호작용은 Sniffer·스트리밍 규칙 글에서도 같은 축으로 설명되니, 도메인 규칙이 안 먹는 증상이 함께 있다면 연달아 읽으면 좋습니다.

Windows 자체의 이더넷/Wi-Fi DNS를 수동으로 공인 리졸버로만 바꿔도, 트래픽이 Clash 밖으로 새면 Mihomo의 dns: 블록은 앱에서 실제로 쓰이지 않을 수 있습니다. Verge에서 TUN이나 시스템 프록시, 혹은 문서에 나오는 로컬 DNS 수신 패턴이 어떻게 잡혀 있는지가 한 세트입니다. 이 글에서는 “프로필 값을 바꿨다”는 전제가 이미 트래픽이 코어 쪽으로 들어오는 상태일 때 의미가 가장 크다고 반복해서 짚습니다.

바꾸기 전에 고정할 것

DNS 모드는 감이 안 올 때 한 번에 여러 레버를 동시에 흔들면 원인 추적이 거의 불가능해집니다. 가능하면 아래만 먼저 고정하세요.

  • 활성 프로필 하나(구독 갱신 직후인지, 로컬 수정본인지).
  • TUN on/off와 시스템 프록시 on/off 상태(테스트 중에는 바꾸지 않기).
  • 브라우저의 Secure DNS(DoH) 사용 여부(켜 두면 Clash 밖으로 질의가 새기 쉬움).

그다음에야 dns.enhanced-mode만 fake-ip ↔ redir-host로 바꿔 보고, 같은 사이트·같은 명령을 다시 실행해 차이를 봅니다. 지연·UDP·DNS 트러블슈팅에서 다루는 이중 경로 문제와도 연결됩니다.

팁: 메모장으로 “전:” YAML 조각과 “후:” 조각을 짧게 남겨 두면, 며칠 뒤에도 어떤 값이 기본이었는지 되돌리기 쉽습니다. 구독이 덮어쓰는 프로필이라면 로컬 복제본을 하나 두는 편이 안전합니다.

1단계: Verge에서 프로필의 dns 블록 열기

Clash Verge Rev를 연 뒤 프로필·설정·편집기에 해당하는 화면으로 가서, 현재 적용 중인 YAML에서 dns: 아래를 찾습니다. 흔한 키는 다음과 같습니다.

  • enable: true — DNS 모듈 자체를 켭니다.
  • enhanced-mode: fake-ip 또는 redir-host
  • fake-ip-range: — fake-ip 대역
  • fake-ip-filter: — fake-ip를 쓰지 않고 일반 해석을 태울 도메인 목록
  • nameserver: / fallback: / nameserver-policy: 등 업스트림 분기

UI 라벨은 빌드마다 조금씩 다르지만, “프로필 편집”·“구성”·“YAML” 계열 메뉴 중 하나에서 동일한 텍스트를 볼 수 있습니다. 여기까지 왔다면 이미 Windows 방화벽에서 Verge가 허용돼 있고, 코어가 떠 있는 상태라고 가정합니다.

2단계: fake-ip와 redir-host 전환하기

redir-host로 바꿀 때는 enhanced-mode 값을 문자열 그대로 바꿉니다. 프로필 작성자가 주석으로 “fake-ip 권장”을 달았더라도, 증상 재현·원인 분리 목적이라면 일시적으로 바꿔 보는 것이 일반적인 디버깅 순서입니다.

fake-ip로 되돌릴 때는 반대로 같은 줄만 복구하면 됩니다. 이때 fake-ip-filter가 비어 있으면 기본 동작만 타고, 특정 도메인이 계속 문제를 일으키면 해당 접미사나 FQDN을 필터에 넣어 그 호스트만 실제 해석으로 보내는 방법이 있습니다. 필터를 과하게 넓히면 도메인 규칙의 이점이 줄어드니, 최소 추가를 유지하세요.

구독이 주기적으로 덮어쓰는 원본이라면, Verge의 로컬 편집·머지 규칙(버전에 따라 이름 상이)으로 dns만 덮어쓰게 해 두거나, 복제 프로필에서 실험하는 편이 낫습니다. 그렇지 않으면 다음번 구독 업데이트에 모드가 원복되어 “어제 고쳤는데 또 풀렸다”는 상황이 됩니다.

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

위는 이해를 돕기 위한 예시 스켈레톤입니다. 실제 listen 포트·업스트림·정책은 프로필마다 다르므로 그대로 복사하지 말고, 본인 파일의 맥락에 맞게 조정합니다.

3단계: 저장 후 재적용·코어 재시작

YAML을 저장한 뒤 Verge에서 프로필 다시 불러오기 또는 코어 재시작을 실행합니다. 빌드마다 버튼 이름이 “Reload”·“Apply”·“Restart Core” 등으로 달라도, 목표는 하나입니다. 실행 중인 Mihomo가 새 dns 블록을 읽게 만든다는 점입니다.

재시작 직후에는 DNS 캐시 때문에 브라우저 탭이 이전 경로를 붙잡는 일이 있습니다. 테스트용 창을 닫았다 다시 열거나, 잠시 다른 브라우저 프로필로 확인하면 헷갈림이 줄어듭니다. Windows 쪽에서 ipconfig /flushdns를 쓰는 습관은 있어도 되지만, Clash 내부 캐시·앱 자체 캐시와는 별층이라 로그를 함께 보는 것이 더 중요합니다.

주의: 회사·학교망 정책, 저작권, 서비스 약관을 위반하는 방식으로 노드나 DNS 우회를 쓰지 마세요. 이 문서는 합법적이고 허용된 네트워크 디버깅을 전제로 합니다.

4단계: Verge 로그로 규칙·출구 확인

모드를 바꾼 뒤에는 연결 로그에서 동일한 사이트를 다시 열어 보고, 어느 규칙 줄에 매칭됐는지와 어느 전략 그룹·노드로 나갔는지를 봅니다. 전략 그룹 글에서 익힌 화면과 연결하면 “DNS는 이렇게 나왔는데 출구는 왜 저 그룹이지?”를 더 빨리 해석할 수 있습니다.

fake-ip일 때 로그에 보이는 IP가 가짜 대역이라면 정상일 수 있습니다. 문제는 그 상태에서 DOMAIN 규칙이 기대한 줄에 걸리는지, 아니면 GEOIP·IPCIDR 같은 다른 줄로 먼저 새는지입니다. redir-host로 바꾼 뒤 같은 사이트를 열었을 때 매칭 줄이 의도대로 안정되면, 증상이 DNS 모드와 스니퍼·규칙 순서의 교차점에 있을 가능성이 큽니다.

5단계: Windows에서 nslookup·브라우저로 교차 검증

명령 프롬프트나 PowerShell에서 nslookup example.com을 실행해 보세요. 이때 어떤 DNS 서버에 질의했는지, 응답이 무엇인지가 중요합니다. Clash가 로컬에서 DNS를 받는 구성이라면 127.0.0.1이나 문서에 적힌 내부 리스너를 가리키는 경우가 많습니다. 반대로 공용 IP의 응답만 보이면 시스템이 Clash 밖으로 질의하는지 의심합니다.

브라우저 개발자 도구의 네트워크 탭에서 동일 호스트의 요청이 어떤 IP로 붙는지 보는 것도 교차 확인에 유효합니다. 다만 TLS·HTTP3·프리커넥트 때문에 “한 번에 이해되지 않는” 패턴도 있어, 로그의 규칙 매칭을 우선 증거로 두는 편이 안전합니다. YouTube·googlevideo처럼 CDN이 복잡한 서비스는 YouTube DNS·분할 글의 관점과도 맞닿아 있습니다.

짧은 자체 점검 체크리스트

운영 중에 빠르게 훑을 수 있도록 순서만 다시 적습니다.

  1. 활성 프로필·TUN/시스템 프록시 상태를 메모해 둔다.
  2. dns.enhanced-mode를 목표 값으로 바꾸고 저장한다.
  3. Verge에서 프로필 재적용 또는 코어 재시작.
  4. 같은 테스트 URL을 열고 로그의 규칙 줄·출구 그룹을 캡처한다.
  5. nslookup으로 질의 경로가 Clash 쪽인지 확인한다.
  6. 증상이 같으면 fake-ip-filter·스니퍼·규칙 순서를 다음 변수로 삼는다.

자주 묻는 질문

TUN을 꺼도 DNS 모드는 적용되나요?

TUN 없이 시스템 프록시만 쓰는 구성이라도, 앱이 프록시 클라이언트를 타며 DNS 질의가 Mihomo로 전달되면 의미가 있습니다. 반대로 일부 네이티브 앱은 시스템 리졸버를 직접 쓰므로 TUN 없이는 Clash DNS가 관여하지 않을 수 있습니다. 따라서 “모드를 바꿨는데 증상이 그대로”라면 어느 앱이 어떤 경로로 질의하는지부터 다시 고릅니다.

fake-ip-filter는 언제 늘리나요?

특정 도메인만 도메인 규칙·스니퍼·실제 연결이 서로 어긋날 때 필요한 FQDN 또는 접미사만 추가합니다. 구독 템플릿에 이미 긴 목록이 있다면, 중복 추가보다 증상 도메인이 목록에 있는지를 먼저 확인하세요.

Windows 11·10 차이가 DNS에 영향을 주나요?

Mihomo의 dns 엔진 자체는 OS와 무관하지만, 멀티 홈·Wi-Fi 호핑·사설 DNS 같은 Windows 네트워크 스택 차이는 간접적으로 증상을 바꿉니다. 문제가 재현될 때마다 “같은 PC·같은 프로필”인지 확인하는 정도면 충분합니다.

마무리

Clash Verge Rev에서 Windows 사용자가 가장 자주 막히는 지점 중 하나가 “규칙 YAML은 맞는데 DNS 한 줄 때문에 화면이 다르게 보인다”는 패턴입니다. fake-ip와 redir-host는 서로 대체재라기보다 트레이드오프가 다른 두 모드이므로, 한 번에 올바른 쪽 하나만 고르기보다 증상에 맞게 전환·검증하는 습관이 더 실용적입니다.

반면 일부 배포판은 DNS·TUN·업데이트 채널이 뭉뚱그려 안내돼, 문제가 났을 때 어느 레이어를 봐야 할지 감이 오지 않습니다. 문서가 흩어지거나 구버전 스크린샷만 돌아다니면 같은 설정도 시간 낭비가 커집니다. ClashSource는 Mihomo·Verge·구독·DNS·분할 규칙을 같은 맥락에서 이어 주는 튜토리얼과 검증된 다운로드 경로를 한곳에 모아, “한 기능만 깊게” 파고들 때도 길을 잃지 않게 돕습니다.

지금 PC에서 모드를 바꿔 보려면 Clash Verge Rev 최신 빌드를 맞춘 뒤, 위 체크리스트 순서만 한 사이클 돌려 보세요. 로그 한 줄과 nslookup 한 번이면 오늘 막히던 DNS 의문이 꽤 줄어듭니다.