v2rayNG 자주 묻는 질문

Windows, macOS, Linux 데스크톱에서는 v2rayN을, Android에서는 보통 Xray 코어를 사용하는 v2rayNG를 먼저 고려하세요. v2flyNG는 V2Fly 코어를 사용하는 대안 클라이언트이며, 구독에서 제공하는 프로토콜과 전송 방식 조합에 따라 적합성이 달라집니다. 앱 이름만 보고 호환 여부를 판단하지 말고 노드 요구 사항과 클라이언트가 실제로 지원하는 설정 항목을 확인하세요. 사용 중인 설정이 있다면 기존 클라이언트를 유지한 채 대체 클라이언트를 시험해 보세요. 클라이언트마다 백업 설정을 서로 복원할 수 있는 것은 아닙니다.

클라이언트는 설정을 읽고 코어를 실행해 트래픽을 전달합니다. 설치만으로 연결할 수 있는 서비스가 준비되는 것은 아닙니다. 유효한 구독 주소나 노드 공유 링크 또는 서버의 전체 설정값이 필요합니다. 먼저 설정 출처와 사용 권한을 확인한 다음 노드를 가져와 사용할 구성을 선택하세요. 구독에는 개인 접속 정보가 포함될 수 있으므로 주소를 공개 게시판에 올리지 마세요. 문제를 문의할 때 프로토콜, 전송 방식, 오류 유형은 설명해도 되지만 주소의 토큰, 사용자 식별자와 인증 정보는 가려야 합니다.

프로토콜은 VMess, VLESS처럼 클라이언트와 서버가 프록시 데이터를 주고받는 방식을 말합니다. 전송 방식은 TCP, WebSocket처럼 데이터를 전달하는 방법이며, 코어는 설정을 해석하고 연결을 수립하는 프로그램입니다. REALITY는 보안 전송과 관련된 방식으로, 모든 노드 설정을 대신하는 범용 옵션이 아닙니다. 같은 프로토콜도 전송 방식과 보안 설정이 다를 수 있습니다. 설정을 가져온 뒤 프로토콜, 포트, 전송 방식, 보안 옵션, 서버 이름을 함께 확인하세요. 프로토콜 이름만 바꾼다고 연결이 되는 것은 아닙니다.

세 가지는 역할이 다릅니다. 시스템 프록시는 시스템 설정을 따르는 앱에 프록시 진입점을 제공합니다. 라우팅은 코어로 들어온 연결을 어떤 아웃바운드로 보낼지 결정합니다. TUN은 가상 네트워크 인터페이스로 트래픽을 받아 시스템 프록시보다 넓은 범위를 처리할 수 있지만, 라우팅과 권한, 앱 설정의 영향을 받습니다. 시스템 프록시를 켜도 모든 앱이 이를 사용하는 것은 아니며, TUN을 켜도 모든 연결이 프록시 아웃바운드로 나가는 것은 아닙니다. 처음 설정할 때는 한 가지 트래픽 처리 방식을 먼저 사용해 연결을 확인한 뒤 필요에 따라 라우팅과 TUN을 조정하세요.

대부분의 최신 Android 스마트폰에서는 arm64 패키지를 선택할 수 있지만, 구매 연도가 아니라 기기가 지원하는 앱 아키텍처를 기준으로 해야 합니다. universal 패키지는 여러 아키텍처를 포함해 용량이 더 큰 편이며, 아키텍처를 모를 때 시도하기 좋습니다. 다만 최소 시스템 요구 사항을 우회할 수는 없습니다. 설치 중 파싱 오류나 비호환 안내가 나오면 파일이 완전히 다운로드됐는지, 시스템 버전이 요구 사항을 충족하는지 확인한 뒤 아키텍처를 점검하세요. 기존 앱 위에 설치되지 않으면 패키지 이름과 서명 출처도 확인해야 합니다. 앱을 삭제하기 전에 설정을 백업해 구독 그룹과 사용자 지정 규칙이 사라지지 않도록 하세요.

입력한 것이 구독 주소인지 단일 노드 공유 링크인지 먼저 확인하세요. 구독 주소는 구독 그룹에 저장하고, 노드 링크는 클라이언트의 해당 가져오기 메뉴를 사용해야 합니다. 복사할 때 앞뒤 공백과 줄바꿈, 메신저가 덧붙인 문장 부호를 제거하고 웹페이지 안내 주소를 구독 주소로 착각하지 않도록 하세요. 그룹을 저장한 뒤 구독 업데이트를 실행해야 목록이 생성됩니다. 형식을 인식할 수 없다는 메시지가 나오면 제공된 형식이 현재 클라이언트와 호환되는지 확인하세요. 브라우저에서 주소가 열려도 노드 설정이 반환된다는 뜻은 아닙니다. 로그인 페이지나 오류 페이지가 표시될 수도 있습니다.

