1. DNS 모드와 트래픽 가로채기는 별개의 설정입니다
dns.enhanced-mode는 엔진이 DNS 조회에 응답하는 방식을 결정하고, 시스템 프록시와 TUN은 앱 연결이 엔진으로 전달되는 방식을 결정합니다. 두 설정은 서로 대신할 수 없습니다. Fake-IP를 켰다고 시스템의 모든 DNS 요청이 가로채지는 않으며, TUN을 켰다고 브라우저 자체의 암호화 DNS 조회까지 반드시 엔진에서 처리되는 것도 아닙니다.
이 글에서는 mihomo 엔진을 사용하는 Clash 클라이언트를 다룹니다. 구버전 Clash, 엔진 포크, 클라이언트의 설정 덮어쓰기 기능에 따라 동작이 다를 수 있습니다. 설정을 바꾸기 전에 현재 설정을 백업하고 엔진 버전을 기록한 다음, 구독 원본 파일만 보지 말고 실제 적용된 설정의 dns 항목을 확인하세요.
- 시스템 프록시: 앱이 HTTP 프록시에 도메인 이름을 전달하면 엔진은 대상 도메인을 바로 알 수 있습니다. 따라서 로컬 DNS의 Fake-IP 매핑에 의존하지 않을 수도 있습니다.
- TUN: 앱에서 나온 IP 패킷을 받습니다. DNS 가로채기와 매핑 테이블은 원래 도메인을 복원할 때 특히 중요합니다.
- DNS 리스너: 예를 들어
127.0.0.1:1053은 엔진이 DNS 요청을 받는 주소일 뿐입니다. 시스템의 DNS 요청이 적절한 전달 또는 가로채기 경로를 통해 이곳으로 와야 합니다.
설정이 적용됐는지 확인하려면 ‘DNS 요청이 어디로 전달되는지’와 ‘그다음 연결이 어디로 향하는지’를 따로 점검해야 합니다. 클라이언트의 기본 스위치만 보고 두 경로가 일치하는지 판단할 수는 없습니다.
2. Fake-IP 주소 할당과 도메인 역추적 과정
Fake-IP의 핵심은 ‘도메인과 가상 IP’의 매핑을 만드는 것입니다. 앱에서 도메인의 IPv4 주소를 조회하면 엔진은 실제 A 레코드 응답을 기다리지 않고 fake-ip-range로 지정한 주소 풀에서 IP를 할당해 반환할 수 있습니다. 흔히 쓰이는 주소 풀은 198.18.0.1/16이며, 벤치마크용으로 예약된 주소 대역이지 웹사이트의 공인 IP가 아닙니다.
- 앱이
example.com을 조회하면 요청이 mihomo DNS로 전달됩니다. - 엔진은 주소 풀에서 가상 IP를 하나 반환하고, 해당 IP가
example.com에 대응한다는 매핑을 저장합니다. 실제 할당 주소는 실행 중인 상태에 따라 달라지므로 설정에 고정값으로 적지 마세요. - 앱이 이 가상 IP에 연결하면 연결은 TUN 등 트래픽 가로채기 경로를 통해 같은 엔진 인스턴스로 전달됩니다.
- 엔진은 매핑 테이블에서 도메인을 복원한 다음 규칙에 따라 직접 연결하거나 프록시로 전송합니다.
- 직접 연결할 때는 보통 실제 대상 IP를 다시 조회해야 합니다. 프록시가 도메인 전달을 지원하면 도메인 자체를 원격 서버에 넘길 수 있습니다. 실제 동작은 규칙, 노드 프로토콜, 관련 DNS 설정에 따라서도 달라집니다.
대기 시간이 줄어들 수 있는 이유
도메인으로 분기한 뒤 도메인 정보를 프록시에 전달할 수 있는 연결이라면, 로컬에서 대상 웹사이트의 실제 IP를 먼저 조회하지 않아도 됩니다. 따라서 로컬 DNS 응답이 느리거나 방해받더라도 첫 연결이 반드시 지연되는 것은 아닙니다. 다만 Fake-IP가 노드 핸드셰이크, 원격 DNS 조회, 서버 응답 시간을 줄여 주는 것은 아니며 모든 웹사이트의 속도 향상을 보장하지도 않습니다.
매핑이 사라지면 연결이 끊기는 이유
가상 IP는 매핑을 보유한 엔진 안에서만 의미가 있습니다. 앱이 이전 IP를 캐시했는데 엔진을 재시작한 뒤 매핑이 복원되지 않으면 다음 연결에서 도메인을 찾지 못할 수 있습니다. 클라이언트나 DNS 모드를 바꾸거나 트래픽을 다른 게이트웨이로 보내도 같은 문제가 생길 수 있습니다. 이때는 가상 IP에 일반 직접 연결 규칙을 추가하는 대신 DNS를 다시 조회해야 합니다.
3. redir-host의 DNS 응답 시점과 규칙 매칭 차이
redir-host는 보통 먼저 상위 DNS 서버에 조회한 다음 실제 IP 주소를 앱에 반환합니다. 엔진은 자체 DNS를 거친 조회 결과를 바탕으로 도메인과 IP의 연관 정보를 저장하고, 이후 연결에서 도메인을 복원하는 데 활용합니다. 앱에 실제 IP가 보이므로 호환성 면에서 유리하지만, 실제 IP와 도메인이 항상 일대일로 대응하는 것은 아닙니다.
| 비교 항목 | Fake-IP | redir-host |
|---|---|---|
| 앱에 반환되는 A 레코드 | 대체로 주소 풀의 가상 IP | 대체로 상위 DNS가 반환한 실제 IP |
| 첫 조회에 걸리는 시간 | 가상 IP 할당에는 보통 실제 대상 IP 조회가 필요하지 않음 | 보통 상위 DNS의 응답을 기다려야 함 |
| 도메인 복원에 사용하는 정보 | 가상 IP에 연결된 매핑 | DNS 조회 기록과 실제 IP의 연관 정보 |
| 공유 IP의 영향 | 도메인별로 각각 매핑 가능 | 여러 도메인이 같은 IP를 쓰면 연관 정보를 특정하기 어려울 수 있음 |
| 앱에서 자체 암호화 DNS를 사용하는 경우 | 가상 IP 할당을 우회할 수 있음 | 엔진의 DNS 연관 기록을 우회할 수 있음 |
| 로컬 네트워크 서비스 호환성 | 내부 도메인을 필터에 추가해야 하는 경우가 많음 | 실제 내부 IP를 반환하는 편이 대체로 간편함 |
규칙에 따라서도 DNS 조회 시점이 달라집니다. Fake-IP를 사용하더라도 대상의 실제 IP가 필요한 규칙을 처리할 때 엔진이 DNS 조회를 시작할 수 있습니다. IP-CIDR 같은 규칙의 no-resolve 옵션은 해당 규칙을 위해 도메인을 직접 조회하지 않도록 할 수 있지만, ‘연결 전체에서 DNS 조회를 금지하는’ 전역 스위치는 아닙니다. 규칙 순서, 실제 IP를 이미 알고 있는지, 다른 규칙의 동작까지 함께 확인하세요.
프로그램이 도메인 조회 없이 IP에 직접 연결하면 두 DNS 모드 모두 원래 도메인을 알아낼 수 없습니다. 트래픽 스니핑으로 일부 프로토콜의 핸드셰이크에서 도메인을 추출할 수는 있지만, DNS 매핑을 그대로 대체하지 못하고 모든 암호화 프로토콜을 지원하는 것도 아닙니다.
4. Fake-IP와 DNS 유출의 관계
DNS 유출은 보통 예상한 경로로 조회가 전달되지 않는 상황을 말합니다. 예를 들어 지정한 DNS 서버를 사용해야 하는 요청이 접속한 네트워크에서 제공하는 DNS 서버로 전송되는 경우입니다. Fake-IP는 프록시 대상 도메인의 일부 로컬 실제 IP 조회를 줄일 수 있지만, 모든 DNS 유출을 막는 기능은 아닙니다. redir-host도 반드시 DNS 유출을 일으키는 것은 아닙니다. 유출 여부는 DNS 가로채기 범위, 상위 DNS 프로토콜, 트래픽의 출구 선택에 따라 달라집니다.
- 브라우저 보안 DNS: 브라우저가 HTTPS로 외부 DNS 서버에 직접 조회하면 시스템 DNS를 우회할 수 있습니다. 문제를 확인할 때는 이 기능을 잠시 끄고 결과를 비교해 보세요.
- 일반 UDP/TCP DNS: 보통 포트 53을 사용합니다. TUN의 DNS 가로채기는 조건에 맞는 요청을 처리할 수 있지만, HTTPS 443이나 TLS 853을 사용하는 암호화 DNS 요청에 포트 53 규칙을 그대로 적용할 수는 없습니다.
- IPv6: A 레코드만 확인해서는 충분하지 않습니다. AAAA 조회, IPv6 라우팅, 앱 연결도 점검해야 합니다. IPv4 Fake-IP 주소 풀이 있다고 해서 IPv6 경로까지 가로채고 있다고 볼 수는 없습니다.
- 부트스트랩 및 노드 DNS 조회: 암호화 DNS 서버의 도메인과 프록시 노드 서버의 도메인은 별도 경로로 조회될 수 있습니다.
default-nameserver,proxy-server-nameserver등의 항목을 확인하세요.
DoH는 DNS 서버와 주고받는 조회를 암호화하지만, 연결이 자동으로 프록시를 통과하도록 하거나 DNS 서버가 도메인을 볼 수 없게 하지는 않습니다. DNS 테스트 사이트에 표시되는 운영자는 해당 사이트가 관찰한 DNS 요청의 출구일 뿐입니다. 엔진 로그와 네트워크 캡처도 함께 확인해 실제 DNS 서버와 연결 경로를 점검하세요.
5. fake-ip-filter 설정과 로컬 네트워크 예외
fake-ip-filter는 어떤 도메인에 일반적인 Fake-IP 응답을 적용하지 않을지 지정합니다. 아래 예시에서는 mihomo의 blacklist 필터 모드를 명시적으로 사용합니다. 목록에 있는 도메인에는 실제 DNS 조회 결과를 반환하고, 나머지 도메인에는 가상 IP를 할당할 수 있습니다. 구버전 엔진이 fake-ip-filter-mode를 지원하지 않는다면 해당 버전의 문서를 먼저 확인하고 이 항목을 그대로 적용하지 마세요.
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:
- "*.lan"
- "*.home.arpa"
- "router.home.arpa"
nameserver:
- 223.5.5.5
nameserver-policy:
"+.lan": 192.168.1.1
"+.home.arpa": 192.168.1.1이 예시는 설정 항목 간의 관계를 보여 주기 위한 것으로, 전체 설정을 덮어쓸 수 있는 구독 파일이 아닙니다. 192.168.1.1은 내부 도메인 조회를 실제로 처리하는 라우터라고 가정한 주소입니다. 사용 전에 현재 네트워크의 내부 DNS 주소로 바꾸세요. 예시의 공용 DNS 서버는 동작 과정을 확인하기 위해 일반 DNS를 사용하며, 암호화 또는 프록시 DNS 구성을 뜻하지 않습니다. listen을 설정해도 시스템 DNS가 자동으로 변경되지는 않습니다.
필터, DNS 조회 정책, 출구 규칙은 각각 다른 역할을 합니다
fake-ip-filter: 목록에 해당하는 도메인에 가상 IP를 반환하지 않도록 합니다. 직접 연결을 지정하는 기능은 아닙니다.nameserver-policy: 내부 도메인에 응답할 수 있는 DNS 서버를 지정합니다. 공용 DNS 서버는 기업이나 가정 네트워크의 비공개 레코드를 모르는 경우가 많습니다.rules: 연결의 출구를 결정합니다. 내부 서비스가 실제 IP를 받더라도 적절한 직접 연결 규칙과 도달 가능한 경로가 필요합니다.
예를 들어 광범위한 프록시 규칙보다 앞에 다음 두 규칙을 배치할 수 있습니다. 두 규칙은 출구 선택만 처리하며 DNS 정책을 대신하지 않습니다. 예시를 적용하려고 기존 규칙을 삭제하지 마세요.
rules:
- DOMAIN-SUFFIX,home.arpa,DIRECT
- DOMAIN-SUFFIX,lan,DIRECT로컬 네트워크 서비스가 영향을 받기 쉬운 이유
NAS, 프린터, 화면 전송, 일부 게임의 기기 검색 기능은 대상이 로컬 네트워크에 있는지 확인하거나 DNS 응답을 다른 기기에 전달할 수 있습니다. 198.18.0.0/16 대역의 IP를 받으면 앱이 연결을 거부할 수 있으며, 같은 매핑을 공유하지 않는 다른 기기에서도 해당 주소를 사용할 수 없습니다. 우선 실제로 사용하는 내부 도메인만 필터에 추가하고 처음부터 모든 도메인을 제외하지는 마세요.
.local은 일반 유니캐스트 DNS뿐 아니라 멀티캐스트 검색에 쓰이는 mDNS 도메인입니다. *.local을 필터 목록에 넣어도 mDNS가 자동으로 복구되지는 않습니다. 화면 전송 기기가 검색되지 않으면 로컬 네트워크 접근 권한, 멀티캐스트 전달, TUN 라우팅, 방화벽도 함께 확인하세요. 라우터를 통해 다른 기기에 DNS를 제공한다면, 해당 기기의 가상 IP 대상 트래픽도 매핑을 보유한 게이트웨이를 통과해야 합니다.
6. DNS 응답과 연결 가로채기 확인
먼저 지정된 리스너 주소로 엔진 DNS를 확인한 다음 시스템의 기본 DNS 경로를 점검하세요. 아래 명령은 해당 도구가 있는 시스템에서 사용할 수 있습니다. 조회 포트 1053은 실제 실행 설정과 일치해야 합니다.
# Windows: 엔진 DNS에 직접 조회
nslookup -port=1053 example.com 127.0.0.1
# macOS / Linux: 엔진 DNS에 직접 조회
dig @127.0.0.1 -p 1053 example.com A
# 내부 도메인이 실제 내부 IP를 반환하는지 확인
dig @127.0.0.1 -p 1053 router.home.arpa A- DNS 응답 확인: 필터에 없는 도메인은 Fake-IP 모드 설정에 따라 주소 풀의 IP를 반환해야 합니다. 필터에 추가한 내부 도메인은 내부 DNS가 제공하는 실제 IP를 반환해야 합니다. 조회 시간이 초과되면 먼저 리스너와 엔진 실행 상태를 확인하세요.
- 시스템 경로 확인: 다음으로 서버를 지정하지 않은
nslookup example.com을 실행하거나 일반 앱에서 접속해 보세요. 엔진에 직접 조회가 성공해도 시스템 DNS 요청이 엔진에 전달된다는 뜻은 아닙니다. - 연결 기록 확인: 클라이언트의 연결 화면이나 로그에서 도메인, 매칭된 규칙, 출구를 확인하세요. DNS 조회는 되지만 연결되지 않는다면 트래픽이 같은 엔진으로 전달되는지, 규칙이 잘못된 노드를 선택하지 않는지 살펴보세요.
- IPv6 별도 확인: AAAA 레코드를 조회하고 앱이 실제로 사용하는 주소 유형을 확인하세요. A 레코드가 정상이라는 이유만으로 전체 DNS 경로가 정상이라고 판단하지 마세요.
문제 해결 중에는 log-level을 잠시 debug로 설정할 수 있습니다. 확인이 끝나면 평소 수준으로 되돌려 도메인 정보가 장시간 대량 기록되지 않도록 하세요. 로그를 공유하기 전에 구독 주소, 토큰, 노드 인증 정보, 내부 호스트 이름을 삭제하세요.
7. 모드 전환과 문제 해결 순서
주로 TUN 환경에서 도메인 규칙을 적용하고, DNS 요청과 연결이 모두 같은 엔진으로 전달되는 상황이라면 Fake-IP를 우선 검토할 수 있습니다. 많은 앱이 실제 IP를 요구하거나 내부 서비스 구성이 복잡한 경우, 또는 제한된 환경에서 가상 IP의 트래픽 가로채기를 보장하기 어렵다면 redir-host와 호환성을 비교해 보세요. 선택 기준은 모드 이름이 아니라 실제 데이터 경로입니다.
| 증상 | 먼저 확인할 항목 | 해결 방향 |
|---|---|---|
| 가상 IP를 받은 뒤 연결 시간 초과 | TUN 라우팅과 엔진 매핑의 일치 여부 | 트래픽 가로채기 경로를 수정하고 DNS를 다시 조회 |
| 공용 사이트는 되지만 NAS 도메인은 연결되지 않음 | 필터 목록, 내부 DNS, 직접 연결 규칙 | 해당 내부 도메인에 예외 설정 |
| 재시작 후 일부 앱의 연결이 끊김 | 앱에 캐시된 이전 가상 IP | 기존 연결을 닫고 캐시를 비운 뒤 다시 시도 |
| 구독 설정을 바꾼 뒤 모드가 원래대로 돌아감 | 클라이언트의 DNS 설정 덮어쓰기 및 구독 업데이트 방식 | 실제로 적용되는 설정 계층에서 수정 |
| 브라우저에서만 결과가 다름 | 브라우저의 암호화 DNS 및 자체 캐시 | 테스트 경로를 통일한 뒤 모드 비교 |
한 번에 하나의 변수만 변경
- 설정을 백업하고 현재
enhanced-mode, DNS 상위 서버, TUN 상태를 기록합니다. - 같은 노드, 같은 규칙, 같은 테스트 도메인을 유지한 채 DNS 모드만 전환합니다.
- 설정을 적용한 뒤 기존 연결을 닫고 시스템 및 앱의 DNS 캐시를 비웁니다. Windows에서는
ipconfig /flushdns를 실행할 수 있습니다. 브라우저나 다른 앱은 별도로 다시 시작해야 할 수도 있습니다. - 공용 도메인, 내부 도메인, 실제 업무 앱을 차례로 테스트하고 조회, 규칙 매칭, 연결 수립 중 어느 단계에서 실패하는지 기록합니다.
IPv6를 영구적으로 끄거나, 모든 도메인을 필터링하거나, 노드를 바꾸는 작업을 한꺼번에 해결책으로 적용하지 마세요. 여러 조건을 동시에 바꾸면 원인을 추적하기 어려워집니다. 설정 항목의 의미는 설정 항목 참고 문서에서 확인하고, 트래픽 가로채기 경로는 입문 가이드를 참고하세요.
최종 설정은 세 가지 조건을 충족해야 합니다. DNS 요청이 예상한 서버로 전달되고, 연결이 예상한 엔진으로 들어가며, 규칙이 의도한 출구를 선택해야 합니다. Fake-IP와 redir-host는 이 연결 과정에서 DNS를 처리하는 방식일 뿐입니다. 세 항목을 각각 확인해야 DNS 조회 문제, 라우팅 문제, 프록시 노드 문제를 구분할 수 있습니다.