코어를 고를 때는 클라이언트 이름보다 노드 요구사항을 먼저 확인해야 합니다. 이 글에서는 클라이언트, 프로토콜, 전송 방식, 보안 계층을 구분해 VLESS와 REALITY, XTLS Vision과 일반 TLS의 차이를 설명합니다. 안드로이드에서의 선택, 데스크톱 설정 확인 방법, 전환에 실패했을 때 점검 순서도 안내합니다. 기존 VMess 노드를 계속 사용해도 되는지 판단하는 데도 도움이 됩니다.
1. Xray와 V2Fly: 같은 뿌리, 다른 설정 범위
이 생태계를 이해하려면 Project V부터 살펴볼 필요가 있습니다. V2Ray는 Project V의 핵심 프록시 도구이며, V2Fly 커뮤니티가 V2Ray의 개발을 이어가고 있습니다. Xray-core는 V2Ray 프로젝트에서 분기한 뒤 독자적인 기능과 설정 체계를 발전시켰습니다. 따라서 두 코어는 인바운드, 아웃바운드, 라우팅 개념이 비슷하지만 모든 JSON 설정 파일을 서로 그대로 사용할 수 있는 것은 아닙니다.
클라이언트는 노드 목록, 구독 업데이트, 인터페이스 설정과 실행을 관리하고, 코어는 실제 연결 처리와 프로토콜 핸드셰이크, 라우팅을 담당합니다. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 데스크톱용 v2rayN에서 사용할 수 있는 코어와 호출 방식은 배포 패키지와 설정 유형에 따라 다릅니다. 문제를 확인할 때는 시작 로그에 표시된 실행 파일과 버전을 기준으로 살펴보세요.
- 클라이언트 이름: 조작에 사용하는 앱을 나타낼 뿐, 어떤 코어가 실행 중인지 단독으로 판단할 수는 없습니다.
- 노드 프로토콜: VMess나 VLESS처럼 프록시 연결의 프로토콜 구조를 정합니다.
- 전송 방식: TCP나 WebSocket처럼 프록시 데이터를 전달하는 방식을 정합니다.
- 보안 및 흐름 제어: TLS, REALITY, Vision은 서로 다른 설정 항목이므로 각각 확인해야 합니다.
2. VLESS·XTLS Vision·REALITY 지원 비교
VLESS 자체에는 전송 암호화 기능이 없으며, 일반적으로 TLS나 REALITY와 함께 설정합니다. V2Fly에도 VLESS 구현이 있으므로 “VLESS를 쓰려면 반드시 Xray를 사용해야 한다”는 말은 정확하지 않습니다. flow, 보안 계층, 전송 방식이 어떻게 조합되었는지 확인해야 합니다. Xray의 확장 기능을 근거로 V2Fly도 같은 이름의 기능을 지원한다고 추정해서는 안 됩니다.
| 설정 기능 | Xray 코어 | V2Fly 코어 | 선택 기준 |
|---|---|---|---|
| VMess | 지원 | 지원 | 전송 방식, TLS, 서버 설정을 추가로 확인하세요 |
| 기본 VLESS | 지원 | 해당 기능 구현 있음 | 모든 확장 기능 조합을 공통 설정으로 사용할 수는 없음 |
| XTLS Vision | 해당 흐름 제어 지원 | Xray의 Vision 흐름 제어 미지원 | xtls-rprx-vision이 있으면 호환되는 Xray 환경을 선택하세요 |
| REALITY | 지원 | Xray의 REALITY 설정 미지원 | 키 자료, SNI, shortId, 지문 설정을 확인하세요 |
| 라우팅 | 규칙 설정 지원 | 규칙 설정 지원 | 설정 형식, 규칙 의미, 데이터 파일을 확인하세요 |
XTLS Vision은 흐름 제어 방식이며, 흔히 사용하는 설정 값은 xtls-rprx-vision입니다. 전송 방식 이름이 아니므로 노드의 TLS 스위치 이름을 Vision으로 바꾼다고 활성화되지 않습니다. REALITY는 Xray의 보안 방식으로, 클라이언트와 서버의 설정값이 서로 일치해야 합니다. 구독 인코딩 형식이나 독립적인 클라이언트가 아닙니다.
일반 TLS는 보통 인증서와 도메인 검증을 사용합니다. REALITY는 핸드셰이크 방식과 인증 매개변수가 다르므로 인증서 검증을 끄는 것으로 대체할 수 없습니다. 서버에서 허용한 serverName과 클라이언트의 키 자료 및 shortId가 일치해야 합니다. 값이 하나라도 다르면 포트에 연결되더라도 프록시 핸드셰이크는 실패할 수 있습니다.
3. 설정 방법: flow와 security의 위치부터 구분하기
아래는 필드의 계층 구조를 확인하기 위한 Xray 아웃바운드 예시로, VLESS와 Vision, 일반 TLS의 조합을 보여 줍니다. 도메인은 예시용으로 예약된 도메인이며 UUID는 형식 설명을 위한 값이므로 그대로 사용할 수 있는 노드 설정이 아닙니다. 실제로 적용할 때는 서버에서 제공한 주소, 사용자 ID, 인증서 도메인으로 바꾸고 서버에서 해당 흐름 제어를 활성화했는지 확인하세요.
{
"outbounds": [
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "example.com",
"port": 443,
"users": [
{
"id": "e1dd2b67-68ca-4c8f-a92b-27eb305d91e7",
"encryption": "none",
"flow": "xtls-rprx-vision"
}
]
}
]
},
"streamSettings": {
"network": "tcp",
"security": "tls",
"tlsSettings": {
"serverName": "example.com"
}
}
}
]
}
예시의 encryption: "none"은 VLESS 사용자 필드이며 연결 전체가 평문이라는 뜻은 아닙니다. 바깥쪽의 security: "tls"가 전송 보안을 담당합니다. flow는 사용자 객체 안에, security는 streamSettings 안에 설정합니다. 계층이 잘못되면 오류가 발생하거나 설정이 예상대로 적용되지 않을 수 있습니다.
- REALITY로 변경:
tls를reality로 바꾸는 것만으로는 충분하지 않습니다. 해당하는realitySettings를 사용하고 서버에서 제공한 매개변수를 입력해야 합니다. - 키 필드: 공유 링크에는 서버 공개 키 자료가
pbk로 포함되는 경우가 많습니다. Xray 버전에 따라 JSON에서publicKey또는password라는 이름을 사용할 수 있으므로 실제 코어 버전의 설정 정의에 맞춰 생성하세요. 오래된 스크린샷을 그대로 따라 해서는 안 됩니다. - 기타 매핑: 공유 링크의
sni,sid,fp는 보통 인터페이스의 serverName, shortId, 지문 옵션에 대응합니다. 가져온 뒤에도 항목별로 확인하세요. - 기존 설정 마이그레이션: 이전 XTLS 설정은 필드 이름을 일괄 변경하는 것만으로 Vision 설정으로 옮길 수 없습니다. 전송 방식, 흐름 제어, 서버 지원 여부를 함께 확인해야 합니다.
4. v2rayNG·v2flyNG·v2rayN 선택 방법
현재 구독에 VLESS, Vision, REALITY 조합이 명시되어 있다면 안드로이드에서는 Xray 환경인 v2rayNG를 우선 사용하세요. 기존 설정이 V2Fly 설정 체계를 기준으로 하며 Xray 기능에 의존하지 않는다면 v2flyNG를 사용할 수 있습니다. 이름이 다르다는 이유만으로 정상 작동하는 VMess 설정을 옮길 필요는 없습니다.
Xray 코어 환경
추천이 글에서 다루는 VLESS, Vision, REALITY 사용 사례에서는 안드로이드용 v2rayNG를 선택하세요. 데스크톱에서는 v2rayN에서 해당 노드가 실제로 어떤 Xray 코어를 호출하는지 확인하세요.
적합한 경우: 서버에서 Xray 확장 기능을 요구하는 노드
V2Fly 코어 환경
안드로이드에서 v2flyNG를 사용해 기존 V2Fly 설정과 같은 방식으로 유지하세요. 기본 프로토콜로 연결할 수 있는지는 전송 방식과 매개변수가 일치하는지에 따라 달라집니다.
적합한 경우: 사용할 수 있는 V2Fly 설정이 있고 Vision이나 REALITY에 의존하지 않는 경우
확인 방법: 데스크톱과 안드로이드에서 각각 테스트
데스크톱: v2rayN
- 가져온 뒤 프로토콜, 전송 방식, 보안 방식과 flow를 확인합니다.
- 연결을 시작하고 로그에서 코어 이름과 버전을 확인합니다.
- 시스템 프록시가 현재 로컬 수신 포트를 가리키는지 확인합니다.
안드로이드: 코어에 맞춰 선택
- REALITY 또는 Vision 노드에는 v2rayNG를 사용합니다.
- V2Fly 설정은 v2flyNG에서 가져온 결과를 확인합니다.
- VPN 연결을 허용한 다음 앱별 프록시 범위를 확인합니다.
같은 구독을 두 기기에서 사용할 수 있지만 노드 이름이 같다고 해서 두 기기에서 해석한 필드와 지원 기능까지 완전히 같다는 뜻은 아닙니다.
5. 코어를 바꾼 뒤 연결되지 않을 때: 포트부터 핸드셰이크까지 점검하기
먼저 “코어가 시작되지 않음”과 “코어는 시작됐지만 원격 연결에 실패함”을 구분하세요. 전자는 JSON, 필드 지원 여부, 파일 경로, 로컬 포트 사용 여부를 확인해야 합니다. 후자는 서버 주소, 보안 계층 매개변수, 네트워크 연결, 시스템 시간을 점검하세요. 모든 실패를 코어 속도 문제로 돌리면 실제로 해결할 수 있는 설정 오류를 놓치게 됩니다.
위의 로컬 주소와 포트는 점검 방법을 설명하기 위한 예시이며, 모든 클라이언트의 기본값을 뜻하지 않습니다. 먼저 현재 클라이언트에 표시된 SOCKS 수신 포트를 확인하세요. 실제 포트가 10808이 아니라면 아래 명령을 수정해야 합니다. 원격 포트 443과 로컬 프록시 포트는 서로 다른 연결 구간에 속하므로 바꿔 쓸 수 없습니다.
curl --proxy socks5h://127.0.0.1:10808 https://example.com/
- 로컬 수신 확인: 로컬 프록시에 즉시 연결할 수 없다는 메시지가 나오면 먼저 코어가 정상적으로 시작됐는지, 포트가 일치하는지 확인하고 같은 포트를 사용하는 기존 프로세스를 종료하세요.
- 가져온 설정 확인: 원본 노드 매개변수와 대조해 UUID, 서버 포트, flow, SNI, REALITY 매개변수를 확인하세요. Base64는 인코딩 방식일 뿐, 누락된 필드를 채워 주지 않습니다.
- 원격 핸드셰이크 확인: TLS 또는 인증 오류가 발생하면 시스템 시간, 도메인, 키 자료를 확인하세요. 검증을 끄는 것은 일반적인 해결책이 아닙니다.
- 프록시 적용 범위 확인: 명령어는 접속되는데 브라우저가 접속되지 않는다면 시스템 프록시, 앱별 프록시, 라우팅 규칙과 DNS를 확인하세요. 이때 서버 프로토콜부터 바꾸는 것은 적절하지 않습니다.
코어 차이를 테스트할 때는 같은 노드, 네트워크, 대상, 비슷한 시간대를 유지하세요. 먼저 Mux 같은 추가 변수를 끄고 로그와 연결 결과를 확인합니다. 노드 부하, 네트워크 경로, 서버 속도 제한, 대상 사이트 응답이 모두 속도에 영향을 줄 수 있습니다. 더 많은 프로토콜을 지원한다고 해서 모든 회선에서 처리량이 더 높은 것은 아닙니다.
6. 코어 선택 관련 자주 묻는 질문
구독에 VLESS라고 적혀 있는데 v2flyNG에서 사용할 수 없는 이유는 무엇인가요?
먼저 노드 세부 정보를 열어 REALITY나 xtls-rprx-vision 설정이 있는지 확인하세요. 이런 확장 기능은 기본 VLESS와 같은 뜻이 아닙니다. 노드에서 해당 기능을 요구한다면 v2rayNG로 원본 링크를 가져온 뒤 필드가 모두 들어왔는지 확인하세요.
v2rayN에서 코어 파일을 바꿨는데도 시작 오류가 발생하는 이유는 무엇인가요?
먼저 시작 로그를 읽고 실제로 호출된 파일과 버전이 바뀌었는지 확인한 다음 생성된 설정을 점검하세요. 구버전 클라이언트는 여전히 이전 필드에 맞춰 JSON을 생성할 수 있습니다. 실행 파일만 교체한다고 클라이언트의 설정 생성기와 새 코어의 호환성이 보장되지는 않습니다.
REALITY 포트에는 연결되지만 웹 페이지가 계속 시간 초과되는 경우 어떻게 해야 하나요?
포트에 연결된다는 것은 기본 네트워크 연결이 성립했다는 뜻일 뿐입니다. SNI, shortId, 키 자료, 지문, flow를 확인하고 원격 핸드셰이크 로그도 살펴보세요. 직접 프록시 테스트는 성공하지만 앱에서 실패한다면 시스템 프록시와 라우팅 규칙을 확인하세요.
기존 VMess 노드가 정상 작동하는데 Xray로 옮겨야 하나요?
프로토콜 이름만으로 반드시 옮겨야 할 이유는 없습니다. 먼저 현재 설정을 유지하세요. 서버에서 새 노드를 제공하거나, 현재 클라이언트가 필요한 기능을 지원하지 않거나, 명확한 호환성 문제가 확인된 경우에만 노드별로 테스트하며 옮기세요.
최종 선택은 세 단계로 확인하면 됩니다. 먼저 서버의 요구사항을 확인하고, 다음으로 클라이언트가 어떤 필드를 생성할 수 있는지 살펴본 뒤, 마지막으로 실제 실행 중인 코어가 해당 필드를 받아들이는지 확인하세요. 이 세 단계를 나누면 클라이언트 이름만으로 호환성을 추측하는 것보다 정확합니다.