VPN 연결 확인: 출구 IP와 DNS 검사 초보자 가이드

연결 상태와 실제 트래픽은 다릅니다

먼저 ‘무엇에 연결됐는지’를 구분해야 합니다. 시스템 프록시를 사용하는 클라이언트는 시스템 프록시 설정을 따르는 프로그램의 트래픽을 주로 처리합니다. 가상 네트워크 어댑터나 시스템 VPN 인터페이스를 사용하는 클라이언트는 라우팅 규칙에 따라 트래픽을 처리합니다. 화면상 비슷해 보여도 적용 범위는 다를 수 있습니다. 브라우저에서 경로를 이용한다고 해서 게임이나 터미널, 다른 앱도 같은 출구를 사용한다고 단정할 수는 없습니다.

분할 터널링을 사용하면 결과가 달라질 수 있습니다. 일부 도메인은 직접 연결하고 다른 도메인은 프록시를 통하도록 설정할 수 있으며, 앱별 분할 설정에서는 지정한 프로그램만 터널을 이용합니다. 검사 페이지가 직접 연결 규칙에 해당하면 원래 IP가 표시될 수 있습니다. 이는 연결 실패가 아니라 설정에 따른 결과일 수 있습니다. 검사 전에 현재 모드와 해당 도메인에 적용된 규칙을 확인하세요.

판단 기준은 설정과 일치해야 합니다. 전체 트래픽을 처리하도록 설정했다면 처리 범위를 확인하고, 분할 터널링을 사용한다면 대상 앱에 예상한 규칙이 적용되는지 확인하세요. 분할 설정을 사용하는 모든 요청에 같은 출구가 표시되어야 하는 것은 아닙니다.

출구 IP: 연결 전후 비교 방법

출구 IP는 검사 사이트가 요청을 받을 때 확인하는 외부 주소입니다. 가정용 공유기가 기기에 할당하는 내부 IP 주소는 여기서 확인할 공인 출구 IP가 아닙니다. 브라우저 주소창 옆의 보안 표시도 웹사이트 연결에 HTTPS를 사용한다는 뜻일 뿐, 요청이 VPN을 통과했는지는 알려주지 않습니다.

1. 클라이언트 연결을 끊고 VPNKD의 IP 검사 페이지를 엽니다. 공인 IP, 네트워크 정보, 표시된 지역을 기록하세요. IPv4와 IPv6를 따로 표시하는 페이지라면 각각 기록합니다.
2. 선택한 경로에 연결하고 트래픽 처리 모드를 확인한 다음 검사 페이지를 새로고침합니다. 화면에 남아 있는 이전 결과만 보지 않도록 주의하세요.
3. 주소가 바뀌었는지 비교하고 네트워크 정보를 확인합니다. 지역 정보 데이터베이스의 갱신이 늦을 수 있으므로 도시 이름이 다르다는 이유만으로 경로가 작동하지 않는다고 단정하지 마세요.
4. 별도의 검사 사이트에서도 확인합니다. 결과가 다르면 각 요청에 서로 다른 분할 규칙이 적용됐는지, IPv4와 IPv6 중 다른 주소 체계를 사용했는지 살펴보세요.
5. 연결을 끊고 다시 검사해 원래 출구로 돌아오는지 확인합니다. 문제를 재현할 수 있도록 연결 전후 결과를 기록해 두세요.

주소가 바뀌지 않았다면 먼저 검사 요청이 프록시를 이용하도록 설정되어 있는지 확인하세요. 로그에 직접 연결로 표시되면 규칙을 점검합니다. 프록시로 표시되는데도 결과가 예상과 다르면 브라우저 자체 프록시 설정, 확장 프로그램, 기존 연결, 클라이언트 오류 메시지를 확인하세요. ‘표시된 지역이 바뀌지 않았다’는 이유만으로 경로를 계속 바꾸지는 마세요.

IPv4 출구는 바뀌었는데 IPv6에 기존 네트워크가 표시된다면 IPv6 라우팅을 따로 확인해야 합니다. 클라이언트가 일부 주소 체계만 처리하거나 규칙에 따라 IPv6를 직접 연결할 수 있습니다. 먼저 클라이언트의 IPv6 지원 및 트래픽 처리 안내를 확인한 뒤 설정을 조정하세요. 모든 상황에 IPv6를 끄는 것이 정답은 아닙니다.

DNS 검사: 리졸버가 다르다고 누출은 아닙니다

DNS는 도메인 이름을 네트워크 주소로 변환합니다. DNS 검사에서는 브라우저가 테스트 도메인에 요청을 보내고, 서버가 관찰한 결과를 바탕으로 재귀 리졸버를 추정합니다. 이 결과는 DNS 조회 경로를 파악하는 단서이지, 기기에서 실행 중인 모든 프로그램의 DNS 기록은 아닙니다.

