V2Ray 클라이언트 자주 묻는 질문

데스크톱에서는 Windows, macOS, Linux를 지원하는 v2rayN을 먼저 살펴보세요. Android에서는 Xray 코어를 사용하는 v2rayNG가 대표적이며, V2Fly 코어를 사용하는 v2flyNG도 대안입니다. GUI는 설정을 가져오고 관리하며, 실제 연결은 코어가 담당합니다. 따라서 이름이 비슷한 클라이언트라도 지원하는 설정 조합이 다를 수 있습니다. 선택하기 전에 서버 프로토콜과 전송 방식, 필요한 코어 기능을 확인하고 운영체제와 프로세서 아키텍처에 맞는 설치 파일을 고르세요. 기존 설정이 안정적으로 작동한다면 인터페이스 차이만으로 클라이언트를 바꿀 필요는 없습니다. 이전하기 전에는 사용자 지정 라우팅과 구독 그룹 설정을 저장하세요.

아닙니다. VMess와 VLESS는 프록시 프로토콜이고, TCP와 WebSocket 등은 전송 방식입니다. REALITY는 연결 보안과 관련된 메커니즘으로, VLESS 등의 설정과 함께 사용되는 경우가 많습니다. 설정을 가져올 때는 프로토콜 이름뿐 아니라 전송 유형, 보안 옵션, 서버 이름과 관련 매개변수도 확인해야 합니다. 클라이언트에 특정 프로토콜 옵션이 있다고 해서 현재 코어가 모든 조합을 지원하는 것은 아닙니다. 서버에서 제공한 전체 설정에 맞춰 코어를 선택하세요. REALITY를 일반 TLS 옵션처럼 바꿔 끄거나, 기존 설정의 프로토콜 드롭다운만 변경해 변환해서는 안 됩니다.

공유 링크는 보통 서버 설정 하나를 나타내며, 예를 들어 vmess:// 또는 vless://로 시작하는 문자열입니다. 구독 주소는 대개 HTTPS 주소로, 여러 설정을 가져오고 이후 업데이트하는 데 사용합니다. 공유 링크 하나는 클립보드에서 가져오기 같은 메뉴로 불러오고, 구독 주소는 구독 그룹의 주소 입력란에 넣어야 합니다. 올바르지 않은 메뉴에 넣으면 파싱 오류가 나거나 목록이 비어 보일 수 있습니다. 구독을 업데이트하면 보통 해당 그룹의 서버 항목이 교체되며, 사용자 지정 라우팅까지 자동으로 동기화되지는 않습니다. 구독 주소와 공유 링크에는 연결 자격 증명이 포함될 수 있으므로 문제를 확인할 때 전체 내용을 공개된 곳에 올리지 마세요.

최근 출시된 Android 휴대전화라면 arm64를 먼저 선택할 수 있지만, 구매 연도만으로 판단하지 말고 기기가 지원하는 앱 아키텍처를 확인하세요. 프로세서는 64비트를 지원해도 시스템에서 32비트 앱 환경만 제공하는 기기에서는 arm64 패키지가 설치되지 않을 수 있습니다. 아키텍처를 모르거나 설치 프로그램에서 호환되지 않는다고 표시하면 같은 클라이언트의 universal 패키지를 사용해 볼 수 있습니다. universal 패키지는 더 많은 아키텍처를 포함하므로 보통 용량이 큽니다. 서명 충돌이나 버전 다운그레이드 메시지가 뜨면 아키텍처를 바꿔도 해결되지 않는 경우가 많습니다. 설치된 앱의 출처와 버전을 확인하고, 삭제하기 전에 설정을 백업하세요.

