v2rayN 완벽 가이드

1. 핵심 개념: 클라이언트, 코어, 연결 경로

화면과 실제 동작을 구분하기

v2rayN은 서버 정보를 저장하고 구독 그룹을 관리하며 프록시 진입점을 설정하고 코어를 실행하는 그래픽 클라이언트입니다. 실제 연결을 만들고 라우팅 규칙을 해석하며 프로토콜과 전송을 처리하는 것은 코어입니다. 화면이 정상적으로 열려도 코어가 실행 중이라는 뜻은 아니며, 코어가 실행 중이어도 브라우저 요청이 코어를 거친다는 보장은 없습니다. 두 계층을 이해해야 ‘접속할 수 없음’이라는 문제를 점검 가능한 단계로 나눌 수 있습니다. 클라이언트 전체를 반복해서 다시 설치할 필요도 없습니다.

Project V는 관련 프록시 기술의 생태계 배경이며, V2Fly와 Xray는 서로 연관되어 있지만 독립적으로 개발되는 코어 프로젝트입니다. 코어마다 지원하는 필드, 전송 조합, 확장 기능이 완전히 같지는 않습니다. 클라이언트에 특정 프로토콜 옵션이 표시된다는 것은 설정 입력란이 있다는 뜻일 뿐, 실제 작동 여부는 선택한 코어, 서버 매개변수, 현재 빌드에 따라 달라집니다. 호환성 문제가 생기면 프로토콜 이름만 비교하지 말고 이 조건부터 확인하세요.

요청이 지나가는 경로를 따라 설정 이해하기

일반적인 데스크톱 연결은 앱, 시스템 프록시 또는 앱 자체 프록시, 로컬 수신 포트, 라우팅 규칙, 아웃바운드, 원격 서버 순으로 이어집니다. 인바운드는 코어가 트래픽을 받아들이는 방식을 정하고, 아웃바운드는 코어에서 연결이 나가는 방식을 정합니다. 흔한 아웃바운드 유형으로는 프록시 서버, 직접 연결, 차단이 있습니다. 구독은 주로 서버 정보를 제공하고 라우팅 규칙은 요청별로 어떤 아웃바운드를 사용할지 결정합니다. 두 기능은 서로 다른 문제를 해결합니다.

노드는 필드를 마음대로 바꿔 넣을 수 있는 주소록 항목이 아닙니다. 서버 주소, 포트, 사용자 ID, 프로토콜, 전송 방식, TLS 매개변수가 함께 연결 조건을 이룹니다. 도메인은 서버를 찾는 데 쓰일 수도 있고 TLS 서버 이름을 확인하는 데 쓰일 수도 있지만, 두 용도의 값이 반드시 같지는 않습니다. 전송 경로, 호스트 이름, 서비스 이름도 서버 측 매칭에 사용될 수 있습니다. 서버 주소만 알아서는 나머지 매개변수를 채우기 어렵습니다.

프로토콜, 전송, 암호화의 역할 구분하기

VMess, VLESS, Trojan은 인증과 프로토콜 동작이 서로 다릅니다. TCP, WebSocket, gRPC 등은 별도의 전송 계층 선택지입니다. TLS는 해당 연결에 암호화와 인증을 제공하며, REALITY는 별도의 매개변수가 필요합니다. 프로토콜 이름이 같아도 전송 방식이나 보안 설정이 다르면 연결이 실패할 수 있습니다. 구독 항목을 확인할 때는 각 계층을 구분해서 살펴보세요. 특정 프로토콜을 하나의 고정된 암호화 또는 전송 조합과 동일시하면 안 됩니다.

DNS는 도메인 이름을 IP 주소로 변환하지만, 어디에서 이름을 해석하는지에 따라 라우팅 결과가 달라집니다. 앱이 먼저 이름을 해석한 뒤 연결하면 코어에는 대상 주소만 전달될 수 있습니다. 앱이 도메인 이름을 전달하면 코어가 도메인 규칙을 적용할 수 있습니다. 시스템 프록시는 일반적으로 앱이 해당 설정을 따를 때 작동하고, TUN은 가상 네트워크 인터페이스를 통해 조건에 맞는 트래픽을 받습니다. 두 진입 방식의 적용 범위는 다르지만 같은 라우팅 규칙과 아웃바운드를 사용할 수 있으므로, 진입 방식만으로 최종 연결 경로를 판단할 수는 없습니다.

다음 장으로 넘어가기 전에 세 가지 상태를 구분할 수 있어야 합니다. 클라이언트가 설정을 저장했는지, 코어가 설정을 받아들였는지, 앱 요청이 실제로 설정된 경로를 거쳤는지입니다. 첫 번째는 화면에서, 두 번째는 실행 로그에서 확인할 수 있습니다. 세 번째는 실행 로그와 앱 테스트를 함께 살펴봐야 합니다. 용어가 낯설다면 용어 가이드에서 확인할 수 있습니다. 처음 연결하기 전에 모든 프로토콜 세부사항을 알 필요는 없습니다. 전체 경로를 파악하는 것이 모든 필드를 외우는 것보다 중요합니다.

2. 클라이언트 선택: 플랫폼, 코어, 사용 환경

데스크톱은 v2rayN부터 시작

Windows, macOS, Linux 데스크톱에서는 v2rayN부터 시작하는 것이 좋습니다. 같은 클라이언트를 사용하면 구독 그룹과 문제 해결 방식을 통일하기 쉽지만, 세 운영체제의 메뉴, 권한, 네트워크 연결 방식까지 모두 같다고 가정해서는 안 됩니다. 안내된 절차를 따라갈 때는 현재 화면에 표시된 이름을 기준으로 삼으세요. 특정 설정을 찾을 수 없다면 다른 운영체제의 설정 디렉터리나 권한 절차를 그대로 적용하기보다 플랫폼과 사용 중인 화면부터 확인하세요.

