V2Ray 자주 묻는 질문
설정 및 연결 문제 해결

V2Ray는 Project V 생태계에 속하며, V2Fly는 관련 코어 개발을 이어갑니다. Xray는 별도의 코어 개발 계열입니다. 코어는 프로토콜 연결, 라우팅, DNS를 처리하고 v2rayN은 이러한 설정을 관리하는 데스크톱 GUI를 제공합니다. Android에서는 v2rayNG가 주로 Xray 코어를 사용하고 v2flyNG는 v2fly 코어를 사용합니다. 클라이언트에서 특정 링크를 가져올 수 있다고 해서 현재 코어가 해당 링크의 모든 매개변수를 지원하는 것은 아닙니다. 클라이언트를 선택할 때는 프로토콜, 전송 방식, 보안 계층과 실제 코어 버전을 함께 확인하세요.

클라이언트는 설정을 읽어 연결을 구성합니다. 설치만으로 사용할 수 있는 서버 정보가 자동 생성되지는 않습니다. 사용 권한이 있는 구독 주소나 공유 링크, 또는 완전한 서버 설정을 준비해야 합니다. 직접 입력한다면 서버 주소, 포트, 사용자 ID 또는 비밀번호, TLS와 전송 방식 등의 매개변수가 서버 측 설정과 일치해야 합니다. 먼저 기기에서 기본 네트워크에 정상적으로 접속되는지 확인한 뒤 출처가 분명한 설정 하나를 가져와 테스트하세요. 클라이언트 설치 성공과 서버 연결 성공을 혼동하지 마세요.

시스템 프록시는 시스템 프록시 설정을 따르는 앱의 요청을 클라이언트로 전달합니다. 이 설정을 따르지 않는 프로그램은 계속 직접 연결할 수 있습니다. TUN은 가상 네트워크 인터페이스로 트래픽을 받아들이므로 일반적으로 더 많은 트래픽을 처리하지만, 시스템 권한과 라우팅 및 DNS 설정이 필요합니다. 라우팅 분할은 트래픽이 코어에 들어온 뒤 프록시, 직접 연결, 차단 중 어디로 보낼지 결정합니다. 세 기능은 서로 다른 단계에서 작동합니다. 문제를 해결할 때는 먼저 앱 트래픽이 클라이언트로 들어오는지 확인한 다음 라우팅을 점검하세요. TUN을 켰다는 이유만으로 모든 요청이 프록시를 통한다고 판단해서는 안 됩니다.

먼저 서버에서 제공하는 프로토콜을 확인하세요. 클라이언트에서 프로토콜 이름만 바꾼다고 변환되는 것은 아닙니다. VLESS, VMess, Trojan은 인증 필드와 보안 설정이 서로 다릅니다. REALITY는 보통 VLESS 등의 프로토콜과 조합하는 보안 계층 설정이며, 임의로 바꿔 쓸 수 있는 프로토콜 이름이 아닙니다. 비교할 때는 TLS, 전송 방식, 코어 지원 여부도 확인해야 합니다. 배포 환경과 무관하게 적용되는 고정 속도 순위는 없습니다. 서버에서 명시적으로 지원하고 매개변수가 완전하며 클라이언트 코어와 호환되는 조합을 우선 선택한 뒤 실제 연결 상태를 기준으로 판단하세요.

먼저 가져오려는 항목의 종류를 확인하세요. 공유 링크는 보통 vmess://, vless://, trojan:// 또는 ss://로 시작하며, 구독 주소는 대개 HTTPS 주소입니다. 복사할 때 함께 들어간 설명 문구와 줄바꿈, 앞뒤 공백을 지우고 클립보드 가져오기 또는 구독 그룹에 맞는 메뉴를 사용하세요. 지원하지 않는다는 메시지가 표시되면 클라이언트와 코어가 해당 전송 설정을 지원하는지 확인하세요. 웹페이지 주소, 로그인 페이지, 일반 JSON 파일을 모두 공유 링크처럼 처리할 수는 없습니다. 여러 아웃바운드나 라우팅 규칙을 포함한 JSON도 단일 노드로 변환되지 않을 수 있습니다.

대부분의 최신 Android 스마트폰에서는 arm64를 우선 선택할 수 있지만, 최종적으로는 기기 시스템이 지원하는 ABI를 기준으로 해야 합니다. 프로세서의 홍보용 모델명만으로 판단하지 마세요. universal 패키지는 보통 여러 아키텍처를 포함해 용량이 더 크며, 아키텍처를 모를 때 적합합니다. 실제 포함된 아키텍처는 해당 클라이언트 배포 파일을 확인하세요. 파싱 실패나 호환되지 않는다는 안내가 나오면 시스템 버전, 설치 파일의 다운로드 완료 여부, 기존 앱과 서명이 일치하는지도 확인해야 합니다. 다른 클라이언트로 바꾸기 전에 설정을 백업하고, 유일한 설정 사본을 바로 삭제하지 마세요.

