V2Ray 자주 묻는 질문

Windows, macOS, Linux 데스크톱에서는 v2rayN을 먼저 살펴보세요. Android에서는 보통 Xray 코어를 사용하는 v2rayNG를 선택하고, V2Fly 설정 환경이 필요한 경우 v2flyNG를 고려할 수 있습니다. 클라이언트는 구독과 인터페이스, 프록시 연결 지점을 관리하고, 코어는 설정을 해석해 연결을 수립합니다. 서로 담당하는 계층이 다릅니다. 운영체제를 확인한 다음 서버 프로토콜, 전송 방식, 보안 계층의 지원 여부를 확인하세요. 클라이언트 이름만으로 호환성을 판단하면 안 됩니다. 클라이언트를 설치해도 사용할 수 있는 서비스가 자동으로 제공되지는 않으므로, 이용 권한이 있는 구독이나 연결 설정을 별도로 준비해야 합니다.

VMess와 VLESS는 프록시 프로토콜이고, REALITY는 보안 계층 메커니즘입니다. REALITY를 이들과 동등한 별도의 아웃바운드 프로토콜로 볼 수는 없습니다. 흔히 VLESS와 REALITY를 함께 구성하지만, 클라이언트는 프로토콜과 전송 방식, 보안 계층을 모두 지원해야 합니다. 설정을 가져온 뒤 서버 설정과 대조해 주소, 포트, 사용자 ID, serverName, REALITY의 publicKey와 shortId를 확인하세요. 서버에서 특정 flow를 요구한다면 이 값도 일치해야 합니다. 보안 계층 드롭다운만 REALITY로 바꾼다고 기존 설정이 자동으로 호환되지는 않습니다. 필요한 값이 없다면 설정 제공자에게 확인하세요.

구독 링크는 보통 클라이언트가 여러 설정을 가져오는 주소이며, 이후 업데이트에도 같은 주소를 사용합니다. 단일 노드 공유 링크는 하나의 연결 정보를 담고 있어 가져온 뒤 구독 변경 사항이 자동으로 반영되지 않습니다. 링크를 받으면 먼저 제공자가 구독 주소와 노드 공유 링크 중 무엇으로 안내했는지 확인한 다음 알맞은 가져오기 메뉴를 선택하세요. 구독 주소를 단일 노드 입력란에 붙여 넣으면 형식 오류가 나거나 목록이 비어 있을 수 있습니다. 구독 주소에는 접근 자격 증명이 포함될 수 있으므로 계정 정보처럼 안전하게 보관하세요. 문제를 확인할 때 전체 주소나 QR 코드, 자격 증명이 보이는 화면을 공개 게시판에 올리지 마세요.

원본 구독 형식을 대상 클라이언트가 인식하지 못할 때만 형식 변환을 고려하세요. 클라이언트에서 바로 가져올 수 있다면 원본 구독을 그대로 사용하는 편이 좋습니다. 변환은 대개 설정 항목을 재구성하는 작업일 뿐, 구독 기간을 연장하거나 서버 장애와 인증 정보 누락을 해결하지는 않습니다. 타사 변환 서비스가 전체 구독 주소와 접근 자격 증명을 처리할 수 있으므로 사용 전에 신뢰할 수 있는 서비스인지 확인하고, 우선 제공자가 안내한 호환 형식을 사용하세요. 변환 후에도 전송 방식, 보안 계층, flow, 라우팅 정보를 하나씩 확인해야 합니다. 변환된 텍스트가 생성됐다고 연결까지 되는 것은 아닙니다.

v2rayN의 구독 그룹 설정에서 이름과 구독 주소를 입력해 저장해도, 보통 그룹만 만들어질 뿐 노드가 가져와지는 것은 아닙니다. 메인 화면으로 돌아가 해당 그룹의 구독 업데이트를 실행하고, 목록에 설정이 나타났는지 확인한 다음 사용할 항목을 활성 서버로 선택하세요. 버전에 따라 메뉴 이름이 조금씩 다를 수 있으니 현재 화면을 기준으로 진행하면 됩니다. 그룹이 이미 있다면 주소가 잘리지 않았는지, 앞뒤에 공백이 들어가지 않았는지, 올바른 그룹을 업데이트하고 있는지 먼저 확인하세요. 같은 이름의 그룹을 반복해서 만들면 항목이 중복되어 업데이트 결과를 확인하기 어려워집니다.

먼저 v2rayNG의 구독 설정에 이름과 전체 구독 주소를 추가하고 저장하세요. 설정 목록으로 돌아가 구독 업데이트를 실행해 항목을 가져오면 됩니다. 단일 노드 공유 정보를 받았다면 클립보드에서 가져오기 등 알맞은 메뉴를 선택하세요. 목록에 설정이 나타나면 사용할 항목을 선택하고 연결을 시작합니다. 처음 연결할 때는 시스템 안내에 따라 VPN 연결 권한을 허용하세요. 시스템 상태 아이콘은 로컬 연결 서비스가 시작됐다는 뜻일 뿐, 원격 서버 연결까지 보장하지는 않습니다. 연결 후에도 접속할 수 없다면 같은 정보를 반복해서 가져오기보다 로그, 활성 설정, DNS를 확인하세요.

