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

먼저 기기의 운영체제를 기준으로 선택지를 좁혀 보세요. Windows, macOS, Linux 데스크톱에서는 v2rayN을, Android에서는 보통 Xray 코어를 사용하는 v2rayNG를 선택합니다. V2Fly 코어를 사용해야 한다면 v2flyNG를 고려할 수 있습니다. 같은 클라이언트라도 버전과 코어에 따라 기능이 달라질 수 있으므로 이름만 보고 프로토콜 호환성을 판단해서는 안 됩니다. 이미 설정이 있다면 설정 제공자가 요구하는 프로토콜, 전송 방식, 보안 매개변수를 먼저 확인하고 클라이언트가 해당 조합을 지원하는지 살펴보세요. 연결 문제가 생겼다고 해서 가장 먼저 클라이언트를 바꿀 필요는 없습니다.

클라이언트는 그래픽 인터페이스와 설정 관리, 프록시 켜기·끄기를 담당하고, 코어는 설정에 따라 연결과 라우팅, 프로토콜 처리를 담당합니다. 노드는 원격 연결에 필요한 매개변수 모음이며, 구독 주소는 이러한 매개변수를 가져오거나 업데이트할 때 사용합니다. 클라이언트를 설치했다고 사용할 수 있는 노드가 생기는 것은 아니며, 화면이 실행된다고 코어와 원격 서버의 연결까지 정상이라는 뜻도 아닙니다. 문제를 해결할 때는 인터페이스 조작, 코어 실행, 구독 가져오기, 노드 연결 중 어느 단계에서 문제가 발생했는지 구분하세요. 구독 주소에는 접속 자격 증명이 포함될 수 있으니 계정 정보처럼 안전하게 보관하고 스크린샷이나 게시판에 공개하지 마세요.

그대로 바꿔 사용할 수 없습니다. VMess, VLESS, Trojan은 서로 다른 프록시 프로토콜이고, REALITY는 이들과 나란히 놓이는 별도의 노드 프로토콜이 아니라 보안 계층 방식입니다. 연결이 성립하려면 클라이언트와 서버의 프로토콜, 전송 방식, 보안 계층 및 관련 항목이 서로 일치해야 합니다. 프로토콜 이름만 바꾸거나 옵션 하나를 켠다고 사용할 수 있는 설정이 만들어지는 것은 아닙니다. 설정 제공자가 준 전체 링크를 가져오는 방법을 우선 사용하세요. 직접 수정하기 전에는 기존 설정을 백업하고 포트, 사용자 식별자, 서버 이름, 공개 키 등 해당 항목을 하나씩 확인하세요.

시스템 프록시는 운영체제에 프록시 주소를 등록하며, 주로 해당 설정을 따르는 앱에 영향을 줍니다. TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 처리하므로 적용 범위가 더 넓고 권한, 라우팅, DNS 설정에도 더 많이 의존합니다. 처음 사용할 때는 TUN을 끄고 시스템 프록시로 설정 하나가 작동하는지 확인한 뒤, 시스템 프록시를 따르지 않는 앱을 살펴보는 것이 좋습니다. TUN은 연결 품질을 높이는 스위치가 아니며 모든 트래픽을 처리한다고 보장하지도 않습니다. 방식을 바꿀 때는 한 번에 하나만 변경하고, 다른 가상 네트워크 어댑터나 프록시 프로그램이 동시에 네트워크를 처리하지 않도록 하세요.

기기가 64비트 ARM 앱을 지원하는지 확인했다면 arm64를 우선 선택하세요. 기기 아키텍처를 확인하기 어렵다면 여러 아키텍처 구성 요소를 포함한 universal 패키지를 선택할 수 있습니다. universal 패키지는 파일 크기가 더 클 수 있지만 연결이 빨라지는 것은 아닙니다. 기기를 구입한 연도만으로 판단하지 마세요. 프로세서는 64비트를 지원해도 운영체제는 32비트 환경으로 실행되는 기기가 있습니다. 앱이 호환되지 않는다는 메시지가 표시되면 시스템 요구 사항, 기기 아키텍처, 설치 파일 출처를 먼저 확인하세요. 서명 충돌이 발생하면 설정을 백업한 다음 기존 앱과 같은 배포 경로에서 받은 앱인지 확인하세요.

먼저 구독 주소와 개별 노드 공유 링크를 구분하세요. 구독 주소는 구독 그룹에 추가하고, 개별 링크는 클립보드에서 가져오기 등 해당 기능을 사용해야 합니다. 주소를 복사할 때 앞뒤 공백, 줄바꿈, 잘림이 없는지 확인하고 웹페이지 제목이나 로그인 페이지가 아닌 원본 주소를 가져왔는지 살펴보세요. 그룹을 추가한 뒤에는 업데이트해야 노드가 표시되는 경우가 많습니다. 내용을 가져오지만 해석하지 못한다면 응답 형식이 호환되지 않거나 오류 페이지가 반환됐을 수 있습니다. 제공자에게 지원 클라이언트와 출력 형식을 확인하세요. 문제를 해결하려고 전체 구독 주소를 낯선 변환 사이트에 입력하지 마세요.

