v2rayN 자주 묻는 질문

Windows, macOS, Linux 데스크톱에서는 v2rayN을 선택하고, Android에서는 보통 Xray 코어를 사용하는 v2rayNG를 먼저 고려합니다. 기존 설정이 V2Fly 동작에 명확히 의존한다면 v2flyNG를 선택할 수 있습니다. 클라이언트는 화면, 구독 관리, 프록시 전환을 담당하며, 실제 프로토콜 지원 여부는 포함된 코어와 버전에 따라 달라집니다. 선택하기 전에 플랫폼, 프로세서 아키텍처, 서버 요구 사항을 확인하세요. 앱 이름만으로 호환성을 판단하면 안 됩니다. 세 클라이언트 모두 사용 가능한 서버 설정이 필요하며, 설치만으로 연결 준비가 끝나는 것은 아닙니다.

VMess와 VLESS는 프록시 프로토콜이고, REALITY는 보안 계층과 관련된 기술이므로 세 가지를 같은 종류의 옵션처럼 서로 바꿔 쓸 수 없습니다. 실제 연결에는 전송 방식, 포트, 보안 매개변수도 필요하며 서버 설정과 일치해야 합니다. 예를 들어 VLESS 설정에서 REALITY를 사용하는 경우 공개 키, serverName, shortId 등의 해당 필드를 정확히 입력하고 flow도 서버 요구 사항에 맞춰야 합니다. 가져온 뒤 지원하지 않는 필드가 표시되면 프로토콜을 임의로 VMess로 바꾸기보다 클라이언트와 코어의 지원 여부를 확인하세요.

구독 링크는 보통 클라이언트가 설정 목록을 가져오는 주소로, 업데이트할 때마다 내용을 다시 요청합니다. 공유 링크는 대개 단일 서버 설정을 담으며 vmess://, vless://, trojan://, ss:// 등의 접두사가 흔히 사용됩니다. 기본 JSON에는 인바운드, 아웃바운드, 라우팅, DNS 등 코어의 전체 설정이 포함될 수 있으므로 일반 구독처럼 가져올 수 있다고 단정하면 안 됩니다. 콘텐츠 유형에 따라 구독 그룹, 클립보드 가져오기, 사용자 지정 설정 메뉴를 선택하세요. 구독 주소에 접근 자격 증명이 포함될 수 있으니 화면을 캡처하거나 도움을 요청할 때 전체 주소와 관련 매개변수를 가려야 합니다.

시스템 프록시는 프록시 주소를 운영체제 설정에 등록하므로, 주로 해당 설정을 참조하는 앱에 적용됩니다. 직접 연결하거나 별도로 프록시를 설정한 앱에는 적용되지 않을 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 처리하며 권한, DNS, 네트워크 라우팅 설정이 필요합니다. 모든 트래픽이 반드시 프록시를 통과한다는 뜻은 아니며, 최종 경로는 분할 라우팅 규칙의 영향을 받습니다. 처음 설정할 때는 시스템 프록시로 서버 연결을 확인한 다음 앱 요구 사항에 따라 TUN을 활성화하세요. 여러 설정을 한꺼번에 바꾸면 문제 원인을 찾기 어려워집니다.

2015년 이후 출시된 대부분의 스마트폰에서는 보통 arm64 패키지를 먼저 고려하지만, 최종적으로는 기기의 운영체제가 지원하는 ABI를 기준으로 선택해야 합니다. 프로세서가 64비트를 지원하더라도 운영체제가 해당 앱을 지원한다고 단정할 수는 없습니다. universal 패키지는 여러 아키텍처용 파일을 포함해 아키텍처를 확인하기 어려울 때 유용하지만, 일반적으로 용량이 더 큽니다. 설치 중 기기와 호환되지 않는다는 메시지가 나오면 운영체제 버전과 아키텍처를 확인한 뒤 맞는 패키지를 선택하세요. 서명 충돌이 발생했다면 아키텍처를 계속 바꿔 해결하려 하지 마세요. 기존 설정을 보존해 재설치 후 구독과 사용자 지정 규칙이 사라지지 않도록 하세요.

먼저 복사한 주소가 구독 관리 웹페이지, 안내 문구, 단일 공유 링크가 아닌 전체 구독 주소인지 확인하고 앞뒤 공백과 줄바꿈을 제거하세요. 주소를 구독 그룹에 추가한 뒤에도 구독 업데이트를 실행해야 합니다. 목록이 비어 있다면 로그에서 요청 결과와 파싱 오류를 확인하세요. 로그인 페이지가 반환된다면 주소나 인증 정보가 잘못되었을 가능성이 높고, 형식을 인식하지 못한다면 제공업체가 안내한 클라이언트 유형을 확인해야 합니다. 문제 해결을 위해 전체 구독 주소를 공개하지 마세요. 오류 유형, 응답 상태, 민감한 정보를 가린 콘텐츠 특징만 기록하세요.

