V2Ray 전체 플랫폼 설치 및 설정

사전 준비: 플랫폼, 구독, 설정 단계

클라이언트·코어·서버 설정 구분하기

v2rayN, v2rayNG, v2flyNG는 설정과 실행을 위한 클라이언트입니다. 클라이언트는 서버 정보를 저장하고 코어 설정을 생성하며 로그를 표시합니다. 플랫폼에 따라 시스템 프록시나 VPN 연결 기능도 제공합니다. Xray와 V2Fly는 연결과 라우팅을 처리하는 코어 계열입니다. 클라이언트를 설치했다고 바로 사용할 수 있는 서버가 생기는 것은 아닙니다. 서버 주소, 포트, 인증 정보, 전송 방식, TLS 매개변수는 실제 서비스 제공자가 제공해야 합니다. 프로토콜 이름만으로 이런 값을 추측할 수 없으며, 인터넷에서 찾은 다른 설정의 인증 정보를 기존 주소에 임의로 합쳐서도 안 됩니다.

한 번의 연결은 앱, 로컬 연결 지점, 코어 라우팅, 원격 서버 등 여러 단계를 거칩니다. 앱이 요청을 로컬 연결 지점으로 보내지 않는다면 원격 프로토콜을 바꿔도 소용없습니다. 코어가 시작되지 않았다면 브라우저를 바꿔도 해결되지 않습니다. 먼저 이 단계 구조를 파악하고, 이후 점검할 때는 한 번에 한 단계만 바꾸세요. 기존 시스템 프록시 설정, 다른 VPN 사용 여부, 현재 네트워크 종류, 클라이언트 설정 저장 위치를 기록해 두면 테스트 후 네트워크 설정을 원래대로 되돌리기 쉽습니다.

프로세서와 설치 파일 유형 확인

클라이언트 다운로드 페이지에서 운영체제를 고른 다음 프로세서와 패키지 형식을 선택하세요. Windows의 Desktop과 WPF는 UI 유형의 차이이지 프록시 프로토콜의 차이가 아닙니다. macOS는 Apple Silicon과 Intel을 구분해야 합니다. Linux는 프로세서 아키텍처와 배포판의 패키지 형식을 함께 확인해야 하며, Android에서는 보통 arm64를 우선 선택하고 호환 여부를 확인하기 어려우면 범용 버전을 살펴보세요. 파일 확장자가 같아도 아키텍처가 다를 수 있으며, 파일을 다운로드할 수 있다고 실행할 수 있는 것은 아닙니다.

확인 가능한 구독 정보와 복구 자료 준비

구독 주소는 보통 서버 설정 목록을 반환하는 주소입니다. 관리 페이지 주소나 요금제 구매 페이지 주소와는 다릅니다. 서비스 제공자가 클라이언트에 가져오기 위한 링크라고 명시한 주소만 구독 그룹에 입력하세요. 이 문서에서는 형식 예시로 https://example.com/sub?token=xxxx를 사용하며, 실제 서비스에 연결되지 않습니다. 실제 구독 주소에는 접근 정보가 포함될 수 있습니다. 화면 캡처를 공유하거나 로그를 보내거나 도움을 요청할 때는 전체 쿼리 매개변수, 사용자 식별 정보, 서버 인증 정보를 가리세요.

본인만 접근할 수 있는 설정 백업을 준비하고 기기의 날짜, 시간, 시간대가 올바른지 확인하세요. TLS 인증서 검증은 시스템 시간에 의존하므로 시간이 크게 어긋나면 정상적으로 작동하던 설정 여러 개가 한꺼번에 실패할 수 있습니다. 첫 테스트에서는 시스템 프록시, TUN, 다른 VPN을 동시에 켜지 마세요. 연결 방식을 하나만 선택해 정상 작동을 확인한 뒤 필요한 기능을 추가하세요. 회사나 학교 기기라면 네트워크 설정 변경이 기기 관리 정책상 허용되는지도 먼저 확인하세요. 권한을 반복해서 요청하기보다 권한 부여의 출처를 확인해야 합니다.

마지막으로 테스트 대상 두 가지를 준비하세요. 하나는 원래 접속할 수 있었던 페이지로, 직접 연결이 영향을 받는지 확인하는 데 사용합니다. 다른 하나는 현재 프록시 설정을 통해 접속해야 하는 대상으로, 프록시 연결이 작동하는지 확인합니다. 단순히 “인터넷이 안 됨”이라고 기록하지 말고 테스트 대상, 시간, 연결 방식을 함께 적으세요. 첫 연결만 설정하려면 빠른 시작 가이드를 먼저 읽어도 됩니다. 이 매뉴얼은 설치, 권한, 복구 절차를 문제별로 찾아볼 수 있도록 정리했습니다.

Windows: v2rayN 설치 및 프록시 연결

Desktop 또는 WPF를 선택해 설치

Windows 다운로드 페이지에서 v2rayN Desktop 또는 클래식 WPF 버전을 선택하세요. Desktop은 크로스 플랫폼 UI를 사용하고, WPF는 기존 Windows UI 구성을 유지합니다. UI가 다르다고 서버 매개변수가 다른 프로토콜로 자동 변경되는 것은 아닙니다. 처음 설치할 때는 한 가지 버전만 선택하세요. 두 버전을 동시에 실행하면 로컬 포트를 함께 사용하려 할 수 있습니다. UI를 비교해야 한다면 실행 중인 인스턴스를 먼저 종료하고 다른 버전을 실행하세요. 각 버전의 설정 백업도 따로 보관하는 것이 좋습니다.