먼저 오류 메시지를 기록하고 운영체제, 프로세서 아키텍처, 설치 파일 종류에 따른 실행 요구 사항을 확인하세요. 압축 파일은 쓰기 가능한 폴더에 완전히 풀어야 하며 압축 프로그램 안에서 바로 실행하면 안 됩니다. 설치 파일은 안내에 따라 설치하세요. Windows 데스크톱 버전과 WPF 버전은 서로 다른 UI 기술을 사용하므로 필요한 실행 환경은 해당 버전의 배포 안내를 기준으로 확인해야 합니다. 모든 실행 오류를 같은 런타임 누락 문제로 볼 수는 없습니다. 이전에는 정상 실행됐다면 남아 있는 프로세스를 종료하고 설정을 백업한 뒤, 별도 폴더의 새 설정으로 실행해 프로그램 문제와 기존 설정 문제를 구분하세요.

데스크톱에서는 로그에서 구체적으로 어느 단계가 실패했는지 확인한 뒤, 현재 운영체제와 클라이언트 요구 사항에 맞게 관리자 권한이나 네트워크 확장 권한을 부여하세요. 시스템 보안 기능을 장기간 끄지는 마세요. Android에서는 시스템 VPN 권한을 허용해야 하며, 일반적으로 같은 VPN 연결을 사용하는 다른 앱을 동시에 실행할 수 없습니다. 이전에는 작동했다면 다른 VPN, 가상 네트워크 어댑터 도구, 보안 프로그램이 네트워크 환경을 바꾸었는지 확인하세요. 네트워크를 처리하는 다른 프로그램을 종료하고 클라이언트를 다시 실행하세요. 그래도 실패하면 시스템 프록시로 되돌려 노드를 확인하고, 권한 문제를 서버 장애로 오해하지 않도록 하세요.

구독을 가져오는 요청과 노드에 연결하는 요청은 서로 다른 경로를 사용합니다. 기존 노드가 작동해도 구독 주소에 접속할 수 있다는 뜻은 아닙니다. 기존 설정은 보존하고 주소가 만료되지 않았는지, 자격 증명이 취소되지 않았는지 확인한 뒤 업데이트 로그에서 시간 초과, 접근 거부, 파싱 오류를 살펴보세요. 클라이언트에서 프록시를 통한 업데이트와 직접 업데이트를 모두 지원한다면 사용할 수 있는 노드가 있을 때 각각 시도해 보세요. 메뉴 이름은 버전에 따라 다를 수 있습니다. 로그인 페이지가 반환되거나 접근이 거부되면 제공자에게 권한을 확인하세요. 그룹을 반복해서 삭제하거나 업데이트를 연달아 실행하지 마세요.

일상적인 사용에는 대상별 규칙에 따라 직접 연결, 프록시 또는 차단을 선택하는 규칙 기반 분할 라우팅을 우선 사용해 보세요. 전역 모드는 임시 비교 테스트에 적합하지만, 구체적인 동작은 클라이언트 설정에 따라 달라집니다. 모든 앱의 트래픽이 클라이언트로 전달된다는 뜻은 아니며, 처리 범위는 시스템 프록시, 앱 프록시, TUN 중 무엇을 사용하는지에 따라 달라집니다. 모드를 전환한 뒤에는 요청을 다시 보내고, 필요하다면 앱의 기존 연결을 끊으세요. 이미 연결된 통신은 이전 경로를 계속 사용할 수 있습니다. 규칙 모드에서만 문제가 발생한다면 노드를 바꾸기보다 적용된 규칙과 DNS 결과를 확인하세요.

그렇지 않습니다. TCP 연결 테스트는 보통 지정한 주소와 포트에 연결할 수 있다는 점만 보여 줍니다. 실제 요청 테스트 결과는 테스트 대상, TLS, DNS, 서버 정책의 영향을 받습니다. 특정 테스트에 실패했다고 노드를 전혀 사용할 수 없는 것은 아니며, 응답이 있다고 모든 웹사이트와 앱에 접속할 수 있는 것도 아닙니다. 자주 사용하는 대상으로 범위를 좁혀 확인하고 로그를 함께 살펴 실패 단계를 파악하세요. 여러 노드를 한꺼번에 테스트하면 트래픽이 늘거나 서비스 제한이 적용될 수 있습니다. 동시 테스트 수를 줄이고 단일 수치에 집착하기보다 같은 환경에서 나온 결과를 비교하세요.

