V2Ray 자주 묻는 질문

V2Ray는 Project V 생태계의 프록시 소프트웨어이며, V2Fly는 관련 코어의 개발을 이어 왔습니다. Xray는 같은 계열에서 파생된 프로젝트로, 기능과 설정이 각자의 방향으로 발전했습니다. v2rayN은 구독, 노드, 프록시 모드를 관리하는 데스크톱 GUI 클라이언트이며, 실제 연결은 선택한 코어가 처리합니다. 따라서 클라이언트에 특정 프로토콜 옵션이 표시된다고 해서 현재 코어가 해당 설정을 지원한다는 뜻은 아닙니다. 문제를 확인할 때는 클라이언트 버전, 코어 이름, 시작 로그를 함께 기록하세요. REALITY나 Vision 설정을 사용할 때는 선택한 코어의 지원 여부를 특히 확인해야 합니다.

Windows, macOS, Linux 데스크톱에서는 해당 플랫폼용 v2rayN 설치 파일을 우선 선택하세요. Android에서는 Xray 코어를 사용하는 v2rayNG가 일반적인 선택이며, V2Fly 설정이 필요한 경우 v2flyNG를 고려할 수 있습니다. 이름이 비슷한지보다 운영체제, 프로세서 아키텍처, 노드에서 필요한 기능을 기준으로 선택하세요. 클라이언트마다 메뉴 위치, 라우팅 옵션, 구독 파싱 기능이 다를 수 있으므로 옮길 때 설정을 다시 확인해야 합니다. 먼저 한 클라이언트에서 구독을 가져오고 연결을 확인한 뒤 다른 기기로 옮기면 여러 변수를 한꺼번에 점검하는 일을 줄일 수 있습니다.

VMess, VLESS, Trojan은 프록시 프로토콜이며 Shadowsocks도 같은 계층에 속합니다. REALITY는 보안 전송 관련 설정으로, 보통 VLESS와 함께 사용하며 임의로 바꿔 쓸 수 있는 프로토콜 이름이 아닙니다. VLESS 자체는 콘텐츠를 암호화하지 않으므로 전송 보안을 별도로 설정해야 합니다. 클라이언트에는 TCP, WebSocket, TLS, flow처럼 서로 다른 계층의 연결 방식을 나타내는 항목도 표시될 수 있습니다. 구독을 가져오거나 직접 입력할 때는 서버에서 제공한 전체 매개변수를 항목별로 맞추세요. 프로토콜 드롭다운만 바꾸거나 이름이 비슷하다는 이유로 호환된다고 판단해서는 안 됩니다.

구독 주소는 보통 여러 노드 정보를 가져오는 URL이며, 업데이트할 때 클라이언트가 해당 주소에서 내용을 다시 요청합니다. 공유 링크는 vmess:// 또는 vless:// 같은 형식으로 노드 하나를 설명합니다. 기본 JSON 설정에는 인바운드, 아웃바운드, 라우팅, DNS 등 전체 설정이 포함될 수 있습니다. 세 가지를 모두 같은 입력란에 붙여 넣을 수 있는 것은 아닙니다. 노드 목록을 주기적으로 갱신하려면 구독 그룹을 사용하고, 노드 링크 하나만 있다면 클립보드 가져오기를 사용하세요. 전체 설정은 클라이언트의 설정 가져오기 기능으로 불러오면 됩니다. 구독 주소에 접근 정보가 포함될 수 있으므로 스크린샷이나 로그를 공유하거나 도움을 요청할 때는 주소 전체를 가리세요.

최근 출시된 Android 휴대전화라면 대체로 용량이 작은 arm64 패키지를 선택할 수 있습니다. universal 패키지는 여러 프로세서 아키텍처를 포함하므로 기기 아키텍처를 모르거나 구형 기기와의 호환성이 필요할 때 적합합니다. 기기 구입 연도만으로 판단하기는 어렵습니다. 64비트 칩을 사용해도 32비트 시스템을 실행하는 기기가 있으므로, 시스템에서 지원하는 앱 ABI를 기준으로 선택하세요. arm64 패키지가 호환되지 않는다고 표시되면 시스템 조건을 확인한 뒤 universal 버전을 시도할 수 있습니다. 업데이트할 때는 앱 서명 출처를 동일하게 유지하세요. 설치 실패 원인은 아키텍처뿐 아니라 서명 충돌, 시스템 버전, 저장 공간 부족일 수도 있습니다.

먼저 복사한 내용이 서비스 페이지 주소나 QR 코드 이미지 주소, 단일 공유 링크가 아닌 전체 구독 주소인지 확인하세요. 붙여 넣기 전에 앞뒤 공백을 제거하고, 메신저가 매개변수를 잘라내지 않았는지도 살펴보세요. 주소가 여전히 유효한지, 계정 권한에 문제가 없는지, 응답 형식이 클라이언트에서 지원되는지 확인해야 합니다. 브라우저에서 주소가 열린다고 해서 노드 목록이 반환되는 것은 아닙니다. 로그인 페이지, 오류 페이지, 리디렉션 페이지도 정상적으로 표시될 수 있습니다. 제공업체가 안내한 클라이언트용 입력 메뉴를 우선 사용하고 프로토콜 유형을 계속 바꾸지 마세요. 공유 링크라면 클립보드 가져오기 기능을 사용하면 됩니다.

