설정 구조 · 개념도

  • 연결 유입: 시스템 프록시 / TUN 모드
  • 트래픽 판별: 라우팅 규칙 / DNS
  • 연결 처리: 프로토콜 / 전송 보안 / 코어
  • 설정 출처: 구독 / 공유 링크

개념 관계를 나타낸 그림이며 클라이언트 조작 화면이 아닙니다.

프로토콜 · 코어 · 클라이언트 설정

V2Ray 용어 정리

자주 쓰이는 용어를 여섯 가지 범주로 살펴봅니다. 먼저 설정이 어느 단계에 속하는지 파악한 뒤 클라이언트의 실제 항목과 비교해 보세요.

프로토콜은 연결 방식을 정하고, 코어는 설정을 실행하며, 클라이언트는 관리 화면을 제공합니다. 이름이 비슷해도 기능이 같거나 매개변수를 서로 바꿔 쓸 수 있다는 뜻은 아닙니다.

사용 문서 보기 →

통신 방식과 보안 계층

프로토콜 및 전송

프로토콜 이름은 전체 설정의 일부일 뿐입니다. 전송 방식, 인증 매개변수, 전송 보안 옵션도 서로 맞아야 합니다.

프로토콜 및 전송VMess
Project V 생태계의 프록시 프로토콜로, 사용자 ID 등의 매개변수로 인증하고 자체적인 데이터 보호 기능을 제공합니다. 실제 연결에는 전송 방식과 외부 보안 설정도 필요하므로 프로토콜 이름만으로 설정 호환 여부를 판단할 수 없습니다. 가져온 뒤 연결되지 않는다면 노드 별칭만 바꾸지 말고 사용자 ID, 서버 시간, 전송 매개변수를 확인하세요.
프로토콜 및 전송VLESS
가벼운 프록시 프로토콜로, 자체적으로 페이로드를 암호화하지 않으며 보통 TLS 또는 REALITY 등의 방식과 함께 사용합니다. VLESS, 전송 방식, 보안 계층은 각각 별도의 설정 항목이므로 VLESS라는 이름만 보고 나머지 매개변수를 추정할 수 없습니다. 사용자 ID, 서버 이름 및 서버가 요구하는 다른 옵션을 일치시켜야 합니다.
프로토콜 및 전송Trojan
일반적으로 TLS로 연결을 보호하고 비밀번호로 인증하는 프록시 프로토콜입니다. 클라이언트의 비밀번호, 서버 이름, 전송 설정은 서버 측과 일치해야 합니다. 서버 포트에 연결된다고 해서 인증까지 성공한 것은 아닙니다. 인증서 오류가 발생하면 서버 이름과 시스템 시간을 확인하고, 인증서 검증을 끄는 방법을 일반적인 해결책으로 사용하지 마세요.
프로토콜 및 전송REALITY
Xray 생태계의 전송 보안 방식으로, VLESS 연결 설정에 자주 사용되지만 구독 형식이나 GUI 클라이언트는 아닙니다. 공개 키, 서버 이름, Short ID 등의 매개변수를 서버 측 설정과 일치시켜야 합니다. 구체적인 항목은 클라이언트와 코어 버전에 따라 다를 수 있습니다. 지원되지 않는 옵션이 있으면 코어의 지원 여부부터 확인하고 프로토콜 이름만 보고 매개변수를 임의로 삭제하거나 수정하지 마세요.

프로젝트 관계와 실행 구성 요소

코어 및 생태계

V2Ray, V2Fly, Xray, v2rayN은 서로 다른 계층에 속합니다. 프로젝트, 실행 코어, 클라이언트의 이름을 구분해서 이해해야 합니다.