구독 업데이트와 노드 연결은 서로 다른 대상에 접속하므로, 기존 노드가 작동한다고 해서 구독 주소에도 접속할 수 있는 것은 아닙니다. 기존 노드를 유지하고 그룹을 바로 비우지 마세요. 주소가 변경됐는지, 접속 정보가 만료됐는지, 클라이언트 로그에 어떤 상태 코드나 파싱 오류가 있는지 확인하세요. 일부 클라이언트는 직접 연결하거나 프록시를 통해 업데이트하는 옵션을 제공합니다. 연결 가능한 노드가 있을 때 두 방식을 비교해 보세요. 인증 실패가 반환되면 구독 제공처에 권한을 문의하세요. 웹페이지 내용이 반환된다면 같은 주소를 반복해서 가져오기보다 로그인 페이지로 리디렉션되는지 확인하세요.

데스크톱 TUN은 가상 네트워크 인터페이스를 만들고 관련 라우팅을 변경하므로 클라이언트 안내에 따라 필요한 권한을 부여하세요. Windows에서는 관리자 권한이나 관련 서비스가 필요한지 확인하고, 다른 데스크톱 운영체제에서는 각 시스템의 권한 부여 절차를 따르세요. Android에서 로컬 VPN 연결을 처음 만들 때는 시스템 연결 요청을 승인해야 합니다. 다른 VPN 앱이 이미 연결을 사용 중이라면 충돌하는 연결을 먼저 중지한 뒤 다시 시도하세요. 기기 관리 정책으로 제한된 경우 시스템 정책을 억지로 변경하지 마세요. 권한을 허용한 뒤에도 실패하면 노드를 계속 바꾸기보다 가상 인터페이스나 서비스 시작 오류를 확인하세요.

시스템 프록시는 해당 설정을 읽어 사용하는 앱에 주로 적용됩니다. 자체 네트워크 설정을 사용하는 앱도 있고, 일부 연결 유형은 시스템 프록시를 자동으로 거치지 않습니다. 먼저 브라우저로 현재 프록시 진입점이 작동하는지 확인한 다음 대상 앱에 프록시 주소를 별도로 입력해야 하는지 살펴보세요. 주소와 포트는 클라이언트의 현재 로컬 수신 설정에서 확인하고 다른 기기의 값을 그대로 사용하지 마세요. 앱이 HTTP 프록시와 SOCKS 프록시 중 어느 쪽을 요구하는지도 확인해야 합니다. 더 많은 앱의 트래픽을 처리해야 한다면 TUN을 고려하고, 대상 트래픽이 라우팅에서 직접 연결로 지정돼 있지 않은지 확인하세요.

현재 메뉴가 시스템 프록시의 트래픽 처리 방식을 제어하는지, 코어의 라우팅 프리셋을 제어하는지 먼저 확인하세요. 두 설정은 서로 다른 기능입니다. 라우팅 프리셋의 전역 프록시는 보통 코어에 들어온 더 많은 연결을 프록시 아웃바운드로 보냅니다. 중국 본토 우회는 일반적으로 도메인 또는 주소 규칙에 따라 중국 본토 관련 대상은 직접 연결로 보내며, 실제 동작은 프리셋 설정에 따라 다릅니다. 어느 쪽도 클라이언트에 들어오지 않은 트래픽까지 자동으로 처리하지는 않습니다. 평소에는 목적에 맞는 분할 라우팅 프리셋을 선택하세요. 특정 웹사이트를 점검할 때만 전역 규칙과 비교한 뒤 원래 설정으로 되돌리고, DNS와 여러 라우팅 규칙을 동시에 바꾸지 마세요.

사용자 지정 규칙이 더 넓은 범위의 규칙보다 앞에 있는지, 규칙에서 참조하는 아웃바운드 태그가 실제로 존재하는지 먼저 확인하세요. 라우팅은 보통 순서대로 규칙을 적용하며, 앞선 규칙에 연결이 이미 일치하면 뒤의 규칙은 적용되지 않습니다. 이어서 클라이언트가 도메인과 IP 중 무엇을 확인했는지 살펴보세요. 도메인 규칙은 IP만 있는 연결에 항상 적용되는 것은 아니며, DNS를 어디서 해석하는지도 주소 기반 판단에 영향을 줍니다. 설정을 수정한 뒤 적용하고 대상 앱의 기존 연결을 끊은 다음 다시 테스트하세요. 일부 장시간 연결은 변경 전 경로를 계속 사용할 수 있으므로 이를 근거로 새 규칙이 작동하지 않는다고 판단하지 마세요.

