V2Ray 사용 가이드

핵심 개념과 연결 경로

클라이언트·코어·서버의 역할

V2Ray는 프록시 기술 생태계에서 널리 쓰이는 이름이지, 특정 설치 패키지 하나를 뜻하지는 않습니다. v2rayN, v2rayNG, v2flyNG는 노드 저장, 구독 관리, 실행 모드 선택, 설정 생성 등을 담당하는 그래픽 클라이언트입니다. 실제 연결 처리는 코어가 담당합니다. 서버는 원격지에서 약속된 프로토콜에 맞는 요청을 받습니다. 클라이언트를 설치하는 것만으로 연결 가능한 서버가 생기거나 사용할 수 있는 구독이 자동으로 만들어지지는 않습니다.

Project V는 관련 기술의 기초 배경을 제공하고, V2Fly는 V2Ray 코어 생태계를 이어갑니다. Xray는 별도의 관련 코어 구현입니다. 코어마다 지원하는 프로토콜, 전송 방식, 설정 매개변수가 다를 수 있으므로 노드 이름만으로 호환 여부를 판단하면 안 됩니다. 노드에 표시된 프로토콜뿐 아니라 전송 방식, 보안 계층, 추가 매개변수도 확인하세요. 그래픽 인터페이스에서 특정 항목을 저장할 수 있더라도 현재 선택한 코어가 해당 조합을 지원한다는 뜻은 아닙니다.

접속 과정을 네 단계로 나눠 보기

접속 흐름은 ‘애플리케이션, 로컬 진입점, 라우팅 판단, 원격 아웃바운드’ 순서로 살펴볼 수 있습니다. 브라우저가 먼저 요청을 프록시에 전달할지 결정합니다. 클라이언트는 로컬 수신 포트나 가상 네트워크 인터페이스로 트래픽을 받습니다. 라우팅 규칙은 이후 직접 연결, 프록시, 차단 중 어떤 경로를 사용할지 결정합니다. 마지막으로 프록시 아웃바운드가 원격 서버에 연결합니다. 어느 한 단계라도 연결되지 않으면 웹페이지가 열리지 않을 수 있지만, 원인에 따라 해결 방법은 다릅니다.

예를 들어 브라우저는 정상인데 다른 앱만 연결에 실패한다면, 먼저 해당 앱이 시스템 프록시를 따르는지 확인하세요. 바로 노드를 바꿀 필요는 없습니다. 클라이언트 로그에 해당 요청이 전혀 없다면 트래픽이 로컬 진입점까지 도달하지 않았을 가능성이 큽니다. 요청은 로그에 있지만 원격 핸드셰이크가 실패한다면 서버 주소, 포트, 보안 매개변수를 확인하세요. 연결은 되지만 도메인 이름 해석에서 오류가 난다면 DNS를 따로 살펴봐야 합니다. 모든 문제를 회선 품질 탓으로 돌리면 안 됩니다.

프로토콜·전송 방식·보안 계층 구분하기

VMess, VLESS 등의 이름은 프록시 프로토콜을 가리킵니다. TCP와 WebSocket 등은 전송 방식을, TLS와 REALITY는 보안 전송 관련 메커니즘을 가리킵니다. 이들은 같은 수준에서 서로 대체하는 선택지가 아닙니다. 가져올 때는 전체 매개변수를 일치시켜야 합니다. 프로토콜을 올바르게 선택해도 경로, 서버 이름, 공개 키가 틀리면 연결되지 않습니다. REALITY의 공개 키와 짧은 ID는 구독 비밀번호가 아닙니다. 다른 노드의 값을 가져다 쓰거나 클라이언트 안내만 보고 임의로 추측하지 마세요.

노드 주소는 도메인 이름일 수도 있고 숫자 주소일 수도 있습니다. 연결에 사용하는 주소와 보안 핸드셰이크에 사용하는 서버 이름은 서로 다를 수 있습니다. 포트는 원격 서비스가 요청을 받는 위치를 뜻하며, 로컬 포트는 기기에서 클라이언트가 요청을 받는 진입점입니다. 둘을 바꿔 쓰면 안 됩니다. 안내에 나오는 로컬 루프백 주소는 현재 기기만 가리키므로 다른 기기에 입력해도 원래 클라이언트로 연결되지 않습니다. 로컬 네트워크에서 공유하려면 수신 범위, 방화벽, 접근 제어도 별도로 설정해야 합니다.

이 가이드의 각 단계에는 확인 지점이 있습니다. 설치 단계에서는 코어가 시작되는지, 구독 단계에서는 노드 정보가 온전한지, 프록시 단계에서는 요청이 로그에 나타나는지, 라우팅 단계에서는 예상한 아웃바운드를 사용하는지 확인하세요. 결과를 순서대로 기록하면 여러 설정을 연달아 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다. 익숙하지 않은 용어는 용어집에서 확인한 뒤 해당 단계로 돌아와 설정을 이어가세요.

플랫폼과 코어에 맞는 클라이언트 선택

데스크톱에서는 v2rayN을 우선 고려

Windows, macOS, Linux 데스크톱에서는 v2rayN부터 살펴보세요. 먼저 운영체제를 확인하고, 다음으로 프로세서 아키텍처를 확인한 뒤 설치 패키지 형식을 선택합니다. 아키텍처는 프로그램이 기기에서 실행될 수 있는지를 결정하고, 패키지 형식은 설치 방법을 결정합니다. 두 가지는 별개의 조건입니다. 다운로드 페이지에 플랫폼별 다운로드 항목이 있으니 기기 외관이나 구매 시기를 보고 추측하지 말고 시스템 정보를 기준으로 선택하세요. 압축 파일 이름에 플랫폼이 표시되어 있다고 해서 모든 환경에서 쓸 수 있는 것은 아닙니다.

Windows 버전은 Desktop과 WPF 두 가지로 제공됩니다. Desktop은 최신 크로스 플랫폼 UI를 사용하고, WPF는 기존 Windows UI를 유지합니다. 설정 위치, 실행 환경, 기능 표시 방식에 차이가 있을 수 있지만 노드 매개변수는 서버 설정과 일치해야 합니다. 처음 설치한다면 다운로드 페이지의 안내에 따라 한 가지 버전을 선택해 연결을 완료하세요. 클라이언트 두 개를 동시에 실행하면 포트가 충돌하거나 시스템 프록시 설정이 반복해서 덮어써질 수 있습니다.