v2rayN에서 사용할 서버를 선택하고 코어가 정상적으로 시작됐는지 확인한 다음, 필요에 따라 시스템 프록시를 설정하거나 TUN을 활성화하세요. 목록에서 한 줄을 선택하는 것만으로 앱 트래픽이 연결된 것은 아닙니다. Android 클라이언트는 서비스를 시작해야 하며, VPN 모드에서는 시스템 연결 권한을 허용해야 합니다. 그런 다음 실제 브라우저로 접속을 테스트하고 로그에서 요청이 코어에 들어왔는지, 어떤 아웃바운드를 사용했는지 확인하세요. 화면의 연결 상태나 지연 시간은 일부 단계만 보여 주므로 브라우저, DNS, 대상 웹사이트가 모두 정상이라고 단정할 수 없습니다.

데스크톱에서는 먼저 로그에서 구체적인 실패 항목을 확인하세요. 가상 인터페이스 생성, 라우팅 설정, 포트 바인딩 실패는 각각 해결 방법이 다릅니다. Windows에서는 클라이언트 안내에 따라 관리자 권한으로 실행할 수 있습니다. macOS와 Linux는 현재 버전의 안내에 따라 시스템 권한을 허용하거나 보조 구성 요소를 설치하세요. 모든 파일 권한을 무작정 완화하지 마세요. Android의 VPN 권한과 데스크톱 TUN 권한은 서로 다른 방식이며, 보통 VPN 인터페이스를 점유한 다른 앱도 중지해야 합니다. 권한을 허용한 뒤 서비스를 다시 시작하고, 이전 가상 인터페이스나 다른 네트워크 도구의 라우팅이 시스템을 점유하고 있지 않은지 확인하세요.

구독 설정과 수동 설정을 서로 다른 그룹에 넣고, 업데이트 전에 어느 구독 그룹을 대상으로 하는 작업인지 확인하세요. 구독을 새로고침하면 원격 콘텐츠에 따라 해당 그룹의 노드가 다시 생성되거나 변경될 수 있으므로, 계속 보존할 수동 수정 사항을 구독 노드에만 저장하지 않는 것이 좋습니다. 수정이 필요하면 별도 설정으로 복사한 뒤 편집하세요. 인증 정보가 바뀌었다면 서버 측 설정도 함께 확인해야 합니다. 클라이언트의 내보내기 또는 백업 기능을 정기적으로 사용하고 파일을 안전하게 보관하세요. 구독 주소와 내보낸 설정에는 접속 인증 정보가 포함될 수 있으므로 일반 스크린샷이나 첨부 파일처럼 공개하지 마세요.

먼저 클라이언트에 내장된 라우팅 구성을 사용하고, 사용자 지정 규칙은 하나씩 추가하세요. 전체 설정을 한 번에 교체하지 않는 것이 좋습니다. 규칙의 매칭 순서, 도메인 정책, 기본 아웃바운드를 확인하세요. 예를 들어 geosite:category-ads-all → block은 해당 도메인 목록과 일치하는 요청을 차단한다는 뜻이지만, 선택한 코어와 규칙 리소스가 이 형식을 지원해야 합니다. 코어마다 규칙 형식은 호환되지 않을 수 있습니다. 수정한 뒤에는 직접 연결되어야 하는 대상과 프록시를 거쳐야 하는 대상을 각각 테스트하고 로그를 확인하세요. IPIfNonMatch는 도메인과 일치하는 규칙이 없을 때의 이름 해석 판단과 관련된 설정이지, 모든 도메인을 프록시로 보내는 스위치가 아닙니다.

먼저 시스템이 서비스를 종료한 경우와 서비스는 실행 중이지만 연결이 끊긴 경우를 구분하세요. 전자는 시스템의 배터리 최적화, 백그라운드 실행 권한, 제조사별 앱 절전 설정을 확인하고 필요한 경우 클라이언트가 계속 실행되도록 허용하세요. 후자는 네트워크 전환, 구독 설정, 코어 로그를 확인해야 합니다. 배터리 소모를 점검할 때는 장시간 전송, 반복 재연결, 불필요한 백그라운드 요청을 살펴보고 필요하면 앱별 프록시로 연결 범위를 줄이세요. VPN 모드라고 해서 반드시 배터리를 비정상적으로 많이 소모하는 것은 아닙니다. 연결 유지를 위해 모든 앱의 배터리 제한을 한꺼번에 끄는 것도 권장하지 않습니다. 한 번에 한 항목씩 바꾸고 개선되는지 확인하세요.

