V2Ray 멀티 플랫폼
설치 및 설정 가이드

준비 사항: 운영체제, 코어, 연결 정보

클라이언트와 코어의 차이부터 확인하기

v2rayN, v2rayNG, v2flyNG는 연결 정보를 저장하고 구독을 관리하며, 라우팅을 설정하고 코어를 실행하는 그래픽 클라이언트입니다. 프로토콜을 처리하고 원격 서버에 연결해 트래픽을 전달하는 것은 코어의 역할입니다. Project V는 관련 기술 생태계의 중요한 출발점이며, V2Fly와 Xray는 서로 다른 코어 개발 계열입니다. 이름이 비슷하더라도 설정 항목, 프로토콜 확장, 리소스 파일을 임의로 서로 바꿔 쓸 수는 없습니다. 데스크톱에서는 v2rayN을 우선 고려하고, Android에서는 일반적으로 Xray를 사용하는 v2rayNG로 시작합니다. V2Fly 설정 호환성이 필요하다면 v2flyNG를 검토하세요.

설치 전 운영체제, 프로세서 아키텍처, 사용할 패키지 형식을 확인하세요. 운영체제 이름은 첫 번째 선택 기준일 뿐이며, 프로그램 실행 여부는 아키텍처에 따라 달라집니다. 설치 패키지 형식은 바로가기, 권한, 업데이트 방식에도 영향을 줍니다. 파일을 다운로드했다고 해서 내 기기에 맞는 것은 아닙니다. 데스크톱에서는 시스템의 ‘정보’ 화면에서 프로세서 정보를 확인하고, Android에서는 기기 정보에서 운영체제 버전을 확인하세요. 아키텍처를 판단하기 어렵다면 설치 파일을 여러 개 시험하기보다 기기 제조사의 사양을 먼저 확인하는 편이 좋습니다.

출처를 확인할 수 있는 설정 정보 준비

클라이언트 자체에는 사용할 수 있는 서버가 포함되어 있지 않습니다. 사용 권한이 있는 구독 링크, 단일 노드 공유 링크 또는 선택한 코어와 호환되는 설정 파일을 미리 준비해야 합니다. 가져오기 메뉴는 자료의 종류에 따라 다릅니다. 구독은 다시 요청할 수 있는 원격 주소이고, 공유 링크는 대개 하나의 연결 정보를 담으며, 전체 설정 파일에는 수신 포트·아웃바운드·라우팅 설정까지 들어 있을 수 있습니다. 먼저 제공처에 형식과 지원 클라이언트를 확인한 다음 가져오기 방식을 선택하세요. 그래야 웹페이지 주소를 구독 링크로 착각하거나 전체 JSON을 노드 링크 입력란에 붙여 넣는 일을 피할 수 있습니다.

연결 정보에는 서버 주소, 포트, 프로토콜, 해당 프로토콜의 인증 정보가 포함되어야 합니다. TLS 등 보안 계층을 사용한다면 서버 이름, 전송 방식과 관련 매개변수도 확인하세요. 필요한 항목은 프로토콜마다 다르므로 오류 안내를 없애려고 값을 임의로 채우면 안 됩니다. 기기 시간은 자동 동기화를 유지하세요. 시간이 크게 어긋나면 인증서 유효성 판단에 문제가 생길 수 있습니다. 원격 연결에 실패했을 때 원인을 클라이언트로 바로 돌리지 않도록, 먼저 로컬 게이트웨이와 일반 웹사이트에 정상적으로 접속되는지도 확인해야 합니다.

최소한의 테스트 환경 만들기

첫 연결을 확인할 때는 프록시 클라이언트 하나만 실행하고, 다른 VPN·프록시 프로그램과 트래픽을 처리할 수 있는 브라우저 확장 프로그램은 먼저 종료하세요. 기존 시스템 프록시 설정을 기록하고, 복잡한 규칙·사용자 지정 DNS·TUN은 동시에 활성화하지 마세요. 한 가지 트래픽 처리 방식으로 노드 하나가 작동하는지 확인한 뒤 설정을 하나씩 추가합니다. 한 번에 하나의 항목만 바꾸고 변경 전 화면이나 설정을 기록해 두세요. 문제가 생겼을 때 이전 상태로 되돌릴 수 있어야 원인을 쉽게 찾을 수 있습니다.

문제 해결에 필요한 기본 정보를 미리 기록해 두세요. 클라이언트 이름, 시스템 아키텍처, 사용 중인 코어, 트래픽 처리 모드, 오류가 발생한 작업 단계면 충분합니다. 전체 설정 파일을 기록할 필요는 없습니다. 기기를 교체한다면 새 기기에 필요한 정보를 다시 가져와 테스트하고, 정상 작동을 확인한 뒤 이전 기기의 자료를 정리하세요. ‘설치 성공’, ‘구독 업데이트 성공’, ‘앱 트래픽이 프록시를 통과함’은 각각 프로그램 실행, 설정 가져오기, 실제 트래픽 경로에 관한 별개의 결과입니다.

Windows: v2rayN 설치 및 프록시 설정

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

Windows 클라이언트 다운로드에서 v2rayN을 선택하세요. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하고, 클래식 WPF 버전은 Windows의 기존 인터페이스를 제공합니다. 둘 다 연결을 관리하지만 설정 배치, 실행 환경, 일부 메뉴 위치가 다를 수 있습니다. 처음 사용한다면 데스크톱 버전부터 시작해도 좋습니다. 클래식 인터페이스를 이미 사용 중이라면 필요에 따라 WPF 버전을 선택하세요. 연결 결과를 비교하려고 두 버전을 동시에 실행하지 마세요. 로컬 수신 포트, 시스템 프록시, 백그라운드 프로세스가 서로 간섭할 수 있습니다.