Android는 필요한 프로토콜을 확인한 뒤 패키지 아키텍처를 선택하세요

Android에는 Xray 코어를 사용하는 v2rayNG를 우선 추천합니다. V2Fly 기반을 원한다면 v2flyNG를 고려할 수 있습니다. 이름이 비슷하다고 두 클라이언트의 기능이 완전히 같다고 볼 수는 없습니다. 특정 보안 전송 매개변수가 포함된 노드는 사용할 클라이언트와 코어가 이를 지원하는지 먼저 확인하세요. 사용할 수 있는 구독이 있다면 노드 이름의 약어만 보고 판단하기보다 제공자가 안내한 프로토콜 설명을 확인하는 편이 정확합니다. 필요한 항목이 없다면 출처에 문의하고, 매개변수를 임의로 조합하지 마세요.

다운로드 페이지에서 arm64와 범용 패키지를 제공합니다. 최근 출시된 일반적인 기기는 대체로 arm64를 사용하지만, 구형 기기나 특수 기기, 에뮬레이션 환경에서는 실제 아키텍처를 확인해야 합니다. 아키텍처가 불분명하거나 여러 기기를 지원해야 한다면 범용 패키지를 사용할 수 있지만, 보통 파일 크기가 더 큽니다. 시스템에서 설치할 수 없다고 표시되면 설치 버튼을 반복해서 누르지 마세요. 시스템 호환성, 기기에 맞는 패키지인지, 기존 앱과 서명 또는 설치 출처가 충돌하는지 확인하세요.

매개변수 호환성을 먼저 확인한 뒤 코어를 선택하세요

코어를 바꾼다고 항상 속도가 빨라지는 것은 아닙니다. 노드 연결 실패는 매개변수 누락, 구독 파싱 문제, 네트워크 연결 불가 등으로도 발생하므로 코어를 바꿔도 해결되지 않을 수 있습니다. 코어를 바꿔야 한다면 먼저 노드 프로토콜, 전송 방식, 보안 계층, 오류 내용을 기록하고 새 코어의 지원 범위를 확인하세요. 클라이언트에 따라 노드별로 코어를 지정할 수 있거나 코어가 고정되어 있을 수 있습니다. 실제 설정을 확인하고 다른 플랫폼의 메뉴 경로를 그대로 따라 하지 마세요.

macOS에서는 ‘이 Mac에 관하여’에서 칩 종류를 확인한 뒤 Apple Silicon 또는 Intel용 다운로드 항목을 선택하세요. Linux에서는 배포판의 패키지 체계와 아키텍처를 함께 확인해야 하며, deb와 rpm은 같은 파일의 다른 이름이 아닙니다. 데스크톱 환경, 권한 관리, 시스템 프록시 구현도 사용 방법에 영향을 줍니다. 다운로드를 마쳤다고 데스크톱 앱이 자동으로 프록시를 따르는 것은 아니므로 이후 모드 확인 단계에서 계속 점검하세요.

클라이언트를 선택한 뒤에는 주로 사용할 클라이언트 하나를 정해 학습하고 데이터 저장 위치, 현재 실행 방식, 종료 동작을 기록해 두는 편이 좋습니다. 다른 클라이언트로 옮겨야 한다면 기존 설정을 먼저 백업한 뒤 구독, 라우팅, DNS를 하나씩 확인하세요. 노드만 복사하고 설정도 모두 옮겨졌다고 가정하면 안 됩니다. 자세한 차이는 클라이언트 비교에서 확인할 수 있습니다. 실제 설치 파일은 다운로드 페이지에서 제공하며, 이 페이지에서는 설치 패키지를 직접 배포하지 않습니다.

설치 및 첫 실행 확인

데스크톱 설치는 디렉터리와 권한부터 확인

Windows 설치 프로그램을 사용하는 경우 안내에 따라 설치를 완료하세요. 압축 배포 패키지를 사용하는 경우에는 고정된 폴더에 압축을 완전히 푼 다음 주 프로그램을 실행해야 합니다. 압축 파일 미리보기 창에서 바로 실행하거나 실행 파일만 따로 꺼내지 마세요. 코어와 관련 리소스가 압축 파일 안에 남아 있을 수 있습니다. 관리하기 쉽고 현재 사용자가 쓸 수 있는 폴더를 선택하고, 자주 기록되는 설정을 엄격하게 보호되는 경로에 두지 마세요. 권한 안내가 나오면 먼저 어떤 작업을 수행하는 중인지 확인하세요.

첫 실행에서 실행 환경이 없다는 안내가 나오면 UI 의존성 문제와 코어 시작 실패를 구분하세요. WPF와 Desktop은 필요한 환경이 다를 수 있으므로 현재 배포 안내와 시스템 메시지를 확인해야 합니다. 출처를 알 수 없는 팝업에서 복구 도구를 설치하지 말고, 모든 실행 실패를 런타임 누락 탓으로 돌리지 마세요. UI는 열리지만 코어가 종료된다면 로그에서 원인을 확인하세요. 흔한 원인으로는 파일 누락, 설정 파싱 실패, 포트 충돌, 시스템 제한이 있습니다.

macOS 및 Linux 설치 시 확인할 점

macOS에서는 칩에 맞는 디스크 이미지를 선택한 뒤 안내에 따라 앱을 응용 프로그램 폴더로 옮기고 정식 위치에서 실행하세요. 시스템 보안 확인은 시스템 설정의 안내된 메뉴에서 처리하세요. 클라이언트 하나를 실행하려고 보안 기능을 전역으로 끄는 것은 권장하지 않습니다. 앱을 열 수 없다는 메시지가 표시되면 파일이 기기에 맞는지, 설치가 완료됐는지, 시스템이 구체적으로 어떤 이유를 표시하는지 먼저 확인하세요. 모든 검사를 우회하는 터미널 명령을 바로 사용하면 안 됩니다.