설치 프로그램의 안내에 따라 설치한 뒤 정상적인 앱 실행 경로에서 시작하세요. 압축을 풀어 실행하는 버전이라면 쓰기 권한이 있는 위치에 전체 압축을 푸세요. 압축 파일 미리보기에서 실행하거나 함께 제공된 파일을 빼고 본 프로그램만 복사하지 마세요. 프로그램, 사용자 설정, 로그의 위치는 설치 방식에 따라 다를 수 있으므로 클라이언트의 폴더 열기 기능으로 확인하는 것이 좋습니다. 시작할 때 런타임이 없다는 안내가 표시되면 필요한 .NET 데스크톱 런타임, 아키텍처, UI 유형을 확인하세요. 이름이 비슷한 다른 런타임으로 대체할 수는 없습니다.

구독을 가져오고 사용할 서버 선택

“구독 그룹”을 열어 새 그룹을 만든 뒤 알아보기 쉬운 이름과 구독 주소를 입력하고 저장하세요. 그런 다음 해당 그룹의 구독을 업데이트합니다. 업데이트가 완료되면 설정을 가져온 것이며, 실제로 사용할 서버를 메인 화면에서 선택해 활성 항목으로 지정해야 합니다. 구독 그룹이 여러 개라면 현재 목록이 어느 그룹에 속하는지 먼저 확인하세요. 엉뚱한 그룹에서 업데이트를 반복하지 않도록 주의해야 합니다. 공유 링크를 가져올 때는 해당 클립보드 가져오기 기능을 사용하세요. 전체 프로토콜 공유 링크를 서버 주소 입력란에 붙여 넣지 마세요.

처음 실행할 때는 기본 로컬 수신 주소를 유지하고 클라이언트에 표시되는 실제 인바운드 포트를 확인하세요. 이 문서에서는 설명을 위해 로컬 포트 10808을 사용합니다. 실제 포트와 연결 유형은 설정과 로그를 기준으로 확인해야 합니다. 포트 번호만 보고 HTTP, SOCKS, 혼합 연결 중 무엇인지 추측할 수 없습니다. 다른 기기에서도 사용해야 하는 경우가 아니라면 수신 주소를 모든 네트워크 인터페이스로 변경하지 마세요. 수신 범위를 넓히면 로컬 방화벽과 접근 권한 문제가 생길 수 있습니다.

먼저 시스템 프록시로 확인하고 필요할 때 TUN 사용

“시스템 프록시”에서 “시스템 프록시 자동 설정”을 선택한 뒤 Windows 시스템 프록시를 사용하는 브라우저로 테스트 대상에 접속하세요. “시스템 프록시 지우기”는 클라이언트가 설정한 시스템 프록시를 해제합니다. “시스템 프록시 변경 안 함”은 시작하거나 전환할 때 기존 설정을 수정하지 않는다는 뜻이지, 이전 프록시 설정을 지운다는 뜻은 아닙니다. 브라우저에서 별도의 프록시 확장 프로그램을 사용한다면 확장 프로그램의 규칙 적용을 잠시 중지하세요. 시스템 설정과 확장 프로그램 설정이 서로 덮어쓸 수 있습니다. 조직에서 관리하는 브라우저라면 프록시 설정이 조직 정책으로 잠겨 있는지도 확인하세요.

시스템 프록시를 사용하지 않는 앱의 트래픽까지 처리해야 할 때 TUN을 고려하세요. 사용 전에 다른 가상 네트워크 인터페이스 관리 도구를 종료하고 현재 네트워크 상태를 기록한 뒤, 클라이언트 안내에 따라 필요한 권한을 허용하세요. TUN은 가상 인터페이스, 라우팅, DNS와 관련되므로 연결에 실패하면 서버를 계속 바꾸기보다 먼저 검증된 시스템 프록시 방식으로 되돌리세요. 권한 상승이 필요한지는 구현과 실행 방식에 따라 다릅니다. 일반적인 구독 업데이트를 위해 클라이언트 전체를 항상 관리자 권한으로 실행할 필요는 없습니다.

자주 발생하는 문제로는 디렉터리 쓰기 권한 부족, 포트 충돌, 시작 후 트레이 아이콘만 표시되는 현상, 런타임 불일치 등이 있습니다. 먼저 작업 표시줄 알림 영역에 이미 실행 중인 인스턴스가 있는지 확인한 뒤, 로그에서 수신 실패나 권한 오류를 찾아보세요. 보안 프로그램의 차단 기록이 있다면 어떤 파일이 어디에서 왔는지 확인하세요. 보호 기능 전체를 바로 끄지 마세요. 시작 문제는 v2rayN이 열리지 않거나 실행 직후 종료될 때 점검하는 방법에서 자세히 확인할 수 있습니다. 네트워크 복구와 앱 충돌 해결은 별도로 점검해야 합니다.

macOS: 칩 선택, 설치 권한, 네트워크 설정

칩 종류에 맞는 v2rayN 설치 파일 선택

시스템 메뉴에서 “이 Mac에 관하여”를 열어 칩 또는 프로세서 정보를 확인하세요. Apple 칩이 표시되면 Apple Silicon용 패키지를, Intel 프로세서가 표시되면 Intel용 패키지를 선택한 다음 macOS 다운로드 페이지에서 v2rayN을 받으세요. 컴퓨터 외관이나 구입 연도로 아키텍처를 추측하지 마세요. 다른 아키텍처용 앱이 호환 계층에서 실행될 수 있는지를 기본 설치 기준으로 삼지 않는 것이 좋습니다. 기기에 맞는 아키텍처를 선택하면 런타임과 권한 문제를 점검할 때 불필요한 변수를 줄일 수 있습니다.

