VPN이 정말 작동하는지 확인할 때 클라이언트에 표시되는 “연결됨”만 봐서는 안 됩니다. 이 상태는 일반적으로 클라이언트가 핸드셰이크를 완료했거나 프록시 포트가 수신 대기 중임을 뜻하며, 시스템에 가상 네트워크 인터페이스가 생성되었다는 의미일 수도 있습니다. 하지만 브라우저, 명령줄 도구 및 다른 앱의 요청이 모두 대상 경로를 통과한다고 보장하지는 않습니다. 정확하게 판단하려면 공인 IP, DNS 요청 경로와 각 앱의 실제 경로를 함께 확인해야 합니다.

검증에서 가장 중요한 원칙은 비교 기준을 만드는 것입니다. 연결하지 않은 상태의 네트워크 정보를 먼저 기록한 뒤 경로에 연결하고 완전히 동일한 요청을 반복하세요. 연결 후 한 번의 결과만 보면 로컬 네트워크의 기존 출구, 브라우저 캐시 또는 보안 DNS 서비스를 경로의 효과로 잘못 판단하기 쉽습니다. 다음 절차는 특정 클라이언트 브랜드에 의존하지 않으며 시스템 프록시, TUN 모드, 기본 VPN 구성과 브라우저 확장 프로그램 등 일반적인 연결 방식에도 적용할 수 있습니다.

판단 기준: 아이콘·핸드셰이크·실제 트래픽은 서로 다릅니다

한 번의 연결은 구성 로드, 프로토콜 핸드셰이크, 시스템 트래픽 인계, 앱 요청 전송이라는 여러 단계로 나눌 수 있습니다. 구독 링크는 구성 배포를 위한 진입점일 뿐이며, 가져오기에 성공했다는 것은 클라이언트가 노드 정보를 읽었다는 뜻입니다. Shadowsocks, VMess, Trojan, VLESS, Hysteria2 및 TUIC 같은 프로토콜이 핸드셰이크를 완료한 뒤에도 클라이언트는 시스템 프록시, 가상 네트워크 카드 또는 앱 내부 프록시를 통해 트래픽을 해당 연결로 전달해야 합니다.

관찰 신호 확인할 수 있는 내용 이것만으로는 확인할 수 없는 내용
클라이언트에 연결됨으로 표시됨 구성이 시작되었고 일반적으로 경로 핸드셰이크가 완료됨 모든 앱이 해당 경로를 사용함
시스템에 VPN 또는 가상 네트워크 카드 표시가 나타남 시스템 네트워크 인터페이스가 생성됨 기본 경로와 DNS가 예상대로 전환됨
공인 IP가 변경됨 현재 테스트 요청이 다른 출구를 사용함 다른 앱과 DNS 요청도 같은 경로를 사용함
DNS 소속이 변경됨 현재 조회 요청이 다른 리졸버를 사용함 웹 요청 자체가 반드시 대상 경로를 통과함
대상 앱의 요청이 성공함 현재 규칙에서 해당 앱에 사용 가능한 경로가 있음 백그라운드 프로세스와 다른 앱도 인계됨

따라서 정확한 결론은 “클라이언트 아이콘이 켜졌다”가 아니라 “인계를 예상한 앱의 새 요청이 대상 출구에서 전송되고, 도메인 조회도 현재 구성에 맞는다”입니다. 분할 라우팅을 사용하면 일부 요청이 직접 연결되는 것이 정상일 수 있습니다. 중요한 것은 모든 트래픽이 같은 출구로 보이는지가 아니라 결과가 규칙과 일치하는지입니다.

기준 기록과 공인 IP 비교

