V2Ray와 Xray를 처음 접하면 두 이름이 서로 다른 프로그램인지, 어느 쪽을 설치해야 하는지 헷갈리기 쉽습니다. 먼저 구분해야 할 점은 V2Ray와 Xray가 v2rayN이나 v2rayNG처럼 화면을 제공하는 클라이언트가 아니라는 사실입니다. 클라이언트가 서버 목록과 설정을 관리하고, 실제 프록시 연결·라우팅·DNS 처리를 수행하는 실행 엔진이 바로 코어입니다. 따라서 “V2Ray 앱을 설치한다”는 표현은 실제로는 클라이언트와 그 안에서 사용할 코어를 준비한다는 뜻에 가깝습니다.
V2Ray는 오랫동안 사용된 프록시 코어 계열의 기본 이름이며, Xray는 V2Ray 설정 형식과 핵심 구조를 바탕으로 기능과 프로토콜 지원을 확장한 별도 프로젝트입니다. 두 코어는 설정 구조가 비슷한 부분이 많지만 완전히 같은 실행 파일은 아닙니다. 프로토콜, 전송 방식, 보안 계층, 라우팅 옵션이 모두 동일하게 동작한다고 가정하면 연결 실패나 예상하지 못한 경로 선택이 발생할 수 있습니다.
V2Ray와 Xray의 관계, v2rayN·v2rayNG에서 코어를 선택하는 방법, VMess와 VLESS 설정을 대조하는 순서, 안전한 설치 파일 확인 기준을 초보자 눈높이에서 설명합니다. 처음에는 Xray를 무조건 선택하기보다 현재 구독과 서버가 요구하는 기능을 기준으로 판단하면 됩니다.
클라이언트와 코어의 역할부터 구분하기
v2rayN은 Windows, macOS, Linux 데스크톱 환경에서 서버 목록, 구독 그룹, 시스템 프록시, TUN, 로그와 코어 실행을 관리하는 클라이언트입니다. v2rayNG는 Android 환경에서 비슷한 역할을 수행합니다. 두 클라이언트는 직접 모든 프로토콜 로직을 구현하기보다, 선택된 코어에 설정을 전달하고 로컬 인바운드 포트를 열어 애플리케이션 트래픽을 코어로 보냅니다.
일반적인 흐름은 애플리케이션 요청 → 로컬 프록시 또는 TUN 인바운드 → 라우팅 규칙 → 선택된 아웃바운드 → 원격 서버 순서입니다. Windows의 수동 시스템 프록시에서는 HTTP 프록시와 SOCKS 프록시 포트가 사용될 수 있으며, 설치 상태나 설정에 따라 대표적인 로컬 포트가 10808, 10809로 표시되기도 합니다. 숫자 자체는 고정 규칙이 아니므로 실제 클라이언트의 설정 화면과 로그를 기준으로 확인해야 합니다.
이 구조를 이해하면 “노드가 목록에 보인다”와 “트래픽이 실제로 프록시를 통과한다”가 다르다는 점도 알 수 있습니다. 서버 설정을 가져왔지만 코어가 실행되지 않았거나, 시스템 프록시가 꺼져 있거나, 애플리케이션이 다른 네트워크 경로를 사용하면 목록에는 정상적인 노드가 있어도 웹 접속은 직접 연결로 처리될 수 있습니다.
V2Ray와 Xray는 어떻게 다른가
V2Ray는 VMess, SOCKS, HTTP, WebSocket, TLS와 같은 기능을 중심으로 널리 사용된 코어입니다. 오랜 기간 다양한 클라이언트와 구독 형식에서 사용되어 기존 VMess 서버나 오래된 설정과의 호환성을 확인하기 쉽다는 장점이 있습니다. 반면 오래된 설정은 현재 서버 정책이나 보안 요구 사항을 충분히 반영하지 못할 수 있으므로 “예전에 연결됐다”는 사실만으로 모든 환경에 적합하다고 판단해서는 안 됩니다.
Xray는 V2Ray에서 파생된 코어로, 공통적인 설정 개념을 유지하면서 VLESS, REALITY, Vision 계열 설정과 최신 라우팅·전송 기능을 사용하는 환경에서 자주 선택됩니다. 특히 서버가 VLESS와 REALITY를 명시적으로 요구한다면 Xray를 우선 검토하는 편이 자연스럽습니다. 다만 Xray가 모든 V2Ray 설정을 자동으로 완벽하게 변환하거나, 서버 측 설정이 틀려도 해결해 주는 것은 아닙니다.
VLESS, REALITY, 최신 라우팅과 전송 기능을 사용하는 새 구성에 적합합니다. v2rayN과 v2rayNG에서 현재 배포되는 설정과 함께 선택되는 경우가 많습니다.
적합: 새 서버, VLESS·REALITY, 세밀한 라우팅
기존 VMess, WebSocket, TLS 환경과의 호환성을 확인할 때 유용합니다. 오래된 서버가 특정 코어 동작을 전제로 할 때 비교 대상이 됩니다.
적합: 기존 VMess, 레거시 설정, 호환성 점검
결론: 이름보다 서버 요구 사항이 우선입니다
새로운 서버가 Xray 전용 매개변수를 요구하면 Xray를 선택하고, 기존 VMess 설정만 제공된다면 먼저 V2Ray와 Xray 양쪽의 호환성을 시험하세요. 코어 이름만 바꾸는 것보다 프로토콜과 전송 항목을 일치시키는 일이 훨씬 중요합니다.
VMess와 VLESS 설정을 혼동하지 않는 법
코어를 선택하기 전에 노드의 프로토콜부터 확인해야 합니다. VMess와 VLESS는 모두 사용자 식별자와 서버 주소를 사용하지만 동일한 프로토콜이 아닙니다. VMess 노드의 UUID를 VLESS 노드에 그대로 넣거나, VLESS의 flow 값을 VMess 설정에 추가하는 방식은 올바른 변환이 아닙니다. 주소와 포트가 같아 보여도 프로토콜 계층에서 서버와 클라이언트의 대화 방식이 달라지므로 연결이 실패할 수 있습니다.
전송 방식도 함께 대조해야 합니다. TCP, WebSocket, HTTP/2, gRPC 등은 연결을 운반하는 방법이며, TLS나 REALITY는 보안·핸드셰이크 계층의 설정입니다. WebSocket을 사용하는 경우 경로가 /ws인지, Host 헤더가 필요한지, TLS 사용 여부와 서버 이름이 무엇인지 확인해야 합니다. REALITY를 사용하는 경우 서버 공개 키, short ID, 서버 이름, 지문과 flow가 서버 측 설정과 일치해야 합니다.
VLESS + REALITY
- 프로토콜
- VLESS
- 전송
- TCP
- 보안
- REALITY
- 주요 항목
- UUID·공개 키·short ID
서버가 지정한 SNI와 flow까지 항목별로 대조해야 합니다.
VMess + WS + TLS
- 프로토콜
- VMess
- 전송
- WebSocket
- 보안
- TLS
- 주요 항목
- UUID·경로·Host
CDN 또는 웹 서버를 거치는 구성이라면 경로와 서버 이름이 중요합니다.
구독 링크를 가져온 경우에는 가능한 한 노드를 직접 편집하기 전에 원본 구독 데이터를 확인하세요. 구독 업데이트가 실행되면 수동으로 수정한 값이 다시 덮어써질 수 있습니다. 코어를 바꿨는데 연결되지 않는다면 노드 이름, 서버 주소, 포트, UUID, 전송 방식, 보안 계층과 서버 이름을 한 번에 모두 변경하지 말고 항목별로 대조해야 원인을 좁힐 수 있습니다.
v2rayN에서 코어를 선택하는 순서
v2rayN의 메뉴 이름은 버전에 따라 조금 달라질 수 있지만, 기본적인 확인 순서는 같습니다. 먼저 현재 설치된 코어 목록과 실행 파일 상태를 확인하고, 그다음 활성 서버의 프로토콜을 살펴보세요. “Xray가 최신이므로 모든 노드에 무조건 사용”하거나 “V2Ray라는 이름의 서버에는 반드시 V2Ray 코어만 사용”하는 식의 규칙은 안전하지 않습니다.
클라이언트 확인
v2rayN을 실행한 뒤 「설정」 또는 「코어 설정」에서 현재 등록된 코어와 실행 경로를 확인합니다. 실행 파일이 없는 코어를 선택하면 노드 설정과 관계없이 시작할 수 없습니다.
노드 확인
서버 목록에서 대상 노드를 선택하고 편집 화면을 엽니다. VMess인지 VLESS인지, 전송 방식과 보안 계층이 무엇인지 먼저 기록합니다.
코어 지정
「설정」→「코어 설정」 또는 노드별 코어 선택 메뉴에서 요구 사항에 맞는 코어를 지정합니다. 메뉴 위치는 빌드에 따라 다를 수 있으므로 코어 이름과 실행 상태를 함께 확인하세요.
프록시 적용
노드를 활성 서버로 지정한 뒤 시스템 프록시 또는 TUN 모드를 켭니다. 로컬 HTTP·SOCKS 포트가 다른 프로그램과 충돌하지 않는지 확인합니다.
로그 확인
코어를 재시작하고 로그에서 실행 완료, 인바운드 포트 개방, TLS 핸드셰이크 또는 인증 오류를 확인합니다. 웹페이지 한 곳만 보지 말고 먼저 로그와 간단한 연결 테스트를 함께 확인하세요.
v2rayN에서 코어 변경은 서버 설정을 자동으로 고쳐 주는 기능이 아닙니다. 예를 들어 VLESS + REALITY 노드를 V2Ray 코어로 바꾼 뒤 오류가 발생했다면, 먼저 해당 코어가 필요한 보안 기능을 지원하는지와 클라이언트가 올바른 설정을 생성했는지 확인해야 합니다. 반대로 VMess + WebSocket + TLS 노드가 Xray에서 작동하지 않는다면 코어 이름보다 UUID, WebSocket 경로, Host, SNI, 인증서 검증 설정을 점검하는 것이 우선입니다.
v2rayNG에서 확인할 항목
v2rayNG에서는 Android 시스템의 VPN 권한과 배터리 절전 정책이 연결 결과에 영향을 줄 수 있습니다. 앱에서 코어를 선택하고 노드를 활성화했더라도 VPN 권한 요청을 승인하지 않았거나 백그라운드 실행이 제한되면 연결이 중단될 수 있습니다. 처음 설정할 때는 「설정」에서 코어 관련 항목을 확인한 다음, 대상 노드의 상세 설정에서 프로토콜과 전송 값을 대조하세요.
분할 터널링이나 앱별 프록시를 사용한다면 어떤 애플리케이션이 VPN 경로에 포함되는지도 확인해야 합니다. 브라우저는 연결되지만 특정 앱만 작동하지 않는 경우 코어 문제라기보다 해당 앱이 VPN 제외 목록에 들어갔거나 UDP를 별도로 사용하기 때문일 수 있습니다. DNS 모드를 변경한 직후 문제가 생겼다면 먼저 기본 모드로 되돌리고, 노드 자체가 연결되는지부터 분리해서 테스트하세요.
초보자 권장 구성: 한 노드씩 검증하기
v2rayN
- 코어 실행 상태 확인
- 시스템 프록시를 먼저 테스트
- 로그를 저장하고 설정 변경
v2rayNG
- VPN 권한 승인
- 앱별 프록시 예외 확인
- 배터리 제한 해제 검토
두 클라이언트에서 같은 구독을 사용하더라도 코어 버전, 운영체제 권한과 라우팅 설정은 별도로 확인해야 합니다.
안전한 다운로드와 첫 실행 점검
코어와 클라이언트를 내려받을 때는 검색 결과의 임의 압축 파일이나 출처가 불명확한 재배포 페이지보다, 사용 중인 클라이언트가 안내하는 공식 배포 경로와 이 사이트의 설치 패키지 페이지를 우선 사용하세요. 파일 이름에 “최신”, “무설치”, “크랙” 같은 표현이 붙었다는 이유만으로 신뢰해서는 안 됩니다. 실행 전에는 운영체제와 CPU 아키텍처에 맞는 패키지인지, 압축 해제 후 실행 파일이 예상한 구성인지, 보안 프로그램의 경고가 무엇을 의미하는지 확인해야 합니다.
v2rayN을 처음 준비할 때는 클라이언트와 코어를 각각 무작위로 모으기보다 클라이언트가 제공하는 코어 관리 기능을 활용하는 편이 안전합니다. v2rayNG도 앱 내부의 코어 선택과 업데이트 경로를 확인하고, 여러 출처의 실행 파일을 동시에 등록하지 않는 것이 좋습니다. 설치 후에는 노드 구독부터 추가하기보다 빈 상태에서 클라이언트가 정상적으로 실행되는지, 코어 경로가 유효한지, 로컬 포트가 열리는지 먼저 확인하세요.
- 다운로드 페이지의 플랫폼과 파일 종류가 현재 장치와 일치하는지 확인합니다.
- 압축 파일은 임시 폴더보다 권한과 저장 위치를 관리할 수 있는 전용 폴더에 풉니다.
- 코어 실행 오류가 있으면 다른 설정을 추가하기 전에 실행 경로와 운영체제 권한을 점검합니다.
- 구독 주소와 UUID가 포함된 설정을 공개 채팅이나 공개 문서에 붙여 넣지 않습니다.
- 설치 후에는 사용하지 않는 코어와 오래된 실행 파일을 정리해 어떤 코어가 실제로 호출되는지 명확히 합니다.
연결되지 않을 때의 첫 점검 순서
코어 선택 후 연결이 실패하면 다음 네 가지를 순서대로 확인하세요. 첫째, 선택한 코어의 실행 로그에 파일 누락이나 설정 문법 오류가 없는지 봅니다. 둘째, 노드의 프로토콜과 코어의 지원 범위를 대조합니다. 셋째, 원격 주소와 포트가 현재 네트워크에서 접근 가능한지 확인합니다. 넷째, 시스템 프록시 또는 TUN이 실제로 켜져 있고 테스트 애플리케이션이 해당 경로를 사용하는지 확인합니다.
failed to start core
원인과 해결: 코어 실행 파일 경로가 틀렸거나 파일이 누락되었을 가능성이 큽니다. 「코어 설정」에서 경로를 다시 지정하고 실행 권한을 확인하세요.
address already in use
원인과 해결: 로컬 포트가 다른 프로그램 또는 이전 코어 프로세스에 점유된 상태입니다. 사용 중인 프로세스를 종료하거나 HTTP·SOCKS 포트를 사용하지 않는 번호로 변경하세요.
TLS handshake failed
원인과 해결: 서버 이름, TLS·REALITY 항목, 시스템 시간이 맞지 않을 수 있습니다. 서버가 제공한 SNI와 보안 매개변수를 다시 대조하세요.
invalid user
원인과 해결: UUID가 틀렸거나 프로토콜을 잘못 선택했을 가능성이 있습니다. VMess와 VLESS를 구분하고 구독 원본에서 사용자 식별자를 다시 가져오세요.
최종적으로는 “어떤 코어가 더 좋으냐”보다 현재 서버가 요구하는 프로토콜과 기능을 만족하는지가 기준입니다. 새로 구성된 VLESS·REALITY 환경이라면 Xray를 먼저 검토하고, 오래된 VMess 설정이나 특정 호환성 문제가 있다면 V2Ray를 비교 대상으로 남겨 두세요. 어느 쪽을 선택하든 v2rayN 또는 v2rayNG의 로그, 로컬 포트, 시스템 프록시 상태를 함께 확인하면 원인을 훨씬 빠르게 좁힐 수 있습니다.