v2rayN·v2rayNG
자주 묻는 질문

데스크톱에서는 v2rayN을 선택하고, Windows·macOS·Linux 중 사용 중인 운영체제에 맞는 설치 파일을 고르세요. Android에서는 보통 Xray 코어를 사용하는 v2rayNG를 먼저 선택하고, V2Fly 코어가 필요하다면 v2flyNG를 고려할 수 있습니다. 이름이 비슷해도 같은 앱의 스킨만 다른 것은 아닙니다. 필요한 프로토콜과 전송 방식, 보안 설정을 확인하고 두 코어 계열이 모든 기능을 똑같이 지원한다고 가정하지 마세요. 이전하기 전 기존 설정을 보관하고, 새 클라이언트에 설정을 가져와 연결을 확인한 뒤 기존 클라이언트를 삭제할지 결정하세요.

클라이언트는 설정을 읽고 프록시 코어를 실행해 기기의 트래픽을 처리하지만, 그 자체가 연결 가능한 서버는 아닙니다. 구독 주소로 여러 서버 설정을 가져올 수 있으며, 단일 공유 링크에는 보통 설정 하나가 들어 있습니다. 두 경우 모두 이용 권한이 있는 서비스에서 제공받아야 합니다. 가져온 뒤 서버 목록에 항목이 표시되는지 확인하고, 사용할 서버를 선택해 연결을 시작하세요. 구독 주소에는 접속 정보가 포함될 수 있으므로 공개 댓글이나 스크린샷, 온라인 분석 도구에 올리지 마세요. 문제를 문의할 때는 오류 유형과 필요한 설정만 남기고 주소, 사용자 ID, 구독 정보를 가리세요.

VLESS는 프록시 프로토콜이고, REALITY는 전송 계층 보안과 관련된 방식이며, Xray는 설정을 실행하는 코어입니다. 서로 대체할 수 있는 클라이언트 이름이 아닙니다. 실제 연결에는 전송 방식과 포트, 흐름 제어, 서버가 제공한 보안 설정도 필요합니다. 설정에 REALITY가 표시되어 있다면 선택한 클라이언트와 코어가 해당 기능을 지원하는지 확인한 다음 공개 키, 서버 이름, 짧은 ID 등을 점검하세요. 보안 옵션만 REALITY로 바꾸어 연결을 시도하거나 일반 TLS 설정을 그대로 적용하지 마세요. 각 항목은 서버에서 제공한 설정을 기준으로 입력해야 합니다.

최근 출시된 Android 휴대전화 대부분은 해당 프로세서 아키텍처에 맞는 arm64를 선택할 수 있으며, 설치 파일 크기도 보통 universal보다 작습니다. universal에는 여러 아키텍처에 필요한 구성 요소가 포함되어 있어 아키텍처를 모를 때 적합하지만, 기능이 더 많은 상위 버전은 아닙니다. 휴대전화를 구매한 연도만으로 아키텍처를 정확히 판단할 수 없으므로 구형 기기나 특수 기기는 시스템 정보를 확인하세요. 호환되지 않는다는 안내가 나오면 운영체제 버전, 아키텍처, 저장 공간을 먼저 확인하세요. 서명 충돌이 표시되더라도 기존 앱을 바로 삭제하지 말고 설정을 백업한 뒤, 새 설치 파일이 같은 클라이언트의 것인지와 기존 앱 위에 설치할 수 있는 배포본인지 확인하세요.

먼저 구독 주소와 단일 서버 공유 링크를 구분해 각각 구독 그룹이나 클립보드에서 가져오기 등 알맞은 메뉴를 사용하세요. 복사한 주소 앞뒤의 공백과 줄바꿈, 메신저가 덧붙인 문구를 확인하고, 구독 관리 페이지 주소가 아닌 전체 구독 주소를 복사했는지 살펴보세요. 그룹을 만들었는데 서버 목록이 비어 있다면 수동으로 한 번 업데이트하고 로그를 확인하세요. 가져오기에 실패하면 네트워크, 주소 만료 여부, 접근 권한을 먼저 점검하고, 파싱에 실패하면 응답 형식과 클라이언트 호환성을 확인하세요. 웹페이지가 열린다고 유효한 구독인 것은 아닙니다. 로그인 페이지나 오류 안내가 반환될 수도 있습니다.

기존 서버 목록은 그대로 두고, 다시 시도하려고 모든 설정을 삭제하지 마세요. 구독이 만료되었는지, 주소가 바뀌었는지, 기기의 날짜와 시간이 정확한지 확인한 다음 로그에서 연결 시간 초과, 인증서 오류, 서버의 접근 거부 중 어떤 문제인지 살펴보세요. 클라이언트에 프록시를 통해 구독을 업데이트하는 옵션이 있다면 현재 선택된 서버에 실제로 연결할 수 있는지 확인하세요. 업데이트가 이미 사용할 수 없는 서버에 의존한다면 허용되는 네트워크 환경에서 직접 업데이트를 시도할 수 있습니다. 한 번에 한 항목만 바꾸고 결과를 기록하세요. 계속 실패하면 구독 제공자에게 상태를 확인하세요. 업데이트 버튼을 반복해서 눌러도 권한이나 만료된 주소 문제는 해결되지 않습니다.

