Project V#
Project V는 V2Ray 계열 도구의 통칭으로, 동일한 JSON 설정 규격을 중심으로 발전한 오픈 소스 프록시 소프트웨어 모음을 가리킵니다. 클라이언트는 UI와 프로세스 관리를 담당하고 실제 포워딩은 코어가 수행합니다. 현재 생태계에는 V2Fly와 Xray 두 코어 갈래가 있으며 설정 파일 구조는 대부분 호환됩니다.
Project V · Xray · V2Fly
V2Ray 용어 사전과 용어 해설
6개 분류로 V2Ray 클라이언트와 설정 파일에서 반복해서 등장하는 용어를 정리했습니다. 각 항목은 한 가지만 다룹니다. 이 필드, 이 스위치, 이 프로토콜 이름이 v2rayN, v2rayNG 또는 설정 파일에서 무엇을 뜻하는지입니다.
- 6개 분류
- 35개 용어
- 설정 파일과 동일한 필드 이름
- v2rayN · v2rayNG · v2flyNG
총 35개 용어
전체 용어 빠른 찾기(35개)
프로토콜과 코어
8개설정 파일에 등장하는 프로토콜 이름과, 이를 구동하는 두 코어 갈래입니다.
Xray#
Xray는 Project V 생태계에서 활발하게 개발되는 코어 갈래로, 기존 프로토콜 외에 VLESS, XTLS, REALITY 등의 기능을 확장했습니다. v2rayNG는 기본적으로 Xray 코어를 사용하고 v2rayN도 설정에서 코어 유형을 바꿀 수 있습니다. 설정 필드는 V2Ray와 대체로 같아 대부분의 노드 파라미터를 그대로 쓸 수 있습니다.
V2Fly#
V2Fly는 원래 저장소가 아카이브된 뒤 커뮤니티가 이어서 유지하는 코어 갈래로, 기존 V2Ray 설정 형식과의 호환성을 유지합니다. v2flyNG는 V2Fly 코어로 빌드한 Android 클라이언트로, 서버도 같은 갈래를 쓰는 환경에 적합합니다. 업데이트 주기는 비교적 안정적이며 설정 필드는 Xray와 대부분 겹칩니다.
VMess#
VMess는 Project V가 초기에 자체 개발한 프록시 프로토콜로, 클라이언트와 서버가 UUID와 alterId로 신원을 확인합니다. 시간을 기준으로 연결 검증값을 만들기 때문에 양쪽 시스템 시간 차이가 크면 테스트는 통과해도 연결이 되지 않습니다. 최신 코어에서는 alterId의 역할이 줄어 기본값을 두거나 0을 입력하면 됩니다.
VLESS#
VLESS는 VMess를 가볍게 대체하는 프로토콜로, 내장 암호화 계층을 없애고 암호화를 TLS나 REALITY에 맡깁니다. 신원 식별에는 UUID 하나만 쓰기 때문에 설정 필드가 적고 핸드셰이크 비용도 낮습니다. 클라이언트와 서버가 모두 지원해야 하며 코어 버전이 너무 오래되면 이 프로토콜을 인식하지 못합니다.
Trojan#
Trojan은 프록시 트래픽이 전송 계층에서 일반 HTTPS 요청과 같아 보이도록 설계되어 TLS와 함께 사용해야 합니다. 설정에는 서버 주소, 포트, 비밀번호를 입력하며 비밀번호가 신원 자격 증명 역할도 합니다. V2Ray 계열 코어는 이를 아웃바운드 프로토콜로 지원하므로 VMess, VLESS 노드와 같은 구독에 섞어 둘 수 있습니다.
REALITY#
REALITY는 Xray가 도입한 전송 보안 방식으로, 자체 서명 인증서 대신 실제 사이트의 TLS 핸드셰이크 특성을 사용하므로 클라이언트에 인증서 파일이 필요 없습니다. 설정에는 publicKey, shortId, serverName 세 가지 필드가 등장하며 서버와 완전히 일치해야 합니다. 전송 계층의 핸드셰이크 특성만 다루며 상위 프로토콜 선택에는 영향을 주지 않습니다.
Shadowsocks#
Shadowsocks는 등장이 이른 경량 프록시 프로토콜로, V2Ray 계열 코어가 아웃바운드 프로토콜 중 하나로 지원합니다. 설정 필드에는 서버 주소, 포트, 암호화 방식, 비밀번호가 있으며 암호화 방식은 서버와 같은 값을 써야 합니다. 구독에 이 프로토콜이 있으면 클라이언트 목록에는 보통 암호화 방식만 표시되고 전송 계층 옵션은 나타나지 않습니다.
클라이언트와 UI
6개세 가지 클라이언트의 성격 차이와, 인터페이스에서 전체 동작을 좌우하는 몇 가지 스위치입니다.
v2rayN#
v2rayN은 Windows, macOS, Linux용 데스크톱 클라이언트로, 구독 관리와 노드 속도 측정, 코어 프로세스 관리를 담당합니다. 화면 왼쪽에는 구독 그룹과 서버 목록이, 오른쪽에는 현재 선택한 노드의 설정 필드와 스위치가 표시됩니다. 자체적으로는 UI와 프로세스 관리만 하고 실제 포워딩은 로컬 코어가 수행합니다.
v2rayNG#
v2rayNG는 Android용 GUI 클라이언트로 기본적으로 Xray 코어를 사용합니다. 시스템 VpnService를 통해 트래픽을 처리하며 첫 연결 시 시스템 권한 요청 창이 뜹니다. 구독, 라우팅 규칙, 앱별 프록시를 모두 같은 화면에서 설정합니다.
v2flyNG#
v2flyNG는 v2rayNG와 인터페이스가 거의 같고 내장 코어가 V2Fly 갈래라는 점만 다릅니다. 서버가 V2Fly 코어를 쓰고 양쪽을 맞추고 싶은 환경에 적합합니다. 두 앱을 함께 설치할 수 있으며 구독 데이터는 각각 따로 저장됩니다.
시스템 프록시#
시스템 프록시는 클라이언트가 운영체제 프록시 설정을 바꿔 브라우저 요청을 로컬 수신 포트로 전달하는 방식입니다. 시스템 프록시 설정을 따르는 프로그램만 적용되며 일부 앱은 자체적으로 우회합니다. 클라이언트를 끈 뒤 설정이 원래대로 돌아왔는지 확인하지 않으면 브라우저가 인터넷에 연결되지 않을 수 있습니다.
TUN 모드#
TUN 모드는 가상 네트워크 인터페이스를 만들어 시스템 프록시 설정을 읽지 않는 프로그램까지 포함해 시스템 전체 트래픽을 처리합니다. 켤 때 보통 관리자 권한이나 시스템 승인이 필요하며 트래픽 경로는 코어가 라우팅 규칙에 따라 결정합니다. 데스크톱과 Android의 구현 방식은 다르지만 대응하는 설정 필드는 대체로 같습니다.
앱별 프록시#
앱별 프록시는 Android 클라이언트의 앱 단위 분할 기능으로, 어떤 앱을 프록시로 보내고 어떤 앱을 직접 연결로 보낼지 지정할 수 있습니다. VpnService 계층에서 동작하므로 같은 앱의 모든 트래픽에 적용됩니다. 보통 브라우저와 외부 리소스가 필요한 앱은 프록시로, 로컬 서비스 앱은 직접 연결로 설정합니다.
구독과 노드
7개구독 주소 하나가 목록의 서버 한 줄이 되기까지 어떤 단계를 거치는지 정리했습니다.
구독#
구독은 서버 측에서 관리하는 노드 목록 주소로, 클라이언트가 일정 간격으로 가져와 로컬 서버 목록을 갱신합니다. 구독 내용은 base64로 인코딩한 공유 링크 모음일 수도 있고 완전한 JSON 설정일 수도 있습니다. 구독을 쓰면 노드 추가와 삭제를 서버에서 처리하므로 로컬에서 하나씩 직접 입력할 필요가 없습니다.
구독 변환#
구독 변환은 한 구독 형식을 다른 형식으로 바꾸는 작업으로, 예를 들어 base64 링크 모음을 클라이언트가 바로 읽을 수 있는 JSON으로 변환합니다. 변환 과정에서 가장 자주 유실되는 것은 전송 계층 필드와 TLS 관련 파라미터입니다. 변환이 끝나면 노드 개수만 확인하지 말고 실제로 한 번 연결해 봐야 합니다.
공유 링크#
공유 링크는 단일 노드의 프로토콜, 주소, 포트, 신원 식별자, 전송 파라미터를 하나의 URI로 압축한 것으로, 흔히 vmess:// 와 vless:// 접두사를 씁니다. 노드 하나를 임시로 공유하기에 적합하며 그룹과 라우팅 정보는 포함하지 않습니다. 링크 가운데의 base64 부분을 디코딩하면 설정 파일과 필드 이름이 일대일로 대응하는 JSON이 나옵니다.
노드#
노드는 접속 가능한 서버와 그에 대응하는 프로토콜 파라미터 조합으로, 클라이언트 목록에서는 한 줄의 항목으로 표시됩니다. 같은 구독에 보통 여러 지역의 노드가 들어 있으며 이름은 서버 측에서 정합니다. 노드 자체에는 클라이언트 로직이 없고 노드를 바꾸는 것은 아웃바운드 대상을 바꾸는 일입니다.
지연 시간#
지연 시간은 클라이언트가 테스트를 보내고 응답을 받기까지 걸린 시간으로 단위는 보통 밀리초이며 값이 작을수록 왕복이 빠릅니다. 목록의 지연 수치는 능동 테스트 결과이므로 로컬 네트워크 상태와 서버 부하에 따라 달라집니다. 연결 속도만 반영할 뿐 실제 다운로드 속도나 장기적인 안정성을 뜻하지는 않습니다.
실제 연결 지연#
실제 연결 지연은 TCP 연결 확인만 하는 대신 테스트 시 프로토콜 핸드셰이크까지 실제로 완료합니다. 결과가 실제 사용 환경에 더 가깝지만 시간이 더 오래 걸리고 서버 부담도 큽니다. 노드가 많을 때는 먼저 일반 지연으로 후보를 추린 뒤 소수 노드에만 이 테스트를 하는 편이 좋습니다.
배수#
배수는 트래픽 집계에서 노드에 적용되는 가중치로, 1배 노드는 실제 사용량대로, 2배 노드는 두 배로 계산됩니다. 배수는 서버 측이 표기하며 노드 속도와는 직접적인 관계가 없습니다. 노드를 고를 때는 먼저 배수로 높은 항목을 걸러낸 뒤 지연과 지역을 비교하면 됩니다.
라우팅과 분할
5개트래픽 경로를 결정하는 규칙 체계와, 규칙이 의존하는 두 가지 데이터 파일입니다.
라우팅 규칙#
라우팅 규칙은 하나의 연결이 어느 아웃바운드로 갈지 정하며 도메인, IP, 포트 등의 조건과 대상 아웃바운드로 구성됩니다. 규칙은 순서대로 매칭되고 첫 번째로 일치한 규칙에서 멈추므로 구체적인 규칙을 일반 규칙보다 앞에 써야 합니다. 설정 파일에서는 routing.rules 배열에 해당하고 클라이언트 화면에서는 체크할 수 있는 항목으로 표시됩니다.
분할 라우팅#
분할 라우팅은 대상 주소에 따라 트래픽을 서로 다른 아웃바운드로 보내는 것으로, 예를 들어 로컬 주소는 직접 연결, 특정 도메인은 프록시, 광고 도메인은 차단합니다. 적절한 분할은 불필요한 프록시 트래픽을 줄이고 내부망 서비스가 우회되는 일도 막습니다. 분할 결과는 규칙 세트와 도메인 조회 결과의 영향을 함께 받으므로 둘을 잘못 설정하면 서로 간섭할 수 있습니다.
GeoIP#
GeoIP는 IP 대역별 지역 정보를 기준으로 생성된 데이터 파일로, 라우팅 규칙에서 geoip:cn 같은 형태로 참조합니다. 연결 대상의 IP 소속을 판단하므로 도메인은 먼저 IP로 해석되어야 매칭됩니다. 데이터 파일을 주기적으로 갱신하지 않으면 새로 할당된 대역이 매칭되지 않을 수 있습니다.
GeoSite#
GeoSite는 도메인 분류를 기준으로 생성된 데이터 파일로, 라우팅 규칙에서 geosite:category-ads 같은 형태로 참조합니다. GeoIP와의 차이는 해석 결과를 기다리지 않고 도메인을 바로 매칭한다는 점입니다. 보통 둘을 함께 쓰며 도메인 규칙을 먼저, IP 규칙을 뒤에 둡니다.
인바운드와 아웃바운드#
인바운드(inbounds)는 어느 포트에서 어떤 프로토콜로 연결을 받을지 설명하고, 아웃바운드(outbounds)는 연결이 최종적으로 어디로 나갈지 설명합니다. 데스크톱 클라이언트의 인바운드는 보통 로컬 수신 포트이고 아웃바운드는 구독에 있는 노드입니다. 설정 파일의 이 두 최상위 배열이 전체 설정의 출발점입니다.
전송과 보안
5개아웃바운드 프로토콜 아래에 위치하며 핸드셰이크, 암호화, 연결 재사용을 담당하는 계층입니다.
TLS#
TLS는 전송 계층 암호화 프로토콜로, VLESS, Trojan 등의 설정에서 암호화와 인증서 검증을 담당합니다. 클라이언트는 서버 요구에 맞춰 serverName, allowInsecure 등의 필드를 입력해야 합니다. 인증서 도메인과 실제 접속 주소가 다르면 핸드셰이크가 바로 실패합니다.
WebSocket#
WebSocket은 하나의 TCP 연결에서 양방향으로 데이터를 전송하는 프로토콜로, 프록시 트래픽의 전송 계층으로 자주 쓰입니다. 설정에는 path와 host를 입력해야 하며 서버와 값이 같아야 합니다. 리버스 프록시를 거쳐 전달하는 배포 방식에 적합합니다.
gRPC#
gRPC는 HTTP/2 기반 원격 호출 프레임워크로, V2Ray 계열 설정에서 전송 방식 중 하나로 사용됩니다. 핵심 필드는 serviceName이며 양쪽 값이 완전히 같아야 합니다. 다중화 지원이 좋은 편이지만 서버에서도 해당 설정을 켜 두어야 합니다.
uTLS 핑거프린트#
uTLS를 사용하면 클라이언트가 TLS 핸드셰이크에서 지정한 브라우저의 핑거프린트 특성을 쓸 수 있으며 설정에서는 fingerprint 필드로 선택합니다. 핸드셰이크 특성이 얼마나 식별되기 어려운지에 영향을 줄 뿐 암호화 강도를 바꾸지는 않습니다. 필드를 비워 두면 코어의 기본 핑거프린트를 사용합니다.
mux 다중화#
mux는 여러 연결을 하나의 하위 연결로 합쳐 전송해 반복되는 핸드셰이크 비용을 줄입니다. 노드 지연이 높고 동시 연결 수가 많을 때 효과가 두드러집니다. 일부 서버는 mux를 지원하지 않으므로 켠 뒤 연결이 이상하면 이 항목을 먼저 끄고 확인하세요.
문제 해결과 로그
4개연결이 이상할 때 가장 먼저 확인할 필드와 스위치입니다.
로그 레벨#
로그 레벨은 클라이언트가 기록하는 실행 정보의 양을 조절하며 대표적인 값은 warning, info, debug입니다. 평소에는 warning으로 두고 연결 문제를 확인할 때만 임시로 debug로 바꾸면 됩니다. debug는 기록량이 많으므로 문제를 찾은 뒤에는 원래 레벨로 되돌리세요.
DNS 누출#
DNS 누출은 도메인 조회 요청이 프록시 경로를 거치지 않고 로컬 네트워크에서 직접 나가는 현상입니다. 프록시가 무력해지는 것은 아니지만 조회 결과와 실제 출구가 어긋나 일부 사이트가 비정상으로 판단할 수 있습니다. 조회를 프록시 쪽에서 처리하게 하거나 설정에서 신뢰할 수 있는 DNS 서버를 지정하면 이런 상황을 줄일 수 있습니다.
FakeDNS#
FakeDNS는 코어가 먼저 임시 주소를 반환하고 연결이 실제로 맺어질 때 진짜 대상으로 바꿔 조회 왕복 한 번을 줄이는 방식입니다. 주로 TUN 모드와 함께 쓰며 클라이언트와 코어에서 해당 스위치를 모두 켜야 합니다. 끈 뒤에는 이전 매핑이 남지 않도록 로컬 캐시를 정리하는 편이 좋습니다.
시간 차이#
시간 차이는 로컬 시간과 서버 시간의 차이로, VMess 프로토콜은 이 값으로 연결 검증값을 만듭니다. 허용 범위를 넘으면 보통 노드 테스트는 통과하는데 연결은 곧바로 실패합니다. 시스템 시간을 자동 동기화로 설정하면 이런 문제는 대개 해결됩니다.
일치하는 용어가 없습니다. 다른 키워드를 입력하거나 입력란을 비워 35개 항목 전체를 확인하세요.
용어를 설정 파일로 되돌리기
용어 해설은 색인일 뿐입니다. 각 필드가 설정 파일 어디에 있고 어떤 값을 갖는지 보려면 아래 페이지에서 이어서 확인하세요.