V2Ray 전체 플랫폼 설치 및 설정

사전 준비: 기기, 설정 및 트래픽 처리 범위 확인

클라이언트, 코어, 연결 설정 구분하기

먼저 세 가지 구성 요소를 구분하세요. v2rayN, v2rayNG, v2flyNG는 노드를 표시하고 구독을 저장하며 프록시 모드를 설정하는 GUI 클라이언트입니다. Xray와 v2fly는 프로토콜 처리, 라우팅, 연결을 담당하는 코어입니다. 구독 또는 공유 링크에는 서버 주소, 포트, 인증 정보와 전송 매개변수가 담깁니다. 클라이언트를 설치했다고 사용할 수 있는 서버까지 제공되는 것은 아닙니다. 시작하기 전에 유효한 설정을 준비하고, 제공자가 현재 기기에서의 사용을 허용하는지 확인하세요. 연결 정보가 없는 것을 설치 실패로 오해하지 않도록 주의해야 합니다.

데스크톱에서는 v2rayN부터 시작하세요. Windows, macOS, Linux의 사용 흐름은 비슷하지만 설치 형식과 권한은 다릅니다. Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 선택하고, 기존 설정에서 v2fly를 명시적으로 요구하는 경우에만 v2flyNG를 선택하세요. 프로토콜 이름만으로 호환 여부를 판단해서는 안 됩니다. VLESS라도 전송 방식, 보안 계층, 추가 옵션이 다를 수 있습니다. 전체 매개변수와 선택한 클라이언트 코어의 지원 여부를 함께 확인하세요. 앱 아이콘을 바꾸는 것만으로 설정 차이를 해결할 수는 없습니다.

아키텍처, 시스템 환경 및 설정 출처 확인

시스템의 기기 정보를 열어 운영체제, 프로세서 아키텍처, 현재 네트워크 연결 방식을 확인하세요. 데스크톱에서 흔히 사용하는 x64와 arm64는 서로 다르며, 설치 파일 형식이 프로세서 아키텍처를 결정하지도 않습니다. 먼저 다운로드 페이지에서 플랫폼을 고른 다음 해당 아키텍처에 맞는 항목을 선택하세요. 시스템 호환 범위는 다운로드 페이지 안내와 설치 프로그램의 실제 메시지를 기준으로 판단하세요. 오래된 글만 보고 모든 시스템에서 실행된다고 가정하지 마세요. 기기 시간은 자동으로 동기화되어야 합니다. 날짜가 크게 어긋나면 인증서 검증과 일부 프로토콜 인증에 문제가 생길 수 있습니다.

받은 자료가 구독 주소인지, 단일 노드 링크인지, 전체 설정 파일인지 확인하세요. 구독 주소는 일반적으로 네트워크에서 설정 목록을 가져오는 URL이며, 단일 노드 링크는 보통 프로토콜 접두사를 포함합니다. 전체 설정 파일에는 인바운드, 아웃바운드, 라우팅이 들어갈 수 있습니다. 각 자료에 맞는 가져오기 메뉴를 사용하세요. 원본은 별도로 보관하고 복사할 때 줄바꿈, 끝부분 공백, 메신저의 내용 잘림을 확인하세요. 구독 링크에는 계정 식별 정보가 포함될 수 있으므로 스크린샷, 로그, 문의 글에 올릴 때 가려야 합니다.

최소 구성으로 연결한 뒤 기능을 하나씩 추가하기

처음 설정할 때는 클라이언트 하나, 선택한 노드 하나, 트래픽 처리 방식 하나만 사용하세요. 데스크톱에서는 시스템 프록시를, Android에서는 VPN 연결을 먼저 설정하고 브라우저가 의도대로 접속되는지 확인한 뒤 라우팅 분기, 앱 제외, TUN을 추가하세요. 프록시 프로그램을 여러 개 동시에 실행하면 로컬 포트를 두고 충돌하거나 시스템 설정을 덮어쓰고 라우팅을 중복 처리할 수 있습니다. 문제가 생기면 최소 구성으로 되돌리세요. 구독, 코어, DNS를 한꺼번에 바꾸는 것보다 원인을 찾기 쉽습니다.

시스템 프록시의 적용 범위를 이해하세요. 시스템 설정을 따르는 앱에 로컬 프록시를 사용하도록 지정하지만, 모든 프로그램이 이를 사용하는 것은 아닙니다. 브라우저 확장 프로그램, 앱 자체 프록시 설정, 명령줄 환경에는 별도 설정이 있을 수 있습니다. TUN은 가상 네트워크 인터페이스로 더 많은 트래픽을 수신하지만 라우팅, DNS, 앱 제외 설정과 시스템 권한의 영향을 받습니다. '전역'이라고 해서 모든 상황에서 모든 데이터가 같은 출구를 거친다고 단정하지 마세요. 클라이언트 규칙과 로그를 함께 확인해야 합니다.

마지막으로 프록시를 사용하지 않는 기본 네트워크 상태를 확인하세요. 기기에서 로그인 페이지조차 열리지 않는다면 클라이언트 설정에 앞서 Wi-Fi 연결, 네트워크 인증, 로컬 DNS 문제를 해결해야 합니다. 기존 시스템 프록시와 수동 DNS 설정을 기록하세요. 특히 회사 네트워크나 관리 대상 기기의 기존 정책을 임의로 덮어쓰면 안 됩니다. 테스트할 때는 가능한 한 같은 네트워크, 대상, 모드를 사용하세요. 한 번에 하나씩만 변경하고 결과를 기록해야 나중에 정확히 되돌릴 수 있습니다. 재설치에 기대지 마세요.

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

데스크톱 버전과 클래식 WPF 버전 선택

Windows 다운로드에서 v2rayN을 먼저 확인하세요. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하고, 클래식 WPF 버전은 Windows 인터페이스와 익숙한 조작 방식을 유지합니다. 메뉴 위치는 다를 수 있지만 구독, 활성 노드, 시스템 프록시, 라우팅은 같은 설정 계층에 속합니다. 다운로드 페이지의 시스템 요구 사항에 따라 선택하고, 같은 포트를 시험하려고 두 버전을 동시에 실행하지 마세요. 사용할 버전을 먼저 결정한 뒤 바로 가기와 작업 디렉터리를 맞춰 두세요.

