웹페이지는 프록시로 접속되지만 DNS 테스트에서 로컬 통신사 DNS가 표시되거나, DNS를 변경한 뒤 일부 도메인이 열리지 않는 경우에 참고하세요. 먼저 브라우저·운영체제·코어의 세 가지 DNS 경로를 구분하고, 비교 테스트로 요청이 어디서 발생하는지 확인합니다. 마지막으로 사용 중인 코어에 맞춰 DNS와 라우팅 설정을 기존 구성에 병합하세요. 아래 예시는 전체 노드 설정 파일이 아니며 기존 프록시 아웃바운드를 대체할 수 없습니다.
DNS 누수 판단 기준: 위치가 아니라 DNS 조회 경로
DNS 누수란 예상한 프록시 경로로 처리되어야 할 도메인 조회가 다른 DNS 서버로 전달되는 현상입니다. 예를 들어 웹 연결은 프록시를 통하지만 앱이 먼저 라우터에 도메인을 조회하고, 라우터가 이를 로컬 통신사에 전달할 수 있습니다. 웹 트래픽의 외부 IP가 바뀌었다고 DNS 조회 경로까지 바뀐 것은 아닙니다.
브라우저의 보안 DNS, 운영체제 DNS, V2Ray 내장 dns가 동시에 사용될 수 있습니다. 해당 요청이 각 처리 경로에 들어와야 관련 설정이 적용됩니다. 시스템 프록시는 보통 프록시 설정을 따르는 앱 연결만 처리하며, 모든 UDP 조회를 가로채지는 않습니다. JSON에 dns.servers를 추가해도 네트워크 어댑터의 DNS 요청이 자동으로 이 설정을 따르지는 않습니다.
- 브라우저가 직접 조회: 보안 DNS를 사용하면 브라우저가 시스템 DNS 대신 지정된 DoH 서버에 직접 질의할 수 있습니다.
- 시스템에서 먼저 조회: 앱이 IP 주소를 먼저 받은 다음 연결을 프록시에 전달합니다. 이때 코어에는 IP 주소만 전달될 수 있으므로 이미 전송된 DNS 요청을 되돌릴 수 없습니다.
- 필요할 때 코어가 조회: IP 라우팅 규칙 매칭, 일부 아웃바운드 연결 또는 DNS 인바운드 전달 과정에서 내장 DNS가 동작할 수 있지만, 다른 프로세스의 요청까지 처리한다고 보장할 수는 없습니다.
판단 기준: 먼저 DNS 서버의 소속 확인
테스트 페이지에 노드와 다른 국가가 표시된다는 이유만으로 누수라고 단정할 수는 없습니다. 먼저 DNS 서버 주소와 운영 주체를 확인하고 예상한 DNS 서비스인지 비교하세요. 공용 DNS의 애니캐스트 운영 방식과 테스트 데이터베이스에 따라 표시 지역이 달라질 수도 있습니다.
테스트 절차: 직접 연결과 프록시 연결 비교
테스트 중에는 브라우저, 네트워크, 테스트 서비스를 동일하게 유지하세요. 매회 웹 외부 IP, DNS 서버 IP, 브라우저 보안 DNS 상태, 클라이언트 라우팅 모드를 기록합니다. 아래는 점검 방법이며 이 사이트에서 직접 테스트한 결과가 아닙니다. 특정 회차에 표시된 DNS 서버 수를 일반적인 합격 기준으로 삼지 마세요.
기준값 기록
프록시 연결을 잠시 종료하고 브라우저 DNS 누수 테스트를 실행해 DNS 서버 주소와 운영 주체를 기록합니다. 공유 사무실 네트워크나 회사 장비라면 네트워크 설정을 변경해도 되는지 먼저 확인하세요.
브라우저 설정 고정
브라우저의 「설정」에서 「보안 DNS」를 검색해 현재 상태를 기록합니다. 원인을 분리하기 위해 점검 중에는 보안 DNS를 잠시 끌 수 있습니다. 점검이 끝나면 원래 설정으로 되돌리고, 시스템 DNS는 동시에 변경하지 마세요.
프록시 사용
v2rayN을 실행한 뒤 트레이 메뉴의 「시스템 프록시」에서 「시스템 프록시 자동 설정」을 선택하고, 활성 서버와 라우팅 모드를 확인합니다. 테스트 페이지를 새로 열어 다시 검사하세요.
캐시 비우기
Windows 터미널에서
ipconfig /flushdns를 실행한 다음 브라우저를 완전히 종료하고 다시 여세요. 이 명령은 시스템 DNS 캐시만 비우며 브라우저 자체 캐시를 지우지는 않습니다.항목별 재검사
매회 변수 하나만 변경하세요. 브라우저 DNS, 코어 DNS, 요청 가로채기 방식 순으로 확인합니다. 최소 두 번 반복하고 결과가 일정하지 않으면 시간과 로그를 기록하세요. 이전 캐시를 새 설정의 적용 결과로 오인하지 않도록 주의해야 합니다.
명령줄로 요청이 들어오는 경로를 확인할 수도 있습니다. 아래 예시는 SOCKS 포트 10808을 사용하며, 실제 포트는 클라이언트 설정을 따릅니다. --socks5-hostname은 대상 도메인을 SOCKS 프록시에 전달합니다. 이 앱 연결에서 도메인이 어떻게 전달되는지는 확인할 수 있지만, 시스템 전체에 DNS 우회 경로가 없다는 뜻은 아닙니다.
curl.exe --proxy socks5h://127.0.0.1:10808 https://example.com/ --head
ipconfig /flushdns
Resolve-DnsName example.com -Type A마지막 명령은 PowerShell에서 실행되며 보통 시스템 DNS 경로를 사용합니다. HTTP 시스템 프록시를 설정했더라도 자동으로 V2Ray를 거치지는 않습니다. 브라우저와 결과가 다르다면 두 요청의 진입 경로가 다르다는 의미일 수 있으며, 그것만으로 코어 설정이 적용되지 않았다고 판단할 수는 없습니다.
포트와 프로토콜: 로컬 프록시, DNS, DoH 구분하기
해당 포트에서 로컬 DNS 서비스가 실제로 대기 중인 경우가 아니라면 네트워크 어댑터 DNS를 127.0.0.1로 바꾸지 마세요. SOCKS와 DNS는 서로 다른 프로토콜입니다. DNS 요청을 10808로 보내도 자동으로 DNS 응답을 받을 수 없습니다. 클라이언트가 혼합 포트를 사용할 수도 있으므로 현재 생성된 설정을 확인해야 합니다.
| 설정 위치 | 주요 역할 | 이 설정만으로는 알 수 없는 점 |
|---|---|---|
| 시스템 네트워크 어댑터 DNS | 시스템 DNS 설정을 따르는 프로그램에서 사용 | 브라우저 자체 DoH가 같은 서비스를 사용한다고 보장할 수 없음 |
코어 dns.servers | 내장 DNS 조회에 사용할 업스트림 지정 | 다른 프로그램의 DNS 요청을 자동으로 가로채지 않음 |
routing.rules | 코어에 들어온 연결이 사용할 아웃바운드 결정 | 코어 밖에서 이미 완료된 DNS 조회를 바꾸지 못함 |
| TUN DNS 가로채기 | 구현 방식에 따라 DNS 트래픽을 포착하거나 리디렉션 | 모든 암호화 DNS를 식별해 변경할 수 있다고 보장할 수 없음 |
dns.servers 설정: DNS 요청의 프록시 경로 지정
아래는 원격 DoH와 DNS 트래픽 태그를 설명하기 위한 V2Ray/Xray 형식의 설정 조각입니다. 사용 중인 코어가 해당 필드를 지원하고, 기존 outbounds에 proxy라는 이름의 사용 가능한 프록시 아웃바운드가 있어야 합니다. 실제 태그 이름이 다르면 현재 값에 맞게 수정하세요. 이 조각만으로 전체 설정을 구성해 실행하지 마세요.
{
"dns": {
"tag": "dns-query",
"servers": [
"https://1.1.1.1/dns-query"
],
"queryStrategy": "UseIPv4"
},
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"inboundTag": ["dns-query"],
"outboundTag": "proxy"
}
]
}
}dns.tag: 내장 DNS가 생성한 조회 트래픽에 라우팅 식별자를 지정합니다. 여기서는inboundTag로dns-query를 매칭하며, SOCKS 인바운드를 새로 만드는 것이 아닙니다.servers: 예시에서는 IP 형식의 DoH 주소를 사용해 DNS 서비스 자체의 도메인을 먼저 조회해야 하는 단계를 줄였습니다. 현재 네트워크와 프록시 경로에서 서비스에 연결할 수 있는지는 별도로 확인해야 합니다.queryStrategy:UseIPv4는 내장 DNS 조회를 IPv4로 제한해 먼저 IPv6 경로 차이를 배제할 수 있게 합니다. 듀얼 스택 환경에서는 설정을 확인한 뒤UseIP사용을 검토하세요.- 규칙 순서: 이 DNS 전용 규칙을 광범위한 직접 연결 규칙보다 앞에 두고 기존의 다른 규칙은 유지하세요. 앞선 규칙이 이미 매칭되면 뒤에 있는 DNS 프록시 규칙은 적용되지 않습니다.
DoH는 클라이언트와 DNS 서비스 사이의 조회 연결을 암호화하지만, 이 연결이 프록시를 통과하는지는 라우팅 설정에 따라 달라집니다. 일부 코어에는 +local로 끝나는 이름의 로컬 처리 모드가 있으며, 일반 원격 모드와 라우팅 방식이 다릅니다. 단지 “더 빠르다”는 이유로 이 예시의 설정을 바꾸지 마세요. 도메인별로 DNS를 분기하려면 도메인 조건이 있는 업스트림 규칙을 추가하고, 폴백 조회가 의도치 않은 DNS 서비스를 사용하지 않는지도 확인하세요.
domainStrategy: 라우팅 단계와 아웃바운드 단계의 조회를 따로 확인
domainStrategy는 전역 DNS 누수 차단 스위치가 아닙니다. 같은 키라도 서로 다른 객체에 있으면 제어하는 단계가 다릅니다. 문제를 찾을 때는 JSON의 계층 구조까지 확인하세요. 키 이름만 검색해 일괄 변경해서는 안 됩니다.
| 필드 위치 또는 값 | 동작 | 확인할 사항 |
|---|---|---|
routing.domainStrategy: AsIs | 라우팅 단계에서 IP 규칙을 위해 도메인을 먼저 조회하지 않음 | 도메인 규칙과 기본 아웃바운드가 모두 설정되어 있는지 |
routing.domainStrategy: IPIfNonMatch | 도메인 규칙이 매칭되지 않으면 조회를 시도한 뒤 IP 규칙 매칭 | 조회 요청이 어떤 DNS 업스트림을 사용하는지 |
routing.domainStrategy: IPOnDemand | IP 확인이 필요한 규칙을 만나면 조회 실행 | IP 규칙의 위치와 추가 DNS 조회량 |
freedom.settings.domainStrategy | 직접 연결 아웃바운드에서 대상 도메인을 처리하는 방식 제어 | 시스템 DNS와 내장 DNS 중 무엇을 쓸지는 값과 코어에 따라 달라짐 |
AsIs는 라우팅 단계에만 적용되며 대상 연결에서 DNS 조회가 전혀 일어나지 않는다는 뜻은 아닙니다. 요청이 직접 연결 아웃바운드로 전달되면 대상 주소가 필요하고, 도메인 형태로 프록시 서버에 전달되면 보통 원격 측에서 처리합니다. 한국 내 웹사이트를 직접 연결하려면 해당 사이트의 DNS 조회 정책도 먼저 정해야 합니다. 로컬 DNS 요청을 전부 문제로 간주하지 마세요.
작업 순서: DNS 아웃바운드를 고정한 뒤 매칭 전략 조정
먼저 dns-query 태그가 붙은 트래픽이 프록시 아웃바운드에 실제로 매칭되는지 확인한 다음, 분기 방식에 맞춰 AsIs 또는 다른 전략을 선택하세요. IPIfNonMatch만 AsIs로 바꿔도 앱이 코어에 들어오기 전에 로컬에서 완료한 DNS 조회는 해결되지 않습니다.
FakeDNS: 주소 매핑만으로 트래픽을 가로챌 수는 없습니다
FakeDNS는 실제 대상 IP가 아니라 예약된 주소 풀의 매핑 주소를 반환합니다. 코어가 도메인과 매핑 주소의 관계를 저장하며, 이후 연결도 같은 처리 경로를 거쳐야 매핑된 주소에서 도메인을 복원할 수 있습니다. DNS 가로채기와 연결 복구 기능을 갖춘 환경에 적합하며, 필드 하나만 복사해 활성화하는 방식으로는 사용할 수 없습니다.
{
"fakedns": [
{
"ipPool": "198.18.0.0/15",
"poolSize": 65535
}
],
"dns": {
"servers": ["fakedns"]
}
}아래는 FakeDNS를 지원하는 V2Ray/Xray 코어의 개념 예시이며 DNS 인바운드, 전달, 시스템 라우팅은 포함하지 않습니다. 매핑을 복원해야 하는 기존 인바운드에는 코어 지원 여부에 맞춰 다음 스니핑 설정도 병합해야 합니다. 실제 트래픽이 들어오지 않는 빈 인바운드를 새로 만들지 마세요.
{
"sniffing": {
"enabled": true,
"destOverride": ["fakedns"]
}
}- DNS 요청이 코어에 들어와야 합니다: JSON에
"servers": ["fakedns"]만 설정해도 Windows 네트워크 어댑터가 자동으로 해당 DNS에 질의하지 않습니다. - 매핑된 연결을 코어로 되돌려야 합니다:
198.18.0.0/15는 공인 웹사이트 주소가 아닙니다. 시스템이 이 주소를 물리 게이트웨이로 직접 보내면 웹페이지가 시간 초과되는 경우가 많습니다. - 라우팅 경로를 일치시켜야 합니다: 해당 주소 풀이 기존 네트워크 주소 계획과 충돌하지 않는지, 현재 DNS 가로채기 경로에서 처리되는지 확인하세요. 직접 연결 우회 목록에 추가하지 마세요.
- 전환 후 캐시 비우기: FakeDNS를 끄거나 재시작해 매핑이 사라지면 캐시에 남은 매핑 주소가 더 이상 유효하지 않을 수 있습니다. 다시 조회해 새 연결을 만들어야 합니다.
v2rayN은 여러 코어를 관리할 수 있으며 TUN 모드의 DNS 가로채기는 별도의 설정 구조를 사용할 수도 있습니다. 먼저 실제로 실행 중인 코어를 확인한 뒤 위의 V2Ray/Xray 설정을 사용할지 판단하세요. 다른 코어의 TUN DNS 설정 화면에는 이 JSON을 그대로 붙여 넣을 수 없습니다.
v2rayN 설정 위치와 자주 발생하는 오류
데스크톱에서는 먼저 「설정」→「매개변수 설정」에서 로컬 수신 포트를 확인한 다음, 「설정」→「DNS 설정」에서 현재 코어에 해당하는 DNS 항목을 확인하세요. 버전에 따라 DNS 메뉴가 매개변수 설정 안에 있을 수 있으며, 필드도 코어마다 다릅니다. 저장한 뒤 서비스를 다시 시작하고 실행 로그에서 실제 코어와 설정 로드 결과를 확인하세요. 클라이언트나 구독을 업데이트하거나 구성을 전환한 뒤에도 생성된 설정에 변경 사항이 유지되는지 다시 확인해야 합니다.
시스템 프록시를 점검할 때는 트레이 메뉴의 「시스템 프록시」를 확인하고, DNS 가로채기를 점검할 때는 메인 화면의 「TUN 모드」와 관련 설정을 확인하세요. 두 기능은 같은 스위치가 아닙니다. TUN은 관리자 권한이 필요하거나 기존 가상 네트워크 어댑터와 충돌할 수 있으므로 변경 전에 현재 상태를 기록하세요. 비교 테스트를 위해 가로채기 프로그램 여러 개를 동시에 실행하지 마세요.
오류: failed to find an available destination
원인: 노드 도메인 조회에 실패했거나 연결 가능한 대상 주소가 없을 수 있습니다. 이 로그 한 줄만으로 DNS 누수라고 단정할 수는 없습니다. 해결: 앞뒤 로그를 확인하고 노드 주소의 DNS 조회를 먼저 테스트한 다음 DNS 아웃바운드 의존성과 노드 연결 상태를 점검하세요.
오류: lookup example.com: no such host
원인: 현재 DNS 경로에서 해당 도메인의 유효한 레코드를 가져오지 못했습니다. 로그에 표시된 도메인이 실제 요청 도메인과 다를 수도 있습니다. 해결: 도메인 철자, 업스트림 응답, DNS 분기 제한을 확인하세요. 조회가 정상적으로 되는 다른 도메인과 비교하고, 먼저 수신 포트를 변경하지 마세요.
오류: context deadline exceeded
원인: 대기 시간이 초과된 상황으로, DNS 조회 중이거나 이후 연결 단계에서 발생했을 수 있습니다. 해결: 로그의 대상 주소를 기준으로 시간 초과가 발생한 단계를 구분하세요. 대상이 DoH 서비스라면 예상한 아웃바운드에 매칭되는지와 프록시가 정상인지 확인하세요.
Android에서도 코어를 구분해야 합니다. v2rayNG는 Xray를, v2flyNG는 V2Fly를 사용합니다. 시스템 VPN의 트래픽 가로채기, 앱 우회 목록, Android의 「비공개 DNS」가 DNS 경로를 바꿀 수 있으므로 데스크톱 시스템 프록시의 점검 결과를 그대로 적용할 수 없습니다. 같은 노드라도 두 기기에서 결과가 다르면 노드 문제로 단정하지 말고 먼저 요청 경로와 DNS 서버를 비교하세요.
- 수정 완료 기준: 테스트를 반복했을 때 대상 앱에 예상한 DNS 서버만 표시되고, 로그에서도 DNS 트래픽이 예상한 아웃바운드를 선택해야 합니다.
- 분기 설정 유지 기준: 직접 연결 도메인과 프록시 도메인을 각각 테스트해 DNS 조회 결과와 해당 웹사이트의 연결 여부를 모두 확인합니다.
- 시스템 전체 확인: 더 많은 앱에 적용하려면 UDP/TCP 53, 브라우저 암호화 DNS, IPv6 경로도 별도로 확인해야 합니다. 웹페이지 한 곳의 테스트만으로 모든 프로세스를 확인할 수는 없습니다.
- 되돌리기: 변경 전 설정을 저장하고 한 번에 한 계층만 수정하세요. 문제가 생기면 해당 항목을 복원하고 서비스를 재시작한 뒤 캐시를 비우세요. 잘못된 설정을 여러 개 겹쳐 적용하지 마세요.