V2Ray / FAQ
V2Ray 자주 묻는 질문
구독, 연결, 프록시 설정 문제를 증상별로 찾아보세요.
먼저 기본 연결을 확인한 뒤 트래픽 처리 방식을 점검하세요. 한 번에 설정 하나만 바꾸고 문제를 재현할 수 있는 테스트 조건을 유지하세요.
V2Ray, Xray, v2rayN, v2rayNG는 각각 무엇인가요?
먼저 코어와 GUI 클라이언트를 구분해야 합니다. V2Ray는 Project V 생태계에 속하며, V2Fly는 관련 코어 개발을 이어가고 있습니다. Xray는 별도의 코어 포크로, 두 코어가 지원하는 기능과 설정 세부 사항은 완전히 같지 않습니다. v2rayN은 구독 관리, 서버 선택, 라우팅, 코어 실행을 담당하는 데스크톱 GUI 클라이언트입니다. v2rayNG는 주로 Android에서 사용하며 Xray 코어를 사용합니다. v2flyNG는 V2Fly 코어를 사용하는 대안입니다. 설정을 가져오기 전에 클라이언트와 실제 실행할 코어가 해당 설정을 지원하는지 모두 확인하세요. GUI가 있다고 해서 그 안의 모든 코어가 모든 프로토콜 조합을 지원하는 것은 아닙니다.
클라이언트를 설치했는데 사용할 서버가 없는 이유는 무엇인가요?
클라이언트는 설정을 읽어 연결을 만드는 프로그램이며, 설치만으로 원격 서비스가 자동 제공되지는 않습니다. 사용 권한이 있는 구독 주소나 단일 노드 공유 링크, 또는 서비스 운영자가 제공한 연결 정보를 준비해야 합니다. 구독은 여러 설정을 한 번에 가져오고 이후 업데이트할 때 주로 사용하며, 단일 노드 링크는 하나의 연결 설정을 담습니다. 두 항목은 가져오기 메뉴를 임의로 바꿔 사용할 수 없습니다. 이 사이트는 클라이언트 다운로드와 사용 안내를 제공하며 노드 계정은 제공하지 않습니다. 목록이 비어 있다면 먼저 설정을 가져왔는지 확인하세요. 목록은 있지만 모두 연결에 실패한다면 클라이언트를 반복해서 재설치하기보다 서비스 유효 기간, 연결 정보, 로컬 네트워크를 점검하세요.
VMess, VLESS, Trojan, REALITY는 자유롭게 바꿔 쓸 수 있나요?
클라이언트에서 프로토콜 이름만 바꿔서는 안 됩니다. VMess, VLESS, Trojan 등의 연결 방식은 서버 설정과 일치해야 하며 인증 정보, 전송 방식, TLS 설정도 서로 맞아야 합니다. REALITY는 전송 보안 방식으로, 이 프로토콜들과 완전히 같은 계층에서 독립적으로 바꿔 끼우는 항목이 아닙니다. 일반적으로 특정 VLESS 조합에 사용됩니다. 서버에서 REALITY를 요구한다면 공개 키, 짧은 ID, 서버 이름, 흐름 제어 등의 항목을 확인하고 코어가 지원하는지도 점검하세요. 지원되지 않는 조합이라면 매개변수를 하나씩 추측하기보다 호환되는 클라이언트와 코어로 업데이트하거나 서비스 운영자에게 호환 설정을 요청하세요.
핑 테스트에 숫자가 표시되면 노드로 인터넷을 정상적으로 사용할 수 있나요?
반드시 그렇지는 않습니다. TCP 연결 테스트는 보통 대상 포트에 연결할 수 있다는 뜻일 뿐, 프록시 인증과 TLS 핸드셰이크, DNS 조회, 웹 요청까지 성공한다는 의미는 아닙니다. 실제 연결 테스트는 더 많은 단계를 거치지만 테스트 주소, 라우팅, 현재 네트워크의 영향을 받습니다. 클라이언트가 어떤 테스트를 제공하는지 확인한 뒤 같은 설정을 선택해 실제 연결을 테스트하고, 실제로 사용하려는 웹사이트에도 접속해 보세요. 테스트 방식이 다른 결과끼리 수치를 직접 비교하거나 한 번의 시간 초과만으로 노드가 영구적으로 사용할 수 없다고 판단하지 마세요. TCP 연결은 되는데 실제 요청이 실패한다면 코어 로그에서 인증, 핸드셰이크, DNS 조회 오류를 확인하세요.
v2rayNG 또는 v2rayN에서 구독을 가져온 뒤 노드가 보이지 않으면 무엇을 확인해야 하나요?
먼저 복사한 내용이 구독 주소 전체인지 확인하고, 앞뒤 공백이나 줄바꿈, 누락된 쿼리 매개변수가 없는지 살펴보세요. v2rayN은 보통 구독 그룹 설정에서 주소를 저장한 뒤 해당 그룹을 업데이트해야 합니다. v2rayNG는 구독 그룹 설정에 주소를 추가하고 구독 업데이트를 실행합니다. 주소만 저장하고 업데이트하지 않으면 서버 목록이 생성되지 않습니다. 입력한 주소가 vmess:// 또는 vless://로 시작하는 단일 노드 링크라면 클립보드 가져오기 메뉴를 사용하세요. 업데이트 후에도 목록이 비어 있다면 다른 그룹을 선택했거나 목록 필터가 켜져 있는지 확인하고, 응답 내용이 로그인 페이지나 오류 페이지 또는 호환되지 않는 구독 형식인지 점검하세요.
구독 업데이트에 실패하면 기존 구독 그룹을 먼저 삭제해야 하나요?
일시적인 업데이트 오류 때문에 연결 수단을 모두 잃지 않도록 기존 그룹과 여전히 사용할 수 있는 설정은 그대로 두세요. 업데이트 오류 메시지를 확인하세요. 파싱 오류라면 응답 형식을, 연결 시간 초과라면 현재 네트워크와 업데이트 요청의 경로를 점검해야 합니다. 인증 오류가 발생하면 구독이 만료되었거나 주소가 변경되었는지 확인하세요. 클라이언트에 프록시를 통한 업데이트 옵션이 있다면 사용 가능한 프록시가 있을 때만 시도하세요. 현재 프록시 자체에 문제가 있다면 직접 연결로 업데이트하는 편이 나을 수 있습니다. 한 번에 조건 하나만 바꾸고 다시 시도하세요. 구독 주소에는 다른 사람이 서비스 설정을 읽을 수 있는 인증 정보가 포함될 수 있으니 공개 게시판에 전체 주소를 올리지 마세요.
Android 설치 파일은 arm64와 universal 중 무엇을 선택해야 하나요?
시스템이 64비트 ARM 앱을 지원하는 것을 확인했다면 arm64를 우선 선택하세요. 기기의 아키텍처를 모르거나 여러 기기에서 사용할 파일이 필요하다면 universal 패키지를 선택할 수 있습니다. 최근 출시된 대부분의 스마트폰은 arm64를 지원하지만, 하드웨어가 64비트를 지원한다고 해서 설치된 시스템도 반드시 64비트 앱 환경을 제공하는 것은 아닙니다. 구형 기기나 커스텀 시스템은 특히 확인이 필요합니다. 설치 중 호환되지 않는다는 메시지가 나오면 출처가 불분명한 파일을 계속 시도하지 말고 시스템 버전과 앱의 아키텍처 요구 사항을 확인하세요. universal은 일반적으로 파일 크기가 더 크지만 연결 속도가 빨라지는 것은 아닙니다. 서명이 다른 출처의 앱으로 바꾸면 서명 충돌이 생길 수 있으므로 삭제 전에 필요한 설정을 백업하세요.
TUN 모드를 켤 때 권한 부족 메시지가 표시되면 어떻게 해야 하나요?
TUN은 가상 네트워크 인터페이스를 만들고 일부 네트워크 경로를 변경하므로 일반적으로 시스템 프록시보다 높은 권한이 필요합니다. 데스크톱에서는 클라이언트를 종료한 뒤 운영체제에 맞게 관리자 권한으로 실행하거나 클라이언트의 서비스 설치 절차를 완료하세요. 메뉴 위치는 버전에 따라 다를 수 있습니다. Android에서는 보통 시스템 VPN 권한을 요청하므로 연결 요청 내용을 확인한 뒤 승인하고, 다른 앱이 VPN 연결을 사용 중인지도 살펴보세요. 권한을 허용한 뒤에도 실패하면 로그에서 가상 네트워크 어댑터, 라우트 생성, 포트 충돌 관련 오류를 확인하세요. 안내를 우회하려고 보안 기능을 통째로 끄지는 마세요. 문제를 해결하는 동안에는 TUN을 끄고 기본 프록시 연결이 되는지 확인한 뒤 트래픽 가로채기 권한을 점검하세요.
시스템 프록시와 TUN 모드는 어떻게 다르며, 둘 다 켜야 하나요?
시스템 프록시는 시스템 프록시 설정을 따르는 앱에 연결 경로를 제공하지만, 모든 프로그램이 이를 사용하는 것은 아닙니다. TUN은 가상 네트워크 인터페이스를 통해 설정에 맞는 트래픽을 처리하므로 보통 더 많은 앱에 적용되지만 라우팅과 DNS 문제 해결이 복잡해질 수 있습니다. 처음에는 시스템 프록시로 연결을 확인한 다음 앱 요구 사항에 따라 TUN을 사용해 보세요. 여러 옵션을 한꺼번에 켜지 않는 것이 좋습니다. 두 방식을 함께 사용할 때의 동작은 클라이언트마다 다르므로 현재 버전의 안내를 확인하세요. 연결이 반복되거나 트래픽이 중복으로 처리된다면 한 가지 방식만 남기고 다른 프록시 도구, 브라우저 확장 프로그램, 앱 자체 프록시가 실행 중인지 점검하세요.
전역 프록시와 규칙 기반 분할 라우팅 중 무엇을 선택해야 하나요?
일상적인 사용은 클라이언트에서 제공하는 규칙 기반 분할 라우팅으로 시작하세요. 규칙에 일치하는 요청을 프록시 또는 직접 연결로 보낼 수 있습니다. 전역 프록시는 문제가 분할 라우팅 규칙 때문인지 임시로 확인할 때 유용하지만, 대개 클라이언트에 들어온 뒤의 라우팅 결정만 바꾸며 모든 앱의 트래픽을 처리하는 것은 아닙니다. 모드를 바꾸기 전에 현재 설정을 기록하고 같은 웹사이트를 테스트한 뒤 로그를 통해 실제 연결 경로를 확인하세요. 분할 라우팅, DNS, 코어를 동시에 변경하면 어느 설정이 영향을 줬는지 알기 어렵습니다. 특정 도메인 하나만 잘못된 경로로 연결된다면 전체 트래픽 처리 방식을 바꾸기보다 해당 도메인의 규칙과 규칙 순서를 확인하세요.
V2Ray 노드 속도를 제대로 측정해 참고할 만한 결과를 얻으려면 어떻게 해야 하나요?
먼저 지연 시간과 처리량을 구분하세요. 핸드셰이크가 빠르다고 계속 빠르게 다운로드되는 것은 아니며, 다운로드 속도가 높아도 상호작용 요청이 안정적이라는 보장은 없습니다. 테스트할 때는 가능한 한 로컬 네트워크, 서버 설정, 테스트 대상, 시간을 동일하게 유지하고 다른 대용량 작업은 멈추세요. 여러 노드를 동시에 테스트하면 대역폭을 나눠 써 결과가 서로 영향을 줄 수 있으니 하나씩 측정하세요. 실제 연결 테스트로 사용 가능 여부를 확인한 다음 실제 사용 환경이나 신뢰할 수 있는 속도 측정 대상으로 지속 성능을 살펴보세요. 트래픽 테스트는 로컬 데이터와 서버 측 사용량을 소모하므로 모든 노드를 자주 측정하는 것은 적절하지 않습니다. 결과가 크게 달라진다면 다른 시간에 다시 측정하고 같은 기기의 직접 연결 결과와 비교하세요. 한 번의 최고 속도로 장기적인 사용 경험을 판단하지 마세요.
컴퓨터와 휴대폰에서 같은 설정을 그대로 사용할 수 있나요?
서비스가 해당 기기들의 사용을 허용하고 프로토콜과 구독 형식을 각 클라이언트가 지원한다면 데스크톱과 Android 클라이언트에서 같은 구독을 읽을 수 있습니다. 프로그램 폴더 전체를 공용 설정처럼 복사하기보다는 각 기기에서 구독을 따로 가져오는 편이 좋습니다. 로컬 포트, 시스템 프록시, TUN, 파일 경로, 라우팅 규칙은 운영체제마다 다르므로 각각 확인해야 합니다. 설정을 가져온 뒤에도 프로토콜, 전송 방식, 보안 매개변수가 그대로 유지되었는지 확인하세요. 구독 업데이트가 로컬 설정 전체를 동기화하는 것은 아닙니다. 한 기기에서는 연결되고 다른 기기에서는 실패한다면 구독 전체에 문제가 있다고 단정하기보다 코어 버전과 가져온 설정을 먼저 비교하세요.
LOG / RECOVERY
문제 해결
로컬 네트워크, 원격 연결, 앱의 트래픽 처리 순서로 원인을 좁혀 보세요.
노드 연결 시간 초과는 어떤 순서로 점검하는 것이 가장 효과적인가요?
먼저 프록시를 끈 상태에서 로컬 네트워크가 정상인지 확인한 다음 서비스가 유효한지, 주소와 포트가 올바른지 살펴보세요. 이어서 TCP 연결 실패와 프록시 핸드셰이크 실패를 구분해야 합니다. 전자는 네트워크 경로, 대상 포트, 서버의 리스닝 상태를 중점적으로 확인하고, 후자는 인증, TLS, 서버 이름, 프로토콜 조합을 점검하세요. 정상 작동이 확인된 설정과 비교하거나 다른 로컬 네트워크에서 테스트하면 원인을 좁히는 데 도움이 됩니다. 문제가 발생할 때 관련 로그를 확인하고 오류 유형과 발생 시간만 기록하세요. 공유할 때는 주소와 인증 정보를 숨기세요. 시간 초과 값을 늘리는 것만으로 설정 오류를 해결할 수는 없습니다. 코어를 반복해서 바꾸기 전에 현재 설정을 코어가 지원하는지 확인하세요.
클라이언트에는 연결됨으로 표시되는데 웹페이지가 열리지 않으면 어떻게 해야 하나요?
연결됨 표시는 로컬 프록시나 VPN 인터페이스가 시작되었다는 뜻일 수 있으며, 원격 요청까지 성공했다는 의미는 아닙니다. 현재 선택한 설정으로 실제 연결 테스트를 먼저 실행하세요. 테스트에 실패하면 연결 버튼만 보지 말고 코어 로그를 확인하세요. 테스트는 성공하지만 브라우저에서 접속되지 않는다면 브라우저가 시스템 프록시를 사용하는지, 확장 프로그램이 설정을 덮어쓰는지, 앱에 다른 프록시 포트가 지정되어 있는지 확인하세요. 도메인으로만 접속할 수 없다면 DNS 설정과 조회 요청의 경로를 점검하세요. 일부 웹사이트만 실패한다면 분할 라우팅 규칙을 먼저 확인하세요. 설정을 한 번에 하나씩만 바꾸고 같은 대상을 다시 테스트해 DNS, 라우팅, 트래픽 처리 방식을 한꺼번에 변경하지 않도록 하세요.
시스템 프록시를 켰는데 일부 앱은 왜 프록시를 사용하지 않나요?
시스템 프록시는 앱이 따르도록 선택할 수 있는 설정이지 모든 네트워크 연결을 강제로 처리하는 기능은 아닙니다. 시스템 프록시를 따르는 브라우저로 먼저 기본 연결을 확인하세요. 브라우저는 정상인데 특정 앱만 문제가 있다면 해당 앱에 별도의 프록시 설정이 있는지, 기본적으로 직접 연결을 사용하는지 점검하세요. 프록시를 수동으로 입력할 때는 프로토콜 종류, 리스닝 주소, 포트를 확인해야 합니다. HTTP와 SOCKS 주소를 혼용하거나 다른 클라이언트의 포트 번호를 그대로 사용하지 마세요. 기본 연결이 정상임을 확인한 뒤 모든 앱의 트래픽을 처리해야 할 때 TUN을 고려하세요. 모든 앱에서 프록시가 작동하지 않는다면 클라이언트의 로컬 리스너가 실행 중인지, 포트 충돌이 있는지, 다른 프로그램이 시스템 프록시 설정을 덮어쓰는지 확인하세요.
클라이언트를 종료한 뒤 인터넷에 연결할 수 없을 때 기존 네트워크를 복구하려면 어떻게 해야 하나요?
먼저 시스템이 종료된 로컬 프록시 포트를 계속 가리키는지 확인하세요. 클라이언트를 다시 실행해 시스템 프록시를 해제하거나 원래 설정으로 복구한 다음 정상적으로 종료할 수 있습니다. 또는 시스템 네트워크 설정에서 남아 있는 수동 프록시를 제거하세요. 이전에 TUN을 사용했다면 해당 모드를 끄고 가상 인터페이스가 종료되었는지 확인하세요. Android에서는 시스템 VPN 설정에서 상시 연결과 VPN 연결 없이 차단 옵션이 켜져 있는지도 살펴보세요. 복구가 끝나면 현재 네트워크에 다시 연결하고 기본 접속을 테스트하세요. 특히 회사 네트워크나 사용자 지정 DNS를 사용하는 기기에서는 처음부터 전체 네트워크 설정을 초기화하지 마세요. 복구 전에 기존 값을 기록해 업무에 필요한 설정이 사라지지 않도록 하세요.