설치 프로그램을 실행하고 시스템 안내에 따라 설치한 뒤 현재 계정에 쓰기 권한이 있는 위치에 설정을 저장하세요. 압축 파일 형태로 받은 경우 먼저 전체 압축을 푼 다음 압축 해제한 폴더에서 실행하세요. 압축 파일 미리보기 창에서 바로 실행하면 안 됩니다. 런타임 구성 요소가 필요하다는 메시지가 나오면 시스템 안내와 다운로드 페이지 설명을 먼저 확인하세요. 출처를 알 수 없는 팝업에서 구성 요소를 받지 마세요. 처음 실행할 때 보안 경고가 표시되면 파일 출처와 시스템 메시지를 확인하고, 시스템 보호 기능 전체를 끄지 마세요.

구독 가져오기 및 활성 노드 선택

메인 창에서 구독 그룹 관리 메뉴를 찾아 그룹을 추가하고 알아보기 쉬운 이름과 전체 구독 주소를 입력한 뒤 저장하고 업데이트하세요. 주소를 추가하는 것만으로 구독 기록이 만들어집니다. 노드 목록을 가져오려면 보통 직접 업데이트해야 합니다. 업데이트가 완료되면 해당 그룹에서 노드를 선택하고 활성 서버로 설정하거나 같은 의미의 메뉴를 사용하세요. 목록에서 행을 강조 표시하는 것만으로 전환이 완료되지 않을 수 있습니다. 활성 표시를 확인하고 로그에 해당 설정이 로드되었는지도 살펴보세요.

먼저 코어를 시작한 다음 시스템 프록시를 켜세요. 자동 설정을 사용할 때는 Windows에 원격 서버 주소를 직접 입력하지 말고 클라이언트가 제공하는 시스템 프록시 옵션을 선택하세요. 시스템 프록시는 로컬 수신 주소를 가리키며 원격 연결은 코어가 처리합니다. 시스템 프록시 설정을 열어 주소가 로컬 루프백인지, 포트가 클라이언트와 일치하는지 확인하세요. 다른 사용자의 고정 포트를 그대로 따라 하지 마세요. 실제 값은 현재 클라이언트 설정을 기준으로 해야 합니다.

앱별로 시스템 프록시와 TUN 확인

시스템 프록시를 따르는 브라우저에서 테스트 페이지를 열고 새 연결 기록이 생기는지 확인하세요. 브라우저는 정상인데 특정 앱만 실패한다면 노드를 바꾸기 전에 앱 자체 프록시 설정, 확장 프로그램, 내장 네트워크 옵션을 확인하세요. 프로그램이 수동 프록시를 명시적으로 지원한다면 클라이언트의 실제 수신 프로토콜에 맞춰 HTTP 또는 SOCKS 주소를 입력하세요. SOCKS 포트를 HTTP 포트로 사용하지 마세요. 확인이 끝나면 앱 프록시 설정은 명확한 한 가지 방식만 남기세요.

시스템 프록시를 따르지 않는 앱까지 처리해야 한다면 그때 TUN을 고려하세요. 기존 설정을 저장하고 클라이언트 안내에 따라 가상 네트워크 인터페이스와 라우팅에 필요한 권한을 부여한 다음 기능을 켜세요. 첫 테스트에서는 타사 VPN이나 수동 라우팅을 추가로 사용하지 마세요. TUN이 정상적으로 시작되면 관련 인터페이스나 시작 로그가 보여야 합니다. 스위치가 켜져 있어도 권한 오류가 발생했다면 트래픽 처리가 시작된 것으로 볼 수 없습니다. TUN 모드 안내를 참고해 구체적인 절차를 확인하세요.

Windows의 시작 및 종료 관련 문제 해결

시작에 실패하면 먼저 다른 인스턴스가 수신 포트를 사용 중인지 확인하세요. 중복 실행 중인 인스턴스를 종료한 뒤 다시 시작하세요. 그래도 실패하면 로그에서 포트 충돌, 설정 파싱, 구성 요소 누락에 관한 구체적인 메시지를 찾으세요. 보호된 위치에 설치했거나 설정 파일을 동기화 프로그램이 사용 중이면 저장에 실패할 수 있습니다. 디렉터리 권한과 파일 상태를 확인하세요. 모든 문제를 관리자 권한으로 실행해 덮어두지 말고, 백업하지 않은 구독 자료도 삭제하지 마세요.

정상 종료 전 TUN을 끄고 이 클라이언트가 설정한 시스템 프록시를 해제한 다음 프로그램을 종료하세요. 비정상 종료 후 웹페이지가 모두 열리지 않는다면 Windows가 중지된 로컬 프록시를 계속 가리키는지 확인하세요. 기존 설정으로 복구한 뒤 클라이언트를 다시 시작하세요. 자동 시작은 수동 연결이 안정된 뒤 켜고, 로그인 후 시작과 권한 상승 안내를 각각 확인하세요. 절전 모드에서 깨어난 뒤 문제가 생기면 먼저 트래픽 처리 기능을 다시 시작하고 네트워크를 확인하세요. 구독 전체를 다시 가져올 필요는 없습니다.

macOS: 칩에 맞는 설치 및 네트워크 서비스 확인

칩을 확인하고 앱 설치

시스템의 '이 Mac에 관하여'에서 Apple 칩인지 Intel 프로세서인지 확인한 뒤 macOS 다운로드에서 v2rayN을 선택하세요. Apple Silicon은 arm64, Intel은 x64에 해당합니다. 기기를 구매한 연도만으로 판단하지 마세요. 아키텍처가 맞지 않으면 실행되지 않거나 추가 호환 계층이 필요해 문제 해결 과정이 복잡해질 수 있습니다. 다운로드 페이지에 선택지가 두 개라면 앱을 둘 다 설치해 시험하지 말고 기기의 기본 아키텍처에 맞는 항목을 선택하세요.

디스크 이미지를 열고 안내에 따라 앱을 응용 프로그램 폴더로 옮긴 뒤 그 위치에서 실행하세요. 마운트한 이미지에서 계속 실행하면 업데이트, 바로 가기, 권한 관리가 복잡해질 수 있습니다. 처음 열 때는 시스템 안내에 따라 앱 출처를 확인하세요. 시스템이 실행을 차단하면 개인정보 보호 및 보안에서 이번 작업과 관련된 메시지를 확인하고, 출처를 검증한 뒤 시스템에서 허용하는 절차를 따르세요. 이유를 알 수 없는 차단을 피하려고 시스템 보안 기능 전체를 끄는 명령을 사용하지 마세요.

설정 가져오기 및 시스템 프록시 적용 위치 확인

