Xray와 V2Fly 코어 차이: 버전 관계 정리와 클라이언트 선택 가이드

먼저 클라이언트·코어·구독의 관계부터 이해하기

v2rayN, v2rayNG, v2flyNG는 그래픽 인터페이스를 제공하는 클라이언트입니다. 노드를 저장하고 구독을 갱신하며 시스템 프록시를 전환하고 실행 설정을 생성한 뒤 로그를 보여줍니다. Xray와 V2Fly는 실제 연결을 처리하는 코어로, 로컬 포트를 열고 라우팅 규칙을 실행하며 프로토콜 핸드셰이크를 수행한 다음 트래픽을 원격 서버로 보냅니다. 인터페이스가 정상적으로 열렸다고 해서 코어가 성공적으로 시작된 것은 아닙니다.

구독은 두 요소의 중간에 있습니다. 구독 서비스가 노드 목록을 반환하면 클라이언트는 링크에 포함된 프로토콜, 주소, 포트, 전송 계층과 TLS 매개변수를 코어 설정으로 변환합니다. 같은 구독을 서로 다른 클라이언트에 가져와도 최종 JSON은 다를 수 있습니다. 클라이언트가 로컬 인바운드, DNS, 로그와 라우팅 설정을 추가하기 때문입니다.

따라서 “V2Ray 노드”는 일반적으로 생태계 전반을 가리키는 표현일 뿐, 하위에서 반드시 V2Fly가 실행된다고 단정할 수 없습니다. VLESS, REALITY, XTLS Vision 매개변수가 포함된 노드는 Xray에 더 적합한 편입니다. 전통적인 VMess, WebSocket, TLS 조합은 대체로 두 코어 모두에서 성숙한 구현을 찾을 수 있지만, 필드와 버전은 반드시 확인해야 합니다.

판단 순서: 노드 매개변수를 먼저 확인한 뒤 클라이언트 이름을 보기

노드에 REALITY, shortId, spiderX 또는 XTLS Vision 플로우 제어 매개변수가 있다면 우선 Xray를 사용하세요. VMess, WebSocket, TLS 같은 일반 필드만 있다면 현재 클라이언트와 설정 호환성을 기준으로 선택하면 됩니다.

V2Fly와 Xray의 버전 관계

두 코어 모두 초기 Project V 생태계와 관련이 있지만, 오늘날 Xray를 V2Fly의 “고급 모드”로 이해해서는 안 되며 V2Fly를 Xray의 구버전으로 보아서도 안 됩니다. 각자 배포 주기, 기능 선택과 버그 수정 경로가 다릅니다. 설정 형식이 여전히 많은 부분에서 비슷한 이유는 인바운드, 아웃바운드, 라우팅과 전송 계층 모델을 서로 가까운 기반에서 계승했기 때문입니다.

V2Fly는 V2Ray 커뮤니티의 유지보수 노선을 이어가며, 전통적인 설정 모델의 연속성을 유지하고 v5 설정 체계를 발전시키는 데 중점을 둡니다. 일반적인 설정은 여전히 inbounds, outbounds, routing, dns, log 등의 부분으로 구성됩니다. 기존 VMess 배포, 표준 전송 계층 조합과 V2Fly 동작에 의존하는 환경에서는 대체로 이 노선을 우선 고려합니다.

Xray는 유사한 코드 기반에서 독립적으로 발전했으며 버전 번호는 1.x 계열을 사용합니다. 주요 기능으로 VLESS, REALITY와 XTLS Vision 등이 있습니다. V2Fly와 일부 JSON 필드가 같아 보여도 새로 추가된 모든 필드를 서로 바꿔 쓸 수 있는 것은 아닙니다. Xray 설정을 그대로 V2Fly에 넘기면 알 수 없는 필드, 프로토콜 구현 누락 또는 인식되지 않는 플로우 제어 값이 발생하는 경우가 많습니다.

버전 번호는 서로 비교할 수 없다

