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

플랫폼을 먼저 고려하세요. Windows, macOS, Linux 데스크톱에서는 구독, 시스템 프록시, 라우팅 규칙을 한곳에서 관리하기 편한 v2rayN을 우선 선택할 수 있습니다. Android에서는 Xray 코어를 사용하는 v2rayNG를 고려하세요. v2flyNG는 V2Fly 코어 계열을 대안으로 선택할 수 있으며, 기존 설정이 해당 계열의 동작 방식에 의존하는 경우에 적합합니다. 순서는 플랫폼 지원 범위와 설정 호환성을 기준으로 한 것이며, 연결 속도 순위가 아닙니다. 이미 구독이 있다면 프로토콜, 전송 방식, 보안 매개변수를 먼저 확인한 뒤 클라이언트를 선택하세요. 서버 문제를 해결하기 위해 클라이언트를 바꾸는 것을 기본 해결책으로 삼지 마세요.

역할 구분: 클라이언트는 구독 관리, 노드 선택, 설정 화면을 제공하고, 코어는 설정을 해석해 라우팅을 수행하고 연결을 설정합니다. 노드에는 원격 서버의 주소, 포트, 인증 매개변수가 담깁니다. 화면에서 노드를 가져올 수 있다는 것은 설정이 입력됐다는 뜻일 뿐, 원격 서버를 사용할 수 있다는 의미는 아닙니다. 문제를 진단할 때는 클라이언트 시작 실패, 코어 설정 오류, 원격 연결 실패를 구분해야 합니다. 같은 구독을 반복해서 다시 가져오기보다 클라이언트 버전, 실제 실행 중인 코어, 오류 발생 시각을 기록하는 편이 원인 파악에 도움이 됩니다.

트래픽 처리 범위: 시스템 프록시는 주로 운영체제의 프록시 설정을 따르는 앱에 적용됩니다. 일부 프로그램은 이 설정을 무시하거나 자체 프록시 옵션을 사용할 수 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 조건에 맞는 트래픽을 처리하므로 더 많은 앱에 적용할 수 있지만, 권한과 DNS, 다른 네트워크 도구와의 호환성도 고려해야 합니다. 처음 설정할 때는 시스템 프록시로 노드가 정상 작동하는지 확인한 뒤 TUN을 따로 테스트하세요. 두 모드는 속도 단계가 아닙니다. TUN을 켜도 잘못된 노드 매개변수는 해결되지 않으며, 모든 앱이 같은 경로로 연결된다고 보장할 수도 없습니다.

매개변수 호환성: 프로토콜, 전송 방식, 보안 계층은 서버 설정과 일치해야 합니다. 클라이언트 메뉴에서 이름만 바꾼다고 호환되는 것은 아닙니다. VLESS, VMess, Trojan은 서로 다른 프록시 프로토콜입니다. REALITY는 보안 메커니즘으로, 특정 VLESS 설정 조합에서 흔히 사용되며 이들 프로토콜과 같은 종류의 대체 옵션이 아닙니다. 설정을 가져온 뒤에는 제공된 흐름 제어, 전송, 보안 항목을 그대로 유지하세요. 지원되지 않는 항목이 있다면 현재 코어의 지원 여부부터 확인해야 합니다. 연결 시간 초과를 해결하려고 프로토콜을 바꾸면 변수가 더 늘어날 수 있으므로 기존 설정과 서버 상태를 먼저 확인하세요.

아키텍처 선택: 최근 출시된 Android 스마트폰은 대부분 arm64를 사용하므로 해당 설치 파일을 우선 선택할 수 있습니다. universal은 보통 여러 프로세서 아키텍처를 포함해 파일 크기가 더 크며, 기기의 아키텍처를 아직 확인할 수 없을 때 적합합니다. 기기 출시 연도는 참고만 하고, 실제로는 기기와 운영체제가 지원하는 아키텍처를 확인하세요. 설치 파일을 분석할 수 없다는 오류가 발생하면 다운로드가 완료됐는지, 해당 버전의 시스템 요구 사항을 충족하는지, 아키텍처가 맞는지 점검하세요. 업데이트할 때는 같은 앱을 덮어쓰는지와 서명이 호환되는지도 확인하고, 삭제 후 재설치하기 전에 구독과 사용자 설정을 백업하세요.

가져오기 경로와 형식: 먼저 구독 주소와 단일 노드 공유 링크를 구분하세요. 구독 주소는 구독 그룹에 추가한 뒤 업데이트해야 하며, 노드 공유 링크는 클라이언트에서 지원하는 클립보드 가져오기를 사용하세요. 복사할 때 앞뒤 공백과 줄바꿈, 메신저가 덧붙인 설명을 제거한 뒤 주소가 만료됐거나 재인증이 필요한지 확인하세요. 클라이언트에서 파싱 실패가 표시된다면 응답이 웹페이지나 로그인 안내일 수도 있고, 지원되지 않는 형식일 수도 있습니다. 인코딩을 무작정 바꾸지 마세요. 오류 로그를 통해 요청 단계와 파싱 단계 중 어디서 실패했는지 확인할 수 있습니다. 구독 주소는 민감한 설정 정보이므로 전체 내용이 보이는 화면을 공개하거나 그대로 붙여 넣지 마세요.

