코어는 노드 설정을 실행할 수 있는지 결정하고, 클라이언트는 가져오기·편집·시스템 연결을 담당합니다. VLESS, REALITY, Vision 조합이 필요하다면 Xray 지원 여부를 먼저 확인하세요. 기존 VMess 노드와 V2Fly 설정을 사용 중이라면 이름이 다르다는 이유만으로 옮기기보다 현재 설정이 작동하는지 먼저 검증하면 됩니다. 아래에서 프로토콜, 필드, 클라이언트, 문제 해결 순서로 실제 선택 방법을 살펴봅니다.
1. Project V, V2Fly, Xray-core의 관계
Project V는 V2Ray를 중심으로 한 네트워크 도구 및 기술 생태계입니다. V2Fly 커뮤니티는 V2Ray-core를 계속 관리하고 있습니다. Xray-core는 2020년 관련 코드에서 분기해 독자적인 개발 경로를 구축했습니다. 두 코어는 공통 기반을 갖지만, 이후 추가된 전송 방식과 설정 필드, 구현 세부 사항이 서로 호환된다고 보장되지는 않습니다.
‘V2Ray 노드’는 구독 서비스에서 흔히 쓰이는 포괄적인 표현이며, 이것만으로 코어를 판단할 수는 없습니다. 실제 연결은 VMess일 수도, VLESS일 수도 있고 전송 방식은 WebSocket이나 TCP일 수 있습니다. 구독 그룹 이름이 아니라 펼쳐진 프로토콜과 매개변수를 기준으로 확인하세요.
- 클라이언트 계층: 구독을 관리하고 노드를 선택하며 시스템 프록시나 가상 네트워크 인터페이스를 설정합니다. 데스크톱용 v2rayN과 안드로이드용 v2rayNG, v2flyNG가 여기에 해당합니다.
- 코어 계층: 설정을 해석하고 프로토콜 핸드셰이크, DNS 조회, 라우팅 규칙 적용, 데이터 전달을 수행합니다. Xray-core와 V2Fly의 V2Ray-core가 이 계층에 속합니다.
- 서버 계층: 접속 프로토콜, 인증 매개변수, 전송 조건을 결정합니다. 로컬 코어를 바꿔도 서버의 VMess가 자동으로 VLESS로 바뀌지는 않습니다.
2. 프로토콜 지원: VLESS, REALITY, Vision 구분하기
VLESS는 프록시 프로토콜이고, REALITY는 보안 전송 방식이며, xtls-rprx-vision은 Xray에서 사용하는 흐름 제어 옵션입니다. 세 가지는 서로 다른 설정이며, 어느 하나의 이름만으로 전체 연결 구성을 설명할 수 없습니다. 흔히 쓰이는 조합은 VLESS, TCP, REALITY이며, 서버 요구 사항에 따라 Vision을 설정합니다.
| 기능 또는 조합 | Xray-core | V2Fly의 V2Ray-core | 확인할 항목 |
|---|---|---|---|
| VMess 및 일반적인 WebSocket/TLS 설정 | 해당 설정 지원 | 해당 설정 지원 | 인증 매개변수, 경로, Host, TLS 이름 |
| VLESS 기본 프로토콜 | 지원하며 관련 기능을 계속 확장 중 | 이름만으로 완전히 지원되지 않는다고 단정할 수 없습니다. 버전과 구현 범위를 확인해야 합니다. | 프로토콜 이름뿐 아니라 전체 전송 조합 |
| VLESS + REALITY | 주요 사용 사례에 해당 | Xray의 REALITY 설정을 그대로 가져와 사용할 수는 없습니다. | 서버 이름, 키 관련 매개변수, shortId |
| xtls-rprx-vision | 해당 흐름 제어 조합 지원 | 이름이 같다고 바로 대체할 수 있는 기능은 아닙니다. | 클라이언트와 서버의 flow 설정이 일치하는지 |
| 기본 DNS 및 규칙 기반 라우팅 | 지원 | 지원 | 필드 구조, 규칙 순서, 데이터 파일 형식 |
VMess는 인증 방식도 확인해야 합니다. 일반적인 AEAD 노드에서는 alterId: 0을 사용합니다. 오래된 가이드에 나온 0이 아닌 값을 그대로 적용하지 마세요. 이는 프로토콜 호환 조건이지, 값을 임의로 높여 속도를 개선하는 성능 설정이 아닙니다.
결론: 전체 연결 조합에 맞춰 코어 선택하기
노드에서 REALITY 또는 xtls-rprx-vision을 명시적으로 요구한다면 해당 기능을 지원하는 Xray 환경을 선택하세요. VMess, WebSocket, TLS만 필요하다면 기존 환경부터 검증하고, 속도를 높이기 위한 목적으로 무조건 이전할 필요는 없습니다.
3. 설정 호환성: JSON 형식이 같아도 그대로 바꿔 쓸 수는 없습니다
두 코어 모두 inbounds, outbounds, routing 등의 개념을 사용하지만, 필드가 비슷하다는 것은 구조에 공통 기반이 있다는 뜻일 뿐입니다. 새 전송 방식과 보안 설정, DNS 동작, V2Fly의 설정 형식별 차이로 인해 설정 파싱이나 실행에 문제가 생길 수 있습니다.
구독 링크는 또 다른 형식입니다. 클라이언트는 보통 공유 링크를 내부 노드 형식으로 해석한 다음 해당 코어용 설정을 생성합니다. 따라서 ‘구독 가져오기 성공’은 인터페이스가 내용을 받아들였다는 뜻일 뿐, 생성된 설정을 코어가 처리할 수 있다거나 원격 서버와 핸드셰이크에 성공했다는 의미는 아닙니다.
- 먼저 프로토콜 필드를 확인하세요:
protocol이 VMess인지 VLESS인지 확인하고 인증 정보가 서버 설정과 일치하는지 점검합니다. 스크린샷이나 공개 로그에 인증 정보를 그대로 노출하지 마세요. - 다음으로 전송 필드를 확인하세요:
streamSettings의network와security를 점검합니다. TCP와 WebSocket은 서로 대체할 수 없으며, TLS와 REALITY도 같은 옵션이 아닙니다. - 흐름 제어는 별도로 확인하세요: 서버에서 Vision을 요구한다면 생성된 설정의
flow가xtls-rprx-vision인지 확인하세요. 일반 VMess 노드에는 이 값을 추가하지 마세요. - 마지막으로 라우팅을 확인하세요: 각 규칙이 참조하는 아웃바운드 태그가 실제로 존재하는지 확인합니다. 태그는 설정 내부에서 참조하는 이름일 뿐, 이름을 ‘프록시’로 지정한다고 프록시 기능이 생기는 것은 아닙니다.
아래는 참조 관계를 설명하기 위한 일반적인 라우팅 필드 일부 예시이며, 바로 실행할 수 있는 전체 설정은 아닙니다. 이름이 direct인 직접 연결 아웃바운드가 이미 있고, 코어가 private 태그를 포함한 GeoIP 데이터 파일을 불러올 수 있다고 가정합니다.
{
"routing": {
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}4. 클라이언트 선택: v2rayN, v2rayNG, v2flyNG
데스크톱에서는 노드 호환성을 따지기 전에 v2rayN이 현재 어떤 코어를 사용하는지 확인하세요. 안드로이드에서는 프로젝트 경로를 기준으로 구분할 수 있습니다. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 이름이 비슷하다고 프로토콜 지원이 완전히 같거나, 같은 구독을 가져왔을 때 사용 가능한 노드가 동일하다는 뜻은 아닙니다.
Xray 경로: v2rayN의 해당 코어 또는 v2rayNG
추천노드에서 VLESS, REALITY, Vision 조합을 요구한다면 이 구성을 우선 고려하세요. 클라이언트에 포함된 코어가 서버의 구체적인 매개변수를 지원하는지도 확인해야 합니다.
적합한 경우: 구독에 REALITY 또는 Vision 노드가 명시되어 있고 해당 프로토콜 기능이 필요한 경우
V2Fly 경로: v2flyNG 또는 기존 V2Fly 환경
검증된 VMess 등 기존 설정에 의존하고 V2Fly 설정 체계를 사용 중이라면 계속 이용할 수 있습니다. 기존 설정이 안정적으로 작동하는지가 선택 기준이지, 오래된 설정을 모두 뒤처진 것으로 볼 필요는 없습니다.
적합한 경우: 기존 V2Fly 배포를 유지하거나 호환성이 확인된 노드와 라우팅 규칙을 재사용하는 경우
v2rayN에서는 먼저 ‘설정’ → ‘매개변수 설정’에서 로컬 리스너와 관련 코어 설정을 확인하세요. 배포판에 따라 옵션 이름과 위치가 달라질 수 있습니다. 예상한 코어 옵션이 보이지 않으면 현재 릴리스 안내와 실행 로그를 기준으로 판단하세요. 호환성을 추측하려고 프로그램 폴더의 실행 파일을 바로 교체하지 마세요.
설치 및 설정: 데스크톱과 안드로이드에서 각각 확인하기
데스크톱: v2rayN
- 시작 로그에 표시된 코어 이름과 버전을 기록합니다.
- 노드를 가져온 뒤 프로토콜, 전송 방식, 보안 설정을 확인합니다.
- 로컬 포트를 확인한 다음 시스템 프록시와 규칙 기반 라우팅을 검증합니다.
안드로이드: 코어에 맞춰 클라이언트 선택
- REALITY/Vision이 필요하다면 v2rayNG를 우선 확인합니다.
- 기존 V2Fly 설정은 먼저 v2flyNG에서 검증합니다.
- 시스템 VPN 권한과 앱별 설정이 대상 앱에 적용되는지 확인합니다.
같은 구독을 두 기기에서 사용할 수는 있지만, 프로토콜 파싱 결과와 라우팅 정책, 앱 트래픽 처리 범위는 각각 확인해야 합니다.
5. 이전 후 검증: 코어 실행부터 프록시 경유까지 확인하기
이전할 때는 한 번에 하나의 변수만 바꾸세요. 기존 구독과 라우팅 설정을 백업한 다음 호환되는 같은 노드로 새 코어를 검증합니다. 노드, DNS, 라우팅 모드, 로컬 포트를 동시에 변경하면 연결이 실패해도 어느 단계에서 문제가 생겼는지 파악하기 어렵습니다.
- 실행 상태 확인: 클라이언트 로그를 열어 설정 파싱 오류, 알 수 없는 필드, 포트 사용 중 여부부터 확인합니다. 이 단계에서는 원격 회선의 속도를 판단할 필요가 없습니다.
- 리스너 확인: v2rayN의 ‘설정’ → ‘매개변수 설정’에서 로컬 리스닝 포트를 확인합니다. 아래 예시는 SOCKS 리스너
127.0.0.1:10808이 활성화된 경우를 가정하며, 모든 설치 환경의 고정값은 아닙니다. - 프록시를 명시적으로 지정: 명령줄에서 요청을 보내 브라우저가 시스템 프록시를 읽는지 여부를 배제합니다. 아래 명령은 로컬에서 SOCKS 서비스를 실제로 제공하는 경우에만 사용할 수 있습니다.
- 라우팅 확인: 테스트 대상이 프록시 아웃바운드와 일치하도록 임시 설정하고, 로그를 통해 실제 사용된 아웃바운드를 확인합니다. 요청이 성공했다는 사실만으로 직접 연결 규칙에 따라 우회되지 않았다고 볼 수는 없습니다.
- 앱에서 확인: 다음으로 시스템 프록시나 해당 네트워크 연결 방식을 활성화하고 평소 사용하는 앱을 테스트합니다. 안드로이드에서는 앱별 규칙에서 해당 앱이 제외되지 않았는지도 확인하세요.
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/Windows 터미널에서는 명령 별칭의 간섭을 피하기 위해 curl.exe를 사용할 수 있습니다. 여기서 socks5h는 대상 도메인의 처리를 프록시 측에 맡긴다는 뜻입니다. 이것만으로 원격 프록시 아웃바운드가 선택된다고 보장할 수는 없으며, 이후에도 코어의 라우팅 규칙이 적용됩니다. 예시의 연결 제한 시간 10초와 전체 제한 시간 20초는 테스트용 설정이지 속도 보장이 아닙니다.
| 증상 | 우선 확인할 계층 | 다음 조치 |
|---|---|---|
| 코어가 시작 직후 종료됨 | 설정 파싱, 파일 경로, 로컬 리스너 | 로그에서 처음 나타난 오류를 확인하고 원격 노드부터 바꾸지 마세요. |
| 로컬 포트 연결이 거부됨 | 코어 프로세스, 주소, 포트 | 리스너가 활성화되어 있는지, 테스트 포트가 설정과 일치하는지 확인합니다. |
| REALITY 핸드셰이크 실패 | 매개변수 일치 여부, 시스템 시간, 서버 연결 가능 여부 | 서버 이름, 키 관련 매개변수, shortId를 확인합니다. |
| 명령줄에서는 성공하지만 브라우저에서는 실패 | 시스템 프록시, 브라우저 정책, 확장 프로그램 설정 | 먼저 프록시 적용 범위를 확인한 다음 DNS와 라우팅 차이를 점검합니다. |
6. 성능 판단: 코어 이름만으로는 성능을 비교할 수 없습니다
Xray와 V2Fly의 성능 차이는 프로토콜과 회선을 함께 고려해야 합니다. 출구 구간의 혼잡, 왕복 지연 시간, 패킷 손실, 서버 부하, 기기의 잦은 절전이 코어 차이보다 더 큰 영향을 줄 수 있습니다. Vision은 해당 트래픽에서 중복 처리를 줄이는 방식일 뿐, 모든 웹페이지 접속이 눈에 띄게 빨라진다는 뜻은 아닙니다.
- 테스트 조건을 동일하게 유지하세요: 같은 기기, 네트워크, 서버, 대상 주소를 사용합니다. 한쪽은 Wi-Fi, 다른 쪽은 모바일 네트워크에서 측정하는 일을 피하세요.
- 공통 기능만 비교하세요: 두 코어를 비교할 때는 양쪽이 모두 지원하는 동일한 프로토콜 조합을 사용합니다. VMess/WebSocket과 VLESS/REALITY를 비교하면 전체 구성의 차이를 측정하는 셈입니다.
- 지표를 나눠 살펴보세요: 연결 성공률, 최초 응답 시간, 지속 전송 성능, 기기 CPU 사용량을 각각 확인하세요. 한 번 측정한 지연 시간으로 안정성을 판단하지 마세요.
- 반복 검증하세요: 각 요청을 5회씩 번갈아 실행하고 결과를 기록하면 일시적인 네트워크 변동의 영향을 줄일 수 있습니다. 이는 테스트 방법이며, 이 글에서 실측 성능 순위를 제시하는 것은 아닙니다.
결론: 이전은 명확한 이유가 있을 때 진행하세요
필요한 기능이 없거나 확인된 호환성 문제가 있거나, 같은 조건에서 재현되는 장애가 있을 때만 코어 변경을 해결책으로 고려하세요. 노드 자체에 연결할 수 없다면 먼저 회선과 매개변수 문제를 해결해야 합니다.
7. 자주 묻는 질문: 가져오기 성공, 전환 실패, 혼합 구독
구독은 업데이트되는데 REALITY 노드에 연결되지 않는 이유는 무엇인가요?
업데이트 성공은 구독 요청으로 내용을 받아왔다는 뜻일 뿐입니다. 노드 편집 화면에서 VLESS, REALITY, 서버 이름, 키 관련 매개변수, shortId, flow를 차례로 확인하세요. 그런 다음 시작 로그에서 필요한 기능을 지원하는 Xray 코어가 실제로 실행 중인지 확인합니다.
v2rayNG에서 v2flyNG로 바꾸면 기존 노드를 모두 계속 사용할 수 있나요?
노드 수만으로 사용할 수 있는지 판단할 수는 없습니다. 프로토콜과 전송 방식이 명확히 호환되는 노드부터 골라 테스트하세요. REALITY 또는 Vision을 요구하는 노드는 일반 VLESS 노드처럼 취급하면 안 됩니다. 기존 클라이언트 설정을 보존하고 검증을 마친 뒤 평소 사용 환경을 이전하세요.
코어를 바꾼 뒤 포트가 사용 중이라고 나옵니다. 10808을 다른 포트로 바꿔야 하나요?
먼저 다른 클라이언트나 종료되지 않은 코어 프로세스를 닫은 뒤 ‘설정’ → ‘매개변수 설정’에서 리스닝 주소와 포트를 확인하세요. 포트를 바꿔야 한다면 테스트 명령과 해당 포트를 사용하는 앱 설정도 함께 수정해야 합니다. 한 곳만 바꾸면 안 됩니다.
하나의 구독에 VMess와 VLESS가 함께 있으면 클라이언트를 두 개 설치해야 하나요?
프로토콜이 섞여 있다는 이유만으로 클라이언트를 두 개 설치할 필요는 없습니다. 먼저 단일 클라이언트와 현재 코어가 구독에 실제로 필요한 조합을 모두 지원하는지 확인하세요. 같은 환경에서 검증할 수 있는 노드는 한곳에서 관리하고, 별도 환경은 기능이나 호환성 요구가 분명할 때만 유지하면 됩니다.
선택 순서는 서버 요구 사항, 코어 기능, 클라이언트와 시스템 연결 방식 순으로 정리할 수 있습니다. 구독, DNS 또는 프록시 적용 범위를 추가로 점검하려면 문제 해결 가이드에 따라 단계별로 확인하세요. 용어 설명은 용어집에서 볼 수 있습니다.