클라이언트 설정 참고 / FAQ

V2Ray 자주 묻는 질문
구독·프록시·연결 문제 해결

v2rayN·v2rayNG·v2flyNG를 위한 안내입니다. 구독 가져오기, 코어 연결, 앱 트래픽 처리 과정을 구분한 뒤 오류가 발생한 단계부터 확인하세요.

처음 설정한다면: 사용 가이드 보기
개념과 역할

기본 개념

클라이언트, 코어, 서버를 구분하고 각 계층의 역할을 확인하세요.

용어집 보기 →
V2Ray, Xray와 세 클라이언트는 어떤 관계인가요?

Project V는 관련 프록시 도구 생태계의 배경이며, V2Fly와 Xray는 공통된 역사를 지닌 코어 프로젝트입니다. 코어는 프로토콜 처리, 라우팅, 연결을 담당하고 클라이언트는 구독 관리, 인터페이스, 시스템 연동을 담당합니다. v2rayN은 데스크톱 플랫폼용이며, 사용할 수 있는 코어 기능은 선택한 코어와 버전에 따라 다릅니다. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 문제를 해결할 때는 클라이언트와 코어 정보를 함께 기록하세요. 클라이언트 이름만으로는 특정 설정의 지원 여부를 판단하기 어렵습니다.

클라이언트를 설치한 뒤 무엇을 더 준비해야 하나요?

클라이언트는 프록시 연결을 설정하고 실행하는 도구일 뿐, 설치만으로 사용할 수 있는 서버가 생기지는 않습니다. 사용 권한이 있는 구독 주소나 공유 링크, 또는 서버 설정 전체를 준비해야 합니다. 직접 설정한다면 주소, 포트, 프로토콜, 인증 정보를 확인하고 TLS나 REALITY를 사용하는 경우 관련 보안 설정도 점검하세요. 구독 주소에는 대개 접속 정보가 포함되므로 민감 정보로 취급해야 합니다. 스크린샷, 로그, 문의 내용에는 전체 주소와 사용자 식별 정보, 인증 항목이 드러나지 않도록 가리세요.

VMess·VLESS·Trojan·REALITY는 어떻게 구분하나요?

VMess, VLESS, Trojan은 클라이언트에서 선택하는 프록시 프로토콜입니다. REALITY는 VLESS 등과 함께 사용하는 전송 보안 방식으로, 앞의 세 프로토콜과 같은 수준에서 직접 대체할 수 있는 선택지가 아닙니다. 설정은 서버와 일치해야 하므로 이름만 바꾸려고 프로토콜 드롭다운만 변경해서는 안 됩니다. 먼저 서버에서 실제로 제공하는 설정을 확인하고 현재 코어의 지원 여부를 살펴보세요. VLESS의 암호화 항목만으로 연결 전체의 보안 상태를 판단할 수는 없으며, TLS·REALITY 등의 설정도 함께 확인해야 합니다.

구독 주소, 공유 링크, 설정 파일은 어떻게 다른가요?

구독 주소는 제공처에서 여러 서버 설정을 가져오는 데 사용하며, 제공처의 내용이 바뀌면 업데이트할 수 있습니다. 공유 링크는 보통 서버 하나의 정보를 담고 있으며, 가져온 뒤 자동 업데이트가 설정되는 것은 아닙니다. 설정 파일에는 아웃바운드, DNS, 라우팅 등 더 많은 정보가 담길 수 있지만, 전체를 가져올 수 있는지는 클라이언트가 지원하는 파일 형식에 따라 다릅니다. 브라우저에서 주소가 열린다고 해서 호환되는 구독 정보가 반환되는 것은 아닙니다. 웹페이지, 로그인 화면, 오류 페이지는 서버 목록으로 가져올 수 없습니다.

시스템 프록시, TUN, Android VPN 모드는 같은 기능인가요?

시스템 프록시는 시스템 설정을 따르는 앱에 프록시 경로를 제공하지만 모든 프로그램의 트래픽을 가로채지는 않습니다. TUN은 가상 네트워크 인터페이스로 트래픽을 받아 처리하며, 보통 라우팅과 DNS 설정 및 높은 권한이 필요합니다. Android 클라이언트의 VPN 모드는 시스템 가상 네트워크 인터페이스를 이용해 선택한 앱의 트래픽을 처리합니다. VPN 표시가 나타나도 인터페이스가 만들어졌다는 뜻일 뿐입니다. 어느 방식도 모든 요청이 반드시 프록시를 거친다는 의미는 아니며, 최종 경로는 라우팅 규칙, 우회 목록, 앱별 설정에 따라 달라집니다.

설치와 트래픽 처리

