V2Ray 자주 묻는 질문

V2Ray는 일반적으로 Project V와 관련된 프록시 기술 및 도구 생태계를 가리킵니다. V2Fly와 Xray는 그중 널리 쓰이는 코어 계열입니다. 코어는 프로토콜 연결, 라우팅 규칙 적용, 데이터 전달을 담당하고, GUI 클라이언트는 구독 관리와 설정 화면, 프로세스 실행을 맡습니다. 문제를 확인할 때는 클라이언트 이름과 실제 실행 중인 코어를 각각 기록해야 합니다. 단순히 V2Ray를 사용한다고만 적어서는 원인을 파악하기 어렵습니다. 특정 프로토콜이나 전송 방식의 작동 여부는 코어 버전, 클라이언트의 설정 생성 방식, 서버 매개변수가 서로 일치하는지에 따라 달라집니다.

Windows, macOS, Linux 데스크톱에서는 v2rayN을 우선 살펴보세요. Android 기기에서는 보통 Xray 코어를 사용하는 v2rayNG를 선택하고, V2Fly 코어가 필요하다면 v2flyNG를 검토하면 됩니다. 이름이 비슷한지보다 기기 운영체제, 구독에 필요한 프로토콜, 라우팅 요구 사항을 기준으로 선택하세요. 가져오기 전에 설정이 클라이언트와 호환되는지 확인하고, 기존에 작동하는 설정은 먼저 백업해 두세요. 클라이언트를 바꾸면 시스템 프록시나 연결 권한을 다시 확인해야 하며, 기존 클라이언트의 연결 상태는 자동으로 이전되지 않습니다.

시스템 프록시는 앱이 클라이언트에 연결되는 방식 중 하나로, 주로 시스템 프록시 설정을 따르는 프로그램에 영향을 줍니다. 전역 모드와 중국 본토 우회 모드는 라우팅 정책이며, 코어로 들어온 연결을 어떤 출구로 보낼지 결정합니다. 전역 모드를 선택해도 기기의 모든 앱이 자동으로 프록시를 사용하는 것은 아닙니다. 중국 본토 우회 모드도 모든 대상이 직접 연결된다는 뜻은 아니며, 실제 동작은 규칙과 우선순위, 데이터베이스에 따라 달라집니다. 테스트할 때는 먼저 앱 트래픽이 클라이언트에 들어오는지 확인한 다음 라우팅 결과를 살펴보세요. 연결 단계의 문제를 분할 라우팅 문제로 오인하지 않도록 주의해야 합니다.

클라이언트는 설정과 연결 기능을 제공하지만, 설치만으로 사용할 수 있는 원격 서버가 만들어지지는 않습니다. 원격 프록시로 연결하려면 정식으로 제공받은 구독 주소, 단일 공유 링크 또는 서버 매개변수가 필요합니다. 구독은 설정 모음을 업데이트하는 방식이지 프로토콜이나 클라이언트 계정이 아닙니다. 설정을 받으면 주소의 출처와 유효 기간, 지원 클라이언트를 확인한 뒤 가져오세요. 이 사이트는 클라이언트 다운로드 경로와 기술 정보를 제공하며 노드를 배정하지 않습니다. 구독 권한이나 사용량은 해당 서비스 제공업체에 문의하세요.

먼저 구독 주소와 단일 공유 링크를 구분하세요. 구독 주소는 구독 그룹에 추가하고, 공유 링크는 클립보드에서 링크를 가져오는 메뉴를 이용해야 합니다. 주소를 복사할 때 앞뒤 공백과 줄바꿈, 메신저가 덧붙인 문장 부호를 제거하고 안내 페이지 주소를 잘못 복사하지 않았는지 확인하세요. 가져오기 오류 메시지도 살펴보세요. 웹페이지가 반환되거나 형식이 지원되지 않는다면 제공업체의 구독 형식이 클라이언트와 호환되는지 확인해야 합니다. 구독 주소에는 접속 정보가 포함될 수 있으므로 공개 게시판에 올리지 마세요. 가져온 뒤에는 그룹을 업데이트하고 항목이 표시되는지 확인하세요.

최신 Android 휴대전화 대부분은 arm64를 사용하지만, 최종적으로는 기기 운영체제가 지원하는 앱 아키텍처를 기준으로 선택해야 합니다. 프로세서 모델이나 구입 연도만으로 판단하지 마세요. 64비트 앱을 지원하는 것이 확인되면 arm64를 우선 선택하고, 아키텍처가 불분명하면 설치 파일이 더 큰 편인 universal을 선택할 수 있습니다. 압축 해제 오류나 설치 실패가 발생하면 Android 버전, 앱 설치 출처 권한, 서명이 다른 동일 앱이 이미 설치되어 있는지도 확인하세요. 기존 앱을 삭제해야 한다면 먼저 설정을 내보내고 백업이 정상적으로 열리는지 확인해 사용자 지정 규칙이 사라지지 않도록 하세요.

