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

V2Ray는 Project V 프록시 생태계의 일부입니다. V2Fly는 관련 코어를 유지 관리하며, Xray는 별도의 개발 계열입니다. 코어는 연결, 프로토콜 처리, 라우팅을 담당하고 v2rayN은 구독, 노드, 설정을 관리하는 그래픽 인터페이스를 제공합니다. 문제를 해결할 때는 인터페이스 조작 실패와 코어 실행 실패를 먼저 구분하세요. 전자는 가져온 내용과 화면 안내를 확인하고, 후자는 클라이언트 로그를 살펴보세요. 설정의 사용 가능 여부는 현재 코어와 버전의 지원 범위에 달려 있으므로 클라이언트 이름만으로 판단할 수 없습니다. 다른 코어의 설정 파일을 그대로 덮어쓰지 마세요.

Windows, macOS, Linux 데스크톱에서는 v2rayN을 우선 고려하고, Android에서는 Xray 코어를 사용하는 v2rayNG를 권장합니다. V2Fly 코어가 필요하다면 v2flyNG를 선택하세요. 세 클라이언트는 메뉴, 코어 기능, 설정 형식이 서로 다르며, 안내서에 나온 설정 이름도 버전에 따라 달라질 수 있습니다. 먼저 운영체제와 프로세서 아키텍처를 확인한 뒤 구독 프로토콜의 지원 여부를 살펴보세요. 클라이언트를 바꿀 때는 기존 프로그램 폴더를 통째로 옮기기보다 원본 구독을 다시 가져오는 편이 좋습니다. 사용자 지정 라우팅을 설정했다면 규칙과 로컬 포트도 따로 기록해 두세요.

클라이언트는 설정과 연결을 관리하는 도구이며, 연결할 서버를 자동으로 제공하지는 않습니다. 구독 주소로 노드 목록을 가져올 수 있고, 개별 노드 링크에는 연결에 필요한 주소, 포트, 프로토콜, 인증 정보가 담겨 있습니다. 사용 권한이 있는 서비스나 직접 구축한 서버에서 설정을 받아 클라이언트에 가져오세요. 구독 주소에는 계정 식별 정보가 포함되는 경우가 많아, 주소에 접근할 수 있는 사람이 설정을 확인할 수 있습니다. 공개 댓글이나 스크린샷, 온라인 변환 도구에 올리지 마세요. 구독이 만료되면 클라이언트를 반복해서 다시 설치하기보다 서비스 안내와 계정 상태부터 확인하세요.

시스템 프록시는 시스템 설정을 따르는 앱의 요청을 로컬 프록시로 전달합니다. 라우팅 규칙은 코어로 들어온 트래픽을 프록시로 보낼지, 직접 연결할지, 차단할지 결정합니다. TUN은 가상 네트워크 어댑터를 통해 조건에 맞는 네트워크 트래픽을 처리합니다. 세 기능은 서로 다른 단계에서 작동합니다. 시스템 프록시를 켜도 모든 프로그램이 프록시를 사용하는 것은 아니며, TUN을 켜도 모든 트래픽이 원격 노드를 거치는 것은 아닙니다. 브라우저 요청만 처리한다면 시스템 프록시부터 사용해 보세요. 시스템 프록시 설정을 따르지 않는 앱까지 처리해야 할 때 TUN을 고려하고, 권한과 DNS, 라우팅도 함께 확인하세요.

최근 출시된 대부분의 Android 휴대전화에서는 arm64 설치 파일을 먼저 고려할 수 있지만, 최종적으로는 기기에서 지원하는 앱 아키텍처를 확인해야 합니다. 프로세서가 64비트를 지원해도 운영체제에서 64비트 앱 설치를 허용하지 않을 수 있습니다. universal 설치 파일은 여러 아키텍처를 포함하므로 크기가 더 큰 편이며, 아키텍처를 모를 때 적합합니다. 앱이 설치되지 않는다는 안내가 나오면 아키텍처 문제를 의심하기 전에 시스템 요구 사항, 저장 공간, 기존 앱과 서명이 일치하는지 확인하세요. 문제를 확인하려고 기존 클라이언트를 바로 삭제하지 마세요. 먼저 필요한 설정을 내보내고 구독 정보를 안전하게 보관해 그룹과 규칙이 사라지지 않도록 하세요.

복사한 내용이 구독 주소인지, 개별 노드 링크인지, 계정 관리 페이지 주소인지 먼저 확인하세요. 구독 주소는 구독 그룹의 주소 입력란에 넣고 저장한 뒤 업데이트해야 합니다. 개별 링크는 클립보드에서 가져오기 등 해당 기능을 사용하세요. 복사할 때 앞뒤 공백, 줄바꿈, 메신저가 덧붙인 문장 부호를 제거하고 주소가 잘리지 않았는지 확인하세요. 업데이트 후에도 목록이 비어 있다면 로그에서 형식 미지원, 인증 실패, 웹 페이지 내용 반환 등의 오류가 있는지 살펴보세요. 비공개 구독을 공개 도구에서 변환하지 마세요. 설정 제공자에게 클라이언트 호환 형식을 확인한 뒤 다시 가져오세요.

