네트워크 지식 약 8분

VPN 연결은 됐는데 작동하지 않나요? 외부 IP와 DNS를 확인하는 완벽한 검증 방법

연결됨으로 표시돼도 트래픽이 실제 경로를 이용한다는 뜻은 아닙니다. 외부 IP 위치, DNS 경로, 앱별 연결을 확인하고 연결된 것처럼 보이지만 적용되지 않는 대표적인 상황을 분석합니다.

VPN 작동 여부를 확인할 때 클라이언트의 ‘연결됨’ 표시만 봐서는 안 됩니다. 이 상태는 보통 클라이언트와 원격 서버의 핸드셰이크가 완료됐거나 로컬 프록시 포트가 시작됐다는 의미일 뿐입니다. 브라우저, 명령줄 도구 및 다른 앱의 트래픽이 모두 원하는 경로를 거친다는 증거는 아닙니다. 외부 IP, DNS 경로, IPv4와 IPv6, 앱별 실제 네트워크 경로를 함께 확인해야 정확하게 판단할 수 있습니다.

가장 실용적인 방법은 연결 전 기준값을 먼저 기록한 뒤, 연결 후 같은 테스트를 반복하는 것입니다. IP 조회 웹페이지 하나만 확인하면 브라우저 캐시, 분할 라우팅 규칙, 시스템 프록시, 앱 자체 네트워크 스택 때문에 결과가 달라질 수 있습니다. 아래에서는 재현하기 쉽고 문제 발생 계층을 찾는 데 유용한 전체 절차를 소개합니다.

먼저 ‘작동’의 기준을 정하세요: 연결 아이콘만 보지 않기

‘작동’ 여부는 서로 독립적인 여러 계층을 포함합니다. 터널 또는 프록시 세션이 구축됐는지, 대상 앱이 트래픽을 클라이언트에 전달하는지, 라우팅 또는 프록시 규칙이 예상 경로와 일치하는지, DNS 조회가 설정된 경로를 벗어나지 않는지, 외부 주소가 선택한 지역 또는 서버와 일치하는지를 확인해야 합니다. 어느 한 계층이라도 어긋나면 클라이언트에는 정상으로 표시되지만 웹페이지는 여전히 로컬 네트워크로 접속하는 현상이 나타날 수 있습니다.

확인 위치 확인할 수 있는 내용 이것만으로는 확인할 수 없는 내용
클라이언트에 연결됨으로 표시됨 로컬 클라이언트에서 세션 또는 프록시 서비스가 시작됨 모든 앱이 해당 세션을 사용함
외부 IP가 변경됨 현재 테스트 요청이 다른 출구를 통과함 DNS, IPv6 및 다른 앱도 같은 경로를 사용함
DNS 확인 주체가 변경됨 현재 테스트 도메인 조회가 예상 경로로 전달됨 모든 프로토콜과 앱에 우회 경로가 없음
대상 웹사이트에 정상적으로 접속됨 현재 웹사이트 요청이 완료됨 전체 경로 설정이 올바르거나 다른 대상도 이용 가능함

따라서 검증 과정에서 ‘통과’ 아이콘 하나만 찾기보다 서로 뒷받침되는 증거를 수집해야 합니다. 외부 IP는 ‘요청이 최종적으로 어디에서 인터넷에 진입했는지’를 보여주고, DNS 테스트는 ‘도메인을 누가 조회했는지’를 알려주며, 앱별 테스트는 ‘어떤 프로그램이 실제로 규칙을 적용받았는지’를 확인합니다. 결과를 함께 비교해야 경로 문제, 누락된 분할 라우팅, 앱 설정 오류를 구분할 수 있습니다.

판단 기준: 클라이언트 상태는 시작점일 뿐입니다. 외부 IP가 예상과 일치하고 DNS 경로가 합리적이며 앱별 결과가 일관될 때 전체 설정이 정상적으로 작동한다고 판단할 수 있습니다.

외부 IP 비교: 요청이 어디에서 나가는지 확인하기

