V2Ray 자주 묻는 질문

Windows, macOS, Linux 데스크톱에서는 v2rayN을 우선 고려하고, 프로세서 아키텍처와 운영체제에 맞는 설치 파일을 선택하세요. Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 선택하세요. 기존 설정이 V2Fly를 명시적으로 대상으로 한다면 v2flyNG를 대안으로 고려할 수 있습니다. 세 클라이언트 모두 GUI 방식으로 설정 가져오기, 서버 선택, 연결 관리를 지원합니다. 사용할 수 있는 프로토콜은 앱 이름만으로 판단할 수 없으며, 포함된 코어와 버전에 따라 달라집니다. 이전하기 전 서버에서 제공하는 프로토콜과 보안 계층 요구사항을 확인하세요.

클라이언트는 연결을 관리하는 도구입니다. 설치만으로 연결할 수 있는 서버가 생기는 것은 아닙니다. 연결하려면 서버 주소, 인증 정보, 포트, 프로토콜과 전송 설정이 필요하며, 보통 구독 주소, 공유 링크 또는 설정 파일로 제공됩니다. 구독은 서버 항목을 한곳에서 가져오고 업데이트하는 기능이지, 클라이언트가 서비스를 자동으로 제공한다는 뜻은 아닙니다. 사용 권한이 있고 신뢰할 수 있는 출처에서 설정을 받으세요. 다른 사람의 설정 전체를 공개 게시판에 복사하거나 출처가 불분명한 구독을 반복해서 가져와 테스트하지 마세요.

VMess, VLESS, Trojan, Shadowsocks는 프록시 프로토콜입니다. REALITY는 VLESS 등의 프로토콜과 함께 사용할 수 있는 보안 계층 방식이며, 모든 프로토콜 항목을 대체하는 범용 유형은 아닙니다. 설정을 가져올 때 전송 방식, TLS, SNI, 흐름 제어 항목도 함께 보일 수 있습니다. 각 항목은 연결의 서로 다른 계층을 나타냅니다. 서버에서 제공한 전체 설정에 맞춰 입력하고, 문제를 해결하려고 VLESS를 VMess로 바꾸거나 TLS를 REALITY로 임의 변경하지 마세요. 필요한 항목이 보이지 않으면 현재 클라이언트와 코어의 지원 여부부터 확인하세요.

시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 프록시 경로를 제공합니다. 모든 프로그램이 이를 사용하는 것은 아닙니다. TUN은 가상 네트워크 인터페이스를 통해 지정된 범위의 트래픽을 처리하며, 보통 추가 권한이 필요하고 다른 가상 네트워크 어댑터나 보안 소프트웨어의 영향을 받을 수 있습니다. 라우팅 모드는 코어에 들어온 요청을 직접 연결, 프록시 또는 차단 중 어디로 보낼지 결정합니다. 세 기능은 같은 스위치가 아닙니다. 라우팅을 전역 프록시로 설정해도 프록시 경로를 완전히 우회하는 프로그램까지 자동으로 처리하지는 않습니다. 문제를 확인할 때는 요청이 클라이언트에 들어오는지 먼저 확인한 다음 라우팅 경로를 살펴보세요.

2015년 이후 출시된 대부분의 Android 스마트폰에서는 arm64를 우선 고려할 수 있지만, 실제로 지원되는 앱 아키텍처를 기준으로 선택해야 합니다. universal은 여러 아키텍처용 구성 요소를 하나의 설치 파일에 포함하므로 아키텍처를 모르거나 여러 기기와 호환해야 할 때 적합하지만 파일 크기가 더 큰 편입니다. arm64 설치 시 호환되지 않는다는 메시지가 나오면 시스템 기기 정보에서 프로세서와 시스템 아키텍처를 확인한 뒤 universal 버전을 시도하세요. 휴대폰 브랜드나 구입 연도만으로 판단하지 마세요. 기존 앱 업데이트에 실패한다면 배포 출처의 서명이 같은지도 확인하세요.

먼저 가져오려는 항목이 구독 주소인지 단일 공유 링크인지 구분하고, 알맞은 가져오기 메뉴를 선택하세요. 구독 주소를 복사할 때 앞뒤 공백이나 줄바꿈이 들어갔는지, 설명 문구가 함께 복사되지는 않았는지 확인하세요. 웹페이지 주소가 실제 구독 주소인 것은 아닙니다. 클라이언트가 내용을 가져오지만 형식을 인식하지 못한다면 로그인 페이지나 오류 페이지가 반환됐거나 현재 버전에서 지원하지 않는 형식일 수 있습니다. 링크 끝부분만 보고 판단하지 말고 설정 제공자에게 클라이언트 호환 형식을 확인하세요. 구독 주소에는 접근 인증 정보가 들어 있는 경우가 많으므로 공개 변환 사이트에 붙여 넣거나 스크린샷으로 공유하지 마세요.

