Clash Fake-IP 모드 원리와 설정: 가상 IP 풀로 DNS 대기 시간을 줄이는 방법

Fake-IP의 작동 방식: 먼저 가상 IP를 반환하고 연결을 처리합니다

Clash에서 Fake-IP 모드를 켜면 DNS 조회 결과로 198.18.0.2 같은 주소를 받을 수 있습니다. 이 주소는 대상 웹사이트의 공인 IP도, 프록시 노드의 IP도 아닙니다. 도메인에 임시로 할당된 가상 주소입니다. 앱이 이 주소로 연결하면 같은 커널이 트래픽을 가로채고, 매핑 정보를 이용해 도메인을 확인한 뒤 규칙에 따라 아웃바운드 연결을 처리합니다.

이 방식은 앱에 연결 가능한 주소를 제공하는 단계와 실제 서버 주소를 확인하는 단계를 분리합니다. 도메인 주소를 원격에서 조회할 수 있는 프록시 아웃바운드라면, 클라이언트가 대상 도메인의 실제 IP를 로컬에서 먼저 조회하지 않아도 연결을 시작할 수 있습니다. 주로 연결 전 DNS 조회 대기 시간을 줄이는 기능으로, 회선 대역폭을 높이거나 모든 웹페이지의 로딩 속도를 보장하지는 않습니다.

198.18.0.0/16은 왜 공인 IP가 아닐까요?

198.18.0.0/15는 네트워크 장비 성능 테스트용으로 예약된 IPv4 주소 대역이며, 일반적인 공인 서비스 주소가 아닙니다. Clash 설정에서는 이 대역 중 198.18.0.0/16을 사용하는 경우가 많으며, 흔히 fake-ip-range: 198.18.0.1/16처럼 지정합니다. 이 프리픽스에는 IPv4 주소 65,536개가 포함되지만, 이를 커널이 동시에 지원하는 매핑 수로 해석해서는 안 됩니다.

커널이 주소 풀을 관리하고 주소를 할당·기록·회수합니다. 오늘 특정 도메인에 198.18.0.2가 할당되더라도, 다음 재시작이나 매핑 변경 후에는 달라질 수 있습니다. 따라서 가상 IP를 장기 고정 라우트, 서버 허용 목록, 앱의 고정 설정에 넣지 마세요. 기업망이나 테스트 환경, 다른 VPN에서 같은 대역을 사용 중이라면 먼저 라우팅 충돌을 확인한 뒤 주소 풀 변경 여부를 결정하세요.

Fake-IP와 redir-host: DNS 대기는 어디서 발생할까요?

두 모드의 핵심 차이는 프록시 사용 여부가 아니라 앱에 어떤 주소를 반환하느냐입니다. 규칙 모드와 전역 모드는 연결에 사용할 아웃바운드를 결정하고, enhanced-mode는 DNS를 처리하는 방식을 정합니다. 두 설정은 서로 다른 계층에 해당합니다.

프록시 접속 과정 비교

1. redir-host: 앱이 도메인을 조회하면 Clash가 상위 DNS에 실제 IP를 요청한 뒤 결과를 앱에 전달합니다. 앱은 해당 주소로 연결하고, 규칙에 따라 아웃바운드가 선택됩니다.
2. Fake-IP: 앱이 도메인을 조회하면 Clash가 도메인과 가상 IP의 매핑을 저장하고 주소를 전달합니다. 연결이 커널에 도달하면 도메인을 복원한 뒤 규칙에 따라 아웃바운드를 선택합니다.
3. 프록시가 도메인 주소를 지원하는 경우: 실제 DNS 조회를 원격에서 처리할 수 있습니다. 반면 최종 연결이 직결이거나 규칙에서 대상 IP를 확인해야 한다면 로컬에서 실제 IP를 조회할 수도 있습니다.

예를 들어 캐시에 없는 상위 DNS 조회에 120ms가 걸린다고 가정해 보겠습니다. Fake-IP를 사용하면 앱이 연결을 시작하기 전에 이 조회를 기다리지 않아도 될 수 있습니다. 120ms는 처리 과정을 설명하기 위한 예시일 뿐, 실제로 속도가 그만큼 빨라진다는 의미는 아닙니다. 총 소요 시간은 규칙, 노드 핸드셰이크, 원격 DNS 조회, 서버 응답 등에 따라 달라지므로 페이지 로딩 시간이 같은 만큼 줄어든다고 단정할 수 없습니다.