기기가 64비트 ARM 아키텍처라면 arm64를 우선 선택하세요. 아키텍처를 모르거나 지원되는 다른 아키텍처와의 호환성이 필요하다면 universal 버전을 선택할 수 있지만 설치 파일 크기는 보통 더 큽니다. 최신 주류 스마트폰은 대부분 64비트 ARM 프로세서를 사용하지만, 프로세서 사양과 실제 시스템 실행 환경이 항상 일치하는 것은 아닙니다. 기기 정보와 소프트웨어 호환성 요건을 확인하세요. 설치가 안 된다면 운영체제 버전, 저장 공간, 기존 앱 서명, 설치 파일의 다운로드 상태도 함께 점검하세요. 설치 오류만으로 프로토콜을 바꿔야 한다고 판단하지 마세요. 설치 아키텍처와 연결 설정은 별개의 문제입니다.

먼저 네트워크를 제어할 수 있는 다른 프로그램을 종료한 뒤, 사용 중인 플랫폼의 안내에 따라 가상 네트워크 어댑터 생성과 라우팅 변경 권한을 허용하세요. Windows에서는 보통 관리자 권한이 필요하고, macOS와 Linux에서는 클라이언트 안내에 따라 별도 권한을 부여해야 합니다. 구체적인 방법은 버전과 설치 방식에 따라 다릅니다. 권한을 확인한 후 코어가 정상적으로 시작되는지 점검하고 TUN을 켠 다음 로그를 살펴보세요. 일반 시스템 프록시가 이미 작동한다면 이를 기준으로 유지하면서 항목별로 테스트하는 편이 좋습니다. 권한 문제를 피하려고 시스템 보호 기능을 계속 꺼 두지 마세요. 네트워크 어댑터나 라우팅 설정이 남아 있다면 먼저 TUN을 중지한 뒤 시스템 네트워크 상태를 확인하세요.

시스템 프록시는 시스템 프록시 설정을 따르는 앱에 프록시 주소를 제공할 뿐, 모든 프로세스의 연결을 강제로 가로채지는 않습니다. 먼저 v2rayN 코어가 실행 중인지, 로컬 수신 포트가 올바른지, 시스템 프록시 자동 설정이 선택되어 있는지 확인하세요. 그런 다음 대상 프로그램이 별도의 프록시 설정이나 환경 변수, 자체 네트워크 구현을 사용하는지 살펴보세요. 브라우저 확장 프로그램이 시스템 설정을 덮어쓸 수도 있습니다. 일부 프로그램만 프록시를 사용하지 않는다면 해당 프로그램에 로컬 프록시를 직접 설정해 보세요. 더 넓은 범위의 트래픽을 처리해야 할 때 TUN을 고려하면 됩니다. 클라이언트를 종료하기 전에 시스템 프록시를 해제해야 종료된 로컬 포트를 계속 가리키는 일을 막을 수 있습니다.

시스템 프록시는 앱이 트래픽을 클라이언트로 보낼지 결정하고, 라우팅 규칙은 코어에 들어온 트래픽을 프록시로 보내거나 직접 연결하거나 차단할지 결정합니다. 두 설정을 혼동하지 마세요. 평소에는 실제 사용 목적에 맞는 라우팅 프리셋을 선택한 뒤, 대상 도메인에 예상한 규칙이 적용되는지 확인하면 됩니다. 문제를 진단할 때 잠시 모든 트래픽을 프록시로 보내면 분할 라우팅 오류인지 확인하는 데 도움이 됩니다. 다만 이 설정만으로 모든 프로그램의 트래픽이 코어로 들어오는 것은 아닙니다. 테스트가 끝나면 기존 정책을 복원하고, 단일 웹사이트 문제를 해결하려고 모든 연결 경로를 계속 바꾸지 않도록 LAN 접근과 DNS 동작도 확인하세요.

노드 프로토콜이 아니라 현재 네트워크에서 구독 주소에 직접 접속할 수 있는지에 따라 결정하면 됩니다. 직접 접속이 잘된다면 기존 연결에 의존하지 않도록 프록시 없이 업데이트할 수 있습니다. 구독 주소에 접속할 때 실제로 사용 가능한 연결이 필요한 경우에만 프록시를 통한 업데이트를 시도하세요. 현재 활성 노드가 작동하지 않는다면 해당 노드를 거친 업데이트도 실패하기 쉽습니다. 직접 업데이트로 바꾸거나 사용 가능한 다른 설정을 먼저 선택하세요. 자동 업데이트 간격을 조정하기 전에는 수동 업데이트가 성공하는지 확인하고, 구독 만료 시점과 사용 빈도에 맞춰 간격을 정하세요. 잦은 요청으로 오류 원인 확인을 대신하지 마세요.

