V2Ray 자주 묻는 질문
설치·구독·연결 문제 해결

V2Ray는 보통 Project V 생태계의 프록시 코어와 관련 프로젝트를 가리킵니다. V2Fly는 이 코어 계열을 이어가며, Xray는 별도의 개발 분기입니다. v2rayN은 설정 가져오기, 서버 선택, 라우팅 설정과 코어 실행을 담당하는 GUI 클라이언트입니다. 어떤 링크를 가져올 수 있다고 해서 현재 코어가 모든 매개변수를 지원한다는 뜻은 아닙니다. 호환성 문제를 확인할 때는 클라이언트 버전과 실제로 실행되는 코어 및 버전을 함께 기록한 뒤, 프로토콜·전송 방식·보안 설정을 대조하세요.

Windows·macOS·Linux 데스크톱에서는 우선 v2rayN을 살펴보고, 운영체제와 프로세서에 맞는 설치 파일을 선택하세요. Android에서는 보통 v2rayNG를 먼저 사용하고, V2Fly 코어 설정이 필요하면 v2flyNG를 고려할 수 있습니다. 클라이언트 이름이 비슷한지가 아니라 기존 설정의 요구 사항을 기준으로 선택해야 합니다. 특히 Xray 전용 기능을 사용하는 설정은 V2Fly와 호환된다고 단정할 수 없습니다. 클라이언트를 바꾸기 전 필요한 설정을 내보내고, 구독 제공자가 안내한 대상 클라이언트와 형식을 확인하세요.

클라이언트는 설정 관리와 연결 기능을 제공할 뿐, 설치만으로 사용할 수 있는 서버가 자동 생성되지는 않습니다. 직접 관리하거나 사용 권한을 받은 공유 링크·설정 파일·구독 주소를 가져와야 합니다. 공유 링크는 보통 개별 설정 하나를 가리키고, 구독 주소는 업데이트 가능한 설정 목록을 가져오는 데 사용됩니다. 자료를 받으면 먼저 종류를 구분한 뒤 알맞은 가져오기 메뉴를 사용하세요. 구독 주소를 서버 주소 입력란에 넣으면 대개 유효한 설정을 가져오지 못합니다. 구독 링크에 접근 자격 증명이 포함될 수 있으므로 공개 스크린샷이나 게시판에 올리지 마세요.

아닙니다. VLESS는 프록시 프로토콜이고 REALITY는 Xray에서 제공하는 전송 보안 방식입니다. 둘은 함께 사용할 수 있으므로 둘 중 하나만 선택하는 관계가 아닙니다. 설정에는 전송 유형, 서버 이름, 공개 키, 지문, shortId 등의 매개변수가 포함될 수 있으며 서버 요구 사항과 일치해야 합니다. 프로토콜 드롭다운만 VLESS로 바꾸고 변환이 끝났다고 생각하거나, 일반 TLS 설정을 임의로 REALITY로 바꾸지 마세요. 전체 공유 링크와 서버 안내를 기준으로 유형을 선택하고, 코어별 차이는 프로토콜 문서를 확인하세요.

대부분의 최신 Android 휴대전화에서는 설치 파일이 더 작은 arm64를 먼저 선택하면 됩니다. universal은 여러 아키텍처를 지원하므로 기기 아키텍처를 잘 모를 때 적합합니다. 다만 프로세서가 64비트를 지원해도 운영체제가 반드시 64비트 환경으로 실행되는 것은 아니며, 일부 구형 기기에서는 범용 버전이 필요할 수 있습니다. arm64가 기기와 호환되지 않는다고 나오면 시스템 아키텍처를 확인한 뒤 universal을 사용해 보세요. 설치 파일을 열지 못하는 원인은 운영체제 버전, 다운로드 미완료, 서명 충돌일 수도 있으므로 아키텍처 문제로만 단정하지 마세요.

입력한 주소가 계정 웹페이지나 안내 페이지, 단일 공유 링크가 아니라 구독 API 주소인지 먼저 확인하세요. 복사 과정에서 공백이 들어가거나 쿼리 매개변수가 빠지지 않았는지도 살펴보세요. v2rayN에서는 구독 그룹을 저장한 다음 구독 업데이트를 실행해야 하며, v2rayNG에서도 구독 업데이트를 시작해야 합니다. 이후 업데이트 알림과 로그를 확인해 요청 실패인지 파싱 실패인지 구분하세요. 요청이 실패했다면 접속 경로와 주소 유효 기간을 확인하고, 파싱 실패라면 응답 형식을 확인하세요. 항목이 있는데 화면에 표시되지 않는다면 현재 그룹 필터가 결과를 숨기고 있는지 살펴보세요.

