V2Ray 자주 묻는 질문과 문제 해결

V2Ray는 Project V 프록시 도구 생태계에 속하며, V2Fly는 관련 코어 개발을 이어 왔습니다. Xray는 독립적으로 발전한 또 다른 코어입니다. v2rayN은 서버, 구독, 라우팅, 로컬 프록시를 관리하는 그래픽 클라이언트이며, 실제 연결은 선택한 코어가 처리합니다. 설정 항목이나 프로토콜을 인식하지 못한다면 창에 표시된 클라이언트 이름만 보지 말고, 현재 클라이언트가 사용하는 코어와 버전을 먼저 확인하세요. 서로 다른 코어의 JSON 설정은 그대로 섞어 쓰지 않는 것이 좋으며, 특히 전송 방식, 보안 설정, 라우팅 항목을 확인해야 합니다.

Windows, macOS, Linux 데스크톱에서는 v2rayN을 사용하고, Android에서는 일반적으로 Xray 코어를 사용하는 v2rayNG를 선택합니다. 기존 설정이 V2Fly의 동작에 명확히 의존할 때는 v2flyNG를 고려하세요. 세 클라이언트 모두 구독이나 서버 설정을 코어에 전달해 실행하지만, 메뉴 구성과 지원 프로토콜, 고급 설정 항목은 서로 다릅니다. 먼저 운영체제에 맞는 클라이언트를 고른 다음 서버의 프로토콜과 전송 방식을 확인하세요. 클라이언트를 바꾸기 전에는 구독 주소와 필요한 설정을 저장하세요. 다른 앱의 데이터 폴더 전체를 가져오기 설정으로 사용할 수는 없습니다.

클라이언트 설치는 로컬 관리 화면과 실행 환경이 준비되었다는 뜻일 뿐, 사용할 수 있는 서버가 자동으로 만들어지는 것은 아닙니다. 사용할 권한이 있는 구독 주소를 가져오거나 서버 주소, 포트, 사용자 ID 및 전송 매개변수를 입력해야 합니다. 구독은 서버 설정을 배포하는 수단이지 클라이언트 자체가 아닙니다. 구독의 유효성이나 서버 접속 가능 여부는 해당 서비스에 달려 있습니다. 먼저 설정의 출처와 유효 기간을 확인한 뒤 가져와 사용할 서버를 선택하세요. 접속 정보가 포함된 구독 주소를 공개 댓글이나 스크린샷, 온라인 변환 도구에 올리지 마세요.

시스템 프록시는 시스템 설정을 따르는 앱의 요청을 로컬 프록시 포트로 전달합니다. 일부 터미널 프로그램과 앱은 시스템 프록시 설정을 읽지 않습니다. 라우팅 분기는 트래픽이 코어에 들어온 뒤 도메인, IP 등 조건에 따라 프록시, 직접 연결 또는 차단을 결정합니다. TUN 모드는 가상 네트워크 인터페이스로 조건에 맞는 트래픽을 처리하며, 보통 시스템 네트워크 권한, 라우팅 테이블, DNS 설정이 필요합니다. 문제를 해결할 때는 먼저 일반 로컬 프록시로 서버 연결을 확인한 뒤 시스템 프록시나 TUN을 각각 따로 활성화하세요. 세 설정을 동시에 바꾸면 어느 단계에서 문제가 생겼는지 파악하기 어렵습니다.

대부분의 최신 Android 휴대전화에는 arm64 패키지를 사용할 수 있습니다. universal 패키지는 여러 아키텍처를 지원해 용량이 더 큰 편이며, 기기 아키텍처를 확인하기 어려울 때 적합합니다. 휴대전화의 출시 연도만으로 판단해서는 안 됩니다. 프로세서는 64비트를 지원해도 설치된 시스템이나 앱 실행 환경은 32비트일 수 있습니다. 기기 사양이나 신뢰할 수 있는 시스템 정보 화면에서 아키텍처를 확인하세요. arm64 패키지에서 아키텍처가 맞지 않는다는 메시지가 나오면 universal 패키지를 사용하세요. 서명 충돌 메시지는 아키텍처 문제가 아닙니다. 설치된 앱의 출처와 앱 식별자를 확인하고 설정을 백업한 뒤 설치 충돌을 해결하세요.

서비스 관리 페이지나 결제 페이지, 브라우저 로그인 후 표시되는 페이지 주소가 아니라 전체 구독 링크를 붙여 넣어야 합니다. v2rayN에서는 구독 그룹 설정으로 이동해 그룹을 추가하고 주소를 저장한 다음 구독을 업데이트하세요. v2rayNG에서도 먼저 구독 그룹을 저장한 뒤 해당 그룹을 업데이트해야 합니다. 주소를 복사할 때 앞뒤 공백, 줄바꿈, 잘린 쿼리 매개변수가 없는지 확인하세요. 로그에 HTML 응답이 표시된다면 로그인 페이지나 오류 페이지를 가져왔을 가능성이 높으므로 올바른 링크를 다시 확인하세요. 주소 문제를 덮으려고 인코딩 방식을 계속 바꾸지 말고, 접속 정보가 포함된 전체 링크를 공개하지 마세요.