공인 IP는 가장 직접적인 1차 점검 항목입니다. 연결을 끊은 상태에서 신뢰할 수 있는 IP 조회 페이지를 통해 공인 주소, 네트워크 운영자와 대략적인 지역을 기록한 다음 대상 경로에 연결하고 조회 결과를 새로 고치세요. 주소와 네트워크 소속이 바뀌면 현재 조회 요청이 다른 공인 출구를 실제로 사용했다는 뜻입니다.

  • ✅ 경로 연결을 해제하고 트래픽을 자동으로 인계할 수 있는 브라우저 확장 프로그램을 끈 뒤 현재 출구 정보를 기록합니다.
  • ✅ 대상 경로에 연결하고 클라이언트에 핸드셰이크 완료가 표시될 때까지 기다린 다음 새 브라우저 탭에서 조회합니다.
  • ✅ 공인 주소, 자율 시스템 소속과 지역을 비교하되 지도에 표시된 도시 이름만 보지는 마세요.
  • ✅ IPv4와 IPv6를 각각 확인합니다. 듀얼 스택 네트워크에서는 두 종류의 요청이 서로 다른 경로를 선택할 수 있습니다.
  • ✅ 인계 대상인 다른 앱으로 다시 확인해 브라우저 고유의 프록시 설정을 전체 결과로 오해하지 않도록 합니다.

지역명은 보조 정보로만 사용해야 합니다. IP 데이터베이스는 같은 주소 대역을 데이터센터 등록지, 네트워크 운영자 소재지 또는 인접 도시에 표시할 수 있습니다. 따라서 도시가 완전히 일치하지 않는다고 해서 경로가 작동하지 않는 것은 아닙니다. 더 중요한 것은 공인 주소가 바뀌었는지, 네트워크 소속이 노드 유형에 맞는지, 새 요청을 여러 번 만들어도 예상 출구를 유지하는지입니다.

연결 전후 주소가 완전히 같다면 먼저 노드를 반복해서 바꾸지 마세요. 현재 모드가 로컬 프록시 포트만 열고 시스템 프록시나 TUN을 활성화하지 않았는지 확인해야 합니다. 조회 페이지가 분할 라우팅 규칙에 따라 직접 연결로 처리되었는지도 확인하세요. 브라우저 확장 프로그램이 시스템 설정을 덮어써 브라우저와 다른 앱의 결과가 반대로 나타날 수도 있습니다.

도메인 조회: DNS 소속과 유출 판단

DNS는 도메인 이름을 연결 가능한 주소로 변환합니다. 웹 트래픽은 경로를 통과하지만 DNS 조회가 로컬 네트워크 리졸버로 계속 전달되면 방문한 도메인 정보가 다른 경로로 전송될 수 있습니다. 이를 일반적으로 DNS 유출이라고 합니다. 핵심은 “DNS가 있는 국가가 출구와 반드시 같아야 한다”가 아니라, 리졸버가 클라이언트·시스템 또는 브라우저에서 설정한 방식과 일치하는지입니다.

최신 브라우저는 암호화 DNS를 활성화해 브라우저가 지정한 조회 서비스를 직접 사용할 수 있습니다. Android의 비공개 DNS, 시스템 네트워크 설정과 클라이언트 내장 DNS도 서로 설정을 덮어쓸 수 있습니다. 이때 조회 결과에 제3자 DNS 네트워크가 표시된다고 해서 자동으로 유출인 것은 아닙니다. 먼저 실제로 누가 조회를 담당하는지 확인한 뒤 경로가 예상과 일치하는지 판단해야 합니다.

모든 데스크톱 플랫폼에서 현재 DNS 구성을 확인할 수 있습니다. 아래 명령은 시스템 상태를 관찰하기 위한 것이며 브라우저가 시스템 DNS를 우회하는지 직접 증명하지는 않지만, 설정 출처를 파악하는 데 도움이 됩니다:

Windows
ipconfig /all

macOS
scutil --dns

Linux
resolvectl status

Windows 출력에서는 활성 네트워크 인터페이스가 사용하는 DNS 서버를 확인할 수 있습니다. macOS 결과에는 서로 다른 범위의 리졸버가 표시됩니다. systemd-resolved를 사용하는 Linux 환경에서는 각 인터페이스의 DNS와 기본 경로 상태를 확인할 수 있습니다. 클라이언트가 TUN으로 DNS를 인계하는 경우 관련 가상 인터페이스나 클라이언트 구성에서 단서를 찾을 수 있습니다.

