V2Ray 전체 플랫폼 설치 및 설정

공통 준비: 클라이언트, 코어, 구독

먼저 세 가지를 구분해야 합니다. 클라이언트는 창을 표시하고 구독을 저장하며 노드를 선택하고 프록시를 관리합니다. 코어는 연결 매개변수를 해석하고 전송을 설정하며 라우팅을 처리합니다. 구독은 설정을 가져오는 경로이지 클라이언트 자체가 아닙니다. 설치가 끝났다는 것은 프로그램을 사용할 준비가 됐다는 뜻일 뿐, 연결하려면 유효한 노드 설정이 필요합니다. 이 사이트는 클라이언트 선택과 사용 방법을 안내하며 구독 서비스는 제공하지 않습니다. 서비스 제공업체의 계정 상태, 데이터 한도 또는 서버 매개변수도 변경할 수 없습니다.

클라이언트와 코어의 관계

데스크톱에서는 Windows·macOS·Linux를 지원하는 v2rayN을 우선 권장합니다. Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 선택하고, V2Fly 설정이 필요한 경우 v2flyNG를 고려할 수 있습니다. Project V는 관련 기술 생태계의 출발점이며, V2Fly는 V2Ray의 유지·개발을 이어 가고 Xray는 별도로 발전 중인 코어입니다. 클라이언트 UI가 비슷해도 코어 구현과 지원 매개변수까지 같은 것은 아닙니다. 프로토콜이 지원되지 않거나 전송 유형을 인식하지 못한다면 설정 요구 사항부터 확인하세요. 이름만 보고 호환성을 판단하지 말고 필요하면 코어를 바꾸세요.

다운로드 전에 운영체제, 프로세서 아키텍처, 설치 파일 형식을 확인하세요. x64는 일반적인 Intel·AMD 데스크톱 프로세서용이고 arm64는 해당 ARM 기기용입니다. 두 파일은 크기만 다른 같은 패키지가 아닙니다. 데스크톱 설치 파일과 Android 설치 파일도 서로 바꿔 쓸 수 없습니다. 클라이언트 다운로드 페이지에서 플랫폼에 맞는 파일을 선택하세요. 설치 전에 기존 클라이언트 데이터를 백업해 두면 문제를 진단할 때 프로그램, 코어, 구독을 한꺼번에 변경하는 일을 피할 수 있습니다.

구독 링크와 설정 정보

전체 구독 주소를 준비하고 복사할 때 안내 문구, 줄바꿈, 끝의 문장 부호가 포함되지 않도록 하세요. 구독 주소에는 접근 토큰이 들어 있을 수 있어 계정 자격 증명과 비슷하게 취급해야 합니다. 공개 채팅, 스크린샷, 공유 로그에 올리지 마세요. QR 코드에도 전체 노드 매개변수가 포함될 수 있습니다. 도움을 요청할 때는 오류 유형과 프로토콜 이름만 남기고 구독 주소, 사용자 ID, 비밀번호, 서버 정보는 가리세요. 구독을 가져오는 데 성공했더라도 설정이 유효하다는 뜻은 아닙니다. 서비스 기간, 데이터 한도, 노드 상태도 확인해야 합니다.

처음 설정할 때는 다른 프록시나 VPN을 끄고 시스템 시간을 맞춘 뒤 일반 네트워크가 정상인지 확인하세요. 기업 네트워크, 학교 인증 페이지, 호텔 로그인 페이지는 먼저 인증을 완료해야 합니다. 프록시 프로그램이 이 절차를 대신할 수는 없습니다. 현재 시스템 프록시와 DNS 설정을 기록해 두고 이후에는 한 번에 한 항목씩만 변경하세요. 조직에서 관리하는 기기는 인증서, 가상 네트워크 어댑터, 네트워크 권한이 정책에 따라 제한될 수 있습니다. 반복해서 권한을 높여 제한을 우회하려 하지 말고 먼저 허용 범위를 확인하세요.

VMess, VLESS, REALITY의 차이

VMess와 VLESS는 연결 프로토콜이고 TLS와 REALITY는 관련 보안 핸드셰이크 설정입니다. TCP와 WebSocket 등은 전송 방식을 나타냅니다. 각 항목은 서로 맞게 조합해야 하며 프로토콜 이름 하나만으로 연결 설정 전체를 설명할 수는 없습니다. VMess는 기기의 시간 설정에 민감합니다. VLESS 자체에는 암호화 기능이 없으므로 설정 요구에 맞는 보안 방식을 함께 사용해야 합니다. REALITY는 모든 노드에 임의로 적용하는 가속 옵션이 아닙니다. 클라이언트가 해당 기능을 지원해야 하며 서버에서 제공한 공개 키와 서버 이름 등의 매개변수도 정확히 입력해야 합니다.

Windows: v2rayN 설치 및 시스템 프록시

Windows 다운로드 페이지에서 v2rayN을 선택하세요. 데스크톱 버전은 크로스 플랫폼 UI를 사용하고, 클래식 WPF 버전은 익숙한 Windows 사용 방식을 이어 갑니다. 이는 UI와 구현 방식의 차이이지 노드 품질의 차이가 아닙니다. 처음 사용한다면 데스크톱 버전부터 시작해도 좋습니다. 기존 작업 흐름이 안정적이라면 연결 문제를 해결하려고 곧바로 UI를 바꿀 필요는 없습니다. 설치 파일 안내에 따라 설치하고, 필요한 실행 환경은 실제로 표시되는 안내를 따르세요. 오래된 가이드를 보고 관련 없는 구성요소를 미리 설치하지 마세요.