설치 프로그램을 실행하기 전에 해당 패키지의 시스템 요구 사항을 충족하는지 확인하세요. 설치 마법사에서 설치 위치를 선택합니다. 처음 실행할 때 실행 환경이 없다는 안내가 나오면 이름이 비슷한 다른 프로그램을 다운로드하지 말고, 안내에 따라 필요한 구성 요소를 설치한 뒤 클라이언트를 다시 실행하세요. 사용자 설정 폴더에 정상적으로 쓸 수 있어야 합니다. 권한이 제한된 위치에 프로그램을 설치하거나 여러 계정에서 번갈아 실행하면 설정이 저장되지 않을 수 있습니다. 보안 프로그램이 차단한 경우에는 안내에 표시된 파일 경로와 차단 이유를 먼저 확인하세요. 시스템 보호 기능 전체를 끄지는 마세요.

구독을 가져와 활성 서버 확인

구독 그룹 설정을 열고 출처를 알아볼 수 있는 이름을 지정한 다음, 전체 구독 주소를 주소 입력란에 넣고 저장한 뒤 구독을 업데이트하세요. 업데이트가 끝나면 알림이 사라졌는지만 보지 말고 서버 목록에 항목이 실제로 추가됐는지 확인해야 합니다. 제공받은 정보가 단일 노드 공유 링크라면 클립보드에서 가져오기 기능을 사용하세요. 이 방법으로 가져온 링크가 자동 업데이트되는 구독으로 바뀌지는 않습니다. 처음 테스트할 때는 필요한 매개변수가 모두 있는 서버 하나를 선택해 활성화하고, 현재 코어가 해당 설정과 호환되는지도 확인하세요.

업데이트에 실패했다면 먼저 클라이언트가 설정 내용을 받았는지 확인하세요. 로그인 페이지가 반환된 경우, 권한 오류, 지원하지 않는 형식, 노드 연결 시간 초과는 서로 다른 문제입니다. 현재 네트워크에서 구독 주소에 직접 연결할 수 없다면 사용 가능한 연결이 있을 때 프록시를 통해 업데이트해 볼 수 있습니다. 사용할 수 있는 연결이 없다면 업데이트 방식을 반복해서 바꾸어도 접속 경로가 생기지는 않습니다. 확인 순서는 구독 업데이트 실패 및 파싱 오류 점검 목록을 참고하세요.

먼저 시스템 프록시를 사용하고 TUN은 필요할 때 검토

처음 연결할 때는 ‘시스템 프록시 자동 설정’을 활성화하고 클라이언트 코어가 실행된 것을 확인한 다음, 시스템 프록시를 따르는 앱을 여세요. Windows의 시스템 프록시에는 보통 로컬 루프백 주소와 클라이언트 수신 포트가 설정됩니다. 원격 서버 주소가 아닙니다. 브라우저에서 접속된다고 해서 모든 데스크톱 프로그램도 시스템 프록시를 사용한다고 볼 수는 없습니다. 앱 자체에 프록시 설정이 있다면 시스템 설정을 사용하거나 해당 로컬 주소를 직접 지정하세요. 시스템 설정과 앱 설정이 서로 충돌하지 않도록 확인해야 합니다.

시스템 프록시를 따르지 않는 프로그램까지 트래픽을 처리해야 한다면, 사용 중인 v2rayN에서 TUN을 지원하는지 확인하세요. 활성화 과정에서 관리자 권한이 필요하거나 가상 네트워크 인터페이스를 만들 수 있으므로 클라이언트의 권한 안내를 읽어야 합니다. TUN을 시작한 뒤에는 네트워크 어댑터, 라우팅, DNS가 모두 설정됐는지 확인하세요. 스위치가 켜졌다는 이유만으로 작동한다고 판단해서는 안 됩니다. 원격 데스크톱, 업무용 VPN, 가상 머신 네트워크는 라우팅 변경의 영향을 받을 수 있습니다. 테스트 중에는 로컬에서 복구할 수 있는 방법을 확보하고, 일반 네트워크가 끊기면 TUN을 먼저 종료해 환경을 복구하세요.

종료, 업데이트 및 남아 있는 프록시 설정

사용을 마치면 클라이언트에서 시스템 프록시를 먼저 해제한 다음, 정상 종료 메뉴로 프로그램을 닫으세요. 프로세스가 비정상 종료되면 Windows가 중지된 로컬 포트를 계속 가리킬 수 있어 시스템 프록시를 따르는 앱이 모두 접속하지 못할 수 있습니다. 시스템 프록시 설정을 열어 이전 값으로 복구하세요. 업데이트 전에는 설정을 백업하고 기존 프로세스를 종료해 되돌릴 수 있는 상태를 남겨 두세요. 시작 시 실행되지 않는다면 같은 사용자 계정으로 실행되는지, 바로가기가 유효한지, 보안 정책이 시작을 막는지 확인하세요. 문제를 우회하려고 시작 작업을 여러 개 추가하지 마세요.

macOS: 칩에 맞는 설치 파일, 권한 및 네트워크 서비스

칩에 맞는 설치 파일 선택

시스템의 ‘이 Mac에 관하여’에서 칩 정보를 확인하세요. Apple Silicon은 arm64, Intel은 x64에 해당합니다. macOS 다운로드에서 v2rayN을 선택하세요. 프로세서 아키텍처와 운영체제 버전을 혼동하지 마세요. 같은 이름의 운영체제라도 서로 다른 칩에서 실행될 수 있습니다. 디스크 이미지 파일을 연 뒤 패키지 안내에 따라 앱을 응용 프로그램 폴더에 옮기고 해당 위치에서 실행하세요. 마운트된 이미지에서 계속 실행하면 업데이트, 권한, 바로가기 동작이 예상과 다를 수 있습니다.