디스크 이미지 파일을 열고 설치 안내에 따라 앱을 “응용 프로그램” 폴더로 옮긴 뒤 설치된 위치에서 실행하세요. 마운트된 이미지에서 계속 실행하면 이미지를 업데이트하거나 제거할 때 경로가 달라질 수 있습니다. 앱 출처나 실행이 제한된다는 안내가 나오면 먼저 다운로드 출처와 파일 유형을 확인하세요. 그런 다음 “시스템 설정 → 개인정보 보호 및 보안”에서 해당 앱을 처리할 수 있는 항목이 있는지 살펴보세요. 이번에 확인한 앱에만 필요한 조치를 적용하고, 클라이언트를 실행하기 위해 시스템 보안 검사 기능 전체를 끄지 마세요.

설정을 가져오고 활성 연결 확인

v2rayN의 “구독 그룹”에서 이름과 구독 주소를 추가하고 저장한 다음 해당 그룹을 업데이트하세요. 구독을 가져왔는데 연결이 실패한다면 메인 화면에서 설정을 하나 선택했는지 먼저 확인하고, 해당 프로토콜과 전송 매개변수가 현재 코어에서 지원되는지 살펴보세요. “구독 업데이트 성공”이 모든 서버 연결 테스트의 성공을 의미하지는 않습니다. 이름이 비슷한 항목이 여러 개라면 소속 그룹과 서버 주소를 확인해 구분하세요. 업데이트된 항목을 오래된 수동 등록 항목으로 착각하지 않도록 주의해야 합니다.

처음 테스트할 때는 TUN을 끄고 시스템 프록시만 사용하세요. 클라이언트에서 시스템 프록시를 설정한 뒤 “시스템 설정 → 네트워크”에서 현재 연결을 선택하고 세부 정보의 프록시 항목을 확인할 수 있습니다. 유선, 무선 등 네트워크 서비스마다 설정이 따로 있을 수 있습니다. 네트워크를 바꾼 뒤 동작이 달라지면 클라이언트 버튼이 계속 켜져 있는지만 보지 말고 현재 어떤 네트워크 서비스의 설정이 적용되는지 확인하세요. 자동 프록시 구성, 수동 HTTP 프록시, SOCKS 프록시는 설정 출처를 모른 채 중복으로 유지하지 않는 것이 좋습니다.

그래픽 앱·터미널·TUN 권한 구분

일부 그래픽 앱은 시스템 프록시를 사용하지만, 앱 자체 네트워크 스택이나 별도 프록시 설정을 사용하는 경우도 있습니다. 터미널 프로그램도 그래픽 환경의 시스템 프록시를 반드시 따르는 것은 아니므로 브라우저는 되지만 터미널은 안 되는 상황이 생길 수 있습니다. 특정 명령에서 로컬 프록시를 사용하려면 해당 명령이 지원하는 연결 유형에 맞춰 별도로 설정하고, 먼저 수신 포트가 실제로 열려 있는지 확인하세요. 시작 설정 파일에 터미널 환경 변수를 영구적으로 추가하지 마세요. 클라이언트를 종료한 뒤에도 새 터미널이 이미 닫힌 로컬 연결 지점에 접속하려 할 수 있습니다.

TUN에 추가 권한, 보조 구성 요소 또는 권한 상승이 필요한지는 클라이언트 구현에 따라 달라집니다. UI 안내에 따라 필요한 권한을 허용한 뒤 로그에서 가상 인터페이스와 라우팅이 설정됐는지 확인하세요. 앱 실행 권한이 있다고 해서 네트워크 경로를 변경할 권한까지 있는 것은 아닙니다. TUN을 켠 뒤 원래 접속되던 직접 연결 페이지가 열리지 않으면 TUN을 끄고 DNS와 네트워크 서비스 순서를 확인하세요. 다른 VPN을 함께 실행해 해결하려 하지 마세요. 두 연결 관리 기능이 경로를 기기로 되돌려 보내 처음 문제를 가릴 수 있습니다.

업데이트하기 전에 앱을 종료하고 설정 백업을 저장하세요. 서로 다른 디렉터리에 새 앱과 이전 앱이 동시에 남지 않도록 주의해야 합니다. 업데이트 후 설정이 사라진 것처럼 보이면 “응용 프로그램” 폴더의 앱을 실행 중인지, 다운로드 폴더의 이전 복사본을 실행 중인지 먼저 확인한 다음 현재 사용자 설정 위치를 살펴보세요. 앱을 제거하거나 사용을 중지하기 전에는 클라이언트에서 시스템 프록시를 지우고 TUN을 끈 뒤 현재 네트워크 서비스의 프록시 항목을 확인하세요. 앱을 휴지통으로 옮기는 것만으로 기존 네트워크 설정이 모두 해제되지는 않습니다. 프로그램을 삭제하기 전에 복구 절차를 마치세요.

Linux: 패키지 형식, 데스크톱 프록시, TUN 권한

배포판·아키텍처·그래픽 세션 확인

Linux를 설치할 때는 패키지 관리 방식과 프로세서 아키텍처를 구분해야 합니다. Debian, Ubuntu 등은 일반적으로 deb 패키지를 사용하고 Fedora 등은 보통 rpm 패키지를 사용합니다. 구체적인 내용은 해당 배포판의 패키지 관리 문서를 확인하세요. Linux 다운로드 페이지에서 x64 또는 arm64를 각각 선택하세요. 시스템이 압축 파일을 인식한다고 해서 설치 패키지를 사용할 수 있는 것은 아닙니다. v2rayN은 그래픽 클라이언트이므로 데스크톱 세션이 없는 순수 터미널 서버 환경은 이 문서의 그래픽 설치 절차를 직접 적용하기 어렵습니다.

