V2Ray 자주 묻는 질문

V2Ray는 Project V 프록시 도구 생태계에 속하며, V2Fly와 Xray는 관련 코어 계열입니다. 코어는 프로토콜 처리, 연결 수립, 라우팅을 담당하고 GUI 클라이언트는 설정 편집, 구독 관리, 코어 실행을 맡습니다. v2rayN은 데스크톱용이며, v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 클라이언트를 다운로드해도 사용할 서버 설정이 자동으로 제공되지는 않습니다. 시작하기 전에 사용 권한이 있는 구독이나 노드 정보를 준비해야 합니다.

Windows, macOS, Linux 데스크톱에서는 운영체제에 맞춰 v2rayN을 우선 선택하세요. Android에서는 v2rayNG를 먼저 고려하고, V2Fly 코어 호환성이 필요하면 v2flyNG를 선택할 수 있습니다. Windows 다운로드 페이지에는 Desktop과 WPF 두 가지 인터페이스가 있습니다. 전자는 크로스 플랫폼 인터페이스를, 후자는 클래식 WPF 인터페이스를 사용합니다. 운영체제, 프로세서 아키텍처, 프로토콜 지원 여부를 기준으로 선택하세요. 다른 클라이언트에서 같은 링크를 가져올 수 있다고 해서 모든 전송 설정까지 완벽히 호환되는 것은 아닙니다.

구독 링크는 일반적으로 여러 서버 설정을 가져오는 주소이며, 클라이언트가 구독을 업데이트할 때 해당 주소에 다시 요청을 보냅니다. 단일 노드 공유 링크는 보통 프로토콜 이름으로 시작하며 하나의 연결 설정만 담습니다. 각 링크에 맞는 가져오기 기능을 사용해야 하며, 링크가 길다는 이유만으로 구독이라고 판단할 수는 없습니다. 구독 주소에는 계정 식별 정보나 접속 자격 증명이 포함될 수 있으므로 민감 정보로 취급하세요. 도움을 요청할 때는 오류 유형만 설명하고 전체 주소, QR 코드, 자격 증명이 보이는 스크린샷은 공개하지 마세요.

시스템 프록시는 시스템 설정을 따르는 앱의 요청을 로컬 프록시 포트로 전달합니다. 라우팅 프리셋은 코어에 들어온 요청을 직접 연결, 프록시, 차단 중 어디로 보낼지 결정합니다. TUN 모드는 가상 네트워크 인터페이스로 트래픽을 받아 처리하며, 적용 범위는 구현 방식, 권한, 라우팅 설정에 따라 달라집니다. 세 기능은 서로 다른 단계에서 작동하므로 같은 기능을 대체하는 스위치가 아닙니다. 처음 설정할 때는 TUN을 끄고 시스템 프록시로 기본 연결을 확인한 뒤, 앱이 시스템 프록시를 따르는지에 따라 TUN 사용 여부를 결정하세요.

먼저 구독 주소 전체를 복사했는지 확인하고, 앞뒤 공백과 줄바꿈, 메신저에서 덧붙은 문장 부호를 제거하세요. v2rayN에서는 구독 그룹에 주소를 저장한 다음 해당 그룹의 구독 업데이트를 실행해야 합니다. Android 클라이언트에서는 구독 설정에 주소를 저장한 뒤 업데이트하세요. 주소를 저장했다고 해서 노드를 가져온 것은 아닙니다. 여전히 목록이 비어 있다면 업데이트 로그를 확인해 네트워크 요청 실패, 응답 내용 해석 실패, 유효한 노드 없음 중 무엇인지 구분하세요. 웹 로그인 주소, 요금제 안내 페이지, 만료된 구독은 노드 구독으로 바로 가져올 수 없습니다.

먼저 기기의 프로세서와 시스템이 지원하는 앱 아키텍처를 확인하세요. 2015년 이후 출시된 일반적인 스마트폰은 arm64를 우선 고려할 수 있지만, 프로세서가 64비트를 지원한다고 해서 현재 시스템에서 64비트 앱을 설치할 수 있는 것은 아닙니다. 기기 정보를 기준으로 판단하세요. 아키텍처를 확인하기 어렵다면 여러 아키텍처용 구성 요소를 포함하는 universal을 선택할 수 있습니다. 다만 설치 파일 크기는 더 큰 편입니다. 설치 패키지를 분석할 수 없다는 오류가 나면 아키텍처뿐 아니라 시스템 버전, 다운로드 중단 여부, 같은 이름의 앱이 다른 서명 출처에서 배포됐는지도 확인하세요. 앱을 삭제하기 전에 설정을 백업하세요.