v2rayN의 구독 관리에서 그룹을 추가하고 전체 주소를 입력한 다음 저장 후 업데이트하세요. 노드가 표시되면 사용할 노드를 활성 노드로 지정한 뒤 프록시를 시작하세요. 설정을 가져왔지만 코어가 시작되지 않는다면 로그에서 프로토콜, 보안 계층, 전송 오류를 먼저 확인하세요. 가져오기에 성공했다는 것은 클라이언트가 자료를 읽었다는 뜻일 뿐, 선택한 코어가 모든 옵션을 지원한다는 뜻은 아닙니다. 다른 기기로 옮길 때도 다른 환경에만 맞는 사용자 지정 설정 파일을 잘못 사용하지 않았는지 확인하세요.

시스템 프록시를 켠 뒤 시스템 네트워크 설정에서 현재 사용 중인 네트워크 서비스를 확인하세요. Wi-Fi, 이더넷, 기타 네트워크 서비스마다 프록시 옵션을 따로 저장할 수 있습니다. 연결 방식을 바꾸면 기존 설정이 새 서비스에 적용되지 않을 수도 있습니다. 로컬 주소, 포트, 프로토콜을 확인하고 서버 도메인을 로컬 프록시 주소에 입력하지 마세요. 회사 네트워크에 자동 프록시 스크립트가 설정되어 있다면 기존 설정을 먼저 기록하세요. 기존 연결 경로를 덮어써서 복구할 수 없게 되지 않도록 주의해야 합니다.

브라우저 테스트가 통과하면 사용할 앱도 확인하세요. 일부 앱은 자체 프록시 설정을 유지하고, 일부 터미널 프로그램은 환경 변수만 읽습니다. 시스템 프록시를 켰다고 모든 프로그램이 이를 사용하는 것은 아닙니다. 문제를 진단할 때는 먼저 브라우저 프록시 확장 프로그램을 잠시 끄고, 같은 대상에서 기본 설정과 앱 자체 설정을 비교하세요. 특정 앱 하나만 문제가 있다면 전체 시스템 DNS를 반복해서 바꾸기보다 해당 앱의 네트워크 옵션을 먼저 확인하세요.

TUN 활성화 및 권한·네트워크 전환 처리

더 많은 트래픽을 처리해야 한다면 클라이언트에서 실제 제공하는 TUN 기능을 사용할 수 있습니다. 먼저 설정을 저장하고 현재 인터페이스의 권한 안내를 따른 뒤 가상 인터페이스와 라우팅이 제대로 구성되었는지 확인하세요. 배포 형태와 시스템 환경에 따라 보조 구성 요소나 권한 안내가 다를 수 있으므로 현재 클라이언트의 메시지를 기준으로 하세요. 오래된 글의 인터페이스 이름을 그대로 따라 하거나 용도를 모르는 시스템 네트워크 인터페이스를 직접 삭제하지 마세요. 활성화 후 네트워크가 끊기면 먼저 TUN을 꺼서 기본 상태로 복구하세요.

Wi-Fi에서 유선 네트워크, 핫스팟 또는 웹 로그인이 필요한 네트워크로 전환할 때는 먼저 기본 연결이 성립했는지 확인하세요. 인증 페이지는 현재 네트워크에서 직접 접속해야 할 수 있으며 기존 프록시, DNS, 라우팅이 인증을 방해할 수 있습니다. 먼저 트래픽 처리를 끄고 인증을 마친 뒤 다시 켜세요. 절전 모드에서 깨어난 뒤 코어는 실행 중인데 연결이 멈췄다면 네트워크 서비스가 바뀌었는지 확인하고 트래픽 처리를 다시 시작하세요. 구독이 만료되었거나 매개변수가 바뀐 경우에만 노드 정보를 업데이트하면 됩니다.

설정을 저장하고 명확한 종료 절차 유지

앱을 업그레이드하기 전에 클라이언트가 지원하는 방법으로 구독 그룹과 필요한 설정을 백업하고 현재 라우팅 및 트래픽 처리 모드를 기록하세요. 프로그램 디렉터리와 사용자 설정 디렉터리는 역할이 다르므로 앱 삭제가 설정 삭제를 뜻하지는 않습니다. 새 기기로 옮길 때는 원본 구독을 다시 가져온 다음 사용자 지정 설정을 하나씩 복원하세요. 이전 기기의 네트워크 경로, 권한 상태, 인터페이스 관련 매개변수를 그대로 옮기지 않도록 주의하세요. 백업 파일은 직접 관리할 수 있는 위치에 보관하고 공개하지 마세요.

앱을 종료했는데도 인터넷에 연결되지 않으면 현재 네트워크 서비스의 프록시 설정에 로컬 주소가 남아 있는지, 해당 로컬 프로세스가 중지되었는지 확인하세요. 기록해 둔 기존 설정으로 복구한 뒤 기본 네트워크를 테스트하세요. 회사 네트워크 도구도 설치되어 있다면 기기 관리 정책을 따르고 관리 대상 설정을 임의로 수정하지 마세요. 장기 사용 시에는 명확한 시작·종료 순서를 유지하세요. 네트워크를 먼저 연결하고 코어를 시작한 다음 트래픽 처리를 켭니다. 종료할 때는 반대 순서로 진행하면 남은 설정을 찾기 쉽습니다.

Linux: 패키지 선택 및 데스크톱 프록시와 TUN 구분

배포판과 아키텍처에 맞는 설치 방법 선택

Linux 다운로드에서 v2rayN을 선택하세요. 먼저 시스템 설정이나 기기 정보에서 배포판과 프로세서 아키텍처를 확인한 뒤 패키지를 고르세요. deb는 Debian, Ubuntu 및 관련 배포판에서 흔히 사용하고 rpm은 해당 패키지 관리 체계를 쓰는 배포판에서 주로 사용합니다. 두 형식은 임의로 바꿔 쓸 수 있는 압축 파일이 아닙니다. 데스크톱에서는 x64가 흔하고 일부 기기는 arm64를 사용하므로 패키지 형식과 아키텍처가 모두 맞아야 합니다. 파일 확장자만 보고 설치 가능 여부를 판단하지 마세요.

시스템 소프트웨어 설치 도구로 로컬 패키지를 설치해 패키지 관리자가 의존성과 설치 기록을 처리하도록 하세요. 의존성이 충족되지 않는다는 메시지가 나오면 구체적인 구성 요소와 시스템 버전을 확인한 뒤 현재 환경이 지원 범위에 포함되는지 판단하세요. 의존성 검사를 무시하고 설치를 강행하거나 클라이언트 하나를 실행하려고 시스템 기본 라이브러리를 임의로 바꾸지 마세요. 설치 후 앱 메뉴에서 실행하세요. 데스크톱 바로 가기가 바로 갱신되지 않으면 데스크톱 세션에 다시 로그인한 뒤 설치가 완료되었는지 확인하세요.

