Xray 코어와 V2Fly 코어 차이: XTLS·REALITY 지원 및 설정 호환성 비교

프로젝트 배경과 클라이언트별 역할

Xray-core와 V2Fly가 관리하는 v2ray-core는 같은 프로젝트에서 출발했지만, 현재는 서로 다른 기능 개발 방향을 갖고 있습니다. Project V는 이 프록시 도구 생태계를 이해하는 데 필요한 배경입니다. V2Fly는 커뮤니티에서 이어진 v2ray-core를 관리하고, Xray는 독자적인 방향으로 발전해 왔습니다. 두 코어 모두 프록시 연결, 라우팅, DNS 등을 처리하는 프로그램이며 클라이언트 인터페이스 자체는 아닙니다.

클라이언트는 구독 관리, 노드 편집, 코어 실행, 로그 표시를 담당합니다. 코어는 최종 설정을 읽고 연결을 처리합니다. 따라서 ‘인터페이스에서 노드를 가져올 수 있음’과 ‘코어에서 노드를 실행할 수 있음’은 별개의 문제입니다. 구독 파서는 일부 항목을 인식하더라도 현재 코어에서 실행할 수 있는 형태로 전달하지 못할 수 있습니다.

• v2rayNG: Xray 코어를 사용하는 Android 클라이언트입니다. REALITY, XTLS Vision 또는 기존 Xray 설정이 필요한 경우에 적합합니다.
• v2flyNG: V2Fly 코어를 사용하는 Android 클라이언트입니다. 서버가 일반적인 V2Fly 설정을 사용하고 Xray 전용 기능이 필요하지 않은 경우에 적합합니다.
• v2rayN: 데스크톱 클라이언트입니다. 실제 지원 기능은 선택한 코어와 버전에 따라 달라지므로 클라이언트 이름만으로 프로토콜 지원 여부를 판단할 수 없습니다.

문제를 점검할 때는 클라이언트 버전과 현재 실행 중인 코어 버전을 함께 확인하세요. 인터페이스 프로그램을 업데이트해도 기존 코어 파일이 함께 업데이트되는 것은 아닙니다. 코어를 교체하더라도 클라이언트 편집기에서 모든 신규 항목을 생성할 수 있다는 뜻은 아닙니다.

프로토콜 지원과 XTLS·REALITY 비교

REALITY와 XTLS Vision은 VMess나 VLESS와 같은 뜻이 아닙니다. VLESS는 프록시 프로토콜이고, REALITY는 전송 보안 설정 계층에 해당합니다. Vision은 특정 연결 조합과 함께 사용하는 흐름 제어 방식입니다. 구독에 VLESS, REALITY, Vision이 함께 표시된다면 여러 설정 계층을 확인해야 하며, ‘VLESS 지원’ 여부만 확인해서는 충분하지 않습니다.

여기서 XTLS는 현재 널리 사용되는 Vision 방식을 가리킵니다. 이전 가이드에 나오는 xtls-rprx-direct 같은 과거 흐름 제어 값을 xtls-rprx-vision으로 바꾸는 것만으로 마이그레이션이 완료되지는 않습니다. 서버도 호환되는 조합을 사용해야 합니다. 클라이언트에서 흐름 제어 값만 바꾸면 핸드셰이크가 실패할 수 있습니다.

REALITY와 Vision이 연결에서 하는 역할

REALITY는 핸드셰이크 과정에서 클라이언트가 서버의 키 정보를 확인하도록 하고, 대상 사이트 관련 설정을 사용해 TLS 핸드셰이크 특성을 구성합니다. 프록시 트래픽 전체를 대상 사이트로 전달하거나 인증을 생략하는 기능은 아닙니다. 서버에는 키, 대상, 허용할 이름을 올바르게 설정해야 하며 클라이언트에서도 이에 맞는 값을 지정해야 합니다.

Vision은 프록시 터널로 TLS 트래픽을 전달할 때의 식별 및 데이터 전달 경로를 처리합니다. 조건이 맞으면 중복 처리와 포장에 드는 부담을 줄일 수 있습니다. 모든 연결에서 암호화를 생략한다는 뜻도, 물리 회선의 혼잡이나 지역 간 왕복 시간, 통신망의 패킷 손실을 해결한다는 뜻도 아닙니다. 웹페이지 로딩 속도 개선 여부는 실제 사용 환경에서 확인해야 합니다.

설정 호환성과 항목 마이그레이션

두 코어의 기존 JSON 설정은 inbounds, outbounds, routing처럼 구조가 비슷한 부분이 많습니다. 하지만 ‘항목 이름이 같아 보인다’고 해서 모든 값, 기본 동작, 하위 항목까지 같다는 뜻은 아닙니다. V2Fly도 설정 형식에 따라 차이가 있으므로 마이그레이션 전에 현재 파일의 형식을 확인하세요.

일반적인 기존 JSON 라우팅 규칙을 예로 들면, 아래 코드는 ‘사설 주소를 direct 아웃바운드로 연결’한다는 의미입니다. 라우팅 부분만 보여 주는 예시이며 단독으로 실행할 수 있는 전체 설정은 아닙니다. 실제 파일에는 태그가 direct인 아웃바운드가 있어야 하며, 규칙에 필요한 데이터 파일도 준비해야 합니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

