V2Ray FAQ
및 문제 해결

기기에 맞는 그래픽 클라이언트를 먼저 선택한 다음 코어를 알아보세요. V2Ray는 보통 Project V 프록시 생태계의 핵심 프로젝트를 가리킵니다. V2Fly는 이를 이어가는 커뮤니티 프로젝트이며, Xray는 관련 코어 프로젝트입니다. v2rayN은 Windows, macOS, Linux용 데스크톱 클라이언트로, 설정을 관리하고 코어를 실행하며 프록시를 구성합니다. v2rayNG는 Xray 코어를 사용하는 Android 클라이언트입니다. 클라이언트 인터페이스와 코어는 서로 다른 계층이므로, 인터페이스가 실행된다고 코어까지 작동하는 것은 아닙니다. 문제를 확인할 때는 설정을 가져왔는지, 코어가 실행 중인지, 앱 트래픽이 프록시로 들어가는지 각각 확인하세요.

네. 사용할 권한이 있는 서버 설정이나 구독 링크를 준비한 뒤 클라이언트로 가져와야 합니다. 클라이언트는 설정 관리와 트래픽 전달 기능을 제공하지만, 연결할 원격 서버를 포함하지는 않습니다. 구독은 보통 여러 서버 설정을 하나의 주소로 제공하며, 업데이트하면 클라이언트에 서버 항목이 생성됩니다. 개별 공유 링크는 대개 하나의 설정만 담고 있습니다. 서비스 제공자의 로그인 페이지 주소를 구독 링크로 착각하지 말고, 구독 링크를 공개 게시판에 올리지 마세요. 구독에는 접속 인증 정보가 포함될 수 있으므로 스크린샷, 로그, 문의 자료를 공유하기 전에 링크와 사용자 식별 정보, 인증 내용을 가리세요.

먼저 트래픽이 클라이언트로 들어오는 방식을 확인한 다음, 들어온 트래픽이 어떤 경로로 나가는지 살펴보세요. 시스템 프록시는 운영체제에 프록시 주소를 등록하며, 해당 설정을 따르는 앱에만 적용됩니다. 전역 라우팅은 보통 코어에 들어온 트래픽을 프록시 출구로 보내는 것을 뜻하며, 기기의 모든 프로그램을 가로채는 것은 아닙니다. TUN은 가상 네트워크 인터페이스를 통해 지정된 범위의 트래픽을 받아 시스템 프록시를 사용하지 않는 앱에 적합하지만, 권한과 라우팅, DNS 설정이 필요합니다. 처음 설정할 때는 시스템 프록시로 먼저 확인하고, 필요한 경우 TUN을 테스트하세요. 트래픽 유입 방식과 라우팅 규칙을 동시에 바꾸지 않는 것이 좋습니다.

실제 이용하려는 웹사이트나 앱에서 문제를 재현한 다음 서버별로 비교하세요. 지연 시간 테스트는 특정 방식과 대상에 대한 응답 시간만 보여 줄 뿐, 지속적인 대역폭이나 모든 웹사이트의 접속 가능성을 나타내지는 않습니다. 웹페이지 로딩은 DNS, 전송 중 패킷 손실, 원격 출구, 대상 서비스와 로컬 네트워크의 영향도 받습니다. 비교할 때는 네트워크, 라우팅 모드, 테스트 대상을 동일하게 유지하고 서버만 하나씩 바꾸세요. 작은 페이지는 잘 열리지만 대용량 파일이 느리다면 대역폭과 패킷 손실을 확인하세요. 특정 웹사이트만 문제라면 해당 도메인의 분기 라우팅 결과와 서비스 상태부터 살펴보세요.

기기의 프로세서와 운영체제가 지원하는 앱 아키텍처를 먼저 확인하세요. 비교적 최신 Android 휴대전화는 대체로 arm64를 선택할 수 있으며 설치 파일도 더 작습니다. 아키텍처를 모른다면 여러 아키텍처용 파일을 포함하는 universal을 선택할 수 있지만 용량이 더 큽니다. 프로세서가 64비트를 지원해도 운영체제에서 64비트 앱 설치를 허용하는 것은 아닙니다. 특히 구형 기기라면 지원 여부를 확인하세요. 설치 파일이 호환되지 않는다는 메시지가 나오면 아키텍처, 운영체제 버전, 저장 공간부터 확인한 뒤 다른 파일을 고려하세요. 기존 클라이언트를 업데이트할 때는 패키지명과 서명이 일치하는지도 확인해야 합니다. 삭제 후 재설치하기 전에는 내보낼 수 있는 설정을 백업하세요.

Windows 사용자는 다운로드 페이지의 시스템 요구 사항을 확인하고 데스크톱 버전을 선택하면 됩니다. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용해 통일된 사용 흐름으로 시작하기 좋습니다. 기존 인터페이스에 익숙하다면 WPF 버전을 선택하고 필요한 실행 환경이 설치되어 있는지 확인하세요. 두 버전은 메뉴 위치와 설정 이름이 다를 수 있으므로 오래된 튜토리얼의 스크린샷만 보고 기능이 없다고 판단하지 마세요. 업그레이드하거나 버전을 바꾸기 전에는 실행 중인 클라이언트를 종료하고 설정을 백업하세요. 두 인스턴스가 로컬 포트를 두고 충돌하지 않도록 별도 폴더에서 테스트하는 것도 좋습니다. macOS와 Linux 사용자는 해당 플랫폼용 데스크톱 설치 파일을 선택하세요.

