V2Ray 처음부터 완벽하게 익히는 방법: v2rayN 전체 설정

핵심 개념과 트래픽 경로

먼저 클라이언트, 코어, 서버를 구분하세요

V2Ray을 사용할 때 가장 혼동하기 쉬운 대상은 그래픽 클라이언트, 프록시 코어, 원격 서버입니다. v2rayN, v2rayNG, v2flyNG는 그래픽 클라이언트로, 구독 저장, 서버 목록 표시, 실행 설정 생성, 프록시 모드 전환을 담당하며 사용자의 조작을 코어가 이해할 수 있는 매개변수로 바꿉니다. Xray와 V2Fly는 코어 계열로, 주로 로컬 포트를 수신하고 아웃바운드 연결을 만들며 라우팅 매칭과 다양한 전송 방식을 처리합니다. 구독 제공업체가 설정한 원격 서버는 연결 경로의 반대편에서 클라이언트가 보낸 프로토콜 연결을 받습니다. 그래픽 인터페이스에 ‘실행 중’이라고 표시되는 것은 로컬 코어 프로세스가 실행 중이라는 뜻일 뿐, 원격 서버에 반드시 연결된다는 의미는 아닙니다. 구독 업데이트 성공 역시 주소에서 해석 가능한 내용이 반환되었다는 뜻일 뿐, 모든 노드가 연결된다는 의미는 아닙니다.

이 세 계층을 이해하면 문제를 경계별로 나누어 해결할 수 있습니다. 프로그램이 열리지 않으면 먼저 클라이언트 설치와 시스템 의존성을 확인하고, 코어 실행에 실패하면 로컬 로그와 포트 점유를 확인하세요. 서버 테스트에 실패하면 노드 매개변수, 네트워크 연결 가능 여부와 시스템 시간을 점검하고, 브라우저가 여전히 일반 네트워크를 사용하면 시스템 프록시나 TUN이 해당 애플리케이션을 실제로 인계했는지 확인해야 합니다. 모든 문제를 ‘노드를 사용할 수 없음’으로 뭉뚱그리면 핵심 단서를 놓치고 불필요한 재설치를 반복하게 됩니다.

요청은 어떻게 애플리케이션을 빠져나가는가

v2rayN의 시스템 프록시 모드를 예로 들어 보겠습니다. 브라우저가 먼저 운영체제의 프록시 설정을 읽은 다음, 요청을 로컬에서 HTTP 또는 SOCKS 인바운드 포트를 수신하는 v2rayN으로 전달합니다. 코어는 요청을 받으면 routing에 위에서 아래 순서로 배치된 규칙에 따라 도메인, IP, 포트, 프로토콜 또는 인바운드 태그를 확인합니다. 규칙이 매칭되면 요청은 지정된 아웃바운드로 전달됩니다. 현재 선택한 프록시 서버일 수도 있고, direct 직접 연결 출구나 block 차단 출구일 수도 있습니다. 어떤 규칙에도 매칭되지 않으면 설정의 기본 아웃바운드로 들어갑니다. DNS 조회는 애플리케이션, 시스템 또는 코어에서 수행될 수 있으므로 ‘도메인이 직접 연결 규칙에 매칭됐는데도 결국 프록시를 사용함’과 같은 현상은 도메인 해석 결과와 매칭 단계에서 비롯되는 경우가 많습니다.

프로토콜, 전송 계층, 보안 계층은 서로 다른 매개변수입니다

VMess, VLESS, Trojan 등은 일반적으로 노드가 사용하는 프록시 프로토콜을 뜻하고, TCP, WebSocket, gRPC 등은 전송 방식의 운반 계층을 뜻합니다. TLS, REALITY 등은 연결 인증 또는 보안 계층에 사용됩니다. 노드를 가져온 뒤에는 이 필드들을 서버 설정과 하나씩 일치시켜야 하며, 주소와 포트만 남겨 임의로 조합해서는 안 됩니다. 예를 들어 한 노드가 VLESS, TCP, REALITY를 사용한다면 flow, serverName, publicKey, shortId 등의 필드가 함께 연결 성립 여부를 결정할 수 있습니다. 어느 한 항목이라도 바꾸면 실제 요청에 도달하기 전에 핸드셰이크가 종료될 수 있습니다. 초보자에게 가장 안전한 원칙은 공유 링크나 구독을 완전한 형태로 가져오고, 필드의 의미를 이해하기 전에는 전송 매개변수를 직접 수정하지 않는 것입니다.

지연 시간, 연결 가능 여부와 실제 속도

클라이언트의 지연 시간 테스트는 대개 대상에 연결할 수 있는지와 핸드셰이크에 걸리는 대략적인 시간을 판단하는 용도이며, 지속적인 전송 속도를 의미하지 않습니다. 테스트 방식에 따라 TCP 핸드셰이크, 실제 프로토콜 요청 또는 지정된 웹사이트를 사용할 수 있으므로 같은 노드가 클라이언트마다 다른 결과를 보이는 것은 이상하지 않습니다. 지연 시간이 짧은 노드가 장시간 연결에서 불안정할 수도 있고, 지연 시간이 조금 더 긴 노드가 더 넉넉한 가용 대역폭을 제공할 수도 있습니다. 노드를 선택할 때는 단일 수치만으로 정렬하지 말고 연속 연결 성공 여부, 웹페이지 첫 응답의 안정성, 장시간 사용 중 잦은 끊김 여부를 함께 확인하세요. 이러한 계층적 이해가 이후의 구독 관리, 분할 라우팅과 TUN 설정의 기반이 됩니다.

클라이언트 선택 및 설치