기기를 옮길 때는 기존의 유효한 구독을 다시 추가하고, 대상 클라이언트에서 로컬 포트, 시스템 프록시, DNS, 라우팅 설정을 각각 확인하세요. 이런 로컬 설정은 구독에 포함되지 않을 수 있습니다. 설정을 내보내야 한다면 신뢰할 수 있는 로컬 경로나 관리되는 채널로만 전송하고, 이전이 끝나면 임시 파일과 클립보드 기록을 삭제하세요. 코어와 클라이언트마다 설정 항목이 모두 호환되는 것은 아니며, 특히 전송 옵션, flow, 보안 계층 매개변수에 주의해야 합니다. 설정 폴더 전체를 덮어쓴 뒤 곧바로 TUN을 켜지 마세요. 먼저 연결 하나가 정상적으로 작동하는지 확인하고, 이후 분할 라우팅과 네트워크 제어 설정을 단계적으로 복원하세요.

먼저 기기 자체가 인터넷에 정상적으로 연결되는지 확인한 다음, 구독이 만료되지 않았는지, 활성 설정이 올바른지, 주소와 포트가 잘못 변경되지 않았는지 점검하세요. 이어서 클라이언트 로그를 확인해 도메인 이름 해석 실패, 연결 시간 초과, 인증 실패, 핸드셰이크 오류를 구분해야 합니다. 각 오류의 해결 방법은 다릅니다. 같은 구독의 다른 설정과 비교해 볼 수 있지만, 한 번의 테스트만으로 특정 프로토콜 전체가 작동하지 않는다고 판단할 수는 없습니다. 모든 항목에서 동시에 문제가 생기면 로컬 네트워크, DNS, 방화벽, 시간 설정을 먼저 확인하세요. 한 항목에서만 문제가 계속되면 서비스 제공자에게 상태를 문의하면 됩니다. 구체적인 오류를 가리기 위해 클라이언트를 계속 재설치하지 마세요.

연결됨 표시는 코어나 로컬 네트워크 서비스가 시작됐다는 뜻일 수 있지만, 대상 웹사이트에 접속할 수 있다는 의미는 아닙니다. 먼저 활성 설정과 시스템 프록시가 올바른지 확인하고, 로그를 통해 도메인 이름 해석 실패인지, 원격 연결 실패인지, 트래픽이 클라이언트에 들어오지 않는 문제인지 구분하세요. TUN을 사용 중이라면 잠시 중지하고 시스템 프록시로 기본 연결을 확인해 가상 네트워크 어댑터 문제와 프로토콜 문제를 나눠 살펴보세요. 다른 프록시 프로그램이나 브라우저 확장, 보안 소프트웨어가 네트워크 설정을 동시에 변경하는지도 확인해야 합니다. 한 번에 하나씩만 바꾸고 결과를 기록하세요. DNS, 라우팅, 구독을 한꺼번에 초기화하면 실제 원인을 파악하기 어렵습니다.

먼저 구독 주소 전체가 복사됐는지 확인하세요. 특히 물음표 뒤의 매개변수와 복사 과정에서 들어간 줄바꿈이나 공백을 살펴보고, 계정 유효 기간과 제공자가 요구하는 구독 형식도 확인해야 합니다. 요청 결과가 로그인 페이지, 오류 페이지 또는 빈 내용이라면 주소가 열리더라도 클라이언트가 설정 데이터를 받은 것은 아닙니다. Base64나 프로토콜 항목 오류가 발생해도 전체 내용을 무작정 반복해서 인코딩하지 마세요. 원본 형식을 현재 클라이언트가 지원하는지 확인하고 원래 주소를 보관하세요. 업데이트 후에는 현재 구독 그룹과 필터 조건을 확인해 목록 필터링을 구독 데이터 누락으로 오해하지 않도록 합니다. 필요하면 제공자에게 대상 클라이언트에 맞는 형식을 요청하세요.

먼저 구독 주소 접속, 응답 다운로드, 내용 파싱 중 어느 단계에서 오류가 발생하는지 확인하고 구독이 만료되거나 초기화되지 않았는지도 살펴보세요. 링크가 초기화됐다면 클라이언트에 저장된 기존 주소가 더 이상 유효하지 않을 수 있으므로 새 전체 주소로 바꿔야 합니다. 직접 업데이트와 프록시를 통한 업데이트를 각각 테스트할 수 있지만, 해당 네트워크 경로가 실제로 작동해야 합니다. 프록시 업데이트를 사용한다면 활성 노드도 확인하세요. 서버가 요청 횟수를 제한하는 경우 연속 재시도를 멈추고 제공자 안내에 따라 기다리세요. 문의할 때는 클라이언트 이름과 시스템 환경, 자격 증명을 제거한 오류 요약만 전달하고 전체 구독 링크는 공개하지 마세요.