시스템 프록시는 시스템 프록시 설정을 따르는 앱에만 적용되며 모든 트래픽을 자동으로 가로채지는 않습니다. 먼저 노드가 선택되어 있고 코어가 정상적으로 실행 중인지 확인한 다음, 클라이언트의 로컬 수신 포트와 시스템 프록시에 등록된 포트가 일치하는지 살펴보세요. 브라우저 확장 프로그램, 회사 정책, 브라우저 자체 프록시 설정이 시스템 설정을 덮어쓸 수 있습니다. 설정을 바꾼 뒤 브라우저를 완전히 종료하고 다시 실행해 보세요. 한 앱에서만 작동하지 않으면 해당 앱의 프록시 옵션을 먼저 확인하세요. 모든 앱에서 작동하지 않는다면 로컬 포트가 사용 중인지, 보안 소프트웨어가 차단하는지 살펴보세요. 더 많은 앱의 트래픽을 처리해야 할 때 TUN을 검토하고, 프록시 도구 여러 개를 동시에 켜지는 마세요.

TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅과 DNS를 변경할 수 있어 일반 시스템 프록시보다 높은 권한이 필요합니다. Windows에서는 클라이언트 안내에 따라 관리자 권한으로 실행하고 가상 네트워크 어댑터 구성 요소가 정상적으로 로드되었는지 확인하세요. macOS와 Linux에서는 현재 버전 안내에 따라 권한을 부여해야 하며, 다른 운영체제의 절차를 그대로 적용하면 안 됩니다. 먼저 다른 VPN이나 유사한 TUN 프로그램을 종료한 뒤 다시 시도하세요. 그래도 실패하면 로그에서 구체적인 권한 또는 장치 오류를 확인하고, 시스템 정책상 인터페이스를 만들 수 있는지 살펴보세요. 메시지를 없애려고 방화벽을 계속 꺼 두지 마세요. 일반적인 브라우저 사용이라면 우선 시스템 프록시로 되돌려 확인할 수 있습니다.

세 가지는 같은 계층의 개념이 아닙니다. 시스템 프록시와 TUN은 트래픽이 클라이언트로 들어오는 방식을 정하고, 규칙 라우팅과 전체 라우팅은 들어온 트래픽이 어떤 아웃바운드를 사용할지 정합니다. 프록시를 지원하는 브라우저만 사용한다면 시스템 프록시를 켜고 규칙 라우팅을 적용하는 것부터 시작할 수 있습니다. 시스템 프록시를 따르지 않는 앱의 트래픽도 처리해야 한다면 TUN을 고려하세요. 전체 라우팅은 보통 이미 가로챈 트래픽을 프록시 아웃바운드로 보내지만, 가로채지 않은 앱의 트래픽까지 자동으로 클라이언트에 전달하지는 않습니다. 한 번에 한 계층의 설정만 변경하고 기존 설정을 보존하세요. 접속 결과를 확인한 뒤 다음 항목을 바꾸면 트래픽 가로채기 문제를 노드 오류로 오인하는 일을 줄일 수 있습니다.

먼저 노드 목록에서 사용할 노드 하나를 현재 항목으로 명확히 선택한 뒤 코어를 시작하고 필요한 프록시 모드를 설정하세요. 목록에 표시되는 테스트 결과는 참고용입니다. 테스트 방식에 따라 TCP 연결, 핸드셰이크, 특정 URL 응답을 측정할 수 있으며 실제 웹 페이지 다운로드 속도와 같지는 않습니다. 확인할 때는 프록시를 사용해야 하는 페이지에 접속하면서 연결이 생성되었는지, 어떤 아웃바운드를 사용했는지 로그를 살펴보세요. 이어서 직접 연결되어야 하는 페이지에 접속해 라우팅이 설정대로 적용되는지 확인합니다. 모드와 규칙은 그대로 둔 채 노드만 바꾸면 결과를 더 명확하게 비교할 수 있습니다. 한 번의 테스트 실패만으로 구독 그룹 전체를 삭제하지 마세요.

Android의 VpnService는 기기 내 트래픽을 가로채는 인터페이스를 만들며, 처음 시작할 때 시스템 권한을 승인해야 합니다. 화면이 꺼진 뒤 연결이 끊기면 배터리 최적화, 백그라운드 실행, 자동 시작 제한을 받는지 확인하고 기기 설정에서 필요한 백그라운드 활동을 허용하세요. 앱별 프록시의 포함 모드는 선택한 앱의 트래픽만 가로채고, 제외 모드는 선택한 앱을 건너뜁니다. 설정 전에 현재 모드를 확인하고 변경한 뒤 연결을 다시 시작하세요. 테스트 중인 브라우저가 제외 목록에 들어가지 않도록 주의하세요. 백그라운드 연결 끊김과 노드 시간 초과는 서로 다른 문제이므로 구독을 바로 바꾸기보다 끊긴 시점과 로그를 함께 살펴보세요.