운영체제에 맞는 클라이언트 선택

데스크톱 환경에서는 v2rayN을 우선 추천합니다. Windows, macOS, Linux를 지원하며 구독 관리, 시스템 프록시 전환, 라우팅 설정과 TUN 활성화를 할 수 있어 여러 데스크톱 기기의 사용 방식을 통일하기 좋습니다. Android에서는 v2rayNG를 우선 추천합니다. Xray 코어를 사용하며 모바일 연결 흐름에 맞춘 인터페이스를 제공합니다. V2Fly 코어가 필요하다면 v2flyNG를 선택할 수 있습니다. 세 클라이언트는 용도가 다르므로 같은 기기에서 동시에 실행할 필요가 없습니다. 여러 클라이언트가 같은 로컬 포트를 동시에 수신하거나 시스템 프록시를 동시에 제어하려 하면 원인을 파악하기 어려운 포트 충돌과 상태 덮어쓰기가 발생합니다.

아키텍처, 설치 방식과 디렉터리 권한

설치하기 전에 운영체제 아키텍처를 확인하세요. Windows의 일반적인 데스크톱 기기는 x64를 사용합니다. macOS에서는 ‘이 Mac에 관하여’에서 칩 유형을 확인해야 합니다. 최근 Android 기기는 대체로 arm64를 사용하지만 확실하지 않다면 범용 버전을 선택할 수 있습니다. Linux에서는 uname -m을 실행해 아키텍처를 확인할 수 있으며, 출력값 x86_64는 x64, aarch64는 arm64에 해당합니다. 아키텍처가 맞지 않으면 설치 프로그램이 실행을 거부하거나 시스템에서 형식 오류를 표시하거나, 프로그램이 시작 직후 종료되는 일이 흔합니다.

Windows에서는 v2rayN 데스크톱 버전과 클래식 WPF 버전 중 하나를 일상적인 실행入口로 선택해야 합니다. 압축 파일로 설치할 때는 먼저 쓰기 권한이 있는 고정 디렉터리에 완전히 압축을 푼 다음 주 프로그램을 실행하세요. 압축 프로그램의 임시 미리보기 창에서 바로 실행하면 설정 파일, 로그와 코어 파일이 안정적으로 저장되지 않을 수 있습니다. macOS에서는 설치 후 응용 프로그램 디렉터리에서 실행하세요. Linux에서 deb 또는 rpm으로 설치하면 패키지 관리자가 시스템 규칙에 따라 파일을 배치합니다. 의존성 안내가 표시되면 라이브러리 파일을 직접 복사하지 말고 해당 배포판의 패키지 관리자로 의존성을 처리하세요.

첫 실행 시 확인할 항목

처음 실행한 뒤에는 TUN을 바로 활성화하지 마세요. 주 창이 정상적으로 표시되는지, 설정 페이지가 코어를 인식하는지, 로그 창에 지속적인 오류가 나타나는지 확인하고 로컬 수신 포트가 다른 프록시 클라이언트에 점유되지 않았는지도 점검하세요. 그런 다음 설정 하나를 가져와 서버를 선택하고 클라이언트에서 제공하는 연결 테스트를 실행합니다. 일반 시스템 프록시 경로가 안정적으로 작동한 뒤에야 라우팅과 TUN 장으로 넘어가세요. 이렇게 하면 설치 문제와 고급 트래픽 인계 문제를 분리할 수 있습니다.

시스템 권한과 보안 알림 처리 원칙

TUN 드라이버 설치, 시스템 프록시 변경과 방화벽 규칙 저장 과정에서 시스템 권한 확인이 나타날 수 있습니다. 실행 중인 프로그램 이름과 요청 출처를 먼저 확인한 뒤 권한을 승인하세요. 일반 시스템 프록시는 장기간 관리자 권한을 사용할 필요가 없는 경우가 많지만, TUN은 가상 네트워크 인터페이스를 만들어야 하므로 더 높은 권한이 필요합니다. 기업용 기기에 중앙 네트워크 정책이 있다면 프록시와 네트워크 어댑터를 변경할 수 있는지 먼저 확인하세요. 실행 후 특정 계정만 설정을 저장하지 못한다면 프로토콜 매개변수를 바로 바꾸지 말고 프로그램 디렉터리 쓰기 권한과 계정 설정 디렉터리를 점검하세요.

설치를 마친 뒤에는 클라이언트 다운로드 페이지에서 현재 플랫폼에 맞는 클라이언트 유형과 설치 방식을 확인할 수 있습니다. 설치 단계의 목표는 모든 기능을 한 번에 설정하는 것이 아니라 안정적으로 시작되고, 설정을 저장하며, 로그를 읽을 수 있는 기본 환경을 만드는 것입니다. 이후 기능을 하나씩 추가할 때마다 이 기본 상태로 돌아올 수 있는 경로를 남겨 두세요.

구독 가져오기와 노드 관리

구독 주소와 단일 노드 공유 링크

구독 주소는 일반적으로 업데이트 가능한 서버 목록을 가리킵니다. 클라이언트가 해당 주소를 요청하면 여러 노드를 해석해 해당 구독 그룹에 넣습니다. vmess, vless 등의 공유 링크는 단일 노드의 전체 매개변수를 설명하므로 임시로 가져오거나 별도로 저장할 때 적합합니다. 둘은 겉모양만으로 간단히 구분할 수 없습니다. 구독 주소도 일반 HTTPS 링크이거나 접근 매개변수를 포함할 수 있고, 단일 노드 링크는 보통 프로토콜 이름으로 시작합니다. 공유 링크를 구독 주소 입력란에 붙여 넣지 말고, 구독 URL을 단일 노드 스캔 데이터로 처리하지도 마세요.

