V2Ray 자주 묻는 질문

Windows, macOS, Linux 데스크톱에서는 구독 그룹 관리, 시스템 프록시, 라우팅 설정을 지원하는 v2rayN을 주로 사용합니다. Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 고려하세요. 기존 설정이 V2Fly에 명확히 의존하는 경우에는 v2flyNG를 검토할 수 있습니다. 이름이 비슷하다고 설치 파일이나 설정을 서로 그대로 사용할 수 있는 것은 아니며, 데스크톱 설치 파일을 휴대폰에 설치해서도 안 됩니다. 운영체제에 맞는 클라이언트를 선택한 뒤 노드 프로토콜, 전송 방식, 코어 지원 여부를 확인하세요. 화면이 비슷하다는 이유만으로 설정 전체를 그대로 옮기지 마세요.

V2Ray는 일반적으로 Project V 생태계의 프록시 도구와 관련 설정 체계를 가리키며, V2Fly는 그중 코어 개발을 이어가고 Xray는 별도의 코어 분기입니다. GUI 클라이언트는 구독을 저장하고 노드를 선택해 실행 설정을 생성하며, 실제 연결은 코어가 담당합니다. 따라서 화면에서 공유 링크를 인식하더라도 현재 코어가 해당 링크의 모든 매개변수를 지원한다는 뜻은 아닙니다. REALITY나 특정 혼잡 제어 설정으로 실행되지 않는다면 노드 이름이 목록에 표시되는지만 볼 것이 아니라 클라이언트의 파싱 결과와 코어 로그를 함께 확인하세요.

클라이언트는 설정 및 연결 도구일 뿐, 사용할 수 있는 원격 서비스 자체는 아닙니다. 연결하려면 서버 주소, 포트, 인증 정보, 프로토콜, 전송 매개변수가 필요하며, 보통 구독 주소나 개별 공유 링크를 통해 가져옵니다. 구독 주소는 여러 설정을 가져오는 경로이지 서버 주소 입력란에 넣는 값이 아닙니다. 가져오기 전에 출처와 사용 권한을 확인하고, 가져온 뒤에는 구독 그룹을 업데이트한 다음 노드를 선택하세요. 구독에 접속 정보가 포함될 수 있으므로 전체 주소, 공유 링크, QR 코드를 공개 게시판에 올리지 마세요.

Mac에서는 Apple 메뉴의 ‘이 Mac에 관하여’를 먼저 여세요. Apple 칩이 표시되면 Apple Silicon용 arm64 패키지를, Intel 프로세서가 표시되면 x64 패키지를 선택하면 됩니다. Android용 arm64와 universal은 별도의 설치 파일 선택지이므로 Mac 다운로드 항목과 혼동하지 마세요. 2015년 이후 출시된 일반적인 Android 휴대폰은 arm64를 우선 고려할 수 있지만, 최종 선택은 기기 운영체제가 지원하는 앱 아키텍처에 따라 달라집니다. 구형 기기이거나 설치 중 아키텍처가 호환되지 않는다는 메시지가 나오면 universal 버전을 사용해 보세요. universal 버전은 더 많은 아키텍처 구성 요소를 포함해 파일 크기가 더 클 수 있지만, 연결 속도가 더 빠르다는 뜻은 아닙니다.

먼저 받은 것이 구독 주소인지, 개별 공유 링크인지, 기본 JSON인지 확인하세요. 구독 주소는 구독 그룹 설정에 입력한 뒤 업데이트해야 합니다. 개별 공유 링크는 클립보드에서 가져오기 등 해당 기능을 이용하고, 기본 JSON은 클라이언트가 지원하는 사용자 지정 설정 방식으로 처리하세요. 복사할 때 앞뒤 공백과 줄바꿈, 메신저에 덧붙은 안내 문구를 제거하세요. 로그에 형식을 인식할 수 없다고 나오면 해당 주소가 로그인 페이지나 오류 페이지가 아닌 설정 내용을 반환하는지 확인하고, 제공자에게 클라이언트에서 인식할 수 있는 형식을 요청하세요. 웹페이지 주소를 노드로 반복해서 가져오지 마세요.

현재 작동하는 구독 그룹은 그대로 두고 업데이트 중 표시된 오류를 기록하세요. 구독이 만료되었는지, 주소가 변경되었는지, 현재 네트워크에서 구독 서버에 접속할 수 있는지 확인합니다. 업데이트할 때 프록시가 필요하다면 아직 사용할 수 있는 노드를 선택한 뒤, 클라이언트에 프록시를 통한 업데이트 옵션이 있는지 확인하세요. 현재 프록시가 작동하지 않으면 구독 서버에 접속 가능한 다른 네트워크에서 다시 시도합니다. 브라우저에서 주소가 열리더라도 올바른 형식의 응답이 온다는 보장은 없으므로 로그인 페이지나 접근 제한도 확인하세요. 처음부터 모든 노드를 지우면 사용 가능한 연결과 문제 해결에 필요한 비교 기준을 잃을 수 있습니다.

