V2Ray 사용 설명서: 설치 및 설정

01 / concepts

핵심 개념: 트래픽이 거치는 단계부터 파악하기

클라이언트, 코어, 서버

V2Ray는 Project V 생태계의 프록시 기술 체계이며, 데스크톱 앱 하나를 뜻하지 않습니다. v2rayN은 노드와 구독, 라우팅, 실행 매개변수를 관리하는 그래픽 인터페이스를 제공합니다. 코어는 로컬 포트를 열고 요청을 처리해 원격 연결을 설정합니다. 클라이언트 창이 정상적으로 열렸다는 사실만으로는 인터페이스 프로그램의 실행 여부만 알 수 있으며, 코어가 정상적으로 시작됐는지는 판단할 수 없습니다.

V2Fly는 V2Ray 코어 개발을 이어가며, Xray도 관련 코어 계열에 속합니다. 두 코어가 지원하는 기능은 완전히 같지 않습니다. 클라이언트에서 같은 형식의 노드 정보를 저장할 수 있어도, 실제 작동 여부는 선택한 코어에 따라 달라집니다. VLESS, REALITY 또는 특정 흐름 제어를 사용하는 경우에는 서버 설정에 맞는 코어를 선택하세요. 프로토콜 이름만으로 호환성을 판단하면 안 됩니다.

원격 서버는 요청이 로컬 프록시 경로를 벗어나는 종착점입니다. 클라이언트를 설치해도 서버 주소와 인증 정보, 구독이 자동으로 제공되지는 않습니다. 노드 출처는 직접 확인해야 하며, 이 가이드는 소프트웨어 설정만 다룹니다. 연결 문제는 로컬 프로그램, 네트워크 경로, 서버 중 어느 단계에서든 발생할 수 있으므로 원인을 나누어 확인해야 합니다. 모든 문제를 클라이언트 탓으로 돌리지 마세요.

진입점, 라우팅, 출구

일반적인 요청은 앱에서 로컬 SOCKS 또는 HTTP 진입점으로 전달되고, 코어가 라우팅 규칙에 따라 출구를 선택한 다음 직접 연결 또는 프록시 출구로 전송됩니다. 시스템 프록시는 해당 설정을 참조하는 앱에만 영향을 줍니다. 라우팅 규칙은 코어에 들어온 트래픽을 처리하므로, 규칙을 바꿔도 원래 프록시를 사용하지 않는 프로그램이 자동으로 클라이언트에 연결되지는 않습니다.

노드 목록의 항목에는 보통 서버 주소와 원격 포트, 프로토콜, 인증 정보, 전송 방식, 보안 계층 매개변수가 포함됩니다. 로컬 수신 포트는 진입점 설정이며 원격 포트와는 다릅니다. 서버 포트를 브라우저의 로컬 프록시 설정에 입력하거나 로컬 포트를 노드 주소에 넣으면 요청이 잘못된 곳으로 전달됩니다.

‘연결’도 여러 단계를 뜻할 수 있습니다. 클라이언트에서 노드를 선택한 상태, 코어 프로세스가 실행 중인 상태, 서버 연결이 설정된 상태, 대상 웹사이트에서 콘텐츠를 받은 상태는 각각 다릅니다. 한 번 테스트에 성공했다고 모든 앱이 프록시를 사용한다는 뜻은 아닙니다. 웹사이트 하나가 열리지 않는다고 노드 전체가 작동하지 않는 것도 아닙니다. 먼저 어느 단계에서 실패했는지 구분해야 다음 점검 방향을 정할 수 있습니다.

프로토콜, 전송 방식, 보안 계층

VMess, VLESS, Trojan, Shadowsocks는 서로 다른 프록시 프로토콜을 나타냅니다. TCP와 WebSocket 등은 전송 방식이며 TLS와 REALITY는 연결 보안 및 핸드셰이크 조건과 관련됩니다. 이 항목들은 임의로 조합할 수 있는 선택지가 아닙니다. 클라이언트와 서버의 필수 항목이 서로 일치해야 하며, 한쪽의 설정을 바꾸면 다른 쪽도 함께 변경해야 하는 경우가 많습니다. 한쪽에서 체크만 한다고 적용되는 것은 아닙니다.

프로토콜 이름만으로 속도를 비교할 수는 없습니다. 실제 성능은 회선 상태, 서버 부하, 전송 오버헤드, 대상 서비스, 로컬 네트워크의 영향을 받습니다. 먼저 호환성을 확인한 다음 같은 환경에서 안정성을 비교하세요. 인증서 검증을 끄거나 핸드셰이크 매개변수를 임의로 바꾸는 것은 정상적인 성능 최적화가 아닙니다. 해당 항목이 필요한 이유부터 확인해야 합니다.

02 / clients

클라이언트 선택: 플랫폼과 호환성 확인

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

Windows, macOS, Linux 데스크톱에서는 v2rayN을 사용하세요. 노드 관리, 구독 업데이트, 로컬 진입점, 라우팅 설정을 그래픽 인터페이스에서 한곳에 관리할 수 있어 이 가이드의 주요 예제로 다룹니다. 여러 플랫폼을 지원한다고 해서 운영체제별 동작이 모두 같은 것은 아닙니다. 실행 권한, 시스템 프록시 적용 방식, 가상 네트워크 어댑터 지원, 설정 저장 위치는 운영체제와 설치 방법에 따라 달라집니다.

Windows 다운로드에는 데스크톱 버전과 클래식 WPF 버전이 있습니다. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하며 WPF 버전은 기존 Windows 인터페이스를 유지합니다. 처음 설치한다면 데스크톱 버전부터 사용해 볼 수 있습니다. 기존 WPF 사용 방식이나 설정이 필요한 경우에는 현재 인터페이스와 기능을 비교하세요. 두 버전이 동시에 시스템 프록시를 제어하게 하지 말고, 백업 없이 같은 쓰기 가능 설정 폴더를 공유하지 마세요.