전체 링크를 다시 복사하고 가능한 한 일반 텍스트 형태의 원본을 사용하세요. 메신저가 링크를 줄바꿈하거나 줄임표를 붙이거나 한글 문장 부호를 추가하지 않았는지 확인하세요. 링크 유형이 현재 클라이언트 버전과 호환되는지도 살펴보세요. 특히 새 전송 매개변수가 포함된 설정은 주의가 필요합니다. 구독 주소는 구독 관리 메뉴에 입력하고 공유 링크 가져오기와 혼용하지 마세요. 매개변수 누락 오류가 나면 공개 키나 사용자 식별자를 추측해 채우지 말고 설정 제공자에게 전체 원문을 요청하세요. 직접 입력할 때는 프로토콜·포트·전송 방식·보안 설정을 항목별로 확인한 뒤 연결을 테스트하세요.

데스크톱에서 가상 네트워크 인터페이스를 만들고 라우팅을 변경하려면 대개 높은 권한이 필요합니다. 먼저 현재 운영체제와 클라이언트 안내에 따라 권한을 부여하세요. Windows에서는 프로그램 출처를 확인한 뒤 관리자 권한으로 실행해 볼 수 있습니다. 라우팅이나 인터페이스 충돌을 막으려면 네트워크를 제어 중인 다른 터널 프로그램도 종료하세요. Android에서는 시스템의 VPN 연결 권한을 허용하고 다른 VPN이 실행 중인지 확인해야 합니다. 보안 기능을 끄는 것을 일반적인 해결 방법으로 삼지 마세요. 그래도 실패하면 로그에 표시된 인터페이스·드라이버·라우팅 오류를 확인해 해당 항목을 해결하세요.

시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 사용됩니다. TUN은 네트워크 계층에서 조건에 맞는 트래픽을 처리하므로 시스템 프록시를 읽지 않는 프로그램에 적합합니다. 라우팅 규칙은 코어에 들어온 연결을 어떤 아웃바운드로 보낼지 결정합니다. 세 가지는 서로 다른 단계에서 작동합니다. 처음 설정할 때는 시스템 프록시로 브라우저 접속을 확인한 뒤, 실제 필요에 따라 TUN을 켜세요. 여러 조건을 동시에 바꾸지 않는 것이 좋습니다. TUN을 켠 뒤에도 DNS와 라우팅 규칙을 확인해야 합니다. 트래픽을 처리한다고 해서 모든 연결이 프록시를 통과하는 것은 아니며, 운영체제마다 메뉴와 동작이 같다고 가정하지 마세요.

먼저 테스트 종류를 구분하세요. TCP 연결 테스트는 포트 연결 여부만 보여주고, 실제 요청 테스트는 더 많은 프로토콜 핸드셰이크와 대상 접속 과정을 확인합니다. 다운로드 테스트 결과에는 대역폭과 테스트 대상도 영향을 줍니다. 테스트에 성공해도 모든 웹사이트에 접속할 수 있는 것은 아니며, 한 번 시간 초과가 났다고 설정이 무효라고 단정할 수도 없습니다. 같은 서버·라우팅·대상을 유지해 반복 확인하고 코어 로그와 대조하세요. 브라우저에서 별도로 사용하는 프록시 확장 프로그램, 보안 DNS, 캐시 때문에 클라이언트 테스트와 다른 경로를 사용할 수도 있습니다.

자동 업데이트를 지원하는 클라이언트에서 해당 구독 그룹의 업데이트를 켜고 적절한 간격을 설정한 뒤, 실제 업데이트가 완료되는지 확인하세요. 프로그램이 종료됐거나 휴대전화가 백그라운드 제한 상태라면 업데이트가 제때 실행되지 않을 수 있습니다. 구독 항목은 보통 원격 콘텐츠를 바탕으로 다시 생성되므로 매개변수를 직접 수정해도 다음 업데이트 때 덮어써질 수 있습니다. 계속 보관할 사용자 설정은 별도의 수동 그룹에 복사하고 출처를 구분하세요. 구독 자격 증명이 바뀌었다면 주소를 업데이트해야 합니다. 만료된 권한은 기존 주소를 반복해서 새로 고쳐도 복구되지 않습니다.