먼저 현재 서버가 선택되어 있고 코어가 실행 중인지 확인한 다음, 운영체제의 프록시 설정에서 주소와 포트가 클라이언트의 실제 수신 대상을 가리키는지 확인하세요. 예시 포트를 고정값으로 여기면 안 됩니다. 업데이트하거나 사용자 지정 설정을 적용하면 수신 포트가 달라질 수 있습니다. 브라우저가 시스템 프록시를 사용하도록 설정되어 있는지, 프록시 확장 프로그램이 해당 설정을 덮어쓰고 있지는 않은지도 확인하세요. 일부 앱은 별도의 네트워크 설정에서 프록시를 지정해야 합니다. 다른 프록시 도구를 종료하고 같은 대상을 다시 테스트하세요. 특정 웹사이트만 직접 연결된다면 라우팅 규칙이 해당 사이트를 direct로 지정했는지도 확인해야 합니다.

데스크톱 운영체제에서는 가상 인터페이스 생성과 라우팅 변경에 보통 관리자 권한이 필요합니다. 클라이언트의 현재 버전 안내에 따라 권한을 부여한 뒤 관련 서비스나 가상 인터페이스 구성 요소가 정상적으로 생성되었는지 확인하세요. Android에서는 시스템 VPN 권한 요청 대화상자에서 승인해야 합니다. 같은 네트워크 트래픽 처리 기능을 사용하는 다른 도구를 동시에 켜지 마세요. 권한을 부여한 뒤에도 실패한다면 로그에서 실패한 단계를 확인하고 보안 소프트웨어의 차단 여부나 남아 있는 인터페이스를 살펴보세요. 해결책으로 시스템 보호 기능을 계속 꺼 두면 안 됩니다. TUN을 비활성화한 뒤 일반 네트워크가 복구되었는지 먼저 확인하고 계속 문제를 진단하세요.

Tcping은 대상 주소와 포트에 TCP 연결을 설정할 수 있는지 주로 확인하며, 프록시 프로토콜 핸드셰이크, 인증, 대상 웹사이트 접속까지 완전히 검증하지는 않습니다. 실제 연결 지연 시간 테스트는 프록시를 거쳐 지정된 테스트 주소에 접속하므로 실제 사용 경로에 더 가깝지만, 결과는 테스트 대상, DNS, 당시 네트워크 상태에도 영향을 받습니다. 포트에 연결되지만 실제 연결 테스트가 실패하면 프로토콜 매개변수와 로그를 추가로 확인하세요. 한 번의 테스트만으로 서버를 고르지 마세요. 같은 테스트 대상을 고정해 여러 번 확인한 뒤 브라우저로 접속해 필요한 앱의 트래픽이 실제로 프록시를 통과하는지 살펴보세요.

일상적인 사용에서는 목적에 맞춰 중국 본토 우회 등의 분할 라우팅 방식을 선택할 수 있으며, 실제 적용 결과는 규칙 내용과 순서에 따라 달라집니다. 특정 대상에 접속할 수 없는 문제를 확인할 때는 일시적으로 해당 대상의 트래픽을 프록시로 보내거나, 클라이언트의 전역 프록시 라우팅 방식으로 전환해 비교하세요. 이때 서버와 테스트 주소는 그대로 유지해야 합니다. 전환 후 문제가 해결된다면 규칙 우선순위, 규칙 데이터, 도메인 이름 확인 동작을 중점적으로 살펴보세요. 시스템 프록시 스위치는 앱의 요청을 클라이언트로 전달하는 방식을 정할 뿐, 코어의 전역 라우팅과 같지 않습니다. 테스트가 끝나면 필요한 분할 라우팅 설정으로 되돌리세요.

구독을 업데이트하면 해당 그룹에서 구독으로 생성된 서버 항목이 덮어써질 수 있으므로, 자동 업데이트되는 항목에 장기간 사용할 변경 사항을 직접 저장하지 않는 것이 좋습니다. 매개변수를 조정해야 한다면 클라이언트에서 지원하는 경우 별도의 수동 그룹에 복사하고, 비교할 수 있도록 원래 구독을 보존하세요. 업데이트 전에 구독 그룹, 라우팅 규칙, 필요한 사용자 지정 설정을 백업하고 백업 파일도 안전하게 보관하세요. 업데이트 후 현재 서버가 작동하지 않으면 활성 서버와 그룹 소속을 다시 확인하세요. 이름이 같다고 해서 이전과 같은 주소와 매개변수를 사용하는 것은 아닙니다.

