V2Ray 자주 묻는 질문,설정과 문제 해결

V2Ray는 Project V 프록시 생태계의 핵심 프로젝트입니다. V2Fly는 관련 코어 개발을 이어 가고 있으며, Xray는 별도의 코어 분기입니다. 코어는 연결, 프로토콜 처리, DNS, 라우팅을 담당하고 v2rayN은 설정을 관리하는 그래픽 클라이언트입니다. 데스크톱에서는 v2rayN을, Android에서는 Xray 코어를 사용하는 v2rayNG 또는 V2Fly 코어를 사용하는 v2flyNG를 이용할 수 있습니다. 화면에서 노드를 추가했다는 것은 설정이 저장되었다는 뜻일 뿐, 서버 연결이 가능하다는 의미는 아닙니다. 문제를 확인할 때는 클라이언트에서 코어가 실행 중인지 먼저 살펴본 뒤 연결 로그를 확인하세요. 코어를 바꾸기 전에는 노드의 프로토콜과 전송 설정을 지원하는지 확인해야 합니다. 코어 이름만으로 연결 품질을 판단할 수는 없습니다.

클라이언트는 로컬 설정과 트래픽 전달을 담당하는 도구이며, 설치 파일에 사용할 수 있는 원격 서비스가 포함되어 있지는 않습니다. 노드에는 서버 주소, 포트, 프로토콜, 인증 정보, 전송 매개변수가 담깁니다. 구독은 클라이언트가 여러 노드 정보를 정기적으로 가져올 수 있도록 제공되는 링크입니다. 사용할 권한이 있는 서비스나 직접 구축한 서버에서 설정을 받은 뒤 클라이언트에 가져오세요. 구독 정보를 불러올 수 있는지와 노드에 연결할 수 있는지는 별개의 문제이므로 서비스 이용 기간, 서버 상태, 현재 네트워크도 확인해야 합니다. 로컬 SOCKS 주소인 127.0.0.1을 원격 노드로 착각하지 마세요. 구독 링크에는 계정 접근 정보가 포함될 수 있으므로 공개 스크린샷이나 게시판에 올리지 말고 민감 정보로 취급하세요.

사용할 프로토콜은 클라이언트에서 임의로 고르는 것이 아니라 서버 설정에 따라 결정됩니다. 공유 링크를 가져올 때는 제공된 프로토콜, 포트, 전송 방식, 보안 계층 설정을 그대로 유지하세요. VLESS 노드는 특정 flow, REALITY 공개 키 또는 서버 이름이 필요할 수 있습니다. Trojan은 TLS와 함께 쓰이는 경우가 많으며, VMess와 Shadowsocks도 각각 인증 및 암호화 설정이 있습니다. 프로토콜 드롭다운만 바꾸면 대개 연결이 실패하며, 프로토콜 이름만으로 속도가 더 빨라지는 것도 아닙니다. 처음 설정할 때는 전체 링크나 QR 코드를 사용하고, 연결이 확인된 뒤 각 항목을 살펴보세요. 프로토콜을 변경해야 한다면 서버와 클라이언트 설정을 함께 바꾸고, 현재 코어가 해당 조합을 지원하는지 확인해야 합니다.

세 설정은 서로 다른 단계에 해당합니다. 시스템 프록시는 앱에 로컬 프록시 주소를 제공하며, 시스템 프록시를 따르는 프로그램만 이를 사용합니다. TUN은 가상 네트워크 인터페이스로 트래픽을 전달하므로 시스템 프록시를 읽지 않는 앱도 더 폭넓게 처리할 수 있습니다. 전역 모드는 코어에 들어온 트래픽의 라우팅 정책을 뜻하며, 일반적으로 조건에 맞는 트래픽을 프록시 출구로 보내지만 모든 프로그램을 자동으로 클라이언트에 연결하지는 않습니다. 분할 라우팅은 도메인이나 IP 등의 규칙에 따라 직접 연결, 프록시, 차단을 선택합니다. 특정 앱이 프록시를 사용하는지 확인하려면 트래픽이 클라이언트에 들어오는지 먼저 살펴본 다음 어떤 규칙이 적용됐는지 확인하세요. 처음 문제를 점검할 때는 연결 방식 하나만 선택해 테스트해야 합니다. 시스템 프록시, TUN, 라우팅을 한꺼번에 바꾸면 무엇이 영향을 줬는지 알기 어렵습니다.

