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

V2Ray는 일반적으로 Project V 프록시 생태계의 관련 기술과 도구를 가리킵니다. 코어는 프로토콜 처리, 연결 설정, 라우팅을 담당하고 GUI 클라이언트는 서버, 구독 및 실행 옵션을 관리합니다. v2rayN, v2rayNG, v2flyNG는 GUI 클라이언트이며 V2Fly와 Xray는 관련 코어 프로젝트입니다. 프로토콜 호환성 문제가 발생하면 화면에 표시된 이름만 보지 말고 클라이언트 버전과 실제 실행 중인 코어를 함께 확인하세요.

Windows, macOS, Linux 데스크톱에서는 v2rayN을 우선 고려하세요. Android에서는 보통 Xray 코어를 사용하는 v2rayNG를 먼저 선택하고, V2Fly 코어가 필요한 경우 v2flyNG를 고려하면 됩니다. 어느 클라이언트든 프록시 연결을 설정하려면 유효한 서버 설정이 필요하며, 앱을 설치한다고 사용할 수 있는 서버가 자동으로 생기지는 않습니다. 운영체제와 프로세서 아키텍처, 서버가 요구하는 프로토콜 및 전송 설정을 확인한 뒤 다운로드 페이지에서 알맞은 파일을 선택하세요.

구독 링크는 보통 업데이트 가능한 서버 목록을 제공하며, 업데이트하면 해당 구독 주소에서 설정을 다시 가져옵니다. 개별 공유 링크는 대개 서버 하나의 정보만 담고 있어 가져온 뒤 원본의 변경 사항이 자동 반영되지 않습니다. 링크를 받으면 먼저 종류를 확인한 다음 구독 설정에 추가하거나 클립보드에서 서버를 가져오세요. 구독 주소에 인증 정보가 포함될 수 있으므로 공개 게시판에 올리지 마세요. 도움을 요청할 때는 가져온 방법과 오류 내용을 설명하고 전체 주소는 공개하지 않는 것이 좋습니다.

시스템 프록시는 시스템 설정을 따르는 앱의 연결을 클라이언트로 전달할지 결정하고, 라우팅 규칙은 코어에 들어온 연결을 직접 연결할지 프록시로 보낼지 결정합니다. 클라이언트의 글로벌 프록시는 보통 코어에 들어온 트래픽을 모두 프록시 출구로 보내지만, 모든 앱의 트래픽이 코어에 들어온다는 뜻은 아닙니다. 버전에 따라 시스템 프록시와 라우팅 옵션이 별도로 배치되기도 합니다. 따라서 전체 프록시 옵션 하나만 보고 적용 범위를 판단하지 말고 트래픽 유입 경로와 출구 규칙을 각각 확인하세요.

클라이언트의 드롭다운에서 프로토콜 이름만 바꾼다고 전환이 완료되는 것은 아닙니다. 프로토콜, 서버 포트, 인증 정보, 전송 방식, TLS 등의 설정이 서버와 일치해야 하며 클라이언트 코어도 해당 기능을 지원해야 합니다. 기존 공유 링크를 가져왔다면 제공된 설정을 그대로 유지하세요. 프로토콜을 바꾸려면 서버 측에서 해당 프로토콜용으로 제공하는 전체 설정이 필요합니다. REALITY 같은 보안 설정도 특정 코어의 지원 여부에 따라 달라지므로 호환되지 않으면 먼저 설정 요구 사항을 확인하세요.

2015년 이후 출시된 주요 Android 스마트폰은 보통 arm64를 먼저 시도할 수 있지만, 최종적으로는 기기의 프로세서와 운영체제가 지원하는 앱 아키텍처를 기준으로 선택해야 합니다. 일부 기기는 64비트 프로세서를 사용해도 32비트 앱만 지원하는 운영체제를 실행하므로 arm64 파일이 설치되지 않을 수 있습니다. 아키텍처를 모르겠다면 여러 아키텍처 구성 요소를 포함하는 universal 버전을 선택하세요. 파일 크기는 더 큰 편입니다. 그래도 설치 파일을 분석할 수 없다는 오류가 나오면 운영체제 버전 요구 사항과 다운로드 완료 여부를 확인하세요.

먼저 구독 설정에서 주소가 올바른 그룹에 저장됐는지 확인한 뒤 해당 그룹의 구독을 업데이트하세요. 주소를 저장하는 것만으로 서버 목록이 바로 생성되지는 않을 수 있습니다. 업데이트가 성공했는데도 목록이 비어 있으면 현재 그룹 필터, 이름 필터, 구독 내용의 유효성을 확인하세요. 파싱 오류가 표시되면 로그인 페이지나 안내 페이지, 개별 공유 링크가 아니라 전체 구독 주소를 복사했는지 살펴보세요. 필터를 잠시 끄고 다시 업데이트하면 내용 누락인지 표시 조건 문제인지 구분하는 데 도움이 됩니다.