• 아웃바운드부터 마이그레이션: 프로토콜, 사용자 인증, 전송 방식, 보안 계층, 흐름 제어를 하나씩 확인하세요. REALITY가 포함된 아웃바운드는 V2Fly에서 그대로 사용할 수 없습니다.
• 다음은 라우팅 마이그레이션: 규칙 순서를 유지하고 각 outboundTag가 같은 이름의 아웃바운드를 참조하는지 확인하세요. 태그는 참조용 이름일 뿐, 직결이나 프록시 기능을 자동으로 생성하지 않습니다.
• 마지막으로 DNS 마이그레이션: 조회 정책, 도메인 규칙, 데이터 파일 경로를 확인하세요. 클라이언트 인터페이스에 표시된 DNS 옵션 이름을 코어 JSON 항목으로 그대로 간주하지 마세요.
• 구독과 전체 설정 구분: 노드 공유 링크에는 보통 단일 아웃바운드에 필요한 정보만 포함됩니다. 로컬 인바운드, DNS, 라우팅, 로그 설정까지 모두 옮겨 주지는 않습니다.

설정을 성공적으로 불러온 것과 항목이 실제로 적용된 것은 구분해야 합니다. 알 수 없는 항목이 오류를 일으킬 수도 있고 무시될 수도 있습니다. 프로세스가 실행 중이라는 사실만으로 마이그레이션이 성공했다고 볼 수 없습니다. 로그, 실제 아웃바운드, 대상 앱의 연결 결과를 확인하세요. 항목 간 관계는 프로토콜 설정 안내를 참고해 하나씩 점검할 수 있습니다.

포트 확인 및 문제 진단 순서

연결에 실패하면 로컬 접속과 원격 핸드셰이크를 나누어 확인하세요. 아래 포트 두 개는 점검 방법을 설명하기 위한 예시이며 모든 클라이언트의 기본값은 아닙니다. 현재 인바운드 설정과 노드의 포트를 기준으로 하세요. 가이드를 그대로 따라 하려고 정상 작동 중인 리스닝 설정을 변경하지 마세요.

1. 앱 트래픽이 클라이언트로 전달되는지 확인하세요. 로컬 SOCKS 인바운드가 127.0.0.1:10808에서 대기 중이라면 앱에서도 해당 주소, 포트, 프록시 유형을 사용해야 합니다. 시스템 프록시를 켜도 모든 앱이 이를 따르는 것은 아닙니다.
2. 코어가 정상적으로 로드되는지 확인하세요. 실행 직후 종료되거나 로그에 설정 항목 파싱 오류 또는 미지원 흐름 제어가 표시되면 먼저 코어 선택과 설정 형식을 확인하세요. DNS부터 변경하지 마세요.
3. 원격 서버에 연결할 수 있는지 확인하세요. 로컬 인바운드는 정상인데 원격 연결이 시간 초과된다면 노드 주소, 실제 서버 포트, 네트워크 경로, 서버 상태를 확인하세요. 포트에 연결할 수 있어도 인증 성공을 의미하지는 않습니다.
4. 핸드셰이크 설정을 확인하세요. REALITY는 공개 키 정보, shortId, serverName, 시간 설정을 중점적으로 확인하세요. 일반 TLS는 SNI, 인증서 유효 기간, 신뢰 체인을 점검해야 합니다. 오류를 숨기려고 인증서 검증을 끄지 마세요.
5. 라우팅과 DNS 조회를 확인하세요. 일부 도메인만 연결되지 않는다면 도메인 조회 결과와 적용된 아웃바운드를 확인하세요. 테스트 중에는 한 번에 한 종류의 설정만 변경하고 원래대로 되돌릴 수 있도록 기존 설정을 보관하세요.

클라이언트 선택 및 구독 마이그레이션

Android에서 REALITY 또는 Vision 노드를 사용한다면 v2rayNG를 우선 고려하세요. 일반 VMess 또는 VLESS 노드이고 서버 안내가 V2Fly 설정을 기준으로 한다면 v2flyNG를 선택할 수 있습니다. 데스크톱에서 v2rayN을 사용할 때는 노드에 필요한 기능을 먼저 확인한 뒤 알맞은 코어를 선택하세요. 인터페이스에 표시된 이름만으로 호환성을 판단할 수는 없습니다.

구독을 마이그레이션할 때는 새 그룹을 만들고 기존 그룹은 되돌릴 수 있도록 보관하세요. 먼저 노드 하나를 가져와 설정을 확인한 다음 일괄 업데이트를 진행하고 라우팅 설정을 옮기세요. 구독 업데이트가 수동으로 수정한 노드 항목을 덮어쓸 수 있습니다. 가져온 뒤 흐름 제어나 보안 계층이 사라졌다면 계속 수동 입력하기보다 구독 형식과 클라이언트 파싱 기능부터 확인하세요.