코어를 고를 때는 이름이나 버전 번호보다 설정 호환성을 먼저 확인해야 합니다. v2rayN에서 코어를 확인하거나 v2rayNG와 v2flyNG 사이에서 설정을 옮기려는 사용자를 위한 안내입니다. 프로젝트 관계부터 프로토콜 필드, 전환 절차, 로그 확인까지 살펴보고 REALITY, Vision, 구독 변환, 로컬 포트가 각각 어느 단계에서 적용되는지 설명합니다.
프로젝트 관계: 그래픽 클라이언트와 프록시 코어는 다릅니다
V2Fly-core는 Project V의 V2Ray 기술을 이어받아 V2Fly 커뮤니티가 관리합니다. Xray-core는 V2Ray 코드 기반에서 분기한 뒤 독자적인 개발 및 배포 경로를 구축했습니다. 두 프로젝트는 공통된 기반을 갖지만 이후 기능과 설정 필드, 기본 동작이 계속 동일하게 유지되는 것은 아닙니다. Xray를 단순히 ‘최신 V2Ray’라고 보면 마이그레이션 때 확인해야 할 핵심 차이를 놓칠 수 있습니다.
그래픽 클라이언트는 구독 관리, 노드 편집, 설정 메뉴를 담당하고, 코어는 실제 실행 설정을 해석해 로컬 트래픽을 받아 프록시 연결을 처리합니다. 클라이언트에 노드가 표시되더라도 선택한 코어가 노드의 모든 옵션을 지원한다는 뜻은 아닙니다. 구독 가져오기, 설정 생성, 코어 실행은 각각 별도로 확인해야 합니다.
- v2rayN: 데스크톱 그래픽 클라이언트입니다. 사용할 수 있는 코어와 선택 메뉴는 클라이언트 버전, 설치된 구성 요소, 노드 유형에 따라 달라질 수 있으므로 현재 기기의 화면과 실행 로그를 기준으로 확인하세요.
- v2rayNG: Xray 코어를 사용하는 Android 클라이언트입니다. 데스크톱에서 실행 파일을 교체하는 방법을 Android에 그대로 적용할 수는 없습니다.
- v2flyNG: V2Fly 코어를 사용하는 Android 클라이언트입니다. 마이그레이션할 때 노드 매개변수와 구독 파싱 결과를 다시 확인해야 합니다.
버전 계열: 세 가지 버전을 따로 기록하세요
클라이언트 버전, Xray-core 버전, V2Fly-core 버전은 각각 따로 배포됩니다. 클라이언트 업데이트로 설정 생성 방식과 코어 파일이 함께 바뀔 수도 있고, 화면만 변경될 수도 있습니다. 코어를 수동으로 업데이트해도 클라이언트가 새 필드를 지원하도록 함께 업데이트되는 것은 아닙니다. 문제를 확인할 때는 ‘최신 버전으로 업데이트했다’고만 하지 말고 실제 조합을 기록하세요.
과거 자료에서는 V2Fly의 v4·v5 버전 계열과 Xray의 1.x 및 이후 날짜 기반 버전 표기를 자주 볼 수 있습니다. 서로 같은 기준으로 매긴 숫자가 아니므로 기능 수나 호환성을 판단하는 근거로 삼을 수 없습니다. 특히 V2Fly 프로그램 버전과 설정 형식은 구분해야 합니다. v5라는 이유만으로 기존 설정을 전부 다시 작성해야 한다고 단정하거나, 새 형식의 모든 필드를 구형 도구가 인식한다고 가정하지 마세요.
- 클라이언트 ‘정보’ 화면에 표시된 전체 버전과 운영체제, 프로세서 아키텍처를 기록하세요.
- 연결을 한 번 시작하고 로그에서 실제로 실행된 코어 이름과 버전, 시작 결과를 확인하세요.
- 일반 노드에서 생성된 설정과 직접 관리하는 사용자 지정 설정을 구분하세요. 사용자 지정 설정은 일부 화면 변환 과정을 거치지 않을 수 있습니다.
- 업데이트 전에 기존 클라이언트 설정과 코어 조합을 보관하세요. 문제가 생기면 파일 하나만 바꾸기보다 조합 전체를 이전 상태로 되돌리세요.
버전 번호가 같아도 두 기기의 동작이 완전히 일치한다는 보장은 없습니다. 라우팅 데이터 파일, DNS 설정, 클라이언트가 생성하는 매개변수가 다를 수 있습니다. 두 번의 업데이트 사이에 구독 내용이 바뀌었을 수도 있으므로 문제를 재현할 때는 동일한 노드 항목을 사용하세요.
프로토콜과 전송: 이름이 같아도 설정 필드가 호환되는 것은 아닙니다
VMess와 VLESS는 프록시 프로토콜이고, TCP·WebSocket·gRPC는 전송 방식입니다. TLS와 REALITY는 연결 보안 방식이며 Vision은 양쪽 설정이 일치해야 하는 흐름 제어 옵션입니다. 이들을 임의로 바꿔 쓸 수 있는 같은 종류의 ‘모드’로 보면 안 됩니다. 서버에서 요구하는 조합에 따라 클라이언트에 필요한 기능이 결정됩니다.
| 확인 항목 | Xray-core | V2Fly-core 지원 및 마이그레이션 시 주의사항 |
|---|---|---|
| VMess | 지원합니다. 인증 정보와 전송 매개변수가 일치해야 합니다. | 지원합니다. 프로토콜 이름이 같아도 설정 전체를 그대로 복사할 수 있다는 뜻은 아닙니다. |
| VLESS 및 확장 필드 | 노드에 필요한 흐름 제어와 보안 설정을 확인하세요. | 버전과 설정 형식에 따라 지원 범위를 확인하세요. Xray 확장 필드를 그대로 적용할 수는 없습니다. |
| REALITY 및 Vision | 관련 설정의 주요 선택 항목이며 양쪽 설정이 일치해야 합니다. | 일반적인 호환 항목으로 옮기지 마세요. 대상 코어에서 실행할 수 있는 서버 설정을 별도로 받아야 합니다. |
| WebSocket、gRPC | 현재 버전의 지원 여부와 서버 측 설정을 확인하세요. | 경로, 서비스 이름, 호스트 이름, TLS 설정을 각각 확인하세요. 전송 이름만 비교해서는 안 됩니다. |
| DNS, 라우팅 및 트래픽 감지 | 실행 설정과 관련 데이터에 따라 동작이 결정됩니다. | 필드, 파싱 동작, 데이터 형식이 다를 수 있으므로 별도로 검증해야 합니다. |
예를 들어 VLESS 노드에서 xtls-rprx-vision을 요구한다면 flow 필드를 삭제한다고 일반 VLESS 노드로 바뀌는 것은 아닙니다. REALITY의 서버 공개 키, 서비스 이름, 짧은 식별자도 각각 용도가 있습니다. 값이 없거나 맞지 않는 경우 코어만 바꿔서는 필요한 매개변수를 보완할 수 없습니다.
판단 순서: 대체할 수 없는 필드부터 확인하세요
먼저 노드에서 REALITY나 Vision을 명시적으로 요구하는지 확인한 다음, 대상 코어와 클라이언트가 해당 매개변수를 빠짐없이 설정할 수 있는지 살펴보세요. 호환되지 않는 필드가 있다면 계속 삭제하기보다 서비스 제공자에게 사용할 수 있는 다른 설정을 요청하는 편이 효과적입니다.
코어 선택: 보유한 노드 설정에 맞춰 결정하세요
‘새 프로토콜은 무조건 더 빠르다’는 이유로 코어를 바꾸면 안 됩니다. 네트워크 경로, 서버 부하, 통신사 연결 품질, 라우팅 규칙이 모두 사용 경험에 영향을 줍니다. 먼저 노드 요구사항을 충족하는 코어를 고르고, 그다음 조건이 같은 환경에서 안정성, 리소스 사용량, 기능을 비교하세요.
Xray 코어
추천노드에서 REALITY, Vision 또는 Xray 전용으로 확인된 설정을 사용하는 경우, 해당 필드를 빠짐없이 생성할 수 있는 클라이언트와 코어 조합을 우선 선택하세요. 이 추천은 해당 설정을 사용하는 경우에 한하며, 모든 네트워크에서 성능이 더 좋다는 뜻은 아닙니다.
적합한 경우: Xray 전용 노드 매개변수가 있고 서버 요구사항에 맞춰 연결해야 할 때
V2Fly 코어
검증된 V2Fly 설정과 DNS, 라우팅 규칙을 이미 사용 중이라면 기존 조합을 계속 사용할 수 있습니다. 마이그레이션 전에 새 구성이 해결할 구체적인 문제가 있는지 확인하세요. 다른 프로젝트의 버전 번호가 바뀌었다는 이유만으로 코어를 바꿀 필요는 없습니다.
적합한 경우: 기존 V2Fly 설정을 유지하면서 규칙과 실행 동작을 그대로 이어가야 할 때
두 코어 모두 같은 서버 설정을 실행할 수 있다면 노드, 테스트 시간대, 테스트 대상을 고정한 뒤 연결 성공률과 로그 오류를 비교하세요. 출구가 서로 다른 환경에서 한 번씩 측정한 결과만으로 코어 자체의 성능을 판단하지 마세요.
전환 절차: 먼저 백업하고 최소 연결부터 확인하세요
v2rayN에서 ‘설정’ → ‘매개변수 설정’을 열고 로컬 리스너, DNS, 라우팅 관련 옵션을 기록하세요. 버전에 따라 메뉴 이름과 코어 선택 위치가 바뀔 수 있습니다. 현재 화면에 원하는 코어를 선택하는 옵션이 없다면 오래된 안내를 따라 출처가 불분명한 파일을 수정하지 마세요. 구독 그룹 이름을 코어 선택 기능으로 착각해서도 안 됩니다.
- 기존 상태 보관. 클라이언트 설정, 사용자 지정 규칙, 필요한 노드 매개변수를 백업하세요. 구독 주소나 인증 정보가 백업에 포함되어 있다면 접근을 제한하고 공개된 곳에 올리지 마세요.
- 대상 조합 확인. 노드의 프로토콜, 전송 방식, 보안 방식, 흐름 제어를 확인하고 클라이언트가 대상 코어에서 인식하는 필드를 생성할 수 있는지 살펴보세요.
- 기존 코어 중지. 클라이언트의 중지 또는 재시작 기능을 사용해 두 코어가 같은 로컬 리스너 포트를 동시에 사용하지 않도록 하세요.
- 변수 하나만 변경. 먼저 코어 또는 클라이언트만 바꾸고 DNS, 노드, 라우팅은 동시에 변경하지 마세요. 시작한 뒤 설정 파싱과 리스너 로그를 먼저 확인하세요.
- 최소 연결 테스트. 매개변수가 모두 확인된 노드 하나로 프록시 요청을 테스트하세요. 그다음 자주 사용하는 분할 라우팅 규칙을 복원하고 마지막으로 구독 업데이트를 테스트하세요.
마이그레이션 절차: 데스크톱과 Android에서 각각 확인하세요
데스크톱: v2rayN
- 현재 코어의 시작 로그와 리스닝 포트를 기록하세요.
- 현재 버전에서 실제로 제공하는 코어 선택 메뉴를 사용하세요.
- 전환 후 시스템 프록시가 올바른 포트를 가리키는지 확인하세요.
Android: v2rayNG / v2flyNG
- 마이그레이션 전에 구독 항목에 대상 코어가 지원하지 않는 필드가 있는지 확인하세요.
- 가져온 뒤에는 목록의 노드 수만 보지 말고 노드 편집 화면에서 설정을 확인하세요.
- 연결할 때 시스템 VPN 권한과 앱별 적용 범위를 다시 확인하세요.
같은 구독을 사용해도 입력 원본만 같을 뿐, 양쪽에서 파싱한 노드와 라우팅, DNS 동작까지 같다는 보장은 없습니다.
포트와 로그: 로컬 실행 오류와 원격 핸드셰이크 오류 구분하기
아래 세 숫자는 포트의 역할을 설명하기 위한 예시이며 모든 클라이언트의 기본값은 아닙니다. 실제 값은 기기의 설정과 노드 매개변수를 기준으로 확인하세요. 로컬 프록시 포트를 서버 포트에 잘못 입력하거나 원격 포트를 시스템 프록시에 지정하면 코어 선택과 관계없는 연결 문제가 발생합니다.
설정에서 HTTP 프록시가 127.0.0.1:10809에서 수신 대기하는 것을 확인했다면, 아래 명령으로 해당 리스너를 통과하는 HTTPS 요청을 테스트할 수 있습니다. 테스트 주소는 연결 확인에만 사용하세요. 응답 결과만으로 출구 위치를 확인하거나 모든 앱이 프록시를 사용한다고 판단할 수는 없습니다.
curl --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 20 -I https://example.com/unknown field오류가 발생하는 경우: 서버 주소를 먼저 바꾸지 말고 설정 필드와 대상 코어 버전을 우선 확인하세요.address already in use오류가 발생하는 경우: 기존 코어나 다른 프로그램이 리스닝 포트를 사용 중인지 확인하세요. 중복 프로세스를 중지한 뒤 다시 시작하세요.- 로컬 수신은 되지만 원격 핸드셰이크가 실패하는 경우: 서버 포트, 시스템 시간, TLS 서비스 이름, REALITY 매개변수를 확인하고 전체 오류 로그를 살펴보세요.
- 명령은 성공하지만 브라우저에서 연결되지 않는 경우: 시스템 프록시, 브라우저 자체 프록시 설정, 라우팅 규칙을 확인하세요. 곧바로 프로토콜 비호환 문제라고 단정하지 마세요.
자주 묻는 질문: 구독 가져오기, 전환 실패, 이전 상태 복구
구독은 가져와지는데 연결하자마자 종료되는 이유는 무엇인가요?
가져오기에 성공했다는 것은 클라이언트가 구독을 파싱했다는 뜻일 뿐입니다. 먼저 시작 로그에서 인식하지 못하는 필드 오류가 있는지 확인한 다음 노드 편집 화면에서 프로토콜, 전송 방식, 보안 옵션을 살펴보세요. 설정을 확인하는 대신 구독 업데이트를 반복하지 마세요. 설정 파싱 오류라면 기존 코어로 되돌리거나 호환되는 설정을 받아야 합니다.
REALITY를 TLS로 바꾸면 V2Fly에서 실행할 수 있나요?
클라이언트 옵션 하나만 바꿔서는 안 됩니다. 서버에서 해당 TLS 서비스와 인증 설정을 제공해야 합니다. 서비스 제공자에게 대상 코어를 지원한다고 명시된 노드 매개변수를 받아 다시 가져오세요. 공개 키나 흐름 제어 필드를 삭제하는 방식으로 변환할 수는 없습니다.
코어를 바꾼 뒤 분할 라우팅 결과가 달라진 이유는 무엇인가요?
먼저 현재 라우팅 모드, DNS 확인 정책, 규칙 데이터가 백업과 동일한지 확인하고 로그에서 규칙 적용 결과와 출구를 살펴보세요. 시스템 프록시는 일부 앱의 트래픽을 클라이언트로 전달할지 결정할 뿐, 서로 다른 코어가 동일한 분할 라우팅 설정을 사용하도록 보장하지는 않습니다.
전환에 실패한 뒤 기존 연결을 복구하려면 어떻게 해야 하나요?
새 코어를 중지하고 기존 클라이언트 설정과 코어 조합을 복원하세요. 로컬 포트가 사용 중이 아닌지 확인한 다음 클라이언트를 재시작하고 시스템 프록시를 다시 설정하세요. 이전에 작동하던 동일한 노드로 테스트하세요. 그래도 실패하면 구독 내용이 바뀌었는지와 원격 서비스가 정상인지 확인하세요.
최종 선택을 내리기 전에 세 가지를 확인하세요. 노드에서 어떤 필드를 요구하는지, 클라이언트가 실제로 어떤 설정을 생성했는지, 로그에서 어떤 코어가 실행된 것으로 확인되는지입니다. 이 세 가지가 일치하는지 확인한 뒤 업데이트와 성능을 검토하세요. 일치하지 않는 상태에서 버전만 계속 바꾸면 문제를 일으키는 변수가 늘어납니다. 원인을 더 확인하려면 문제 해결의 연결, 구독, 라우팅 절차를 따라 단계별로 살펴보세요.