DNS 누출은 지정한 경로를 이용해야 하는 DNS 요청이 실제로는 다른 경로를 통해 전송되는 경우를 말합니다. 문제가 되는지는 예상한 설정에 따라 달라집니다. 브라우저가 별도의 암호화 DNS를 사용한다면 다른 DNS 서비스가 표시되는 것이 설정에 맞는 결과일 수 있습니다. 암호화 DNS 연결 자체가 프록시를 통할 수도 있습니다. 리졸버의 브랜드나 국가만으로 전송 경로를 판단할 수는 없습니다.

• 먼저 클라이언트의 DNS 설정을 확인하고, 원격 DNS 조회가 필요한지, 직접 연결 도메인에 별도의 리졸버를 지정했는지 살펴보세요.
• 브라우저의 보안 DNS 설정이 시스템 DNS 설정을 덮어쓸 수 있습니다. 시스템 DNS 주소만 바꾸지 말고 브라우저 설정과 클라이언트 정책을 함께 확인하세요.
• 네트워크를 그대로 유지한 채 연결 해제 상태와 연결 상태의 검사 결과를 비교합니다. 연결 후에도 현재 네트워크에서 제공하는 리졸버가 나타난다면 확인이 필요한 단서입니다. 다만 로그와 설정을 함께 살펴야 합니다.
• 새 테스트 도메인을 사용하거나 검사를 다시 실행하세요. 캐시된 결과가 있으면 DNS 조회가 다시 발생하지 않아 검사 항목이 빠지거나 결과가 그대로인 것처럼 보일 수 있습니다.

암호화 DNS는 기기와 DNS 서비스 사이의 조회 내용을 보호하지만 웹 접속의 출구를 자동으로 바꾸지는 않습니다. 반대로 웹 트래픽이 프록시를 이용한다고 해서 모든 DNS 요청도 프록시를 통하는 것은 아닙니다. ‘도메인을 누가 조회하는지’와 ‘연결이 어디로 나가는지’를 따로 확인하세요.

앱별 확인: 브라우저 외의 앱도 점검하세요

브라우저 검사는 해당 브라우저에서 보낸 요청만 보여줍니다. 평소 사용하는 도구가 제대로 작동하는지 확인하려면 실제 대상 앱에서 새 네트워크 요청을 보내고, 클라이언트의 연결 목록이나 로그를 함께 살펴보세요. 클라이언트에서 규칙 이름과 아웃바운드 정보가 제공된다면 해당 요청이 직접 연결인지 선택한 프록시 경로인지 확인합니다.

Windows와 macOS의 시스템 프록시 설정을 모든 프로그램이 자동으로 따르는 것은 아닙니다. 터미널 프로그램은 프록시 환경 변수를 읽을 수도, 무시할 수도 있습니다. Linux의 데스크톱 프록시 설정도 모든 프로세스에 공통으로 적용되는 것은 아닙니다. 가상 네트워크 어댑터 모드는 더 많은 IP 트래픽을 처리하는 경우가 많지만, 라우팅과 제외 항목, 클라이언트 기능의 영향을 받습니다.

iOS와 Android 클라이언트는 시스템 VPN 인터페이스를 통해 트래픽을 처리할 수 있지만, 구체적인 범위는 설정에 따라 달라집니다. Android 클라이언트에는 앱별 포함 또는 제외 옵션이 있을 수 있습니다. 한 플랫폼의 사용 절차를 다른 플랫폼에 그대로 적용하지 마세요. 앱이 기존 연결을 유지 중이라면 경로를 바꾼 뒤 연결을 다시 수립하고 검사해야 합니다.

• ✅ 사용할 앱을 열고 캐시된 페이지를 보는 대신 실제 네트워크 작업을 수행하세요.
• ✅ 클라이언트 로그에서 해당 요청을 찾아 도메인, 규칙, 아웃바운드 경로를 확인하세요.
• ✅ 앱 전용 프록시 설정, 브라우저 확장 프로그램, 시스템 프록시가 서로 덮어쓰는지 확인하세요.
• ✅ 모드를 바꾼 뒤 앱 연결을 새로 수립하고 같은 네트워크에서 다시 확인하세요.
• ❌ 특정 웹사이트에 접속된다는 사실만으로 모든 기기와 앱의 트래픽이 처리된다고 판단하지 마세요.

일부 앱에서는 외부에 출구 IP를 표시하지 않습니다. 이때는 연결 로그와 규칙 적용 여부, 기능 동작을 함께 살펴보고 결론이 적용되는 범위를 명확히 하세요. 대상 웹사이트에서 접속을 거부하더라도 계정 상태, 지역 정책, 출구 IP의 평판 때문일 수 있으므로 기기의 연결이 적용되지 않았다고 단정할 수는 없습니다.

