클라이언트 창에 '연결됨'이 떠 있다고 해서 트래픽이 실제로 해외 회선으로 나가는 것은 아닙니다. VPN이 정말 적용됐는지 확인하려면 세 가지를 나눠서 봐야 합니다. 출구 IP가 노드가 있는 지역으로 바뀌었는지, DNS 조회는 누가 처리하는지, 지금 쓰는 앱이 규칙에 포함되는지입니다. 아래에서는 이 세 단계를 따라 바로 복사해 쓸 수 있는 점검 방법을 설명하고, '연결은 됐는데 실제로는 통하지 않는' 대표적인 경우도 정리합니다.

연결, 트래픽 인계, 실제 적용은 각각 다른 문제

많은 사람이 이 세 단계를 한 덩어리로 생각하기에, 막상 문제를 찾으려면 어디서부터 손대야 할지 모릅니다. 실제로 이 셋은 서로 독립적입니다:

  • 터널 수립: 클라이언트와 노드가 핸드셰이크를 마칩니다. Shadowsocks, VMess, Trojan, VLESS는 보통 TCP나 WebSocket 같은 전송 위에서 동작하고, Hysteria2, TUIC는 QUIC 기반이라 하위 전송이 UDP입니다. 핸드셰이크 성공은 이 링크가 뚫렸다는 것만 뜻합니다.
  • 트래픽 인계: 클라이언트가 로컬 트래픽을 터널로 넘깁니다. TUN 모드는 모든 IP 트래픽을 인계하고, 시스템 프록시 모드는 프록시 설정을 읽는 앱에만 영향을 줍니다.
  • 출구 적용: 대상 사이트가 보는 출발지 주소가 로컬 통신사가 할당한 주소가 아니라 노드 주소입니다.

이 셋이 분리돼 있을 때 가장 흔한 착각은 '클라이언트는 멀쩡한데 웹페이지를 열면 여전히 로컬 결과가 나온다'입니다. 보통은 클라이언트가 거짓말을 하는 게 아니라, 인계 범위나 분할 규칙이 테스트한 대상까지 닿지 않기 때문입니다.

1단계: 출구 IP 확인

연결 전후로 한 번씩 조회하는 것이 가장 직접적인 판단 방법입니다. 브라우저에서 아무 IP 조회 페이지나 열면 주소와 소속 지역을 볼 수 있고, 명령줄은 출력이 깔끔하고 기록하기 쉬워 전후 비교에 더 적합합니다.

# 연결 전: 기준값 기록
curl -s https://api.ipify.org; echo

# 연결 후: 다시 조회
curl -s https://api.ipify.org; echo

# 출구 지역도 함께 확인
curl -s https://www.cloudflare.com/cdn-cgi/trace | grep -E '^(ip|loc)='

정상이라면 두 주소가 다르고, 두 번째 주소의 소속 지역이 선택한 노드와 일치합니다. 두 번 모두 같다면 먼저 분할 규칙이 이 조회 도메인을 직접 연결로 판정하지 않았는지 확인하고, 다음으로 현재 인계 모드가 시스템 프록시인지 확인하세요.

IPv6와 WebRTC, 자주 새는 두 지점

대부분의 터널은 기본적으로 IPv4만 인계합니다. 로컬 네트워크에 네이티브 IPv6가 있으면 IPv6를 지원하는 사이트에 접속할 때 로컬 주소로 그대로 나가는데, IPv4 검사 결과만 보면 모든 게 정상으로 보입니다. IPv6 출구를 따로 조회해 보세요. curl -6 -s https://api64.ipify.org 가 로컬 주소를 반환하면 IPv6가 인계되지 않은 것입니다.

브라우저에는 별도의 통로가 하나 더 있습니다. WebRTC는 프록시를 거치지 않고 로컬 주소를 얻어낼 수 있습니다. 확장 프로그램을 하나도 설치하지 않은 브라우저로 한 번 비교해 보거나, 브라우저 설정에서 WebRTC를 제한해 보면 문제가 여기서 비롯됐는지 판단할 수 있습니다.

명령줄 도구는 시스템 프록시를 읽지 않습니다. curl은 -x를 명시하거나 http_proxy / https_proxy 환경 변수를 설정해야 프록시를 탑니다. 그래서 시스템 프록시 모드에서 터미널이 조회한 주소가 브라우저와 다른 것은 정상 동작이며, TUN 모드로 바꾸면 둘이 일치해야 합니다.

2단계: DNS는 누가 처리하는지 확인