v2rayN에서는 먼저 구독 그룹 관리로 이동해 그룹을 만들고 구독 주소를 입력한 뒤 ‘현재 구독 업데이트’ 또는 해당 구독 업데이트 메뉴를 실행합니다. 그룹 이름은 용도나 출처를 나타내야 하며, 나중에 구분하기 어려운 ‘구독 1’, ‘구독 2’ 같은 이름은 피하세요. v2rayNG와 v2flyNG는 메뉴 이름이 조금 다를 수 있지만 흐름은 같습니다. 구독 주소 저장, 업데이트 실행, 구성 목록으로 돌아가기, 대상 노드 선택 순서입니다. 업데이트 전후의 노드는 클라이언트가 구독 내용에 따라 관리하므로 구독 노드의 필드를 직접 수정하면 다음 업데이트에서 덮어써질 수 있습니다.

구독 업데이트 실패 시 계층별 점검

업데이트 후 목록이 비어 있다면 먼저 로그에서 ‘요청 실패’인지 ‘해석 실패’인지 확인하세요. 요청 실패는 클라이언트가 구독 내용을 가져오지 못했다는 뜻이므로 주소가 완전한지, 시스템 시간이 정확한지, 현재 네트워크에서 구독 주소에 접근할 수 있는지, 구독 업데이트가 현재 사용할 수 없는 프록시 출구를 거치도록 설정되어 있지 않은지 확인해야 합니다. 해석 실패는 서버가 내용을 반환했지만 클라이언트가 예상한 형식이 아니라는 뜻입니다. 주소 만료, 로그인 페이지 반환, 접근 매개변수 누락 또는 클라이언트 버전이 새 필드를 인식하지 못하는 경우가 흔합니다. 기존 그룹을 수정하지 않고 테스트 그룹을 새로 만들어 전체 주소를 다시 붙여 넣으면 이전 필드가 남아 있는지 확인할 수 있습니다.

기존 노드가 남아 있는데도 업데이트가 계속 실패한다면 전체 설정을 바로 삭제하지 마세요. 현재 사용할 수 있는 노드를 먼저 보존하고 로그에서 처음 나타난 명확한 오류를 복사한 뒤 구독 링크를 확인하세요. 점검 순서는 주소, 네트워크 요청, 반환 내용, 해석 과정, 노드 연결이어야 하며, 업데이트 실패에서 곧바로 클라이언트 재설치로 넘어가서는 안 됩니다. 더 자세한 점검 경로는 구독 해석 실패의 일반적인 원인과 자가 점검 목록에서 확인할 수 있습니다.

노드 테스트 활용 방법

일괄 테스트는 연결할 수 없는 항목을 빠르게 걸러내는 데 적합하지만, 한 번의 테스트 결과를 영구적인 순위로 삼아서는 안 됩니다. 먼저 구독을 업데이트하고 동일한 테스트 방식을 선택해 실행한 뒤, 실패가 같은 프로토콜, 같은 도메인 그룹 또는 같은 서버 지역에 집중되는지 확인하세요. 한 구독의 모든 노드가 동시에 실패한다면 로컬 네트워크, 시스템 시간, 코어 상태와 구독 매개변수를 우선 점검하고, 일부 노드만 실패한다면 노드 자체의 상태를 의심하세요. 테스트를 짧은 간격으로 여러 차례 반복하면 연결 혼잡이 발생하고 로그에 병렬 오류가 대량으로 섞여 원인 파악이 어려워질 수 있습니다.

그룹, 메모와 업데이트 전략

구독 수가 늘어나면 그룹을 경계 관리에 활용해야 합니다. 출처가 다른 항목은 다른 그룹에 넣고, 수동 노드는 별도 그룹에 보관하며, 테스트용 임시 노드에는 용도를 분명히 적으세요. 자동 업데이트 주기는 정상 사용을 자주 방해할 만큼 짧게 설정하지 말고 실제 변경 빈도에 맞추되 수동 업데이트入口는 남겨 두세요. 업데이트 작업에 프록시가 필요하다면 그 기반이 되는 현재 노드가 사용 가능한지 확인해야 합니다. 그렇지 않으면 ‘복구하려면 업데이트해야 하지만 업데이트도 실패한 노드에 의존하는’ 순환이 발생합니다.

구독 주소에는 접근 자격 증명이 포함될 수 있으므로 공개 스크린샷, 로그 공유 또는 공개 문서에 붙여 넣어서는 안 됩니다. 문제 해결 시 도메인과 오류 유형은 남겨도 되지만 쿼리 매개변수와 경로의 식별 정보는 가리세요. 노드 공유 링크에도 전체 연결 매개변수가 들어 있으므로 통제된 기기 사이에서만 전달해야 합니다. 효율적인 노드 관리의 목표는 항목을 최대한 많이 보관하는 것이 아니라 출처, 업데이트 시각, 자주 쓰는 노드와 실패 원인을 빠르게 식별할 수 있게 하는 것입니다.

시스템 프록시와 프록시 모드

시스템 프록시는 어떤 문제를 해결하는가

