Project V
V2Ray 생태계의 배경생태계 이해: Project V는 V2Ray 오픈소스 프록시 기술 체계를 이해하는 출발점이지, 특정 그래픽 클라이언트의 이름은 아닙니다. 흔히 말하는 ‘V2Ray 설정’은 관련 프로토콜과 도구를 통칭할 수 있지만, 프로젝트마다 지원하는 설정 항목은 다릅니다. 가이드를 읽을 때는 생태계 이름과 실제로 실행되는 코어 이름을 구분해 확인하세요.
설정 참고
6개 주제 · 용어 25개
V2Ray 용어 정리
코어, 프로토콜 및 설정
용어 찾아보기: 설정이 어느 계층에 속하는지 확인해 문제를 파악하세요. 먼저 클라이언트와 코어를 구분한 다음 프로토콜, 보안 계층, 전송 방식을 살펴보세요. 구독 관리, 라우팅, DNS는 설정 업데이트 방식과 요청 처리 경로를 결정합니다.
코어와 생태계
선택 순서: 데스크톱에서는 v2rayN, 안드로이드에서는 v2rayNG를 먼저 살펴보세요. V2Fly 코어가 필요하다면 v2flyNG를 고려할 수 있습니다. 클라이언트 이름만으로 실제 코어의 지원 기능을 판단할 수는 없습니다.
V2Fly
V2Ray 커뮤니티 프로젝트와 코어 계열코어 계열: V2Fly는 V2Ray 커뮤니티 개발을 이어가며 관련 핵심 프로그램과 설정 기능을 발전시키고 있습니다. 사이트에서 소개하는 v2flyNG는 이 계열 코어를 사용하는 안드로이드 대체 클라이언트로, 기존 설정에서 해당 기능을 요구할 때 고려할 수 있습니다. 설정에 V2Ray라는 이름이 들어 있다고 해서 다른 코어에서도 모든 확장 항목을 사용할 수 있는 것은 아닙니다.
Xray
프로토콜 처리와 연결을 담당하는 코어코어 기능: Xray는 V2Ray 기술 체계에서 발전한 독립 코어 프로젝트로, v2rayN과 v2rayNG 설정에서 자주 사용됩니다. REALITY 등의 기능은 클라이언트에 관련 입력란이 있는지만 볼 것이 아니라 실제로 사용하는 코어와 버전을 확인해야 합니다. 클라이언트를 업데이트한 뒤에는 현재 선택한 코어가 가져온 설정과 호환되는지도 확인하세요.
클라이언트와 코어
관리 인터페이스 / 연결 실행 프로그램역할 구분: 클라이언트는 노드 목록, 구독 관리, 모드 전환, 로그 화면을 제공하고 코어는 설정 파싱, 연결 수립, 라우팅 실행을 담당합니다. 링크를 가져올 수 있다고 해서 현재 코어가 모든 매개변수를 지원하는 것은 아닙니다. 호환성 문제를 확인할 때는 클라이언트 이름, 실제 코어, 오류가 발생한 설정 항목을 먼저 기록한 뒤 화면 변환 문제인지 코어 실행 문제인지 살펴보세요.
전송 프로토콜
계층 구분: VMess, VLESS, Trojan은 프록시 통신 규칙을 설명하고 TCP, WebSocket 등은 데이터를 전달하는 방식을 설명합니다. 이름이 비슷한 선택 항목이라고 서로 바꿔 쓸 수 있는 것은 아닙니다.
VMess
프록시 프로토콜프로토콜 설정: VMess는 V2Ray 생태계의 프록시 프로토콜입니다. 연결하려면 사용자 ID, 주소, 포트, 관련 전송 설정이 서로 일치해야 합니다. 인증 과정에는 시스템 시간이 중요하므로 시계 오차가 있으면 연결이 실패할 수 있습니다. 오래된 가이드의 예전 매개변수를 현재 설정에 그대로 적용하지 말고, 서버에서 제공한 설정 조합을 우선 사용하세요.
VLESS
경량 프록시 프로토콜보안 설정 조합: VLESS 자체는 완전한 전송 암호화를 제공하지 않으므로 실제로는 TLS나 REALITY 같은 보안 계층과 함께 사용하는 경우가 많습니다. 노드의 사용자 ID, 흐름 제어 옵션, 전송 방식, 보안 설정을 함께 맞춰야 합니다. 프로토콜 선택 항목만 바꾸면 해결되는 문제가 아닙니다. 가져온 설정에서 지원하지 않는 항목이 보이면 보안 매개변수를 하나씩 지우기보다 코어의 지원 여부부터 확인하세요.
Trojan
일반적으로 TLS와 함께 사용하는 프록시 프로토콜연결 구성: Trojan은 일반적으로 TLS 연결을 통해 프록시 요청을 전달하며, 인증 정보와 TLS 설정이 모두 서버와 일치해야 합니다. 비밀번호가 맞더라도 서비스 이름이 틀리면 핸드셰이크 단계에서 실패할 수 있습니다. 문제를 확인할 때는 인증 오류와 인증서 오류를 구분하세요. 인증서 검증을 끄는 대신 도메인, 시스템 시간, 인증서 체인을 점검해야 합니다.
전송 방식
TCP / WebSocket / gRPC데이터 전달 방식: 전송 방식은 프록시 데이터를 어떻게 구성하고 전달할지 정하며, 프록시 프로토콜과는 다른 계층에 속합니다. WebSocket 경로와 요청 호스트 이름, gRPC 서비스 이름은 각각 의미가 다르므로 한 필드의 값을 다른 필드에 그대로 복사하면 안 됩니다. 전송 설정을 바꾸려면 서버 측 설정도 맞아야 하는 경우가 많으며, 클라이언트에서만 전환한다고 호환성이 자동으로 생기지는 않습니다.
보안과 암호화
확인할 항목: 연결 주소, 서비스 이름, 인증 자료는 각각 역할이 다릅니다. 핸드셰이크 오류가 발생하면 각 필드의 의미에 따라 점검하고, 검증 생략을 기본 설정으로 사용하지 마세요.
TLS
전송 계층 보안 프로토콜보안 연결: TLS는 전송을 암호화하고 통신 상대를 인증합니다. 인증서 검증은 상대방을 확인하는 중요한 절차입니다. 신뢰할 수 있는 인증서 체인, 이름 일치, 정확한 시스템 시간이 검증 결과에 영향을 줍니다. 인증서 오류가 발생하면 먼저 시간과 서비스 이름을 확인하고 서버 인증서 상태를 살펴보세요. 암호화 연결이 성립했다고 해서 상대방의 신원이 올바르게 확인된 것은 아닙니다.
REALITY
Xray 생태계의 전송 보안 방식매개변수 일치 여부: REALITY는 Xray 생태계의 전송 보안 방식으로, VLESS와 함께 사용하는 경우가 많습니다. 노드 프로토콜 이름을 바꾸는 독립 스위치가 아닙니다. 클라이언트에서 필요한 공개 키 자료, 서비스 이름, 짧은 ID 등의 매개변수를 서버 설정과 하나씩 대조해야 합니다. 버전에 따라 화면의 항목 이름이 다를 수 있으므로 매개변수의 의미를 기준으로 확인하고, 서로 다른 노드의 설정을 조합하지 마세요.
SNI
Server Name Indication서비스 이름: SNI는 TLS 핸드셰이크에서 대상 서비스 이름을 나타내는 확장 정보로, 서버가 해당 설정을 선택할 수 있도록 합니다. 노드 연결 주소가 IP여도 서비스 이름은 도메인일 수 있으므로 두 값이 꼭 같을 필요는 없습니다. 클라이언트 화면에서는 서버 이름으로 표시되기도 합니다. 서버가 지정한 값을 사용하고 노드 별칭이나 임의의 웹사이트 도메인을 입력하지 마세요.
암호화와 신원 인증
내용 보호 / 상대방 확인개념 구분: 암호화는 전송 내용을 보호하고 신원 인증은 연결된 상대방을 확인하므로 서로 다른 문제를 해결합니다. 특정 계층에서 프로토콜 자체 암호화를 사용하지 않는다고 표시되어도 전체 연결에 보안 계층이 없다는 뜻은 아닐 수 있습니다. TLS 등의 조합 설정도 확인해야 합니다. 설정을 판단할 때는 암호화 선택 항목 하나만 보고 결론 내리지 말고 계층별로 살펴보세요.
구독과 노드
관리 핵심: 구독은 설정을 가져오고, 노드는 연결 지점을 설명하며, 그룹은 설정을 정리하는 데 쓰입니다. 업데이트 성공 여부와 노드 연결 가능 여부는 별도로 확인해야 합니다.
구독 링크
설정을 가져오고 업데이트하는 주소설정 가져오기: 구독 링크를 사용하면 클라이언트가 여러 노드의 설정을 가져오고 이후 업데이트에서 변경 사항을 반영할 수 있습니다. 링크에 접근 자격 증명이 포함될 수 있으므로 민감한 정보로 관리하고 스크린샷, 로그, 게시글에 공개하지 마세요. 구독 업데이트는 설정을 가져오는 과정일 뿐 서버 문제를 자동으로 해결하지 않습니다. 업데이트에 실패하면 링크 만료, 네트워크 접속, 형식 파싱 문제를 구분해 확인해야 합니다.
노드
단일 연결 지점의 설정 모음연결 지점: 노드에는 보통 서버 주소, 포트, 프록시 프로토콜, 인증 정보, 전송 및 보안 매개변수가 포함됩니다. 단순한 서버 IP가 아닙니다. 노드 이름은 식별을 위한 별칭일 뿐 실제 위치나 연결 품질을 보장하지 않습니다. 노드를 복사할 때는 모든 매개변수를 유지하세요. 주소와 포트만 직접 입력해서는 기존 연결 설정을 복원하기 어려운 경우가 많습니다.
구독 그룹
출처와 용도별 설정 정리관리 범위: 구독 그룹은 설정 출처를 구분하고 노드 필터링, 구독 업데이트, 별칭 관리를 편리하게 해 줍니다. 그룹 이름이 요청을 프록시로 보낼지 직접 연결할지를 결정하지는 않습니다. 실제 경로는 현재 노드, 실행 모드, 라우팅 규칙에 따라 정해집니다. 자동 업데이트나 서버 필터링을 사용한다면 설정이 어느 그룹에 적용되는지 확인해 필터 결과를 구독 내용의 삭제로 오해하지 않도록 하세요.
실제 연결 지연 시간
노드를 통해 테스트 대상에 접속하는 데 걸리는 시간측정 의미: 실제 연결 지연 시간은 보통 지정한 노드를 통해 테스트 대상에 접속할 때 걸리는 시간을 뜻합니다. 어느 단계까지 측정하는지는 클라이언트의 테스트 방식에 따라 다릅니다. 서버 포트의 TCP 연결만 확인하는 시간과는 다르며 다운로드 속도를 바로 나타내지도 않습니다. 결과를 비교할 때는 테스트 주소, 네트워크 환경, 측정 방식을 동일하게 유지하세요. 한 번의 시간 초과는 실제 접속 결과와 로그를 함께 확인해야 합니다.
라우팅과 DNS
경로 확인: 요청에 도메인이 포함됐는지 IP가 포함됐는지 먼저 살펴본 뒤 규칙과 DNS 해석 정책을 확인하세요. 실제 연결 경로와 DNS 조회 경로는 각각 검증해야 합니다.
라우팅 규칙과 트래픽 분기
매칭 조건 → 아웃바운드 선택경로 선택: 라우팅 규칙은 도메인, IP, 포트, 인바운드 등의 조건에 따라 요청을 직접 연결, 프록시, 차단 등의 아웃바운드 처리로 전달합니다. 규칙은 순서대로 적용되는 경우가 많아 범위가 넓은 규칙을 앞에 두면 뒤의 세부 규칙이 적용되지 않을 수 있습니다. 트래픽 분기는 독립된 프로토콜이 아니라 규칙, 기본 아웃바운드, 도메인 조회, 트래픽 가로채기가 함께 만든 결과입니다.
GeoIP
IP 주소 분류 데이터주소 목록: GeoIP는 IP 주소를 지역이나 분류별로 정리한 데이터입니다. 호환되는 코어는 해당 태그를 통해 데이터를 참조할 수 있습니다. 매칭 결과는 데이터 출처, 업데이트 시점, 대상의 실제 주소에 따라 달라지므로 지역 태그를 정확한 위치 정보로 간주하면 안 됩니다. 공유 인프라를 사용하거나 주소가 바뀌는 경우 로그에서 최종 대상 IP를 확인한 뒤 더 구체적인 규칙을 추가할지 판단하세요.
GeoSite
도메인 분류 데이터도메인 목록: GeoSite는 도메인 규칙을 분류별로 정리해 태그를 기준으로 여러 사이트의 트래픽 분기 정책을 관리할 수 있게 합니다. 매칭 대상은 GeoIP와 다르며, 도메인 목록이 해당 사이트에서 현재 사용하는 모든 IP와 자동으로 일치하는 것은 아닙니다. 규칙이 적용되는지는 코어가 도메인 정보를 확보할 수 있는지, 데이터 파일에 해당 태그가 있는지에 따라서도 달라집니다.
FakeDNS
도메인과 가상 IP 매핑매핑 방식: FakeDNS는 예약 주소 범위의 가상 IP로 도메인 조회에 응답하고 IP와 도메인의 대응 관계를 저장해, 이후 트래픽에서 원래 도메인을 복원할 수 있게 합니다. TUN 등의 트래픽 가로채기 경로 및 매핑 복원 기능과 함께 사용해야 하며, 공용 DNS 주소만 바꾸는 기능은 아닙니다. 일부 앱은 이런 주소 처리 방식과 호환되지 않을 수 있습니다. 설정을 바꾸기 전후로 이전 DNS 캐시도 확인하세요.
DNS 누수
예상한 DNS 조회 경로에서 벗어나는 현상DNS 확인 범위: DNS 누수는 일반적으로 도메인 조회가 예상한 경로를 따르지 않고 시스템, 앱 또는 다른 DNS 리졸버에서 직접 처리되는 현상을 말합니다. 실제 연결이 프록시를 통하더라도 DNS 조회까지 같은 경로를 사용한다고 볼 수는 없습니다. 브라우저 자체 DNS 조회, 시스템 캐시, 클라이언트 DNS 규칙을 함께 확인해야 합니다. 출구 IP나 특정 리졸버 이름만으로 결론 내리지 마세요.
클라이언트 기능
기능 범위: 시스템 프록시와 TUN은 트래픽을 가로채는 범위가 다르고, 로컬 인바운드는 앱의 접속 방식을 정합니다. 문제가 생기면 로그를 확인해 요청이 어느 단계에서 멈췄는지 살펴보세요.
시스템 프록시
시스템에 프록시 주소 등록적용 범위: 시스템 프록시는 로컬 프록시 주소를 운영체제 설정에 등록하며, 해당 설정을 따르는 앱에서만 사용됩니다. 자체 네트워크 설정을 사용하는 프로그램도 있으므로 시스템 프록시를 켜도 모든 트래픽이 가로채지는 것은 아닙니다. v2rayN을 종료한 뒤 일반 인터넷 접속에 문제가 생기면 운영체제에 중지된 포트를 가리키는 프록시 설정이 남아 있는지 먼저 확인하세요.
TUN 모드
가상 네트워크 인터페이스를 통한 트래픽 가로채기트래픽 처리 방식: TUN은 가상 네트워크 인터페이스를 통해 트래픽을 클라이언트로 전달합니다. 일반적으로 시스템 프록시보다 더 많은 앱을 처리할 수 있지만, 시스템 라우팅과 제외 규칙의 영향을 받습니다. 사용 시 추가 권한이 필요할 수 있으며 DNS 및 루프백 보호 설정도 함께 구성해야 합니다. 처음 문제를 확인할 때는 먼저 노드가 정상적으로 연결되는지 확인한 뒤 TUN을 켜세요. 여러 설정을 동시에 바꾸면 문제를 추적하기 어려워집니다.
로컬 인바운드
앱이 코어에 접속하는 수신 대기 지점수신 지점: 로컬 인바운드는 코어가 앱 요청을 받는 위치입니다. 흔히 HTTP, SOCKS 또는 혼합 프록시 포트를 사용합니다. 앱에 입력한 프록시 유형, 주소, 포트는 실제 수신 설정과 일치해야 합니다. 포트가 열려 있다는 이유만으로 프로토콜도 호환된다고 볼 수는 없습니다. 루프백 주소만 수신하는 경우와 모든 인터페이스에서 수신하는 경우의 접근 범위는 다르므로, 바꾸기 전에 LAN 접속이 필요한지 확인하세요.
실행 로그
설정 및 연결 단계 확인문제 해결의 근거: 실행 로그에는 설정 로드, 파싱, 핸드셰이크, 연결 등의 이벤트가 기록되어 로컬 설정 오류와 원격 연결 실패를 구분하는 데 도움이 됩니다. 특정 요청을 한 번 실행한 뒤 해당 시간대의 로그를 확인하고, 이전 오류와 현재 요청을 혼동하지 마세요. 로그를 공유하기 전에는 구독 링크, 사용자 ID, 인증 정보 등 민감한 내용을 삭제하고, 필요한 경우 오류 유형과 관련 설정 항목 이름만 남기세요.