Windows 다운로드 페이지에는 데스크톱 버전과 클래식 WPF 버전이 제공됩니다. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하므로 여러 데스크톱 운영체제에서 비슷한 방식으로 사용하려는 경우에 적합합니다. 클래식 WPF 버전은 기존 창 레이아웃을 유지하므로 익숙한 사용 환경을 원하는 경우에 적합합니다. 두 버전을 함께 설치해야 하는 것은 아닙니다. 처음 설정할 때 하나를 선택하고 연결을 테스트한 다음 필요하면 이전하세요. 두 인스턴스가 수신 포트를 함께 사용하거나 시스템 프록시 설정을 덮어쓰는 상황을 피할 수 있습니다.

Android는 필요한 코어에 따라 선택

Android에서는 v2rayNG를 우선 사용하며, 일반적으로 Xray 코어를 사용합니다. v2flyNG는 V2Fly 코어를 사용하는 대안입니다. 클라이언트 이름이 비슷한지보다 기존 서버 매개변수와 필요한 기능을 기준으로 선택하세요. 특정 설정이 특정 코어의 기능에 의존한다면 다른 클라이언트도 해당 기능을 지원하는지 먼저 확인해야 합니다. 가져오기에 성공했다는 것은 항목을 읽고 저장했다는 뜻일 뿐, 모든 확장 필드가 실행 단계에서 제대로 적용됐다는 의미는 아닙니다.

설치 패키지의 아키텍처는 기기에 맞아야 합니다. 최신 Android 기기는 대부분 arm64를 사용하지만 프로세서와 실제 시스템 환경을 함께 고려해야 합니다. 확인하기 어렵다면 시스템 정보를 살펴보거나 다운로드 페이지에서 제공하는 범용 버전을 선택하세요. 데스크톱도 x64와 arm64를 구분해야 하며, macOS는 Apple Silicon과 Intel에 맞는 버전을 선택해야 합니다. 아키텍처가 맞지 않으면 설치에 실패하거나 프로그램이 실행되지 않을 수 있습니다. 이 문제를 구독이나 네트워크 회선 탓으로 돌리지 마세요.

이전 비용도 고려해 선택하기

클라이언트 간에 구독 주소는 재사용할 수 있어도 로컬 설정은 그대로 옮기지 못하는 경우가 많습니다. 시스템 프록시, 앱별 라우팅, 라우팅 템플릿, DNS, TUN 설정은 클라이언트 고유의 설정 형식일 수 있습니다. 이전할 때는 서버 정보를 먼저 가져온 다음 동작 관련 설정을 하나씩 다시 구성하세요. 데이터 디렉터리 전체를 복사하면 호환되지 않는 필드, 이전 경로, 로컬 포트까지 함께 옮겨져 새 환경의 문제를 찾기 어려워질 수 있습니다.

기기가 조직에서 관리되는지, 가상 네트워크 인터페이스 설치가 허용되는지, 다른 네트워크 도구가 이미 실행 중인지도 확인해야 합니다. 시스템 권한이 제한되어 있다면 앱 자체 프록시나 일반 시스템 프록시부터 사용해도 됩니다. TUN을 설치 완료의 필수 조건으로 삼을 필요는 없습니다. 기기에 기존 네트워크 설정이 있다면 원래의 프록시와 DNS 상태를 기록하세요. 클라이언트를 바꿔도 시스템 정책을 우회할 수는 없습니다. 여러 도구를 겹쳐 켜 어느 설정이 적용되는지 추측하지 마세요.

이 장을 마치면 사용할 클라이언트 하나, 설치 경로 하나, 초기 연결 방식 하나를 정해야 합니다. 데스크톱에서는 일반 프록시로 먼저 연결을 확인하고, Android에서는 시스템 안내에 따라 네트워크 연결 권한을 허용하세요. 플랫폼에 맞는 설치 패키지는 클라이언트 다운로드 페이지에서 선택하고, 여러 아키텍처를 번갈아 설치하지 마세요. 선택한 이유를 기록해 두면 이후 기능 차이가 발생했을 때 플랫폼 제한인지, 인터페이스 차이인지, 코어 기능 문제인지 판단하기 쉽습니다.

3. 설치 및 실행: 되돌릴 수 있는 기본 환경 구성

설치 전 네트워크 기준 상태 기록하기

클라이언트를 실행하지 않은 상태에서 기기의 네트워크가 정상인지 먼저 확인하세요. 시스템 프록시에 기존 주소가 있는지, 자동 구성 스크립트가 설정되어 있는지, DNS가 네트워크에서 자동으로 할당되는지, 다른 가상 네트워크 연결이 있는지 기록합니다. 원래 접속되던 사이트 하나를 테스트해 나중에 복구 여부를 확인할 기준으로 삼으세요. 기본 네트워크부터 문제가 있다면 연결, 인증, 시스템 시간 문제를 먼저 해결해야 합니다. 그렇지 않으면 프록시와 관계없는 오류까지 클라이언트 문제로 오인할 수 있습니다.

다운로드 페이지의 안내에 따라 플랫폼에 맞는 프로그램을 설치하세요. Windows에서는 두 인터페이스 중 하나를 선택합니다. macOS는 칩에 맞는 설치 경로를 선택한 뒤 시스템 안내에 따라 앱을 설치합니다. Linux에서는 배포판의 패키지 형식에 맞는 deb 또는 rpm을 고르고 프로세서 아키텍처도 확인하세요. 시스템에서 실행 환경이 없다고 명확히 알리면 오류 메시지에 따라 해결해야 합니다. 프로그램이 제대로 실행되지 않는 상태를 감추려고 서버를 계속 바꾸거나, 모든 시스템 보호 기능을 끄고 시험하지 마세요.

처음 실행할 때 코어 상태 확인

프로그램을 연 뒤 실행 로그나 시작 출력 영역을 찾아 코어가 실행되는지 확인하고 파일을 찾을 수 없음, 설정 해석 실패, 주소 사용 중 등의 오류가 있는지 살펴보세요. 빌드에 따라 구성 요소와 실행 조건이 다를 수 있으므로 메인 창이 열렸다고 모든 의존성이 갖춰졌다고 단정하면 안 됩니다. 코어가 바로 종료되면 가장 먼저 나온 오류 행을 보존하세요. 이후 재시도와 연결 실패는 연쇄적인 결과일 수 있으므로 처음 발견된 명확한 오류부터 해결하세요.