먼저 공유 링크 하나를 가져오는지 구독 주소를 가져오는지 확인한 다음, 복사한 내용에 공백, 줄바꿈, 중국어 문장 부호나 안내 문구가 섞이지 않았는지 살펴보세요. 구독 주소의 쿼리 매개변수는 그대로 보존해야 하며, 구독 그룹에 추가한 뒤 업데이트해야 합니다. 로그에 파싱 오류가 표시된다면 웹 로그인 페이지나 오류 안내 페이지가 반환됐거나, 클라이언트에서 지원하지 않는 구독 형식일 수 있습니다. 브라우저에서 주소가 열린다고 해서 반환된 내용을 클라이언트가 파싱할 수 있는 것은 아닙니다. 제공업체가 현재 클라이언트에 맞는 형식을 제공하는지 확인하세요. 문제를 확인하는 동안 기존 그룹을 유지하고 설정을 연달아 지우지 마세요. 접속 자격 증명이 포함된 전체 주소를 로그 스크린샷에 노출하지 마세요.

기존 서버에 연결된다는 것은 현재 연결 매개변수가 작동한다는 뜻일 뿐, 구독 서버에도 접속할 수 있다는 뜻은 아닙니다. 먼저 업데이트 로그에서 DNS 확인 실패, 연결 시간 초과, 인증서 오류, HTTP 거부 상태를 구분한 뒤 구독이 만료됐는지, 주소가 바뀌었는지 확인하세요. 클라이언트에 프록시를 통해 구독을 업데이트하는 옵션이 있다면 아직 작동하는 설정으로 시도할 수 있습니다. 현재 프록시가 작동하지 않는다면 프록시를 강제로 거쳐 업데이트하려다 실패할 수 있습니다. 시스템 시간과 네트워크 로그인 상태도 확인하세요. 한 번에 조건 하나만 바꾸고, 업데이트에 성공하면 그룹 항목이 정상인지 확인하세요. 업데이트 버튼을 반복해서 누르는 것은 해결 방법이 아닙니다.

클라이언트를 실행했다고 해서 시스템 프록시가 자동으로 설정되는 것은 아닙니다. 먼저 코어가 정상적으로 실행 중인지, 로컬 수신 포트가 설정과 일치하는지 확인하세요. 그런 다음 시스템 프록시 자동 설정을 선택하고 운영체제의 네트워크 설정에서 실제 프록시 주소와 포트를 확인하세요. 시스템 프록시는 해당 설정을 따르는 앱에만 적용됩니다. 자체 프록시 설정을 사용하는 프로그램도 있고, TUN으로 처리해야 하는 트래픽도 있습니다. 다른 프록시 도구나 브라우저 확장 프로그램, 관리 정책이 설정을 덮어쓰는지도 확인하세요. 라우팅 규칙과 프록시 포트를 동시에 바꾸지 말고, 먼저 시스템 프록시를 지원하는 브라우저로 확인한 뒤 개별 앱의 예외를 살펴보세요.

TUN은 가상 네트워크 어댑터와 시스템 라우팅을 사용하므로 보통 시스템 프록시보다 더 많은 권한이 필요합니다. Windows에서는 클라이언트 안내에 따라 관리자 권한을 부여할 수 있습니다. macOS와 Linux에서는 설치 방식에 맞게 보조 서비스나 시스템 권한을 승인해야 합니다. 구체적인 메뉴는 버전별 인터페이스를 확인하세요. 로그에 권한 문제, 네트워크 어댑터 생성 실패, 라우팅 설정 실패가 명확히 표시되는지 먼저 살펴보세요. 인터넷이 안 된다는 이유만으로 권한을 높이지 마세요. TUN을 켜기 전에 트래픽을 처리 중인 다른 도구를 종료하고 기존 네트워크 설정을 보존하세요. 활성화 후 네트워크에 문제가 생기면 TUN을 끄고 기본 연결이 복구되는지 확인한 다음 DNS와 라우팅을 점검하세요. 반복해서 재설치할 필요는 없습니다.