Linux에서는 배포판에 맞는 deb 또는 rpm 패키지를 선택하고 시스템 패키지 관리 도구로 의존성을 처리하세요. 설치 프로그램에서 의존성 충돌이 보고되면 다른 배포판의 라이브러리 파일을 복사하지 말고 패키지 상태부터 해결해야 합니다. 일반 프록시 모드에서는 그래픽 클라이언트를 계속 높은 권한으로 실행할 필요가 없습니다. 가상 인터페이스나 라우팅을 변경하는 경우에만 추가 권한이 필요할 수 있습니다. 필요한 권한의 범위와 방식은 배포 패키지에 따라 다르므로 현재 클라이언트의 안내를 우선 따르세요.

Android 설치 및 첫 권한 승인

Android에 설치하기 전에 패키지 아키텍처를 확인하세요. 시스템에서 현재 출처의 앱 설치를 허용해야 한다면 실제로 사용할 설치 출처에만 권한을 부여하세요. 같은 이름의 앱이 이미 설치되어 있어 덮어쓸 수 없다면 서명이 다르거나 다운그레이드가 제한된 경우일 수 있습니다. 앱을 삭제하면 앱 데이터도 사라지므로 설정을 내보낼 수 있는지 먼저 확인하세요. 처음 연결을 켤 때 시스템에서 VPN 연결을 요청합니다. 이는 클라이언트가 트래픽을 처리하는 데 필요한 시스템 권한이며, 원격 핸드셰이크가 완료됐거나 노드를 사용할 수 있다는 뜻은 아닙니다.

기기에서 VPN 인터페이스를 사용하는 다른 앱이 실행 중이면 보통 기존 연결을 먼저 중지한 뒤 현재 클라이언트를 시작해야 합니다. 배터리 관리가 백그라운드 실행을 방해할 수 있지만, 처음 설치할 때 모든 권한을 한꺼번에 허용할 필요는 없습니다. 먼저 앱이 열린 상태에서 연결을 시험하고 실제로 연결이 끊기는 경우에만 백그라운드 활동과 배터리 제한을 조정하세요. 시스템 알림, VPN 표시, 클라이언트 상태로 프로세스가 실행 중인지 확인할 수 있지만, 최종적으로는 요청 테스트와 로그도 함께 살펴봐야 합니다.

설치 후에는 UI가 정상적으로 열리는지 확인하고 코어가 시작됐는지 살펴보세요. 다음으로 로컬 수신 주소와 포트를 기록한 뒤 다른 클라이언트가 같은 포트를 사용 중인지 확인합니다. 노드가 없어도 이 단계에서 로컬 상태를 확인할 수 있습니다. 포트를 변경했다면 앱의 수동 프록시 설정도 함께 바꾸세요. 그렇지 않으면 앱이 이전 포트에 계속 연결합니다. 포트 번호는 현재 클라이언트 화면에 표시된 값을 기준으로 하며, 다른 가이드의 숫자를 고정값으로 간주하지 마세요.

마지막으로 종료 동작을 확인하세요. 일부 데스크톱 클라이언트는 창을 닫아도 시스템 트레이에 계속 실행되며, 완전히 종료하려면 트레이 메뉴를 사용해야 합니다. 종료할 때 시스템 프록시를 지우는 설정이 있는 경우도 있습니다. 처음 설정할 때 실제로 종료한 다음 다시 열어 프록시가 정상적으로 복구되는지 확인하세요. Windows 배포 버전에 관한 자세한 내용은 WPF 및 Desktop 설치 가이드를 참고하세요. 설치가 안정화되기 전에 라우팅과 TUN 설정을 더하지 마세요.

구독 가져오기·갱신 및 매개변수 확인

구독 주소와 단일 노드 링크 구분하기

구독 주소는 여러 노드를 가져올 때 사용합니다. 보통 구독 그룹에 주소를 저장한 다음 갱신해야 합니다. 단일 노드 링크는 하나의 연결 정보를 담고 있으며 클립보드나 QR 코드로 가져올 수 있습니다. 두 종류는 입력하는 위치가 다릅니다. 구독 주소를 단일 노드 매개변수 입력란에 붙여 넣거나 노드 링크를 구독 소스로 사용하면 목록이 비거나 파싱에 실패할 수 있습니다. 가져오기 전에 제공자가 안내한 사용법을 읽고 형식과 현재 클라이언트의 지원 여부를 확인하세요.

v2rayN에서는 구독 그룹 관리로 이동해 그룹을 추가하고 알아보기 쉬운 설명과 구독 주소를 입력한 다음 저장 후 갱신하세요. v2rayNG와 v2flyNG에서는 사이드바의 구독 그룹 설정에서 해당 관리 화면을 열 수 있습니다. 메뉴 이름은 조금 다를 수 있지만 순서는 같습니다. 그룹 생성, 주소 저장, 콘텐츠 가져오기, 노드 확인 순입니다. 주소만 저장하고 갱신하지 않았다면 목록이 비어 있을 수 있습니다. 구독이 만료됐다고 단정하거나 바로 클라이언트를 삭제할 필요는 없습니다.

갱신 실패 시 가져오기와 파싱을 구분하세요

갱신 실패는 주로 ‘주소에 접근할 수 없음’과 ‘응답 내용을 파싱할 수 없음’으로 나뉩니다. 전자는 기기 네트워크, 구독 만료 여부, 주소 전체가 복사됐는지, 요청에 기존 프록시가 필요한지 확인하세요. 후자는 응답이 로그인 페이지, 웹 안내문, 미지원 형식인지 살펴보세요. 클라이언트에서 프록시를 통한 갱신을 지원하더라도 기존 프록시가 정상 작동할 때만 사용해야 합니다. 사용할 수 있는 노드가 없는 상태에서 이 옵션을 켜면 연결에 필요한 노드를 가져오는 과정이 기존 연결을 요구하는 순환 문제가 생길 수 있습니다.

구독 갱신에 성공하면 프로토콜, 서버 주소, 원격 포트, 보안 전송 항목을 확인하세요. 노드 표시 이름만으로 판단하면 안 됩니다. 같은 지역으로 표시된 항목도 전송 조합이 다를 수 있으며 이름이 비슷하다고 서로 바꿔 쓸 수 있는 것은 아닙니다. 가져온 노드에서 필드가 눈에 띄게 누락됐다면 구독 형식과 클라이언트 호환성을 먼저 확인하세요. 다른 노드의 서버 이름, 경로, 공개 키를 복사해 시험하지 마세요. 매개변수는 전체 조합이 서로 맞아야 합니다.

