VPN 초보자라면 먼저 용어마다 무엇을 담당하는지 알아두세요. 구독은 설정을 가져오고, 노드는 연결 지점이며, 프로토콜은 통신 방식을 정하고, 트래픽 분할은 요청이 어느 경로로 갈지 결정합니다. 설정을 가져왔는데 웹페이지가 열리지 않는다면 노드를 계속 바꾸기보다 각 단계를 차례로 확인하세요.

일상적으로 말하는 ‘VPN 클라이언트’가 실제로는 기존의 전체 기기 가상 사설망이 아닌 프록시 프로토콜을 실행하는 경우도 있습니다. 앱에 VPN 표시가 나타나더라도 시스템 가상 네트워크 인터페이스를 통해 트래픽을 처리하는 것일 수 있습니다. 따라서 상태 아이콘만 보지 말고 실제 설정과 요청 경로를 확인해야 합니다.

용어 비교: 설정에서 요청 출구까지

용어 실제 의미 혼동하기 쉬운 점
구독 링크 노드 또는 전체 설정을 가져오고 업데이트하는 주소 결제 주기를 뜻하지 않으며, 트래픽 분할 규칙이 반드시 포함되는 것도 아닙니다
노드 클라이언트에서 선택할 수 있는 연결 매개변수의 모음 노드 이름이 실제 출구 위치를 나타낸다고 단정할 수 없습니다
프로토콜 클라이언트와 서버가 데이터를 협의하고 전송하는 방식 프로토콜 이름은 속도나 안정성 등급이 아닙니다
회선 연결 지점, 중간 전송 네트워크, 출구로 구성된 경로 같은 지역과 같은 프로토콜이어도 경로는 다를 수 있습니다
트래픽 분할 규칙 도메인이나 주소 등의 조건에 따라 직접 연결, 프록시 또는 차단을 선택하는 규칙 규칙 모드라고 해서 모든 해외 사이트가 자동으로 프록시를 사용하는 것은 아닙니다
DNS 도메인을 네트워크 주소로 변환하는 방식 웹페이지 연결이 프록시를 거쳐도 DNS 조회까지 프록시를 거친다는 뜻은 아닙니다
TUN 모드 가상 네트워크 인터페이스로 트래픽을 받아 처리하는 방식 처리 범위는 라우팅, 제외 항목, 클라이언트 구현에 따라 달라집니다

모든 요소를 하나의 경로로 이어서 이해해 보세요. 클라이언트가 구독 정보를 읽어 노드와 규칙을 가져오고, 앱이 요청을 보내면 규칙에 따라 연결 방식이 선택됩니다. 프록시가 필요한 요청은 해당 노드의 프로토콜과 회선을 거쳐 출구로 전달됩니다. DNS는 목적지 주소를 확인하는 과정에 관여하므로 별도로 설정해야 할 수도 있습니다.

구독과 노드: 설정을 가져오는 곳과 네트워크 출구는 다릅니다

구독을 업데이트하면 무엇이 바뀔까요?

‘요금제 구독’은 서비스의 결제 방식을, ‘클라이언트 구독’은 설정을 가져오는 방법을 뜻하며 서로 다른 개념입니다. 클라이언트는 구독 주소에서 노드 목록을 가져올 수도 있고, 정책 그룹·DNS·규칙이 포함된 전체 설정을 가져올 수도 있습니다. 제공되는 형식에 따라 달라집니다.

주소를 복사한 뒤 클라이언트의 구독 또는 설정 가져오기 메뉴에 추가하고, 업데이트를 실행한 다음 해당 설정을 활성화하세요. 링크를 브라우저 주소창에 붙여넣는 것만으로 자동 가져오기가 되는 것은 아닙니다. 업데이트와 활성화도 별개입니다. 클라이언트에 설정을 여러 개 저장할 수 있다면 현재 실행 중인 설정이 이전 버전일 수 있습니다.

노드에는 일반적으로 서버 주소, 포트, 인증 정보, 프로토콜과 전송 매개변수가 포함됩니다. 이 중 하나를 직접 수정하면 설정이 맞지 않을 수 있습니다. 노드 이름에 표시된 지역, 배율, 회선 설명은 제공자가 붙인 표기이며 프로토콜이 검증한 사실은 아닙니다. 지역별 기능을 확인하려면 회선 설명과 연결 후 출구 정보를 함께 살펴보세요.