처음 실행할 때 보안 안내가 표시되면 다운로드 출처, 앱 이름, 시스템 안내의 구체적인 이유를 확인한 다음 시스템의 ‘개인정보 보호 및 보안’ 설정에서 처리하세요. 보안 정책, 조직의 기기 관리 제한, 다운로드 파일 손상은 각각 다른 문제입니다. 모든 제한을 터미널 명령으로 제거해서는 안 됩니다. 관리형 업무 기기에서는 네트워크 인터페이스 생성이나 프록시 변경이 허용되지 않을 수 있습니다. 클라이언트를 반복해서 설치하기보다 먼저 권한 조건을 확인하세요.

구독 가져오기 및 기본 연결 확인

v2rayN에서 구독 그룹을 만들고 전체 주소를 붙여 넣은 뒤 저장하고 업데이트하세요. 처음 사용할 때는 서버 하나를 활성화하고 프로토콜, 서버 이름, 전송 방식이 제공처 안내와 일치하는지 확인합니다. 크로스 플랫폼 클라이언트의 메뉴 구성은 버전에 따라 달라질 수 있습니다. 같은 이름의 메뉴를 찾을 수 없다면 ‘구독 그룹’, ‘시스템 프록시’, ‘라우팅 설정’ 등의 기능을 찾아보세요. Windows의 설정 폴더나 단축키를 macOS에 그대로 적용하지 마세요. 가져오기가 끝나면 먼저 기본 연결을 확인하고 나서 다른 사용자 지정 설정을 옮기세요.

시스템 프록시를 켠 뒤 시스템 네트워크 설정을 열어 현재 사용 중인 네트워크 서비스에 프록시 주소가 입력됐는지 확인하세요. Wi-Fi, 유선 네트워크, 기타 서비스는 프록시 설정을 각각 저장할 수 있으므로 네트워크를 바꾼 뒤 다시 확인해야 합니다. 자동 프록시 구성 스크립트와 수동 HTTP·HTTPS·SOCKS 프록시는 서로 다른 항목입니다. 다른 도구를 사용한 적이 있다면 기존 설정을 먼저 기록하세요. 스크립트 주소를 남겨 둔 채 수동 프록시를 추가하면 앱마다 다른 경로를 선택할 수 있습니다.

TUN, 권한 및 잠자기 후 복구

macOS에서 TUN을 사용할 수 있는지는 현재 클라이언트 빌드, 코어 통합 방식, 시스템 권한에 따라 달라집니다. 인터페이스에 해당 기능이 있다면 안내에 따라 보조 구성 요소와 권한을 설정하고 로그에서 인터페이스 생성 결과를 확인하세요. 모든 데스크톱 버전의 권한 절차가 같다고 가정하지 마세요. 활성화한 뒤 일반 웹사이트, 프록시가 필요한 대상, 로컬 네트워크 서비스를 각각 테스트하세요. 웹은 정상인데 프린터나 공유 폴더에 접근할 수 없다면 로컬 네트워크 대역이 직접 연결 라우팅에 포함됐는지 확인하세요.

기기가 잠자기 상태에서 깨어나거나 Wi-Fi에서 유선 연결로 바뀌면 기존 연결은 끊겼는데 로컬 프록시 설정은 남아 있을 수 있습니다. 먼저 실제 네트워크가 복구됐는지 확인한 뒤 활성 서버에 다시 연결하세요. TUN 인터페이스가 복구되지 않았다면 종료한 다음 다시 활성화하고, 인터페이스 중복이나 권한 오류가 발생했는지 확인합니다. 구독을 전부 삭제하는 것부터 시작하지 마세요. 브라우저 연결, 원격 세션, 시스템 네트워크 서비스는 각기 다른 상태를 유지합니다. 앱, 클라이언트 연결, 트래픽 처리 모드를 차례로 다시 시작하면 어느 단계에서 문제가 생겼는지 파악하기 쉽습니다.

업데이트 전에 다른 기기로 옮길 자료 보관

앱을 업그레이드하기 전에 연결을 정상 종료하고 구독 그룹, 필요한 로컬 노드, 사용자 지정 규칙을 저장하세요. 프로그램을 다시 설치해도 사용자 설정이 모두 삭제되는 것은 아니며, 반대로 앱을 삭제해도 시스템 프록시가 반드시 해제되는 것은 아닙니다. 제거하거나 비활성화한 뒤 현재 네트워크 서비스에서 프록시가 복구됐는지 확인하세요. 다른 Mac으로 옮길 때는 구독과 읽을 수 있는 규칙을 우선 가져온 다음 로컬 포트, 시작 동작, 시스템 권한을 다시 설정하세요. 이 항목들은 기기 환경에 따라 달라지므로 이전 기기의 실행 폴더 전체를 새 기기에 그대로 덮어쓰는 것은 적절하지 않습니다.

Linux: 패키지, 데스크톱 프록시 및 권한 범위

배포판의 패키지 형식 확인