macOS에서는 프로세서에 맞춰 Apple Silicon 또는 Intel 설치 파일을 선택해야 합니다. 칩 정보는 시스템의 ‘이 Mac에 관하여’에서 확인할 수 있습니다. Linux에서는 프로세서와 배포판의 패키지 형식을 함께 고려하세요. 일반적인 데스크톱 컴퓨터는 대부분 x64이고 일부 기기는 arm64를 사용합니다. deb와 rpm은 패키지 관리 형식이며 코어의 프로토콜 지원과는 관계가 없습니다. 파일 이름만 바꿔 서로 다른 형식을 대신 설치할 수도 없습니다.

Android 클라이언트 선택과 데스크톱의 차이

Android에서는 v2rayNG을 우선 사용하세요. V2Fly 코어가 필요하다면 v2flyNG을 고려할 수 있습니다. 최근 기기는 보통 arm64 패키지를 선택하며, 아키텍처를 확인하기 어려운 경우에는 범용 패키지를 고려할 수 있습니다. 최종적으로는 기기의 실제 지원 여부를 확인하세요. 설치에 성공했다고 모든 기능이 호환되는 것은 아닙니다. 프로세서 아키텍처는 프로그램 실행 여부만 결정하며, 노드 프로토콜과 시스템 제한도 별도로 확인해야 합니다.

Android 클라이언트는 보통 시스템 VPN 서비스를 통해 트래픽을 처리하므로 시작할 때 VPN 권한 요청이 표시됩니다. 데스크톱 시스템 프록시와 Android의 VPN 트래픽 처리는 메뉴 이름만으로 비교할 수 없습니다. Android에서는 배터리 최적화, 백그라운드 실행 제한, 다른 VPN 앱의 사용 여부도 확인해야 합니다. 데스크톱에서는 수신 포트 충돌, 권한 부족, 시스템 프록시를 무시하는 앱이 더 흔한 문제입니다.

데스크톱과 Android에서 같은 구독 출처를 가져올 수는 있지만, 양쪽 클라이언트가 모든 항목을 지원한다고 보장할 수는 없습니다. 한쪽에서는 작동하고 다른 쪽에서는 실패한다면 구독이 손상됐다고 단정하지 말고, 파싱된 프로토콜과 전송 방식, 보안 계층, 코어 기능을 먼저 비교하세요. 구독 내용, 클라이언트 설정, 시스템 트래픽 처리 방식은 각각 점검해야 합니다. 기기 간에 복사해도 이 과정을 생략할 수는 없습니다.

클라이언트를 정한 다음 다운로드

클라이언트를 선택할 때 세 가지를 한꺼번에 설치할 필요는 없습니다. 먼저 하나의 클라이언트로 안정적인 기본 설정을 만든 뒤, 호환성 문제가 분명할 때 다른 클라이언트를 시험하세요. 프로그램을 자주 바꾸면 확인할 변수가 늘어납니다. 이전 클라이언트의 시스템 프록시 설정이나 백그라운드 프로세스가 새 프로그램에 영향을 줄 수도 있습니다. 계속 사용할 기기라면 인터페이스를 바꿔 가며 시험하기보다 설정을 복구할 수 있게 유지하는 편이 좋습니다.

다운로드 페이지에서 네 가지 플랫폼별 설치 파일을 확인할 수 있습니다. 페이지를 열기 전에 운영체제, 프로세서 아키텍처, 패키지 형식을 확인하고 다운로드 후 설치 장으로 이동하세요. 기존 사용자가 다른 클라이언트로 옮길 때는 로컬 진입점 포트, 라우팅 설정, 구독 그룹도 기록해야 합니다. 일반 노드 공유 링크에는 이런 정보가 포함되지 않을 수 있으므로 별도로 저장하세요.

03 / installation

설치 확인: 프로그램 실행과 포트 수신

운영체제의 설치 절차 완료하기

Windows에서는 설치 프로그램 안내에 따라 폴더를 선택하고 설치를 마친 다음, 처음 실행할 때 인터페이스와 로그가 정상인지 확인하세요. 클래식 인터페이스와 데스크톱 인터페이스는 설정 저장 위치가 다를 수 있으므로 폴더 이름만 보고 기존 파일을 덮어쓰지 마세요. 추가 실행 환경이 필요한 경우 현재 설치 안내에 따르세요. 오래된 가이드를 보고 구성 요소 이름을 추측하지 말고, 수신 포트를 두고 여러 인스턴스를 동시에 실행하지 마세요.

macOS에서는 칩에 맞는 디스크 이미지를 열고 안내에 따라 앱을 응용 프로그램 폴더로 옮기세요. 시스템 보안 경고가 나타나면 설치 출처와 경고 원인을 확인한 뒤 시스템 설정에서 실행을 허용하세요. 시스템 보안 설정을 계속 낮춰 두는 것을 일반적인 설치 절차로 삼아서는 안 됩니다. 업그레이드 전에 이전 프로세스가 실행 중이라면 종료하고, 새 앱에서 설정을 읽는 위치를 확인하세요.

Linux에서는 배포판의 그래픽 소프트웨어 설치 프로그램으로 deb 또는 rpm 패키지를 열고 해당 패키지 관리자를 통해 의존성을 처리하세요. 설치 후 앱 메뉴에서 실행한 다음 일반 사용자 권한으로 인터페이스와 설정 폴더, 로그를 확인합니다. 추가 권한이 필요한 기능을 사용할 때만 권한을 설정하세요. 그래픽 클라이언트를 항상 높은 권한으로 실행하면 설정 파일과 네트워크 작업의 권한 범위가 불필요하게 넓어집니다.

