V2Ray 자주 묻는 질문

V2Ray가 속한 Project V 생태계에는 프록시 통신에 필요한 여러 구성 요소가 있습니다. V2Fly와 Xray는 프로토콜, 연결, 라우팅, DNS 등을 처리하는 관련 코어 프로젝트입니다. v2rayN, v2rayNG, v2flyNG는 서버 정보를 가져오고 구독을 관리하며 설정을 조정하는 그래픽 인터페이스를 제공합니다. 인터페이스가 실행된다고 코어가 정상 작동한다는 뜻은 아니며, 코어가 실행 중이어도 원격 서버를 사용할 수 있다는 보장은 없습니다. 문제가 생기면 화면의 연결 상태만 보지 말고 클라이언트 설정, 코어 시작 로그, 서버 매개변수를 각각 확인하세요.

Windows, macOS, Linux 데스크톱에서는 v2rayN을 먼저 살펴보세요. Android에서는 보통 Xray 코어를 사용하는 v2rayNG를 고려하고, V2Fly 코어 환경이 필요하다면 v2flyNG를 확인할 수 있습니다. 선택 전 구독에서 사용하는 프로토콜과 전송 방식, 필요한 코어 기능을 확인하세요. 인터페이스가 비슷한지만 비교해서는 안 됩니다. 클라이언트와 버전에 따라 가져오기 형식, 라우팅 프리셋, 설정 메뉴가 다를 수 있으므로 이전할 때는 기존에 작동하는 설정을 보존하고 항목 하나로 먼저 검증하세요. 클라이언트가 서버를 제공하지는 않으므로 유효한 노드 정보나 구독 주소가 필요합니다.

arm64 패키지는 ARM 64비트 앱을 지원하는 기기용이며, universal 패키지는 일반적으로 여러 프로세서 아키텍처용 구성 요소를 포함해 파일 크기가 더 큽니다. 최신 Android 휴대전화 대부분은 arm64를 우선 확인해도 되지만, 출시 시기만으로 아키텍처를 판단할 수는 없습니다. 프로세서는 64비트를 지원해도 시스템이 32비트 앱만 지원하는 기기도 있습니다. 시스템 기기 정보에서 아키텍처를 확인하고, 확인하기 어렵다면 범용 패키지를 고려하되 해당 클라이언트의 최신 릴리스 안내를 따르세요. 설치가 실패하면 네트워크 탓으로 돌리기 전에 시스템 버전, 저장 공간, 기존 앱과의 서명 충돌도 확인하세요.

클라이언트에서 프로토콜 이름만 바꾼다고 전환이 완료되는 것은 아닙니다. VLESS, VMess, Trojan은 서로 다른 프록시 프로토콜이고, REALITY는 관련 연결 보안 설정입니다. 보통 서버 측 전송 및 핸드셰이크 매개변수도 함께 맞춰야 합니다. 서버 주소와 포트, 사용자 식별자 또는 비밀번호, 필요한 경우 서버 이름·공개 키·짧은 식별자까지 서버 설정과 일치해야 합니다. 구독에 전체 매개변수가 포함되어 있다면 원래 값을 유지하고, 직접 변경하기 전에는 기존 설정을 저장하세요. 프로토콜은 서버 지원 여부와 현재 코어의 호환성을 기준으로 선택해야 하며, 이름만 보고 속도나 사용 가능 여부를 판단할 수 없습니다.

먼저 구독 주소와 개별 노드 공유 링크를 구분하세요. 구독 주소는 보통 구독 그룹에 추가하고, 개별 노드 링크는 클립보드나 공유 링크 가져오기 메뉴를 이용합니다. 복사할 때 앞뒤 공백을 없애고, 메신저에서 링크가 잘리지 않았는지 또는 웹페이지 제목까지 함께 복사하지 않았는지 확인하세요. 구독 그룹을 저장한 뒤에는 업데이트를 실행하고 필터가 적용되어 있는지도 확인해야 합니다. 로그인 페이지나 오류 페이지, 클라이언트가 지원하지 않는 설정 형식이 반환되면 주소가 열려도 유효한 항목이 생성되지 않습니다. 업데이트 오류 메시지를 기록해 제공업체에 지원 형식을 문의하세요. 구독 주소에는 접근 인증 정보가 포함될 수 있으므로 공개적으로 붙여넣지 마세요.

구독 다운로드와 기존 노드 연결은 서로 다른 요청 경로를 사용하므로 한쪽이 성공했다고 다른 쪽도 정상인 것은 아닙니다. 먼저 오류가 도메인 이름 확인 실패, 연결 시간 초과, 인증서 오류, 구독 인증 만료 중 무엇인지 확인한 뒤 기기 시간과 구독 유효 기간을 살펴보세요. 클라이언트에서 프록시를 통한 업데이트를 지원한다면 기존 노드가 실제로 작동할 때 시도할 수 있습니다. 반대로 프록시 경로에 문제가 있다면 직접 연결로 업데이트할 수 있는지도 확인하세요. 점검 중에는 기존 구독 그룹과 작동하는 항목을 보존하고, 먼저 모두 지운 뒤 업데이트하지 마세요. 요청 횟수 제한 오류가 표시되면 기다렸다가 다시 시도하고, 연속으로 클릭하거나 같은 그룹을 반복해서 만들지 마세요.

