VPN이 제대로 작동하는지 확인할 때는 ‘연결됨’ 표시만 보지 마세요. 먼저 출구 IP를 비교하고, DNS 조회 경로를 확인한 뒤, 실제 사용하는 앱에서 테스트해야 합니다. 연결 아이콘은 클라이언트가 어떤 연결 상태에 들어갔다는 뜻일 뿐, 브라우저와 데스크톱 앱, 백그라운드 트래픽이 모두 같은 출구를 이용한다는 의미는 아닙니다.
판단 기준은 대상 앱에서 새로 보낸 요청이 예상한 규칙에 따라 선택한 경로로 나가는지입니다. 규칙 모드에서는 일부 사이트가 직접 연결될 수 있으므로 국내 사이트에서 원래 출구가 표시되어도 반드시 오류는 아닙니다. 반대로 브라우저의 출구가 바뀌었다고 해서 모든 앱의 트래픽이 처리되고 있다고 단정할 수는 없습니다.
연결 상태, 출구 주소, 앱별 경로
프록시 클라이언트는 시스템 프록시, 가상 네트워크 어댑터 또는 앱별 규칙으로 연결을 처리할 수 있습니다. 시스템 프록시는 보통 앱이 프록시 설정을 따를 때만 작동합니다. 가상 네트워크 어댑터는 더 많은 트래픽을 처리할 수 있지만 라우팅, 제외 목록, 프로토콜 지원의 영향을 받습니다. 먼저 현재 모드를 확인한 뒤 검사 결과를 해석해야 정상적인 분할 연결을 오류로 오해하지 않습니다.
| 점검 항목 | 확인할 수 있는 내용 | 이것만으로는 확인할 수 없는 내용 |
|---|---|---|
| 클라이언트에 연결됨으로 표시됨 | 연결 기능이 시작됨. 구체적인 의미는 클라이언트 구현에 따라 다름 | 대상 앱이 해당 경로를 사용하는지 여부 |
| 출구 IP 변경 | 이번 조회 요청의 공인 출구 주소가 변경됨 | 다른 앱과 DNS도 같은 경로를 사용하는지 여부 |
| DNS 테스트 | 테스트 도메인의 조회를 처리한 재귀 DNS 리졸버 | 모든 도메인 조회가 같은 방식으로 처리되는지 여부 |
| 앱 요청 및 규칙 기록 | 해당 연결에 적용된 규칙과 실제 아웃바운드 경로 | 테스트하지 않은 앱의 이후 동작 |
출구 IP: 먼저 기준값을 기록하고 새 요청과 비교하기
먼저 연결을 끊고 IP 확인 페이지를 열어 현재 공인 주소와 네트워크 소유 정보를 기록합니다. 같은 네트워크 환경을 유지한 채 대상 경로에 연결한 후 다시 조회하세요. 중간에 무선 네트워크를 다른 네트워크로 바꾸면 원래 출구 자체가 달라질 수 있으므로, 이 비교만으로 경로가 작동한다고 입증할 수는 없습니다.
- 연결을 끊은 상태에서 현재 출구를 조회하고, 비교할 수 있도록 결과를 기록해 두세요. 전체 주소를 공개할 필요는 없습니다.
- 대상 경로에 연결한 뒤, 노드를 선택하기만 한 것이 아니라 클라이언트가 예상한 노드와 작동 모드를 표시하는지 확인하세요.
- 페이지의 이전 결과를 그대로 보지 않도록 새로 조회하세요. 필요하면 기존 탭을 닫고 다시 여세요.
- 클라이언트의 연결 기록에서 조회 요청을 찾아 적용된 규칙과 아웃바운드 경로를 확인하세요.
- 조회 도메인에 직접 연결 규칙이 적용됐다면, 클라이언트에서 지원하는 임시 프록시 규칙으로 다시 테스트한 뒤 원래 설정으로 되돌리세요.
출구 주소 변경은 유용한 근거지만, 지역 표시는 정확한 위치 정보가 아닙니다. 데이터베이스마다 업데이트 주기와 소속 지역 판단이 다를 수 있으므로 표시된 도시가 일치하지 않아도 연결 실패를 뜻하지 않습니다. 지도 표식만 보지 말고 주소, 네트워크 소유 정보, 클라이언트의 아웃바운드 기록을 우선 확인하세요.
IPv4와 IPv6도 확인해야 합니다. 조회 페이지에 한쪽 주소만 표시되고 다른 주소 계열은 다른 경로로 나갈 수 있습니다. 두 주소를 각각 검사할 수 있는 도구를 사용하고 클라이언트의 IPv6 처리 설정도 확인하세요. 모든 기기에 장기적으로 적용할 해결책인 것처럼 IPv6를 끄지는 마세요.
DNS 점검: DNS 리졸버와 트래픽 출구는 다릅니다
DNS는 도메인 이름을 주소로 변환하고, 웹 연결은 조회 결과를 사용해 대상 서비스에 접속합니다. 서로 관련은 있지만 별개의 단계입니다. DNS 검사 페이지는 보통 특수한 도메인을 통해 재귀 DNS 리졸버를 확인하며, 각 데이터 패킷이 통과하는 경로를 직접 보여 주지는 않습니다. 따라서 리졸버의 위치와 출구 위치가 다르다는 사실만으로 누출이라고 단정할 수 없습니다.
여기서 DNS 누출은 프록시의 개인정보 보호 설정에 따라 처리되어야 할 조회가 의도치 않게 예상하지 못한 로컬 경로로 전송되는 경우를 말합니다. 문제가 있는지 판단하려면 클라이언트의 DNS 모드, 브라우저의 보안 DNS 설정, 리졸버 정보, 실제 적용된 규칙을 함께 확인해야 합니다. 분할 연결 정책에 따라 로컬 도메인을 로컬에서 조회하도록 설정했다면 이는 정책에 따른 동작이지, 곧바로 누출이라고 볼 수 없습니다.
브라우저의 암호화 DNS가 검사 결과에 영향을 주는 이유
브라우저에서 HTTPS 기반 DNS를 사용하면 시스템 설정을 따르지 않고 자체 DNS 리졸버를 사용할 수 있습니다. 암호화는 해당 전송 구간에서 조회 내용이 보호된다는 뜻일 뿐, 반드시 프록시를 통과한다는 의미는 아닙니다. 브라우저가 직접 보내는 조회 요청의 출구도 라우팅과 프록시 규칙에 따라 결정됩니다.
검사 결과가 예상과 다르면 먼저 브라우저의 보안 DNS 상태를 기록한 뒤, 클라이언트가 이런 조회를 처리하거나 조정하는 기능을 지원하는지 확인하세요. 비교를 위해 설정을 잠시 바꿀 수 있지만 테스트가 끝나면 적절한 설정으로 되돌려야 합니다. 브라우저 설정을 바꾸면서 노드까지 함께 변경하면 어떤 변화가 결과에 영향을 줬는지 파악하기 어렵습니다.
DNS 캐시 때문에 이전 결과가 계속 사용될 수도 있습니다. 설정을 바꾼 뒤에는 도메인을 다시 조회하고, 시스템이나 클라이언트 안내에 따라 캐시를 처리하세요. 페이지를 새로고침한 뒤에도 사이트가 열린다는 이유만으로 새 DNS 설정이 적용됐다고 단정하지 마세요. 페이지 리소스가 캐시에서 제공되거나 기존 연결이 재사용될 수 있습니다.
앱별 점검: 브라우저에서 통과해도 모든 앱이 통과하는 것은 아닙니다
브라우저는 시스템 프록시를 따르지만 특정 데스크톱 앱은 따르지 않는 것이 ‘웹은 되는데 앱은 안 되는’ 흔한 원인입니다. 브라우저에 프록시 확장 프로그램이 설치되어 별도의 경로를 사용하는 경우도 있습니다. 테스트할 때는 확장 프로그램 프록시, 시스템 프록시, 가상 네트워크 어댑터를 구분하세요. 이 설정들을 같은 기능으로 취급하면 안 됩니다.
데스크톱과 모바일에서 각각 확인할 항목
Windows와 macOS에서는 먼저 앱이 시스템 프록시를 지원하는지, 자체 프록시 설정이 있는지, 클라이언트에서 가상 네트워크 어댑터 모드를 켰는지 확인하세요. 터미널 프로그램은 프록시 환경 변수에 의존할 수도 있으므로 터미널 요청 결과를 브라우저의 작동 근거로 삼을 수는 없습니다. 가상 네트워크 어댑터를 시작해도 트래픽 처리가 반드시 성공하는 것은 아니므로 권한과 라우팅 상태도 확인해야 합니다.
Android 클라이언트에는 앱을 포함하거나 제외하는 설정이 있을 수 있으니 대상 앱이 제외되지 않았는지 확인하세요. iOS에서는 사용하는 클라이언트가 지원하는 트래픽 처리 방식과 규칙을 확인해야 합니다. 다른 플랫폼의 메뉴 이름을 그대로 적용하지 마세요. 모바일에서 VPN 상태 표시가 보이더라도 대상 앱을 직접 테스트해야 합니다.
- ✅ 대상 앱을 종료한 뒤 다시 열고, 네트워크 연결이 필요한 새 작업을 실행하세요.
- ✅ 클라이언트 연결 기록에서 해당 도메인이나 프로세스를 찾아 규칙과 아웃바운드 경로를 확인하세요.
- ✅ 앱 제외 목록, 브라우저 프록시 확장 프로그램, 실행 중인 다른 네트워크 도구를 확인하세요.
- ✅ 웹 검색, 이미지 업로드, 앱 메시지를 각각 테스트하세요. 캐시된 페이지를 네트워크 연결의 근거로 삼지 마세요.
- ❌ 브라우저 검사에 통과했다고 해서 모든 앱이 선택한 경로를 사용한다고 판단하지 마세요.
메시지 앱이나 동기화 도구 등은 장시간 연결을 유지할 수 있습니다. 경로를 바꾼 뒤에도 기존 연결이 바로 새로 설정되지 않을 수 있으므로, 웹페이지를 반복해서 새로고침하기보다 대상 앱을 다시 시작하는 편이 판단에 더 도움이 됩니다. 업로드, 음성·영상 또는 실시간 메시지만 문제가 있다면 웹 접속만 테스트하지 말고 UDP 전달 지원과 규칙도 확인하세요.
연결됨으로 표시되지만 경로를 사용하지 않을 때: 증상별 점검
출구는 바뀌지 않았지만 클라이언트에는 트래픽이 표시됨
먼저 조회 요청에 직접 연결 규칙이 적용됐는지 확인한 다음, 시스템 프록시나 가상 네트워크 어댑터가 실제로 활성화됐는지 살펴보세요. 클라이언트의 트래픽은 구독 정보 업데이트, 지연 시간 확인 또는 기타 백그라운드 요청일 수 있으므로 대상 브라우저의 트래픽까지 처리되고 있다는 증거는 아닙니다. 기록에서 대상 요청을 찾을 수 없다면 노드를 계속 바꾸기보다 먼저 트래픽 처리 범위를 확인하세요.
출구는 바뀌었지만 대상 서비스를 사용할 수 없음
검사 요청이 경로를 통과했다는 점은 알 수 있지만, 대상 서비스도 이용할 수 있다는 뜻은 아닙니다. 서비스는 계정 지역, 결제 정보, 출구 IP의 평판 또는 세션 상태에 따라 제한을 둘 수 있습니다. 먼저 대상 요청이 실제로 어떤 경로로 나갔는지 확인하고 오류 메시지를 살펴보세요. 지역 표시가 맞다고 해서 이용이 허용된다고 볼 수 없으며, 모든 접속 거부를 DNS 탓으로 돌려서도 안 됩니다.
브라우저는 정상인데 별도 앱은 작동하지 않음
먼저 해당 앱이 시스템 프록시를 우회하는지 확인한 다음 프로세스 규칙, 앱 내장 프록시, 연결 재사용 여부를 살펴보세요. 특정 기능만 실패한다면 정상 작동하는 기능과 사용하는 도메인 및 전송 방식을 비교하세요. 구독 정보에 Shadowsocks, Trojan, VLESS 같은 프로토콜 이름이 표시된다는 사실은 설정 유형만 보여 줄 뿐, 클라이언트가 대상 앱의 트래픽을 처리한다는 증거는 아닙니다.
트래픽 처리를 켠 뒤 오히려 인터넷이 전혀 연결되지 않음
가상 네트워크 어댑터 권한, 기본 경로, DNS 설정, 다른 네트워크 도구가 설정을 함께 변경했는지 확인하세요. 먼저 인터넷이 되는 기준 상태로 되돌린 뒤 기능을 하나씩 활성화하세요. 검사를 위해 시스템 보호 기능을 장기간 끄지 마세요. 설정의 출처를 모르는 경우 낯선 구성을 반복해서 가져오기보다 오류 기록을 보관하고 지원 채널에 문의하는 편이 안전합니다.
재검사와 결론: 서로 뒷받침되는 근거를 모으세요
유효한 재검사에서는 네트워크 환경과 대상 앱을 그대로 유지하고 한 번에 한 가지 요소만 바꿔야 합니다. 테스트 시간, 클라이언트 모드, 선택한 경로, 대상 도메인, 오류 증상을 기록한 뒤 출구, DNS, 규칙 기록을 비교하세요. 그래야 노드 변경, 규칙 변경, 앱 자체 상태 중 무엇이 차이를 만들었는지 구분할 수 있습니다.
도움을 요청할 때는 도움말 페이지나 사용자 패널을 통해 이 정보를 전달할 수 있습니다. 스크린샷을 공유하기 전에는 구독 링크, 액세스 토큰, 개인정보를 가리세요. 연결 기록에 방문한 도메인이 포함될 수 있습니다. 익명·무로그 정책은 서비스의 개인정보 보호 방침을 설명하는 것이며, 로컬 클라이언트 기록을 그대로 공개해도 된다는 뜻은 아닙니다.
판단 기준: 대상 앱의 새 요청에 예상한 프록시 규칙이 적용되고, 출구 결과가 선택한 경로와 일치하며, DNS 동작도 선택한 정책에 부합해야 작동 여부를 뒷받침하는 근거가 충분해집니다.
웹페이지 한 번의 검사로 확인되는 것은 해당 요청뿐입니다. 다른 앱, 다른 주소 계열, 연결이 끊긴 뒤의 동작까지 확인하려면 각각 테스트해야 합니다. ‘연결됨’ 표시나 ‘지역이 맞음’만으로 이 과정을 대신할 수는 없습니다.
처음 설정한다면 빠른 시작 가이드를 참고해 구성을 가져오고 모드를 설정한 뒤 이 문서의 점검을 진행하세요. 구독 링크는 노드와 관련 설정을 업데이트하는 데 쓰이며, 그 자체로 트래픽을 처리하지는 않습니다. 구성을 가져온 상태, 노드가 표시되는 상태, 실제 요청이 경로를 통과하는 상태는 각각 따로 확인해야 합니다.