설치 전에 다음 읽기 전용 명령으로 아키텍처와 시스템 정보를 확인할 수 있습니다. x86_64는 보통 다운로드 페이지의 x64에, aarch64는 arm64에 해당합니다. 다른 아키텍처가 표시된다면 이 두 패키지를 억지로 사용하지 마세요. 시스템 정보는 배포판 계열을 파악하는 데 도움을 주지만 데스크톱 종속 항목이 모두 설치됐는지 보장하지는 않습니다. 배포판의 소프트웨어 설치 도구나 패키지 관리자로 다운로드한 패키지를 열고 종속성 안내를 확인하세요. 종속성을 강제로 무시하는 방식은 일반적인 설치 방법이 아닙니다.

uname -m
cat /etc/os-release

일반 사용자로 실행하고 구독 가져오기

설치가 끝나면 데스크톱 앱 목록에서 v2rayN을 실행하세요. 먼저 일반 사용자로 실행해 UI, 설정 저장, 로그 출력이 정상인지 확인한 뒤 권한이 필요한 네트워크 기능을 설정하세요. 디렉터리 권한 오류 하나를 피하려고 그래픽 앱 전체를 root로 실행하지 마세요. 설정 파일의 소유자가 잘못 지정되어 다음 일반 실행 때 저장하지 못할 수 있습니다. 실수로 권한을 높여 실행했다면 실제 설정 디렉터리를 찾아 소유자를 확인하세요. 홈 디렉터리 전체에 재귀적으로 권한을 넓히지 마세요.

“구독 그룹”에 주소를 입력하고 업데이트한 뒤 활성 서버를 선택하고 코어 로그에서 로컬 연결 지점이 정상적으로 수신 중인지 확인하세요. Linux는 데스크톱 환경과 네트워크 관리자 조합이 다양하므로 클라이언트의 “시스템 프록시 자동 설정”이 모든 앱에 적용되는 것은 아닙니다. 데스크톱 환경의 네트워크 프록시 설정에서 주소와 포트를 확인한 다음 해당 설정을 사용하는 앱으로 테스트하세요. 브라우저에 별도 프록시 설정이 있다면 먼저 연결 지점을 하나로 통일하세요. 데스크톱 설정을 바꿨는데 브라우저는 이전 경로를 계속 사용할 수 있습니다.

포트를 추측하지 말고 연결 유형에 맞춰 테스트

터미널 프로그램에서는 프록시를 명시적으로 지정하는 방법이 편리한 경우가 많습니다. 아래 명령은 SOCKS 연결로 확인된 로컬 포트를 테스트할 때만 사용하세요. 예시의 10808은 UI에 표시된 실제 포트로 바꿔야 합니다. socks5h는 프록시 측에서 대상 도메인을 확인한다는 뜻입니다. 일반 socks5를 사용하면 도메인 확인 위치가 달라질 수 있습니다. 명령이 응답했다는 것은 해당 요청이 이번에는 연결 지점을 통과했다는 뜻일 뿐, 데스크톱 전체나 모든 프로토콜의 트래픽이 처리된다는 의미는 아닙니다.

curl --proxy socks5h://127.0.0.1:10808 --head https://example.com

TUN은 가상 장치, 시스템 라우팅, 권한과도 관련이 있습니다. 활성화한 뒤 로그에서 인터페이스 생성 여부를 확인하고, 기본 경로와 DNS가 예상대로 바뀌는지 살펴보세요. 장치 생성 전에 오류가 났다면 구독을 바꿔도 해결되지 않습니다. 배포판에 따라 시스템 서비스, 권한 부여 방식, 클라이언트 내 기능으로 권한을 설정할 수 있으므로 현재 소프트웨어 안내를 따르세요. 출처를 알 수 없는 파일에 시스템 권한을 임의로 추가하지 말고, 네트워크 문제를 모두 방화벽 탓으로 돌려 규칙을 바로 끄지도 마세요.

절전, 네트워크 전환, 비정상 종료 후 네트워크가 끊기면 먼저 TUN을 끄고 데스크톱 프록시 설정을 복구한 뒤 네트워크 관리자가 관리하는 연결과 DNS를 확인하세요. 업데이트할 때는 설정을 백업하고 이전 프로세스를 종료해 코어 두 개가 같은 포트를 사용하지 않도록 하세요. 수동 실행이 안정적으로 작동한 뒤 자동 시작을 설정하세요. 그래픽 클라이언트 시작과 시스템 네트워크 경로 제어는 별개의 기능입니다. 터미널과 브라우저의 동작 차이는 시스템 프록시가 적용되지 않을 때 유형별로 점검하는 방법을 참고하세요.

Android: 클라이언트 설치 및 VPN 연결

v2rayNG 우선 사용, 필요하면 v2flyNG 선택

Android 다운로드 페이지에서 Xray 코어를 사용하는 v2rayNG를 먼저 확인하세요. V2Fly 코어 환경이 필요하다면 v2flyNG를 고려할 수 있습니다. 두 앱 모두 기기에 맞는 arm64 또는 범용 버전을 선택해야 합니다. 최신 주류 기기는 대개 arm64를 사용하지만 최종 선택은 기기 아키텍처와 앱 호환성을 기준으로 하세요. 범용 버전은 아키텍처 선택의 대안일 뿐, 같은 서버 설정에 다른 프로토콜 기능을 추가해 주거나 설치 실패를 항상 해결해 주는 것은 아닙니다.

