먼저 구분할 점: DNS 응답과 실제 연결
휴대폰에서 웹사이트를 열면 앱은 보통 먼저 도메인에 해당하는 IP 주소를 조회한 다음 연결을 시작합니다. Clash Meta(mihomo)의 DNS 기능을 지원하는 클라이언트에서 enhanced-mode: fake-ip를 사용하면 DNS 응답 방식이 달라집니다. 코어가 도메인에 임시 합성 주소를 할당하고 ‘도메인 ↔ 합성 주소’ 매핑을 저장한 뒤, 해당 주소를 앱에 반환합니다.
이후 앱은 해당 주소로 연결을 시도합니다. 클라이언트가 트래픽을 가로채면 코어는 매핑을 통해 원래 도메인을 찾아 규칙을 적용하고, 규칙에 따라 직접 연결하거나 프록시를 사용합니다. 합성 주소는 클라이언트 내부에서 사용하는 색인일 뿐 웹 서버의 실제 주소가 아니며, 인터넷에서 접속할 수 있는 대상으로 취급해서는 안 됩니다.
요청은 어떤 과정을 거칠까
- 앱이
example.com의 A 레코드를 조회합니다. 이 요청은 클라이언트의 DNS 처리 경로를 거쳐야 합니다. - 코어는 설정된 Fake-IP 주소 대역에서 주소 하나를 반환하고, 해당 주소와
example.com의 매핑을 저장합니다. - 앱이 해당 주소로 연결을 시도하면 클라이언트가 연결을 가로챕니다. 도메인을 확인한 뒤
DOMAIN,DOMAIN-SUFFIX등의 규칙을 적용합니다. - 코어는 선택한 아웃바운드 방식으로 대상 연결을 처리합니다. 프록시 아웃바운드가 도메인을 통해 연결할 수 있는지는 프로토콜, 노드, 클라이언트의 구체적인 구현에 따라 달라집니다.
따라서 ‘DNS 응답을 받음’과 ‘대상에 연결됨’은 별개의 일입니다. Fake-IP를 사용하면 앱이 이후 규칙 적용에 쓸 주소를 더 일찍 받을 수 있지만, 실제 아웃바운드 연결에는 여전히 규칙 판단, 노드 연결, 대상 서비스의 응답이 필요합니다. 앱이 숫자 IP에 직접 연결하거나 DNS 요청이 클라이언트를 거치지 않는 경우, 또는 이후 연결이 가로채지지 않는 경우에는 도메인 매핑이 정상적으로 작동하지 않습니다.
Fake-IP와 redir-host: 실제 DNS 조회는 언제 이루어질까
redir-host는 보통 앱에 DNS 응답을 보내기 전에 상위 DNS 서버에서 대상의 실제 IP를 조회한 뒤 그 결과를 반환합니다. fake-ip는 먼저 합성 주소를 반환하고, 이후 가로챈 연결에서 매핑을 통해 도메인을 복원합니다. 핵심 차이는 ‘DNS를 사용하느냐’가 아니라, 앱이 DNS 응답을 기다릴 때 대상 도메인의 실제 IP 조회 결과까지 기다려야 하는 경우가 많은지 여부입니다.
| 비교 항목 | Fake-IP | redir-host |
|---|---|---|
| 앱에 반환되는 주소 | 도메인에 매핑된 합성 주소 | 상위 DNS 조회로 얻은 실제 주소 |
| 도메인 규칙을 적용하는 기준 | 합성 주소에 대응하는 매핑 기록 | DNS 조회 기록. 다른 상황에서는 프로토콜 스니핑이 필요할 수도 있음 |
| 일반적인 장단점 | 앱이 DNS 응답을 더 일찍 받을 수 있지만, 이후 연결을 제대로 가로채야 함 | 앱이 실제 주소를 바로 받지만, 상위 DNS 조회 결과를 기다리느라 응답이 늦어질 수 있음 |
‘첫 응답 대기 시간 단축’은 앱이 DNS 단계에서 실제 주소 조회 결과를 기다리는 상황을 줄인다는 뜻이지, 모든 웹 요청이 더 빨라진다는 뜻은 아닙니다. 병목이 노드 핸드셰이크, 패킷 손실, 대상 사이트의 응답 또는 앱 자체의 시작 과정에 있다면 DNS 모드를 바꿔도 첫 응답 시간은 개선되지 않을 수 있습니다. 직접 연결하는 대상도 결국 실제 IP 조회가 필요할 수 있습니다. 이때 걸리는 시간은 이후 처리 단계로 옮겨갈 뿐, 전체 소요 시간에서 사라지는 것은 아닙니다.
모드를 비교할 때는 같은 네트워크, 같은 노드, 같은 대상을 사용하세요. 먼저 앱이 안정적으로 연결되는지 확인한 다음 대기 시간을 비교하세요. DNS 응답이 빠르다는 이유로 페이지 로딩 전체가 빨라졌다고 판단하지 마세요.
예약 주소 대역과 매핑 테이블의 작동 방식
mihomo 설정에서 fake-ip-range의 예시로 흔히 198.18.0.1/16을 사용합니다. 198.18.0.0/15는 네트워크 장비 벤치마크용으로 예약된 IPv4 주소 공간으로, 일반적인 공인 웹사이트 주소가 아닙니다. 이 대역의 일부를 로컬 합성 주소로 사용하면 코어가 해당 연결을 식별하기 쉽습니다. 구체적인 주소 대역은 현재 사용 중인 클라이언트 설정을 따르세요.
매핑 테이블은 실행 중인 코어가 관리하며, 영구적으로 보관되는 웹사이트 IP 목록이 아닙니다. 같은 합성 주소가 실행 시점이 달라도 늘 같은 도메인에 대응한다고 가정해서는 안 됩니다. 합성 주소를 다른 기기에 복사하거나 장기간 사용할 앱 설정에 입력하는 방법, 클라이언트를 재시작한 뒤 그 주소만으로 연결을 테스트하는 방법은 원래 도메인의 상태를 신뢰성 있게 보여주지 않습니다.
최소한의 DNS 설정 예시
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- 223.5.5.5
fake-ip-filter:
- '*.lan'
- printer.home.arpa아래 YAML은 필드의 위치를 보여주는 예시이며, 모든 네트워크에 그대로 적용할 수 있는 완전한 설정은 아닙니다. nameserver의 주소는 설명을 위한 예시이므로 사용 중인 네트워크, 구독 설정, 실제 연결 가능 여부에 맞춰 DNS 서버를 선택하세요. fake-ip-filter에는 합성 주소를 반환하지 않을 도메인을 지정합니다. 구체적인 매칭 문법과 클라이언트에서 해당 필드를 편집할 수 있는지는 사용 중인 코어 및 클라이언트 버전에 따라 다릅니다. 수정할 때는 들여쓰기를 공백 2칸으로 유지하고 원본 설정을 먼저 백업하세요.
enhanced-mode를 fake-ip로 바꾸는 것만으로는 작동이 보장되지 않습니다. 앱의 DNS 요청이 클라이언트를 거쳐야 하고, 합성 주소로 향하는 이후 트래픽도 가로채야 합니다. 모바일에서는 보통 시스템 VPN 설정, 클라이언트의 DNS 설정, 선택한 프록시 모드도 관련됩니다. 일부 클라이언트는 그래픽 인터페이스에서 이 설정을 관리하므로 사용자가 수정한 YAML을 직접 읽지 않을 수 있습니다.
어떤 대상을 필터 목록에 추가해야 할까
판단 기준은 대상 앱이 실제 주소를 받아야 하는지, 그리고 연결이 계속 같은 클라이언트 코어를 거칠 수 있는지입니다. 모든 도메인을 무작정 필터 목록에 추가하지 마세요. 필터 범위가 넓을수록 더 많은 조회가 실제 주소를 기다리는 경로로 돌아가므로, 줄이려던 DNS 대기 시간이 다시 늘어날 수 있습니다.
LAN 기기: 먼저 도메인을 어디서 조회하는지 확인
프린터, NAS, 라우터는 printer.lan, nas.home.arpa 같은 내부 네트워크 이름을 사용하는 경우가 많습니다. 기기 관리 앱에 실제 LAN 주소가 필요한데 합성 주소가 반환됐다면, 먼저 해당 기기의 정확한 도메인을 필터에 추가한 다음 현재 DNS 상위 서버가 내부 이름을 조회할 수 있는지 확인하세요. 필터는 Fake-IP 반환 여부만 바꿉니다. 공용 DNS 서버가 프린터 주소를 알지 못한다면 필터만 추가해도 이름 조회는 되지 않습니다.
.local 이름은 일반 DNS 요청을 거치지 않고 mDNS로 LAN에서 검색되는 경우가 많습니다. ‘기기 목록에는 보이지만 눌러도 연결되지 않는’ 문제가 생기면 LAN 접근 권한, mDNS 검색, 실제 연결에 사용되는 도메인이나 IP, 프록시 규칙을 각각 확인하세요. 앱이 192.168.1.1에 직접 접속한다면 Fake-IP 필터 목록은 IP를 직접 사용하는 이 연결에 영향을 주지 않습니다.
게임과 일부 앱: 문제가 생긴 도메인을 하나씩 확인
게임 로그인, 매칭, 음성 채팅은 서로 다른 도메인과 UDP 연결을 사용할 수 있습니다. 계정 로그인, 방 매칭, 실시간 통신 중 어느 단계에서 멈추는지 먼저 구분하세요. Fake-IP에서 특정 도메인만 문제가 생기고 실제 DNS 조회로 바꾸면 해결된다면 해당 도메인만 필터에 추가합니다. 일부 앱은 조회 결과를 캐시하므로 설정을 바꾼 뒤에는 앱을 완전히 종료하고 다시 열어야 합니다. 필요한 경우 클라이언트도 다시 연결해 기존 연결과 캐시가 테스트에 영향을 주지 않게 하세요.
‘게임이 UDP를 사용한다’는 이유만으로 Fake-IP를 꺼야 하는 것은 아닙니다. UDP 트래픽의 정상 작동 여부는 클라이언트의 트래픽 가로채기 방식, 노드 프로토콜, 규칙, 서버의 영향을 받습니다. 숫자 IP, LAN 브로드캐스트, 기기 검색 기능을 사용하는 경우에는 도메인 필터가 아예 관련 없을 수도 있습니다. 이때 도메인을 계속 추가하면 설정만 복잡해집니다.
iPhone에서 문제를 확인하는 순서
DNS 모드를 바꾼 뒤 접속이 안 되거나 특정 앱이 계속 로딩되거나 내부 네트워크 기기가 오프라인으로 표시된다면 ‘시스템 가로채기 → DNS 응답 → 연결 규칙 → 개별 앱’ 순서로 점검하세요. 노드, 구독, DNS 상위 서버를 한꺼번에 바꾸는 것보다 원인을 찾기 쉽습니다.
- VPN이 연결되어 있는지 확인하세요. iPhone에서 ‘설정’ → ‘일반’ → ‘VPN 및 기기 관리’ → ‘VPN’으로 이동해 연결 상태를 확인한 다음, 클라이언트로 돌아와 예상한 설정을 사용 중인지 확인하세요. 시스템 메뉴 이름은 iOS 버전에 따라 다를 수 있습니다.
- 설정이 실제로 활성화되었는지 확인하세요. 현재 Profile의 DNS 모드, Fake-IP 주소 대역, 규칙 모드를 확인합니다. 구독을 업데이트한 뒤 다른 Profile로 전환됐다면 실제로 활성화된 설정에서 값을 확인하세요.
- 모든 곳에서 생기는 문제인지 특정 항목만의 문제인지 구분하세요. 모든 웹사이트에 접속할 수 없다면 먼저 DNS 상위 서버의 연결 상태, VPN 가로채기, 노드를 확인하세요. NAS 하나나 앱 하나에서만 문제가 발생한다면 해당 앱이 접속하는 도메인이나 LAN 주소를 먼저 기록하세요.
- 한 번에 한 가지만 변경하세요. 확인된 내부 도메인을 필터에 추가하고 다시 연결한 뒤 대상을 재확인하세요. 변화가 없다면 해당 설정을 되돌리고 LAN 이름 조회, 직접 연결 규칙, 앱 권한을 확인하세요.
규칙 모드와 DNS 모드는 서로 다른 역할을 합니다. 전자는 요청에 사용할 아웃바운드를 결정하고, 후자는 이름 조회 및 응답 방식에 영향을 줍니다. 도메인을 DIRECT 규칙에 추가해도 앱이 실제 IP를 받는 것은 아닙니다. 마찬가지로 도메인을 Fake-IP 필터에 추가해도 자동으로 직접 연결되지는 않습니다. 내부 도메인의 실제 주소 조회와 직접 연결이 모두 필요하다면 두 설정을 따로 확인하세요.
합성 주소가 대상 기능에 영향을 준다는 점을 확인한 경우에만 필터를 추가하세요. 원래 설정을 복사해 두고 변경한 도메인과 증상을 기록한 뒤, 다시 테스트해 문제가 해결된 경우에만 규칙을 유지하세요.