먼저 시스템 정보에서 운영체제와 프로세서 아키텍처를 확인한 다음 해당 플랫폼의 다운로드 항목을 선택하세요. Windows 다운로드에는 데스크톱 버전과 클래식 WPF 버전이 있습니다. macOS는 Apple Silicon과 Intel용을 구분하고, Linux는 배포판의 패키지 형식과 x64·arm64 아키텍처를 함께 고려해야 합니다. deb와 rpm은 패키지 관리 방식의 차이이지 프록시 프로토콜의 차이가 아닙니다. 설치 오류가 나면 패키지 이름과 시스템 메시지를 기록하고 지원 환경과 의존성을 먼저 확인하세요. 설치 문제를 해결하려고 코어를 임의로 바꾸거나 프로그램 디렉터리를 덮어쓰지 마세요.

TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 변경하므로 데스크톱에서는 보통 관리자 권한이나 권한 상승 서비스, 관련 네트워크 권한이 필요합니다. 먼저 TUN을 끄고 일반 프록시 연결이 되는지 확인한 뒤, 현재 클라이언트의 안내에 따라 권한을 허용하세요. Linux에서는 TUN 장치가 제공되는지와 필요한 권한이 있는지도 확인해야 합니다. Android는 시스템 VPN 권한을 사용하므로 연결 확인 창에서 허용하면 됩니다. 다른 VPN이나 네트워크 제어 프로그램이 실행 중이라면 종료한 뒤 다시 시도하세요. 권한을 허용해도 실패하면 인터페이스 생성 로그를 확인하세요. 방화벽 전체를 끄거나 모든 권한을 계속 완화하지 마세요.

먼저 설정 하나를 선택해 연결한 다음, 시스템 프록시를 따르는 브라우저에서 접속 가능한 웹사이트를 열어 보세요. 동시에 클라이언트의 연결 기록이나 로그를 확인해 테스트 요청이 코어로 들어가 예상한 출구를 사용했는지 확인합니다. 연결 아이콘은 대개 프로세스나 로컬 서비스가 시작됐다는 뜻일 뿐, 원격 서버와 핸드셰이크가 성공했다는 의미는 아닙니다. 테스트 중에는 라우팅을 일시적으로 단순화하고, 끝난 뒤 평소 정책으로 되돌리세요. 브라우저에서는 되지만 다른 프로그램에서 안 된다면 해당 프로그램의 프록시 설정과 연결 방식을 확인하세요. 곧바로 서버 매개변수를 전부 바꾸지는 마세요.

라우팅 규칙은 보통 설정된 순서대로 적용됩니다. 범위가 넓은 규칙이 앞에 있으면 뒤에 있는 세부 규칙이 적용되지 않을 수 있습니다. 요청이 현재 설정으로 들어오는지 확인하고, domain·ip·outboundTag 조건과 태그가 서로 맞는지 점검한 뒤 규칙 적용 기록을 살펴보세요. 도메인 규칙을 적용하려면 코어가 도메인 정보를 받아야 합니다. 대상 IP만 있는 경우 geosite 항목에 일치하지 않을 수 있습니다. geoip와 geosite 데이터도 설정과 호환되어야 합니다. 한 번에 한 항목만 수정하고 설정을 다시 불러오거나 재시작하세요. 변경 전 규칙을 보관하면 결과를 비교하고 되돌리기 쉽습니다.

백그라운드 연결이 끊기면 먼저 시스템이 v2rayNG의 백그라운드 동작을 제한하는지 확인하세요. 배터리 설정에서 필요에 따라 백그라운드 실행을 허용하고, 시스템 VPN 권한이 유효한지도 점검합니다. 일부 기기에서는 자동 시작을 별도로 허용해야 하며, 메뉴 이름은 시스템 버전에 따라 다를 수 있습니다. 앱별 프록시 설정에서는 목록이 선택한 앱만 프록시를 사용하는 방식인지, 선택한 앱을 우회하는 방식인지 먼저 확인하세요. 저장한 뒤 연결을 다시 설정해 테스트합니다. 시스템 VPN 아이콘이 표시되어도 모든 앱이 프록시를 사용하는 것은 아닙니다. 목록의 적용 방향을 반대로 선택하면 브라우저와 다른 앱의 동작이 달라질 수 있습니다.