현재 설정에서 로컬 수신 주소와 포트를 확인하세요. 안내문에 흔히 나오는 숫자를 고정 기본값으로 여기거나, 확인되지 않은 포트를 다른 프로그램에 미리 입력하지 마세요. 두 클라이언트가 같은 주소와 포트를 사용하면 나중에 실행한 쪽이 수신에 실패할 수 있습니다. 먼저 불필요한 인스턴스를 종료하고 실행 출력을 확인하세요. 꼭 변경해야 한다면 클라이언트와 해당 클라이언트를 사용하는 앱 양쪽에서 값을 바꾸고 새 연결 정보를 기록하세요.

디렉터리, 권한, 백그라운드 동작

클라이언트 설정 디렉터리는 플랫폼, 설치 방식, 빌드에 따라 달라질 수 있습니다. 프로그램의 설정 메뉴나 디렉터리 열기 기능을 이용해 위치를 확인하세요. 한 기기에서 찾은 경로를 모든 기기의 고정 경로로 일반화하지 마세요. 설정을 저장한 뒤 프로그램을 다시 시작해도 값이 유지되는지 확인해야 현재 계정에 필요한 쓰기 권한이 있다고 볼 수 있습니다. 종료 후 설정이 사라진다면 다른 프로그램을 실행했는지, 다른 계정이나 데이터 디렉터리를 사용했는지 확인하세요.

일반 시스템 프록시와 TUN은 필요한 권한이 다릅니다. 처음 설치할 때는 최소한의 작업 환경만 구성하고 시작 시 자동 실행, 구독 자동 업데이트, 모든 네트워크 연결 옵션을 한꺼번에 켜지 마세요. Android는 시스템 대화상자에서 네트워크 연결을 허용해야 하며, 데스크톱 TUN에는 추가 권한이나 구성 요소가 필요할 수 있습니다. 권한 요청은 방금 실행한 작업과 관련이 있어야 합니다. 출처를 알 수 없는 요청은 취소하고 클라이언트에서 작업 내용과 로그를 확인하세요.

마지막으로 정상 종료 절차를 확인하세요. 네트워크 연결 기능을 먼저 끄고 클라이언트를 종료한 다음 시스템 프록시가 예상한 상태로 돌아왔는지 확인하고, 설치 전 기준 사이트에 다시 접속해 보세요. 종료한 뒤에도 앱이 중지된 로컬 포트에 계속 연결하려 한다면 시스템 네트워크 설정에서 이번 작업으로 남은 값을 지우되, 설치 전에 있던 조직 설정은 유지해야 합니다. 실행, 저장, 종료 후 복구까지 확인해야 기본 환경 구성이 완료된 것입니다. 이후 구독 문제는 이 기준 상태와 분리해 진단할 수 있습니다.

시작 단계에서 문제가 계속된다면 코어 시작 실패 및 포트 충돌 문제 해결을 참고하세요. 이 단계에서 많은 서버를 가져오거나 설치 방식을 여러 개 바꿀 필요는 없습니다. 명확한 오류 기록과 현재 설치 위치를 남기는 것이 한 기기에 프로그램을 여러 개 쌓는 것보다 문제를 찾는 데 도움이 됩니다.

4. 구독 가져오기 및 그룹 관리: 주소, 항목, 업데이트 구분하기

구독 주소와 노드 링크는 별도로 다루기

구독 주소는 서버 정보를 가져오는 경로이며, 단일 노드 링크는 하나의 연결 항목을 나타냅니다. 둘 다 텍스트로 복사할 수 있지만 가져오기 메뉴는 다를 수 있습니다. v2rayN에서는 먼저 구독 그룹 설정을 찾아 알아보기 쉬운 그룹을 추가하고, 제공받은 구독 주소를 입력해 저장한 다음 해당 그룹을 업데이트하세요. 메뉴 이름은 인터페이스에 따라 바뀔 수 있지만, 먼저 그룹을 만든 뒤 클라이언트가 내용을 가져와 해석하도록 하는 흐름은 같습니다.

v2rayNG와 v2flyNG는 일반적으로 구독 설정이나 구성 추가 메뉴에서 구독 출처를 관리합니다. 가져오는 항목이 구독인지 단일 설정인지 확인한 뒤 해당 작업을 선택하세요. 클립보드에 설명 문구, 줄바꿈, 전각 문장 부호, 메신저가 덧붙인 내용이 섞이면 주소를 해석하지 못할 수 있습니다. 주소 끝의 쿼리 매개변수도 인증에 사용될 수 있으므로 짧게 만들려고 임의로 지우지 마세요. 설명용 주소는 https://example.com/sub?token=xxxx처럼 명확한 예시만 사용하세요.

개인 수정 사항이 덮어쓰이지 않도록 그룹 만들기

그룹 이름에는 출처와 용도를 표시하되 접속 인증 정보나 쉽게 바뀌는 회선 홍보 문구는 넣지 않는 것이 좋습니다. 업무 테스트, 일상 사용, 수동으로 추가한 항목을 분리해 관리할 수 있습니다. 구독을 업데이트하면 그룹 내 항목이 다시 만들어질 수 있으며, 수동으로 수정한 별칭이나 매개변수가 유지되는지는 클라이언트 구현에 따라 다릅니다. 오래 보존해야 하는 사용자 지정 항목은 별도 그룹에 두고, 출처가 관리하는 필드와 로컬에서 관리하는 필드를 기록하세요.

기존 그룹 업데이트와 새 그룹을 중복으로 추가하는 것은 다른 작업입니다. 기존 그룹을 업데이트하면 해당 출처의 내용을 새로 가져오지만, 새 그룹을 만들면 항목이 중복되어 이후 선택과 테스트의 대상이 모호해질 수 있습니다. 업데이트 후 파싱 오류가 있는지, 항목이 예상한 그룹에 속하는지, 이전에 선택했던 서버가 여전히 있는지 확인하세요. 출처에서 항목을 삭제하거나 이름을 바꾸면 현재 선택을 다시 확인해야 할 수 있습니다. 목록에 예전 이름이 남아 있어도 원격에서 같은 서비스를 계속 제공한다는 뜻은 아닙니다.

