VPN이 제대로 작동하는지 확인할 때는 클라이언트에 “연결됨”으로 표시되는지만 봐서는 안 됩니다. 이 상태는 보통 로컬 프록시 코어가 시작되었거나 클라이언트가 선택한 회선과 핸드셰이크를 완료했다는 뜻일 뿐입니다. 브라우저, 데스크톱 프로그램, 명령줄 도구의 트래픽이 모두 원하는 출구를 통과한다는 의미는 아닙니다. 출구 IP, DNS 조회 경로, 실제 앱 동작을 함께 확인해야 신뢰할 수 있습니다.
검증하기 전에 연결 모드를 먼저 확인하세요. TUN을 활성화한 클라이언트는 보통 가상 네트워크 인터페이스를 만들고 시스템 라우팅을 인계합니다. 시스템 프록시 모드는 운영체제의 프록시 설정을 따르는 프로그램에 주로 영향을 줍니다. 브라우저 확장 프로그램은 해당 브라우저의 요청만 처리하며, 분할 라우팅 모드에서는 일부 대상은 프록시를 통과하고 나머지는 직접 연결됩니다. 모드에 따라 적용 범위가 다르므로 한 가지 결과만으로 기기 전체를 판단할 수 없습니다.
먼저 클라이언트가 실제로 무엇을 인계했는지 확인하세요
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC은 모두 프록시 트래픽을 전달할 수 있지만, 프로토콜 이름만으로 시스템 트래픽이 터널에 들어가는 방식이 결정되지는 않습니다. 적용 범위를 좌우하는 것은 시스템 프록시, TUN 가상 네트워크 카드, 앱 내 프록시, 수동으로 설정한 로컬 포트 같은 진입 방식입니다. 노드 연결이 정상이어도 프록시 진입점에 연결되지 않은 앱은 계속 네트워크에 직접 접속합니다.
| 연결 방식 | 일반적으로 적용되는 범위 | “연결됨”이 보통 의미하는 것 | 추가로 확인할 항목 |
|---|---|---|---|
| TUN 모드 | 시스템 라우팅을 통해 가상 인터페이스로 전달되는 트래픽 | 가상 인터페이스와 프록시 코어가 실행 중임 | 기본 라우팅, 제외 규칙, IPv6 경로 |
| 시스템 프록시 | 시스템 프록시 설정을 따르는 앱 | 로컬 프록시 포트가 시작되고 시스템 설정에 반영됨 | 앱이 프록시를 무시하는지, 프록시 설정이 덮어쓰이지 않았는지 |
| 브라우저 프록시 | 지정한 브라우저 또는 지정한 프로필 | 확장 프로그램 또는 브라우저 프록시 설정이 활성화됨 | 다른 앱은 직접 연결될 수 있으며 브라우저 DNS도 별도로 확인해야 함 |
| 분할 라우팅 모드 | 규칙과 일치하는 도메인, 주소 또는 앱만 | 규칙 엔진과 회선을 사용할 수 있음 | 대상 요청이 프록시 규칙과 직접 연결 규칙 중 어디에 해당하는지 |
구독 링크는 설정을 가져오는 진입점일 뿐입니다. 클라이언트에서 구독을 가져오면 회선, 프로토콜 매개변수와 분할 라우팅 규칙을 받을 수 있지만, 가져오기에 성공했다고 시스템 프록시가 켜지는 것은 아닙니다. 일부 데스크톱 클라이언트는 “노드 선택”, “코어 시작”, “시스템 프록시 설정”을 별도 작업으로 나눕니다. 모바일 플랫폼은 시스템 VPN 인터페이스를 통해 트래픽을 인계하는 경우가 많습니다. 검증할 때는 현재 모드를 먼저 확인한 뒤 테스트 결과가 예상과 맞는지 판단하세요.
- ✅ 현재 선택한 회선이 자동 선택이나 이전에 사용한 회선이 아닌지 확인했습니다
- ✅ 시스템 프록시, TUN 또는 앱 내 프록시 중 하나 이상이 활성화되어 있는지 확인했습니다
- ✅ 분할 라우팅 모드의 이름을 확인했고 테스트 도메인이 프록시와 직접 연결 중 어디로 가야 하는지 알고 있습니다
- ❌ 클라이언트의 타이머나 상태 색상만 보고 모든 앱이 이미 인계되었다고 판단함
- ❌ 구독을 가져온 뒤 회선을 시작하지 않았고 트래픽을 로컬 프록시 인터페이스로 전달하지 않음
출구 IP를 연결 전후로 비교하세요
출구 IP는 가장 직접적인 검증 항목입니다. 연결한 뒤 조회 페이지를 한 번 여는 것보다, 먼저 VPN 연결을 끊고 현재 공인 출구 주소, 네트워크 사업자와 대략적인 지역을 기록하는 것이 정확합니다. 그런 다음 테스트 페이지를 닫고 원하는 회선에 연결한 뒤 다시 조회하세요. 주소와 네트워크 소속이 예상대로 바뀌었다면 현재 테스트 요청이 프록시 출구를 통과했을 가능성이 높습니다.
- 클라이언트를 잠시 연결 해제하고 별도로 프록시를 설정했을 수 있는 브라우저 확장 프로그램도 종료하세요.
- 브라우저에서 공인 IP를 조회하고, 직접 연결 상태의 기준으로 주소·네트워크 소속·지역 정보를 기록하세요.
- 확인할 회선에 연결하고 시스템 프록시 또는 TUN 모드가 활성화되었는지 확인하세요.
- 새 시크릿 창에서 다시 조회해 기존 페이지 캐시나 장시간 연결의 영향을 피하세요.
- 다른 앱에서도 요청을 보내 동일한 프록시 출구가 반환되는지 확인하세요.
연결 전후의 주소가 완전히 같아도 바로 노드 장애로 단정하지 마세요. 브라우저에 별도 프록시 확장 프로그램이 켜져 있거나 시스템 프록시 반영에 실패했을 수 있고, 대상 사이트가 연결 전에 만든 장시간 연결을 재사용했을 수도 있습니다. 관련 페이지를 닫았다가 다시 열거나 확장 프로그램이 없는 브라우저로 테스트하면 이런 변수를 배제할 수 있습니다.
분할 라우팅 규칙도 확인해야 합니다. 규칙 모드에서는 국내 사이트, 로컬 네트워크 주소 또는 지정 서비스가 직접 연결되도록 설계될 수 있으므로 직접 연결 대상에서 기존 네트워크 출구가 보이는 것은 이상이 아닙니다. 프록시 규칙과 명확히 일치하는 대상을 선택해 검증하거나, 잠시 전체 프록시로 전환해 비교하세요. 테스트가 끝나면 원래 분할 라우팅 모드로 돌아가 불필요한 트래픽이 계속 우회하지 않도록 합니다.
브라우저 결과는 바뀌었지만 다른 프로그램은 그대로인 경우
이 경우 프록시가 브라우저에만 적용되었을 가능성이 큽니다. 브라우저 확장 프로그램이 켜져 있거나 데스크톱 클라이언트가 시스템 프록시만 설정했는데 대상 프로그램이 시스템 프록시를 무시하는 것이 흔한 원인입니다. 게임 런처, 동기화 도구, 명령줄 프로그램과 자체 네트워크 스택을 사용하는 일부 소프트웨어는 시스템 프록시 설정을 읽지 않을 수 있습니다. 앱에 프록시를 별도로 설정하거나 트래픽을 인계할 수 있는 TUN 모드로 전환하세요.
DNS 요청이 예상한 경로로 조회되는지 확인하세요
출구 IP가 바뀐 뒤에도 DNS를 확인해야 합니다. DNS는 도메인 이름을 네트워크 주소로 변환합니다. 웹 요청은 프록시 회선을 통과하지만 도메인은 로컬 네트워크의 리졸버가 처리하면 접속 대상과 조회 경로가 분리됩니다. 이를 보통 DNS 유출이라고 합니다. 다만 분할 라우팅을 명확히 설계한 환경에서는 직접 연결 도메인에 로컬 DNS를, 프록시 도메인에 원격 DNS를 사용하는 것이 정상일 수 있으므로 규칙의 예상 동작과 함께 판단해야 합니다.
브라우저의 DNS 검사 페이지에서는 조회에 참여한 서버와 네트워크 소속을 확인할 수 있습니다. 회선에 연결한 뒤에도 프록시 도메인이 계속 로컬 네트워크의 리졸버를 사용한다면 클라이언트의 DNS 모드, 원격 조회 옵션, 브라우저 자체의 암호화 DNS 설정을 점검하세요. 브라우저가 운영체제 리졸버를 우회할 수도 있고, 클라이언트가 가상 DNS나 도메인 스니핑으로 분할 라우팅을 지원할 수도 있습니다. 두 설정이 충돌하면 결과를 해석하기 어려워집니다.
시스템 수준에서는 먼저 현재 DNS 설정을 확인할 수 있습니다. 다음 명령은 조회만 수행하며 네트워크 설정을 변경하지 않습니다:
Windows
ipconfig /all
nslookup example.com
macOS
scutil --dns
nslookup example.com
Linux
resolvectl status
nslookup example.comnslookup은 현재 조회에 사용된 리졸버를 보여주지만 브라우저의 실제 조회 경로를 완전히 나타내지는 않을 수 있습니다. 브라우저에서 자체 보안 DNS를 사용하면 시스템 명령과 브라우저 검사 결과가 다를 수 있습니다. 따라서 시스템과 브라우저 양쪽의 조회 결과를 확인하고, 클라이언트 로그에 대상 도메인이 나타나는지도 함께 살펴보세요.
IPv6 때문에 결과가 모순처럼 보이는 이유
기기에는 IPv4와 IPv6 네트워크 기능이 동시에 있을 수 있습니다. 클라이언트가 한 프로토콜만 인계하고 브라우저가 다른 사용 가능한 경로를 우선 선택하면 일부 요청은 회선을 통과하고 일부는 직접 연결될 수 있습니다. 이때 IP 조회 페이지의 출구가 예상과 다르게 표시될 수 있으며, DNS가 반환한 주소 유형도 최종 경로에 영향을 줍니다.
점검할 때는 클라이언트가 IPv6 지원을 명시하는지, TUN 인터페이스가 해당 라우팅을 받았는지, 분할 라우팅 규칙이 두 주소 유형을 모두 처리하는지 확인하세요. IPv6 비활성화를 영구적인 해결책으로 간주하지 마세요. 클라이언트가 올바르게 인계하도록 설정하거나, 관리되지 않는 경로가 대상 앱에 제공되지 않도록 명확히 제한하는 편이 안전합니다.
브라우저가 기기 전체를 대신하지 않도록 앱별로 검증하세요
브라우저 테스트가 통과했다는 것은 현재 브라우저 요청이 예상한 출구를 통과했을 가능성이 높다는 뜻일 뿐입니다. 회의 소프트웨어, 클라우드 저장소, 코드 도구, 데스크톱 클라이언트나 터미널 프로그램을 사용한다면 각각 확인해야 합니다. 앱마다 프록시를 읽는 방식이 다를 수 있고 시스템 설정을 우회해 직접 연결할 수도 있습니다.
- 대상 회선을 연결한 상태로 유지하고 브라우저 출구가 바뀌었는지 확인하세요.
- 테스트할 앱을 완전히 종료한 뒤 다시 시작해 연결 전에 만들어진 세션을 재사용하지 않도록 하세요.
- 클라이언트 연결 로그에서 해당 앱이 대상에 접근할 때 새 요청이 발생하는지 확인하세요.
- 클라이언트가 프로세스별 또는 규칙별 일치 결과를 지원한다면 요청이 프록시 규칙에 들어갔는지 확인하세요.
- 직접 연결로 전환한 뒤 같은 작업을 반복하고 앱 동작과 로그가 달라지는지 비교하세요.
로그는 “열리는가”보다 판단에 더 유용합니다. 어떤 서비스가 직접 연결과 프록시 환경에서 모두 정상적으로 열리면 페이지 이용 가능 여부만으로는 경로를 확인할 수 없습니다. 클라이언트 로그에 대상 도메인, 대상 주소, 규칙 이름과 선택한 회선이 표시되면 앱 동작을 실제 전달 경로와 연결해 볼 수 있습니다. 로그를 공유하기 전에는 구독 링크, 인증 정보와 전체 설정 내용을 삭제하세요.
명령줄 도구도 별도 설정을 사용하는 경우가 많습니다. 터미널 환경 변수, 도구 자체의 프록시 매개변수와 시스템 프록시는 서로 다를 수 있습니다. 브라우저 출구는 바뀌었는데 터미널 요청이 직접 연결된다면 현재 터미널 세션이 이전 프록시 환경을 물려받았는지, 사용하는 도구가 시스템 프록시를 명시적으로 무시하는지 확인하세요. 수정한 뒤에는 기존 세션에서 반복 테스트하기보다 터미널을 새로 열어 확인하는 편이 안정적입니다.
연결됨으로 표시되지만 트래픽이 회선을 통과하지 않는 일반적인 원인
시스템 프록시가 제대로 반영되지 않음
클라이언트 코어는 노드에 정상적으로 연결되었지만 운영체제에는 이전 프록시, 수동 프록시 또는 자동 설정 스크립트가 남아 있을 수 있습니다. 이 경우 클라이언트에는 연결됨으로 표시되지만 어떤 앱도 로컬 프록시 포트로 요청을 보내지 않습니다. 먼저 다른 프록시 도구를 종료하고 시스템 네트워크 설정을 확인한 뒤 클라이언트에서 시스템 프록시를 다시 활성화하세요.
TUN 라우팅이 다른 네트워크 도구에 의해 덮어써짐
가상 머신, 컨테이너, 기업용 네트워크 클라이언트와 다른 가상 네트워크 카드가 라우팅 우선순위를 바꿀 수 있습니다. TUN 인터페이스는 존재하지만 기본 트래픽이 우선순위가 더 높은 라우팅으로 빠져나가는 경우입니다. 네트워크 경로를 변경하는 프로그램을 잠시 종료하고 회선을 다시 연결한 다음 하나씩 다시 실행해 충돌 원인을 확인하세요.
규칙에서 테스트 대상을 직접 연결로 판단함
도메인 규칙, 주소 규칙과 지역 규칙은 서로 다른 결과를 낼 수 있습니다. 대상 도메인이 DNS를 통해 주소로 변환된 뒤 다른 주소 규칙에 의해 덮어써질 수도 있습니다. 규칙 목록을 읽는 것보다 클라이언트 로그의 최종 일치 규칙을 확인하는 편이 정확합니다. 전체 모드에서는 정상인데 규칙 모드에서만 문제가 생긴다면 대개 회선 핸드셰이크가 아니라 규칙과 DNS의 조합에 원인이 있습니다.
브라우저가 이전 연결이나 별도 DNS 설정을 유지함
최신 브라우저는 연결을 재사용하며 자체 암호화 DNS를 활성화할 수도 있습니다. VPN에 연결한 뒤 기존 페이지를 새로 고침해도 새 네트워크 세션이 만들어진다는 보장은 없습니다. 브라우저를 완전히 종료하고 다시 연 다음 새 시크릿 창에서 테스트하고 시스템 DNS와 브라우저 DNS 결과를 비교하면 오판을 줄일 수 있습니다.
구독을 업데이트했지만 이전 설정을 계속 사용함
구독을 업데이트하면 회선 매개변수나 규칙이 바뀔 수 있지만, 일부 클라이언트는 새 노드로 수동 전환하거나 설정을 다시 불러와야 적용합니다. 구독 목록에 새 내용이 보이는지만 확인하지 말고 현재 활성 설정의 이름, 업데이트 시간과 선택한 회선을 확인하세요. 구독 링크는 민감한 인증 정보이므로 공개 검사 사이트나 스크린샷에 붙여 넣지 마세요.
정해진 순서로 최종 점검을 완료하세요
“클라이언트에는 연결됨으로 표시되지만 접속 경로가 바뀌지 않는” 상황에서는 프로토콜이나 노드를 계속 바꾸기보다 진입점부터 출구까지 단계별로 확인하는 것이 가장 효과적입니다. 한 번에 하나의 조건만 바꿔야 어떤 설정이 결과를 변화시켰는지 알 수 있습니다.
- ✅ 현재 설정·회선·연결 모드가 예상과 일치하는지 확인
- ✅ 회선을 끊고 직접 연결 출구를 기록한 뒤, 연결 후 새 창에서 다시 비교
- ✅ 프록시 대상의 DNS 리졸버와 클라이언트 DNS 설정 확인
- ✅ 브라우저·데스크톱 앱·명령줄 프로그램을 각각 테스트
- ✅ 로그에서 최종 규칙, 대상 주소와 실제 선택된 회선 확인
- ✅ IPv6, 가상 네트워크 카드와 다른 네트워크 도구로 인한 우회 확인
- ❌ 노드·프로토콜·DNS·분할 라우팅 규칙을 동시에 변경해 변수를 추적할 수 없게 함
- ❌ 지역 표시가 부정확하다는 이유만으로 연결이 적용되지 않았다고 판단함
출구 IP가 바뀌지 않으면 먼저 트래픽 진입점과 시스템 프록시를 확인하세요. 출구는 바뀌었지만 DNS 경로가 이상하면 원격 조회, 브라우저 DNS와 분할 라우팅 정책을 점검합니다. 브라우저는 정상인데 특정 앱만 문제라면 해당 앱이 시스템 프록시를 읽는지와 TUN 인계가 필요한지를 확인하세요. 일부 대상만 이상하다면 규칙 일치 결과와 주소 유형을 중점적으로 살펴보세요. 이 순서로 클라이언트 진입점, DNS, 라우팅 또는 앱 설정 중 문제 계층을 좁힐 수 있습니다.