최소한 구독 그룹, 사용자 지정 서버, 라우팅 규칙, DNS 설정, 로컬 수신 포트를 저장하세요. 내보내기 기능을 사용한 뒤 백업 파일이 실제로 생성됐고 다시 찾을 수 있는 위치에 저장됐는지 확인합니다. 코어마다 지원하는 프로토콜 필드와 라우팅 문법이 다를 수 있으므로 전환 후에는 정상 작동이 확인된 설정 하나로 테스트하고 복잡한 규칙은 나중에 복원하세요. 구독을 다시 업데이트해도 직접 추가한 항목이 복구되지 않을 수 있습니다. 백업에는 구독 정보와 서버 인증 정보가 포함될 수 있으므로 접근을 제한하고, 일반 스크린샷이나 로그 파일에 첨부해 공개하지 마세요.

먼저 업데이트 로그를 확인해 도메인 조회 오류, 연결 시간 초과, 인증서 오류, 권한 오류, 콘텐츠 분석 오류를 구분하세요. 구독이 만료되지 않았는지, 기기 날짜가 정확한지, 제공업체가 주소를 변경하지 않았는지 확인합니다. 업데이트에 프록시가 필요한데 현재 선택한 노드가 작동하지 않으면 업데이트도 연결도 되지 않는 상황이 반복될 수 있습니다. 클라이언트가 제공하는 업데이트 방식에 따라 직접 연결을 시도하거나 정상 작동이 확인된 다른 설정으로 바꿔 보세요. 권한 오류가 반환되면 구독 상태를 확인하고 요청을 반복해서 보내지 마세요. 인증서 검증을 끄는 방식으로 문제를 덮으려 하지 마세요.

먼저 시간 초과가 서버 주소 연결, 프로토콜 핸드셰이크, 실제 요청 중 어느 단계에서 발생하는지 확인하세요. 서버 주소와 포트, 전송 방식, TLS 또는 REALITY 관련 필드가 제공업체 설정과 일치하는지 점검하고 기기 시간도 확인합니다. 같은 설정으로 다른 네트워크에서 테스트하거나, 같은 네트워크에서 정상 작동이 확인된 다른 설정과 비교하세요. 한 번에 조건 하나만 바꾸는 것이 좋습니다. ICMP 테스트에 실패해도 프록시를 사용할 수 없다는 뜻은 아니며, TCP 연결에 성공해도 프로토콜 인증까지 성공했다는 의미는 아닙니다. 로그에 인증 또는 핸드셰이크 오류가 표시되면 로컬 라우팅을 반복해서 바꾸기보다 매개변수를 먼저 확인하세요.

먼저 TUN과 복잡한 분할 라우팅을 잠시 끄고, 정상 작동이 확인된 설정 하나를 일반 시스템 프록시로 테스트하세요. 코어가 정상 실행 중인지, 로컬 수신 주소와 포트가 시스템 프록시 설정과 일치하는지 확인하고 브라우저 확장 프로그램이나 다른 프록시 도구가 설정을 덮어쓰는지도 살펴보세요. 로그에 테스트 요청이 없다면 앱이 시스템 프록시를 따르는지 먼저 확인합니다. 요청은 있지만 도메인 조회에 실패하면 DNS를, 핸드셰이크에 실패하면 원격 설정을 점검하세요. 명령줄 도구와 일부 데스크톱 앱은 프록시를 별도로 설정해야 합니다. 클라이언트를 종료한 뒤에도 인터넷이 안 되면 중지된 포트를 가리키는 시스템 프록시 설정이 남아 있는지 확인하세요.

먼저 클라이언트에서 TUN을 정상적으로 끄고 다른 VPN도 종료하세요. DNS 자동 설정이나 이전에 작동하던 네트워크 설정으로 되돌린 다음 기본 네트워크를 테스트합니다. 기본 네트워크는 정상인데 클라이언트를 켠 뒤에만 실패한다면 DNS 요청의 출구, DNS 서버 연결 가능 여부, 아직 연결되지 않은 프록시에 의존하는지 확인해 DNS 조회가 반복되는 상황을 방지하세요. 재시작이 필요하면 먼저 로그와 설정을 저장하고, 재시작 후에는 네트워크를 제어하는 도구 하나만 실행하세요. 연결을 복구한 뒤 라우팅, DNS, TUN을 하나씩 켜 문제를 일으키는 항목을 찾습니다. 모든 설정을 한꺼번에 초기화하면 원인을 파악하기 어렵습니다.