V2Ray 자주 묻는 질문

먼저 기기에 맞는 클라이언트를 선택한 다음 설정 요구 사항을 확인하세요. Windows, macOS, Linux에서는 v2rayN을 사용합니다. Android에서는 보통 Xray 코어를 사용하는 v2rayNG를 선택하고, v2fly 코어가 필요하면 v2flyNG를 고려하세요. 클라이언트는 그래픽 인터페이스와 구독 관리, 모드 전환을 담당하고, 코어는 실제 프로토콜 처리를 담당합니다. 이름이 비슷해도 설정이 모두 호환되는 것은 아닙니다. 특히 전송 방식과 보안 매개변수는 서버 설정과 일치해야 합니다. 구독을 이미 사용 중이라면 제공업체가 안내한 클라이언트와 코어 요구 사항을 확인하세요. 프로토콜 이름만으로 호환 여부를 판단하지 말고, 클라이언트를 바꾸기 전에는 기존 설정을 보관해 비교할 수 있도록 하세요.

클라이언트만으로는 연결할 서버가 제공되지 않습니다. 설정을 시작하기 전에 사용할 권한이 있는 구독 주소, 단일 노드 공유 링크 또는 서버 매개변수를 준비하고, 기기에서 로컬 네트워크에 정상적으로 접속할 수 있는지 확인하세요. 수동으로 입력할 때는 주소, 포트, 사용자 ID, 전송 방식, TLS 등의 항목을 하나씩 맞춰야 합니다. 누락된 내용을 임의로 추측하지 마세요. 먼저 기기의 날짜와 시간대를 정확하게 설정한 다음, 사용 가능한 것으로 확인된 설정 하나를 가져와 테스트하세요. 구독 주소와 공유 링크에는 접속 정보가 포함될 수 있으므로 공개 페이지에 게시하거나 낯선 사람에게 전체 내용을 전달하지 마세요.

단일 노드 공유 링크는 보통 vmess://, vless://와 같은 프로토콜 접두사로 시작하며, 하나의 연결 설정을 설명합니다. 구독 주소는 대개 접속 가능한 HTTPS 주소이며, 클라이언트가 해당 주소에 요청을 보내 노드 목록을 가져옵니다. 단일 노드 링크를 복사했다면 클립보드에서 가져오기 기능을 사용하고, 구독을 추가하려면 구독 관리에서 주소를 저장한 뒤 업데이트하세요. 구독 주소를 서버 주소로 직접 입력하면 올바른 설정이 생성되지 않는 경우가 많습니다. 단일 노드는 가져온 뒤 원본 링크의 변경 사항이 자동으로 반영되지 않지만, 구독은 이후 업데이트를 통해 노드를 동기화할 수 있습니다. 다만 업데이트 성공 여부는 구독 서비스와 네트워크 상태에 따라 달라집니다.

서로 다른 계층의 설정입니다. 시스템 프록시는 해당 설정을 따르는 앱의 요청을 로컬 프록시 포트로 보냅니다. TUN은 가상 네트워크 인터페이스로 트래픽을 받아 시스템 프록시를 따르지 않는 일부 앱을 처리하는 데 적합합니다. 전역 라우팅은 코어에 들어온 트래픽이 어떤 출구를 사용할지 결정하지만, 모든 앱의 트래픽이 코어에 들어오도록 보장하지는 않습니다. 따라서 적절한 트래픽 가로채기 기능을 켜지 않고 전역 라우팅만 바꾸면 일부 앱은 여전히 직접 연결될 수 있습니다. 처음 설정할 때는 시스템 프록시로 브라우저 연결을 확인한 뒤 필요에 따라 TUN을 사용하세요. 전환할 때는 로컬 네트워크, DNS, 제외 규칙을 살펴보고 여러 설정을 한꺼번에 바꾸지 마세요.