수동 노드와 구독 노드를 따로 관리하기

구독 노드는 다음 갱신 때 다시 생성되는 경우가 많아 직접 수정한 매개변수가 덮어써질 수 있습니다. 특정 항목을 시험하려면 노드를 별도의 수동 그룹으로 복사하고 설명에 테스트용 복사본이라고 표시하세요. 시험이 끝나도 원본 구독은 기준으로 보관해 여러 복사본이 섞이지 않게 관리하세요. 그룹을 삭제하기 전에는 노드도 함께 삭제되는지, 다른 설정에서 해당 그룹이나 선택 항목을 참조하는지 확인해야 합니다.

노드를 선택할 때 클라이언트의 연결 테스트로 대략적인 상태를 확인한 뒤 실제 대상 앱에서도 시험하세요. 테스트마다 포트 연결, 핸드셰이크, 단일 요청 등 확인 범위가 다르므로 모든 앱의 사용 경험을 그대로 나타내지는 않습니다. 테스트 결과가 비어 있거나 시간이 초과됐다고 해서 노드를 완전히 사용할 수 없다는 뜻은 아닙니다. 트래픽 한도, 사용 상태, 지역 선택은 구독 제공자의 안내를 확인하세요. 클라이언트가 서버 권한을 보충하거나 중지된 서비스를 복구할 수는 없습니다.

목록이 갑자기 비었다면 먼저 현재 선택된 그룹과 필터 조건을 확인한 다음 갱신 기록을 살펴보세요. 다른 그룹으로 전환했거나 제공자가 일시적으로 빈 내용을 반환했을 수 있습니다. 최근에 사용 가능했던 백업을 보관하고 모든 그룹을 연달아 삭제한 뒤 다시 만들지 마세요. 일부 노드만 실패한다면 전체 구독을 반복해서 갱신하기보다 프로토콜과 전송 방식별로 비교하는 편이 유용합니다. 모든 노드가 동시에 실패한 경우에만 로컬 환경과 구독 상태를 추가로 확인하세요.

갱신할 때마다 현재 선택된 노드를 다시 확인하세요. 기존 노드가 삭제된 뒤 클라이언트가 의도한 항목을 자동으로 선택하지 못할 수 있습니다. 노드 선택 기준은 지연 시간, 배율, 지역, 프로토콜별 선택 안내를 참고하세요. 이 단계를 마쳤다는 기준은 목록에 노드가 표시되는 것이 아니라, 이후 검증에 사용할 수 있도록 매개변수가 완전한 연결을 확보하고 해당 노드가 어느 구독 그룹에서 왔는지 파악하는 것입니다.

시스템 프록시와 앱 트래픽 처리 범위

시스템 프록시는 앱이 따르는 설정이지, 기기 전체의 트래픽을 처리하는 기능은 아닙니다

데스크톱의 시스템 프록시는 해당 설정을 따르는 앱에 로컬 프록시 진입점으로 요청을 전달하라고 알려줍니다. 모든 프로그램을 자동으로 처리하거나 각 앱의 네트워크 구현을 바꾸지는 않습니다. 브라우저는 확인하기 쉬운 편이지만 일부 게임, 명령줄 도구, 내장 네트워크 구성 요소는 시스템 프록시를 무시할 수 있습니다. 따라서 ‘브라우저는 되는데 다른 프로그램은 안 된다’면 먼저 앱별 트래픽 처리 범위를 확인하세요. 바로 클라이언트 오류로 단정하지 마세요. 필요하면 앱 자체의 프록시 설정을 사용하거나 TUN을 고려할 수 있습니다.

v2rayN의 일반적인 시스템 프록시 옵션으로는 시스템 프록시 지우기, 시스템 프록시 자동 설정, 시스템 프록시 변경 안 함, PAC 모드가 있습니다. 프록시를 지우면 현재 시스템 프록시 연결이 제거되지만 코어까지 중지되는 것은 아닙니다. 자동 설정은 시스템이 클라이언트의 로컬 진입점을 사용하도록 변경합니다. 변경 안 함은 기존 시스템 설정을 유지한다는 뜻이며, 연결을 새로 만든다는 의미가 아닙니다. 옵션을 고르기 전에 시스템에 수동 프록시나 다른 프로그램이 관리하는 설정이 있는지 확인해 덮어쓰지 않도록 하세요.

PAC와 코어 라우팅은 서로 다른 단계에서 동작합니다

PAC는 자동 프록시 스크립트로, 이를 따르는 앱이 직접 연결할지 프록시로 요청을 보낼지 결정합니다. 이 단계에서 앱이 직접 연결하면 요청이 클라이언트 코어에 들어오지 않으므로 코어의 라우팅 규칙으로 처리할 수 없습니다. 코어 라우팅은 로컬 진입점에 들어온 요청을 처리합니다. 두 기능을 함께 사용할 수도 있지만 문제를 찾을 때 확인할 변수가 늘어납니다. 처음에는 명확한 진입 방식 하나를 사용해 연결을 확인한 뒤 PAC가 필요한지 결정하세요.

앱에서 수동 프록시를 설정할 때는 진입점 프로토콜을 확인해야 합니다. HTTP 프록시 포트와 SOCKS 포트가 다를 수 있고, 하나의 혼합 포트가 두 방식을 처리할 수도 있으므로 현재 수신 설정을 기준으로 하세요. 주소에 로컬 루프백을 입력하면 같은 기기의 클라이언트에만 연결할 수 있습니다. 브라우저에 이전 포트가 저장되어 있다면 시스템 프록시를 업데이트해도 브라우저 자체 설정이 우선 적용될 수 있습니다. 브라우저 확장 프로그램이 프록시를 관리할 수도 있으니 시험할 때는 한 곳에서만 설정하도록 하세요.

Android VPN 모드와 라우팅 설정

