V2Ray 자주 묻는 질문

V2Ray는 Project V 프록시 기술 생태계의 일부입니다. 코어는 프로토콜 처리, 인바운드 리스닝, 라우팅을 담당하고, 클라이언트는 그래픽 인터페이스를 제공해 노드 저장, 구독 업데이트, 코어 실행을 처리합니다. v2rayN은 데스크톱 클라이언트이며 v2rayNG와 v2flyNG는 안드로이드용입니다. 문제를 확인할 때는 먼저 인터페이스 조작 문제인지 코어 연결 문제인지 구분하세요. 구독 목록이 비어 있으면 가져오기 결과를 확인하고, 노드는 있지만 연결되지 않으면 코어 로그를 살펴보세요. 모든 문제의 첫 단계로 클라이언트 재설치를 선택하지 마세요.

데스크톱에서는 v2rayN부터 사용하는 것이 좋습니다. 안드로이드에서는 보통 Xray 코어를 사용하는 v2rayNG를 선택하고, V2Fly 코어 동작이 필요하거나 기존 설정과의 호환성이 중요한 경우 v2flyNG를 고려하세요. REALITY와 XTLS Vision은 Xray 관련 기능이므로 클라이언트 이름이 비슷하다는 이유만으로 지원 여부를 판단할 수 없습니다. 먼저 서버에서 요구하는 프로토콜, 보안 계층, 전송 방식을 확인한 뒤 클라이언트에 포함된 코어가 이를 지원하는지 살펴보세요. 두 안드로이드 클라이언트는 설정을 각각 저장하므로 앱을 바꾸면 구독을 다시 가져와야 하는 경우가 많습니다.

클라이언트는 연결 도구이며, 설치 파일에 바로 사용할 수 있는 원격 서버가 포함되어 있지는 않습니다. 연결하려면 정식으로 제공받은 서버 주소와 포트, 인증 정보, 서버와 일치하는 프로토콜 및 전송 설정이 필요합니다. 구독은 이러한 설정을 일괄 배포하는 주소일 뿐 클라이언트 계정이 아닙니다. 구독을 받으면 먼저 가져와 노드 목록을 업데이트한 뒤 사용할 서버를 선택하세요. 노드가 없는 상태에서 시스템 프록시나 TUN을 반복해서 전환해도 서버 정보가 생기지 않으며 프록시 연결도 설정되지 않습니다.

VMess, VLESS, Trojan은 프록시 프로토콜 이름이고, REALITY는 Xray가 제공하는 보안 전송 방식입니다. 이들을 서로 배타적인 네 가지 프로토콜 옵션으로 보면 안 됩니다. 노드에는 TCP, WebSocket, gRPC 같은 전송 설정과 TLS, SNI 등의 항목이 함께 포함될 수도 있습니다. 가져온 뒤에는 서버 제공 정보에 따라 전체 조합을 확인하세요. 특히 포트, 경로, 서비스 이름, 보안 매개변수를 점검해야 합니다. 문제를 해결하려고 프로토콜을 임의로 바꾸지 마세요. 클라이언트와 서버 설정이 일치하지 않으면 핸드셰이크가 실패할 수 있습니다.

대부분의 최신 안드로이드 휴대전화에서는 arm64를 먼저 선택할 수 있지만, 제조 연도만으로 판단하지 말고 기기에서 지원하는 앱 아키텍처를 확인해야 합니다. 시스템의 기기 정보에서 확인하거나 제조사 사양을 참고하세요. 아키텍처를 확인하기 어렵다면 여러 아키텍처를 포함해 호환 범위가 넓은 universal 패키지를 선택할 수 있지만 파일 크기는 보통 더 큽니다. 설치 중 호환되지 않는다는 메시지가 나오면 시스템 버전과 앱 아키텍처를 확인하세요. 서명 충돌이 발생하면 설정을 먼저 백업하고 기존 앱의 출처를 확인하세요. 구독과 라우팅 설정을 잃을 수 있으니 바로 삭제하지 마세요.

먼저 받은 항목이 구독 URL인지, 단일 공유 링크인지, 전체 JSON 설정인지 확인하세요. 각 형식에 따라 가져오기 메뉴가 다릅니다. 구독 URL은 구독 그룹의 주소 입력란에 넣고 저장한 뒤 업데이트하세요. 공유 링크는 클립보드에서 가져오고, 전체 설정 파일은 사용자 지정 설정 메뉴를 이용하세요. 복사할 때 공백이나 줄바꿈, 메신저에서 덧붙인 문구가 포함되지 않았는지도 확인하세요. 목록이 계속 비어 있으면 업데이트 메시지를 살펴보세요. 인증 실패라면 구독 유효기간을 확인하고, 형식 오류라면 응답이 로그인 페이지인지 확인하세요. 모르는 온라인 파싱 서비스에 구독 주소를 입력하지 마세요.