Android 버전만 보지 말고 먼저 기기의 프로세서 아키텍처를 확인하세요. 최신 Android 휴대전화 대부분은 arm64를 사용하므로 해당 설치 파일을 우선 선택할 수 있습니다. universal 파일은 보통 여러 아키텍처를 포함해 크기가 더 크며, 아키텍처를 확인하기 어렵고 해당 파일이 기기의 아키텍처를 지원하는 경우에 적합합니다. 설치 파일이 호환되지 않는다는 메시지가 나오면 시스템 기기 정보나 신뢰할 수 있는 제품 사양에서 아키텍처를 확인한 뒤 다운로드 페이지에서 다시 선택하세요. 기존 앱 위에 설치하지 못하는 원인은 서명 불일치, 버전 다운그레이드 또는 저장 공간 부족일 수도 있습니다. 앱을 바로 삭제하지 말고 먼저 설정을 백업하세요. 삭제하면 구독, 노드, 사용자 지정 규칙이 지워질 수 있습니다.

단일 노드 가져오기가 아니라 구독 추가를 실행했는지 먼저 확인하세요. 구독 관리에서 주소가 온전한지 확인하고, 복사 과정에서 들어간 공백이나 줄바꿈, 설명 문구를 제거한 뒤 저장하고 수동으로 한 번 업데이트하세요. 그런 다음 해당 구독 그룹으로 돌아가 확인합니다. 여전히 비어 있다면 업데이트 메시지가 접속 실패, 파싱 실패, 빈 응답 중 무엇인지 살펴보세요. 웹페이지나 로그인 화면이 반환되거나 구독 형식이 호환되지 않으면 노드를 인식하지 못할 수 있습니다. 제공업체에 해당 주소가 현재 클라이언트에서 사용 가능한지, 계정이 유효한지 문의하세요. 주소를 낯선 온라인 변환 서비스에 붙여 넣지 말고, 문제 해결용 스크린샷을 공유할 때는 URL 경로의 접속 정보를 가리세요.

먼저 프로세서 아키텍처와 설치 파일 형식을 확인하세요. Windows는 다운로드 페이지 안내에 따라 데스크톱 버전과 클래식 WPF 버전을 구분하고, 선택한 버전의 시스템 요구 사항을 충족하는지 확인합니다. macOS는 ‘이 Mac에 관하여’에서 칩을 확인해 Apple Silicon 또는 Intel용 항목을 선택하세요. Linux는 배포판의 패키지 형식에 따라 deb 또는 rpm을 선택한 다음 x64와 arm64를 구분합니다. 설치 파일을 다운로드할 수 있다고 해서 현재 시스템과 호환되는 것은 아닙니다. 시스템 보안 경고가 표시되면 파일 출처와 경고 원인을 먼저 확인하고, 보안 기능을 일괄적으로 끄지 마세요. 처음 실행한 뒤에는 일반 프록시 연결부터 확인하고, 가상 네트워크 인터페이스와 추가 권한은 실제로 필요할 때 설정하세요.

설정을 저장하고 연결을 중지한 다음, 로그에서 가상 네트워크 인터페이스 생성, 라우팅 변경, 기기 접근 중 어느 단계에서 거부되었는지 확인하세요. Windows에서는 보통 클라이언트 안내에 따라 관리자 권한으로 실행하거나 관련 서비스를 설치해야 합니다. macOS와 Linux의 권한 부여 방식은 버전과 패키징 방식에 따라 다르므로 현재 클라이언트의 안내를 따르고, 다른 플랫폼용 권한 상승 명령을 그대로 사용하지 마세요. Android에서는 처음 연결할 때 시스템 VPN 권한을 허용해야 하며, 다른 VPN 앱이 연결을 사용 중인지도 확인해야 합니다. 권한을 부여한 뒤 해당 기능을 다시 시작하고 로그에서 권한 오류가 사라졌는지 확인하세요. 문제를 우회하려고 시스템 보안 기능을 계속 꺼 두지 마세요.

