V2Ray 자주 묻는 질문
구독·프록시·TUN

먼저 코어와 그래픽 클라이언트를 구분해야 합니다. V2Ray는 Project V 생태계에 속하며, V2Fly가 관련 코어를 유지 관리합니다. Xray는 별도의 코어 분기이며, 지원하는 프로토콜과 전송 방식은 버전에 따라 달라집니다. v2rayN은 구독 그룹, 서버, 라우팅을 관리하는 데스크톱 그래픽 인터페이스로, 선택한 코어를 실행해 연결을 구성합니다. 설정을 사용할 수 있는지 판단할 때는 클라이언트가 링크를 해석할 수 있는지와 코어가 설정 항목을 지원하는지 모두 확인해야 합니다. 클라이언트 이름만 보고 REALITY나 특정 전송 방식을 지원한다고 단정할 수는 없습니다.

클라이언트는 설정을 읽고 연결을 구성하지만, 설치만으로 사용할 수 있는 서버가 자동으로 생기지는 않습니다. 구독 주소는 여러 서버 설정을 가져오는 경로로, 일반적으로 서비스 제공자가 전달하며 계정 식별 정보가 포함될 수도 있습니다. 주소를 받으면 구독 그룹에 저장한 뒤 구독을 업데이트하세요. 주소만 등록하고 업데이트하지 않으면 서버 목록이 비어 있을 수 있습니다. 먼저 서비스 상태와 유효 기간을 확인한 다음 클라이언트 설정을 점검하세요. 전체 주소를 공개 게시판에 올리지 말고, 문제 해결용 스크린샷에서도 쿼리 매개변수와 개인 식별 정보를 가리세요.

구독 주소는 보통 네트워크를 통해 여러 설정을 받아오며, 구독 그룹에서 계속 관리하기에 적합합니다. 개별 노드 공유 링크는 서버 설정 하나를 나타내며, 흔히 vmess://, vless://, trojan://로 시작합니다. QR 코드 모양만으로 유형을 판단하지 말고 먼저 디코딩한 내용을 확인하세요. 개별 링크는 보통 클립보드에서 가져오기 등의 메뉴로 추가하고, 구독 주소는 구독 그룹에 저장합니다. 직접 가져온 노드는 구독 업데이트에 따라 바뀌지 않을 수 있습니다. 제공자가 포트나 인증 매개변수를 변경했다면 다시 가져오거나 설정 항목을 확인해야 합니다.

아닙니다. 시스템 프록시는 시스템 설정을 따르는 앱에 로컬 프록시 진입점을 제공합니다. 전역 라우팅은 코어로 들어온 요청이 어떤 아웃바운드 경로를 이용할지 정합니다. TUN은 가상 네트워크 인터페이스를 통해 조건에 맞는 트래픽을 가로챕니다. 전역 라우팅을 켜도 시스템 프록시를 무시하는 앱의 트래픽이 자동으로 코어에 들어가지는 않습니다. TUN을 켠다고 모든 라우팅 규칙이 프록시를 거치는 것도 아닙니다. 먼저 앱 트래픽이 클라이언트로 들어오는 방식을 확인한 뒤 라우팅 출구를 점검하세요. 처음 테스트할 때는 한 가지 트래픽 처리 방식만 켜 다른 진입점이나 네트워크 도구와 충돌하지 않도록 하세요.

Android 버전만 보지 말고 먼저 기기의 프로세서 아키텍처를 확인하세요. 최근 출시된 일반적인 스마트폰에는 대체로 arm64 패키지가 적합하며, 용량도 범용 패키지보다 작은 편입니다. 아키텍처를 확인하기 어렵거나 설치 중 호환되지 않는다는 안내가 나오면 universal을 선택할 수 있지만, 범용 패키지도 최소 지원 시스템 버전 등의 조건을 따릅니다. 데스크톱 기기 역시 아키텍처에 맞는 설치 파일을 선택해야 하며, Apple Silicon용과 Intel용 설치 경로를 혼용하면 안 됩니다. 업데이트 전에 구독 주소와 필요한 설정을 보관하고 다운로드 센터에서 플랫폼에 맞는 파일을 선택하세요. 아키텍처 문제를 해결하려고 출처가 불분명한 설치 파일을 무작정 덮어쓰지 마세요.

