VPN 작동 여부 확인하기: 출구 IP와 DNS 점검

VPN이 제대로 작동하는지 확인하려면 먼저 출구 IP를 비교하고, DNS를 확인한 다음, 사용하려는 앱에서 연결을 점검하세요. 클라이언트에 ‘연결됨’이라고 표시되는 것은 연결 상태만 보여줄 뿐, 모든 요청이 선택한 경로를 이용한다는 증거는 아닙니다. 점검 결과는 현재 모드와 분할 연결 규칙을 함께 고려해야 합니다.

이 글에서는 실제 문제 해결 순서에 따라 확인 방법을 설명합니다. 모든 검사 항목에 같은 지역이 표시되는 것이 목표는 아닙니다. VPN을 이용해야 하는 요청은 실제로 VPN 경로를 이용하는지, 도메인 조회가 설정에 맞는지, 직접 연결 요청도 예상대로 처리되는지 확인하면 됩니다.

먼저 ‘작동’의 점검 범위부터 확인하기

시스템 터널, 시스템 프록시, 브라우저 프록시는 적용 범위가 서로 다릅니다. 시스템 프록시는 일반적으로 해당 설정을 따르는 프로그램에만 영향을 주며, 브라우저 확장 프로그램은 브라우저 요청만 처리할 수 있습니다. 터널 모드는 더 많은 트래픽을 처리할 수 있지만 라우팅, 제외 앱, 분할 연결 규칙의 영향을 받습니다. 시스템에 VPN 아이콘이 표시된다고 해서 모든 앱의 트래픽이 VPN을 통한다고 단정할 수는 없습니다.

규칙 모드에서는 국내 웹사이트는 직접 연결하고 해외 웹사이트는 프록시로 연결하는 방식이 동시에 적용될 수 있습니다. 출구 IP 확인 사이트도 직접 연결 규칙에 해당할 수 있습니다. 클라이언트의 ‘전체’ 모드는 대개 이미 처리 대상으로 지정된 요청을 모두 프록시로 보낸다는 뜻이지, 모든 앱의 트래픽을 자동으로 가로챈다는 뜻은 아닙니다.

점검 전에 현재 모드, 노드 이름, 브라우저의 보안 DNS 설정, 터널 사용 여부를 기록하세요. 이후에는 한 번에 조건 하나만 바꿔야 결과가 달라진 이유를 파악할 수 있습니다.

출구 IP: 연결 전후를 먼저 비교하기

출구 IP는 원격 웹사이트에 표시되는 공인 IP 주소로, 기기의 로컬 네트워크 주소와는 다릅니다. 연결을 끊은 상태에서 브라우저로 신뢰할 수 있는 공인 IP 확인 사이트를 열고 주소와 네트워크 정보를 기록하세요. 그런 다음 선택한 경로에 연결하고 같은 브라우저에서 다시 확인합니다. 오래전에 저장한 화면을 비교 자료로 쓰지 마세요. 로컬 네트워크의 공인 IP도 바뀔 수 있습니다.

1. 연결을 끊고 현재 네트워크의 공인 IP를 기록합니다. 확인 페이지에 IPv4와 IPv6가 각각 표시되면 두 결과를 모두 보관하세요.
2. 경로에 연결한 뒤 클라이언트에 핸드셰이크 실패, 인증 실패 또는 설정 오류가 표시되지 않는지 확인합니다.
3. 확인 페이지를 새로고침하고, 필요하면 새 시크릿 창을 열어 페이지 캐시의 영향을 배제합니다.
4. 클라이언트 연결 기록을 열어 확인 도메인에 어떤 규칙이 적용됐는지, 어떤 출구가 선택됐는지 확인합니다.
5. 별도의 확인 사이트에서도 주소를 확인하고, 지도에 표시된 도시 이름만 보지 마세요.

