VPN이 연결됐다고 표시되어도 실제로 적용됐는지는 별도로 확인해야 합니다. 공인 IP는 특정 요청이 어디를 통해 나갔는지 보여주고, DNS 검사는 도메인 조회 경로를 살펴보는 데 쓰입니다. 앱별 테스트를 하면 실제 사용하려는 프로그램이 예상한 경로를 이용하는지 확인할 수 있습니다. 이 증거들을 함께 살펴야 정상적인 분할 라우팅과 트래픽이 제대로 전달되지 않는 설정을 구분할 수 있습니다.
연결 상태와 실제 트래픽은 다릅니다
클라이언트의 ‘연결됨’ 표시는 터널이 만들어졌다는 뜻일 수도 있고, 프록시 서비스가 실행되거나 노드가 선택됐다는 뜻일 수도 있습니다. 구체적인 의미는 클라이언트에 따라 다릅니다. 구독을 가져왔다는 것은 설정 파일을 읽을 수 있다는 의미일 뿐입니다. 노드 테스트 성공도 대개 특정 테스트가 통과했다는 뜻이지, 모든 앱의 요청이 해당 노드를 이용한다는 보장은 아닙니다.
일반적인 프록시 클라이언트에서 시스템 프록시는 해당 설정을 따르는 앱에 프록시 주소를 전달합니다. 브라우저는 보통 이를 사용할 수 있지만 다른 프로그램은 자체 네트워크 설정을 쓸 수 있습니다. TUN 또는 시스템 VPN 모드는 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 처리하므로 적용 범위가 더 넓은 편입니다. 그래도 제외 앱, 라우팅 규칙, DNS 설정의 영향을 받습니다.
‘전역 프록시’와 ‘모든 트래픽’도 구분해야 합니다. 일부 클라이언트의 전역 모드는 프록시 엔진에 전달된 요청의 경로 선택 방식만 바꿉니다. 원래 프록시를 우회하는 앱까지 자동으로 엔진에 전달하지는 않습니다. 문제를 확인할 때는 트래픽 처리 방식, 실행 모드, 앱 설정을 각각 살펴보세요. 이름이 비슷한 메뉴를 같은 기능의 스위치로 간주하지 않는 것이 좋습니다.
| 확인 항목 | 확인할 수 있는 내용 | 이것만으로 단정할 수 없는 내용 |
|---|---|---|
| 클라이언트 연결 상태 | 터널 또는 로컬 프록시 서비스의 실행 상태 | 모든 앱이 해당 연결을 이용한다는 것 |
| 웹페이지의 공인 IP | 해당 웹페이지 요청에서 확인된 공인 출구 | 다른 앱이나 도메인도 같은 출구를 이용한다는 것 |
| DNS 검사 | 테스트 도메인 조회에 사용된 재귀 DNS 서버의 단서 | DNS 서버의 위치가 데이터의 출구 위치와 같다는 것 |
| 클라이언트 연결 로그 | 기록된 요청에 적용된 규칙, 정책 및 출구 선택 | 로그에 나오지 않은 트래픽도 처리됐다는 것 |
| 대상 앱에서 실제로 수행한 작업 | 현재 네트워크 환경에서 해당 기능이 작동하는 방식 | 기능이 작동하면 모든 네트워크 경로도 예상대로라는 것 |
먼저 공인 IP를 연결 전후로 비교하세요
먼저 테스트 목표를 정하세요. 특정 국제 사이트만 프록시를 이용하게 할지, 앱 전체가 시스템 터널을 이용하게 할지 결정합니다. 그런 다음 신뢰할 수 있는 공인 IP 확인 페이지를 선택하고, 확인 주소와 시간, 현재 네트워크, 클라이언트 모드를 기록하세요. 검사 서비스는 접속 요청을 받습니다. 네트워크를 확인하려고 구독 링크나 계정 정보, 클라이언트 설정을 업로드할 필요는 없습니다.
- 직접 연결 기준값을 기록합니다. 직접 연결 테스트를 해도 괜찮은 환경이라면 프록시를 끊고 IP 확인 페이지를 열어 공인 주소와 주소 체계를 기록하세요. 현재 작업에서 직접 연결로 정보가 노출되면 안 된다면 이 단계는 건너뛰세요. 필요한 보호를 해제하면서까지 테스트하지 마세요.
- 연결하고 모드를 확인합니다. 원하는 경로를 선택하고 시스템 프록시나 터널이 계획대로 작동하는지 확인하세요. 규칙 모드라면 확인 페이지의 도메인에 어떤 규칙이 적용되는지도 살펴보세요.
- 요청을 다시 보냅니다. 확인 페이지를 새로고침하고, 필요하면 기존 탭을 닫았다가 다시 여세요. 새 주소를 기록하고 클라이언트에 해당 연결 기록이 있는지도 확인하세요.
- 교차 확인합니다. 다른 신뢰할 수 있는 검사 서비스에서도 확인하고 주소의 위치 정보를 비교하세요. 데이터베이스마다 지역 표시가 다를 수 있으므로 지도에 표시된 도시만 보고 연결 실패라고 판단해서는 안 됩니다.
주소가 바뀌지 않았다면 먼저 해당 검사 사이트가 규칙에서 직접 연결로 설정됐는지 확인하세요. 브라우저가 별도의 프록시나 확장 프로그램 설정을 사용하는지도 살펴보세요. 주소가 바뀌었다면 이번 웹페이지 요청의 출구가 달라졌다는 점만 확인할 수 있습니다. IPv4와 IPv6도 확인해야 합니다. 검사 페이지에는 한쪽만 표시될 수 있지만 대상 앱은 다른 쪽을 우선 사용할 수 있습니다.
DNS 확인: 국가가 아니라 조회 경로를 살펴보세요
DNS는 도메인 이름을 네트워크 주소로 변환합니다. 웹페이지 데이터가 프록시를 통과한다고 해서 DNS 요청까지 원격에서 처리되는 것은 아닙니다. 반대로 원격 DNS를 사용한다고 웹페이지 데이터가 프록시를 통과한다는 뜻도 아닙니다. 클라이언트는 로컬 조회, 원격 조회 또는 규칙에 따른 분할 조회를 사용할 수 있으며 브라우저가 자체 암호화 DNS를 켜 두었을 수도 있습니다.
일반적인 DNS 검사 페이지는 브라우저에서 검사 전용 도메인을 요청하게 한 뒤 어떤 재귀 DNS 서버가 조회에 참여했는지 확인합니다. 결과에 표시된 주소는 대개 DNS 서비스의 주소이지 웹페이지 출구가 아닙니다. 공용 DNS 서비스는 애니캐스트와 분산 노드를 사용할 수 있으므로, 가까운 지역이나 낯선 국가가 표시된다는 사실만으로 누출이라고 단정할 수 없습니다.
먼저 설정이 의도한 동작을 확인하는 편이 좋습니다. 어떤 도메인을 로컬에서 조회하고 어떤 도메인을 프록시 쪽에서 조회할지, 암호화 DNS 연결 자체는 어떤 경로를 이용하는지 살펴보세요. 그다음 검사를 실행해 예상한 DNS 서비스와 결과를 비교하고 클라이언트의 DNS 로그도 확인합니다. 대상 도메인을 모두 원격에서 조회하도록 설정했는데도 예상하지 못한 로컬 조회가 반복해서 보인다면 추가로 원인을 확인해야 합니다.
Windows에서는 아래 PowerShell 명령으로 네트워크 어댑터의 DNS 설정을 확인할 수 있습니다. 이는 설정을 파악하는 단서일 뿐 실제 조회 경로를 증명하지는 않습니다. 브라우저의 암호화 DNS, 클라이언트 내장 리졸버, 터널 리디렉션이 실제 동작을 바꿀 수 있습니다.
Get-DnsClientServerAddress문제를 확인할 때 브라우저의 보안 DNS 설정과 클라이언트의 DNS 설정을 따로 살펴보세요. 한 번에 한 항목만 바꾼 뒤 다시 테스트해야 비교할 수 있습니다. 캐시를 지우면 DNS 조회를 다시 실행하는 데 도움이 될 수 있지만 잘못된 라우팅을 고쳐 주지는 않습니다. 기존 연결은 이전 주소를 계속 사용할 수도 있으므로 대상 앱을 다시 열어 확인하세요.
브라우저만 통과하고 끝내지 말고 앱별로 확인하세요
실제로 사용하는 앱을 목록으로 정리하고 반복할 수 있는 네트워크 작업을 선택하세요. 예를 들어 대상 페이지 열기, 원격 콘텐츠 새로고침, 새 서비스 연결 등이 있습니다. 테스트마다 앱 이름과 작업 시간, 대상 도메인, 클라이언트 로그에서 일치하는 기록을 적어 두세요. 로그에 프로세스 이름이 없으면 작업 시간과 도메인을 기준으로 연결해 볼 수 있지만, 시간대가 비슷하다는 이유만으로 확정적인 증거라고 보아서는 안 됩니다.
- ✅ 브라우저: 시스템 프록시, 확장 프로그램 프록시, 암호화 DNS 설정을 확인해 테스트 중인 브라우저가 어떤 설정을 사용하는지 파악하세요.
- ✅ 데스크톱 앱: 앱 자체의 프록시 옵션을 확인하세요. 시스템 터널을 사용해야 한다면 해당 앱이 제외 목록에 있는지도 살펴보세요.
- ✅ 명령줄 도구: 환경 변수와 도구 자체의 프록시 옵션을 확인하세요. 터미널 테스트 결과를 브라우저 테스트의 대체 증거로 사용하지 마세요.
- ✅ 모바일 앱: 시스템 VPN 연결이 유지되는지 확인하고 클라이언트에서 앱별 분할 라우팅을 사용 중인지 살펴보세요.
- ✅ 대상 기능: 로그인, 콘텐츠 로딩 등 실제 작업을 각각 테스트하고 서로 다른 도메인에 연결하는지 확인하세요.
Windows의 WinHTTP 프록시와 사용자 인터페이스의 시스템 프록시는 별개의 설정입니다. 아래 명령으로 WinHTTP 설정을 확인할 수 있지만, 결과에 직접 연결이라고 나와도 브라우저가 반드시 직접 연결되는 것은 아닙니다. 출력값을 맞추려고 설정을 무작정 바꾸지 마세요.
netsh winhttp show proxymacOS에서는 네트워크 서비스 프록시, 앱 내부 프록시, 터널 설정을 각각 확인해야 합니다. Linux의 데스크톱 프록시 설정은 터미널 프로그램에 적용되지 않을 수 있으며, 터미널은 프록시 환경 변수를 사용할 수도 있습니다. Android의 앱별 설정과 iOS 클라이언트의 라우팅 기능은 구현 방식에 따라 다르므로 플랫폼마다 메뉴와 동작이 같다고 가정하지 마세요.
온라인 게임, 음성 통화, 일부 실시간 앱은 UDP를 사용할 수 있습니다. 브라우저 페이지가 정상적으로 열려도 이런 연결까지 처리된다는 뜻은 아닙니다. 클라이언트와 현재 설정이 필요한 트래픽을 지원하는지 확인하고 대상 기능을 직접 테스트하세요. 프로토콜 이름만 보고 특정 앱이 반드시 작동한다고 판단할 수는 없습니다.
‘연결된 것처럼 보이는’ 흔한 원인
검사 페이지는 직접 연결되지만 대상 사이트는 프록시를 정상 이용하는 경우
대개는 모순이 아니라 규칙이 서로 다르기 때문입니다. 두 도메인에 각각 어떤 규칙과 정책 그룹이 적용되는지 확인하세요. 규칙 이름은 표시용일 뿐이므로 정책 그룹을 펼쳐 실제로 선택된 출구까지 확인해야 합니다. 구독 링크는 설정을 배포하지만, 로컬 규칙의 우선순위가 원하는 대로 되어 있다고 보장하지는 않습니다.
브라우저의 출구는 바뀌었지만 다른 프로그램은 기존 네트워크를 계속 이용하는 경우
먼저 트래픽 처리 범위를 확인하세요. 시스템 프록시는 이를 따르는 앱에만 적용됩니다. 앱이 별도 프록시를 쓰거나 기존 연결을 유지하거나 터널에서 제외됐을 수도 있습니다. 대상 앱을 완전히 종료한 뒤 다시 열어 새 연결을 확인하세요. 그래도 예상과 다르면 클라이언트 안내에 따라 처리 방식을 조정하세요. 시스템 네트워크 구성 요소를 바로 삭제하지 마세요.
IP는 바뀌었지만 서비스에는 기존 지역이 표시되는 경우
서비스는 계정 지역, 이전 세션, 위치 권한, 캐시, 자체 주소 데이터베이스 등을 함께 사용해 지역을 판단할 수 있습니다. ‘네트워크 출구 확인’과 ‘서비스의 지역 판정’을 따로 기록하세요. 관련 사이트 데이터를 지우거나 새 브라우저 세션을 사용하면 캐시 영향을 확인하는 데 도움이 됩니다. 하지만 출구를 바꿔도 대상 서비스의 지역 표시나 제공 콘텐츠가 달라진다고 보장할 수는 없습니다.
DNS는 예상대로지만 웹페이지가 열리지 않는 경우
도메인 조회에 성공했다는 것은 주소를 얻었다는 뜻일 뿐입니다. 이후에도 라우팅, 인증서, 대상 서비스의 제한 또는 연결 오류가 발생할 수 있습니다. 시스템 시간과 브라우저 오류 메시지를 확인한 뒤 클라이언트 로그를 살펴보세요. 검사를 완료하려고 인증서 경고를 무시하지 마세요. 출처를 확인하지 않은 페이지에 계정 정보를 입력하지도 마세요.
문제 해결 과정을 재현 가능한 기록으로 정리하세요
문제가 발생하면 한 번에 하나의 변수만 바꾸세요. 예를 들어 규칙 모드만 전환하거나 경로만 바꾸거나 특정 앱의 프록시 설정만 조정할 수 있습니다. 같은 작업을 대상으로 새 연결을 만들어야 어떤 변경이 영향을 줬는지 파악할 수 있습니다. 네트워크, 클라이언트, 설정을 계속 한꺼번에 바꾸면 ‘가끔 다시 작동하는’ 이유를 알기 어렵습니다.
지원 담당자에게 문의할 때는 기기 운영체제, 클라이언트 이름, 테스트 시간, 트래픽 처리 모드, 대상 도메인, 오류 메시지, 민감 정보를 가린 관련 로그를 전달하세요. 공인 IP도 민감 정보이므로 문의에 필요한 범위에서만 공유하세요. 구독 주소에는 접속 인증 정보가 포함될 수 있으니 공개 게시판에 올리지 마세요. 스크린샷을 공유하기 전에는 전체 구독 링크와 계정 토큰을 가리세요.
MHZVPN 사용 방법을 확인하려면 클라이언트 사용 가이드를 참고하세요. 경로 선택에 관한 내용은 서버 목록에서 확인할 수 있습니다. 경로 수와 제공 지역은 선택 가능한 범위를 나타낼 뿐, 특정 앱의 사용 가능성을 보장하지 않습니다. 실제로 사용할 때는 이 문서의 절차에 따라 확인하세요.