항상 가능한 것은 아닙니다. 전체 JSON은 코어 설정을 설명하며 인바운드, 라우팅, 여러 아웃바운드가 함께 들어 있을 수 있습니다. 일반적인 구독은 클라이언트가 인식하는 노드 목록이나 Base64로 인코딩된 공유 링크 목록입니다. URL에서 JSON을 내려받을 수 있다고 해서 현재 구독 메뉴가 지원하는 형식이라는 뜻은 아닙니다. 제공자의 안내를 확인한 뒤 사용자 지정 설정 또는 해당 형식의 가져오기 메뉴를 선택하세요. 사용자 지정 설정은 리스닝 포트와 라우팅을 직접 지정할 수도 있으므로 사용 전에 로컬 포트 충돌을 확인하고 복구할 수 있도록 기존 설정을 저장하세요.

먼저 일반 프록시 모드에서 노드가 작동하는지 확인한 뒤 TUN 문제를 살펴보세요. 두 계층의 문제를 동시에 점검하는 일을 피할 수 있습니다. 데스크톱에서 가상 네트워크 인터페이스를 만들고 라우팅을 설정하려면 관리자 권한이나 해당 시스템 권한이 필요한 경우가 많습니다. 클라이언트 안내에 따라 권한을 허용하고 가상 인터페이스 구성 요소가 제대로 설치되었는지 확인하세요. 안드로이드에서는 시스템 VPN 권한을 허용해야 하며 연결 요청을 승인해야 합니다. 기기의 다른 VPN 서비스와 충돌할 수도 있습니다. 로그에 권한 또는 인터페이스 생성 오류가 표시되면 충돌하는 서비스를 먼저 종료한 뒤 다시 시도하세요. 문제를 피하려고 시스템 보안 기능을 계속 꺼 두지는 마세요.

기존 노드를 먼저 보존하세요. 구독 업데이트는 설정 배포 주소에 접속하고, 노드 연결은 프록시 서버에 접속하므로 두 연결은 각각 성공하거나 실패할 수 있습니다. 구독이 만료되었는지, 주소가 변경되었는지 확인한 뒤 클라이언트에서 제공하는 옵션에 따라 프록시를 거치지 않는 업데이트와 프록시를 통한 업데이트를 각각 시도하세요. 프록시를 통한 업데이트에는 먼저 사용할 수 있는 노드가 있어야 합니다. 시간 초과라면 현재 네트워크를 확인하고, 인증 오류라면 구독 권한을 점검하세요. 목록을 반복해서 지우면 쓸 수 있는 설정을 잃을 수 있으므로 먼저 백업하고 연달아 빠르게 재시도하기보다 구체적인 오류를 기록하세요.

시스템 프록시는 시스템 설정을 따르는 앱에 요청을 로컬 프록시 포트로 보내도록 안내합니다. 전역 라우팅은 일반적으로 코어에 들어온 트래픽을 프록시 아웃바운드로 우선 보내는 방식이며, 모든 앱의 트래픽이 코어에 들어온다는 뜻은 아닙니다. TUN은 가상 네트워크 인터페이스로 조건에 맞는 트래픽을 처리합니다. 세 기능은 서로 다른 계층에 있으며 함께 사용할 수 있지만 같은 기능은 아닙니다. 브라우저는 되는데 특정 앱만 작동하지 않으면 먼저 해당 앱이 시스템 프록시를 따르는지 확인하고, 필요하면 앱 내 프록시나 TUN을 검토하세요. 모든 라우팅 규칙을 먼저 전역 프록시로 바꿀 필요는 없습니다.

먼저 TCPing으로 서버 포트에 TCP 연결이 가능한지 확인하고, 실제 연결 속도 측정으로 프록시 핸드셰이크와 대상 사이트 접속을 점검하세요. 마지막으로 실제 앱에서 출구 IP를 확인합니다. TCPing에 결과가 표시되어도 포트에 도달했다는 뜻일 뿐 인증, TLS, 라우팅이 모두 정상이라는 의미는 아닙니다. 실제 연결 속도 측정 결과도 테스트 주소와 현재 네트워크의 영향을 받습니다. 출구 IP를 확인할 때는 신뢰할 수 있는 조회 페이지를 사용하고 해당 요청이 예상대로 프록시를 통과하는지 확인하세요. 한 번 측정한 지연 시간은 처리 속도가 아닙니다. 노드를 선택할 때는 가장 낮은 수치만 기준으로 삼지 말고 지속적인 접속 안정성도 살펴보세요.