Android 클라이언트는 시스템 VPN 인터페이스로 트래픽을 받습니다. 모든 앱을 처리하는지는 앱별 규칙과 라우팅 설정에 따라 달라집니다. 시스템에 VPN 표시가 있더라도 모든 요청이 원격 프록시를 거친다는 뜻은 아닙니다. 제외된 앱은 기존 네트워크 경로를 사용할 수 있고, 직접 연결로 설정된 대상도 로컬 네트워크를 통해 접속할 수 있습니다. 특정 앱의 문제를 확인할 때는 연결 스위치만 보지 말고 앱 적용 범위와 코어 아웃바운드도 살펴보세요.

확인할 때는 안정적으로 접속할 수 있는 테스트 대상을 하나 정하세요. 연결을 켠 뒤 새 요청을 보내고 클라이언트 로그에 해당 연결이 나타나는지 확인합니다. 브라우저 캐시 때문에 실제 네트워크 요청이 없어도 페이지가 보일 수 있고, 이미 열린 연결은 이전 경로를 계속 사용할 수 있습니다. 새 페이지 요청을 보내고 연결을 다시 만드세요. 로그에 요청이 없으면 진입점을 확인하고, 요청은 있지만 실패하면 아웃바운드를 점검하세요. 요청은 성공했지만 내용이 이상하다면 대상 서비스와 DNS를 살펴보세요.

종료하기 전에 시스템 프록시를 어떤 프로그램이 관리하는지 확인하세요. 클라이언트는 중지됐는데 시스템이 여전히 클라이언트의 로컬 포트를 가리키면 프록시를 따르는 앱은 연결되지 않을 수 있습니다. 남아 있는 시스템 프록시를 지우거나 해당 클라이언트를 다시 실행하면 되며 모든 네트워크 설정을 즉시 초기화할 필요는 없습니다. 클라이언트를 바꿀 때도 기존 연결을 먼저 중지하고 시스템 상태를 확인하세요. 한 프로그램이 다른 프로그램이 방금 설정한 프록시 주소를 지울 수 있습니다.

이 단계는 ‘대상 앱의 요청이 실제로 클라이언트에 들어오는 것’을 확인하면 완료입니다. 우선 복잡한 분할 라우팅은 설정하지 마세요. 간단한 연결 절차가 필요하면 입문 가이드의 연결 및 확인 단계로 돌아가세요. 모드 이름과 실제 적용 범위가 일치하지 않는다면 도움말 센터에서 확인할 수 있습니다. 다음 단계에서는 클라이언트에 들어온 트래픽이 어떤 아웃바운드를 사용할지 살펴봅니다. 트래픽 처리와 분할 라우팅을 하나의 스위치로 혼동하지 마세요.

라우팅 규칙·DNS·매칭 순서

인바운드·규칙·아웃바운드의 관계 이해하기

코어에 들어온 요청은 라우팅을 통해 경로가 결정됩니다. 일반적으로 규칙을 설정된 순서대로 확인하고 조건에 맞으면 지정된 아웃바운드로 전달합니다. 하나의 요청이 규칙에 일치하면 이후 규칙은 같은 요청을 처리하지 않습니다. 따라서 범위가 넓은 규칙이 앞에 있으면 뒤의 세부 규칙이 적용되지 않을 수 있습니다. 수정 전에 클라이언트가 어떤 아웃바운드 태그를 생성했는지, 어느 규칙에도 맞지 않는 트래픽을 어떻게 처리하는지 확인하세요. UI의 ‘프록시’ 또는 ‘직접 연결’이 설정 파일의 실제 태그 이름과 같다고 단정하면 안 됩니다.

직접 연결은 현재 기기에서 대상에 직접 연결하고, 프록시는 설정된 원격 아웃바운드를 사용하며, 차단은 해당 트래픽을 거부합니다. 세 가지는 네트워크 품질 등급이 아닙니다. 로컬 네트워크 서비스에 프록시를 적용하면 프린터, 라우터 관리 페이지, 로컬 개발 서버에 접근할 수 없을 수 있습니다. 반대로 원격 아웃바운드가 필요한 대상에 직접 연결을 적용하면 예상과 다른 결과가 나올 수 있습니다. 규칙은 명확한 필요에 맞춰 설정하고 모든 항목을 한 방향으로 바꾸지 마세요.

최소 규칙으로 필드 이해하기

아래는 특정 도메인 그룹과 사설 IP 주소를 direct라는 아웃바운드로 보내는 Xray 스타일 라우팅 예시입니다. 클라이언트 설정 전체를 대체할 수 있는 완전한 파일은 아닙니다. 실행 환경에 같은 이름의 아웃바운드와 관련 규칙 데이터가 있어야 합니다. 클라이언트에서 라우팅을 관리한다면 수동 설정과 UI 생성 결과가 서로 덮어쓰지 않도록 라우팅 화면에서 같은 규칙을 추가하는 편이 좋습니다.

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

domainStrategy는 라우팅 매칭에서 도메인과 IP 주소를 어떻게 처리할지 지정합니다. IPIfNonMatch는 도메인 단계에서 규칙이 일치하지 않을 때 주소를 조회한 뒤 IP 규칙을 추가로 확인하도록 합니다. 모든 DNS 요청이 자동으로 프록시를 통과한다는 뜻은 아니며, 각 앱의 DNS 조회가 같은 설정을 따른다는 의미도 아닙니다. 코어와 클라이언트에는 별도의 DNS 설정이 있을 수 있습니다. 라우팅 전략을 바꾼 뒤에는 이름 해석 경로와 실제 연결 경로를 각각 확인하세요.

도메인 규칙과 IP 주소 규칙의 적용 범위

도메인 규칙을 적용하려면 코어가 대상 도메인을 알아야 합니다. 앱이 숫자 주소에 직접 연결하거나 요청이 들어올 때 도메인 정보가 없다면 기존 도메인 규칙이 적용되지 않을 수 있습니다. 지원되는 경우 스니핑 기능으로 일부 프로토콜의 대상 정보를 확인할 수 있지만 모든 트래픽을 식별하지는 못하며, 올바른 DNS 설정과 진입점을 대신하지도 않습니다. 스니핑을 켠 뒤에도 로그를 확인하세요. 규칙 이름만 보고 적용됐다고 판단하면 안 됩니다.

