Fake-IP 모드에서 도메인 정보를 유지하는 방법: DNS 매핑, 사용 조건과 제외 항목

1. Fake-IP와 실제 주소 해석의 차이

Fake-IP를 활성화한 상태에서 웹사이트의 A 레코드를 조회하면 애플리케이션은 웹사이트 서버의 공인 IP 대신 198.18.0.2와 같은 주소를 받을 수 있습니다. 이는 일반적으로 코어가 생성한 가상 주소이므로, 이 결과만으로 DNS 장애라고 판단해서는 안 됩니다. 이후 연결에 다시 조회할 수 있는 식별자를 포함하고, 코어가 해당 접속의 도메인을 복원하도록 하는 것이 목적입니다.

일반 DNS 해석에서 실제 주소를 반환하면 애플리케이션은 대상 IP만 네트워크 스택에 전달할 수 있습니다. 여러 도메인이 하나의 CDN 주소를 공유하면 IP만으로 원래 도메인을 확인하기 어렵습니다. Fake-IP는 DNS 응답 단계에서 ‘도메인과 가상 주소’의 연결을 만들고, 연결이 같은 코어로 들어오면 매핑을 통해 도메인을 복원한 뒤 규칙 매칭과 아웃바운드 처리를 진행합니다.

Fake-IP는 프록시 노드가 아닙니다: 로컬 처리 경로에서 사용하는 주소 식별자일 뿐, 원격 서버의 위치를 나타내지 않습니다.
Fake-IP는 DNS 암호화가 아닙니다: 업스트림이 UDP, DoH 또는 DoT인지 여부는 별도의 설정입니다.
Fake-IP는 글로벌 프록시와 같지 않습니다: mode: rule에서는 연결이 여전히 규칙에 따라 직접 연결이나 프록시 등의 대상으로 전달됩니다.

198.18.0.0/16은 네트워크 기준 테스트용으로 예약된 198.18.0.0/15 주소 공간에 속하며, 웹사이트의 실제 공인 주소도 일반 가정용 LAN 주소 대역도 아닙니다. 장치가 연결된 네트워크에서 이미 이 범위를 사용한다면 라우팅 충돌을 먼저 해결해야 하며, 그 위에 추가로 인터셉트 규칙을 적용해서는 안 됩니다.

2. DNS 조회부터 아웃바운드 연결까지의 5단계

Fake-IP를 이해하려면 두 경로를 나누어 봐야 합니다. DNS 조회가 어디로 들어가는지, 그리고 주소를 받은 뒤 연결이 어디로 들어가는지입니다. 두 경로가 동일한 유효 매핑으로 연결될 때만 가상 주소가 의미를 가집니다.

애플리케이션이 조회를 시작합니다. 예를 들어 브라우저가 example.com의 A 레코드를 요청하면, 조회는 시스템 리졸버, DNS 포워딩 또는 TUN의 DNS 인터셉트를 거쳐 코어로 들어갑니다.
코어가 가상 주소를 할당합니다. 도메인이 Fake-IP 처리 조건에 맞으면 코어는 주소 풀에서 하나를 반환하고 매핑을 저장합니다. 이 글에서는 흐름 설명을 위해 198.18.0.2를 사용하지만, 실제 할당 값은 고정되지 않습니다.
애플리케이션이 연결을 수립합니다. 애플리케이션은 이 가상 주소의 대상 포트로 연결을 시작합니다. 예를 들면 HTTPS의 443 포트입니다.
코어가 도메인을 다시 조회하고 규칙을 매칭합니다. 코어는 연결을 받은 뒤 매핑을 이용해 example.com을 식별하고, 도메인 규칙을 매칭할 수 있게 됩니다.
선택한 아웃바운드 방식으로 처리합니다. 직접 연결에는 일반적으로 실제 대상 주소가 필요합니다. 프록시 아웃바운드는 도메인 해석을 원격 서버에 맡길 수도 있고 로컬에서 수행할 수도 있으며, 이는 프로토콜, 노드 옵션과 코어 동작에 따라 달라집니다.