먼저 배포판의 패키지 관리 방식을 확인하세요. Debian, Ubuntu 및 파생 배포판은 보통 deb를, Fedora 등 RPM 계열 배포판은 보통 rpm을 사용합니다. 그런 다음 uname -m을 실행해 아키텍처를 확인하세요. x86_64는 x64에, aarch64는 일반적으로 arm64에 해당합니다. 패키지 형식과 CPU 아키텍처는 별개의 조건이므로 둘 다 맞아야 합니다. 배포판의 소프트웨어 설치 도구나 패키지 관리자를 사용해 의존성이 정상적으로 처리되도록 설치하세요. 의존성 누락 메시지가 나오면 구체적인 패키지 이름을 먼저 확인하세요. 의존성을 강제로 무시하지 말고, 일반적인 설치를 위해 데스크톱 클라이언트를 root 권한으로 계속 실행하지 마세요.

먼저 TUN을 끄고 일반 로컬 프록시로 정상 연결되는지 확인한 뒤 시스템 권한을 설정하세요. Linux에서는 사용할 수 있는 TUN 장치와 가상 인터페이스 생성 및 라우팅 변경 권한이 필요합니다. 구체적인 권한 설정은 현재 v2rayN 버전의 안내와 배포판의 권한 관리 방식에 따르세요. 정체를 알 수 없는 프로그램에 함부로 높은 권한을 부여하지 마세요. Windows에서는 클라이언트 안내에 따라 관련 작업을 허용하고, macOS에서는 시스템 설정에서 네트워크 또는 VPN 권한을 확인하세요. Android에서는 시스템 VPN 요청을 승인해야 하며, 일반적으로 VPN 통로를 사용하는 다른 앱과 동시에 실행할 수 없습니다. 권한을 승인한 뒤 관련 연결을 다시 시작하고 로그에서 실패한 작업을 확인하세요.

먼저 구독을 업데이트하고 현재 코어와 호환되는 프로토콜의 서버를 선택하세요. 이름이나 지역만 보고 판단하지 말고 클라이언트의 실제 연결 테스트로 핸드셰이크를 확인하세요. 일반 지연 시간 테스트와 실제 연결 테스트는 탐색 경로가 다를 수 있으므로 어느 한쪽 결과만으로 실제 접속 여부를 판단할 수 없습니다. 서버를 활성화한 뒤 필요한 프록시 진입점을 켜고, 명확한 HTTPS 주소에 접속한 다음 로그에 해당 요청이 표시되는지 확인하세요. 처음 확인하는 동안에는 라우팅 모드를 유지하고 서버와 DNS를 연달아 바꾸지 마세요. 먼저 반복해서 성공하는 연결 경로를 만들어야 다른 설정과 비교하기 쉽습니다.

터미널 프로그램은 데스크톱의 시스템 프록시 설정을 읽지 않을 수 있습니다. 먼저 클라이언트에서 로컬 HTTP 또는 혼합 수신 포트를 확인하세요. 포트가 10808이라면 curl -I -x http://127.0.0.1:10808 https://example.com으로 프록시를 명시해 테스트할 수 있습니다. SOCKS 수신 포트만 사용한다면 해당 유형에 맞는 옵션을 사용해야 하며 HTTP 방식의 명령을 그대로 적용하면 안 됩니다. 임시 환경 변수가 필요하면 현재 터미널에서 http_proxy와 https_proxy를 설정하고 테스트가 끝난 뒤 해제하세요. 프록시를 명시하면 성공하지만 일반 curl은 실패한다면 서버를 바로 바꾸기보다 프로그램의 프록시 설정 적용 방식을 확인하세요.

먼저 클라이언트에서 제공하는 라우팅 프리셋을 사용하고, 필요한 경우에만 사용자 지정 규칙을 조금씩 추가하세요. 로컬 네트워크와 사설 IP 주소는 직접 연결 출구에 매칭해야 합니다. 지정한 사이트는 도메인 규칙으로 지정하세요. 웹사이트 첫 페이지에서 확인한 IP 하나만 입력하면 같은 사이트의 여러 하위 도메인이나 CDN 주소를 놓칠 수 있습니다. 규칙은 보통 순서대로 적용되며 실제 동작은 사용하는 코어에 따라 달라집니다. 더 구체적인 예외 규칙을 적절한 위치에 두세요. 규칙을 저장하고 적용한 뒤 로그에서 어떤 출구가 선택됐는지 확인하세요. DNS 해석 방식도 IP 기반 매칭에 영향을 주므로 DNS와 라우팅을 동시에 크게 바꾸지 마세요.

