V2Ray 자주 묻는 질문

V2Ray는 Project V 프록시 도구 생태계의 일부이며, V2Fly는 V2Ray를 이어 커뮤니티에서 관리하고 Xray는 이 생태계에서 발전한 코어 포크입니다. 코어는 프로토콜 처리, 라우팅, 데이터 전달을 담당하고 v2rayN, v2rayNG, v2flyNG는 설정 관리와 그래픽 인터페이스를 제공합니다. v2rayNG는 Xray를, v2flyNG는 V2Fly를 사용합니다. v2rayN에서 실제로 사용하는 코어는 버전과 설정에 따라 달라집니다. 특정 프로토콜을 사용할 수 있는지 확인하려면 클라이언트 버전, 실제 실행 중인 코어, 서버 매개변수를 함께 살펴봐야 합니다. 화면에 비슷한 이름이 표시되는지만으로 판단할 수는 없습니다.

클라이언트 설치가 끝났다는 것은 로컬 도구를 실행할 수 있다는 뜻일 뿐, 연결할 원격 서버가 준비됐다는 의미는 아닙니다. 보통 유효한 구독이나 공유 링크를 가져오거나 서버에서 받은 주소, 포트, 인증 정보, 전송 매개변수를 직접 입력해야 합니다. 이 사이트는 클라이언트 다운로드와 설정 문서를 제공하며 노드나 구독은 제공하지 않습니다. 기존 설정도 유효 기간, 서비스 상태, 프로토콜 호환성을 확인해야 합니다. 출처가 불분명한 구독으로 기존 설정을 바로 덮어쓰지 마세요. 별도 그룹을 만들어 출처와 용도를 확인한 다음 노드를 선택하고 연결을 테스트하세요.

시스템 프록시는 시스템 프록시 설정을 따르는 앱에 로컬 프록시 주소를 제공하지만 모든 프로그램에 적용되는 것은 아닙니다. 라우팅 규칙은 트래픽이 코어에 들어온 뒤 어떤 아웃바운드를 사용할지 결정합니다. 클라이언트에 들어오지 않은 트래픽을 자동으로 처리하지는 않습니다. TUN은 가상 네트워크 인터페이스를 통해 조건에 맞는 트래픽을 전달하며 시스템 라우팅, DNS, 권한 설정도 필요합니다. 문제를 확인할 때는 앱 트래픽이 클라이언트에 들어오는지, 라우팅 규칙이 일치하는지, 아웃바운드가 작동하는지 순서대로 살펴보세요. 처음 설정한다면 먼저 시스템 프록시로 브라우저 접속을 확인하고, 그다음 TUN을 별도로 테스트하세요. 여러 진입 방식을 한꺼번에 바꾸지 않는 것이 좋습니다.

Windows, macOS, Linux 데스크톱에서는 v2rayN을 먼저 살펴보세요. Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 고려하고, V2Fly 코어가 필요하다면 v2flyNG를 검토하세요. 이름이 비슷한지가 아니라 운영체제, 기기 아키텍처, 기존 설정의 프로토콜 요구사항을 기준으로 선택해야 합니다. Windows용 v2rayN 데스크톱 버전은 크로스 플랫폼 인터페이스를, WPF 버전은 기존 인터페이스를 사용하므로 메뉴 위치가 다를 수 있습니다. 클라이언트를 바꾸기 전에 설정을 백업하고, 새 클라이언트가 기존 전송 및 보안 매개변수를 지원하는지 확인하세요. 다른 도구의 내부 데이터베이스를 그대로 복사하지 마세요.

arm64는 64비트 ARM 시스템을 사용하는 기기에 적합합니다. 2015년 이후 출시된 주요 Android 휴대전화라면 우선 고려할 수 있지만, 최종적으로는 기기 시스템이 지원하는 ABI를 확인해야 합니다. universal 패키지에는 여러 아키텍처용 네이티브 구성 요소가 포함되어 있어 아키텍처를 확인하기 어려울 때 유용하지만 파일 크기가 더 큰 편입니다. 프로세서가 64비트를 지원해도 설치된 시스템까지 반드시 64비트인 것은 아닙니다. 설치 파일이 호환되지 않는다는 메시지가 나오면 시스템 버전과 ABI를 확인하세요. 서명 충돌 메시지가 표시된다면 기존 앱과 새 패키지의 서명이 다르다는 뜻이며, universal을 선택하는 것만으로 해결되지 않습니다.

먼저 구독 주소와 개별 노드 공유 링크를 구분하세요. 구독 주소는 구독 그룹에 추가한 뒤 업데이트해야 하고, 노드 링크는 클립보드에서 가져오기 등 노드 가져오기 기능을 사용해야 합니다. 복사한 주소의 앞뒤 공백, 줄바꿈, 누락된 문자를 확인하고 메신저에서 주소가 잘리지 않았는지도 살펴보세요. 목록이 비어 있다면 구독 업데이트 로그를 확인하고 현재 그룹 필터가 새 노드를 숨기지 않는지 확인하세요. 로그인 페이지, 오류 페이지, 빈 내용을 반환하는 주소는 유효한 구독으로 처리할 수 없습니다. 서버가 클라이언트에서 아직 지원하지 않는 형식을 사용한다면 제공자에게 호환되는 형식을 문의하세요. 주소의 인증 정보를 반복해서 바꾸며 해결하려고 하지 마세요.

