FakeDNS는 로컬에서 할당한 가상 주소로 도메인 정보를 보존하는 기능입니다. 공용 DNS도 새로운 프록시 프로토콜도 아닙니다. 연결이 정상적으로 작동하고 TUN 및 도메인 분기 설정을 조정하려는 사용자를 위한 글입니다. DNS 조회와 연결이 어떻게 이어지는지 확인한 다음 설정 범위를 점검하고, 캐시·DNS 가로채기·로컬 네트워크 접속 문제를 차례로 살펴봅니다. 특별한 이유가 없다면 현재 정상 작동하는 실제 주소 해석 방식을 그대로 사용하는 편이 좋습니다.
FakeDNS 원리: 가상 주소는 도메인 매핑을 위한 색인
일반 DNS는 도메인 이름을 대상 서비스의 실제 주소로 변환합니다. FakeDNS는 로컬 주소 풀에서 주소를 골라 도메인과 가상 IP의 매핑을 저장한 뒤 가상 주소를 앱에 반환합니다. 예를 들어 앱이 example.org의 A 레코드를 조회하면 198.18.0.1을 받을 수 있습니다. 이는 설명을 위한 예시이며, 실제 할당 순서는 구현 방식과 실행 상태에 따라 달라집니다.
이후 앱은 해당 가상 IP로 연결을 시도합니다. 트래픽을 가로채는 구성 요소는 대상 주소를 확인해 도메인을 찾아낸 다음 라우팅과 아웃바운드 처리에 전달합니다. 따라서 FakeDNS의 핵심은 단순히 “특수한 IP 주소를 응답하는 것”이 아닙니다. DNS 조회와 후속 연결이 모두 같은 매핑을 공유하거나 활용할 수 있는 처리 경로를 거쳐야 합니다.
198.18.0.0/15는 벤치마크 테스트용으로 예약된 주소 대역이며, 198.18.0.0부터 198.19.255.255까지 포함합니다. 일반적인 공용 인터넷 서비스 주소가 아닙니다. FakeDNS는 이 대역을 사용하는 경우가 많지만, 구현에 따라 다른 주소 풀을 쓸 수도 있습니다. 가상 주소가 가로채기 경로를 거치지 않고 물리 네트워크로 전송되면 원래 접속하려던 웹사이트에 연결되지 않는 경우가 대부분입니다.
TUN과 도메인 분기: 가로채기·복원·규칙 적용이 모두 필요합니다
TUN은 네트워크 계층에서 IP 패킷을 수신합니다. 연결을 처음 가로챌 때 확인할 수 있는 정보는 대개 대상 IP, 포트, 전송 프로토콜뿐입니다. 앱이 이미 도메인을 조회했다면 패킷에 도메인 정보가 더 이상 직접 포함되지 않을 수 있습니다. FakeDNS는 “이 주소에 원래 어떤 도메인이 연결되어 있었는지”를 매핑에 미리 저장해 도메인 규칙이 참고할 단서를 제공합니다.
- DNS 가로채기: 앱의 DNS 조회가 예상한 DNS 처리 경로로 들어와야 합니다. 기존 DNS는 주로 UDP 53을 사용하지만 TCP 53을 쓸 수도 있습니다. 한쪽만 처리한다고 해서 모든 DNS 조회를 가로챘다고 볼 수는 없습니다.
- 연결 가로채기: 가상 주소 대역으로 향하는 TCP 또는 UDP 트래픽은 해당 TUN, 라우팅 및 코어 처리 경로로 들어와야 합니다. 제외 규칙이 먼저 적용되어 트래픽이 우회하면 안 됩니다.
- 도메인 복원: 연결을 수신하는 구성 요소가 매핑을 사용할 수 있어야 합니다. Xray 관련 설정에서는 FakeDNS와 인바운드 스니핑을 함께 확인해야 합니다. DNS 목록에 이름 하나를 추가하는 것만으로는 전체 흐름이 완성되지 않습니다.
- 규칙 적용: 도메인을 복원한 뒤 도메인 규칙, IP 규칙, 기본 규칙에 따라 아웃바운드를 결정합니다. VMess, VLESS 등의 프로토콜은 이후 프록시 전송을 담당하며 이 매핑을 생성하지 않습니다.
브라우저가 시스템 HTTP 프록시를 통해 HTTPS 웹사이트에 접속하면 CONNECT 요청에 대상 호스트 이름을 담을 수 있습니다. SOCKS5도 주소 유형으로 도메인 이름을 사용할 수 있습니다. 이런 경로에서는 도메인이 이미 프록시에 전달되므로 FakeDNS가 필요하지 않을 수 있습니다. 반대로 앱이 로컬에서 도메인을 조회한 뒤 IP 주소만 전달한다면 도메인 정보를 어떻게 가져올지 따로 확인해야 합니다.
판단 기준: 먼저 도메인 정보가 라우팅 계층까지 전달되는지 확인하세요
현재 시스템 프록시 경로에서 도메인 규칙이 정상적으로 적용된다면 우선 기존 설정을 유지하세요. TUN으로 가로챈 뒤 도메인 정보가 부족하고 DNS와 연결이 모두 같은 처리 경로로 들어올 수 있을 때 FakeDNS 도입을 검토하면 됩니다.
설정 점검: 주소 풀과 도메인 복원 경로를 함께 구성해야 합니다
v2rayN은 데스크톱 클라이언트이며, v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 클라이언트 인터페이스, 선택한 코어, TUN 연결 구성 요소는 서로 다른 계층입니다. 클라이언트 이름만으로 설정 항목의 사용 가능 여부를 판단할 수 없습니다. 아래 키와 값은 Xray 설정의 관계를 설명하기 위한 것으로, 세 클라이언트 모두 같은 이름의 스위치를 제공한다는 뜻이 아닙니다. 완성된 설정 파일로 그대로 가져와 사용할 수도 없습니다.
가상 주소 할당 측
- 설정 객체
fakedns- 주소 풀 예시
198.18.0.0/15- 용량 예시
poolSize: 65535- DNS 서비스 항목
fakedns
용량은 예시 설정값일 뿐 노드 수나 동시 연결 수를 보장하지 않습니다. 주소 풀을 정의한 뒤에는 해당 풀을 실제 DNS 조회에 사용하도록 설정해야 합니다.
연결 복원 측
- 인바운드 설정
sniffing- 사용 설정 항목
enabled: true- 복원 유형
destOverride: ["fakedns"]- 가로채기 대상
- 가상 주소 풀로 향하는 연결에 적용
실제 트래픽을 처리하는 인바운드를 점검해야 합니다. 트래픽이 지나지 않는 인바운드에 설정 항목만 추가해서는 안 됩니다.
아래는 Xray 기본 JSON 형식의 주소 할당 설정 일부로, 주소 풀과 내장 DNS의 연결만 보여줍니다. 인바운드, 아웃바운드, 라우팅, 트래픽 가로채기 설정은 포함하지 않으므로 클라이언트가 생성한 전체 설정 파일을 대체할 수 없습니다. 클라이언트가 다른 구성 요소로 TUN과 DNS를 처리한다면 해당 구성 요소의 설정 구조를 따르고, 서로 다른 설정 항목을 섞어 쓰지 마세요.
{
"fakedns": [
{
"ipPool": "198.18.0.0/15",
"poolSize": 65535
}
],
"dns": {
"servers": [
"fakedns"
]
}
}- 먼저 현재 설정을 백업한 뒤 실제로 생성된 실행 설정을 확인하세요. 인터페이스에서 “TUN 사용”을 켰다고 해서 FakeDNS까지 활성화된 것은 아닙니다.
- 클라이언트 시작 시 알 수 없는 설정 항목, 설정 파싱 오류, 주소 풀 충돌이 없는지 확인하세요. 설정이 정상적으로 적용되지 않으면 즉시 이전 상태로 되돌리고 노드 프로토콜 설정은 동시에 변경하지 마세요.
- A 및 AAAA 조회 처리 방식을 각각 확인하세요. 위의 IPv4 주소 풀 예시만으로 IPv6 조회에도 이에 대응하는 가상 매핑이 제공된다고 볼 수는 없습니다.
- 직접 연결과 프록시 아웃바운드에서 복원된 도메인을 각각 어떻게 처리하는지 확인하세요. 최종 연결에 실제 주소가 필요하다면 사용할 수 있는 DNS 조회 경로가 있어야 합니다. 조회가 가상 주소 할당 측으로 계속 되돌아가게 해서는 안 됩니다.
사용 사례와 부작용: 모든 앱에 가상 IP가 적합한 것은 아닙니다
FakeDNS는 일부 연결에서 로컬로 실제 주소를 조회할 필요를 줄이고, IP 연결로 바뀐 요청을 도메인 규칙이 식별하도록 도울 수 있습니다. 하지만 원격 DNS 조회 시간을 자동으로 단축하거나 사용할 수 없는 노드, 잘못된 TLS 설정, 잘못된 라우팅 규칙 순서를 해결해 주지는 않습니다. 효과는 DNS 응답 속도가 빨라졌는지가 아니라 도메인 식별과 앱 호환성을 기준으로 판단해야 합니다.
| 사용 사례 | 주요 영향 | 대응 방법 |
|---|---|---|
| TUN에서 도메인별로 분기 | IP 연결에서 매핑을 통해 도메인 정보를 복원할 수 있음 | DNS, 가상 네트워크 대역, 도메인 복원 경로가 모두 연결되는지 확인 |
| 로컬 네트워크 서비스와 내부 도메인 | 서비스 검색 및 내부 DNS 조회가 잘못 가로채질 수 있음 | 내부 도메인과 네트워크 대역은 실제 DNS 조회 및 직접 연결 경로를 사용하도록 설정 |
| 기업 네트워크에서 같은 주소 대역 사용 | 가상 주소 풀이 기존 라우팅과 충돌할 수 있음 | 라우팅 테이블을 확인하고, 구현 방식에 따라 주소 풀을 변경하거나 기능을 끄세요 |
| 앱에서 DNS 조회 결과 검사 | 앱이 예약 주소를 거부하거나 가상 주소를 캐시할 수 있음 | 해당 앱은 실제 주소 조회를 사용하도록 설정하고 로그인과 연결을 다시 테스트 |
| 앱에서 암호화 DNS 사용 | DNS 조회가 일반적인 53번 포트 가로채기를 우회할 수 있음 | 앱의 DNS 설정을 확인하고 암호화된 연결을 일반 DNS로 오인해 강제 리디렉션하지 마세요 |
IP 주소를 직접 지정하는 프로그램은 먼저 도메인을 조회하지 않으므로 FakeDNS가 도메인을 만들어 낼 수 없습니다. 로컬 네트워크의 멀티캐스트 이름 검색도 일반적인 유니캐스트 DNS와 다릅니다. 53번 포트 규칙만 조정해서는 프린터, 파일 공유 또는 내부 서비스 검색 문제가 해결되지 않을 수 있습니다.
선택 기준: 내부 서비스는 실제 DNS 조회를 우선하세요
업무 네트워크에서 내부 DNS를 사용한다면 먼저 내부 도메인, DNS 서버, 관련 네트워크 대역의 조회 및 연결 경로를 확인하세요. 로그인이나 서비스 검색에 문제가 생기면 프록시 범위를 넓혀 문제를 덮으려 하지 말고 FakeDNS부터 되돌리세요.
검증 절차: DNS, 매핑, 아웃바운드를 각각 확인하세요
검증할 때는 동일한 테스트 도메인을 사용하고 노드와 라우팅 규칙을 고정한 뒤 한 번에 설정 하나만 변경하세요. 가상 주소가 보였다는 것은 특정 조회에서 가상 응답을 받았다는 뜻일 뿐입니다. 웹사이트가 열려도 모든 앱이 같은 경로를 거쳤다고 단정할 수 없습니다. DNS 응답, 가로채기 로그, 규칙 적용 결과를 함께 확인해야 합니다.
- 기준 상태 기록: FakeDNS를 끄고 테스트 도메인 접속 여부, 현재 DNS 응답, 아웃바운드 규칙을 기록합니다. 복원할 수 있는 설정을 보관하고 구독에 포함된 서버 주소는 변경하지 마세요.
- DNS 조회 확인: 기능을 켠 뒤 같은 도메인을 조회하고 A 레코드가 실제 설정한 가상 주소 풀에 속하는지 확인합니다. 여전히 실제 IP가 표시된다면 주소 풀을 서둘러 바꾸지 말고 캐시, 앱 자체 DNS, DNS 라우팅부터 살펴보세요.
- 도메인 복원 확인: 새 연결을 만들어 로그에 원래 도메인과 예상 아웃바운드가 함께 표시되는지 확인합니다. 가상 IP로 직접 연결하는 로그만 보인다면 먼저 도메인 복원 경로와 네트워크 대역 라우팅을 점검하세요.
- 호환성 확인: 웹사이트, 내부 서비스, 브라우저가 아닌 앱 하나를 각각 테스트하세요. UDP 앱도 별도로 확인해야 합니다. 웹사이트의 TCP 연결 성공만으로 UDP까지 정상이라고 볼 수는 없습니다.
Windows에서는 먼저 시스템이 현재 사용하는 DNS 응답을 확인하고 설정을 바꾼 뒤 시스템 DNS 캐시를 지울 수 있습니다. 아래 명령은 각각 조회와 캐시 삭제에 사용되며 성능 테스트나 고정된 예상 주소 확인용이 아닙니다.
nslookup example.org
ipconfig /flushdns시스템 캐시를 지워도 브라우저나 앱 내부 캐시까지 삭제되는 것은 아닙니다. FakeDNS를 끄거나 매핑 구성 요소를 재시작한 뒤에도 앱에 이전 가상 주소가 남아 있을 수 있습니다. 매핑이 이미 사라졌다면 해당 주소를 사용하는 기존 연결은 실패합니다. 설정을 되돌릴 때는 관련 앱을 종료하고 시스템 캐시를 지운 다음 앱을 다시 실행해 확인하세요.
자주 묻는 질문: 사용 중 문제가 생기면 어디부터 확인하나요?
198.18로 시작하는 주소가 조회되는데 DNS 오류인가요?
먼저 실제 주소 풀을 확인하세요. FakeDNS가 켜져 있고 198.18.0.0/15를 사용하도록 설정되어 있다면 정상 응답일 수 있습니다. 이어서 연결을 시도하고 도메인 복원 및 아웃바운드 로그를 확인하세요. 기능을 껐는데도 이런 주소가 계속 반환된다면 시스템과 앱 캐시를 지우고 다른 DNS 가로채기 구성 요소가 실행 중인지 확인하세요.
사용 설정 후 브라우저는 되는데 다른 앱은 인터넷에 연결되지 않는 이유가 뭔가요?
앱별 DNS를 사용하는지, TUN 가로채기 대상에서 제외되었는지, 예약 주소를 거부하는지 각각 확인하세요. 먼저 문제가 있는 앱에서 실제 주소 조회 방식을 사용하도록 되돌린 뒤 앱을 재시작해 테스트하세요. 브라우저가 된다는 이유만으로 모든 앱의 트래픽을 가로채도록 범위를 넓히지 마세요.
FakeDNS를 켜면 원격 DNS 설정이 필요 없나요?
아닙니다. 가상 주소 할당 측은 로컬 매핑만 처리합니다. 직접 연결 아웃바운드나 원격 프록시가 실제 연결을 만들 때는 도메인 조회가 여전히 필요할 수 있습니다. 최종 DNS 조회를 담당하는 구성 요소와 DNS 아웃바운드를 확인하고, 프록시 서버 도메인 조회가 아직 연결되지 않은 프록시에 의존하지 않도록 하세요.
기능을 껐는데도 웹사이트가 열리지 않으면 클라이언트를 다시 설치해야 하나요?
먼저 원래 DNS 및 트래픽 가로채기 설정을 복원하고 ipconfig /flushdns를 실행한 다음 브라우저를 완전히 종료했다가 다시 여세요. 이후 시스템 프록시가 이미 중지된 로컬 서비스로 설정되어 있지 않은지 확인합니다. Android에서는 클라이언트 VPN 연결과 관련 앱을 중지한 뒤 다시 실행하고 테스트하세요. 대개 먼저 오래된 캐시와 남아 있는 가로채기 상태를 확인해야 합니다.
최종적으로는 연결 경로를 설명할 수 있고 도메인 규칙이 적용되며 일상적으로 사용하는 앱이 안정적으로 작동해야 합니다. FakeDNS는 DNS 처리와 트래픽 가로채기를 연동하는 방법 중 하나일 뿐입니다. 구독 가져오기, 노드 선택, 시스템 프록시, TUN 설정은 각각 따로 확인해야 합니다.