Linux에서 v2rayN 그래픽 클라이언트를 사용하려면 먼저 배포판이 deb 또는 rpm 중 어떤 패키지 형식을 사용하는지 확인하고, 프로세서 아키텍처도 확인하세요. Debian 계열 및 파생 배포판은 일반적으로 deb를 선택하고, RPM 패키지 관리 체계를 쓰는 배포판은 rpm을 선택합니다. x64와 arm64는 서로 바꿔 쓸 수 없습니다. 사이트의 Linux 클라이언트 다운로드에서 각 패키지를 확인할 수 있습니다. 패키지 형식이 맞더라도 오래된 시스템에서 필요한 종속성을 모두 갖췄다는 뜻은 아닙니다. 설치 프로그램의 종속성 안내를 따로 확인하고, 무시해도 호환된다고 판단하지 마세요.

다운로드한 파일은 배포판의 소프트웨어 설치 프로그램으로 여는 것이 좋습니다. 종속성 처리, 설치 위치, 제거 기록을 시스템 패키지 관리자가 관리할 수 있습니다. 터미널에서 그래픽 라이브러리가 없다는 안내가 나오면 시스템 지원 범위를 확인하고 배포판의 공식 경로로 필요한 패키지를 설치하세요. 그래픽 인터페이스를 띄우려고 클라이언트 전체를 계속 최고 권한으로 실행하지 마세요. 설정 파일 소유권이 바뀌고 구독 및 로컬 파일을 다룰 때 권한 범위가 넓어집니다. 일반 사용자로 저장한 설정과 권한을 높여 실행한 뒤 생성한 설정은 서로 다른 경로에 있을 수 있습니다.

데스크톱 세션과 앱 프록시는 서로 다른 방식

그래픽 인터페이스에서 구독을 가져오고 목록을 업데이트한 다음 활성 서버를 설정했다면, 우선 클라이언트의 로컬 수신이 정상인지 확인하세요. Linux 데스크톱 환경은 시스템 프록시를 지원하는 방식이 제각각입니다. 데스크톱 설정을 읽는 앱도 있고 환경 변수를 읽는 앱도 있으며 자체 설정만 사용하는 앱도 있습니다. 따라서 ‘시스템 프록시 설정 완료’는 클라이언트가 어떤 데스크톱 프록시 인터페이스에 값을 기록하려 했다는 뜻일 뿐입니다. 터미널, 소프트웨어 설치 프로그램, 모든 그래픽 앱이 같은 경로를 사용한다고 볼 수는 없습니다.

별도로 설정해야 하는 앱은 클라이언트에서 로컬 HTTP 또는 SOCKS 접속 주소, 포트, 지원 프로토콜을 확인한 뒤 앱 설정에 입력하세요. 환경 변수는 대개 이후에 실행되는 프로세스에만 적용되므로 이미 실행 중인 터미널이나 앱에는 반영되지 않을 수 있습니다. 원격 노드 주소를 로컬 프록시 입력란에 넣지 말고, 포트 숫자만으로 프로토콜을 추측하지 마세요. 하나의 포트에서 여러 프로토콜을 지원한다면 클라이언트에 표시된 내용을 따르세요. 별도 포트를 사용한다면 HTTP와 SOCKS에 맞는 프로토콜 항목을 각각 선택해야 합니다.

# 현재 데스크톱 세션과 코어 아키텍처 확인
printf '%s\n' "$XDG_CURRENT_DESKTOP"
uname -m

# 현재 이 기기에서 수신 대기 중인 TCP 포트 확인
ss -ltn

TUN 권한 및 DNS 문제 해결

TUN 인터페이스 생성과 라우팅 변경에는 대개 추가 권한이 필요하지만, 구체적인 권한 부여 방식은 클라이언트 빌드와 배포판 환경에 따라 다릅니다. 사용 중인 클라이언트가 안내하는 절차를 따르고, 실패하면 권한 또는 인터페이스 관련 오류를 확인하세요. 출처가 불분명한 고권한 명령을 그대로 복사해 실행하지 마세요. 방화벽, 다른 VPN, 컨테이너 네트워크, 정책 라우팅이 동시에 트래픽 경로를 바꿀 수 있습니다. 처음에는 네트워크 구성을 단순하게 유지하고 구성 요소를 하나씩 다시 활성화하면서 연결 동작이 달라진 단계를 기록하세요.

DNS는 데스크톱 네트워크 관리 서비스, 로컬 이름 해석 서비스, 다른 네트워크 도구가 관리할 수도 있습니다. TUN은 연결됐는데 도메인 접속이 실패한다면 도메인으로 접속한 결과와 이미 확인된 대상에 연결한 결과를 비교하고, 로그에서 DNS 요청과 상위 DNS 서버의 연결 가능 여부를 확인하세요. 시스템 DNS 설정 파일을 바로 덮어쓰지 마세요. 서비스가 자동 생성하는 파일일 수 있어 수동 변경 내용이 사라지거나 다른 네트워크 기능이 손상될 수 있습니다. 클라이언트 DNS 설정, 현재 네트워크 서비스, 충돌하는 프로그램을 차례로 확인해 실제 DNS 설정을 관리하는 주체를 찾아야 합니다.

시스템 트레이, 자동 실행 및 설정 저장

일부 데스크톱 환경에서는 기존 방식의 시스템 트레이 아이콘이 기본 표시되지 않습니다. 창을 닫은 뒤 아이콘이 보이지 않아도 프로세스가 종료됐다고 단정할 수 없습니다. 프로세스와 수신 포트를 먼저 확인하고 다시 실행해 포트를 두 인스턴스가 차지하지 않도록 하세요. 자동 실행은 현재 사용자 데스크톱 세션이 정상적으로 시작된 뒤에 실행해야 합니다. 너무 일찍 실행하면 프록시 인터페이스를 읽지 못할 수 있습니다. 업데이트 전 클라이언트를 종료하고 필요한 설정을 백업한 다음 설치 후 파일 소유자와 쓰기 권한을 확인하세요. 권한을 높여야만 설정을 저장할 수 있다면 일상적인 실행 권한을 높이는 대신 설정 폴더의 소유권을 바로잡으세요.