먼저 클라이언트의 내보내기 또는 백업 기능을 사용하고, 현재 코어, 프록시 모드, 수신 포트, 사용자 지정 규칙도 따로 기록하세요. 설정 폴더를 복사해야 한다면 파일이 완전히 저장되지 않은 상태로 복사되지 않도록 클라이언트를 정상 종료하세요. 백업에 노드 자격 증명과 구독 주소가 포함될 수 있으므로 안전한 위치에 보관하고 로그나 설정을 공유하기 전 민감한 항목을 삭제하세요. 한 번에 한 종류의 설정만 변경하고 저장한 다음 같은 대상으로 다시 테스트해 결과를 기록하세요. 복원할 때는 클라이언트 버전과 설정 형식의 호환성을 확인하세요. 특정 코어의 JSON 파일을 그래픽 클라이언트의 관리 데이터베이스에 그대로 덮어쓰지 마세요.

먼저 프록시를 끄고 기본 네트워크가 작동하는지 확인한 다음 시스템 시간, 노드 주소와 포트, 현재 네트워크의 웹 인증 필요 여부를 살펴보세요. 로그에서 DNS 조회 실패가 보이면 DNS를 먼저 확인하고, 연결 설정 시간 초과라면 대상 주소와 포트, 네트워크 경로를 살펴보세요. 핸드셰이크 실패 시에는 프로토콜, 보안 계층, 인증 항목을 확인해야 합니다. 동일한 노드를 사용 권한이 있는 다른 네트워크에서 테스트하거나 현재 네트워크에서 정상 작동이 확인된 다른 설정을 시험하면 문제 범위를 좁힐 수 있습니다. 처음부터 DNS, 라우팅, 프로토콜을 한꺼번에 바꾸지 마세요. 계속 변경하면 기존 문제와 새 문제가 뒤섞입니다.

연결됨 표시는 코어가 실행됐거나 시스템 VPN 연결이 만들어졌다는 뜻일 수 있지만, 원격 요청이 성공했다는 뜻은 아닙니다. 먼저 브라우저에서 명확한 테스트 대상에 접속하고 클라이언트 로그에 해당 연결이 기록되는지 확인하세요. 로그가 없다면 앱 트래픽이 프록시를 통과하는지 살펴보세요. 로그는 있지만 도메인 조회에 실패한다면 DNS를 확인하고, 인증서나 핸드셰이크 오류가 발생하면 시스템 시간과 보안 매개변수를 점검하세요. 다른 라우팅 모드로 잠시 바꿔 규칙이 잘못 적용되는지도 비교해 보세요. 프록시를 꺼도 인터넷에 접속할 수 없다면 기본 네트워크를 먼저 복구하고, 다른 네트워크 처리 프로그램을 종료한 뒤 남아 있는 프록시 설정을 확인하세요.

모든 앱이 운영체제의 프록시 설정을 사용하는 것은 아닙니다. 자체 프록시 옵션을 사용하는 앱도 있고, 시작할 때만 설정을 읽는 앱도 있으며, 일반 HTTP 프록시로 처리할 수 없는 유형의 트래픽도 있습니다. 먼저 클라이언트가 시스템 프록시를 제대로 설정했는지 확인하고 수신 주소와 포트를 점검하세요. 그런 다음 대상 앱을 완전히 종료했다가 다시 실행하세요. 앱이 수동 프록시 설정을 지원한다면 클라이언트에 표시된 프로토콜과 포트를 입력하고 HTTP와 SOCKS를 혼용하지 마세요. 더 넓은 범위의 트래픽을 처리해야 할 때 TUN을 검토하고 앱 제외 목록과 라우팅 규칙도 확인하세요. 시스템 프록시 스위치만으로 트래픽 경로를 판단하지 마세요.

영향을 받는 대상이 특정 도메인인지, 일부 앱인지, 모든 연결인지 먼저 구분하고 로그의 DNS 조회 결과와 일치한 아웃바운드를 기록하세요. 앱, 운영체제, 코어가 각각 DNS 조회에 관여할 수 있으며 브라우저에서 암호화 DNS를 켜면 요청이 예상한 코어 DNS 경로를 거치지 않을 수도 있습니다. DNS 서버에 연결할 수 있는지, 조회 요청이 어떤 경로로 나가는지, 라우팅이 도메인과 IP 중 무엇을 기준으로 일치하는지, 오래된 캐시가 남아 있는지 하나씩 확인하세요. 설정을 바꾼 뒤에는 연결을 다시 만들어 테스트하세요. FakeDNS, IPv6, 도메인 조회 정책은 서로 영향을 줄 수 있으므로 특정 도메인 하나가 실패한다고 고급 옵션을 한꺼번에 모두 켜지 마세요.