macOS에서는 먼저 ‘이 Mac에 관하여’에서 칩 정보를 확인하세요. Apple Silicon은 arm64, Intel은 x64를 선택합니다. Linux에서는 프로세서 아키텍처와 배포판 패키지 형식을 모두 확인하세요. Debian과 Ubuntu 계열은 보통 deb, Fedora 등은 보통 rpm을 사용합니다. ARM 기기에는 해당 arm64 패키지가 필요합니다. 설치 후 실행되지 않는다면 노드를 바꾸기보다 먼저 시스템에 표시된 종속성, 권한, 호환성 안내를 확인하세요. 앱은 실행되지만 코어가 시작되지 않는 문제는 별도로 살펴봐야 합니다. 로그, 런타임 라이브러리, 파일 실행 권한을 확인해 설치 문제를 네트워크 문제로 오해하지 않도록 하세요.

현재 클라이언트 버전이 TUN 기능을 실제로 제공하는지 확인한 뒤, 해당 버전의 안내에 따라 가상 인터페이스 생성과 라우팅 변경에 필요한 권한을 부여하세요. Windows에서는 보통 관리자 권한이나 클라이언트에 포함된 서비스가 필요합니다. macOS와 Linux의 권한 부여 방식은 버전에 따라 다르므로 다른 플랫폼의 절차를 그대로 적용하지 마세요. Android에서는 시스템 VPN 권한을 확인하고 다른 VPN 앱이 연결을 사용 중인지 살펴보세요. 기능에 필요한 권한만 부여하고 보안 기능 전체를 끄지 마세요. 문제를 진단하기 전에 TUN을 끄고 일반 프록시가 작동하는지 확인하세요. 기본 아웃바운드 연결이 실패한다면 권한을 높여도 원격 연결 문제는 해결되지 않습니다.

먼저 수동 업데이트가 성공하는지 확인한 다음 클라이언트의 구독 그룹 설정이나 구독 설정에서 자동 업데이트 옵션을 찾으세요. 옵션 이름, 시간 단위, 실행 조건은 버전마다 다를 수 있으므로 현재 화면을 기준으로 설정해야 합니다. 제공자의 업데이트 주기에 맞춰 적절한 간격을 지정하고 지나치게 짧은 주기로 반복 요청하지 마세요. 데스크톱 클라이언트를 종료하면 예약 작업이 실행되지 않는 경우가 많고, Android의 백그라운드 제한으로 업데이트가 지연될 수도 있습니다. 업데이트에 프록시가 필요하다면 사용 가능한 노드를 하나 유지하고 업데이트 요청의 네트워크 경로를 확인하세요. 자동 업데이트는 설정 내용을 새로고침할 뿐 구독 기간을 연장하거나 중지된 서비스를 복구하지 않습니다.

대부분의 경우 다시 가져올 필요가 없습니다. 구독은 노드 설정을 일괄로 가져오고 갱신하는 기능이며, 노드 전환은 기존 목록에서 사용할 설정을 선택하는 기능입니다. 서로 다른 작업입니다. 전환한 뒤에는 클라이언트가 새 설정을 적용했는지, 로그에 다시 불러오기 오류가 나타나는지 확인하세요. 브라우저의 기존 연결이 이전 노드를 계속 사용할 수 있으므로 테스트할 때는 기존 페이지를 닫았다가 다시 열고, 필요하면 앱을 재시작하세요. 자동 선택이나 로드 밸런싱 규칙이 목록을 제어하는 경우 화면에서 선택한 노드가 실제 출구와 다를 수 있으니 현재 모드를 확인해야 합니다. 노드 매개변수가 바뀌었거나 설정이 만료됐거나 목록 갱신이 필요한 경우에만 구독을 업데이트하세요.

먼저 코어가 정상적으로 시작됐는지 확인한 다음 시스템 프록시를 켜세요. 시스템 프록시의 주소와 포트가 클라이언트의 로컬 인바운드 설정과 일치하는지도 확인해야 합니다. 새 브라우저 페이지를 열고 클라이언트의 액세스 로그를 살펴보세요. 해당 요청이 로그에 나타나야 브라우저 요청이 코어에 들어온 것입니다. 로그가 꺼져 있다면 적절한 수준으로 활성화하고 테스트 후 원래 설정으로 되돌리세요. 브라우저 확장 프로그램, 별도 프록시 설정, 앱 자체의 연결 정책이 시스템 설정을 덮어쓸 수도 있습니다. 지연 시간 테스트가 성공해도 테스트 경로가 작동한다는 뜻일 뿐, 브라우저가 연결됐다는 증거는 아닙니다. 출구 IP도 참고 자료일 뿐이며, 직접 연결 규칙에 따라 요청마다 출구가 달라질 수 있습니다.