일반 사용자 계정으로 구독 및 로컬 프록시 설정

일상적으로 사용하는 계정으로 클라이언트를 실행하고 구독을 가져와 노드를 업데이트한 다음 활성 노드를 선택하세요. 구독과 인터페이스 설정은 보통 현재 사용자 계정에 저장됩니다. 계속 높은 권한으로 실행하면 파일 소유자가 바뀌어 다음에 일반 사용자로 저장할 수 없게 될 수 있습니다. 설정이 저장되지 않는다면 권한을 더 높이기 전에 설정 디렉터리의 소유자와 쓰기 권한을 확인하세요. 설정을 옮길 때는 먼저 백업한 다음 클라이언트가 지원하는 가져오기 방식으로 복원하세요.

Linux의 데스크톱 프록시는 모든 프로세스에 적용되는 단일 스위치가 아닙니다. 데스크톱 환경마다 설정 방식이 다를 수 있고, 브라우저, 소프트웨어 스토어, 터미널, 백그라운드 서비스가 각각 시스템 설정, 환경 변수, 자체 설정을 참조할 수 있습니다. 먼저 시스템 프록시를 명시적으로 지원하는 브라우저 하나로 테스트한 뒤 다른 앱을 하나씩 확인하세요. 터미널은 환경 변수를 변경한 뒤 새로 열어야 할 수 있습니다. 이미 실행 중인 서비스는 데스크톱 세션에서 나중에 바뀐 변수를 자동으로 받지 않습니다.

클라이언트 안내에 따라 TUN 권한 설정

TUN을 켜기 전에 현재 Linux 환경에서 클라이언트가 해당 기능을 제공하는지 확인하고 인터페이스의 권한 안내를 읽으세요. 가상 네트워크 장치와 라우팅을 수정하려면 추가 권한이 필요한 경우가 많지만, 그렇다고 그래픽 인터페이스를 항상 높은 권한으로 실행해야 하는 것은 아닙니다. 클라이언트가 지원하는 보조 서비스나 권한 부여 절차를 우선 이용하세요. 다른 배포판용 권한 명령을 현재 시스템에 그대로 복사하거나 안내를 생략하려고 앱 디렉터리 전체에 과도한 접근 권한을 부여하지 마세요.

시작 후 로그를 확인해 가상 인터페이스가 실제로 생성되고 라우팅이 추가되었는지 살펴본 다음 앱 트래픽을 테스트하세요. 시스템 DNS 관리자, 네트워크 관리 서비스, 클라이언트 DNS 설정이 동시에 존재할 수 있으므로 어떤 구성 요소가 질의를 받고 어느 서버로 전달하는지 구분해야 합니다. 도메인 접속만 실패하고 직접 네트워크 연결은 정상이라면 DNS 관련 오류부터 확인하세요. 모든 문제를 서버 장애로 돌리지 마세요. 이름 해석 설정을 바꾸기 전에 기존 상태를 기록하고, 클라이언트를 중지한 뒤에도 정상적으로 복구할 수 있어야 합니다.

포트, 데스크톱 세션 및 네트워크 관리 충돌 해결

로컬 포트 충돌은 흔한 시작 실패 원인입니다. 다른 사용자 세션, 이전 인스턴스, 다른 프록시 도구가 같은 포트를 이미 수신 중이면 새 인스턴스가 프록시 진입점을 만들지 못할 수 있습니다. 더 이상 필요하지 않은 인스턴스를 먼저 종료하세요. 포트를 바꿔야 한다면 해당 포트를 수동으로 가리키는 앱도 모두 함께 변경해야 합니다. 클라이언트 한쪽만 바꾸면 브라우저가 이전 진입점에 계속 연결됩니다. 방화벽 규칙은 실제 필요에 따라 확인하세요. 로컬에서만 사용하는 프록시 수신 주소를 전체 LAN에 공개할 필요는 보통 없습니다.

그래픽 인터페이스가 열리지 않는 문제와 네트워크 연결이 되지 않는 문제는 서로 다릅니다. 디스플레이 서비스, 데스크톱 세션, 인터페이스 의존성에 문제가 있다면 먼저 앱 실행부터 해결하세요. 코어는 실행되지만 트래픽이 통하지 않는 경우에는 설정과 네트워크 경로를 확인하면 됩니다. 데스크톱 환경이 없는 원격 시스템을 같은 그래픽 사용 환경으로 간주하지 마세요. 이 안내서는 GUI 클라이언트를 중심으로 다루며 문제 해결을 위해 별도의 백그라운드 프록시 서비스를 만들 필요는 없습니다. 같은 기기에 출처가 불분명한 라우팅 설정이 두 벌 생기지 않도록 하세요.

시작 프로그램을 설정하기 전에 일반 로그인 후 수동 실행 절차부터 확인하세요. 자동 시작 작업, 사용자 서비스, 시스템 서비스는 실행 계정과 환경이 서로 다르므로 데스크톱에서 쓸 수 있는 경로가 백그라운드에서도 동작한다고 볼 수 없습니다. 소프트웨어 업데이트 후 자동 시작 항목이 유효한 위치를 가리키는지 확인하세요. 정상 종료 시에는 TUN을 끄고 프록시를 복구하세요. 비정상 종료 후 네트워크가 끊기면 전체 방화벽이나 시스템 라우팅을 지우지 말고 먼저 기존 네트워크 관리 설정을 기준으로 복구한 뒤 클라이언트를 다시 켜세요.

Android: 클라이언트 설치 및 VPN 트래픽 처리 관리

v2rayNG 또는 v2flyNG 선택

Android 다운로드에서 시작해 Xray 코어를 사용하는 v2rayNG를 우선 선택하세요. v2fly 코어가 필요할 때는 v2flyNG를 고려하면 됩니다. 두 앱은 서로 다른 클라이언트이므로 구독, 라우팅, 앱 제외 설정이 자동으로 공유된다고 가정하면 안 됩니다. 최근 출시된 일반적인 휴대전화라면 arm64 항목을 먼저 확인하고, 오래된 기기이거나 아키텍처를 알 수 없다면 범용 버전 안내를 살펴보세요. 최종 선택은 기기 지원 아키텍처와 설치 메시지를 기준으로 해야 하며 휴대전화 외관만으로 판단해서는 안 됩니다.

