구독을 가져와 노드에는 연결되지만 일부 도메인이 열리지 않거나 한국 웹사이트 접속이 느린 macOS 사용자에게 적합합니다. 시스템 DNS와 커널 DNS의 차이를 살펴본 뒤 직접 연결 DNS, 원격 DNS, 도메인 규칙을 설정하고 터미널과 로그로 실제 경로를 확인합니다. 이 글은 Xray 커널을 사용하는 v2rayN을 기준으로 설명합니다. 커널을 바꾸면 DNS 항목을 다시 확인해야 하며 설정을 그대로 복사해서는 안 됩니다.
1. DNS 분리 전에 세 가지 경로부터 이해하기
DNS는 도메인 이름을 IP 주소로 변환합니다. v2rayN은 클라이언트이며, 실제 연결과 일부 DNS 조회는 선택한 커널이 처리합니다. 브라우저, macOS 시스템 리졸버, 커널 내장 DNS가 한 번의 접속에 모두 관여할 수 있습니다. 따라서 한 곳의 설정만 바꿔도 모든 요청에 새 설정이 적용되는 것은 아닙니다.
위 내용은 앱이 도메인을 프록시에 전달하는 과정을 간략히 나타낸 것입니다. 앱이 먼저 로컬에서 도메인을 조회하면 프록시에는 IP만 전달될 수 있습니다. 반대로 프록시 서버가 도메인을 조회하면 로컬 커널에서 대상 도메인의 DNS 요청이 발생하지 않을 수도 있습니다. 따라서 로그에 특정 도메인의 조회 기록이 없다고 해서 설정이 적용되지 않았다고 단정할 수는 없습니다.
- 리졸버 선택: 중국 본토 도메인은 직접 연결 리졸버로, 프록시가 필요한 도메인은 원격 리졸버로 보냅니다.
- DNS 전송 경로: DNS 조회가 직접 연결을 통해 나가는지 프록시를 통해 나가는지 별도로 확인해야 합니다.
- 서비스 연결 경로: 주소를 얻은 뒤 웹사이트 연결은 라우팅 규칙에 따라 경로가 결정됩니다.
2. 직접 연결 DNS와 원격 DNS 설정하기
먼저 v2rayN의 ‘설정’ → ‘DNS 설정’을 열고, ‘설정’ → ‘매개변수 설정’에서 현재 커널을 확인합니다. 버전과 커널에 따라 항목이 다를 수 있습니다. 인터페이스에서 커널별 DNS를 설정한다면 현재 사용 중인 항목을 수정하세요. 기존 설정을 복사해 보관한 다음 리졸버를 변경하고, 라우팅·TUN·IPv6 설정은 동시에 바꾸지 않는 것이 좋습니다.
| 용도 | 처음 설정할 때 참고할 예시 | 확인해야 할 조건 |
|---|---|---|
| 직접 연결 DNS | 223.5.5.5 | 현재 네트워크에서 접속 가능해야 하며 일반 DNS 조회는 보통 암호화되지 않음 |
| 직접 연결 DoH | https://dns.alidns.com/dns-query | 커널이 해당 형식을 지원하고 엔드포인트 도메인을 먼저 조회할 수 있어야 함 |
| 원격 DoH | https://dns.google/dns-query | 조회가 의도한 프록시 경로를 이용하고 TLS 검증과 시스템 시간이 정상이어야 함 |
아래 주소는 공개 DNS 서비스의 예시이며, 모든 네트워크에서 가장 빠르다는 의미는 아닙니다. 처음에는 종류별로 접속 가능 여부가 확실한 리졸버 하나만 설정하면 충분합니다. 주소를 많이 입력하면 대체 조회와 동시 요청이 복잡해져 로그를 분석하기 어려워집니다. 사내망, 학교 네트워크 또는 내부 도메인 조회가 필요한 환경에서는 해당 내부 DNS 경로를 유지하세요.
포트 번호는 전송 방식을 구분하기 위한 값이며, 로컬에서 해당 포트를 수신 중이라는 뜻은 아닙니다. v2rayN의 프록시 수신 포트와 DNS 수신 포트는 별도 설정입니다. HTTP 또는 SOCKS 프록시 포트를 macOS의 DNS 서버 목록에 입력하지 마세요.
3. geosite 규칙은 DNS 조회와 연결 경로를 함께 설정해야 합니다
geosite는 도메인 분류 데이터이고 geoip는 IP 분류 데이터입니다. 둘 다 리졸버가 아니며 DNS 서비스를 제공하지 않습니다. 예를 들어 Xray의 라우팅에서 geosite:cn을 사용하면 중국 본토 도메인을 매칭할 수 있습니다. 내장 DNS 서버 항목에서도 domains로 우선 처리할 도메인 집합을 지정할 수 있습니다. 두 설정은 서로 연관되어 있지만 대체할 수는 없습니다.
- 먼저 규칙 데이터를 확인하세요. 현재 커널이 사용 중인 도메인 및 IP 데이터를 불러올 수 있는지 확인하고, 로그에 파일 누락이나 분류 항목 없음 오류가 없는지 살펴봅니다. 분류 데이터는 바뀔 수 있으므로 항상 정확한 지리적 경계로 간주해서는 안 됩니다.
- 직접 연결 DNS 범위를 설정하세요.
geosite:cn에 해당하는 도메인을 우선 직접 연결 DNS로 보내세요. 내부 도메인은 별도 규칙으로 처리해 공개 리졸버로 전송되지 않도록 합니다. - 원격 DNS 범위를 설정하세요. 프록시가 필요한 도메인은 원격 DNS로 보내세요.
geosite:geolocation-!cn을 사용하는 경우 데이터에 해당 분류가 있는지 먼저 확인해야 합니다. 이는 분류 집합일 뿐, 중국 본토 이외의 모든 도메인을 실시간으로 판별하는 기능은 아닙니다. - 서비스 라우팅을 확인하세요. 중국 본토 도메인은 직접 연결하고 프록시가 필요한 도메인은 프록시로 연결합니다. Xray 라우팅 규칙은 순서대로 확인되므로, 구체적인 도메인 규칙이 먼저 적용될 수 있는 포괄적인 규칙보다 앞에 오도록 하세요.
- 대체 조회 정책을 확인하세요. 도메인이 규칙에 일치하지 않거나 응답이 비어 있거나 주소가 예상과 다르면 조회가 다른 서버로 전달될 수 있습니다. 특정 도메인에서 직접 연결 DNS를 사용하지 않으려면 대체 조회 범위도 함께 검토해야 합니다.
Xray의 routing.domainStrategy는 라우팅 단계에서 IP 규칙을 매칭할 때 DNS 조회 결과를 사용할지 제어합니다. AsIs는 IP 규칙을 위해 도메인을 따로 조회하지 않습니다. IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 조회를 시도한 뒤 IP 규칙과 매칭합니다. 이는 DNS 모듈의 queryStrategy와는 다른 설정이며, 후자는 주로 조회할 주소 유형 등의 동작을 제어합니다.
요약: 도메인 규칙을 먼저 확인한 뒤 IP 규칙을 점검하세요
웹사이트가 잘못된 출구를 통해 연결된다면, 먼저 예상한 도메인 분류와 규칙 순서가 적용되는지 확인하세요. 서비스에서 IP 기준 판별이 꼭 필요할 때만 라우팅 단계의 조회 전략을 조정하고, 라우팅 오류를 DNS 변경으로 덮으려 하지 마세요.
4. DoH로 DNS 오염을 줄이고 초기 조회 설정하기
DoH는 DNS 조회를 HTTPS 연결로 전송해 리졸버까지의 통신을 보호하고, 전송 중 데이터가 노출되거나 변조될 위험을 줄여 줍니다. 하지만 리졸버가 항상 올바른 응답을 제공한다고 보장하지 않으며 연결 대상 IP를 숨기지도 않습니다. 브라우저에서 별도의 보안 DNS를 사용하면 커널에 설정한 리졸버를 우회할 수도 있습니다.
- 초기 조회:
dns.google같은 도메인으로 된 엔드포인트에 연결하려면 먼저 해당 엔드포인트의 주소를 알아야 합니다. 엔드포인트를 조회하는 데 아직 연결되지 않은 DoH가 필요하다면 순환 의존성이 생깁니다. - 노드 도메인: 프록시 노드 주소가 도메인이라면 프록시에 연결하기 전에 먼저 조회해야 합니다. 해당 노드를 통해야만 접속할 수 있는 서비스에 노드 도메인의 유일한 조회 경로를 의존시키지 마세요.
- 인증서 검증: macOS에서 ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’을 열고 자동 시간 설정을 확인하세요. 인증서 오류가 발생하면 시간을 비롯해 엔드포인트 이름과 네트워크 차단 여부를 확인하세요. 검증을 끄는 방식으로 우회하지 마세요.
- 출구 경로 설정: 원격 리졸버에 프록시로 접속해야 한다면 해당 커널이 지원하는 DNS 전송 및 라우팅 설정에서 경로를 명확히 지정하고 로그로 확인해야 합니다. 항목 이름만 보고 판단해서는 안 됩니다.
초기 조회를 피하려고 DoH 주소의 호스트 이름을 임의로 IP로 바꾸는 것은 권장하지 않습니다. HTTPS에는 인증서 이름과 서버의 가상 호스트도 관련됩니다. DNS 서비스가 해당 IP 엔드포인트를 명시적으로 지원하는 경우에만 안내된 주소 형식을 사용하세요.
5. FakeDNS를 사용해야 하는 경우
FakeDNS는 별도의 공개 DNS 서비스가 아닙니다. 도메인에 가상 IP를 할당하고 트래픽이 커널로 다시 들어올 때 해당 IP를 원래 도메인으로 연결합니다. 따라서 앱이 이후 요청에서 IP만 전달하더라도 커널이 도메인 기준으로 트래픽을 분리할 수 있습니다. 투명 프록시와 함께 사용하는 경우가 많지만 TUN을 켰다고 반드시 활성화해야 하는 것은 아닙니다.
| 비교 항목 | DoH | FakeDNS |
|---|---|---|
| 주요 목적 | 실제 DNS 조회를 암호화해 전송 | 도메인과 가상 IP의 연결 관계 유지 |
| 반환 결과 | 리졸버가 제공하는 실제 주소 레코드 | 로컬 매핑 풀에서 생성한 주소 |
| 필수 조건 | 엔드포인트 접속 가능, 인증서 유효, 올바른 출구 경로 | 조회와 후속 연결이 모두 연동된 방식으로 처리되어야 함 |
| 흔한 오류 | 초기 조회 실패, 연결 시간 초과 | 가상 IP가 직접 연결로 빠져나감, 캐시 매핑 불일치 |
시스템 프록시만 사용하고 브라우저가 이미 도메인을 프록시에 전달하는 환경이라면 일반적으로 FakeDNS를 끈 상태로 두세요. TUN 환경에서 앱이 먼저 도메인을 조회해 도메인 규칙이 적용되지 않는다면, 현재 커널과 클라이언트가 DNS 가로채기 및 매핑을 완전하게 지원하는지 확인하세요. 커널을 바꿀 때는 구현 방식이 같다고 가정하지 말고 다시 검증해야 합니다.
요약: 트래픽 가로채기 경로를 확인한 뒤 FakeDNS를 켜세요
먼저 DNS 조회가 예상한 처리 경로로 들어가는지 확인한 다음, 가상 주소에 연결되는 트래픽이 클라이언트를 우회하지 않는지 확인하세요. 활성화한 뒤 일부 앱만 네트워크에 연결되지 않는다면 노드를 바로 바꾸기보다 캐시, 우회 규칙, 주소 매핑부터 점검하세요.
6. macOS에서 DNS 조회와 프록시를 순서대로 확인하기
한 번에 설정 한 가지씩만 변경하세요. 저장한 뒤 커널을 다시 시작하고 시작 로그에 오류가 있는지 확인한 다음 아래 테스트를 진행합니다. 명령어의 도메인은 예시이므로 문제가 발생한 웹사이트를 테스트할 때는 해당 호스트 이름으로 바꾸세요. 구독 주소, 노드 인증 정보, 전체 연결 설정을 공개 로그에 붙여 넣지 마세요.
- 시스템 DNS 확인:
scutil --dns를 실행해 현재 네트워크, VPN 또는 다른 네트워크 서비스에 어떤 리졸버가 설정되어 있는지 확인하세요. 시스템 DNS 설정을 표시하는 명령이며 Xray 내장 DNS의 전체 상태를 보여 주지는 않습니다. - 지정한 리졸버 테스트: 아래
dig명령을 실행해 현재 네트워크에서 해당 리졸버가 응답하는지 확인하세요. 이 테스트만으로 v2rayN의 DNS 분리가 검증되는 것은 아닙니다. - 프록시 연결 테스트: 먼저 ‘설정’ → ‘매개변수 설정’에서 로컬 수신 포트와 프로토콜을 확인한 다음 프록시 요청을 실행하세요. 예시는
10808포트에서 HTTP 또는 혼합 프록시를 제공한다고 가정합니다. SOCKS만 제공하는 경우 HTTP 명령을 그대로 사용하지 마세요. - 커널 로그 확인: 테스트한 시간대의 대상 도메인, 적용된 라우팅 규칙, 출구 선택, DNS 시간 초과를 함께 살펴보세요. 필요하면 로그 수준을 잠시 높이고 테스트가 끝나면 원래대로 되돌리세요.
# macOS 시스템 리졸버 확인
scutil --dns
# 지정한 리졸버에 직접 질의, 제한 시간 2초, 1회만 시도
dig @223.5.5.5 www.baidu.com A +time=2 +tries=1
# 10808에서 HTTP 또는 혼합 프록시를 제공하는 경우에만 사용
curl -I --proxy http://127.0.0.1:10808 \
--connect-timeout 10 --max-time 20 https://www.example.com/수신 포트에서 SOCKS5를 지원한다면 아래 두 명령의 결과도 비교할 수 있습니다. 첫 번째는 일반적으로 로컬에서 대상 도메인을 조회하고, 두 번째는 도메인 조회를 SOCKS 프록시에 맡깁니다. 두 번째는 성공하고 첫 번째는 실패한다면 로컬 조회 경로를 먼저 확인하세요. 다만 주소 유형 차이나 웹사이트의 연결 제한 여부도 로그와 함께 살펴봐야 합니다.
# 로컬에서 대상 도메인 조회
curl -I --proxy socks5://127.0.0.1:10808 \
--connect-timeout 10 --max-time 20 https://www.example.com/
# 대상 도메인 조회를 SOCKS 프록시에 맡김
curl -I --proxy socks5h://127.0.0.1:10808 \
--connect-timeout 10 --max-time 20 https://www.example.com/설정을 바꾼 뒤에도 이전 결과가 나오면 테스트 앱을 종료한 다음 다시 여세요. macOS 시스템 DNS 캐시를 지워야 하는 경우 터미널에서 아래 명령을 실행할 수 있습니다. 두 번째 명령에는 관리자 권한이 필요합니다. 이 명령으로 브라우저 자체 캐시, 커널 캐시, 상위 리졸버 캐시까지 삭제되지는 않습니다.
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder7. DNS 분리 관련 자주 묻는 질문
DoH로 바꾼 뒤 모든 웹사이트가 느려진 이유는 무엇인가요?
먼저 기존 리졸버로 되돌려 정상으로 돌아오는지 확인하세요. 그런 다음 DoH 엔드포인트의 초기 조회, 프록시 출구, 시간 초과 로그를 점검합니다. 중국 본토 도메인까지 원격 리졸버로 보내면 현재 직접 연결 경로에 적합하지 않은 주소를 받을 수 있습니다. DNS 주소만 바꾸기보다 중국 본토 도메인의 DNS 조회와 서비스 연결을 함께 분리하세요.
dig는 정상인데 브라우저에서 사이트가 열리지 않으면 무엇을 의미하나요?
dig @223.5.5.5의 성공은 지정한 리졸버에 보낸 이번 조회가 응답을 받았다는 뜻일 뿐입니다. 브라우저에서 별도의 보안 DNS를 사용하거나 시스템 프록시 또는 확장 프로그램과 충돌할 수 있습니다. 먼저 위의 프록시 지정 명령으로 다시 테스트한 다음 브라우저의 프록시와 보안 DNS 설정을 확인하세요.
중국 본토 웹사이트가 해외 IP로 조회되면 반드시 DNS 오염인가요?
반드시 그렇지는 않습니다. CDN의 연결 조정, 리졸버 위치, 서비스 배치가 결과에 영향을 줄 수 있습니다. 같은 도메인을 직접 연결 리졸버와 원격 리졸버에 각각 질의한 뒤 연결 성공 여부와 라우팅 경로가 예상과 일치하는지 비교하세요. 응답이 서로 다르다는 사실만으로 오염을 입증할 수는 없습니다. 특정 조회 결과를 hosts 파일에 계속 고정하는 것도 권장하지 않습니다.
A 레코드가 있는데 연결이 시간 초과되면 IPv6를 꺼야 하나요?
먼저 A와 AAAA 레코드를 각각 조회하고 curl -4와 curl -6의 결과를 비교하세요. 프록시를 통해 테스트하면 주소 유형은 프록시 측에서 결정될 수도 있으므로 결과만으로 로컬 IPv6 상태를 단정할 수 없습니다. 실패한 IPv6 경로를 확인한 뒤 해당 조회 또는 출구 정책만 조정하고 시스템 기능 전체를 한꺼번에 끄지 마세요.
Android에서도 이 DNS 설정을 그대로 사용할 수 있나요?
트래픽 분리 원칙은 참고할 수 있지만 설정을 그대로 복사해서는 안 됩니다. v2rayNG는 Xray 커널을, v2flyNG는 v2fly 커널을 사용합니다. VPN 트래픽 가로채기, DNS 진입 경로, 지원 설정 항목을 각 클라이언트에서 따로 확인해야 합니다. 설정을 옮길 때는 도메인 하나와 리졸버 하나로 먼저 테스트한 뒤 분류 규칙과 대체 조회 정책을 추가하세요.
최종 점검에서는 세 가지를 확인하세요. 중국 본토 도메인이 예상한 직접 연결 DNS 경로를 사용하는지, 프록시가 필요한 도메인이 의도치 않게 직접 연결 DNS로 빠지지 않는지, 서비스 연결이 올바른 출구를 통과하는지입니다. 정상 작동하는 설정을 하나 보관한 뒤 DoH, IPv6, FakeDNS를 하나씩 추가하면 문제가 생겼을 때 되돌릴 기준이 명확해집니다.