외부 IP는 가장 직관적인 확인 항목입니다. 연결을 해제한 상태에서 신뢰할 수 있는 IP 조회 도구를 열고 공인 주소, 네트워크 정보, 대략적인 지역을 기록합니다. 그런 다음 페이지를 닫고 원하는 경로에 연결한 뒤 다시 조회합니다. VPNVR의 네트워크 테스트 페이지를 함께 사용해도 됩니다. 연결 전후 주소가 완전히 같다고 해서 반드시 실패한 것은 아니지만, 분할 라우팅 규칙과 시스템 프록시, 클라이언트 모드를 추가로 확인해야 하는 강한 신호입니다.

조회할 때 기존 페이지를 새로 고치는 것만으로 판단하지 마세요. 일부 웹페이지는 브라우저 캐시를 사용하고, 페이지의 테스트 스크립트가 네트워크 요청을 다시 보내지 않을 수도 있습니다. 새 시크릿 창을 열거나 별도의 프록시가 설정되지 않은 다른 브라우저로 교차 확인하는 편이 안전합니다. 두 브라우저의 외부 IP가 다르다면 문제는 대개 경로 자체가 아니라 브라우저 확장 프로그램, 프록시 설정 또는 앱별 분할 라우팅에 있습니다.

웹페이지 언어와 위치 결과는 Cookie, 계정 정보, 브라우저 언어, 시스템 시간대 또는 사이트 자체 캐시에서 비롯될 수 있으며 IP 위치와 같지 않습니다. 반대로 IP 데이터베이스에도 갱신 지연이 있을 수 있으므로 ‘도시 이름이 조금 다름’과 ‘외부 IP가 전혀 바뀌지 않음’은 별개의 문제입니다. 주소 대역, 네트워크 정보, 국가 또는 지역이 대체로 예상과 일치하는지에 초점을 맞춰 확인하세요.

명령줄을 사용한다면 공개 IP 에코 서비스에 요청을 보내 브라우저 결과와 비교할 수 있습니다. 명령줄 도구가 시스템 프록시를 따르는지는 운영체제, 환경 변수, 소프트웨어 구현에 따라 달라집니다. 이를 통해 현재 설정이 전체 터널인지, 시스템 프록시를 지원하는 앱만 적용되는지 판단할 수 있습니다.

curl https://example-ip-check.invalid
curl -4 https://example-ip-check.invalid
curl -6 https://example-ip-check.invalid

위 도메인은 명령 구조를 보여주기 위한 예시일 뿐이며, 실제 테스트에서는 신뢰할 수 있는 IP 에코 서비스로 바꿔야 합니다. IPv4와 IPv6를 각각 지정하는 이유는 어느 프로토콜이 더 빠른지 비교하기 위해서가 아니라 듀얼 스택 네트워크의 우회 경로를 찾기 위해서입니다.

DNS 경로 확인: 조회 요청이 우회되는지 파악하기

도메인에 접속하기 전 시스템은 보통 도메인 이름을 주소로 변환해야 합니다. 웹 트래픽은 원하는 경로를 통과하지만 DNS 조회는 로컬 네트워크의 기본 확인 서버로 전달된다면, 테스트 페이지에는 외부 IP가 바뀐 것으로 표시되어도 DNS 확인 주체는 기존 네트워크에 속할 수 있습니다. 이를 흔히 DNS 누출이라고 합니다. 웹사이트 본문이 반드시 경로를 우회한다는 뜻은 아니지만, 도메인 조회와 웹 연결이 동일한 예상 경로를 사용하지 않는다는 의미입니다.

테스트할 때는 무작위 하위 도메인을 여러 개 조회할 수 있는 DNS 테스트 도구를 사용하세요. 무작위 도메인은 운영체제, 브라우저, 로컬 캐시의 영향을 줄여줍니다. 결과를 볼 때 확인 서버에 표시된 도시만 보지 마세요. 공용 DNS는 가까운 서버로 연결될 수 있기 때문입니다. 대신 확인 서비스 제공자가 설정과 일치하는지, 연결 해제와 연결 상태에서 결과가 합리적으로 달라지는지에 주목하세요.