구독 그룹에 유효한 주소를 추가하고 업데이트하거나, 해당 메뉴에서 단일 공유 링크를 가져오세요. 목록에 서버 항목이 나타나면 하나를 활성 서버로 지정합니다. 그런 다음 코어를 시작하고 시스템 프록시 메뉴에서 시스템 프록시 자동 설정을 선택하세요. 시스템 프록시 설정을 따르는 브라우저로 테스트할 사이트에 접속합니다. 프로그램 아이콘만 확인하지 말고 로그에 해당 요청이 나타나는지 살펴보세요. 버전에 따라 메뉴 이름은 다를 수 있지만, 설정 가져오기, 서버 선택, 코어 시작, 트래픽 경로 설정, 실제 접속 확인 순서는 같습니다.

먼저 로그에서 가상 네트워크 어댑터 생성, 라우팅 설정, 백그라운드 서비스 시작 중 어떤 단계에서 오류가 발생했는지 확인하세요. Windows에서는 현재 버전 안내에 따라 관리자 권한이나 관련 서비스를 사용해야 할 수 있습니다. macOS와 Linux에서는 앱 안내에 따라 필요한 시스템 권한을 허용하세요. Android의 연결 권한은 시스템 VPN 승인으로 관리되므로 승인 창을 확인하고, 다른 앱이 같은 연결을 사용 중인지 살펴보세요. 문제를 확인하려고 모든 보안 기능을 끄지는 마세요. 권한을 허용한 뒤에도 실패한다면 가상 네트워크 어댑터 충돌을 확인하세요. 일시적으로 시스템 프록시로 전환하면 원인을 좁히는 데 도움이 됩니다.

v2rayN에서는 설정 출처별로 구독 그룹을 만들고 각 그룹에 주소를 입력할 수 있습니다. 그룹이나 메모 키워드로 서버 항목을 필터링할 수도 있습니다. 업데이트하면 보통 구독 출처의 내용과 다시 동기화되므로 제공자가 서버를 삭제하거나 이름을 바꾸거나 구성을 조정하면 기존 위치에 표시되지 않을 수 있습니다. 로컬 필터 때문에 항목이 일시적으로 숨겨졌을 수도 있습니다. 먼저 필터를 해제하고 올바른 그룹을 선택한 뒤 업데이트 로그를 확인하세요. 수동으로 관리할 항목은 별도로 관리해 중요한 변경 사항이 구독 동기화 항목에만 저장되지 않도록 하세요. 항목 보존 방식은 클라이언트 버전에 따라 다를 수 있습니다.

먼저 클라이언트 기본 라우팅으로 같은 결과를 반복해서 확인할 수 있는 상태를 만드세요. 그다음 실제 필요에 따라 도메인 규칙과 DNS를 조정합니다. 특정 사이트에서 문제가 발생하면 로그에 표시된 도메인, 적용된 규칙, 출구 방향을 기록하고 실수로 직접 연결되는지 확인한 뒤 DNS 응답과 원격 DNS 연결을 점검하세요. 라우팅 템플릿, DNS 주소, 도메인 정책을 한꺼번에 바꾸면 원인을 파악하기 어렵습니다. geosite와 geoip 데이터도 규칙 적용 결과에 영향을 주므로 규칙 데이터를 업데이트한 뒤 다시 테스트하세요. 모든 요청을 같은 경로로 보내는 방법은 비교용으로만 사용하고, 원인 분석을 대신하지는 마세요.

화면 잠금, 네트워크 전환, 시스템의 백그라운드 앱 정리 중 언제 연결이 끊기는지 먼저 확인하세요. Android 배터리 설정에서 v2rayNG의 백그라운드 실행이 제한되어 있는지 살펴보고, 기기에서 제공하는 옵션으로 필요한 백그라운드 활동을 허용하세요. 앱의 VPN 권한이 유지되고 있는지, 다른 네트워크 도구가 연결을 대신 처리하고 있는지도 확인하세요. 절전 설정을 한꺼번에 모두 끄지 말고 v2rayNG 설정만 조정한 뒤 다시 테스트하세요. 앱은 실행 중인데 요청이 실패한다면 네트워크가 바뀌면서 연결을 다시 설정해야 할 수 있습니다. 로그와 재연결 후 결과를 함께 확인하세요.