안드로이드: VPN 권한, 백그라운드 실행 및 앱별 프록시

v2rayNG와 v2flyNG 선택

안드로이드에서는 우선 Xray 코어를 사용하는 v2rayNG로 시작하는 것이 좋습니다. V2Fly 관련 호환성이 필요하다면 v2flyNG를 고려할 수 있습니다. 이름이 비슷하다는 이유만으로 두 클라이언트가 모든 프로토콜 확장을 함께 지원한다고 볼 수는 없습니다. 안드로이드 다운로드에서 아키텍처에 맞는 패키지를 선택하세요. 최신 기기 대부분은 arm64를 사용합니다. 아키텍처를 모르거나 특수한 기기라면 제조사 자료를 확인하고 필요에 따라 범용 버전을 선택하세요. 범용 버전은 아키텍처 호환 범위를 넓힐 뿐, 다른 서버나 연결 기능을 제공하는 것은 아닙니다.

설치 중 시스템에서 현재 파일 출처의 설치 권한을 요청하면 필요한 출처에만 임시로 허용하세요. 설치가 끝난 뒤에는 기존 권한 설정으로 되돌릴 수 있습니다. 기존 클라이언트를 업데이트할 때는 앱의 식별 정보와 서명이 호환되어야 합니다. 덮어쓸 수 없다는 안내가 나오면 같은 클라이언트를 다운로드했는지 먼저 확인하고 바로 삭제하지 마세요. 앱을 삭제하면 로컬 노드, 사용자 지정 설정, 앱별 목록이 지워질 수 있습니다. 재설치가 필요하다면 클라이언트에서 지원하는 내보내기 기능으로 필요한 정보를 먼저 저장하세요.

정보 가져오기 및 첫 VPN 연결

클라이언트 구독 설정에서 그룹 이름과 전체 주소를 추가하고 저장한 다음 업데이트하세요. 단일 노드라면 클립보드 또는 QR 코드 가져오기 메뉴를 사용합니다. 서버 항목이 표시되는지 확인한 뒤 활성 항목을 선택하세요. 연결을 시작하면 Android에서 VPN 권한 안내가 나타납니다. 이는 VpnService가 로컬 가상 인터페이스를 만들기 위해 필요한 시스템 권한입니다. 앱 이름이 올바른지 확인한 뒤 허용하세요. 권한을 거부했거나 다른 창 때문에 승인 절차가 중단된 경우, 또는 이미 다른 VPN이 사용 중인 경우 클라이언트가 기기 트래픽을 처리하지 못할 수 있습니다.

Android에서는 일반적으로 현재 사용자 공간에서 VPN 서비스를 하나만 활성 상태로 유지할 수 있습니다. 다른 VPN이나 로컬 VPN 기능이 있는 필터링 도구를 실행하면 현재 연결을 대체할 수 있습니다. 먼저 충돌하는 서비스를 종료하고 시스템 VPN 표시와 클라이언트 로그를 확인하세요. 시스템에 VPN 표시가 나타나는 것은 가상 인터페이스가 생성됐다는 뜻일 뿐, 원격 서버에 연결됐다는 뜻은 아닙니다. 실제 앱에서 대상에 접속해 보고 로그에 해당 요청이 기록되는지도 확인하세요. 네트워크는 정상인데 특정 앱만 실패한다면 권한을 다시 요청하기보다 앱별 규칙을 확인하세요.

백그라운드 연결 끊김 및 네트워크 전환

절전 설정에 따라 백그라운드 네트워크가 제한되거나 클라이언트 프로세스가 종료될 수 있습니다. 화면을 잠근 뒤 연결이 끊겼다가 화면을 켜면 복구되는 경우, 배터리 최적화, 백그라운드 활동 제한, 제조사의 자동 실행 관리 설정을 확인하세요. 설정 이름은 기기마다 다르므로 해당 클라이언트에 맞춰 조정하면 됩니다. 모든 앱의 설정을 바꿀 필요는 없습니다. 지속 알림은 포그라운드 서비스를 유지하는 데 필요할 수 있으며, 숨길 수 있는지와 그 영향은 운영체제 버전에 따라 다릅니다. 알림을 없애려고 연결 유지에 필요한 권한과 서비스를 끄지 마세요.

Wi-Fi와 모바일 데이터 사이를 전환하면 네트워크 경로가 바뀌어 기존 연결을 다시 만들어야 할 수 있습니다. 먼저 새 네트워크 자체가 정상인지 확인한 다음 클라이언트가 터널을 다시 연결하는지 살펴보세요. 시스템의 상시 VPN, VPN을 통하지 않는 연결 차단 옵션은 연결이 끊겼을 때의 네트워크 동작을 바꿉니다. 활성화하기 전에 결과를 이해해야 합니다. 클라이언트가 실행되지 않았을 때 모든 앱의 접속이 차단된다면 구독이 만료됐다고 단정하지 말고 이 시스템 설정을 확인해 의도적인 차단인지 오류인지 구분하세요.

앱별 규칙 및 대체 클라이언트로 이전

앱별 프록시에는 보통 ‘선택한 앱만 사용’과 ‘선택한 앱은 제외’처럼 방향이 다른 모드가 있습니다. 모드의 의미를 확인한 다음 앱을 선택하세요. 브라우저를 제외하면 노드가 정상이어도 해당 브라우저는 프록시를 통과하지 않습니다. 업무용 프로필, 앱 복제본, 별도 사용자 공간은 앱 식별 정보가 달라 기존 목록이 적용되지 않을 수 있습니다. 설정을 변경한 뒤에는 클라이언트 안내에 따라 다시 연결해 VPN의 앱 목록을 적용하세요. 자세한 내용은 VPN 권한, 배터리 최적화 예외 및 앱별 프록시를 참고하세요.

