Xray 코어와 V2Fly 코어 차이: VLESS·XTLS·REALITY 지원 비교

1. Xray와 V2Fly: 코어와 클라이언트 화면은 다릅니다

V2Ray는 프록시 도구 프로젝트의 이름이며, 이런 도구를 통칭하는 말로도 쓰입니다. V2Fly는 V2Ray를 유지·관리하는 커뮤니티 프로젝트입니다. 코어는 인바운드 연결을 받고, 라우팅 규칙을 적용하고, 프로토콜을 처리해 아웃바운드 연결을 설정합니다. Xray는 V2Ray 코드 기반에서 분기되어 개발됐습니다. 두 코어는 같은 역사를 공유하지만 기능 개발 방향과 설정 규칙은 서로 달라졌습니다. Xray를 V2Fly의 이름만 바꾼 버전으로 보면 안 됩니다.

클라이언트는 구독 관리, 노드 편집, 시스템 네트워크 설정을 담당하고 코어는 실제 연결을 처리합니다. 안드로이드용 v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 데스크톱에서 v2rayN을 쓴다면 현재 설정이 어떤 코어를 호출하는지 확인해야 합니다. 메인 창의 제목만으로는 판단할 수 없습니다. 클라이언트를 업데이트한 뒤에는 시작 로그에서 실제로 로드된 코어 이름과 버전도 확인하세요.

이 흐름을 보면 서로 다른 두 가지 문제를 구분할 수 있습니다. 노드가 목록에 보인다는 것은 클라이언트가 구독을 읽었다는 뜻일 뿐입니다. 코어가 설정을 불러오고 원격 서버와 핸드셰이크까지 완료해야 노드를 사용할 수 있습니다. 화면에 프로토콜 이름이 표시되더라도 현재 코어가 해당 조합의 모든 필드를 처리할 수 있다는 보장은 없습니다.

2. VLESS·XTLS·REALITY 지원 범위

프로토콜, 전송 방식, 보안 계층은 서로 다른 개념입니다. VMess와 VLESS는 프록시 프로토콜이고, TCP와 WebSocket은 데이터를 전달하는 전송 방식입니다. TLS와 REALITY는 연결 보안과 관련된 방식입니다. XTLS Vision은 특정 흐름 제어 방식으로 조건에 맞는 트래픽을 처리합니다. 노드 이름에 “VLESS”라고 적혀 있어도 사용할 코어를 결정하기엔 정보가 부족합니다. 보안 계층과 flow도 확인해야 합니다.

VLESS 자체에는 페이로드 암호화 기능이 없으므로 일반적으로 TLS나 REALITY 같은 보안 방식과 함께 설정합니다. VLESS와 VMess는 단순히 “새 버전이 구버전을 대체하는” 관계가 아닙니다. 호환성을 판단할 때는 첫 항목만 비교하지 말고 “VLESS + TCP + REALITY + Vision”처럼 노드 설정 전체를 하나의 조합으로 살펴보세요.

3. 설정 두 가지: 함께 확인해야 할 필드

아래 두 카드는 매개변수를 식별하기 위한 예시이며, 그대로 사용할 수 있는 노드 설정이 아닙니다. 도메인은 예시용 예약 도메인이고 경로와 포트도 설명을 위한 값입니다. 실제 연결에는 서버나 구독에서 제공한 매개변수를 사용하세요. 특히 한 노드의 UUID와 다른 노드의 공개 키, 또 다른 노드의 서버 이름을 조합해서는 안 됩니다.

REALITY 클라이언트에는 서버의 개인 키를 입력하지 않습니다. 클라이언트에는 서버에 대응하는 공개 키 등 인증 정보가 필요하며, 서버 개인 키는 서버에 보관해야 합니다. shortId는 16진수로 표시되며 사용할 수 있는 값은 서버에서 정합니다. 이를 메모처럼 취급하거나 구독에 포함된 값을 임의로 바꾸지 마세요. 서버 이름은 보통 serverName 또는 링크 매개변수 sni에 지정하며 서버 설정과 일치해야 합니다.

클라이언트 설정의 “지문”은 보통 TLS ClientHello의 모의 특성을 뜻하며 기기 식별 코드가 아닙니다. fingerprint를 chrome으로 바꿔도 잘못된 공개 키, UUID, 포트는 해결되지 않습니다. REALITY를 쓴다고 해서 반드시 Vision을 활성화해야 하는 것도 아닙니다. 두 항목은 서로 다른 설정이며, 서버가 해당 조합을 사용하는 경우에만 알맞은 flow를 설정하세요.

• VLESS: UUID, encryption, flow를 확인하세요. encryption은 보통 none을 사용하며, VMess의 auto 값을 그대로 복사하면 안 됩니다.
• WebSocket: path와 요청 헤더의 Host를 확인하세요. TLS의 serverName과 WebSocket의 Host는 서로 다른 필드입니다.
• TLS: 인증서 검증을 활성화된 상태로 유지하세요. 인증서나 서버 이름 오류를 감추기 위해 검증을 건너뛰지 마세요.
• REALITY: 공개 키, 서버 이름, shortId, 지문, 코어 버전을 확인하세요. 버전에 따라 화면의 항목 이름과 JSON 필드가 달라질 수 있으므로 현재 코어 문서와 클라이언트가 생성한 설정을 기준으로 삼으세요.