다운로드한 설치 파일을 열면 시스템에서 현재 파일 관리자나 브라우저에 앱 설치 권한을 요청할 수 있습니다. 이번 설치에 실제로 사용하는 출처에만 권한을 허용하고, 설치 후 기기 설정에 따라 권한을 취소할 수 있습니다. 파싱 실패, 서명 불일치, 기존 앱 덮어쓰기 불가 메시지가 표시되면 파일 다운로드가 완료됐는지, 앱 아키텍처와 기존 앱 출처가 맞는지 먼저 확인하세요. 기존 앱을 바로 삭제하지 마세요. 복구 가능한 설정을 먼저 내보낸 뒤 설치 파일 호환성 문제인지 출처가 다른 앱 사이의 서명 충돌인지 확인하세요.

구독 추가, 그룹 업데이트, 서버 선택

앱에서 “구독 그룹 설정” 또는 구독 관리 메뉴를 열어 그룹을 추가하고 이름과 주소를 입력한 뒤 저장하세요. 메인 화면으로 돌아와 구독을 업데이트합니다. 업데이트 방식이 여러 가지라면 우선 일반적인 업데이트를 사용하세요. 기존 연결을 통해 구독을 가져와야 한다면 현재 연결이 구독 주소에 접근할 수 있는지 확인하세요. 목록이 업데이트되기 전에 버튼을 연속으로 누르지 마세요. 가장 최근 작업의 결과를 구분하기 어려워집니다. 서버 목록이 표시되면 사용할 항목을 직접 선택해야 합니다.

QR 코드와 클립보드 가져오기는 개별 공유 링크에, 구독 주소는 계속 업데이트할 설정 모음에 적합합니다. 둘을 함께 사용할 수 있지만 각 설정의 출처를 구분해 두세요. 한 번만 가져온 항목을 구독이 자동으로 관리하는 항목으로 착각할 수 있습니다. 전송 방식, TLS, 서버 이름 정보가 없다면 원래 제공받은 자료를 확인하세요. 비슷해 보이는 다른 설정을 참고해 임의로 값을 채우지 마세요. Android 앱의 클립보드나 파일 접근 권한은 시스템 제한을 받을 수도 있으므로 가져오기에 실패하면 실제로 읽힌 내용이 무엇인지 확인하세요.

시스템 VPN 안내와 앱별 적용 범위 이해

시작 버튼을 누르면 Android에서 VPN 연결 권한을 요청합니다. 이 권한은 시스템 VPN 인터페이스를 통해 선택한 트래픽을 앱이 처리하도록 허용하는 것이며, 원격 서버 연결이 성공했다는 뜻은 아닙니다. v2rayNG의 일반적인 VPN 모드는 가상 네트워크 인터페이스로 트래픽을 처리하므로 데스크톱의 “시스템 프록시” 스위치와 같은 방식으로 판단할 수 없습니다. 앱에 프록시 전용 모드도 있다면 현재 모드에서 VPN이 설정되는지 확인하세요. 로컬 수신 기능만 켜서는 다른 앱이 자동으로 해당 연결 지점을 사용하지 않습니다.

일반적으로 한 기기에서 동시에 활성화할 수 있는 VPN 연결 관리 기능은 하나뿐입니다. 다른 VPN, 업무 프로필의 네트워크 구성 요소, 일부 로컬 필터링 도구가 현재 연결과 충돌할 수 있습니다. 먼저 다른 연결 관리 기능을 끄고 다시 권한을 허용하세요. 앱별 프록시를 사용할 때는 “선택한 앱을 프록시로 연결”과 “선택한 앱은 프록시 우회”가 반대 동작임을 확인하고, 저장 후 UI 안내에 따라 연결을 다시 설정하세요. 테스트할 앱을 하나 지정해 확인하세요. 상태 표시줄 아이콘만 보고 모든 앱이 적용 범위에 있다고 판단하지 마세요.

앱이 전면에서는 정상 작동하지만 화면을 잠그면 반복해서 연결이 끊기는 경우, 시스템 배터리 설정에서 해당 앱의 백그라운드 실행 제한을 확인하고 기기 제조사가 제공하는 설정으로 필요한 백그라운드 활동을 허용하세요. “항상 켜진 VPN”이나 “VPN 미사용 연결 차단”을 설정하기 전에 연결이 끊겼을 때 어떤 동작이 발생하는지 확인해야 합니다. 후자는 클라이언트가 중지되면 네트워크를 바로 차단할 수 있습니다. 사용을 중지하기 전 앱 안에서 연결을 끄고, 시스템 VPN 설정에 지속 연결 요구가 남아 있는지도 확인하세요. 모바일 데이터와 Wi-Fi는 DNS, IPv6, 인증 조건이 다를 수 있으므로 각각 테스트해야 합니다.

구독 관리, 코어 선택, 설정 이전

구독 업데이트와 수동 설정을 분리해 관리

구독은 설정 목록을 가져오는 출처이지, 네트워크 연결 자체가 아닙니다. 업데이트할 때 클라이언트가 내용을 가져와 서버 항목으로 변환하고, 연결할 때 코어가 활성 항목의 매개변수에 따라 원격 서버에 접속합니다. 따라서 구독 주소에 접근할 수 없는 문제, 구독 내용을 파싱할 수 없는 문제, 특정 서버 연결이 시간 초과되는 문제는 각각 나눠 처리해야 합니다. 먼저 업데이트 로그에서 네트워크 응답과 파싱 결과를 확인하고, 다음으로 항목이 표시되는지 확인한 뒤 활성 연결을 테스트하세요. 구독 파싱 실패를 라우팅 규칙 수정으로 해결하려 하지 말고, 업데이트 성공을 연결 테스트 대신 사용하지도 마세요.

