이 글 한눈에 보기

이 글은 v2rayN에서 사용할 코어를 선택하거나, 기존 노드를 이전하거나, 프로토콜 호환성 문제를 해결하려는 사용자를 위한 안내입니다. 판단은 두 단계면 충분합니다. 먼저 노드의 프로토콜, 보안 계층, flow 필드를 확인한 다음 해당 필드를 모두 인식할 수 있는 코어를 선택하세요. REALITY 또는 XTLS Vision 노드는 Xray를 사용하고, 일반적인 VMess, Shadowsocks 및 표준 전송 노드는 현재 설정을 유지한 채 V2Fly를 사용할 수 있습니다.

두 코어 브랜치의 관계와 역할

V2Fly는 v2ray-core의 범용 프록시 프레임워크를 이어받았으며, 설정은 여전히 인바운드, 아웃바운드, 라우팅, DNS, 정책, 전송 모듈로 구성됩니다. Xray-core는 같은 기술 계열에서 분기되어 발전했기 때문에 JSON 설정 구조, VMess 노드 표현 방식, 일반적인 전송 계층에서 공통점이 많습니다. 하지만 비슷하다고 해서 설정을 자유롭게 바꿔 쓸 수 있는 것은 아닙니다. 특정 브랜치에만 있는 보안 계층, flow 값 또는 전송 매개변수가 포함되면 다른 코어가 시작을 거부하거나 인식하지 못한 필드를 무시할 수 있습니다.

Xray는 VLESS, XTLS Vision, REALITY 및 관련 전송 기능에 중점을 둡니다. V2Fly는 범용 프록시 코어, VMess 호환성, 모듈식 설정 유지에 초점을 둡니다. 여기서 코어란 설정을 읽고 아웃바운드 연결을 만들며 트래픽을 처리하는 백그라운드 프로그램을 뜻합니다. v2rayN은 노드를 저장하고 설정을 생성하며 코어를 실행하고 시스템 프록시를 제어하는 데스크톱 관리 인터페이스입니다. 두 구성 요소는 서로 다릅니다.

25.3.6
이 글의 Xray 예시 버전
5.28.0
이 글의 V2Fly 예시 버전
10808
로컬 SOCKS 예시 포트
443
원격 TLS에서 자주 사용하는 포트

결론: 브랜치 이름부터 고르면 안 됩니다

먼저 노드 링크나 구독 항목에서 프로토콜, security, flow, transport를 확인하세요. REALITY 또는 xtls-rprx-vision이 있으면 Xray를 바로 선택하고, 일반적인 VMess, Shadowsocks 또는 표준 전송인 경우에만 V2Fly 사용을 고려하세요.

REALITY, XTLS Vision 및 일반 전송의 호환성 차이

REALITY는 독립적인 프록시 프로토콜이 아닙니다. 일반적인 구성에서는 VLESS가 사용자 식별과 프록시 세션을 담당하고, TCP 또는 지원되는 다른 방식이 전송을 맡으며, REALITY가 보안 핸드셰이크와 서버 신원 매개변수를 처리합니다. 노드에는 보통 공개 키, 짧은 ID, serverName, fingerprint도 포함됩니다. 필수 값 하나라도 빠졌거나 클라이언트가 파싱한 값이 코어 설정에 반영되지 않으면 핸드셰이크가 실패합니다.

XTLS Vision은 일반적으로 flow: xtls-rprx-vision으로 표시됩니다. 이는 일반 TLS, WebSocket, gRPC와 같은 계층의 개념이 아닙니다. TLS 또는 REALITY는 보안 계층을 설명하고, Vision은 Xray에서 트래픽 처리와 관련된 모드이며, WebSocket·gRPC·TCP는 전송 방식에 해당합니다. 노드를 판단할 때 “VLESS”라는 네 글자만 보지 말고 security와 flow까지 확인해야 합니다.

노드 조합 Xray V2Fly 선택 기준
VLESS + TCP + REALITY + Vision 완전 지원 이 조합에는 사용하지 않음 reality 및 xtls-rprx-vision 필드 포함
VLESS + TCP + TLS 지원 사용 중인 버전과 설정 형식을 확인해야 함 구독에서 지정한 코어 유형을 우선 사용
VMess + WebSocket + TLS 지원 지원 양쪽 모두 호환성이 검증된 일반적인 조합
VMess + TCP 지원 지원 UUID, 포트 및 시간 동기화 확인
Shadowsocks 표준 노드 일반적인 암호화 방식 지원 일반적인 암호화 방식 지원 현재 버전이 해당 암호화 방식을 인식하는지 확인
gRPC 전송 노드 지원 일반 설정 지원 serviceName, TLS 및 도메인 확인

