VPN에 연결했는데 제대로 작동하는지 어떻게 확인할까요? 먼저 출구 IP를 확인하고, 다음으로 DNS를 점검한 뒤 앱별로 하나씩 테스트하세요. 클라이언트에 '연결됨'이라고 표시되는 것은 시작일 뿐입니다. 대상 앱의 요청이 예상한 경로를 이용해야 해당 연결이 제대로 적용된 것입니다.
점검할 때는 노드를 바꾸고 규칙을 수정하면서 브라우저 설정까지 동시에 조정하지 마세요. 연결 전 상태를 먼저 기록하고, 한 번에 설정 하나만 변경한 뒤 같은 앱과 페이지로 다시 확인하세요. 그래야 경로 문제와 분할 라우팅 동작, 기존 연결 캐시를 구분할 수 있습니다.
'연결됨', 트래픽 처리, 접속 성공의 차이
'연결됨'은 터널이 구성됐다는 뜻일 수도 있고, 클라이언트에 따라 로컬 프록시가 실행 중이라는 뜻일 수도 있습니다. 시스템 프록시를 켜도 해당 설정을 따르는 앱만 처리하는 클라이언트가 있는 반면, 가상 네트워크 인터페이스로 트래픽을 처리하더라도 라우팅, 제외 목록, 분할 규칙의 영향을 받는 경우도 있습니다.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC 같은 프로토콜 이름만으로 기기 전체의 트래픽이 처리되고 있는지 알 수는 없습니다. 클라이언트 작동 모드와 시스템 권한, 앱의 실제 요청 경로를 확인해야 합니다. 화면에 표시된 '글로벌'은 프록시 규칙이 모두 프록시 출구를 가리킨다는 뜻일 수 있으며, 모든 앱의 트래픽이 클라이언트를 통과한다는 의미는 아닙니다.
| 확인된 현상 | 알 수 있는 내용 | 추가로 확인할 사항 |
|---|---|---|
| 클라이언트에 연결됨으로 표시됨 | 클라이언트가 연결 상태로 전환됨 | 대상 요청이 클라이언트에 전달되어 연결에 성공했는지 |
| 브라우저 출구 IP가 변경됨 | 해당 브라우저 요청의 공인 출구 주소가 변경됨 | 다른 앱과 IPv6도 같은 경로를 사용하는지 |
| DNS 검사에 공용 리졸버가 표시됨 | 테스트 도메인이 해당 리졸버 체계를 통해 처리됨 | DNS 요청의 전송 경로가 설정과 일치하는지 |
| 대상 앱 기능이 정상 작동함 | 현재 기능으로 접속할 수 있음 | 예상한 규칙이 적용됐는지, 아니면 직접 연결에 성공한 것인지 |
출구 IP: 연결 전후 비교부터 시작
신뢰할 수 있는 공인 IP 조회 페이지에서 현재 출구 주소를 기록하고, 페이지에 IPv4와 IPv6가 각각 표시되는지 확인하세요. 여기서 확인할 것은 공인 주소이며, 시스템 네트워크 설정에 표시되는 사설 IP가 아닙니다. 기록을 마친 뒤 클라이언트에 연결하고 같은 브라우저로 다시 조회하세요.
- 클라이언트를 연결 해제한 상태에서 현재 네트워크와 조회 페이지에 표시된 공인 주소 및 네트워크 정보를 기록하세요. 페이지에 IPv6 결과가 없다면 '감지되지 않음'으로 표시하고, 기기에 IPv6가 반드시 없다고 추정하지 마세요.
- 대상 노드에 연결하고 클라이언트 안내에 따라 시스템 프록시나 가상 인터페이스 모드를 활성화한 뒤 필요한 시스템 권한을 허용하세요.
- 이전 페이지에 의존하지 않도록 조회 페이지를 새로 여세요. 클라이언트 연결 기록도 함께 확인해 조회 요청에 프록시 또는 직접 연결 규칙이 적용됐는지 살펴보세요.
- 주소가 바뀌었는지 비교한 다음 대상 웹사이트를 확인하세요. 조회 페이지에 직접 연결 규칙이 적용됐다면 주소가 그대로여도 정상적인 분할 라우팅일 수 있습니다. 테스트 대상을 바꾸거나 클라이언트가 지원하는 글로벌 프록시 규칙을 잠시 적용해 다시 확인하세요.
IP 위치 정보는 데이터베이스의 추정값이라 업데이트가 늦을 수 있습니다. 출구 도시와 노드 이름이 완전히 일치하지 않는다고 연결 실패로 볼 수는 없습니다. 반대로 웹페이지 언어, 검색 결과의 지역, 계정의 등록 지역도 출구 경로를 증명하지 않습니다. 로그인 정보, 위치 권한, 과거 설정에 영향을 받을 수 있기 때문입니다.
조회 페이지는 해당 페이지에 도달한 요청만 보여줍니다. 브라우저 확장 프로그램이 별도의 프록시를 설정했다면 브라우저 결과는 데스크톱 앱의 경로를 대표하지 않으며, 기기 전체의 상태도 보여주지 않습니다.
DNS: 지역만 보지 말고 해석 경로를 확인하세요
DNS는 도메인 이름을 IP 주소로 변환합니다. DNS 검사 페이지는 보통 브라우저에서 새로운 테스트 도메인으로 요청을 보내고, 어떤 재귀 리졸버가 조회에 관여하는지 확인합니다. 표시되는 정보는 대개 DNS 서비스의 출구이며, 기기에서 리졸버까지 이어지는 전체 네트워크 경로는 아닙니다.
모든 DNS 조회가 클라이언트를 거쳐야 하는 설정인데도 테스트에 로컬 접속 네트워크의 리졸버가 나타난다면 DNS 우회 여부를 확인하세요. 다만 특정 공용 DNS 브랜드나 다른 국가의 리졸버가 보인다는 이유만으로 누출이라고 단정할 수는 없습니다. 공용 DNS 서비스는 여러 지역에 분산돼 있을 수 있고, 클라이언트가 원격 조회, 암호화 DNS 또는 합성 주소 방식을 사용할 수도 있습니다.
브라우저 DNS와 시스템 DNS를 각각 확인하세요
브라우저의 보안 DNS 설정은 시스템의 DNS 설정과 별도로 작동할 수 있습니다. 암호화 DNS는 조회 내용이 전송되는 동안 보호하지만, 프록시를 거치는지는 연결 경로와 규칙에 따라 달라집니다. '암호화됨'을 '대상 경로를 이용함'과 같은 뜻으로 보지 마세요.
먼저 클라이언트의 DNS 설정 안내를 읽고 브라우저 보안 DNS 및 시스템 설정과 비교한 뒤, 변경 사항을 적용해 테스트를 다시 실행하세요. 캐시가 남아 있으면 새로운 DNS 조회가 발생하지 않을 수 있으므로 일반 웹사이트를 반복해서 새로고침하기보다 검사 페이지에서 새 테스트를 진행하는 편이 좋습니다. 이상이 보인다고 익숙하지 않은 DNS 주소를 임의로 입력하지 마세요.
일부 클라이언트는 Fake-IP를 사용해 도메인을 임시 합성 주소에 연결한 다음 후속 연결을 처리합니다. 이 경우 시스템 도구에 표시되는 주소가 실제 웹사이트 주소가 아닐 수 있으므로, 이를 근거로 DNS가 변조됐다고 단정할 수 없습니다. 클라이언트 로그와 규칙 적용 내역, 최종 접속 결과를 함께 확인하세요.
IPv6와 WebRTC: 우회 요청 추가 점검
IPv4가 프록시를 통과한다고 해서 IPv6도 같은 경로를 이용한다는 뜻은 아닙니다. 네트워크와 앱이 IPv6를 지원하는데 클라이언트가 IPv4만 처리한다면 일부 요청이 기존 네트워크를 통해 전송될 수 있습니다. 눈에 가장 잘 띄는 주소만 보지 말고 검사 결과를 각각 확인한 뒤, 클라이언트의 IPv6 처리·직접 연결·차단 정책을 살펴보세요.
IPv6 경로가 예상과 다르면 우선 클라이언트 문서에 따라 트래픽 처리 설정을 조정하세요. 클라이언트가 IPv6를 지원하지 않는다고 명시돼 있다면 영향 범위를 이해한 뒤 해당 네트워크에서 IPv6를 잠시 끄고 비교할 수 있습니다. 이후 설정을 복원하고 적절한 구성을 선택하세요. 시스템 네트워크 설정을 장기간 변경하기 전에는 현재 네트워크의 정상 서비스에 지장이 없는지 확인해야 합니다.
WebRTC는 브라우저의 실시간 통신에 사용되며, 관련 검사에서 웹페이지 요청과 다른 네트워크 경로가 발견되기도 합니다. 하지만 사설 IP나 가려진 호스트 식별자가 보인다고 공인 주소가 노출된 것은 아닙니다. 예상과 다른 공인 주소가 나타났는지 확인하고 브라우저 개인정보 설정 및 클라이언트의 UDP 지원 여부를 함께 살펴보세요.
검사 페이지를 '전부 초록색'으로 만들려고 모든 실시간 통신 기능을 무작정 끄지 마세요. 설정을 바꾸면 회의나 통화에 영향을 줄 수 있습니다. 먼저 이상 주소가 어떤 종류인지 확인한 뒤 필요한 부분만 조정하세요.
앱별 확인: 브라우저를 통과한 뒤 다른 앱도 점검
모든 소프트웨어가 시스템 프록시 설정을 따르는 것은 아닙니다. Windows와 macOS의 브라우저 및 데스크톱 앱은 서로 다른 네트워크 설정을 사용할 수 있고, 명령줄 프로그램은 자체 프록시 설정을 읽을 수도 있습니다. iOS와 Android에서 VPN 권한을 허용해도 앱 제외 규칙이나 주문형 연결 규칙이 없다는 뜻은 아닙니다. Linux에서는 데스크톱 프록시, 터미널 환경 변수, 시스템 라우팅의 차이를 특히 확인해야 합니다.
앱을 확인할 때는 클라이언트에서 해당 도메인, 프로세스 또는 연결 기록을 찾아 적용된 규칙과 출구를 확인하세요. 모든 클라이언트가 프로세스 정보를 표시하는 것은 아니며, 모든 모드에서 도메인을 표시하는 것도 아닙니다. 기록이 충분하지 않다면 시스템 설정과 앱 내 프록시 안내를 함께 확인하세요. 기록이 없다는 사실만으로 직접 연결이라고 판단하지 마세요.
- ✅ 브라우저: 확장 프로그램의 프록시와 보안 DNS를 확인하고 출구를 다시 조회한 다음, 실제로 접속해야 하는 웹사이트를 여세요.
- ✅ 메일·업무 앱: 연결을 다시 설정하고 송수신이나 동기화를 테스트하면서 해당 연결에 예상한 규칙이 적용되는지 확인하세요.
- ✅ 화상 회의: 로그인, 회의 참가, 음성·영상 연결을 각각 확인하세요. 웹페이지가 열려도 실시간 미디어가 사용하는 UDP 경로까지 정상이라는 뜻은 아닙니다.
- ✅ 명령줄·백그라운드 작업: 도구 자체의 프록시 설정을 확인하세요. 브라우저 점검 결과를 터미널 프로그램에 그대로 적용하지 마세요.
- ❌ 중국 본토 웹사이트가 직접 연결된다고 무조건 실패로 보지 마세요. 규칙 기반 분할 라우팅을 사용한다면 의도한 설정일 수 있습니다.
노드를 바꾼 뒤에도 이미 맺어진 장시간 연결은 한동안 이전 경로를 유지할 수 있습니다. 먼저 작업을 저장한 뒤 대상 앱을 종료하고 다시 열고, 필요한 경우 다시 로그인하세요. 앱 첫 화면에 머물지 말고 실제 업무 동작까지 테스트해야 합니다.
문제 해결: 증상별로 원인 범위 좁히기
브라우저는 정상인데 다른 프로그램은 달라진 점이 없음
브라우저 확장 프로그램만 활성화했는지, 대상 소프트웨어가 시스템 프록시를 따르는지 먼저 확인하세요. 클라이언트가 가상 인터페이스 모드를 제공한다면 공식 안내에 따라 활성화한 뒤 다시 점검하고, 앱 제외 목록도 확인하세요. 관리 대상 업무 기기에서는 조직 정책을 임의로 우회하지 말고 관리자에게 확인해야 합니다.
출구는 바뀌었는데 대상 웹사이트에서 접속을 거부함
프록시가 작동하지 않는다고 단정할 수는 없습니다. 대상 서비스가 계정 지역, 출구 IP의 평판, 위치 권한 또는 자체 규칙에 따라 접속을 제한할 수 있습니다. 먼저 대상 요청에 프록시 규칙이 실제로 적용됐는지 확인한 다음 웹사이트의 안내를 살펴보세요. 특정 서비스 하나가 작동하지 않는다는 이유만으로 모든 트래픽이 우회 경로를 거치지 않는다고 판단하면 안 됩니다.
노드를 바꿨는데 표시 결과가 갱신되지 않음
조회 페이지에 직접 연결 규칙이 적용됐는지, 브라우저가 기존 연결을 재사용하고 있는지 확인하세요. 앱을 다시 열어 새 요청을 만들고, 필요한 경우 신뢰할 수 있는 다른 조회 페이지로 교차 확인하세요. 여러 노드가 같은 공인 출구를 공유할 수도 있으므로 주소가 같다는 사실만으로 연결 실패라고 단정할 수는 없습니다.
모든 접속에 문제가 있거나 클라이언트에 노드가 표시되지 않음
먼저 클라이언트 연결을 끊고 기본 네트워크에서 접속할 수 있는지 확인한 다음, 구독이 유효한지와 노드 목록이 업데이트됐는지 살펴보세요. 구독 링크는 연결 설정을 가져오기 위한 인증 정보이지 웹사이트를 직접 탐색하는 주소가 아닙니다. 호환되는 클라이언트에 가져온 뒤 업데이트해야 합니다. 가져오기에 성공했다는 것은 설정을 읽었다는 뜻일 뿐이며, 이후 노드를 선택하고 연결을 활성화한 다음 앞서 설명한 방법으로 확인해야 합니다.
IEPL 전용 회선, 중계, 직접 연결은 회선 구성 방식을 설명하는 용어로 기기에서의 점검을 대신할 수 없으며 DNS나 모든 앱이 예상대로 전송된다고 보장하지도 않습니다. 문제가 계속되면 문제 해결 가이드를 확인하거나 고객 지원에 민감 정보를 가린 증상 기록을 보내세요.
연결 정보를 노출하지 않도록 점검 기록을 보관하세요
유용한 문제 기록에는 운영체제, 클라이언트 이름, 연결 모드, 노드 이름, 대상 앱, 적용된 규칙, 연결 전후의 변화가 포함됩니다. 공인 주소 전체를 공개할 필요는 없습니다. 스크린샷을 공유할 때는 계정 정보, 구독 링크, 액세스 토큰과 문제 해결에 필요하지 않은 요청 내용을 가리세요.
구독 링크를 낯선 온라인 검사·변환 페이지에 붙여 넣지 마세요. 링크가 노출됐다면 서비스 패널에서 제공하는 초기화 또는 취소 기능을 이용한 뒤 클라이언트에 다시 가져오세요. 채팅 메시지만 삭제해도 이미 복사된 인증 정보는 무효화되지 않습니다.
YuanVPN의 개인정보 보호 정책은 '로그를 기록하지 않습니다'입니다. 이는 서비스 정책에 관한 설명이며, 기기 권한, DNS 해석, 트래픽 분할 점검을 대신하지 않습니다. 서비스 연결, 브라우저 동작, 앱 설정은 각각 다른 영역이므로 따로 확인해야 합니다.