V2Ray 자주 묻는 질문
설정 및 연결 문제 해결

Project V는 관련 프록시 도구 생태계의 배경이며, V2Fly와 Xray는 서로 다른 코어 프로젝트입니다. 코어는 프로토콜 연결, 라우팅, 트래픽 전달을 담당하고 GUI 클라이언트는 구독, 서버 선택, 설정 화면을 제공합니다. 데스크톱에서는 v2rayN을, Android에서는 Xray 코어를 사용하는 v2rayNG 또는 V2Fly 코어를 사용하는 v2flyNG를 선택할 수 있습니다. 프로토콜 지원 여부는 실제로 실행 중인 코어와 버전에 따라 달라지므로 클라이언트 이름만으로 판단할 수 없습니다. 호환성 문제가 생기면 먼저 클라이언트와 코어 정보를 기록한 뒤 서버에서 요구하는 기능을 확인하세요.

클라이언트는 로컬 프록시 인터페이스와 코어 실행 환경을 제공하며, 서버 설정은 별도로 가져와야 합니다. 구독 주소는 보통 여러 설정을 반환하고, 공유 링크는 일반적으로 단일 설정을 담으므로 각각 해당 가져오기 메뉴에서 추가해야 합니다. 설치 후에는 사용할 권한이 있는 구독 주소나 공유 링크를 준비해 가져온 다음 서버를 선택하세요. 목록이 비어 있다고 설치에 실패한 것은 아니며 시스템 프록시를 켠다고 서버가 자동으로 추가되는 것도 아닙니다. 구독 주소에는 바로 구독을 이용할 수 있는 인증 정보가 포함될 수 있으니 공개 스크린샷이나 문의 글에 붙여 넣지 마세요.

시스템 프록시는 해당 설정을 따르는 앱에 요청을 로컬 수신 포트로 보내도록 안내하지만, 모든 프로그램의 트래픽을 가로채지는 않습니다. 라우팅 모드는 코어에 들어온 트래픽을 처리해 프록시, 직접 연결, 차단 중 어떤 출구를 사용할지 결정합니다. TUN은 가상 네트워크 인터페이스를 통해 가로채기 대상인 트래픽을 받으며 라우팅, DNS, 권한 설정이 필요합니다. 세 기능은 서로 다른 계층에서 작동합니다. 문제를 해결할 때는 앱 트래픽이 클라이언트에 들어오는지 확인하고, 적용된 라우팅 규칙을 살핀 뒤 출구 연결을 점검하세요. 시스템 프록시를 켜는 것과 모든 트래픽이 프록시를 이용하는 것은 다릅니다.

테스트 성공만으로 실제 접속이 된다고 볼 수는 없습니다. TCP 테스트는 주로 대상 주소와 포트에 연결할 수 있는지 확인하며 인증, 전송 설정, 웹 접속까지 검증하지는 않습니다. 실제 연결 테스트는 실제 요청에 더 가깝지만 테스트 주소, DNS, 현재 라우팅, 네트워크 상태의 영향을 받습니다. 사용 가능 여부를 판단하려면 서버를 선택해 실제 앱으로 접속하고 같은 시각의 클라이언트 로그도 확인하세요. 지연 시간이 가장 낮은 순서로 정렬하는 것만으로 연결이 정상이라고 단정하지 마세요. 테스트는 성공했는데 웹페이지가 열리지 않으면 앱의 프록시 진입점과 도메인 이름 확인을 먼저 점검한 뒤 서버 설정을 확인하세요.

먼저 복사한 공유 링크가 완전한지 확인하세요. vmess://, vless://, trojan://, ss:// 같은 프로토콜 접두사가 포함되어야 하며 웹 주소나 구독 주소와는 다릅니다. 앞뒤 공백, 메신저에서 덧붙인 설명, 중간에 삽입된 줄바꿈을 제거한 뒤 클립보드에서 가져오기를 실행하세요. 그래도 실패하면 가져오기 오류를 확인해 형식 분석 실패인지 프로토콜 미지원인지 구분하세요. 가져오기에 성공하려고 인코딩된 내용, 인증 필드, 전송 설정을 임의로 수정하지 마세요. 원본 링크를 다시 받아 현재 클라이언트와 코어가 해당 설정을 지원하는지 확인하세요.

v2rayN의 구독 그룹 설정에서 새 그룹을 만들고 알아보기 쉬운 이름과 전체 구독 주소를 입력한 뒤 저장하고 해당 그룹의 구독 업데이트를 실행하세요. Android 클라이언트에서도 그룹 이름만 추가하는 것이 아니라 구독을 저장한 다음 업데이트해야 합니다. 주소를 추가했다고 설정을 받은 것은 아닙니다. 업데이트가 끝나면 결과 메시지, 그룹 필터, 서버 목록을 확인하세요. 로그인 페이지, 오류 페이지, 일반 웹페이지가 반환되면 클라이언트가 유효한 설정을 만들 수 없습니다. 주소가 만료되지 않았는지, 반환된 내용이 클라이언트에서 지원하는 구독 형식인지 확인하세요.