Android에서는 시스템에서 허용하는 설치 절차에 따라 설치 파일을 열고, 처음 실행한 뒤 노드를 가져온 다음 VPN 권한을 확인하세요. 앱을 설치할 수 없다는 메시지가 표시되면 아키텍처와 저장 공간, 서명이 다른 이전 앱의 존재 여부를 확인합니다. 이전 앱을 삭제하면 앱 데이터가 함께 지워질 수 있으므로 삭제 전에 필요한 설정을 내보내세요. 백업도 하지 않은 상태에서 재설치를 첫 번째 문제 해결 방법으로 삼지 마세요.

코어와 수신 주소 확인

클라이언트 인터페이스가 시작되면 로그에서 코어 시작 결과를 먼저 확인하세요. 유효한 노드가 없으면 클라이언트가 프록시 서비스를 시작하지 않았을 수 있습니다. 오류가 있으면 로그에 나온 첫 번째 관련 오류부터 해결한 뒤 네트워크를 테스트하세요. 포트 점유, 설정 구문 오류, 코어 비호환은 서로 다른 문제입니다. 연결 버튼을 반복해서 눌러도 조건은 바뀌지 않으며 로그만 더 복잡해질 수 있습니다.

로컬 진입점은 127.0.0.1과 같은 루프백 주소에서 수신하도록 설정하는 것이 좋습니다. 이 주소는 이 기기의 요청만 받으므로 기본값으로 적합합니다. ‘LAN 연결 허용’을 켜면 접근 가능한 범위가 달라지며 방화벽과 접근 제어도 함께 고려해야 합니다. 이 기기의 브라우저 연결을 위해 모든 네트워크 인터페이스에서 수신하도록 열지 마세요. 로컬 연결 문제는 보통 LAN 권한과 관련이 없습니다.

ss -tlnp
ss -tlnp 'sport = :10808'

Linux 첫 번째 명령은 TCP 수신 상태를 표시하고, 두 번째 명령은 예시 포트만 확인합니다. 권한이 부족하면 프로세스 이름이 완전히 표시되지 않을 수 있지만, 주소와 포트가 있는지는 먼저 확인할 수 있습니다. 해당 포트에서 수신 중이 아니라면 클라이언트 설정과 시작 로그를 다시 살펴보세요. 다른 프로세스가 포트를 사용 중이면 용도를 확인한 뒤 클라이언트 포트를 바꾸거나 충돌하는 서비스를 중지하세요.

설치 후 점검 기준 만들기

처음 점검할 때는 시스템 프록시와 TUN을 동시에 켜지 말고 트래픽 처리 방식을 하나만 사용하세요. 유효한 노드를 가져온 뒤 로컬 프록시를 명시적으로 지정하는 도구로 코어를 확인하고, 다음으로 시스템 프록시를 테스트합니다. 이 순서를 따르면 ‘프로그램이 수신하지 않음’과 ‘앱이 프록시를 사용하지 않음’을 구분할 수 있습니다. 여러 모드를 한꺼번에 켜면 실패 원인을 파악하기 어렵습니다.

설치 단계의 완료 기준은 인터페이스가 열리고, 유효한 설정으로 코어가 시작되며, 로컬 진입점이 수신하고, 종료 후 네트워크 설정을 복구할 수 있는 상태입니다. 복잡한 분할 라우팅을 서두르지 마세요. 이 단순한 기준을 유지해야 이후 기능을 추가할 때 신뢰할 수 있는 비교 대상이 생깁니다.

04 / subscription

구독 가져오기: 그룹, 업데이트, 노드 확인

구독과 공유 링크 구분하기

구독 링크는 업데이트 가능한 노드 목록을 가리키며, 노드 공유 링크는 보통 하나의 노드 정보를 담습니다. 내용을 복사한 뒤 출처 설명을 확인하고 알맞은 가져오기 방법을 선택하세요. 구독 주소를 단일 노드 링크로 해석하거나 단일 노드 공유 텍스트를 구독 주소 입력란에 넣으면 목록이 비어 있을 수 있습니다. 네트워크 모드를 바꿔도 해결되지 않는 문제입니다.

v2rayN에서 먼저 구독 그룹 설정을 열고 그룹을 추가한 다음 이름과 전체 주소를 입력하세요. 저장 후 해당 그룹의 구독을 업데이트합니다. 이름을 용도나 출처별로 정해 두면 업데이트 오류를 찾기 쉽습니다. 주소의 쿼리 매개변수는 접근 인증에 사용될 수 있으므로 복사할 때 전체 내용을 유지하세요. 줄바꿈이나 따옴표, 끝에 붙은 문장 부호, 채팅 앱이 추가한 공백이 섞이지 않도록 주의하세요.

구독 주소에는 접근 인증 정보가 포함될 수 있으므로 민감한 정보로 취급해야 합니다. 공개 스크린샷에서는 전체 주소를 가리고, 로그를 공유하기 전에 쿼리 매개변수가 포함됐는지 확인하세요. 구독으로 노드 설정을 가져올 수는 있지만 출처가 신뢰할 만하다는 보장은 없습니다. 용도를 모르는 구독이나 QR 코드, 설정 파일은 내용과 출처를 확인한 뒤 클라이언트에 가져오세요.

업데이트 성공이 노드 사용 가능을 뜻하지는 않습니다

업데이트가 끝나면 노드 항목이 나타났는지, 그룹이 올바른지, 프로토콜이 예상과 일치하는지 확인하세요. 구독 요청이 성공했다는 것은 내용을 가져왔다는 뜻일 뿐입니다. 노드가 만료됐거나 서버에 연결할 수 없거나 현재 코어가 지원하지 않는 항목이 포함됐을 수도 있습니다. 먼저 노드 하나를 테스트 대상으로 정하고 그룹, 코어, 라우팅, 시스템 트래픽 처리 방식을 한꺼번에 변경하지 마세요. 비교 기준을 잃지 않도록 해야 합니다.

