Fake-IP과 redir-host 차이: Mihomo DNS 향상 모드 원리와 사용 사례

DNS 향상 모드는 어떤 주소를 반환할지 결정합니다

Mihomo의 dns.enhanced-mode는 내장 DNS의 응답 방식과 이후 연결에서 도메인을 식별하는 방식에 주로 영향을 줍니다. 프록시 모드와는 별개이며, 모든 트래픽이 프록시를 거칠지도 결정하지 않습니다. Rule, Global, Direct는 별도의 설정이고, TUN은 시스템 트래픽을 받아들이는 역할을 합니다.

핵심 차이부터 살펴보겠습니다. fake-ip는 보통 커널이 할당한 가상 IPv4 주소를 앱에 반환하고, redir-host는 상위 DNS에서 조회한 실제 주소를 반환합니다. 두 방식 모두 DNS 요청이 올바른 경로로 전달되어야 합니다. 설정에서 DNS를 활성화하는 것만으로 시스템이나 브라우저가 DNS 요청을 커널에 보내는 것은 아닙니다.

비교 항목	Fake-IP	redir-host
앱이 받는 IPv4 주소	대개 가상 주소	상위 DNS가 조회한 실제 주소
도메인과 연결의 연계	가상 주소 매핑을 통해 복원	DNS 매핑 등의 정보에 의존하며, 필요하면 스니핑을 함께 사용
응답 전 필요한 작업	대상 서버의 실제 주소를 기다리지 않고 먼저 주소 할당 가능	대개 DNS 조회 결과가 필요
대표적인 호환성 문제	앱의 IP 검증, 커널을 우회하는 주소 경로	공유 IP로 도메인을 하나로 특정하기 어려움

Fake-IP 연결 과정과 성능의 한계

가상 주소는 대상 서버의 주소가 아닙니다

일반적인 설정에서는 198.18.0.1/16을 Fake-IP 주소 범위로 사용합니다. 이 주소는 네트워크 벤치마크용으로 예약된 198.18.0.0/15 범위에 속하며, 공용 인터넷에서 정상적으로 라우팅되는 대상 주소도 RFC 1918에서 정의한 사설 주소 대역도 아닙니다. 커널은 할당한 주소와 요청 도메인을 매핑합니다.

앱이 도메인의 A 레코드를 조회하면 요청이 Mihomo DNS로 전달됩니다.
커널이 도메인에 가상 주소를 할당해 앱에 반환합니다.
앱이 가상 주소로 연결을 시도합니다. 연결은 해당 매핑을 보유한 커널을 다시 거쳐야 합니다.
커널이 도메인을 복원하고 규칙을 적용한 다음, 선택된 직접 연결 또는 프록시 출구로 연결합니다.

가상 주소는 해당 매핑과 분리해서 사용할 수 없습니다. 앱이 주소를 커널을 거치지 않는 프로세스에 전달하거나 TUN이 해당 주소의 트래픽을 처리하지 못하면 연결이 실패할 수 있습니다. 클라이언트를 종료한 뒤에도 프로그램이 198.18.x.x에 접속한다면 앱이나 시스템에 이전 결과가 캐시되어 있을 가능성이 큽니다.

DNS 대기 시간을 줄여도 모든 접속이 빨라지는 것은 아닙니다

Fake-IP를 사용하면 실제 DNS 조회를 필요한 시점까지 미룰 수 있습니다. 도메인 규칙이 적용되고 사용하는 프록시 프로토콜이 도메인 전달을 지원한다면 원격에서 대상 주소를 조회할 수 있습니다. DIRECT를 선택하면 커널이 실제 주소를 알아내야 합니다. IP 규칙도 조회를 유발할 수 있으므로 규칙 구성에 따라 실제 효과가 달라집니다.

주로 연결 전에 발생하는 DNS 대기 시간 일부를 줄일 뿐, 실제 네트워크 경로를 짧게 하거나 프록시 서버의 대역폭을 높이지는 않습니다. 게임 지연 시간, 동영상 전송 속도, 패킷 손실률은 여전히 출구, 라우팅, 프로토콜에 좌우됩니다. 이 글에서는 실측 가속률을 제시하지 않습니다. DNS 조회 단계의 변화를 연결 전체의 성능 개선으로 오해하지 않도록 하기 위해서입니다.

redir-host를 선택할 때 고려할 점

redir-host에서는 앱이 실제 DNS 조회 주소를 받으며, 커널은 연결의 도메인을 식별하는 데 사용할 DNS 관련 매핑을 유지합니다. 실제 IP에 의존하는 앱의 기존 네트워크 동작과 더 가깝지만, 도메인과 IP가 항상 일대일로 연결되는 것은 아닙니다. 여러 도메인이 같은 CDN 주소를 공유할 수도 있고, 한 도메인에서 여러 주소가 반환될 수도 있습니다.