실패 단계별로 업데이트 문제 찾기

업데이트에 실패하면 주소를 가져오지 못한 것인지, 내용을 해석하지 못한 것인지 먼저 구분하세요. 연결 시간 초과와 도메인 이름 해석 실패는 보통 가져오기 단계에서 발생합니다. 로그인 페이지, 오류 안내, 호환되지 않는 내용이 반환되면 해석 단계의 문제일 수 있습니다. 오류를 공유할 때는 오류 유형을 남기되 전체 구독 주소는 공개하지 마세요. 일반 브라우저에서 페이지를 볼 수 있다고 클라이언트가 사용할 수 있는 구독을 받은 것은 아닙니다. 반환된 내용의 용도와 선택한 가져오기 방식이 맞는지 확인하세요.

일부 환경에서는 구독을 업데이트할 때 이미 사용 가능한 프록시가 필요합니다. 클라이언트에 직접 업데이트와 프록시를 통한 업데이트 옵션이 있다면 현재 연결 상태에 맞는 방식을 선택하세요. 아직 사용 가능한 프록시가 하나도 없다면 프록시를 거쳐야 하는 업데이트가 순환 문제를 만들 수 있습니다. 서버가 없어서 업데이트할 수 없고, 업데이트할 수 없어 서버를 얻지 못하는 상황입니다. 이때 DNS와 TUN 설정을 무작정 모두 바꾸기보다 제공처가 안내한 적절한 가져오기 방법을 사용하거나 기본 네트워크를 확인하세요.

구독 변환을 사용하면 원본 정보를 처리하는 단계가 추가되며 대상 클라이언트가 이해하지 못하는 확장 필드가 사라질 수 있습니다. 원본 형식을 직접 가져올 수 없고 변환을 처리하는 주체와 출력 형식을 이해하는 경우에만 고려하세요. 연결 문제를 해결하기 위한 기본 절차로 변환을 사용하지 마세요. 처음 가져오기를 마친 뒤 그룹 이름, 업데이트 방법, 테스트 항목을 기록해 두세요. 나중에 업데이트 문제가 생기면 출처, 가져오기 경로, 로컬 설정 중 무엇이 바뀌었는지 비교할 수 있습니다.

기기를 바꿀 때는 구독 주소가 담긴 화면 캡처를 공개로 전달하지 말고 구독 그룹을 새로 설정하는 편이 좋습니다. 가져오기 문제에 대한 도움을 요청하려면 FAQ에서 설치 및 설정 항목을 확인하고 클라이언트 이름, 가져오기 방식, 오류가 발생한 단계를 알려 주세요. 비공개 정보를 삭제한 뒤에도 로그에는 문제 진단에 필요한 내용이 충분히 남는 경우가 많습니다.

5. 프록시 모드: 시스템 프록시, 앱 프록시, 전체 라우팅

먼저 앱이 프록시에 연결되는 방식 선택하기

데스크톱에서 처음 연결할 때는 서버 하나를 선택한 다음 시스템 프록시를 켜는 것이 좋습니다. v2rayN의 일반적인 설정 항목인 ‘시스템 프록시 자동 설정’은 시스템에서 지원하는 프록시 설정이 클라이언트의 로컬 진입점을 가리키도록 합니다. 모든 네트워크 연결을 강제로 터널에 넣는 기능은 아닙니다. 앱이 해당 설정을 사용할지는 앱의 동작, 네트워크 라이브러리, 확장 프로그램 또는 별도의 프록시 설정 유무에 따라 달라집니다. 설정이 적용되는 것과 모든 트래픽을 처리하는 것은 따로 확인해야 합니다.

브라우저는 처음 테스트하기에 편리하지만 확장 프로그램, 별도 프록시 설정, 자동 구성 스크립트가 연결 경로를 바꿀 수 있습니다. 변수를 줄이고 명확한 진입 방식 하나만 남기세요. 테스트할 때 새 요청을 보내고 해당 연결이 클라이언트 로그에 나타나는지 확인합니다. 페이지에 예전 내용이 계속 보인다면 캐시 때문일 수 있습니다. 브라우저에서 페이지가 열린다는 사실만으로 프록시를 거쳤다고 판단하지 말고 화면 결과와 실행 로그를 함께 살펴보세요.

‘전체 프록시’는 한 가지 설정을 가리키지 않음

사용자가 말하는 ‘전체’는 시스템 프록시 스위치, 라우팅의 전체 프록시 모드, TUN을 통한 연결 범위 확장 중 하나를 가리킬 수 있습니다. 이 세 가지를 혼동하면 안 됩니다. 시스템 프록시는 일부 앱의 진입 방식을 정하고, 라우팅의 전체 프록시 모드는 코어에 들어온 트래픽이 어떤 아웃바운드를 사용할지 결정합니다. TUN은 더 많은 연결을 포착합니다. 라우팅을 전체 프록시로 설정해도 시스템 프록시를 따르지 않는 프로그램은 코어에 들어오지 않을 수 있으며 기존 네트워크 경로를 그대로 사용할 수 있습니다.

앱 자체에서 HTTP 또는 SOCKS 프록시를 지원한다면 클라이언트의 현재 수신 주소와 포트를 직접 입력할 수 있습니다. 프록시 유형은 수신 인터페이스와 일치해야 합니다. 포트 번호가 같다는 이유만으로 프로토콜도 같다고 생각하지 마세요. 로컬 기기에서만 사용할 때는 수신 범위를 필요한 수준으로 유지하고 LAN 접속을 함부로 허용하지 마세요. 다른 기기에서 접속하도록 허용하면 노출 범위가 바뀌므로 방화벽, 접근 제어, 기기가 연결된 네트워크 환경을 함께 고려해야 합니다.

터미널과 백그라운드 프로그램은 따로 확인하기

