VPN이 제대로 작동하는지 확인할 때는 클라이언트의 연결 아이콘만 봐서는 안 됩니다. IP, DNS, 앱별 경로를 점검하면 트래픽이 어디로 나가는지, 도메인을 어떤 서버가 조회하는지, 대상 앱이 예상한 경로를 사용하는지 각각 확인할 수 있습니다. 연결 전후 결과를 비교하고 분할 라우팅 규칙까지 살펴봐야 설정이 사용 목적에 맞는지 판단할 수 있습니다.
먼저 검증 범위를 정하세요: 연결됨이 모든 트래픽의 경유를 뜻하지는 않습니다
‘연결됨’은 보통 터널이나 프록시 연결이 설정되었다는 뜻이지, 기기의 모든 요청이 이를 통과한다는 의미는 아닙니다. 브라우저 확장 프로그램은 브라우저에만 적용될 수 있고, 시스템 프록시는 앱이 이를 따르도록 설정되어 있어야 합니다. TUN이나 시스템 VPN 인터페이스는 더 많은 트래픽을 처리할 수 있지만, 라우팅 설정과 앱 제외 항목, 프로토콜 지원 범위에 따라 달라질 수 있습니다.
프록시 클라이언트에서 ‘전역’이 무엇을 뜻하는지도 맥락에 따라 다릅니다. 프록시 엔진으로 들어온 요청을 모두 선택한 노드로 보내는 설정일 수 있으며, 모든 앱의 트래픽을 자동으로 프록시로 보내는 것은 아닙니다. 규칙 모드는 도메인, 대상 주소, 프로세스 등의 조건에 따라 프록시, 직접 연결 또는 차단을 선택합니다. 따라서 중국 본토 웹사이트에서 현지 네트워크의 IP가 표시되어도 반드시 오류는 아닙니다.
공인 IP 확인: 연결 전후 결과 비교
공인 IP는 대상 웹사이트에 표시되는 요청의 출발지입니다. VPN97의 IP 확인 페이지를 열고, 먼저 프록시 연결을 끊은 상태에서 공인 IP 주소와 주소 유형, 통신사 정보를 기록하세요. 연결한 뒤 다시 확인합니다. 테스트 중에는 같은 네트워크를 유지하세요. Wi-Fi와 다른 네트워크를 번갈아 사용하면 접속 네트워크 자체의 변화가 IP에 영향을 줄 수 있습니다.
- 다른 프록시 확장 프로그램이나 중복 실행 중인 클라이언트를 종료하고, 연결하지 않은 상태의 조회 결과를 기록합니다.
- 확인할 노드에 연결하고, 클라이언트 모드가 테스트 목적에 맞는지 확인한 다음 조회 페이지를 새로고침합니다.
- 클라이언트 연결 기록에서 조회 요청이 프록시 규칙과 예상한 아웃바운드에 매칭되었는지 확인합니다.
- 연결을 끊은 뒤 다시 조회해 결과가 원래 접속 네트워크로 돌아오는지 확인합니다. 필요하면 페이지를 닫았다가 다시 여세요.
IP가 바뀌었다면 이번 조회 요청이 다른 네트워크 경로를 사용했다는 뜻입니다. 다른 소프트웨어의 트래픽도 프록시를 거쳤다는 증거는 아닙니다. IP가 바뀌지 않았다고 바로 노드 장애로 판단하지 마세요. 조회 사이트가 직접 연결 규칙에 해당하거나 브라우저가 시스템 프록시를 우회했을 수 있고, 다른 주소 유형을 사용 중일 수도 있습니다.
IP 위치 데이터베이스는 업데이트 시점에 따라 결과가 다를 수 있습니다. 조회 페이지에 표시된 도시가 노드 이름과 다르다는 사실만으로 장애라고 판단할 수는 없습니다. 공인 IP, 네트워크 사업자, 클라이언트의 아웃바운드 기록, 대상 서비스가 예상대로 작동하는지를 함께 확인하는 편이 유용합니다.
| 확인 결과 | 알 수 있는 점 | 추가로 확인할 항목 |
|---|---|---|
| 조회 페이지의 IP가 변경됨 | 해당 페이지 요청이 다른 출구를 사용함 | 대상 앱과 DNS도 규칙에 맞는지 |
| 조회 페이지의 IP가 그대로임 | 이번 요청에서 예상한 출구가 확인되지 않음 | 직접 연결 규칙, 프록시 진입 경로, 캐시, 주소 유형 |
| DNS에 다른 지역이 표시됨 | DNS 조회 서비스와 웹 트래픽의 출구가 같은 위치일 필요는 없음 | 조회 서비스가 예상한 설정을 사용하는지 |
| 브라우저는 정상인데 다른 앱은 이상함 | 앱마다 프록시 경로가 다를 수 있음 | 앱별 프록시 설정, 앱 제외 항목, 라우팅 |
DNS 확인: 조회 위치와 누출 구분하기
DNS는 도메인 이름을 연결 가능한 주소로 변환합니다. 웹 요청이 프록시를 통과해도 도메인 조회까지 반드시 프록시를 통과하는 것은 아닙니다. DNS 조회를 터널 안에서 처리하도록 설정했는데 실제로는 현지 네트워크의 DNS 서버에 요청이 전달된다면, 의도하지 않은 외부 조회가 있는지 확인해야 합니다. 반대로 현지 도메인은 현지 DNS로 조회하도록 규칙을 설정했다면, 그 결과를 곧바로 누출로 볼 수는 없습니다.
새 도메인 조회를 발생시킬 수 있는 DNS 테스트 페이지를 사용해 연결 전후의 DNS 서버 목록을 비교하세요. DNS 서버의 국가가 노드와 일치하는지보다 서버 제공자가 클라이언트 설정에 맞는지를 확인하는 것이 중요합니다. 공용 DNS의 분산 배포, 상위 DNS 서버로의 전달, 테스트 사이트의 식별 방식에 따라 결과가 달라질 수 있습니다.
브라우저 보안 DNS와 시스템 DNS를 따로 확인하세요
브라우저의 보안 DNS는 DoH를 통해 시스템 DNS 설정과 별도로 조회 요청을 보낼 수 있습니다. 해당 요청은 프록시를 통과할 수도 있고 직접 연결될 수도 있습니다. 점검할 때는 먼저 브라우저 설정을 확인하고 클라이언트가 해당 요청을 처리하는지 살펴보세요. ‘암호화된 DNS 사용’이 곧 ‘DNS가 터널 안에서 처리됨’을 뜻하지는 않습니다.
아래 명령어는 시스템 DNS 도구가 반환하는 서버와 결과를 확인하는 데 도움이 되지만, 브라우저의 DNS 조회 경로를 단독으로 증명하지는 못합니다. 운영체제에 따라 로컬 전달 주소가 표시될 수도 있고, 도구가 지정된 DNS 서버에 직접 요청할 수도 있습니다.
nslookup example.com설정을 방금 변경했다면 기존 DNS 캐시 때문에 새로운 요청이 발생하지 않을 수 있습니다. 먼저 테스트 페이지의 새 조회 기능을 사용한 다음 대상 앱을 재시작해 다시 확인하세요. 캐시 삭제는 이전 결과의 간섭을 줄이는 방법일 뿐, DNS 조회 경로를 확인하는 일을 대신하지는 않습니다.
앱별 확인: 브라우저 결과가 모든 소프트웨어를 대변하지는 않습니다
대상 소프트웨어를 완전히 종료한 뒤 프록시에 연결하고 다시 실행하세요. 기존 연결이 이전 경로를 계속 사용할 수 있고 백그라운드 프로세스가 연결을 유지할 수도 있습니다. 그런 다음 클라이언트 연결 패널에서 대상 도메인, 매칭된 규칙, 아웃바운드 노드, 트래픽 변화를 확인하세요. 총 트래픽이 늘었다는 사실만으로 해당 소프트웨어가 프록시를 사용한다고 단정할 수는 없습니다.
- ✅ 브라우저: 확장 프로그램 프록시와 시스템 프록시가 중복 설정되어 있는지 확인하고 조회 요청의 아웃바운드 기록을 비교합니다.
- ✅ 데스크톱 앱: 앱에 별도 프록시 설정이 있는지 확인한 다음 클라이언트에서 제외되어 있는지 살펴봅니다.
- ✅ 명령줄 도구: 프록시 환경 변수와 도구 자체 설정을 확인합니다. 터미널의 결과를 브라우저에도 그대로 적용해 판단하지 마세요.
- ✅ 게임, 회의, 실시간 통신: 로그인, 콘텐츠 로딩, 미디어 연결을 각각 확인하고 UDP 등 관련 트래픽이 현재 모드에서 지원되는지 살펴봅니다.
- ✅ 모바일 앱: 시스템 VPN 상태, 앱별 분할 라우팅, 백그라운드 제한을 확인하고 네트워크를 전환한 뒤 다시 검증합니다.
Windows와 macOS에서 시스템 프록시와 가상 네트워크 인터페이스는 서로 다른 트래픽 처리 방식입니다. Linux에서는 터미널, 데스크톱 환경, 앱이 각자 다른 프록시 설정을 사용할 수 있습니다. iOS와 Android의 VPN 인터페이스도 앱별 분할 라우팅과 클라이언트 기능을 확인하는 일을 대신할 수 없습니다. 차이가 있다면 현재 운영체제와 클라이언트에서 실제로 제공하는 설정을 기준으로 점검하세요.
대상 웹사이트가 열린다는 사실은 현재 접속이 가능하다는 뜻일 뿐입니다. 원래 직접 연결할 수 있는 사이트일 수도 있습니다. 반대로 웹사이트에서 접속을 거부하더라도 계정 지역, 사이트의 위험 관리 정책, 서비스 제공 범위, 앱 캐시가 원인일 수 있으므로 프록시 전체가 작동하지 않는다고 단정할 수는 없습니다.
자주 발생하는 차이: IPv6, WebRTC, 분할 라우팅 규칙
주소 유형마다 다른 경로를 사용할 수 있습니다
기기는 IPv4와 IPv6 연결을 동시에 사용할 수 있습니다. 프록시가 한쪽만 처리한다면 다른 경로는 접속 네트워크의 출구를 사용할 수 있습니다. 주소 유형별 확인 기능이 있는 도구로 점검하고, 클라이언트의 IPv6 지원 여부와 라우팅 설정을 비교하세요. 특정 유형의 주소가 감지되지 않는 것은 현재 네트워크가 해당 연결을 제공하지 않기 때문일 수도 있습니다. 이를 근거로 모든 환경에서 외부 연결이 발생하지 않는다고 판단할 수는 없습니다.
WebRTC 결과는 주소 유형을 구분해 확인하세요
브라우저의 실시간 통신은 후보 주소를 통해 네트워크 경로를 확인할 수 있습니다. 테스트 결과에 나온 사설 네트워크 주소나 숨김 처리된 로컬 호스트 이름은 접속 네트워크의 공인 IP와 다릅니다. 예상하지 못한 공인 IP가 표시되면 주소가 더 있다는 이유만으로 전체 트래픽이 누출되었다고 단정하지 말고 UDP 라우팅과 브라우저 설정을 추가로 확인하세요.
규칙, 구독, 연결 상태는 서로 다른 단계입니다
구독을 가져오는 것은 서비스가 제공한 노드나 설정을 클라이언트에 전달하는 과정일 뿐, 시스템 프록시가 활성화되었다는 뜻은 아닙니다. 구독을 업데이트한 뒤에는 선택된 노드, 모드, 규칙이 예상한 설정인지 확인하세요. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC은 프로토콜 방식을 나타내는 이름이며, 프로토콜 이름만으로 앱 트래픽이 프록시를 거치는지 판단할 수는 없습니다.
증거를 바탕으로 점검하고 설정을 반복해서 바꾸지 마세요
기존 설정을 보관하고 관련 옵션은 한 번에 하나씩만 바꾸세요. 예를 들어 먼저 앱이 프록시를 사용하지 않는 문제를 해결한 다음 DNS를 확인합니다. 노드, 규칙, DNS 서버를 한꺼번에 바꾸면 문제가 해결되더라도 원인을 파악하기 어렵습니다. 테스트가 끝나면 일상적인 용도에 맞는 설정으로 되돌리세요.
지원 담당자에게 문의할 때는 운영체제, 클라이언트 버전, 연결 모드, 문제가 발생한 앱과 도메인을 알려주세요. 민감 정보를 가린 매칭 규칙과 출구 변경 기록도 함께 전달하면 도움이 됩니다. ‘브라우저의 출구는 바뀌었지만 대상 앱은 직접 연결됩니다’처럼 구체적으로 설명하면 ‘VPN이 작동하지 않습니다’라고만 말하는 것보다 원인을 찾기 쉽습니다.
판단 기준: 공인 IP가 예상과 일치하고, DNS 경로가 설정에 맞으며, 대상 앱이 올바른 아웃바운드에 연결된다는 증거가 서로 일치해야 테스트한 사용 환경에서 VPN이 작동한다고 판단할 수 있습니다. 한 번의 테스트로 지속적인 설정 상태를 보장할 수는 없습니다. 네트워크를 바꾸거나 클라이언트를 업데이트하거나 규칙을 수정한 뒤에는 다시 확인하세요.
VPN97은 설정 진입점을 확인할 수 있도록 클라이언트 사용 가이드와 노드 정보를 제공합니다. 로그 미보관 정책은 서비스의 개인정보 보호 방침이며, 기기에서 의도치 않은 직접 연결이 발생하지 않는다는 보장은 아닙니다. 로컬 라우팅, DNS, 앱 설정은 별도로 확인해야 합니다.