V2Ray 자주 묻는 질문

V2Ray는 Project V 프록시 도구 생태계에 속합니다. V2Fly는 V2Ray 코어 개발을 이어가며, Xray는 별도의 코어 분기입니다. 코어는 프로토콜 연결, 라우팅, DNS 등을 처리하고 그래픽 클라이언트는 노드를 저장하고 구독을 관리하며 설정 파일을 생성해 코어를 실행합니다. 문제를 해결할 때는 이 두 계층을 구분해야 합니다. 인터페이스가 열린다고 코어가 실행 중인 것은 아니며, 코어가 실행 중이어도 시스템 트래픽이 프록시로 전달된다는 뜻은 아닙니다. 먼저 클라이언트 로그에서 코어가 정상적으로 시작됐는지 확인한 다음 프록시 진입 경로를 점검하세요.

Windows, macOS, Linux 데스크톱에서는 v2rayN을 선택한 뒤 프로세서 아키텍처와 설치 파일 형식에 맞는 버전을 고르세요. Android에서는 보통 Xray 코어를 사용하는 v2rayNG를 먼저 고려하고, V2Fly 코어가 필요하다면 v2flyNG를 선택할 수 있습니다. 클라이언트 이름만으로 설정 호환성을 판단하지 말고 서버에서 사용하는 프로토콜, 전송 방식, 보안 항목도 확인하세요. 특정 항목을 지원하지 않는다면 실제 실행 중인 코어와 버전을 먼저 확인한 뒤 클라이언트를 바꾸세요.

클라이언트는 설정 및 연결을 위한 도구이며, 설치만으로 서버 주소나 접속 정보가 생성되지는 않습니다. 노드 목록을 만들려면 정당하게 발급받은 구독 주소나 공유 링크를 가져오거나 연결 정보를 직접 입력해야 합니다. 구독에는 보통 여러 노드가 포함되고, 공유 링크 하나에는 대개 노드 하나의 정보만 담겨 있어 가져오기 메뉴가 서로 다를 수 있습니다. 가져오기 전에 자료 유형을 확인하고, 완료 후 노드 이름과 주소, 포트가 표시되는지 살펴보세요. 계정 관리 웹페이지 주소를 구독 주소로 붙여 넣으면 안 됩니다.

VMess, VLESS, Trojan은 프록시 프로토콜 이름이며, REALITY는 이들과 나란히 놓이는 별도의 노드 프로토콜이 아니라 보안 메커니즘입니다. 연결에는 TCP, WebSocket, gRPC 등의 전송 설정도 포함될 수 있습니다. 직접 설정할 때는 프로토콜, 주소, 포트, 사용자 식별자, 전송 및 보안 매개변수를 각각 확인하세요. 프로토콜 이름만 같다고 설정이 일치하는 것은 아닙니다. 빠진 항목은 설정 제공자에게 확인하고, 특히 서버 이름이나 공개 키, 짧은 ID를 임의로 추측하지 마세요.

휴대전화 출시 연도만 보지 말고 기기가 지원하는 앱 아키텍처를 먼저 확인하세요. 64비트 ARM 앱을 설치할 수 있는 기기라면 보통 arm64를 선택합니다. 아키텍처를 확인하기 어렵다면 여러 아키텍처를 포함하는 universal 패키지를 사용할 수 있지만 파일 크기가 더 큰 편입니다. 파싱 오류가 나거나 설치할 수 없다면 파일 다운로드가 완료됐는지, 시스템 호환 조건을 충족하는지, 서명이 다른 이전 버전이 설치되어 있는지 확인하세요. 이전 버전을 삭제하기 전에는 설정을 내보내 노드와 그룹 기록이 앱 데이터와 함께 삭제되지 않도록 하세요.

주소 저장, 콘텐츠 가져오기, 노드 파싱 중 어느 단계에서 실패했는지 먼저 구분하세요. 주소 저장에 실패하면 앞뒤 공백이나 줄바꿈, 복사 과정에서 잘린 부분이 없는지 확인합니다. 콘텐츠를 가져오지 못하면 로그에서 네트워크 오류나 HTTP 오류를 살펴보세요. 콘텐츠는 가져왔지만 노드가 없다면 로그인 페이지나 오류 페이지가 반환됐는지, 클라이언트가 지원하지 않는 형식인지 확인하세요. v2rayN의 구독 그룹 설정에 주소를 저장한 뒤에는 구독 업데이트도 실행해야 합니다. 구독 주소에 접근 토큰이 포함될 수 있으므로 스크린샷이나 문의용 로그를 공유할 때 전체 주소를 가리세요.

