VPN이 연결됐는데 작동하지 않는다면 클라이언트에 표시되는 “연결됨”만 확인해서는 안 됩니다. 이 상태는 일반적으로 클라이언트와 원격 노드의 핸드셰이크가 완료됐거나 로컬 프록시 포트가 시작됐다는 뜻일 뿐입니다. 브라우저, 명령줄 도구 및 다른 앱의 트래픽이 모두 의도한 경로를 통과한다는 증거는 아닙니다. 정확히 확인하려면 출구 IP, DNS 조회, IPv6 경로와 앱별 규칙을 순서대로 점검해야 합니다.
점검 중에는 노드, 프로토콜, 시스템 설정을 자주 바꾸지 마세요. 한 번에 변수 하나만 변경한 뒤 같은 테스트를 반복해야 노드 문제인지, 라우팅 문제인지, 특정 앱이 프록시를 우회한 것인지 구분할 수 있습니다. 아래 방법은 일반적인 시스템 VPN, 시스템 프록시, TUN 모드와 Shadowsocks, VMess, Trojan, VLESS, Hysteria2 또는 TUIC 설정을 사용하는 클라이언트에 적용할 수 있습니다.
“연결됨”인데도 적용되지 않을 수 있는 이유
클라이언트가 연결을 만든 뒤에도 트래픽을 해당 터널이나 로컬 프록시 포트로 보내야 합니다. 이 과정에는 시스템 프록시, 라우팅 테이블, 가상 네트워크 어댑터, DNS 설정과 앱 자체의 네트워크 구현이 관여합니다. 어느 한 단계라도 인계에 실패하면 “클라이언트는 정상으로 표시되지만 접속 결과는 달라지지 않는” 상황이 생길 수 있습니다.
연결 모드마다 적용 범위가 다릅니다. 시스템 프록시는 시스템 프록시 설정을 읽는 앱에 주로 영향을 줍니다. 브라우저는 대개 이를 따르지만 일부 명령줄 프로그램, 게임, 다운로드 도구 또는 자체 네트워크 스택을 구현한 소프트웨어는 무시할 수 있습니다. TUN 모드는 가상 네트워크 어댑터를 통해 더 넓은 IP 트래픽을 처리하지만 라우팅 제외 항목, 로컬 네트워크 우회, 분할 라우팅 규칙과 시스템 권한의 영향을 받습니다.
| 표면적으로 보이는 현상 | 실제로 발생했을 가능성이 있는 상황 | 우선 확인할 항목 |
|---|---|---|
| 클라이언트에 연결됨으로 표시됨 | 노드 핸드셰이크만 완료되고 앱이 로컬 프록시나 터널 라우팅을 사용하지 않음 | 출구 IP, 시스템 프록시, TUN 상태 |
| 브라우저에는 적용되지만 다른 앱에는 적용되지 않음 | 브라우저는 시스템 프록시를 읽지만 다른 앱은 직접 연결함 | 앱별 규칙, 앱 프록시 설정, TUN 모드 |
| 웹 출구는 바뀌었지만 조회 결과가 이상함 | 웹 트래픽은 노드를 통과하지만 DNS는 로컬 네트워크에서 처리되거나 캐시됨 | DNS 모드, 캐시, 클라이언트 로그 |
| 일부 웹사이트의 경로가 비정상임 | 도메인 규칙, IP 규칙 또는 IPv6 경로가 예상과 다름 | 규칙 매칭 기록, IPv6, 라우팅 정책 |
| 노드를 바꿔도 결과가 달라지지 않음 | 확인 페이지가 캐시됐거나 현재 앱이 프록시 경로에 들어가지 않음 | 새로고침, 다른 앱으로 재확인, 라우팅 점검 |
프로토콜 이름 자체만으로 적용 범위를 알 수는 없습니다. Shadowsocks, VMess, Trojan, VLESS, Hysteria2 및 TUIC은 클라이언트와 노드 사이에서 데이터를 전송하는 방식을 설명합니다. 앱 트래픽이 이 연결로 들어가는지는 로컬 리스닝 포트, 시스템 프록시, TUN과 라우팅 규칙이 결정합니다. 프로토콜 핸드셰이크 성공과 전체 트래픽 인계는 별개의 문제입니다.
연결 전 네트워크 기준 상태부터 기록하기
변화를 판단하려면 연결하지 않았을 때의 상태를 먼저 알아야 합니다. 클라이언트 연결을 끄고 시스템 프록시와 TUN이 복원됐는지 확인한 다음 현재 출구 IP, 네트워크 사업자 정보, IP 유형과 대략적인 지역을 기록하세요. 이 단계는 본 사이트의 IP 확인 페이지에서 진행할 수 있습니다.
기준 테스트는 이후 확인할 동일한 앱에서 진행해야 합니다. 브라우저를 점검할 계획이라면 해당 브라우저에서 기록하세요. 문제가 명령줄 도구에서 발생했다면 명령줄에서도 별도로 테스트해야 합니다. 브라우저와 다른 앱은 서로 다른 프록시 설정을 사용할 수 있으므로 브라우저 결과로 다른 앱을 대신할 수 없습니다.
- ✅ 현재 연결을 끊고 클라이언트가 더 이상 시스템 프록시나 가상 네트워크 어댑터를 사용하지 않는지 확인하세요.
- ✅ 대상 앱에서 IP 확인 페이지를 열고 출구 IP, IP 유형과 지역을 기록하세요.
- ✅ 네트워크 경로를 바꿀 수 있는 다른 프록시 확장 프로그램이나 동시 실행 클라이언트를 종료하세요.
- ✅ 테스트 중 유선, 무선 또는 다른 네트워크로 전환하지 말고 접속 네트워크를 유지하세요.
- ✅ 대상 노드에 다시 연결한 뒤 동일한 앱과 동일한 확인 페이지로 재테스트하세요.
연결을 끊은 뒤에도 노드 출구가 표시된다면 시스템 프록시, 브라우저 확장 프로그램, 가상 네트워크 어댑터 또는 백그라운드 프로세스가 복원되지 않았을 수 있습니다. 이 상태에서는 기준 상태가 이전 설정에 오염됐으므로 연결 테스트를 계속해도 의미가 없습니다. 관련 클라이언트를 먼저 종료하고 시스템 네트워크 설정을 확인한 뒤 기준 상태를 다시 만드세요.
출구 IP 확인: 웹 트래픽 경로 점검
기준 상태를 기록한 뒤 대상 노드에 연결하고 IP 확인 페이지를 다시 여세요. 캐시의 영향을 줄이려면 페이지를 새로고침하거나 브라우저의 새 탭을 사용하세요. 출구 IP가 로컬 네트워크 주소에서 노드 출구로 바뀌고 네트워크 소속이 선택한 경로와 일치한다면 해당 브라우저 탭의 웹 요청이 프록시 경로를 통과한다고 볼 수 있습니다.
출구 IP 변화는 가장 직접적인 증거지만 현재 확인 요청의 경로만 보여 줍니다. 브라우저 확장 프로그램은 브라우저만 프록시할 수 있고, 시스템 프록시는 일부 프로그램만 읽을 수 있으며, 분할 라우팅 규칙에 따라 확인 사이트만 노드를 통과하고 다른 도메인은 직접 연결될 수도 있습니다. 따라서 실제 문제가 발생한 앱과 대상 도메인도 계속 확인해야 합니다.
출구 IP가 바뀌지 않을 때 확인할 항목
- 클라이언트가 로컬 프록시 포트만 시작하고 시스템 프록시 설정은 자동으로 적용하지 않았는지 확인하세요.
- 브라우저에 별도의 프록시가 설정되어 있지 않은지 확인하세요. 별도 설정이 시스템 구성을 덮어쓰거나 이미 작동하지 않는 이전 포트를 가리킬 수 있습니다.
- 클라이언트의 현재 모드를 확인하세요. 규칙 모드에서는 확인 도메인이 직접 연결로 판정될 수 있으므로, 진단할 때는 적용 범위가 더 명확한 모드를 임시로 사용해 보세요.
- TUN을 사용한다면 가상 네트워크 어댑터가 정상적으로 생성됐는지, 클라이언트가 라우팅 변경에 필요한 시스템 권한을 얻었는지 확인하세요.
- 실행 로그에서 요청이 프록시 규칙, 직접 연결 규칙 또는 차단 규칙과 매칭됐는지 확인하세요.
클라이언트가 구독 링크에서 설정을 가져오면 일반적으로 노드 매개변수와 그룹 규칙을 얻게 되지만, 가져오기에 성공했다고 시스템 프록시가 활성화된 것은 아닙니다. 일부 클라이언트에서는 “구독 업데이트”, “노드 선택”, “로컬 서비스 시작”과 “시스템 프록시로 설정”이 별도 작업으로 나뉩니다. 점검할 때는 구독을 반복해서 다시 가져오기보다 각 상태를 확인해야 합니다.
출구 IP가 바뀐 뒤에도 대상 서비스가 열리지 않을 때
이제 문제는 “프록시를 사용하는가”에서 “이 경로가 대상 요청에 적합한가”로 좁혀집니다. DNS 응답 이상, 대상 서비스의 출구 네트워크 제한, 관련 하위 도메인이 다른 경로를 타는 분할 라우팅, 브라우저의 이전 연결 유지 등이 원인일 수 있습니다. 프로토콜을 계속 바꾸기보다 DNS, 규칙 매칭과 앱 로그를 먼저 확인하세요.
DNS 확인: 도메인 조회 경로 점검
웹사이트에 접속하기 전에 시스템은 대개 도메인을 IP 주소로 변환해야 합니다. 웹 연결이 노드를 통과한다고 DNS 조회도 반드시 같은 경로로 전송되는 것은 아닙니다. DNS가 계속 로컬 네트워크에서 처리되면 조회 결과가 노드 지역과 맞지 않거나 일부 도메인이 비정상적으로 응답할 수 있으며, 도메인 요청이 로컬 DNS 서비스에 노출될 수도 있습니다.
DNS를 점검할 때는 시스템 화면에 어떤 서버가 입력되어 있는지만 확인해서는 안 됩니다. 많은 시스템이 로컬 스텁 리졸버를 사용하고, 클라이언트가 조회를 인계하거나 가상 주소를 반환하거나 터널 안에 조회를 캡슐화할 수도 있습니다. 화면에 로컬 주소가 표시된다고 반드시 누출을 의미하는 것은 아닙니다. 핵심은 클라이언트 로그의 처리 방식과 최종적으로 어느 쪽이 재귀 조회를 수행하는지입니다.
브라우저와 시스템 DNS가 다를 수 있습니다
최신 브라우저는 자체 암호화 DNS를 활성화할 수 있습니다. 이 경우 브라우저의 조회 경로가 운영체제와 달라질 수 있습니다. 따라서 명령줄 조회는 정상인데 브라우저만 이상하거나, 브라우저는 정상인데 다른 앱은 여전히 로컬 네트워크의 리졸버를 사용할 수 있습니다. 점검할 때는 각각 테스트하고 하나의 결과로 전체 시스템을 판단하지 마세요.
터미널에서 캐시되지 않은 대상 도메인을 조회하면서 클라이언트 로그를 함께 확인할 수 있습니다. Windows에서는 일반적으로 nslookup을 사용하고, macOS와 Linux에서는 dig 또는 nslookup을 사용할 수 있습니다. 명령 출력은 조회 결과를 보여 주고, 클라이언트 로그는 요청이 인계·전달됐는지 또는 규칙에 따라 직접 연결됐는지를 설명합니다.
nslookup example.com
dig example.com
nslookup example.com 테스트할 DNS 서버마지막 줄의 “테스트할 DNS 서버”는 실제로 확인하려는 서버 주소로 바꿔야 합니다. 공용 DNS 서비스 자체를 프록시로 간주해서는 안 됩니다. DNS는 도메인 조회만 담당하며 웹 연결의 출구를 자동으로 바꾸지 않습니다.
DNS 캐시로 인한 오판 피하기
시스템, 브라우저와 클라이언트는 모두 조회 결과를 캐시할 수 있습니다. 노드를 바꾼 직후 같은 도메인을 조회하면 이전 응답이 계속 보일 수 있습니다. 관련 탭을 닫고 앱 내부 DNS 캐시를 비운 뒤 다시 연결하여 조회하는 방법이 더 안전합니다. 시스템 캐시 삭제 명령에 익숙하지 않다면 대상 앱을 재시작하세요. 알 수 없는 네트워크 설정을 임의로 삭제하지 마세요.
- ✅ 출구 IP가 바뀐 것을 확인한 뒤 DNS를 점검하여 두 문제가 동시에 영향을 주지 않게 하세요.
- ✅ 브라우저와 시스템 명령줄을 각각 테스트하여 특정 앱만 이상한지 확인하세요.
- ✅ 클라이언트 로그에서 DNS 요청이 프록시 조회 또는 직접 조회로 처리됐는지 확인하세요.
- ✅ 브라우저에 별도의 암호화 DNS 설정이 활성화되어 있는지 확인하세요.
- ❌ 시스템 화면에 로컬 스텁 주소가 표시된다는 이유만으로 DNS 누출이라고 단정하지 마세요.
- ❌ 도메인이 조회된다는 사실을 웹 트래픽이 터널에 들어갔다는 뜻으로 보지 마세요.
IPv6 및 앱별 라우팅 점검
일부 네트워크는 IPv4와 IPv6를 함께 제공합니다. 클라이언트가 둘 중 하나만 인계하거나 시스템 기능에 따라 서로 다른 경로를 선택할 수 있습니다. IPv4는 노드를 통과하지만 IPv6는 로컬로 직접 연결되면 IPv6를 지원하는 웹사이트가 인계되지 않은 경로를 우선 사용할 수 있습니다. 그 결과 같은 브라우저에서도 웹사이트마다 결과가 달라질 수 있습니다.
IP 확인 페이지에서 현재 노출되는 주소가 IPv4인지, IPv6인지 또는 둘 다인지 확인하세요. 프로토콜 스택의 일부만 인계된다면 클라이언트에서 해당 지원을 활성화하거나 클라이언트 문서에 따라 IPv6 정책을 조정해야 합니다. 브라우저에서 결과만 숨겨서는 안 됩니다. 하위 라우팅 자체는 바뀌지 않기 때문입니다.
앱별 프록시의 일반적인 한계
앱별 기능은 보통 앱을 포함하거나 제외해 라우팅을 결정합니다. 설정할 때 “선택한 앱만 프록시를 통과”하는 의미와 “선택한 앱은 프록시를 통과하지 않음”이라는 의미를 혼동하기 쉽습니다. 클라이언트 업데이트 후 앱 경로나 프로세스 이름이 바뀌면 기존 규칙이 더 이상 매칭되지 않을 수도 있습니다.
브라우저는 여러 보조 프로세스를 실행할 수도 있습니다. 주 프로그램을 규칙에 추가해도 시스템 구성 요소가 처리하는 요청까지 모두 포함된다고 보기는 어렵습니다. 반대로 TUN 모드는 앱이 프록시 설정을 읽는지에 전적으로 의존하지 않고 네트워크 트래픽과 규칙을 기준으로 매칭하므로 시스템 프록시를 지원하지 않는 소프트웨어를 확인하는 데 더 적합할 수 있습니다. 다만 TUN도 무조건 전체 트래픽을 인계하는 것은 아닙니다. 로컬 네트워크, 예약 주소, 직접 연결 도메인과 수동 제외 항목은 여전히 우회할 수 있습니다.
| 인계 방식 | 일반적으로 포함되는 트래픽 | 누락되기 쉬운 부분 | 적합한 확인 방법 |
|---|---|---|---|
| 브라우저 확장 프로그램 | 브라우저 안에서 확장 프로그램이 처리하는 요청 | 다른 앱과 시스템 백그라운드 요청 | 브라우저와 명령줄에서 각각 출구 확인 |
| 시스템 프록시 | 시스템 프록시 설정을 따르는 앱 | 시스템 프록시를 무시하는 소프트웨어 및 일부 비웹 트래픽 | 앱별로 테스트하고 로그 확인 |
| TUN 모드 | 가상 네트워크 어댑터로 들어가 라우팅과 매칭되는 IP 트래픽 | 제외 라우팅, 로컬 네트워크 트래픽, 인계되지 않은 프로토콜 스택 | 라우팅, IPv6와 규칙 매칭 확인 |
| 앱 내 프록시 | 앱이 직접 프록시 포트로 보내는 요청 | 앱 외부 트래픽 및 설정이 포함하지 않은 연결 | 주소, 포트와 앱 로그 대조 |
클라이언트 로그로 연결 계층 문제 찾기
출구와 DNS가 모두 예상과 다르다면 노드를 반복해서 바꾸는 것보다 로그를 확인하는 편이 효과적입니다. 로그에서는 일반적으로 구독 파싱 실패, 노드 핸드셰이크 실패, 로컬 포트 충돌, 인증서 또는 시간 이상, 라우팅 기록 실패와 요청을 처리한 규칙을 구분할 수 있습니다. 읽을 때는 연결 작업이 발생한 시점부터 확인하여 이전 기록의 오류에 방해받지 않도록 하세요.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2와 TUIC은 핸드셰이크 방식이 다르고 오류 문구도 완전히 같지는 않지만 점검 순서는 비슷합니다. 먼저 설정이 완전한지 확인하고, 다음으로 노드에 연결할 수 있는지 확인한 뒤 로컬 리스닝이 성공했는지 점검하고, 마지막으로 대상 요청이 해당 아웃바운드에 들어갔는지 확인하세요. 핸드셰이크는 성공했지만 로그에 대상 요청이 없다면 원격 프로토콜보다 로컬 인계나 분할 라우팅 규칙이 원인일 가능성이 큽니다.
구독 링크 가져오기에 실패하면 먼저 링크가 완전한지, 클라이언트가 구독에 포함된 설정 형식을 지원하는지, 현재 네트워크가 구독 업데이트를 차단하고 있지 않은지 확인하세요. 가져오기에 성공한 뒤에도 유효한 노드를 선택하고 연결을 시작해야 합니다. 노드 목록이 보인다는 것만으로 노드가 사용 중이라는 뜻은 아닙니다.
플랫폼별 주요 확인 항목
Windows에서는 남아 있는 시스템 프록시 설정, 가상 네트워크 어댑터 상태와 앱이 WinHTTP 또는 자체 프록시 설정을 사용하는지 확인해야 합니다. macOS에서는 현재 네트워크 서비스의 프록시 설정을 점검하고 시스템 확장 프로그램이나 네트워크 확장 프로그램에 필요한 권한이 부여됐는지 확인하세요. Linux에서는 데스크톱 프록시 설정과 터미널 환경 변수가 서로 독립적일 수 있으므로 브라우저에 적용됐다고 터미널 명령에도 적용된다고 볼 수 없습니다.
모바일 플랫폼은 대개 시스템 VPN 인터페이스가 트래픽을 통합 처리하지만 절전 정책, 앱별 VPN, 상시 연결과 로컬 네트워크 접근 설정에 따라 결과가 달라질 수 있습니다. 백그라운드 복귀 후 작동하지 않는다면 상태 표시줄 아이콘만 보지 말고 클라이언트를 다시 열어 터널 상태와 최근 로그를 확인하세요.
“연결된 것처럼 보이는” 대표 사례
브라우저는 정상인데 다운로드 도구는 로컬 출구를 사용함
이는 대개 시스템 프록시의 적용 범위 문제입니다. 브라우저는 시스템 프록시를 읽지만 다운로드 도구는 직접 연결 네트워크 스택을 사용합니다. 다운로드 도구가 프록시를 지원하는지 확인하거나 해당 트래픽까지 처리할 수 있는 TUN 모드를 사용한 뒤 두 앱의 출구를 각각 확인하세요.
노드를 바꿔도 웹사이트 지역이 달라지지 않음
먼저 페이지 캐시와 이전 연결 재사용을 배제한 다음, 규칙 모드에서 확인 도메인을 직접 연결로 처리하는지 점검하세요. 로그에 확인 요청이 없다면 브라우저가 현재 클라이언트에 들어가지 않았을 수 있습니다. 로그에 새 노드를 통한 요청이 표시되는데도 위치 정보가 갱신되지 않는다면 지역 문구만 보지 말고 출구 IP와 네트워크 소속을 기준으로 판단하세요.
연결을 활성화한 뒤 네트워크에 전혀 접속할 수 없음
연결 끊김 보호나 유사한 차단 정책을 활성화했다면 노드 핸드셰이크가 실패할 때 로컬 직접 연결도 차단될 수 있습니다. 이는 “트래픽이 몰래 직접 연결되는” 현상이 아니라 연결을 사용할 수 없을 때 보호 규칙이 통신을 중지한 것입니다. 핸드셰이크 오류, 로컬 시간, 네트워크 권한과 노드 연결 가능성을 확인하세요.
일부 도메인만 실패함
도메인 분할 라우팅, DNS 응답 결과와 관련 하위 도메인을 우선 확인하세요. 하나의 서비스가 여러 도메인을 사용할 수 있으며 메인 사이트와 API 요청이 서로 다른 규칙에 매칭될 수 있습니다. 메인 도메인만 프록시 목록에 추가해도 모든 리소스가 같은 경로를 사용한다고 보장할 수 없습니다. 로그의 규칙 매칭 기록에서 차이를 바로 확인할 수 있는 경우가 많습니다.
직접 연결, 일반 중계와 IEPL 전용 회선의 결과가 다름
직접 연결은 기기가 원격 노드에 직접 연결하는 방식으로, 경로가 공용 인터넷 라우팅의 영향을 받습니다. 일반 중계는 먼저 중계 진입점에 연결한 뒤 출구로 전달합니다. IEPL 전용 회선은 일반적으로 진입점과 출구 사이의 전송을 전용 링크에서 처리하지만, 사용자에서 진입점까지와 출구에서 대상 서비스까지도 전체 경로의 일부입니다. 회선 유형은 라우팅 안정성에 영향을 주지만 로컬 프록시와 DNS 점검을 대신하지는 않습니다. 전용 회선을 사용해도 로컬 앱이 터널에 들어가지 않으면 출구는 바뀌지 않습니다.
반복 실행할 수 있는 확인 순서
전체 점검을 위해 여러 설정을 한꺼번에 바꿀 필요는 없습니다. 아래 순서는 관찰하기 쉬운 현상부터 시작해 시스템과 클라이언트 내부로 단계적으로 들어갑니다. 각 단계를 마칠 때마다 결과를 기록하고, 이상을 발견하면 해당 계층에서 먼저 처리하세요. 뒤의 프로토콜 매개변수를 미리 조정할 필요는 없습니다.
- 연결을 끊고 대상 앱의 출구 IP, IP 유형과 네트워크 소속을 기록해 기준 상태를 만드세요.
- 대상 노드에 연결한 뒤 동일한 앱에서 출구를 다시 확인하여 요청 경로가 바뀌었는지 확인하세요.
- 브라우저와 시스템 도구에서 DNS를 각각 확인하고 클라이언트 로그와 함께 조회 방식을 판단하세요.
- IPv4와 IPv6가 모두 예상대로 인계되는지 확인하여 듀얼 스택 환경에서 경로가 분리되지 않도록 하세요.
- 실제로 문제가 발생한 앱에서 테스트를 반복하여 시스템 프록시, TUN 또는 앱 내 프록시의 적용 범위를 확인하세요.
- 규칙 매칭 및 아웃바운드 로그를 확인해 직접 연결, 프록시, 차단과 조회 오류를 구분하세요.
- 마지막으로 노드나 프로토콜을 바꾸되 다른 조건은 유지하여 변화의 원인을 비교하세요.
문제가 계속되면 클라이언트에서 연결 시간, 플랫폼, 연결 모드, 프로토콜 유형, 오류 로그와 완료한 점검 항목을 정리한 뒤 사이트의 FAQ 또는 장애 지원 채널을 통해 계속 확인할 수 있습니다. “어떤 앱에서 어떤 도메인에 접속했고 출구가 바뀌었는지, DNS가 어떻게 처리됐는지”를 구체적으로 설명하면 단순히 “연결되지 않는다”고 말하는 것보다 문제 계층을 찾기 쉽습니다.