시스템 프록시는 데스크톱에서 가장 먼저 익히기 좋은 트래픽 인계 방식입니다. v2rayN에서 시스템 프록시를 활성화하면 운영체제의 프록시 주소가 로컬 수신 포트를 가리키도록 바뀝니다. 시스템 프록시 설정을 따르는 브라우저와 데스크톱 애플리케이션은 이후 요청을 코어에 전달합니다. 경계가 명확하고 켜고 끄기 쉬우며 문제 해결 비용이 낮다는 장점이 있지만, 일부 프로그램은 시스템 프록시를 읽지 않아 게임, 명령줄 도구 또는 자체 네트워크 스택을 사용하는 앱이 직접 연결할 수 있습니다. 특정 프로그램이 인계되지 않을 때는 먼저 해당 프로그램이 시스템 프록시를 지원하는지 확인한 뒤 TUN이 필요한지 판단하세요. 곧바로 노드 프로토콜을 바꿀 필요는 없습니다.

시스템 프록시 상태와 코어 실행 상태는 별개의 문제입니다. 코어는 시작됐지만 시스템 프록시가 꺼져 있을 수 있고, 코어가 종료됐는데 시스템 프록시는 이전 포트를 계속 가리킬 수도 있습니다. 클라이언트를 정상적으로 종료할 때는 시스템 프록시를 원래대로 복원해야 합니다. 프로그램이 비정상 종료된 뒤 브라우저가 인터넷에 연결되지 않으면 운영체제의 프록시 설정에 들어가 로컬 주소가 남아 있는지 확인하세요. v2rayN을 다시 열어 시스템 프록시를 끄는 것만으로도 복구되는 경우가 많습니다.

전체, 규칙과 직접 연결의 차이

‘전체’는 클라이언트가 인계한 트래픽을 하나의 프록시 아웃바운드로 보내는 방식입니다. ‘규칙’은 먼저 라우팅 매칭을 거친 뒤 프록시, 직접 연결 또는 차단 출구로 보내는 방식이며, ‘직접 연결’은 인계된 트래픽을 로컬 네트워크에서 바로 내보내는 방식입니다. 여기서 핵심은 ‘인계된 트래픽’이라는 조건입니다. 애플리케이션이 시스템 프록시에 전혀 들어오지 않았다면 전체나 규칙으로 전환해도 영향을 받지 않습니다. 반대로 전체 모드도 기기의 모든 데이터가 자동으로 클라이언트에 들어간다는 뜻은 아니며, 코어 내부의 아웃바운드 선택만 바꿉니다.

비교 테스트로 트래픽 인계 경로 확인

프록시 모드를 확인할 때 트레이 아이콘 색상만 보지 마세요. 먼저 연결이 확인된 노드를 선택하고 시스템 프록시를 켠 뒤 시스템 프록시를 따르는 브라우저로 테스트 페이지에 접속합니다. 다음으로 직접 연결 모드로 바꾸어 같은 페이지를 열고, 마지막으로 시스템 프록시를 끕니다. 세 상태에서 아무 차이가 없다면 브라우저가 별도 프록시 설정을 사용하는지, 시스템 프록시 주소가 현재 포트를 가리키는지, 클라이언트 로그에 해당 요청이 나타나는지 확인하세요. 로그에는 요청이 있지만 연결에 실패하면 문제는 라우팅이나 노드 쪽에 있고, 로그에 요청 자체가 없다면 애플리케이션과 로컬 인바운드 사이에 문제가 있습니다.

명령줄 도구의 동작은 별도로 판단해야 합니다. 일부 도구는 데스크톱 시스템 프록시가 아니라 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY 환경 변수를 읽습니다. 임시 테스트에서는 도구 문서에 따라 프록시 주소를 설정할 수 있지만, 다른 기기의 포트 번호를 그대로 사용하지 말고 현재 클라이언트의 로컬 수신 설정을 기준으로 하세요. 수신 포트를 바꾸면 수동으로 설정한 환경 변수와 애플리케이션 내부 프록시도 함께 업데이트해야 합니다.

LAN 접근과 로컬 수신

LAN 연결을 허용하면 클라이언트의 수신 범위가 로컬 전용에서 LAN 인터페이스까지 확장됩니다. 같은 네트워크의 다른 기기가 이 컴퓨터를 프록시入口로 사용해야 할 때만 활성화하고, 방화벽 범위, 수신 주소와 접근 제어를 함께 확인하세요. 일반적인 단일 기기 사용에서는 로컬 전용 수신을 유지하면 됩니다. 활성화 후에도 다른 기기에서 연결되지 않으면 수신 주소, 시스템 방화벽, 라우터의 기기 격리, 포트 입력 순서로 점검하세요. 문제를 해결하려고 모든 인터페이스를 장기간 개방하지 마세요. 원래 명확했던 로컬 경계가 바뀔 수 있습니다.

라우팅 규칙

규칙은 순서대로 매칭됩니다

분할 라우팅의 핵심은 규칙의 개수가 아니라 매칭 순서입니다. 코어는 일반적으로 규칙을 위에서 아래로 확인하며, 트래픽이 한 규칙에 매칭되면 해당 규칙이 지정한 아웃바운드로 들어가고 뒤의 규칙은 처리되지 않습니다. 따라서 더 구체적인 예외 규칙은 더 포괄적인 규칙보다 앞에 배치해야 합니다. 예를 들어 특정 도메인은 프록시를 사용해야 하지만 해당 도메인 집합은 기본적으로 직접 연결된다면, 단일 도메인 프록시 규칙을 집합 직접 연결 규칙보다 앞에 둬야 합니다. 포괄적인 규칙을 먼저 배치하면 뒤의 예외는 절대 적용되지 않습니다.