설치 및 설정

설치 파일 아키텍처부터 프록시 경로까지, 최소한의 작동 설정을 구성하세요.

클라이언트 옵션 보기 →
구독 가져오기에 실패하면 형식과 네트워크 중 무엇부터 확인해야 하나요?

먼저 가져오기 방식을 구분하세요. 서버 하나의 공유 링크는 클립보드나 공유 링크 메뉴에서 가져오고, 구독 주소는 구독 그룹에 추가한 뒤 업데이트해야 합니다. 복사 과정에서 공백, 줄바꿈, 설명 문구가 섞이지 않았는지, 관리 페이지를 구독 주소로 착각하지 않았는지 확인하세요. 그다음 연결 실패, 인증 실패, 내용 파싱 실패 중 어떤 오류인지 살펴보면 네트워크, 권한, 형식 문제를 구분할 수 있습니다. 구독 파싱 오류를 해결하려고 서버 프로토콜을 계속 바꾸지 마세요. 두 작업은 서로 다른 단계에서 처리됩니다.

Android 설치 파일은 arm64와 universal 중 무엇을 선택해야 하나요?

프로세서의 홍보 명칭보다 기기가 지원하는 앱 ABI를 기준으로 선택하세요. 최근의 일반적인 기기라면 보통 arm64를 선택할 수 있습니다. 아키텍처를 확인하기 어렵다면 여러 아키텍처를 포함하는 universal 패키지를 선택할 수 있지만, 저장 공간을 더 많이 차지하는 편입니다. 64비트 칩을 사용해도 시스템에서 32비트 앱만 설치할 수 있는 기기도 있습니다. 설치에 실패하면 시스템 버전과 여유 공간, 기존 앱의 서명이 설치 파일과 일치하는지도 확인하세요. 설정이 사라질 수 있으니 기존 앱을 바로 삭제하지 마세요.

v2rayN 데스크톱 버전과 클래식 WPF 버전 중 무엇을 선택해야 하나요?

데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하고, 클래식 WPF 버전은 Windows의 전통적인 인터페이스에 익숙한 사용자를 위한 버전입니다. 먼저 다운로드 페이지에서 운영체제와 아키텍처를 확인한 다음 인터페이스 버전을 선택하세요. 인터페이스 차이를 프로토콜 성능 차이로 오해해서는 안 됩니다. 두 버전은 메뉴 위치, 백업 항목, 설정 폴더가 다를 수 있으므로 이전하기 전에 설정을 내보내고 사용자 지정 라우팅, DNS, 로컬 수신 포트를 기록하세요. 시작 문제가 발생하면 해당 설치 파일의 안내에 따라 실행 환경을 확인하고, 서로 다른 설치 폴더의 파일을 섞어 사용하지 마세요.

시스템 프록시를 켰는데도 일부 프로그램이 직접 연결되는 이유는 무엇인가요?

먼저 클라이언트 코어가 실행 중인지, 로컬 수신 주소와 포트가 시스템 프록시 설정과 일치하는지 확인한 다음 대상 프로그램이 시스템 프록시를 따르는지 살펴보세요. 일부 명령줄 도구와 다운로드 도구, 별도의 네트워크 설정을 사용하는 앱은 따로 설정해야 합니다. 브라우저 확장 프로그램이 시스템 설정을 덮어쓸 수도 있습니다. 시스템 프록시를 확실히 따르는 앱으로 먼저 테스트한 뒤, 라우팅에서 대상 도메인이 직접 연결로 지정되어 있는지 확인하세요. 더 많은 트래픽을 처리해야 한다면 TUN 사용을 검토하되, 프록시 경로를 여러 개 겹쳐 연결이 되돌아오는 상황은 피하세요.

TUN이 시작되지 않거나 권한 부족 메시지가 나타나면 어떻게 해야 하나요?

로그에서 가상 인터페이스 생성, 권한 요청, 라우팅 설정 중 어느 단계에서 실패했는지 먼저 확인하세요. Windows에서는 클라이언트 안내에 따라 필요한 권한을 허용하고, macOS와 Linux에서는 해당 플랫폼의 안내에 따라 권한을 부여하세요. 다른 운영체제의 드라이버 설정을 그대로 따라 해서는 안 됩니다. 가상 네트워크 인터페이스를 사용하거나 기본 경로를 변경하는 다른 도구를 잠시 종료한 뒤 다시 테스트하세요. 권한 문제를 해결하려고 방화벽을 계속 꺼두지 마세요. 브라우저 프록시만 필요하다면 시스템 프록시로 서버가 정상 작동하는지 먼저 확인할 수 있습니다.

그룹과 정책

사용 팁