클라이언트 이름, 운영체제, 사용 중인 코어, 발생 시각, 프록시 방식, 전체 오류 문구를 기록한 뒤 최소한의 동작으로 한 번 재현하세요. 로그는 오류 전후의 짧은 구간을 우선 보관하면 파싱 실패, 연결 시간 초과, 인증 실패를 구분하는 데 도움이 됩니다. 스크린샷이나 설정을 공유하기 전에 구독 주소, 사용자 식별자, 비밀번호, 접속 정보를 복원할 수 있는 QR 코드를 가리세요. 설정 구조를 보여줘야 한다면 민감한 값은 예시 값으로 바꾸되 항목 이름과 오류 상황은 남겨 두세요. 로그 수준을 높이는 것은 단기 분석에만 사용하고 작업이 끝나면 원래 설정으로 되돌리세요.

먼저 프록시를 끄고 로컬 네트워크에서 정상적으로 접속되는지 확인한 다음 서버 주소와 포트가 정확한지 살펴보세요. TCPing과 실제 연결 속도 측정 결과를 각각 확인합니다. 포트 연결도 시간 초과되면 네트워크 경로, 서버 상태, 방화벽을 먼저 점검하세요. 포트에는 연결되지만 실제 연결은 실패한다면 프로토콜, 인증, 보안 계층, 전송 설정을 확인하세요. 신뢰할 수 있는 다른 네트워크와 비교해 볼 수 있지만 한 번에 하나의 항목만 변경하세요. 모든 노드가 실패하면 로컬 네트워크나 클라이언트 공통 설정을 먼저 확인하고, 특정 노드만 실패하면 해당 서버의 설정과 상태를 집중적으로 살펴보세요.

연결됨 표시는 코어가 실행되었거나 가상 인터페이스가 만들어졌다는 의미일 수 있으며, 대상 사이트에 접속할 수 있다는 보장은 아닙니다. 먼저 사용할 노드가 선택되어 있는지 확인한 다음 로컬 인바운드가 리스닝 중인지, 브라우저가 올바른 프록시 포트를 사용하는지, 라우팅이 요청을 예상한 아웃바운드로 전달하는지 점검하세요. 로그에 도메인 이름 확인 실패가 표시되면 DNS 주소에 접속할 수 있는지 확인하세요. 아직 연결되지 않은 프록시에 DNS 요청을 의존해 순환 문제가 생기지 않도록 주의해야 합니다. 일부 사이트만 실패한다면 해당 분기 규칙과 대상 서비스 상태를 확인하고 노드, DNS, 라우팅을 한꺼번에 바꾸지 마세요.

먼저 운영체제의 프록시 설정을 열어 주소가 클라이언트의 실제 로컬 리스닝 주소와 포트를 가리키는지 확인하세요. 사용하지 않는 이전 포트가 남아 있지 않은지도 살펴보세요. 브라우저 확장 프로그램, 앱 내부 프록시, 자동 구성 스크립트가 시스템 설정을 덮어쓰는지 확인하세요. 일부 앱은 시스템 프록시를 사용하지 않으므로 별도로 설정해야 합니다. 클라이언트를 종료한 뒤에도 접속할 수 없다면 남아 있는 시스템 프록시 설정을 지우고 직접 연결을 테스트하세요. 다시 시작할 때는 프록시 도구 하나만 활성화하고 설정을 하나씩 복원하세요. 원격 서버 주소 입력란에 로컬 리스닝 주소를 넣지 마세요. 두 주소의 용도가 다릅니다.

인증서 검증을 건너뛰는 방법을 장기적인 해결책으로 삼는 것은 권장하지 않습니다. 먼저 시스템 날짜와 시간, 시간대를 맞춘 뒤 SNI가 서버 요구 사항에 맞는지, 인증서가 해당 도메인을 포함하고 있고 만료되지 않았는지 확인하세요. 서버 주소와 SNI는 서로 다를 수 있지만 서버 설정에 따라 입력해야 하며 임의로 바꾸면 안 됩니다. REALITY를 사용한다면 공개 키, 짧은 ID, 지문 등의 매개변수도 확인하세요. 최근 노드 설정을 변경했다면 신뢰할 수 있는 출처에서 정보를 다시 가져오세요. 문제가 계속되면 원본 오류를 보관하고 설정 제공자에게 서버 상태를 확인하세요.