VPN이 실제로 적용되었는지 확인하는 방법: 출구 IP·DNS·앱별 점검

클라이언트의 '연결됨' 표시는 로컬 터널 핸드셰이크가 성공했다는 뜻일 뿐, 데이터가 실제로 서버를 통해 나갔다는 뜻은 아닙니다. VPN이 적용됐는지 판단하려면 각각 독립적으로 어긋날 수 있는 세 가지 신호를 봐야 합니다. 출구 IP, DNS 조회 위치, 그리고 특정 앱의 실제 경로입니다. 세 가지 중 두 가지가 맞지 않으면 적용되지 않은 것으로 보는 게 안전합니다.

먼저 구분할 것: 연결 상태, 출구 IP, DNS 조회

연결 상태는 클라이언트가 스스로 판단하는 값으로, '터널이 만들어졌다'는 단계까지만 보여줍니다. 터널이 만들어진 뒤에 어떤 트래픽이 터널로 들어가는지, 도메인을 누가 조회하는지, 특정 앱이 시스템 설정을 우회하는지는 전혀 다른 설정이 결정합니다. 그래서 검증은 항목별로 따로 해야 하며, '웹페이지가 열리느냐' 하나로 전체를 판단하면 안 됩니다.

권장 순서는 출구 IP → DNS → 앱별 확인입니다. 출구 IP가 가장 직관적이고, DNS는 가장 자주 놓치는 항목이며, 앱별 확인은 가장 자주 오판하는 항목입니다.

방법 1: 출구 IP 확인 — 트래픽이 어디서 나가는지 보기

출구 IP는 외부 사이트가 보는 출발지 주소입니다. 방법은 간단합니다. 연결을 끊고 한 번, 연결한 뒤 다시 한 번 조회해서 두 결과가 다르고 새 주소가 선택한 지역에 있으면 이 단계는 통과입니다. 명령줄에서 받는 값은 순수 텍스트라 클라이언트 화면에 의존하지 않습니다.

# macOS / Linux 터미널
curl -s https://ifconfig.me/ip