Fake-IP를 사용해도 DNS가 완전히 필요 없어지는 것은 아닙니다. 노드 서버 자체의 도메인 조회가 필요할 수 있고, 직결 도메인은 실제 IP가 필요하며, 일부 IP 규칙도 조회 결과를 사용합니다. 앱이 HTTP 또는 SOCKS 프록시에 도메인을 직접 전달하는 경우에는 가상 IP 할당 과정을 거치지 않을 수도 있습니다.

최소 설정: 가상 IP 매핑을 켜고 로컬 네트워크 DNS 유지하기

아래 예시는 Clash Meta(현재 명칭 mihomo)에서 흔히 쓰는 설정 항목의 관계를 설명하기 위한 것으로, 구독 설정을 그대로 대체할 수 있는 완성된 설정 파일이 아닙니다. 작업 전에 현재 설정을 백업하고 기존 노드, 정책 그룹, 규칙을 유지한 채 DNS 항목을 클라이언트가 지원하는 오버라이드 설정에 병합하세요. 하나의 YAML 파일에 최상위 dns 키를 두 개 만들지 마세요.

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

• enable: 커널 DNS를 활성화합니다. DNS를 켜지 않고 모드만 바꾸면 원하는 DNS 처리 경로가 구성되지 않습니다.
• listen: 예시에서는 로컬 UDP/TCP 1053 포트를 수신 대기하도록 설정해 독립적으로 테스트합니다. 시스템 기본 DNS는 53 포트를 사용하며, 자동으로 1053 포트에 연결되지는 않습니다.
• enhanced-mode: fake-ip를 선택합니다. 비교 테스트에서는 다른 조건을 그대로 둔 채 redir-host로 바꾸면 됩니다.
• nameserver: 실제 IP 조회에 사용할 상위 DNS를 지정합니다. 예시는 암호화되지 않은 일반 DNS입니다. 네트워크 연결 가능 여부와 개인정보 보호 요구에 맞춰 선택하세요.
• fake-ip-filter: 일반적인 제외 방식에서는 목록과 일치하는 도메인에 주소 풀의 가상 IP 대신 실제 DNS 조회 결과를 반환합니다.

mihomo 일부 버전에는 필터 목록의 동작 방식을 바꾸는 fake-ip-filter-mode가 있습니다. 여기서는 제외 방식 기준으로 설명합니다. 현재 설정에서 whitelist 모드를 명시적으로 사용 중이라면, 목록의 도메인을 Fake-IP를 사용하지 않는 대상으로 해석할 수 없습니다. 클라이언트마다 포함된 커널 버전과 기본 필터 항목이 다를 수 있으므로 실제 적용된 설정을 확인하세요.

fake-ip-filter 예외 목록: 문제가 있는 도메인만 추가하기

흔히 말하는 Fake-IP 예외 목록은 일반적으로 가상 IP를 할당하지 않을 도메인 목록을 뜻합니다. 목록에 도메인을 추가해도 자동으로 직결되거나 라우터 DNS를 사용하는 것은 아닙니다. 직결 여부는 규칙이 결정하고 실제 IP를 조회할 DNS 서버는 DNS 정책이 결정하므로, 세 설정을 각각 확인해야 합니다.

로컬 네트워크 기기와 내부 도메인

프린터, NAS, 공유기 관리 페이지, 사내 서비스는 로컬 네트워크 DNS에 의존하는 경우가 많습니다. home.arpa나 조직 내부 도메인에는 구체적인 도메인 예외를 추가하고, 올바른 로컬 DNS에서 조회하도록 설정할 수 있습니다. 공용 DNS는 내부 호스트 주소를 모르는 경우가 많으므로 필터 항목만 추가하면 도메인을 찾을 수 없다는 응답을 받을 수 있습니다.