설치, 실행, 데이터 위치

실행 후 먼저 기본 창이 정상적으로 열리는지 확인하고, 로그에서 코어 시작 오류가 있는지 살펴보세요. 압축 배포 파일을 받았다면 쓰기 가능한 폴더에 완전히 압축을 푸세요. 압축 파일 미리보기 창에서 바로 실행하지 마세요. 설치 폴더, 사용자 데이터 폴더, 임시 폴더는 서로 다를 수 있습니다. 바탕 화면 바로 가기만 복사하지 말고 클라이언트의 내보내기 또는 백업 기능을 사용하세요. 보안 경고가 나타나면 다운로드 출처와 시스템 안내를 확인하세요. 시작 문제를 해결하려고 시스템 보호 기능을 계속 꺼 두는 것은 권장하지 않습니다.

일반 시스템 프록시를 사용할 때는 보통 관리자 권한이 필요하지 않습니다. TUN으로 가상 네트워크 인터페이스를 만들 때는 추가 권한이 필요할 수 있습니다. 먼저 일반 권한으로 구독과 노드 연결을 설정해 기본 연결이 되는지 확인한 뒤 TUN을 별도로 설정하세요. 시작할 때마다 권한 오류가 발생한다면 구체적으로 어떤 작업이 실패했는지 확인하세요. 폴더 쓰기, 포트 바인딩, 가상 네트워크 어댑터 생성은 서로 다른 문제입니다. 프로그램 전체의 권한을 높이는 것이 항상 올바른 해결책은 아닙니다.

구독을 추가하고 활성 설정 선택

「구독 그룹」 관리에서 그룹을 추가하고 구독 주소를 입력한 뒤 구분하기 쉬운 이름을 지정하세요. 저장 후 「구독 업데이트(프록시 미사용)」를 실행합니다. 아직 프록시 연결을 설정하지 않았다면 이 방법으로 결과를 확인하기 쉽습니다. 구독 출처에 프록시 접속이 반드시 필요한 경우에는 사용 가능한 노드를 먼저 준비한 다음 「구독 업데이트(프록시 사용)」를 선택하세요. 업데이트 로그에서 내용을 가져왔는지 확인하고 기본 목록에 노드가 표시되는지 살펴보세요. 주소만 저장하고 업데이트를 실행하지 않아 목록이 비어 있는 경우가 흔합니다.

사용할 노드를 선택해 활성 설정으로 지정한 다음 코어가 정상적으로 실행되는지 확인하세요. 같은 로컬 수신 포트를 테스트할 때 데스크톱 버전과 WPF 버전을 동시에 실행하지 마세요. 나중에 시작한 프로세스는 포트가 이미 사용 중이라 실패할 수 있습니다. 구독 그룹마다 이름이 같은 노드가 있을 수 있으므로 현재 선택된 그룹을 확인하세요. 새 구독을 업데이트한 뒤에도 기존 그룹의 만료된 설정을 계속 사용하지 않도록 주의해야 합니다.

시스템 프록시, TUN, 종료 후 복구

트레이 메뉴의 「시스템 프록시」에서 「시스템 프록시 자동 설정」을 선택하면 Windows 시스템 프록시를 읽는 앱이 로컬 엔드포인트를 통해 연결됩니다. 「시스템 프록시 지우기」는 시스템 프록시 설정을 제거합니다. 「시스템 프록시 변경 안 함」은 현재 상태를 건드리지 않는다는 뜻이지 설정을 지운다는 뜻은 아닙니다. 브라우저는 확장 프로그램, 기업 정책, 자체 네트워크 설정의 영향을 받을 수 있고 일부 명령줄 프로그램은 시스템 프록시를 전혀 사용하지 않습니다. 따라서 트레이 상태가 올바른 것은 연결 조건 중 하나일 뿐이며 앱별로 확인해야 합니다.

시스템 프록시를 사용하지 않는 프로그램까지 연결해야 한다면 「Tun 활성화」를 검토하세요. 켜기 전에 다른 VPN을 종료하고 로컬 게이트웨이, LAN 서비스, 클라이언트 자체 연결이 터널로 잘못 전달되지 않도록 규칙을 확인하세요. 종료할 때는 먼저 TUN을 끄고 시스템 프록시를 지운 다음 클라이언트를 정상 종료하세요. 프로그램이 비정상 종료된 뒤 브라우저가 인터넷에 연결되지 않는다면 Windows 「설정 → 네트워크 및 인터넷 → 프록시」에서 수동 프록시가 중지된 로컬 포트를 가리키는지 먼저 확인하세요.

macOS: 칩 유형 선택, 네트워크 권한, 프록시 복구

macOS 다운로드 페이지로 이동하기 전에 「Apple 메뉴 → 이 Mac에 관하여」를 여세요. Apple 칩이 표시되면 arm64, Intel 프로세서가 표시되면 x64를 선택합니다. 아키텍처 선택은 프로그램의 네이티브 실행 여부에 영향을 주며 구독 내용은 바꾸지 않습니다. 기기 구매 연도만 보고 칩을 추측하지 마세요. 해당 아키텍처의 v2rayN 디스크 이미지를 다운로드하고 배포 패키지 안내에 따라 앱을 「응용 프로그램」 폴더로 옮기세요. 마운트된 이미지나 다운로드 폴더에서 계속 임시 실행하는 것은 피하세요.

첫 실행 및 시스템 권한 승인