4. 설정 이전: JSON 구조가 같아도 서로 호환되는 것은 아닙니다

Xray와 V2Fly의 기존 설정에는 inbounds, outbounds, routing 같은 구조가 있지만, 공통 구조가 있다고 해서 모든 필드를 서로 사용할 수 있는 것은 아닙니다. V2Fly도 설정 형식에 따라 차이가 있습니다. 설정을 이전할 때는 먼저 대상 코어가 어떤 형식을 지원하는지 확인한 뒤, 프로토콜과 전송 관련 필드를 점검하세요. Xray 설정 전체를 V2Fly에 그대로 넘기면 로드 단계에서 실패할 수 있습니다.

아래는 flow가 어느 계층에 있는지 확인하기 위한 Xray의 일반적인 VLESS + TLS + Vision 아웃바운드 예시입니다. 전체 설정이 아니며, 예시 도메인과 모두 0인 UUID는 실제로 사용할 수 없는 가짜 값입니다. 이 예시에는 REALITY 매개변수가 없으므로 tls를 reality로 바꾸는 것만으로 설정을 전환할 수 없습니다.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "node.example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-0000-0000-000000000000",
                "encryption": "none",
                "flow": "xtls-rprx-vision"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "node.example.com",
          "allowInsecure": false
        }
      }
    }
  ]
}

1. 먼저 기존 설정을 저장하세요. 클라이언트 버전, 코어 버전, 현재 노드, 라우팅 프리셋을 기록해 두세요. 백업 파일에 접속 정보가 포함될 수 있으므로 안전하게 보관해야 합니다.
2. 노드 하나부터 이전하세요. 대상 클라이언트가 지원하는 노드 링크나 구독을 통해 다시 가져온 뒤 생성된 설정을 확인하세요. 전체 라우팅과 DNS 설정을 먼저 덮어쓰지 마세요.
3. 코어가 시작되는지 먼저 확인하세요. 로그에 알 수 없는 프로토콜이나 보안 유형, 지원하지 않는 flow가 표시되면 설정을 수정하거나 호환되는 코어를 선택하세요. 네트워크 지연을 반복해서 측정할 문제가 아닙니다.
4. 그다음 라우팅을 복원하세요. 규칙에서 참조하는 아웃바운드 tag, 도메인 및 IP 데이터 파일, DNS 처리 방식을 확인하세요. 노드에 연결된다고 해서 기존 규칙이 올바르게 이전된 것은 아닙니다.

5. v2rayNG와 v2flyNG 선택 및 연결 확인

안드로이드에서 REALITY 또는 Vision 노드를 사용 중이라면 보통 v2rayNG를 선택합니다. 기존 V2Fly 설정을 사용 중이고 노드가 일반적인 호환 조합으로 정상 작동한다면 v2flyNG를 계속 사용해도 됩니다. 데스크톱의 v2rayN은 관리 화면입니다. 현재 노드가 어떤 코어를 호출하는지, 해당 코어가 매개변수를 지원하는지가 핵심입니다.

코어, 노드, DNS, 라우팅 프리셋을 한꺼번에 바꾸지 마세요. 한 번에 하나씩 변경해야 원인을 파악할 수 있습니다. 아래 숫자는 각 포트의 역할을 설명하기 위한 예시이며, 속도 측정 결과나 모든 클라이언트의 기본값을 뜻하지 않습니다. 실제 포트 값은 현재 설정을 기준으로 확인하세요.

원격 443 포트에서 TCP 연결이 성립해도 해당 계층에 도달했다는 뜻일 뿐, VLESS 인증이나 TLS 또는 REALITY 핸드셰이크가 성공했다는 보장은 없습니다. 로컬 10808 포트를 다른 프로그램이 사용 중이면 코어가 시작되지 않을 수 있으며, 이는 원격 프로토콜 호환성과 무관합니다. DNS 요청도 별도의 경로를 사용합니다. 브라우저에서 도메인이 확인되더라도 코어가 사용하는 리졸버에 연결할 수 있다는 뜻은 아닙니다.

• 코어 로그: 먼저 시작 성공 기록과 실제 버전을 확인한 다음 연결 오류를 살펴보세요. 설정 로드 오류, DNS 오류, 핸드셰이크 오류, 시간 초과를 구분해야 합니다.
• 접속 설정: 데스크톱에서는 시스템 프록시가 활성화됐는지 확인하세요. 안드로이드에서는 VPN 권한과 앱별 프록시 적용 범위를 확인하세요. 접속 경로가 활성화되지 않으면 요청이 코어에 전달되지 않을 수 있습니다.
• 같은 조건에서 테스트: 네트워크, 노드, 라우팅 설정을 동일하게 유지하고 실제 웹 요청으로 확인하세요. 한 번의 지연 시간 측정만으로 호환성이 입증되는 것은 아닙니다.
• 로그 공유: 구독 토큰, UUID, 서버 주소, 인증 매개변수는 가리세요. 오류 유형, 버전 정보, 발생 시간만 있어도 문제를 파악하는 데 도움이 됩니다.

6. 자주 묻는 질문: 가져오기·시작·연결은 서로 다릅니다