먼저 v2rayN 코어가 정상 실행 중인지 확인하고 시스템 프록시 메뉴에서 ‘시스템 프록시 자동 설정’을 선택하세요. 그런 다음 시스템 설정의 네트워크 프록시 화면에서 현재 사용하는 Wi-Fi 또는 유선 네트워크에 클라이언트의 로컬 수신 주소와 포트가 설정되어 있는지 확인합니다. macOS 버전에 따라 메뉴 이름과 위치가 다를 수 있습니다. 테스트할 앱을 종료한 뒤 다시 실행하세요. 시스템 프록시는 해당 설정을 따르는 앱에만 적용됩니다. 앱 자체 프록시 옵션, 환경 변수, 다른 프록시 도구가 시스템 설정을 덮어쓸 수도 있습니다. 특정 명령줄 프로그램이 프록시를 사용하지 않는다는 이유만으로 시스템 설정 전체가 작동하지 않는다고 판단하지 마세요.

TUN은 가상 네트워크 인터페이스를 만들고 관련 네트워크 설정을 변경하므로 보통 추가 권한이 필요합니다. 먼저 다른 VPN이나 비슷한 네트워크 제어 도구를 종료한 다음, 현재 클라이언트 버전의 권한 안내에 따라 승인하세요. Windows에서는 관리자 권한이 필요할 수 있으며, macOS와 Linux의 처리 방법은 클라이언트의 권한 지원 방식에 따라 달라집니다. 다른 플랫폼의 명령을 그대로 적용하거나, 원인을 알 수 없는 오류를 덮기 위해 반복해서 높은 권한으로 실행하지 마세요. 먼저 일반 시스템 프록시로 노드 연결을 확인한 뒤 TUN을 별도로 켜세요. 그래도 실패하면 처음 표시된 오류와 인터페이스 생성 관련 로그를 저장하고 권한 및 라우팅 충돌을 하나씩 확인하세요.

두 설정은 서로 다른 단계에 적용됩니다. ‘시스템 프록시 자동 설정’은 시스템 프록시를 따르는 앱이 요청을 로컬 클라이언트로 보낼지 결정합니다. ‘중국 본토 우회’는 트래픽이 코어에 들어온 뒤 직접 연결할지 프록시로 내보낼지 정하는 라우팅 프리셋입니다. 시스템 프록시 자동 설정과 중국 본토 우회를 함께 사용할 수도 있고, 클라이언트에 들어온 트래픽을 전역 프록시 규칙으로 처리할 수도 있습니다. 앱이 요청을 클라이언트로 보내지 않는다면 라우팅 프리셋만 바꿔도 보통 결과는 달라지지 않습니다. 문제를 확인할 때는 먼저 트래픽이 들어오는 경로를 확인하고, 그다음 규칙 매칭과 최종 출구를 살펴보세요. 시스템 프록시 메뉴를 라우팅 모드 전환 기능으로 혼동하지 마세요.

테스트 방식을 먼저 확인한 다음 결과를 비교하세요. TCP 연결 테스트는 주로 포트에 연결할 수 있는지를 보여주며, 애플리케이션 계층의 지연 시간 테스트에는 핸드셰이크와 테스트 대상의 응답도 영향을 줍니다. 둘 다 다운로드 속도와 같지는 않습니다. 같은 네트워크와 테스트 대상, 시간대를 기준으로 비교하고, 먼저 자주 쓰는 웹페이지가 열리는지 확인한 다음 지속적인 데이터 전송이 안정적인지 살펴보세요. 많은 노드를 동시에 테스트한 직후 한 번의 결과만으로 순위를 매기지 마세요. 네트워크 혼잡이나 서버 측 속도 제한이 결과에 영향을 줄 수 있습니다. 지연 시간이 낮은 노드에서도 대상 사이트에 접속할 수 없다면 반복 측정에 그치지 말고 DNS, 라우팅, 원격 출구를 확인하세요.

먼저 현재 DNS 설정을 기록하고 시스템 DNS, 브라우저의 암호화 DNS, 코어 DNS가 각각 요청 처리에 관여하는지 구분하세요. 일부 도메인만 접속되지 않을 때 로그에서 이름 해석 오류와 DNS 요청 경로, 라우팅 루프 여부를 확인합니다. 모든 DNS 리졸버와 분할 라우팅 규칙을 한꺼번에 바꾸지 마세요. TUN을 사용한다면 DNS가 어떤 범위까지 가로채지는지, 리졸버 주소에 직접 연결하거나 프록시를 통해 접속할 수 있는지도 확인해야 합니다. 같은 도메인으로 테스트하고 필요하면 관련 캐시를 비우세요. 원격 서버에 연결할 수 없거나 인증서 매개변수가 잘못된 문제는 DNS를 무작정 바꿔도 해결되지 않습니다.

