v2rayN / v2rayNG 자주 묻는 질문

데스크톱에서는 Windows, macOS, Linux를 지원하는 v2rayN을 먼저 살펴보세요. Android에서는 Xray 코어를 사용하는 v2rayNG가 우선 선택이며, V2Fly 코어가 필요할 때는 v2flyNG를 고려할 수 있습니다. 클라이언트를 골랐다면 서버 설정에 필요한 프로토콜, 전송 방식, 보안 계층을 해당 코어가 지원하는지도 확인해야 합니다. 세 제품은 같은 프로그램의 테마만 다른 버전이 아니므로 설정 위치와 구성 가져오기 기능이 다를 수 있습니다. 이전할 때는 먼저 구성을 하나 가져와 작동을 확인한 다음 구독과 라우팅 규칙을 옮기세요. 다른 클라이언트의 데이터 폴더를 바로 덮어쓰지 마세요.

Project V는 관련 프록시 도구 생태계의 기반이며 V2Fly와 Xray는 대표적인 코어 계열입니다. GUI 클라이언트는 구독 관리, 구성 편집, 실행을 담당하고 코어는 실제 연결과 라우팅, 트래픽 전달을 처리합니다. 클라이언트 창이 열려도 코어가 정상적으로 실행됐다는 뜻은 아닙니다. 문제를 확인할 때는 클라이언트 버전, 코어 종류, 실행 로그를 각각 기록하세요. 지원하지 않는 구성 항목이 보이면 클라이언트 이름만으로 호환성을 판단하지 말고 해당 항목을 지원하는 코어와 버전을 확인해야 합니다. 코어를 업데이트해도 구독 설정이 자동으로 올바르게 바뀌지는 않습니다.

VMess, VLESS, Trojan은 프록시 프로토콜이며, REALITY는 Xray 생태계의 보안 계층 방식입니다. 주소, 포트, 사용자 식별자를 대신하는 독립적인 노드 유형은 아닙니다. 연결 설정에는 전송 방식과 TLS 또는 REALITY 매개변수도 포함되며, 각 항목이 서버 설정과 일치해야 합니다. 프로토콜 드롭다운에서 VMess를 VLESS로 바꾸기만 해서는 기존 구성이 작동하지 않습니다. REALITY를 사용할 때는 서버에서 제공한 공개 키, 서버 이름, shortId 등의 매개변수를 특히 꼼꼼히 확인하세요. 항목이 누락됐다면 임의의 값으로 채우지 말고 구성 제공자에게 문의하세요.

vmess://, vless:// 또는 trojan://로 시작하는 문자열은 대개 단일 공유 링크이며, 가져오면 연결 설정 하나가 저장됩니다. 구독 주소는 보통 HTTPS 주소로, 클라이언트가 접속해 여러 설정을 가져오고 이후 다시 업데이트할 수 있습니다. 브라우저에서 구독 주소가 열린다고 해서 응답 내용이 현재 클라이언트와 호환되는 것은 아닙니다. 로그인 화면이나 오류 메시지가 반환될 수도 있습니다. 단일 링크는 클립보드에서 가져오고 구독 주소는 구독 그룹에 입력하세요. 구독 주소에 접속 자격 정보가 포함될 수 있으므로 스크린샷, 로그, 문의 내용에서는 전체 주소와 쿼리 매개변수를 가리세요.

2015년 이후 출시된 주류 Android 스마트폰은 보통 arm64를 먼저 선택하면 됩니다. 다만 최종적으로는 기기에서 지원하는 앱 ABI를 확인해야 합니다. 프로세서가 64비트를 지원해도 시스템이 64비트 앱 환경을 제공한다는 보장은 없습니다. universal에는 여러 아키텍처가 포함되어 파일 크기가 더 큰 편이며, 기기 아키텍처를 모를 때 시도하기 좋습니다. 설치 파일을 분석할 수 없다는 오류가 발생하면 Android 버전 요구 사항, 다운로드 완료 여부, 기존 앱과 설치 파일의 서명 호환성도 확인하세요. 아키텍처를 확인하려고 앱을 반복해서 삭제하지 마세요. 삭제 전에 설정을 백업하고, 백업 파일에 구독 주소와 연결 자격 정보가 들어 있을 수 있다는 점에 유의하세요.

먼저 가져올 항목이 무엇인지 구분하세요. 단일 공유 링크는 클립보드에서 가져오고, 구독 주소는 구독 그룹 설정에 입력해야 합니다. 주소를 복사할 때 앞뒤 공백과 줄바꿈, 중국어 문장 부호를 제거하고 웹페이지 제목까지 붙여넣지 않았는지 확인하세요. 그룹을 저장하는 것은 주소를 저장하는 단계일 뿐이며, 구성을 표시하려면 구독 업데이트를 따로 실행해야 하는 경우가 많습니다. 업데이트 후에도 비어 있다면 주소 만료 여부, 로그인 필요 여부, 응답 형식의 클라이언트 지원 여부를 확인하세요. 구독 주소를 노드 서버 주소로 입력하면 안 됩니다. 오류를 공유할 때는 오류 유형은 남기고 구독 자격 정보와 개인 설정 내용은 가리세요.