터미널 프로그램이 데스크톱 시스템 프록시를 읽지 않는 경우가 있습니다. 프로세스 환경 변수만 확인하거나 자체 매개변수를 요구하는 프로그램도 있습니다. 브라우저에서 성공했다고 터미널 설정까지 완료된 것은 아닙니다. 반대로 특정 터미널 프로세스에서 성공해도 시스템 전체가 연결된다는 뜻은 아닙니다. 환경 변수는 일반적으로 프로세스가 시작될 때 상속되므로 이미 실행 중인 프로그램에는 이전 값이 남을 수 있습니다. 새 프로세스에서 확인하고 테스트가 끝나면 임시 설정을 정리하세요.

‘브라우저는 되는데 다른 프로그램은 안 되는’ 경우 먼저 해당 프로그램의 프록시 설정 출처, 우회 목록, 요청 프로토콜을 확인한 다음 TUN이 필요한지 살펴보세요. 클라이언트 로그에 관련 기록이 전혀 없다면 요청이 진입점에 도달하지 않았을 가능성이 큽니다. 연결 기록은 있지만 실패한다면 서버, 라우팅, DNS를 확인하세요. 자세한 단계는 시스템 프록시가 작동하지 않을 때: 브라우저와 터미널 문제 해결을 참고하세요. 진입점 계층을 건너뛰고 원격 서버 설정부터 바꾸지 마세요.

이 장을 마칠 때는 서버 하나, 테스트 앱 하나, 진입 방식 하나, 명확한 라우팅 선택으로 이루어진 최소한의 작동 모드를 유지해야 합니다. 모드를 바꾸기 전에 충돌하는 기존 설정을 끄고, 변경한 뒤 새 요청을 보내 로그를 확인하세요. 클라이언트를 종료했을 때 시스템이 복구되는지도 테스트해야 합니다. 특히 앱이 종료된 로컬 포트에 계속 연결하지 않는지 확인하세요. 재현 가능한 기본 상태가 있으면 다음 장에서 복잡한 분기 규칙을 추가할 때 비교 기준으로 활용할 수 있습니다.

6. 라우팅 분기: 규칙 순서, 도메인 매칭, DNS

아웃바운드 선택은 진입 이후에 이루어짐

라우팅 분기는 코어에 들어온 연결을 대상으로 도메인, 주소, 포트 등의 조건에 따라 아웃바운드를 선택합니다. 먼저 클라이언트에서 ‘중국 본토 우회’와 같은 기존 라우팅 템플릿을 사용해 동작을 이해할 수 있는 기본 상태를 만든 뒤 사용자 지정 규칙을 추가하세요. 템플릿 이름은 동작을 요약할 뿐이며 실제 결과는 규칙 내용, 리소스 데이터, 순서에 따라 달라집니다. 대상이 잘못된 아웃바운드를 사용한다면 어떤 조건에 실제로 매칭됐는지 확인하세요. 템플릿 이름만으로 모든 연결의 동작을 판단할 수는 없습니다.

규칙은 보통 위에서 아래 순서로 확인하며 먼저 일치한 규칙이 결과를 정합니다. 따라서 구체적인 예외 규칙은 일반적으로 앞쪽에 둡니다. 도메인 조건과 주소 조건은 서로 완전히 대체할 수 없습니다. 도메인은 서비스 구분에 적합하고 주소는 네트워크 범위를 지정하는 데 적합합니다. 도메인 하나가 여러 주소로 연결될 수 있고 하나의 공유 주소에 여러 서비스가 호스팅될 수도 있습니다. 특정 사이트 하나를 고치려고 넓은 주소 범위를 모두 프록시로 보내면 관계없는 연결에도 영향을 줄 수 있습니다.

V2Ray 라우팅 설정 예시 읽기

아래 예시는 호환되는 V2Ray 설정에 병합하는 라우팅 조각이며 전체 실행 설정은 아닙니다. 비공개 주소는 직접 연결로, 지정한 광고 분류는 차단 아웃바운드로 보내고 두 아웃바운드 태그를 선언합니다. 사용하려면 해당 리소스 데이터가 있어야 하며 기존 설정의 같은 이름 아웃바운드와 병합해야 합니다. 최상위 필드를 중복해서 붙여 넣지 마세요. 그래픽 클라이언트가 설정을 다시 생성할 수 있으므로 같은 동작은 우선 클라이언트에서 제공하는 라우팅 편집 메뉴로 구성하세요.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      }
    ]
  },
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

outboundTag는 실제로 존재하는 아웃바운드 태그를 참조해야 합니다. 태그는 이름일 뿐이며 그 자체로 특정 연결 기능을 만들지는 않습니다. geoip:private는 해당 비공개 주소 분류를 매칭하고 geosite:category-ads-all은 도메인 분류 데이터를 참조합니다. 리소스가 없거나 분류가 존재하지 않으면 설정을 불러오지 못할 수 있습니다. 규칙의 태그, 필드, 리소스 파일을 하나의 묶음으로 확인하세요. JSON 구문 검사를 통과하는지만 살펴서는 안 됩니다.

도메인 전략과 DNS 해석 위치

IPIfNonMatch는 도메인 규칙에 일치하는 항목이 없을 때 대상 도메인을 해석해 주소 규칙을 추가로 적용할 수 있다는 뜻입니다. 특정 DNS 서버를 지정하는 필드도 아니고 모든 앱이 코어의 DNS를 사용하도록 강제하는 설정도 아닙니다. 앱이 이미 대상 주소를 전달했다면 라우팅 규칙이 예상과 다른 정보를 볼 수 있습니다. 도메인 규칙이 적용되지 않는 문제를 해결할 때는 진입점에서 실제로 전달된 값이 도메인인지 주소인지, 대상 식별에 영향을 주는 관련 기능이 클라이언트에서 켜져 있는지 확인하세요.