노드 편집 화면에서 서버 주소, 원격 포트, 인증 정보, 전송 방식, 보안 계층을 확인하세요. WebSocket 경로와 호스트 이름, TLS 서버 이름, REALITY 공개 키 등의 항목을 임의로 지우면 안 됩니다. 구독을 파싱한 뒤 항목이 누락됐다면 출처 형식과 클라이언트 지원 여부를 확인하세요. 보안 검사를 끄는 것으로 누락된 매개변수를 보완할 수는 없습니다.

v2rayNG과 v2flyNG에서도 구독을 구분이 명확한 그룹에 저장한 뒤 업데이트하고 노드를 선택하세요. Android에서는 메뉴 이름이 다를 수 있지만 구독 주소 저장과 프록시 연결 시작은 별개의 작업입니다. 목록을 업데이트한 뒤 현재 선택이 삭제된 항목을 가리키지 않는지 확인하고, 목록이 늘었는지만 보지 말고 시작 로그도 살펴보세요.

구독 업데이트가 실패할 때 확인할 두 가지 네트워크 경로

구독 업데이트 요청은 직접 연결하거나 현재 프록시를 통해 보낼 수 있습니다. 사용할 수 있는 노드가 없다면 출처 안내에 따라 직접 업데이트를 먼저 시도하세요. 안정적으로 작동하는 노드가 있다면 프록시를 통한 업데이트도 시도할 수 있습니다. 두 방법은 요청 경로를 바꾸는 것이며 만료된 주소, 잘못된 인증, 서버의 잘못된 응답 형식을 고쳐 주지는 않습니다. 먼저 로그를 확인한 뒤 요청 방식을 바꾸세요.

목록이 비어 있다면 요청 자체가 실패했는지, 구독 데이터 대신 웹페이지를 받았는지, 형식이 지원되지 않는지, 필터가 항목을 모두 숨겼는지 구분해야 합니다. 로그인 페이지가 반환됐다면 다시 가져와도 유효한 노드는 생기지 않습니다. 그룹 필터 문제라면 목록 범위를 원래대로 복원하세요. 구체적인 오류를 기록하면 무의미한 재시도를 줄이고 출처에 정확한 내용을 전달할 수 있습니다.

여러 기기를 동기화할 때는 구독 출처를 공유하고 시스템 프록시, 포트, 라우팅 등 기기별 설정은 각각 관리하는 것이 좋습니다. 일반 공유 링크에는 모든 전역 설정이 포함되지 않습니다. 자세한 방법은 여러 기기 간 설정 동기화 방법에서 확인하세요. 처음 구독을 가져오는 간단한 절차는 빠른 시작의 구독 단계를 참고하세요.

05 / proxy modes

프록시 모드: 트래픽 처리 방식과 출구 선택

시스템 프록시: 앱이 클라이언트에 연결되는 방식

시스템 프록시는 운영체제에 로컬 HTTP 또는 SOCKS 주소를 등록해 해당 설정을 따르는 앱이 클라이언트를 사용하도록 합니다. 모든 네트워크 패킷을 자동으로 프록시로 보내는 기능은 아닙니다. 일부 브라우저는 시스템 설정을 읽지만, 자체 네트워크 설정을 사용하는 프로그램도 있습니다. 명령줄 도구와 게임, 백그라운드 서비스도 시스템 프록시를 무시할 수 있습니다. 테스트할 때는 앱이 해당 진입점을 지원하는지 확인해야 합니다.

v2rayN에서 시스템 프록시 설정 또는 해제를 선택하면 운영체제에 저장된 프록시 상태가 바뀝니다. 설정한 뒤 로컬 포트가 계속 수신 중인지 확인하고, 해제한 뒤 앱에 별도의 프록시 설정이 남아 있지 않은지 살펴보세요. 일부 프로그램은 시작할 때만 시스템 프록시를 읽으므로 전환 후 다시 실행해야 합니다. 기존 연결은 이전 경로를 계속 사용할 수도 있어 페이지 새로고침만으로 판단할 수 없습니다.

Linux 데스크톱 환경에서는 네트워크 프록시 설정에 수동 프록시 주소를 입력할 수 있습니다. SOCKS 호스트에는 로컬 루프백 주소를, 포트에는 클라이언트의 해당 진입점 포트를 입력하세요. HTTP 항목에는 클라이언트가 제공하는 HTTP 또는 호환 혼합 진입점을 지정해야 합니다. 아무 포트나 모든 프로토콜에 지정하면 안 됩니다. 데스크톱 설정이 터미널 프로세스에도 적용되는지는 프로그램과 환경 변수 처리 방식에 따라 달라집니다.

전체 프록시와 우회 규칙: 트래픽 출구 결정

전체 프록시는 보통 코어에 들어온 대상 요청을 주로 프록시 출구로 보내는 설정입니다. 운영체제의 모든 앱이 트래픽 처리 대상이 된다는 뜻은 아닙니다. 중국 본토 우회와 같은 사전 설정 라우팅은 도메인 및 주소 분류, 규칙 순서에 따라 직접 연결할 요청과 프록시로 보낼 요청을 결정합니다. 두 설정은 서로 다른 계층에서 작동하므로 ‘전체 프록시를 켰는데 특정 프로그램은 여전히 직접 연결된다’고 해서 반드시 코어에 문제가 있는 것은 아닙니다.

처음에는 기본 라우팅을 사용해 자주 접속하는 대상이 열리는지 확인한 다음 용도에 맞게 조정하세요. 웹 브라우징과 일상 업무에서는 로컬 서비스와 원격 서비스를 함께 고려해야 합니다. 개발 도구는 별도로 프록시를 설정해야 할 수 있고, 게임에는 UDP와 서버 지역, 지연 시간도 영향을 줍니다. 모드 이름만 보고 선택하지 말고 앱 트래픽이 진입하는지, 선택한 출구가 요청을 지원하는지 확인하세요.