모든 주소를 이름이 모호한 그룹 하나에 넣기보다 출처나 용도에 따라 그룹을 만드세요. 자동 업데이트가 구독에서 생성된 서버 항목을 교체할 수 있으므로 해당 항목을 수동으로 수정하기 전에 클라이언트가 변경 내용을 유지하는지 확인해야 합니다. 장기간 고정해 둘 설정은 별도의 수동 항목으로 만들고 원래 구독 변경이 자동 반영되지 않는다는 점을 기록하세요. 제공자가 주소나 인증 정보를 바꾸면 출처 주소를 업데이트하세요. 오래된 항목으로 계속 재연결하지 마세요. 그룹을 삭제하기 전에 백업되지 않은 수동 항목이 포함되어 있는지도 확인해야 합니다.

예시와 민감 정보 안전하게 다루기

아래 주소는 일반적인 구독 형식을 보여 주기 위한 예시입니다. 실제 주소의 경로와 쿼리 매개변수는 서비스 제공자가 정하므로 예시를 보고 추측할 수 없습니다. 구독 응답은 여러 공유 링크를 인코딩한 형식일 수도 있고 클라이언트가 인식하는 다른 형식일 수도 있습니다. 브라우저에서 파일의 글자를 읽을 수 있다고 해서 현재 가져오기 기능에서 사용할 수 있는 형식인 것은 아닙니다. 코어 JSON 전체를 받았다면 클라이언트의 사용자 지정 설정 가져오기 기능을 확인하세요. JSON을 구독 주소 입력란에 붙여 넣으면 안 됩니다.

https://example.com/sub?token=xxxx

문제 화면을 공유할 때는 구독 쿼리 매개변수, 인증 식별 정보, 비밀번호, 개인 서버 정보를 가리세요. 전체 클라이언트 설정을 내보내면 구독, 수동 항목, 로컬 수신 설정, 라우팅 정보가 함께 포함될 수 있으므로 일반적인 진단 자료처럼 공개하면 안 됩니다. 도움을 요청할 때는 오류 일부, 프로토콜과 전송 유형, 플랫폼, 연결 방식, 재현 절차만으로 충분한 경우가 많습니다. 구독 주소가 유출된 것으로 의심되면 제공자의 관리 페이지에서 접근 정보를 변경하세요. 로컬 기록만 삭제해도 이미 복사된 주소는 무효화되지 않습니다.

기능 호환성을 기준으로 코어 전환

v2rayN의 코어 설정은 어떤 코어로 설정을 실행할지 선택하는 기능이지, 단순한 성능 비교 스위치가 아닙니다. Xray와 V2Fly는 생태계를 공유하지만 확장 기능, 전송 구현, 매개변수 지원은 다를 수 있습니다. 먼저 현재 서버가 요구하는 기능을 확인하고 클라이언트가 대상 코어용 설정을 생성할 수 있는지 살펴보세요. 코어가 특정 필드를 인식하지 못한다면 라우팅 모드를 바꿔도 호환성이 생기지 않습니다. 다른 코어로 전환한 뒤 실행에 성공했더라도 기존 사용자 지정 규칙이 모두 유지된다는 뜻은 아닙니다.

전환 전에 활성 서버, 라우팅, DNS 설정을 기록하세요. 전환 후에는 설정 생성과 코어 시작 로그를 확인한 다음 요청 하나를 테스트합니다. Android에서 v2rayNG 대신 v2flyNG를 사용하는 것은 앱을 바꾸는 것이지 앱 내부에서 매끄럽게 전환하는 것이 아닙니다. 구독을 다시 추가하고 VPN 권한과 백그라운드 설정을 다시 확인해야 합니다. 서버 이름이 같아도 앱 전용 데이터가 자동으로 동기화되지는 않습니다. 권한 충돌을 코어 차이로 오해하지 않도록 연결 관리 앱은 한 번에 하나만 실행하세요.

플랫폼 간 이전은 세 단계로 진행

설정을 이전할 때는 먼저 구독 또는 서버 매개변수를 옮기고, 다음으로 라우팅과 DNS를 이전한 뒤, 마지막으로 기기별 설정을 다시 구성하세요. Windows 시스템 프록시, Linux 데스크톱 세션, Android 앱별 적용 범위는 서로 그대로 옮길 수 없습니다. 로컬 포트, 설정 경로, 자동 시작 항목, TUN 권한은 기기 환경에 속하므로 백업을 무작정 덮어쓰지 마세요. 서버 목록에서 “내보내기”나 “공유”를 사용하기 전에 개별 설정을 내보내는지 그룹 전체를 내보내는지 확인하세요. 대상 기기에서는 내보내기 유형에 맞는 가져오기 기능을 사용해야 합니다.

호환되는 클라이언트 환경에서는 전체 백업을 복원할 수 있지만 플랫폼 간 이전에는 클라이언트가 지원하는 교환 형식을 우선 사용하세요. 여러 항목을 가져오기 전에 대상 기기에서 연결 하나를 테스트하세요. 구독 업데이트, 라우팅, 연결을 중지한 뒤 네트워크 복구까지 정상인지 확인한 다음 기존 기기 사용을 중단하세요. 성공 기준은 목록 개수가 비슷한지가 아닙니다. 주요 매개변수가 올바르고 활성 연결이 작동하며 트래픽 범위가 예상대로이고 변경을 취소할 복구 방법이 있어야 합니다.

시스템 프록시, TUN, 트래픽 분할 라우팅

트래픽 진입과 코어의 출구는 별개