먼저 코어가 정상적으로 실행 중인지 확인한 뒤, 지정한 앱이 시스템 프록시, 수동 프록시, TUN 처리 중 어떤 경로를 사용하는지 확인하세요. 같은 앱으로 프록시를 사용해야 하는 것이 명확한 대상에 접속하면서 클라이언트의 연결 기록이나 액세스 로그에서 인바운드와 아웃바운드 표시를 확인합니다. 페이지가 열리는 것만으로 프록시 사용을 입증할 수는 없습니다. 대상에 직접 연결할 수 있거나 direct 규칙이 적용되었을 수도 있습니다. 테스트 중에는 로그 수준을 일시적으로 높이고 완료 후 평소 설정으로 되돌리세요. 기록을 다른 사람에게 제공하기 전에 서버 주소, 구독 매개변수, 개인 활동과 연관될 수 있는 정보를 가리세요.

먼저 기기의 일반 네트워크가 작동하는지 확인하고 서버 주소와 포트가 빠짐없이 입력되었는지 살펴보세요. 그런 다음 도메인 이름 확인 실패, TCP 연결 시간 초과, 프로토콜 핸드셰이크 실패를 구분하세요. 이름 확인 실패는 DNS를, 연결 시간 초과는 서버 수신 상태와 네트워크 경로를, 핸드셰이크 실패는 프로토콜, 보안 계층, 인증 필드를 중점적으로 확인합니다. 시스템 시간이 크게 어긋나면 인증이나 인증서 검증에 영향을 줄 수 있습니다. 비교 테스트는 서버 하나를 고정하고 한 번에 하나씩만 변경하세요. 같은 설정이 다른 네트워크에서는 작동한다면 클라이언트를 반복해서 재설치하기보다 로컬 네트워크 환경을 먼저 비교하는 것이 좋습니다.

클라이언트가 실행되거나 로컬 수신에 성공했다는 것은 트래픽을 받는 경로가 시작되었다는 뜻일 뿐, 원격 요청이 모두 성공한다는 의미는 아닙니다. 먼저 실제 연결 테스트와 액세스 로그를 확인해 요청이 클라이언트에 들어왔는지 살펴보세요. 기록이 없다면 앱의 프록시 설정을 확인하고, 기록은 있지만 아웃바운드 연결이 실패했다면 서버와 프로토콜 매개변수를 확인해야 합니다. 로그에 도메인 이름 확인 오류가 집중되어 있다면 DNS와 라우팅을 확인하고, 아직 연결되지 않은 프록시에 DNS 요청이 의존하지 않도록 하세요. 일부 대상만 실패한다면 적용된 규칙과 대상 연결 상태를 비교하세요. 인증서 검증을 끄는 것을 일반적인 해결책으로 삼지 마세요.

먼저 오류가 요청 시간 초과, 인증 거부, 콘텐츠 파싱 실패 중 무엇인지 확인하세요. 인증이 거부되면 구독 유효기간이나 주소가 재설정되었는지 확인해야 합니다. 파싱에 실패하면 반환된 콘텐츠가 웹페이지로 바뀌었거나 호환되지 않는 형식인지 살펴보세요. 클라이언트에서 직접 연결과 프록시 연결을 각각 사용해 업데이트할 수 있다면, 사용 가능한 연결이 있을 때 비교 테스트하여 업데이트 요청이 이미 작동하지 않는 서버에 의존하지 않도록 하세요. 시스템 시간, DNS, 로컬 보안 소프트웨어 기록도 확인해야 합니다. 기존 항목이 여전히 작동한다면 비교용 설정을 잃지 않도록 먼저 보존하고 모든 그룹을 바로 비우지 마세요.

포트 사용 중 메시지는 보통 다른 프로세스나 중복 실행된 코어가 같은 주소에서 수신 중이라는 뜻입니다. 중복 실행된 클라이언트를 종료하고 운영체제에서 포트를 사용 중인 대상을 확인한 뒤 해당 프로세스를 종료하거나 설정에서 로컬 수신 포트를 변경하세요. 앱에 수동 프록시를 설정했다면 그 포트도 함께 변경해야 합니다. 비정상 종료 후 인터넷에 연결되지 않으면 먼저 시스템 프록시가 종료된 로컬 수신 주소를 계속 가리키는지 확인한 뒤 TUN 인터페이스와 라우팅이 복구되었는지 살펴보세요. 가능하면 클라이언트의 정상적인 비활성화 및 종료 절차를 사용하세요. 그래도 복구되지 않으면 오류 기록을 저장하고 운영체제의 네트워크 설정을 하나씩 확인하세요.