처음 실행할 때 시스템 보안 확인 창이 표시될 수 있습니다. 먼저 앱 출처를 확인하고 macOS UI의 안내에 따라 승인하세요. 「시스템 설정 → 개인정보 보호 및 보안」에서 해당 앱 실행과 관련된 안내를 확인할 수도 있습니다. 구체적인 안내는 시스템 버전, 서명 상태, 관리 정책에 따라 다르므로 모든 기기에 같은 버튼이 나타난다고 기대해서는 안 됩니다. 시스템에서 앱 손상, 아키텍처 불일치, 조직 정책 제한을 알린다면 먼저 오류 원인을 확인하세요. 출처가 불분명한 터미널 명령으로 기기 전체의 보안 설정을 바꾸지 마세요.

기본 창이 열리면 먼저 설정 저장과 코어 실행이 가능한지 확인한 뒤 네트워크 제어 권한을 처리하세요. 시스템 프록시 변경과 가상 인터페이스 생성은 서로 다른 작업입니다. 한쪽을 승인했다고 다른 쪽까지 준비된 것은 아닙니다. 추가 구성요소 설치나 관리자 승인이 필요하면 현재 클라이언트가 안내하는 절차만 따르세요. 회사 관리 기기에서는 터널 인터페이스 생성이 금지될 수 있으며 일반 앱을 반복해서 재설치해도 해결되지 않습니다.

구독 가져오기 및 활성 노드 확인

「구독 그룹」에서 주소를 추가하고 저장한 다음 해당 업데이트 작업을 실행하세요. 처음에는 「구독 업데이트(프록시 미사용)」으로 일반 네트워크에서 구독 출처에 접속할 수 있는지 확인할 수 있습니다. 로그인 페이지, 인증 페이지, 오류 안내가 반환된다면 클라이언트가 응답을 받았더라도 노드 정보를 해석하지 못할 수 있습니다. 이 경우 서비스 제공업체의 계정 페이지에서 구독 상태를 확인하세요. 반환된 웹페이지 텍스트를 노드 설정으로 복사해서는 안 됩니다.

업데이트가 끝나면 노드 하나를 활성 설정으로 선택하고 로그에서 코어 매개변수 오류가 없는지 확인하세요. 처음 테스트할 때 전송 방식, 핑거프린트, 보안 매개변수를 동시에 바꾸지 마세요. 일반적으로 구독에 서버가 요구하는 조합이 이미 포함되어 있습니다. 시스템 시간이 맞지 않으면 인증서 유효 기간이나 프로토콜 인증 판단이 잘못될 수 있습니다. 검증을 끄기보다 날짜와 시간을 자동으로 설정했는지 확인하는 편이 낫습니다. 직접 수정해야 한다면 먼저 설정을 복사해 백업하세요. 다음 구독 업데이트에서 문제 해결 기록이 덮어써지는 일을 막을 수 있습니다.

시스템 프록시와 TUN 선택

「시스템 프록시 자동 설정」을 선택하면 시스템 네트워크 프록시를 사용하는 앱은 대개 클라이언트를 통해 연결됩니다. 「시스템 설정 → 네트워크」에서 현재 네트워크 서비스를 선택하고 세부 정보에서 프록시 설정을 확인하세요. 시스템 UI에 따라 「세부사항」 또는 「고급」에 있을 수 있습니다. Wi-Fi와 유선 네트워크는 별도의 네트워크 서비스이므로 연결 방식을 바꾼 뒤 다시 확인해야 합니다. 브라우저는 되지만 터미널은 안 된다고 해서 노드가 잘못된 것은 아닙니다. 터미널 프로그램에 별도로 프록시를 설정해야 할 수 있습니다.

TUN은 더 많은 트래픽을 제어해야 하는 상황에 적합하지만 DNS, 라우팅, LAN 접근에도 영향을 줍니다. 먼저 시스템 프록시로 명확한 요청 하나를 검증한 다음 TUN을 켜야 어느 단계에서 문제가 생겼는지 알 수 있습니다. 다른 VPN, 원격 업무 소프트웨어, 네트워크 필터링 도구를 실행 중이면 라우팅이 충돌할 수 있습니다. 우선 트래픽 제어 경로를 하나만 사용하고 연결을 확인한 뒤 나머지를 하나씩 복구하세요. 여러 도구가 기본 경로를 동시에 설정하지 않도록 하세요.

네트워크를 바꾸거나 절전 모드에서 복귀하거나 도킹 스테이션을 교체한 뒤 접속에 문제가 생기면 먼저 활성 네트워크 서비스가 달라졌는지 확인하고 클라이언트 코어가 계속 실행 중인지 살펴보세요. 정상 종료 전에는 시스템 프록시를 지우고 TUN을 끄세요. 클라이언트가 중지됐는데도 네트워크가 로컬 프록시를 가리킨다면 현재 네트워크 서비스의 프록시 설정을 복구하세요. 원래 값을 기록하지 않은 채 조직에서 요구하는 DNS나 자동 프록시 주소를 일괄 삭제하지 마세요.

Linux: 설치 형식, 데스크톱 프록시, TUN 권한

Linux에서는 먼저 배포판의 패키지 형식을 확인한 다음 프로세서 아키텍처를 확인하세요. Debian·Ubuntu 계열은 deb, Fedora 등 RPM 계열 배포판은 rpm을 선택합니다. x64와 arm64는 기기에 맞춰야 합니다. 같은 패키지 형식이라고 아키텍처까지 같은 것은 아닙니다. Linux 다운로드 페이지에서 v2rayN을 선택하고 시스템 소프트웨어 설치 프로그램으로 파일을 여세요. 패키지 관리자가 의존성과 설치 정보를 처리하도록 하고 앱 내부 파일을 직접 복사하지 마세요.