구독 주소에 실제로 접속할 수 있는 방법을 기준으로 선택하세요. 현재 네트워크에서 주소에 직접 접속할 수 있다면 먼저 직접 연결로 업데이트해 보세요. 프록시를 통해서만 접속할 수 있고 사용 가능한 노드가 있을 때는 프록시 연결 업데이트를 선택합니다. 모든 노드가 만료된 상태에서 그 노드를 이용해 구독을 업데이트하려고 하면 해결할 수 없는 순환이 생깁니다. 접속 가능한 네트워크를 사용하거나 제공업체에 새 유효 주소를 요청하세요. 업데이트 전 현재 그룹과 오류 메시지를 기록하고, 업데이트 후 노드가 실제로 바뀌었는지 확인합니다. 요청을 짧은 간격으로 반복하지 마세요. 서비스에서 요청 횟수를 제한할 수 있습니다. 로컬 DNS 해석 실패, 인증서 오류, 계정 만료를 모두 같은 업데이트 문제로 취급해서도 안 됩니다.

대개는 필요하지 않습니다. 기존 그룹에서 사용할 노드를 선택해 현재 연결로 지정한 뒤, 클라이언트 안내에 따라 다시 연결하거나 설정을 새로고침하세요. 단일 노드만 테스트하는 경우에는 라우팅, DNS, 프록시 모드를 동시에 변경하지 마세요. 차이가 무엇 때문에 생겼는지 판단하기 어려워집니다. 구독을 업데이트하면 노드 ID가 바뀔 수 있으므로 업데이트 후 선택한 항목이 여전히 유효한지 확인하세요. 삭제된 항목을 계속 참조해서는 안 됩니다. 중요한 사용자 지정 매개변수는 업데이트 전에 기록해 두세요. 구독이 생성한 설정을 영구 저장 위치로 오해하지 않도록 주의해야 합니다. 구독 주소가 바뀌었거나 기존 그룹이 손상되었거나 설정 형식을 변경해야 할 때만 구독을 다시 추가하세요.

먼저 필요한 라우팅 규칙 세트를 켜고 각 규칙의 매칭 순서를 확인하세요. 대부분의 규칙은 순서대로 적용됩니다. 로컬 네트워크 주소나 특정 도메인처럼 우선 처리할 항목은 적절한 위치에 배치해 더 넓은 범위의 규칙이 먼저 적용되지 않도록 하세요. 도메인 규칙, IP 규칙, DNS 해석 정책은 서로 영향을 주므로 직접 연결 태그 하나만 바꾸고 모든 요청이 의도대로 처리될 것이라고 가정하면 안 됩니다. 변경 후 로컬 네트워크 서비스, 직접 연결할 사이트, 프록시로 연결할 사이트를 각각 테스트하고, 로그에서 확인할 수 있다면 실제 출구도 살펴보세요. 전역 프록시 모드에서는 규칙 적용 방식이 달라질 수 있으므로 트래픽 분할을 확인하기 전에 해당 규칙 모드가 선택되어 있는지 확인하세요.

흔한 원인은 시스템이 더 이상 요청을 받지 않는 로컬 프록시 포트를 계속 가리키는 것입니다. 정상적으로 종료하기 전에 클라이언트에서 시스템 프록시를 끄거나 해제한 뒤 연결을 중지하세요. 클라이언트가 비정상 종료되었다면 다시 실행해 프록시를 해제하거나 시스템 네트워크 설정에서 프록시 스위치와 주소를 확인하고, 이번 설정으로 남은 로컬 프록시 항목을 제거하세요. TUN을 사용했다면 가상 네트워크 인터페이스와 라우팅이 복원되었는지도 확인해야 합니다. 필요하면 정상 절차로 다시 연결한 뒤 종료하세요. 회사나 학교 네트워크에 필요한 고정 설정을 삭제하지 마세요. 변경 전에 기존 값을 기록해 두세요. 마지막으로 브라우저를 완전히 닫았다가 다시 열어 기본 네트워크가 복구되었는지 확인하세요.