Android의 VPN 트래픽 처리는 데스크톱 시스템 프록시와 다릅니다. 클라이언트에서 앱별 선택이나 LAN 우회 옵션을 제공할 수 있지만, 이는 코어 라우팅과 별도로 이해해야 합니다. 어떤 앱이 트래픽 처리 대상에서 제외되면 해당 요청은 코어의 도메인 분할 규칙을 거치지 않습니다. 코어 라우팅을 바꿔도 시스템 계층에서 이미 적용한 제외 설정을 덮어쓸 수는 없습니다.

명시적인 진입점으로 트래픽 확인하기

curl -x socks5h://127.0.0.1:10808 -I https://www.example.com

이 명령은 SOCKS 진입점을 명시적으로 지정하므로 프록시 자체와 시스템 프록시 설정을 구분하는 데 적합합니다. socks5h는 대상 호스트 이름 처리를 프록시 측에 맡깁니다. 실제 포트는 클라이언트에서 사용 중인 값으로 바꾸세요. HTTP 응답을 받으면 해당 요청 경로가 작동한 것입니다. 응답 상태 코드는 대상 웹사이트가 결정하므로 특정 코드 하나만으로 전체 네트워크가 정상이라고 판단할 수는 없습니다.

명령에서 로컬 포트에 연결할 수 없다고 나오면 먼저 수신 주소와 포트를 확인하세요. 진입점에는 연결되지만 핸드셰이크가 실패한다면 노드와 로그를 살펴보세요. 명령은 성공하는데 브라우저가 실패한다면 브라우저 자체 프록시와 확장 프로그램, 보안 DNS 설정을 확인하세요. 이 순서로 점검하면 앱 문제를 서버 문제로 오해하지 않고, 처음부터 TUN을 켤 필요도 없습니다.

이 장을 마치면 두 가지를 설명할 수 있어야 합니다. 앱이 어떤 진입점을 통해 클라이언트에 들어오는지, 진입 후 어떤 규칙이 출구를 선택하는지입니다. 두 가지가 분명해야 라우팅을 검증할 수 있습니다.

06 / routing

라우팅: 규칙 순서와 DNS의 범위

명확한 규칙 몇 개부터 시작하기

라우팅 규칙은 요청을 지정된 출구로 보냅니다. 조건에는 도메인, 대상 주소, 포트, 네트워크 유형 등이 있습니다. 규칙은 보통 위에서 아래로 확인하며 먼저 일치한 규칙이 출구를 결정합니다. 따라서 특정 대상에 대한 예외는 범위가 넓은 규칙보다 앞에 두어야 합니다. 모든 대상을 프록시로 보내는 규칙을 먼저 작성하고 아래에 직접 연결 예외를 추가하면 앞선 규칙이 요청을 이미 처리했기 때문에 예상대로 동작하지 않을 수 있습니다.

도메인 규칙에서 full:은 도메인 전체와 일치시키고, domain:은 지정한 도메인과 하위 도메인에 적용하며, geosite:는 도메인 분류 목록을 참조합니다. 접두사가 없는 문자열은 키워드 기준으로 일치할 수 있어 범위가 넓어질 수 있습니다. 처음에는 의미가 명확한 접두사를 사용하세요. 주소 규칙의 CIDR은 네트워크 대역을 나타내며, 분류 목록은 로컬 리소스 파일을 사용합니다. 실시간 조회 서비스가 아닙니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:www.example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

이 코드는 설정 일부이며 그대로 실행할 수 있는 전체 설정 파일은 아닙니다. 사용 전에 현재 코어에 proxy와 direct라는 출구가 있고 필요한 분류 리소스가 있는지 확인하세요. v2rayN의 그래픽 라우팅 인터페이스는 코어 설정을 생성합니다. 규칙을 추가할 때는 인터페이스에 이미 있는 출구에 연결하세요. 클라이언트가 생성한 파일을 직접 덮어쓰면 재시작하거나 노드를 바꿀 때 수정 사항이 다시 쓰일 수 있습니다.

DNS 설정: 도메인 이름을 누가 조회하는지 확인

DNS는 도메인 이름을 주소로 변환하지만 조회는 앱, 운영체제, 코어, 프록시 경로의 다른 쪽에서 수행될 수 있습니다. 브라우저의 보안 DNS와 자체 조회 라이브러리, 시스템 DNS 설정은 각각 별도로 작동할 수 있습니다. 코어 DNS 서버를 바꿔도 모든 앱이 즉시 그 설정을 사용하는 것은 아닙니다. 앱이 이미 도메인을 주소로 변환했다면 도메인 라우팅에서 원래 이름을 확인하지 못할 수도 있습니다.

AsIs는 라우팅 단계에서 주소 규칙에 맞추기 위해 도메인을 능동적으로 조회하지 않는다는 뜻입니다. 다른 도메인 정책은 필요할 때 조회를 유발할 수 있습니다. 코어 DNS 설정, 라우팅의 도메인 정책, 출구의 조회 동작은 서로 관련이 있지만 각각 다른 설정입니다. 주소 규칙이 일치하지 않는다고 DNS 서버 문제로 단정하지 마세요. 요청에 도메인 이름이 들어 있는지 주소가 들어 있는지, 현재 정책이 변환을 수행하는지부터 확인해야 합니다.

문제를 확인할 때는 같은 대상을 앱 직접 연결, 명시적 SOCKS 진입점, 시스템 프록시에서 각각 비교하세요. 브라우저에서만 문제가 생긴다면 브라우저의 DNS 조회와 캐시를 확인합니다. 로그에 조회 시간 초과가 표시되면 DNS 요청의 라우팅과 연결 가능성을 살펴보세요. 조회를 우회하려고 대상 주소를 장기간 직접 입력하지 마세요. 주소 변경, 인증서 이름, 콘텐츠 전송 경로 선택에 영향을 받을 수 있습니다.

규칙 검증과 충돌 해결