설치 후 실행 환경 확인

그래픽 설치 프로그램에서 의존성 부족을 알리면 시스템 소프트웨어 저장소를 새로 고치고 어떤 구성요소가 빠졌는지 확인하세요. 배포판마다 라이브러리 이름, 데스크톱 환경, 디스플레이 서비스가 다르므로 다른 시스템의 의존성 목록을 그대로 따라 하면 안 됩니다. 앱이 메뉴에 나타나지 않으면 데스크톱 세션에서 로그아웃한 뒤 다시 로그인해 확인하세요. 프로그램이 시작되지 않는다면 데스크톱 실행기나 시스템 로그에서 오류를 살펴보세요. 창이 열리지 않는 문제, 코어가 시작되지 않는 문제, 트레이 아이콘이 보이지 않는 문제는 각각 다릅니다.

GNOME 등 데스크톱 환경에서 트레이 표시 여부는 데스크톱 자체의 지원에 따라 달라집니다. 트레이 아이콘이 보이지 않는다고 프로세스가 종료된 것은 아닐 수 있습니다. 기본 창과 프로세스 상태를 확인하고 여러 인스턴스를 연속으로 실행하지 마세요. 트레이를 표시하려고 출처를 알 수 없는 데스크톱 확장 프로그램을 설치하는 것도 권장하지 않습니다. 백업에는 클라이언트 설정과 직접 관리하는 규칙을 포함하세요. 다른 기기로 옮길 때는 로컬 경로, 포트, 권한을 다시 확인해야 하며 이전 시스템 환경이 완전히 같다고 가정하면 안 됩니다.

구독 가져오기 및 데스크톱 시스템 프록시

「구독 그룹」에 주소를 추가하고 저장한 뒤 업데이트를 실행하세요. 노드가 나타나면 활성 설정으로 선택합니다. 먼저 일반 사용자 권한으로 클라이언트를 실행해 코어가 로컬 포트를 수신할 수 있는지 확인하세요. 로그에서 주소가 이미 사용 중이라고 나오면 이전 프로세스가 남아 있거나 다른 프록시 프로그램이 실행 중인지 확인하세요. 포트를 바꿨다면 기존 포트를 명시적으로 참조하는 앱도 함께 변경해야 합니다. 클라이언트 포트만 바꾸고 브라우저나 터미널 설정을 그대로 두면 연결이 무작위로 실패하는 것처럼 보일 수 있습니다.

「시스템 프록시 자동 설정」이 앱에 적용되는지는 데스크톱 환경과 앱의 프록시 설정 읽기 방식에 따라 달라집니다. GNOME, KDE, 독립 창 관리자에서 같은 프록시 설정을 공유하지 않을 수 있고 샌드박스 앱에는 별도 제한이 있을 수 있습니다. 먼저 데스크톱 네트워크 설정에서 실제 프록시 주소를 확인한 다음 브라우저로 테스트하세요. 그래픽 앱은 되지만 패키지 관리자가 연결되지 않는다면 노드를 바꾸기보다 패키지 관리자의 프록시 설정부터 살펴보세요.

# 현재 터미널 세션에 설정된 프록시 환경 변수를 확인합니다
printenv | grep -iE '^(http|https|all|no)_proxy='

# 현재 터미널 세션의 일반적인 프록시 변수만 지웁니다
unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

위 명령은 현재 셸에만 적용되며 데스크톱 프록시, 시스템 서비스, 이미 실행 중인 다른 프로그램의 설정은 변경하지 않습니다. 변수가 셸 시작 파일에서 설정된다면 새 터미널을 열 때 다시 나타납니다. 원래 설정된 위치를 찾아 수정하세요. 환경 변수 대소문자 지원은 앱마다 달라서 변수 하나가 존재한다고 모든 프로그램이 프록시를 사용한다고 볼 수 없습니다. 권한을 높여 실행한 프로그램은 일반 사용자 환경을 상속하지 않을 수도 있습니다.

TUN, 라우팅, LAN 범위

TUN을 사용하려면 시스템이 가상 네트워크 인터페이스를 지원하고 클라이언트가 설계한 방식으로 인터페이스와 라우팅을 설정할 수 있어야 합니다. 구체적인 권한 부여 방법은 현재 클라이언트의 안내를 따르세요. 데스크톱 세션 전체를 장기간 root로 실행하거나 확인되지 않은 권한 부여 명령을 그대로 따라 하지 마세요. 처음 활성화하기 전에 다른 VPN을 종료하고 기존 기본 경로와 DNS 상태를 기록하세요. TUN을 켠 뒤에만 네트워크가 끊긴다면 인터페이스 생성, 권한, 라우팅, DNS 제어 관련 로그를 중점적으로 확인하세요.

컨테이너 네트워크, 가상 머신 브리지, 회사 VPN은 TUN의 라우팅 범위와 겹칠 수 있습니다. LAN 주소에는 적절한 직접 연결 경로를 유지하고 로컬 수신 주소는 기본적으로 루프백으로 제한하세요. 다른 인터페이스에서도 접근해야 할 때만 방화벽과 인증을 설정해 외부에 개방하세요. 종료 후에도 시스템 이름 해석에 문제가 있다면 데스크톱 네트워크 서비스와 실제 DNS 관리 구성요소부터 확인하세요. 여러 DNS 설정 파일을 동시에 수정하면 다음 연결 때 자동 설정으로 다시 덮어써질 수 있습니다.