‘연결됨인데 경로를 이용하지 않는’ 문제 해결 순서

문제를 확인할 때는 먼저 트래픽이 클라이언트에 들어오는지 살펴본 다음 어디로 전달되는지 확인하세요. 구독 정보를 새로고침하거나 노드를 계속 바꾸는 것보다 문제를 찾기 쉽습니다. 한 번에 한 가지만 변경하고 요청을 새로 보내 결과를 기록하세요. 설정을 복구할 때도 근거를 남길 수 있습니다.

1. 설정이 선택됐는지 확인합니다. 구독 링크를 가져왔다고 해서 설정이 적용되거나 노드를 선택하고 트래픽 처리를 활성화한 것은 아닙니다. 현재 설정과 선택한 경로, 연결 오류를 확인하세요. 구독 링크에는 접속 정보가 포함되어 있으므로 공개 스크린샷이나 게시판에 올리지 마세요.
2. 시스템 연결 지점을 확인합니다. 시스템 프록시 모드에서는 프록시가 활성화되어 있는지 확인하고, 가상 네트워크 어댑터 모드에서는 권한과 라우팅 상태를 살펴보세요. 다른 네트워크 도구가 설정을 변경할 수 있으므로 테스트할 때 여러 도구가 같은 연결 지점을 두고 충돌하지 않게 하세요.
3. 규칙이 적용됐는지 확인합니다. 대상 도메인이 직접 연결된다면 규칙 순서, 앱별 제외 항목, 기본 아웃바운드를 확인하세요. 모드를 잠시 바꿔 문제를 찾을 수는 있지만, 모든 트래픽을 장기간 같은 경로로 보내야 한다는 뜻은 아닙니다.
4. DNS 조회가 성공했는지 확인합니다. 로그에 조회 실패가 표시되면 먼저 DNS 경로를 확인하세요. 출구 IP 검사에 문제가 없더라도 대상 도메인이 정상적으로 조회된다는 뜻은 아닙니다.
5. 아웃바운드 연결을 확인합니다. 요청이 프록시에 들어간 뒤 연결 오류가 발생한다면 노드, 네트워크, 클라이언트 호환성을 확인하세요. 오류 메시지만으로 경로 구성이나 서버 장애를 단정할 수는 없습니다.
6. 전체 근거를 다시 확인합니다. 설정을 바꾼 뒤 출구 IP, DNS, 대상 앱을 다시 검사하세요. 한 항목이 정상으로 돌아왔다고 다른 항목의 문제까지 해결된 것으로 간주하지 마세요.

프로토콜 이름만으로 연결 여부를 확인할 수는 없습니다. Shadowsocks, VMess, Trojan, VLESS 등의 설정이 트래픽을 처리하고 정상적으로 작동하는지는 클라이언트 지원 여부, 전송 설정, 서버 설정에도 달려 있습니다. 경로에 직접 연결, 중계, 전용 회선이라고 표시되어 있어도 기기의 출구 IP 검사를 대신할 수 없습니다. IP의 지역 표시만으로 구체적인 경로 구성을 추정할 수도 없습니다.

브라우저 IP 노출과 검사 결과의 한계

일부 검사 도구는 WebRTC 주소도 표시합니다. WebRTC는 실시간 통신에 사용되며 일반 웹 요청과 다른 경로로 연결될 수 있습니다. 내부 네트워크 주소, 개인정보 보호를 위해 처리된 로컬 주소, 공인 주소를 구분해야 합니다. 로컬 주소가 보인다고 해서 공인 트래픽이 경로를 우회한다고 입증된 것은 아닙니다.

예상과 다른 공인 주소가 검사에 나타나면 브라우저 정책, 관련 트래픽에 대한 클라이언트 지원, 라우팅 설정을 확인하세요. 여러 확장 프로그램을 설치해 해결하려 하지 마세요. 확장 프로그램은 브라우저에만 영향을 줄 수도 있고 기존 프록시 설정과 충돌할 수도 있습니다. 설정을 바꾼 뒤에는 실제 앱에서도 다시 확인해야 합니다.

이 검사는 테스트 당시의 경로만 보여주며 영구적인 상태를 보장하지 않습니다. 네트워크를 바꾸거나 클라이언트를 업데이트하고, 규칙을 조정하거나 설정을 다시 가져온 뒤에는 재검사하는 것이 좋습니다. IP가 바뀌어도 개인정보 보호가 보장되는 것은 아닙니다. 로그인 계정, 웹사이트 쿠키, 앱 권한으로도 사용자를 식별할 수 있습니다.