구독과 로컬 정책을 분리해 업데이트와 기기 이전 중 설정이 예기치 않게 바뀌는 일을 줄이세요.

프로토콜 안내서 보기 →
구독을 업데이트하면 직접 추가한 서버가 덮어써지나요?

업데이트는 대개 해당 구독 그룹에 적용되지만, 기존 항목을 교체하거나 유지하고 중복을 제거하는 방식은 클라이언트와 설정에 따라 다릅니다. 직접 만든 설정은 별도 그룹에 넣으세요. 구독에서 생성된 항목을 직접 수정한 뒤 다음 업데이트에도 유지될 것이라고 가정하지 마세요. 업데이트 전에 중요한 설정을 백업하고, 업데이트 후에는 현재 그룹과 필터 조건, 기본 서버가 바뀌었는지 확인하세요. 목록에서 항목이 보이지 않아도 그룹이나 필터 조건이 달라졌을 수 있습니다. 먼저 필터를 해제해 확인하고, 모든 설정을 지운 뒤 다시 가져오지는 마세요.

규칙 모드와 글로벌 프록시는 언제 전환해야 하나요?

일상적으로는 규칙 모드를 사용해 대상별로 직접 연결, 프록시, 차단 아웃바운드를 지정할 수 있습니다. 글로벌 프록시는 분기 규칙이 문제인지 확인하는 짧은 비교 테스트에 사용할 수 있지만, 클라이언트에 들어오지 않은 앱 트래픽까지 바꾸지는 않을 수 있습니다. 글로벌 프록시에서는 작동하고 규칙 모드에서 실패한다면 서버를 바꾸기 전에 규칙 순서, 도메인 일치 여부, 최종 아웃바운드를 확인하세요. 테스트가 끝나면 원래 모드로 되돌리고, 로컬 네트워크 서비스와 기기 접근이 예상대로 되는지도 확인하세요.

Android 앱별 프록시에서 앱을 빠뜨리지 않으려면 어떻게 해야 하나요?

현재 목록이 선택한 앱만 프록시를 사용하는 방식인지, 선택한 앱을 우회하는 방식인지 먼저 확인하세요. 두 방식은 동작이 반대입니다. 변경 사항을 적용한 뒤에는 클라이언트 안내에 따라 연결을 다시 설정해 새 앱 범위를 적용하세요. 앱은 별도 구성 요소나 업무 프로필의 앱 복사본, 시스템 서비스를 통해 요청을 보낼 수 있으므로 기본 앱만 선택해도 관련 프로세스가 모두 포함된다고 볼 수 없습니다. 테스트할 때는 대상 앱 하나로 범위를 좁혀 트래픽 경로를 확인한 뒤 목록을 늘리세요. 앱별 범위, DNS, 서버를 동시에 자주 바꾸면 차이를 파악하기 어려워집니다.

Mux 다중화를 항상 켜 두어야 하나요?

Mux는 적은 수의 하위 연결에 여러 논리 연결을 실으려는 기능이지만, 효과는 프로토콜, 전송 방식, 서버, 사용 환경에 따라 달라지며 항상 속도를 높여 주는 설정은 아닙니다. 지원되지 않거나 권장되지 않는 조합도 있으므로, 특히 VLESS 흐름 제어와의 조합은 현재 코어의 안내를 따르세요. 끊김이나 지연을 해결할 때는 먼저 Mux를 끄고 기준 상태를 만든 다음, 같은 작업에서 Mux를 켠 결과와 비교하세요. 모바일 배터리 사용량은 신호 상태, 지속적인 데이터 전송, 백그라운드 실행에도 영향을 받으므로 설정 상태만으로 배터리 지속 시간을 판단할 수 없습니다.

데스크톱과 Android 간 설정을 안전하게 동기화하려면 어떻게 해야 하나요?

같은 제공처에서 관리하는 서버라면 양쪽 기기에서 구독 주소를 각각 가져와 별도로 업데이트하는 방법이 좋습니다. 직접 만든 서버 설정 하나를 옮길 때는 공유 링크나 QR 코드를 사용할 수 있지만, 프로토콜과 전송 항목이 모두 보존되었는지 확인하세요. 클라이언트 백업 파일은 기기 간 호환을 보장하지 않으며, 데스크톱의 라우팅·DNS·수신 포트와 Android의 앱별 설정도 자동으로 연결되지 않습니다. 이전할 때는 서버 하나를 먼저 검증한 뒤 로컬 정책을 하나씩 다시 설정하세요. 구독과 백업은 안전한 경로로 전달하고, 인증 정보가 포함된 파일을 공개된 곳에 올리지 마세요.

요청 경로별 점검

문제 해결