라우팅을 변경하기 전에 기존 규칙을 저장하고, 재현 가능한 대상 하나만 처리하는 새 규칙을 추가하세요. 테스트할 때는 웹페이지가 열리는지만 보지 말고 액세스 로그에서 대상과 출구를 확인해야 합니다. 직접 연결과 프록시 모두 성공할 수 있기 때문입니다. 로그에 요청이 없다면 이전 장으로 돌아가 트래픽 처리 방식을 확인하세요. 출구가 예상과 다르면 앞선 규칙, 분류 리소스, 대상 형식을 살펴본 뒤 규칙 순서를 조정합니다.

한 규칙에 여러 조건을 넣으면 보통 모든 조건을 충족해야 합니다. 같은 필드에 여러 후보를 넣으면 대개 그중 하나와 일치하면 됩니다. 도메인과 주소를 함께 넣으면 예상보다 조건이 까다로워질 수 있습니다. ‘도메인 또는 주소와 일치’하는 동작이 필요하다면 규칙을 두 개로 나누는 편이 명확하며 각 조건의 실패 원인도 따로 확인할 수 있습니다.

07 / tun

TUN 모드: 트래픽 처리 범위 확장과 복구 경로 확보

가상 네트워크 어댑터가 필요한 경우

TUN은 가상 네트워크 장치로 네트워크 트래픽을 받아 명시적 프록시를 설정할 수 없거나 시스템 프록시를 무시하는 앱, 더 넓은 트래픽 범위를 처리해야 하는 경우에 적합합니다. 프록시 경로로 들어오는 방식을 바꾸는 기능이지, 사용할 수 없는 노드를 되살리는 기능은 아닙니다. 명시적 SOCKS 테스트가 이미 실패했다면 먼저 노드와 코어 문제를 해결하세요. 그렇지 않으면 TUN을 켜서 같은 문제를 더 많은 앱으로 확대할 수 있습니다.

TUN의 실제 동작은 클라이언트 구현, 사용 코어, 네트워크 스택, 운영체제 권한에 따라 달라집니다. ‘TUN 모드 사용’ 옵션이 표시된다고 현재 환경에 필요한 조건이 모두 갖춰졌다는 뜻은 아닙니다. 클라이언트는 가상 네트워크 어댑터와 라우팅, DNS 처리를 위해 별도 구성 요소를 사용할 수 있으므로 로그에서 실제 시작 결과를 확인하세요. 데스크톱 플랫폼의 구현이 모두 같다고 가정하지 마세요.

활성화하기 전에 현재 사용 중인 노드, 시스템 프록시 상태, 기본 라우트를 기록하고 기능을 끄는 메뉴에 계속 접근할 수 있는지 확인하세요. 원격으로 관리하는 기기에서는 특히 주의해야 합니다. 라우팅 변경으로 현재 세션이 끊길 수 있습니다. 먼저 직접 조작할 수 있는 환경에서 테스트하고, 지속적인 연결이 필요한 기기에서는 프록시 네트워크에 의존하지 않고 실행할 수 있는 복구 방법을 마련하세요.

권한, 라우팅, 루프백

가상 장치와 라우팅을 변경하려면 관리자 권한이 필요할 수 있습니다. Linux에서는 시스템의 TUN 장치와 관련 권한도 확인해야 합니다. macOS와 Windows에서는 시스템 권한 요청이나 구성 요소 설치 안내가 나타날 수 있습니다. 권한 오류가 발생하면 로그에서 실패한 단계를 먼저 찾으세요. 설정 폴더 전체의 권한을 일괄 변경하거나 문제를 감추려고 모든 프로그램을 높은 권한으로 실행하지 마세요.

프록시가 서버에 연결하는 트래픽은 가상 장치를 빠져나갈 수 있어야 합니다. 그렇지 않으면 코어가 생성한 연결이 다시 트래픽 처리 대상이 되어 원격 서버에 도달하지 못하는 루프가 생길 수 있습니다. 자동 라우팅과 제외 기능이 대개 이 문제를 처리하지만, 다른 VPN이나 가상 네트워크 어댑터, 사용자 지정 라우팅과 함께 쓰면 충돌할 수 있습니다. 테스트 전에 다른 트래픽 처리 프로그램을 중지하고 단일 경로부터 확인하세요.

LAN 접근도 별도로 확인해야 합니다. 프린터, 파일 공유, 개발 서버, 라우터 관리 페이지는 로컬 경로를 유지해야 할 수 있습니다. LAN 우회는 모든 알 수 없는 주소를 직접 연결로 보내는 설정이 아니라 로컬 주소 대역과 관련 이름을 적절히 처리하는 기능입니다. 원격 웹사이트는 정상인데 로컬 서비스에 연결되지 않는다면 노드를 바꾸기보다 로컬 라우팅과 DNS를 확인하세요.

모든 기능을 한꺼번에 켜지 말고 단계별로 확인

검증된 노드와 단순한 라우팅을 유지하고 불필요한 시스템 프록시를 해제한 뒤 TUN을 켜고 시작 로그를 확인하세요. 그다음 브라우저, 원래 시스템 프록시를 따르지 않던 앱, LAN 서비스를 차례로 테스트합니다. 이렇게 하면 트래픽 처리 범위가 실제로 넓어졌는지 확인할 수 있습니다. DNS와 분할 라우팅까지 동시에 바꾸면 문제가 가상 장치에서 비롯됐는지 새 규칙에서 비롯됐는지 알기 어렵습니다.

UDP가 작동하려면 앱 트래픽 진입 방식, 코어 처리, 서버 기능까지 전체 경로가 지원되어야 합니다. TUN을 켠다고 모든 UDP 요청이 성공하거나 게임 환경이 좋아지는 것은 아닙니다. 일부 앱은 별도의 인증 서비스, 음성 서비스, 고정 네트워크 인터페이스를 사용하기도 합니다. 웹페이지 하나만 테스트한 뒤 모든 프로토콜이 정상이라고 판단하지 말고 문제가 생긴 기능의 로그를 확인하세요.