두 기능은 트래픽을 받아들이는 방식이 다릅니다. 시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 주로 적용됩니다. TUN은 가상 네트워크 인터페이스로 트래픽을 받아들이며, 적용 범위는 라우팅, 제외 규칙, DNS 설정에도 영향을 받습니다. 처음 설정할 때는 시스템 프록시만 먼저 확인한 뒤 실제 필요에 따라 TUN을 테스트하세요. 여러 설정을 한꺼번에 바꾸면 원인을 찾기 어렵습니다. 환경에 따라 두 기능을 함께 쓸 수 있지만, 동시에 켜야 더 완전하게 작동한다고 단정할 수는 없습니다. 전환하기 전에 기존 설정을 기록하고, 클라이언트를 종료한 뒤 시스템 프록시와 네트워크 경로가 복구됐는지 확인하세요. 특히 여러 네트워크 도구를 함께 사용하는 기기라면 주의가 필요합니다.

먼저 실행 로그를 확인해 권한 요청, 가상 인터페이스 생성, 라우팅 설정 중 어느 단계에서 실패했는지 파악하세요. 데스크톱에서는 클라이언트 안내에 따라 필요한 시스템 권한을 부여하세요. Windows에서는 관리자 권한이나 서비스 모드가 필요할 수 있고, 다른 데스크톱 운영체제에서도 네트워크 구성 요소 설치를 승인해야 할 수 있습니다. Android에서는 VPN 연결 권한을 허용했는지 확인하고 다른 VPN 앱이 연결을 사용 중인지 살펴보세요. 오류를 우회하려고 보안 기능을 모두 끄거나 시스템 네트워크 어댑터를 임의로 삭제하지 마세요. TUN을 켠 뒤 네트워크가 끊기면 먼저 TUN을 꺼서 연결을 복구한 다음 충돌하는 도구, 인터페이스 설정, 라우팅을 하나씩 확인하세요.

테스트 결과는 테스트 방식에 따라 달라집니다. TCP 테스트는 보통 대상 포트에 연결할 수 있는지만 확인합니다. 실제 요청 테스트에는 프록시 핸드셰이크, 대상 사이트, DNS도 관여합니다. 특정 테스트가 성공했다고 모든 앱이 프록시를 거치거나 모든 대상에 접속할 수 있다는 뜻은 아닙니다. 먼저 클라이언트가 어떤 방식으로 테스트하는지 확인한 뒤 동일한 구성으로 명확한 HTTPS 대상에 접속하고, 연결 로그에 해당 요청이 기록되는지 살펴보세요. 테스트 수치만으로 사용 가능 여부를 순위 매기지 마세요. 테스트 대상 자체의 문제로 시간 초과가 발생할 수도 있으므로 실제 요청과 로그를 함께 확인하고 구성을 반복해서 바꾸지 마세요.

클라이언트마다 모드 이름이 다를 수 있으므로 실제로 생성된 라우팅 규칙을 기준으로 판단하세요. 규칙 모드는 도메인, IP 또는 다른 조건에 따라 아웃바운드를 선택합니다. 전역 프록시는 유입된 트래픽을 대체로 프록시 아웃바운드로 전달하고, 직접 연결은 원격 프록시를 거치지 않습니다. 전역 프록시를 켜도 클라이언트에 연결되지 않은 앱까지 자동으로 처리되는 것은 아닙니다. 확인할 때는 같은 대상을 사용하고 먼저 앱 트래픽이 클라이언트에 들어오는지 확인한 다음 적용된 아웃바운드 태그를 살펴보세요. 전역 모드는 작동하지만 규칙 모드가 실패한다면 서버 주소나 사용자 식별자를 바로 바꾸지 말고 규칙 순서, 규칙 데이터 파일, DNS를 먼저 확인하세요.

먼저 보존할 항목이 구독에서 생성된 노드인지, 직접 추가한 노드인지, 클라이언트 수준의 라우팅 및 DNS 설정인지 구분하세요. 구독 업데이트 과정에서 해당 그룹의 항목이 다시 생성될 수 있으며, 구독 노드의 매개변수를 직접 수정하면 다음 업데이트 때 변경 사항이 사라질 수 있습니다. 장기간 유지할 설정은 별도 그룹에 복사하고 클라이언트의 내보내기 또는 백업 기능으로 저장하세요. 백업 후에는 성공 메시지만 믿지 말고 파일이 실제로 생성됐는지 확인하세요. 복원할 때는 적은 수의 설정으로 먼저 호환성을 검증하세요. 내보낸 파일에는 민감한 매개변수가 포함되는 경우가 많으므로 안전한 위치에 보관하고 공개 첨부 파일로 보내지 마세요.