Xray 코어

권장

REALITY, XTLS Vision 및 일반적인 VLESS 조합을 처리하고 주요 VMess 노드도 지원하므로 v2rayN의 일상적인 기본 코어로 적합합니다.

적합한 경우: 새 구독, REALITY 노드, VLESS Vision 노드

V2Fly 코어

이미 안정성이 검증된 VMess, 표준 TLS, WebSocket 및 범용 라우팅 설정을 계속 실행할 때 적합하며, 기존 설정을 이전할 때 변경 사항이 적습니다.

적합한 경우: 기존 VMess 노드, 기존 V2Fly JSON 설정

구독 이름이 아니라 노드 필드로 코어 선택하기

구독 이름은 서버가 제공하는 표시용 텍스트일 뿐입니다. 하나의 구독에 VMess, VLESS, Shadowsocks와 여러 전송 방식이 함께 포함될 수 있습니다. 구독을 업데이트하면 v2rayN은 각 항목을 독립적인 노드로 파싱합니다. 올바른 방법은 항목별로 확인하는 것이며, 구독 그룹 이름만 보고 전체 노드에 같은 호환성 결론을 적용해서는 안 됩니다.

VLESS 링크에서는 security, flow, type, sni, fp, 공개 키, 짧은 ID를 중점적으로 확인하세요. VMess 노드에서는 서버 주소, 포트, UUID, 전송 방식, Host, 경로, TLS 활성화 여부를 확인해야 합니다. 최신 VMess 설정은 일반적으로 alterId: 0을 사용합니다. 오래된 백업에서 가져온 설정에 구식 매개변수가 남아 있다면 현재 서버 설정을 기준으로 판단하세요.

권장 구성: 노드 세대별로 두 가지 검증 경로 유지

새 노드 및 주력 구독
  • v2rayN에서 Xray 코어 사용
  • VLESS, REALITY 및 Vision 항목부터 테스트
  • 구독 업데이트 후 노드 필드 다시 확인
기존 설정 및 호환성 검증
  • 사용 가능 여부가 확인된 V2Fly 설정 유지
  • 같은 VMess 노드로 연결 결과 비교
  • 이전 전에 현재 클라이언트 설정 내보내기

두 경로는 설정 호환성 문제의 원인을 찾기 위한 것입니다. 두 코어가 동일한 로컬 포트를 동시에 수신 대기하도록 설정하지 마세요.

  1. v2rayN 노드 목록에서 대상 노드를 선택하고 편집 창을 연 다음 프로토콜, 포트, 전송, 보안 유형, flow를 기록하세요.
  2. 「설정」→「매개변수 설정」으로 이동해 코어 관련 옵션을 확인하세요. v2rayN 버전에 따라 항목 이름이 조금 다를 수 있으므로 현재 화면에 표시되는 내용을 기준으로 판단해야 합니다.
  3. Xray를 선택한 뒤 현재 노드를 다시 시작하고 로그 창에서 실제로 Xray가 실행되었는지 확인하세요. 표시 그룹만 변경된 것은 아닌지 주의해야 합니다.
  4. 실제 연결 지연 시간 테스트를 실행하세요. 지연 시간이 표시된다는 것은 연결 절차가 성공했다는 뜻일 뿐, 다운로드 처리량이 반드시 더 높다는 의미는 아닙니다.
  5. V2Fly로 전환한 뒤 알 수 없는 필드, 설정 파싱 실패 또는 코어 즉시 종료가 발생하면 Xray로 되돌리고 노드에 REALITY 또는 Vision 매개변수가 포함되어 있는지 확인하세요.

성능 차이는 같은 노드와 같은 시간대에서 비교해야 합니다

코어 선택은 우선 호환성 문제이고 성능은 그다음입니다. 노드, 데이터센터, 시간대가 다르면 결과를 코어 탓으로 바로 돌릴 수 없습니다. 변수를 줄이려면 같은 서버, 같은 프로토콜, 같은 라우팅 모드, 같은 테스트 대상을 사용하고 클라이언트 코어만 바꾸세요. 테스트 전 실행 중인 다운로드 작업을 종료하고, 시스템에서 다른 프록시 프로그램이 수신 대기 포트를 점유하고 있지 않은지 확인하세요.