연결 후 주소가 바뀌고 로그에서 해당 요청이 선택한 프록시를 거친 것으로 확인되어야 충분한 근거가 됩니다. 위치 정보 데이터베이스가 오래됐을 수 있으므로 도시가 정확하지 않아도 경로가 작동하지 않는다는 뜻은 아닙니다. 주소, 네트워크 정보, 요청 경로를 우선 확인하고 국기나 지역 표시만으로 판단하지 마세요.

주소가 바뀌지 않아도 곧바로 연결 실패라고 단정할 필요는 없습니다. 확인 도메인이 규칙에서 직접 연결로 지정됐는지, 브라우저가 시스템 프록시를 우회하는지, 확인 페이지가 특정 주소 유형만 표시하는지 먼저 확인하세요. 비교를 위해 일시적으로 전체 트래픽 정책을 사용했다면 테스트 후 원래 설정으로 되돌리세요.

DNS: 리졸버가 다르다고 반드시 누출은 아닙니다

DNS는 도메인 이름을 IP 주소로 변환합니다. DNS 테스트 페이지는 보통 테스트 전용 도메인을 만들어 권한 DNS 서버에 어떤 재귀 리졸버가 조회를 요청하는지 확인합니다. 표시되는 주소는 대개 리졸버가 외부 서버에 조회할 때 사용하는 주소이지, 기기의 공인 출구 IP가 아닙니다. 따라서 DNS 주소와 웹 출구 IP가 다른 것은 흔한 일입니다.

비교할 때는 모든 결과가 노드가 있는 지역에 표시되는지보다 리졸버의 소속과 설정을 확인하세요. 공용 DNS는 분산형 서비스를 제공할 수 있으며, 테스트 페이지의 지역 표시는 데이터베이스에 따른 위치 정보일 뿐입니다. 클라이언트는 도메인마다 로컬 조회, 원격 조회 또는 합성 주소 방식을 다르게 적용할 수 있고, 그에 따라 결과도 달라집니다.

더 자세히 살펴봐야 할 상황은 관련 DNS 조회가 모두 프록시를 거쳐야 하는데도 로컬 네트워크의 리졸버가 반복해서 나타나고, 로그나 설정에서 조회가 예상한 경로를 우회한 사실이 확인되는 경우입니다. 익숙한 공용 DNS 서비스 이름이 보인다는 것만으로 누출이라고 판단할 수는 없습니다.

암호화 DNS와 프록시 출구는 별개의 문제입니다. 브라우저가 DoH를 사용하면 브라우저와 DNS 서비스 간의 조회를 암호화할 수 있지만, 그 연결 자체는 직접 연결일 수 있습니다. 암호화 DNS를 사용한다고 DNS 요청이 선택한 경로를 이용하는 것은 아닙니다.

먼저 브라우저의 보안 DNS를 확인한 뒤 클라이언트의 DNS 정책과 시스템 설정을 살펴보세요. 일부 브라우저는 자체적으로 DNS를 조회해 클라이언트가 지정한 리졸버를 우회할 수 있고, 일부 클라이언트는 DNS 요청을 내부 모듈로 처리합니다. 테스트 페이지의 결과를 그대로 설정에 복사하거나 모든 DNS 설정을 한꺼번에 바꾸지 마세요.

브라우저 결과를 기기 전체에 적용하지 말고 앱별로 확인하기

브라우저 출구가 예상과 일치해도 확인된 것은 테스트 웹페이지의 요청뿐입니다. 데스크톱 프로그램, 게임, 터미널, 백그라운드 서비스는 서로 다른 네트워크 스택을 사용할 수 있습니다. 시스템 프록시 설정을 따르지 않는 앱도 있고, UDP를 사용하는 앱도 있으며, 노드를 바꿔도 기존 연결이 바로 전환되지 않을 수 있습니다.

실제로 확인하려면 먼저 대상 앱을 완전히 종료한 뒤 다시 열고 명확한 네트워크 작업을 실행하세요. 동시에 클라이언트 연결 기록에서 대상 도메인, 프로세스 또는 목적지 주소를 찾아 적용 규칙과 출구를 확인합니다. 전체 트래픽 사용량만 보면 앱 요청인지 시스템 백그라운드 트래픽인지 구분하기 어렵습니다.