DNS 결과가 이상할 때 확인하는 방법

  1. 브라우저 DNS 캐시와 시스템 DNS 캐시를 삭제한 다음 무작위 도메인 테스트를 다시 실행합니다.
  2. 클라이언트에서 원격 DNS, 가상 네트워크 어댑터 인계 또는 DNS 가로채기 기능을 활성화했는지 확인합니다.
  3. 분할 라우팅 규칙이 웹 연결만 프록시로 보내고 DNS 요청은 직접 연결로 남겨두지 않았는지 확인합니다.
  4. 브라우저에서 별도의 암호화 DNS를 사용하고 있는지 확인한 뒤 시스템 설정과 따로 테스트합니다.
  5. 다른 네트워크에서 다시 테스트해 현재 라우터가 DNS를 강제로 변경하는 영향을 배제합니다.

프록시 프로토콜과 DNS 처리 방식은 별개의 문제입니다. Shadowsocks, VMess, Trojan, VLESS, Hysteria2 및 TUIC은 서로 다른 형태의 프록시 트래픽을 전달할 수 있지만, DNS를 로컬에서 조회할지 원격에서 조회할지는 클라이언트, 실행 모드 및 규칙 설정에 따라 결정됩니다. 노드의 프로토콜 이름만으로 DNS가 반드시 원격으로 전달된다고 판단할 수는 없습니다.

규칙 모드에서는 클라이언트가 도메인에 따라 직접 연결과 프록시 연결을 선택하는 방식이 일반적입니다. 도메인이 규칙 판단 전에 로컬 네트워크에서 조회되면 DNS 기록이 로컬 DNS에 노출될 수 있습니다. 클라이언트가 DNS를 인계받아 원격에서 조회하면 도메인 판단과 이후 연결을 동일한 정책으로 처리할 수 있습니다. 클라이언트마다 용어가 다를 수 있으므로 다른 플랫폼의 설정을 그대로 따라 하기보다 DNS, 스니핑, 가상 네트워크 어댑터 및 규칙 모드 설명을 확인하세요.

IPv4와 IPv6를 각각 확인: 듀얼 스택 우회 경로 배제하기

현대 네트워크에서는 IPv4와 IPv6를 동시에 제공할 수 있습니다. 일부 클라이언트가 IPv4만 인계받는 상태에서 시스템이 듀얼 스택 웹사이트에 IPv6로 우선 접속하면 테스트 페이지에 경로의 외부 IP와 로컬 네트워크가 번갈아 표시될 수 있습니다. 이런 문제를 노드 불안정으로 오해하기 쉽지만, 실제 원인은 두 주소 프로토콜이 서로 다른 라우팅을 사용하기 때문입니다.

IPv4와 IPv6의 외부 경로를 각각 테스트하세요. IPv4는 원하는 경로로 바뀌었지만 IPv6가 로컬 네트워크로 표시된다면 클라이언트의 IPv6 인계 지원 여부, 가상 네트워크 어댑터의 해당 경로 확보 여부, 규칙의 IPv6 적용 여부를 확인해야 합니다. 현재 서비스나 클라이언트가 IPv6를 처리하지 않는다면 영향을 충분히 이해한 뒤 시스템 네트워크 설정을 조정할 수 있습니다. 가장 안전한 방법은 듀얼 스택 트래픽을 완전히 인계받는 실행 모드를 사용하는 것입니다.

테스트 현상 가능한 원인 우선 확인할 항목
IPv4는 변경되고 IPv6는 변경되지 않음 클라이언트가 IPv4만 인계받거나 IPv6 경로가 없음 가상 네트워크 어댑터, 듀얼 스택 지원, 라우팅 테이블
브라우저 결과가 번갈아 바뀜 사이트의 듀얼 스택 연결 선택이 다름 두 주소 프로토콜을 각각 강제 테스트
둘 다 변경되지 않음 앱이 프록시에 들어가지 않았거나 터널이 트래픽을 인계받지 못함 시스템 프록시, TUN 모드, 분할 라우팅 규칙
둘 다 변경됐지만 DNS는 변경되지 않음 데이터 연결은 프록시되지만 조회는 로컬 경로를 사용함 원격 DNS, 브라우저 보안 DNS, 캐시

