프록시 체인에서 DNS 해석이 막히는 지점
Fake-IP의 역할을 이해하려면 먼저 이것이 없을 때 프록시 소프트웨어가 거쳐야 하는 전체 과정을 살펴봐야 합니다. 클라이언트가 도메인에 접속하면 시스템은 먼저 DNS 조회를 보내고, 실제 IP를 받은 뒤 TCP 연결을 맺습니다. 이 연결이 프록시를 거쳐야 한다면 코어는 규칙(도메인 접미사, IP 대역, GEOIP 등)에 따라 어떤 프록시 그룹으로 전달할지 결정해야 합니다. 문제는 규칙 매칭이 대부분 도메인 정보를 필요로 한다는 점입니다. IP를 받은 뒤에야 판단하는 것이 아니라, DNS 조회 단계 자체가 프록시를 경유하거나 하이재킹당하면 첫 패킷이 만들어지기도 전에 한두 번의 네트워크 왕복이 추가로 발생합니다. 특히 TUN 모드로 전체 트래픽을 처리할 때는 이 지연이 매 신규 연결마다 누적됩니다.
또 하나의 모순은, 많은 분기 규칙이 도메인 규칙(예: DOMAIN-SUFFIX)으로 작성되지만 운영체제 하위에서 실제로 전달하는 것은 IP 계층의 패킷이라는 점입니다. TUN 모드가 네트워크 카드 계층에서 트래픽을 가로챌 때 얻는 것은 이미 목적지 IP이며, 만약 이 IP가 통신사 DNS나 프록시 노드 자체가 해석해 낸 실제 주소라면 코어는 "이 연결이 원래 어떤 도메인에 대응하는지"에 대한 정보를 잃게 되어 규칙 엔진이 도메인 기준으로 판단할 수 없게 됩니다.
Fake-IP의 매핑 메커니즘: 가상 주소로 자리 채우기
Fake-IP의 접근 방식은 이 두 문제를 동시에 해결하는 것입니다. 클라이언트가 DNS 조회를 보내면 mihomo 코어는 실제 해석을 수행하지 않고, 예약된 사설 대역(일반적으로 198.18.0.0/16)에서 아직 사용되지 않은 주소를 순서대로 골라 클라이언트에 즉시 반환하는 동시에, 메모리 안에 "가상 IP ↔ 도메인" 매핑 테이블을 구축합니다. 클라이언트는 이 가짜 주소를 받는 즉시 연결을 시도하고, TUN 네트워크 카드가 이 목적지 IP를 가로채면 코어는 매핑 테이블을 조회해 실제 도메인이 무엇인지 파악합니다. 규칙 엔진은 평소처럼 도메인 기준으로 매칭해 어떤 프록시 노드로 보낼지 결정하고, 실제 도메인 해석은 연결이 맺어지는 시점에 프록시 노드나 코어가 비동기로 완료하므로 별도의 왕복 시간을 차지하지 않습니다.
이 과정은 클라이언트 입장에서는 투명합니다. 애플리케이션은 자신이 받은 것이 가짜 주소라는 것을 모르고 그냥 이 IP로 패킷을 보낼 뿐입니다. 바로 이 때문에 Fake-IP가 첫 패킷 시간을 눈에 띄게 줄일 수 있는 것입니다. DNS 조회 단계가 거의 로컬 테이블 조회로 바뀌어 더 이상 네트워크 지연에 의존하지 않게 됩니다.
매핑 테이블의 수명 주기
- 매핑 관계는 메모리에 저장되며 보통 일정한 TTL을 가지고, 일정 시간 사용되지 않은 항목은 새로운 도메인에 재활용됩니다.
- 같은 도메인을 짧은 시간 내에 여러 번 조회하면 같은 가상 IP를 재사용해 동일 세션 내 주소를 안정적으로 유지합니다.
- 가상 대역의 용량은 제한적이므로 장시간 실행되고 방문 도메인 수가 매우 많은 환경에서는 간혹 주소 재사용으로 인한 일시적인 매핑 혼란이 발생할 수 있으며, 클라이언트를 재시작하거나 DNS 캐시를 비우면 해결됩니다.
Fake-IP와 Redir-Host의 동작 차이
Redir-Host는 비교적 이전부터 사용된 또 다른 DNS 처리 방식입니다. 클라이언트의 DNS 조회는 실제 상위 서버로 그대로 전달되어 진짜 IP를 받은 뒤 클라이언트에 반환되며, 코어는 이 진짜 IP를 리다이렉트하면서 "실제 IP ↔ 도메인" 역조회 테이블을 유지해 규칙 매칭에 필요한 도메인 정보를 복원합니다. 장점은 클라이언트가 항상 실제 주소를 갖고 있어 호환성 문제가 적다는 점이고, 단점은 DNS 조회 단계가 그대로 남아 있어 원래 필요한 해석 지연을 전혀 줄이지 못한다는 점입니다. 또한 역조회 테이블은 실제 IP가 중복되지 않고 바뀌지 않는다는 전제에 의존하므로, 어떤 도메인이 CDN을 사용하며 IP가 자주 바뀌면 역조회 관계가 만료될 수 있습니다.
| 비교 항목 | Fake-IP | Redir-Host |
|---|---|---|
| 클라이언트가 받는 주소 | 가상 대역 내 가짜 주소 | 실제 해석 주소 |
| DNS 조회 소요 시간 | 거의 로컬 테이블 조회, 지연 거의 없음 | 실제 상위 서버 해석 대기 |
| 도메인 매칭 근거 | 코어가 관리하는 가상 IP 매핑 테이블 | 실제 IP 역조회 테이블 |
| CDN IP 변경에 대한 민감도 | 민감하지 않음, 항상 도메인 기준 매칭 | 비교적 민감, 역조회 테이블이 지연될 수 있음 |
| 호환성 리스크 | 일부 프로그램이 비정상 주소 대역에 민감 | 호환성이 비교적 양호 |
간단히 말해 Fake-IP는 "도메인 매칭 + 가짜 주소 자리 채우기" 방식으로 속도와 CDN 환경에서의 안정성을 확보하는 대신, 클라이언트가 받는 주소가 실제 주소가 아니라는 대가를 지불합니다. IP의 유효성을 능동적으로 검사하거나 인증서 고정(certificate pinning) 외의 주소 검증을 수행하는 극히 일부 프로그램에서는 예외적인 동작이 발생할 수 있습니다.
Fake-IP를 회피하거나 화이트리스트에 추가해야 하는 시나리오
Fake-IP는 대부분의 웹 브라우징, 동영상 시청, 다운로드 시나리오에는 영향을 주지 않지만, 다음 몇 가지 경우는 주의가 필요합니다. 보통 fake-ip-filter 설정 항목을 통해 해당 도메인을 Fake-IP 처리 대상에서 제외하고 실제 DNS 해석을 사용하도록 합니다:
LAN 기기 및 내부망 서비스
라우터 관리 페이지, NAS, 프린터, 회사 내부망 시스템처럼 원래 LAN 주소로 해석되는 도메인에 접속할 때 Fake-IP가 개입되면 클라이언트는 가짜 주소를 받게 되고, 이후 코어가 직접 연결로 갈지 프록시로 갈지 다시 판단해야 하는데 이 과정 중 어느 한 단계라도 잘못 처리되면 접속이 안 될 수 있습니다. 대부분의 배포판은 흔히 쓰이는 LAN 도메인 접미사(예: .lan, .local)와 내부망 IP 대역을 기본적으로 필터 목록에 포함하고 있으며, 자체 구축한 내부망 도메인은 수동으로 추가하는 것이 좋습니다.
게임 온라인 플레이 및 P2P 애플리케이션
일부 온라인 게임, P2P 다운로드 도구, LAN 디스커버리 프로토콜은 실제 IP를 이용해 피어 연결 협상을 하거나 DNS 반환 결과의 유효성을 검사하는데, 198.18.0.0/16 같은 예약 대역 주소를 받으면 연결을 거부하거나 매칭에 실패합니다. 이런 애플리케이션의 도메인은 보통 fake-ip-filter 화이트리스트에 추가하거나, 아예 해당 애플리케이션 전체를 TUN 네트워크 카드를 거치지 않는 직접 연결로 설정해야 합니다.
시스템 레벨 탐지 및 통신사 종속 서비스
일부 통신사의 광랜 인증, IoT 기기의 클라우드 페어링 과정은 해석된 IP가 특정 대역에 속하는지 검증하며, 가짜 주소를 만나면 비정상으로 판정합니다. 이런 서비스에서 "인터넷은 되는데 특정 기능이 이상하다"는 현상이 나타나면 먼저 Fake-IP의 영향인지 확인한 뒤 화이트리스트 추가 여부를 결정하는 것이 좋습니다.
설정 예시와 진단 절차
mihomo 코어를 예로 들면 DNS 섹션의 일반적인 설정 구조는 다음과 같으며, enhanced-mode와 fake-ip-filter 두 항목을 중점적으로 봐야 합니다:
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.0/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "+.stun.*.*"
- "+.stun.*.*.*"
- "time.*.com"
- "*.market.xiaomi.com"
nameserver:
- 223.5.5.5
- 8.8.8.8
"Fake-IP로 의심되는 이상 현상"을 진단할 때는 다음 순서로 확인하는 것이 좋습니다:
- 먼저 해당 현상이 TUN 모드나 규칙 모드를 켰을 때만 나타나고 직접 연결 모드에서는 정상인지 확인합니다. 이 경우 DNS 처리 방식과 관련되어 있다고 기본적으로 판단할 수 있습니다.
- 코어 로그나 클라이언트의 연결 상세 패널을 확인해 목적지 주소가 198.18.0.0/16 같은 예약 대역에 속하는지 살펴 Fake-IP가 사용되고 있음을 확인합니다.
- 해당 도메인 또는 도메인 와일드카드 패턴을 fake-ip-filter에 추가하고, 코어를 재시작하거나 설정을 다시 적용한 뒤 재테스트합니다.
- 도메인이 고정되어 있지 않다면(예: 통신사 탐지 서비스가 자주 변경되는 경우) 필터 규칙을 하나씩 추가하는 대신 해당 애플리케이션 전체나 그 애플리케이션이 속한 LAN 대역을 직접 연결로 설정하는 것을 고려할 수 있습니다.
Fake-IP를 우선적으로 선택해야 하는 경우
일상적인 사용에서는 Fake-IP를 기본값으로 유지하는 것이 바람직합니다. 대부분의 트래픽에서 연결 수립 시간을 눈에 띄게 줄여 주기 때문이며, 특히 노드를 자주 전환하고 접속하는 도메인 종류가 다양한 사용 환경에서는 그 차이가 더욱 뚜렷합니다. 구체적이고 재현 가능한 연결 이상이 발생하고, 그것이 실제로 예약 대역 주소 때문임을 확인한 경우에만 해당 소수의 도메인만 별도로 처리해야 하며, Fake-IP 전체를 끄고 실제 해석으로 되돌리는 것은 바람직하지 않습니다. 그렇게 하면 모든 연결이 다시 완전한 DNS 왕복 지연을 감당해야 하므로 손해가 더 큽니다. 매핑 메커니즘을 이해한 뒤 선택과 조정을 해야 속도의 장점을 유지하면서도 주소의 실제성에 민감한 개별 서비스에 영향을 주지 않을 수 있습니다.