시스템 프록시는 “앱이 요청을 로컬 프록시로 보내는가?”를 결정하고, 라우팅 규칙은 “코어가 요청을 받은 뒤 어떤 출구를 선택하는가?”를 결정합니다. 전역 라우팅을 켜도 시스템 프록시를 전혀 사용하지 않는 앱이 갑자기 클라이언트를 거치는 것은 아닙니다. TUN을 켰다고 해서 처리되는 모든 트래픽이 프록시 서버로 전송되는 것도 아닙니다. 먼저 요청이 코어에 도달하는지 확인한 다음 직접 연결, 프록시, 차단 중 어디에 해당하는지 살펴보세요. 이 차이를 이해하면 앱 연결 지점 문제를 도메인 규칙 변경으로 해결하려다 범위를 넓히는 일을 줄일 수 있습니다.

v2rayN의 “중국 본토 우회”, “전역”, “직접 연결”은 기본 제공 라우팅 정책이며 실제 동작은 현재 규칙, 출구 태그, 데이터베이스에 따라 달라집니다. 전역 정책은 프록시 연결을 짧게 확인할 때 유용하며, 평소 트래픽 분할에는 필요한 정책을 다시 설정하세요. “직접 연결”도 클라이언트가 종료됐다는 뜻은 아닙니다. 트래픽이 로컬 연결 지점을 거친 뒤 코어에서 대상에 직접 연결될 수 있습니다. 테스트할 때 시스템 프록시나 TUN 상태와 라우팅 모드를 함께 기록하세요. “켜짐” 표시 하나만으로 요청 경로를 확인할 수는 없습니다.

규칙의 필드와 순서 이해하기

아래는 호환되는 코어 설정에 넣을 수 있는 routing 예시이며, 전체 실행 설정은 아닙니다. 첫 번째 규칙은 도메인 목록으로, 두 번째 규칙은 사설 IP 목록으로 대상을 확인하고 모두 direct라는 출구를 사용합니다. 기본 설정에 이 태그가 있어야 하며 규칙이 참조하는 데이터 파일도 준비해야 합니다. 출구 정의나 데이터베이스가 없다면 이 조각만 복사해도 연결되지 않습니다. 클라이언트 라우팅 편집기는 다른 형식으로 저장할 수 있으므로 전체 설정 파일을 덮어쓰기보다 편집기에서 제공하는 필드를 사용하세요.

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

라우팅 규칙은 보통 작성된 순서대로 확인되므로 앞쪽의 광범위한 조건이 뒤쪽의 세부 예외보다 먼저 적용될 수 있습니다. 특정 도메인이나 로컬 네트워크 서비스 같은 예외는 이를 덮어쓰는 와일드카드 규칙보다 앞에 두는 것이 일반적이지만, 최종 순서는 목적에 따라 정해야 합니다. 하나의 규칙에 도메인과 IP 조건을 함께 쓴다고 해서 둘 중 하나만 일치하면 적용된다고 단정할 수 없습니다. 여러 조건의 조합을 코어가 어떻게 해석하는지 확인하세요. 일치하는 규칙이 없을 때 사용할 기본 출구는 전체 설정을 보고 확인해야 하며, 조각의 마지막 규칙만으로 추측해서는 안 됩니다.

DNS와 규칙 데이터베이스 함께 확인

geosite:cn은 데이터베이스에 포함된 도메인 분류를, geoip:private는 사설 주소 목록을 나타냅니다. 인터넷에서 실시간으로 조회하는 태그가 아니며 도메인 분류가 영구히 고정되는 것도 아닙니다. 라우팅 데이터를 업데이트한 뒤 코어가 실제로 새 파일을 불러왔는지 확인하세요. 업데이트 위치와 참조 방법은 GeoIP 및 GeoSite 규칙 파일 업데이트 방법에서 확인할 수 있습니다. 필드 순서를 이해하려면 트래픽 분할 규칙 실전 가이드를 이어서 읽어 보세요.

DNS는 도메인 확인 방식을 결정하며 IP 조건이 라우팅 판단에 사용될 수 있는지에도 영향을 줍니다. 예시의 AsIs는 라우팅 확인을 위해 모든 도메인을 IP 주소로 자동 변환하지 않습니다. 앱이 도메인만 제공하고 규칙은 IP에 의존한다면 적절한 정책을 명시하고 추가 조회에 따른 부담을 이해해야 합니다. 브라우저의 암호화 DNS, 사용자 지정 리졸버, TUN의 DNS 처리도 조회 위치를 바꿀 수 있습니다. 먼저 도메인 규칙으로 대상을 확인한 다음 IP 조건을 단계적으로 추가하세요. 모든 DNS 경로를 한꺼번에 바꾸지 마세요.

라우팅을 수정하기 전에 내보내거나 복구 가능한 사본을 저장하고 규칙은 한 번에 한 그룹만 추가하세요. 다시 불러온 뒤 로그에서 대상과 출구를 확인해야 합니다. 클라이언트 실행 중 생성된 임시 설정을 직접 수정하지 마세요. 다음에 서버를 전환할 때 덮어써질 수 있습니다. 테스트가 끝나면 임시 전역 재정의 규칙을 제거하고 규칙의 용도를 기록해 두세요. 안정적인 트래픽 분할은 출처 불명의 규칙을 쌓는 것이 아니라 진입, DNS 조회, 출구의 관계를 명확히 하는 데 달려 있습니다.

자주 발생하는 설정 문제와 단계별 복구

문제가 발생한 위치부터 순서대로 확인