브라우저 측의 보안 DNS 설정도 별도로 확인해야 합니다. 브라우저가 사용자 지정 리졸버를 강제로 사용하면 시스템 명령에 표시된 서버는 웹 조회를 전혀 처리하지 않을 수 있습니다. 반대로 일부 클라이언트는 시스템 DNS를 가로채 터널 안에서 전달합니다. 이 경우 로컬 장치에서 보이는 주소는 수신 진입점일 뿐이며 최종 재귀 리졸버는 다른 네트워크에 있을 수 있습니다.

DNS 판단: 출구 지역과 DNS 지역이 완전히 일치하지 않는 것만으로는 유출이라고 판단할 수 없습니다. 조회 요청이 예상한 터널 또는 프록시 정책을 우회해 로컬 네트워크나 예상하지 못한 리졸버에서 처리될 때 DNS 인계, 브라우저 보안 DNS 또는 분할 라우팅 구성을 수정해야 합니다.

앱별 요청: 직접 연결되는 앱 찾기

공인 IP 페이지는 조회를 요청한 해당 앱이 경로를 사용했다는 것만 보여 줍니다. 브라우저가 정상이라고 해서 터미널, 다운로드 도구, 게임 플랫폼 또는 데스크톱 커뮤니케이션 앱도 같은 경로를 사용하는 것은 아닙니다. 가장 확실한 방법은 앱별로 동일한 요청을 수행하고 결과를 연결 방식과 함께 비교하는 것입니다.

시스템 프록시는 일반적으로 시스템 프록시 설정을 능동적으로 읽는 소프트웨어에만 영향을 줍니다. 일부 명령줄 도구, 게임과 자체 네트워크 스택을 사용하는 앱은 이 설정을 무시합니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 IP 트래픽을 인계하지만 라우팅 제외 항목, 앱 우회 규칙과 로컬 네트워크 직접 연결 규칙의 영향을 받을 수 있습니다. 브라우저 확장 프로그램은 범위가 더 좁아 보통 해당 브라우저 내부에서 프록시를 지원하는 요청만 처리합니다.

  1. 먼저 브라우저에서 출구를 확인하고 결과를 기록합니다.
  2. 그다음 명령줄 네트워크 도구로 같은 유형의 출구 조회 인터페이스에 요청해 네트워크 소속을 비교합니다.
  3. 검증할 데스크톱 또는 모바일 앱을 열고 캐시된 내용을 보는 대신 새 요청을 발생시킵니다.
  4. 클라이언트 연결 로그 또는 활성 연결 목록을 확인해 대상 도메인, 대상 주소나 해당 프로세스가 나타나는지 확인합니다.
  5. 잠시 전체 규칙으로 전환해 비교합니다. 전체 모드에서는 정상이고 분할 라우팅 모드에서만 이상하다면 문제는 대개 규칙 매칭에 있습니다.

분할 라우팅을 진단할 때는 “웹페이지가 열리는가”보다 클라이언트 로그가 더 유용합니다. 로그에서 요청이 직접 연결로 표시되면 도메인 규칙, IP 규칙, 프로세스 규칙과 규칙 우선순위를 확인해야 합니다. 도메인은 조회 후 콘텐츠 전송 네트워크 주소로 연결될 수 있으므로 도메인 규칙만 작성했는데 실제 매칭이 IP 단계에서 발생하면 예상과 다른 경로가 선택될 수 있습니다.

연결 테스트와 서비스 사용 가능성도 구분해야 합니다. 경로 핸드셰이크 성공과 출구 변경은 전송 경로가 기본적으로 성립했다는 뜻입니다. 대상 서비스에서 계속 오류가 발생한다면 계정 지역, 캐시, 브라우저 저장 데이터, 시간 설정 또는 서비스 자체 정책의 문제일 수 있습니다. 이 경우 프록시 포트를 계속 수정해도 앱 계층의 문제는 해결되지 않습니다.

대표적인 오판과 해결 방법

클라이언트만 시작하고 시스템 인계를 활성화하지 않음

