VPN 작동 여부를 확인하고 연결과 트래픽 처리를 구분하세요
VPN에 연결한 뒤에도 사이트가 열리지 않는다면 외부 IP부터 확인하고, 다음으로 DNS와 해당 앱을 점검하세요. 클라이언트의 ‘연결됨’ 표시는 보통 터널이나 프록시 서비스가 시작됐다는 뜻일 뿐, 브라우저·게임·명령줄 프로그램이 모두 이를 사용한다는 의미는 아닙니다.
문제를 진단할 때는 몇 가지 단계를 나눠서 살펴보세요. 앱이 요청을 어디로 보내는지, 클라이언트가 어떤 규칙으로 처리하는지, 도메인을 어디서 조회하는지, 원격 사이트에 어떤 공인 IP가 표시되는지 확인해야 합니다. 어느 한 단계라도 예상과 다르면 아이콘은 켜져 있는데 사이트가 열리지 않을 수 있습니다. 처음부터 클라이언트를 다시 설치하거나 여러 설정을 한꺼번에 바꾸지는 마세요.
시스템 프록시, 가상 네트워크 인터페이스를 통한 트래픽 처리, 브라우저 확장 프로그램은 적용 범위가 서로 다릅니다. 시스템 프록시는 앱이 프록시 설정을 따를 때 작동합니다. TUN 모드는 가상 네트워크 인터페이스로 라우팅 조건에 맞는 트래픽을 받지만, 제외 항목과 권한, 규칙의 영향을 받습니다. 브라우저 확장 프로그램은 대개 해당 브라우저에만 적용됩니다. 연결 아이콘 하나만으로 어느 방식이 제대로 작동하는지 판단할 수는 없습니다.
외부 IP: 연결 전후 비교
IP 조회 페이지를 열어 현재 공인 IP 주소, 통신사, 지역을 기록하세요. 선택한 경로에 연결한 다음 같은 브라우저로 다시 조회합니다. 지역 데이터베이스는 업데이트가 늦을 수 있으므로 지도에 표시된 지역명만 보지 말고 IP 주소 자체를 우선 비교하세요.
- 기준값을 기록하세요. 테스트할 클라이언트의 연결을 끊고, 다른 프록시 확장 프로그램이나 네트워크 클라이언트가 브라우저 트래픽을 처리하지 않는지 확인한 뒤 조회 결과를 저장합니다.
- 지역을 선택하고 연결하세요. 현재 경로 이름과 작동 모드를 기록하고, 테스트 중에는 설정을 반복해서 바꾸지 마세요.
- 새 요청을 보내세요. 조회 페이지를 새로고침합니다. 결과가 캐시된 것 같으면 기존 탭을 닫고 새 창에서 조회 페이지를 여세요.
- 규칙을 대조하세요. 조회 페이지가 직접 연결로 설정되어 있다면 IP가 바뀌지 않는 것이 설정에 따른 결과일 수 있습니다. 해당 사이트에 한해 프록시를 사용하도록 임시로 바꿔 다시 확인한 뒤 원래 규칙으로 되돌리세요.
- 대상 앱을 확인하세요. 브라우저의 외부 IP가 바뀌었다면 이번 브라우저 요청의 경로가 달라졌다는 뜻입니다. 다른 앱은 각각 따로 확인해야 합니다.
서로 다른 경로가 같은 외부 IP를 공유할 수도 있으므로, 경로를 바꾼 뒤에도 IP가 같다고 해서 전환에 실패했다고 단정할 수는 없습니다. 반대로 IP가 바뀌어도 모든 프로토콜의 트래픽이 해당 경로를 이용한다는 뜻은 아닙니다. 조회 서비스에서 IPv4와 IPv6 결과를 따로 제공한다면 각각 비교하세요. 한쪽 주소만 보고 결론을 내리지 않는 것이 좋습니다.
브라우저 시크릿 창은 일부 로컬 세션과 저장 정보를 분리할 뿐, 시스템 프록시를 자동으로 우회하거나 별도의 네트워크 경로를 만들지는 않습니다. 로그인 상태나 캐시의 영향을 확인하는 데는 도움이 되지만, 기기 전체의 트래픽 경로를 증명하는 방법은 아닙니다.
DNS 확인: 이름을 조회하는 위치와 외부 IP 위치는 다릅니다
DNS는 도메인 이름을 IP 주소로 변환합니다. 웹페이지 트래픽은 프록시를 이용하면서도 DNS 조회는 로컬 네트워크에서 처리될 수 있습니다. 브라우저의 보안 DNS, 클라이언트 내장 조회기, 원격 프록시가 DNS를 처리하는 경우도 있습니다. 외부 IP 확인과 DNS 확인은 서로 다른 단계를 살펴봅니다.
신뢰할 수 있는 DNS 검사 페이지를 이용할 때는 표시되는 정보가 조회 서버의 주소와 위치인지, 웹 트래픽의 외부 IP인지 먼저 확인하세요. 검사 페이지는 보통 전용 도메인으로 조회를 유도한 뒤 재귀 DNS 서버를 확인합니다. 공용 DNS 서비스는 여러 지역에 분산되어 운영될 수 있으므로, 표시된 지역이 선택한 경로와 다르다는 사실만으로 DNS 누출이라고 볼 수는 없습니다.
더 중요한 점은 원격에서 조회할 것으로 예상한 도메인이 실수로 로컬 네트워크의 DNS 서버에 전달되는지 여부입니다. 먼저 클라이언트가 프록시 도메인과 직접 연결 도메인에 각각 어떤 DNS 서버를 쓰는지 확인한 다음, 브라우저에서 별도의 보안 DNS가 활성화되어 있는지 살펴보세요. 암호화 DNS는 DNS 요청 전송의 일부를 보호하지만, 암호화되어 있다고 해서 현재 프록시 경로를 통해 전송되는 것은 아닙니다.
명령줄에서 확인할 수 있는 항목
Windows에서는 터미널에서 아래 명령을 실행해 기본 DNS 서버와 도메인 응답을 확인할 수 있습니다. 예시 도메인은 DNS 조회 테스트용이며 CPUVPN 노드나 서비스 접속 주소가 아닙니다.
nslookup example.commacOS와 Linux에서도 관련 도구가 설치되어 있다면 해당 명령을 사용할 수 있습니다. dig example.com으로 조회하는 방법도 있습니다. 이런 도구는 보통 브라우저의 HTTP 프록시 설정을 따르지 않습니다. TUN, DNS 가로채기, 시스템 DNS 설정에 따라 조회 경로가 달라질 수 있으므로 명령 출력만으로 브라우저가 실제 사용한 DNS 서버를 단정할 수는 없습니다.
DNS 설정을 변경한 뒤에는 새로 조회해야 하며, 필요하다면 해당 시스템이나 앱의 DNS 캐시를 비우세요. 캐시에 남은 이전 응답이 있다고 해서 지금도 이전 DNS 서버에 요청을 보내는 것은 아닙니다. 검사 페이지의 결과를 맞추려고 모든 DNS 설정을 무작정 바꾸지 마세요. 로컬 사이트나 내부 네트워크 도메인에 영향을 줄 수 있습니다.
증상별 진단: 먼저 규칙, 다음으로 앱 확인
아래 표에서는 눈에 보이는 증상에 따라 확인할 항목을 정리했습니다. 표만으로 원인을 확정할 수는 없습니다. 같은 증상도 여러 단계에서 발생할 수 있으므로 한 번에 하나씩 바꾸고 다시 확인해 범위를 좁혀 보세요.
| 증상 | 가능한 원인 | 우선 확인할 항목 |
|---|---|---|
| 브라우저의 외부 IP가 바뀌지 않음 | 시스템 프록시가 꺼져 있거나, 확장 프로그램이 설정을 덮어쓰거나, 조회 사이트가 직접 연결 규칙에 해당함 | 프록시 설정과 해당 도메인에 적용된 규칙 확인 |
| 브라우저는 정상인데 데스크톱 앱은 작동하지 않음 | 앱이 시스템 프록시를 따르지 않거나 별도의 네트워크 설정을 사용함 | 앱의 프록시 설정과 가상 네트워크 인터페이스의 적용 범위 확인 |
| 외부 IP는 바뀌었지만 대상 사이트에서 접속을 거부함 | 계정 지역, 플랫폼 정책, 외부 IP 평판 또는 서버 장애 | 접속 거부 페이지인지 네트워크 연결 오류인지 먼저 구분 |
| 일부 도메인만 실패하고 다른 사이트는 정상 | DNS 조회, 분할 라우팅 규칙 또는 대상 서비스 문제 | DNS 조회 결과, 규칙 적용 여부, 오류 유형 비교 |
| IPv4는 예상대로지만 IPv6는 기존 네트워크를 사용함 | 현재 모드가 IPv6를 처리하지 않거나 관련 우회 규칙이 있음 | 클라이언트의 IPv6 지원 여부와 실제 라우팅 확인 |
| 네트워크를 전환한 뒤 작동하지 않음 | 기존 연결, 라우팅 또는 DNS 상태가 제때 갱신되지 않음 | 연결을 다시 만든 뒤 시스템 프록시와 새 요청 확인 |
‘도메인 이름을 확인할 수 없음’, ‘연결 시간 초과’, ‘플랫폼에서 접속을 거부함’은 각각 따로 기록하세요. 첫 번째는 DNS를 우선 확인하고, 두 번째는 라우팅이나 경로, 대상 서비스 문제일 수 있습니다. 마지막은 계정 권한이나 지역 정책과 관련될 수도 있습니다. 오류 화면 하나만으로 클라이언트가 작동하지 않는다고 단정할 수는 없습니다.
분할 라우팅 규칙과 플랫폼 권한 확인 방법
규칙 모드에서는 일부 트래픽은 직접 연결하고 일부는 프록시를 이용하는 것이 정상적인 설정입니다. 클라이언트의 연결 목록이나 진단 정보를 볼 때는 대상 도메인이 어떤 규칙에 해당하며 최종적으로 어느 경로를 선택했는지 확인하세요. 클라이언트에서 관련 정보를 제공하지 않는다면 대상 앱의 실제 동작과 외부 IP 조회 결과를 함께 확인하세요. 존재하지 않는 메뉴 위치를 지어내지 마세요.
여러 클라이언트에서 ‘전역’ 모드는 프록시 엔진에 이미 전달된 요청을 지정된 경로로 보내는 설정일 뿐, 모든 앱의 트래픽을 자동으로 처리하지는 않습니다. 분할 라우팅 문제를 진단하는 데 쓸 수 있지만, 해당 요청이 실제로 클라이언트에 전달되어야 합니다. 확인을 마친 뒤에는 일상 사용에 적합한 규칙으로 되돌려 로컬 업무 트래픽이 불필요하게 다른 경로로 전송되지 않도록 하세요.
- ✅ Windows: 시스템 프록시 설정과 클라이언트 상태가 일치하는지 확인하세요. 가상 네트워크 인터페이스로 트래픽을 처리해야 한다면 필요한 권한과 실행 상태도 확인합니다. 일부 프로그램은 별도의 프록시 설정을 사용하므로 시스템 설정을 따르지 않을 수 있습니다.
- ✅ macOS: 클라이언트 안내에 따라 VPN 설정, 네트워크 확장 프로그램 또는 프록시 권한을 확인하세요. 구현 방식에 따라 필요한 권한이 다르므로 모든 종류의 권한 설정을 찾을 필요는 없습니다.
- ✅ Android: VPN 권한과 앱별 라우팅 목록을 확인하세요. 앱이 제외되어 있으면 상태 표시줄에 연결됨으로 나타나더라도 직접 연결을 계속할 수 있습니다.
- ✅ iOS: 시스템 VPN 상태와 클라이언트 규칙을 확인하세요. 브라우저 외 앱도 각각 테스트해야 하며, 웹페이지 한 번 조회한 결과로 시스템 전체를 판단하면 안 됩니다.
- ✅ Linux: 데스크톱 프록시, 터미널 환경 변수, 가상 네트워크 인터페이스의 라우팅 설정을 각각 확인하세요. 터미널 프로그램은 데스크톱 환경의 프록시 설정을 읽지 않을 수 있습니다.
프록시 클라이언트나 브라우저 확장 프로그램을 여러 개 동시에 실행하면 어떤 설정이 적용되는지 파악하기 어려워질 수 있습니다. 테스트할 때는 확인 대상 클라이언트만 남기고 프록시나 DNS 경로를 바꾸는 다른 도구는 잠시 비활성화하세요. 기기가 조직에서 관리되는 경우 관리형 네트워크 정책을 임의로 변경하지 마세요.
IPv6, WebRTC, 구독 설정의 범위
IPv6는 별도의 경로로 확인해야 합니다. 대상 앱이 IPv6를 사용하지만 현재 프록시 모드가 IPv4만 처리한다면 일부 요청이 예상한 경로를 따르지 않을 수 있습니다. 먼저 클라이언트에서 제공하는 IPv6 처리 또는 호환 설정을 사용하세요. 원인 파악을 위해 시스템 IPv6를 일시적으로 끄는 경우 기존 설정을 기록하고 테스트 후 복구하세요. 이를 모든 상황에 적용되는 해결책으로 여기면 안 됩니다.
WebRTC 검사 결과에는 로컬 주소, 개인정보 보호를 위해 처리된 호스트 이름, 공인 IP 후보가 표시될 수 있습니다. 로컬 주소가 보인다고 해서 웹 트래픽이 프록시를 벗어났다는 뜻은 아닙니다. 예상하지 못한 공인 IP 후보가 표시되면 브라우저 정책, UDP 지원, 실제 라우팅을 함께 확인하세요. 검사 경고를 없애려고 출처가 불분명한 확장 프로그램을 설치하지 마세요.
구독 링크는 노드와 관련 설정을 가져오는 데 사용되며, 분할 라우팅과 DNS 규칙이 모두 가져와진다는 의미는 아닙니다. 이는 구독 형식과 클라이언트 구현에 따라 다릅니다. 구독을 갱신한 뒤 선택한 구성이 실제로 활성화되어 있는지도 확인하세요. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC은 서로 다른 프로토콜 또는 방식의 이름이며, 그 자체만으로 시스템 트래픽이 처리되고 있음을 증명하지는 않습니다.
구독 링크에는 접속 자격 정보가 포함될 수 있습니다. 전체 링크나 QR 코드, 토큰이 보이는 스크린샷을 공개 게시판에 올리지 마세요. 지원팀에 오류를 문의할 때는 먼저 자격 정보, 계정 정보, 불필요한 주소 정보를 가리세요.
경로 유형과 트래픽 처리 범위는 별개의 문제입니다. IEPL 전용 회선, 중계, 직접 연결은 서로 다른 전송 방식입니다. 전용 회선을 선택했더라도 앱 요청이 클라이언트에 전달되지 않으면 해당 경로로 전송되지 않습니다. 먼저 요청 경로를 확인한 다음 회선 성능을 비교하세요. 점검 순서를 거꾸로 진행하지 마세요.
확인을 마친 뒤 결과를 기록하세요
문제를 다시 확인할 수 있도록 운영체제와 클라이언트 이름, 현재 모드, 선택한 지역, 테스트한 앱, 연결 전후 외부 IP, DNS 확인 결과, 구체적인 오류를 기록하세요. 설정은 한 번에 하나만 바꾸고 같은 작업을 다시 시도합니다. 그래야 규칙이 수정된 것인지, DNS 조회가 바뀐 것인지, 대상 사이트가 우연히 복구된 것인지 구분할 수 있습니다.
대상 사이트만 실패하고 외부 IP와 규칙이 예상대로라면 사이트 공지, 계정 권한, 지역 제한을 추가로 확인하세요. 네트워크 경로가 정상이라고 해서 플랫폼이 반드시 접속을 허용하는 것은 아니며, 콘텐츠 이용 권한이 바뀌는 것도 아닙니다. 지역을 반복해서 바꾸기보다 서비스 이용 규칙을 확인하는 편이 원인을 파악하는 데 도움이 됩니다.
클라이언트 연결 절차를 다시 확인하려면 사용 가이드를 참고하세요. 연결 오류를 더 살펴보려면 자주 묻는 질문을 확인하세요. 앞서 정리한 비교 결과를 함께 전달하면 같은 테스트를 반복하지 않아도 됩니다.