먼저 구독 그룹 정보, 사용자 지정 라우팅, DNS 설정, 직접 관리하는 노드 매개변수를 백업하고 백업에 포함된 인증 정보가 공개되지 않도록 확인하세요. 코어를 바꾸기 전에는 새 코어가 현재 프로토콜과 전송 방식, REALITY 매개변수, 혼잡 제어 설정을 지원하는지 확인해야 합니다. 프로토콜 이름이 같다는 이유만으로 완전히 호환된다고 판단하지 마세요. 한 번에 하나씩 변경하세요. 먼저 노드를 바꿔 연결을 확인한 뒤 코어나 라우팅 설정을 조정합니다. 구독을 업데이트하면 구독에서 생성된 노드가 덮어써질 수 있으므로 직접 수정한 설정을 오래 유지하려면 별도 파일로 저장하세요. 여러 기기에서 사용할 때도 실행 설정 전체를 그대로 복사하지 말고 기기별 클라이언트 지원 여부를 확인하세요.

먼저 프록시를 끄고 원래 직접 접속할 수 있던 웹사이트에 기본 네트워크로 접속되는지 확인한 뒤 클라이언트 로그를 살펴보세요. 연결 시간 초과, 연결 거부, 도메인 이름 해석 실패, 인증 실패는 서로 다른 오류이므로 모두 시간 초과로 처리해서는 안 됩니다. 서버 주소와 포트가 잘못 변경되지 않았는지, 기기 시간이 정확한지 확인한 다음 같은 노드로 다른 네트워크에서 테스트하세요. 한 노드만 실패한다면 해당 노드의 서비스와 매개변수를 먼저 확인합니다. 모든 노드가 실패한다면 로컬 방화벽, 네트워크 제한, 코어 미실행 여부부터 점검하세요. 문제를 확인하는 동안 여러 매개변수를 계속 바꾸면 어떤 변경이 결과에 영향을 줬는지 알기 어렵습니다.

‘연결됨’은 로컬 서비스가 시작되었다는 뜻일 수 있으며 모든 원격 요청이 성공했다는 의미는 아닙니다. 브라우저에서 요청을 보낼 때 클라이언트 로그에 해당 기록이 있는지 먼저 확인하세요. 기록이 없으면 시스템 프록시, 브라우저 자체 프록시, 로컬 포트를 점검합니다. 기록은 있지만 요청이 실패한다면 DNS, 핸드셰이크, 라우팅 출구 오류를 확인하세요. 모든 웹사이트가 안 되는지 일부 도메인만 안 되는지도 구분해야 합니다. 시스템 프록시와 TUN을 함께 사용하고 있다면 한 가지 네트워크 제어 방식만 남겨 최소 설정으로 다시 테스트하세요. DNS, 노드, 라우팅을 한꺼번에 바꾸지 말고 요청이 클라이언트로 들어오는지부터 단계적으로 확인하는 편이 효과적입니다.

설치 파일의 아키텍처와 운영체제 요구 사항을 확인하고 전체 오류 메시지를 보관하세요. Windows에서는 필요한 .NET 데스크톱 런타임이 없는 경우와 앱 설정 오류를 구분해야 합니다. 런타임을 별도로 설치해야 하는지는 배포 파일에 따라 다릅니다. Linux에서는 배포 파일 형식과 누락된 종속성을 확인하세요. Mac에서는 개발자를 확인할 수 없다는 경고, 파일 접근 권한 문제, 앱 자체의 충돌을 구분해야 합니다. 출처를 신뢰할 수 있는지 확인한 뒤 시스템 설정의 개인정보 보호 및 보안 안내에 따라 처리하세요. 앱이 열리지 않는 모든 문제를 같은 권한 오류로 취급하거나 시스템 보호 기능을 일괄 해제하지 마세요. 업데이트 후에만 문제가 발생했다면 설정을 먼저 백업하고 시작 로그를 확인하세요.

종료 후 인터넷이 끊기면 시스템이 이미 중지된 로컬 프록시 포트를 계속 가리키는지 확인하세요. 클라이언트를 다시 열고 ‘시스템 프록시 해제’를 선택한 뒤 종료할 수 있습니다. 다른 네트워크 도구가 설정을 다시 변경하는지도 확인하세요. TUN을 사용했다면 가상 인터페이스와 라우팅이 복구되었는지 점검해야 합니다. 특정 앱만 프록시를 사용하지 않는다면 해당 앱의 네트워크 설정을 확인하세요. 명령줄 도구는 프록시 환경 변수를 읽을 수도 있습니다. 로컬 앱의 문제를 해결하려고 로컬 수신을 모든 네트워크 인터페이스에 공개하지 마세요. 추가 지원을 요청할 때는 운영체제, 클라이언트, 네트워크 제어 방식, 오류 요약을 알려주세요. 로그에 포함된 구독 인증 정보와 신원 정보는 먼저 가리세요.