2015년 이후 출시된 주류 Android 스마트폰은 보통 arm64를 우선 선택하면 되지만, 최종적으로는 기기에서 실제 지원하는 앱 아키텍처를 기준으로 하세요. universal 패키지는 여러 아키텍처 구성 요소를 포함해 용량이 더 큰 편이며 기기 아키텍처를 모를 때 적합합니다. 프로토콜 기능이 더 많은 패키지라는 뜻은 아닙니다. arm64 설치 시 호환되지 않는다는 메시지가 나오면 시스템 버전과 아키텍처를 확인한 뒤 universal 버전을 시도하세요. 기존 클라이언트를 업데이트할 때는 앱 출처와 서명을 동일하게 유지해야 합니다. 업데이트 오류를 피하려고 바로 삭제하지 말고 필요한 설정을 먼저 백업해 구독 그룹과 직접 추가한 서버가 사라지지 않게 하세요.

데스크톱에서는 먼저 로그를 확인해 권한 요청, 가상 인터페이스 생성, 라우팅 설정 중 어느 단계에서 실패했는지 파악한 뒤 현재 클라이언트가 요구하는 권한을 부여하세요. 권한 상승이 필요하면 운영체제에서 제공하는 인증 절차를 이용하세요. Android에서 처음 연결할 때는 보통 시스템 VPN 연결 요청을 승인해야 하며 다른 앱이 해당 연결을 점유하고 있지 않은지도 확인해야 합니다. 트래픽을 가로채는 도구를 여러 개 반복해서 켜고 끄지 마세요. 충돌하는 기능을 끄고 일반 프록시 연결이 되는지 확인한 뒤 TUN만 따로 활성화하세요. 권한을 허용해도 실패하면 서버를 계속 바꾸기보다 가상 인터페이스, 서비스 구성 요소, 라우팅 오류를 점검하세요.

주로 시스템 프록시를 따르는 브라우저를 사용한다면 시스템 프록시 자동 설정을 켠 다음 중국 본토 우회 등 필요한 라우팅 규칙을 선택하세요. 특정 대상이 분할 라우팅의 영향을 받는지 확인할 때는 프록시 출구를 더 넓게 적용하는 규칙으로 잠시 바꿔 비교한 뒤 원래 설정으로 되돌리면 됩니다. 모드 이름은 버전에 따라 달라질 수 있으므로 실제 적용된 규칙을 기준으로 판단하세요. 일반적으로 전역 모드는 코어에 들어온 뒤의 라우팅을 가리키며 모든 앱의 트래픽을 자동으로 가로챈다는 뜻은 아닙니다. 시스템 프록시를 읽지 않는 프로그램은 로컬 프록시 주소를 따로 설정하거나 호환성을 확인한 뒤 TUN을 사용하세요.

먼저 클라이언트의 설정을 열어 현재 HTTP, SOCKS 또는 혼합 수신 포트를 확인하세요. 앱에서 해당 프록시 유형을 선택하고 주소에는 보통 127.0.0.1을 입력합니다. 서버의 원격 연결 포트를 로컬 포트로 입력하지 말고, 모든 버전이 같은 기본값을 사용한다고 가정하지 마세요. 수신 포트를 변경한 뒤에는 코어가 정상적으로 다시 불러와졌는지 확인하고 앱 설정도 함께 수정하세요. 해당 기기에서만 사용할 때는 LAN 연결 옵션을 꺼 두세요. 다른 기기의 접속을 허용해야 한다면 수신 주소, 방화벽, 접근 제어를 확인해 신뢰할 수 없는 네트워크에 프록시 입구가 노출되지 않도록 하세요.

구독에 포함된 서버는 보통 원격에서 관리되므로 업데이트할 때 교체, 삭제 또는 재생성될 수 있으며 직접 수정한 내용이 유지되지 않을 수 있습니다. 장기간 보관할 사용자 지정 설정은 클라이언트가 지원하는 별도 그룹에 저장하고 수정 이유도 기록하세요. 업데이트 전에 대상 구독 범위를 확인해 다른 그룹을 잘못 변경하지 않도록 하세요. 특정 설정이 업데이트할 때마다 되돌아간다면 구독 항목을 계속 수정하지 말고 클라이언트에 로컬 덮어쓰기 기능이 있는지 확인하거나 설정 제공자에게 원래 값을 문의하세요. 백업 파일에도 구독 인증 정보가 포함될 수 있으므로 안전하게 보관하세요.