먼저 서버가 활성 항목으로 선택되어 있고 코어가 정상적으로 실행 중인지 확인한 뒤, 시스템 프록시 메뉴에서 자동으로 시스템 프록시 설정을 선택하세요. 코어 실행과 시스템 프록시 설정은 별개의 작업이므로 기본 창이 열려 있는지만 확인해서는 안 됩니다. 다음으로 시스템 프록시의 주소와 포트가 클라이언트의 로컬 수신 설정과 일치하는지, 브라우저가 시스템 프록시를 사용하는지, 다른 프록시 도구나 확장 프로그램이 설정을 덮어쓰지 않는지 살펴보세요. 일부 앱은 시스템 프록시를 사용하지 않으므로 앱 내부에 프록시를 설정하거나 적절한 트래픽 가로채기 방식을 사용해야 합니다. 클라이언트를 종료한 뒤 네트워크에 문제가 생기면 꺼진 로컬 포트를 가리키는 프록시 설정이 남아 있는지 확인하세요.

먼저 TUN을 끄고 일반 프록시 방식으로 정상 연결되는지 확인해 서버 문제를 권한 문제로 오인하지 않도록 하세요. TUN은 가상 네트워크 인터페이스와 라우팅 설정을 사용하므로 필요한 권한은 운영체제와 클라이언트 버전에 따라 다릅니다. Windows에서는 클라이언트 안내에 따라 관리자 권한을 부여하고, 다른 데스크톱 운영체제에서는 해당 버전의 권한 안내를 따르세요. 로그에 인터페이스 생성 실패가 표시되면 가상 네트워크 어댑터 구성 요소, 보안 소프트웨어의 차단 여부, 다른 터널 도구와의 충돌을 확인하세요. 문제를 해결하는 동안 방화벽을 계속 꺼 두지 마세요. 테스트할 때는 트래픽을 가로채는 도구를 하나만 실행하고, 연결된 뒤 DNS와 라우팅이 예상대로 설정되었는지 확인하세요.

시스템 프록시는 해당 설정을 따르는 앱에 요청을 로컬 프록시 포트로 보내도록 알리는 방식입니다. TUN은 가상 네트워크 인터페이스를 통해 규칙에 맞는 트래픽을 가로채므로 적용 범위가 더 넓습니다. Android 클라이언트는 보통 VpnService로 기기 내 트래픽을 전달하며, 처음 연결할 때 시스템 권한을 허용해야 합니다. 이 권한이 서버 설정까지 자동으로 제공한다는 뜻은 아닙니다. 세 방식 모두 라우팅, DNS, 앱 자체 동작의 영향을 받습니다. 일반적인 웹 이용에는 필요한 기능을 충족하는 간단한 방식부터 사용하세요. 시스템 프록시를 사용하지 않는 앱까지 처리해야 한다면 TUN이나 모바일 트래픽 가로채기 설정을 검토하되, 처음부터 모든 모드를 함께 켤 필요는 없습니다.

실제 접속 목적에 맞춰 라우팅 모드를 선택하세요. 중국 본토 우회는 보통 도메인 및 IP 규칙에 일치하는 트래픽을 직접 연결하고, 나머지는 프록시로 보냅니다. 글로벌 프록시는 클라이언트에 들어온 트래픽을 우선 프록시로 보내는 방식이지만, 모든 앱의 트래픽을 가로채는 것은 아닙니다. 문제를 진단할 때는 잠시 글로벌 프록시로 바꿔 같은 대상에 접속되는지 확인하면 분할 라우팅 규칙 문제인지 판단하는 데 도움이 됩니다. 기존 연결이 이전 경로를 계속 사용할 수 있으므로 모드를 바꾼 뒤 연결을 새로 설정하는 편이 좋습니다. 일부 도메인만 문제라면 글로벌 프록시를 상시 해결책으로 쓰기보다 규칙 순서와 규칙 데이터, DNS 결과를 확인하세요.

앱별 설정을 켠 뒤 먼저 현재 모드의 의미를 확인하세요. 우회 모드에서는 선택한 앱이 보통 프록시 경로를 사용하지 않고, 프록시 전용 모드에서는 선택한 앱만 해당 경로를 사용합니다. 정확한 동작은 현재 화면의 안내를 따르세요. 먼저 결과를 쉽게 확인할 수 있는 앱 하나로 테스트하고, 한꺼번에 너무 많은 앱을 선택해 원인을 파악하기 어려워지지 않도록 목록을 조금씩 늘리세요. 변경한 뒤 클라이언트 연결을 다시 시작하고 대상 앱도 완전히 종료했다가 다시 여세요. 시스템 구성 요소나 다운로드 서비스, 다른 앱이 대신 보내는 요청은 화면에서 선택한 앱 설정과 다르게 동작할 수 있으므로 로그와 실제 요청을 함께 확인하세요. 선택 표시만 보고 판단하지 마세요.

