VPN이 실제로 작동하는지 확인할 때 클라이언트의 ‘연결됨’ 표시만 봐서는 충분하지 않습니다. 이 상태는 보통 클라이언트와 원격 회선 사이의 핸드셰이크가 완료되었다는 뜻일 뿐, 브라우저, 데스크톱 프로그램, 명령줄 도구와 DNS 조회가 모두 예상한 경로를 통과한다는 의미는 아닙니다. 신뢰할 수 있는 확인 방법은 외부 IP, DNS 조회, 라우팅 모드와 실제 앱을 차례로 점검하고 연결 전후 결과를 함께 비교하는 것입니다.
외부 주소는 바뀌었지만 특정 앱에 이전 네트워크 위치가 계속 표시된다면, 문제는 대개 회선 핸드셰이크가 아니라 시스템 프록시, TUN 모드, 분할 라우팅 규칙, 캐시된 연결 또는 앱 자체의 네트워크 구현에 있습니다. 반대로 페이지가 정상적으로 열리더라도 모든 요청이 회선을 통과한다고 단정할 수 없습니다. 규칙 모드에서는 특정 도메인만 전달하고 나머지 트래픽은 로컬 네트워크로 직접 연결할 수 있습니다.
먼저 ‘작동한다’는 것이 무엇을 포함하는지 이해하기
VPN 작동 여부는 단순한 하나의 스위치가 아닙니다. 완전한 연결에는 최소한 회선 핸드셰이크, 시스템 라우팅, 이름 조회와 앱 트래픽이 포함됩니다. 어느 한 계층이라도 예상대로 작동하지 않으면 화면에는 정상적으로 표시되지만 실제 경로는 다를 수 있습니다.
| 확인 대상 | 확인해야 할 결과 | 일반적인 문제 |
|---|---|---|
| 클라이언트 상태 | 설정이 로드되고 회선 핸드셰이크가 완료되며 반복적인 재연결이 없음 | 구독 만료, 노드 연결 불가, 시스템 시간 오류 또는 프로토콜 매개변수 불일치 |
| 외부 IP | 연결 후 공인 외부 IP가 연결 전과 다르고 선택한 지역과 일치함 | 앱이 프록시 우회, 규칙이 직접 연결로 처리, 기존 연결이 해제되지 않음 |
| DNS 조회 | 조회 요청이 클라이언트에 설정된 로컬, 원격 또는 암호화 DNS 정책에 맞게 처리됨 | 시스템 캐시, 브라우저의 독립 조회, 로컬 네트워크 조회기가 계속 처리함 |
| 특정 앱 | 회선을 사용해야 하는 앱이 실제로 해당 외부 IP를 사용함 | 앱이 시스템 프록시를 읽지 않음, 일부 프로토콜만 처리됨, 앱별 규칙 설정 오류 |
| 프로토콜 및 주소 체계 | TCP, UDP, IPv4와 IPv6가 현재 설정에 따라 처리됨 | 한 종류의 트래픽만 처리되고 다른 종류는 로컬 네트워크로 전송됨 |
클라이언트마다 이러한 계층을 제어하는 능력은 다릅니다. 데스크톱에서 흔히 사용하는 ‘시스템 프록시’는 주로 운영체제의 프록시 설정을 변경하며, 해당 설정을 읽는 앱만 이를 따릅니다. TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅 테이블을 통해 더 광범위한 네트워크 트래픽을 처리하므로 프록시 설정을 지원하지 않는 소프트웨어에 더 적합하지만, 일반적으로 관련 시스템 권한이 필요합니다.
모바일 클라이언트는 일반적으로 시스템이 제공하는 VPN 인터페이스를 사용해 트래픽을 통합 처리합니다. 그러나 앱별 제외, 주문형 연결, 프라이빗 DNS 또는 앱 내 암호화 DNS의 영향을 받을 수 있습니다. 따라서 동일한 Shadowsocks, VMess, Trojan, VLESS, Hysteria2 또는 TUIC 설정이라도 플랫폼에 따라 ‘연결됨’ 상태가 의미하는 처리 범위는 완전히 같지 않을 수 있습니다.
외부 IP를 확인하는 올바른 순서
외부 IP는 가장 직관적인 확인 방법이지만, 신뢰할 수 있게 비교하려면 먼저 연결되지 않은 상태를 기록해야 합니다. 연결 후 조회 페이지를 열어 낯선 주소가 보인다는 것만으로는 현재 회선의 결과라고 입증하기 어렵습니다. 기업 네트워크, 공유 네트워크와 상위 프록시 자체로 인해 공인 주소와 기기의 로컬 네트워크 주소가 다를 수도 있습니다.
- 클라이언트 연결을 끊습니다. 기존 연결을 완전히 종료하고 자동으로 재연결될 수 있는 주문형 규칙을 해제합니다.
- 기준값을 기록합니다. 현재 공인 외부 IP, 네트워크 제공업체와 대략적인 지역을 확인하되, 전체 주소를 공개 스크린샷에 포함하지 않습니다.
- 다시 연결합니다. 구분하기 쉬운 지역 회선을 선택하고 클라이언트 상태가 안정될 때까지 기다립니다.
- 새 세션을 만듭니다. 기존 페이지, 캐시와 지속 연결의 영향을 피하기 위해 새 브라우저 시크릿 창을 사용합니다.
- 다시 조회합니다. 외부 주소, 지역과 네트워크 소속이 회선 변경에 따라 달라졌는지 비교합니다.
- 회선을 바꿔 재확인합니다. 다른 회선 그룹으로 전환한 뒤 페이지를 다시 로드해 결과가 조회 페이지 캐시 때문이 아닌지 확인합니다.
- ✅ 연결 전후 외부 주소가 다르고 지역이 선택한 회선과 일치한다면 DNS와 앱 트래픽을 계속 확인합니다.
- ✅ 브라우저와 시스템 네트워크 도구에서 같은 외부 IP가 확인되면 처리 범위가 비교적 일관적이라는 뜻입니다.
- ❌ 주소가 전혀 바뀌지 않는다면 현재 규칙에서 조회 도메인을 직접 연결로 지정했는지 확인해야 합니다.
- ❌ 브라우저에서만 주소가 바뀌고 다른 소프트웨어는 그대로라면, 일반적으로 전체 트래픽 처리가 아니라 시스템 프록시를 사용 중이라는 의미입니다.
- ❌ 회선을 바꾼 뒤에도 이전 지역이 표시된다면 페이지 캐시, 연결 재사용 또는 기존 프로세스가 종료되지 않은 문제일 수 있습니다.
IPv4와 IPv6도 각각 확인해야 합니다. 일부 로컬 네트워크는 두 주소를 모두 제공하지만 클라이언트가 IPv4만 처리할 수 있습니다. 이 경우 일반적인 조회에서는 외부 IP가 바뀐 것처럼 보여도 IPv6를 지원하는 앱은 여전히 로컬 경로를 우선 사용할 수 있습니다. 단순히 모든 네트워크 기능을 끄기보다는 먼저 클라이언트가 IPv6 처리를 지원하는지 확인해야 합니다. 지원하지 않는다면 클라이언트 문서에 따라 비활성화하거나 차단하거나 규칙으로 처리합니다.
DNS 조회가 예상대로 처리되는지 확인하기
브라우저가 도메인에 접속하기 전에는 일반적으로 도메인을 IP 주소로 변환하는 조회가 필요합니다. DNS 유출은 회선 내부의 조회기나 지정된 암호화 조회기로 보내야 하는 요청이 로컬 네트워크가 제공하는 조회 서비스로 계속 전송되는 상황을 가리킵니다. 이 문제가 있다고 해서 반드시 웹페이지가 열리지 않는 것은 아니지만, 조회한 도메인의 범위가 노출되고 회선 지역과 맞지 않는 조회 결과가 발생할 수 있습니다.
DNS 이상 여부를 판단할 때는 검사 페이지에 표시된 조회기 이름만 봐서는 안 됩니다. 최신 클라이언트는 공용 DNS, DoH, DoT, 원격 조회 또는 도메인별 분할 라우팅을 사용할 수 있으며, 브라우저가 자체 보안 DNS를 활성화했을 수도 있습니다. 이러한 결과가 외부 IP의 네트워크와 같지 않다고 해서 반드시 문제가 있는 것은 아닙니다. 실제로 확인해야 할 것은 결과가 현재 설정과 일치하는지이지, 조회기 이름이 외부 IP와 완전히 같은지가 아닙니다.
해석 가능한 DNS 결과 만들기
먼저 클라이언트의 DNS 설정을 열어 현재 정책을 확인합니다. 시스템 조회인지, 원격 회선을 통한 조회인지, 지정된 암호화 DNS를 사용하는지, 아니면 도메인 규칙에 따라 각각 처리하는지 확인합니다. 그런 다음 기존 캐시를 삭제하고 조회를 다시 실행합니다. 데스크톱 운영체제마다 해당 캐시를 갱신하는 명령을 사용할 수 있습니다.
Windows:
ipconfig /flushdns
macOS:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
Linux with systemd-resolved:
resolvectl flush-caches시스템 캐시를 갱신한 뒤에는 브라우저도 완전히 종료했다가 다시 열어야 합니다. 브라우저가 독립적인 캐시와 연결 풀을 유지할 수 있기 때문입니다. 브라우저에서 자체 암호화 DNS를 활성화했다면 시스템 명령으로 모든 상태가 삭제되지 않으므로 브라우저 네트워크 설정에서 조회 정책을 확인해야 합니다.
- ✅ 조회기가 클라이언트 설정과 일치하고 설정을 바꿀 때 조회 결과도 달라집니다.
- ✅ 로컬 도메인은 로컬 규칙으로 조회하고 국제 도메인은 원격 규칙으로 조회해 분할 라우팅 설계와 일치합니다.
- ❌ 클라이언트는 원격 조회로 설정했지만 검사 결과에는 계속 로컬 네트워크 조회기만 표시됩니다.
- ❌ 브라우저와 명령줄의 조회 결과가 장기간 다르다면 브라우저의 독립 DNS 설정을 확인해야 합니다.
- ❌ 회선을 바꾼 뒤에도 도메인이 명백히 오래된 주소를 반환한다면 시스템, 브라우저와 앱 캐시를 삭제해야 합니다.
분할 DNS는 하나의 조회 경로보다 복잡합니다. 예를 들어 로컬 도메인은 로컬 조회기가 처리한 뒤 직접 접속하고, 다른 도메인은 원격 조회 후 회선을 통과할 수 있습니다. 이런 경우 검사 페이지에 서로 다른 출처의 조회 요청이 함께 표시된다고 해서 반드시 유출을 의미하지는 않습니다. 중요한 것은 규칙이 예상대로 작동하는지, 원격 조회가 필요한 도메인이 잘못 로컬로 전송되지 않는지입니다.
앱별로 트래픽 경로 확인하기
외부 IP와 DNS가 모두 정상이라면 다음 단계는 실제로 사용하는 소프트웨어를 하나씩 확인하는 것입니다. 브라우저가 회선을 사용한다고 해서 게임, 다운로드 도구, 터미널, 동기화 도구와 데스크톱 클라이언트도 같은 프록시 설정을 읽는 것은 아닙니다. 특히 시스템 프록시 모드에서는 일부 앱이 운영체제 프록시를 완전히 무시하고 직접 연결할 수 있습니다.
브라우저
브라우저는 대개 확인하기 가장 쉽지만 확장 프로그램, 독립 프록시 설정, 보안 DNS와 연결 재사용의 영향을 받기도 쉽습니다. 점검할 때는 먼저 네트워크 경로를 변경하는 확장 프로그램을 비활성화한 뒤 새 시크릿 창에서 테스트합니다. 한 브라우저는 정상이고 다른 브라우저는 비정상이라면 노드를 바로 바꾸기보다 두 브라우저의 프록시와 DNS 설정을 비교해야 합니다.
명령줄 및 개발 도구
명령줄 도구가 프록시를 사용하는지는 도구 자체, 환경 변수와 시스템 구현에 따라 달라집니다. 일부 도구는 프록시 환경 변수를 읽고, 일부는 프록시를 명시적으로 지정해야 하며, 또 다른 도구는 TUN 모드에서만 투명하게 처리됩니다. 테스트할 때는 클라이언트 연결 로그도 함께 확인해 요청이 프록시 규칙, 직접 연결 규칙 또는 차단 규칙에 해당하는지 확인해야 합니다.
데스크톱 소프트웨어 및 모바일 앱
데스크톱 소프트웨어는 자체 네트워크 스택을 사용할 수 있고, 모바일 앱도 독립적인 QUIC 또는 다른 UDP 세션을 만들 수 있습니다. 현재 노드 프로토콜이나 클라이언트 모드가 TCP만 처리한다면 관련 요청은 계속 직접 연결되거나 아예 실패할 수 있습니다. Hysteria2와 TUIC는 UDP를 기반으로 전송하지만, 이러한 프로토콜을 활성화했다고 해서 모든 앱의 UDP가 반드시 처리되는 것은 아닙니다. 앱 트래픽이 터널에 들어가는지는 여전히 클라이언트 라우팅과 TUN 설정에 따라 결정됩니다.
앱별 규칙 및 우회 설정
일부 클라이언트에서는 어떤 앱이 회선을 사용하고 어떤 앱이 직접 연결을 유지할지 지정할 수 있습니다. 점검할 때는 ‘포함’ 목록과 ‘제외’ 목록을 모두 확인하고, 앱 업데이트 후 실행 파일 경로나 패키지 식별자가 바뀔 수 있다는 점에 유의해야 합니다. 규칙이 이전 경로를 계속 참조하면 새 버전 프로그램이 기존 정책에 더 이상 해당하지 않을 수 있습니다.
| 현상 | 우선 확인할 항목 | 처리 방향 |
|---|---|---|
| 브라우저는 정상이고 터미널은 직접 연결됨 | 시스템 프록시, 프록시 환경 변수, TUN 모드 | 도구에 프록시를 설정하거나 해당 트래픽을 처리할 수 있는 모드로 변경 |
| 웹페이지는 정상이나 앱 내부 요청이 실패함 | UDP, QUIC, 인증서 검증, 앱별 규칙 | 프로토콜 지원 여부와 앱이 제외되었는지 확인 |
| 일부 웹사이트만 회선을 사용하고 일부는 직접 연결됨 | 규칙 모드, 도메인 분류, 프로세스 규칙 | 규칙 적중 로그를 확인해 의도한 분할 라우팅인지 판단 |
| 노드를 바꿔도 앱에 이전 외부 IP가 표시됨 | 지속 연결, 백그라운드 프로세스, 연결 풀 | 앱을 완전히 종료한 뒤 다시 열고, 필요하면 네트워크 연결을 끊었다가 다시 연결 |
| IPv4는 정상이나 IPv6는 로컬 외부 IP를 유지함 | 클라이언트의 주소 체계 지원, 시스템 라우팅 | 해당 처리 기능을 활성화하거나 설정에 따라 보호되지 않은 경로를 차단 |
연결됨으로 표시되지만 트래픽이 회선을 사용하지 않는 이유
가장 흔한 원인은 클라이언트가 노드와의 연결만 만들고 시스템 프록시나 라우팅을 제대로 변경하지 못한 경우입니다. 권한 부족, 가상 네트워크 어댑터 초기화 실패, 다른 네트워크 도구가 설정을 덮어쓰는 상황으로 인해 제어 계층은 온라인이지만 데이터 계층은 처리되지 않을 수 있습니다. 이때는 연결 버튼을 반복해서 누르기보다 먼저 클라이언트 로그를 확인해야 합니다.
시스템 프록시와 TUN 모드 선택 오류
브라우저와 프록시를 지원하는 소프트웨어만 사용한다면 시스템 프록시가 일반적으로 더 간단합니다. 프록시 설정을 읽지 않는 앱까지 처리해야 한다면 TUN 모드가 더 적합합니다. 두 방식은 속도 단계가 아니라 서로 다른 트래픽 진입점입니다. TUN을 활성화한 뒤에도 가상 인터페이스가 생성되었는지, 기본 경로 또는 정책 경로가 등록되었는지 확인해야 합니다.
분할 라우팅 규칙이 직접 연결로 처리함
규칙 모드는 도메인, IP, 프로세스 또는 규칙 세트에 따라 경로를 결정합니다. 외부 IP를 확인하는 웹사이트가 직접 연결로 분류되어 있다면 검사 결과가 바뀌지 않는 것이 당연합니다. 점검할 때 전체 프록시로 전환하는 것은 짧은 비교 테스트로만 활용해야 합니다. 전체 모드에서 정상이라면 회선 자체는 대체로 사용할 수 있고 문제가 규칙에 집중되어 있다는 뜻입니다. 확인이 끝나면 필요한 분할 라우팅 모드로 되돌려야 합니다.
기존 연결이 해제되지 않음
브라우저, 메신저와 동기화 도구는 지속 연결을 유지합니다. 회선을 바꿔도 이러한 연결이 즉시 새로 만들어진다고 보장할 수 없으므로 앱이 잠시 이전 경로를 계속 사용할 수 있습니다. 페이지를 새로 고치는 것보다 앱을 완전히 종료한 뒤 다시 여는 방법이 더 확실합니다. 백그라운드 상주 프로세스도 실제로 종료되었는지 확인해야 합니다.
여러 네트워크 도구가 설정을 서로 덮어씀
기업용 VPN, 디버깅 프록시, 네트워크 필터링 소프트웨어 또는 다른 클라이언트가 동시에 실행되면 나중에 기록된 라우팅과 프록시 설정이 이전 설정을 덮어쓸 수 있습니다. 점검 단계에서는 필요한 도구만 남기고 네트워크 경로를 변경하는 다른 프로그램을 일시 중지한 뒤 하나씩 다시 활성화해 충돌 원인을 찾아야 합니다.
구독 설정이 업데이트되지 않음
구독 링크는 클라이언트에 노드와 규칙 정보를 제공합니다. 서버 설정이 변경된 뒤에도 로컬 클라이언트에 이전 사본이 남아 있을 수 있습니다. 클라이언트에서 구독 업데이트를 실행하고 업데이트가 완료된 것을 확인한 후 회선을 다시 선택해야 합니다. 구독 링크는 접속 인증 정보이므로 공개 검사 사이트나 문제 스크린샷에 붙여 넣어서는 안 됩니다.
회선 유형이 점검 결과에 미치는 영향
직접 연결, 중계와 IEPL 전용 회선은 회선의 진입점과 출구 사이 네트워크 경로를 설명하는 용어이며, 클라이언트의 트래픽 처리 방식과는 다릅니다. 직접 연결 회선은 기기에서 원격 노드로 바로 연결되므로 경로가 단순하지만, 로컬 네트워크에서 대상 지역까지의 공용 네트워크 품질에 더 크게 의존합니다. 중계 회선은 가까운 진입점에 먼저 연결한 뒤 중간 네트워크를 통해 출구로 전달하므로 일부 네트워크 환경에서 라우팅 안정성이 개선될 수 있습니다.
IEPL 전용 회선은 일반적으로 진입점과 출구 사이에 전용 전송망 또는 제어된 링크를 사용한다는 뜻이며, 핵심은 지역 간 전송 경로에 있습니다. 어떤 회선을 사용하든 기기에서 시스템 프록시, TUN, DNS와 분할 라우팅을 올바르게 설정해야 합니다. 전용 회선이 프록시 우회를 자동으로 해결해 주는 것은 아니며, 외부 IP와 DNS 확인을 대신할 수도 없습니다.
프로토콜만으로 작동 여부가 결정되는 것도 아닙니다. Shadowsocks, VMess, Trojan과 VLESS는 서로 다른 전송 및 인증 방식을 제공하고, Hysteria2와 TUIC는 UDP 기반 전송 방식에 중점을 둡니다. 실제로 앱 요청이 회선에 들어가는지는 클라이언트가 로컬 진입점을 만들고 라우팅 규칙을 적용하는 방식에 달려 있습니다. 노드 핸드셰이크는 성공했지만 앱이 직접 연결된다면 원격 노드 장애로 단정하기보다 먼저 로컬 처리 계층을 확인해야 합니다.
반복해서 사용할 수 있는 전체 검증 절차
조회 페이지를 잠시 여는 것만으로는 순간적인 결과만 얻을 수 있습니다. 더 안정적인 방법은 고정된 점검 절차를 만들어 클라이언트를 변경하거나 구독을 가져오거나 DNS 또는 분할 라우팅 규칙을 조정할 때마다 같은 순서로 실행하는 것입니다. 그러면 변화가 어느 계층에서 발생했는지 빠르게 판단할 수 있습니다.
- 설정을 업데이트합니다.신뢰할 수 있는 클라이언트에서 구독을 업데이트하고 회선과 규칙이 정상적으로 로드되었는지 확인합니다.
- 연결 전 기준값을 기록합니다.외부 지역, 주소 체계와 현재 DNS 정책을 저장하되 전체 네트워크 식별 정보는 공개하지 않습니다.
- 연결을 설정합니다.로그에서 핸드셰이크가 완료되었는지, 반복적인 재시도나 가상 인터페이스 오류가 발생하는지 확인합니다.
- 외부 IP를 확인합니다.새 세션에서 연결 전후 IP를 비교하고 IPv4와 IPv6를 각각 확인합니다.
- DNS를 확인합니다.조회기가 클라이언트 정책과 일치하는지 확인하고 시스템 및 브라우저 캐시를 배제합니다.
- 규칙 적중 여부를 확인합니다.테스트 도메인과 앱이 프록시로 처리되었는지 직접 연결로 처리되었는지 확인합니다.
- 앱별로 확인합니다.브라우저, 터미널, 데스크톱 소프트웨어와 사용하려는 모바일 앱을 점검합니다.
- 회선을 바꿔 재확인합니다.앱이 새 연결을 만들고 외부 IP 결과가 회선 변경에 따라 달라지는지 확인합니다.
- 일상 모드로 되돌립니다.점검을 위해 일시적으로 전체 프록시를 사용했다면 완료 후 필요한 분할 라우팅 설정으로 복원합니다.
- ✅ 클라이언트 핸드셰이크가 안정적이고 로그에 반복적인 재연결이 없습니다.
- ✅ 외부 IP 결과가 선택한 회선과 일치하고 주소 체계가 예상치 않게 우회하지 않습니다.
- ✅ DNS 조회가 로컬, 원격 또는 암호화 조회 정책에 맞게 처리됩니다.
- ✅ 회선을 사용해야 하는 모든 앱이 프록시 규칙에 해당합니다.
- ✅ 직접 연결을 유지해야 하는 로컬 서비스는 여전히 규칙에 따라 접속합니다.
- ❌ 연결 아이콘만 확인하고 실제 외부 IP와 규칙 로그를 대조하지 않았습니다.
전체 절차에서 특정 앱 하나만 실패했다면 먼저 해당 앱 이름, 운영체제, 클라이언트 모드, 노드 프로토콜, 규칙 적중 결과와 오류 로그를 수집해야 합니다. 모든 앱에서 외부 IP가 바뀌지 않는다면 시스템 프록시, TUN 인터페이스, 라우팅 충돌과 구독 설정을 우선 확인합니다. 문제를 구체적인 계층으로 좁히면 노드를 반복해서 바꾸는 것보다 훨씬 효율적으로 점검할 수 있습니다.