먼저 일반 네트워크가 작동하는지 확인한 뒤 노드 주소와 포트, 구독 만료 여부를 살펴보세요. 테스트 종류도 구분해야 합니다. TCP 연결 테스트 실패는 대상에 접속할 수 없거나 포트가 제한되었거나 서버가 수신 대기 중이 아닐 가능성이 있습니다. 실제 연결 테스트에는 프로토콜 핸드셰이크, TLS, DNS, 테스트 대상 웹사이트도 영향을 줍니다. 특정 테스트 하나의 시간 초과만으로 모든 앱을 사용할 수 없다고 단정할 수는 없습니다. 설정 하나를 그대로 유지하고 다른 정상 노드와 비교한 뒤 해당 시간대의 로그를 확인하세요. 노드 하나만 실패한다면 해당 노드와 서버 상태를 먼저 확인합니다. 모두 실패한다면 로컬 방화벽, 네트워크 환경, 기기 시간, 코어 실행 상태를 점검하세요.

연결됨 표시는 보통 로컬 서비스나 VPN 터널이 시작되었다는 뜻일 뿐, 원격 요청이 성공했다는 의미는 아닙니다. 먼저 코어가 정상 작동하는지 확인한 다음 브라우저 요청이 클라이언트에 들어오는지 살펴보세요. 요청 로그가 없다면 시스템 프록시, 브라우저 자체 프록시, 로컬 수신 포트를 먼저 확인합니다. 요청은 기록되지만 연결에 실패한다면 노드 매개변수, 서버 상태, TLS 오류를 점검하세요. 도메인이 해석되지 않으면 DNS 설정과 해석 서비스에 접속할 수 있는지 확인합니다. 한 번에 하나만 변경하고 같은 테스트를 반복하세요. 모든 보호 기능을 먼저 끄거나 인증서 설정을 임의로 바꾸지 마세요. 특히 인증서 검증 건너뛰기를 일반적인 해결책으로 사용해서는 안 됩니다.

먼저 해당 앱이 시스템 프록시 설정을 따르는지 확인하세요. 일부 앱은 자체 네트워크 설정, 별도 프록시 확장 기능 또는 다른 네트워크 인터페이스를 사용하므로 시스템 프록시를 켜도 연결 방식이 자동으로 바뀌지 않습니다. 시스템 프록시를 따르는 브라우저로 먼저 비교 테스트한 다음, 대상 앱에서 HTTP 또는 SOCKS 프록시를 별도로 설정할 수 있는지 확인하고 클라이언트가 실제로 수신 대기 중인 주소와 포트를 입력하세요. 앱에서 별도 설정을 지원하지 않는다면 TUN 사용이 적절한지 검토하고 제외 규칙과 권한도 확인합니다. 로컬 앱을 연결하려고 무작정 로컬 네트워크 접근을 허용하지 마세요. 수신 범위가 넓어질 수 있으며, 이는 로컬 시스템 프록시가 작동하는지와는 별개의 문제입니다.

문제가 발생한 시간, 시스템 및 클라이언트 버전, 사용한 코어, 프록시 모드, 테스트 동작과 오류 전후의 관련 로그 줄을 남기세요. 먼저 연결을 중지하고 같은 동작을 한 번 재현한 뒤 짧은 구간의 로그를 캡처하면 전체 기록보다 원인을 찾기 쉽습니다. 공유 전에는 구독 주소, 사용자 ID, 비밀번호, 액세스 토큰, 개인을 식별할 수 있는 정보를 가리세요. 스크린샷의 QR 코드와 공유 링크도 숨겨야 합니다. 전체 접속 정보를 공개하지 말고 주소 유형과 오류 범주만 설명할 수 있습니다. 로그에 시작 성공 정보만 있다면 실제 요청을 보낸 뒤의 기록을 추가하고, 모든 앱에서 실패하는지 특정 사이트나 앱에서만 문제가 생기는지도 알려 주세요.