먼저 코어가 실행 중이고 사용할 서버가 선택되어 있는지 확인한 다음, v2rayN에서 시스템 프록시 자동 설정을 선택하세요. 운영체제의 네트워크 프록시 설정을 열어 로컬 주소와 포트가 클라이언트 설정과 일치하는지 확인합니다. 브라우저 확장 프로그램, 다른 프록시 도구, 조직의 관리 정책이 설정을 덮어쓸 수 있으며 시스템 프록시를 전혀 사용하지 않는 앱도 있습니다. 충돌할 수 있는 도구를 종료하고 시스템 프록시를 따르는 브라우저로 테스트하세요. Linux 데스크톱은 프록시 설정 위치가 환경마다 다르므로 필요한 경우 GNOME 또는 KDE 네트워크 설정에서 직접 확인하세요.

먼저 TUN을 끄고 일반 프록시 연결이 되는지 확인한 뒤 가상 인터페이스 권한을 설정하세요. Windows에서는 일반적으로 관리자 권한과 호환되는 관련 드라이버가 필요합니다. macOS와 Linux에서는 클라이언트 안내에 따라 권한을 부여하고, 출처를 알 수 없는 명령어로 권한 설정을 대신하지 마세요. Android는 처음 실행할 때 시스템 VPN 권한을 요청합니다. 거부했다면 연결을 다시 시작해 권한 요청을 승인하세요. 다른 VPN 앱이 시스템 인터페이스를 사용 중이면 먼저 종료해야 합니다. 권한을 설정한 뒤에도 실패한다면 로그에서 인터페이스 생성 또는 라우트 추가 오류를 확인하고, 스위치를 반복해서 켜고 끄지 마세요.

실제 접속 목적에 맞는 라우팅 프리셋을 먼저 선택한 뒤, 특정 도메인에 어떤 규칙이 적용되는지 확인하세요. 중국 본토 우회는 보통 도메인 및 IP 분류 규칙에 따라 해당 트래픽을 직접 연결로 보냅니다. 전역 프록시는 일반적으로 코어에 들어온 요청을 우선 프록시로 보내지만, 실제 동작은 선택한 규칙의 영향을 받습니다. 라우팅 설정의 전역은 기기 전체의 트래픽을 가로챈다는 뜻이 아닙니다. 코어에 들어오지 않은 앱 트래픽은 바뀌지 않습니다. 특정 사이트에 문제가 있다면 프리셋을 잠시 바꿔 비교하고, 원인을 확인한 뒤 규칙을 조정하세요. 프록시 적용 범위를 무작정 넓혀 설정 문제를 덮어두는 것은 피해야 합니다.

가져온 서버를 선택하고 코어를 실행한 뒤 시스템 프록시를 설정하세요. 정상적으로 열리는 HTTPS 페이지에 접속하면서 클라이언트의 연결 기록이나 로그를 확인합니다. 대상 도메인이 기록에 나타나는지, 프록시와 직접 연결 중 어떤 경로로 처리됐는지 살펴보세요. 노드 테스트 성공은 특정 테스트 요청이 작동한다는 뜻일 뿐, 브라우저가 프록시를 사용하고 있음을 증명하지는 않습니다. 브라우저 요청 기록이 없다면 브라우저 자체 프록시 설정과 확장 프로그램, 시스템 설정을 먼저 확인하세요. 로그 정보가 부족하면 잠시 로그 수준을 높여 문제를 찾고, 확인이 끝나면 일반 수준으로 되돌린 뒤 로그를 안전하게 관리하세요.

구독 그룹의 노드는 일반적으로 원격 구독 내용에서 생성됩니다. 업데이트할 때 클라이언트가 원격 데이터로 항목을 다시 만들거나 덮어쓸 수 있으므로, 구독 노드에 장기간 사용할 수동 설정을 직접 적용하지 않는 편이 좋습니다. 별도 설정을 유지해야 한다면 먼저 백업한 뒤 클라이언트가 지원하는 복사 또는 수동 추가 기능으로 독립 항목을 만들고, 기존 구독 그룹과 구분해 관리하세요. 구독 업데이트로 항목 식별 정보가 달라지면 기존에 선택한 서버가 계속 선택되어 있지 않을 수도 있습니다. 업데이트할 때마다 활성 항목, 라우팅 프리셋, 주요 전송 설정을 확인하고 연결을 테스트하세요.