먼저 시도해 볼 만한 경우: 앱이 대상 IP를 확인하거나, 다른 기기에 주소를 전달하거나, 여러 네트워크 스택 사이에서 조회 결과를 공유해야 할 때
자동으로 해결되지 않는 문제: 상위 DNS가 잘못된 주소를 반환하거나, 사내 DNS에 연결할 수 없거나, UDP 출구를 사용할 수 없거나, 연결이 커널에 전혀 전달되지 않는 경우
계속 주의해야 할 경우: 앱 자체의 암호화 DNS 때문에 커널이 일반 DNS 요청을 확인하지 못하면 도메인 규칙을 적용할 근거가 부족할 수 있습니다.

스니핑은 일부 TLS, HTTP, QUIC 트래픽에서 도메인 정보를 보완할 수 있지만, 모든 프로토콜에서 쓸 수 있는 도메인을 얻을 수 있는 것은 아닙니다. 암호화 방식, 클라이언트 구현, 스니핑 설정에 따라 결과가 달라집니다. 스니핑을 켜면 모든 도메인 라우팅 문제가 해결된다고 생각하지 마세요.

fake-ip-filter: 필요한 도메인만 제외하기

fake-ip-filter는 어떤 도메인에 가상 주소를 할당하지 않을지 지정합니다. blacklist 모드에서는 목록에 일치하는 도메인이 실제 DNS 조회를 사용하고, 나머지 도메인에는 Fake-IP를 할당할 수 있습니다. Mihomo는 다른 필터 모드도 지원하므로 설정을 확인할 때는 목록뿐 아니라 fake-ip-filter-mode도 함께 살펴봐야 합니다.

아래는 DNS 설정 예시입니다. 수신 주소 127.0.0.1:1053은 로컬 기기에서만 접속할 수 있습니다. 전체 TUN 설정이 아니며 시스템 DNS를 자동으로 바꾸지도 않습니다. 기존 설정에 dns:가 있다면 최상위 키가 중복되지 않도록 필드를 병합하세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - '+.home.arpa'
    - '+.lan'
  nameserver:
    - 1.1.1.1
    - 9.9.9.9

가상 주소를 제외해도 직접 연결되는 것은 아닙니다

+.home.arpa는 해당 도메인과 하위 도메인에 모두 일치합니다. 여기서는 홈 네트워크 도메인 처리 예시로 사용했습니다. .lan은 일부 로컬 네트워크에서 사용하는 접미사입니다. 필터 목록은 DNS 응답 방식만 바꿀 뿐, DIRECT 규칙을 추가하거나 요청을 라우터로 보내지 않습니다.

따라서 사내 네트워크에 접속하려면 보통 세 가지가 모두 필요합니다. 실제 주소를 반환하고, 올바른 사내 DNS에 질의하고, 연결을 접근 가능한 사내 네트워크 출구로 라우팅해야 합니다. 첫 번째만 설정하면 공용 DNS에서 도메인이 없다는 오류가 반환될 수 있습니다.

LAN 및 기업 내부망 DNS 설정

홈 네트워크에서 192.168.50.53을 사내 DNS 주소로 사용하고 기기 이름이 nas.home.arpa라고 가정해 보겠습니다. 앞에서 설명한 dns: 아래에 다음 필드를 추가할 수 있습니다. 이 주소는 네트워크 구성을 설명하기 위한 예시입니다. 적용하기 전에 현재 네트워크에서 실제로 연결 가능한 DNS 주소로 바꾸세요.

  nameserver-policy:
    '+.home.arpa':
      - 192.168.50.53

기존 rules:에는 LAN 규칙을 마지막 기본 규칙보다 앞에 추가해야 합니다. 아래 두 규칙은 각각 도메인과 예시 IP 대역에 적용됩니다. 기존 구독 규칙을 덮어쓰거나 정책 그룹을 삭제하지 마세요.

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,PROXY

마지막 줄은 설정에 PROXY라는 정책 그룹이 이미 있다고 가정합니다. 실제 이름은 현재 설정과 일치해야 합니다. no-resolve는 이 IP 규칙만을 위해 도메인을 별도로 조회하지 않게 합니다. 원래 조회할 수 없던 사내 도메인을 사용할 수 있게 만드는 옵션은 아닙니다.

기업 VPN과 .local 이름은 별도로 처리하세요

기업 VPN: 사내 DNS로 가는 경로가 기업 VPN을 통과하는지 확인하세요. TUN과 기업 VPN이 동시에 라우팅을 처리한다면 대역 충돌, 라우팅 우선순위, 클라이언트에서 제공하는 우회 설정을 점검해야 합니다.
짧은 호스트 이름: nas 입력은 시스템 검색 도메인에 의존할 수 있습니다. 검색 도메인 누락을 Fake-IP 문제로 오해하지 않도록 먼저 전체 도메인 이름으로 테스트하세요.
.local: mDNS에 주로 사용되며 보통 UDP 5353 포트와 멀티캐스트를 이용합니다. 일반 DNS 필터 항목을 추가해도 mDNS가 연결되는 것은 아닙니다. LAN 기기 검색 방식과 멀티캐스트 경로를 확인하세요.
네트워크 간 이동: 회사나 홈 네트워크를 벗어나면 기존 사내 DNS에 연결할 수 없을 수 있습니다. 도메인별 라우팅 범위를 유지하고 모든 DNS 요청을 사내 서버로 보내지 않도록 하세요.