Android: 클라이언트 선택, 구독, VPN 트래픽 제어

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 권장합니다. V2Fly 코어 설정이 필요하다면 v2flyNG를 대안으로 사용할 수 있습니다. 두 앱은 데이터, 권한, 실행 상태를 각각 관리하므로 대체 클라이언트를 설치했다고 기존 구독이 자동으로 옮겨지는 것은 아닙니다. Android 다운로드 페이지에서 설치 파일을 선택하세요. 대부분의 arm64 기기는 해당 패키지를 우선 선택하면 됩니다. 프로세서 호환성을 확인하기 어렵다면 범용 패키지를 고려하세요. 범용 패키지는 대개 용량이 더 크지만 연결 성능이 더 좋다는 뜻은 아닙니다.

설치 출처 권한 및 업데이트 시 데이터 유지

시스템에서 브라우저나 파일 관리자가 앱을 설치할 수 있도록 권한을 요청할 수 있습니다. 실제 설치에 사용하는 앱에만 권한을 임시로 부여하고 설치가 끝난 뒤 필요에 따라 해제하세요. 설치할 수 없다는 안내가 나오면 아키텍처 불일치, 시스템 요구 사항 미충족, 저장 공간 부족, 서명 충돌을 구분해야 합니다. 업데이트 설치에 실패했다고 바로 제거하지 마세요. 제거하면 로컬 설정까지 삭제될 수 있습니다. 먼저 클라이언트가 지원하는 내보내기 기능으로 백업하고 백업 파일을 민감한 자료로 관리하세요.

같은 앱이라도 배포 출처에 따라 서명이 호환되지 않을 수 있습니다. 시스템 충돌 오류는 구독 문제를 뜻하지 않으며 구독을 다시 업데이트해도 설치 단계 오류가 해결되지는 않습니다. 기존 앱을 정상적으로 사용 중이라면 현재 상태를 유지하고 설치 안내를 읽은 뒤 이전 여부를 결정하세요. 앱 업데이트 후 처음 실행할 때는 바탕 화면 아이콘만 확인하지 말고 기존 그룹, 활성 설정, 라우팅 옵션이 예상대로 유지됐는지 살펴보세요.

구독 그룹, 클립보드, QR 코드

구독 설정이나 그룹 관리에서 이름과 전체 주소를 추가해 저장한 뒤 메뉴에서 구독 업데이트를 실행하세요. 클라이언트 UI에서 구독 관리와 서버 목록이 분리되어 있을 수 있습니다. 그룹을 추가한 뒤 목록으로 돌아가 해당 그룹을 선택해야 합니다. 클립보드 가져오기는 전체 노드 링크에 적합하고 QR 코드 스캔은 단일 설정을 가져올 때 편리하지만, QR 코드가 구독 주소를 가리킬 수도 있습니다. 가져온 뒤 프로토콜과 이름이 적절한지 확인하세요. 목록이 비어 있다면 같은 QR 코드를 반복해서 스캔하지 말고 업데이트 결과부터 살펴보세요.

노드를 선택해 연결을 시작하면 처음에는 Android의 VPN 연결 확인 창이 나타납니다. 이 권한은 클라이언트가 로컬 가상 네트워크 인터페이스를 만들어 트래픽을 제어하도록 허용하는 것이며 원격 노드 연결 성공을 뜻하지 않습니다. 상태 표시줄에 열쇠 또는 VPN 아이콘이 나타나면 시스템 인터페이스가 만들어졌다는 의미일 뿐입니다. 실제 웹 요청과 클라이언트 로그로 전송이 정상인지 확인해야 합니다. 설정 해석에 실패하거나 서버가 연결을 거부해도 시스템 아이콘은 계속 표시될 수 있습니다.

앱별 프록시와 백그라운드 실행

Android 클라이언트는 시스템 VPN 인터페이스로 앱 트래픽을 제어하는 경우가 많습니다. 데스크톱에서 시스템 프록시를 변경하는 방식과는 다릅니다. 앱별 규칙을 켠다면 목록이 「선택한 앱만 프록시 사용」인지 「선택한 앱은 우회」인지 먼저 확인하세요. 방향을 반대로 이해하면 브라우저 테스트 결과도 완전히 달라집니다. 처음에는 범위가 명확한 기본 설정으로 확인하고 연결이 안정된 뒤 필요한 범위만 줄이세요. 설정을 바꿀 때마다 같은 앱으로 다시 테스트하세요.

Android에서는 일반적으로 일반 VPN 서비스를 하나만 활성화할 수 있습니다. 다른 VPN, 일부 방화벽, 로컬 VPN 기반 필터링 도구가 같은 연결을 차지할 수 있습니다. 항상 켜기 VPN과 VPN 없이 연결 차단 옵션은 연결을 끊은 뒤 네트워크 동작에도 영향을 줍니다. 클라이언트를 중지하기 전에 관련 시스템 설정을 확인하세요. 모든 앱에서 네트워크가 끊긴 것을 곧바로 노드 문제로 판단하지 마세요. 시스템이 설정된 차단 정책에 따라 작동하는 것일 수 있습니다.