많은 프록시 클라이언트는 “코어 시작”과 “시스템 프록시 설정”을 별도로 제어합니다. 전자는 로컬에서 프록시 포트만 수신 대기하며 프록시를 수동으로 입력하는 앱에 적합합니다. 후자는 시스템 프록시 설정을 변경합니다. 시스템 프록시를 읽지 않는 소프트웨어까지 더 넓게 적용하려면 클라이언트가 지원하는 경우 TUN 모드를 검토하고 가상 네트워크 카드 권한이 허용되었는지 확인하세요.

분할 라우팅 규칙이 테스트 대상을 직접 연결로 지정함

규칙 모드는 도메인, 주소, 프로세스 또는 규칙 세트에 따라 경로를 결정합니다. 출구 조회 사이트가 직접 연결 규칙에 걸리면 로컬 출구가 표시되지만 다른 대상은 이미 경로를 사용하고 있을 수 있습니다. 문제를 확인할 때는 잠시 전체 모드로 전환해 비교하고, 경로 자체에 문제가 없음을 확인한 뒤 규칙 모드로 돌아가 규칙을 수정하세요.

IPv4는 경로를 사용하지만 IPv6는 직접 연결됨

듀얼 스택 네트워크는 도메인 응답과 시스템 경로에 따라 프로토콜 버전을 선택합니다. 클라이언트가 IPv4만 인계하는데 앱이 IPv6 연결을 우선하면 조회 결과에 로컬 IPv6 출구가 노출될 수 있습니다. 해결을 위해 시스템 기능을 무작정 끄기보다는 먼저 클라이언트가 해당 트래픽을 지원하는지 확인한 뒤 TUN, 라우팅 또는 DNS 응답 정책을 조정하세요.

브라우저와 시스템이 서로 다른 DNS를 사용함

브라우저 보안 DNS는 시스템 조회 설정을 우회할 수 있으며 시스템의 비공개 DNS가 클라이언트 설정보다 우선할 수도 있습니다. 브라우저가 직접 암호화 조회를 처리할지, 클라이언트가 터널 안에서 통합 처리할지처럼 통제 가능한 방식을 하나로 정해야 합니다. 여러 계층의 설정을 동시에 켜면 작동할 수는 있지만 문제 해결은 어려워집니다.

기존 연결이 경로 전환을 따르지 않음

앱이 기존 연결을 재사용할 수 있고 연결 풀과 백그라운드 프로세스가 이전 경로를 계속 유지할 수도 있습니다. 노드를 전환한 뒤에는 테스트 앱이 새 연결을 만들도록 해야 합니다. 앱을 종료하거나 페이지를 다시 열고 관련 연결 상태를 정리하는 것이 새로 고침을 연속해서 누르는 것보다 기존 세션의 영향을 배제하는 데 효과적입니다.

  • ✅ 브라우저만 바뀌고 다른 앱은 그대로라면 시스템 프록시의 적용 범위를 확인하거나 적절한 TUN 인계를 사용하세요.
  • ✅ 전체 모드에서는 바뀌고 규칙 모드에서는 그대로라면 직접 연결 규칙, 규칙 순서와 프로세스 매칭을 확인하세요.
  • ✅ IP는 바뀌지만 DNS가 계속 로컬 네트워크를 사용한다면 클라이언트 DNS 인계와 브라우저 보안 DNS를 확인하세요.
  • ✅ IPv4는 바뀌지만 IPv6가 그대로라면 듀얼 스택 라우팅과 클라이언트의 프로토콜 버전 지원을 확인하세요.
  • ✅ 모든 출구는 정상인데 대상 서비스에 문제가 있다면 계정, 캐시, 지역 판정과 앱 계층 오류를 점검하세요.

플랫폼 차이: 같은 구성인데 결과가 다른 이유

Windows에서는 시스템 프록시와 라우팅 테이블이 서로 다른 방식으로 작동합니다. 브라우저는 시스템 프록시를 읽을 수 있지만 명령줄 프로그램은 그렇지 않을 수 있습니다. TUN 모드는 가상 네트워크 카드와 라우팅에 의존합니다. route print를 사용해 기본 경로와 가상 인터페이스가 전달에 참여하는지 확인하고, 클라이언트 로그와 함께 구체적인 요청을 판단할 수 있습니다.