TUN 모드는 가상 네트워크 인터페이스를 만들고 관련 라우팅을 조정하므로 일반 로컬 프록시보다 높은 권한이 필요합니다. Windows에서는 클라이언트 안내에 따라 관리자 권한으로 실행하거나 해당 서비스를 설치하세요. macOS와 Linux에서는 현재 버전의 그래픽 안내에 따라 권한을 부여하고, 설정 폴더 전체의 권한을 임의로 바꾸지 마세요. Android에서는 시스템 VPN 연결 권한을 확인하고, 같은 종류의 연결을 사용하는 다른 앱이 있는지도 살펴보세요. 권한을 부여한 뒤에도 실패하면 로그에서 인터페이스, 드라이버, 라우팅 오류를 확인하세요. 먼저 일반 프록시로 노드가 작동하는지 확인한 다음 TUN을 점검하세요. 문제 해결을 위해 방화벽이나 다른 시스템 보호 기능을 장기간 끄지 마세요.

먼저 클라이언트 코어가 실행 중인지 확인한 다음 시스템 프록시가 클라이언트의 현재 로컬 수신 주소와 포트를 가리키는지 살펴보세요. HTTP 포트와 SOCKS 포트가 다를 수 있습니다. 브라우저에 별도의 프록시 확장 프로그램이나 네트워크 설정이 있으면 시스템 설정을 덮어쓸 수 있으며, 시스템 프록시 설정을 따르지 않는 앱도 있습니다. 프록시 관리 방법을 하나만 남기고 브라우저를 다시 시작해 확인한 뒤 시스템 프록시 예외 목록도 살펴보세요. 로컬 문제를 해결하려고 수신 주소를 모든 네트워크 인터페이스로 변경하지 마세요. 앱이 시스템 프록시를 사용하지 않는다면 앱의 수동 프록시 설정을 확인하거나, 트래픽이 처리되는 범위를 이해한 뒤 TUN을 사용하세요.

시스템 프록시는 어떤 앱의 요청을 클라이언트로 보낼지 결정하고, 라우팅 모드는 코어에 들어온 요청이 어떤 아웃바운드를 사용할지 결정합니다. TUN은 트래픽을 가로채는 방식을 바꾸므로 서로 다른 계층의 설정입니다. 클라이언트의 전역 모드는 보통 이미 가로챈 트래픽이 프록시 아웃바운드를 우선 사용하게 한다는 뜻이지, 모든 프로그램을 자동으로 제어한다는 뜻은 아닙니다. 규칙 기반 분기는 도메인, 주소 등의 조건에 따라 프록시, 직접 연결, 차단을 선택합니다. TUN을 사용해도 라우팅 규칙은 계속 적용될 수 있습니다. 문제를 확인할 때는 먼저 요청이 코어에 들어왔는지 확인한 다음 규칙 매칭 결과를 살펴보세요. 트래픽 가로채기 문제를 노드 문제로 오인하지 않도록 주의하세요.

테스트 결과는 특정 시점에 특정 방식으로 측정한 결과만 보여 줍니다. 포트 탐지가 성공해도 원격 포트에 도달할 수 있다는 뜻일 뿐, 프로토콜 핸드셰이크와 도메인 이름 확인, 대상 웹사이트 요청까지 성공한다고 보장하지 않습니다. 실제 요청 테스트도 사용한 테스트 주소에만 해당합니다. 노드를 선택할 때는 먼저 실제 사이트에 접속되는지 확인하고, 일정 시간 사용하며 안정성을 살펴보세요. 구독 제공업체가 안내한 트래픽 배수와 지역 정보도 확인해야 합니다. 지연 시간이 낮다고 전송 속도가 빠른 것은 아닙니다. 비교할 때는 테스트 방식과 네트워크 환경을 고정하고 한 번에 하나씩 바꾸세요. DNS, 라우팅, 노드를 동시에 변경하면 어떤 설정이 효과를 냈는지 알기 어렵습니다.

출처별로 그룹을 나누고 용도를 알아보기 쉬운 이름을 사용하세요. 그룹마다 업데이트 주소와 필터 조건도 확인해야 합니다. 자동 업데이트 전에 새 구독을 정상적으로 파싱할 수 있는지 검증하고, 보존해야 하는 수동 항목은 별도 위치에 두어 구독 갱신 때 덮어쓰지 않도록 하세요. 이름이 같다고 같은 서버라는 뜻은 아니므로 주소, 포트, 프로토콜, 그룹 출처도 비교해야 합니다. 업데이트 후 목록이 줄었다면 모든 그룹을 바로 삭제하지 말고 필터 조건과 제공업체가 반환한 내용을 먼저 확인하세요. 설정을 내보내거나 백업할 때 구독 인증 정보, 사용자 식별자, 비밀번호가 포함될 수 있으므로 안전한 위치에 보관하세요.