출처가 다른 구독은 별도 그룹으로 나누고, 각 그룹에 알아보기 쉬운 이름을 붙이면 어느 구독에서 업데이트가 실패했는지 찾기 쉽습니다. 자동 업데이트 간격은 제공업체의 제한과 노드 변경 빈도를 고려해 정하세요. 몇 분마다 갱신할 필요는 없습니다. 너무 자주 요청하면 제한에 걸릴 수 있고 모바일 기기의 백그라운드 활동도 늘어납니다. 처음 가져온 뒤에는 수동 업데이트가 정상적으로 완료되는지 확인하고 자동 업데이트를 켜세요. 일시적인 네트워크 문제로 업데이트가 실패해도 기존 노드가 모두 사용할 수 없다는 뜻은 아닙니다. 중복 노드를 정리하거나 구독 주소를 바꾸기 전에는 현재 사용하는 노드와 필요한 설정을 기록해 두세요. 업데이트 후 연결 복구에 필요한 설정을 잃지 않도록 할 수 있습니다.

구독 업데이트 요청과 노드 연결은 서로 다른 경로를 사용합니다. 기존 노드가 작동한다고 해서 구독 주소에도 접속할 수 있다는 뜻은 아닙니다. 먼저 오류가 주소 만료, 요청 시간 초과, 인증서 오류, 응답 파싱 실패 중 무엇인지 확인한 다음 현재 프록시를 통해 업데이트해야 하는지 살펴보세요. 버전에 따라 관련 메뉴 이름이 다를 수 있으므로 업데이트 요청이 실제로 어떤 경로를 사용하는지 확인해야 합니다. 인증서 오류가 발생하면 시스템 날짜와 시간, 시간대를 확인하고 인증서 검증을 바로 끄지 마세요. 로그인 페이지나 오류 메시지가 반환되면 제공업체에 주소 상태를 문의하세요. 반복해서 실패할 때는 요청을 연달아 보내지 말고, 사용 가능한 노드를 보존한 상태에서 구독 문제를 처리하세요.

먼저 기기의 일반 네트워크가 작동하는지 확인하고 코어가 정상적으로 시작되었는지 살펴보세요. 로컬 수신 포트 충돌이나 설정 파싱 오류가 있다면 먼저 해결해야 합니다. 코어가 실행 중이라면 노드 주소, 포트, 프로토콜, 전송 방식, 보안 매개변수가 제공업체 설정과 일치하는지 확인하세요. 프록시 모드와 라우팅은 그대로 둔 채 정상 작동이 확인된 다른 노드와 비교해 보세요. 한 노드만 실패한다면 해당 노드의 설정이나 서버 상태 문제일 가능성이 높습니다. 모든 노드가 실패하면 시스템 시간, DNS, 네트워크 환경, 보안 소프트웨어 로그를 확인하세요. 테스트 시간 초과만으로는 원인을 찾기 어려우므로 실제 접속 결과와 연결 로그를 함께 살펴봐야 합니다.

연결됨 표시는 보통 로컬 서비스나 가상 인터페이스가 시작되었다는 뜻일 뿐, 원격 핸드셰이크와 대상 사이트 접속까지 성공했다는 의미는 아닙니다. 먼저 일반적으로 접속 가능한 페이지를 열어 기본 네트워크를 확인한 다음 브라우저 트래픽이 클라이언트에 들어오는지 살펴보세요. 로그에 새 연결이 없다면 시스템 프록시, 앱별 설정, TUN의 트래픽 가로채기를 먼저 확인해야 합니다. 연결은 보이지만 핸드셰이크 오류가 발생한다면 SNI, 인증서, 프로토콜 매개변수를 확인하세요. 도메인 조회 오류라면 DNS 경로를 점검합니다. 마지막으로 라우팅이 대상을 잘못된 아웃바운드로 보내는지 확인하세요. 노드, DNS, 규칙을 한꺼번에 바꾸지 말고 한 항목씩 조정하며 다시 테스트해야 원인을 찾기 쉽습니다.

먼저 모든 접속에 문제가 있는지, 일부 도메인만 실패하는지 확인하세요. TUN을 사용하면 DNS 요청도 가로채질 수 있고, 원격 DNS에 접속하려면 프록시 아웃바운드가 필요할 수 있습니다. 시작할 수 없는 상호 의존성이 생기지 않았는지 확인하고 현재 DNS 설정을 선택한 코어가 지원하는지도 살펴보세요. 복구하려면 클라이언트에서 TUN과 시스템 프록시를 정상적으로 끈 뒤 프로그램을 종료하고, 시스템에 로컬 프록시 설정이나 잘못된 DNS 설정이 남아 있는지 확인하세요. 필요한 경우 네트워크 어댑터를 원래의 자동 설정으로 되돌리고 네트워크에 다시 연결합니다. 공용 DNS 주소를 그대로 복사해 모든 설정을 바꾸지 말고, 먼저 기존 설정을 기록해 되돌릴 수 있게 해 두세요.