코어 및 생태계Project V
V2Ray 등의 네트워크 도구를 중심으로 형성된 프로젝트와 기술 생태계로, 프로토콜 구현, 트래픽 처리, 관련 도구를 포함합니다. 특정 데스크톱 창이나 설치 프로그램을 뜻하는 이름이 아니며, 특정 기능의 사용 가능 여부를 바로 판단할 수도 없습니다. 클라이언트를 선택할 때는 실제로 사용하는 코어와 해당 코어가 지원하는 설정 범위를 확인해야 합니다.
코어 및 생태계V2Fly
V2Ray 코어를 지속적으로 관리하는 커뮤니티 프로젝트로, 오픈 소스 프록시 도구 생태계의 일부입니다. Android 클라이언트 v2flyNG는 이 코어 계열을 사용하지만 클라이언트 화면의 이름과 코어 기능은 별개의 개념입니다. 설정 사용 가능 여부는 구체적인 버전의 지원 범위를 확인해야 하며, 다른 포크의 옵션을 그대로 가져와서는 안 됩니다.
코어 및 생태계Xray
V2Ray 코드 기반에서 출발해 독자적으로 발전한 프록시 코어 프로젝트로, 자체적인 프로토콜 구현과 기능 개선을 제공합니다. v2rayNG는 Xray 코어를 사용하며 REALITY 등의 설정에도 해당 코어의 지원이 필요합니다. Xray와 V2Fly는 기술적 배경을 공유하지만 설정 세부 사항과 지원 범위가 항상 같은 것은 아닙니다.
코어 및 생태계코어
프로토콜 연결, 라우팅 판단, DNS 처리 등을 실제로 수행하는 구성 요소입니다. GUI 클라이언트는 설정 편집, 연결 선택, 실행 상태 관리를 담당합니다. 클라이언트 업데이트와 코어 업데이트는 별도로 진행될 수 있으며, 화면에 특정 항목이 있어도 현재 코어가 이를 인식한다는 보장은 없습니다. 오류가 발생하면 클라이언트 이름, 코어 종류, 오류 내용을 각각 기록하세요.

계속 읽기: V2Ray 코어 차이와 클라이언트 선택 →

설정 내용과 업데이트 출처

구독 및 노드

구독은 설정을 가져오고 업데이트하는 기능이며, 노드는 가져온 연결 항목입니다. 어느 쪽도 프록시 연결이 이미 수립되었다는 뜻은 아닙니다.

구독 및 노드구독
주소를 통해 여러 연결 설정을 가져오고, 이후 업데이트할 때 해당 출처의 내용을 다시 읽는 방식입니다. 응답은 인코딩된 텍스트, 공유 링크 모음 또는 클라이언트가 지원하는 다른 형식일 수 있으므로 웹페이지에서 주소가 열린다고 해서 클라이언트에서 가져올 수 있는 것은 아닙니다. 구독 주소에는 접근 자격 정보가 포함될 수 있으니 스크린샷, 로그, 문의 내용에 전체 주소가 노출되지 않도록 하세요.
구독 및 노드노드
클라이언트에서 선택할 수 있는 연결 설정 항목입니다. 보통 서버 주소, 포트, 프로토콜, 인증 정보, 전송 매개변수를 포함합니다. 노드 별칭은 구분을 위한 이름일 뿐이며, 한 서버에 여러 설정이 있을 수도 있고 이름이 달라도 같은 장비일 수 있습니다. 노드를 선택한 뒤에는 코어를 실행하고 적절한 방식으로 앱 트래픽을 유입해야 합니다.
구독 및 노드구독 그룹
클라이언트에서 구독 주소와 가져온 항목을 출처별로 정리하는 관리 단위입니다. 출처와 업데이트 범위를 구분하는 데 유용합니다. 그룹 이름은 정리 목적으로만 사용되며 프로토콜, 프록시 연결 방식, 라우팅 결과를 바꾸지는 않습니다. 주소를 수정하거나 그룹을 삭제하기 전에 포함된 항목의 출처를 확인하세요. 구독으로 생성된 노드를 직접 편집하면 다음 업데이트 때 변경 사항이 덮어써질 수도 있습니다.

구독 업데이트 실패: 주소·형식·네트워크 순서로 확인 →

매칭 조건과 트래픽 경로

라우팅 및 트래픽 분기