먼저 구독 출처, 수동으로 추가한 서버, 라우팅 변경 사항, DNS 설정을 기록한 뒤 현재 클라이언트가 지원하는 내보내기 기능으로 필요한 내용을 저장하세요. 구독 주소로 서버 항목을 다시 가져올 수는 있지만, 로컬 그룹 순서, 메모 수정, 앱 환경설정까지 모두 복원되지는 않는 경우가 많습니다. 기본 JSON 설정도 다른 코어에서 그대로 사용할 수 있다고 보장할 수 없습니다. 이전한 뒤 프로토콜, 보안 계층, 전송 항목을 확인하세요. 내보낸 파일과 공유 링크에는 인증 정보가 포함될 수 있으므로 안전한 위치에 보관하고 공개 문서에 올리지 마세요. 새 기기에서 정상 연결을 확인한 뒤 기존 기기의 민감한 사본을 정리하세요.

먼저 업데이트 로그에서 도메인 조회 실패, 연결 시간 초과, 접근 거부, 내용 분석 실패를 구분하세요. 구독이 아직 유효한지, 계정 페이지에서 주소를 새로 발급해야 하는지 확인합니다. 현재 활성 서버를 사용할 수 없고 구독 업데이트가 그 프록시에 의존한다면 업데이트 옵션에서 프록시를 사용하지 않도록 설정해 보세요. 해당 주소에 직접 연결할 수 없다면 사용할 수 있는 연결 경로가 필요합니다. 가져오기는 성공했지만 내용 분석에 실패하면 반환 형식이 클라이언트와 호환되는지 확인하세요. 무작위 DNS를 반복해서 바꾸거나 그룹을 한꺼번에 삭제하지 말고 기존 주소와 오류 정보를 먼저 보존하세요.

반드시 그렇지는 않습니다. 테스트 방식에 따라 특정 포트만 확인하거나 프록시를 통해 지정된 테스트 주소에 접속할 수 있으며, 결과는 로컬 네트워크, 테스트 대상, 프로토콜 핸드셰이크의 영향을 함께 받습니다. 먼저 일반 네트워크가 정상인지 확인하고, 정상 작동이 확인된 다른 설정과 비교한 뒤 실제 웹사이트 접속도 시도하세요. 한 항목만 문제가 있다면 서버 주소, 포트, 인증 정보, 보안 계층 설정을 확인하세요. 모든 항목에서 실패한다면 로컬 방화벽, 네트워크 환경, 코어 실행 여부를 먼저 점검하세요. 테스트 버튼을 계속 눌러도 잘못된 설정은 고쳐지지 않습니다. 같은 시간대의 로그를 보관하면 원인을 찾는 데 도움이 됩니다.

연결됨 표시는 보통 로컬 서비스나 가상 인터페이스가 시작되었다는 뜻이지, 서버 핸드셰이크와 웹사이트 접속까지 성공했다는 의미는 아닙니다. 먼저 로그에 브라우저 요청이 있는지 확인하세요. 요청이 없다면 시스템 프록시 설정, 브라우저 자체 프록시 설정, 프록시 경로를 바꾸는 다른 도구를 점검하세요. 요청이 있다면 적용된 라우팅, DNS, 출구 오류를 확인합니다. 다른 설정과 다른 사이트로 교차 테스트해 볼 수도 있습니다. 클라이언트를 종료하기 전에 메뉴에서 시스템 프록시를 해제하세요. 비정상 종료 후 일반 인터넷도 되지 않는다면 종료된 로컬 포트를 가리키는 프록시 설정이 시스템에 남아 있는지 확인하세요.

로그 창에서 처음 실패한 시점 전후의 오류 메시지를 빠짐없이 확인하세요. 주소가 이미 사용 중이라는 오류가 나오면 클라이언트가 중복 실행됐거나 다른 프로그램이 로컬 수신 포트를 사용 중인지 확인하세요. 설정 항목 오류라면 가져온 형식과 현재 코어의 지원 범위를 점검합니다. TLS 인증서 오류는 먼저 시스템 시간을 동기화하고 서버 이름, SNI, 인증서 도메인이 일치하는지 확인하세요. 인증서 검증을 건너뛰는 방법을 장기적인 해결책으로 사용하지 마세요. 다른 사람에게 도움을 요청하기 전 구독 주소, 인증 정보, 개인 경로를 가리고 오류 유형, 관련 항목 이름, 필요한 시스템·클라이언트 정보만 남기세요.