게임에서 TUN 모드를 선택하는 순서

일반 웹페이지는 열리는데 게임 로그인이 안 된다고 해서 Fake-IP 비호환이라고 단정할 수는 없습니다. 게임은 HTTPS 로그인, UDP 대전, 음성 채팅, LAN 기기 검색을 함께 사용할 수 있습니다. 시스템 프록시는 이 모든 트래픽을 처리하지 못하는 경우가 많습니다. TUN은 더 많은 IP 트래픽을 처리할 수 있지만 권한, 라우팅, UDP 출구 지원도 필요합니다.

먼저 연결이 커널에 들어오는지 확인하세요. 클라이언트의 연결 목록이나 로그를 연 뒤 게임을 실행합니다. 해당 연결이 전혀 보이지 않으면 필터 목록을 수정하기보다 트래픽을 받아들이는 방식을 먼저 점검하세요.
로그인과 대전을 구분하세요. 로그인이 실패하면 인증 도메인을 기록하고, 방에 들어간 뒤 연결이 끊기면 UDP, 출구 정책, NAT 동작을 확인하세요. 두 문제는 서로 다른 경로에서 발생할 수 있습니다.
실제 주소가 필요한지 확인하세요. 로그에서 특정 도메인이 가상 주소를 받은 뒤 연결에 실패한 것을 확인했다면 해당 도메인만 필터 목록에 추가하세요. 출구와 다른 조건은 그대로 유지한 채 다시 테스트합니다.
마지막으로 모드를 비교하세요. 임시로 redir-host로 전환하고 설정을 다시 불러온 뒤 캐시를 비우세요. 같은 네트워크와 같은 출구를 사용해 비교해야 모드 호환성을 판단하는 데 도움이 됩니다.

TUN을 사용할 때는 DNS 하이재킹 설정이 실제 DNS 요청을 처리하는지 확인하세요. 일반적인 DNS는 53번 포트를 사용하지만 브라우저의 DoH는 보통 HTTPS 443번 포트로 요청을 보냅니다. 53번 포트만 처리해서는 암호화 DNS를 모두 가로챌 수 없습니다. 테스트가 필요하면 브라우저의 보안 DNS를 잠시 끄고 기존 설정을 기록해 둔 다음, 테스트가 끝나면 필요에 따라 복원하세요.

결과 확인 및 설정 복구

먼저 커널 DNS를 확인한 뒤 시스템 연결을 점검하세요

앞서 설명한 로컬 1053번 포트를 사용한다면 dig가 설치된 macOS 또는 Linux에서 다음 명령을 실행할 수 있습니다. 첫 번째 명령은 일반 도메인이 가상 주소를 받는지 확인합니다. 두 번째 명령은 사내 도메인이 올바른 DNS에서 실제 주소를 받는지 확인합니다. 사내 이름은 현재 네트워크에 실제로 등록된 레코드를 사용하세요.

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 nas.home.arpa A

이 명령은 지정한 포트로 직접 질의하므로 커널 DNS의 응답은 확인할 수 있지만, 시스템과 브라우저도 해당 DNS를 사용하는지는 알 수 없습니다. 이어서 실제 앱에서 연결을 시도하고 클라이언트 로그에서 도메인, 대상 주소, 적용된 규칙, 출구를 확인하세요. 직접 질의는 정상인데 브라우저 동작이 다르면 브라우저 DNS, 시스템 캐시, 앱 캐시를 먼저 점검하세요.

모드 전환 후 이전 상태 정리하기

현재 설정을 백업하고, DNS 모드나 필터 항목을 한 번에 하나씩만 변경하세요.
설정을 다시 불러오세요. 클라이언트에 DNS 캐시나 Fake-IP 매핑을 지우는 기능이 있다면 해당 메뉴에서 실행하세요.
Windows에서는 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 비울 수 있습니다.
macOS에서는 sudo dscacheutil -flushcache를 실행한 다음 sudo killall -HUP mDNSResponder를 실행하세요. 이 작업으로 브라우저 자체 캐시까지 지워진다고 보장할 수는 없습니다.
이전 연결과 주소가 비교 결과에 영향을 주지 않도록 문제가 있는 앱을 완전히 종료한 뒤 다시 실행하세요.

평소 도메인 규칙으로 트래픽을 분기하고 연결이 온전히 커널을 통과한다면 우선 Fake-IP를 사용해 보세요. 일부 사내 네트워크나 앱에서 호환성 문제가 생기면 도메인별 예외를 추가하고 올바른 DNS 서버를 설정하는 것이 좋습니다. 앱이 계속 실제 IP에 의존하거나 예외를 관리하기 어렵거나 비교 테스트에서 모드 차이가 분명할 때 전체 redir-host 전환을 고려하세요.

트래픽 경로를 더 확인하려면 연결 확인 절차를 참고하세요. DNS, 규칙, 유지 관리 설정을 구분하려면 DNS 설정 안내를 읽어 보세요. 확인할 것은 언제나 DNS 요청이 어디로 갔는지, 어떤 응답을 받았는지, 연결이 최종적으로 어떤 출구를 사용했는지입니다.