먼저 복사한 내용이 완전한 구독 주소인지 확인하고 앞뒤 공백, 줄바꿈, 메신저가 덧붙인 문구를 제거하세요. 구독 그룹 설정을 열어 주소가 주소 Url 입력란에 들어갔는지, 그룹이 활성화되어 있는지 확인한 다음 구독을 업데이트하세요. 파싱 오류가 표시되면 로그인 페이지나 오류 메시지가 반환되었거나 구독 형식이 호환되지 않을 수 있습니다. 제공자에게 클라이언트에서 사용할 수 있는 형식을 확인하세요. 업데이트 성공으로 표시되는데 노드가 없다면 그룹 필터와 정규식 필터를 해제한 뒤 다시 확인하세요. 같은 이름의 그룹을 반복해서 만들어 원래 오류를 덮지 마세요.

먼저 현재 네트워크에서 프록시를 사용하지 않고 모든 구독을 업데이트해 로그에 기록된 네트워크 오류나 HTTP 상태 코드를 확인하세요. 주소에 기존의 정상적인 프록시가 필요한 경우에는 현재 활성 노드와 로컬 프록시가 실제로 작동하는지 확인한 뒤 프록시를 사용해 모든 구독을 업데이트하세요. 이미 사용할 수 없는 노드에 의존해 같은 구독을 업데이트하지 마세요. 인증 실패, 만료된 주소, 서버의 잘못된 응답은 업데이트 방식을 바꾸는 것만으로 해결되지 않는 경우가 많습니다. 주소, 서비스 상태, 응답 형식을 하나씩 확인하고 로그를 공유하기 전에는 구독 매개변수를 가리세요.

먼저 코어가 실행 중이고 로컬 수신 포트가 열려 있는지 확인한 뒤, 시스템 프록시의 주소와 포트가 클라이언트 설정과 일치하는지 점검하세요. 다음으로 브라우저가 별도의 프록시 설정이나 확장 프로그램 규칙을 사용하거나 직접 연결 예외를 지정했는지 확인하세요. 일부 앱은 시스템 프록시 설정을 아예 따르지 않습니다. 브라우저를 완전히 종료했다가 다시 열고, 같은 테스트 주소에 대한 클라이언트 로그를 비교해 볼 수 있습니다. 다른 네트워크 도구가 시스템 프록시를 계속 덮어쓴다면 충돌하는 도구를 종료한 다음 다시 설정하세요. 시스템 프록시는 트래픽이 들어오는 경로만 제공하며, 프록시를 통과할지는 코어의 라우팅 규칙에 달려 있습니다.

먼저 TUN을 끄고 로그를 확인해 권한, 가상 인터페이스 생성, 라우트 추가 중 어디에서 실패했는지 구분하세요. Windows에서는 보통 관리자 권한이 필요합니다. macOS와 Linux는 사용하는 클라이언트 버전의 안내에 따라 권한을 승인하거나 서비스를 설정해야 하며, 모든 오류를 권한 부족으로 볼 수는 없습니다. Android에서 처음 연결할 때는 시스템 VPN 권한을 승인했는지 확인하고, 다른 앱이 VPN 연결을 사용 중인지 살펴보세요. 권한을 승인한 뒤에도 실패한다면 필요한 구성 요소가 모두 있는지, 보안 소프트웨어가 차단했는지 확인하세요. 구독이 만료된 것으로 오해하지 않도록 당분간 시스템 프록시를 사용해 노드를 테스트할 수 있습니다.

TCPing은 주로 서버 포트와 TCP 연결이 성립하는지 확인하며, 인증, 전송 핸드셰이크, 대상 요청까지 성공한다는 뜻은 아닙니다. 실제 연결 지연은 노드를 통해 테스트 주소에 실제 요청을 보내므로 사용 경로에 더 가깝지만, 테스트 주소의 접근성, 라우팅, 네트워크 부하에도 영향을 받습니다. 먼저 테스트 주소와 설정이 동일한지 확인한 뒤 여러 노드를 비교하세요. 한 번 나온 낮은 수치만으로 안정적인 속도를 판단하지 마세요. TCPing은 정상인데 실제 연결 지연에 실패한다면 서버 포트만 확인하지 말고 프로토콜 매개변수, TLS 핸드셰이크, 테스트 대상도 점검하세요.

먼저 해당 구독 그룹으로 전환해 업데이트 결과를 확인하고 서버 목록에서 현재 활성 항목을 살펴보세요. 구독 업데이트로 이름, 주소, 정렬 순서가 바뀔 수 있으므로 이전 목록에서의 행 위치를 같은 노드의 식별자로 보면 안 됩니다. 사용할 서버를 선택해 활성 서버로 지정한 뒤 로그에서 설정이 다시 로드됐는지 확인하세요. 필요하면 연결을 중지했다가 다시 시작하세요. 구독 노드를 직접 수정한 뒤에도 변경 사항이 계속 유지될 거라고 기대하지 마세요. 다음 업데이트에서 해당 항목이 덮어써질 수 있습니다. 사용자 지정 매개변수를 오래 보존해야 한다면 별도의 설정으로 저장하고 관리 주체를 구분하세요.