• ✅ 브라우저: 확인 페이지를 다시 열고 출구 주소와 확인 도메인에 적용된 규칙을 확인합니다.
• ✅ 대상 앱: 앱을 재시작한 뒤 실제 기능을 사용하고 관련 연결 기록이 나타나는지 확인합니다.
• ✅ UDP 사용 환경: 클라이언트의 트래픽 처리 방식과 경로 지원 여부를 확인합니다. 웹페이지 접속으로 대신 검증하지 마세요.
• ✅ 규칙 모드: 프록시를 사용해야 하는 요청과 직접 연결해야 하는 요청을 각각 확인해 모두 예상대로 처리되는지 살펴봅니다.
• ❌ 페이지가 열리거나 앱 아이콘이 켜지거나 트래픽 수치가 변했다는 이유만으로 모든 연결이 작동한다고 판단하지 마세요.

Windows와 macOS에서는 시스템 프록시와 터널 처리를 구분해야 합니다. Android에서는 대상 앱이 제외 목록에 있는지 확인하세요. iOS에서 VPN 구성을 추가하도록 허용하는 것은 시스템 권한을 부여한 것일 뿐이므로 클라이언트 정책과 실제 연결을 확인해야 합니다. 플랫폼마다 메뉴 이름이 다르므로 사용 중인 클라이언트의 안내를 참고하세요.

터미널 도구도 프록시 환경 변수의 영향을 받을 수 있습니다. 브라우저에서는 연결되지만 명령줄에서는 실패한다면 경로를 바꾸기 전에 명령줄이 같은 프록시를 사용하는지 확인하세요. 설정 방법은 빠른 시작 가이드에서 트래픽 처리와 설정 가져오기 단계를 확인할 수 있습니다.

IPv6와 WebRTC: 놓치기 쉬운 경로 추가 점검

네트워크에서 IPv4와 IPv6를 모두 제공하면 앱이 한쪽을 우선 사용할 수 있습니다. 클라이언트가 일부 트래픽만 처리하는 경우 웹의 IPv4 출구는 바뀌어도 IPv6는 로컬 네트워크를 계속 이용할 수 있습니다. 확인 페이지에서 가장 눈에 띄는 주소 하나만 보지 말고 각각 확인하세요.

로컬 네트워크에서 사용할 수 있는 IPv6가 없다면 테스트 실패가 프록시 문제를 뜻하지는 않습니다. 테스트에 로컬 네트워크의 공인 IPv6가 표시되면 해당 요청이 원래 직접 연결을 허용받았는지 확인한 뒤 터널, IPv6 라우팅, 제외 규칙을 살펴보세요. 문제를 좁히기 위해 IPv6를 일시적으로 끌 수는 있지만, 일반적인 장기 해결책은 아닙니다.

WebRTC는 브라우저의 실시간 통신 기능으로, 일반 웹 요청과 다른 경로를 통해 후보 주소를 확인할 수 있습니다. 테스트 결과에 표시되는 로컬 네트워크 주소, 숨김 처리된 호스트 이름, 공인 IP 주소는 각각 의미가 다르므로 주소 하나만 보고 모두 누출이라고 부를 수는 없습니다.

중요한 것은 예상하지 못한 로컬 공인 IP 출구가 나타나는지 여부입니다. 그렇다면 브라우저의 관련 개인정보 설정, 클라이언트의 UDP 처리, 터널 정책을 확인하세요. 설정을 바꾸기 전에 화상 회의 등 필요한 기능에 미칠 영향도 고려해야 합니다. 테스트 결과를 보기 좋게 만들려고 필요한 기능을 무작정 끄지 마세요.

연결됐지만 작동하지 않을 때, 증상별로 원인 좁히기

구독을 가져왔지만 선택한 설정이 업데이트되지 않음