시스템의 ‘이 Mac에 관하여’에서 칩 또는 프로세서 정보를 확인하세요. Apple M 시리즈 칩이라면 Apple Silicon용 arm64 파일을, Intel 프로세서라면 x64 파일을 선택하면 됩니다. 호환성 변환에 의존하기보다 기기 아키텍처에 맞는 설치 파일을 사용하세요. 처음 실행할 때 보안 경고가 표시되면 먼저 파일 출처와 지원하는 시스템을 확인하고 시스템 설정의 안내에 따라 처리하세요. 앱 실행을 위해 시스템 보안 기능 전체를 끄지는 마세요.

먼저 코어가 실행 중인지 확인하고 시스템 프록시 주소가 클라이언트의 실제 로컬 수신 주소와 포트를 가리키는지 살펴보세요. 다음으로 브라우저에 별도의 프록시 설정이나 프록시 확장 프로그램이 있는지 확인하세요. 이런 설정이 시스템 설정을 덮어쓸 수 있습니다. 기업 정책, 다른 프록시 프로그램, 수동으로 입력한 이전 포트도 충돌을 일으킬 수 있습니다. 문제를 확인할 때는 프록시 관리 경로를 하나만 남기고 브라우저를 다시 열어 테스트하세요. 클라이언트 로그를 함께 확인하면 요청이 실제로 코어에 들어왔는지 알 수 있습니다.

데스크톱 TUN은 보통 가상 네트워크 인터페이스를 만들거나 라우팅을 변경해야 합니다. 클라이언트 안내에 따라 필요한 관리자 권한, 보조 서비스 권한 또는 시스템 승인을 허용한 뒤 실행하세요. Android 클라이언트에서는 시스템의 VPN 연결 권한을 확인하고 다른 앱이 해당 연결을 사용 중인지 살펴보세요. 필요한 권한은 시스템과 클라이언트 버전에 따라 다를 수 있으니 시작 로그에서 가장 먼저 나타난 오류를 확인하고 스위치를 반복해서 켜고 끄지 마세요. 테스트 전에는 다른 VPN 또는 TUN 도구를 종료해 라우팅과 인터페이스 충돌을 방지하세요.

구독 출처마다 별도 그룹을 만들고, 출처나 용도를 알아보기 쉬운 이름으로 지정하세요. 주소에 포함된 인증 정보는 그룹 이름에 넣지 마세요. 가져온 뒤 각 그룹을 따로 업데이트하고 내용을 확인한 다음 필요한 이름 필터를 설정하세요. 필터는 표시 또는 선택 범위만 바꾸며 서버를 삭제하지 않습니다. 직접 편집한 서버는 별도 그룹에 저장하는 편이 좋습니다. 그래야 이후 구독 업데이트에서 출처의 설정으로 덮어쓰이지 않습니다. 업데이트 후 현재 서버가 여전히 유효한지도 확인하세요.

일상적인 사용에서는 프록시가 필요한 대상만 프록시로 보내고 나머지는 규칙에 따라 직접 연결하는 규칙 기반 라우팅을 먼저 고려하세요. 글로벌 프록시는 라우팅과 관련된 문제인지 짧게 확인할 때 유용하며 모든 오류를 해결하는 만능 방법은 아닙니다. 어떤 사이트가 글로벌 모드에서는 정상인데 규칙 모드에서는 작동하지 않는다면 도메인, 관련 리소스, 규칙 순서를 확인하세요. 테스트를 마친 뒤 원래 모드로 되돌리고, 직접 연결·글로벌·규칙 등의 표시 이름은 클라이언트 버전에 따라 다를 수 있다는 점에 유의하세요.

클라이언트가 정상 실행 중일 때 로그나 연결 기록을 열고 대상 앱에서 새 요청을 보내 대상 주소와 출구 정보가 나타나는지 확인하세요. 기존에 열린 장시간 연결은 바로 다시 설정되지 않을 수 있으므로 필요하면 앱을 종료한 뒤 테스트하세요. 웹페이지가 열린다는 사실만으로 프록시 사용 여부를 입증할 수는 없습니다. 선택한 서버, 라우팅 결과, 로그를 함께 확인하세요. 로그를 공유하기 전에는 구독 주소, 인증 정보 및 기타 민감한 내용을 가리세요.

포트 충돌이 없다면 보통 클라이언트의 기본 설정을 그대로 사용하면 됩니다. 튜토리얼에 나온 특정 숫자를 그대로 적용할 필요는 없습니다. 수신 포트를 변경했다면 시스템 프록시, 브라우저의 개별 프록시 설정, 프록시를 수동으로 설정한 다른 앱도 함께 확인하세요. HTTP, SOCKS, 혼합 포트도 구분해야 합니다. 숫자가 같다고 프로토콜을 서로 바꿔 쓸 수 있는 것은 아닙니다. 이 기기에서만 사용한다면 로컬 수신 범위를 유지하세요. LAN 접근을 허용하기 전에는 인증과 방화벽 설정을 먼저 확인하세요.