Xray 1.x와 V2Fly v5의 숫자는 같은 배포 순서에 속하지 않으므로 숫자 크기로 신구를 판단할 수 없습니다. 유효한 기준은 대상 프로토콜이 구현되어 있는지, 설정 필드를 인식하는지, 클라이언트에 포함된 코어 버전이 노드 요구 사항을 충족하는지입니다.

프로토콜 지원과 설정 필드의 차이

VMess는 두 노선 모두에서 접할 수 있는 전통적인 프로토콜이지만, 구체적인 전송 계층, 암호화 옵션과 호환 동작은 버전에 따라 달라집니다. 기존 VMess + TCP 또는 VMess + WebSocket + TLS 노드를 마이그레이션할 때는 원래 주소, 포트, UUID, Host, 경로와 TLS 도메인을 먼저 유지하고 여러 매개변수를 동시에 바꾸지 마세요.

VLESS는 인증과 암호화 전송 계층을 분리해 설정합니다. 실제 클라이언트 환경에서 VLESS는 Xray의 REALITY 또는 XTLS Vision과 함께 사용되는 경우가 많습니다. 이런 노드는 서버 주소와 UUID 외에도 serverName, publicKey, shortId, spiderX, 지문과 xtls-rprx-vision 플로우 제어 값을 요구할 수 있습니다. 필수 항목 하나라도 빠지면 핸드셰이크 실패 또는 연결 후 유효한 트래픽이 흐르지 않는 문제가 발생할 수 있습니다.

라우팅 구조도 “겉보기에는 같은” 설정이라는 오판을 만들기 쉽습니다. 두 코어 모두 도메인, IP, 포트와 인바운드 태그에 따라 규칙을 실행할 수 있지만, 규칙 데이터 파일, 필드 확장과 DNS 동작은 버전에 따라 달라질 수 있습니다. routing.rules를 마이그레이션할 때는 domain, ip, port, network, outboundTag를 하나씩 확인하고 참조된 태그가 실제로 존재하는지도 확인하세요.

v2rayN, v2rayNG, v2flyNG 중 무엇을 선택할까

Windows 데스크톱에서는 일반적으로 v2rayN을 우선 사용하고 클라이언트가 Xray 코어를 관리하도록 설정합니다. 구독 가져오기, 노드 일괄 테스트, 시스템 프록시, 라우팅 분할과 로그 확인에 적합합니다. 노드에 REALITY 또는 XTLS Vision이 포함되어 있다면 이 조합으로 설정 변환 과정의 불확실성을 줄일 수 있습니다.

v2rayN에서 코어 선택을 확인하려면 먼저 「설정」→「매개변수 설정」을 열고 코어, 기본 설정 또는 시작 매개변수와 관련된 항목을 확인하세요. 버전에 따라 항목 이름은 조금 다를 수 있습니다. 그런 다음 메인 창으로 돌아가 서비스를 다시 시작하고 즉시 로그를 확인합니다. 로그 첫 화면에 Xray 버전 정보가 표시된다면 현재 실행 중인 코어가 Xray라는 뜻이며, 프로그램 폴더의 파일명만 보고 추측할 필요가 없습니다.

Android에서는 코어 노선에 따라 v2rayNG와 v2flyNG 중에서 선택해야 합니다. v2rayNG는 Xray 코어와 함께 사용하며 VLESS, REALITY 또는 XTLS Vision이 포함된 구독에 적합합니다. v2flyNG는 V2Fly 코어와 함께 사용하며 V2Fly 동작에 명확히 의존하는 노드와 설정에 적합합니다. 두 앱의 조작 방식이 비슷하다고 해서 하위 프로토콜 확장까지 완전히 같은 것은 아닙니다.

로컬 포트도 함께 확인하기