애플리케이션이 example.com 조회
  → 코어 DNS가 가상 주소 반환
  → 애플리케이션이 가상 주소:443에 연결
  → 동일한 코어에서 example.com 복원
  → 규칙 매칭
  → 직접 연결 또는 프록시 아웃바운드

따라서 ‘DNS가 Fake-IP를 반환했다’는 것은 조회 경로 일부가 성공했다는 뜻일 뿐, 연결까지 인터셉트되었다는 의미는 아닙니다. 애플리케이션이 가상 주소를 받았지만 코어를 우회해 데이터를 직접 전송하면 일반 네트워크는 이를 어느 웹사이트로 보내야 하는지 알 수 없어 연결 시간 초과가 발생하는 경우가 많습니다.

도메인 매핑이 있는데도 실제 DNS 조회가 발생할 수 있는 이유

Fake-IP는 애플리케이션이 먼저 가상 응답을 받게 할 수 있지만, 전체 연결 과정에서 실제 IP를 전혀 조회하지 않는다는 보장은 없습니다. 직접 연결 아웃바운드, 대상 IP가 필요한 규칙 판단, 프록시 서버 자체의 도메인 해석 등에서 조회가 발생할 수 있습니다. 규칙에 no-resolve가 있는지와 코어가 해당 규칙 옵션을 지원하는지도 처리 과정에 영향을 줍니다. ‘일부 대기 시간을 줄인다’는 것을 ‘모든 DNS 조회를 취소한다’고 이해해서는 안 됩니다.

3. 활성화 전에 DNS와 연결 인터셉트 범위 점검

Fake-IP는 투명 인터셉트가 필요하고 도메인 규칙 매칭 정보를 유지해야 하는 환경에 더 적합합니다. 예를 들어 라우팅과 DNS 인터셉트가 올바르게 설정된 데스크톱 TUN 환경입니다. 모든 애플리케이션의 네트워크 문제를 기본적으로 해결하는 방법은 아닙니다.

사용 방식	도메인 정보의 출처	우선 점검할 항목
HTTP 시스템 프록시	프록시 요청에는 일반적으로 대상 호스트명이 이미 포함됩니다	애플리케이션이 시스템 프록시를 따르는지 확인해야 하며, 이것만으로 전체 장치의 DNS가 인터셉트되었다고 볼 수는 없습니다
TUN 투명 인터셉트	Fake-IP 매핑으로 도메인을 복원할 수 있습니다	DNS 조회와 가상 주소 연결이 동일한 코어로 들어가는지 확인합니다
LAN 게이트웨이	게이트웨이 DNS가 매핑을 생성합니다	단말의 DNS, 게이트웨이 라우팅과 반환 경로가 일치하는지 확인합니다
애플리케이션 내장 암호화 DNS	코어의 DNS를 우회해 실제 IP를 직접 가져올 수 있습니다	애플리케이션 보안 DNS, 시스템 암호화 DNS와 기존 VPN 설정

TUN은 가상 네트워크 인터페이스와 인터셉트 경로를 제공하고, Fake-IP는 DNS 매핑을 제공합니다. 둘은 서로 다른 계층입니다. TUN을 켠다고 모든 애플리케이션의 DoH 요청이 일반 DNS 조회로 바뀌는 것은 아닙니다. DNS의 enhanced-mode: fake-ip를 활성화해도 시스템의 모든 라우팅이 자동으로 설정되지는 않습니다.

클라이언트 버전, 코어 이름과 코어 버전을 기록하고 현재 실행 중인 것이 다른 백그라운드 인스턴스가 아닌지 확인합니다.
현재 적용된 설정과 클라이언트가 별도로 관리하는 오버라이드 조각을 저장합니다. 구독 원문만 백업하면 DNS 설정이 누락될 수 있습니다.
다른 VPN, 게이트웨이 소프트웨어와 보안 소프트웨어가 동시에 DNS 또는 라우팅을 변경하고 있지 않은지 확인합니다.
처음 검증할 때는 DNS 모드와 필요한 인터셉트 설정만 변경하고, 노드·정책 그룹·규칙 순서는 동시에 바꾸지 않습니다.

4. Fake-IP 설정 조각과 필드 범위