arm64 설치 파일은 64비트 ARM 아키텍처를 사용하고 해당 앱을 지원하는 시스템이 설치된 기기용이며, 보통 파일 크기가 더 작습니다. universal 설치 파일에는 지원되는 여러 아키텍처가 포함되어 있어 기기의 아키텍처를 잘 모를 때 적합합니다. 최근 출시된 주류 스마트폰은 대체로 arm64를 선택할 수 있지만, 구매 연도나 프로세서 사양만으로 단정할 수는 없습니다. 일부 기기는 여전히 32비트 시스템을 사용합니다. 앱을 설치할 수 없다는 메시지가 나오면 먼저 시스템 버전, 저장 공간, 기존 앱의 서명, 설치 권한을 확인한 뒤 아키텍처 문제를 살펴보세요. 업그레이드 전에는 구독 그룹과 사용자 지정 규칙을 보관해 설치 충돌을 해결하려다 설정이 사라지지 않도록 하세요. v2rayNG와 v2flyNG는 각각 별도의 설치 파일을 선택해야 하며, 같은 앱의 버전으로 보고 덮어쓰면 안 됩니다.

먼저 구독 주소와 단일 노드 공유 링크를 구분하세요. 구독 주소는 구독 그룹의 주소 입력란에 넣고, 단일 노드 링크는 클립보드나 공유 링크 가져오기 메뉴를 이용해야 합니다. v2rayN에서는 그룹을 저장한 뒤 구독 업데이트도 실행해야 합니다. v2rayNG 역시 구독을 추가한 다음 업데이트해야 하며, 이름만 저장해서는 노드 정보가 불러와지지 않습니다. 복사한 내용이 온전한지 확인하고 앞뒤 공백과 줄바꿈을 제거하세요. 웹 로그인 주소나 안내 문구가 함께 붙지 않았는지도 확인해야 합니다. 로그에 파싱 오류가 표시되면 응답이 로그인 페이지나 오류 페이지일 수 있고, 클라이언트가 지원하지 않는 설정 형식일 수도 있습니다. 제공자에게 확인하세요. 이름을 바꾸거나 계속 재설치해 형식 문제를 해결하려 하지 마세요. 먼저 호환성이 확인된 노드 링크로 가져오기 기능을 테스트하세요.

구독 업데이트는 구독 서비스 주소에 접속하며, 노드 연결에 사용하는 서버와 주소가 다를 수 있습니다. 따라서 두 작업의 결과가 다를 수 있습니다. 먼저 링크 만료 여부와 계정 상태를 확인하고 로그에서 HTTP 상태 코드나 시간 초과 메시지를 살펴보세요. 구독 주소에 프록시를 통해서만 접속할 수 있다면, 정상 작동하는 노드를 먼저 켠 뒤 클라이언트의 프록시 경유 업데이트 기능을 선택하세요. 직접 연결해야 하는 주소라면 직접 연결로 업데이트해야 합니다. 메뉴 이름과 위치는 클라이언트 버전에 따라 다를 수 있습니다. 시스템 시간이 잘못되었거나 DNS 조회에 문제가 있는지, 네트워크 로그인 페이지가 방해하는지도 확인하세요. 업데이트가 실패해도 기존 구독 그룹은 유지하고 노드를 모두 지우지 마세요. 응답이 계속 비어 있거나 형식이 바뀌었다면 제공자에게 구독 형식을 문의하세요.

TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 변경하므로 일반 로컬 프록시보다 높은 권한이 필요합니다. Windows에서는 클라이언트 안내에 따라 관리자 권한으로 실행하거나 필요한 서비스를 설정해야 하는 경우가 많습니다. Linux에서는 현재 버전의 권한 방식, 가상 네트워크 장치 접근 권한, 서비스 상태를 확인하세요. macOS에서는 시스템 안내에 따라 필요한 권한을 부여해야 합니다. Android에서는 시스템 VPN 권한을 확인하세요. 일반적으로 VPN 서비스는 한 번에 하나만 실행할 수 있습니다. 먼저 같은 종류의 인터페이스를 사용하는 다른 도구를 종료한 뒤 클라이언트 로그에서 구체적인 오류를 확인하세요. 모든 권한 문제를 노드 연결 불가로 단정하거나 시스템 파일 권한을 함부로 바꾸면 안 됩니다. 당장 권한을 부여할 수 없다면 시스템 프록시로 노드를 먼저 테스트하고, 일반 연결이 안정된 뒤 TUN을 설정하세요.