.local은 mDNS로 조회되는 경우가 많으며, mDNS의 기기 검색 방식은 일반적인 유니캐스트 DNS와 다릅니다. 필터 목록에 추가하면 Fake-IP를 할당하지 않도록 할 수 있지만, 기기 검색 문제까지 해결되지는 않습니다. 검색에 계속 실패한다면 공용 상위 DNS를 더 추가하기보다 로컬 네트워크 접근 권한, 멀티캐스트, TUN 라우팅을 확인하세요.

조회 결과를 검증하거나 다른 기기에 IP를 전달하는 앱

일부 게임, 음성 통화, 시간 동기화, 기기 검색 앱은 DNS 조회 결과를 검사하거나 조회한 IP를 다른 기기에 전달합니다. 다른 기기에는 로컬 커널의 매핑 정보가 없으므로 가상 IP로 대상에 연결할 수 없습니다. 이 경우 연결 로그에서 해당 도메인을 찾아 예외를 하나씩 추가한 뒤 전체 기능을 다시 테스트하세요.

• 가능한 한 정확하게 지정하세요: 한 서비스에서만 문제가 발생한다면 실제로 조회되는 도메인만 먼저 추가하세요. 대규모 도메인 접미사를 통째로 제외하지 마세요.
• 문제가 발생한 동작을 기준으로 확인하세요: 웹페이지가 열린다고 해서 음성 통화, 온라인 플레이, 기기 검색까지 정상이라는 뜻은 아닙니다. 기존에 실패했던 작업을 직접 테스트하세요.
• 앱 종류만 보고 전부 제외하지 마세요: 게임, NTP, STUN이 본질적으로 Fake-IP와 충돌하는 것은 아닙니다. 예외가 필요한지는 앱 구현 방식과 트래픽 처리 경로에 따라 달라집니다.

mihomo에서 흔히 쓰는 도메인 매칭 문법에서 +.home.arpa는 해당 도메인과 하위 도메인을 매칭합니다. 구버전 Clash 커널을 사용한다면 먼저 해당 문법의 지원 여부를 확인하세요. 필터 항목을 바꾼 뒤에는 앱과 시스템의 캐시도 비워야 합니다. 그렇지 않으면 앱이 변경 전에 받은 가상 IP를 계속 사용할 수 있습니다.

TUN과 시스템 프록시: 가상 IP 연결이 커널에 도달하도록 설정하기

Fake-IP는 DNS 처리 방식이고 TUN은 트래픽을 가로채는 방식입니다. 함께 사용할 수 있지만 같은 설정은 아닙니다. TUN은 시스템 프록시를 따르지 않는 앱의 트래픽을 처리하는 데 더 적합한 경우가 많습니다. 시스템 프록시는 시스템 HTTP, HTTPS 또는 SOCKS 설정을 사용하는 프로그램에 영향을 주지만, 모든 앱의 가상 IP 연결을 처리한다고 보장할 수는 없습니다.

먼저 DNS를 확인한 다음 연결 경로를 테스트하세요

1. 설정이 적용됐는지, DNS 수신 포트가 실제로 127.0.0.1:1053인지 확인하세요. 포트가 사용 중이라는 메시지가 나오면 다른 DNS 서비스나 중복 실행된 커널이 있는지 먼저 살펴보세요.
2. 해당 포트에 직접 질의해 필터 목록에 없는 도메인이 주소 풀의 A 레코드를 받는지 확인하세요.
3. 시스템이나 앱이 실제로 사용하는 DNS를 확인하세요. 직접 질의 테스트가 성공해도 시스템의 기본 DNS 질의가 Clash를 거친다는 뜻은 아닙니다.
4. 대상에 접속한 뒤 연결 로그를 확인해 도메인이 복원되고, 예상한 규칙과 아웃바운드가 적용됐는지 살펴보세요.

# macOS / Linux: dig가 기본 제공되거나 설치된 경우 사용
dig @127.0.0.1 -p 1053 example.com A

# 기본 DNS 조회 경로와 비교
dig example.com A

첫 번째 명령은 198.18.0.2 같은 주소 풀의 주소를 반환할 수 있으며, 실제 할당 주소는 달라집니다. 첫 번째 명령에서 가상 IP가 나오고 두 번째에서는 공인 IP가 나온다면 Fake-IP 설정이 적용되지 않았다고 보기보다 DNS 진입 경로를 먼저 확인하세요. 브라우저의 암호화 DNS, 앱 내장 DNS 조회 기능, 캐시 때문에 실제 접속이 다른 경로를 사용할 수도 있습니다.