설치 전에 현재 다운로드 출처에서 앱을 설치하도록 허용하고 실제로 사용하는 브라우저나 파일 관리자에만 필요한 권한을 부여하세요. 설치 후에는 더 이상 필요하지 않은 출처 권한을 끌 수 있습니다. 패키지 분석 실패, 설치 불가, 기존 앱과의 충돌이 발생하면 파일이 현재 기기에 맞는지, 기존 앱의 설치 출처는 무엇인지 확인하세요. 설정이 지워질 수 있으므로 바로 삭제 후 재설치하지 마세요. 먼저 구독 주소와 필요한 설정을 저장한 뒤 이전 또는 재설치가 필요한지 판단하세요.

구독 가져오기, 노드 선택 및 연결 허용

앱을 열고 메뉴에서 구독 그룹 또는 구독 설정으로 이동해 이름과 주소를 추가한 뒤 저장하세요. 메인 화면으로 돌아와 업데이트를 실행합니다. 노드가 표시되면 사용할 항목을 선택하고 연결을 시작하세요. 단일 노드 공유 링크를 복사한 경우에는 클립보드에서 가져오기 메뉴를 사용하세요. 전체 구독 URL을 단일 노드 자료로 처리하면 안 됩니다. 목록의 강조 표시, 서비스 실행 상태, 시스템 VPN 아이콘은 각각 다른 계층을 나타내므로 테스트할 때 모두 확인하세요.

처음 연결할 때 시스템 VPN 권한 대화상자가 표시되는 경우가 많습니다. 현재 사용하는 클라이언트에서 요청한 것인지 확인한 뒤 연결을 허용하세요. 이 권한은 기기에서 트래픽을 처리할 인터페이스를 만드는 것이며 구독 서버가 작동한다는 의미는 아닙니다. VPN 아이콘은 보이지만 웹페이지가 열리지 않는다면 노드, DNS, 라우팅을 계속 확인하세요. Android의 트래픽 처리 방식은 데스크톱 브라우저에 시스템 HTTP 프록시를 입력하는 것과 다릅니다. Wi-Fi 프록시 설정에 원격 노드 주소를 다시 입력할 필요가 없습니다.

앱 적용 범위 및 백그라운드 제한 확인

먼저 기본 앱 범위로 테스트한 뒤 필요에 따라 앱별 프록시를 설정하세요. '선택한 앱만 프록시 사용'과 '선택한 앱은 프록시 우회'는 의미가 정반대이므로 현재 화면의 설명을 확인해야 합니다. 앱을 추가하거나 삭제한 뒤에는 클라이언트 안내에 따라 연결을 다시 설정하세요. 브라우저는 정상인데 특정 앱만 실패한다면 해당 앱이 제외되었는지, 다른 사용자 프로필에서 실행 중인지 먼저 확인한 다음 라우팅과 프로토콜을 살펴보세요. 데스크톱에서 작동한다고 해서 휴대전화에서도 설정이 완전히 같다고 단정하지 마세요.

일반적인 사용 환경에서는 같은 사용자 프로필에서 활성 VPN 연결을 하나만 유지할 수 있는 경우가 많습니다. 다른 VPN, 로컬 VPN 방식의 필터링 도구, 기업 네트워크 도구가 현재 연결을 대체해 클라이언트가 시작된 뒤 곧 중지될 수 있습니다. 문제를 진단할 때는 트래픽 처리 도구 하나만 남기고 시스템 상태와 클라이언트 로그를 확인하세요. 관리 대상 기기에서는 조직 정책을 따르세요. 연결을 계속 유지하려고 기업 관리 기능을 임의로 끄거나 시스템 제한을 우회하지 마세요.

화면을 잠근 뒤 연결이 끊기거나 앱을 전환한 뒤 서비스가 중지되는 문제는 백그라운드 관리와 관련된 경우가 많습니다. 클라이언트가 배터리 최적화 대상인지, 백그라운드 데이터 사용이 허용되어 있는지 확인한 뒤 잠금 화면에서 다시 테스트하세요. 기기 전체 절전 기능을 한꺼번에 끄지 말고 필요한 앱만 조정하세요. 백그라운드에서 실행되더라도 네트워크가 항상 유지되는 것은 아닙니다. Wi-Fi에서 모바일 데이터로 전환하면 기존 연결을 다시 만들어야 할 수 있습니다. 복구 여부는 알림 표시만 보지 말고 실제 접속과 새 연결 기록으로 판단하세요.

네트워크 전환 및 상시 VPN 설정

핫스팟, Wi-Fi, 모바일 데이터 사이를 전환한 뒤에는 먼저 기기 자체가 인터넷에 연결되는지 확인하고 노드 연결을 살펴보세요. 웹 인증이 필요한 네트워크라면 잠시 트래픽 처리를 중지하고 로그인한 뒤 다시 연결하세요. 모바일 데이터에서만 실패하면 클라이언트와 대상 앱의 모바일 네트워크 권한을 확인하세요. 모든 네트워크에서 실패한다면 구독 유효성, 기기 시간, 매개변수를 확인해야 합니다. 문제를 특정 네트워크로 좁히면 노드를 연달아 바꾸는 것보다 원인을 찾기 쉽습니다.

상시 VPN이나 연결이 끊긴 뒤 다른 연결을 차단하는 기능을 설정하기 전에 결과를 이해하세요. 서비스 중지, 기기 재시작, 구독 만료 시 시스템이 다른 네트워크 접속까지 제한할 수 있습니다. 일반 연결이 안정된 뒤 설정하고 시스템에서 복구 메뉴를 찾을 수 있는지 확인하세요. 다른 클라이언트로 옮기기 전 기존 서비스를 중지하고 설정을 백업한 뒤 새 앱의 코어 기능을 확인하세요. 이전이 끝나면 앱 적용 범위를 다시 설정해야 합니다. 기억에 의존한 규칙이 실제로 저장되지 않았을 수 있습니다.

구독 관리: 가져오기, 업데이트 및 설정 이전

자료 유형을 구분하고 맞는 메뉴 선택

먼저 자료의 형태를 확인하세요. vmess://, vless:// 등의 프로토콜 접두사로 시작하면 일반적으로 서버 한 대에 연결하는 정보가 담긴 단일 노드 공유 링크입니다. 구독 주소는 보통 설정 목록을 가져오는 URL이고, 전체 JSON 설정에는 인바운드, 아웃바운드, DNS, 라우팅이 함께 들어갈 수 있습니다. 공유 링크 가져오기, 구독 그룹 관리, 사용자 지정 설정 메뉴를 각각 사용하세요. 파일 확장자와 URL 형태는 참고 정보일 뿐이며 최종적으로는 내용 형식을 확인해야 합니다.