V2Ray DNS 설정에서는 DNS 서버에 연결할 수 있는지, DNS 요청이 어떤 아웃바운드를 거치는지, 해석 결과가 어떤 매칭에 사용되는지를 함께 고려해야 합니다. DNS 주소를 바꿔도 모든 연결 문제가 자동으로 해결되지는 않으며 기존 캐시가 즉시 갱신된다는 보장도 없습니다. 먼저 원래 설정을 기록하고 테스트 대상 하나에서 DNS와 연결 로그를 비교하세요. 암호화된 DNS를 사용하면 DNS 서버 이름을 먼저 해석해야 할 수도 있습니다. 아직 설정되지 않은 프록시 경로에 DNS 해석이 의존하는 순환 구조는 피하세요.

사용자 지정 도메인 규칙에서는 full:로 도메인 전체를 정확히 매칭하고 domain:으로 도메인과 하위 도메인 범위를 지정할 수 있습니다. 키워드와 정규식 매칭은 범위가 더 넓으므로 잘못 매칭되는 항목이 없는지 추가로 확인해야 합니다. 구체적인 규칙 하나를 먼저 추가해 검증한 뒤 적용 범위를 넓히세요. 자세한 내용은 사용자 지정 라우팅 구문과 우선순위를 참고하세요. 규칙을 많이 만드는 것이 이 장의 목표는 아닙니다. 대상이 특정 규칙에 매칭되는 이유를 설명하고 규칙을 삭제해 원래 동작으로 복구할 수 있어야 합니다.

7. TUN 전체 연결: 권한, 라우팅, 충돌 해결

기본 프록시가 작동한 뒤에만 활성화하기

TUN은 가상 네트워크 인터페이스를 통해 시스템 라우팅이 전달하는 트래픽을 받으며, 일반 시스템 프록시가 처리하지 못하는 앱에 사용할 수 있습니다. TUN은 트래픽이 클라이언트에 들어오는 방식을 바꾸지만 작동하지 않는 서버를 고쳐 주지는 않으며 모든 연결이 프록시 아웃바운드를 사용해야 한다는 뜻도 아닙니다. 활성화하기 전에 일반 진입 방식으로 연결을 확인하고 정상 작동하는 설정을 보존하세요. 그렇지 않으면 서버, 인터페이스, DNS 문제가 한꺼번에 발생해 새 오류의 원인을 찾기 어렵습니다.

클라이언트의 TUN 스위치는 특정 구성 요소, 실행 권한, 시스템 기능에 의존할 수 있으며 플랫폼별 구현을 그대로 비교할 수는 없습니다. v2rayN의 데스크톱 네트워크 연결 방식은 Android 시스템의 네트워크 연결 권한 부여 방식과 다릅니다. 현재 클라이언트의 안내에 따라 권한을 허용한 다음 로그에서 인터페이스와 라우팅이 실제로 설정됐는지 확인하세요. 화면에 스위치가 켜져 있어도 인터페이스 생성이나 라우팅 설정에 실패하면 요청은 예상한 경로로 들어가지 않을 수 있습니다.

활성화 전후를 비교해 테스트하기

테스트 전에 네트워크 연결을 대신 처리할 수 있는 다른 도구를 끄고 시스템 프록시가 여전히 켜져 있는지 기록하세요. 함께 사용할 수 있는 조합도 있지만 처음 확인할 때는 진입점을 최소화해야 합니다. 시스템 프록시를 따르지 않는 테스트 앱 하나를 선택하고 TUN을 켠 뒤 새 연결을 시작해 코어 로그를 살펴보세요. 같은 앱이 원래 명시적 프록시를 사용했다면 성공해도 TUN이 해당 앱을 처리했다는 증거가 되지 않습니다. 진입 방식의 변화를 확인할 수 있는 테스트 조건을 사용하세요.

라우터 관리 페이지, LAN 기기, 직접 연결이 필요한 내부 서비스 등 로컬 네트워크 접근은 따로 테스트해야 합니다. TUN이 라우팅을 바꾸면 이러한 대상이 원격 아웃바운드로 잘못 전달될 수 있습니다. 서버를 계속 바꾸지 말고 클라이언트가 지원하는 제외 및 분기 설정을 사용하세요. 비공개 주소 직접 연결 규칙이 도움이 될 수 있지만 시스템 라우팅과 기기의 실제 주소 범위를 확인하는 것까지 대신하지는 못합니다. 특수한 네트워크에는 추가 내부 주소 대역이 있을 수 있습니다.

DNS, 루프백, 기존 가상 인터페이스

앱이 기존 시스템 DNS 리졸버로 계속 조회 요청을 보내는 동안 가상 인터페이스가 요청 경로를 바꿀 수 있어 TUN과 DNS는 밀접하게 연결됩니다. DNS 요청을 가로챌지, 어떻게 처리할지는 사용 중인 구현과 클라이언트 설정을 확인하세요. 다른 코어의 DNS 필드를 현재 설정에 그대로 붙여 넣거나 서로 덮어쓰는 여러 DNS 방식을 동시에 활성화하지 마세요. DNS 옵션을 하나 추가할 때마다 도메인 해석과 대상 연결을 다시 확인하세요.

프록시 자체 연결이 다시 가로채져 라우팅 루프가 발생할 수도 있습니다. 일반적으로 잘 만들어진 연결 기능은 자체 트래픽을 처리하지만, 라우팅, 인터페이스, 아웃바운드 바인딩을 수동으로 수정하면 이 전제가 깨질 수 있습니다. TUN을 켠 뒤 갑자기 서버에 연결할 수 없다면 먼저 TUN을 끄고 일반 프록시가 복구되는지 확인하세요. 일반 모드는 되지만 TUN만 실패한다면 구독을 다시 가져오기보다 로컬 연결 경로부터 점검하는 것이 좋습니다.

모바일 기기는 백그라운드 제한, 절전 상태, 네트워크 전환도 살펴봐야 합니다. 앱을 열어 둔 동안에는 연결되지만 화면을 잠근 뒤 끊긴다면 시스템 절전이나 백그라운드 정책이 원인일 수 있습니다. Wi-Fi에서 모바일 네트워크로 전환한 뒤 실패한다면 전환 전후의 로그와 권한 상태를 비교하세요. 백그라운드 설정을 변경하기 전에 시스템에 실제로 어떤 옵션이 있는지 확인하세요. 앱을 계속 전면에 둔다는 임시 방법을 장기적인 해결책으로 삼거나, 동작 주기를 살펴보는 대신 반복해서 다시 설치하지 마세요.