먼저 클라이언트에 내장된 내보내기 또는 백업 기능을 사용하세요. 설정 폴더를 복사해야 한다면 아직 기록 중인 파일이 복사되지 않도록 클라이언트를 완전히 종료하세요. 구독 그룹, 직접 추가한 서버, 사용자 지정 라우팅, 필요한 DNS 설정은 최소한 보관해야 합니다. 백업에 사용자 ID, 비밀번호, 구독 접속 정보가 포함될 수 있으므로 안전한 위치에 저장하세요. 새 기기에서는 서버 정보를 먼저 복원한 뒤 수신 포트, 시스템 프록시, TUN 권한을 확인하세요. 시스템 환경과 관련된 설정은 그대로 복사하면 안 됩니다. 다른 클라이언트로 옮길 때는 구독을 다시 가져오는 편이 좋으며 앱 데이터 폴더 전체를 덮어쓰지 마세요.

먼저 구독 주소가 완전하고 서비스가 유효한지 확인한 뒤 업데이트 로그의 오류 유형을 살펴보세요. 시간 초과는 제한 시간 안에 연결 경로를 완료하지 못했다는 뜻입니다. 도메인 해석 실패는 현재 DNS를 확인해야 합니다. HTTP 401 또는 403은 접속 권한, 주소의 유효성, 서버 측 제한을 확인하세요. 클라이언트에 프록시를 통한 업데이트 옵션이 있다면 현재 프록시 서버가 정상인지 먼저 확인해야 합니다. 프록시가 이미 작동하지 않는데 이를 통해 구독을 업데이트하려 하면 순환 문제가 생길 수 있습니다. 직접 연결과 사용 가능한 프록시를 각각 테스트하고 매번 한 항목씩만 바꾸세요. 로그에 민감한 링크가 나오면 오류 정보를 공유하기 전에 접속 정보를 가리세요.

먼저 기기 자체가 정상적으로 인터넷에 연결되는지 확인한 다음 서버 도메인, 포트, 프로토콜, 전송 매개변수가 설정 출처와 일치하는지 살펴보세요. TLS serverName이나 WebSocket path 등을 직접 입력했다면 값이 조금만 달라도 포트 연결은 되지만 핸드셰이크 단계에서 실패할 수 있습니다. 클라이언트 로그를 확인해 도메인 해석 실패, 연결 시간 초과, 연결 거부, TLS 오류를 구분하고 시스템 시간이 정확한지도 확인하세요. 정상 작동이 확인된 설정이나 다른 네트워크와 비교할 수 있지만 한 번에 하나의 조건만 바꾸세요. 한 번의 시간 초과만으로 서버가 중단됐다고 단정하지 말고, 연결을 위해 인증서 검증을 함부로 끄지 마세요.

실행 중이라는 표시는 보통 코어 프로세스가 시작됐다는 뜻일 뿐, 서버 핸드셰이크나 웹사이트 접속까지 성공했다는 의미는 아닙니다. 먼저 로컬 프록시를 명시한 요청으로 테스트해 로컬 포트와 서버 연결 경로를 확인하세요. 다음으로 브라우저가 시스템 프록시를 사용하는지 살펴보고 마지막으로 라우팅과 DNS를 확인하세요. 프록시를 명시하면 접속되지만 브라우저에서 실패한다면 브라우저 확장 프로그램, 별도의 프록시 설정, 캐시된 연결을 중점적으로 확인하세요. 특정 도메인만 실패한다면 해당 라우팅 규칙의 적용 결과와 DNS 로그를 살펴보세요. TUN을 켠 뒤에만 문제가 생기면 TUN을 끄고 비교 테스트를 진행하고, 다른 VPN이나 네트워크 필터링 프로그램과 충돌하는지 확인하세요. 트래픽을 가로채는 도구를 여러 개 동시에 켜지 마세요.

Linux의 프록시 설정은 데스크톱 환경, 앱 자체 설정, 프로세스 환경 변수에서 가져올 수 있습니다. 모든 프로그램이 같은 경로를 사용하도록 보장하는 단일 스위치는 없습니다. 먼저 시스템 프록시 주소가 로컬 루프백 주소인지, 포트가 클라이언트의 HTTP 또는 혼합 수신 포트와 일치하는지 확인한 뒤 프록시를 명시한 요청으로 수신 포트가 실제로 작동하는지 테스트하세요. 브라우저에 별도 프록시 설정이나 확장 프로그램이 있다면 따로 확인하고, 이미 실행 중인 앱은 다시 시작해야 할 수 있습니다. 터미널에서는 http_proxy, https_proxy, ALL_PROXY, NO_PROXY 설정이 충돌하는지도 확인하세요. 프록시를 지원하지 않는 앱이라면 권한과 라우팅에 미치는 영향을 이해한 뒤 TUN 사용을 고려하세요.