단일 노드 링크는 임시 테스트나 고정 설정에 적합하며 매개변수가 바뀌면 다시 가져와야 하는 경우가 많습니다. 구독은 제공자가 관리하는 노드 목록을 관리하기에 적합하고 업데이트하면 새 내용을 가져옵니다. QR 코드는 텍스트를 전달하는 수단일 뿐이므로 스캔 후 어떤 유형의 자료인지 확인해야 합니다. 브라우저에서 열리는 링크라고 해서 반드시 클라이언트가 읽을 수 있는 구독 주소인 것은 아닙니다. 로그인 페이지, 오류 페이지, 계정 관리 페이지는 유효한 노드 목록이 아닙니다.

그룹을 만들고 업데이트 결과 확인

출처별로 별도 그룹을 만들고 이름에 용도나 기기를 표시해 여러 출처가 추적하기 어려운 목록에 섞이지 않게 하세요. 주소를 저장한 뒤 한 번 직접 업데이트하고 결과와 노드 표시 여부를 확인하세요. 클라이언트가 프록시를 통한 업데이트와 직접 업데이트를 구분한다면 현재 실제로 사용할 수 있는 경로를 선택하세요. 사용할 수 있는 노드가 없는데 작동하지 않는 프록시를 통해 업데이트하려고 하면 순환 문제가 생길 수 있습니다. 구독에 다른 작동 경로가 필요한 것을 확인한 경우에만 업데이트 방식을 바꾸세요. 버튼을 반복해서 누르지 마세요.

업데이트 후 활성 노드를 확인하세요. 클라이언트가 기존 선택을 유지하려 해도 노드가 삭제, 이름 변경, 교체되면 활성 항목이 바뀌거나 작동하지 않을 수 있습니다. 노드 이름은 표시용일 뿐 서버의 신원을 증명하지 않습니다. 이름이 같은 항목은 그룹과 연결 매개변수를 함께 확인하세요. 자동 업데이트는 수동 업데이트가 안정된 뒤 설정하고 간격을 지나치게 짧게 지정하지 마세요. 자주 새로고침해도 계정 만료, 요청 제한, 형식 비호환은 해결되지 않으며 오히려 오류를 구분하기 어려워질 수 있습니다.

목록이 비거나 항목이 누락되거나 매개변수가 호환되지 않는 문제 해결

노드가 없으면 먼저 다운로드 실패와 파싱 실패를 구분하세요. 다운로드 실패는 주소 전체가 올바른지, 네트워크 경로, 계정 상태, 시스템 시간을 확인해야 합니다. 파싱 실패는 응답 내용이 유효한 형식인지, 현재 코어가 지원하지 않는 옵션이 있는지 살펴보세요. 구독 주소에 접근 권한이 포함될 수 있으므로 공개 온라인 도구에 붙여 넣지 마세요. 문의할 때는 서버 식별 정보, 계정 매개변수, 인증 정보를 가린 오류 요약과 클라이언트 및 플랫폼 정보를 제공하세요.

일부 노드만 누락되면 프로토콜, 전송 방식, 보안 계층 조합이 지원되는지, 클라이언트에서 필터가 켜져 있는지 확인하세요. 프로토콜 이름이 같아도 확장 매개변수까지 다른 코어가 인식한다고 볼 수 없습니다. 가져오기에 성공하게 하려고 TLS, REALITY, 서비스 이름, 경로 등의 필드를 임의로 지우지 마세요. 클라이언트와 서버는 이 매개변수에 대해 일치해야 합니다. 공유 링크와 구독 주소의 차이를 확인한 뒤 원본 자료를 다시 살펴보세요.

이전 전 백업하고 업데이트 후 확인

기기를 바꾸거나 재설치하기 전에 구독 출처, 직접 추가한 노드, 라우팅 규칙, 앱 제외 설정을 각각 백업하세요. 구독을 다시 업데이트하면 출처에서 계속 제공하는 노드는 복원할 수 있지만 로컬 메모, 사용자 지정 정렬 순서, 출처에서 삭제한 항목까지 복구되지는 않을 수 있습니다. 전체 설정을 내보내도 로컬 수신 주소, 파일 경로, 가상 인터페이스, 권한이 다를 수 있어 플랫폼 간에 그대로 작동한다고 보장할 수 없습니다. 연결 정보를 먼저 복원하고 공통 규칙을 다음에 복원한 뒤 플랫폼 전용 설정을 마지막에 조정하세요.

구독에서 생성된 노드를 직접 수정하는 방식으로 계속 관리하지 마세요. 다음 업데이트에서 변경 내용이 덮어써질 수 있습니다. 수정이 꼭 필요하다면 클라이언트가 지원하는 범위에서 별도 항목으로 복제하고 변경 이유를 기록하세요. 그러면 출처를 업데이트해도 로컬 테스트 설정이 원본과 섞이지 않습니다. 수동 노드도 정기적으로 유효성을 확인하세요. 자동 업데이트에 포함되지 않는다고 서버 매개변수가 영원히 바뀌지 않는 것은 아닙니다.

복원한 뒤에는 노드 하나로 최소 테스트를 진행해 코어 시작, 앱 트래픽 처리, 도메인 접속을 확인한 다음 그룹과 규칙을 추가로 복원하세요. 구독에 표시된 메모나 만료일만으로 연결 상태를 판단할 수 없습니다. 클라이언트가 목록을 읽더라도 계정이 연결을 허용하지 않을 수 있습니다. 제공자가 형식이나 코어 요구 사항을 변경했다면 클라이언트 설정을 업데이트하기 전에 이전 안내를 확인하세요. 백업하지 않은 상태에서 그룹을 일괄 삭제하지 마세요. 문제를 해결할 때 비교할 원본이 사라집니다.

모드 및 라우팅: 트래픽 진입점과 규칙 순서 확인

트래픽 처리 모드와 라우팅 모드 구분

시스템 프록시와 TUN은 '트래픽이 어떻게 클라이언트에 들어오는가'를 결정합니다. 전역, 직접 연결, 규칙 기반 라우팅은 '들어온 트래픽을 어디로 보낼 것인가'를 결정합니다. 두 설정은 서로 다른 계층에 있습니다. 시스템 프록시를 켜도 이를 따르지 않는 앱은 직접 연결할 수 있고, TUN을 켜도 일부 트래픽은 규칙에 따라 직접 연결될 수 있습니다. 문제를 해결할 때는 먼저 앱 트래픽이 코어에 들어왔는지 확인한 다음 어떤 아웃바운드 규칙이 적용됐는지 살펴보세요. '전역'이라는 표시만 보고 앱 트래픽 처리가 제대로 되는지 확인하지 않으면 안 됩니다.