DNS는 도메인을 주소로 바꾸는 역할을 합니다. 트래픽은 터널로 가는데 조회는 여전히 로컬 통신사에 맡기면 두 가지 문제가 생깁니다. 접속 의도가 로컬 리졸버에 노출되고, 조회 결과가 로컬 위치를 기준으로 반환되어 가까운 노드를 받게 되므로 '이미 해외로 넘어갔다'는 기대가 어긋납니다.

확인 방법은 세 가지입니다:

  • 온라인 DNS 누출 테스트 페이지는 이번 조회에 실제로 사용된 리졸버를 보여 주므로 빠르게 훑어보기에 적합합니다.
  • Windows는 nslookup example.com, macOS와 Linux는 dig example.com을 실행해 반환되는 SERVER 항목이 어느 서버인지 확인합니다.
  • macOS에서는 scutil --dns로 시스템 리졸버의 우선순위를 확인해 기본으로 어느 쪽을 쓰는지 판단할 수 있습니다.

판단 기준은 '로컬 DNS가 나타났는지'가 아니라 '관심 있는 그 도메인을 누가 처리하는지'입니다. 분할 모드에서 국내 도메인은 로컬에서, 해외 도메인은 터널에서 조회하는 것이 애초에 설계 목표입니다. 국내 도메인까지 억지로 터널로 보내면 오히려 국내 사이트가 느려집니다.

분할 모드에서 로컬 리졸버가 보인다고 해서 누출은 아닙니다. 정말 확인해야 할 것은 해외 사이트에 접속할 때 그 조회 요청이 터널을 통해 나가는지입니다.

3단계: 앱별 검증

같은 노드라도 앱마다 인계 방식이 다릅니다. '브라우저에서 열리면 다 된 것'으로 보는 것이 문제 해결에서 가장 흔한 오판입니다.

  • 브라우저는 보통 시스템 프록시 설정을 읽기 때문에 가장 쉽게 통과하는 부류입니다.
  • 데스크톱 앱은 시스템 프록시를 읽는 것도 있고, TUN 모드에서만 동작하는 것도 있습니다.
  • 명령줄과 개발 도구는 대부분 시스템 프록시를 읽지 않아, 환경 변수나 TUN이 있어야 인계됩니다.
  • 모바일은 시스템 수준 VPN 구성이 인계하기 때문에 적용 범위가 가장 넓지만, 백그라운드 절전 정책이 연결을 끊어 버릴 수 있습니다.

검증 방법은 간단합니다. 같은 대상을 브라우저와 터미널에서 각각 한 번씩 접속해 출구 주소를 비교하세요. 양쪽이 같다면 인계 범위가 명령줄까지 닿은 것이고, 브라우저만 바뀌었다면 현재 시스템 프록시 모드이거나 분할 규칙이 터미널이 접속한 대상을 직접 연결로 판정한 것입니다.

플랫폼별 차이

Windows에서 TUN 모드는 가상 네트워크 어댑터를 설치해야 하므로 첫 연결 시 권한 확인이 뜹니다. macOS는 네트워크 확장을 허용해야 하고, 설치 후 보통 클라이언트를 다시 시작해야 적용됩니다. Linux에서 TUN은 root 권한이 필요하거나 바이너리에 CAP_NET_ADMIN 권한을 부여해야 하며, 그렇지 않으면 시스템 프록시만 쓸 수 있습니다. iOS와 Android는 시스템 VPN 프레임워크를 사용하므로 첫 연결 시 구성을 확인해야 하고, 클라이언트가 백그라운드에서 정리되면 연결이 끊겨 다시 열어야 합니다. 구독 가져오기 방식도 다릅니다. 데스크톱 클라이언트는 구독 링크를 붙여 넣은 뒤 노드 목록을 한 번 수동으로 갱신하고, 모바일은 대부분 한 번의 탭으로 가져오기가 끝납니다.

세 가지 점검 비교표

위 세 단계를 표 하나로 압축했습니다. 문제를 찾을 때 행 단위로 하나씩 대조하면 됩니다:

세 가지 점검의 판단 기준
점검 항목 확인 방법 정상 결과 의미
출구 IP IP 조회 페이지, curl 조회 API 연결 후 주소가 선택한 노드와 같은 지역 트래픽이 실제로 노드에서 나감
DNS 리졸버 누출 테스트 페이지, nslookup 또는 dig 해외 도메인 조회가 터널 안에서 이뤄짐 조회를 로컬 통신사에 넘기지 않음
앱별 인계 브라우저와 터미널에서 각각 한 번씩 접속 양쪽 출구 주소가 일치 인계 범위가 해당 앱까지 닿음