TUN은 가상 네트워크 어댑터를 만들고 라우팅을 조정하므로 추가 시스템 권한이 필요한 경우가 많습니다. Windows에서는 v2rayN을 완전히 종료한 다음 현재 버전 안내에 따라 관리자 권한으로 실행하고 TUN을 켜 보세요. macOS와 Linux에서는 클라이언트 안내에 따라 서비스를 설치하거나 권한을 부여하세요. 그래도 실패하면 로그에서 어댑터 생성, 드라이버 로드, 권한 거부 관련 내용을 확인하고 다른 가상 어댑터나 프록시 도구와 충돌하는지 살펴보세요. 오류를 없애려고 보안 프로그램을 계속 꺼 두거나 출처를 알 수 없는 권한 상승 명령을 실행하지 마세요. 조치를 마친 뒤에는 한 가지 트래픽 처리 방식만 켜고 테스트하세요.

macOS에서는 시스템의 ‘이 Mac에 관하여’에서 칩을 확인하세요. Apple Silicon은 arm64, Intel은 x64 설치 파일을 선택하고 기기 아키텍처에 맞는 파일을 우선 사용하세요. Linux에서는 아키텍처와 패키지 관리 방식이 모두 맞아야 합니다. Debian·Ubuntu 계열은 일반적으로 deb, Fedora 등 RPM 패키지 관리 방식을 사용하는 배포판은 rpm을 사용합니다. ARM64 기기라면 arm64 패키지도 선택해야 합니다. 같은 패키지 형식이라도 배포판별 실행 의존성이 다를 수 있으므로 설치 전 패키지 관리자의 안내를 확인하세요. 의존성이 부족하면 배포판에 맞는 방식으로 설치하고, 의존성을 무시한 채 강제로 설치하지 마세요.

출처별로 구독 그룹을 따로 만들고, 어디에서 가져온 구독인지 알아볼 수 있는 이름을 붙이세요. 그런 다음 대상 그룹에서 업데이트를 실행하세요. 업데이트가 끝나면 현재 선택한 노드가 목록에 남아 있는지 확인하세요. 구독에 따라 이름이나 지역, 항목 순서가 바뀔 수 있어 기존 선택이 더 이상 유효하지 않을 수 있습니다. 먼저 노드 하나를 직접 선택해 연결을 확인한 뒤 자동 선택이나 다른 규칙을 다시 적용하세요. 목록에서의 위치만 보고 자주 쓰는 회선을 기억하지 말고, 직접 만든 노드는 업데이트 때 덮어써질 수 있는 구독 그룹에 넣지 마세요. 사용자 지정 항목은 별도의 수동 그룹에서 관리하세요.

먼저 현재 변경하려는 항목이 시스템 프록시 방식인지 코어의 라우팅 규칙인지 확인하세요. 중국 본토 우회 규칙은 보통 도메인이나 주소를 기준으로 일부 트래픽을 직접 연결합니다. 전역 프록시 규칙은 코어에 들어온 요청을 더 많이 프록시로 보내지만, 모든 앱의 트래픽을 처리하지는 않습니다. 설정을 바꾼 뒤 이전에 실패했던 대상으로 다시 테스트하고 접근 로그에서 실제로 선택된 출구를 확인하세요. 특정 도메인의 분기만 맞지 않는다면 해당 도메인과 관련 도메인의 규칙 우선순위를 살펴보세요. 전역 프록시로 계속 바꿔 둘 필요는 없습니다. 사용자 지정 규칙은 기존 직접 연결 설정이 사라지지 않도록 수정 전에 백업하세요.

지연 시간 테스트는 특정 방식으로 측정한 왕복 시간이나 핸드셰이크 성능만 보여 주며, 지속적인 전송 속도를 나타내지는 않습니다. 실제 속도는 대상 서버, 노드의 출구, 네트워크 혼잡, 서비스의 속도 제한, 로컬 무선 네트워크에도 영향을 받습니다. 같은 시간대에 같은 다운로드 대상을 정해 직접 연결과 프록시를 각각 테스트한 다음, 같은 구독에서 후보 노드를 몇 개만 비교하세요. 테스트 중에는 백그라운드 동기화를 일시 중지하고 트래픽 한도나 배율 제한이 없는지 확인하세요. 모든 노드의 속도를 한꺼번에 대량 측정하지 마세요. 대역폭을 소모하고 서버 제한을 유발해 결과를 비교하기 더 어려워질 수 있습니다.