시작 순서: 구독을 추가했다고 프록시 연결까지 설정된 것은 아닙니다. 먼저 노드를 선택하고 코어가 정상적으로 실행되는지 확인한 뒤, v2rayN에서 시스템 프록시 자동 설정을 켜세요. 시스템 프록시 주소가 클라이언트의 실제 수신 대기 포트와 일치하는지도 확인해야 합니다. 포트는 현재 설정을 기준으로 하며, 다른 안내에 나온 숫자를 그대로 사용하지 마세요. 특정 앱만 작동하지 않는다면 해당 앱에 별도 프록시 설정이 있는지 확인하세요. 모든 앱에서 실패한다면 포트 사용 여부, 코어 시작 로그, 보안 소프트웨어의 차단 기록을 살펴보세요. 테스트 중에는 다른 프록시 도구를 종료해 시스템 설정이 계속 덮어써지지 않도록 하세요.

권한 확인: 먼저 일반 프록시 모드가 작동하는지 확인한 다음 TUN 권한을 설정하세요. Windows에서는 클라이언트 안내에 따라 관리자 권한을 허용하세요. macOS와 Linux에서는 현재 버전의 요구 사항에 맞춰 보조 서비스 또는 권한 상승을 승인해야 합니다. Android에서는 시스템의 VPN 연결 요청을 확인하세요. 플랫폼마다 권한 승인 방식이 다르므로 서로 바꿔 적용할 수 없습니다. 계속 실패한다면 로그에 나온 구체적인 오류를 확인하고, 다른 VPN이나 가상 네트워크 인터페이스, 보안 소프트웨어와 충돌하는지 점검하세요. 권한 승인을 반복하거나 모든 보안 기능을 끄지 마세요. 충돌하는 프로그램을 종료하고 클라이언트를 다시 시작한 뒤 최소 설정으로 재시험하세요.

요청 경로: 먼저 구독 주소가 여전히 유효한지 확인하고, 연결 시간 초과·접근 거부·응답 파싱 실패를 구분하세요. 직접 연결로 구독을 가져올 수 없지만 사용 가능한 노드가 이미 있다면, 구독 업데이트 시 프록시 사용을 켜고 수동으로 한 번 업데이트한 뒤 로그를 확인해 보세요. 이 옵션은 기존 프록시가 작동해야 사용할 수 있습니다. 처음 설정하는 중이라 사용 가능한 노드가 없다면 켰을 때 의존성이 순환할 수 있습니다. 요청은 성공했지만 파싱에 실패했다면 프록시를 계속 바꾸기보다 구독 형식과 응답 내용을 확인하세요. 자동 업데이트 간격은 제공처의 업데이트 주기에 맞추고, 짧은 시간에 같은 요청을 반복하지 마세요.

그룹 관리: 제공처별로 구독 그룹을 만들고, 알아보기 쉬운 메모로 용도를 구분하세요. 여러 주소를 같은 그룹에 반복해서 가져오지 마세요. 업데이트 전에 현재 선택된 노드와 소속 그룹을 기록하고, 업데이트 후 노드가 삭제되거나 이름이 바뀌거나 교체됐는지 확인하세요. 자동 업데이트는 보통 제공처가 전달한 노드 정보를 다시 구성하므로, 구독 노드에 중요한 수동 변경 사항을 직접 적용하지 않는 편이 좋습니다. 장기간 유지할 설정은 별도로 저장하세요. 그룹을 삭제하기 전에 수동으로 추가한 항목이 포함돼 있는지 확인하세요. 필터 규칙은 조건을 몇 개만 적용해 먼저 테스트해, 사용 가능한 노드까지 숨겨지지 않도록 하세요.

라우팅 선택: 평소에는 실제 사용 목적에 맞는 규칙 기반 분할을 우선 사용하세요. 지정한 대상만 프록시를 거치고 나머지는 규칙에 따라 직접 연결할 수 있습니다. 전역 프록시는 분할 규칙 때문에 문제가 생겼는지 확인할 때 짧은 비교 테스트용으로 적합합니다. 다만 전역 프록시도 클라이언트가 처리하는 범위에 영향을 받으므로 기기의 모든 트래픽을 처리한다는 뜻은 아닙니다. 전역 모드는 정상인데 규칙 모드에서 실패한다면 노드를 바로 바꾸기보다 규칙 순서, 도메인 식별, DNS 경로를 확인하세요. 로컬 네트워크, 프린터, 내부 서비스에는 명시적인 직접 연결 규칙이 필요한 경우가 많습니다. 설정을 바꾸기 전에 기존 값을 보관하고, 한 번에 하나씩 수정해 결과를 기록하세요.

