V2Ray 자주 묻는 질문

V2Ray는 일반적으로 Project V 생태계의 프록시 도구와 관련 기술을 가리킵니다. 코어는 프로토콜 연결, 라우팅 규칙 적용, 데이터 전달을 담당하고, GUI 클라이언트는 서버 목록과 구독 관리, 시스템 연동을 제공합니다. 데스크톱에서는 v2rayN, 안드로이드에서는 v2rayNG를 많이 사용하며, v2flyNG는 V2Fly 코어를 사용하는 대안입니다. 설정을 저장할 수 있다고 해서 현재 코어가 해당 기능을 지원하는 것은 아닙니다. 호환성 문제를 확인할 때는 프로그램 아이콘이나 창 화면만 공유하지 말고 클라이언트 이름, 코어 종류, 오류 내용도 함께 기록하세요.

클라이언트에서 프로토콜 이름만 바꿔서는 연결할 수 없습니다. 프로토콜 종류, 포트, 인증 정보, 전송 방식, 보안 계층이 모두 서버 설정과 일치해야 합니다. VLESS는 자체적으로 페이로드를 암호화하지 않아 TLS나 REALITY 같은 보안 방식과 함께 사용하는 경우가 많습니다. VMess에는 자체 인증 및 암호화 방식이 있고, Trojan은 일반적으로 TLS를 사용합니다. REALITY는 보안 계층 방식이지 모든 프로토콜을 대체하는 독립적인 서버 유형이 아닙니다. 먼저 전체 공유 링크를 가져온 뒤 전송 및 보안 설정을 확인하세요. 지원하지 않는 항목이 있다면 보안 설정을 삭제해 연결을 시도하지 말고 코어의 지원 여부부터 확인하세요.

구독 주소는 여러 서버 설정을 가져오는 데 사용하며, 업데이트하면 내용을 다시 불러옵니다. 공유 링크는 보통 단일 서버 정보를 담고 있으며 vmess:// 또는 vless://로 시작할 수 있습니다. JSON 설정에는 인바운드, 아웃바운드, DNS, 라우팅 등 전체 설정이 포함될 수 있습니다. 확장자만 바꿔 서로 변환할 수 있는 것도 아니고, 같은 메뉴에서 모두 가져올 수 있는 것도 아닙니다. 주소를 받으면 먼저 제공자가 안내한 유형이 구독인지, 단일 서버인지, 사용자 지정 설정인지 확인한 뒤 해당 메뉴를 선택하세요. 구독 주소에는 접근 정보가 포함될 수 있으므로 공개적으로 도움을 요청할 때는 전체 경로, 쿼리 매개변수, 인증 정보를 가리세요.

최신 안드로이드 기기 대부분은 arm64 파일을 사용할 수 있지만, 기기를 구매한 연도만으로 판단해서는 안 됩니다. 프로세서는 64비트를 지원해도 설치된 운영체제가 32비트인 기기가 있습니다. 시스템 정보나 기기 사양에서 ABI를 확인해 arm64-v8a가 포함되어 있는지 살펴보세요. 아키텍처를 모르겠다면 지원 범위가 넓은 universal을 선택할 수 있지만, 파일 크기는 더 클 수 있습니다. 설치할 수 없다는 메시지가 나오면 운영체제 버전 요구 사항, 저장 공간, 설치 출처 권한, 서명 충돌도 확인하세요. 클라이언트나 설치 파일 출처를 바꾸기 전에 필요한 설정을 내보내 두세요. 구독 주소를 저장하지 않은 채 앱부터 삭제하지 않도록 주의하세요.

먼저 복사한 내용이 온전한지 확인하고 주소 앞뒤의 공백과 줄바꿈, 메신저가 덧붙인 문장 부호를 제거하세요. v2rayN에서는 구독 그룹 설정에 주소를 저장한 뒤 구독 업데이트를 실행해야 합니다. 그룹만 저장해서는 서버 목록이 자동으로 만들어지지 않습니다. 다음으로 업데이트 로그를 확인해 요청 실패와 내용 분석 실패를 구분하세요. 요청 실패라면 네트워크, 주소 유효 기간, 접근 권한을 확인하고, 분석 실패라면 현재 클라이언트가 구독 형식을 지원하는지 확인하세요. 로그인 페이지나 오류 페이지가 반환되면 요청 자체는 성공해도 서버가 추가되지 않습니다. 구독 그룹 필터가 결과를 숨기지 않는지 확인한 뒤 다시 가져오세요.

현재 사용할 수 있는 설정은 유지하세요. 업데이트가 한 번 실패했다고 서버 목록을 지우지 마세요. 기기 날짜와 시간, 현재 네트워크, 구독 만료 여부를 확인한 다음 로그에서 도메인 해석 실패, 연결 시간 초과, 접근 거부 중 어떤 오류인지 살펴보세요. v2rayN에서는 우선 프록시를 사용하지 않고 현재 구독을 업데이트해 보세요. 주소에 기존의 사용 가능한 프록시로만 접근할 수 있다면 프록시를 통한 업데이트를 선택하세요. 이미 사용할 수 없는 서버로 업데이트하려 하면 연결에 업데이트가 필요하고 업데이트에 연결이 필요한 악순환이 생길 수 있습니다. 계속 실패하면 제공자에게 주소와 서비스 상태를 확인하고, 짧은 시간에 요청을 반복하지 마세요.