• v2rayN의 일반적인 로컬 SOCKS 수신 포트는 10808이며 HTTP 포트는 인접한 포트를 사용할 수 있습니다. 최종 값은 「설정」→「매개변수 설정」의 로컬 수신 설정을 기준으로 하세요.
• 브라우저나 다른 프로그램에서 프록시를 수동으로 설정할 때는 프록시 유형과 수신 유형이 일치해야 합니다. HTTP 요청을 SOCKS 포트로 보내면 연결이 거부되거나 페이지가 계속 대기하는 것처럼 보입니다.
• 코어를 바꾼 뒤 포트가 해제되지 않으면 로그에 address already in use가 표시될 수 있습니다. 아직 실행 중인 이전 프로세스를 먼저 종료한 뒤 클라이언트를 다시 시작하세요.
• 시스템 프록시를 활성화한 뒤에도 접속할 수 없다면 먼저 단일 노드의 지연 시간을 테스트하고, 라우팅 규칙이 대상 도메인을 direct 아웃바운드로 보내고 있지 않은지 확인하세요.

로그로 현재 실행 중인 코어 확인

클라이언트 제목, 구독 이름과 노드 메모만으로는 실제 코어를 증명할 수 없습니다. 가장 신뢰할 수 있는 확인 지점은 시작 로그입니다. 서비스를 중지한 뒤 한 번 다시 시작하고 첫 줄부터 버전 식별자, 설정 로드 경로, 수신 주소와 오류 정보를 확인하세요. 마지막 줄의 “시작 실패”만 캡처하지 마세요. 실제 원인은 대개 그보다 앞에 표시됩니다.

정상적인 시작 과정은 일반적으로 설정 생성, 설정 파싱, 인바운드 포트 수신 대기와 서비스 실행 단계를 거칩니다. 파싱 단계에서 중단되면 JSON 문법과 필드를 우선 확인하세요. 127.0.0.1:10808에서 이미 수신 대기 중인데 이후 원격 연결이 실패한다면 주소, 포트, TLS, SNI, REALITY 공개 키와 라우팅 규칙을 점검해야 합니다.

시작 확인 순서
1. 코어 이름과 버전 줄 확인
2. 설정 파일이 성공적으로 로드되었는지 확인
3. 127.0.0.1:10808에서 수신 대기를 시작했는지 확인
4. 노드 테스트 또는 웹 요청 한 번 실행
5. 첫 warning / error부터 위쪽으로 올라가며 주변 로그 확인

1. unknown field가 표시되는 경우: 현재 코어가 해당 설정 필드를 인식하지 못하는 것입니다. 먼저 그 필드가 어느 코어 노선에 속하는지 확인한 뒤, 클라이언트가 호환되지 않는 확장 매개변수를 생성했는지 점검하세요.
2. failed to listen이 표시되는 경우: 로컬 포트가 사용 중이거나 수신 주소가 잘못된 것입니다. 중복 실행 중인 클라이언트를 종료하거나 SOCKS 포트를 10808에서 사용하지 않는 포트로 변경하세요.
3. invalid user가 표시되는 경우: UUID, 사용자 식별자와 프로토콜 유형을 확인하세요. VMess와 VLESS 링크는 프로토콜 이름만 바꾼다고 계속 사용할 수 없습니다.
4. handshake failed가 표시되는 경우: 시스템 시간, 서버 이름, TLS 매개변수, REALITY 공개 키, 짧은 식별자와 클라이언트 지문을 확인하세요. 라우팅 규칙은 먼저 변경하지 않는 것이 좋습니다.
5. 시작에는 성공했지만 트래픽이 없는 경우: 시스템 프록시, DNS와 아웃바운드 태그를 확인하세요. 라우팅 규칙이 존재하지 않는 outboundTag를 참조하면 특정 요청이 예상대로 전송되지 않을 수 있습니다.

자주 묻는 선택 질문과 해결 방법

코어 선택은 한 번 정하고 끝나는 결정이 아닙니다. 구독 제공자가 노드 프로토콜을 변경하거나 클라이언트가 코어를 업그레이드하고 서버 설정이 이전되면 호환성을 다시 확인해야 할 수 있습니다. 검증된 노드 하나를 보관하고 사용한 프로토콜과 전송 매개변수를 기록해 두면 이후 문제 해결 시간을 크게 줄일 수 있습니다.