일반적인 매칭 조건에는 도메인, IP, 포트, 네트워크 유형, 프로토콜과 인바운드 태그가 있습니다. domain 조건은 전체 도메인, 접미사 또는 규칙 집합에 따른 매칭에 적합하고, ip 조건은 해석된 대상 주소를 처리합니다. port는 서비스 포트를 제한할 때 사용하며, inboundTag는 서로 다른 로컬入口에서 들어온 트래픽을 구분합니다. outboundTag는 매칭 후 사용할 출구를 결정합니다. 규칙의 태그는 outbounds에 실제로 정의된 태그와 일치해야 하며, 철자 차이로 설정 검사가 실패하거나 예상과 다른 라우팅 결과가 나올 수 있습니다.

간단한 routing 예시

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.com",
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

예시는 먼저 사설 주소를 direct로 보내 라우터, 프린터 또는 LAN 서비스에 접근할 때 원격 서버를 거치지 않도록 합니다. 두 번째 규칙은 예시 도메인과 지정된 집합을 block으로 보냅니다. 마지막 규칙은 나머지 TCP와 UDP 트래픽을 proxy로 보내는 기본 처리입니다. 실제 클라이언트는 그래픽 인터페이스를 통해 동등한 설정을 생성할 수 있고 아웃바운드 태그 이름도 다를 수 있으므로, 규칙을 복사하기 전에 현재 설정의 태그를 확인하세요. 예시의 마지막 규칙은 매우 포괄적이므로 첫 번째에 놓으면 LAN 직접 연결 규칙이 매칭될 기회를 잃습니다.

domainStrategy가 판단에 미치는 영향

domainStrategy는 라우팅 단계에서 어떤 경우에 도메인을 IP로 해석할지 결정합니다. AsIs는 원래 도메인을 우선 유지하고 IP 규칙을 위해 적극적으로 해석하지 않습니다. IPIfNonMatch는 도메인 규칙이 매칭되지 않을 때 IP를 해석해 IP 규칙을 계속 확인합니다. IPOnDemand는 규칙에 IP가 필요할 때 더 적극적으로 해석합니다. 더 적극적인 설정이 항상 좋은 것은 아닙니다. 추가 해석으로 DNS 경로, 캐시와 결과 차이가 생길 수 있기 때문입니다. 일반적인 분할 라우팅은 IPIfNonMatch로 시작한 뒤 로그를 보고 조정하는 방법이 좋습니다.

최소 규칙 집합부터 시작하기

분할 라우팅을 구성할 때는 먼저 세 가지 기본 동작을 유지하세요. LAN 직접 연결, 명확히 프록시가 필요한 대상, 나머지 트래픽의 기본 처리입니다. 안정성을 확인한 뒤 광고 차단, 애플리케이션 전용 포트 또는 복잡한 도메인 집합을 추가하세요. 매번 규칙 한 그룹만 추가하고 목록에서의 위치를 기록합니다. 문제가 생기면 먼저 전체 모드로 전환해 비교하세요. 전체 모드는 정상인데 규칙 모드가 실패한다면 노드 자체는 대체로 사용할 수 있으므로 라우팅 조건, DNS 또는 아웃바운드 태그에 집중해야 합니다.

복잡한 설정은 V2Ray 설정 파일 구조를 구간별로 이해하기를 함께 참고해 inbounds, outbounds와 routing의 관계를 파악할 수 있습니다. 분할 라우팅을 점검할 때는 웹페이지가 열렸는지만 기록하지 말고 ‘원래 도메인, 해석된 주소, 매칭된 규칙, 대상 아웃바운드’ 네 가지를 남기세요. 이 네 항목이 서로 대응하면 라우팅 동작은 대체로 설명하고 재현할 수 있습니다.

TUN 모드 설정

TUN과 시스템 프록시의 트래픽 인계 차이

TUN 모드는 가상 네트워크 인터페이스를 통해 시스템 트래픽을 받아 시스템 프록시를 읽지 않는 더 많은 애플리케이션을 포함할 수 있습니다. 시스템은 라우팅 조건에 맞는 패킷을 가상 인터페이스로 전달하고, 클라이언트는 이를 변환해 코어로 보냅니다. 애플리케이션 프록시보다 낮은 네트워크 계층에서 작동하므로 DNS, UDP, LAN 접근, 기본 경로와 방화벽이 결과에 모두 관여합니다. TUN은 ‘더 강력한 전체 스위치’가 아니라 트래픽 인계 범위가 넓고 설정 변수도 많은 실행 방식입니다.

활성화하기 전에 세 가지를 확인해야 합니다. 일반 시스템 프록시가 현재 노드로 안정적으로 연결되는지, 시스템 프록시 모드에서 라우팅 규칙이 올바르게 동작하는지, 클라이언트가 필요한 권한으로 가상 인터페이스를 만들 수 있는지 확인하세요. 기본 경로를 검증하지 않았다면 TUN 실행 실패가 노드, 규칙, 드라이버 또는 시스템 네트워크 중 무엇 때문인지 구분할 수 없습니다. TUN을 끈 상태의 사용 가능한 설정을 저장해 두고 문제가 생기면 먼저 그 상태로 되돌리는 것이 좋습니다.

활성화 과정과 필수 점검

v2rayN 설정에서 TUN을 활성화하면 시스템이 권한 상승을 요청하고 가상 네트워크 어댑터를 만들 수 있습니다. 권한을 승인한 뒤 로그에서 어댑터 생성, 주소 할당, 경로 기록과 코어 시작에 오류가 없는지 확인하세요. 이후 일반 웹페이지를 먼저 열고, UDP가 필요한 애플리케이션을 테스트한 다음 LAN 기기를 확인합니다. 처음부터 사용자 지정 DNS, 엄격한 라우팅, 복잡한 규칙 집합과 여러 네트워크 필터링 도구를 동시에 켜지 마세요. 어느 단계에서 문제가 생겼는지 알기 어려워집니다.