시스템 프록시는 해당 설정을 지원하는 프로그램에 프록시 주소를 알려줄 뿐, 모든 앱의 트래픽을 자동으로 가로채지는 않습니다. 먼저 클라이언트 코어가 실행 중인지 확인하고 로컬 수신 주소와 포트를 점검하세요. HTTP 포트를 SOCKS 설정에 입력하지 않도록 주의하세요. 이어서 대상 프로그램에 별도의 프록시 설정이 있는지, 재시작이 필요한지, 프록시 예외 목록에 해당 도메인이 포함되어 있는지 확인하세요. 일부 명령줄 도구와 게임은 시스템 프록시를 사용하지 않으므로 별도로 설정하거나 적절한 TUN 모드를 사용해야 합니다. 문제를 확인할 때는 시스템 프록시를 명확히 지원하는 브라우저로 먼저 테스트하세요. 한 프로그램의 동작만으로 시스템 전체를 판단하지 마세요.

TUN은 가상 네트워크 인터페이스를 만들고 관련 라우팅을 변경하므로 필요한 권한은 운영체제, 클라이언트 버전, 설치 방식에 따라 다릅니다. 먼저 다른 VPN이나 가상 네트워크 어댑터 도구를 종료하고, 로그에서 권한·드라이버·인터페이스 생성 오류를 확인한 뒤 클라이언트 안내에 따라 권한을 허용하세요. Windows에서는 관리자 권한이 필요할 수 있고, 다른 데스크톱 운영체제에서는 서비스를 설치하거나 시스템 권한을 승인해야 할 수 있습니다. 오류 원인을 찾는 대신 보안 소프트웨어를 계속 꺼 두지는 마세요. TUN을 켜기 전에 일반 프록시 모드가 작동하는지 확인하세요. 켠 뒤 네트워크에 문제가 생기면 TUN을 끄고 네트워크를 복구한 다음 DNS, 라우팅, 인터페이스 충돌을 각각 확인하세요.

일상적인 사용에는 규칙 기반 분할 프록시를 먼저 고려하세요. 조건에 일치하는 도메인이나 주소를 지정된 아웃바운드로 보낼 수 있습니다. 전역 프록시는 규칙 적용이 문제의 원인인지 확인하기 위한 짧은 비교 테스트에 적합하지만, 앱 트래픽을 가로채는 방식과 우회 설정의 영향을 받습니다. 전역 모드라고 해서 모든 프로그램이 반드시 프록시를 사용하는 것은 아닙니다. 테스트할 때는 서버, 대상, 네트워크를 그대로 두고 모드만 변경한 뒤 결과를 확인하고 평소 설정으로 되돌리세요. 전역 모드에서는 작동하지만 규칙 모드에서는 실패한다면 규칙 순서, 기본 아웃바운드, 도메인 일치 범위를 확인하세요. 특정 사이트 하나 때문에 직접 연결 규칙을 모두 삭제하지 마세요.

라우팅 설정에서 AsIs는 원래 대상 그대로 규칙과 대조하며, IP 규칙을 위해 도메인을 추가로 해석하지 않습니다. IPIfNonMatch는 도메인이 규칙에 일치하지 않을 때 주소를 해석한 뒤 IP 규칙으로 다시 확인합니다. IPOnDemand는 라우팅 중 IP가 필요한 규칙을 만났을 때 필요한 경우에만 주소를 해석합니다. 이 설정은 라우팅 규칙을 적용하는 단계를 제어하며 모든 DNS 요청을 같은 방식으로 처리한다는 뜻은 아닙니다. 주로 도메인 규칙을 사용한다면 클라이언트 기본값을 유지해도 됩니다. IP 규칙에 실제로 의존한다면 값을 조정하고 DNS 설정도 함께 확인하세요. 임의로 변경하면 규칙 적용 결과가 달라지거나 DNS 응답을 기다리는 시간이 늘어날 수 있습니다.

안드로이드의 앱별 프록시는 VPN 트래픽 가로채기 기능을 사용합니다. 일반적으로 앱별 프록시를 켠 상태에서 우회 모드를 끄면 선택한 앱이 VPN을 사용하고, 우회 모드를 켜면 선택한 앱은 VPN을 우회하며 나머지 앱이 VPN을 사용합니다. 설정의 정확한 의미는 현재 화면의 안내를 확인해 목록의 적용 방향을 혼동하지 않도록 하세요. VPN을 사용한다고 해서 모든 트래픽이 원격 프록시로 전송되는 것은 아니며, 이후 직접 연결 규칙이 적용될 수도 있습니다. 목록을 변경한 뒤 연결을 다시 설정하고 테스트할 앱도 재시작하세요. 다른 VPN을 함께 실행 중이라면 활성 VPN을 하나만 허용하는 시스템 충돌부터 해결하세요.

