코어를 선택하기 전에 노드에서 요구하는 프로토콜, 전송 방식, 보안 계층을 확인하고 클라이언트가 올바른 설정을 생성하는지 살펴보세요. v2rayN을 사용 중이거나 안드로이드에서 v2rayNG 또는 v2flyNG를 선택하려는 사용자를 위해 REALITY와 Vision의 의존성, 두 설정을 그대로 서로 바꿔 쓸 수 없는 이유, 코어 전환 시 언제든 되돌릴 수 있도록 현재 상태를 보존하는 방법을 설명합니다.
클라이언트·코어·서버의 역할 구분하기
v2rayN은 구독 관리, 노드 편집, 프록시 켜기·끄기, 설정 생성을 담당하는 데스크톱 GUI 클라이언트입니다. Xray-core와 V2Fly가 유지 관리하는 V2Ray는 실제 연결을 처리합니다. 클라이언트 창이 정상적으로 열려도 코어가 제대로 시작됐다는 뜻은 아닙니다. 노드가 목록에 표시되어도 현재 코어가 해당 노드의 모든 설정 항목을 지원한다고 볼 수 없습니다.
Xray와 V2Fly는 기술적 뿌리를 공유하지만, 현재는 각자의 방향으로 발전해 왔습니다. Xray를 “어떤 상황에서든 대체 가능한 최신 V2Ray”로 보는 것은 정확하지 않습니다. 반대로 두 설정에 inbounds, outbounds가 모두 있다고 해서 완전히 호환된다고 볼 수도 없습니다.
- 데스크톱: v2rayN을 사용할 때는 현재 클라이언트 버전이 지원하는 코어와 노드 유형을 확인하고, 설치 폴더의 파일명만 보지 말고 시작 로그에서 실제 실행 중인 코어를 확인하세요.
- 안드로이드: v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 기반으로 합니다. 같은 앱의 테마만 다른 것이 아닙니다.
- 서버: 클라이언트와 서버에서 같은 이름의 코어를 사용할 필요는 없습니다. 다만 양쪽 모두 같은 프로토콜 조합을 지원하고 인증·전송·보안 매개변수가 일치해야 합니다.
프로토콜 지원 차이: VLESS나 VMess라는 이름만으로 판단하지 마세요
노드가 제공하는 기능은 보통 프록시 프로토콜, 전송 방식, 보안 계층이 함께 결정합니다. VLESS는 프록시 프로토콜이고 WebSocket은 전송 방식입니다. TLS와 REALITY는 연결 보안 방식에 해당하며, Vision은 Xray의 특정 사용 사례에서 활용되는 플로우 제어 방식입니다. 각 항목은 서로 다른 계층에 속하므로 서로 대체할 수 없습니다.
| 노드 요구 사항 | Xray | V2Fly | 선택 전 확인 사항 |
|---|---|---|---|
| VMess + WebSocket + TLS | 일반적인 지원 조합 | 일반적인 지원 조합 | 인증 매개변수, 경로, Host, TLS 서버 이름 |
| VLESS 기본 프로토콜 | 지원하며 자체 확장 기능도 제공 | 일부 버전이나 설정 체계에서 관련 기능을 구현했을 수 있으므로 사용 중인 버전을 확인해야 함 | VLESS라는 이름만으로 완전한 호환성을 판단할 수 없음 |
| VLESS + REALITY | Xray에서 주로 사용하는 구성 | Xray의 REALITY 설정을 그대로 사용할 수 없음 | 공개 키, 서버 이름, 짧은 ID, 전송 요구 사항 |
| xtls-rprx-vision | 지원되는 Xray 버전과 조합 필요 | 해당 Xray 플로우 값을 지원하지 않음 | 서버에서 이 flow를 명시적으로 요구하는지 |
| SOCKS / HTTP 로컬 인바운드 | 일반적으로 사용하는 로컬 프록시 인바운드 지원 | 일반적으로 사용하는 로컬 프록시 인바운드 지원 | 수신 주소와 포트, 앱의 프록시 설정 |
특히 “V2Fly가 VLESS를 지원하는가”를 버전 조건 없이 단정하지 마세요. 문제를 확인할 때는 사용 중인 바이너리, 설정 형식, 노드 요구 사항을 기준으로 살펴봐야 합니다. 다만 구독에 security=reality 또는 flow=xtls-rprx-vision이 명시되어 있다면 일반 VLESS 노드처럼 V2Fly에서 실행할 수 없습니다.
결론: 노드 기능에 맞춰 코어 선택하기
노드에서 REALITY나 Vision을 명시적으로 요구한다면 해당 조합을 지원하는 Xray 환경을 선택하세요. VMess + WebSocket + TLS 노드가 안정적으로 작동 중이라면 코어 이름만 바꾸기 위해 설정을 다시 만들 필요는 없습니다.
설정 호환성: JSON을 읽을 수 있어도 연결이 성립하는 것은 아닙니다
양쪽 설정에 비슷한 항목이 있어도 항목의 위치, 허용되는 값, 실행 시 의미가 다를 수 있습니다. V2Fly의 설정 형식도 한 가지로 뭉뚱그려서는 안 됩니다. 클라이언트가 생성하는 완성된 설정에는 보통 DNS, 라우팅, 로컬 인바운드도 포함됩니다. 아웃바운드 객체 하나만 복사한다고 마이그레이션이 끝나는 것은 아닙니다.
아래 두 카드는 하나씩 확인해야 할 매개변수 조합을 보여주는 예시입니다. 바로 가져오기 할 수 있는 노드가 아니며 서버 주소와 인증 정보도 포함하지 않습니다. WebSocket 경로 /ws는 예시일 뿐이므로 실제 경로는 서버 설정을 따르세요.
VLESS + REALITY + Vision
- 프로토콜
- VLESS
- 전송 방식
- TCP, 화면에 표시되는 명칭은 버전에 따라 다를 수 있음
- 보안 계층
- REALITY
- Flow
xtls-rprx-vision- 확인 항목
- 서버 이름, 공개 키, 짧은 ID
이 조합은 해당 Xray 기능에 의존합니다. 다른 코어에서 사용하려고 보안 항목을 삭제하지 마세요.
VMess + WebSocket + TLS
- 프로토콜
- VMess
- 전송 방식
- WebSocket
- 경로 예시
/ws- 보안 계층
- TLS
- 확인 항목
- UUID, Host, 서버 이름
두 코어 모두 일반적인 지원 사례가 있지만, 각 설정 형식에 맞게 항목을 생성해야 합니다.
- 프로토콜 항목: UUID, 암호화 매개변수, flow를 확인하고 한 프로토콜의 인증 항목을 다른 프로토콜에 그대로 복사하지 마세요.
- 전송 항목: 경로, 요청 헤더, 전송 명칭을 현재 버전 기준으로 확인하세요. 오래된 가이드의 명칭이 최신 설정에서도 유효하다고 단정할 수 없습니다.
- 보안 항목: TLS의 서버 이름과 WebSocket의 Host는 역할이 다릅니다. 예시에서 같은 도메인을 사용하더라도 항상 서로 같은 값이라고 볼 수 없습니다.
- 라우팅 항목: 아웃바운드 태그가 남아 있는지 확인하세요. 규칙에서 이전 태그를 참조한다면 문제는 프로토콜 핸드셰이크 단계가 아니라 라우팅 단계에서 발생했을 수 있습니다.
구독 가져오기와 라우팅 분기: 전환 후 다시 확인하기
구독 링크는 노드를 배포하는 경로일 뿐, 코어 자체가 아닙니다. 구독 업데이트에 성공했다는 것은 다운로드와 파싱의 일부 과정이 완료됐다는 뜻일 뿐입니다. 일부 클라이언트 버전은 인식하지 못하는 항목을 무시하거나 해당 아웃바운드를 생성하지 못할 수 있습니다. 서버 수가 늘어난 것을 확인한 뒤에도 노드 편집 화면에서 주요 매개변수를 점검하세요.
- 기존 그룹 보존: 필요한 설정을 먼저 내보내고 구독 주소를 안전하게 보관하세요. 기존의 유일하게 작동하는 설정을 덮어쓰지 말고 새 그룹에서 테스트하세요.
- 가져오기 결과 확인: 제공업체 안내와 비교해 프로토콜, 포트, 전송 방식, 보안 계층, flow를 확인하세요. REALITY 노드라면 공개 키, 서버 이름, 짧은 ID도 점검해야 합니다.
- 실행 중인 코어 확인: 연결을 다시 시작한 뒤 로그에서 코어 정보, 시작 오류, 수신 정보를 확인하세요. 노드 메모만 바꿔서는 코어가 전환되지 않습니다.
- 아웃바운드별 확인: 먼저 지정한 노드로 테스트 대상에 접속할 수 있는지 확인한 다음, 직접 연결 도메인과 프록시 도메인에 예상한 규칙이 적용되는지 확인하세요.
라우팅 분기는 규칙 순서, DNS 확인 방식, 도메인 및 IP 규칙 데이터, 스니핑 설정에 따라 달라집니다. 두 번의 테스트에서 서로 다른 규칙 파일이나 DNS를 사용했다면 결과 차이를 Xray나 V2Fly 탓으로만 돌릴 수 없습니다. 시스템 프록시와 TUN은 트래픽을 처리하는 범위도 다르므로 코어를 테스트할 때는 같은 연결 방식을 유지하세요.
로컬 포트와 핸드셰이크 오류: 연결 단계별로 원인 찾기
“전환 후 인터넷에 연결되지 않는다”는 말만으로는 어느 코어가 더 나은지 판단할 수 없습니다. 코어 시작 실패, 로컬 인바운드 장애, 원격 핸드셰이크 실패를 먼저 구분하면 노드를 계속 바꾸는 것보다 효과적으로 문제를 찾을 수 있습니다. 아래 숫자는 연결 과정을 설명하기 위한 설정 예시이며 모든 클라이언트의 기본값을 뜻하지 않습니다.
| 로그 또는 증상 | 우선 확인할 항목 | 다음 조치 |
|---|---|---|
unknown field 또는 설정을 불러오지 못함 | 항목 위치, 설정 형식, 코어 버전 | 알 수 없는 항목을 무작정 삭제하지 말고 현재 클라이언트에서 설정을 다시 생성 |
address already in use | 로컬 수신 포트가 이미 사용 중인지 | 중복 실행 중인 프록시 프로세스를 종료하거나 수신 포트와 앱 포트를 함께 변경 |
connection refused | 오류가 로컬 주소와 원격 주소 중 어느 쪽을 가리키는지 | 로컬 오류라면 수신 상태를 확인하고, 원격 오류라면 서버가 열려 있는지와 포트가 맞는지 확인 |
| 인증서 이름 불일치 | TLS 서버 이름, 인증서, 시스템 시간 | 이름과 시간을 바로잡고 검증 건너뛰기를 일반적인 해결책으로 사용하지 않기 |
| 핸드셰이크 실패 또는 연결 시간 초과 | 프로토콜 매개변수와 네트워크 연결 상태 | 매개변수를 확인한 뒤 네트워크를 점검하세요. 오류 문구만으로 원인을 단정할 수 없습니다. |
예를 들어 앱이 127.0.0.1:10808에 연결하자마자 거부된다면 먼저 코어가 해당 주소에서 수신 대기 중인지 확인하세요. 원격 443 포트를 바로 의심할 필요는 없습니다. 로컬 인바운드는 정상인데 로그에 원격 핸드셰이크 실패가 표시된다면 그때 UUID, 서버 이름, 보안 매개변수를 확인하세요. 두 단계는 해결 방법이 완전히 다릅니다.
업데이트 주기와 성능 비교: 한 번에 변수 하나만 변경하기
Xray와 V2Fly는 각각 자체 릴리스 기록을 관리합니다. 버전 번호의 크기를 서로 비교할 수 없으며, 출시일만으로 현재 노드에 더 적합한 코어를 판단할 수도 없습니다. 실제 사용 가능 여부는 GUI 클라이언트의 신규 항목 지원 여부, 포함된 코어와의 호환성, 서버에서 해당 기능을 사용하는지에 따라서도 달라집니다.
성능 역시 환경을 고려하지 않고 단정할 수 없습니다. 회선 혼잡, 서버 부하, 전송 방식, DNS, 라우팅이 모두 속도 측정에 영향을 줄 수 있습니다. 프로토콜이나 회선이 다른 테스트를 한데 묶어 특정 코어가 항상 얼마나 빠르다고 결론 내릴 수는 없습니다.
- 기준 상태 기록: 클라이언트와 코어의 실제 버전, 노드 매개변수, 프록시 모드, 라우팅 설정을 기록하고 현재 작동하는 설치 파일과 설정을 백업하세요.
- 변수 통제: 두 코어가 모두 지원하는 같은 프로토콜 조합으로 비교하고 서버, 테스트 대상, 트래픽 처리 방식을 동일하게 유지하세요.
- 반복 측정: 각 구성을 같은 조건에서 최소 3회 테스트하세요. 한 번의 지연 시간만 보지 말고 연결 성공 여부, 응답 시간, 지속 전송 성능을 각각 기록하세요.
- 업데이트 내용 확인: 새 버전에서 해결된 문제가 현재 사용 환경과 관련 있는지 확인하세요. 업그레이드 후에는 시작 로그, DNS, 직접 연결, 프록시 접속을 다시 점검하세요.
결론: 언제든 되돌릴 수 있도록 준비한 뒤 업그레이드 검증하기
클라이언트만 업그레이드하거나 코어만 교체하면 설정 생성 기능과 실제 실행 기능이 맞지 않을 수 있습니다. 먼저 클라이언트 안내에서 지원 범위를 확인하고 백업을 바탕으로 테스트하세요. 문제가 생기면 설정을 여러 개 연달아 바꾸기보다 정상 작동이 확인된 조합으로 되돌리세요.
실제 노드에 맞춘 선택: 세 가지 사용 사례
코어 선택은 결국 “현재 노드에 필요한 기능은 무엇인가”와 “현재 클라이언트가 올바르게 설정을 생성할 수 있는가”를 기준으로 해야 합니다. 이름을 통일하려고 모든 기기의 코어를 바꿀 필요도 없고, 기존 설정을 유지하려고 서버의 변경된 연결 요구 사항을 무시해서도 안 됩니다.
- 노드에서 REALITY 또는 Vision을 요구하는 경우: 데스크톱에서는 v2rayN이 지원되는 Xray 조합을 사용하는지 확인하세요. 안드로이드에서는 해당 기능에 맞는 v2rayNG를 선택하고 가져온 항목을 하나씩 확인하세요.
- 기존 V2Fly 설정이 안정적으로 작동하는 경우: 노드가 지원되는 프로토콜 조합을 사용하고 새 기능이 필요하지 않다면 계속 사용해도 됩니다. 안드로이드의 v2flyNG는 해당 코어 기능과 호환되는 노드에 적합합니다.
- 다른 코어로 이전하려는 경우: 기존 JSON 전체를 범용 설정 파일처럼 사용하지 말고 원본 구독 정보나 서버 매개변수로 설정을 새로 생성하세요. 프로토콜, 보안 계층, DNS, 라우팅을 각각 확인하세요.
올바르게 선택했는지는 코어가 정상적으로 시작되는지, 노드 매개변수가 빠짐없이 설정됐는지, 원하는 연결이 성공하는지, 라우팅 결과가 예상대로인지로 판단할 수 있습니다. 이 조건을 충족한 다음 업데이트 편의성과 설정 유지 비용을 고려하는 편이 프로젝트 이름만으로 순위를 매기는 것보다 실용적입니다.