DNS 문제는 도메인으로는 접속할 수 없지만 숫자 주소로는 연결되는 형태로 나타날 수 있습니다. 다만 이는 단서일 뿐입니다. 보안 연결에는 서버 이름이 필요할 수 있으므로 숫자 주소로 직접 접속해도 같은 조건이 되지 않을 수 있습니다. 이름 해석에 성공했는지 확인하고, 조회 결과에 대한 연결이 되는지 살펴본 다음 보안 핸드셰이크를 점검하세요. DNS 서버 변경, 스니핑 활성화, 라우팅 수정을 한꺼번에 하지 마세요. 문제가 해결되더라도 어떤 설정이 원인이었는지 알 수 없습니다.

규칙을 관리할 때는 ‘예외를 먼저, 범위를 명확히, 변경은 되돌릴 수 있게’라는 원칙을 따르세요. 먼저 제한된 범위의 규칙 하나를 추가하고 대상 앱에서 새 요청을 보낸 뒤 로그에서 매칭 결과를 확인합니다. 결과가 맞으면 도메인 그룹으로 범위를 확장하세요. 규칙 데이터베이스도 그룹 매칭 결과에 영향을 줄 수 있으므로 클라이언트 업데이트 후 동작이 달라졌다면 UI 선택지만 비교하지 말고 규칙 데이터와 설정을 함께 확인하세요. 설정 구조는 inbounds, outbounds, routing 구성별 설명에서 더 자세히 볼 수 있습니다.

TUN 모드와 시스템 라우팅 범위

가상 네트워크 인터페이스가 필요한 경우

TUN은 가상 네트워크 인터페이스로 시스템 트래픽을 받은 뒤 클라이언트 또는 관련 코어 구성 요소에 전달합니다. 시스템 프록시를 따르지 않고 앱 자체 프록시 설정도 없는 경우에 사용할 수 있습니다. TUN은 트래픽이 클라이언트에 들어오는 경로를 바꿀 뿐, 잘못된 노드 매개변수를 고치거나 중지된 구독을 복구하지 않습니다. 시스템 프록시로 충분하다면 ‘더 완전하게’ 사용하려고 TUN을 켤 필요는 없습니다. 트래픽 처리 단계가 늘어날수록 권한, DNS, 라우팅 문제를 확인하기도 복잡해집니다.

TUN을 켜기 전에 일반 프록시 방식으로 사용할 수 있는 노드가 있는지 확인하고 현재 시스템 프록시, 라우팅 모드, DNS 설정을 기록하세요. 기존 연결 자체가 실패하는 상황에서 TUN을 켜면 기본 연결 문제와 시스템 트래픽 처리 문제가 섞입니다. 일부 배포 버전은 추가 서비스, 가상 인터페이스 구성 요소, 권한이 필요할 수 있습니다. 실제 지원 여부는 클라이언트, 운영체제, 선택한 코어 조합에 따라 다릅니다. UI에 스위치가 보인다고 해서 시스템 조건이 모두 갖춰졌다는 뜻은 아닙니다.

한 번에 하나씩 설정하기

먼저 라우팅을 바꾸거나 VPN 인터페이스를 점유할 수 있는 다른 프로그램을 중지한 다음 클라이언트 안내에 따라 TUN을 켜세요. 권한이 필요한 경우 요청 출처와 작업 내용을 확인하세요. 일반적인 시작 실패를 모두 높은 권한으로 해결하려고 하지 마세요. 실행 후 코어 및 인터페이스 로그에서 권한 부족, 장치 생성 실패, 라우팅 등록 실패가 없는지 확인한 다음 대상 앱을 시험합니다. 인터페이스가 만들어지지 않았다면 노드를 계속 바꾸는 것은 도움이 되지 않습니다. 먼저 로컬 트래픽 처리 조건을 해결하세요.

처음 시험할 때는 특별한 이유 없이 시스템 프록시와 TUN을 동시에 사용하지 마세요. 일부 클라이언트는 두 방식을 함께 조정할 수 있지만, 수동으로 조합하면 경로가 중복되어 로그를 이해하기 어려워질 수 있습니다. 한 가지 트래픽 처리 방식만 명확하게 사용한 다음 다른 설정을 하나씩 복구하세요. 테스트에는 원격 대상뿐 아니라 로컬 네트워크 서비스와 일반 네트워크 연결도 포함해 기존 경로가 끊기지 않았는지 확인해야 합니다.

출구 루프와 사설 네트워크 예외 이해하기

클라이언트는 실제 네트워크를 통해 원격 서버에 연결해야 합니다. 이 자체 아웃바운드가 가상 인터페이스에 다시 포착되면 루프가 생길 수 있습니다. 일반적인 구현은 인터페이스 바인딩, 라우팅 제외, 관련 보호 기능으로 이를 처리하지만, 시스템 라우팅을 직접 바꾸거나 다른 네트워크 도구를 함께 사용하면 문제가 발생할 수 있습니다. 연결이 반복해서 생성되거나 연결 직후 시간 초과가 발생하거나 TUN을 켠 뒤 모든 접속이 실패할 수 있습니다. 이런 경우 먼저 TUN을 꺼서 기존 상태로 복구한 다음 라우팅 충돌을 확인하세요.

로컬 네트워크 접근도 범위를 명확히 해야 합니다. 라우터 관리 주소, 프린터, 원격 데스크톱, 로컬 개발 환경은 사설 IP로 직접 연결해야 할 수 있습니다. TUN을 켠 뒤 이런 서비스가 작동하지 않으면 모든 트래픽을 프록시로 보내지 말고 사설 IP 규칙, 로컬 네트워크 우회 옵션, 가상 인터페이스 라우팅을 확인하세요. 네트워크마다 주소 범위가 다를 수 있으며 기업 네트워크에는 자체 정책이 있습니다. 네트워크 관리자의 안내를 따르고 기존 라우팅을 임의로 덮어쓰지 마세요.

DNS와 UDP도 확인해야 합니다. TUN이 시작됐다고 모든 도메인 조회가 예상한 경로를 따른다는 뜻은 아닙니다. 앱 자체의 암호화 DNS 설정이 동작을 바꿀 수 있습니다. 실시간 통신이나 게임의 UDP 연결이 정상적으로 되는지는 코어, 노드, 서버 지원 여부에 따라 달라집니다. 웹페이지가 열린다고 UDP도 정상이라고 판단할 수 없습니다. 웹, 이름 해석, 대상 앱 결과를 나눠 기록하고 하나의 테스트로 모든 상황을 판단하지 마세요.