TUN이 실행 중으로 표시되지만 모든 네트워크가 끊긴다면 먼저 TUN을 끄고 기본 네트워크가 복구되는지 확인하세요. 그런 다음 기본 경로가 올바르게 기록되었는지, DNS에 사용 가능한 출구가 있는지, 가상 어댑터에 주소가 할당되었는지, 다른 보안 소프트웨어가 새 인터페이스를 차단하지 않는지 점검합니다. 브라우저만 정상이고 특정 애플리케이션만 실패한다면 해당 앱이 TCP와 UDP 중 무엇을 사용하는지, 라우팅 규칙이 해당 프로토콜을 차단했는지 확인하세요. 도메인만 실패하고 테스트 주소에 직접 접근할 때 응답이 있다면 대개 DNS 문제입니다.

DNS와 루프백 문제

TUN 환경에서는 클라이언트가 자체적으로 만든 연결이 다시 TUN에 포착되어 클라이언트로 되돌아가는 라우팅 루프를 피해야 합니다. 안정적인 클라이언트는 코어 프로세스, 서버 주소 또는 특정 출구에 우회 경로를 설정하지만 사용자 지정 규칙이 이 관계를 깨뜨릴 수 있습니다. 같은 서버 주소에 대한 연결이 로그에 반복되고 CPU 사용량이 올라가며 연결이 빠르게 실패하는 현상이 대표적입니다. 이때는 기본 TUN 규칙을 복원하고 프록시 서버 주소가 실제 네트워크 인터페이스를 통해 직접 연결되도록 하며, 코어 아웃바운드가 다시 가상 인터페이스로 들어가지 않는지 확인하세요.

DNS 처리는 단일하고 설명 가능한 기본 경로를 유지해야 합니다. 시스템 DNS, 클라이언트 내장 DNS, 브라우저 자체 해석과 다른 네트워크 도구가 동시에 작동하면 도메인이 서로 다른 위치에서 다른 결과를 얻을 수 있습니다. 문제를 해결할 때는 추가 애플리케이션 수준 DNS 기능을 잠시 끄고 클라이언트가 권장하는 기본 해석 설정을 사용하세요. 로그에서 도메인 조회가 어느 인바운드로 들어오고 어느 아웃바운드를 통해 반환되는지 확인한 뒤 안정되면 사용자 지정 정책을 하나씩 다시 활성화합니다.

절전, 네트워크 전환과 종료 후 복구

노트북이 절전 모드에서 복귀하거나 유선과 무선 네트워크 사이를 전환하거나 다른 네트워크로 이동한 뒤에는 가상 인터페이스와 기본 경로가 이전 상태를 참조할 수 있습니다. 연결이 끊기면 먼저 TUN을 중지하고 실제 네트워크가 유효한 주소를 받을 때까지 기다린 다음 다시 활성화하세요. 클라이언트가 비정상 종료된 후 네트워크가 복구되지 않으면 시스템 프록시, 가상 어댑터와 기본 경로를 확인하고 모든 설정을 바로 삭제하지 마세요. Windows에서는 남아 있는 시스템 프록시를 끄고 클라이언트를 다시 시작해 보세요. Linux에서는 ip route로 기본 경로를 확인할 수 있고, macOS에서는 네트워크 설정에서 현재 서비스 순서를 확인할 수 있습니다.

TUN 설정 완료의 기준은 아이콘에 ‘준비됨’이라고 표시되는 것이 아닙니다. 일반 웹페이지, UDP 애플리케이션, LAN 리소스, 절전 복귀와 클라이언트 종료라는 다섯 가지 상황에서 예측 가능한 결과가 나와야 합니다. 테스트를 마친 뒤 현재 DNS 방식, 사설 네트워크 대역 규칙과 권한 설정을 기록해 두면 이후 업그레이드나 네트워크 변경 시 빠르게 비교할 수 있습니다.

문제 해결과 유지 관리

먼저 첫 번째 유효 오류를 읽으세요

코어 실행에 실패하면 로그 뒤쪽의 수많은 오류가 첫 번째 문제로 인해 연쇄적으로 발생한 결과일 수 있습니다. 이번 실행이 시작된 시점부터 아래로 읽어 필드명, 포트, 파일 경로 또는 설정 구간이 포함된 첫 번째 명확한 오류를 찾으세요. 흔한 유형으로는 로컬 포트 점유, JSON 필드 형식 오류, 존재하지 않는 아웃바운드 태그, 누락된 전송 매개변수, 실행할 수 없는 코어 파일과 설정 디렉터리 쓰기 권한 부족이 있습니다. 원래 오류를 기록한 뒤 설정을 수정하고, 한 번에 하나의 원인만 처리한 다음 다시 시작하세요. 노드, 포트, 코어와 라우팅 규칙을 동시에 바꾸면 안 됩니다.

포트가 사용 중이라면 먼저 다른 클라이언트가 백그라운드에서 실행 중인지 확인하세요. Windows에서는 다음 명령으로 로컬 포트를 점유한 프로세스 번호를 확인한 뒤 작업 관리자에서 프로그램을 대조할 수 있습니다. Linux에서는 ss로 수신 프로세스를 확인할 수 있습니다. 포트 번호는 클라이언트 설정에 실제로 표시된 로컬 수신 포트로 바꿔야 합니다.

netstat -ano | findstr LISTENING
ss -lntup