이 장을 마치면 일반 진입, TUN 진입, 종료 후 복구를 각각 확인할 수 있어야 합니다. 필요한 권한, 유지할 제외 규칙, 시스템 프록시를 함께 사용하는지 기록하세요. 아직 네트워크 연결 기능이 필요하지 않은 기기라면 일반 프록시만 사용하는 것도 완전한 설정입니다. 더 많은 스위치를 켜기 위해 복잡성을 늘릴 필요는 없습니다. TUN은 분명한 트래픽 연결 문제를 해결하는 수단이지, 클라이언트 설정이 올바른지 판단하는 유일한 기준이 아닙니다.

8. 유지 관리: 업데이트, 로그, 설정 백업

업데이트 대상별로 나눠 진행하기

클라이언트 프로그램, 실행 코어, 구독 정보, 라우팅 리소스는 각각 다른 유지 관리 대상입니다. 프로그램 업데이트는 인터페이스와 설정 생성 방식에 영향을 주고, 코어 업데이트는 프로토콜과 필드 해석에 영향을 주며, 구독 업데이트는 서버 항목을 바꾸고, 리소스 업데이트는 분류 매칭에 영향을 줍니다. 모두 한꺼번에 바꾸면 문제가 발생했을 때 원인을 빠르게 찾을 수 없습니다. 한 번에 한 종류씩 업데이트하고 기본 테스트를 마친 뒤 다음 항목으로 넘어가세요. 업데이트 전 정상 작동 상태도 기록해 두세요.

업데이트 전에 클라이언트가 지원하는 내보내기 또는 백업 기능으로 설정을 저장하고, 백업에 어떤 항목이 포함되는지 확인하세요. 일부 내보내기는 서버 정보만 저장하고 DNS, 라우팅, 시스템 동작은 포함하지 않습니다. 구독 인증 정보와 사용자 ID가 포함될 수 있는 백업은 민감한 자료로 관리해야 합니다. 복구 가능한 백업은 파일 하나만 보관한다고 완성되는 것이 아닙니다. 복구 메뉴, 클라이언트 종류, 설정 저장 위치, 수동으로 다시 구성해야 할 항목을 기록하세요.

로그로 문제 발생 계층 확인하기

문제가 생기면 발생 시각, 테스트 앱, 대상, 마지막 변경 사항을 먼저 기록한 뒤 코어 시작 출력과 실행 오류를 확인하세요. 시작하자마자 종료되면 설정과 로컬 파일부터 확인합니다. 요청 기록이 없으면 진입 방식을 살펴봅니다. 요청은 기록되지만 연결 시간이 초과되면 원격 서버의 연결 가능 여부와 아웃바운드를 확인합니다. 도메인 해석 오류는 DNS 경로를 다시 확인해야 합니다. 로그는 문제를 특정하기 위한 증거이며 ‘오류’라는 단어가 있는 모든 기록을 같은 원인으로 간주하면 안 됩니다.

접속 로그는 요청과 경로를 확인하는 데 쓰이고 오류 로그는 예외와 실행 문제를 기록하지만, 클라이언트에 따라 둘이 합쳐져 표시될 수 있습니다. 재현을 위해 일시적으로 로그 상세 수준을 높일 수 있지만 테스트가 끝난 뒤에는 일상 사용에 적합한 수준으로 되돌려 불필요한 기록이 쌓이지 않도록 하세요. 로그를 공유하기 전에 구독 쿼리 매개변수, 사용자 ID, 비공개 대상 정보를 지우세요. 진단에 필요한 시간 순서, 오류 유형, 관련 필드 이름은 남겨야 문제 해결과 정보 보호를 모두 할 수 있습니다.

변수 하나씩 재현하고 되돌리기

서버 하나와 앱 하나로 문제를 재현하고 매번 설정 하나만 바꾸세요. 수정 후에는 기존 장기 연결에 의존하지 말고 새 연결을 시작합니다. 변경 전후의 차이를 기록하고 성공한 뒤 다른 앱과 규칙을 다시 추가하세요. 변경해도 나아지지 않으면 다음 작업 전에 원래대로 되돌립니다. 그렇지 않으면 설명할 수 없는 설정 조합이 남게 됩니다. 결국 연결이 복구되더라도 어떤 설정이 필요한지 알 수 없습니다.

구독에 표시되는 지연 시간이나 연결 테스트는 특정 방식으로 측정한 결과일 뿐, 대상 서비스의 전체 접속 품질을 나타내지 않습니다. 테스트가 실패하면 연결 가능 여부, 핸드셰이크, 특정 요청 중 무엇을 확인하는지 먼저 알아보세요. 실제 앱 동작에는 DNS, 라우팅, UDP, 서버 정책이 영향을 줄 수 있습니다. 유지 관리 기록에는 테스트 숫자만 적지 말고 어떤 경로에서 어떤 앱이 작동했는지 남기세요. 이를 바탕으로 전체 네트워크 성능을 추정해서도 안 됩니다.

업데이트 후 문제가 생기면 기존 설정이 이전되었는지, 현재 어떤 프로그램 사본을 실행하는지, 시스템 프록시가 새 수신 주소를 가리키는지 먼저 확인하세요. 이전 상태로 되돌릴 때는 저장해 둔 설정과 적절한 설치 경로를 이용하고 새 프로그램과 이전 프로그램을 동시에 실행하지 마세요. 바로 원인을 찾기 어렵다면 최소 작동 모드로 복구한 뒤 각 장을 참고해 라우팅과 TUN을 다시 추가하세요. 이렇게 하면 사용 상태를 복구하면서 안정적인 비교 환경도 유지할 수 있습니다.