클라이언트의 내보내기 또는 백업 기능을 우선 사용해 구독 그룹, 수동으로 추가한 노드, 사용자 지정 라우팅, 필요한 DNS 설정을 저장하세요. 로컬 수신 포트와 자주 사용하는 모드도 기록해 두는 것이 좋습니다. 백업 파일에는 서버 비밀번호, 사용자 식별 정보, 구독 자격 증명이 포함될 수 있으므로 안전하게 관리하고 일반 첨부 파일처럼 공개 전송하지 마세요. 다른 클라이언트로 가져올 때는 기본 연결 설정부터 옮긴 다음 라우팅과 DNS를 하나씩 다시 설정하세요. 인터페이스 설정과 구성 파일 형식이 호환되지 않을 수 있습니다. 복원 후에는 먼저 노드 하나를 테스트하고 정상 작동을 확인한 뒤 나머지 설정을 옮기세요.

먼저 기기의 네트워크가 정상이고 시스템 시간이 정확한지 확인한 다음, 노드 주소와 포트, 프로토콜 설정이 빠짐없이 입력됐는지 살펴보세요. 같은 구독의 다른 노드와 비교하고, 가능하면 다른 네트워크에서도 테스트합니다. 특정 노드만 실패하면 해당 서버나 설정에 문제가 있을 가능성이 높고, 모든 노드가 실패하면 로컬 네트워크와 코어 실행 상태, 구독 상태를 확인해야 합니다. TCP 연결이 된다고 해서 TLS 또는 프로토콜 핸드셰이크까지 성공한 것은 아닙니다. 로그에서 이름 확인 실패, 연결 시간 초과, 핸드셰이크 오류를 찾아 해당 단계부터 해결하세요. 원인을 추적하기 어려워지지 않도록 여러 설정을 한꺼번에 바꾸지 마세요.

연결됨 표시는 보통 로컬 서비스나 시스템 인터페이스가 시작됐다는 뜻이며, 원격 연결과 도메인 이름 확인까지 모두 정상이라는 의미는 아닙니다. 먼저 현재 선택된 서버를 확인한 다음 브라우저 트래픽이 코어로 들어가는지 살펴보세요. 요청이 코어에 들어간 뒤 실패한다면 DNS 조회, 라우팅 경로, 핸드셰이크 로그를 확인합니다. 요청 기록이 전혀 없다면 시스템 프록시 또는 TUN의 트래픽 처리 범위를 다시 확인하세요. 다른 정상적인 HTTPS 페이지로 테스트해 특정 사이트의 문제인지 구분할 수 있습니다. 처음부터 방화벽이나 모든 보안 설정을 끄지 말고, 로그를 활용해 앱, 이름 확인, 라우팅, 서버 중 어느 단계의 문제인지 좁혀 가세요.

노드 연결은 저장된 서버 설정을 사용하지만, 구독 업데이트는 구독 주소에 요청을 보냅니다. 두 경로의 DNS, 라우팅, 접속 조건이 서로 다를 수 있습니다. 먼저 구독 만료 여부와 주소가 재설정됐는지, 로그에 표시된 HTTP 상태를 확인하세요. 인증 또는 권한 오류라면 구독 제공업체에 문의해야 합니다. 네트워크 시간 초과는 클라이언트가 지원하는 경우 직접 연결 업데이트와 프록시 경유 업데이트를 비교해 확인하세요. 프록시 경유 업데이트에 필요한 활성 노드 자체가 작동하지 않으면 업데이트가 막힐 수 있습니다. 짧은 시간 동안 반복 요청하면 제한에 걸릴 수 있으므로 오류 내용을 기록하고 간격을 두고 다시 시도하세요.

먼저 클라이언트를 다시 열고 TUN을 끈 다음, 시스템 프록시를 해제하고 정상적으로 종료하세요. 클라이언트를 실행할 수 없다면 운영체제의 네트워크 설정에서 로컬 주소를 가리키는 수동 프록시가 남아 있는지 확인합니다. 다른 앱이 해당 프록시 설정을 사용 중이지 않은지 확인한 뒤 해제하세요. Android에서는 시스템 VPN 연결이 계속 활성화되어 있는지 확인하고, 데스크톱에서는 다른 VPN이나 가상 네트워크 도구도 살펴보세요. 복구한 뒤 일반 직접 연결 페이지로 테스트합니다. 고장 원인을 파악하고 기존 네트워크 설정을 복구할 준비가 된 경우가 아니라면 모든 네트워크 어댑터를 삭제하거나 라우팅을 초기화하지 마세요.