도메인이나 주소에 따라 연결 경로를 나누려면 분할 라우팅을 사용하세요. 특정 규칙이 접속에 영향을 주는지 잠시 확인할 때는 전역 프록시로 바꿔 비교할 수 있습니다. 전역 프록시는 보통 코어에 들어온 연결을 프록시 경로로 보내는 기능이며, 기기의 모든 앱을 자동으로 처리하지는 않습니다. 규칙은 순서대로 적용되므로 범위가 넓은 규칙을 앞에 두면 뒤에 있는 세부 규칙이 적용되지 않을 수 있습니다. 최종 동작에는 기본 아웃바운드도 영향을 줍니다. 변경할 때 규칙 순서와 일치 조건, 아웃바운드 태그를 함께 확인하세요. 테스트가 끝나면 원래 모드로 되돌려 전역 모드에서 성공한 결과를 구독이나 DNS 문제까지 해결된 것으로 오해하지 않도록 하세요.

먼저 앱별 프록시의 전체 스위치가 켜져 있는지 확인하고 현재 모드의 의미를 정확히 읽으세요. 선택한 앱을 프록시로 보내는 모드와 선택한 앱을 프록시에서 제외하는 모드는 서로 반대입니다. 목록을 저장한 뒤 화면 안내에 따라 연결을 다시 시작하세요. 필요하면 테스트할 앱을 종료했다가 다시 열어 새 연결에 정책이 적용되도록 합니다. VPN 대상에 포함되지 않은 앱의 트래픽은 코어 라우팅에 들어가지 않으므로, 앱 목록 오류를 도메인 규칙 변경만으로 해결할 수 없습니다. 테스트할 때는 확인할 앱 하나를 정하고 여러 목록을 동시에 바꾸지 마세요. 버전에 따라 옵션 이름이 다를 수 있으니 체크박스 개수만 보지 말고 현재 화면의 설명을 따르세요.

먼저 앱이 도메인을 확인하는 방식, 코어가 사용하는 DNS 서버, 라우팅에서 도메인을 IP로 확인해야 하는지를 구분하세요. AsIs는 일반적으로 원래 도메인을 기준으로 먼저 일치 여부를 확인합니다. IPIfNonMatch는 도메인 규칙이 일치하지 않으면 IP 규칙에 맞추기 위해 조회를 시도합니다. IPOnDemand는 규칙을 적용하는 데 IP가 필요할 때 조회합니다. 이 전략만으로 시스템 전체의 DNS가 교체되지는 않습니다. 앱에서 자체 암호화 DNS를 사용한다면 트래픽 경로가 달라질 수도 있습니다. 일부 도메인이 열리지 않으면 먼저 조회 로그와 DNS 아웃바운드를 확인한 뒤 규칙을 조정하세요. DNS와 도메인 전략을 한꺼번에 모두 바꾸면 문제를 재현하기 어려워집니다.

일상적으로 연결할 서버를 고를 때는 단순 ping보다 실제 연결 지연 시간이 프록시 사용 경로에 가까운 지표입니다. 다만 실제 연결 지연 시간도 다운로드 속도를 뜻하지는 않습니다. ping은 보통 ICMP 왕복 시간을 측정하고, TCP 테스트는 포트 연결을 확인합니다. 실제 연결 테스트는 프록시 핸드셰이크와 테스트 대상의 응답까지 포함할 수 있습니다. 테스트 방식이나 대상이 다르면 결과를 직접 비교할 수 없습니다. 네트워크와 테스트 대상, 측정 방식을 고정하고 최저값 하나만 보지 말고 반복 측정하세요. 다운로드 속도는 서버 부하, 회선 손실, 대상 사이트의 영향을 받습니다. 지연 시간은 낮지만 처리량이 부족하다면 지속 전송 테스트를 따로 진행하세요. 목록의 숫자만으로 순위를 매기지 마세요.