TUN을 껐는데도 네트워크가 복구되지 않으면 클라이언트를 정상 종료하고 시스템 프록시와 현재 VPN 연결을 확인한 뒤 가상 인터페이스가 계속 활성 상태인지 살펴보세요. 시스템 네트워크 어댑터를 한꺼번에 삭제하지 말고 클라이언트의 중지 또는 복구 기능을 우선 사용하세요. TUN을 켜기 전 설정을 기록해 두고 필요하면 시스템을 재시작해 남은 상태를 확인하세요. 이 단계를 마치려면 트래픽 처리 범위를 설명하고 대상 앱을 검증하며 일반 프록시 방식으로 안전하게 되돌릴 수 있어야 합니다. 스위치를 켜 두는 것만으로는 충분하지 않습니다.

유지 관리 및 단계별 문제 해결

업데이트 전 복구 가능한 상태 보존하기

유지 관리에서는 클라이언트 업데이트, 코어 업데이트, 구독 갱신, 규칙 데이터 업데이트를 구분해야 합니다. 각각 변경하는 내용이 다르므로 문제가 발생했을 때 한꺼번에 모두 실행하지 마세요. 클라이언트 업데이트는 UI와 설정 생성 방식을 바꿀 수 있고, 코어 업데이트는 프로토콜 지원에 영향을 줍니다. 구독 갱신은 노드 출처를 바꾸며 규칙 데이터 업데이트는 분할 라우팅 매칭에 영향을 줍니다. 현재 정상 작동하는 설정을 기록한 뒤 필요한 항목만 하나씩 업데이트하고 매번 확인해야 문제가 생긴 단계를 찾을 수 있습니다.

백업에는 구독 그룹, 수동 노드, 라우팅 및 DNS 설정, 앱 트래픽 처리 범위가 포함되어야 합니다. 클라이언트에서 내보내기 기능을 제공한다면 이를 우선 사용하세요. 데이터 폴더를 복사할 때는 프로그램을 먼저 중지해 저장 중인 파일이 백업에 포함되지 않게 합니다. 백업 파일에는 접속 자격 정보가 들어 있을 수 있으므로 안전한 곳에 보관하세요. 다른 클라이언트나 배포 버전으로 복원할 때 내부 설정 형식이 모두 호환된다고 가정하지 마세요. 필요하면 표준 노드 정보로 다시 가져오세요.

오류가 발생한 단계를 먼저 확인하세요

연결이 실패하면 먼저 로컬 네트워크에서 일반적인 접속이 가능한지 확인합니다. 다음으로 클라이언트 코어가 실행 중인지, 요청이 로그에 들어오는지 확인하세요. 코어가 시작되지 않았다면 원격 노드를 시험할 필요가 없습니다. 요청이 로그에 없다면 프록시 또는 VPN 트래픽 처리를 먼저 점검하세요. 요청이 코어에 들어온 뒤에는 원격 연결, 이름 해석, 핸드셰이크 결과를 확인합니다. 이런 순서로 살펴보면 ‘요청이 로컬에 들어오지 않은 경우’와 ‘들어온 요청 처리에 실패한 경우’를 구분해 불필요한 설정 변경을 줄일 수 있습니다.

로그의 시간 초과는 어떤 대기 과정이 정해진 시간 안에 끝나지 않았다는 뜻일 뿐, 원인을 자동으로 알려주지는 않습니다. 주소 연결 시간 초과는 네트워크 경로나 서비스 상태와 관련될 수 있습니다. 핸드셰이크 오류라면 서버 이름, 키, 시스템 시간, 프로토콜 조합을 확인하세요. 이름 해석 오류는 DNS를 점검해야 합니다. 오류 단어 하나만 검색하지 말고 주변 로그 행에서 대상과 처리 단계를 확인하세요. 로그를 공유할 때 오류 유형과 발생 순서는 남기되 노드 인증 정보와 개인 네트워크 정보는 가리세요.

최소한의 비교 테스트로 범위 좁히기

비교 테스트에서는 한 번에 조건 하나만 바꾸세요. 클라이언트와 모드를 그대로 둔 채 이미 사용 가능한 노드로 바꾸면 노드에 문제가 있는지 확인할 수 있습니다. 노드를 유지하고 다른 네트워크에 연결하면 현재 네트워크 환경과 관련 있는지 살펴볼 수 있습니다. 네트워크와 노드를 그대로 둔 채 기본 라우팅으로 되돌리면 사용자 지정 분할 라우팅을 확인할 수 있습니다. 네트워크, 클라이언트, 구독을 동시에 바꾼 뒤 해결됐다고 해서 특정 설정이 원인이었다고 판단할 수는 없습니다.

시스템 시간은 신뢰할 수 있는 시간 동기화 기능으로 관리해야 합니다. 특히 인증서 유효 기간이나 시간 기반 인증이 관련된 경우 중요합니다. 시간이 크게 틀리면 매개변수가 올바른데도 연결이 실패할 수 있습니다. 또 다른 흔한 문제는 시스템 프록시가 남아 있는 경우입니다. 클라이언트가 종료되어 로컬 포트가 더 이상 수신하지 않는데도 앱이 이전 진입점으로 요청을 보낼 수 있습니다. 이 경우 먼저 시스템 프록시를 복구하세요. 모든 노드를 삭제하거나 운영체제를 다시 설치할 필요는 없습니다.

문제를 확인할 때만 필요한 범위에서 로그 수준을 높이고, 완료 후에는 일반 수준으로 되돌리세요. 접속 정보가 과도하게 저장되는 것을 막을 수 있습니다. 스크린샷만 공유할 수 있다면 오류 전후의 관련 로그와 현재 모드를 함께 포함하세요. ‘연결 실패’ 한 줄만으로는 알 수 있는 내용이 제한적입니다. 노드 시간 초과 점검 방법은 7가지 확인 항목을 참고하세요. 일반적인 사용 문제는 도움말 센터에서 확인할 수 있습니다. 유지 관리의 목표는 매번 변경 내용을 기록하고 되돌릴 수 있는 안정적인 기준 상태를 보존하는 것입니다.