mixed-port: 7890
mode: rule
allow-lan: false

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "localhost"
    - "*.lan"
    - "*.home.arpa"
  nameserver:
    - 1.1.1.1

두 포트는 혼동해서 사용할 수 없습니다

7890은 예시에 사용된 HTTP/SOCKS 통합 프록시 포트이고, 1053은 코어의 DNS 리슨 포트입니다. 브라우저의 프록시 설정에는 DNS 포트를 입력할 수 없습니다. 대부분의 시스템 DNS 설정 화면에서도 비표준 포트를 직접 지정할 수 없으므로, 이 조각은 포트를 명시할 수 있는 조회 도구에 적합하며 YAML을 불러오는 것만으로 시스템 DNS를 자동 인터셉트하지는 않습니다.

listen: 127.0.0.1:1053은 리슨 범위를 로컬 장치로 제한합니다. LAN의 다른 장치는 이를 DNS 서버로 사용할 수 없습니다. LAN에 서비스를 제공하려면 리슨 주소, 방화벽과 트래픽 라우팅을 별도로 설계해야 합니다. allow-lan: false는 프록시 진입점의 LAN 접근 제어에 사용되며, DNS 리슨 주소의 보안 설정을 대신할 수 없습니다.

필터 모드는 코어의 기능과 맞아야 합니다

fake-ip-filter-mode을 지원하는 mihomo에서는 예시가 blacklist를 명시적으로 선택합니다. 목록에 매칭되는 도메인은 Fake-IP를 반환하지 않고 실제 해석을 사용합니다. whitelist를 선택하면 목록의 의미가 반대로 바뀌어 매칭 항목에만 Fake-IP를 사용합니다. 구형 코어가 모드 필드를 지원하지 않을 수도 있으므로, 알 수 없는 필드가 무시된 것을 설정 성공으로 보아서는 안 됩니다.

예시의 ipv6: false는 이번 DNS 검증 범위를 좁히기 위한 것으로, 운영체제의 IPv6을 끄거나 다른 해석 경로에서 AAAA 레코드가 반환되지 않는다는 뜻은 아닙니다. 운영 환경에서는 IPv6 라우팅과 실제 코어의 기능을 함께 고려해 다시 평가해야 합니다. 더 많은 필드는 설정 전체 목록에서 하나씩 대조할 수 있습니다.

5. LAN 호환성 문제와 제외 항목 선택

일부 애플리케이션은 단순히 연결을 수립할 수 있는 식별자가 아니라 실제 주소를 필요로 합니다. 예를 들어 NAS 관리 도구는 서버가 로컬 네트워크 대역에 있는지 확인할 수 있고, 프린터 도구는 해석 결과를 프록시를 거치지 않는 검색 구성 요소에 전달할 수 있습니다. 일부 프로그램은 IP 주소를 다른 장치에서 사용하도록 전송하기도 합니다. 이런 경우 특정 도메인 하나만 실제 해석으로 유지하는 편이 모든 도메인을 제외하는 것보다 영향 범위를 제어하기 쉽습니다.

Fake-IP 제외는 LAN DNS 지정과 다릅니다

"*.home.arpa"를 필터 목록에 추가하면 코어가 실제 주소를 조회하도록 바뀔 뿐입니다. 공용 DNS는 일반적으로 홈 네트워크의 호스트 레코드를 알지 못합니다. NAS 이름을 라우터가 제공한다면 해당 도메인을 라우터 DNS로 전달해야 합니다. 예를 들어 코어가 지원하는 nameserver-policy 설정으로 지정 해석을 구성하고 라우터의 DNS 서비스에 연결할 수 있는지 확인합니다.

.local은 일반적으로 mDNS에 사용되며, 유니캐스트 DNS 서버에 일반 조회를 보내는 것과 본질적으로 다릅니다. "*.local"을 목록에 추가해도 멀티캐스트 검색이 자동으로 복구되거나 코어가 mDNS 포워더가 되지는 않습니다. 화면 전송이나 프린터 검색이 실패하면 LAN 접근 권한, 멀티캐스트 트래픽과 TUN 라우팅 범위도 확인해야 합니다.