구독 그룹, 직접 추가한 노드, 사용자 지정 라우팅, DNS 설정, 앱별 분할 설정을 우선 저장하고 현재 프록시 모드도 기록해 두세요. 클라이언트에서 설정 내보내기를 지원하면 백업 기능을 사용하세요. 백업에 인증 정보가 포함될 수 있으므로 안전하게 관리하고 공개적으로 업로드하지 마세요. 업데이트 후 기존 설정을 정상적으로 읽는지 확인한 다음 오래된 파일을 정리하세요. 다른 클라이언트로 옮길 때는 호환되는 구독이나 공유 링크를 다시 가져오고 로컬 설정을 하나씩 재구성하는 편이 좋습니다. 필드 차이로 실행에 실패할 수 있으니 설정 디렉터리 전체를 그대로 덮어쓰지 마세요.

먼저 기기의 기본 네트워크가 작동하는지 확인하고 시스템 날짜와 시간이 자동으로 동기화되는지 점검하세요. 그다음 구독을 업데이트해 노드 설정이 만료되거나 변경되지 않았는지 확인합니다. 노드 하나를 선택해 테스트하고, 같은 네트워크에서 정상 작동이 확인된 다른 설정과 비교해 모든 문제를 클라이언트 탓으로 돌리지 마세요. 이어서 프로토콜, 포트, 서버 이름, 보안 전송 설정을 확인한 뒤 로그에서 DNS 오류, 연결 시간 초과, 핸드셰이크 오류를 살펴보세요. 한 번의 지연 시간 테스트 실패만으로 노드를 사용할 수 없다고 단정하지 말고 실제 요청 결과도 확인해야 합니다. 모든 노드가 동시에 실패한다면 로컬 네트워크와 트래픽 처리 설정부터 점검하세요.

연결됨 표시는 로컬 서비스나 VPN 연결이 시작됐다는 뜻일 뿐, 원격 요청이 성공했다는 의미는 아닐 수 있습니다. 먼저 사용할 노드를 올바르게 선택했는지 확인한 다음 브라우저 트래픽이 클라이언트로 들어오는지 로그에 해당 요청 기록이 있는지 살펴보세요. 기록이 없다면 시스템 프록시, 앱별 프록시 또는 TUN의 처리 범위를 확인하세요. 기록은 있지만 이름 해석에 실패한다면 DNS를 점검하고, 핸드셰이크나 원격 연결 오류가 있다면 노드 설정과 서버 상태를 다시 확인하세요. 여러 설정이 서로 문제를 가리지 않도록 한 번에 하나만 바꾸고 같은 대상으로 반복 테스트하세요.

먼저 코어가 정상적으로 실행됐고 로컬 수신 포트를 다른 프로그램이 사용하고 있지 않은지 확인하세요. 그런 다음 운영체제의 프록시 설정이 현재 클라이언트의 주소와 포트를 가리키는지 살펴보세요. 브라우저 확장 프로그램이나 다른 프록시 클라이언트, 기기 관리 정책이 시스템 설정을 덮어쓸 수 있으므로 하나씩 확인하고 여러 프로그램이 동시에 프록시를 설정하지 않도록 하세요. 브라우저를 완전히 종료했다가 다시 열어 테스트하고 클라이언트가 요청을 받는지도 확인하세요. 클라이언트를 종료한 뒤 오히려 네트워크가 끊긴다면, 시스템에 종료된 포트를 가리키는 프록시 설정이 남아 있는지 살펴보세요. 시스템 프록시 초기화 기능을 사용하거나 운영체제 설정에서 원래 상태로 복원하세요.

DNS 오류가 나면 기본 네트워크와 DNS 서버에 접속할 수 있는지, DNS 요청이 직접 연결과 프록시 중 어느 경로를 사용하는지 확인하세요. 일부 도메인만 문제가 있다면 해당 분할 라우팅 규칙도 살펴보세요. TLS 핸드셰이크 실패는 DNS 문제라고 단정하지 말고 시스템 시간, 서버 이름, 인증서 관련 설정, 노드의 보안 전송 설정을 먼저 확인하세요. 인증서 검증을 건너뛰는 방법을 일반적인 해결책으로 사용하지 마세요. 로그를 공유해 도움을 요청하기 전에는 오류 유형과 앞뒤 관련 줄만 남기고 구독 주소, 인증 정보, 개인적으로 접속하는 도메인을 가리세요. 전체 설정도 민감 정보를 제거한 뒤 공유해야 합니다.