설정 파일 읽기와 고급 학습 과정

사용자 지정 설정을 쓰기 전에 생성된 결과부터 살펴보세요

앞의 단계를 완료했다면 고급 설정의 첫걸음은 규칙을 더 많이 추가하는 것이 아니라 클라이언트가 생성한 설정을 이해하는 것입니다. 로컬 인바운드, 원격 아웃바운드, 직접 연결 아웃바운드, 라우팅, DNS의 위치를 찾고 태그 참조를 따라 관계를 확인하세요. UI는 작업하기 쉽도록 설정을 추상화하지만 설정 파일에는 코어가 실제로 받은 지시가 나타납니다. UI와 파일 내용이 다르다면 현재 실행 중인 인스턴스에서 생성한 파일인지 확인하세요. 이전 설정을 읽고 현재 동작을 잘못 판단하지 않도록 주의해야 합니다.

인바운드는 요청을 받는 방식과 수신 범위를 결정하고, 아웃바운드는 대상이나 원격 서버에 연결하는 방법을 정의합니다. 라우팅은 태그로 이들을 연결합니다. 태그는 설정에서 참조하는 이름일 뿐 자동으로 연결되는 기능은 없습니다. 예시의 아웃바운드 태그 이름을 바꾸면 해당 태그를 참조하는 모든 규칙도 함께 수정해야 합니다. 설정 구문이 올바르더라도 논리가 잘못될 수 있습니다. 예를 들어 규칙 파싱은 성공했지만 앞의 범위가 넓은 규칙이 항상 먼저 매칭될 수 있습니다. 요청 테스트로 실제 동작을 검증해야 합니다.

범위를 제한한 규칙으로 매개변수 익히기

아래 규칙으로 도메인 매칭 방식을 익힐 수 있습니다. full:은 전체 도메인을 지정하고 domain:은 지정한 도메인과 하위 도메인에 매칭됩니다. 예시 대상은 문서용 도메인입니다. 규칙을 추가하려면 기존 라우팅 규칙 배열에 넣고 direct 아웃바운드가 있는지 확인하세요. 이 규칙만으로 완전한 설정이 되지는 않으며 원격 연결 정보도 포함하지 않습니다. 원본 파일을 그대로 덮어쓰기보다 규칙 순서, 매칭 조건, 참조 태그를 확인하는 것이 학습의 핵심입니다.

{
  "type": "field",
  "domain": [
    "full:example.com",
    "domain:example.org"
  ],
  "outboundTag": "direct"
}

사용자 지정 설정을 적용하기 전에 클라이언트가 시작할 때 파일을 다시 생성하는지 확인하세요. 파일을 다시 생성한다면 결과 파일을 직접 편집해도 잠시만 적용되고 다음에 설정을 저장할 때 덮어써질 수 있습니다. 클라이언트가 제공하는 사용자 지정 설정, 라우팅 관리, 템플릿 메뉴를 사용하고 UI 설정과 병합되는지 대체되는지 확인하세요. 하나의 필드를 여러 곳에서 관리하면 최종 적용 값을 알기 어려워집니다. 중복된 설정 출처를 줄이고 각 설정의 관리 위치를 명확히 하세요.

필요에 맞춰 프로토콜 학습하기

프로토콜을 더 깊이 알아보려면 VMess와 VLESS의 기본 차이부터 살펴본 다음 보안 계층과 전송 방식의 조합을 이해하세요. 프로토콜 이름만으로 속도나 안정성을 추측하면 안 됩니다. 실제 성능은 서버, 네트워크 경로, 앱 동작에도 영향을 받습니다. REALITY, TLS, WebSocket은 각각 필요한 매개변수와 적용 조건이 있습니다. 출처가 명확한 노드 하나를 기준으로 항목을 하나씩 확인하고, 무작위 예시의 필드를 조합해 새 연결을 만들지 마세요. 기본 비교는 VMess와 VLESS 설명에서 확인할 수 있습니다.

그다음 DNS 정책, 규칙 그룹, 스니핑, 앱별 적용 범위를 살펴보세요. 각 주제에 대해 로컬 네트워크 서비스를 직접 연결 상태로 유지하거나 특정 앱의 요청을 지정한 아웃바운드로 보내는 등 검증할 목표를 먼저 정하세요. 예상 결과를 적은 뒤 설정하고, 테스트 중 해당 규칙이 적용됐는지와 실패가 발생한 단계를 기록합니다. 옵션을 바꿨을 때 어떤 결과가 달라질지 설명할 수 없다면 일단 기본값을 유지하세요. 복잡한 옵션을 모두 켜야 하는 기능 목록처럼 다루지 마세요.

장기간 사용할 때는 무엇을 변경했는지, 어떤 문제를 해결하려 했는지, 어떤 조건으로 확인했는지, 어떻게 되돌릴 수 있는지 간단히 기록하세요. 업데이트 후 동작이 달라지면 전체 환경을 즉시 다시 만들지 말고 변경 기록과 실행 설정을 먼저 비교하세요. 다른 기기로 옮길 때도 시스템 프록시, 권한, 인터페이스 적용 범위를 다시 확인해야 합니다. 노드 매개변수는 같아도 운영체제의 트래픽 처리 방식은 다를 수 있습니다. 설정 일부를 공유하기 전에는 민감한 정보를 가리세요.

전체 학습 과정이 마무리되었습니다. 연결 경로를 이해하고, 적절한 설치 패키지를 선택하고, 구독을 가져와 관리하며, 트래픽 처리와 분할 라우팅을 구분하고, TUN을 검증한 뒤 되돌릴 수 있습니다. 마지막으로 로그를 사용해 사용자 지정 규칙을 확인할 수 있습니다. 다시 확인할 때마다 처음부터 읽을 필요 없이 상단 목차에서 필요한 단계로 이동하세요. 최소한의 연결을 다시 설정하려면 빠른 시작 가이드로 돌아간 뒤 필요한 설정을 하나씩 복구하세요. 기존 설정이 새로운 문제의 원인이 되지 않도록 할 수 있습니다.