먼저 호스트 기기에서 프록시가 정상 작동하는지 확인한 뒤 로컬 네트워크 연결 허용을 켜고, 실제 수신 프로토콜과 포트를 확인하세요. 호스트 방화벽에서는 신뢰할 수 있는 로컬 네트워크의 해당 연결만 허용하세요. 다른 기기에는 호스트의 로컬 네트워크 IP와 프록시 포트를 입력해야 하며, 기기 자신을 가리키는 127.0.0.1을 입력하면 안 됩니다. 두 기기가 서로 통신할 수 있는 네트워크에 연결되어 있어야 합니다. 게스트 네트워크나 무선 클라이언트 격리 설정이 연결을 막을 수 있습니다. 로컬 프록시 포트를 인터넷에 직접 공개하지 마세요. 사용이 끝나면 공유를 끌 수 있습니다. 호스트가 절전 모드에 들어가거나 IP가 바뀌거나 클라이언트가 종료되면 다른 기기의 프록시 연결도 끊깁니다.

먼저 로그에서 서버 도메인을 확인할 수 있는지 살펴본 다음 대상 주소와 포트에 연결할 수 있는지 확인하세요. 도메인 확인 실패와 연결 시간 초과는 서로 다른 문제입니다. 포트, 전송 방식, 시스템 시간, 서버 상태를 점검하고 정상 작동이 확인된 다른 설정과 비교하세요. 가능하다면 휴대전화 핫스팟으로 테스트하되 여러 설정을 동시에 바꾸지는 마세요. 같은 네트워크에서 모든 설정이 시간 초과된다면 해당 네트워크와 방화벽, 기기의 트래픽 가로채기 설정을 우선 확인하세요. 특정 설정 하나만 계속 실패한다면 설정 제공자에게 서버 상태를 문의하세요. 지연 시간 테스트에 실패했다고 해서 실제 연결도 사용할 수 없다고 단정할 수는 없습니다.

연결됨 표시는 로컬 서비스가 시작되었거나 시스템 터널이 만들어졌다는 뜻일 수 있으며, 대상 웹사이트 요청이 성공했다는 의미는 아닙니다. 일반 HTTPS 페이지 하나를 열어 테스트하고 클라이언트 로그에 해당 요청이 나타나는지 확인하세요. 로그에 기록이 없다면 시스템 프록시, 브라우저 설정, 앱별 목록, TUN 적용 범위를 점검하세요. 기록은 있지만 연결에 실패한다면 활성 서버와 프로토콜 설정을 확인하고, 도메인 접속만 실패한다면 DNS도 살펴보세요. 테스트 중에는 다른 프록시 도구와 프록시 설정을 덮어쓸 수 있는 브라우저 확장 프로그램을 끄세요. 설정을 바꿀 때마다 페이지를 새로고침하거나 연결을 다시 설정해 캐시와 기존 연결의 영향을 줄이세요. 모든 설정을 한 번에 초기화하지 마세요.

그럴 수 있지만 라우팅 규칙, 대상 사이트의 제한, 서버 연결 실패가 원인일 수도 있습니다. 먼저 문제가 있는 도메인과 오류 메시지를 기록하고, 로그에서 DNS 확인 결과와 일치한 규칙, 선택된 아웃바운드를 살펴보세요. 같은 도메인이 직접 연결과 프록시 경로에서 다르게 작동한다면 클라이언트 DNS, 시스템 DNS, 브라우저의 암호화 DNS 설정이 함께 어떻게 작동하는지 확인해 예상한 경로로 DNS 조회가 이루어지는지 살펴보세요. 출처를 알 수 없는 DNS 주소를 임의로 입력하지 마세요. HTTPS 도메인 대신 IP 주소로 접속하는 것도 권장하지 않습니다. 인증서와 사이트 호스팅 방식 때문에 결과가 달라질 수 있습니다. 한 항목을 바꾼 뒤 관련 캐시를 지우거나 연결을 다시 시작하고 같은 방식으로 재시험하세요.

먼저 시스템 배터리 사용량에서 실제로 클라이언트가 배터리를 많이 소모하는지 확인하고, 지속적인 대용량 전송과 잦은 재연결을 구분하세요. 화면을 잠근 뒤에만 연결이 끊긴다면 백그라운드 실행 제한, 자동 시작 권한, 배터리 최적화 설정을 확인하세요. 장시간 연결이 필요하면 시스템 설정에 따라 백그라운드 활동을 허용할 수 있지만 대기 중 배터리 소모가 늘어날 수 있습니다. 시스템 VPN 연결을 사용하는 앱을 여러 개 동시에 실행하지 마세요. 연결이 자주 끊겼다 다시 연결된다면 무선 네트워크 전환, 서버 안정성, 로그 오류를 점검하고 연결 유지 기능만으로 회선 문제를 감추지 마세요. 설정을 바꾼 뒤 비슷한 사용 환경에서 한동안 관찰하고, 짧은 시간의 배터리 변화 한 번만으로 판단하지 마세요.