기본 규칙으로 기준 상태를 만든 뒤 변경이 필요한지 결정하세요. 전역 프록시는 라우팅 분기 문제를 잠시 배제할 때 유용하지만 서버 오류나 이름 해석 문제를 자동으로 해결하지는 않습니다. 전역 직접 연결은 로컬 네트워크를 확인하는 데 적합하지만 클라이언트의 모든 백그라운드 요청에 별도 설정이 없다는 뜻은 아닙니다. 규칙 기반 라우팅을 계속 사용하려면 기본 아웃바운드, LAN 처리, 앱 제외 설정이 각각 어디에 있는지 알아야 합니다. 인터페이스에 표시되는 명칭은 달라질 수 있으므로 실제 규칙 내용과 로그를 기준으로 작업하세요.

구체적인 규칙부터 일반 규칙 순으로 배치

일반적인 라우팅 규칙은 순서대로 적용됩니다. 앞의 규칙이 아웃바운드를 결정하면 뒤에 있는 같은 유형의 규칙이 그 결정을 다시 바꾸지 않는 경우가 많습니다. 따라서 특정 도메인, 업무용 네트워크, LAN 규칙은 더 광범위한 규칙보다 앞에 두세요. 도메인 규칙과 IP 규칙은 완전히 같은 방식으로 작동하지 않습니다. 대상 도메인이 아직 해석되지 않았거나 앱 및 트래픽 처리 방식에 따라 IP만 확인할 수 있습니다. 문제를 진단하기 전에 코어가 실제로 어떤 대상 정보를 받았는지 확인하세요. 브라우저 주소 표시줄만 보고 규칙이 적용됐다고 판단하면 안 됩니다.

아래는 규칙 순서를 설명하기 위한 Xray 라우팅 예시입니다. 예시 도메인과 하위 도메인에는 프록시를, 일반적인 사설 IP 주소에는 직접 연결을 적용합니다. 필요한 아웃바운드 태그가 포함된 설정에 합쳐야 하며 완전한 클라이언트 설정이 아닙니다. proxy와 direct는 실제 아웃바운드 태그와 일치해야 합니다. GUI 클라이언트가 설정을 자동 생성한다면 사용자 지정 규칙 화면에서 같은 논리를 설정하세요. 시작할 때마다 새로 생성되는 파일을 직접 덮어쓰지 마세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

여기서 domain:example.com은 예시 도메인과 하위 도메인에 일치하는 규칙이지 해당 문자열이 포함된 모든 주소를 의미하지 않습니다. 사설 네트워크 규칙이 특수 용도 주소와 IPv6를 모두 포함하는 것도 아닙니다. AsIs는 IP 규칙만을 위해 도메인을 강제로 조회하지 않으므로 도메인 대상은 뒤에 있는 IP 규칙에 일치하지 않을 수 있습니다. 이 예시는 두 가지 목적만 명시합니다. 나머지 트래픽은 전체 설정의 기본 동작에 따라 처리되므로 완전한 라우팅 구성으로 바로 가져오면 안 됩니다.

규칙 리소스, DNS 및 IPv6 확인

geosite 또는 geoip 분류를 사용할 때는 규칙 파일이 존재하고 현재 코어에서 지원하는 형식 및 분류 이름과 일치해야 합니다. 분류를 찾지 못하는 문제, 리소스 로드 실패, 네트워크 연결 실패는 서로 다른 문제이므로 먼저 시작 로그를 확인하세요. 출처와 분류 의미를 모르는 상태에서 규칙을 많이 추가하지 마세요. 구성을 체계적으로 정리하려면 라우팅 설정 안내를 참고한 뒤 대상 도메인에 맞춰 소수의 규칙을 추가하고 각각의 목적을 분명히 하세요.

DNS는 이름을 해석하는 방법을 결정하고 라우팅은 연결을 내보내는 방법을 결정합니다. 서로 영향을 주지만 서로 대체할 수는 없습니다. 앱이 자체 암호화 DNS를 사용하거나 먼저 IP 주소를 얻은 뒤 연결할 수 있으므로 클라이언트가 보는 정보에 따라 도메인 규칙의 동작이 달라질 수 있습니다. TUN을 켰다면 DNS 요청이 의도한 경로로 들어가는지, 원격 DNS에 필요한 연결이 사용 가능한 아웃바운드를 이용하는지 확인하세요. 모든 DNS 서버를 한꺼번에 바꾸지 말고 로그에서 어느 단계가 실패했는지 먼저 살펴보세요.

IPv6도 별도의 네트워크 경로로 확인해야 합니다. 기기에 IPv6 주소가 있다고 해서 현재 노드, 대상, 트래픽 처리 규칙이 같은 연결 방식을 모두 지원하는 것은 아닙니다. 듀얼 스택 네트워크에서 문제가 생겼을 때만 통제된 테스트로 주소 계열별 결과를 비교하세요. IPv6를 영구적으로 끄는 것을 모든 문제의 해결책으로 삼지 마세요. LAN 프린터, 파일 공유, 내부 도메인은 직접 연결이 필요할 수 있으므로 광범위한 규칙을 추가하기 전에 로컬 서비스를 확인하세요. 기존 네트워크 기능이 프록시 설정으로 중단되지 않도록 주의해야 합니다.

변경할 때마다 같은 대상으로 다시 테스트하고 어떤 규칙이나 아웃바운드가 적용되었는지 로그에서 확인하세요. 규칙이 많다고 정확도가 높아지는 것은 아닙니다. 목적을 설명할 수 없는 오래된 규칙은 먼저 백업한 뒤 정리하세요. 문제가 없는 것을 확인한 후 장기 설정으로 저장하고 기본 아웃바운드와 복구 방법을 기록하세요. 특정 앱만 시스템 프록시를 우회한다면 도메인 규칙을 더 추가하기보다 트래픽 진입 단계의 문제를 해결하는 편이 효과적입니다. 코어에 들어오지 않은 연결은 라우팅으로 처리할 수 없습니다.

설정 문제 해결: 연결 경로를 따라 단계별 확인

증상을 분류한 뒤 확인 위치 결정