포트가 사용 중이라고 해서 임의의 숫자로 바꾸지 마세요. 브라우저, 환경 변수 또는 다른 애플리케이션에 이전 포트를 직접 입력해 두었다면 변경 후 모두 함께 업데이트해야 합니다. 더 자세한 로그 읽기 방법은 로그 창에서 코어 실행 오류를 찾는 문제 해결 경로를 참고하세요.

연결 경로에 따라 문제 해결 목록 만들기

프로그램은 시작되지만 대상에 접근할 수 없다면 다음 순서로 확인하세요. 구독이 업데이트되는지, 대상 노드가 연결 테스트를 완료하는지, 코어가 실행 중인지, 애플리케이션 요청이 로컬 인바운드로 들어오는지, 라우팅이 올바른 아웃바운드를 선택하는지, DNS가 사용 가능한 결과를 반환하는지 점검합니다. 각 단계에는 구독 로그, 코어 시작 로그, 요청 기록 또는 모드 비교 결과처럼 관찰 가능한 증거가 필요합니다. 전체 모드는 작동하지만 규칙 모드가 실패하면 라우팅을 중점적으로 확인하고, 시스템 프록시는 작동하지만 TUN이 실패하면 가상 인터페이스, DNS와 시스템 경로를 점검하세요. 모든 모드에서 연결을 만들 수 없다면 노드 매개변수, 시스템 시간과 기본 네트워크로 돌아가야 합니다.

일상적인 업데이트와 되돌리기

클라이언트, 코어, 구독과 규칙 집합은 서로 다른 네 가지 업데이트 대상이므로 같은 유지 관리 작업에서 모두 바꾸지 않는 것이 좋습니다. 안정적인 순서는 현재 사용 가능한 상태를 기록하고, 한 항목만 업데이트한 뒤 재시작해 자주 쓰는 환경을 확인하고 다음 항목으로 넘어가는 것입니다. 클라이언트 업그레이드 후에는 설정 마이그레이션과 메뉴 변화를, 코어 업데이트 후에는 프로토콜 매개변수와 시작 로그를, 구독 업데이트 후에는 노드 추가·삭제와 이름 변화를, 규칙 집합 업데이트 후에는 자주 방문하는 웹사이트와 LAN 접근을 확인하세요. 모든 단계에 검증 지점이 있으면 문제를 가장 최근의 변경으로 한정할 수 있습니다.

되돌리려면 식별 가능한 기준 상태를 보존해야 합니다. 최소한 현재 사용하는 클라이언트 유형, 구독 그룹, 자주 쓰는 노드, 시스템 프록시 모드, TUN 상태와 사용자 지정 라우팅 규칙을 기록하세요. 설정 내보내기 파일은 통제된 위치에 보관하고, 구독 주소와 노드 정보는 공개 동기화 디렉터리에 넣지 마세요. 업그레이드 후 문제가 생기면 가장 최근에 변경한 항목부터 되돌리고 모든 설정을 삭제해 처음부터 다시 시작하지 마세요. 환경을 재구축하면 일시적으로 복구될 수 있지만 원인을 설명할 수 있는 로그와 차이도 함께 사라집니다.

로그 공유 전 처리

로그에는 오류 시각, 오류 유형, 필드명, 대상 포트와 클라이언트 조작 단계를 남기는 것이 좋지만, 구독 경로, 서버 주소, 사용자 식별자 또는 로컬 디렉터리가 포함될 수 있습니다. 다른 사람에게 로그를 제공하기 전에는 구독 쿼리 매개변수, 노드 식별 정보와 개인 디렉터리명을 삭제하되 오류 상황은 남기세요. 마지막 한 줄만 잘라내면 시작 단계 정보가 부족하고, 전체 설정을 공개하면 불필요한 데이터까지 노출됩니다. ‘발생 전에 무엇을 했는지, 기대한 결과, 실제 결과, 첫 번째 오류와 앞뒤 몇 줄’을 제공하는 방식을 권장합니다.

안정적인 유지 관리는 설정을 자주 초기화하는 것이 아니라 재현 가능한 절차에 달려 있습니다. 기준 상태를 보존하고 한 번에 하나의 변수만 바꾸며 첫 번째 오류부터 읽으면 대부분의 문제를 명확한 계층으로 좁힐 수 있습니다. 주 창 각 영역의 역할은 v2rayN 메인 화면 기능 구역 상세 안내에서 확인할 수 있습니다.

설정 파일과 고급 학습 경로

그래픽 설정을 설정 구조에 매핑하기

고급 학습의 핵심은 그래픽 클라이언트를 떠나 모든 설정을 직접 작성하는 것이 아니라, 인터페이스에서 수행한 작업이 최종적으로 구조의 어느 부분을 바꾸는지 이해하는 데 있습니다. V2Ray 설정은 일반적으로 log, dns, inbounds, outbounds, routing 등의 부분으로 구성됩니다. inbounds는 로컬 SOCKS, HTTP 또는 TUN入口처럼 트래픽이 코어로 들어오는 방식을 정의하고, outbounds는 프록시, 직접 연결과 차단 출구를 정의합니다. routing은 인바운드 트래픽을 어느 아웃바운드로 보낼지 결정하며, dns는 도메인 해석 방식과 해석 요청이 거치는 경로에 영향을 줍니다. log는 기록 수준과 출력 위치를 결정합니다.

v2rayN에서 서버를 전환하면 보통 주 프록시 아웃바운드의 매개변수가 바뀌고, 전체 또는 규칙 모드로 전환하면 라우팅 선택이 달라지며, 로컬 포트를 수정하면 인바운드 수신에 영향을 줍니다. TUN을 활성화하면 해당 인바운드와 시스템 네트워크 설정이 추가되거나 변경됩니다. 이 매핑을 이해하면 로그에 나타나는 inboundTag, outboundTag, 도메인 전략 등의 용어가 더 이상 고립된 필드로 보이지 않습니다. 설정을 읽을 때는 먼저 ‘入口—규칙—출구’의 세 구간 관계를 그린 다음 프로토콜 세부 사항을 확인하세요.