화면이 켜져 있을 때는 정상인데 잠금 후 연결이 끊긴다면 배터리 최적화, 백그라운드 활동, 제조사의 자동 시작 제한을 확인하세요. 실제 사용하는 클라이언트에 적절한 백그라운드 권한을 부여하면 됩니다. 기기 전체의 절전 정책을 일괄 해제할 필요는 없습니다. Wi-Fi와 모바일 네트워크를 전환한 뒤 연결이 복구되는지도 확인하세요. 특정 네트워크에서만 실패한다면 해당 네트워크의 DNS, 인증, 연결 가능성을 비교하세요. 테스트할 때 노드, 앱, 접속 대상을 고정해 네트워크 전환과 구독 업데이트가 섞이지 않도록 하세요.

라우팅 및 DNS: 규칙에 따른 트래픽 경로

시스템 프록시와 TUN은 트래픽이 클라이언트에 들어오는 방식을 결정하고, 라우팅 규칙은 들어온 트래픽이 어느 경로로 나갈지 결정합니다. 두 계층은 서로 대체할 수 없습니다. 앱 트래픽이 클라이언트에 들어오지 않았다면 「전역」으로 바꿔도 자동으로 제어되지 않습니다. 클라이언트에 들어온 트래픽도 규칙에 따라 직접 연결될 수 있습니다. 먼저 진입 경로를 확인하고 다음에 출구를 살펴보면 불필요한 시행착오를 줄일 수 있습니다. 데스크톱 메뉴의 「중국 본토 우회」, 「블랙리스트」, 「전역」은 미리 설정된 정책이며 실제 규칙 내용은 현재 클라이언트 설정을 기준으로 확인하세요.

규칙 적용 순서와 직접 연결 예외

코어 라우팅은 일반적으로 규칙 순서대로 확인하며 처음 일치하는 규칙이 처리 방식을 결정합니다. LAN 접속을 유지하는 규칙은 업무 규칙과 순서를 조정해야 합니다. 범위가 지나치게 넓은 직접 연결 규칙을 앞에 두면 뒤의 프록시 규칙이 적용되지 않을 수 있습니다. 도메인 규칙은 코어가 도메인을 파악할 수 있을 때만 적용됩니다. IP 직접 접속, 앱의 사전 DNS 조회, 연결 재사용도 확인 결과에 영향을 줍니다. 규칙을 바꾼 뒤에는 새 연결로 테스트하는 편이 좋습니다. 기존 연결은 원래 경로를 계속 사용할 수 있습니다.

아래는 Xray 형식의 라우팅 일부로, 사설 주소를 직접 연결하는 방법만 보여 줍니다. 단독으로 실행할 수 있는 완전한 설정은 아닙니다. 합치기 전에 실제 설정에 direct라는 이름의 직접 연결 아웃바운드가 있는지 확인하고 기존 규칙 순서에 맞게 배치하세요. 그래픽 클라이언트가 시작할 때 설정 파일을 생성할 수 있습니다. 생성된 파일을 직접 편집하면 다음 시작 때 덮어써질 수 있으므로 장기간 사용할 규칙은 클라이언트가 지원하는 규칙 관리 기능으로 관리하세요.

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

도메인 해석 및 규칙 데이터베이스

GeoIP 데이터는 주로 IP 분류에, GeoSite 데이터는 주로 도메인 그룹 매칭에 사용됩니다. 두 데이터는 같은 목록이 아닙니다. geoip:private는 사설 주소 분류를 대상으로 하고 geosite:cn은 해당 도메인 그룹을 참조합니다. 데이터베이스가 없거나 규칙 참조 이름이 지원되지 않거나 코어와 형식이 호환되지 않으면 규칙을 불러오지 못할 수 있습니다. 업데이트 후에는 로그에서 로드 성공 여부를 확인하고 구체적인 요청을 테스트하세요. 다운로드 진행이 끝났다는 이유만으로 규칙이 적용됐다고 판단하지 마세요.

DNS는 도메인 해석 과정을, 라우팅은 연결 경로를 결정하지만 두 기능은 서로 영향을 줍니다. 잘못된 해석 경로를 선택하면 연결할 수 없는 주소를 받거나 도메인 기준 판단에 필요한 정보가 IP만 남을 수 있습니다. 앱, 시스템, 코어 중 누가 DNS를 처리하는지 먼저 확인한 뒤 DNS 요청이 직접 연결되는지 프록시를 거치는지 살펴보세요. 브라우저의 독립 보안 DNS가 켜져 있으면 클라이언트가 예상한 방식으로 조회되지 않을 수 있습니다. 문제를 진단할 때는 한 가지 해석 경로를 고정하고 여러 설정을 동시에 바꾸지 마세요.

FakeDNS와 TUN의 사용 범위

FakeDNS는 가상 IP와 도메인 간 매핑을 통해 후속 연결에서 코어가 도메인 정보를 복원하도록 돕습니다. 실제 서버 주소가 가상 주소로 바뀌거나 모든 앱과 호환된다는 뜻은 아닙니다. 앱 캐시, 분할 라우팅에서 제외된 트래픽, 같은 매핑 과정을 거치지 않은 DNS 요청 때문에 가상 주소가 잘못 사용될 수 있습니다. 클라이언트, 코어, 트래픽 제어 경로가 서로 맞는지 확인한 뒤 사용하세요. 모든 DNS 문제를 해결하는 만능 옵션으로 취급해서는 안 됩니다.

LAN 프린터, 내부 도메인, 회사 네트워크에서는 올바른 DNS 경로를 유지하는 것이 특히 중요합니다. 새 DNS 설정을 켠 뒤 내부 서비스만 작동하지 않는다면 먼저 원래 설정으로 되돌리고 명확한 직접 연결 및 DNS 예외를 추가하세요. 더 많은 필드의 관계는 config.json 구조 해설을 참고하세요. 규칙 데이터 업데이트는 GeoIP 및 GeoSite 데이터베이스 안내를, 가상 주소 방식은 FakeDNS 작동 원리를 확인하세요.