먼저 앱 트래픽이 클라이언트에 유입되는지 확인한 다음, 규칙이 어떤 경로를 선택하는지 살펴보세요. 트래픽 유입 설정과 라우팅 설정은 서로 대체할 수 없습니다.

라우팅 및 트래픽 분기라우팅 규칙
도메인, 대상 IP, 포트, 프로토콜 등의 조건에 따라 연결을 어느 경로로 보낼지 정하는 설정입니다. 일반적으로 규칙은 순서대로 적용되므로 앞의 범위가 넓은 조건이 뒤의 구체적인 규칙보다 먼저 적용될 수 있습니다. 일치하는 규칙이 없는 트래픽은 기본 경로의 영향을 받습니다. 예상과 다른 결과가 나오면 규칙 순서, 사용할 수 있는 대상 정보, 기본 처리 방식을 함께 확인하세요.
라우팅 및 트래픽 분기트래픽 분기
규칙에 따라 트래픽을 직접 연결, 프록시, 차단 등의 경로로 나누는 처리 방식이며 독립적인 프로토콜은 아닙니다. 시스템 프록시는 일부 앱이 클라이언트에 연결되는 방식을 제어하고, 트래픽 분기는 클라이언트에 들어온 뒤의 처리 방법을 결정합니다. 글로벌 프록시는 일반적으로 더 넓은 범위의 트래픽에 프록시 경로를 선택한다는 뜻이지만, 모든 앱이 자동으로 가로채지는 것은 아닙니다.
라우팅 및 트래픽 분기GeoIP
IP 주소 집합을 기준으로 트래픽을 매칭하는 데이터 및 규칙 형식으로, 집합은 지역이나 다른 용도별로 구성될 수 있습니다. 주소 할당과 서버 배치는 바뀔 수 있으므로 매칭 결과가 서버의 실시간 위치를 절대적으로 증명하지는 않습니다. 관련 규칙을 수정할 때는 클라이언트가 실제로 불러온 데이터 파일과 태그, 도메인 확인 정책이 예상과 일치하는지 확인하세요.
라우팅 및 트래픽 분기GeoSite
도메인을 서비스나 범주별 집합으로 분류해 라우팅 규칙에서 참조하는 데이터 방식입니다. IP 주소를 기준으로 매칭하는 GeoIP와는 다릅니다. 특정 태그를 사용할 수 있는지, 어떤 도메인이 포함되는지는 실제로 불러온 데이터의 출처와 내용에 따라 달라집니다. 앱이 IP 주소를 직접 사용하거나 클라이언트가 도메인 정보를 얻지 못하면 도메인 집합 규칙만으로는 대상을 매칭하지 못할 수 있습니다.

라우팅 모드와 트래픽 분기 설정 방법 보기 →

트래픽 유입 및 식별

클라이언트 설정

옵션 이름은 플랫폼과 버전에 따라 달라질 수 있습니다. 다른 기기의 스위치 상태를 그대로 따라 하기보다 기능의 적용 범위를 이해하는 것이 중요합니다.