구독 링크는 노드와 설정을 가져오는 용도이지 연결 성공을 증명하지는 않습니다. 업데이트 실패, 클라이언트 형식 비호환, 이전 설정 사용으로 인해 노드 이름은 표시되지만 요청이 제대로 처리되지 않을 수 있습니다. 구독 업데이트 시각과 오류 메시지를 확인한 뒤 선택한 노드가 현재 설정에서 가져온 것인지 확인하세요. 클라이언트가 구독에 포함된 프로토콜을 지원해야 합니다. 노드 이름이 같다는 것만으로 호환성을 확인할 수는 없습니다.

구독 링크에는 계정 인증 정보가 포함되는 경우가 많습니다. 도움을 요청할 때 전체 링크를 공개하거나 출처가 불분명한 온라인 변환 도구에 붙여 넣지 마세요. 화면 캡처와 로그에 포함된 액세스 토큰은 먼저 가리세요.

출구 IP는 바뀌었지만 대상 웹사이트를 이용할 수 없음

이때는 ‘프록시가 작동하는지’와 ‘웹사이트가 해당 요청을 허용하는지’를 구분해야 합니다. 웹사이트는 계정 지역, 이전 세션, 출구 IP 평판, 서비스 정책 등을 기준으로 판단할 수 있으며 앱에 이전 연결이 남아 있을 수도 있습니다. 먼저 앱을 재시작하고 새 요청의 로그를 확인한 뒤 웹사이트 자체 안내를 살펴보세요. 모든 접속 실패를 DNS 탓으로 돌려서는 안 됩니다.

다시 연결하거나 네트워크를 바꾼 뒤 결과가 달라짐

네트워크를 전환하면 시스템 DNS, 기본 경로, 이미 설정된 연결이 바뀔 수 있습니다. 브라우저 페이지 캐시, 시스템 DNS 캐시, 클라이언트 조회 캐시가 동시에 갱신되지 않을 수도 있습니다. 먼저 요청을 새로 보내고 관련 앱을 재시작하세요. 그래도 결과가 다르면 플랫폼 안내에 따라 캐시를 지우세요. 매번 작업을 기록하고 캐시 삭제, 노드 변경, DNS 수정, 모드 변경을 한꺼번에 하지 마세요.

IEPL 전용 회선, 중계, 직접 연결은 회선의 전송 방식을 설명하는 용어이지 기기에서 트래픽을 처리하는 범위와는 다릅니다. 전용 회선을 사용해도 앱의 프록시 우회나 잘못된 분할 연결 규칙이 저절로 해결되지는 않습니다. 프로토콜과 네트워크 구성은 회선과 프로토콜에서 더 확인할 수 있습니다.

점검 결과를 다시 확인할 수 있도록 정리하기

유용한 점검 기록에는 네트워크 환경, 클라이언트와 모드, 노드 이름, 연결 전후 출구 IP, DNS 정보, 대상 앱의 동작, 로그에 적용된 규칙이 포함되어야 합니다. 시각과 작업 순서도 저장한 뒤 같은 조건에서 다시 테스트하면 일시적인 장애와 설정 문제를 구분하기 쉽습니다.

결과를 여전히 설명하기 어렵다면 고객 지원으로 민감 정보를 가린 기록을 보내 주세요. 어떤 요청이 프록시를 이용해야 하는지와 실제로 무엇을 확인했는지 알려주면 ‘연결이 안 돼요’라는 설명만 있을 때보다 원인을 찾기 쉽습니다. 로그에 전체 공인 IP, 접속 도메인, 구독 인증 정보가 포함되어 있다면 문제 해결에 필요한 정보만 남기세요.

마지막으로 테스트 중 임시로 바꾼 설정을 복원하고 자주 사용하는 앱을 다시 확인하세요. 테스트 페이지는 상태를 살펴보는 도구일 뿐, 최종 목표는 아닙니다. 실제로 확인해야 할 것은 평소 사용하는 요청이 규칙에 따라 계속 올바른 경로를 이용하는지입니다.