절전 모드에서 깨어난 뒤, 무선 네트워크를 바꾼 뒤, 유선 네트워크에 연결한 뒤에는 가상 장치와 기본 라우트를 다시 확인하세요. 네트워크 인터페이스가 바뀌면 기존 상태가 유효하지 않을 수 있으므로 노드를 무작정 바꾸기보다 트래픽 처리 서비스를 다시 시작하는 편이 합리적입니다. 같은 문제가 자주 발생한다면 발생 전후의 인터페이스, 라우팅, 로그를 저장해 재현할 수 있도록 기록한 뒤 TUN을 계속 사용할지 결정하세요.

08 / maintenance

유지 관리: 업데이트, 백업, 문제 기록

세 가지 업데이트 대상은 각각 관리

클라이언트 프로그램, 구독 내용, 라우팅 분류 리소스는 서로 다른 항목입니다. 클라이언트 업데이트는 인터페이스와 기능 구현을 바꾸고, 구독 업데이트는 노드 목록을 바꾸며, 분류 리소스 업데이트는 도메인 또는 주소 규칙에 영향을 줍니다. 문제를 확인하는 동안 이 세 가지를 동시에 변경하지 마세요. 한 종류의 업데이트를 마칠 때마다 기존 기준을 테스트하고 결과를 확인한 뒤 다음 항목을 진행하세요.

클라이언트를 업데이트하기 전에 사용 중인 기능과 관련된 변경 사항을 읽고 필요한 코어와 설정 형식이 계속 지원되는지 확인하세요. 버전 숫자를 따라가려고 자주 재설치할 필요는 없지만 호환성이나 보안 수정 업데이트를 무시해서도 안 됩니다. 업그레이드 후에는 프로그램 창이 열리는지만 확인하지 말고 노드 시작, 구독 파싱, 라우팅 선택, 시스템 트래픽 처리도 점검하세요.

구독 업데이트 주기는 출처가 실제로 얼마나 자주 바뀌는지에 맞추세요. 지나치게 자주 요청해도 인증 오류는 해결되지 않으며 서버에서 제한할 수 있습니다. 업데이트 후 기존 노드가 사라졌다면 정상적으로 교체된 것인지 확인한 뒤 새 항목을 선택하세요. 분류 리소스 업데이트 후 특정 대상의 출구가 바뀌었다면 모든 대상을 전체 프록시로 돌리기보다 적용된 분류와 예외 규칙을 확인해야 합니다.

실제로 복구 가능한 백업 만들기

백업에는 최소한 구독 그룹, 수동 노드, 라우팅 규칙, 주요 전역 설정이 포함되어야 합니다. 가능하면 클라이언트에서 제공하는 내보내기 기능을 사용하세요. 설정 폴더를 복사하기 전에는 프로그램을 종료해 데이터베이스나 설정 파일에 쓰기 작업이 진행 중이지 않도록 합니다. 플랫폼마다 경로와 저장 방식이 다를 수 있으므로 다른 운영체제의 폴더를 기준으로 추측하지 말고 현재 프로그램이 실제로 사용하는 위치를 확인하세요.

설정 백업에는 서버 인증 정보, 구독 접근 자격 증명, 기기별 설정이 포함될 수 있으므로 접근이 제한된 곳에 보관하는 것이 좋습니다. 문제를 논의하기 위해 스크린샷이나 로그를 공유할 때는 별도로 민감 정보를 가린 사본을 만드세요. 원본 백업을 그대로 공개하지 마세요. 새 기기로 옮길 때는 먼저 가져오기를 진행한 뒤 수신 주소와 포트, 권한, 트래픽 처리 방식을 직접 확인하세요. 이전 기기의 환경 설정을 그대로 복사하지 마세요.

복구 가능 여부는 작은 범위의 테스트로 확인해야 합니다. 설정을 내보내고 주요 항목 몇 개를 기록한 다음 별도의 테스트 환경에서 가져와 확인할 수 있습니다. 파일이 있다는 사실만으로는 백업이 유효하다고 할 수 없습니다. 여러 플랫폼 간 복구에서는 호환되지 않는 경로와 프로그램 시작 항목, 권한 필드를 특히 주의해야 합니다. 노드 데이터는 재사용할 수 있어도 시스템 통합 설정은 새로 구성해야 하는 경우가 많습니다.

연결 경로 순서대로 문제 해결

연결 문제가 발생하면 시스템 시간과 기본 네트워크부터 확인한 다음 로컬 진입점, 코어 로그, 노드 연결, DNS, 라우팅 순으로 살펴보세요. 시스템 시간이 크게 틀어지면 핸드셰이크나 인증에 영향을 줄 수 있습니다. 기본 네트워크 자체에 문제가 있다면 먼저 네트워크를 복구하세요. 로컬 포트가 열려 있지 않다면 코어 시작 문제를 해결해야 합니다. 원격 서버나 규칙 분류를 먼저 추측하지 마세요.

문제를 기록할 때 발생 시각, 클라이언트 종류, 사용 중인 코어, 트래픽 처리 방식, 실패한 대상, 오류 원문을 적으세요. ‘안 열림’만으로는 연결 시간 초과와 DNS 조회 실패, 인증서 오류, 앱 자체 오류를 구분하기 어렵습니다. 문제 전후의 로그 중 관련 부분을 순서가 보이도록 추려내고 민감 정보는 가리세요. 로그 수준을 높이는 것은 짧은 진단에만 사용하고 작업이 끝나면 평소 수준으로 되돌리세요.

유지 관리 과정에서는 오래 남아 있는 설정도 확인해야 합니다. 더 이상 쓰지 않는 구독과 중복 노드, 임시 규칙, 이전 시작 항목은 각각 용도가 분명해야 합니다. 삭제하기 전에 백업하고 정리한 뒤 다시 검증하세요. 출처를 모르는 설정을 겹쳐 두지 않으면 이후 문제를 더 쉽게 찾을 수 있고, 백그라운드의 이전 프로그램이 더 이상 필요하지 않은 시스템 프록시 상태를 되살리는 것도 막을 수 있습니다.