일상적인 웹 탐색은 분할 라우팅으로 시작할 수 있습니다. 프록시가 필요한 대상은 프록시 출구로 보내고 나머지는 규칙에 따라 직접 연결합니다. 중국 본토 우회는 대개 중국 본토 도메인과 IP를 분류해 직접 연결하도록 하는 사전 설정이지만, 실제 동작은 클라이언트의 규칙 집합에 따라 달라집니다. 전역 모드는 프록시 출구를 잠시 테스트하거나 출구를 통일해야 하는 상황에 적합합니다. 모든 앱이 자동으로 클라이언트에 연결되는 것은 아닙니다. 모드를 바꾼 뒤에는 같은 대상에 다시 연결하고, 기존 연결이 이전 경로를 유지하지 않도록 필요하면 열려 있는 페이지나 앱을 닫으세요. 전역 모드에서는 되는데 분할 라우팅에서는 안 된다면 노드를 바로 바꾸기보다 규칙 순서, 분류 데이터, DNS를 확인하세요. 테스트가 끝나면 평소 사용하는 정책으로 되돌려 불필요한 우회를 줄이세요.

명령줄 도구 중에는 데스크톱 시스템 프록시를 자동으로 읽지 않는 경우가 많습니다. 도구 자체에서 프록시 주소를 설정하거나 해당 프로세스에 환경 변수를 지정해야 합니다. 먼저 클라이언트의 실제 수신 주소, 포트, 프로토콜을 확인하세요. SOCKS 포트가 10808이라면 curl -x socks5h://127.0.0.1:10808 -I https://www.example.com으로 해당 연결을 테스트할 수 있습니다. 포트가 다르면 명령도 함께 수정하세요. socks5h는 대상 도메인의 조회를 프록시 측에 맡기는 방식이며 로컬에서 조회하는 경우와 다릅니다. 앱이 컨테이너나 가상 머신에서 실행 중이라면 127.0.0.1은 호스트가 아니라 해당 환경 자체를 가리킬 수 있습니다. 먼저 호스트에서 연결을 확인한 뒤 격리된 환경의 네트워크 접근을 점검하세요. 편의를 위해 프록시 수신을 모든 네트워크에 공개하지 마세요.

다른 기기에는 클라이언트가 실행 중인 컴퓨터의 LAN IP와 해당 프록시 포트를 입력해야 합니다. 127.0.0.1은 현재 기기 자신을 가리키므로 입력하면 안 됩니다. v2rayN에서 LAN 연결 허용을 켠 뒤에는 코어의 수신 범위, 시스템 방화벽, 기기 간 네트워크 연결도 확인하세요. 라우터의 게스트 네트워크나 무선 기기 격리 기능이 접근을 차단할 수 있으며, HTTP 포트와 SOCKS 포트를 임의로 바꿔 쓸 수는 없습니다. 신뢰할 수 있는 네트워크에서만 공유하고, 방화벽 접근 범위를 필요한 기기나 네트워크 대역으로 제한해 인터넷에 프록시를 노출하지 마세요. 연결되지 않으면 먼저 같은 LAN에서 해당 포트에 접속할 수 있는지 확인한 뒤 노드 상태를 점검하세요. 공유를 중단할 때는 해당 옵션을 끄고 기존 수신 설정을 복구하세요.

각 기기에서 같은 구독 주소를 업데이트해 노드 목록을 공유하거나 단일 노드 링크 또는 QR 코드로 전달할 수 있습니다. 구독은 보통 노드만 배포하며 시스템 프록시, TUN 권한, 로컬 포트, 모든 라우팅 규칙을 동기화하지는 않습니다. 따라서 노드 목록이 같아도 트래픽 경로는 다를 수 있습니다. 먼저 구독 출처와 업데이트 시점을 통일한 다음 기기별로 활성 노드, 분할 라우팅 모드, DNS, 사용자 지정 규칙을 확인하세요. 데스크톱과 Android는 화면 구성과 기능 지원이 다르므로 전체 설정 파일을 그대로 주고받는 것은 적절하지 않습니다. 가져오기 전에 형식 호환성을 확인하세요. QR 코드나 백업 파일을 공유할 때는 인증 정보가 포함되어 있는지 확인하고 공개 앨범이나 단체 대화방에 저장하지 마세요. 기기를 바꾼 뒤에는 다시 테스트해야 하며, 노드 이름만으로 설정이 같다고 판단하면 안 됩니다.