로그 필드가 낯설다면 실행 로그 의미 안내를 확인하세요. 이 장의 완료 기준은 복구 가능한 백업, 재현 가능한 테스트 경로, 민감 정보가 제거된 오류 기록입니다. 유지 관리의 목적은 매개변수를 계속 바꾸는 것이 아니라 모든 변경을 설명하고 검증하며 되돌릴 수 있게 하는 것입니다. 우연히 복구된 것을 원인을 찾은 것으로 착각하지 마세요.

9. 고급 설정: 프로토콜 범위와 설정 검증

먼저 설정 관리 주체 정하기

고급 설정에 들어가기 전에 클라이언트가 생성하는 항목과 사용자가 계속 관리할 항목을 구분하세요. 그래픽 클라이언트는 일반적으로 화면 설정을 바탕으로 코어 실행 설정을 생성합니다. 생성된 파일을 직접 편집하면 서버를 바꾸거나 프로그램을 다시 시작할 때 수정 내용이 덮어써질 수 있습니다. 사용자 지정 라우팅, 템플릿, 클라이언트가 명시적으로 제공하는 설정 메뉴를 우선 사용하세요. 전체 설정을 직접 관리해야 한다면 구독, 서버 선택, 화면 설정과의 관계를 이해하고 같은 필드를 두 설정 출처에서 동시에 제어하지 않도록 하세요.

일반 작동 설정을 유지하고 별도의 실험 설정을 만들어 필요한 기능을 하나씩 테스트하세요. 실험마다 기대 결과, 확인 방법, 복구 절차를 기록합니다. 예를 들어 도메인 규칙을 연구한다면 서버, DNS, 진입 방식을 고정하고 매칭 조건 하나만 바꾸세요. TUN을 연구할 때는 이미 작동하는 라우팅과 아웃바운드를 그대로 유지합니다. 실험은 옵션을 많이 모으는 것이 아니라 원인과 결과의 관계를 확인하는 과정입니다. 이후 문제가 생겼을 때 증거를 바탕으로 범위를 좁힐 수 있어야 합니다.

프로토콜 매개변수는 계층별로 익히기

프로토콜은 인증, 전송, 보안 계층을 나눠 살펴보세요. VMess와 VLESS는 인증과 암호화 역할이 다르므로 프로토콜 이름 하나를 바꾼다고 서로 변환되지 않습니다. Trojan에도 고유한 연결 조건이 있습니다. WebSocket의 경로와 호스트 필드, gRPC의 서비스 이름, TLS 서버 이름, REALITY에 필요한 매개변수는 서버 설정과 하나씩 대조해야 합니다. 출처에서 제공하지 않은 필드를 경험에 기대어 추측하지 마세요. 가져오기에 성공해도 모든 조합이 실행 중에 작동한다는 뜻은 아닙니다.

프로토콜 호환성은 클라이언트가 사용하는 코어와 설정 생성 방식에도 영향을 받습니다. 인터넷에서 찾은 설정이 다른 코어용 필드를 사용할 수 있으며 JSON 구문이 맞아도 현재 환경에서는 알 수 없는 필드 오류가 나거나 다른 의미로 해석될 수 있습니다. 새 기능을 시험하기 전에 어떤 코어 계열에 속하는지 확인하고 현재 클라이언트에서 해당 설정을 제공하는지 살펴보세요. 기본 비교는 VMess와 VLESS의 차이를 먼저 읽은 뒤 실제 설정을 계층별로 확인하면 됩니다.

규칙 검증에서 유지 관리 가능한 설정으로

복잡한 규칙은 특정 서비스를 고정 아웃바운드로 보내거나 LAN은 직접 연결로 유지하거나 특정 분류를 차단하는 등 분명한 요구에 따라 추가해야 합니다. 각 규칙의 목적과 예상 매칭 범위를 기록하고 더 이상 유효하지 않은 예외는 정기적으로 정리하세요. 겹치는 규칙이 많아지면 순서를 파악하기 어려워지고 리소스를 업데이트한 뒤 매칭 결과가 바뀔 수도 있습니다. 동작을 설명하기 어렵다면 범위가 더 넓은 규칙을 계속 추가하기보다 검증할 수 있는 소수의 규칙만 남기세요.

DNS 고급 테스트도 관찰 대상을 명확히 해야 합니다. 앱이 요청한 이름, 코어가 수행한 조회, 라우팅에서 사용하는 대상 주소는 서로 다른 단계의 데이터일 수 있습니다. 이름 해석 실패, 예상과 다른 응답, 연결할 수 없는 주소를 각각 구분해 기록하세요. DNS 정책을 바꾸면 기존 캐시와 장기 연결이 이전 동작을 계속 사용할 수 있으므로 새 연결로 다시 테스트해야 합니다. 페이지를 한 번 새로 고치는 것만으로 전체 해석 경로가 바뀌었다고 판단할 수는 없습니다.

마지막으로 브라우저 일반 요청, 원래 시스템 프록시를 따르지 않는 앱, LAN 접속, 구독 업데이트, 종료 후 네트워크 복구를 확인하는 고정 회귀 테스트를 마련하세요. 새로운 기능만 테스트해서는 부족합니다. 규칙을 추가하면 기존 경로가 깨질 수 있고 DNS 설정을 바꾸면 구독 가져오기에 영향을 줄 수도 있습니다. 회귀 테스트는 간단해도 되지만 조건이 일정해야 하며 테스트 대상과 성공 기준이 명확해야 변경 전후의 차이를 비교할 수 있습니다.

이 가이드를 제대로 익혔다는 것은 연결이 어디로 들어오는지, 어떤 규칙에 따라 아웃바운드를 선택하는지, 이름을 어디에서 해석하는지, 문제가 생겼을 때 어떻게 복구하는지 설명할 수 있다는 뜻입니다. 이후에는 자주 묻는 질문에서 증상별로 찾아보거나 빠른 시작 가이드로 돌아가 최소 설정을 다시 구성할 수 있습니다. 작동하는 기준 상태를 유지하고 실험 결과를 일상 설정에 하나씩 반영하는 편이 출처와 동작을 설명할 수 없는 복잡한 설정을 계속 사용하는 것보다 관리하기 쉽습니다.