구독 주소에는 접속 토큰이 포함될 수 있으며, 공유 링크와 QR 코드에는 전체 연결 인증 정보가 들어 있을 수 있습니다. 문제 해결 자료를 제출하기 전에 구독 경로의 민감한 부분, 사용자 ID, 비밀번호, 개인 서버 주소, 로그에 포함된 공개를 원치 않는 접속 도메인을 가리세요. 클라이언트 이름, 실제 버전, 운영체제 종류, 오류 원문과 발생 시각은 남겨 두는 편이 원인 파악에 도움이 됩니다. 맥락을 유지하려고 전체 설정을 공개하지 마세요. 민감 정보를 제거한 필드 설명으로 프로토콜, 전송 방식, 보안 계층을 알리고 최근 변경한 설정을 함께 설명할 수 있습니다.

먼저 기기의 기본 네트워크 연결이 정상인지 확인한 다음 서버 주소를 확인할 수 있는지, 포트가 올바른지, 구독이 만료되지 않았는지, 서버가 실행 중인지 살펴보세요. 클라이언트의 TCP 테스트와 실제 프록시 요청은 서로 다른 테스트입니다. 포트에 연결할 수 있다고 프로토콜 인증까지 성공한 것은 아니며, 한 번 시간 초과가 발생했다고 설정이 잘못됐다고 단정할 수도 없습니다. 같은 설정으로 다른 네트워크에서 다시 테스트하고 인증, TLS, 전송 관련 로그를 확인하세요. 특정 설정 하나만 실패한다면 해당 설정을 우선 점검하고, 모두 실패한다면 로컬 프록시 충돌, DNS, 현재 네트워크 상태를 먼저 확인하세요.

브라우저에서 접속을 시도할 때 클라이언트에 요청 로그가 나타나는지 먼저 확인하세요. 로그가 없다면 시스템 프록시가 활성화되어 있는지, 브라우저에 별도의 프록시 설정이 있는지, 앱이 앱별 규칙에서 제외되었는지 살펴보세요. 로그는 있지만 접속에 실패한다면 DNS 확인 실패, 잘못된 라우팅 아웃바운드, 원격 연결 실패를 구분해야 합니다. 도메인으로만 접속할 수 없다면 DNS를 집중적으로 확인하되, HTTPS 웹사이트의 IP 주소에 직접 접속하는 방법을 일반적인 검증 수단으로 사용하지 마세요. 알려진 설정으로 잠시 되돌려 하나씩 테스트하면 DNS, 라우팅, 전송 매개변수를 동시에 바꿔 원인을 찾기 어려워지는 일을 막을 수 있습니다.

클라이언트 설정에서 실제 로컬 리슨 포트를 확인한 뒤 시스템 프록시가 가리키는 주소와 포트가 일치하는지 살펴보세요. 일부 설정은 socks 10808과 http 10809를 사용하지만, 모든 버전과 설정에 고정으로 적용되는 값은 아닙니다. 현재 화면과 로그를 기준으로 확인하세요. 브라우저 확장 프로그램, 다른 프록시 소프트웨어, 기업 관리 정책이 시스템 설정을 덮어쓸 수 있습니다. 시스템 프록시를 사용하지 않는 앱은 별도로 설정하거나 적절한 TUN 연결 방식을 사용해야 합니다. 다른 프록시 도구를 종료한 뒤 시스템 프록시를 다시 설정하고 포트가 이미 사용 중인지 확인하세요. 로컬 연결 문제를 해결하려고 노드만 계속 바꾸지 마세요.

구독 업데이트에 실패하면 먼저 주소가 완전한지, 접속 토큰이 유효한지, 응답이 로그인 페이지나 오류 페이지로 바뀌지 않았는지 확인하세요. 연결 시간 초과와 응답 형식 오류는 각각 다르게 처리해야 합니다. 프록시를 통해 업데이트한다면 현재 프록시가 먼저 정상 작동해야 합니다. 필요한 경우 클라이언트가 지원하는 다른 업데이트 방식을 사용하세요. TLS 핸드셰이크 오류가 발생하면 시스템 시간, 인증서 유효 기간, SNI, 서버 요구 사항을 확인하세요. 구독 도메인과 노드의 serverName을 혼동하지 마세요. 인증서 검증을 건너뛰는 allowInsecure 설정을 장기간 사용하는 것은 권장하지 않습니다. 시간, 도메인, 서버 인증서를 바로잡은 뒤 다시 테스트하세요.