반드시 그렇지는 않습니다. TCP 연결 테스트, 실제 요청 테스트, 앱 접속 확인은 각각 검사하는 내용이 다릅니다. 테스트 대상 자체에 접속할 수 없어도 시간 초과가 발생할 수 있습니다. 먼저 코어가 정상적으로 실행 중인지 확인하고 노드 주소와 포트, 시스템 시간, 전송 매개변수를 점검하세요. TLS 서버 이름, REALITY 공개 키, flow 설정이 잘못되어도 핸드셰이크에 실패할 수 있습니다. 정상 작동이 확인된 노드와 동일한 테스트 대상을 비교하고 다른 정상 네트워크에서도 시도해 서버 문제와 현재 네트워크 문제를 구분하세요. 한 번의 테스트 결과가 계속 사용할 수 있음을 보장하지는 않습니다. 시간 초과를 늘려 설정 오류를 감추려 하지 마세요. 여러 노드가 동시에 실패하면 로컬 네트워크와 클라이언트 로그부터 확인하고, 한 노드만 실패한다면 제공자에게 문의하세요.

연결됨 표시는 코어 또는 VPN 인터페이스가 실행 중이라는 뜻일 수 있지만, 모든 요청이 성공한다는 의미는 아닙니다. 먼저 이 기기에서 인터넷에 정상적으로 접속할 수 있는지와 네트워크 로그인 절차가 완료됐는지 확인한 뒤 시스템 시간, 활성 노드, 클라이언트 로그를 살펴보세요. 다음으로 로컬 수신 포트와 앱의 프록시 설정을 확인하고, 프록시를 명시한 요청으로 해당 연결을 통해 트래픽이 전달되는지 테스트하세요. 테스트는 성공하지만 브라우저에서 실패한다면 브라우저 프록시 확장 프로그램과 시스템 설정을 확인하세요. 요청이 코어에 들어간 뒤에도 실패한다면 전역 모드와 분할 라우팅 모드를 잠시 비교해 라우팅 또는 DNS 문제를 찾으세요. TUN을 사용한다면 가상 인터페이스와 라우팅도 확인해야 합니다. 한 번에 설정 하나만 바꾸고 결과를 기록하세요. 노드를 바꾸고 DNS를 수정하고 모든 규칙을 초기화하는 일을 동시에 하면 효과가 있었던 조치를 알아내기 어렵습니다.

먼저 클라이언트에 설정된 프록시 주소가 시스템 네트워크 설정과 일치하는지 확인하고, 해당 포트가 실제로 수신 중인지 살펴보세요. Linux는 데스크톱 환경에 따라 시스템 프록시 지원이 다르며, 일부 앱은 자체 설정이나 환경 변수만 읽습니다. 브라우저 확장 프로그램이 시스템 프록시를 덮어쓸 수도 있습니다. 프록시를 명시적으로 지정할 수 있는 도구로 연결을 테스트하세요. 연결된다면 코어를 바로 재설치하기보다 앱이 프록시에 연결되는 방식을 확인해야 합니다. 트래픽이 클라이언트에 들어오지 않는 경우와 들어온 뒤 라우팅 규칙에 따라 직접 연결되는 경우도 구분해야 합니다. 요청 로그가 도움이 될 수 있습니다. 시스템 프록시를 읽지 않는 앱까지 처리해야 한다면 TUN 사용을 검토하세요. 클라이언트를 종료한 뒤 네트워크에 문제가 생기면 시스템 프록시 설정을 복구하세요. 수신이 중단됐는데 시스템이 계속 해당 포트를 가리키면 앱 연결이 실패할 수 있습니다.

먼저 실패한 도메인과 로그 오류를 기록해 도메인 조회 실패, 연결 시간 초과, 인증서 오류를 구분하세요. 전역 모드와 분할 라우팅 모드를 비교합니다. 분할 라우팅에서만 실패한다면 앞쪽의 사용자 지정 규칙이 대상을 잘못된 출구로 보내는지, geosite와 geoip 분류 데이터가 규칙과 호환되는지 확인하세요. DNS 설정은 트래픽 출구에 맞춰야 합니다. 노드 서버 주소의 조회와 접속하려는 대상의 조회를 각각 살펴보세요. 브라우저의 보안 DNS가 다른 경로로 조회할 수도 있습니다. 설정을 바꾼 뒤 연결을 다시 만들고, 필요하면 앱 캐시를 지운 다음 같은 도메인을 테스트하세요. TLS를 사용하는 도메인 대신 IP 주소로 계속 접속하면 서버 이름이나 인증서 검증에 문제가 생길 수 있습니다. 로그에 IPv6 관련 내용이 있다면 해당 네트워크 연결도 확인하고, 근거 없이 DNS 설정 여러 개를 동시에 바꾸지 마세요.