연결 아이콘만 보지 말고 적용 범위를 확인하세요
VPN이 제대로 작동하는지 확인하려면 먼저 외부 IP를 확인하고, 다음으로 DNS를 점검한 뒤 실제로 사용할 앱에서 검증하세요. 클라이언트에 ‘연결됨’이라고 표시되어도 특정 연결이나 트래픽 처리 기능이 설정되었다는 뜻일 뿐, 모든 트래픽이 원하는 경로를 이용한다는 증거는 아닙니다.
먼저 원하는 동작을 분명히 하세요. 특정 해외 사이트만 프록시를 이용하면 되는지, 아니면 기기의 인터넷 요청 대부분을 터널로 보내야 하는지 확인해야 합니다. 규칙 기반 분할 라우팅에서는 중국 본토 사이트는 직접 연결하고 해외 사이트는 프록시를 이용할 수 있습니다. 이 경우 사이트마다 외부 IP가 다르게 보이는 것이 정상일 수 있습니다. 모든 확인 페이지에 같은 지역이 표시되어야 한다고 보기보다 실제 라우팅 규칙을 기준으로 판단하세요.
| 점검 항목 | 주요 확인 사항 | 바로 단정할 수 없는 내용 |
|---|---|---|
| 외부 IP | 현재 요청에 사용되는 외부 주소와 네트워크 정보 | 다른 앱도 같은 경로를 이용한다는 점 |
| DNS 점검 | 테스트 도메인을 어떤 DNS 리졸버가 처리하는지 | 리졸버의 위치만으로 누출 여부를 단정하는 것 |
| 클라이언트 연결 로그 | 요청에 적용된 규칙, 외부 경로, 오류 정보 | 로그에 없는 앱은 인터넷에 연결되지 않았다는 점 |
| 대상 앱 확인 | 실제 기능이 작동하는지, 요청이 예상한 경로를 이용하는지 | 플랫폼 계정의 지역 또는 권한 제한이 해제되었다는 점 |
연결 전후를 비교할 기록부터 남기세요
처음부터 모든 설정을 바꾸지 마세요. 현재 설정을 저장하고 클라이언트가 규칙 모드, 전역 프록시 모드, TUN 모드 중 무엇을 사용하는지 기록하세요. 프록시 설정이 서로 덮어쓰지 않도록 다른 프록시 확장 프로그램과 동시에 실행 중인 네트워크 클라이언트를 종료하세요. 조직에서 관리하는 기기라면 관리 정책을 먼저 확인하고 보안 소프트웨어를 임의로 끄지 마세요.
- 직접 인터넷에 연결할 수 있는 환경에서 현재 경로 연결을 해제하고, 신뢰할 수 있는 공인 IP 확인 페이지를 열어 주소와 네트워크 정보, 확인 시간을 기록하세요.
- 확인하려는 경로에 연결한 뒤 같은 브라우저에서 다시 확인하세요. 페이지에 이전 결과가 캐시되어 표시되는 것이 아니라 새 요청이 이루어졌는지 확인합니다.
- 확인 페이지의 도메인에 적용된 분할 라우팅 규칙을 살펴보세요. 직접 연결 규칙이 적용되었다면 해당 도메인만 임시로 프록시를 사용하도록 지정한 뒤 비교합니다.
- 결과를 기록한 다음 원래 분할 라우팅 설정으로 되돌리고 DNS와 대상 앱을 계속 확인하세요. 원인을 찾기 쉽도록 한 번에 설정 하나만 변경합니다.
구독 설정을 가져오는 것과 트래픽 처리가 제대로 되는 것은 별개의 문제입니다. 구독 링크에는 노드와 관련 설정이 포함되며, 클라이언트는 해당 프로토콜을 지원하고 트래픽 처리 모드를 올바르게 활성화해야 합니다. 노드 이름은 서버 측 라벨일 수 있으므로 외부 경로 확인을 대신할 수 없습니다. 접속 정보가 포함된 경우가 많으니 구독 링크를 낯선 확인 사이트에 붙여넣지 마세요.
외부 IP: 주소 변경과 요청 경로를 함께 확인하세요
연결 후 확인 페이지에 표시된 공인 주소가 목표 외부 주소로 바뀌었다면, 해당 브라우저 요청이 그 경로를 이용했다는 직접적인 근거가 됩니다. 지역 표시는 참고 정보일 뿐입니다. IP 데이터베이스마다 위치가 다를 수 있고, 특히 도시 단위 위치 정보는 정확한 근거로 삼기 어렵습니다. 주소 변경과 네트워크 정보, 클라이언트 로그를 함께 살펴보는 편이 확실합니다.
주소가 바뀌지 않았다면 먼저 브라우저에 별도의 프록시 확장 프로그램이 켜져 있는지, 확인 도메인에 직접 연결 규칙이 적용되는지, 시스템 프록시가 실제로 활성화되어 있는지 살펴보세요. 새 노드와 기존 노드가 같은 공인 출구를 공유할 수도 있으므로, 노드를 바꾼 뒤 주소가 같다는 사실만으로 전환 실패를 단정할 수는 없습니다.
IPv4와 IPv6도 각각 확인해야 합니다. 확인 서비스가 둘 중 하나만 점검하는 반면, 브라우저는 다른 주소 체계로 사이트에 접속할 수 있습니다. 클라이언트가 일부 주소 체계만 처리한다면 확인 페이지는 프록시를 이용해도 다른 연결은 직접 연결될 수 있습니다. 두 주소 체계를 구분하는 점검 방법을 사용하고 클라이언트의 IPv6 라우팅 및 DNS 설정을 확인하세요.
공인 IP 확인은 확인 서비스로 향한 해당 연결만 증명합니다. 컴퓨터의 사설 네트워크 주소가 바뀌지 않는 것은 정상이며, 라우터 내부 주소도 국제 경로의 외부 출구가 아닙니다.
DNS: 국기 표시보다 조회 경로를 확인하세요
DNS는 도메인 이름을 IP 주소로 변환하며, DNS 조회와 웹 연결은 서로 다른 경로를 이용할 수 있습니다. 웹 트래픽의 외부 경로가 바뀌었다고 해서 도메인 조회도 자동으로 터널을 통과하는 것은 아닙니다. 관련 조회가 모두 터널을 이용하도록 설정했는데도 로컬 네트워크의 DNS 서비스로 요청이 전달된다면 추가 확인이 필요합니다.
신뢰할 수 있는 DNS 누출 점검은 보통 새 테스트 도메인에 대한 조회를 발생시킨 뒤, 해당 조회를 처리한 재귀 리졸버를 보여줍니다. 연결 전후의 리졸버 이름과 네트워크 정보, 변화를 기록하고 클라이언트 DNS 설정과 비교하세요. 리졸버가 현지에 있다고 해서 반드시 누출된 것은 아니며 해외에 있다고 해서 조회가 터널로 보호되었다는 뜻도 아닙니다. 공용 DNS, 애니캐스트 네트워크, 데이터베이스 오류가 표시 결과에 영향을 줄 수 있습니다.
브라우저의 보안 DNS, 시스템 암호화 DNS, 클라이언트 내장 DNS가 함께 작동할 수 있습니다. 브라우저에서 DoH를 사용하면 조회 요청이 별도의 HTTPS 연결을 이용할 수 있으며, 그 경로는 프록시와 라우팅 규칙에 따라 달라집니다. 암호화 DNS는 조회 전송을 보호하지만, ‘암호화’와 ‘지정된 경로를 이용’하는 것은 별개의 문제입니다.
결과가 예상과 다르면 먼저 클라이언트가 권장하는 DNS 모드를 확인하고, 브라우저가 시스템 설정을 덮어쓰는지 살펴보세요. 오래된 기록이 영향을 주지 않도록 DNS 캐시를 지우거나 관련 앱을 다시 시작한 뒤 점검합니다. 확인 페이지의 국기 표시를 맞추려고 임의로 DNS 주소를 입력하거나 문제를 감추기 위해 조회 보호를 계속 꺼두지 마세요.
앱별 점검: 브라우저에서 통과해도 기기 전체가 확인된 것은 아닙니다
시스템 프록시는 이를 지원하는 앱에 프록시 설정을 제공할 뿐, 기기의 모든 네트워크 연결을 강제로 바꾸지는 않습니다. 일부 명령줄 프로그램, 게임, 업데이트 프로그램, 앱 내 네트워크 구성 요소는 시스템 프록시 설정을 따르지 않거나 별도 설정이 필요할 수 있습니다. 브라우저 점검이 정상이라면 우선 브라우저의 연결 경로만 확인된 것입니다.
TUN 모드는 가상 네트워크 어댑터와 라우팅을 통해 IP 트래픽을 처리하므로 일반적으로 더 많은 연결을 포괄하지만, 제외 경로와 앱별 규칙, 프로토콜 지원, 권한의 영향을 받습니다. ‘전역 프록시’도 프록시 엔진으로 전달된 요청의 경로를 통일해서 선택하는 설정일 수 있으므로 기기 전체의 트래픽 처리와 같다고 볼 수 없습니다.
Windows와 macOS에서는 시스템 프록시, 네트워크 확장 또는 가상 네트워크 어댑터 권한을 각각 확인하세요. 모바일 기기에서는 앱의 네트워크 트래픽 처리 권한과 클라이언트의 앱 우회 규칙을 살펴봐야 합니다. 클라이언트마다 옵션 이름이 다르므로 스위치 이름만 보고 적용 범위를 단정할 수 없습니다. 설치 및 권한 설정은 사이트의 사용 가이드를 참고하세요.
- ✅ 브라우저: 새 페이지를 열어 외부 경로를 확인하고 프록시 확장 프로그램과 보안 DNS의 별도 설정도 점검하세요.
- ✅ 대상 앱: 완전히 종료한 뒤 다시 열고 실제 네트워크 작업을 실행하세요. 클라이언트 연결 로그에서 해당 도메인이나 프로세스를 찾습니다.
- ✅ 명령줄 프로그램: 시스템 프록시 설정을 따르는지, 자체적으로 지원하는 프록시 옵션이나 환경 변수가 필요한지 확인하세요.
- ✅ 규칙 적용: 요청에 프록시, 직접 연결, 차단 중 어떤 규칙이 적용되는지 확인하고 선택된 경로가 용도에 맞는지 살펴보세요.
- ❌ 웹페이지가 열리거나 계정에 로그인되거나 클라이언트 아이콘이 켜졌다는 이유만으로 기기 전체의 트래픽이 처리되고 있다고 단정하지 마세요.
로그에서는 도메인, 프로세스, 시간의 연관성을 확인하세요. DNS 조회와 백그라운드 연결 확인, 실제 서비스 요청은 서로 다른 연결일 수 있습니다. 로그가 보이지 않는 것은 기록 수준 설정이나 이미 연결된 세션 때문일 수도 있습니다. 로그를 지원팀에 전달하기 전에 구독 정보와 계정 식별 정보, 관련 없는 접속 기록을 삭제하세요.
연결된 것처럼 보여도 경로가 적용되지 않는 흔한 원인
기존 연결이 이전 경로를 계속 이용함
앱이 연결 풀이나 백그라운드 세션, 이미 설정된 연결을 재사용할 수 있습니다. 외부 경로를 바꾼 뒤에는 대상 앱을 완전히 종료하고 다시 열어 새 요청을 발생시키세요. 브라우저에서 새 탭을 열어도 새 연결이 만들어진다는 보장은 없습니다. 최신 점검 결과와 로그를 함께 확인해야 합니다.
분할 라우팅 규칙에 따라 요청이 직접 연결됨
웹페이지는 기본 사이트뿐 아니라 리소스 도메인, 로그인 API, 미디어 도메인과도 통신할 수 있습니다. 기본 사이트의 규칙만 바꾸면 나머지 요청은 다른 경로를 이용할 수 있습니다. 로그를 확인해 관련 요청을 하나씩 점검하세요. 잠시 통합 프록시를 사용했을 때 정상화된다면 규칙 모드로 돌아가 관련 규칙을 수정하면 됩니다. 관련 없는 트래픽까지 계속 프록시로 보낼 필요는 없습니다.
프로토콜 호환성 또는 UDP 처리가 불완전함
노드 프로토콜과 트래픽 처리 모드는 서로 다른 문제를 해결합니다. Shadowsocks, VMess, Trojan, VLESS 등은 클라이언트가 해당 설정을 지원해야 합니다. Hysteria2와 TUIC은 UDP 전송에도 의존합니다. 노드 연결 테스트에 성공해도 모든 앱의 UDP 요청이 전달된다는 뜻은 아닙니다. 클라이언트 지원 여부와 외부 경로의 기능, 로컬 네트워크 제한을 확인하세요.
플랫폼 제한을 경로 문제로 오해함
외부 경로가 예상과 일치하는데도 플랫폼을 사용할 수 없다면 계정 지역, 앱 캐시, 외부 IP의 평판 또는 플랫폼의 접속 정책이 원인일 수 있습니다. IEPL 전용 회선, 중계, 직접 연결은 전송 경로를 설명하는 말일 뿐 최종 외부 경로 확인을 대신하지 않으며 앱 호환성을 보장하지도 않습니다. 지역을 반복해서 바꾸며 계정 사용 가능 여부를 추측하지 마세요.
다시 확인할 수 있는 결론을 내리는 방법
연결 전후의 외부 IP 기록과 DNS 결과, 트래픽 처리 모드, 대상 앱 로그를 보관하세요. 결론은 ‘브라우저에서 확인 도메인으로 보낸 요청이 목표 경로를 이용했고, 대상 앱 요청에는 프록시 규칙이 적용됨’처럼 구체적으로 적는 편이 좋습니다. ‘VPN 정상’처럼 뭉뚱그리면 오판하기 쉽습니다. 구체적인 기록은 이후 환경 변화를 확인하는 데도 도움이 됩니다.
판단 기준: 외부 경로가 예상과 일치하고 DNS 조회 경로가 설정과 부합하며 대상 앱의 새 요청에 올바른 경로가 적용되어야 이번 점검 대상에 대한 기능이 작동한다고 볼 수 있습니다. 하나라도 맞지 않으면 해당 단계부터 원인을 찾은 뒤 설정을 변경하세요. 점검에 통과해도 익명성이나 보안이 절대적으로 보장되는 것은 아닙니다.
추가로 문제를 해결하려면 도움말 센터를 확인하거나 사용자 패널에서 문의를 제출하세요. 기기 플랫폼과 클라이언트 이름, 트래픽 처리 모드, 오류 현상, 완료한 점검 항목을 함께 알려주면 ‘연결됨’ 화면만 보내는 것보다 문제 파악에 도움이 됩니다.