설정 수정 시 최소 변경 원칙

설정을 직접 조정하기 전에 현재 사용 가능한 버전을 복사하고 복사본의 용도를 적어 두세요. 한 번에 하나의 논리적 목표만 수정합니다. 예를 들어 직접 연결 도메인 하나 추가, DNS 아웃바운드 변경 또는 테스트 인바운드 하나 추가처럼 진행하세요. 저장 후 클라이언트나 코어가 제공하는 설정 검사를 먼저 실행하고, 시작해 초기 로그를 확인한 다음 수정 목표와 직접 관련된 요청을 검증합니다. 한 번의 편집에서 모든 라우팅을 재배열하고 DNS, 수신 포트와 노드를 동시에 바꾸지 마세요. 연결이 성공하더라도 어떤 변경이 실제로 영향을 주었는지 알 수 없습니다.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

이 예시는 로컬 SOCKS 인바운드와 직접 연결·차단이라는 두 가지 기본 아웃바운드를 보여 줍니다. 수신 주소가 127.0.0.1이므로 로컬에서만 접근할 수 있고, UDP를 활성화하면 해당 인바운드가 관련 요청을 받을 수 있습니다. 프록시 아웃바운드에는 구독 또는 서버가 제공한 실제 프로토콜 매개변수가 필요하므로 완전한 원격 프록시 설정은 아닙니다. 학습할 때는 이처럼 간단한 조각으로 구조를 이해할 수 있지만, 일상적인 연결에서는 클라이언트가 구독에 맞는 완전한 설정을 생성하도록 해야 합니다.

로그 수준과 관찰 범위

일상적인 실행에는 warning과 같이 비교적 제한적인 로그 수준이면 충분합니다. 복잡한 라우팅이나 연결 과정을 점검할 때만 일시적으로 상세 수준을 높이고, 문제가 확인되면 다시 낮추세요. 상세 로그는 내용이 빠르게 늘어나고 더 많은 대상 정보가 기록될 수 있으므로 장기간 켜 두기에는 적합하지 않습니다. 로그를 관찰할 때는 하나의 테스트 요청과 시각을 기록한 뒤 해당 시각을 중심으로 인바운드, 대상 도메인, 라우팅 결정과 아웃바운드 오류를 찾으세요. 명확한 테스트 동작 없이 쌓인 긴 로그는 백그라운드 요청과 대상 요청을 구분하기 어렵습니다.

권장 고급 학습 순서

1단계에서는 시스템 프록시, 노드 선택과 로그入口를 익히고, 2단계에서는 도메인, IP, 포트와 규칙 순서를 이해하세요. 3단계에서는 DNS 요청이 발생하는 위치와 domainStrategy의 영향을 학습하고, 4단계에서 TUN의 가상 인터페이스, 기본 경로와 UDP를 다룹니다. 프로토콜 필드와 전송 매개변수는 5단계에 들어가서 학습하세요. 이 순서는 로컬에서 관찰 가능한 동작부터 프로토콜 세부 사항으로 단계적으로 나아가므로 문제가 생겨도 이미 검증한 기본 계층으로 돌아갈 수 있습니다.

프로토콜 학습은 필드 간 관계를 중심으로 진행해야 합니다. VLESS 등의 프로토콜 필드는 신원과 흐름 제어를 담당하고, TCP, WebSocket, gRPC 등의 전송 방식은 데이터를 운반하며, TLS 또는 REALITY는 해당 보안과 인증 매개변수를 담당합니다. 공유 링크는 항상 하나의 완전한 매개변수 묶음으로 다뤄야 하며 이름이 비슷하다는 이유로 필드를 서로 바꿔서는 안 됩니다. 단일 노드 링크와 구독의 구조를 비교하려면 vmess와 vless 공유 링크 사용법을 참고하세요.

자신만의 실행 기준 만들기

이 매뉴얼을 마친 뒤에는 기기 기준 상태를 만들어 두는 것이 좋습니다. 클라이언트 이름, 운영체제, 수신 포트, 시스템 프록시 모드, TUN 상태, DNS 경로, 라우팅 규칙 출처와 자주 사용하는 구독 그룹을 기록하세요. 기준 상태에는 노드의 민감한 매개변수를 저장할 필요 없이 설정 관계만 적으면 됩니다. 업그레이드나 수정 후에는 클라이언트 시작, 구독 업데이트, 일반 웹페이지, 규칙 라우팅, LAN 접근, UDP 애플리케이션과 절전 복귀를 같은 시나리오로 검증하세요. 결과가 기준 상태와 일치해야 변경이 완료된 것으로 볼 수 있습니다.

처음부터 완벽하게 익힌다는 것은 모든 필드를 외우는 것이 아니라 안정적인 분석 순서를 갖추는 것입니다. 먼저 문제의 계층을 정하고, 로그 증거를 수집한 다음, 최소한의 변경을 적용하고, 마지막으로 비교 테스트로 확인하세요. 가장 짧은 설정 과정을 다시 진행하려면 빠른 시작으로 돌아가고, 다른 플랫폼의 설치 패키지가 필요하면 클라이언트 다운로드 페이지로 이동하세요. 두 페이지는 작업入口를 제공하고, 이 매뉴얼은 설정 사이의 인과 관계를 설명합니다.