V2Ray 자주 묻는 질문

먼저 설정 화면과 실제 연결을 처리하는 프로그램을 구분하세요. V2Ray는 보통 Project V 생태계의 프록시 도구와 관련 기술을 가리킵니다. V2Fly와 Xray는 지원 기능을 각각 확인해야 하는 코어 프로젝트입니다. v2rayN, v2rayNG, v2flyNG는 구독 관리, 노드 선택, 설정 생성을 담당하는 GUI 클라이언트이며, 실제 프로토콜 처리는 코어가 수행합니다. 따라서 화면에서 노드를 가져올 수 있다고 해서 현재 코어에서 해당 노드를 사용할 수 있는 것은 아닙니다. 문제를 진단할 때 클라이언트와 코어 이름, 로그 오류를 함께 기록하세요. 특히 프로토콜, 전송 방식, 설정 항목이 서로 맞는지 확인하고, 화면에 표시된 프로토콜 이름만으로 호환 여부를 판단하지 마세요.

데스크톱에서는 Windows, macOS, Linux를 지원하는 v2rayN을 먼저 살펴보세요. Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 고려하고, V2Fly 코어 설정이 필요하다면 v2flyNG를 확인하세요. 선택 기준은 이름이 비슷한지가 아니라 운영체제, 프로세서 아키텍처, 노드에 필요한 프로토콜과 전송 기능입니다. 특히 VLESS, REALITY 설정은 선택한 클라이언트에 포함된 코어가 실제로 지원하는지 확인해야 합니다. 클라이언트를 바꾸기 전에 현재 설정을 기록하고, 사용 가능한 것으로 확인된 노드 하나를 가져와 비교하세요. 여러 클라이언트를 동시에 실행해 시스템 프록시나 가상 네트워크 인터페이스를 제어하면 테스트 결과가 뒤섞일 수 있습니다.

네. 클라이언트는 설정과 연결을 관리하는 도구이며, 설치만으로 원격 서버가 자동 제공되지는 않습니다. 구독 주소를 사용하면 노드 목록을 가져올 수 있고, 개별 노드 링크에는 보통 프로토콜, 서버, 포트, 인증 정보가 포함됩니다. 두 정보 모두 사용 권한이 있는 서비스나 직접 구성한 설정에서 받아야 합니다. 클라이언트가 서버 계정이나 트래픽 제공을 대신하지는 않습니다. 가져온 뒤에는 노드를 선택해 연결하고, 용도에 맞게 시스템 프록시나 다른 트래픽 처리 방식을 설정해야 합니다. 구독 목록이 비어 있다면 먼저 구독 내용과 계정 상태를 확인하세요. 목록이 비어 있다고 설치 실패인 것은 아닙니다. 구독 주소와 노드 설정에 접속 정보가 포함될 수 있으므로 스크린샷이나 로그를 공유하기 전에 가리세요.

시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 요청을 클라이언트로 보내도록 안내합니다. 라우팅 분기는 트래픽이 코어에 들어온 뒤 규칙에 따라 직접 연결, 프록시 연결, 차단 중 하나를 결정합니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 많은 트래픽을 처리합니다. 세 기능은 서로 다른 단계에서 작동하므로 서로 대체할 수 없습니다. 앱이 시스템 프록시를 무시한다면 요청 자체가 클라이언트에 들어오지 않을 수 있어 라우팅 규칙을 바꿔도 해결되지 않습니다. TUN은 더 넓은 범위의 트래픽을 처리하지만 권한, DNS, 게이트웨이, 다른 네트워크 소프트웨어와의 호환성도 고려해야 합니다. 처음 설정할 때는 시스템 프록시로 노드 하나를 테스트한 뒤, 앱별 필요에 따라 TUN을 검토하고 여러 설정을 한꺼번에 바꾸지 마세요.

