Project V와 V2Fly의 관계
Project V는 네트워크 프록시 도구를 중심으로 형성된 오픈 소스 생태계이며, V2Ray는 그중 핵심 소프트웨어 중 하나입니다. V2Fly 커뮤니티는 V2Ray 관련 코어 개발과 문서 작업을 이어가고 있습니다. 일상적인 대화에서 ‘V2Ray’는 관련 클라이언트를 통칭하는 말로도 쓰이지만, 데스크톱에 설치하는 v2rayN은 코어 자체가 아닙니다. 각 이름의 차이를 알아야 가이드에서 말하는 ‘클라이언트 업데이트’와 ‘코어 변경’이 무엇을 바꾸는지 이해할 수 있습니다.
그래픽 클라이언트는 보통 구독, 서버 목록, 라우팅 템플릿, 시스템 설정을 관리하고 정리된 설정을 코어에 전달합니다. 따라서 인터페이스에 특정 항목이 보인다는 사실만으로 현재 코어가 해당 기능을 지원한다고 단정할 수 없습니다. 실제 사용 전에는 선택한 코어, 서버 요구 사항, 클라이언트가 생성한 설정을 함께 확인하세요. 문제를 진단할 때 이 세 가지를 먼저 기록해 두면 소프트웨어 전체를 바꾸는 것보다 정확하게 원인을 찾을 수 있습니다.
Xray와 V2Fly의 기능은 동일하지 않습니다
Xray는 관련 코드 기반에서 발전한 별도의 코어 계열입니다. 두 계열은 일부 개념을 공유하지만 각기 다른 방향으로 발전하고 있습니다. VMess, VLESS, 전송 계층, 보안 계층을 구분해 이해해야 합니다. REALITY는 보안 관련 기술이지 모든 프록시 프로토콜과 나란히 놓을 수 있는 독립적인 서버 유형이 아닙니다. 설정이 작동하는지는 공유 링크를 인터페이스가 인식하는지만 볼 것이 아니라 실제 조합을 확인해야 합니다.
XTLS 또는 REALITY를 사용하는 설정은 Xray의 해당 구현 요구 사항을 기준으로 확인하세요. 코어마다 설정 항목, 기본값, 동작이 완전히 같다고 보장할 수 없습니다. 이전하기 전에는 기존 설정을 보관하고 지원 여부가 명확한 연결 하나를 테스트한 뒤 로그에서 알 수 없는 항목, 전송 방식 불일치, 핸드셰이크 오류가 있는지 살펴보세요. 이 문서의 설정 창은 인바운드와 라우팅 항목을 보여주는 예시일 뿐, 그대로 실행할 수 있는 완전한 설정이 아닙니다.
세 클라이언트의 오픈 소스 범위
v2rayN은 데스크톱용으로 그래픽 인터페이스에서 서버, 구독, 라우팅을 관리합니다. v2rayNG는 Android용이며 일반적인 배포판은 Xray 코어를 사용합니다. v2flyNG는 v2fly 코어 기반의 Android 사용 경로를 제공합니다. 세 클라이언트 모두 오픈 소스이지만 이름이 비슷하다고 인터페이스 기능, 코어 지원, 플랫폼 권한까지 같다고 볼 수는 없습니다.
오픈 소스 소프트웨어는 각 프로젝트의 라이선스 조건에 따라 코드를 읽고 사용하거나 재배포할 수 있다는 뜻이지, 모든 구성 요소가 같은 라이선스를 따른다는 뜻은 아닙니다. 그래픽 인터페이스, 코어, 규칙 데이터는 각각 살펴봐야 합니다. 클라이언트는 구독 서비스가 아닙니다. 소프트웨어를 설치해도 사용할 수 있는 서버가 자동으로 만들어지지 않으며, 구독의 유효 기간과 내용, 사용 권한은 제공자가 정합니다. 클라이언트를 선택할 때는 먼저 현재 설정에 필요한 프로토콜을 확인하고 플랫폼과 사용 방식에 맞는 제품을 고르세요.
클라이언트·코어·구독 업데이트
클라이언트 업데이트는 주로 인터페이스, 설정 관리, 플랫폼 호환성에 영향을 줍니다. 코어 업데이트는 프로토콜 구현과 실행 동작을 바꾸며 구독 업데이트는 원격 서버 정보를 다시 가져옵니다. 세 작업은 서로 다른 대상을 처리합니다. 구독이 만료된 경우 인터페이스를 재설치해도 해결되지 않으며, 인터페이스 오류가 구독 업데이트로 고쳐지지도 않습니다. 먼저 문제가 발생한 계층을 파악한 뒤 해당 작업을 진행하세요.
업데이트 전 필요한 설정을 저장하고 현재 코어 선택, 라우팅 모드, 로컬 수신 포트를 기록하세요. 업데이트 후에는 기본 연결을 테스트한 다음 사용자 지정 규칙과 TUN을 다시 설정합니다. 구독을 업데이트하면 제공 서버의 매개변수가 덮어써질 수 있으므로 계속 사용할 수동 설정은 구독 그룹과 분리해 관리하세요. 구독 주소, 공유 링크, 전체 설정에는 접속 정보가 포함될 수 있으니 공개 스크린샷이나 문제 해결 기록에 그대로 올리지 마세요.
데이터 흐름 순서에 따라 설정 문제 진단
연결 과정을 앱, 인바운드, 라우팅, 아웃바운드, 원격 서버 단계로 나눠 살펴보세요. 브라우저가 시스템 프록시를 사용하지 않는다면 앱에서 인바운드까지의 문제입니다. 포트 충돌은 로컬 수신 문제이고, 요청이 잘못된 태그로 전달되면 라우팅 문제입니다. 원격 서버와 매개변수가 맞지 않는다면 아웃바운드와 서버 설정을 확인해야 합니다. DNS는 도메인 확인과 규칙 매칭에도 영향을 줄 수 있으므로 마지막에만 확인해서는 안 됩니다.
한 번에 하나의 설정만 변경하고 변경 전후의 로그를 보관하세요. 먼저 서버 설정으로 연결할 수 있는지 확인하고, 그다음 분할 라우팅 규칙을 검증한 후 투명 프록시를 설정합니다. 웹페이지가 열린다는 사실은 해당 요청이 완료됐다는 뜻일 뿐, 모든 프로그램과 도메인, 전송 방식이 예상한 경로를 사용한다는 의미는 아닙니다. 동작을 구체적으로 확인하려면 트레이 아이콘만 볼 것이 아니라 클라이언트 로그와 앱 자체의 프록시 설정을 함께 확인하세요.