프로토콜 비교: 호환성을 먼저, 네트워크 환경은 그다음

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC은 서로 다른 프록시 프로토콜 또는 프로토콜 방식으로, 이름만 바꿔 쓸 수 있는 것이 아닙니다. 클라이언트가 해당 프로토콜과 구체적인 설정을 지원해야 하며, 서버에도 이에 맞는 매개변수가 설정되어 있어야 합니다. 노드의 프로토콜 항목을 다른 이름으로 바꾼다고 연결되는 것은 아닙니다.

프로토콜, 전송 계층, 회선은 구분해서 살펴봐야 합니다. WebSocket은 전송 방식이고 TLS는 보안 계층을 제공하며 IEPL은 네트워크 전송 경로를 설명하므로 서로 같은 계층의 대체 항목이 아닙니다. 클라이언트가 특정 프로토콜을 지원하더라도 해당 프로토콜의 모든 전송 조합을 지원하는 것은 아닙니다. 가져오기 오류가 나면 먼저 코어 버전과 형식 요구 사항을 확인하세요.

결론: 초보자는 서비스에서 명시적으로 제공하고 클라이언트가 분명히 지원하는 설정을 우선 사용하세요. 프로토콜의 신구만으로 속도를 판단할 수 없습니다. 실제 사용 환경은 로컬 네트워크, 회선 혼잡, 서버 자원, 접속하려는 사이트에 따라서도 달라집니다.

회선 유형: 직접 연결, 중계, IEPL

직접 연결은 일반적으로 기기가 해외 프록시 서버에 바로 연결되고, 서비스 제공자가 마련한 별도의 중계 지점을 거치지 않는다는 뜻입니다. 통신사 라우팅까지 전혀 거치지 않는다는 의미는 아닙니다. 사용 환경은 로컬 네트워크의 국제 출구와 통신사 간 연동 상황에 비교적 직접적인 영향을 받습니다.

중계 연결은 먼저 하나의 접속 지점에 연결한 뒤, 해당 지점에서 다음 노드 또는 출구로 트래픽을 전달합니다. ‘중계’는 전달 구간이 하나 더 있다는 뜻일 뿐 전용 회선을 사용한다거나 직접 연결보다 성능이 좋다는 보장은 아닙니다. 접속 지점에 연결할 수 있는지, 접속 지점에서 출구까지의 경로와 혼잡도는 어떤지 함께 고려해야 합니다.

IEPL은 국제 이더넷 전용 회선으로, 회선의 특정 전송 구간에 사용되는 경우가 많습니다. 이는 네트워크 전송 서비스를 설명하는 말이지 프록시 프로토콜이 아니며, 기기에서 대상 사이트까지 모든 구간이 전용 회선이라는 뜻도 아닙니다. 기기에서 접속 지점까지, 출구에서 대상 사이트까지는 다른 네트워크를 이용할 수 있습니다.

회선을 선택할 때 지역 이름은 주로 출구 위치와 대상 서비스의 지역 설정이 맞는지 판단하는 데 도움이 됩니다. 가까운 지역이 통신사 경로까지 가장 원활하다는 보장은 없고, 지연 시간이 짧다고 지속적인 다운로드 속도가 더 빠른 것도 아닙니다. 회선 목록을 확인할 때는 이름만 보지 말고 접속 지점, 출구, 회선 유형과 실제 용도를 함께 비교하세요.

분할 라우팅 모드: 글로벌 모드와 규칙 모드의 선택

규칙 모드는 일반적으로 설정된 순서에 따라 요청을 검사하고 직접 연결, 프록시 정책 그룹 또는 차단 동작으로 전달합니다. 규칙은 도메인, 대상 주소, 프로세스 또는 다른 조건을 기준으로 삼을 수 있으며, 실제 지원 범위는 클라이언트에 따라 다릅니다. 어떤 규칙에도 해당하지 않는 요청은 보통 기본 규칙으로 전달됩니다. 기본 규칙이 직접 연결인지 프록시인지는 현재 설정에서 확인하세요.

글로벌 모드는 일반적으로 프록시 코어에 전달된 요청을 하나의 정책으로 처리합니다. 기기의 모든 트래픽이 처리된다는 뜻은 아닙니다. 시스템 프록시를 사용하지 않는 앱, 제외된 라우팅 또는 클라이언트가 처리할 수 없는 트래픽은 다른 경로로 전송될 수 있습니다.