문제를 점검할 때는 마지막으로 정상 작동한 단계가 무엇인지 먼저 적으세요. 앱 실행, 구독 업데이트, 코어 수신 대기, 로컬 연결 지점의 요청 수신, 원격 서버 핸드셰이크, 대상 응답 여부 순으로 확인하면 문제를 인접한 두 단계 사이로 좁힐 수 있습니다. 로그에 로컬 포트 바인딩 실패가 표시되면 먼저 포트 충돌을 해결하세요. 요청 기록이 전혀 없다면 앱의 프록시 진입 설정부터 확인해야 합니다. “연결 실패”를 하나의 오류로 보거나 클라이언트, 코어, DNS, 라우팅을 한꺼번에 바꾼 뒤 무엇이 해결했는지 추측하지 마세요.

구독 목록이 비어 있음, 코어 시작 실패, 일부 앱만 작동

구독을 업데이트한 뒤 목록이 비어 있다면 네트워크 가져오기에 실패했는지, 응답 내용을 파싱하지 못했는지 먼저 구분하세요. 주소가 관리 페이지 주소로 복사되지는 않았는지, 끝에 공백이 들어가지는 않았는지, 그룹 목록이 필터링되어 숨겨지지는 않았는지 확인하세요. 응답이 웹페이지 안내나 만료 메시지라면 빈 목록으로 연결을 시도하지 말고 실제 제공자에게 구독 문제를 문의하세요. 현재 연결을 통해서만 구독을 받을 수 있다면 사용할 수 있는 기존 설정으로 먼저 연결한 뒤 적절한 업데이트 방식을 선택하세요. 설정이 하나도 없는데 설정을 다운로드하려는 상황을 만들지 않도록 해야 합니다.

코어 시작에 실패하면 마지막의 “프로세스 종료” 메시지가 아니라 처음 나타난 구체적인 오류를 확인하세요. 수신 주소 충돌, 지원되지 않는 설정 필드, 규칙 데이터 누락, 디렉터리 권한 부족은 각각 해결 방법이 다릅니다. 포트를 바꾸기 전에 다른 클라이언트 인스턴스가 실행 중인지 확인하고, 코어를 바꾸기 전에 서버가 요구하는 기능을 확인하세요. 사용자 지정 JSON이 포함된 설정은 클라이언트가 정상적으로 생성하는 기본 설정으로 복구한 뒤 수정 사항을 하나씩 다시 추가하세요. 시작 버튼을 반복해서 누르면 시간대가 비슷한 로그만 늘어날 뿐 설정이 자동으로 고쳐지지 않습니다.

브라우저는 되지만 터미널이 안 되면 명시적 프록시 매개변수로 터미널 연결 지점을 확인하세요. 터미널은 되지만 브라우저가 안 되면 브라우저 확장 프로그램, 별도 프록시, 관리 정책을 확인합니다. 특정 앱만 실패한다면 Android 앱별 적용 범위에 포함되어 있는지 또는 자체 네트워크 스택을 사용하는지 살펴보세요. TUN 모드에서도 해당 요청이 코어에 들어왔는지 확인해야 합니다. 이론상 트래픽을 처리할 수 있다는 이유만으로 실제 증거 확인을 건너뛰면 안 됩니다. 자세한 비교는 브라우저와 터미널을 구분해 점검하는 방법을 참고하세요.

핸드셰이크·DNS 조회·간헐적 연결 끊김을 따로 점검

TLS 핸드셰이크가 실패하면 시스템 시간, 서버 이름, 전송 방식, 제공자가 요구한 매개변수를 확인하세요. 인증서 검증을 건너뛰는 것은 서버 신원을 확인하는 보호 기능을 우회하므로 일반적인 해결 방법으로 사용하지 마세요. 도메인 조회가 실패한다면 실패한 대상이 서버 도메인인지 최종 접속 대상 도메인인지 먼저 구분하세요. 두 도메인의 조회 경로가 다를 수 있습니다. 큰 요청이나 특정 네트워크에서만 실패한다면 네트워크 유형과 재현 조건을 기록하고 전송 방식, 경로 MTU, UDP 지원 여부를 확인하세요. 작은 페이지가 열린다고 모든 트래픽이 정상인 것은 아닙니다.

간헐적인 연결 끊김은 화면 잠금, 절전, 네트워크 전환, 구독 업데이트, 서버 변경 중 어떤 이벤트와 관련이 있는지 확인하세요. Android에서는 백그라운드 프로세스가 살아 있는지 확인하고, 데스크톱에서는 네트워크 복구 후 가상 인터페이스와 DNS가 다시 설정됐는지 살펴보세요. 재시작으로 복구됐다고 원인을 찾은 것은 아닙니다. 끊기기 전후의 로그 일부를 민감 정보가 보이지 않도록 처리해 보관하세요. 로그 상세 수준은 필요한 시간 동안만 높이고 문제를 확인한 뒤 평상시 설정으로 되돌리세요. 불필요하게 파일이 쌓이지 않으며 개인 접속 대상이 로그에 오래 남는 위험도 줄일 수 있습니다.

도움을 요청할 때는 플랫폼과 아키텍처, 클라이언트 이름, 현재 코어, 연결 방식, 오류 원문, 이미 확인한 절차를 제공하면 됩니다. 구독 링크, 비밀번호, 인증 식별 정보는 필요한 자료가 아닙니다. 문제가 특정 설정 하나로 좁혀졌다면 도움말 센터에서 관련 답변을 찾아보세요. 최소 설정을 다시 구성해야 한다면 사용 가이드로 돌아가세요. 최종 확인에는 정상 연결, 예상대로 작동하는 트래픽 분할, 연결을 끈 뒤 네트워크 복구까지 포함되어야 합니다. 페이지가 한 번 열렸다는 것만으로 충분하지 않습니다.