VPN이 제대로 작동하는지 확인하려면 먼저 연결 전후의 외부 IP를 비교하고, DNS 조회 경로를 점검한 다음 실제 사용하는 앱을 하나씩 확인하세요. 클라이언트에 ‘연결됨’이라고 표시되어도 연결 상태이거나 프록시 코어가 실행 중이라는 뜻일 뿐, 기기의 모든 요청이 선택한 경로를 통과한다는 의미는 아닙니다.
핵심은 ‘모든 주소가 반드시 바뀌어야 한다’가 아니라 트래픽이 설정에 맞게 처리되는지 확인하는 것입니다. 규칙 모드에서는 국내 웹사이트에 직접 연결되는 것이 의도된 동작일 수 있고, 전역 프록시를 사용해도 프록시에 연결되지 않은 앱은 직접 접속할 수 있습니다. 아래 순서대로 재현 가능한 항목을 확인해 웹사이트 접속 여부, 노드 지연 시간, 표시 지역 변경만으로 모든 트래픽이 제대로 처리된다고 단정하지 마세요.
먼저 검증 대상을 정하세요: 연결, 외부 IP, 앱
구독 링크는 노드와 설정을 가져오는 경로일 뿐입니다. 구독을 클라이언트에 추가하고 업데이트에 성공했다면 설정을 가져왔다는 뜻이지, 프록시가 활성화됐다는 뜻은 아닙니다. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC은 서로 다른 프록시 프로토콜입니다. 클라이언트의 해당 프로토콜 지원 여부와 설정 완성도는 연결에 영향을 주지만, 프로토콜 이름만으로 트래픽이 프록시를 거친다고 확인할 수는 없습니다.
전송 경로와 기기에서 트래픽을 처리하는 방식도 구분해야 합니다. IEPL 전용 회선, 중계, 직접 연결은 주로 서버나 접속 경로의 구성 방식입니다. 시스템 프록시, 앱 내 프록시, TUN 모드는 기기에서 어떤 트래픽을 프록시로 보낼지 결정합니다. 전용 회선이 프록시가 설정되지 않은 앱의 트래픽까지 자동으로 처리하지는 않으며, TUN 모드도 실제 라우팅과 DNS 동작 점검을 대신할 수 없습니다.
| 점검 항목 | 확인할 수 있는 내용 | 이 결과만으로는 확인할 수 없는 내용 |
|---|---|---|
| 클라이언트 연결 상태 | 클라이언트에서 연결이 설정됐거나 프록시 코어가 실행 중이라고 보고함 | 모든 앱이 해당 연결을 통해 통신하는지 |
| 브라우저 외부 IP | 이번 브라우저 요청에 사용된 외부 주소 | 데스크톱 앱·게임·백그라운드 서비스의 외부 접속 주소 |
| DNS 테스트 | 테스트 도메인 조회에 나타난 DNS 리졸버 정보 | 모든 도메인과 앱의 전체 DNS 조회 경로 |
| 클라이언트 연결 로그 | 요청에 적용된 규칙과 선택된 아웃바운드 | 대상 웹사이트의 접속 허용 여부나 계정 지역 |
외부 IP 확인: 연결 전후 결과를 비교하세요
신뢰할 수 있는 공인 IP 조회 사이트에서 주소와 위치를 확인하세요. 계정 비밀번호나 구독 링크를 입력할 필요는 없습니다. 먼저 프록시 연결을 끊고 현재 네트워크의 외부 IP, 통신사 이름, IPv6 표시 여부를 기록합니다. 그런 다음 클라이언트를 켜고 노드를 선택한 뒤 같은 브라우저로 같은 검사 페이지를 다시 열어 두 결과를 보관하세요.
- 기준값을 기록합니다. 네트워크는 그대로 두고 다른 프록시 도구와 네트워크를 제어할 수 있는 브라우저 확장 프로그램을 일시 중지한 다음, 연결 전 공인 IP 주소를 확인하세요.
- 클라이언트 모드를 확인합니다. 선택한 노드와 현재 모드가 규칙·전역·직접 연결 중 무엇인지 기록하세요. 시스템 프록시나 TUN이 실제로 켜져 있는지도 확인합니다.
- 새 요청으로 테스트합니다. 검사 페이지를 다시 열고, 캐시 영향을 줄이려면 필요에 따라 시크릿 창을 사용하세요. 시크릿 창을 열어도 시스템 프록시를 자동으로 우회하지 않으며 익명 네트워크가 되는 것도 아닙니다.
- 실제 아웃바운드를 확인합니다. 클라이언트 연결 로그에서 검사 페이지의 도메인을 찾아 적용된 규칙, 정책 그룹, 최종 노드를 확인하세요.
- 다른 결과와 교차 확인합니다. 별도의 IP 조회 사이트에서도 결과를 확인하세요. 표시 위치가 다르면 먼저 IP 주소가 같은지 비교하고, 노드에 문제가 있다고 서둘러 결론 내리지 마세요.
외부 IP가 바뀌고 로그에 요청이 선택한 노드를 통과한 기록이 있다면 해당 브라우저 요청은 프록시를 거친 것으로 볼 수 있습니다. 주소가 바뀌지 않았다면 검사 도메인에 직접 연결 규칙이 적용됐는지, 브라우저에 별도 프록시 설정이 있는지 확인하세요. 결과가 같다는 이유만으로 노드 연결이 불가능하다고 단정할 수는 없습니다.
IP 위치 정보는 데이터베이스를 기반으로 하며 실시간 위치 추적 결과가 아닙니다. 데이터베이스에 따라 같은 주소가 서로 다른 도시나 지역으로 표시될 수 있고, IP 등록 정보가 서버의 실제 위치와 일치하지 않을 수도 있습니다. 스트리밍 서비스와 다른 웹사이트는 계정 지역, 결제 정보, 이용 기록 등을 함께 확인하기도 합니다. 따라서 외부 IP가 바뀌었다고 특정 서비스를 반드시 이용할 수 있는 것은 아닙니다.
DNS 누출 여부는 리졸버가 있는 국가만으로 판단할 수 없습니다
DNS는 도메인 이름을 IP 주소로 변환하고, 실제 서비스 연결은 대상에 접속합니다. 두 작업이 서로 다른 경로를 사용할 수 있으므로 외부 IP가 정상적으로 바뀌어도 DNS 동작을 확인해야 합니다. 여기서 DNS 누출은 프록시 정책으로 보호되어야 할 조회 요청이 실수로 로컬 네트워크나 예상하지 않은 리졸버를 통해 전송되는 경우를 말합니다. 설정을 기준으로 판단해야 하며, 특정 국가 이름이 표시됐다는 이유만으로 결론을 내리면 안 됩니다.
연결하지 않은 상태에서 신뢰할 수 있는 DNS 누출 테스트를 실행하고 리졸버 이름과 통신사를 기록하세요. 연결한 뒤 같은 방식으로 다시 테스트하면서 클라이언트의 DNS 설정과 로그도 확인합니다. 테스트 사이트는 보통 전용 도메인 조회를 이용해 외부에 보이는 재귀 리졸버 주소를 확인하지만, 기기에서 리졸버까지 이어지는 모든 구간을 보여 주지는 않습니다.
연결한 뒤에도 로컬 통신사 리졸버가 표시되고 설정에서 원격 DNS 조회를 요구한다면 점검이 필요합니다. 반대로 해외 공용 리졸버가 표시되어도 DNS 조회가 프록시를 거쳤다고 단정할 수는 없습니다. 시스템이나 브라우저가 직접 연결 상태에서도 해당 리졸버를 사용할 수 있기 때문입니다.
브라우저 보안 DNS와 클라이언트 DNS를 함께 확인하세요
브라우저의 보안 DNS는 보통 DoH를 사용하며, 시스템에도 암호화 DNS가 설정되어 있을 수 있습니다. 이 기능은 해당 DNS 전송을 암호화하지만, 반드시 프록시를 거치게 하지는 않습니다. 브라우저가 시스템 DNS 설정을 따르지 않고 직접 DNS 서비스에 연결할 수 있으며, 이 연결이 프록시를 통과하는지는 시스템 프록시, TUN, 분할 터널링 규칙에 따라 달라집니다.
결과가 일치하지 않으면 먼저 현재 설정을 기록한 다음 브라우저가 시스템 DNS 설정을 사용하도록 잠시 바꾸고, 클라이언트 권장 DNS 설정과 함께 다시 테스트하세요. 검사 페이지를 ‘정상’으로 표시하려고 보안 DNS를 전부 끄지는 마세요. 규칙 모드에서는 로컬 도메인은 로컬에서, 다른 도메인은 원격에서 조회하도록 설정할 수도 있습니다. 이는 의도하지 않은 누출과 다릅니다.
DNS 캐시는 새 조회를 줄이므로 테스트할 때 페이지에서 새로운 요청을 보내도록 해야 합니다. 클라이언트가 Fake-IP를 사용하면 앱에 내부 매핑용 가상 주소가 전달될 수 있습니다. 이 주소는 최종 외부 IP가 아니므로 위치를 보고 노드의 위치를 판단할 수 없습니다.
앱별 확인: 브라우저가 정상이어도 모든 앱이 정상인 것은 아닙니다
Windows와 macOS의 시스템 프록시는 보통 시스템 설정을 따르는 앱에만 적용됩니다. 기기의 모든 트래픽을 터널로 보내는 기능과 같지 않습니다. 일부 데스크톱 앱에는 자체 프록시 설정이 있고, 터미널 도구는 환경 변수에 따라 동작할 수 있으며, 프록시를 사용하지 않고 직접 연결하는 앱도 있습니다. TUN 모드는 더 많은 트래픽을 처리할 수 있지만 권한, 라우팅 제외 항목, 클라이언트 지원 여부를 확인해야 합니다.
Android 클라이언트는 앱별 포함 또는 제외 옵션을 제공할 수 있습니다. iOS 클라이언트는 일반적으로 시스템 네트워크 확장으로 트래픽을 처리하며, 실제 처리 범위는 클라이언트 기능과 설정에 따라 달라집니다. 한 플랫폼의 메뉴나 스위치 이름을 다른 플랫폼에 그대로 적용하지 말고, 실제 설정 방법은 먼저 클라이언트 사용 가이드를 참고하세요.
- ✅ 브라우저: 외부 IP를 확인하고 검사 도메인의 아웃바운드 기록이 연결 로그에 있는지 확인합니다.
- ✅ 데스크톱 앱: 기존 연결을 끊고 새 요청을 보낸 뒤 시간, 대상 도메인, 프로세스 기준으로 로그를 확인합니다. 클라이언트가 프로세스 정보를 제공하지 않으면 프로세스 단위로 억지로 판단하지 마세요.
- ✅ 터미널 도구: 시스템 프록시나 별도 프록시 설정을 지원하는지 확인한 다음 클라이언트 로그와 비교하세요. 브라우저에서 얻은 결과를 그대로 적용하면 안 됩니다.
- ✅ 모바일 앱: 앱별 프록시 목록과 시스템 권한을 확인하고 앱을 다시 연 뒤 실제 기능을 테스트합니다.
- ❌ 앱 첫 화면에 콘텐츠가 보인다는 이유만으로 연결이 적용됐다고 판단하지 마세요. 로컬 캐시의 화면일 수 있어 새로운 네트워크 요청이 발생하지 않았을 수 있습니다.
외부 IP 조회 기능이 없는 앱은 새 연결이 클라이언트 로그에 기록되는지, 예상한 아웃바운드가 적용됐는지 확인할 수 있습니다. 다만 로그가 보이지 않는다고 반드시 직접 연결된 것은 아닙니다. 로그 수준이 낮거나, 연결을 재사용하거나, 클라이언트가 해당 기록을 표시하지 않을 수도 있습니다. 앱 자체의 네트워크 진단 기능과 시스템 네트워크 설정을 함께 확인하세요.
연결됨으로 표시되는데 경로를 통과하지 않을 때 점검 순서
모드와 규칙을 확인한 뒤 네트워크 적용 여부를 살펴보세요
먼저 직접 연결 모드가 아닌지, 대상 도메인이 우회 목록에 포함되어 있지 않은지 확인하세요. 규칙 모드에서는 대상에 지역·프로세스·기본 규칙이 적용될 수 있으며, 정책 그룹에서 직접 연결을 선택했을 수도 있습니다. 노드 목록에서 강조 표시된 이름만 보지 말고 최종 아웃바운드를 확인해야 합니다. 문제 원인을 찾기 위해 전역 프록시로 잠시 전환할 수 있지만, 이는 보통 프록시 코어에 들어온 트래픽의 아웃바운드 방식만 바꿉니다. 처음부터 연결되지 않은 앱까지 자동으로 프록시에 연결되지는 않습니다.
브라우저와 다른 앱의 동작이 다르다면 다른 소프트웨어가 시스템 프록시 설정을 덮어쓰는지, 브라우저 확장 프로그램에 별도 아웃바운드가 설정되어 있는지, TUN에 필요한 권한이 있는지, 앱별 제외 설정이 적용되는지 확인하세요. 테스트 중에는 트래픽을 처리하는 클라이언트를 하나만 켜 두면 문제 원인을 찾기 쉽습니다.
기존 연결, 프로토콜 지원, 네트워크 전환도 확인하세요
노드를 바꾼 뒤에도 이미 열린 장시간 연결은 기존 경로를 계속 사용할 수 있습니다. 상태 아이콘을 반복해서 새로 고치는 것보다 대상 앱을 다시 열거나 기존 연결을 끊고 새 요청을 보내는 편이 효과적입니다. Wi-Fi와 모바일 데이터 사이를 전환한 뒤에도 연결 상태와 라우팅을 다시 확인하세요.
웹페이지는 작동하지만 음성 통화, 게임, 기타 실시간 기능에 문제가 있다면 UDP 지원과 관련 규칙을 따로 확인하세요. 이 문제만으로 프록시 전체가 작동하지 않는다고 판단할 수는 없습니다. 반대로 노드 지연 시간 테스트에 성공해도 테스트 요청만 완료됐다는 뜻입니다. 대상 서비스 연결, 인증, 지역 제한까지 모두 정상이라는 보장은 없습니다.
마지막으로 구독이 최신 상태인지, 현재 클라이언트가 구독에 포함된 프로토콜을 지원하는지, 관리 패널에 요금제와 트래픽 상태가 정상으로 표시되는지 확인하세요. 구독 링크에는 접속 정보가 포함될 수 있으므로 모르는 변환 사이트에 붙여 넣지 마세요. 도움이 필요하면 지원 문의를 통해 클라이언트 이름, 운영체제, 오류 증상, 민감 정보를 가린 로그를 전달하면 됩니다.
최종 판단: 여러 증거를 함께 확인해 작동 여부를 판단하세요
외부 IP 비교로 요청이 어디로 전송됐는지 확인하고, DNS 테스트로 설정에 따라 조회되는지 살펴보며, 앱별 확인으로 평소 사용하는 소프트웨어가 실제로 프록시에 연결됐는지 검증하세요. 여러 결과가 서로 일치해야 ‘연결됨’ 표시만 보는 것보다 신뢰할 수 있습니다. 모든 테스트는 해당 시점의 특정 요청만 확인하므로 지속적인 익명성이나 모든 앱의 상시 보호를 입증하지는 않습니다.
평소에는 설정을 계속 바꿀 필요가 없습니다. 정상 상태에서 외부 IP, 모드, DNS 설정을 한 번 기록해 두고 문제가 생기면 이 기준값과 비교한 다음 변수를 하나씩 바꾸세요. 이렇게 하면 문제를 찾으면서 특정 앱을 고치느라 정상적으로 작동하던 분할 터널링을 망가뜨리는 일도 피할 수 있습니다. 프로토콜과 회선 용어는 프로토콜 및 회선 참고 가이드에서 더 알아볼 수 있습니다.