복사한 항목이 구독 주소인지 개별 노드 공유 링크인지 먼저 확인하세요. v2rayN에서는 보통 구독 그룹 설정에서 주소를 추가하고 저장한 뒤 구독 업데이트를 실행해야 합니다. Android 클라이언트도 구독 메뉴에서 주소를 추가하고 새로고침해야 하며, 웹페이지 주소를 개별 노드로 가져오면 안 됩니다. 주소에 공백이나 줄바꿈이 들어갔는지, 쿼리 매개변수가 빠졌는지, 로그인이 필요한 웹페이지를 가리키는지 확인하세요. 그래도 노드가 나타나지 않으면 업데이트 로그에서 요청 실패, 응답 형식 인식 실패, 필터링 후 목록이 비어 있는 경우를 구분해 살펴보세요. 인증 정보가 포함된 주소를 공개 변환 도구에 붙여넣지 마세요. 형식을 변환해야 한다면 출처와 대상 형식의 호환성을 확인하고 원본 구독도 보관해 비교하세요.

최신 Android 휴대전화라면 arm64를 우선 고려할 수 있지만, 구매 연도가 아니라 기기가 지원하는 앱 아키텍처를 기준으로 선택하세요. 일부 기기는 프로세서가 64비트를 지원해도 운영체제에서 32비트 앱 환경만 제공하므로 arm64 패키지가 설치되지 않을 수 있습니다. 기기 정보에서 지원 ABI를 확인하거나 아키텍처를 모를 때는 universal을 선택하세요. universal 패키지는 여러 아키텍처를 포함하는 대신 파일 크기가 더 큰 편입니다. 설치 오류가 발생하면 아키텍처만 의심하지 말고 기존 앱의 서명, 운영체제 버전, 저장 공간도 확인하세요. 기존 클라이언트를 삭제하면 설정이 사라질 수 있으므로 먼저 백업하고 백업 파일의 저장 위치를 확인하세요.

시스템 정보를 확인해 아키텍처를 파악한 뒤 패키지 형식을 선택하세요. Windows에서는 시스템이 x64 패키지 요구 사항을 충족하는지 확인합니다. macOS에서는 '이 Mac에 관하여'에서 Apple Silicon과 Intel을 구분할 수 있습니다. Linux는 x64 또는 arm64뿐 아니라 배포판에서 사용하는 deb, rpm 등의 패키지 형식도 확인해야 합니다. 확장자가 같아도 아키텍처가 같다는 뜻은 아니며, 패키지가 열려도 실행 환경이 요구 사항을 충족한다는 보장은 없습니다. 프로그램이 시작되지 않으면 운영체제 안내와 클라이언트 시작 로그를 먼저 확인하고, 실행에 필요한 구성 요소를 점검하세요. 다른 기기의 프로그램 폴더를 그대로 복사하지 마세요. 다른 플랫폼으로 옮길 때는 구독과 필요한 설정을 우선 이전하고, 새 기기에서 경로, 네트워크 인터페이스, 권한 설정을 다시 확인하세요.

먼저 일반 연결이 작동하는지 확인한 뒤 TUN 권한을 점검하세요. Windows에서는 클라이언트 안내에 따라 관리자 권한으로 실행하거나 관련 서비스를 설정해야 할 수 있습니다. macOS와 Linux에서도 네트워크 인터페이스 생성이나 라우팅 변경에 권한이 필요할 수 있으며, 구체적인 절차는 클라이언트 버전에 따라 다릅니다. Android 클라이언트가 처음으로 트래픽을 처리할 때는 시스템 VPN 권한을 요청하므로 시스템 대화상자에서 승인해야 합니다. 권한 부여에 실패하면 가상 네트워크 인터페이스를 사용하는 다른 앱을 먼저 종료하고, 로그에서 인터페이스 생성이나 라우팅 오류를 확인하세요. 오류 하나를 피하려고 시스템 보호 기능을 계속 꺼 두지 마세요. 테스트가 끝나면 TUN을 끌 때 기존 네트워크가 복구되는지 확인한 뒤 상시 사용할지 결정하세요.