재현할 수 있는 증상으로 문제를 기록하세요. 앱 실행 불가, 구독 업데이트 실패, 코어 시작 실패, 도메인 접속만 실패, 특정 앱만 실패, 화면 잠금이나 네트워크 전환 후 연결 끊김 등으로 구분할 수 있습니다. 플랫폼, 트래픽 처리 방식, 활성 노드, 마지막으로 정상 작동한 뒤 변경한 내용을 기록하세요. 이런 증상을 '작동 안 됨' 한마디로 합치면 발생 계층을 알 수 없습니다. 먼저 트래픽 처리를 끄고 기본 네트워크를 확인한 뒤 노드 하나와 앱 하나로 재현하는 것이 가장 안정적인 시작점입니다.

앱이 열리지 않으면 설치, 아키텍처, 시스템 의존성, 권한부터 확인하세요. 인터페이스는 정상이지만 코어가 실패하면 설정 파싱과 로컬 포트를 살펴보세요. 코어는 정상이지만 앱 연결 기록이 없다면 시스템 프록시, 앱 제외, TUN을 확인해야 합니다. 연결 기록은 있는데 접속에 실패한다면 대상의 이름 해석, 서버, 프로토콜 매개변수를 살펴보세요. 이 순서대로 진행하면 프로그램이 시작되지도 않았는데 라우팅을 바꾸거나 구독 만료를 시스템 권한 문제로 오해하는 일을 줄일 수 있습니다.

로그를 확인하고 필요한 전후 맥락 보존

오류가 발생한 시간을 먼저 확인하고 마지막 단어만 자르지 말고 앞뒤 몇 줄을 살펴보세요. 포트 점유는 보통 로컬 프로세스 충돌을 가리킵니다. 인증 또는 핸드셰이크 실패는 인증 정보, 시간, 전송 방식, 보안 계층 매개변수와 관련될 수 있습니다. 이름 해석 실패는 DNS 경로를 확인해야 합니다. 로그에 표시된 시간 초과는 특정 작업이 제한 시간 내에 완료되지 않았다는 뜻일 뿐 어느 쪽이 문제인지 바로 알려주지는 않습니다. 요청 대상, 사용된 아웃바운드, 기본 네트워크 상태를 함께 확인해야 원인을 좁힐 수 있습니다.

더 자세한 로그가 필요하면 클라이언트에서 제공하는 로그 수준 설정을 일시적으로 조정하세요. 아래는 서버 정보가 포함되지 않은 Xray의 유효한 로그 객체 예시이며 완전한 연결 설정이 아닙니다. GUI 클라이언트에서는 인터페이스 옵션을 우선 사용하세요. 자동 생성 파일을 직접 수정하면 재시작 후 변경 사항이 사라질 수 있습니다. info로 실행 상태를 확인하고 부족한 경우에만 더 상세한 수준을 잠시 켠 뒤 문제가 해결되면 원래대로 되돌리세요. 불필요한 접속 내용이 장기간 기록되지 않도록 주의하세요.

{
  "log": {
    "loglevel": "info"
  }
}

로그를 공유하기 전에 구독 주소, 식별 매개변수, 서버 인증 정보, 개인을 알아볼 수 있는 경로를 삭제하세요. 오류 유형, 시간 순서, 필요한 대상 유형만 남겨도 문제를 논의하는 데 충분한 경우가 많습니다. 전체 내보내기 설정을 공개 페이지에 붙여 넣거나 낯선 도구가 구독을 읽도록 하지 마세요. 일반적인 질문과 답변은 FAQ에서 확인할 수 있습니다. 추가 정보는 모든 설정 스크린샷을 공개하기보다 현재 문제가 발생한 계층과 관련된 내용으로 제한하세요.

지연 시간, 처리량, 실제 사용 가능성 구분

지연 시간 테스트는 진단을 위한 참고 자료일 뿐 연결을 보장하지 않습니다. TCP 연결 결과는 주로 포트 연결 상태를 보여주며 실제 프록시 연결 테스트에는 핸드셰이크와 테스트 대상도 영향을 줍니다. 다운로드 속도 측정은 처리량, 혼잡, 동시 연결의 영향을 받습니다. 측정값이 낮은데 웹페이지가 열리지 않아도 모순은 아닙니다. 테스트 경로와 실제 앱의 경로가 다를 수 있습니다. 같은 노드, 네트워크, 대상을 사용해 비교하고 시간과 프로토콜이 다른 결과를 한데 모아 안정성을 판단하지 마세요.

특정 대상 하나만 실패한다면 다른 대상은 정상인지 비교한 다음 해당 대상의 DNS, 프로토콜, 라우팅을 확인하세요. 모든 대상이 실패하면 활성 노드와 트래픽 진입점을 먼저 살펴보세요. 특정 앱만 실패하면 앱 설정을, 특정 네트워크에서만 실패하면 네트워크 인증, 주소 계열, 연결 제한을 우선 확인하세요. 테스트 차이는 지연 시간 테스트와 다운로드 속도 측정 안내에서 자세히 확인할 수 있습니다. 오류 로그를 읽는 대신 속도 측정을 반복하지 마세요.

설정 되돌리기 및 복구 상태 확인

복잡한 문제가 생기면 최근 변경을 반대 순서로 되돌리세요. 먼저 추가한 규칙을 끄고 기본 DNS와 트래픽 처리 모드를 복원한 다음 연결 정보를 다시 가져오는 일을 고려하세요. 되돌릴 때마다 같은 대상으로 테스트하고 결과를 기록하세요. 클라이언트를 초기화하기 전 구독, 수동 노드, 라우팅, 앱 적용 범위를 백업하세요. 재설치해도 사용자 설정이 지워지지 않거나 시스템 네트워크 설정이 복원되지 않을 수 있으므로 재설치를 첫 번째 문제 해결 방법으로 삼지 마세요.

검증을 마친 최소 설정과 복구 기록을 보관하세요. 데스크톱에서는 시스템 프록시가 해제되는지, TUN이 정상적으로 꺼지는지 확인하세요. Android에서는 백그라운드 실행, 앱 적용 범위, 상시 VPN 정책이 의도대로 작동하는지 살펴보세요. 업데이트 전에는 백업하고, 업데이트 후에는 최소 테스트를 먼저 진행한 뒤 복잡한 규칙을 복원하세요. 연결 절차를 처음부터 다시 진행하려면 빠른 시작 가이드를, 설치 항목을 확인하려면 클라이언트 다운로드 페이지를 참고하세요. 설치, 설정, 문제 해결의 범위를 명확히 구분할 수 있습니다.