먼저 도메인을 좁혀 확인합니다: 특정 장치에 문제가 있을 때는 범위가 넓은 와일드카드를 바로 추가하지 말고 해당 장치 이름부터 검증합니다.
다음으로 해석 출처를 확인합니다: 제외한 뒤에는 공용 DNS의 존재하지 않음 응답이 아니라 신뢰할 수 있는 로컬 DNS가 반환한 실제 주소를 받아야 합니다.
마지막으로 연결 규칙을 확인합니다: 실제 주소를 반환받았다고 해서 트래픽이 자동으로 직접 연결되는 것은 아닙니다. 규칙에 따라 해당 도메인이 여전히 프록시 그룹으로 전달될 수 있습니다.

클라이언트마다 목록 오버라이드에 교체 또는 병합 방식을 사용할 수 있고, 코어에도 버전별 기본 제외 항목이 있을 수 있습니다. 수정한 뒤에는 편집기에 추가한 몇 줄만 보지 말고 최종 적용 설정을 확인해야 합니다. 하나의 호환성 문제를 없애려고 모든 도메인을 제외하면 Fake-IP가 실제로 처리에 참여했는지 다시 검증하기 어려워집니다.

6. 조회·매핑·규칙·아웃바운드 순서로 검증

1. 코어 DNS 응답만 별도로 검증

dig가 설치된 macOS, Linux 또는 기타 환경에서 앞서 설정한 로컬 리슨 주소를 대상으로 다음을 실행합니다:

dig @127.0.0.1 -p 1053 example.com A +short

도메인이 제외되지 않았다면 설정된 범위의 가상 IPv4 주소가 반환되는 것이 예상됩니다. 구체적인 주소는 고정되지 않습니다. 시간 초과가 발생하면 먼저 코어가 실행 중인지, DNS가 활성화되었는지, 1053 포트를 다른 프로세스가 사용 중인지 확인합니다. 실제 주소가 반환되면 필터 모드, 기본 제외 항목과 현재 실행 중인 설정에 변경 사항이 실제로 포함되었는지 점검합니다. 이는 예상 동작에 대한 설명이며, 이 사이트에서 직접 측정한 기록이 아닙니다.

2. 실제 애플리케이션으로 연결 인터셉트 검증

시스템 또는 애플리케이션의 DNS가 예정된 경로로 연결되었는지 확인한 뒤, 브라우저에서 테스트 도메인을 열면서 클라이언트의 연결 기록을 관찰합니다. ‘웹페이지가 열리는가’만 보지 말고 대상 도메인, 매칭된 규칙, 아웃바운드 정책과 연결 오류를 확인해야 합니다. 코어에 직접 dig를 한 번 실행해도 브라우저가 같은 해석 경로를 자동으로 사용하지는 않습니다.

명시적 HTTP 프록시 요청에는 일반적으로 도메인이 포함되므로 ‘프록시 포트로 접속 성공’은 해당 프록시 경로만 검증할 뿐 TUN의 Fake-IP 재조회가 정상이라는 것을 단독으로 증명하지 못합니다. 마찬가지로 가상 주소에 ping을 실행한 결과로 HTTPS 사용 가능 여부를 판단해서는 안 됩니다. ICMP 처리와 TCP 연결은 서로 다릅니다.

3. 오류가 발생한 위치를 대조

현상	우선 점검할 항목	다음 단계
조회 결과는 가상 주소인데 연결 기록이 없음	애플리케이션 연결이 코어를 우회하는지 확인	TUN 라우팅, 애플리케이션 제외 설정과 다른 VPN을 점검
코어 재시작 후 일부 웹사이트가 작동하지 않음	애플리케이션 캐시에 이전 가상 주소가 남아 있는지 확인	기존 연결을 종료하고 DNS 캐시를 새로 고친 뒤 다시 조회
NAS 도메인을 제외해도 해석되지 않음	해당 도메인이 로컬 레코드를 아는 DNS로 전달되었는지 확인	지정 해석과 라우터 DNS 응답을 점검
도메인과 규칙은 올바르지만 아웃바운드가 시간 초과됨	노드, 직접 연결 대상 또는 아웃바운드 해석이 사용 가능한지 확인	필터 목록을 계속 확대하지 말고 경로를 따라 문제를 해결