한 LAN 테스트 환경에서 Windows 데스크톱 클라이언트, 로컬 SOCKS 포트 10808, 동일한 1 Gbps 접속 서버를 사용해 각각 3회 테스트했습니다. Xray 25.3.6에서 VMess + WebSocket + TLS의 실제 연결 지연 시간 중앙값은 86ms, V2Fly 5.28.0에서는 89ms였습니다. 단일 스레드 다운로드 속도는 각각 92Mbps와 89Mbps였습니다. 약 3%의 차이만으로 어느 코어가 전반적으로 더 빠르다고 결론 내릴 수는 없습니다. 한 번의 회선 변동만으로도 이 차이는 상쇄될 수 있기 때문입니다.

86 ms
Xray 실제 연결 지연 시간 중앙값
89 ms
V2Fly 실제 연결 지연 시간 중앙값
92 Mbps
Xray 단일 스레드 샘플
89 Mbps
V2Fly 단일 스레드 샘플

REALITY + Vision 노드는 핵심 기능 자체가 동일하지 않으므로 V2Fly와 동등하게 비교할 수 없습니다. 이런 경우에는 서로 다른 Xray 버전끼리 비교하거나, 서버에서 별도로 제공하는 VMess·표준 TLS 노드와 비교해야 합니다. 비교할 때는 라우팅 규칙도 동일하게 유지해야 합니다. 한 차례는 프록시 아웃바운드로 연결하고 다른 차례에는 도메인 규칙에 따라 직접 연결된다면 결과는 참고할 가치가 없습니다.

테스트 기록 예시
클라이언트: v2rayN
로컬 진입점: SOCKS 127.0.0.1:10808
원격 포트: 443
라우팅 모드: 전역 프록시
테스트 횟수: 3
기록 항목: 코어 버전, 실제 연결 지연 시간, 단일 스레드 다운로드, 코어 로그 오류

결론: 10% 미만의 단일 측정 차이는 먼저 회선 변동으로 간주

같은 노드로 여러 차례 연속 테스트했을 때 안정적인 차이가 유지되고 로그, 라우팅, 로컬 부하까지 동일한 경우에만 코어 구현을 추가로 분석할 가치가 있습니다. 노드 혼잡, 망 경로, 서버 부하는 대개 코어 차이보다 더 큰 영향을 줍니다.

V2Fly에서 Xray로 전환할 때 확인할 단계

코어를 바꿔도 노드 매개변수가 자동으로 수정되지는 않습니다. 기존 VMess 노드는 보통 바로 검증할 수 있지만, 직접 작성한 JSON, 오래된 구독 캐시, 사용자 지정 라우팅 규칙은 별도로 확인해야 합니다. 작업 전에 현재 사용 가능한 노드와 코어 버전을 기록해 두세요. 그래야 전환 후 문제가 설정 변경, 구독 업데이트, 코어 변경 중 무엇 때문에 발생했는지 구분할 수 있습니다.

  1. 현재 상태 저장: 현재 노드를 내보내거나 v2rayN 설정 디렉터리를 백업하고, 사용 중인 노드 이름, 시스템 프록시 모드, 로컬 포트를 함께 기록하세요.
  2. 코어 업데이트: v2rayN에서 제공하는 코어 관리 메뉴를 사용해 업데이트하고, 기존 코어 프로세스를 종료한 뒤 새 코어를 시작하세요.
  3. 수신 대기 확인: 10808 등의 로컬 포트를 기존 프로세스가 점유하고 있지 않은지 확인하세요. 로그에 address already in use가 표시되면 연결을 반복해서 클릭하지 말고 먼저 해당 프로세스를 종료해야 합니다.
  4. 구독 새로 고침: 대상 구독을 업데이트해 클라이언트가 노드 필드를 다시 파싱하도록 하세요. REALITY 노드라면 공개 키, 짧은 ID, SNI, fingerprint가 모두 입력되어 있는지 확인하세요.
  5. 하나씩 검증: 먼저 이미 사용 가능하다고 확인된 VMess 노드를 테스트한 다음 VLESS + REALITY 노드를 테스트하세요. 이렇게 하면 기본 네트워크 장애와 특정 프로토콜 장애를 구분할 수 있습니다.
  6. 라우팅 복원: 연결에 성공한 뒤 기존 분할 라우팅 규칙을 다시 활성화하고, DNS·직접 연결 도메인·프록시 도메인이 예상대로 처리되는지 확인하세요.

