앱이 먼저 도메인을 조회한 뒤 IP 주소만으로 연결하는 경우, FakeDNS는 도메인과 가상 IP의 대응 관계를 저장해 프록시 코어에 들어오는 연결에서 도메인을 복원할 수 있게 합니다. 아래에서 DNS 조회, 매핑, 스니핑, 라우팅 순서로 원리를 살펴보고 v2rayN에서 TUN, DNS, 스니핑 설정을 확인하는 방법을 알아봅니다. 일반 시스템 프록시만 사용하는 경우에도 이 내용을 바탕으로 기능을 켤 필요가 있는지 판단할 수 있습니다.
FakeDNS가 해결하는 도메인 정보 손실
도메인별 라우팅이 제대로 작동하려면 라우팅을 판단할 때 대상 도메인을 알고 있어야 합니다. 브라우저가 HTTP 프록시로 요청을 보내면 프록시가 도메인을 직접 확인할 수 있는 경우가 많습니다. 반면 TUN 모드에서는 앱이 시스템 DNS로 도메인을 실제 IP 주소로 변환한 다음 해당 IP에 연결할 수 있습니다. 이때 TUN이 가로채는 것은 대상 IP뿐이므로 원래 도메인이 코어까지 전달되지 않을 수 있습니다. 라우팅 규칙에 도메인을 지정했더라도 IP 규칙으로만 판단하게 될 수 있습니다.
FakeDNS는 원격 웹사이트의 실제 주소를 찾아주는 기능이 아닙니다. DNS 조회를 임시 식별자로 바꿔 코어가 앱에 가상 IP를 반환하고, 그 가상 IP가 어떤 도메인에 해당하는지 저장합니다. 앱은 평소처럼 해당 주소에 연결하고, 코어가 연결을 받으면 저장된 매핑으로 도메인을 복원합니다. 이후 처리 방식은 라우팅과 아웃바운드 설정에 따라 달라집니다. FakeDNS를 프록시 프로토콜이나 새로운 서버 노드로 이해해서는 안 됩니다.
핵심 조건은 두 종류의 트래픽이 모두 같은 처리 경로를 거치는 것입니다. DNS 조회는 FakeDNS로 들어가고, 반환된 주소로 시작한 연결도 매핑을 확인할 수 있는 코어로 들어가야 합니다. 조회가 외부 시스템 DNS를 거치거나 연결이 TUN을 우회한다면 FakeDNS 옵션만 켜서는 도메인을 복원할 수 없습니다. 앱이 처음부터 고정 IP에 연결하는 경우에도 저장할 도메인이 없습니다.
가상 IP 할당과 도메인 복원 방식
자주 사용하는 IPv4 가상 주소 풀로 198.18.0.0/15가 있습니다. 이 대역은 네트워크 장비 성능 테스트용이며, 웹사이트에 접속할 때 직접 사용하는 공인 대상 주소가 아닙니다. FakeDNS는 설정된 주소 풀에서 주소를 골라 조회한 앱에 반환하고 코어 내부에 대응 관계를 저장합니다. 주소 풀의 범위와 할당 가능한 수, 캐시 상태는 설정과 코어 구현에 따라 다르므로 특정 가상 IP를 영구적인 도메인 식별자로 여겨서는 안 됩니다.
여기서 말하는 ‘스니핑’은 TLS 핸드셰이크나 HTTP 요청에서 도메인을 읽는 것만을 뜻하지 않습니다. FakeDNS를 지원하는 코어는 앞서 저장한 가상 IP 매핑으로 연결 대상을 도메인으로 복원할 수도 있습니다. HTTP Host나 TLS SNI 같은 일반적인 스니핑 정보는 도메인을 알아낼 수 있는 또 다른 경로입니다. 앱이 사용하는 프로토콜과 암호화 여부, 도메인 정보 포함 여부는 일반적인 스니핑에 영향을 주지만, ‘FakeDNS 응답을 받은 뒤 매핑을 찾는다’는 기본 흐름의 조건은 바뀌지 않습니다.
확인할 핵심: 연결에서 매핑이 조회되는지
로그에 DNS가 가상 IP를 반환한 기록만 있다고 해서 도메인별 라우팅이 성공한 것은 아닙니다. 이후 연결도 같은 코어에서 처리되는지, 라우팅 기록에서 대상 도메인이 복원되는지 확인하세요. 대상이 계속 가상 IP로만 표시된다면 먼저 TUN 캡처 범위와 스니핑 설정을 점검합니다.
코어를 재시작하거나 매핑이 삭제된 경우, 또는 앱이 이전 DNS 응답을 오래 캐시한 경우 앱이 도메인을 찾을 수 없는 가상 IP에 계속 연결할 수 있습니다. ‘설정을 바꾼 직후에는 접속되지 않다가 잠시 뒤 정상화되는’ 상황이라면 서버 주소를 바로 바꾸기보다 앱에서 DNS를 다시 조회하게 하세요. 필요한 경우 앱을 종료한 뒤 다시 실행합니다.
v2rayN의 TUN 환경에서 확인할 설정
먼저 v2rayN의 ‘설정’ → ‘매개변수 설정’에서 현재 사용하는 코어와 TUN 관련 옵션을 확인한 다음 DNS와 트래픽 스니핑 설정을 살펴봅니다. 버전에 따라 메뉴 이름과 옵션 위치가 달라질 수 있으므로 실제 화면의 항목을 기준으로 확인하세요. FakeDNS, DNS 가로채기, TUN 캡처, 스니핑은 서로 연동되어야 합니다. 어느 한 항목만 선택했다고 전체 경로가 작동한다고 볼 수는 없습니다.
DNS 조회 경로
- 확인 위치
- ‘설정’ → ‘매개변수 설정’
- 확인할 항목
- 현재 코어, TUN 및 DNS 옵션
- 정상 동작 시
- 앱의 조회가 설정된 DNS에서 처리됨
- 이상 징후
- 실제 공인 IP가 계속 반환됨
먼저 조회가 코어에 전달되는지 확인한 뒤, 반환 주소가 설정된 가상 주소 풀에 속하는지 살펴보세요.
연결 및 라우팅 경로
- 확인 위치
- v2rayN 코어 로그 및 라우팅 설정
- 확인할 항목
- 스니핑 활성화, 도메인 규칙, 아웃바운드
- 정상 동작 시
- 복원된 도메인에 따라 연결 규칙이 적용됨
- 이상 징후
- 로그에 가상 IP만 표시됨
라우팅 결과는 규칙 순서에도 영향을 받습니다. FakeDNS는 도메인을 복원할 뿐, 어떤 아웃바운드를 사용할지는 결정하지 않습니다.
검증할 때는 도메인별 라우팅 규칙에 명시된 테스트 도메인을 하나 선택하세요. 관련 기능을 끄었을 때의 라우팅 결과를 먼저 기록한 뒤 DNS 응답, 연결 캡처, 규칙 적용 여부를 차례로 확인합니다. ‘웹페이지가 열린다’는 것만으로 판단하지 마세요. 같은 페이지가 직접 연결과 프록시 아웃바운드 양쪽에서 열릴 수 있습니다. 공인 도메인 규칙을 확인하면서 내부 네트워크 기기 이름을 테스트하는 것도 피하세요. 두 경우의 DNS 조회 경로는 대개 다릅니다.
구독은 서버 연결 정보를 제공할 뿐, 로컬 DNS 및 TUN 설정까지 구성해 주지는 않습니다. VMess 또는 VLESS 노드를 바꿔도 FakeDNS 조회 경로는 로컬 환경에서 따로 확인해야 합니다. 노드에 연결된다는 사실만으로 도메인이 예상대로 라우팅된다고 볼 수 없습니다. 문제를 찾을 때는 같은 노드를 유지하고 로컬 설정을 한 번에 하나씩만 바꾸면 로그를 비교하기 쉽습니다.
FakeDNS를 켜기 좋은 트래픽과 실제 DNS 응답을 유지할 트래픽
FakeDNS는 ‘앱이 먼저 도메인을 조회하고 TUN이 나중에 연결을 가로채는’ 상황에 특히 유용합니다. 앱은 IP 주소에만 연결하지만 라우팅 규칙에는 원래 도메인이 필요한 경우입니다. 앱이 실제 DNS 응답을 먼저 받아 코어에 도달하기 전에 도메인 정보가 사라지는 경우도 줄일 수 있습니다. 다만 모든 DNS 문제를 해결하는 만능 기능은 아닙니다. 상위 DNS, 라우팅 규칙, 앱 자체의 DNS 동작은 각각 확인해야 합니다.
| 트래픽 유형 | 우선 확인할 사항 | 사용 권장 사항 |
|---|---|---|
| TUN을 통한 공인 도메인 접속 | DNS 조회와 연결이 모두 코어로 들어가는지 | 도메인별 라우팅이 필요하면 FakeDNS 매핑을 테스트 |
| LAN 기기 및 내부 도메인 | 로컬 DNS, LAN 직접 연결 규칙 | LAN 접속에 영향을 주지 않도록 실제 주소를 우선 유지 |
| 숫자 IP로 직접 접속 | IP 라우팅 규칙 | FakeDNS로 복원할 원래 도메인이 없음 |
| 앱 자체의 암호화 DNS 사용 | 앱의 DNS 조회가 로컬 DNS 경로를 우회하는지 | 먼저 조회 경로를 확인하고 시스템 DNS 설정만으로 판단하지 않기 |
LAN 프린터, 라우터 관리 페이지, 기업 내부 서비스는 특히 주의해야 합니다. 이러한 서비스는 실제 내부망 주소를 반환하는 로컬 DNS에 의존할 수 있습니다. 조회 결과가 가상 주소로 바뀌었는데 이후 연결이 예상대로 코어에 들어오지 않으면 접속에 실패합니다. 먼저 해당 도메인이나 대상 네트워크에 로컬 DNS와 직접 연결 경로를 명확하게 지정한 뒤 공인 도메인에 FakeDNS를 테스트하세요. 모든 조회를 무조건 가상 주소 풀로 보내서는 안 됩니다.
결론: 트래픽 진입 경로에 따라 사용 여부 결정
주로 일반 시스템 프록시를 사용하고 도메인 규칙이 제대로 적용된다면 ‘DNS 기능을 하나 더 추가’하려고 기존 조회 경로를 바꿀 필요는 없습니다. TUN 환경에서 도메인 정보가 사라지는 것을 확인한 경우에만 해당 트래픽에 FakeDNS를 테스트하고, 로컬 리소스는 별도 경로로 처리하세요.
앱이 직접 암호화 DNS 조회를 보내거나 다른 네트워크 구성 요소에 요청을 맡기는 경우도 있습니다. 이때 v2rayN은 일반 DNS 조회를 확인하지 못할 수 있습니다. 이후 연결이 TUN에 잡히더라도 조회할 가상 IP 매핑이 없을 수 있습니다. FakeDNS 할당 실패를 먼저 의심하기보다 앱이 실제로 어디에 DNS 조회를 보내는지부터 확인하세요.
활성화 후 접속 불가: 증상별 점검
먼저 문제를 세 가지로 나눠 보세요. 가상 IP를 받지 못한 경우, 가상 IP를 받았지만 연결되지 않는 경우, 연결은 되지만 예상한 도메인 규칙이 적용되지 않는 경우입니다. 각각 DNS 진입 경로, 연결 캡처 및 매핑, 라우팅 규칙에 해당합니다. 한 번의 테스트에서 나온 조회 결과와 같은 시간대의 코어 로그를 함께 보관하면 서로 다른 요청의 증상을 섞어 판단하는 일을 줄일 수 있습니다.
FakeDNS를 켰는데도 웹사이트의 실제 IP가 조회되나요?
먼저 ‘설정’ → ‘매개변수 설정’에서 현재 코어와 TUN, DNS 옵션을 확인한 다음 조회를 시작한 앱이 해당 DNS 경로를 사용하는지 살펴보세요. 조회가 FakeDNS에 들어오지 않는다면 스니핑 규칙을 바꿔도 DNS 응답은 달라지지 않습니다.
198.18 대역 주소를 받았는데 웹페이지가 계속 로딩되나요?
이후 TCP 또는 UDP 연결이 TUN에 캡처되는지 확인하고 코어 로그에서 해당 요청을 찾으세요. 연결이 코어를 우회하면 가상 IP는 실제 웹사이트 주소처럼 직접 접속할 수 없습니다. 코어를 방금 재시작했다면 앱에서 DNS를 다시 조회하게 하세요.
공인 웹사이트는 접속되는데 LAN 기기는 열리지 않나요?
로컬 DNS와 LAN 직접 연결 설정을 확인해 내부 도메인과 내부망 주소에 실제 DNS 응답이 사용되도록 하세요. 설정을 바꾼 뒤 기기 도메인을 다시 조회해 가상 주소 풀이 아닌 실제 내부망 주소가 반환되는지 확인합니다.
도메인은 복원됐는데 왜 아웃바운드가 잘못 선택되나요?
라우팅 설정에서 규칙 내용과 우선순위를 확인하고 해당 도메인이 앞선 다른 규칙에 먼저 적용되는지 살펴보세요. FakeDNS는 판단에 필요한 도메인을 복원할 뿐이며, 최종 아웃바운드는 라우팅 설정에 따라 결정됩니다.
문제가 특정 앱에서만 발생한다면 브라우저와 해당 앱을 비교해 보세요. 두 앱이 같은 DNS 경로를 사용하는지, 둘 다 TUN을 거치는지, 같은 도메인에 연결하는지 확인합니다. 브라우저가 정상이라고 해서 모든 앱의 DNS 조회 방식도 같다고 볼 수는 없습니다. 설정을 바꾼 직후에만 잠시 문제가 생긴다면 앱에 이전 가상 IP가 캐시됐을 가능성이 있으므로 조회를 다시 실행한 뒤 확인하세요.
마지막으로 노드와 프로토콜 계층을 살펴보세요. v2rayN에서 VMess 또는 VLESS 서버에 연결되는지와 FakeDNS 매핑이 정상인지 여부는 서로 다른 문제입니다. 로그에서 도메인 규칙이 적용되고 아웃바운드도 선택됐는데 요청이 계속 시간 초과되는 경우에만 노드 연결을 점검하세요. 구독, 라우팅, DNS를 한꺼번에 바꾸기보다 DNS, 스니핑, 라우팅, 아웃바운드 순으로 범위를 좁히는 편이 원인을 찾기 쉽습니다.