VPN 연결 상태와 트래픽 경로를 구분해 확인하기
VPN 연결 여부를 확인하려면 공인 IP, DNS, 앱별 경로를 각각 살펴봐야 합니다. 연결 표시는 클라이언트의 연결 상태만 알려줄 뿐입니다. 대상 앱의 트래픽이 VPN을 이용하는지, DNS 요청이 어디로 전달되는지, 공인 IP가 예상한 값인지 실제 요청을 통해 확인해야 합니다.
프록시 클라이언트와 시스템 VPN은 트래픽을 처리하는 범위가 다를 수 있습니다. 시스템 프록시는 해당 설정을 따르는 앱에 프록시를 제공할 뿐, 모든 프로그램에 사용을 강제하지는 않습니다. 브라우저 확장 프로그램은 보통 해당 브라우저에만 영향을 줍니다. TUN 모드는 가상 네트워크 인터페이스와 라우팅을 통해 지정된 트래픽을 처리하지만, 제외 앱이나 라우팅 규칙, 주소 계열 설정에 따라 달라질 수 있습니다. 브라우저가 열린다는 이유만으로 기기 전체가 연결됐다고 판단하면 이런 차이를 놓치기 쉽습니다.
테스트에 앞서 목표를 정하세요. 특정 앱만 국제 경로를 이용하게 할 것인지, 기본 트래픽을 모두 터널로 보낼 것인지 확인합니다. 규칙 모드에서 특정 사이트를 직접 연결하도록 설정하는 것은 오류가 아닙니다. 실제 경로가 설정한 목표와 다를 때만 추가로 점검하면 됩니다.
공인 IP: 연결 전후 결과 비교
공인 IP는 대상 웹사이트가 요청을 보낸 곳으로 확인하는 주소입니다. 기기의 로컬 네트워크 주소와는 다르며, 구독 설정에 적힌 서버 주소와도 반드시 같지는 않습니다. 구독에 포함된 주소가 중계 지점이고 최종 출구는 다른 곳일 수 있습니다. 확인할 때는 같은 도구와 브라우저, 같은 네트워크 환경에서 결과를 비교하세요.
- 클라이언트 연결을 끊고 브라우저 프록시 확장 프로그램을 잠시 비활성화하세요. 신뢰할 수 있는 공인 IP 조회 도구에서 현재 IP와 네트워크 사업자 정보를 기록하고, IPv4와 IPv6 결과가 각각 표시되는지도 확인합니다.
- 선택한 경로에 연결한 뒤 시스템 프록시 또는 TUN이 목표에 맞게 활성화됐는지 확인하세요. 규칙 모드라면 조회 도구의 도메인에 프록시 규칙이 실제로 적용되는지 살펴봅니다.
- 다시 조회를 실행하세요. 이전 탭에 표시된 결과만 확인하지 말고, 필요한 경우 새 브라우저 세션을 열어 캐시된 페이지나 기존 연결의 영향을 배제합니다.
- 클라이언트의 연결 로그에서 조회 요청에 적용된 규칙과 정책 그룹, 실제 출구 경로를 확인한 뒤 조회 결과와 비교하세요.
- 출구 지역이 다른 경로로 바꾼 뒤 다시 조회하세요. 결과가 계속 같다면 경로 적용 범위와 규칙부터 확인하고, 곧바로 경로가 작동하지 않는다고 단정하지 마세요.
국가나 지역 표시는 참고 정보로만 활용하세요. IP 지리 데이터베이스는 최신 정보가 아닐 수 있고 조회 도구마다 결과가 다를 수 있습니다. 같은 지역의 여러 경로가 동일한 출구를 공유할 수도 있습니다. 요청 로그에 선택한 정책이 적용된 것으로 표시되고 조회된 네트워크 소유 정보가 해당 경로의 출구와 일치하는지 확인하는 편이 더 확실합니다. 지연 시간만으로 출구를 검증할 수는 없습니다.
IPv4는 바뀌었지만 IPv6가 여전히 로컬 네트워크로 표시된다면 클라이언트가 IPv6 트래픽을 처리하는지, 앱이 IPv6를 우선 사용하는지 확인하세요. 모든 트래픽을 처리해야 한다면 클라이언트 설명서에 따라 IPv6 라우팅을 설정하거나 제공되는 보호 옵션을 사용하세요. IPv4만 조회하는 페이지로는 IPv6 경로를 확인할 수 없습니다.
DNS 누출: DNS 조회 경로가 설정과 일치하는지 확인
DNS는 도메인 이름을 IP 주소로 변환합니다. 브라우저 요청은 프록시를 거치더라도 도메인 조회는 로컬 네트워크의 DNS 서버로 전달될 수 있고, 프록시 측에서 처리될 수도 있습니다. 여기서 말하는 DNS 누출은 설정한 목표에 따라 판단해야 합니다. 관련 DNS 요청이 지정한 터널을 이용해야 하는데 로컬 DNS 서버로 전송된다면 경로가 설정과 다르게 동작하는 것입니다.
경로에 연결한 뒤 신뢰할 수 있는 DNS 테스트 도구를 사용해 조회 서버와 네트워크 소유 정보를 기록하세요. 이러한 도구는 보통 테스트용 도메인을 이용해 재귀 DNS 조회의 출처를 확인합니다. 표시되는 것은 조회에 참여한 서버이지 웹사이트 요청의 출구가 아닙니다. 조회 서버와 출구의 지역이 다르다는 사실만으로 DNS 누출이라고 판단할 수는 없습니다.
브라우저의 보안 DNS, 시스템 DNS, 클라이언트 DNS, 앱 자체의 조회 기능이 동시에 사용될 수 있습니다. 보안 DNS는 암호화된 방식으로 DNS 서버에 연결하는 경우가 많지만, 암호화됐다고 해서 자동으로 VPN 터널을 이용하는 것은 아닙니다. 브라우저가 시스템 DNS를 거치지 않을 수도 있으므로 브라우저의 테스트 결과가 모든 앱의 경로를 보여주지는 않습니다.
- 먼저 클라이언트와 브라우저의 DNS 설정을 기록하고, 어떤 DNS 서버를 사용할지와 DNS 요청을 프록시로 보낼지 직접 연결할지 정하세요.
- 클라이언트에서 직접 연결 도메인과 프록시 도메인의 DNS 경로를 각각 설정할 수 있는지 확인하세요. 규칙 기반 분할 라우팅에서는 로컬 도메인 조회를 로컬 DNS 서버로 보내도록 의도했을 수도 있습니다.
- 차이를 찾으려면 브라우저의 보안 DNS를 잠시 변경한 뒤 테스트를 반복할 수 있습니다. 한 번에 설정 하나만 바꾸고, 테스트가 끝나면 필요한 설정으로 되돌리세요.
- 클라이언트에서 DNS 로그를 제공하는지 확인하고 캐시 응답, 프록시 측 조회, 클라이언트의 로컬 조회, 실제 전송된 요청을 구분하세요.
앱별 검증: 브라우저만 확인해서는 부족합니다
앱별 경로를 확인하려면 대상 앱에서 새로운 요청을 발생시켜야 합니다. 먼저 클라이언트의 연결 로그를 연 다음 테스트할 앱을 다시 시작하고, 프록시가 필요한 기능이나 페이지에 접속하세요. 요청 시간과 대상 도메인, 적용된 규칙과 정책을 확인합니다. 로그가 없다면 단순히 페이지가 열렸다는 이유만으로 경로를 판단할 수 없습니다. 해당 서비스가 원래 직접 연결될 수도 있고 캐시된 콘텐츠가 표시됐을 수도 있습니다.
Windows와 macOS에서는 시스템 프록시 설정을 따르지 않는 프로그램이 있습니다. 이 경우 프로그램 자체의 프록시 설정을 사용하거나 클라이언트 설명서에 따라 TUN을 활성화하세요. 가상 네트워크 인터페이스를 만들 때 권한이 필요할 수 있으며, 자세한 내용은 사용 중인 클라이언트를 확인해야 합니다. 명령줄 도구도 자체 프록시 옵션이나 환경 변수가 필요할 수 있으므로 시스템 프록시가 작동한다고 터미널 요청까지 성공하는 것은 아닙니다.
Android 클라이언트는 시스템 VPN 인터페이스를 사용하며 앱을 허용하거나 제외하는 옵션을 제공할 수 있습니다. 대상 앱이 올바른 목록에 있는지 확인하고 시스템 VPN 설정과 업무 프로필도 살펴보세요. iOS 클라이언트는 보통 시스템 네트워크 확장으로 터널을 만들며, 실제 라우팅 기능은 클라이언트와 설정에 따라 달라집니다. Android의 앱별 설정 절차를 그대로 적용할 수는 없습니다.
| 테스트 대상 | 중점 확인 항목 | 이 결과만으로 판단할 수 없는 사항 |
|---|---|---|
| 브라우저 | 공인 IP, 프록시 확장 프로그램, 보안 DNS, 해당 요청 로그 | 데스크톱 앱과 터미널도 같은 경로를 이용하는지 |
| 데스크톱 앱 | 앱 자체의 프록시 설정, TUN 적용 범위, 도메인 또는 프로세스 규칙 | 시스템 프록시를 켜면 모든 앱이 자동으로 처리되는지 |
| 모바일 앱 | 앱 허용·제외 목록, 다시 연결한 뒤 발생한 요청 | 시스템에 연결 표시가 있으면 모든 앱이 VPN 경로를 이용하는지 |
| 명령줄 도구 | 프록시 옵션, 환경 변수, 도구에서 실제 사용하는 DNS 경로 | 터미널과 브라우저가 모든 네트워크 설정을 공유하는지 |
규칙을 확인할 때는 특정 규칙에 무엇이 적혀 있는지만 보지 말고 최종적으로 어떤 규칙이 적용됐는지 확인하세요. 앞에서 먼저 일치한 규칙이 뒤의 선택보다 우선할 수 있으며, 정책 그룹이 직접 연결이나 다른 경로를 가리킬 수도 있습니다. 설정을 바꾼 뒤에는 새 연결을 시작하세요. 기존 세션은 새 경로를 바로 적용하지 않을 수 있습니다.
연결된 것처럼 보이지만 경로가 바뀌지 않을 때 점검 순서
먼저 구독을 가져왔고 업데이트가 정상적으로 완료됐는지 확인한 다음, 현재 정책에서 해당 경로를 사용 중인지 살펴보세요. 구독 링크는 설정을 가져오는 주소이지 웹페이지 테스트 주소나 설치 파일 링크가 아닙니다. 가져오기에 성공했다는 것은 클라이언트가 설정을 받았다는 뜻일 뿐입니다. 프로토콜 지원 여부, 연결 성공 여부, 앱 트래픽 적용 여부는 각각 별도로 확인해야 합니다.
Shadowsocks, VMess, Trojan, VLESS는 널리 쓰이는 프록시 프로토콜입니다. Hysteria2와 TUIC는 보통 QUIC 기반 전송 방식을 사용합니다. 프로토콜 이름만으로 앱이 자동으로 프록시를 이용하는 것은 아닙니다. 클라이언트가 해당 프로토콜과 설정 매개변수를 지원해야 하며, 로컬 네트워크도 해당 전송 방식을 허용해야 합니다. IEPL 전용 회선, 중계, 직접 연결은 네트워크 경로를 설명하는 용어로, 프로토콜이나 기기에서 트래픽을 처리하는 모드와는 다른 개념입니다.
- ✅ 브라우저의 공인 IP가 바뀌지 않음: 시스템 프록시가 활성화됐는지, 확장 프로그램이 설정을 덮어쓰는지, 조회 도메인에 직접 연결 규칙이 적용됐는지 확인하세요.
- ✅ 브라우저는 되지만 앱은 안 됨: 앱 자체 프록시 설정과 앱별 제외 목록, TUN 라우팅을 확인하세요. 구독을 반복해서 바꾸는 것부터 시작하지 마세요.
- ✅ 모든 앱에서 실패함: 클라이언트 오류 로그와 현재 노드, 프로토콜 지원 여부를 확인한 뒤 로컬 네트워크에서 해당 전송 방식을 허용하는지 살펴보세요.
- ✅ 재시작한 뒤에만 작동함: 기존 연결과 설정 다시 불러오기 동작을 확인하고 클라이언트와 대상 앱 중 무엇을 재시작해야 하는지 기록하세요.
- ✅ 공인 IP는 맞지만 대상 서비스에서 오류가 발생함: 경로 문제와 계정 지역, 콘텐츠 이용 권한, 위험 관리, 서버 장애를 구분하세요. 오류가 발생했다는 이유만으로 VPN이 작동하지 않는다고 판단할 수는 없습니다.
- ✅ DNS 테스트에 예상하지 못한 서버가 표시됨: 브라우저 보안 DNS와 시스템 DNS, 클라이언트 규칙을 비교해 조회 경로를 확인한 뒤 설정을 변경하세요.
WebRTC 테스트도 별도로 살펴봐야 합니다. 실시간 통신 기능은 후보 주소를 통해 추가 네트워크 정보를 노출할 수 있지만, 로컬 네트워크 주소가 감지됐다고 해서 공인 트래픽이 터널을 우회한 것은 아닙니다. 예상하지 못한 공인 후보 주소가 발견되면 브라우저 정책과 UDP 트래픽 처리 여부를 확인하세요. 일반 웹페이지에서 공인 IP를 확인하는 것만으로 모든 실시간 통신 경로가 목표와 일치한다고 증명할 수는 없습니다.
연결이 끊기거나 네트워크를 바꾼 뒤 다시 확인하기
연결 중 작동하는 것과 연결이 끊긴 뒤에도 개인정보 보호 설정을 유지하는 것은 별개의 문제입니다. 자동 직접 연결을 허용하는 설정은 노드를 사용할 수 없을 때 로컬 네트워크로 돌아갈 수 있습니다. 연결 해제 시 트래픽을 차단하는 옵션이 있는 클라이언트도 해당 옵션이 활성화됐고 필요한 범위에 적용되는지 확인해야 합니다. 모든 클라이언트에 이런 기능이 있다고 가정하지 마세요.
민감하지 않은 테스트 페이지를 사용해 노드를 일시적으로 사용할 수 없을 때 동작을 살펴보세요. 새 요청이 실패하는지, 다른 정책으로 전환되는지, 직접 연결되는지 확인합니다. 클라이언트를 직접 종료하는 경우와 노드 연결이 예기치 않게 끊기는 경우에는 동작이 다를 수 있으므로 테스트 기록에 상황을 명확히 적으세요. 기기의 절전 모드에서 깨어나거나 네트워크를 바꾼 뒤에도 공인 IP와 대상 앱을 다시 확인해 연결이 복구됐는지 살펴보세요.
고객 지원 요청을 제출할 때는 클라이언트 이름, 운영체제 버전, 연결 모드, 문제가 발생한 시각, 대상 도메인과 관련 오류 정보만 남기면 됩니다. 스크린샷을 공유하기 전에 구독 링크와 토큰, 계정 정보, 불필요한 접속 기록을 가리세요. 문제를 재현하려고 전체 설정을 공개 게시판에 올리지 마세요. VPNHO 사용자는 고객 지원 문의를 통해 점검 자료를 제출할 수 있습니다.
판단 기준: 대상 요청의 출구, DNS 조회 경로, 앱에 적용되는 범위와 규칙 설정이 서로 일치해야 해당 상황에서 VPN이 정상 작동한다고 볼 수 있습니다. 브라우저 테스트 통과는 해당 브라우저 요청에만 해당합니다. 연결 해제 시 보호 동작과 다른 앱의 경로는 따로 확인해야 합니다.
점검 결과를 간단한 인수인계 기록으로 정리하세요. 로컬 네트워크, 선택한 경로, 적용 모드, 대상 앱, 공인 IP 결과, DNS 결과와 연결 해제 동작을 적어두면 됩니다. 다음에 문제가 생겼을 때 프로토콜과 DNS, 규칙을 한꺼번에 바꾸는 것보다 기록과 비교하는 편이 원인을 찾기 쉽습니다. 클라이언트 연결과 설정 가져오기 방법은 사용 가이드에서 확인할 수 있습니다. 경로 종류와 프로토콜 설명은 각각 노드 목록과 프로토콜 안내를 참고하세요.