클라이언트 아이콘이 초록색으로 바뀌고 상태가 '연결됨'으로 표시되는데도, 웹페이지를 열면 속도도 내용도 그대로인 경우가 있습니다. 이것이 'VPN은 연결됐지만 실제로는 적용되지 않은' 가장 전형적인 모습입니다. 문제는 대개 회선 자체가 아니라 트래픽이 정말 회선으로 들어갔는지에 있습니다. 시스템 프록시 모드는 프록시 설정을 읽는 앱에만 적용되고, 분할 규칙은 대상 도메인을 직결로 판정할 수 있으며, DNS 조회 역시 회선을 타지 않을 수 있습니다. 판단 방법은 복잡하지 않고 순서도 정해져 있습니다. 먼저 출구 IP를 확인하고, 다음으로 DNS를 확인하고, 마지막으로 앱별로 하나씩 검증하면 됩니다. 이 세 단계만 거치면 '연결된 것처럼 보이지만 실제로는 회선을 타지 않는' 대부분의 상황에서 원인을 특정할 수 있습니다.
왜 '연결됨'이 실제 적용은 아닐까
클라이언트와 회선 사이에 연결이 맺어졌다는 것은 제어 채널이 열렸다는 뜻일 뿐입니다. 노드 정보를 받았고, 인증을 통과했고, 하트비트도 정상이라는 의미입니다. 트래픽이 실제로 이 채널로 들어갔는지는 별개의 문제이며, 세 가지 변수에 달려 있습니다. 클라이언트의 동작 모드, 분할 규칙, 그리고 지금 사용 중인 앱이 프록시 설정을 읽는지 여부입니다.
흔히 쓰이는 동작 모드는 세 가지이며, 적용 범위 차이가 큽니다:
- 시스템 프록시 모드: 클라이언트가 운영체제의 프록시 설정(HTTP / SOCKS)을 수정하는 방식입니다. 이 설정을 직접 읽는 앱만 회선을 탑니다. 대부분의 브라우저는 읽지만, 터미널과 일부 데스크톱 프로그램, 게임 런처는 읽지 않습니다.
- TUN / 가상 네트워크 어댑터 모드: 클라이언트가 시스템에 가상 네트워크 어댑터를 만들고 라우팅 테이블을 장악해, 대부분 앱의 트래픽을 통째로 가져갑니다. 앱이 직접 프록시 설정을 읽을 필요가 없습니다.
- 전역 / 규칙 모드: '어떤 트래픽을 회선으로 보낼지'를 정하는 정책입니다. 전역 모드는 모든 요청을 회선으로 보내고, 규칙 모드는 도메인·IP 대역·지역 목록을 기준으로 하나씩 판정하며, 직결 규칙에 걸린 도메인은 회선을 거치지 않습니다.
따라서 '연결됨'은 필요조건일 뿐입니다. 실제로 적용됐는지 판단하려면 데이터를 봐야 합니다. 출구 IP가 바뀌었는지, DNS 조회가 어디를 거쳤는지, 각 앱이 받는 출처 주소가 무엇인지 확인해야 합니다.
같은 '적용 안 됨' 현상이라도 시스템 프록시 모드와 TUN 모드에서는 원인이 전혀 다릅니다. 클라이언트 설정을 열어 현재 어떤 모드인지 확인해야 이후 점검 방향이 잡힙니다.
출구 IP 확인: 연결 전후 주소 비교
출구 IP는 적용 여부를 판단하는 가장 직접적인 증거입니다. 트래픽이 회선을 타면 외부 사이트가 보는 출처 주소는 회선이 착지한 주소이고, 회선을 타지 않으면 여전히 집 인터넷이나 셀룰러망 주소입니다. 방법은 네 단계뿐입니다:
- 연결하기 전에 출처 주소를 보여주는 페이지를 열어 주소와 지역 정보를 기록해 둡니다.
- 회선에 연결하고 상태가 안정될 때까지 5~10초 기다린 뒤 작업합니다.
- 같은 페이지를 새로 고쳐 두 주소를 비교합니다.
- 다른 조회 서비스로 한 번 더 확인해 페이지 캐시로 인한 오판을 배제합니다.
| 비교 결과 | 설명 | 다음 단계 |
|---|---|---|
| 주소가 바뀌었고 지역 정보가 선택한 노드와 일치 | 데이터 채널이 정상 작동 중 | DNS와 앱 점검 계속 |
| 주소가 전혀 바뀌지 않음 | 현재 앱의 트래픽이 회선으로 들어가지 않음 | 동작 모드와 분할 규칙 확인 |
| 주소는 바뀌었지만 지역이 선택한 지역이 아님 | 입구와 착지 지점이 다른 지역일 수 있거나, 페이지에 CDN 엣지 주소가 표시된 경우 | 다른 조회 서비스로 교차 검증하고 클라이언트의 노드 상세 정보 확인 |
출구 IP와 회선 유형의 관계
직결·중계·IEPL 전용선이 바꾸는 것은 '로컬에서 착지 지점까지'의 경로입니다. 직결은 클라이언트가 해외 노드에 바로 접속해 공용 국제 회선을 이용하고, 중계는 먼저 중계 서버에 접속한 뒤 그것이 해외 착지 지점으로 포워딩하며, IEPL 전용선은 국제 이더넷 전용 회선을 이용해 공용 인터넷 출구를 거치지 않습니다. 세 가지가 영향을 주는 것은 지연과 패킷 손실의 안정성이고, 출구 IP는 착지 노드가 결정합니다. 노드를 바꾸면 출구 주소가 바뀌지만, 직결을 중계로 바꾼다고 해서 지역이 달라지지는 않습니다.
DNS 확인: 조회 요청이 어디로 가는지
도메인은 먼저 IP 주소로 해석되어야 연결이 맺어집니다. DNS 조회가 회선을 타지 않고 통신사 로컬 리졸버로 넘어가면 보통 두 가지 결과가 생깁니다. 접속 대상이 조회 단계에서 로컬 네트워크에 노출되고, 조회 결과가 가까우면서도 도달할 수 없거나 오염된 주소를 가리켜 '연결은 됐는데 페이지가 안 열리거나' '될 때와 안 될 때가 반복되는' 증상이 나타납니다.
확인 방법은 두 가지입니다:
- DNS 유출 테스트 페이지를 열어 나열된 리졸버를 확인합니다. 목록에 통신사 주소가 보이면 조회 요청이 회선을 타지 않은 것입니다.
- 명령줄로 확인합니다. Windows에서는
nslookup example.com을 실행하고, macOS / Linux에서는dig +short example.com을 실행합니다. macOS에서는scutil --dns로 현재 리졸버 순서를 확인할 수도 있습니다.
DNS가 회선을 타지 않는 세 가지 흔한 원인
- 브라우저가 자체적으로 보안 DNS(DNS over HTTPS)를 켠 경우. 브라우저가 DoH 서버에 직접 접속해 시스템 DNS를 우회하므로 클라이언트가 개입할 수 없습니다. 대처: 브라우저 설정에서 보안 DNS를 끄거나 '시스템 설정 따르기'로 변경합니다.
- 클라이언트가 TCP만 프록시하고 UDP 53을 장악하지 못한 경우. 대처: 클라이언트에서 DNS 장악 또는 원격 해석 관련 옵션을 켭니다.
- 분할 규칙이 DNS 요청을 직결로 판정한 경우. 대처: 규칙 목록을 확인해 DNS가 프록시를 따르도록 합니다.
로컬 네트워크에 IPv6 주소가 할당되어 있는데 회선이 IPv4만 프록시한다면, 일부 트래픽이 회선을 우회해 IPv6로 직결될 수 있습니다. 클라이언트에서 IPv6 지원을 켜거나, 시스템 IPv6를 잠시 끄고 다시 테스트하세요.
앱별 개별 검증: 브라우저가 된다고 터미널도 되는 것은 아니다
브라우저는 프록시가 가장 쉽게 적용되는 앱이라, 브라우저만 테스트하면 결론이 지나치게 낙관적이기 쉽습니다. 더 확실한 방법은 세 가지 대표 시나리오를 각각 한 번씩 테스트하는 것입니다.
- 브라우저: 출처 주소를 보여주는 페이지를 열어 주소가 선택한 노드의 지역과 일치하는지 확인합니다.
- 터미널: Windows 10 / 11에는 curl이 기본 포함되어 있으므로
curl https://api.ipify.org를 바로 실행합니다. PowerShell에서는Invoke-RestMethod https://api.ipify.org를, macOS / Linux에서는curl -s https://api.ipify.org를 사용합니다. - 데스크톱 프로그램과 모바일: 메일 클라이언트, 동기화 드라이브, 게임 런처는 대부분 시스템 프록시를 읽지 않으므로 앱 안에서 따로 설정하거나 TUN 모드에 의존해야 합니다. 스마트폰에서는 Wi-Fi와 셀룰러를 전환한 뒤 다시 한 번 확인해야 합니다.
터미널과 브라우저 결과가 다를 때
브라우저는 회선 주소를 보여주는데 터미널은 로컬 주소를 반환한다면, 현재 시스템 프록시 모드라는 뜻입니다. 터미널은 기본적으로 시스템 프록시를 읽지 않기 때문입니다. 대처는 두 가지입니다. 클라이언트의 TUN 모드를 켜서 라우팅 계층이 장악하게 하거나, 현재 터미널 세션에만 프록시를 임시로 지정합니다.
# 현재 터미널 세션에만 프록시를 지정합니다. 포트는 클라이언트 화면에 표시된 로컬 포트를 사용하세요
export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
# 출구 주소를 다시 확인합니다
curl https://api.ipify.orgWindows PowerShell에서의 해당 표기는 $env:https_proxy="http://127.0.0.1:7890"이며, 현재 창에서만 유효하고 창을 닫으면 사라집니다.
연결된 것 같지만 실제로는 미적용인 흔한 상황
아래 대조표는 초보자가 가장 자주 마주치는 몇 가지 상황을 정리한 것입니다. 점검 순서는 위에서 아래로 진행하는 것을 권합니다. 먼저 전체가 적용됐는지 확인하고, 그다음 개별 앱이나 개별 사이트의 예외를 처리하세요.
| 증상 | 가능한 원인 | 대처 방향 |
|---|---|---|
| 출구 IP가 전후 완전히 동일 | 클라이언트가 시스템 프록시 모드이고 현재 앱이 프록시 설정을 읽지 않음 | TUN 또는 전역 모드로 전환하거나 해당 앱에 별도 설정 |
| 브라우저는 정상인데 터미널이 로컬 주소를 반환 | 터미널은 기본적으로 시스템 프록시를 읽지 않음 | TUN 모드를 켜거나 http_proxy / https_proxy 환경 변수 설정 |
| 특정 사이트만 회선을 타지 않고 나머지는 정상 | 분할 규칙이 해당 도메인을 직결로 판정 | 클라이언트의 연결 로그와 규칙 매칭을 확인하고 해당 도메인을 프록시 목록에 추가 |
| 노드를 바꿨는데 출구 주소가 그대로 | 노드가 실제로 전환되지 않았거나 기존 연결이 아직 사용 중 | 연결을 끊고 다시 연결한 뒤 클라이언트에서 현재 선택된 노드 확인 |
| DNS 테스트 페이지에 통신사 리졸버가 나타남 | 브라우저 보안 DNS가 시스템 해석을 우회하거나 클라이언트가 DNS를 장악하지 못함 | 브라우저 보안 DNS를 끄고 클라이언트의 DNS 장악 기능 켜기 |
| 다른 프로토콜로는 연결되는데 기존 것은 연결되지 않음 | 네트워크 환경이 UDP 패킷을 버림 | TCP 전송이 가능한 프로토콜로 바꿔 비교 테스트 |
| 웹페이지는 열리는데 음성 통화는 여전히 로컬로 나감 | WebRTC 또는 앱 자체의 P2P 직결이 프록시를 우회 | 브라우저의 WebRTC를 끄거나 앱 안에서 직결을 제한 |
| 상태는 연결됨인데 실제로는 네트워크가 전혀 안 됨 | 시스템에 남은 예전 프록시 설정이 이미 종료된 프로그램 포트를 가리킴 | 시스템 프록시 설정을 확인해 자동으로 재설정하거나 끈 뒤 다시 연결 |
Hysteria2, TUIC 같은 프로토콜은 QUIC 기반이라 UDP에 의존합니다. Shadowsocks, VMess, Trojan, VLESS는 TCP 전송을 사용할 수 있습니다. '노드는 정상인데 연결이 안 될 때'는 전송 방식을 먼저 바꿔 보고, 그다음 노드 교체를 고려하세요. 회사 네트워크와 학교 네트워크가 UDP를 버리는 경우는 드물지 않습니다.
3단계 자가 점검 체크리스트와 결론
위 내용을 그대로 따라 할 수 있는 체크리스트로 압축했습니다. 네트워크 환경을 바꾸거나 노드를 교체한 뒤에는 매번 다시 실행해 보세요:
- ✅ 연결 전후로 출구 IP를 각각 확인하고, 주소가 바뀌었으며 지역이 선택한 노드와 일치한다.
- ✅ DNS 테스트 페이지에 나열된 리졸버 중 통신사 주소가 없다.
- ✅ 터미널
curl과 브라우저가 같은 출구 주소를 반환한다. 브라우저만 적용된 상태가 아니다. - ✅ 실제로 사용할 앱을 하나씩 열어 확인한다. 브라우저 첫 화면만 테스트하지 않는다.
- ✅ Wi-Fi와 셀룰러를 전환한 뒤에는 이전 결론을 그대로 쓰지 않고 다시 확인한다.
같은 구간에서 문제가 반복된다면, 예를 들어 저녁 피크 시간대에 패킷 손실이 계속되거나 UDP 계열 프로토콜이 장기간 차단된다면 클라이언트 설정만으로는 해결되지 않습니다. 회선 유형을 고려할 때입니다. VPNBF는 100+ 개 국가, 230+ 개 회선을 제공하며 IEPL 전용선과 중계 회선을 포함합니다. 회선 전 구간이 군사급 암호화로 보호되고, 동시 접속 대수 제한이 없으며, Windows / macOS / iOS / Android / Linux를 지원합니다. 가입에는 사용자 이름과 비밀번호만 있으면 되고 이메일 주소는 필요하지 않습니다. 7일 무조건 환불이 가능하고, 트래픽 패키지는 영구적으로 만료되지 않습니다.
- 100+국가 및 지역
- 230+선택 가능 회선
- 무제한동시 접속 대수
- 7일무조건 환불