문제 해결 / 설정 및 연결
V2Ray 자주 묻는 질문
증상에 맞는 설정 메뉴를 찾아보세요. 먼저 트래픽이 클라이언트에 전달되는지 확인한 뒤 라우팅, DNS, 원격 연결을 점검하세요.
아래 내용은 v2rayN, v2rayNG, v2flyNG의 일반적인 설정에 적용됩니다. 메뉴 이름은 버전에 따라 조금씩 다를 수 있으므로 현재 화면과 실행 로그를 기준으로 확인하세요. 질문을 누르면 답변이 펼쳐집니다.
처음 설정한다면 먼저 사용법을 확인하세요 →클라이언트·코어·트래픽 처리 범위
기본 개념
클라이언트, 서버 설정, 네트워크 모드를 구분해 잘못된 설정을 변경하지 않도록 하세요.
V2Ray, Xray 코어와 세 가지 클라이언트는 어떤 관계인가요?
V2Ray는 Project V 생태계의 프록시 도구이며, V2Fly는 관련 코어의 유지 관리를 이어가고 있습니다. Xray는 별도로 개발되는 코어 프로젝트입니다. 코어는 프로토콜 처리, 라우팅, 네트워크 연결을 담당하고, 그래픽 클라이언트는 설정 가져오기, 서버 선택, 실행 상태 관리를 담당합니다. v2rayN은 데스크톱용이며, Android의 v2rayNG는 주로 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 특정 설정을 실행할 수 있는지는 클라이언트에 포함된 코어의 버전과 지원 필드에 따라 달라지므로 클라이언트 이름만으로 판단할 수 없습니다.
클라이언트를 설치한 뒤에도 구독이나 서버 설정이 필요한가요?
네. 클라이언트는 설정과 연결을 관리하는 도구이며, 설치만으로 사용할 수 있는 원격 서버가 생기지는 않습니다. 연결하려면 사용 권한이 있는 구독 주소, 공유 링크 또는 서버 정보를 준비해 해당 클라이언트로 가져와야 합니다. 구독에는 보통 여러 서버 항목과 업데이트 주소가 포함되며, 단일 공유 링크에는 대개 서버 하나의 정보만 들어 있습니다. 가져온 뒤에도 서비스가 유효한지, 인증 정보가 맞는지, 프로토콜과 전송 설정을 지원하는지 확인하세요. 구독 주소에는 서버 설정 전체를 읽을 수 있는 접근 정보가 포함될 수 있으므로 공개 게시판에 올리지 마세요.
시스템 프록시, 전역 라우팅, TUN 모드는 어떻게 다른가요?
시스템 프록시는 운영체제 설정에 로컬 프록시 주소를 지정하며, 해당 설정을 따르는 앱에 주로 적용됩니다. 전역 라우팅은 클라이언트 내부의 트래픽 분배 정책으로, 보통 코어에 전달된 트래픽을 프록시 아웃바운드로 보냅니다. 시스템 프록시를 우회하던 프로그램까지 자동으로 코어에 전달하지는 않습니다. TUN은 가상 네트워크 인터페이스로 처리 대상에 해당하는 IP 트래픽을 받아 시스템 프록시를 사용하지 않는 앱에 적합합니다. TUN으로 받은 트래픽도 라우팅 규칙을 거치므로, TUN을 켠다고 모든 연결이 원격 프록시를 통과하는 것은 아닙니다. 먼저 트래픽을 가져오는 방식을 정한 다음 분기 정책을 설정하세요.
프로토콜을 VMess, VLESS, Trojan으로 아무렇게나 바꿔도 되나요?
클라이언트에서 프로토콜 이름만 바꿔서는 안 됩니다. 프로토콜, 인증 필드, 전송 방식, 보안 설정은 서버의 수신 설정과 일치해야 합니다. VMess, VLESS, Trojan, Shadowsocks는 매개변수 구조가 서로 다르며, 같은 프로토콜도 전송 방식과 TLS 설정이 다를 수 있습니다. 구독에 완성된 항목이 있다면 원본 설정을 먼저 보존하고 호환성을 점검하세요. 서버에서 다른 연결 정보를 명시적으로 제공한 경우에만 해당 항목을 새로 만들어 테스트해야 합니다. 한 프로토콜의 설정을 다른 프로토콜로 가져오면 변환되는 것이 아니라 파싱이나 핸드셰이크 오류가 발생하기 쉽습니다.
설치 파일·가져오기 메뉴·권한
설치 및 설정
먼저 설치와 설정 가져오기를 마친 다음 시스템 프록시나 VPN 권한을 설정하세요.
Android 설치 파일은 arm64와 universal 중 무엇을 선택해야 하나요?
최근 출시된 Android 기기라면 arm64를 우선 고려할 수 있지만, 최종적으로는 시스템이 지원하는 ABI를 확인해야 합니다. 프로세서 사양만으로 판단하지 마세요. 64비트 프로세서를 탑재하고도 32비트 시스템을 실행하는 기기에서는 arm64 패키지가 설치되지 않을 수 있습니다. universal 패키지는 보통 여러 아키텍처를 포함해 용량이 더 크며, 시스템 아키텍처를 모를 때 시도해 볼 수 있지만 모든 구형 시스템과 호환되는 것은 아닙니다. 설치 중 파싱 실패나 호환성 오류가 표시되면 최소 Android 버전, 다운로드 파일의 정상 여부, 서명이 다른 동일 이름 앱의 설치 여부도 확인하세요.
구독 링크를 가져오지 못하면 무엇부터 확인해야 하나요?
복사한 주소가 구독 관리 페이지나 로그인 페이지, 공유 안내문이 아니라 실제 구독 주소인지 확인하세요. 붙여넣기 전에 앞뒤 공백을 지우고, 메신저에서 줄바꿈으로 주소가 잘리지 않았는지 확인한 다음 구독 그룹의 주소 입력란에 추가해 업데이트하세요. 단일 공유 링크를 가져오는 경우에는 클립보드에서 서버를 가져오는 메뉴를 사용하고 구독 주소 입력란에 넣지 마세요. 주소에 접속은 되지만 파싱에 실패한다면 응답 형식이 클라이언트에서 지원되는지 확인하세요. 로그인이 필요한 웹페이지, 오류 안내 페이지, 다른 앱 전용 설정은 서버 목록으로 사용할 수 없습니다. 문제를 확인하는 동안 원본 주소를 보존하고 쿼리 매개변수를 함부로 삭제하지 마세요.
v2rayN과 v2rayNG에서 설정을 가져온 뒤 어떻게 연결하나요?
v2rayN에서는 서버 목록에 유효한 항목이 표시되는지 확인한 뒤 사용할 서버로 지정하고, 코어가 시작되는지 점검하세요. 필요한 경우 시스템 프록시 자동 설정을 선택합니다. 목록에서 행을 선택하는 것만으로는 활성 서버로 지정되지 않을 수 있습니다. v2rayNG에서는 설정을 가져온 뒤 사용할 항목을 선택하고 연결 버튼을 누른 다음 Android에 표시되는 VPN 연결 권한 요청을 승인하세요. 처음 승인한 뒤에도 실행 로그에 오류가 있는지 확인해야 합니다. 버튼에 실행 중이라고 표시되는 것은 서비스가 시작되었다는 뜻일 뿐, 원격 서버와 핸드셰이크에 성공했다는 의미는 아닙니다. 실제 접속과 로그를 통해 연결 경로를 확인하세요.
TUN을 켤 때 관리자 권한이나 VPN 승인이 필요한 이유는 무엇인가요?
데스크톱 TUN은 가상 네트워크 인터페이스 생성·설정, 라우팅 변경 등의 시스템 작업이 필요해 플랫폼과 클라이언트 버전에 따라 관리자 권한, 보조 서비스 또는 시스템 승인을 요구할 수 있습니다. v2rayN에서 활성화에 실패하면 로그의 권한, 인터페이스 생성, 라우팅 오류를 먼저 확인하고 화면 안내에 따라 다시 시작하거나 권한을 승인하세요. Android 클라이언트는 시스템 VPN 서비스로 트래픽을 처리하므로 사용자의 VPN 권한 승인이 필요하며, 일반적으로 root 권한은 필요하지 않습니다. 다른 VPN이 실행 중이면 충돌할 수 있습니다. 승인을 우회하려고 시스템 보안 기능을 계속 꺼 두지 말고, 승인 대상과 오류 원인을 먼저 확인하세요.
그룹 관리·앱 트래픽 처리·규칙 테스트
사용 팁
정상 작동하는 설정을 기준으로 보존하세요. 한 번에 한 종류의 설정만 바꾸고 새 연결로 확인하세요.
구독을 여러 그룹으로 나눠 업데이트 후 설정이 뒤섞이지 않게 하려면 어떻게 해야 하나요?
설정 출처별로 구독 그룹을 만들고 각 그룹에 알아보기 쉬운 이름과 업데이트 주소를 지정한 다음, 자동 업데이트와 서버 필터 설정을 확인하세요. 여러 출처의 설정을 같은 임시 그룹에 반복해서 가져오면 업데이트 후 항목의 출처를 파악하기 어렵습니다. 구독으로 생성된 서버 정보를 직접 수정하면 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 수정이 꼭 필요하다면 항목을 별도의 수동 설정으로 복사하고 용도를 표시하세요. 업데이트가 끝나면 현재 활성 서버가 남아 있는지 확인하고 필요하면 다시 선택하세요. 그룹은 설정을 정리하는 기능일 뿐, 해당 그룹의 트래픽에 적용할 라우팅 규칙을 자동으로 결정하지는 않습니다.
시스템 프록시를 켰는데도 일부 프로그램이 직접 연결되면 어떻게 해야 하나요?
먼저 앱이 운영체제의 프록시 설정을 읽는지 확인하세요. 자체 네트워크 스택을 사용하는 프로그램은 앱 내부에서 HTTP 또는 SOCKS 프록시를 지정해야 할 수 있으며, 터미널 도구도 프록시 환경 변수를 별도로 설정해야 할 수 있습니다. 로컬 주소와 포트는 클라이언트의 현재 설정을 기준으로 확인하고 HTTP와 SOCKS 포트를 혼용하지 마세요. 변경 후 대상 앱을 다시 시작해 기존 연결이 계속 재사용되는 문제를 배제하세요. 프로그램에 프록시 설정 메뉴가 없다면 TUN을 고려하고, 프로세스 또는 주소 우회 규칙에서 제외되지 않았는지 확인하세요. 특정 앱이 직접 연결된다는 이유만으로 클라이언트 전체가 작동하지 않는다고 판단하지 마세요.
라우팅 규칙을 바꿨는데 적용되지 않은 것처럼 보이는 이유는 무엇인가요?
먼저 현재 활성화된 라우팅 설정을 수정했는지, 변경 내용을 저장하고 적용했는지 또는 코어를 다시 시작했는지 확인하세요. 규칙은 대개 위에서 아래로 검사하므로 앞에서 일치한 넓은 규칙이 뒤의 구체적인 규칙보다 먼저 적용될 수 있습니다. 도메인 예외 규칙은 관련 분류 규칙보다 앞에 두세요. 이어서 outboundTag가 실제로 존재하는 아웃바운드 태그를 가리키는지, geosite 및 geoip 데이터가 사용 가능한지 확인하세요. 앱이 도메인을 이미 IP로 변환했다면 도메인 규칙에 필요한 정보가 남아 있지 않을 수 있으므로 DNS와 스니핑 설정도 함께 살펴봐야 합니다. 테스트 전에 대상 앱의 기존 연결을 종료하고, 로그에서 새 연결이 실제로 어떤 아웃바운드에 매칭됐는지 확인하세요.
테스트하거나 도움을 요청할 때 유용한 로그를 제공하려면 어떻게 해야 하나요?
먼저 클라이언트 이름, 운영체제, 트래픽 처리 모드, 재현 절차를 기록한 다음 문제 확인에 적합한 로그 수준으로 잠시 조정하세요. 이전 로그를 지우고 문제를 한 번만 재현한 뒤 코어 시작부터 오류 발생까지의 관련 구간을 보관하세요. 특히 첫 번째 구체적인 오류와 그 앞뒤 내용을 포함해야 합니다. 로그를 공개하기 전에 구독 주소, 인증 정보, 개인 디렉터리, 공개하기 곤란한 서버 주소를 가리세요. 스크린샷도 같은 내용을 확인해야 합니다. 마지막 줄의 시간 초과 메시지만 제공하지 마세요. 앞선 설정 오류로 발생한 결과일 수 있습니다. 문제를 찾은 뒤에는 평소 로그 수준으로 되돌려 접속 대상이 포함된 상세 기록이 장기간 쌓이지 않게 하세요.
로컬 네트워크·이름 확인·원격 연결
문제 해결
먼저 어느 단계에서 실패하는지 확인하세요. 서비스 실행, 원격 서버 연결, 웹사이트 접속은 각각 별도로 점검해야 합니다.
v2rayNG에서 서버 연결 시간이 초과되면 어떤 순서로 확인해야 하나요?
먼저 프록시를 중지하고 기기의 로컬 네트워크가 정상인지, 시스템 날짜와 시간이 정확한지 확인하세요. 구독이 아직 유효한지 확인하고 설정을 업데이트한 뒤 현재 선택한 서버가 삭제되지 않았는지도 살펴보세요. 이어서 원본 서버 정보와 대조해 주소, 포트, 프로토콜, 전송 경로, TLS 설정을 확인하세요. 특히 serverName을 임의로 바꾸지 마세요. 같은 네트워크에서 이미 유효한 다른 설정을 테스트하면 특정 서버 문제와 로컬 네트워크 문제를 구분하는 데 도움이 됩니다. 모든 설정이 실패한다면 다른 VPN, 비공개 DNS, 보안 소프트웨어의 영향도 확인하세요. 한 번에 하나씩만 변경하고 관련 로그를 보관해 원인을 파악할 수 있도록 하세요.
연결됨으로 표시되는데 인터넷이 안 될 때 DNS 문제와 라우팅 문제를 어떻게 구분하나요?
연결됨 표시는 로컬 프록시나 VPN 서비스가 실행 중이라는 뜻일 수 있습니다. 먼저 로그에서 원격 핸드셰이크 실패, 이름 확인 실패, 라우팅 거부가 발생했는지 확인한 다음 직접 연결되어야 하는 사이트와 프록시를 거쳐야 하는 사이트를 각각 테스트하세요. 로그에 도메인 확인 시간 초과가 명확히 표시되면 DNS 서버에 접속할 수 있는지, DNS 요청이 어떤 아웃바운드를 통과하는지, 비공개 DNS와 충돌하는지 확인하세요. 도메인이 정상적으로 확인됐는데도 연결에 실패한다면 라우팅과 원격 서비스를 더 점검하세요. DNS만 반복해서 바꾸지는 마세요. HTTPS 사이트의 IP 주소에 직접 접속하지 못했다고 네트워크 장애로 단정하지 마세요. 인증서와 가상 호스트 설정도 테스트 결과에 영향을 줍니다.
구독이 전에는 업데이트됐는데 지금은 실패한다면 어떻게 해야 하나요?
먼저 현재 사용할 수 있는 설정을 보존하고 구독 그룹 전체를 삭제하지 마세요. 주소가 만료됐는지, 구독 제공처가 변경됐는지, 응답이 접근 거부·네트워크 시간 초과·콘텐츠 파싱 오류 중 무엇인지 확인하세요. 클라이언트에서 프록시를 통한 업데이트를 지원한다면 사용 가능한 연결이 있을 때 업데이트 경로를 바꿔 테스트할 수 있습니다. 직접 연결과 프록시 연결이 모두 실패하면 구독 제공처의 상태를 확인하세요. 응답이 비어 있거나 로그인 페이지로 바뀌었다면 대개 노드 프로토콜이 아니라 구독 권한이나 주소를 해결해야 합니다. 문제를 확인하는 동안 잦은 자동 재시도를 끄고 제공처의 요청 제한을 피하세요. 정상화된 뒤 적절한 업데이트 간격으로 다시 설정하면 됩니다.
클라이언트를 종료한 뒤 네트워크에 문제가 생기거나 로컬 포트가 사용 중이라는 메시지가 표시되면 어떻게 해야 하나요?
먼저 시스템이 이미 종료된 로컬 프록시를 계속 가리키는지 확인하세요. 그렇다면 남아 있는 수동 프록시 설정을 지우고 네트워크가 복구되는지 확인합니다. TUN을 사용했다면 가상 네트워크 인터페이스의 트래픽 처리가 중지됐는지도 확인하고, 필요하면 정상적으로 종료한 뒤 다시 시작해 라우팅을 복구하세요. 포트가 사용 중이라면 클라이언트가 중복 실행 중인지 또는 코어 프로세스가 남아 있는지 확인하고 불필요한 인스턴스를 정상 종료하세요. 로컬 포트를 바꿔야 한다면 앱의 프록시 주소와 포트도 함께 변경해야 합니다. 정체를 알 수 없는 시스템 프로세스를 함부로 종료하지 말고, 프록시가 접근 가능한 범위를 넓힐 수 있으므로 로컬 수신 주소를 모든 네트워크 인터페이스로 변경해 해결하려 하지 마세요.