연결 확인: 로컬 진입점부터 실제 요청까지

연결을 확인할 때 「시작됨」 상태 하나만 보지 마세요. 전체 경로에는 클라이언트 프로세스, 코어 수신 대기, 앱 트래픽 제어, 라우팅 규칙 적용, 원격 핸드셰이크, 대상 서비스 응답이 포함됩니다. 앞 단계가 정상이라고 뒤 단계도 정상인 것은 아닙니다. 먼저 시스템 프록시로 브라우저 요청 하나를 확인하고 시스템 프록시를 사용하지 않는 앱을 테스트한 다음 TUN을 검토하세요. 단계별 경계가 명확해집니다. Android에서는 VPN 인터페이스가 만들어졌는지 확인한 뒤 활성 노드와 앱 적용 범위를 점검하세요.

재현 가능한 테스트 한 번 실행하기

현재 네트워크, 활성 노드, 프록시 모드, 라우팅 모드, 테스트 대상을 기록한 다음 한 번에 한 항목만 변경하세요. 먼저 접속 가능성이 명확한 일반 페이지를 열어 기본 네트워크를 확인한 뒤 프록시를 켜고 확인이 필요한 대상에 접속하세요. 새 연결로 테스트하고 필요하면 기존 탭을 닫거나 테스트 앱을 다시 시작해 캐시가 결과를 계속 성공으로 보이게 하지 않도록 하세요. 클라이언트에 테스트 성공으로 표시되어도 해당 테스트 항목만 통과한 것입니다. 모든 서비스 요청이 가능하다는 뜻은 아닙니다.

브라우저는 정상인데 특정 프로그램만 실패한다면 해당 프로그램이 시스템 프록시를 읽는지, 별도 프록시가 설정돼 있는지, 다른 프로토콜을 사용하는지 확인하세요. HTTP 프록시가 일반적인 웹 요청을 처리한다고 해서 모든 UDP 서비스도 같은 경로로 동작하는 것은 아닙니다. TUN도 트래픽을 제어하는 방법일 뿐이며 원격 노드와 코어가 실제 서비스에 필요한 기능을 지원해야 합니다. 앱의 네트워크 오류가 연결 시간 초과, 인증서 오류, DNS 해석 실패, 서버 거부 중 무엇인지 먼저 구분하세요. 모두 속도 저하로 뭉뚱그리지 마세요.

계층별 로그와 점검 결과 확인

로그에서 인증 실패가 나타나면 보통 노드 매개변수와 서비스 상태를 확인해야 합니다. 연결 거부는 대상 포트가 열려 있지 않거나 서비스가 실행되지 않았다는 뜻일 수 있습니다. 시간 초과는 정해진 시간 안에 예상한 단계가 완료되지 않았다는 뜻일 뿐이며 원인은 로컬 네트워크, 회선, 서버에 있을 수 있습니다. 오류 문구는 발생한 단계를 고려해 읽으세요. 해당 요청이 로그에 전혀 없다면 원격 매개변수를 바꾸기 전에 앱의 진입 경로를 확인하세요. 더 자세한 로그가 필요하면 로그 수준을 일시적으로 높이고 원인을 찾은 뒤 평소 수준으로 되돌리세요. 접속 정보가 과도하게 기록되는 일을 방지할 수 있습니다.

지연 시간, 다운로드 속도, 안정성을 구분해서 확인

연결 가능 여부, 핸드셰이크 시간, 대용량 파일 전송량은 서로 다른 지표입니다. 탐지 지연 시간이 낮아도 다운로드가 계속 빠르다는 보장은 없고, 한 번 속도가 높게 나왔다고 장시간 연결이 안정적이라는 뜻도 아닙니다. 같은 대상과 비슷한 시간대, 같은 네트워크에서 테스트하고 Wi-Fi 신호, 대역폭 사용량, 서버 부하도 살펴보세요. 모든 노드를 한꺼번에 테스트한 뒤 순간 결과 하나만으로 선택하지 마세요. 동시 테스트 자체가 회선을 가득 채워 측정에 영향을 줄 수 있습니다.

특정 노드만 계속 실패하면 다른 설정으로 비교해 보세요. 특정 네트워크에서 모든 노드가 실패하지만 네트워크를 바꾸면 정상이라면 로컬 네트워크 경로를 우선 확인하세요. 시스템 프록시는 정상인데 TUN만 실패한다면 권한, 라우팅, DNS 제어를 먼저 살펴보세요. 결과를 기록해 두면 반복해서 재설치하는 것보다 도움이 됩니다. 계층별 진단 방법은 V2Ray 속도 저하 문제 해결을 참고하세요. 이 비교 방법은 간헐적 연결 끊김에도 적용할 수 있습니다.

설정 관련 자주 묻는 질문: 업데이트, 이전, 문제 복구

이 장에서는 플랫폼에 관계없이 발생할 수 있는 마무리 문제를 다룹니다. 먼저 업데이트, 네트워크 전환, 절전 모드, 규칙 변경, 프로그램 종료 중 언제 문제가 시작됐는지 확인한 다음 어느 계층을 복구할지 결정하세요. 설정이 복잡할수록 정상 작동하는 기준 상태를 유지해야 합니다. 이미 사용 가능한 노드 하나, 명확한 프록시 설정, 복구 가능한 규칙 백업을 보관하세요. 변경 사항을 한 번에 하나씩 복구해야 실제 원인을 찾을 수 있습니다. 초보 사용자가 자주 묻는 메뉴 질문은 v2rayN 초보자 질문 10가지도 참고하세요.