v2rayNG에서 v2flyNG로 바꿀 때는 먼저 이전 클라이언트의 VPN 연결을 종료한 다음 새 클라이언트에서 구독을 다시 가져오고 프로토콜 지원 여부를 확인하세요. 기존 앱의 내부 설정 전체를 복사해 덮어쓰지 마세요. 앱별 목록, 알림 권한, 배터리 최적화 설정은 기기별 앱 설정이므로 다시 확인해야 합니다. 기본 연결 하나가 작동하는지 확인한 뒤 복잡한 규칙을 복원하세요. 특정 프로토콜만 실패한다면 모든 노드를 동시에 수정하지 말고 코어 지원 범위와 제공처의 매개변수를 비교하세요.

구독 및 이전: 형식, 그룹 관리, 정보 보호

구독 업데이트와 노드 가져오기의 차이

구독 업데이트는 클라이언트가 주소에 요청을 보내고, 받은 내용을 서버 항목으로 파싱하는 과정입니다. 성공하려면 주소에 접속할 수 있고, 반환된 내용이 실제 설정이며, 현재 클라이언트가 해당 형식을 인식해야 합니다. 같은 도메인의 웹페이지를 열 수 있다는 사실만으로는 일부 네트워크 경로가 작동한다는 것만 알 수 있습니다. 구독 주소는 별도의 권한을 요구하거나 오류 페이지를 반환할 수 있습니다. 반대로 가져오기에 성공했다고 해서 모든 노드에 연결할 수 있는 것도 아닙니다. 클라이언트는 일반적으로 파싱 단계에서 각 원격 서버의 작동 여부까지 확인할 수 없습니다.

단일 노드 공유 링크는 대개 당시의 매개변수만 저장하므로 제공처가 나중에 주소나 포트를 바꿔도 자동으로 동기화되지 않습니다. 전체 사용자 지정 설정 파일은 적용 범위가 더 넓고 수신 연결, 송신 연결, 라우팅, DNS를 직접 정의할 수 있어 그래픽 인터페이스 설정 일부를 우회하기도 합니다. 가져오기 전에 자료 유형에 맞는 메뉴인지 확인하세요. 전체 설정 파일을 비슷해 보이는 항목으로 분해해 노드 편집 창에 수동으로 조합하지 마세요. 브라우저에 저장해 둔 구독 관리 페이지도 실제 구독 주소가 아닙니다.

https://subscription.example.net/client?token=xxxx

그룹, 업데이트 덮어쓰기 및 로컬 수정

구독 출처가 여러 개라면 각 출처를 별도 그룹으로 관리하고, 출처와 용도를 알 수 있도록 짧은 이름을 붙이세요. 먼저 한 그룹만 업데이트해 반환된 내용이 정상인지 확인한 뒤 일괄 업데이트를 고려하세요. 노드 별칭은 표시용 이름이며 안정적인 식별자가 아닐 수 있습니다. 제공처에서 이름을 바꾸거나 노드를 통합하고 순서를 조정하면 기존 활성 항목이 달라질 수 있습니다. 업데이트 후 연결에 문제가 생기면 이전 별칭만 보고 같은 서버를 선택했다고 판단하지 말고, 활성 서버가 남아 있는지와 실제 매개변수가 바뀌었는지 확인하세요.

구독 관리 목록은 다음 업데이트에서 덮어써질 수 있습니다. 노드를 수정해야 한다면 클라이언트에서 별도의 로컬 항목으로 복사할 수 있는지 먼저 확인하세요. 복사한 항목은 이후 출처의 변경 사항을 자동으로 반영하지 않습니다. 사용자 지정 규칙, 구독 노드, 임시 테스트 노드를 따로 관리해 그룹을 정리할 때 수동 설정까지 삭제하지 않도록 하세요. 일괄 필터링과 속도 테스트도 범위를 제한해야 합니다. 모든 출처에 한꺼번에 많은 테스트 요청을 보내면 불필요한 트래픽이 발생하고 로컬 대역폭과 연결 수 제한의 영향을 받을 수 있습니다.

구독 변환의 적용 범위

설정 형식이 다르다고 해서 변환으로 항상 해결되는 것은 아닙니다. 변환기는 항목 순서를 바꾸거나 다른 클라이언트 형식으로 만들 수 있지만 대상 코어에 원래 없는 프로토콜 기능을 추가하거나 누락된 인증 정보를 정확히 복원할 수는 없습니다. 변환이 꼭 필요하다면 입력·출력 형식과 대상 코어의 지원 여부부터 확인하세요. 접속 인증 정보가 포함된 구독을 잘 모르는 온라인 서비스에 맡기면 해당 서비스가 내용을 읽을 수 있습니다. 불필요한 데이터 전달을 줄이려면 자료 제공처가 제공하는 호환 형식을 우선 사용하세요.

업데이트 중 인코딩 또는 파싱 오류가 발생하면 짧은 오류 내용을 보관하고 링크에 공백, 줄바꿈, 메신저가 붙인 문자가 들어갔는지 확인하세요. 브라우저에서 쿼리 매개변수를 임의로 수정하거나 전체 응답 내용을 공개하지 마세요. 특정 그룹에서만 문제가 발생하고 다른 그룹은 정상이라면 해당 출처의 권한, 반환 형식, 프로토콜 호환성을 집중적으로 확인하세요. 여러 출처를 관리하는 방법은 구독 그룹 및 서버 필터링 활용법을 참고하세요.