먼저 시스템 DNS, 브라우저 보안 DNS, 코어 DNS를 구분하세요. 각각 다른 단계에서 사용될 수 있습니다. 앱이 직접 도메인을 조회하면 코어가 예상한 도메인 규칙으로 요청을 처리하지 못할 수 있으며, TUN 모드에서는 DNS 가로채기도 관련될 수 있습니다. 기존 값을 기록하고 한 번에 한 항목만 바꾼 뒤 같은 대상으로 테스트하고 로그를 확인하세요. 특정 공용 DNS 주소를 입력하면 모든 문제가 해결된다고 생각하지 마세요. domainStrategy 또는 queryStrategy를 변경하기 전에 현재 코어가 지원하는 값과 각 설정이 적용되는 단계를 확인하세요. 라우팅을 위한 도메인 확인 정책과 DNS 조회 주소 계열 정책은 서로 다른 설정입니다.

먼저 기기에서 일반 웹사이트에 정상적으로 접속할 수 있는지 확인한 다음 현재 설정의 서버 주소, 포트, 프로토콜, 보안 계층 매개변수를 잘못 복사하지 않았는지 살펴보세요. 설정 하나만 실패한다면 해당 설정과 서버 상태를 우선 확인하고, 모든 설정이 실패한다면 로컬 네트워크, 코어 실행 상태, 시스템 시간을 점검하세요. 로그의 연결 시간 초과, 인증 실패, 인증서 오류는 각각 의미가 다르므로 구체적인 오류 유형을 남기세요. 네트워크를 바꾸면 문제 범위를 좁히는 데 도움이 되지만 한 번에 조건 하나만 변경하세요. 핸드셰이크 오류를 감추려고 인증서 검증을 끄지 말고, 포트에 연결할 수 있다고 프록시 연결까지 성공한 것으로 판단하지 마세요.

연결됨 표시는 보통 클라이언트 서비스나 로컬 인터페이스가 시작됐다는 뜻일 뿐, 원격 연결 성공을 보장하지 않습니다. 먼저 로그를 열고 웹페이지 요청을 한 번 보내세요. 요청 기록이 없다면 앱이 시스템 프록시를 사용하는지, 로컬 포트가 올바른지, 다른 프록시 확장 프로그램이 연결을 가로채는지 확인하세요. 요청 기록이 있다면 DNS, 핸드셰이크, 아웃바운드 오류를 살펴보세요. 라우팅 충돌을 줄이려면 먼저 TUN을 끄고 한 가지 연결 방식만으로 확인하세요. 도메인으로만 접속에 실패하면 DNS 조회 경로를 중점적으로 점검하세요. HTTPS 사이트의 IP 주소에 직접 접속하는 것만으로 판단하지 마세요. 인증서와 사이트 선택에 도메인이 필요할 수 있습니다.

먼저 코어가 실행 중인지 확인하고 클라이언트가 실제로 수신 대기 중인 주소와 HTTP 또는 SOCKS 포트를 확인하세요. 안내서에 나온 포트 번호를 그대로 복사하지 마세요. 브라우저에서는 프록시 확장 프로그램, 별도 프록시 설정, 기존 연결을 확인하고 필요하면 브라우저를 다시 시작한 뒤 테스트하세요. 명령줄 프로그램은 시스템 프록시 설정을 읽지 않을 수 있습니다. 프로그램 자체의 프록시 옵션이나 HTTP_PROXY, HTTPS_PROXY 등의 환경 변수가 필요할 수 있으며, NO_PROXY에서 대상이 제외됐는지도 확인해야 합니다. 프로토콜 접두사는 수신 대기 중인 서비스와 일치해야 합니다. 터미널의 오래된 환경 변수가 예상한 설정을 덮어쓸 수도 있으므로 브라우저와 터미널을 각각 테스트하세요. 한쪽에서 작동한다고 다른 쪽에도 적용된 것은 아닙니다.

먼저 현재 작동하는 설정을 보존하고 업데이트 중 표시된 오류를 기록하세요. 연결 시간 초과가 발생하면 네트워크 경로와 클라이언트가 프록시를 통한 구독 업데이트를 지원하는지 확인하세요. HTTP 401 또는 403은 보통 인증, 유효 기간, 접근 제한을 살펴봐야 합니다. 응답은 성공했지만 목록이 비어 있다면 응답 형식과 구독에 항목이 남아 있는지 확인하세요. 일부 주소는 설정 텍스트 대신 웹페이지를 반환합니다. 브라우저에 페이지가 표시된다고 구독이 유효한 것은 아닙니다. 구독에 프록시 연결이 필요하다면 업데이트에 사용할 설정이 먼저 연결되는지 확인하세요. 아직 업데이트되지 않은 그룹에 의존하지 마세요. 문제를 파악하는 데 필요한 정보를 잃지 않도록 그룹을 연달아 삭제하고 다시 만들지 마세요.