시스템 프록시는 시스템 설정을 따르는 앱에 프록시 주소를 제공할 뿐, 모든 네트워크 요청을 자동으로 가로채지는 않습니다. 먼저 클라이언트 코어가 실행 중인지 확인한 뒤 시스템 프록시의 호스트와 포트가 로컬 HTTP 또는 혼합 인바운드 설정과 일치하는지 살펴보세요. 이어서 대상 앱이 자체 프록시를 사용하거나 프록시를 명시적으로 비활성화했는지, 설정을 적용하려면 재시작해야 하는지 확인합니다. 명령줄 도구와 일부 앱은 별도 설정이 필요할 수 있습니다. 시스템 프록시를 따르지 않는 트래픽에는 TUN 모드가 적합한지 검토하세요. 스위치가 켜져 있는지만으로 트래픽 경로를 판단해서는 안 됩니다.

TUN은 대개 가상 네트워크 인터페이스와 시스템 라우팅을 사용하며, 필요한 권한은 플랫폼과 클라이언트 버전, 구현 방식에 따라 다릅니다. 데스크톱에서는 클라이언트의 권한 안내를 읽고 관리자 권한이나 보조 서비스에 필요한 권한을 부여하세요. Android에서는 시스템에 표시되는 VPN 연결 요청을 허용해야 합니다. 다른 VPN이나 네트워크 제어 도구가 같은 리소스를 사용 중인지도 확인하세요. 권한을 부여한 뒤 해당 모드를 다시 시작하고 로그를 확인하세요. 출처를 알 수 없는 드라이버를 반복해서 설치하거나 모든 권한 오류를 노드 문제로 단정하지 마세요.

구독 출처별로 그룹을 나누고, 출처를 알아보기 쉬운 이름을 지정한 뒤 해당 주소를 그룹에 저장하는 것이 좋습니다. 직접 추가한 노드는 따로 보관하고 구독 새로고침으로 덮어쓸 수 있는 목록에 섞지 마세요. 업데이트 전에 작업 대상이 특정 그룹인지 전체 그룹인지 확인하고, 완료 후 노드 수와 현재 선택 항목이 어떻게 바뀌었는지 살펴보세요. 노드 수가 줄어도 반드시 클라이언트 오류인 것은 아니며 구독 콘텐츠가 변경됐을 수 있습니다. 그룹 관리와 필터링은 클라이언트 기능이므로 일반적인 코어 설정 항목으로 취급하지 마세요.

규칙 모드는 도메인, IP, 포트 등의 조건에 따라 아웃바운드를 선택합니다. 전역 프록시는 보통 클라이언트로 들어온 트래픽을 모두 프록시 아웃바운드로 보내는 방식이지만, 적용 범위는 클라이언트마다 다릅니다. 모든 앱 트래픽이 가로채진다는 뜻도 아니고 TUN이 자동으로 활성화된다는 뜻도 아닙니다. 분기 설정을 확인할 때는 대상 요청을 잠시 프록시로 보내 비교한 뒤 규칙 모드로 되돌려 어떤 규칙이 적용되는지 확인하세요. 트래픽이 클라이언트에 들어오는 경로와 들어온 뒤 아웃바운드가 선택되는 과정을 분리해 점검해야 합니다.

먼저 같은 상황을 재현할 수 있도록 요청을 한 번 발생시킨 다음 클라이언트 로그에서 해당 도메인, 대상 주소, 아웃바운드 태그를 찾으세요. routing 규칙은 보통 순서대로 적용되므로 앞쪽의 포괄적인 조건이 요청을 먼저 가로챌 수 있습니다. 규칙의 outboundTag는 outbounds에 지정된 tag와 일치해야 합니다. 요청이 코어에 들어올 때 도메인 정보가 남아 있는지도 확인하세요. IP만 전달된 요청은 도메인 규칙에 일치하지 않을 수 있습니다. 한 번에 규칙 하나만 수정하고 설정을 다시 불러오세요. DNS와 라우팅을 동시에 바꾸면 무엇이 영향을 줬는지 판단하기 어렵습니다.