# Windows PowerShell
(Invoke-RestMethod https://ifconfig.me/ip)

# IPv6 출구만 따로 조회
curl -s -6 https://ifconfig.me/ip

브라우저에서 IP 조회 페이지를 열어도 되지만, 화면에 표시되는 것이 순수한 출구 주소인지 확인해야 합니다. CDN이 판단한 도시 이름은 실제 접속 위치와 크게 다른 경우가 많아 결론의 근거로 삼으면 오판하기 쉽습니다.

출구 IP가 선택한 지역과 다르다고 바로 실패로 단정하지 말 것

다음 세 가지는 정상 범위이므로 나눠서 봐야 합니다.

• 중계 서버: 입구는 가까운 곳에, 출구는 목표 지역에 있습니다. 보여야 하는 것은 출구 주소입니다. 입구 주소가 보인다면 이 트래픽이 분할 규칙에 의해 직결로 판정된 것입니다.
• IP 위치 DB 지연: 브로드캐스트 대역이나 최근에 변경된 주소는 위치 표기가 실제보다 늦을 수 있습니다. 다른 조회 소스로 교차 확인하는 편이 안전합니다.
• 듀얼 스택 중 절반만 처리: IPv4는 서버를 거치는데 IPv6는 여전히 로컬 출구인 경우입니다. 브라우저와 OS는 보통 IPv6를 우선하므로, 이때 페이지는 '연결이 안 된' 것처럼 보이지만 실제로는 다른 경로로 나간 것입니다.

듀얼 스택을 점검할 때는 위의 -6 명령을 실행한 뒤 -6 없이 한 번 더 실행해 두 결과를 함께 봐야 합니다. 하나만 보면 잘못된 결론에 이르기 쉽습니다.

방법 2: DNS 조회 — 도메인이 어디서 해석되는지 확인

DNS 유출이란 트래픽은 터널로 들어갔는데 도메인 조회는 여전히 로컬 네트워크의 리졸버에 맡기는 상황입니다. 그러면 조회 결과가 로컬 위치를 기준으로 돌아오고, 플랫폼은 서로 다른 두 개의 위치 신호를 받게 됩니다. 어떤 때는 연결은 되는데 로딩이 느린 것으로, 어떤 때는 로그인 시 추가 인증을 요구받는 것으로, 스트리밍 서비스에서는 지역 불일치로 바로 나타납니다.

# 특정 도메인이 현재 어떻게 해석되는지 확인
nslookup www.wikipedia.org

# 리졸버의 공인 출구 주소 조회(@ 파라미터 없이, 시스템 기본 리졸버 사용)
dig +short TXT o-o.myaddr.l.google.com

# Windows에서 같은 조회
nslookup -type=TXT o-o.myaddr.l.google.com

두 번째 명령이 반환하는 값은 재귀 리졸버의 공인 출구 주소입니다. 이것을 첫 단계에서 확인한 출구 IP와 함께 보세요. 둘이 같은 지역이면 조회가 서버를 따라간 것이고, 리졸버가 여전히 로컬 통신사라면 DNS가 제대로 넘어가지 않은 것입니다.

DNS가 조용히 새는 세 가지 이유

1. 브라우저의 보안 DNS가 켜져 있는 경우. 시스템 리졸버를 우회하기 때문에 클라이언트가 DNS를 넘겨받아도 막을 수 없습니다. 검증할 때는 브라우저 설정에서 보안 DNS를 먼저 끄고 다시 측정해 두 결과를 비교하면 원인을 찾을 수 있습니다.
2. 클라이언트가 DNS를 로컬에서 처리하는 경우. 일부 클라이언트는 기본값이 '로컬 조회 + 원격 연결'이라 도메인이 로컬에서 이미 해석됩니다. 서버 측 조회로 바꾼 뒤 다시 측정하세요.
3. 분할 규칙이 애초에 이 도메인을 직결로 판정한 경우. 규칙 모드에서는 의도된 동작이므로, 검증 대상은 서버로 라우팅되는 도메인이어야 합니다. 직결 도메인을 표본으로 삼으면 안 됩니다.

방법 3: 앱별 점검 — 특정 앱이 서버를 거치는지 확인

앱별 프록시는 Android 클라이언트에서 가장 흔합니다. 데스크톱은 대부분 전역 TUN 방식이라 앱별 분리를 하려면 라우팅 테이블, 별도 브라우저 프록시, 가상 머신 같은 방법이 필요합니다. 이 항목이 가장 오판하기 쉬운 이유는 클라이언트마다 체크의 의미가 반대이기 때문입니다. 어떤 것은 '선택한 앱만 프록시', 어떤 것은 '선택한 앱은 건너뛰기'입니다.

1. 먼저 체크 방향 확인

   앱별 목록을 열어 화면에 '선택한 앱만 프록시'라고 쓰여 있는지 '선택한 앱 건너뛰기'라고 쓰여 있는지 보세요. 이 단계를 반대로 이해하면 이후는 모두 틀어지고, 아무리 꼼꼼히 비교해도 의미가 없습니다.

2. 체크된 앱에서 출구 IP 조회

   앱 내장 브라우저로 IP 조회 페이지를 열어 결과를 기록하고, 연결 전에 적어 둔 기준값과 비교합니다. 주소가 바뀌고 선택한 지역에 있으면 이 항목은 통과입니다.

3. 체크되지 않은 앱이나 시스템 브라우저에서 한 번 더 조회

   두 결과는 달라야 합니다. 같다면 앱별 분리가 적용되지 않고 트래픽이 한 경로로만 나가고 있다는 뜻입니다.

4. 결과가 같다면 두 곳을 확인

   첫째, 목록 방향이 반대로 선택되지 않았는지. 둘째, 이 앱이 자체 네트워크 스택을 쓰는지. 내장 프록시, 자체 프로토콜, 시스템 수준 다운로더는 시스템 설정을 우회할 수 있고, 이런 경우는 클라이언트 설정을 바꿔도 해결되지 않습니다.

5. 기준 기록을 남겨 두기

   OS 메이저 업데이트나 클라이언트 업그레이드 후에는 앱별 목록이 초기화될 수 있습니다. 이 기준 기록으로 다시 측정해 보면, 문제가 생긴 뒤에 원인을 찾아 헤매는 것보다 훨씬 수월합니다.

데스크톱에 앱별 분리 스위치가 없을 때는 판단 방법을 바꿉니다. 같은 PC에서 시스템 브라우저와 자체 프록시 설정을 가진 앱으로 각각 조회해 두 출구가 같은지 보세요. 같으면 전역 처리가 적용된 것이고, 다르면 터널을 우회하는 앱이 있다는 뜻이므로 그 앱에만 따로 프록시를 설정해야 합니다.

연결된 것처럼 보이지만 실제로는 아닌 경우: 흔한 사례 정리

아래 사례들은 점검 과정에서 가장 자주 나오는 것들입니다. 항목별 대조표로 써도 좋습니다.

• ❌ 클라이언트는 연결됨으로 표시되지만 구독 링크가 이미 만료되어 서버 목록이 오래된 상태이고, 연결된 곳은 이미 내려간 주소입니다.
• ❌ 시스템 프록시 모드에서는 시스템 프록시 설정을 읽는 앱만 서버를 거칩니다. 이 설정을 읽지 않는 앱은 그대로 직결됩니다.
• ❌ 브라우저에 보안 DNS가 켜져 있어 조회가 클라이언트 처리를 우회합니다. 출구 IP는 바뀌었는데 조회는 여전히 로컬에서 이뤄집니다.
• ❌ IPv4만 처리되고 IPv6는 로컬 출구로 남아 있습니다. 듀얼 스택 사이트는 IPv6를 우선하므로 페이지는 연결이 안 된 것처럼 보입니다.
• ❌ 앱별 목록 방향을 반대로 선택해, 프록시된다고 생각했지만 실제로는 제외되어 있습니다.
• ❌ 분할 규칙이 대상 도메인을 직결로 판정했거나, 규칙 세트가 오랫동안 갱신되지 않았습니다.
• ✅ 정상 상태: 연결 전과 후에 조회한 출구 IP가 다르고 선택한 지역에 있으며, 리졸버 출구가 서버와 같은 지역이고, 대상 앱에서 따로 조회한 결과도 서버 출구입니다.

한 번에 끝내는 검증 절차

위 방법을 하나의 고정 절차로 묶어 두고, 네트워크를 바꿀 때, 기기를 바꿀 때, 클라이언트 메이저 업데이트 후에 한 번씩 돌려 보세요. 몇 분이면 충분합니다.

1. 연결을 끊고 기준값 기록: IPv4 출구, IPv6 출구, 리졸버 출구 세 가지를 적어 둡니다.
2. 서버 한 곳에 연결하고 같은 세 가지 조회를 반복합니다.
3. 비교: 출구가 바뀌었는지, 지역이 선택한 서버와 일치하는지, 리졸버도 함께 바뀌었는지.
4. 대상 앱을 열어 앱 안에서 출구를 따로 한 번 조회합니다.
5. 하나라도 바뀌지 않았다면 앞 절의 목록을 따라 하나씩 점검하되, 설정은 한 번에 하나만 바꾸고 바꾼 즉시 다시 측정하세요.
6. 다른 서버로 바꿔 한 번 더 돌려 보세요. 서버 한 곳의 문제인지 확인하는 것이고, 서비스 전체를 바로 사용 불가로 단정할 일은 아닙니다.

서버가 많다는 것은 재측정 비용이 낮다는 뜻입니다. 한 서버의 출구가 맞지 않으면 같은 지역의 다른 서버로 바꿔 같은 세 가지 조회를 다시 돌려 보면, 서버 문제인지 로컬 설정 문제인지 구분할 수 있습니다. 서버 목록은 지역별로 묶여 있어 같은 지역의 대체 서버를 고르기 편합니다. 본 서비스는 로그를 기록하지 않으며, 구독 사용량과 트래픽 패키지 잔량은 패널에서 직접 확인할 수 있습니다. 7일 이내 이유 불문 환불 기간에 문제를 발견했다면 복잡한 점검을 먼저 하지 말고 바로 환불 절차를 진행하셔도 됩니다.