각 테스트가 측정하는 구간이 다르기 때문입니다. Tcping은 주로 서버 포트까지 TCP 연결을 맺는 데 걸리는 시간을 확인하며, 인증이나 프록시를 통한 외부 연결, 대상 웹사이트 접속 성공까지 보장하지 않습니다. 실제 연결 테스트는 보통 프록시를 통해 지정한 주소에 요청을 보내므로 더 많은 프로토콜과 네트워크 구간을 확인합니다. 다운로드 속도 측정은 지속적인 전송 능력을 살펴보며 테스트 파일, 동시 연결 수, 서버 속도 제한의 영향을 받습니다. 따라서 연결 지연이 짧아도 다운로드가 빠르다는 보장은 없고, 실제 연결 테스트 실패도 테스트 대상에 접근할 수 없어서일 수 있습니다. 노드를 비교할 때는 테스트 대상과 시간을 동일하게 맞추고, 실제 연결이 되는지 먼저 확인한 다음 실제 사용하는 앱에서의 체감 성능을 기준으로 선택하세요. 다운로드 테스트는 트래픽을 사용하므로 사용량 배수가 적용되는 노드에서는 횟수를 줄이세요.

구독마다 별도의 그룹을 만들고 출처와 용도를 알아보기 쉽게 표시하세요. 먼저 그룹 하나만 업데이트해 노드 수와 항목이 정상인지 확인한 뒤 자동 업데이트를 설정하세요. 필터 조건은 한 번에 모두 추가하지 말고 하나씩 적용해 모든 노드가 숨겨지는 일을 피하세요. 업데이트 과정에서 노드 기록이 바뀔 수 있고 서버가 이름, 주소, 정렬 순서를 조정할 수도 있어 클라이언트가 기존 선택을 계속 유지하지 못할 수 있습니다. 업데이트 후에는 목록 새로고침 여부만 확인하지 말고 현재 노드, 라우팅 모드, 재연결 여부도 살펴보세요. 직접 추가한 노드는 자동 업데이트 항목과 섞이지 않도록 별도 그룹에 두는 편이 좋습니다. 이전 그룹을 정리하기 전에 필요한 설정을 백업하고, 백업에 포함된 구독 인증 정보도 안전하게 보관하세요.

먼저 트래픽이 실제로 클라이언트에 들어오는지 확인한 뒤 변경한 라우팅 설정을 선택했는지 살펴보세요. 규칙은 보통 위에서 아래 순서로 적용되므로 앞에 범위가 넓은 규칙이 있으면 뒤에 있는 세부 규칙이 일치하지 않을 수 있습니다. 도메인 규칙, IP 규칙, 아웃바운드 태그가 올바른지, 참조하는 geo 리소스가 있는지 확인하세요. 도메인 요청과 이미 IP로 확인된 요청도 구분해야 합니다. 저장한 뒤에는 클라이언트 안내에 따라 코어를 재시작하거나 다시 연결해 기존 연결이 이전 경로를 계속 사용하지 않도록 하세요. 테스트할 때는 명확한 대상 하나에만 접속하고 로그에서 대상 주소와 선택된 아웃바운드를 확인하세요. 모든 문제를 규칙 순서 탓으로 돌리지 마세요. 앱 자체의 프록시 설정과 DNS 동작도 결과에 영향을 줍니다.

먼저 문제가 도메인 이름 확인에서 발생하는지 프록시 연결에서 발생하는지 구분하세요. 처음부터 모든 DNS 설정을 바꾸는 것은 권장하지 않습니다. 직접 연결을 통한 조회와 프록시를 통한 조회는 접근 경로가 다릅니다. 원격 DNS 주소에 프록시를 통해 접속해야 한다면 클라이언트가 아웃바운드 경로를 올바르게 설정하는지 확인하세요. 그렇지 않으면 프록시 연결에 필요한 DNS 조회를 다시 해당 프록시에 의존하는 순환이 생길 수 있습니다. 설정을 바꾸기 전에 현재 값을 기록하고, 한 항목만 조정한 뒤 알고 있는 도메인으로 테스트하세요. 앱 자체의 암호화 DNS 사용 여부도 확인해야 합니다. 브라우저, 운영체제, 클라이언트 캐시 때문에 결과가 잠시 다를 수도 있습니다. 공개 DNS 주소는 DNS 서비스의 접속 지점일 뿐 모든 네트워크에서 접근할 수 있는 것은 아닙니다. DNS를 바꿔도 잘못된 노드 인증 정보나 서버 포트 문제는 해결되지 않습니다.