플랫폼 간 이전은 자동 동기화가 아닙니다

플랫폼 간 이전은 주로 구독을 다시 가져오고, 필요한 로컬 연결을 내보내고, 호환되는 규칙을 옮기는 작업입니다. 클라이언트끼리 기본 클라우드 동기화를 제공한다는 뜻은 아닙니다. 데스크톱의 수신 주소, 창 설정, 권한 구성 요소, 시스템 프록시 상태를 Android에 그대로 옮겨서는 안 됩니다. 백업하기 전에 클라이언트를 정상 종료해 아직 기록 중인 파일이 복사되지 않도록 하세요. 복원한 뒤에는 기본 노드부터 확인하고 라우팅을 하나씩 복구합니다. 이전 기기를 더 이상 사용하지 않을 때는 필요 없는 자료를 정리하세요. 구독 정보가 유출된 것으로 의심된다면 출처에서 접속 정보를 폐기하거나 교체해야 합니다. 로컬 기록만 삭제해도 기존 링크가 무효화되지는 않습니다.

프록시 및 라우팅: 수신 경로, 송신 경로, DNS

먼저 트래픽이 코어에 들어왔는지 확인하기

한 번의 접속은 앱에서 요청 생성, 로컬 수신 지점에서 요청 수신, 라우팅에 따라 송신 경로 선택, 코어에서 원격 연결 수립의 단계로 나눌 수 있습니다. 시스템 프록시와 TUN은 트래픽을 클라이언트로 전달하는 방식을 정하고, 라우팅 규칙은 전달된 트래픽을 처리하는 방법을 정합니다. 앱이 시스템 프록시를 전혀 읽지 않는다면 원격 라우팅을 바꿔도 접속 경로는 달라지지 않습니다. 문제를 해결할 때는 먼저 로그에 해당 앱의 요청이 나타나는지 확인한 뒤, 직접 연결과 프록시 중 어느 쪽으로 분류됐는지 살펴보세요. 모든 모드를 반복해서 바꾸는 것보다 원인을 더 명확히 알 수 있습니다.

시스템 프록시는 시스템 설정을 따르는 앱에 적합하며, 로컬 HTTP 또는 SOCKS 연결은 별도 프록시 설정을 지원하는 프로그램에서도 사용할 수 있습니다. 수신 주소는 보통 로컬 루프백 주소로 유지해 기기 내부에서만 접속할 수 있게 하세요. 외부 접속을 허용하면 같은 로컬 네트워크의 다른 기기가 연결할 수 있고 인증 및 방화벽 설정도 필요합니다. 일반적인 연결 문제를 해결하는 방법으로 수신 주소를 외부에 공개해서는 안 됩니다. 포트 번호가 ‘더 빠른’ 것은 아닙니다. 사용 중인 다른 포트가 없는지, 프로토콜이 맞는지, 시스템과 앱에 입력한 포트가 실제 수신 포트와 일치하는지가 중요합니다.

규칙 순서와 송신 경로 이름

코어는 대개 규칙 순서대로 일치 여부를 확인하며, 먼저 일치한 규칙이 처리 결과를 결정합니다. 범위가 넓은 규칙을 앞에 두면 뒤의 세부 규칙이 적용되지 않을 수 있습니다. 직접 연결, 프록시, 차단 등의 송신 경로가 설정에 실제로 존재해야 하며 규칙에서 참조하는 태그도 정확히 일치해야 합니다. 클라이언트에 내장된 ‘중국 본토 우회’ 등의 기본 설정은 현재 규칙 구현과 리소스 파일에 따라 동작하며, 모든 상황을 보장하지는 않습니다. 로컬 네트워크, 업무용 네트워크, 특정 도메인은 실제 환경에서 별도로 확인해야 합니다.

아래는 구조 설명을 위한 Xray 라우팅 예시이며, 단독으로 실행할 수 있는 설정은 아닙니다. direct 태그가 붙은 송신 경로가 이미 있고 참조된 규칙 리소스를 읽을 수 있다고 가정합니다. 사설 주소 트래픽은 직접 연결로 보내고, 나머지는 이후 규칙과 기본 송신 경로에서 처리합니다. 그래픽 클라이언트는 시작 시 설정을 다시 생성할 수 있으므로 생성된 파일을 직접 수정해도 변경 사항이 유지되지 않을 수 있습니다. 클라이언트가 지원하는 규칙 편집 메뉴를 우선 사용하세요.

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

DNS와 라우팅을 함께 살펴보기

DNS는 도메인을 주소로 변환하고, 라우팅은 요청이 어떤 송신 경로를 사용할지 결정합니다. 두 기능은 서로 영향을 줍니다. 앱이 먼저 시스템에서 주소를 확인하면 코어에는 대상 주소만 전달될 수 있습니다. 요청에 도메인 정보가 포함되면 코어가 도메인 규칙을 적용할 수 있습니다. 수신 방식, 스니핑 설정, DNS 정책에 따라 코어에서 확인할 수 있는 정보가 달라지므로 같은 대상도 앱마다 다른 경로를 사용할 수 있습니다. ‘도메인 규칙을 추가했다’는 이유만으로 모든 접속에 규칙이 적용된다고 단정하지 말고 수신 방식과 로그를 함께 확인하세요.