TUN 설정의 dns-hijack은 조건에 맞는 DNS 트래픽을 가로채는 데 사용할 수 있습니다. 흔히 쓰는 대상 표기는 any:53이지만 지원 여부와 적용 범위는 커널, 플랫폼, 프로토콜에 따라 다릅니다. 모든 DNS를 처리하는 만능 설정은 아닙니다. HTTPS 443 포트로 전송되는 DoH는 기존 DNS 53 포트 트래픽을 가로채더라도 자동으로 커널 DNS에 전달되지 않습니다.

자주 발생하는 문제: 주소 풀·캐시·규칙을 하나씩 점검하기

198.18 주소를 받았는데 웹페이지가 열리지 않을 때

먼저 해당 연결이 커널 로그에 나타나는지 확인하세요. 전혀 보이지 않는다면 앱이 프록시를 우회하는지, TUN 라우팅이 적용되지 않았는지, 다른 VPN이 라우트를 선점했는지 살펴보세요. 도메인과 정책이 로그에 보이면 DNS 모드를 바로 바꾸기보다 노드 상태, 직결 DNS, 규칙을 확인하세요.

커널을 재시작한 뒤 일부 앱이 일시적으로 작동하지 않을 때

앱이 이전 가상 IP를 캐시한 상태에서 커널이 새 매핑을 만들었을 수 있습니다. 먼저 문제가 있는 앱을 완전히 종료한 뒤 다시 실행하고, 필요하면 운영체제의 DNS 캐시를 비우세요. Windows에서는 터미널에서 ipconfig /flushdns를 실행할 수 있습니다. systemd-resolved를 사용하는 Linux에서는 resolvectl flush-caches를 사용할 수 있습니다. 이 명령으로 브라우저나 앱 자체의 캐시까지 지워지는 것은 아닙니다.

일부 커널은 profile.store-fake-ip로 매핑을 저장해 재시작 전후의 불일치를 줄일 수 있습니다. 하지만 DNS 우회, 여러 커널이 별도로 관리하는 주소 풀, 라우팅 충돌은 해결하지 못합니다. 지원 여부를 확인하지 않은 상태에서 구버전 커널 설정에 이 항목을 추가하지 마세요.

필터 목록에 추가했는데도 열리지 않을 때

먼저 다시 조회해 결과가 가상 IP에서 실제 IP로 바뀌었는지 확인하세요. 주소 풀의 IP가 계속 반환되면 필터 문법, 모드, 캐시를 점검하세요. 실제 IP가 반환된다면 내부 도메인을 올바른 DNS에서 조회하는지, 연결이 올바른 아웃바운드를 사용하는지 확인하세요. 필터 항목은 주소 할당 방식만 바꾸며 트래픽 분기 규칙을 대신하지 않습니다.

Fake-IP를 유지할 때와 redir-host를 비교할 때

• Fake-IP 유지가 적합한 경우: DNS 조회와 연결을 같은 커널이 처리하고, 주로 도메인 기준으로 트래픽을 분기하며, 프록시 연결 전 로컬 DNS 대기를 줄이고 싶을 때
• 먼저 정확한 예외를 추가하세요: 일부 내부 서비스, 기기 검색, 특정 앱에서만 문제가 발생하고 다른 접속은 정상일 때
• redir-host와 비교 테스트하세요: 많은 프로그램이 실제 IP에 의존하거나 현재 환경에서 가상 IP 연결을 안정적으로 처리하기 어려울 때 두 모드의 실제 호환성을 비교하세요.

한 번에 변수 하나만 바꾸고 도메인, DNS 응답, 적용된 규칙, 오류 메시지를 기록하세요. 먼저 조회가 올바른 DNS에 도달하는지 확인하고, 다음으로 연결이 올바른 커널에 도달하는지 확인한 뒤, 마지막으로 상위 DNS 응답과 아웃바운드 품질을 점검하세요. 주소 풀, 노드, 모든 규칙을 동시에 바꾸는 것보다 원인을 찾기 쉽고, 문제가 생기면 이전 설정으로 되돌릴 수 있습니다.