먼저 컴퓨터 클라이언트에서 LAN 연결 허용을 켜고 프록시 인바운드가 루프백 주소뿐 아니라 외부 연결도 수신하는지 확인하세요. 컴퓨터의 LAN IP와 실제 수신 포트도 기록합니다. 다른 기기의 프록시 설정에 해당 IP와 HTTP 또는 SOCKS 포트를 입력한 뒤, 컴퓨터 방화벽이 신뢰할 수 있는 LAN의 접근을 허용하는지 확인하세요. 두 기기 사이에 통신이 가능해야 하며 게스트 네트워크나 무선 기기 격리 기능이 연결을 차단할 수도 있습니다. 신뢰할 수 있는 네트워크에서만 열고, 가능하면 접속 출발지 주소를 제한하세요. 프록시 포트를 공인 인터넷에 노출하지 마세요.

사용 가능한 설정을 잃지 않도록 기존 노드를 먼저 보존하고 삭제하지 마세요. 구독이 만료됐는지, 주소가 초기화됐는지, 기기의 시간이 정확한지 확인한 뒤 로그를 보고 연결 시간 초과, 인증서 오류, HTTP 상태 오류를 구분하세요. 클라이언트에서 직접 연결 업데이트와 프록시를 통한 업데이트를 모두 지원한다면 사용 가능한 노드가 있을 때 각각 시도할 수 있습니다. 작동하지 않는 노드에 의존해 구독을 업데이트하면 순환 문제가 생길 수 있습니다. 반환된 콘텐츠가 바뀌었다면 구독 제공자가 지원하는 형식을 확인하고, 오류 페이지를 반복해서 노드 목록에 가져오지 마세요.

반드시 그렇지는 않습니다. 테스트 결과는 대상, DNS, 현재 네트워크, 프로토콜 매개변수, 서버 상태의 영향을 모두 받습니다. 먼저 선택한 테스트가 포트 연결 확인인지 실제 프록시 요청인지 구분하세요. 두 결과는 같은 의미가 아닙니다. 주소와 포트, 시스템 시간, 서버에서 요구하는 전송 및 보안 항목을 확인하고 실패 시 로그도 살펴보세요. 정상 작동이 확인된 다른 노드나 네트워크와 비교해 볼 수 있지만, 여러 노드를 반복해서 한꺼번에 테스트하지는 마세요. 모든 노드가 동시에 실패한다면 로컬 코어가 실행 중인지, 네트워크가 정상인지 먼저 확인하세요.

로컬 진입 경로, 라우팅, 원격 연결, DNS 순서로 점검하세요. 먼저 브라우저 요청이 클라이언트 로그에 나타나는지 확인합니다. 기록이 없다면 시스템 프록시, 앱 자체 프록시 설정, TUN의 트래픽 처리 범위를 살펴보세요. 기록은 있지만 연결에 실패했다면 아웃바운드 태그, 노드 설정, 원격 오류를 확인합니다. 도메인 이름 해석 오류만 발생한다면 DNS 서버에 도달하는 경로를 점검하세요. 보안 프로그램을 모두 끄는 방식으로 해결하려 하지 마세요. 모든 웹사이트에서 문제가 발생하는지, 특정 도메인이나 앱에서만 발생하는지도 확인하세요.

마지막 종료 메시지만 보지 말고 시작 단계에서 처음 나타난 명확한 오류를 확인하세요. JSON 파싱 오류라면 쉼표와 따옴표, 괄호를 점검합니다. 포트 충돌이라면 이전 프로세스나 다른 프로그램이 같은 인바운드 포트를 사용하는지 확인하세요. 알 수 없는 프로토콜이나 필드가 표시되면 설정 내용과 코어의 지원 범위를 대조해야 합니다. 규칙 리소스가 없다는 메시지가 나오면 클라이언트가 관리하는 관련 리소스가 있는지 확인하세요. 클라이언트가 생성한 임시 설정은 다음 시작 때 덮어써질 수 있으므로 인터페이스 설정이나 사용자 지정 설정의 원본을 수정하는 것이 좋습니다.