복사한 구독 주소가 완전한지 확인하고 앞뒤 공백과 줄바꿈을 제거하세요. 링크가 만료되었거나 초기화되었는지, 재인증이 필요한지도 확인합니다. 다음으로 클라이언트가 해당 구독 형식을 지원하는지 살펴보세요. 로그인 페이지나 오류 페이지, 다른 클라이언트 전용 설정을 내려받으면 서버 정보를 파싱하지 못할 수 있습니다. 업데이트 요청을 기존 프록시로만 보낼 수 있다면, 먼저 연결 가능한 설정을 선택한 뒤 프록시를 통한 업데이트를 시도하세요. 문제를 확인할 때는 기존 그룹을 그대로 두고 테스트 그룹을 새로 만들어 가져오세요. 유효한 설정이 덮어써지는 일을 막을 수 있습니다. 로그에서는 오류 유형만 확인하고, 공유하기 전에 구독 주소 전체를 가리세요.

먼저 TUN을 끄고 일반 시스템 프록시로 연결되는지 확인한 뒤 권한 문제를 따로 해결하세요. Windows에서는 클라이언트 안내에 따라 필요한 서비스를 설치하거나 실행하고, 필요하면 관리자 권한을 사용합니다. macOS와 Linux에서는 해당 버전 안내에 따라 시스템 권한을 허용하거나 권한이 필요한 서비스를 설정하세요. 다른 플랫폼의 명령을 그대로 적용하지 마세요. Android 클라이언트는 시스템 VPN 권한을 사용하므로 처음 연결할 때 권한 요청을 승인해야 합니다. 기존 VPN이나 다른 가상 네트워크 도구와 충돌할 수 있으니 먼저 종료한 뒤 다시 테스트하세요. 권한 설정을 마치면 TUN을 다시 켜고 로그에서 인터페이스와 라우팅이 생성되었는지 확인하세요. 스위치가 켜졌는지만 봐서는 안 됩니다.

연결 가능한 서버를 선택하고 시스템 프록시 자동 설정을 켠 다음, 운영체제 설정의 프록시 주소와 포트가 클라이언트의 수신 설정과 일치하는지 확인하세요. 시스템 프록시를 따르는 브라우저로 테스트 페이지를 열고, 클라이언트 로그나 연결 기록에 해당 요청이 나타나는지 확인합니다. 더 확실하게 테스트하려면 명령줄 도구에서 로컬 프록시 포트를 명시적으로 사용한 결과와 프록시를 사용하지 않은 결과를 비교하세요. 두 테스트는 서로 다른 유입 경로를 확인합니다. 브라우저 확장 프로그램, 자체 프록시 설정, 캐시가 결과에 영향을 줄 수 있습니다. 외부 IP 주소 변경은 보조 증거로만 보고, 요청 기록과 라우팅 결과도 함께 확인하는 것이 좋습니다.

먼저 기본 분기 라우팅을 사용해 안정적인 기준 상태를 만들고, 자주 쓰는 웹사이트와 로컬 네트워크 기기, 업무용 앱에 모두 정상적으로 접속되는지 확인하세요. 분기 라우팅은 도메인, 주소, 규칙 순서에 따라 직접 연결하거나 프록시를 사용하므로 일상적인 혼합 접속에 적합합니다. 전역 라우팅은 특정 문제가 분기 규칙 때문인지 잠시 확인할 때 유용합니다. 전역 라우팅에서는 정상인데 분기 라우팅에서는 문제가 생긴다면, 전역 설정에 계속 의존해 문제를 가리지 말고 대상 도메인에 적용된 규칙, DNS 결과, 규칙 리소스의 사용 가능 여부를 확인하세요. 테스트가 끝나면 원래 설정으로 되돌리고, 내부 네트워크 서비스가 원격 출구로 잘못 전달되지 않는지 살펴보세요. 프린터, 파일 공유, 기업 네트워크에 문제가 생길 수 있습니다.

구독 출처별로 그룹을 나누고 알아보기 쉬운 이름을 붙이세요. 같은 구독을 여러 위치에 중복으로 가져오지 않는 것이 좋습니다. 업데이트 전에 현재 사용 중인 항목과 주요 매개변수를 기록하고, 업데이트 후에도 선택한 항목이 유효한지 다시 확인하세요. 서버 측에서 설정을 삭제하거나 이름 또는 내용을 바꿀 수 있습니다. 직접 추가한 설정은 구독 업데이트로 바뀌지 않도록 별도 그룹에 두세요. 사용할 수 없는 그룹은 주기적으로 정리하되 모든 설정을 자주 초기화하지 마세요. 자동 업데이트를 사용한다면 현재 네트워크에서 업데이트 주소에 접속할 수 있는지 확인하세요. 문제가 생기면 다시 가져오기 전에 업데이트 시각과 로그부터 살펴보세요.