4. 캐시를 정리한 뒤 단일 변수로 다시 테스트

Windows에서는 ipconfig /flushdns로 시스템 DNS 캐시를 정리할 수 있습니다. Linux에서 systemd-resolved를 사용한다면 resolvectl flush-caches를 실행합니다. 브라우저, 애플리케이션과 코어에도 별도의 캐시가 있을 수 있으므로 시스템 명령만으로 모든 계층이 비워지지는 않습니다. 테스트 애플리케이션의 기존 연결을 종료한 뒤 요청을 다시 시작해야 이전 결과의 영향을 줄일 수 있습니다.

지원되는 코어에서는 profile.store-fake-ip으로 매핑을 영속화할 수 있지만, 이는 라우팅 설정을 대신하지 않으며 외부 캐시와 매핑이 항상 동기화된다고 보장할 수도 없습니다. 주소 풀을 변경하거나 코어 캐시를 삭제한 뒤에는 애플리케이션이 다시 해석하도록 해야 합니다.

7. 자주 묻는 질문과 되돌리기 방법

Fake-IP가 모든 도메인 규칙의 매칭을 보장하나요?

아닙니다. 애플리케이션이 IP에 직접 접속하거나 자체 DNS로 코어를 우회하거나 매핑이 사라진 경우, 또는 더 앞선 규칙이 트래픽을 가로챈 경우 매칭에 영향을 줄 수 있습니다. 트래픽 스니핑이 프로토콜에서 호스트명 정보를 보완하는 경우도 있지만, 이는 별도의 기능이며 암호화 또는 비표준 프로토콜에서 항상 유효하다고 보장할 수 없습니다.

Fake-IP를 활성화하면 모든 도메인이 프록시 서버에서 해석되나요?

아닙니다. 애플리케이션이 가상 주소를 보았다는 것은 로컬 DNS 응답이 매핑 방식을 사용했다는 뜻일 뿐입니다. 실제 해석이 로컬에서 이루어지는지 원격에서 이루어지는지는 규칙, 아웃바운드 프로토콜과 노드 설정에 따라 달라집니다. 프록시 서버 자체의 도메인도 사용 가능한 해석 경로가 필요하므로, 아직 수립되지 않은 프록시 연결에 의존해 순환이 발생하지 않도록 해야 합니다.

필터 목록을 수정한 뒤 구독을 업데이트해야 하나요?

일반적으로 애플리케이션 설정을 적용하거나 코어를 다시 불러오고 애플리케이션이 다시 조회하도록 하면 되며, 구독 업데이트를 고정 단계로 삼을 필요는 없습니다. 구독에서 생성된 파일을 직접 수정하면 다음 업데이트에서 변경 사항이 덮어써질 수 있습니다. 클라이언트가 지원하는 영속 오버라이드 기능에 수정 내용을 저장한 뒤 최종 설정에서 목록 의미를 확인해야 합니다.

대규모 연결 실패가 발생하면 먼저 이전에 저장한 DNS와 인터셉트 설정을 복원한 다음 시스템과 애플리케이션 캐시를 처리합니다. 모드만 redir-host로 되돌리고 기존 가상 주소 캐시를 그대로 두면 장애가 일시적으로 지속될 수 있습니다. 클라이언트만 종료하고 시스템 프록시나 DNS가 중지된 로컬 포트를 계속 가리키게 두어도 새로운 네트워크 단절처럼 보이는 문제가 발생합니다.

문제 해결 정보를 제출할 때는 클라이언트와 코어 버전, 조회 명령과 결과, 매칭된 규칙과 오류 발생 시간을 남기고 구독 URL, 토큰과 노드 인증 정보는 삭제합니다. 검증 목표는 ‘조회와 연결이 동일한 코어로 들어가고, 도메인 매핑이 유효하며, 규칙과 아웃바운드가 예상대로 작동하는지’이지 DNS 결과가 특정 주소 대역으로 표시되는 것 자체가 아닙니다.