IPv6를 끄는 것이 항상 정답은 아닙니다. 우회 경로를 일시적으로 없앨 수 있지만 IPv6에 의존하는 로컬 네트워크 환경에 영향을 줄 수 있습니다. 문제를 찾는 동안에는 별도 테스트로 범위를 확인하고, 장기적으로는 클라이언트가 듀얼 스택을 올바르게 처리하도록 설정하거나 인계받지 못한 트래픽이 기기 밖으로 나가지 않게 명확히 차단하는 편이 좋습니다.

앱별로 테스트: 브라우저에 적용돼도 전체 시스템에 적용된 것은 아님

시스템 프록시 모드는 보통 시스템 프록시 설정을 직접 읽는 소프트웨어에만 영향을 줍니다. 브라우저는 대체로 이를 따르지만 일부 게임, 명령줄 프로그램, 다운로드 도구 및 자체 네트워크 스택을 사용하는 앱은 직접 연결을 만들 수 있습니다. TUN 또는 가상 네트워크 어댑터 모드는 시스템 수준의 라우팅 인계에 가깝지만 제외 규칙, 로컬 네트워크 우회 및 앱별 분할 라우팅의 영향을 여전히 받습니다.

따라서 여러 유형의 앱을 따로 확인해야 합니다. 브라우저에서는 외부 IP 조회 페이지를 열고, 명령줄 도구에서는 에코 서비스에 요청하며, 대상 앱에서는 자체 서비스를 이용해 보세요. UDP를 지원하는 프로그램은 연결 가능 여부도 확인해야 합니다. 브라우저만 작동한다면 시스템 프록시의 적용 범위를 우선 확인하고, 브라우저와 명령줄은 작동하지만 특정 앱만 예외라면 앱 내부 프록시, 우회 목록 및 클라이언트 프로세스 규칙을 확인하세요.

플랫폼별 일반적인 차이

구독 링크를 성공적으로 가져왔다고 해서 시스템 트래픽까지 인계된 것은 아닙니다. 구독은 서버 주소, 포트, 프로토콜 및 일부 매개변수를 클라이언트에 전달할 뿐입니다. 사용자는 노드를 선택하고 연결을 시작한 뒤 필요에 따라 규칙, 전체 또는 TUN 모드를 선택해야 합니다. 가져온 뒤 노드 목록만 보이고 세션이 구축되지 않았다면 외부 IP가 바뀌지 않는 것이 정상입니다.

흔한 가짜 연결 분석: 현상에서 설정 계층으로 거슬러 올라가기

클라이언트에는 연결됨으로 표시되지만 외부 IP가 전혀 바뀌지 않음

먼저 클라이언트가 로컬 프록시 포트만 시작한 상태인지 확인하세요. 앱이 수동 프록시 모드로 실행되고 브라우저가 시스템 프록시를 읽지 않는다면 트래픽은 계속 직접 전송됩니다. 다음으로 다른 소프트웨어가 시스템 프록시를 덮어쓰지 않았는지, TUN 모드에 필요한 권한이 있는지 확인합니다. 마지막으로 분할 라우팅 규칙을 점검하세요. 대상 도메인이나 주소가 직접 연결 규칙에 잘못 매칭됐을 수 있습니다.

외부 IP는 바뀌었지만 대상 웹사이트가 여전히 기존 지역으로 인식함

웹사이트는 IP만으로 지역을 판단하지 않을 수 있습니다. 계정 지역, Cookie, 위치 권한, 언어 및 시간대를 함께 참고하기도 합니다. 먼저 로그아웃한 시크릿 창에서 다시 테스트한 뒤 외부 IP 데이터베이스 결과를 확인하세요. 여러 IP 조회 도구가 모두 원하는 지역을 가리키는데 특정 사이트만 이상하다면 터널보다 사이트 캐시나 계정 속성 때문일 가능성이 높습니다.

연결 직후에는 정상인데 잠시 후 로컬 출구로 돌아감

이는 대개 클라이언트 프로세스가 시스템에 의해 일시 중지됐거나, 가상 네트워크 어댑터 재생성에 실패했거나, 무선과 유선 네트워크가 전환됐거나, 경로가 끊긴 뒤 자동으로 직접 연결로 돌아간 경우와 관련이 있습니다. 클라이언트 로그에서 재연결 기록을 확인하고, 연결 끊김 차단 또는 주문형 연결이 활성화됐는지 점검한 뒤 네트워크 전환 후 라우팅을 다시 테스트하세요. 화면에 남아 있는 연결 상태만 믿지 마세요.