클라이언트 설정시스템 프록시
운영체제가 앱에 제공하는 프록시 설정으로, 일반적으로 클라이언트가 로컬에서 열어 둔 프록시 포트를 가리킵니다. 이 설정을 따르는 앱만 사용하며, 앱이 자체적으로 프록시를 지정하거나 시스템 설정을 무시할 수도 있습니다. 클라이언트를 종료한 뒤 시스템 프록시가 닫힌 포트를 계속 가리키면 해당 앱이 인터넷에 연결되지 않을 수 있으므로 시스템 설정을 복구해야 합니다.
클라이언트 설정TUN 모드
가상 네트워크 인터페이스로 트래픽을 받아 프록시 구성 요소에서 처리하는 연결 방식입니다. 시스템 프록시를 따르지 않는 일부 앱의 트래픽도 처리할 수 있습니다. 추가 권한이 필요할 수 있으며 시스템 라우팅, DNS, 다른 가상 네트워크 소프트웨어와 상호작용할 수 있습니다. 활성화한 뒤에도 실제로 가로채는 범위를 확인해야 합니다. TUN 스위치를 켰다고 연결이 반드시 되거나 모든 트래픽이 같은 경로를 이용하는 것은 아닙니다.
클라이언트 설정로컬 수신 포트
클라이언트가 로컬 기기에서 프록시 요청을 받는 포트로, 시스템이나 앱이 연결할 때 사용합니다. 원격 서버의 포트와는 별개의 설정입니다. 앱을 수동으로 설정한다면 주소, 포트, HTTP 또는 SOCKS 등의 프록시 유형을 모두 수신 설정에 맞춰야 합니다. 수신 주소는 접근 가능한 범위에도 영향을 주므로 일반적인 로컬 사용에서는 다른 기기에 함부로 공개하지 마세요.
클라이언트 설정트래픽 스니핑
연결 초기 단계에서 확인할 수 있는 정보로 프로토콜이나 대상 도메인을 식별해 라우팅 판단 등을 돕는 기능입니다. 앱이 전송하는 모든 내용을 복호화하는 기능은 아니며 모든 연결에서 도메인을 알아낼 수 있는 것도 아닙니다. 사용 여부와 대상 정보 수정 허용 여부는 코어 설정 및 규칙의 목적에 맞춰 판단하세요. 모든 연결 문제를 해결하는 만능 스위치로 여겨서는 안 됩니다.

Android VPN 모드와 앱별 프록시 설정 →

DNS 경로와 연결 테스트

네트워크 기초

DNS 조회 성공, 포트 연결 가능 여부, 실제 요청 완료는 서로 다른 결과입니다. 테스트 지표는 테스트 대상, DNS 조회 방식, 트래픽 유입 모드를 함께 고려해 해석해야 합니다.

네트워크 기초DNS
도메인을 IP 주소 등의 레코드로 변환하는 시스템으로, 보통 앱이 연결을 시작하기 전에 작동합니다. 시스템 DNS, 클라이언트 내장 DNS, 앱이 자체적으로 사용하는 암호화 DNS는 서로 다른 경로를 사용할 수 있으므로 한 곳을 수정해도 다른 설정에는 영향을 주지 않을 수 있습니다. 문제를 확인할 때는 먼저 요청을 누가 시작하고 어디에서 조회하는지, 조회 결과가 이후 라우팅에 어떻게 사용되는지 파악하세요.
네트워크 기초FakeDNS
앱에 가상 주소를 반환하고 내부에 도메인과 가상 주소의 매핑을 저장하는 DNS 처리 방식입니다. 트래픽이 클라이언트에 다시 유입되면 매핑을 이용해 대상 도메인을 복원하므로 가상 주소를 실제 서버 주소로 취급하지 않습니다. DNS 조회, 트래픽 가로채기, 매핑 복원이 서로 연동되어야 하며 캐시가 남아 있거나 트래픽 유입이 불완전하면 연결 문제가 발생할 수 있습니다.
네트워크 기초DNS 유출
정해진 경로로 처리되어야 할 DNS 요청이 다른 DNS 서버로 전송되는 현상입니다. 유출 여부는 예상한 정책을 기준으로 판단해야 합니다. 일부 도메인을 규칙에 따라 로컬에서 조회하는 것이 반드시 잘못된 설정을 뜻하지는 않습니다. 확인할 때는 시스템, 브라우저, 클라이언트, 다른 앱의 DNS 설정을 함께 살펴보고, 단일 출구 주소 테스트만으로 결론을 내리지 마세요.
네트워크 기초실제 연결 지연 시간
선택한 프록시를 통해 테스트 대상에 연결할 때 걸리는 시간입니다. 측정에 포함되는 단계는 클라이언트의 테스트 방식에 따라 다릅니다. TCP 연결만 확인하는 Tcping보다 실제 요청에 가깝지만, 테스트 주소, DNS, 대상 서버의 응답에도 영향을 받습니다. 지연 시간이 낮아도 다운로드 처리량이 높다는 뜻은 아니며, 테스트에 성공해도 모든 웹사이트와 앱이 정상 작동한다고 볼 수는 없습니다.