더 많은 앱의 트래픽을 처리하려고 두 가지 연결 경로를 동시에 설정할 필요는 보통 없습니다. 먼저 클라이언트의 TUN 안내에 따라 단독으로 테스트하세요. 두 기능을 함께 켠다고 반드시 문제가 생기는 것은 아니지만 요청 경로를 파악하고 루프를 제외하거나 남은 설정을 정리하기가 더 어려워집니다. 기존 상태를 기록한 다음 시스템 프록시를 끄고 TUN을 켜서 일반 앱과 DNS 요청이 어떻게 처리되는지 확인하세요. 특정 앱에 별도 프록시가 꼭 필요할 때만 해당 앱을 대상으로 설정하세요. 클라이언트를 종료하기 전 관련 스위치를 원래대로 돌려 유효하지 않은 프록시 주소가 남지 않게 하세요.

먼저 오류가 시간 초과, 이름 확인 실패, 인증 거부, 콘텐츠 파싱 실패 중 무엇인지 확인한 뒤 업데이트 경로를 정하세요. 구독 주소에 직접 연결할 수 있으면 클라이언트의 직접 연결 업데이트를 먼저 사용하세요. 프록시를 거쳐야 한다면 아직 사용할 수 있는 서버를 선택한 뒤 프록시를 통해 업데이트하세요. 기존 서버가 모두 작동하지 않는다면 해당 서버로 업데이트를 시도하지 말고 구독 제공처에 유효한 접속 경로를 문의하세요. 구독 만료, 접근 거부, 로그인 페이지 반환 문제는 프록시 경로를 계속 바꿔도 대개 해결되지 않습니다.

시간 초과는 정해진 시간 안에 테스트에서 기대한 응답을 받지 못했다는 뜻이지, 서버가 작동하지 않는다고 단정할 수는 없습니다. 먼저 로컬 네트워크가 정상인지 확인한 뒤 같은 테스트 방식으로 다른 서버와 비교하고 기기 시간, 구독 유효 기간, 서버 설정을 살펴보세요. 클라이언트마다 지연 시간을 측정하는 방법이 다를 수 있어 결과를 단순 비교하기는 어렵습니다. 모든 서버가 동시에 시간 초과되면 로컬 네트워크, 코어 실행 상태, 테스트 대상을 먼저 확인하세요. 일부 서버만 시간 초과될 때는 해당 서버의 서비스 상태를 점검하세요.

연결됨 표시는 코어나 시스템 VPN 인터페이스가 시작됐다는 뜻일 수 있지만 원격 요청까지 정상이라는 보장은 없습니다. 먼저 유효한 서버를 선택했는지 확인한 뒤 직접 접속 가능한 사이트와 프록시가 필요한 대상을 각각 열어 보세요. 이어서 로그에 DNS, 핸드셰이크 또는 연결 시간 초과 오류가 있는지 확인하세요. 브라우저에서만 문제가 생기면 별도의 프록시 설정과 보안 DNS를 점검하세요. 모든 앱에서 문제가 생기면 TUN과 시스템 프록시를 끄고 기본 네트워크를 확인한 다음 연결 방식을 한 번에 하나씩 다시 활성화하세요. 여러 설정을 동시에 바꾸면 원인을 찾기 어렵습니다.

먼저 클라이언트를 중복 실행했는지, 다른 프록시 프로그램이 같은 수신 포트를 사용 중인지 확인하세요. 중복 프로세스를 종료한 뒤 다시 시작하세요. 필요한 다른 프로그램이 해당 포트를 실제로 사용 중이라면 로컬 포트를 바꾸고 시스템 프록시 설정도 함께 수정하세요. 코어 시작 실패는 호환되지 않는 설정 항목, 누락된 실행 구성 요소, 보안 프로그램의 차단 때문에 발생할 수도 있습니다. 로그에서 가장 먼저 나타난 오류부터 확인하세요. 모든 설정을 바로 삭제하지 말고 구독과 사용자 지정 규칙을 먼저 백업한 뒤 오류 유형에 따라 하나씩 처리하세요.

인증서 검증을 끄는 방식으로 오류를 덮는 것은 권장하지 않습니다. 먼저 기기의 날짜와 시간, 시간대를 올바르게 설정하고 서버 주소, TLS 서버 이름 및 관련 설정이 제공된 정보와 일치하는지 확인하세요. 이름 확인에 실패하면 현재 네트워크에서 DNS에 접근할 수 있는지 살펴보고, 서버 도메인과 대상 웹사이트 도메인의 확인을 구분하세요. 두 도메인은 서로 다른 경로를 사용할 수 있습니다. DNS를 변경하거나 FakeDNS를 켠 뒤에만 문제가 생긴다면 이전에 작동하던 설정으로 되돌린 다음 현재 코어 및 TUN 설정을 하나씩 조정하세요.