출구 IP: 가장 먼저 확인할 수 있는 항목
연결한 뒤 먼저 사이트 내 IP 조회 페이지를 열어 현재 출구 IP와 위치 정보를 확인합니다. 판단 기준은 하나입니다. 위치가 로컬 통신사가 아니라 노드 소재지로 나와야 합니다. 위치가 여전히 로컬 도시로 표시되고 조직명이 로컬 인터넷 사업자로 나온다면 트래픽이 터널로 들어가지 않은 것이며, 클라이언트의 상태 표시등은 프로세스가 실행 중이라는 것만 보여줄 뿐입니다.
출구 IP에서는 두 가지 세부 사항을 더 봐야 합니다. 첫째는 IPv6입니다. 브라우저와 운영체제는 기본적으로 IPv6를 우선 사용합니다. 클라이언트가 IPv4만 처리한다면 페이지에 로컬 IPv6 주소가 그대로 표시될 수 있어 'IP가 바뀐 것처럼' 보이지만 실제로는 절반만 바뀐 상태입니다. 둘째는 WebRTC입니다. 일부 브라우저는 WebRTC를 통해 기기 주소나 로컬 네트워크 주소를 노출하며, 이는 프록시 적용 여부와 무관하므로 브라우저 설정에서 제한하거나 꺼야 합니다.
IPv4에서만 적용된 연결은 IPv6를 지원하는 대상 사이트에서 곧바로 로컬 네트워크로 되돌아갑니다. 자체 점검 시 IP 조회 페이지가 IPv4와 IPv6 결과를 함께 보여주는지 확인하고, 양쪽 위치 정보가 일치하는지 다시 확인하세요.
같은 기기에 브라우저 프록시 확장 프로그램이 함께 설치되어 있다면 확장의 우선순위가 보통 시스템 프록시보다 높습니다. 이때 시스템 수준에서는 이미 트래픽을 처리하고 있는데 브라우저는 확장에 설정된 회선을 계속 사용해 양쪽 출구가 달라지고, 잘못된 결론을 내리기 쉽습니다. 검증할 때는 확장을 먼저 비활성화하거나, 확장을 하나도 설치하지 않은 브라우저 프로필로 한 번 대조해 보세요.
DNS 누출 자체 점검
DNS 조회는 '접속하려는 도메인을 누가 해석하는가'를 결정합니다. 기본 상태에서는 조회가 로컬 통신사로 전달됩니다. 프록시가 적용되면 조회도 노드 쪽에서 나가야 합니다. 조회가 여전히 로컬 DNS로 전달되면 해석 요청 자체가 접속 대상을 드러내고, 동시에 로컬에 더 가까운, 대상 사이트에는 적합하지 않은 CDN 결과를 받을 수 있습니다.
자체 점검 방법은 DNS 누출 검사 페이지를 여는 것입니다. 페이지에 해석에 참여한 서버 IP와 소속이 표시됩니다. 합격 상태는 리졸버가 노드 소재지에 있거나, 최소한 출구 IP와 같은 지역에 있는 경우입니다. 목록에 로컬 통신사 리졸버만 가득하다면 해석이 프록시를 타지 않은 것입니다.
클라이언트의 해당 옵션은 보통 '원격 DNS', 'DNS 프록시', '누출 방지' 등으로 불립니다. 클라이언트마다 표현은 다르지만 역할은 같습니다. 해석 요청을 터널 반대편 리졸버로 넘기는 것입니다. 켠 뒤에는 반드시 다시 연결한 다음 검사 결과를 확인하세요. 설정만 바꾸고 재연결하지 않으면 적용되지 않는 경우가 많습니다.
규칙 모드에서는 국내 도메인을 로컬 DNS로 해석해 직결하는 것 자체가 설계 목표입니다. 누출 여부는 프록시를 타는 도메인을 기준으로 판단해야 합니다. 대상 사이트는 프록시로 가는데 해석은 로컬에 남아 있는 경우가 손봐야 할 상황입니다.
또 하나는 앱에 내장된 암호화 DNS입니다. 브라우저나 운영체제에서 DoH / DoT를 켜면 해석 요청이 별도의 HTTPS 연결로 나가 클라이언트가 설정한 DNS를 우회할 수 있습니다. 이런 옵션은 브라우저 개인정보 설정에 있으니 검증할 때는 먼저 끄고, 기준 상태를 확인한 뒤 다시 켤지 결정하세요.
앱별 라우팅과 분할 라우팅 검증
출구 IP와 DNS가 모두 정상이어도 일부 앱만 프록시를 타지 않는 경우가 있습니다. 원인은 두 가지입니다. 앱이 시스템 프록시 설정을 읽지 않거나, 분할 라우팅 규칙이 대상 도메인을 직결로 판정한 경우입니다.
시스템 프록시(HTTP / SOCKS 프록시)는 앱이 시스템 설정을 직접 읽어야 동작합니다. 브라우저, 시스템 업데이트, 대부분의 명령줄 도구는 이 설정을 읽지만 일부 데스크톱 앱과 게임 클라이언트는 읽지 않습니다. 이런 프로그램까지 처리하려면 클라이언트가 TUN 또는 가상 네트워크 어댑터 모드를 제공해 네트워크 계층에서 트래픽을 가져와야 하며, 대신 더 높은 권한이 필요하고 일부 시스템에서는 네트워크 구성 요소를 추가로 설치해야 합니다.
분할 라우팅 검증 방법은 다음과 같습니다. 먼저 전역 모드로 기본 경로가 정상인지 확인하고, 다시 규칙 모드로 전환한 뒤 실제로 사용할 서비스를 하나씩 열어 봅니다. 전역 모드에서는 정상인데 규칙 모드에서 특정 서비스만 이상하다면 문제는 회선이 아니라 규칙에 있습니다. 규칙 목록에서 보통 매칭된 항목과 경로를 확인할 수 있으니, 도메인이나 IP 대역 기준으로 규칙을 하나 추가하면 됩니다.
앱별 프록시는 일부 플랫폼에서 사용할 수 있습니다. 켜면 선택한 앱만 터널을 통과하고 나머지는 직결됩니다. 업무용 프로그램을 제외하고 싶을 때 적합한 방식이지만, 검증할 때 오판하기 쉽습니다. 선택하지 않은 앱이 로컬 IP로 표시되는 것은 정상 동작이며 오류가 아닙니다.
구독 가져오기도 함께 확인해야 합니다. 구독 링크가 갱신되면 클라이언트의 노드 목록도 함께 새로 고쳐져야 합니다. 노드 이름과 개수가 오랫동안 그대로라면 구독을 가져오지 못했거나 클라이언트가 이전 설정 파일을 계속 사용 중일 수 있습니다. 노드 목록의 지연 시간이 시간 초과로 표시된다면 핸드셰이크가 완료되지 않은 것이므로 다른 회선으로 다시 측정해 보세요.
연결은 되었는데 프록시를 타지 않는 여섯 가지 경우
아래 경우들은 점검 과정에서 가장 자주 나오는 유형이며, 공통점은 클라이언트 화면에 '연결됨'으로 표시된다는 것입니다.
- 시스템 프록시가 기록되지 않았습니다. 일부 클라이언트는 '시스템 프록시 설정'을 직접 켜야 하며, 회선에 연결하는 것만으로는 시스템 설정이 바뀌지 않아 브라우저 외 트래픽은 모두 직결됩니다.
- 브라우저 확장이 시스템 프록시를 덮어썼습니다. 확장의 우선순위가 더 높아 두 개의 출구가 동시에 존재하고, IP 조회 결과는 현재 어느 쪽을 쓰는지에 따라 달라집니다.
- IPv6 우선. 터널이 IPv4만 처리할 때 IPv6를 지원하는 대상 사이트는 브라우저가 로컬 네트워크로 직접 연결합니다.
- 분할 규칙이 직결로 매칭되었습니다. 규칙은 도메인 기준으로 매칭되며, 대상 도메인이 직결 그룹으로 분류되면 출구는 당연히 로컬입니다.
- 앱이 시스템 프록시를 무시합니다. 데스크톱 앱, 게임 클라이언트, 일부 동기화 도구는 시스템 프록시 설정을 읽지 않으므로 TUN 모드로 처리해야 합니다.
- 앱에 내장된 암호화 DNS 또는 독자 네트워크 스택. 해석과 연결 모두 시스템 설정을 거치지 않아 시스템 프록시가 적용되지 않습니다.
플랫폼별 클라이언트 차이
Windows: 시스템 프록시와 TUN 두 가지 모드
시스템 프록시 모드는 시스템 프록시 항목을 변경하며 브라우저와 대부분의 앱이 이를 따릅니다. TUN 모드는 가상 네트워크 어댑터를 만들어 시스템 프록시를 읽지 않는 프로그램까지 처리하지만 관리자 권한이 필요합니다. 모드를 바꾼 뒤에는 반드시 다시 연결해야 합니다. 그렇지 않으면 이전 모드의 설정이 그대로 적용됩니다.
macOS와 iOS: 권한 승인이 없으면 연결되지 않은 것과 같습니다
macOS에서 네트워크 확장을 사용하는 클라이언트는 시스템 설정에서 권한을 요청합니다. 권한이 없으면 연결은 성공한 것처럼 보이지만 실제로는 트래픽을 처리하지 않습니다. iOS는 Network Extension을 사용하므로 첫 연결 시 시스템 팝업에서 확인해야 하며, 거부하면 클라이언트 내부의 스위치는 작동하지 않습니다.
Android: 앱별 목록을 직접 확인해야 합니다
Android는 시스템의 VpnService를 기반으로 하며 마찬가지로 팝업 승인이 필요합니다. 앱별 프록시가 더 세분화되어 있으므로 검증할 때는 전체 스위치만 보는 것보다 체크 목록을 항목별로 확인하는 편이 확실합니다.
프로토콜 차이: TCP와 UDP는 동작이 다릅니다
Shadowsocks, VMess, Trojan, VLESS는 TCP가 중심이며 UDP 지원 여부는 구현에 따라 다릅니다. Hysteria2, TUIC는 QUIC 기반이라 전 구간을 UDP로 전송합니다. 클라이언트에서 보이는 ss://, vmess://, trojan:// 접두사가 각기 다른 프로토콜에 대응합니다. 네트워크에서 UDP를 엄격히 제한하면 노드는 선택되지만 계속 연결되지 않는 증상이 나타나며, 이때 TCP 계열 프로토콜로 바꿔 보면 문제가 어느 계층에 있는지 판별할 수 있습니다.
자체 점검 표와 판단 기준
위 점검 항목을 하나의 표로 묶었으니, 증상에 맞춰 대조해 처리하면 됩니다.
| 증상 | 가능한 원인 | 대처 |
|---|---|---|
| IP 조회에 로컬 통신사가 표시됨 | 시스템 프록시가 기록되지 않았거나 TUN이 시작되지 않음 | 프록시 모드를 확인하고 다시 연결 |
| IP는 정상인데 리졸버가 여전히 로컬 | DNS가 프록시를 타지 않음 | 원격 DNS / 누출 방지 옵션을 켜고 다시 연결 |
| 브라우저에서만 프록시가 적용됨 | 시스템 프록시 모드로는 다른 프로그램을 커버하지 못함 | TUN / 가상 네트워크 어댑터 모드로 전환 |
| 대상 사이트가 여전히 로컬로 판정됨 | 분할 라우팅 규칙이 직결로 매칭됨 | 규칙 목록을 확인하고 도메인 규칙 추가 |
| IPv6 주소가 여전히 로컬 | 터널이 IPv4만 처리함 | 시스템 IPv6를 끄거나 IPv6 프록시 사용 |
| 노드는 선택되지만 계속 시간 초과 | 프로토콜 또는 포트가 제한됨 | 다른 회선으로 바꾸거나 TCP 계열 프로토콜 사용 |
아래 항목을 하나씩 대조해 모두 충족해야 실제로 적용된 것입니다.
- ✅ 출구 IP의 위치가 노드 소재지이며, IPv4와 IPv6 결과가 일치합니다.
- ✅ DNS 검사 페이지의 리졸버가 출구 IP와 같은 지역에 있습니다.
- ✅ 전역 모드에서 대상 서비스가 정상이고, 규칙 모드로 돌아와도 정상입니다.
- ✅ 시스템 프록시를 읽지 않는 데스크톱 앱도 TUN 모드에서는 노드 IP로 표시됩니다.
- ❌ 브라우저에서만 노드 IP가 보이고 시스템 수준 앱은 여전히 로컬 주소입니다. 시스템 프록시만 기록되었고 전역 트래픽을 처리하지 못한 상태입니다.
- ❌ 검사 페이지는 프록시 경유로 나오는데 리졸버가 모두 로컬 통신사입니다. DNS가 함께 이동하지 않은 상태입니다.
판단 기준: 클라이언트 상태 표시등을 볼 필요는 없고, 세 가지 증거가 동시에 성립하면 됩니다. 출구 IP가 노드 쪽에 있을 것, DNS 해석이 노드 쪽에서 이루어질 것, 실제로 사용하는 앱이 터널을 통과할 것. 셋 중 하나라도 빠지면 위 표를 따라 항목별로 점검하세요. 문제는 대개 회선 자체가 아니라 프록시 모드와 분할 라우팅 규칙에 있습니다.
여러 회선을 비교해야 할 때 선택 범위는 100+ 국가와 220+ 회선입니다. 기기 수 제한이 없다는 것은 컴퓨터와 모바일 기기를 동시에 접속해 비교할 수 있다는 뜻이며, 한쪽은 기본 설정을 유지하고 다른 쪽은 분할 모드로 바꾸면 차이가 아주 선명하게 드러납니다. 구독 기간 중 특정 회선이 장기간 시간 초과라면 클라이언트를 반복 재설치하는 것보다 회선을 바꾸는 편이 시간을 아낍니다.
자체 점검을 모두 통과했는데도 대상 서비스가 여전히 이상하다면, 문제는 대개 로컬 연결이 아니라 대상 사이트 쪽 정책에 있습니다. 이때는 같은 지역의 다른 회선으로 교차 검증하는 편이 클라이언트 설정을 계속 고치는 것보다 효율적입니다. 조작을 하나씩 재현해야 한다면 사용 가이드의 클라이언트 설정 설명을 참고하세요.