먼저 주소가 완전한지, 계정이 유효한지 확인한 뒤 업데이트 로그에서 요청 결과를 살펴보세요. 연결 시간 초과라면 구독 도메인 확인과 접속 경로부터 점검합니다. HTTP 401 또는 403 오류는 보통 인증 권한이나 서버 정책을 확인해야 합니다. 요청에 성공했지만 내용을 읽지 못한다면 응답이 노드 구독이 아니라 로그인 페이지나 오류 페이지인지 확인하세요. 현재 노드를 사용할 수 없으면 프록시를 통한 업데이트도 실패할 수 있습니다. 클라이언트에 해당 옵션이 있다면 직접 업데이트와 프록시를 통한 업데이트를 비교해 보세요. 접근 제한이 걸리지 않도록 새로고침을 반복하지 마세요. 필요하면 구독 제공자에게 오류 상태를 전달해 문의하되, 로그를 공유할 때 주소에 포함된 인증 정보는 삭제하세요. 그룹을 삭제한 뒤 다시 만드는 것은 보통 첫 번째 조치가 아니며, 필터와 업데이트 설정을 잃을 수 있습니다.

같은 네트워크에서 사용 가능한 것으로 확인된 노드와 비교한 뒤 현재 노드로 실제 연결 테스트를 해보세요. 한 노드만 실패한다면 서버 주소, 포트, 인증 정보, 전송 설정, 서버 상태를 중점적으로 확인합니다. 여러 노드가 동시에 실패한다면 기기의 네트워크, 시스템 시간, 방화벽, 다른 프록시 소프트웨어를 살펴보세요. 핸드셰이크 테스트 성공은 포트에 접근할 수 있다는 뜻일 뿐, 인증이나 프로토콜 오류까지 배제하지는 않습니다. 로그에 코어가 시작되지 않았다고 표시되면 노드를 계속 바꾸기보다 포트 충돌이나 설정 오류를 먼저 해결하세요. 테스트 중에는 중복된 트래픽 처리 방식을 잠시 끄고, 한 번에 한 항목만 바꾸며 결과를 기록하세요. 한 번 시간 초과됐다고 구독 전체를 삭제하지 말고, 테스트용 웹사이트 하나에 접속하지 못했다고 모든 사이트가 실패한다고 단정하지 마세요.

클라이언트가 실행된 것과 대상 요청이 성공한 것은 별개입니다. 먼저 브라우저 트래픽이 클라이언트로 들어오는지 확인하세요. 시스템 프록시 상태와 앱 자체 프록시 설정, 현재 선택한 노드를 살펴봅니다. 이어서 도메인 확인, 라우팅 아웃바운드, 로그에 표시된 연결 오류를 확인하세요. 일부 웹사이트만 실패한다면 전체 설정을 초기화하기보다 해당 사이트의 규칙과 서비스 상태를 점검하세요. TUN을 사용 중이라면 DNS 처리, 인터페이스 라우팅, 다른 가상 네트워크 소프트웨어와의 충돌도 확인해야 합니다. TUN을 끄고 시스템 프록시로 일반 웹페이지 하나를 테스트하면 원인을 좁힐 수 있습니다. 클라이언트를 종료한 뒤에도 네트워크 문제가 계속되면 시스템 프록시가 남아 있는지, 기존 DNS와 게이트웨이가 복구됐는지 확인하고 다시 테스트하세요.

운영체제에 설정된 프록시 주소와 포트를 확인해 실행 중인 클라이언트의 수신 포트와 일치하는지 살펴보세요. 클라이언트 포트를 변경했거나 다른 프로그램이 설정을 덮어쓴 경우, 또는 프로그램이 비정상 종료된 경우 잘못된 시스템 프록시 설정이 남을 수 있습니다. 정상적으로 종료한 뒤에도 닫힌 로컬 포트를 가리킨다면 클라이언트나 시스템 설정에서 프록시를 해제하고 직접 연결을 테스트하세요. 시스템 프록시를 사용하지 않는 앱은 앱 내부에서 프록시를 지정하거나 TUN 사용을 검토해야 합니다. HTTP 포트와 SOCKS 포트를 임의로 바꿔 쓰지 마세요. 문제를 확인할 때는 클라이언트 하나만 실행해 설정이 서로 덮어쓰이지 않게 하세요. 로컬 수신 포트를 아무렇게나 LAN에 공개하지 마세요. 외부 기기 접속 허용은 인증과 접근 범위를 따로 고려해야 하는 별도 설정입니다.