도메인 접속만 실패하고 다른 연결은 정상이라면 실제 사용 중인 DNS 서버, 상위 DNS 서버의 연결 가능 여부, DNS 요청이 작동하는 송신 경로로 전달되는지 확인하세요. 여러 DNS 서버를 동시에 바꾸고 스니핑을 켜고 모든 규칙을 수정하지 마세요. 한 번에 한 항목씩 변경하고 오류가 DNS 조회 실패에서 연결 시간 초과로 바뀌는지, 아니면 정상으로 복구되는지 확인합니다. TUN을 활성화한 뒤에는 클라이언트 설계에 따라 DNS도 처리되는지 확인해야 합니다. 시스템에 남아 있는 DNS 설정이 새 경로와 맞지 않을 수 있습니다. 업무 네트워크의 내부 도메인에서는 관련 DNS와 직접 연결 조건을 유지해야 합니다.

TUN과 실제 접속 가능 여부 확인

TUN은 더 넓은 범위의 트래픽을 처리하지만 시스템 권한, 라우팅 제외 항목, DNS, 코어 기능의 제한을 받습니다. 모든 UDP 환경이 반드시 작동하는 것도 아닙니다. 프록시가 필요한 대상, 직접 연결해야 하는 로컬 네트워크 리소스, 자주 쓰는 앱을 각각 테스트해 연결 루프가 없는지 확인하세요. 노드 목록의 낮은 지연 시간은 특정 테스트 경로의 결과일 뿐 실제 다운로드 속도나 앱 사용 경험과 같지 않습니다. Ping, 실제 연결 지연 시간, 속도 테스트 결과의 차이를 읽고 숫자 하나만 근거로 전체 네트워크 정책을 바꾸지 마세요.

설정 관련 자주 묻는 질문: 증상에서 문제 발생 계층 찾기

정해진 순서대로 확인 자료 수집하기

연결할 수 없다면 먼저 어느 단계에서 문제가 발생하는지 구분하세요. 프로그램이 열리지 않는지, 구독 업데이트가 실패하는지, 코어가 실행되지 않는지, 앱 접속이 실패하는지에 따라 해결 방법이 다릅니다. 먼저 일반 네트워크가 작동하는지, 그다음 클라이언트의 활성 항목과 트래픽 처리 방식이 올바른지 확인하고 로그에서 처음 나타난 오류를 살펴보세요. 재시도 뒤 마지막 줄만 캡처하지 마세요. 그 오류는 앞서 발생한 문제의 연쇄 결과일 수 있습니다. 작업 시간, 대상 유형, 변경한 설정을 기록하면 해당 요청을 로그와 연결하기 쉽습니다.

프로그램은 실행되지만 코어가 종료된다면 설정 문법, 항목 호환성, 로컬 포트 사용 여부, 리소스 읽기 오류를 확인하세요. 코어는 정상인데 앱 요청이 로그에 나타나지 않는다면 시스템 프록시, 앱 자체 설정, 앱별 목록을 확인합니다. 요청은 기록되지만 원격 연결이 시간 초과된다면 서버 주소와 포트, 네트워크 경로, 서버 상태를 비교하세요. 전체 점검 순서는 노드 시간 초과 및 연결 실패 문제 해결을 참고하세요. 먼저 원인 범위를 좁힌 다음 어느 계층을 수정할지 결정하세요.

인증서, 포트, 권한 오류는 각각 따로 해결

인증서 오류가 발생하면 기기 시간, 서버 이름, 설정의 보안 계층 요구 사항을 확인한 뒤 구독이 최신 상태인지 살펴보세요. 불일치를 감추려고 인증서 검증을 계속 건너뛰지 마세요. 연결의 보안 수준이 달라집니다. 포트 사용 중 오류는 로컬에서 확인해야 합니다. 다른 클라이언트나 중복 프로세스를 종료하고 포트를 사용하는 프로그램을 확인한 다음 필요한 경우 수신 포트를 변경하고 해당 포트를 사용하는 앱도 함께 수정하세요. 권한 오류는 설정 폴더, 인터페이스 생성, 시스템 정책과 관련된 경우가 많습니다. 무조건 더 높은 권한으로 실행하지 말고 문제가 되는 항목을 찾아야 합니다.

문제를 최소한으로 재현하고 업데이트 되돌리기

복잡한 문제는 재현 환경을 최소화하세요. 확인된 설정 출처 하나, 활성 노드 하나, 트래픽 처리 방식 하나, 테스트 앱 하나만 남깁니다. 사용자 지정 규칙은 백업한 뒤 잠시 영향을 제외하세요. 최소 환경에서 정상 작동한다면 DNS, 규칙, 다른 앱 설정을 하나씩 복구해 문제가 다시 나타나는 단계를 찾습니다. 업데이트 전후 동작이 달라졌다면 설정 이전 방식, 코어 선택, 규칙 리소스에 변화가 있었는지 확인하세요. 이전 설정을 보관하고 증상을 기록해 두면 설치를 반복해서 덮어써 되돌릴 수 없게 되는 일을 막을 수 있습니다.

도움을 요청할 때는 운영체제, 클라이언트, 코어, 트래픽 처리 모드와 민감한 내용을 가린 오류 요약만 제공하세요. 구독 전체 내용, 노드 인증 정보, 설정 폴더 전체를 공개하지 말고 한 번의 테스트 결과를 일반적인 사실로 확대 해석하지도 마세요. 연결이 복구되면 처리 내용을 간단히 기록하고, 문제 해결을 위해 임시로 완화한 수신 주소·권한·보안 설정을 원래대로 되돌리세요. 처음부터 다시 시작하려면 빠른 시작 안내를 따르세요. 플랫폼이나 패키지를 바꿔야 한다면 클라이언트 페이지에서 해당 항목을 선택하세요.