변경 전에 현재 프리셋과 작동하는 노드를 기록하고, 한 번에 변수 하나만 조정하세요. 클라이언트 안내에 따라 설정을 저장하고 코어를 다시 불러오거나 재시작해야 합니다. 라우팅 규칙은 적용 순서가 중요하므로 더 넓은 범위의 규칙이 대상 규칙보다 먼저 적용되는지 확인하세요. DNS는 브라우저의 별도 이름 확인, 시스템 캐시, 코어 캐시의 영향을 받을 수 있습니다. 같은 대상을 반복해서 테스트하고 로그에서 실제 아웃바운드나 이름 확인 오류를 확인하세요. 설정 화면의 스위치만 보고 판단해서는 안 됩니다. 검증이 끝나면 임시 로그 수준을 원래대로 되돌리세요. 로그를 공유해야 한다면 주소, 인증 정보, 개인 접속 기록을 먼저 삭제하고 문제와 관련된 최소한의 내용만 전달하세요.

먼저 프록시를 끄고 기본 네트워크로 정상 접속할 수 있는지 확인한 뒤 현재 노드의 주소, 포트, 프로토콜, 구독 상태를 점검하세요. 노드 하나만 실패하면 같은 구독의 다른 항목과 비교해 보세요. 모두 실패한다면 코어가 실행 중인지, 기기 시간이 정확한지, 로컬 방화벽이 클라이언트의 네트워크 연결을 차단하지 않는지 먼저 확인하세요. 로그에 표시되는 연결 시간 초과와 인증 실패는 의미가 다릅니다. 인증 실패라면 인증 정보와 프로토콜 매개변수를 확인하는 것이 우선입니다. 필요하면 이미 작동하는 것으로 확인된 다른 네트워크에서 비교하되, 소프트웨어 재설치와 설정 재작성을 동시에 하지 마세요. 노드 서비스 장애나 구독 만료는 서비스 제공업체에 문의해야 합니다.

화면에 연결됨이라고 표시되어도 코어가 실행 중이라는 뜻에 그칠 수 있습니다. 먼저 브라우저 요청이 실제로 클라이언트에 들어오는지 확인하세요. 시스템 프록시 모드, 로컬 수신 포트, 브라우저의 별도 프록시 설정을 점검한 뒤 로그에 이름 확인 실패, 핸드셰이크 실패, 잘못된 아웃바운드 라우팅이 있는지 살펴보세요. 같은 웹사이트에서 작동이 확인된 다른 노드로 바꿔 노드 문제인지 로컬 설정 문제인지 구분하세요. 이어서 DNS 설정과 분기 규칙을 확인하고, 필요하면 클라이언트 기본 프리셋으로 잠시 되돌려 비교하세요. 특정 웹사이트만 문제가 있다면 사이트 자체의 상태나 접근 제한도 고려해야 합니다. 프록시 연결 전체가 실패했다고 바로 단정하지 마세요.

먼저 실패한 대상이 서버 도메인인지 웹사이트 도메인인지 구분하세요. 서버 도메인 확인에 실패하면 노드 연결이 막히고, 웹사이트 도메인 확인에 실패하면 노드는 연결되지만 페이지가 열리지 않을 수 있습니다. 입력한 DNS의 프로토콜과 주소, 연결 경로를 확인하세요. 암호화 DNS를 사용한다면 DNS 서버 자체의 도메인을 처음에 어떻게 확인하는지도 살펴봐야 합니다. 아직 연결되지 않은 프록시를 통해 모든 이름 확인을 처리하도록 설정하면 순환 의존성이 생길 수 있습니다. 브라우저의 별도 DNS와 시스템 이름 확인은 서로 다른 경로를 사용할 수 있으므로 각각 확인하세요. 한 번에 설정 하나만 바꾸고 코어를 다시 불러온 뒤 테스트하세요. 공용 DNS 주소를 사용한다고 모든 네트워크 환경의 이름 확인 문제가 해결되는 것은 아닙니다.

클라이언트를 종료한 뒤에는 시스템 프록시가 중지된 로컬 포트를 계속 가리키는지 먼저 확인하세요. 필요하면 시스템 네트워크 설정에서 자동 설정으로 되돌리거나 수동 프록시를 끄고, 다른 프록시 도구의 설정이 남아 있는지도 살펴보세요. TUN을 사용했다면 클라이언트에서 정상적으로 종료한 다음 가상 인터페이스와 라우팅이 복원됐는지 확인하세요. 익숙하지 않은 시스템 인터페이스를 바로 삭제하지 마세요. 무선 네트워크를 바꾸거나 절전 모드에서 복귀한 뒤 문제가 생기면 기본 네트워크에 다시 연결하고 코어를 재시작해 노드를 확인하세요. 문제가 계속되면 오류 로그를 저장한 뒤 최근 변경 사항을 하나씩 되돌리세요. 다른 업무용 연결까지 영향을 받을 수 있으므로 네트워크 설정 전체를 바로 초기화하지 마세요.