먼저 테스트 도메인을 하나 정하고 예상한 규칙에 일치하는지, 규칙이 지정한 아웃바운드 태그가 존재하는지 확인하세요. 라우팅 규칙은 보통 순서대로 적용되므로 앞의 포괄적인 규칙이 뒤의 세부 규칙을 가릴 수 있습니다. 도메인 전략 AsIs, IPIfNonMatch, IPOnDemand는 매칭 과정에서 DNS 조회를 수행할지와 IP 기반 규칙의 판단에 영향을 줍니다. 로그에 표시된 대상과 아웃바운드 결과를 함께 확인하고 브라우저 페이지가 열리는지만 보지 마세요. 수정 후 설정을 다시 불러온 다음 새 요청으로 테스트하세요. 이미 연결된 장시간 연결은 기존 경로를 계속 사용할 수 있습니다.

먼저 프록시를 끈 상태에서 테스트 페이지에 표시되는 외부 IP를 기록하세요. 그런 다음 프록시를 켜고 같은 페이지에 접속해 클라이언트 로그의 요청과 아웃바운드 경로를 비교하세요. 테스트 대상이 프록시를 사용해야 하는 규칙 범위에 있어야 합니다. 그렇지 않으면 외부 IP가 바뀌지 않아도 정상적으로 직접 연결된 것일 수 있습니다. 브라우저 결과는 해당 브라우저의 요청 경로만 보여 주며 모든 앱의 트래픽이 처리됐다는 뜻은 아닙니다. 결과가 예상과 다르면 시스템 프록시, 앱별 프록시, 라우팅, TUN 상태를 하나씩 확인하세요. 설정을 변경한 뒤에는 캐시와 기존 연결의 영향을 피하도록 새 탭이나 새 연결로 다시 테스트하세요.

현재 오류 정보를 보존한 뒤 같은 네트워크에서 정상 작동이 확인된 다른 노드를 테스트해 특정 노드 문제인지 기기 전체의 연결 문제인지 구분하세요. 노드 하나만 실패하면 주소, 포트, 인증 매개변수, 서비스 상태를 확인하세요. 모든 노드가 실패하면 로컬 네트워크, DNS, 방화벽, 현재 활성 코어를 점검하세요. 포트를 먼저 테스트한 다음 실제 연결 지연을 확인하면 원인을 좁힐 수 있지만, 포트에 연결된다고 프로토콜까지 작동하는 것은 아닙니다. 포트, 전송 방식, 보안 설정을 한꺼번에 바꾸지 마세요. 한 번에 한 항목만 조정하고 다시 테스트해야 변경 효과를 판단할 수 있습니다. 원래 설정도 복구할 수 있도록 보관하세요.

먼저 시스템 프록시와 TUN을 끄고 평소 접속할 수 있던 사이트에 일반 네트워크로 연결되는지 확인하세요. 기본 네트워크에 문제가 있다면 먼저 네트워크부터 해결해야 합니다. 다음으로 코어를 실행해 시작 실패나 수신 오류가 있는지 확인한 뒤 활성 노드의 실제 연결 지연을 테스트하세요. 노드 테스트에 성공하면 트래픽 처리 방식 하나만 켜고 앱 요청이 로그에 들어오는지 확인하세요. 요청은 들어오지만 대상에 접속할 수 없다면 라우팅, DNS, 대상 사이트 상태를 점검하세요. 연결 아이콘은 대개 실행 상태만 나타내며 모든 요청의 성공을 보장하지 않습니다. 처음부터 설정을 전부 삭제하지 말고 최소한의 설정으로 문제를 재현하세요.

먼저 시작 단계에서 발생한 오류인지 연결 단계에서 발생한 오류인지 구분하세요. 코어 시작에 실패했다면 가장 먼저 나온 오류 줄을 확인하고 포트 충돌, JSON 문법, 알 수 없는 필드, 선택한 코어가 지원하지 않는 프로토콜을 점검하세요. 마지막 종료 메시지만 보지 마세요. 연결 단계에서 TLS 또는 x509 오류가 발생하면 먼저 시스템 날짜와 시간대를 동기화한 뒤 SNI, 인증서 도메인, 제공자가 요구하는 보안 매개변수를 확인하세요. 인증서 검증을 건너뛰는 방법을 일반적인 해결책으로 사용하지 마세요. 로그를 공유해야 한다면 관련 시간대만 잘라 내고 주소, 사용자 식별 정보, 구독 매개변수를 가리되 오류 키워드는 남겨 두세요.