지연 시간 테스트는 특정 방식으로 측정한 응답 시간만 보여 주며 웹페이지 로딩, 지속적인 다운로드, 동영상 재생 성능을 그대로 나타내지는 않습니다. TCP 연결 테스트, 실제 요청 테스트, ICMP 테스트는 대상과 방식이 달라 결과를 직접 비교할 수 없습니다. 같은 네트워크와 테스트 방식을 사용하고 실제 접속 결과 및 로그도 함께 확인하세요. 설정을 변경하기 전에 클라이언트의 내보내기나 백업 메뉴에서 구독 그룹, 수동으로 추가한 서버, 사용자 지정 규칙을 저장하고 복구할 수 있는지 확인하세요. 백업에는 구독 인증 정보와 개인 정보가 포함될 수 있으므로 안전하게 보관하고, 화면이나 로그를 공유하기 전에 민감한 내용을 가리세요.

먼저 프록시를 끄고 기본 네트워크로 정상적으로 접속되는지 확인한 뒤 기기의 날짜와 시간대를 점검하세요. 다음으로 대상 서버 주소와 포트, 구독의 유효성을 확인하고 로그에서 주소 해석 실패, 연결 거부, 핸드셰이크 실패를 살펴보세요. 모든 오류를 회선 속도 문제로 단정하지 마세요. 같은 설정에서 다른 사용 가능한 서버로 바꿔 보거나, 다른 네트워크에서 같은 서버를 테스트하세요. 한 번에 조건 하나만 바꾸세요. 특정 서버 하나만 계속 실패한다면 제공자에게 서비스 상태를 확인하세요. 모든 서버가 실패한다면 로컬 네트워크, 코어 실행 여부, 프록시 트래픽 가로채기 방식을 먼저 점검하세요. 연결 버튼을 반복해서 누르기보다 오류 내용을 기록하세요.

연결됨 표시는 로컬 서비스나 안드로이드 VPN이 시작되었다는 뜻일 수 있으며, 원격 서버가 정상이라는 보장은 아닙니다. 먼저 올바른 서버가 선택되었는지, 코어 로그에 오류가 있는지 확인하고 브라우저가 시스템 프록시를 사용하거나 VPN 또는 TUN에 연결되어 있는지 점검하세요. 이어서 서로 다른 도메인에 접속해 특정 사이트 문제인지 전체적인 문제인지 구분하세요. 규칙 모드에서만 문제가 생긴다면 라우팅과 DNS를 확인하세요. 안드로이드에서 백그라운드 연결이 끊긴다면 배터리 최적화와 백그라운드 실행 제한도 살펴보세요. 프로토콜, DNS, 라우팅, 포트를 한꺼번에 변경하지 마세요. 문제가 해결되어도 원인을 알기 어려워집니다. 각 단계에서 되돌릴 수 있는 설정을 유지하세요.

먼저 접속에 실패한 도메인과 로그 오류를 기록하세요. 도메인 해석 실패, 응답 시간 초과, 잘못된 주소 반환이 나타나면 현재 DNS 설정과 연결 가능 여부부터 확인하세요. 주소 해석은 성공했지만 적절하지 않은 아웃바운드로 연결된다면 규칙 적용 결과와 규칙 순서를 확인하세요. 라우팅의 도메인 해석 전략, 코어 DNS, 시스템 DNS, 브라우저의 보안 DNS는 서로 다른 단계에 관여할 수 있습니다. 한 설정을 바꿨다고 모두 해결된다고 볼 수는 없습니다. 비교를 위해 브라우저의 사용자 지정 DNS를 잠시 끈 뒤 설정을 복구해 보세요. IPv6가 관련된 경우 로컬 네트워크와 선택한 아웃바운드가 IPv6 연결을 지원하는지도 확인하세요.

먼저 클라이언트에서 TUN을 끄거나 VPN을 중지하고 시스템 프록시를 해제한 뒤 정상적으로 종료하세요. 프로그램이 비정상 종료되었다면 시스템 네트워크 설정에서 로컬 루프백 주소를 가리키는 수동 프록시가 남아 있는지 확인하세요. 이번 설정으로 추가된 프록시가 맞는지 확인한 뒤 제거하세요. 이후 네트워크에 다시 연결하고 다른 VPN이나 프록시 서비스가 실행 중인지 점검하세요. 네트워크 어댑터와 시스템 라우팅을 한꺼번에 삭제하지 마세요. 복구되지 않는다면 운영체제, 클라이언트와 코어 버전, 트래픽 가로채기 모드, 문제가 발생한 시각, 관련 오류 로그를 기록하세요. 서버 주소, 구독 인증 정보, 개인 정보를 가린 뒤 도움을 요청하세요.