현재 클라이언트의 백업 또는 내보내기 기능을 우선 사용하고 구독 그룹, 활성 노드, 라우팅 모드, 로컬 포트, DNS 설정을 기록하세요. 내보낸 파일에는 구독 인증 정보와 노드 인증 정보가 포함될 수 있으므로 안전한 곳에 보관하고 공개 게시판에 올리지 마세요. 업그레이드 전에 새 버전의 시스템 요구사항과 설정 이전 안내를 확인하세요. 이전이 끝나면 기본 연결부터 테스트하고 사용자 지정 라우팅과 TUN 설정을 하나씩 복원하세요. 구독에 포함된 노드는 다음 업데이트 때 사용자 지정 내용이 덮어쓰일 수 있으므로 별도로 저장해야 합니다. 다른 클라이언트로 바꿀 때는 범용 공유 링크나 지원되는 설정 형식으로 가져오는 편이 안전합니다.

먼저 기기가 기본 네트워크에 정상적으로 연결되는지 확인하고 서버 주소와 포트, 구독 유효 상태를 살펴보세요. 실제 연결 테스트의 시간 초과는 DNS 확인, 연결 수립, TLS 핸드셰이크, 테스트 대상 접속 불가 등 여러 원인으로 발생할 수 있습니다. 한 번의 결과만으로 노드가 영구적으로 중단됐다고 판단할 수는 없습니다. 같은 시각의 로그를 확인해 도메인 확인 실패, 연결 거부, 핸드셰이크 오류를 구분하세요. 같은 네트워크에서 정상 작동이 확인된 다른 설정과 비교한 뒤, 사용이 허용된 다른 네트워크에서도 원래 설정을 테스트할 수 있습니다. 모든 설정이 실패하면 로컬 네트워크와 코어부터 확인하고, 특정 설정만 실패한다면 해당 설정의 전송·보안 매개변수와 서버 상태를 살펴보세요.

연결됨 표시는 로컬 VPN 인터페이스나 코어 프로세스가 시작됐다는 뜻일 수 있으며, 원격 요청이 성공했다는 의미는 아닙니다. 먼저 브라우저 요청이 액세스 로그에 나타나는지 확인하세요. 요청이 없다면 시스템 프록시, 브라우저 설정, TUN 적용 범위를 살펴보고, 요청이 있다면 해당 아웃바운드와 오류 로그를 확인하세요. 도메인 접속만 실패하고 다른 연결은 정상이라면 DNS 설정과 시스템 시간을 중점적으로 확인하세요. 일부 사이트만 실패한다면 해당 라우팅 규칙과 대상 서비스 상태를 살펴보세요. 문제를 진단할 때는 단순한 설정으로 되돌리고 중복된 프록시 진입 방식을 끈 뒤, 한 번에 하나씩 바꾸며 테스트하세요. DNS, 라우팅, 노드를 동시에 변경하면 원인을 파악하기 어렵습니다.

먼저 클라이언트 코어가 로컬 인바운드 포트를 정상적으로 열고 있는지 확인한 다음 시스템 프록시의 호스트와 포트를 비교하세요. 시스템 프록시 스위치가 켜져 있는지만 봐서는 안 됩니다. 시스템 프록시를 따르지 않는 프로그램도 있으므로 프로그램 자체에서 지원하는 HTTP 또는 SOCKS 프록시를 설정하거나 TUN 사용을 검토해야 합니다. 로그에 address already in use가 표시되면 중복 실행된 클라이언트를 종료하거나 사용 중이지 않은 포트로 로컬 리스닝 포트를 바꾸세요. 해당 포트를 참조하는 앱 설정도 함께 변경해야 합니다. 용도를 확인할 수 없는 시스템 프로세스를 종료하지 마세요. 프록시 확장 프로그램이나 다른 네트워크 도구가 설정을 반복해서 덮어쓴다면 충돌 항목을 먼저 비활성화한 뒤 시스템 프록시를 다시 적용하세요.

구독 업데이트 실패는 구독 내용을 가져오거나 해석하는 단계에서 발생합니다. 링크 유효 기간, 인증 상태, 요청에 사용되는 네트워크, 인증서 오류를 확인하세요. 먼저 시스템 시간이 정확한지 확인한 뒤 직접 연결과 사용 가능한 기존 프록시를 통한 업데이트를 각각 테스트할 수 있습니다. 공개 로그에 전체 구독 주소를 노출하지 마세요. 코어 시작 실패는 로컬 설정을 불러오는 단계에서 발생하므로 로그에서 JSON 문법 오류, 알 수 없는 필드, 누락된 파일, 포트 충돌처럼 처음 나타난 구체적인 오류를 확인하세요. 구독 업데이트 실패가 기존 노드 사용에 영향을 주지 않을 수도 있지만, 코어 시작에 실패하면 해당 코어에 의존하는 연결을 만들 수 없습니다. 먼저 문제가 발생한 단계를 파악하고 해당 설정을 수정하세요. 모든 설정을 지우는 것을 첫 번째 해결책으로 삼지 마세요.