프로젝트 관계: 역사를 공유하며 각자 발전
Project V는 네트워크 통신 도구를 중심으로 형성된 프로젝트 생태계이며, V2Ray는 그 핵심 프로젝트입니다. V2Fly는 커뮤니티의 V2Ray 유지 관리와 개발을 이어가고 있습니다. Xray는 V2Ray에서 출발한 뒤 독자적인 기능 개발 방향을 갖추었습니다. 일상적으로 말하는 ‘V2Ray 클라이언트’는 이 생태계의 GUI 도구를 통칭하는 경우가 많습니다. 그렇다고 모든 클라이언트가 같은 코어를 사용하거나 설정 항목이 완전히 동일하다는 뜻은 아닙니다.
가이드를 읽을 때는 먼저 클라이언트 이름을 확인하고 실제 사용 중인 코어를 파악하세요. 서버에서 특정 프로토콜, 전송 방식, 보안 설정을 요구한다면 실제 지원 여부를 확인해 입력해야 합니다. 특히 VLESS와 REALITY 설정은 코어의 기능과 서버 매개변수를 먼저 확인하세요. 필드 이름을 임의로 바꾸는 것만으로 호환성을 확보할 수는 없습니다. 구독을 가져오면 설정이 클라이언트에 전달되어 해석될 뿐, 해당 매개변수를 지원하는 코어가 필요합니다.
세 클라이언트의 역할: 인터페이스 관리와 코어 실행
v2rayN은 데스크톱 플랫폼용 오픈 소스 GUI 클라이언트로 서버 관리, 구독 업데이트, 라우팅 및 프록시 설정을 지원합니다. 사용할 수 있는 코어와 기능은 설치 패키지 및 현재 설정에 따라 다릅니다. v2rayNG는 Xray 코어를 사용하는 Android용 오픈 소스 클라이언트입니다. v2flyNG도 Android용이며 V2Fly 코어를 사용하므로 관련 설정이 필요한 경우에 적합합니다. 기기 플랫폼과 설정 호환성을 기준으로 클라이언트를 선택하세요.
이 세 도구는 구독 서비스 자체가 아닙니다. 클라이언트 다운로드, 구독 주소 발급, 원격 서비스 이용 가능 여부는 각각 별개의 문제입니다. 클라이언트를 바꿔도 구독 유효 기간이 자동으로 연장되거나 서버의 트래픽 및 연결 제한이 달라지지는 않습니다. 구독을 업데이트해도 서버가 표시되지 않으면 그룹 주소와 업데이트 결과를 확인하세요. 서버 목록은 있지만 연결되지 않는다면 선택한 설정, 프로토콜 매개변수, 로그를 확인하세요. 같은 주소를 반복해서 가져오기보다 문제 계층을 좁혀 살펴보는 편이 효과적입니다.
오픈 소스 프로젝트: 인터페이스와 코어를 구분해 이해하기
오픈 소스란 해당 라이선스에 따라 코드가 공개되어 있다는 의미이며, 사용·수정·배포 시에는 프로젝트의 라이선스 조건을 따라야 합니다. V2Fly의 V2Ray 코어는 MIT 라이선스를, Xray-core는 MPL-2.0을 사용합니다. 클라이언트에는 별도의 라이선스 안내가 있으므로 코어 라이선스를 설치 패키지와 모든 종속 구성 요소에 그대로 적용해서는 안 됩니다. 재배포하거나 수정할 때는 클라이언트, 코어, 포함된 구성 요소의 라이선스를 각각 확인하세요.
커뮤니티 유지 관리로 버그 수정과 기능 개발이 이어지지만, 오픈 소스라고 해서 실제 설정 점검이 필요 없다는 뜻은 아닙니다. 구독 주소에는 접근 자격 정보가 포함되는 경우가 많으므로 스크린샷을 공유하기 전에 전체 주소와 사용자 식별 정보, 민감한 매개변수를 가리세요. 문제를 확인할 때는 메뉴 위치, 오류 유형, 이미 시도한 작업을 우선 제공하고 자격 정보가 포함된 설정 파일 전체를 공개하지 마세요. 사이트의 예시 주소는 필드 형식을 설명하기 위한 것이며 실제 서비스에 사용할 수 없습니다.
업데이트 구분: 구독, 클라이언트, 규칙 데이터
구독을 업데이트하면 서버 설정을 다시 가져옵니다. 클라이언트를 업데이트하면 GUI와 함께 제공되는 구성 요소가 변경됩니다. 라우팅 데이터를 업데이트하면 도메인 목록이나 주소 목록의 매칭 결과가 달라집니다. 각 작업은 서로 다른 대상을 처리합니다. 연결에 문제가 있다고 세 가지를 한꺼번에 업데이트하면 원격 설정, 코어 동작, 라우팅 결과 중 무엇이 원인인지 파악하기 어렵습니다. 현재 설정을 보존하고 오류를 기록한 뒤 문제에 맞는 업데이트만 선택하세요.
클라이언트를 업그레이드하기 전에 실행 중인 프로그램을 종료하고 구독 그룹과 사용자 지정 라우팅 규칙을 백업하세요. 업그레이드 후에는 기존에 연결되던 서버부터 확인한 다음 새 기능을 테스트합니다. 구독 자동 업데이트 간격은 실제 사용 빈도와 서비스 제공자 요구에 맞추세요. 자주 요청한다고 이용 가능성이 높아지는 것은 아니며 요청 제한이 적용될 수 있습니다. 구독 주소가 이미 만료되었다면 간격을 조정해도 복구되지 않으므로 먼저 주소 문제를 해결해야 합니다.
연결 확인: 테스트 결과와 앱 동작 구분하기
서버 테스트에 결과가 나와도 모든 앱이 프록시를 거친다는 뜻은 아닙니다. 먼저 브라우저로 대상에 접속해 보고, 클라이언트 로그에 해당 연결이 표시되는지 확인한 다음 라우팅 결과가 예상과 맞는지 살펴보세요. 실제 연결 테스트, TCPing, 웹페이지 로딩은 서로 다른 구간을 확인하므로 테스트 숫자 하나만으로 전체 연결 상태를 판단해서는 안 됩니다. 네트워크 변경, DNS 캐시, 대상 사이트 상태도 결과에 영향을 줄 수 있습니다.
특정 앱 하나만 실패한다면 앱 자체의 프록시 옵션과 트래픽 처리 범위를 먼저 확인하세요. 모든 앱에서 실패한다면 코어가 실행 중인지, 서버가 선택되었는지, 로컬 포트가 수신 대기 중인지 확인합니다. 전체 프록시가 필요하더라도 ‘앱 트래픽을 프록시로 보내는 것’과 ‘들어온 연결을 프록시 아웃바운드로 보내는 것’은 구분해야 합니다. 전자는 보통 시스템 프록시나 TUN이, 후자는 라우팅 규칙이 결정합니다. 구체적인 설정 순서는 입문 가이드를 참고하고, 플랫폼별 권한 차이는 사용 설명서에서 확인하세요.