시스템 프록시는 앱에 프록시 설정을 제공하며, 이를 따를지는 앱에 달려 있습니다. TUN 모드는 가상 네트워크 인터페이스로 트래픽을 처리하므로 적용 범위가 더 넓지만 라우팅과 DNS를 올바르게 설정해야 합니다. Android 및 iOS 클라이언트는 시스템 VPN 인터페이스를 이용하는 경우가 많고, 데스크톱 클라이언트는 시스템 프록시와 TUN을 별도 옵션으로 제공하는 경우가 많습니다.

일상적으로 사용할 때는 신뢰할 수 있는 규칙 설정부터 시작하세요. 특정 사이트에 문제가 생기면 연결 기록에서 어떤 규칙이 적용됐고 어떤 정책 그룹이 실제로 선택됐는지 먼저 확인합니다. 원인을 파악하기 위해 잠시 글로벌 모드로 바꿔 볼 수 있습니다. 접속이 복구된다면 노드 자체에 계속 문제가 있다고 단정하기보다 트래픽 분할 규칙을 확인하세요.

DNS 누출과 출구 확인

DNS 누수는 예상한 경로로 처리되어야 할 도메인 조회가 의도하지 않은 경로로 전송되는 현상을 말합니다. 예를 들어 로컬 네트워크의 DNS 서버에 직접 조회를 요청할 수 있습니다. 이로 인해 조회한 도메인 정보가 노출될 수 있지만, HTTPS 본문까지 복호화된다는 뜻은 아닙니다.

검사 결과에 로컬 DNS 서버가 표시되어도 설정 의도에 따라 해석해야 합니다. 직접 연결할 도메인을 로컬 DNS로 조회하는 것은 의도적인 트래픽 분할일 수 있습니다. 프록시를 사용해야 할 도메인이 여전히 로컬 DNS로 조회되는 경우에는 추가 확인이 필요합니다. 브라우저의 암호화 DNS, 시스템 DNS 설정, 클라이언트 DNS 설정이 각각 적용될 수 있으므로 옵션 하나만 바꾸고 모두 일치한다고 가정하지 마세요.

출구 주소 확인은 검사를 요청한 연결 경로만 보여줍니다. 브라우저에서 프록시 출구가 표시되어도 다른 앱이 같은 경로를 사용한다는 뜻은 아닙니다. DNS를 검사할 때도 일반 DNS 조회, 브라우저 자체 조회, 프록시 도메인의 처리 방식을 구분해야 합니다. 결과가 서로 맞지 않으면 검사 페이지를 계속 새로 고치기보다 클라이언트 연결 기록을 확인하는 편이 효과적입니다.

초보자를 위한 설정: 가져오기부터 문제 해결까지

  1. 클라이언트 호환성을 확인하세요. 사용 가이드에서 플랫폼과 설정 형식을 확인하고, 관리 화면의 클라이언트 다운로드에서 적합한 클라이언트를 받으세요.
  2. 구독을 가져와 활성화하세요. 해당 형식에 맞는 주소를 사용하고, 업데이트가 완료됐는지, 노드가 표시되는지, 방금 가져온 설정이 활성화되어 있는지 확인하세요.
  3. 노드와 정책을 선택하세요. 실제 사용하는 정책 그룹에서 노드를 선택하세요. 노드 목록에서 선택 상태만 바꾸고 정책 그룹은 수정하지 않는 일이 없도록 확인하세요.
  4. 트래픽이 처리되는지 확인하세요. 플랫폼에서 필요한 권한을 허용하고 시스템 프록시 또는 TUN 상태를 확인한 다음 대상 앱을 열어 테스트하세요.
  5. 출구와 DNS를 확인하세요. 출구 검사, DNS 조회 검사, 연결 기록을 함께 살펴 실제 경로를 확인하세요. 상태 아이콘만을 유일한 근거로 삼지 마세요.
  6. 단계별로 문제를 해결하세요. 가져오기에 실패하면 형식과 주소를 확인하고, 연결에 실패하면 네트워크·인증·프로토콜을 확인하세요. 일부 사이트에서만 문제가 생기면 규칙, DNS, 사이트 자체 제한을 살펴보세요.

점검 순서를 한 문장으로 정리하면 이렇습니다. 설정을 가져왔는지, 노드에 연결되는지, 요청이 클라이언트로 들어왔는지, 규칙에 따라 어디로 전달됐는지 확인하세요. 이 순서대로 살펴보면 프록시 도구 여러 개를 동시에 켜는 것보다 문제를 찾기 쉽습니다. 추가 지원이 필요하면 관리 화면의 문의 티켓으로 민감 정보를 가린 자료를 보내주세요.