구독 업데이트에 성공했는데 왜 연결되지 않나요?

업데이트 성공은 클라이언트가 어떤 데이터를 가져오거나 해석했다는 뜻이지 모든 노드가 온라인이라는 뜻은 아닙니다. 기본 목록에 설정이 실제로 표시되는지, 현재 활성 노드가 방금 업데이트한 그룹에 속하는지, 계정 서비스가 유효한지 확인하세요. 구독 제공업체가 주소를 재설정했다면 이전 링크에서 오류 내용이 계속 반환될 수 있습니다. 계정 페이지에서 전체 주소를 다시 받아 오세요. 업데이트 후 일부 필드를 인식하지 못한다면 클라이언트와 코어의 프로토콜 지원을 확인하고 보안 매개변수를 함부로 삭제해 저장을 강제하지 마세요.

직접 수정한 구독 노드는 다음 업데이트에서 덮어써질 수 있습니다. 사용자 지정 설정을 계속 보관하려면 클라이언트에서 지원하는 방식으로 별도 그룹에 복사하고 수정 목적을 기록하세요. 복사한 노드가 원래 구독의 모든 업데이트를 계속 자동으로 받는다고 생각하면 안 됩니다. 둘 사이의 동기화 관계가 끊겼을 수 있습니다. 기기를 옮길 때도 가져오는 자료가 구독 주소인지, 노드 스냅샷인지, 클라이언트 전체 백업인지 확인하세요. 세 종류의 업데이트 방식은 서로 다릅니다.

클라이언트 업데이트와 코어 전환 순서

업데이트 전에 필요한 자료를 내보내고 진행 중인 전송을 멈춘 다음 이전 프로그램을 정상 종료하세요. 업데이트 후에는 원래 노드와 모드로 기본 기능을 확인한 뒤 코어를 바꾸거나 규칙을 조정하세요. 클라이언트와 코어가 항상 함께 바뀌는 것은 아닙니다. UI에서 특정 필드를 인식해도 현재 실행 중인 코어가 해당 조합을 지원한다는 뜻은 아닙니다. 문제를 진단할 때는 실제 코어 이름과 오류 유형을 기록하세요. 단순히 「업데이트했습니다」라고 말하는 것보다 도움이 됩니다.

데스크톱에서 코어를 전환할 때는 프로토콜, 보안 방식, 전송 유형, 규칙 형식을 확인하세요. 같은 설정도 코어에 따라 지원 범위가 다를 수 있으므로 한 코어의 사용자 지정 필드를 다른 코어에 그대로 적용하면 안 됩니다. Android의 v2rayNG와 v2flyNG는 별개의 앱이므로 앱을 바꾸면 구독 가져오기, VPN 권한, 백그라운드 권한도 따로 설정해야 합니다. 전환 후에만 실패한다면 먼저 정상 작동하던 조합으로 돌아가 비교 결과를 보존한 뒤 호환성을 살펴보세요.

종료 후 네트워크가 끊길 때 복구 순서

데스크톱에서는 먼저 시스템 프록시가 중지된 로컬 포트를 계속 가리키는지 확인하고 TUN이 꺼졌는지 살펴본 뒤 DNS와 다른 VPN 상태를 확인하세요. 브라우저에 별도 프록시 확장 프로그램이 있다면 그것도 따로 점검해야 합니다. Android에서는 항상 켜기 VPN과 VPN 없이 연결 차단 옵션을 확인해 시스템이 기존 정책에 따라 트래픽을 막고 있지 않은지 살펴보세요. 재시작하면 일부 임시 상태가 초기화될 수 있지만 잘못된 설정이 영구 저장됐다면 다시 시작한 뒤에도 문제가 생깁니다.

복구할 때 조직이나 가정 네트워크에서 요구하는 프록시와 DNS 설정을 유지하세요. 모든 값을 한꺼번에 초기화하지 마세요. 컴퓨터에서 LAN 서비스에 접속해야 한다면 먼저 새로 추가한 트래픽 제어 기능을 끄고 기존 네트워크가 정상인지 확인한 뒤 예외 규칙을 하나씩 되돌리세요. 문제가 한 기기에만 있다면 해당 기기부터 확인하세요. 같은 네트워크의 모든 기기에서 동시에 문제가 생긴다면 라우터, 상위 연결, 인증 상태를 먼저 살펴보세요. 클라이언트는 자신에게 전달된 연결만 처리할 수 있으며 네트워크 전체의 기본 문제를 해결하지는 못합니다.

문제 진단을 위해 공유할 정보

운영체제, 클라이언트 이름, 코어 유형, 트래픽 제어 방식, 문제가 발생한 단계, 이미 수행한 비교 테스트를 설명하세요. 로그는 해당 시각 전후의 오류만 추려내고 구독 주소, 사용자 ID, 비밀번호, 식별 가능한 서버 정보는 가리세요. 전체 설정을 보낼 필요는 없습니다. 재현 가능한 문제는 「특정 모드로 전환한 뒤 특정 앱에서 특정 오류가 발생한다」처럼 설명하면 「계속 연결되지 않는다」보다 원인을 찾기 쉽습니다. 설치와 연결 순서를 다시 따라가려면 사용 가이드로 돌아가세요. 설치 형식이나 아키텍처를 바꿔야 한다면 다운로드 페이지에서 확인하세요.