흔한 '가짜 연결' 사례

아래 경우들은 클라이언트 상태가 모두 '연결됨'이지만, 트래픽이 기대대로 해외 회선을 타지 않습니다:

  • ❌ 분할 규칙이 테스트 대상을 직접 연결로 판정해, 출구 주소가 처음부터 끝까지 바뀌지 않습니다.
  • ❌ 시스템 프록시는 켜져 있지만 테스트한 앱이 프록시 설정을 읽지 않아, 브라우저만 터널을 탑니다.
  • ❌ IPv4만 인계하고 로컬에는 네이티브 IPv6가 있어, IPv6를 지원하는 사이트는 여전히 로컬로 나갑니다.
  • ❌ 트래픽은 터널로 들어갔지만 DNS는 여전히 로컬 리졸버가 처리해, 조회 결과가 로컬 위치 기준으로 반환됩니다.
  • ❌ Hysteria2, TUIC처럼 QUIC 기반인 프로토콜은 네트워크에서 UDP를 제한하면 핸드셰이크 실패나 잦은 재연결로 나타나 '연결됐다가 잠시 뒤 끊긴다'처럼 보입니다.
  • ❌ 구독 링크가 만료됐거나 노드가 이미 내려갔는데 클라이언트에 예전 회선 이름이 남아 있어, 연결을 눌러도 재시도만 반복합니다.
  • ✅ 출구 주소가 노드 소재지로 바뀌고, 해외 도메인 조회가 터널 안에서 이뤄지고, 브라우저와 터미널 결과가 일치할 때 — 세 가지를 동시에 만족해야 실제로 통한 것입니다.

절차를 고정해 두기

회선을 바꿀 때, 프로토콜을 바꿀 때, 클라이언트를 바꿀 때마다 같은 순서로 한 번씩 훑는 편이 감으로 판단하는 것보다 훨씬 믿을 만합니다:

  1. 연결 전에 출구 주소와 리졸버를 한 번 기록해 기준값으로 삼습니다.
  2. 노드에 연결하고 선택한 지역과 프로토콜 이름을 적어 둡니다.
  3. 출구 주소를 다시 조회해 지역이 선택한 노드와 일치하는지 비교합니다.
  4. 해외 도메인 하나를 조회해 리졸버를 확인하고, 조회가 터널을 타는지 봅니다.
  5. 브라우저와 터미널에서 각각 한 번씩 테스트해 양쪽 결과를 비교합니다.
  6. 다른 회선이나 다른 프로토콜로 바꿔 다시 테스트해, 문제가 특정 회선 하나에 있는 것이 아님을 확인합니다.

결론: 세 가지를 모두 통과해야 VPN이 실제로 적용된 것입니다. 출구가 바뀌고, 조회가 터널을 타고, 테스트한 앱이 인계 범위에 들어와야 합니다. 하나만 만족한다면 먼저 분할 규칙과 인계 모드를 확인하고, 그다음에 회선 자체를 의심하세요.

검증한 뒤, 서비스 쪽에서 확인할 몇 가지

출구 주소는 선택한 회선에 따라 바뀌므로, 회선을 바꿔 재측정하는 비용이 낮을수록 문제를 빨리 찾을 수 있습니다. VPNAJ는 현재 120+ 국가, 180+ 회선을 제공하며 양자 암호화를 적용하고 동시 접속 대수 제한이 없어, 모바일과 노트북, 데스크톱에서 위 세 단계를 각각 돌려볼 수 있습니다. 가입에는 사용자 이름과 비밀번호만 필요하고 이메일 주소는 필요하지 않습니다.

120+ 국가 및 지역
180+ 선택 가능 회선
7일 이유 불문 환불
무제한 동시 접속 대수

회선 두세 개와 프로토콜 두 가지를 바꿔도 세 가지 점검이 통과되지 않는다면, 문제는 노드가 아니라 로컬 인계 방식에 있을 가능성이 큽니다. 이때는 먼저 TUN 모드로 되돌려 다시 테스트하고, 그다음에 클라이언트 재설치와 구독 링크 재가져오기를 고려하세요.

팁: 검증의 가치는 반복 가능성에 있습니다. 같은 명령, 같은 비교표라면 오늘도 통하고 다른 기기에서도 통하므로, 문제를 찾을 때 매번 처음부터 추측하지 않아도 됩니다.