일부 웹사이트는 정상인데 일부 웹사이트는 열리지 않음

반드시 ‘VPN 전체가 작동하지 않는’ 상황은 아닙니다. DNS가 연결할 수 없는 주소를 반환했거나, 규칙 집합이 관련 도메인을 서로 다른 경로로 나눴거나, 현재 모드에서 UDP를 처리하지 못했거나, 대상 사이트가 해당 출구를 거부했을 수 있습니다. 먼저 실패한 사이트의 DNS 결과를 비교한 다음 기본 도메인, 정적 리소스 도메인 및 API 도메인이 같은 정책에 매칭되는지 확인하세요.

점검 순서: 먼저 개별 요청의 외부 경로를 확인하고 DNS와 듀얼 스택을 점검한 뒤 앱별 차이와 대상 웹사이트 정책을 살펴보세요. 계층별로 확인하는 편이 노드를 계속 바꾸는 것보다 근본 원인을 찾기 쉽습니다.

경로 및 프로토콜 태그는 실제 검증을 대신할 수 없습니다

직접 연결, 중계 및 IEPL 전용 회선은 경로 구성 방식을 설명할 뿐 브라우저에서 정상 작동한다는 증거가 아닙니다. 직접 연결은 일반적으로 사용자 네트워크가 원격 진입점에 바로 연결되는 방식이고, 중계는 중간 노드에 먼저 접속한 뒤 출구로 전달하는 방식입니다. IEPL 전용 회선은 전용 회선 구간을 포함한 국제 전송 방식을 설명할 때 사용됩니다. 어떤 방식을 사용하든 외부 IP, DNS 및 앱별 경로를 통해 트래픽이 실제로 어디로 이동했는지 확인해야 합니다.

프로토콜 태그 역시 테스트를 대신할 수 없습니다. Shadowsocks, VMess, Trojan, VLESS는 일반적인 프록시 방식이며 Hysteria2와 TUIC은 UDP 기반 전송 설계를 강조합니다. 해당 프로토콜 지원 여부, 매개변수 일치, UDP 사용 가능 여부, DNS 처리 방식 및 규칙 매칭이 모두 최종 결과에 영향을 줍니다. 프로토콜 핸드셰이크가 성공했다는 것은 연결 경로의 일부가 성립했다는 뜻일 뿐입니다.

같은 구독이 한 클라이언트에서는 정상이고 다른 클라이언트에서는 이상하다면 프로토콜 지원, 전송 매개변수, TLS 설정, 구독 파싱 결과 및 실행 모드를 비교하세요. 서로 다른 클라이언트에서 이름이 비슷한 옵션을 그대로 복사하지 마세요. ‘전체’, ‘규칙’, ‘로컬 네트워크 우회’와 같은 용어의 실제 구현은 클라이언트마다 다를 수 있습니다.

최종 검증 체크리스트: 결과를 다시 테스트할 수 있는 기록으로 남기기

점검을 마친 뒤 사용한 네트워크, 클라이언트, 실행 모드, 노드 지역, 외부 네트워크 정보, DNS 결과 및 문제가 발생한 앱을 간단히 기록해 두는 것이 좋습니다. 다음에 네트워크 환경이나 클라이언트 버전이 바뀌어도 연결 아이콘만 보고 다시 추측하지 않고 같은 절차로 재검증할 수 있습니다.

모든 앱의 외부 IP가 바뀌지 않았다면 문제는 대개 시스템 인계 또는 프록시 설정 계층에 있습니다. 외부 IP는 바뀌었지만 DNS가 그대로라면 조회 경로를 집중적으로 확인해야 합니다. 특정 앱만 이상하다면 해당 앱이 시스템 프록시를 우회하는지 점검하세요. 주소 프로토콜별 결과가 다르면 듀얼 스택 라우팅으로 돌아가 확인해야 합니다. 이 순서대로 진행하면 ‘연결됐지만 작동하지 않는’ 문제를 명확하고 해결 가능한 설정 문제로 좁힐 수 있습니다.

네트워크 가속 시작