로컬 네트워크 연결, 시스템 시간, 구독 상태, 연결 매개변수, 코어 로그 순서로 확인하세요. 먼저 프록시를 일시 중지해 기본 네트워크가 작동하는지 확인하고, 날짜와 시간대에 큰 차이가 없는지 살펴보세요. 다음으로 구독을 업데이트하고 주소, 포트, 프로토콜, 전송 방식, 보안 옵션, 서버 이름을 확인하세요. TCP 포트에 연결할 수 있다는 것은 전송 경로의 입구에 도달했다는 뜻일 뿐, 이후 인증까지 성공했다는 의미는 아닙니다. 로그에 시간 초과가 표시되면 다른 네트워크나 정상 작동이 확인된 설정과 비교하세요. 핸드셰이크 또는 인증 오류라면 매개변수를 다시 확인해야 합니다. 테스트마다 오류 유형과 바꾼 항목을 기록하세요. 서버와 DNS를 동시에 바꾸면 원인을 파악하기 어렵습니다.

연결됨 표시는 로컬 서비스나 Android VPN 인터페이스가 시작됐다는 뜻일 수 있지만, 서버와 대상 웹사이트에 모두 접속할 수 있다는 의미는 아닙니다. 먼저 대상 앱의 트래픽이 실제로 프록시로 전달되는지 확인하고, 접속 시 코어 로그가 생성되는지 살펴보세요. 로그가 없다면 시스템 프록시, 앱별 목록, TUN 트래픽 처리를 우선 확인하세요. DNS 오류가 있으면 도메인 조회 경로를 확인하고, 인증이나 핸드셰이크 오류가 있으면 서버 매개변수를 점검하세요. 일부 사이트만 실패한다면 라우팅 일치 규칙, 대상 사이트, 앱 캐시를 확인하세요. 같은 대상을 직접 연결한 경우와 프록시를 사용한 경우로 비교하세요. 한 웹페이지의 결과로 전체 네트워크 상태를 판단하거나 연결 아이콘만 보고 성공이라고 단정하지 마세요.

화면이 꺼진 뒤에만 연결이 끊기는지 확인하고, 앱을 다시 열었을 때 서비스가 계속 실행 중인지 살펴보세요. Android의 배터리 절약 정책은 백그라운드 활동을 제한할 수 있습니다. 시스템 설정에서 클라이언트의 백그라운드 실행을 허용하고, 기기에서 제공하는 배터리 최적화와 자동 시작 권한 옵션을 조정하세요. 상시 알림이 꺼져 있거나 백그라운드 앱이 정리되면 서비스 상태를 확인하기 어려울 수 있습니다. Android에서는 보통 활성 VPN을 하나만 사용할 수 있으므로 다른 VPN 앱을 시작하면 현재 연결이 대체될 수 있습니다. 모든 연결 끊김을 배터리 절약 탓으로 돌리지는 마세요. 화면이 켜져 있어도 실패한다면 네트워크 전환, 서버 상태, 코어 로그를 확인하고 각각의 발생 조건을 기록하세요.

인증서 검증을 끄는 것을 일반적인 해결 방법으로 사용해서는 안 됩니다. 먼저 시스템 시간, 서버 주소와 포트, 서버 이름, 보안 유형이 서버 설정과 일치하는지 확인하세요. 일반 TLS는 인증서 유효 기간과 신뢰 체인도 확인해야 합니다. REALITY는 공개 키, Short ID, 지문 등의 설정과 코어 지원 여부를 점검해야 하며, 일반 TLS의 인증서 문제 해결 방법을 그대로 적용할 수 없습니다. 매개변수는 구독에서 관리될 수 있으므로 먼저 업데이트하고 제공업체 안내와 대조하세요. 추측으로 항목을 하나씩 바꾸지 마세요. 같은 설정이 다른 기기에서 정상 작동하면 이 기기의 코어 버전과 네트워크 환경을 확인하세요. 진단 로그를 공개하기 전에는 주소, 식별 정보, 접속 자격 증명을 삭제하세요.