먼저 노드 요구 사항을 확인한 뒤 코어를 선택하세요. VLESS, XTLS Vision, REALITY 조합을 사용한다면 해당 기능을 지원하는 Xray 버전을 선택하고, VMess, WebSocket, TLS 설정은 양쪽의 매개변수를 하나씩 대조하세요. 구독을 이미 가져왔으며 코어 호환성을 확인하려는 사용자를 위해 프로토콜 계층, Android 클라이언트 선택, 코어 변경 후 검증 순서를 설명합니다.
클라이언트, 코어, Project V 분기 구분하기
먼저 사용자 인터페이스와 연결 엔진을 구분하세요. v2rayN, v2rayNG, v2flyNG는 노드 저장, 구독 그룹 관리, 설정 생성, 로그 표시를 담당하는 클라이언트입니다. 코어는 설정을 읽어 프록시 프로토콜, DNS 조회, 라우팅 분기를 처리합니다. 클라이언트가 구독 링크를 읽을 수 있다고 해서 연결에 사용하는 코어가 링크의 모든 매개변수를 지원하는 것은 아닙니다.
Project V는 관련 도구와 프로토콜을 아우르는 프로젝트 생태계이며, V2Fly 커뮤니티가 그 안의 V2Ray 코어를 관리합니다. Xray-core는 2020년에 V2Ray에서 분기된 뒤 독자적으로 발전해 왔습니다. 두 프로젝트는 일부 프로토콜과 설정 개념을 공유하지만, 새 기능과 필드 형식, 릴리스 주기는 달라졌습니다. 같은 프로그램의 테마 차이처럼 여기거나, 버전 번호가 더 높다는 이유만으로 프로젝트 간 기능을 비교하지 마세요.
- v2rayN: 데스크톱 클라이언트입니다. 현재 릴리스에서 제공하는 코어 선택지를 확인하고, 설치 폴더에 실행 파일이 있는지만 보지 말고 노드가 실제로 어떤 코어를 호출하는지 점검하세요.
- v2rayNG: Xray 코어를 사용하는 Android 클라이언트입니다. 특정 신기능을 지원하는지는 클라이언트에 포함된 코어 버전도 확인해야 합니다.
- v2flyNG: V2Fly 코어를 사용하는 Android 클라이언트입니다. V2Fly 설정 형식과 프로토콜 기능에 맞춰 배포하고 문제를 점검할 때 적합합니다.
VLESS·Vision·REALITY의 역할 구분하기
“VLESS + TCP + REALITY + Vision”은 함께 작동하는 설정 조합이지, 서로 바꿔 쓸 수 있는 네 가지 프로토콜 이름이 아닙니다. VLESS는 프록시 프로토콜 계층, TCP는 전송 방식, REALITY는 보안 계층 방식, Vision은 Xray의 흐름 제어 방식입니다. 서로 다른 계층을 하나의 옵션처럼 취급하면 구독 가져오기는 성공해도 실제 핸드셰이크가 실패하기 쉽습니다.
| 이름 | 주요 역할 | 확인할 항목 |
|---|---|---|
| VMess | 인증과 이에 필요한 데이터 보호 기능을 포함하는 프록시 프로토콜 | UUID, 전송 설정, 서버 호환성. 최신 설정에서는 일반적으로 alterId를 0으로 설정합니다. |
| VLESS | 경량 프록시 프로토콜로, 자체적으로 전송 암호화를 제공하지 않음 | UUID, 암호화 필드, 보안 계층, flow 설정 |
| WebSocket | 프록시 트래픽을 전달하는 전송 방식 | 경로, Host, 리버스 프록시 설정, TLS 사용 여부 |
| TLS | 인증서 검증 등의 메커니즘으로 보안 연결 설정 | SNI, 인증서 도메인, 시스템 시간, 인증서 체인 |
| XTLS Vision | 특정 연결 조합에 사용하는 Xray의 흐름 제어 방식 | xtls-rprx-vision, 이에 맞는 전송 방식과 양쪽의 지원 여부 |
| REALITY | Xray에서 제공하는 보안 계층 방식 | 서버 공개 키 매개변수, serverName, shortId, 클라이언트 핑거프린트 설정 |
VLESS의 encryption=none이 연결 전체가 반드시 평문으로 전송된다는 뜻은 아닙니다. 보안 보호 여부를 판단하려면 바깥 계층에서 TLS와 REALITY 중 무엇을 사용하는지 확인해야 합니다. 반대로 VLESS를 설정했다는 이유만으로 연결이 암호화되었다고 단정할 수도 없습니다. 배포 시 UUID만 복사하지 말고 서버에서 제공한 전체 조합을 그대로 설정하세요.
Vision은 범용 “속도 향상 버튼”도 아닙니다. 전송 방식과 연결 내용에 구체적인 요구 사항이 있으므로 WebSocket 노드에 flow=xtls-rprx-vision을 무조건 추가해서는 안 됩니다. REALITY와 Vision을 함께 사용하는 경우가 많지만 두 기능은 같은 뜻이 아닙니다. 하나를 켰다고 다른 하나까지 설정된 것은 아닙니다.
Xray와 V2Fly의 지원 범위 확인하기
코어를 선택할 때는 노드에서 실제 사용하는 기능을 기준으로 확인하세요. VMess와 일반적인 WebSocket·TLS 설정은 두 프로젝트에서 모두 구현되어 있지만, 그렇다고 설정 파일 전체를 그대로 옮길 수 있는 것은 아닙니다. 특히 V2Fly의 설정 형식별 차이, Xray 확장 필드, 새로운 전송 옵션은 사용하려는 릴리스에서 지원하는지 확인해야 합니다.
| 노드 요구 사항 | Xray 코어 | V2Fly 코어 | 선택 기준 |
|---|---|---|---|
| VMess | 지원 | 지원 | 인증, 전송 방식, 보안 계층, 버전 호환성 확인 |
| WebSocket + TLS | 일반적인 조합 지원 | 일반적인 조합 지원 | 경로, Host, SNI 등 매개변수를 동일하게 설정 |
| 기본 VLESS 설정 | 지원 | 사용할 릴리스의 프로토콜 구현과 설정 형식 확인 | VLESS라는 이름만으로 Vision 또는 REALITY 지원 여부를 알 수 없음 |
| XTLS Vision | 해당 기능을 지원하는 버전에서 사용 | Xray의 Vision 흐름 제어 미지원 | 노드에서 해당 flow를 요구하면 호환되는 Xray 버전 사용 |
| REALITY | 해당 기능을 지원하는 버전에서 사용 | Xray의 REALITY 설정 미지원 | 필드 이름을 바꿔 일반 TLS로 전환할 수 없음 |
기본 VLESS의 초기 구현과 릴리스별 차이를 “모든 V2Fly 버전이 지원한다”거나 “두 프로젝트의 VLESS가 완전히 같다”고 단순화해서는 안 됩니다. 실제 선택 기준은 더 명확합니다. 노드에서 REALITY 또는 xtls-rprx-vision을 요구한다면 V2Fly가 해당 필드를 무시하도록 시도하지 말고, Xray 지원 범위에 맞춰 클라이언트와 코어를 선택하세요.
Xray 코어
추천이 글에서는 VLESS, Vision, REALITY 조합을 우선적으로 다룹니다. 서버에서 제공한 보안 계층과 flow 매개변수를 유지하고, 클라이언트에 포함된 버전이 해당 설정을 인식하는지 확인하세요.
적합한 경우: 노드에서 REALITY 또는 XTLS Vision을 명시적으로 요구하는 연결 환경
V2Fly 코어
V2Fly 설정 체계에 맞춰 검증된 프로토콜 및 전송 조합을 사용하세요. VMess 등의 기존 배포 환경은 호환성만 확인하면 계속 사용할 수 있으며, 분기 이름이 다르다는 이유만으로 마이그레이션할 필요는 없습니다.
적합한 경우: 서버에서 V2Fly 설정을 제공하고 Xray 전용 기능에 의존하지 않는 환경
구독 매개변수와 연결 포트 확인하기
구독 업데이트는 노드 정보를 가져올 뿐, 호환되지 않는 프로토콜을 호환되는 프로토콜로 바꾸지 않습니다. VLESS 노드를 점검할 때는 먼저 주소, 포트, UUID를 확인한 다음 전송 방식, 보안 계층, SNI, flow를 살펴보세요. REALITY 노드는 서버에서 제공한 공개 키 매개변수, shortId, 클라이언트 핑거프린트도 각각 확인해야 합니다. 버전에 따라 필드 이름이 달라질 수 있으므로 현재 클라이언트 화면과 코어 문서를 기준으로 점검하세요.
두 포트는 서로 다른 용도입니다. 원격 포트는 서버에 연결할 때 사용하고, 로컬 수신 포트는 브라우저나 다른 프로그램이 이 기기의 프록시에 접속할 때 사용합니다. 원격 포트 443을 로컬 포트 10808로 바꿔도 연결 실패는 해결되지 않습니다. 또한 두 로컬 프로세스가 같은 수신 포트를 동시에 사용하면 코어가 시작되지 않을 수 있습니다. 숫자는 설정 예시일 뿐 현재 기기의 실제 값이 아닙니다.
- 원본 노드 정보를 보관하세요.수정하기 전에 구독 그룹과 노드 매개변수를 저장하고, token이나 UUID가 포함된 전체 링크를 공개하지 마세요.
- 보안 계층을 대조하세요.서버에서 REALITY를 요구하면 클라이언트에서 임의로 TLS로 바꾸지 마세요. 서버에서 TLS를 요구하는 경우에도 REALITY 공개 키를 임의로 입력하지 마세요.
- 흐름 제어 설정을 대조하세요.서버 설정에서 요구하고 조합이 지원되는 경우에만
xtls-rprx-vision을 입력하세요. - 전송 필드를 대조하세요.WebSocket 경로의
/example-ws는 예시이므로 서버의 실제 값으로 바꿔야 합니다. 이를 근거로 TCP 노드에 경로를 추가하지 마세요. - 실제 연결 지연 시간을 테스트하세요.테스트 시각과 로그를 기록하세요. TCPing은 대상 포트에 연결할 수 있는지만 보여 줄 뿐, 인증과 보안 핸드셰이크의 성공 여부를 확인하지는 않습니다.
데스크톱과 Android 설정 방법 선택하기
데스크톱에서는 먼저 v2rayN의 현재 노드가 어떤 코어를 사용하는지 확인한 뒤 테스트하세요. 로컬 수신과 프록시 관련 매개변수를 확인하려면 「설정」→「매개변수 설정」에서 살펴보세요. 릴리스에 따라 메뉴 위치가 달라질 수 있으므로 실제 화면을 기준으로 확인해야 합니다. 구독 그룹은 구독 출처를 관리하고, 구독 업데이트는 노드 정보를 새로 고칩니다. 둘 다 코어 전환과는 다른 작업입니다.
설정 방법: 노드 특성에 맞춰 클라이언트 선택
데스크톱: v2rayN
- REALITY 또는 Vision 노드에서는 실제로 호환되는 Xray 코어를 사용하는지 확인하세요.
- 기존 구독 그룹을 유지하고 같은 노드로 전환 전후를 테스트하세요.
- 먼저 코어 시작 로그를 확인한 다음 시스템 프록시와 라우팅 분기를 점검하세요.
Android: 코어에 맞춰 선택
- Xray 기능이 필요하면 요구 사항을 충족하는 버전이 포함된 v2rayNG를 선택하세요.
- V2Fly 설정으로 배포한다면 v2flyNG를 사용하고 필드 호환성을 확인하세요.
- 각 클라이언트에서 구독을 따로 업데이트하고, 앱별 프록시와 기기 규칙도 각각 설정하세요.
구독 주소를 함께 사용해도 로컬 설정이 동기화되는 것은 아닙니다. 양쪽에 같은 노드가 표시되는지는 구독 내용, 파싱 기능, 업데이트 시점에 따라 달라집니다.
마이그레이션할 때 코어, DNS, 라우팅, 프록시 모드를 한꺼번에 변경하지 마세요. 노드를 그대로 둔 상태에서 새 코어가 시작되는지 확인하고 실제 연결 지연 시간을 테스트한 뒤 라우팅 분기를 하나씩 복원하세요. 시스템 프록시와 Android의 트래픽 처리 방식은 다르므로 같은 노드를 사용해도 모든 앱의 동작을 직접 비교할 수는 없습니다.
로그로 호환성 오류와 네트워크 오류 구분하기
먼저 어느 계층에서 실패했는지 판단하세요. 설정을 읽는 단계에서 오류가 나면 필드와 코어를 우선 확인하고, 원격 서버 연결이 시간 초과되면 주소, 포트, 네트워크를 살펴보세요. 핸드셰이크 오류가 발생하면 보안 계층 매개변수를 대조하세요. 오류가 날 때마다 구독을 다시 업데이트하지 마세요. 기존 비교 조건을 잃을 수 있고 실제 원인을 해결하지 못할 수도 있습니다.
REALITY 노드를 가져올 수 있는데 연결은 왜 실패하나요?
가져오기는 클라이언트가 링크를 파싱하는 과정이고, 연결은 코어가 수행합니다. 먼저 시작 로그에서 Xray 버전과 실제 호출 경로를 확인한 뒤 서버 공개 키 매개변수, serverName, shortId, 핑거프린트 설정을 대조하세요. 마지막으로 실제 연결 지연 시간을 테스트하세요. 노드가 목록에 표시되는지만 확인해서는 안 됩니다.
로그에 unknown field가 표시됩니다. 해당 줄을 지워도 되나요?
먼저 설정이 어느 프로젝트의 어떤 형식인지 확인하세요. 오류가 난 필드가 REALITY 또는 Vision에 사용된다면 이를 삭제할 경우 연결 동작이 달라질 수 있으므로 호환성 해결 방법으로 볼 수 없습니다. 해당 필드를 지원하는 코어 버전을 사용하거나 서버에서 완전한 호환 설정으로 구성된 다른 노드를 제공받으세요.
REALITY를 TLS로 바꾸면 다른 코어에서도 사용할 수 있나요?
클라이언트 설정만 바꿔서는 안 됩니다. 두 보안 계층은 핸드셰이크와 서버 설정이 다릅니다. 서버에 TLS 인바운드가 별도로 설정되어 있고 해당 포트, 인증서 도메인, 인증 정보가 제공된 경우에만 클라이언트에서 그 매개변수로 연결할 수 있습니다.
TCPing은 정상이지만 실제 연결 지연 시간 테스트가 시간 초과됩니다. 어디부터 확인해야 하나요?
먼저 UUID, flow, 보안 계층, SNI를 확인하고 인증 실패나 핸드셰이크 실패가 로그에 있는지 살펴보세요. 노드의 실제 연결 지연 시간은 정상이지만 브라우저에서 접속할 수 없다면 시스템 프록시, 로컬 포트, 라우팅 규칙을 확인하세요. 테스트 대상 자체에 접근할 수 있는지도 점검해야 합니다.
Xray로 바꾸면 반드시 더 빨라지나요?
코어 이름만으로 속도를 판단할 수 없습니다. 같은 네트워크, 같은 서버, 같은 테스트 대상을 사용해 실제 연결 지연 시간과 요청 결과를 각각 기록하세요. 서버 부하, 회선, DNS, 라우팅이 모두 사용 경험에 영향을 줍니다. 호환성 문제가 해결되었다고 해서 처리량이 반드시 높아지는 것도 아닙니다.
반복해서 검증할 수 있는 순서를 유지하세요. 코어가 정상적으로 시작되는지 확인하고, 노드로 실제 요청이 성공하는지 확인한 뒤, 앱 트래픽이 올바르게 전달되는지 점검합니다. 추가 설정 방법은 실제 연결 지연 시간 테스트와 시스템 프록시 설정을 참고하세요. Android 설정은 Android 사용 안내에서 확인할 수 있습니다. 코어 선택 기준은 특정 프로토콜 이름 하나가 아니라 서버의 요구 사항과 클라이언트의 실제 기능입니다.