macOS의 시스템 프록시는 네트워크 서비스별로 저장되며 Network Extension 기반 클라이언트는 시스템 수준의 터널을 만들 수 있습니다. 같은 장치에 여러 네트워크 확장 프로그램이 설치되어 있다면 서로 충돌하는 인계 방식을 동시에 활성화하지 마세요. scutil --proxy로 시스템 프록시 상태를 확인하고, scutil --dns로 DNS 조회 범위를 점검할 수 있습니다.

iOS에서 시스템 상태 표시줄의 VPN 표시는 구성이 활성 상태라는 것만 보여 줍니다. 브라우저, 앱 내부 요청과 DNS가 예상대로 작동하는지는 출구와 실제 서비스 요청을 통해 확인해야 합니다. 일부 앱은 캐시된 콘텐츠를 사용할 수 있으므로 경로를 전환한 뒤 새 로드를 발생시키세요. 조직에서 관리하는 앱별 VPN과 일반 개인 구성은 인계 범위도 서로 다릅니다.

Android에는 VPN 서비스, 항상 켜진 연결, 비공개 DNS와 앱 제외 목록이 함께 존재합니다. 특정 앱이 제외되면 직접 연결을 유지합니다. 비공개 DNS를 별도로 활성화하면 조회 경로도 클라이언트와 달라질 수 있습니다. 검증할 때는 열쇠나 VPN 아이콘만 보지 말고 클라이언트의 앱별 설정과 시스템 네트워크 설정을 확인해야 합니다.

Linux에서는 데스크톱 네트워크 관리자, 환경 변수 프록시와 TUN 라우팅이 함께 사용될 수 있습니다. 터미널 도구가 프록시를 사용하는지는 도구 자체 설정과 환경 변수에 따라 달라지며, 시스템 수준 라우팅은 더 넓은 범위에 영향을 줍니다. ip route로 라우팅을 확인하고 resolvectl status로 리졸버를 확인한 뒤 대상 프로세스의 연결 기록과 함께 판단하세요.

전체 재검토: 정해진 순서로 문제 범위 좁히기

결과가 서로 모순될 때 프로토콜, 노드, DNS와 분할 라우팅을 동시에 변경하지 마세요. 한 번에 변수 하나만 바꿔야 어떤 설정이 실제 결과에 영향을 주었는지 알 수 있습니다. 먼저 경로의 기본 연결성을 확인하고, 다음으로 시스템 인계, 마지막으로 앱 규칙과 DNS를 점검하는 것이 좋습니다.

  1. 연결을 끊고 브라우저, 명령줄과 시스템 DNS의 기준 상태를 기록합니다.
  2. 경로에 연결하고 클라이언트가 핸드셰이크를 완료했으며 지속적인 오류가 없는지 확인합니다.
  3. 새 브라우저 요청을 만들어 공인 IP와 네트워크 소속을 비교합니다.
  4. IPv4, IPv6와 DNS가 현재 인계 방식에 맞는지 확인합니다.
  5. 경로를 사용해야 하는 앱에서 각각 새 요청을 보내고 클라이언트 로그를 확인합니다.
  6. 앱별 결과가 다르면 시스템 프록시, TUN, 앱 제외 항목과 분할 라우팅 규칙을 차례로 확인합니다.
  7. 일상적인 규칙을 복원한 뒤 다시 테스트해 점검 중의 임시 전체 설정이 문제를 가리지 않았는지 확인합니다.
최종 판단: 대상 앱의 새 요청이 예상 출구를 사용하고 DNS 경로가 설정과 일치하며 분할 라우팅 결과가 규칙과 맞을 때에만 VPN이 해당 앱에서 실제로 작동한다고 확인할 수 있습니다. “연결됨”만 보였다면 많아야 클라이언트가 시작되었다는 사실만 확인할 수 있으며, 트래픽 경로 검증을 대신할 수 없습니다.