먼저 구독 그룹, 수동 노드, 사용자 지정 라우팅, DNS, 로컬 수신 포트, 트래픽 처리 방식을 기록하세요. 그런 다음 현재 클라이언트가 지원하는 내보내기나 백업 기능으로 설정을 저장하세요. 백업 파일에는 인증 정보와 비공개 구독 주소가 포함될 수 있으므로 신뢰할 수 있는 곳에 보관하고, 로그를 공유할 때도 해당 내용을 가리세요. 업그레이드 후에는 노드 하나와 자주 쓰는 규칙 하나를 먼저 확인한 다음 복잡한 설정을 복원하세요. 플랫폼이나 클라이언트 간에 옮길 때는 원본 구독을 다시 가져오고 필요한 규칙을 직접 설정하는 편이 좋습니다. 설정 폴더 구조와 코어 형식이 다를 수 있어 전체 폴더를 덮어쓰면 이전 설정과 충돌할 수 있습니다.

먼저 구독 주소가 완전한지, 계정이 유효한지, 서비스에 장애 공지가 있는지 확인한 다음 업데이트 로그에서 구체적인 오류를 살펴보세요. 인증 실패나 접근 거부가 나타나면 설정 제공자에게 주소가 재설정되었는지 확인하세요. 시간 초과나 도메인 확인 실패가 발생하면 로컬 네트워크와 DNS를 점검하세요. 클라이언트에서 프록시를 거쳐 업데이트하는 방법과 직접 업데이트하는 방법을 모두 제공한다면 현재 네트워크에 맞는 방식을 선택하세요. 프록시를 사용하는 경우 해당 노드가 실제로 작동하는지도 확인해 업데이트가 막히지 않도록 하세요. 짧은 간격으로 계속 재시도하지 말고, 오류와 발생 시간을 기록한 뒤 조치하세요. 도움을 요청할 때 전체 구독 주소를 공개하지 마세요.

먼저 로컬 네트워크에서 일반 웹사이트에 접속할 수 있는지 확인한 뒤 클라이언트 코어가 제대로 실행되는지 살펴보세요. 설정이 완전한 것으로 확인된 노드 하나만 테스트하고, 주소와 포트, 전송 방식, 보안 매개변수가 제공자 안내와 일치하는지 확인하세요. 같은 그룹의 노드가 모두 시간 초과되면 사용이 허가된 다른 네트워크에서 다시 테스트하세요. 노드 하나만 실패한다면 해당 회선 상태를 우선 확인하세요. 로그에 TLS 핸드셰이크나 인증서 오류가 표시되면 무조건 포트 문제로 단정하지 말고 시스템 시간과 서버 이름을 확인하세요. 테스트 시간 초과는 현재 탐색이 실패했다는 뜻일 뿐이므로 실제 요청 로그와 함께 판단해야 합니다.

연결됨 표시나 코어 실행은 일부 시작 절차가 완료됐다는 뜻일 뿐, 대상 웹페이지 요청이 성공했다는 의미는 아닙니다. 먼저 브라우저 요청이 클라이언트 접근 로그에 나타나는지 확인하세요. 기록이 없다면 시스템 프록시, 로컬 수신 포트, 앱 자체의 프록시 설정을 먼저 살펴보세요. 기록은 있지만 요청이 실패한다면 선택한 노드, 라우팅 출구, DNS를 확인하세요. 다른 프록시 도구를 잠시 끄고 다시 테스트한 뒤 도메인 확인 오류와 연결 오류를 각각 비교하세요. 설정은 한 번에 하나씩만 바꾸고 기존 값을 기록해 두세요. 특정 웹사이트만 실패한다면 해당 사이트 상태, 브라우저 확장 프로그램, 관련 도메인도 확인해야 합니다.

시스템 네트워크 설정의 프록시 주소와 포트가 클라이언트의 현재 수신 설정과 일치하는지 확인한 다음, 해당 앱의 요청이 클라이언트 로그에 들어오는지 살펴보세요. 시스템 프록시 설정을 읽지 않는 앱도 있고, 브라우저 설정이나 확장 프로그램이 시스템 설정을 덮어쓸 수도 있습니다. 시스템 프록시를 따르는 브라우저로 먼저 확인하고, 필요하면 앱을 완전히 종료한 뒤 다시 실행하세요. 다른 프록시나 VPN 도구가 있다면 설정이 계속 바뀌지 않도록 해당 도구의 트래픽 처리를 먼저 끄세요. 시스템 프록시를 지원하지 않는 앱을 처리해야 한다면 안내에 따라 TUN을 검토하고 라우팅과 DNS를 확인하세요. 로컬 연결 문제를 해결하려고 수신 주소를 공개 주소로 바꾸지 마세요.