먼저 요청이 코어에 들어왔는지 확인하고 편집 창의 규칙만 볼 것이 아니라 현재 활성화된 라우팅 설정을 확인하세요. 규칙은 보통 순서대로 적용되므로 앞쪽의 포괄적인 규칙이 뒤쪽의 세부 규칙보다 먼저 일치할 수 있습니다. 하나의 대상에 요청을 보내고 로그에 표시된 대상, 일치한 규칙, 출구 정보를 함께 확인하세요. 로그에 표시되는 내용은 코어와 로그 수준에 따라 달라집니다. 규칙 리소스를 사용할 수 있는지, 도메인 정책이 의도와 일치하는지도 확인하세요. 설정은 한 번에 하나씩 바꾸고 원래 값을 기록하세요. 테스트가 끝나면 불필요한 디버그 로그를 끄고 접속 기록이 담긴 파일이 쌓이지 않도록 하세요.

먼저 구독 주소가 완전하고 만료되지 않았는지, 기기 시간이 정확한지 확인한 뒤 업데이트 로그를 살펴보세요. 시간 초과, 인증서 오류, 인증 실패, 내용 분석 실패는 서로 다른 문제입니다. 현재 프록시를 사용할 수 없다면 프록시를 통한 업데이트도 실패할 수 있습니다. 이때 클라이언트에 해당 옵션이 있으면 직접 연결 업데이트를 시도해 보세요. 직접 연결로 구독 주소에 접속할 수 없다면 사용 가능한 연결 경로가 필요합니다. 같은 주소를 제3자 변환 페이지에 반복해서 붙여 넣지 마세요. 서버가 내용을 반환했지만 분석에 실패했다면 로컬 수신 포트를 계속 바꾸지 말고 반환 형식이 올바른지 확인하세요.

먼저 로컬 네트워크에서 자주 사용하는 직접 연결 서비스에 접속할 수 있는지 확인한 뒤 기기 시간, 서버 주소, 포트, 설정 만료 여부를 확인하세요. TCP 테스트와 실제 연결 테스트는 구분해서 살펴봐야 합니다. TCP 테스트가 실패하면 주소 확인, 네트워크 경로, 원격 포트를 먼저 점검하세요. TCP 테스트는 성공했지만 실제 연결이 실패하면 인증, TLS, SNI, 전송 경로, 코어 호환성을 확인하세요. 같은 네트워크에서 설정 몇 개만 골라 하나씩 테스트하고 여러 서버를 한꺼번에 테스트해 판단을 흐리지 마세요. 문의할 때는 오류 유형과 발생 시각을 기록하고 로그를 공유하기 전에 주소, 구독 정보, 인증 정보를 가리세요.

연결됨 표시는 로컬 코어나 VPN 인터페이스가 실행되었다는 뜻일 수 있으며 원격 요청이 성공했다는 의미는 아닙니다. 먼저 앱에서 요청을 보낼 때 해당 연결이 로그에 나타나는지 확인하세요. 기록이 없다면 시스템 프록시, 앱별 프록시, TUN 가로채기 상태를 점검하세요. 기록이 있다면 DNS 실패, 연결 시간 초과, 인증 오류, 잘못된 라우팅 출구를 구분하세요. 일부 도메인만 실패한다면 클라이언트를 재설치하지 말고 해당 도메인의 이름 확인과 규칙을 점검하세요. 다른 프록시 도구를 잠시 끄고 앱 하나로 다시 테스트하세요. 설정은 한 번에 하나씩 변경해야 문제가 진입점, 이름 확인, 원격 출구 중 어디에 있는지 파악할 수 있습니다.

먼저 v2rayN이 실행 중이고 코어 시작 오류가 없는지, 시스템 프록시의 로컬 주소와 포트가 클라이언트 설정과 일치하는지 확인하세요. 브라우저가 자체 프록시나 확장 프로그램 설정을 사용할 수 있으므로 시스템 설정을 덮어쓰고 있는지 점검해야 합니다. 종료한 뒤 인터넷에 접속할 수 없다면 운영체제의 프록시 설정을 열어 꺼진 로컬 수신 포트를 계속 가리키는지 확인하세요. 더는 사용하지 않는 프록시 설정을 지운 뒤 다시 시도하세요. 다른 소프트웨어가 시스템 프록시를 설정하고 있다면 어떤 도구가 관리하는지 먼저 확인하세요. 다음부터는 종료 전에 클라이언트의 시스템 프록시 해제 기능을 사용하세요. 시스템 프록시를 따르지 않는 앱은 별도로 점검해야 합니다.