기존 설정을 백업하고 현재 코어와 정상 작동이 확인된 설정 하나를 기록하세요. 그런 다음 새 코어가 해당 설정의 프로토콜, 전송 방식, 보안 매개변수를 지원하는지 확인합니다. 클라이언트에 전환 옵션이 있다고 해서 모든 설정을 그대로 쓸 수 있는 것은 아닙니다. 특히 확장 필드, DNS 설정, TUN 구현의 차이에 주의하세요. 전환 후에는 간단한 라우팅과 서버 하나로 먼저 테스트하고, 연결이 정상일 때 사용자 지정 규칙을 복구하세요. 알 수 없는 필드나 시작 오류가 나타나면 기존 코어로 돌아가 로그를 비교하세요. 매개변수를 연달아 삭제하며 시험하지 마세요. 변경 원인을 찾기 쉽도록 클라이언트와 코어 업데이트도 따로 검증하는 것이 좋습니다.

로컬 환경, 구독, 서버, 운영체제의 네 단계로 확인하세요. 먼저 기기 시간이 정확하고 네트워크를 사용할 수 있는지, 코어 실행 후 로컬 포트가 실제로 수신 대기 중인지 확인합니다. 그다음 구독을 업데이트해 이전 주소, 만료된 인증 정보, 불완전한 가져오기를 점검하세요. 이어서 서버 주소, 포트, 전송 방식, 보안 매개변수를 확인하고 같은 네트워크에서 이미 작동하는 다른 설정과 비교합니다. 마지막으로 방화벽, 다른 프록시 도구, 가상 네트워크 간의 충돌을 살펴보세요. 한 번의 시간 초과만으로 원격 서버가 작동하지 않는다고 단정할 수 없습니다. 반복 테스트에서는 대상과 조건을 동일하게 유지하세요. 처음 오류가 발생한 시각과 로그 유형을 기록하면 반복해서 재설치하는 것보다 원인을 찾는 데 도움이 됩니다.

코어 로그를 확인해 로컬 프록시나 VPN 인터페이스만 켜진 것이 아니라 원격 연결까지 실제로 성공했는지 확인하세요. 다음으로 브라우저 요청이 클라이언트에 들어오는지 살펴봅니다. 요청이 없다면 시스템 프록시, 브라우저 자체 설정, 로컬 포트를 확인하세요. 요청은 있지만 실패한다면 라우팅, DNS, 서버 연결 상태를 확인합니다. 도메인으로 접속할 때만 실패한다면 DNS 조회 오류를 먼저 살펴보세요. 로컬 네트워크와 모든 웹사이트에서 동시에 문제가 생기면 TUN을 끄고 다시 테스트해 라우팅 충돌을 확인하세요. 프록시 유입 경로 하나와 클라이언트 하나만 남겨 다른 도구의 영향을 배제하고, DNS와 포트, 라우팅 모드를 한꺼번에 바꾸지 마세요.

기존 설정을 보존하고 목록을 비우지 마세요. 기존 서버에 연결된다는 것은 프록시 연결이 정상이라는 뜻일 뿐, 구독 주소도 유효하다는 뜻은 아닙니다. 구독이 초기화되거나 만료되었는지, 요청 제한에 걸렸는지 확인하고 기기 시간과 인증서 오류도 살펴보세요. 직접 연결로 업데이트에 실패하면 연결 가능한 서버를 선택한 뒤 프록시를 통한 업데이트를 시도할 수 있습니다. 프록시를 통한 업데이트가 실패하면 직접 연결 결과와도 비교해 업데이트 요청이 서로 의존하지 않도록 하세요. 서버에서 로그인 페이지를 반환하거나 응답 형식이 바뀌었다면 호환되는 링크를 다시 받아야 합니다. 짧은 시간에 반복해서 새로고침하지 마세요. 상태 코드와 오류 요약을 기록하고, 구독 제공자에게 문의할 때는 인증 정보를 가리세요.

포트가 사용 중이면 클라이언트 인스턴스를 두 개 실행했는지 먼저 확인한 다음, 운영체제의 네트워크 도구로 해당 수신 포트를 점유한 프로세스를 찾으세요. 용도를 확인한 뒤 충돌하는 프로그램을 종료하거나 설정에서 사용 가능한 포트로 바꾸고, 수동으로 프록시를 설정한 브라우저와 다른 앱에도 같은 포트를 적용하세요. 출처를 알 수 없는 시스템 프로세스를 종료하지 마세요. 클라이언트를 종료한 뒤에도 직접 연결이 안 되면 운영체제의 프록시 설정에서 남아 있는 수동 프록시나 자동 설정 주소를 끄고, TUN과 다른 VPN이 계속 실행 중인지 확인하세요. 네트워크를 복구한 뒤 클라이언트 하나만 실행해 테스트하세요. 이후에는 시스템 프록시를 먼저 해제한 다음 정상적으로 종료하는 것이 좋습니다.