앱의 프록시 경로부터 DNS, 라우팅, 원격 핸드셰이크까지 단계별로 범위를 좁히세요.

관련 글 보기 →
서버 테스트가 시간 초과되면 어떤 순서로 점검해야 하나요?

먼저 기기의 일반 네트워크가 정상인지 확인한 뒤 서버 주소와 포트, 인증 정보, 기기 시간을 점검하세요. TCP 연결 테스트와 실제 프록시 요청 테스트는 구분해야 합니다. 포트에 연결된다고 해서 프로토콜 핸드셰이크와 대상 사이트 접속까지 성공하는 것은 아니며, 특정 테스트가 시간 초과되어도 모든 앱을 사용할 수 없는 것은 아닙니다. 로그에서 도메인 조회, 연결 거부, 핸드셰이크 실패 여부를 확인하고 해당 설정과 대조하세요. 정상 작동하는 것으로 확인된 설정 하나를 비교 대상으로 사용할 수 있습니다. 네트워크와 여러 보안 설정을 동시에 바꾸지 마세요.

클라이언트에는 연결됨으로 표시되지만 웹페이지가 열리지 않을 때는 어떻게 하나요?

연결됨 표시는 코어나 가상 네트워크 인터페이스가 시작되었다는 뜻일 뿐, 원격 연결이 성공했다는 보장은 아닙니다. 먼저 실제 웹 요청이 로그에 기록되는지 확인하세요. 기록이 없다면 앱의 프록시 경로, VPN 권한, 앱별 범위를 확인하고, 기록은 있지만 요청이 실패한다면 아웃바운드 선택, DNS, 핸드셰이크 정보를 점검하세요. 다른 대상에도 접속해 특정 사이트 문제인지 전반적인 문제인지 구분하세요. 브라우저에서만 문제가 발생한다면 확장 프로그램, 사용자 지정 보안 DNS, 캐시도 확인하세요. 처음부터 클라이언트 데이터를 모두 지우지는 마세요.

구독 업데이트는 실패하지만 기존 서버는 계속 작동하는 이유가 무엇인가요?

구독을 가져오는 경로와 서버에 연결하는 경로는 서로 다릅니다. 기존 설정이 작동해도 구독 제공처에 접속할 수 있다는 뜻은 아닙니다. 구독이 만료되었는지, 권한이 변경되었는지 확인하고 로그에 HTTP 상태 오류, 인증서 오류, 파싱 실패가 있는지 살펴보세요. 업데이트 경로에서 직접 연결과 프록시를 선택할 수 있다면 실제 네트워크 환경에 맞춰 비교하되, 작동하지 않는 서버를 통해 업데이트하는 방식에 의존하지 마세요. 기존 그룹을 먼저 삭제하지 말고, 사용할 수 있는 설정과 백업을 보존하세요. 제공처가 호환되는 내용을 반환하는 것을 확인한 뒤 업데이트하세요.

DNS 문제와 서버 연결 문제를 어떻게 구분하나요?

먼저 로그에서 도메인 조회 전후 어느 단계에서 실패하는지 확인하세요. 조회 실패, 빈 결과 반환, DNS 서버에 연결할 수 없는 경우에는 DNS 경로부터 살펴보세요. 주소를 받은 뒤 연결 거부나 핸드셰이크 오류가 발생하면 원격 연결을 계속 확인해야 합니다. 로컬 DNS와 원격 DNS 요청이 각각 어디로 향하는지, 클라이언트가 시스템의 DNS 조회를 처리하는지도 점검하세요. 브라우저의 보안 DNS는 별도로 요청을 보낼 수 있으므로 함께 확인해야 합니다. IP 주소로 직접 접속한 결과만으로 판단하지 마세요. HTTPS는 올바른 도메인과 인증서가 필요할 수 있습니다.

클라이언트를 종료한 뒤 네트워크에 문제가 생기면 어떻게 복구하나요?

먼저 시스템이 여전히 클라이언트의 로컬 프록시 포트를 가리키는지 확인하세요. 프로세스는 종료됐는데 프록시 설정이 남아 있으면 앱은 존재하지 않는 프록시 경로에 계속 연결을 시도합니다. 클라이언트의 시스템 프록시 해제 기능을 사용하거나 시스템 네트워크 설정에서 이전 설정을 복원하세요. TUN을 사용했다면 가상 인터페이스, 기본 경로, DNS도 정상적으로 복원되었는지 확인하고 필요하면 시스템 방식으로 네트워크에 다시 연결하세요. 조작하기 전에 기존 회사 프록시나 사용자 지정 DNS를 기록해 두어 필요한 설정까지 지우지 않도록 하세요.