09 / next steps

고급 설정: 작동하는 설정에서 이해할 수 있는 설정으로

사용자 지정 전에 생성된 설정부터 확인

고급 설정은 스위치를 더 많이 켜는 데서 시작하지 않습니다. 현재 설정을 설명할 수 있어야 합니다. 먼저 클라이언트에서 설정 보기나 로그를 확인할 수 있는 메뉴를 찾아 인바운드, 아웃바운드, 라우팅, DNS의 관계를 파악하세요. 그래픽 인터페이스의 선택 하나가 코어 설정 여러 항목을 생성할 수 있습니다. 이 연결을 이해하면 인터페이스 변경 후 동작이 달라지는 이유를 설명할 수 있고, 임시 생성 파일을 영구 설정의 기준으로 오해하지 않을 수 있습니다.

사용자 지정 설정을 적용하려면 클라이언트가 파일을 어떻게 불러오는지, 그래픽 인터페이스의 어떤 설정이 계속 적용되는지 먼저 확인하세요. 사용자 지정 파일은 인터페이스에서 생성하는 일부 설정 로직을 우회할 수 있으므로, 화면에 표시된 라우팅 모드가 파일의 실제 라우팅을 나타내지 않을 수 있습니다. 전체 사용자 지정 설정을 사용한다면 그래픽 옵션을 직관적으로 해석하기보다 최종적으로 불러온 파일과 실행 로그를 기준으로 확인하세요.

JSON 구문 검사는 첫 단계일 뿐입니다. 괄호와 쉼표, 문자열이 올바르더라도 코어가 해당 항목을 지원하거나 출구 레이블이 일치한다는 뜻은 아닙니다. 먼저 구조를 확인하고 코어 호환성을 검증한 다음 네트워크 동작을 테스트하세요. 새 기능을 추가할 때마다 명확한 테스트 대상을 정해야 합니다. 프로그램이 오류 없이 시작됐다고 모든 경로가 작동한다고 판단하면 안 됩니다.

작업에 맞춰 테스트 설계

개발 도구를 프록시로 연결하려면 도구 자체의 프록시 지원부터 확인한 뒤 시스템 프록시와 명시적 진입점, TUN 중에서 선택하세요. 특정 도메인을 직접 연결하려면 요청에 도메인 이름이 포함되는지 확인하고 별도 예외 규칙을 추가합니다. DNS 결과 차이를 해결하려면 앱과 코어의 조회 경로를 먼저 비교하세요. 알 수 없는 설정을 대량으로 가져오기보다 문제를 하나의 작업으로 한정하는 편이 안정적인 결과를 얻기 쉽습니다.

테스트 전에 어떤 앱에서 어떤 대상을 어떤 진입점과 출구로 연결할지 예상 결과를 적으세요. 테스트 후 로그로 실제 결과를 확인하고 실패하면 이전에 작동하던 설정으로 복구합니다. 이렇게 기록하면 업그레이드나 기기 이전 후에도 다시 검증할 수 있고 설정의 의도와 실제 동작을 구분할 수 있습니다. 테스트 웹사이트에 표시되는 단일 정보만으로 기기의 모든 앱이 어떤 경로를 사용하는지 추정하지 마세요.

성능을 비교할 때도 변수를 통제해야 합니다. 기기와 네트워크, 대상 서비스, 테스트 시간을 최대한 동일하게 유지하고 연결 설정, 지속 전송, 장시간 안정성을 각각 관찰하세요. 한 번의 다운로드 속도로 노드의 전체 성능을 판단할 수 없습니다. 서버 제한과 대상 서버의 혼잡도도 결과에 영향을 줍니다. 지연 시간을 지어내거나 프로토콜 이름만으로 순위를 매기지 말고 반복해서 관찰할 수 있는 결과를 기록하세요.

프로토콜 이해와 보안 범위

VLESS, REALITY, XTLS Vision을 더 자세히 살펴보려면 TLS 핸드셰이크와 인증, 전송 계층의 기본부터 익히세요. REALITY는 클라이언트와 서버가 합의한 핸드셰이크 매개변수를 사용하고, Vision은 특정 흐름 제어 처리를 다룹니다. 둘 다 독립적인 속도 향상 기능이 아닙니다. 노드 출처에서 제공한 항목을 묶어서 확인하고 필수 매개변수가 빠졌다면 설정 요구 사항부터 확인하세요. 가이드를 보고 값을 추측하지 마세요.

REALITY와 XTLS Vision의 작동 원리를 읽어 기술 배경을 이해한 다음 클라이언트에서 사용 중인 코어의 지원 여부를 확인하세요. 기술 해설은 작동 원리를 설명하며 실제 연결은 서버 설정을 따라야 합니다. 학습할 때는 현재 사용 중인 설정을 변경할 필요가 없습니다. 별도의 테스트 항목을 만들어 일상적인 사용에 영향을 주지 않도록 하세요.

프록시가 앱 자체의 보안 기능을 대체하지는 않습니다. 웹사이트 신원 확인과 계정 인증, 파일 출처, 기기 권한은 각각 따로 관리해야 합니다. LAN 연결 허용, 로컬 진입점 개방, 출처를 모르는 사용자 지정 설정 가져오기는 접근 범위와 실행 결과를 먼저 확인해야 합니다. 경험을 공유할 때는 필요한 구조만 보여 주고 민감 정보를 가리세요. 개인 서비스에 바로 접근할 수 있는 인증 정보를 첨부해서는 안 됩니다.

간단하게 작동하는 설정을 기준으로 보관한 뒤 필요한 기능을 하나씩 추가하세요. 각 설정에 용도와 검증 방법, 되돌리는 절차가 있어야 유지 관리하기 쉬운 설정이라고 할 수 있습니다. 모든 고급 기능을 한꺼번에 켤 필요는 없습니다.