도메인 매핑: FakeDNS는 가상 IP와 도메인을 매핑합니다. 이를 지원하는 TUN 및 라우팅 조합에서 도메인 정보를 유지해 도메인 규칙을 적용하는 데 도움이 됩니다. 범용 네트워크 가속 옵션이 아니므로 DNS 경로를 이해하기 전에 바로 켜지 마세요. 실제 DNS 응답 주소에 의존하는 앱에서는 접속 문제가 생길 수 있습니다. 테스트 전에 DNS와 라우팅 설정을 저장하세요. 활성화한 뒤 특정 앱에서만 문제가 생긴다면 FakeDNS를 끄고 기존 DNS 설정을 복원한 다음, 클라이언트를 다시 연결하고 앱 또는 시스템의 DNS 캐시를 비워 문제가 사라지는지 확인하세요.

단계별 점검: 먼저 기기에서 인터넷이 정상적으로 작동하는지 확인하세요. 이어서 코어가 실행 중인지, 수신 대기 포트가 사용 중인지, 시스템 프록시가 올바른 주소를 가리키는지 살펴보세요. 현재 노드와 구독 업데이트 시각을 확인하고 기기 시계를 점검한 뒤, 로그를 통해 도메인 확인, 연결 설정, 핸드셰이크 중 어느 단계에서 시간 초과가 발생하는지 파악하세요. 정상 작동이 확인된 다른 설정이나 다른 네트워크로 비교할 수 있지만, 한 번에 하나의 조건만 바꾸세요. 지연 시간 테스트 실패가 앱 접속 실패를 반드시 뜻하지는 않습니다. 테스트 대상이 서로 다를 수 있습니다. 같은 노드에서 여러 기기가 모두 실패한다면 설정 제공처에 원격 서버 상태를 문의하세요.

상태 이해: 연결됨 또는 실행 중 표시는 보통 로컬 서비스가 시작됐다는 뜻일 뿐, 모든 대상에 접속할 수 있다는 뜻은 아닙니다. 브라우저가 시스템 프록시와 자체 프록시 중 무엇을 사용하는지 확인한 다음, 같은 대상으로 규칙 모드와 전역 프록시 모드를 비교하세요. 로그에서 DNS 확인 실패, 잘못된 아웃바운드로의 라우팅, 인증 실패가 있는지 살펴보세요. 일반 프록시는 작동하지만 TUN이 작동하지 않는다면 가상 네트워크 인터페이스, DNS, 라우팅 충돌을 중점적으로 확인하세요. 브라우저에서만 실패한다면 확장 프로그램과 브라우저 프록시 옵션을 점검하세요. 클라이언트 재설치, 노드 변경, DNS 수정 등을 동시에 하지 마세요. 어떤 변경이 결과에 영향을 줬는지 파악하기 어렵습니다.

핸드셰이크 매개변수: 먼저 시스템 날짜, 시간, 시간대를 정확하게 설정하세요. 그런 다음 설정 제공처에서 지정한 서버 이름, SNI, 전송 경로, 관련 보안 매개변수를 확인하세요. 연결 주소와 인증서 검증에 사용하는 이름은 서로 다를 수 있으므로 서버 설정에 맞춰 입력해야 합니다. 두 이름이 다르다는 이유만으로 같게 바꾸지 마세요. 일반 TLS 연결은 인증서에 해당하는 이름을 검증해야 합니다. REALITY 설정은 전용 매개변수와 코어 지원 여부도 확인해야 합니다. 인증서 검증을 건너뛰는 방식은 장기적인 해결책으로 사용하지 마세요. 구체적인 오류를 기록하고 주소와 인증 정보는 가리면 인증서, 매개변수, 서버 설정 중 무엇이 문제인지 구분하는 데 도움이 됩니다.

비교 방법: 먼저 문제가 특정 앱이나 도메인에서만 발생하는지 확인한 뒤, 로그에서 도메인 확인 결과와 실제 아웃바운드를 살펴보세요. 같은 대상이 전역 프록시에서는 작동하지만 규칙 모드에서 실패한다면 규칙 적용 순서, 도메인 규칙 데이터, DNS 선택을 먼저 확인하세요. 두 모드에서 모두 실패한다면 노드와 대상 서비스도 점검하세요. 일부 서비스는 도메인과 올바른 TLS 이름이 필요하므로 IP 주소로 직접 접속한 결과만으로 판단하지 마세요. DNS를 조정한 뒤 연결을 다시 설정하고, 필요하다면 캐시를 비우세요. 여러 DNS 서버를 동시에 바꾸면 결과를 재현하기 어려우므로 변경 전후 기록을 남기세요.