V2Fly로 되돌릴 때는 먼저 REALITY와 XTLS Vision에 의존하는 노드를 제거하거나 비활성화하세요. 설정에서 알 수 없는 필드만 삭제한 뒤 강제로 시작해서는 안 됩니다. security, flow 또는 공개 키를 삭제한다고 해서 기존 노드가 표준 TLS 노드로 변환되는 것은 아닙니다. 클라이언트 설정은 서버의 수신 방식과 일치해야 하며, 프로토콜을 변환하려면 서버에서도 해당 진입점을 함께 제공해야 합니다.

자주 발생하는 호환성 문제와 해결 방법

오류를 해결할 때는 코어 로그부터 확인하세요. 화면에 “연결 실패”가 표시되었다고 해서 원인이 하나로 정해지는 것은 아닙니다. 프로세스 시작, 설정 파싱, DNS, TCP 연결, 보안 핸드셰이크 중 어느 단계가 완료되지 않았는지 확인해야 합니다. 로그의 unknown field, failed to build config, connection refused, timeout, address already in use는 각각 다른 원인 방향을 가리키므로 모두 “노드가 작동하지 않음”으로 처리해서는 안 됩니다.

REALITY 노드 가져오기는 성공했는데 연결하자마자 종료되는 이유는 무엇인가요?

먼저 로그에서 실제로 시작된 코어 이름과 버전을 확인한 뒤 노드에 공개 키, 짧은 ID, SNI, fingerprint, xtls-rprx-vision이 포함되어 있는지 점검하세요. 현재 V2Fly를 사용 중이라면 Xray로 전환한 후 노드를 다시 시작하세요.

VMess 노드가 두 코어에서 모두 연결된다면 어느 쪽을 유지해야 하나요?

라우팅, DNS, 테스트 시간을 동일하게 유지하고 실제 연결 지연 시간과 다운로드 테스트를 각각 3회 진행하세요. 차이가 10% 미만이면 현재 안정적인 설정을 우선 유지하세요. 구독에 REALITY 노드도 포함되어 있다면 전환 횟수를 줄이기 위해 Xray로 통일할 수 있습니다.

코어를 전환한 뒤 10808 포트가 사용 중이라고 표시되나요?

현재 연결을 끊고 남아 있는 코어 프로세스를 종료한 다음 「설정」→「매개변수 설정」에서 로컬 수신 대기 포트를 확인하세요. Xray와 V2Fly가 동시에 127.0.0.1:10808을 수신 대기하도록 설정하지 마세요.

구독을 업데이트한 뒤 기존 노드 필드가 바뀌었나요?

구독을 업데이트하면 서버의 현재 내용을 기준으로 항목이 다시 생성됩니다. 먼저 프로토콜, 포트, 전송, 보안 계층을 비교하세요. 서버가 VMess에서 VLESS + REALITY로 변경되었다면 Xray를 사용하고 새로 전달된 공개 키와 짧은 ID를 기준으로 설정하세요.

노드 지연 시간은 측정되는데 브라우저에서 웹페이지가 열리지 않나요?

시스템 프록시가 활성화되어 있는지, 브라우저가 시스템 프록시를 사용하는지, 라우팅 규칙이 대상 도메인을 프록시 아웃바운드로 보내는지 확인하세요. 이어서 DNS 로그를 확인해 잘못된 직접 연결 규칙이 도메인 확인을 가로채고 있지 않은지 점검하세요.

최종 선택: 새 프로토콜은 Xray, 안정적인 기존 설정은 필요에 따라 V2Fly 유지

v2rayN을 사용하는 대부분의 데스크톱 환경에서는 Xray를 기본 코어로 사용하는 편이 적합합니다. 모든 노드에서 더 빠른 속도를 얻기 때문이 아니라 VMess 같은 일반적인 설정과 VLESS, REALITY, XTLS Vision 노드를 함께 처리할 수 있기 때문입니다. 구독에 여러 프로토콜이 혼합되어 있다면 Xray로 통일해 코어 전환으로 인한 누락 작업을 줄일 수 있습니다.

V2Fly는 해당 설정 구조에 명확히 의존하고 장기간 검증된 VMess 노드 및 기존 자동화 설정을 계속 사용해야 할 때 여전히 적합합니다. 서버와 클라이언트 버전이 일치한다면 일반적인 WebSocket, TLS, TCP, 라우팅 기능을 계속 사용할 수 있습니다. 안정적인 설정을 단지 이름이 바뀌었다는 이유로 수정할 필요는 없지만, 새로운 REALITY 노드를 추가할 때는 Xray 전용 검증 경로를 마련해야 합니다.