운영체제가 다른 기기 사이에서 폴더 전체를 덮어쓰는 방법은 권장하지 않습니다. 클라이언트마다 데이터베이스, 파일 경로, 인터페이스 이름, 라우팅 설정이 다를 수 있고, 같은 구독도 특정 클라이언트용 콘텐츠를 반환할 수 있습니다. 각 기기에서 호환되는 구독을 따로 추가하거나 클라이언트의 가져오기·내보내기 기능으로 필요한 설정만 옮기세요. 대상 기기에서 시스템 프록시·TUN·DNS·앱별 분할 설정을 다시 확인해야 합니다. 백업 파일에 서버 자격 증명이나 구독 토큰이 들어 있을 수 있으므로 안전한 위치에 보관하세요. 동기화 후에는 먼저 별도로 검증하고 기존의 작동하는 설정을 교체하세요.

코어가 정상적으로 시작된 것과 원격 사이트에 접속되는 것은 서로 다른 문제입니다. 서버를 선택했는지 확인한 다음 브라우저가 시스템 프록시를 사용하는지, 클라이언트에서 해당 프록시 모드를 설정했는지, 로컬 수신 포트가 충돌하지 않는지 확인하세요. 브라우저 프록시 확장 프로그램을 잠시 끄고 같은 사이트에 다시 접속한 뒤, 코어 로그에서 연결 및 DNS 오류를 살펴보세요. 일부 사이트만 영향을 받는다면 분할 라우팅 규칙과 브라우저 보안 DNS를 확인하세요. 한 번에 한 항목만 바꾸고 기존 설정을 보존하세요. 서버·DNS·라우팅을 동시에 바꾸면 문제를 추적하기 어려워집니다.

먼저 기기 자체에서 인터넷에 정상적으로 접속되는지 확인한 뒤 서버 주소와 포트, 구독의 만료 여부를 살펴보세요. 시스템 자동 시간 설정을 켜고 현재 코어가 설정 요구 사항을 지원하는지 확인한 다음 전송 방식·보안 유형·서버 이름 등의 매개변수를 대조하세요. 로그에서 도메인 확인 실패, 연결 시간 초과, 핸드셰이크 실패를 구분해야 합니다. 각각 해결 방법이 다릅니다. 설정 하나만 실패하면 제공자에게 서버 상태를 확인하고, 여러 설정이 동시에 실패하면 로컬 네트워크·프록시 체인·방화벽 규칙을 먼저 살펴보세요. 오류를 피하려고 인증서 검증을 임의로 끄지 마세요.

시스템 프록시가 모든 앱에 적용되는 것은 아닙니다. 일부 프로그램은 자체 네트워크 스택을 사용하거나 별도의 프록시 설정을 저장합니다. 먼저 시스템 프록시를 따르는 브라우저로 확인한 뒤, 대상 앱에 HTTP 또는 SOCKS 프록시 설정이 있는지 살펴보고 클라이언트가 실제로 수신하는 유형과 포트를 입력하세요. 브라우저 확장 프로그램, 기업 정책, 다른 프록시 도구가 시스템 설정을 덮어쓸 수도 있습니다. 네트워크 계층에서 트래픽을 처리해야 하는 경우에만 TUN을 검토하고 우회 규칙이 있는지 확인하세요. 앱이 프록시 설정을 읽는지와 무관하므로 수신 주소를 로컬 네트워크까지 확대하는 방법으로 해결하려 하지 마세요.

기존 설정이 작동한다는 것은 현재 서버 연결이 정상이라는 뜻일 뿐, 구독 API의 접속 경로·권한·응답 형식까지 정상이라는 뜻은 아닙니다. 먼저 업데이트 알림을 확인하세요. 권한 오류라면 구독 자격 증명을 확인하고, 시간 초과라면 API에 접속할 수 있는지 확인하며, 파싱 오류라면 응답이 클라이언트가 지원하는 형식인지 확인해야 합니다. 클라이언트에서 직접 업데이트와 프록시를 통한 업데이트를 모두 지원한다면 작동 중인 서버 설정은 유지한 채 각각 시도하고, 프록시가 실제로 실행 중인지 확인하세요. 설정을 모두 지우지 마세요. 실패 시각과 민감 정보를 가린 오류 내용을 기록해 두면 원인을 더 쉽게 찾을 수 있습니다.