V2Ray 종합 가이드: 핵심 개념부터 고급 설정까지

// FOUNDATION

핵심 개념: 클라이언트, 코어, 노드와 구독

인터페이스 계층과 실행 계층을 먼저 구분하세요

일반적으로 말하는 “V2Ray 클라이언트”는 하나의 프로그램이 아니라 그래픽 인터페이스, 프록시 코어, 설정 파일과 시스템 네트워크 설정이 결합된 형태입니다. v2rayN, v2rayNG, v2flyNG는 서버 목록 표시, 구독 저장, 프록시 모드 전환과 로그 확인을 담당하며, 실제로 연결을 수립하고 프로토콜을 해석해 트래픽을 처리하는 것은 코어입니다. v2rayN은 데스크톱 시스템에서 관련 코어를 관리할 수 있고, v2rayNG는 Xray 코어를 주요 실행 계층으로 사용하며, v2flyNG는 V2Fly 코어를 대상으로 합니다. 이 관계를 이해하면 문제를 해결할 때 “인터페이스 버튼이 바뀌지 않음”, “코어 시작 실패”, “원격 서버에 연결할 수 없음”을 하나의 문제로 혼동하지 않게 됩니다.

그래픽 클라이언트는 인터페이스에서 선택한 항목을 바탕으로 실행 설정을 생성한 뒤 로컬 프록시 포트를 엽니다. 브라우저나 운영 체제는 요청을 이 로컬 포트로 전달하고, 코어는 프로토콜, 전송 방식, 보안 매개변수와 라우팅 규칙에 따라 요청을 처리합니다. 따라서 노드를 사용하려면 최소한 네 가지 조건이 맞아야 합니다. 서버 주소가 해석되는지, 포트 연결이 가능한지, 인증 정보가 일치하는지, 전송 및 보안 설정이 서로 맞는지 확인해야 합니다. 어느 한 항목이라도 맞지 않으면 연결 시간 초과, 핸드셰이크 실패 또는 시작 후 대상 사이트 접속 불가로 나타날 수 있습니다.

노드는 구독이 아니며, 구독은 프록시 스위치가 아닙니다

노드는 주소, 포트, 사용자 식별자, 프로토콜 유형, 전송 방식과 보안 설정으로 구성된 구체적인 연결 정보입니다. 구독은 여러 노드와 그룹 정보를 한 번에 반환하는 업데이트 가능한 데이터 주소입니다. 클라이언트에 구독을 추가했다는 것은 설정을 읽어 올 위치를 알게 되었다는 뜻일 뿐입니다. 실제 트래픽이 코어로 들어가려면 업데이트를 실행하고 활성 서버를 선택한 뒤 적절한 프록시 모드를 켜야 합니다. 가져오기에 성공했는데 서버 목록이 비어 있다면 아직 업데이트하지 않았거나, 현재 클라이언트가 구독 형식을 인식하지 못했거나, 업데이트 요청 자체가 완료되지 않았을 가능성이 큽니다.

공유 링크와 구독 링크도 구분해서 이해해야 합니다. 공유 링크는 보통 단일 노드만 설명하므로 임시 가져오기나 설정 하나를 옮길 때 적합합니다. 구독 링크는 여러 서버를 지속적으로 관리하는 용도이며, 업데이트하면 노드가 추가·삭제되거나 변경될 수 있습니다. 자세한 형식은 구독 링크 형식 자세히 알아보기에서 확인할 수 있습니다. 장기간 사용할 때는 구독 그룹을 유지하고 모든 노드를 서로 관계없는 로컬 항목으로 복사하지 마세요. 이후 업데이트가 기존 설정을 정확히 덮어쓰지 못하기 때문입니다.

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

VMess와 VLESS 같은 이름은 주로 연결 프로토콜과 인증 필드를 나타내고, TCP, WebSocket, gRPC 등은 전송 계층의 선택입니다. TLS와 REALITY는 보안 핸드셰이크 또는 인증을 처리합니다. 클라이언트 인터페이스에서는 이 필드들이 같은 편집 창에 놓이는 경우가 많지만 임의로 바꿔 쓸 수는 없습니다. 서버가 VLESS를 제공한다면 클라이언트의 드롭다운만 VMess로 바꿔서는 안 됩니다. 전송 방식이 WebSocket이라면 경로와 호스트 필드 등의 매개변수도 일치해야 합니다. 프로토콜의 기본적인 차이는 VMess와 VLESS의 차이에서 계속 확인할 수 있습니다.

// CLIENT AND INSTALL

클라이언트 선택과 유지 관리 가능한 설치

이름이 아니라 플랫폼에 맞춰 선택하세요

데스크톱 플랫폼에서는 v2rayN을 우선 고려하세요. Windows, macOS, Linux를 지원하며 여러 구독 관리, 라우팅 규칙 편집, 상세 로그 확인과 TUN 사용이 필요한 사용자에게 적합합니다. Android에서는 v2rayNG를 우선 선택하고, 구독이나 기존 설정이 V2Fly 코어를 전제로 한다면 v2flyNG를 사용할 수 있습니다. 세 클라이언트의 역할은 완전히 같지 않으므로 여러 기기의 화면을 통일하려고 맞지 않는 플랫폼 솔루션을 억지로 사용하지 않는 것이 좋습니다. 설치 파일은 다운로드 페이지에 모아 두었으며 프로세서 아키텍처와 설치 형식별로 나누어 제공합니다.

설치 파일을 고르기 전에 운영 체제 유형과 프로세서 아키텍처를 확인하세요. Windows 일반 데스크톱은 x64를 선택하고, macOS는 Apple Silicon과 Intel을 구분해야 합니다. 최근 Android 기기는 대부분 arm64를 사용하며, 확인하기 어렵다면 범용 패키지를 선택할 수 있습니다. Linux는 x64와 arm64 외에도 배포판에 맞춰 deb 또는 rpm을 골라야 합니다. 아키텍처가 맞지 않으면 프로그램이 실행되지 않을 수 있고, 설치 형식이 맞지 않으면 시스템 패키지 관리자가 바로 거부합니다.

설치 위치가 이후 유지 관리 비용을 좌우합니다

Windows 데스크톱 버전과 클래식 WPF 버전은 서로 다른 인터페이스 기술을 사용합니다. 데스크톱 버전은 여러 데스크톱 시스템에서 비슷한 조작 방식을 원하는 사용자에게 적합하고, 클래식 WPF 버전은 기존 v2rayN 작업 흐름에 익숙한 Windows 사용자에게 알맞습니다. 압축 파일을 받았다면 쓰기 권한이 있는 고정된 위치에 압축을 풀고, 압축 미리 보기 창에서 직접 실행하지 마세요. 설정, 로그와 임시 파일을 정상적으로 기록할 수 있어야 하며 경로가 자주 바뀌면 바로 가기와 자동 시작 설정도 작동하지 않을 수 있습니다.

macOS에서는 처음 실행할 때 시스템이 허용하는 앱 실행 절차에 따라 확인하고, 프로세서에 맞는 설치 파일을 선택했는지 확인하세요. Linux 사용자는 deb 또는 rpm 설치 후 데스크톱 메뉴에서 실행해 트레이 또는 메인 창이 보이는지 확인해야 합니다. Android는 설치 후 처음 연결을 켤 때 시스템 네트워크 연결 확인 창이 표시됩니다. 이는 로컬 가상 네트워크를 만들기 위해 필요한 권한 단계입니다. 권한을 거부하면 노드가 올바르더라도 기기 트래픽을 인계할 수 없습니다.

첫 실행에서는 세 가지만 확인하세요

첫째, 메인 창이 열리고 코어 시작 오류가 계속 발생하지 않는지 확인합니다. 둘째, 로그, 구독과 프록시 모드 메뉴를 찾습니다. 셋째, 시스템 시간과 시간대가 정확한지 확인합니다. 일부 프로토콜의 인증이나 보안 핸드셰이크는 시간에 의존하므로 기기 시간이 크게 어긋나면 매개변수가 일치해 보여도 연결되지 않을 수 있습니다. 처음 실행할 때 DNS, 라우팅, TUN, 포트와 코어 옵션을 한꺼번에 바꾸지 마세요. 문제가 생겼을 때 원인을 특정하기 어렵습니다.

설치가 끝나면 우선 기본 로컬 수신 대기 설정을 유지해도 됩니다. 일반적인 그래픽 클라이언트는 HTTP, SOCKS 또는 혼합 프록시 포트를 관리하며, 정확한 숫자는 현재 클라이언트 설정 페이지의 값을 따라야 합니다. 다른 기기에서 사용한 포트를 그대로 복사할 필요는 없습니다. 포트를 다른 프로그램이 사용 중이면 로그에 수신 대기 실패 또는 주소 사용 중이라는 메시지가 표시됩니다. 충돌하는 프로그램을 종료하거나 클라이언트에서 로컬 포트를 변경한 뒤, 해당 포트를 사용하는 브라우저, 터미널 또는 개발 도구 설정도 함께 수정하세요.

Windows: “작업 관리자”를 열어 클라이언트 프로세스가 실행 중인지 확인
macOS: “활성 상태 보기”를 열고 v2rayN 검색
Linux: 데스크톱 시스템 모니터를 사용하거나 다음을 실행하세요:
ss -lntp

// SUBSCRIPTION

구독 가져오기, 그룹과 업데이트 전략

전체 가져오기 과정은 네 단계입니다

구독 관리의 안정적인 순서는 구독 주소 추가, 업데이트 실행, 서버 목록 확인, 활성 서버 선택입니다. 링크를 편집 상자에 붙여 넣고 저장하는 것만으로는 노드가 목록에 기록되지 않습니다. v2rayN에서는 먼저 명확한 구독 그룹 이름을 만든 뒤 해당 그룹을 업데이트하세요. v2rayNG와 v2flyNG도 구독 설정에 주소를 저장한 후 직접 새로 고쳐야 합니다. 업데이트가 끝나면 요청 완료 여부만 보지 말고, 인식 가능한 설정을 가져왔는지 안내 메시지를 확인하세요.

링크를 복사할 때 전체 내용을 보존하세요. 메신저나 웹 페이지의 서식 때문에 링크에 공백이나 줄바꿈이 들어가거나, 보이는 부분만 복사해 일부 매개변수가 빠질 수 있습니다. 가져온 뒤 비어 있다면 원본 주소를 다시 복사하고 시작 부분, 쿼리 매개변수와 마지막 문자가 온전한지 확인하세요. 불필요해 보이는 인코딩 문자를 직접 지워 구독을 “수정”하지 마세요. 해당 문자가 필요한 데이터일 수 있습니다.

그룹으로 업데이트 범위를 관리하세요

구독 그룹은 단순한 화면 분류가 아닙니다. 서버 항목과 출처를 연결해 업데이트할 때 어떤 기존 항목을 교체할지 클라이언트에 알려 줍니다. 구독 출처마다 별도의 그룹을 만들고, 용도나 기기 범위를 알아볼 수 있는 이름을 사용하세요. 모두 “기본값”으로 지정하지 않는 것이 좋습니다. 여러 출처를 같은 그룹에 섞으면 업데이트 후 노드의 출처를 확인하기 어렵고, 사용 중인 설정을 정리하다가 잘못 삭제할 수도 있습니다.

직접 추가한 서버는 로컬 설정 그룹에 넣거나 명확히 표시해 구독 업데이트로 덮어쓰지 않도록 하세요. 구독 노드를 임시로 수정해야 한다면 먼저 독립 항목으로 복사한 뒤 복사본을 편집합니다. 구독 관리 대상 노드를 직접 수정하면 다음 업데이트에서 원격 내용으로 되돌아갈 수 있습니다. 클라이언트의 “업데이트 시 이전 서버 삭제”와 “로컬 수정 내용 유지” 옵션은 의미가 다르므로, 켜기 전에 그룹에 반드시 보존해야 할 수동 항목이 있는지 확인하세요.

변경 필요에 맞춰 업데이트 빈도를 정하세요

구독은 자주 업데이트한다고 항상 좋은 것이 아닙니다. 노드 구성이 바뀌었거나 현재 서버를 사용할 수 없을 때, 또는 제공자가 설정 변경을 공지했을 때 업데이트하면 됩니다. 자동 업데이트 간격이 너무 짧으면 불필요한 요청이 발생하고 클라이언트 시작 준비 시간이 길어질 수 있습니다. 적절한 주기의 자동 업데이트를 유지하되 필요할 때 수동으로 실행하는 방식이 안정적입니다. 모바일 네트워크에서는 연결이 자주 전환될 때 연속으로 여러 번 새로 고치지 마세요. 일시적인 네트워크 중단을 구독 만료로 오인할 수 있습니다.

업데이트 실패는 요청 실패와 해석 실패를 구분해야 합니다. 요청 실패는 보통 시간 초과, 이름 해석 오류 또는 연결 거부로 나타나므로 현재 네트워크, 시스템 시간과 구독 주소 접근 가능 여부를 확인해야 합니다. 해석 실패는 내용은 받았지만 클라이언트가 형식을 인식하지 못했다는 뜻이며, 로그인 페이지, 안내 문구 또는 호환되지 않는 데이터 구조가 반환되었을 수 있습니다. 이때 계속 업데이트를 눌러도 결과는 달라지지 않습니다. 로그의 응답 유형을 확인하고 현재 클라이언트가 해당 구독 형식을 지원하는지 점검하세요.

속도 측정 결과는 같은 조건에서만 비교하세요

클라이언트의 지연 시간 테스트, 연결성 테스트와 다운로드 테스트는 같은 지표가 아닙니다. 지연 시간 테스트는 특정 탐색 방식의 왕복 시간만 보여 주는 경우가 많아 웹 페이지 로딩이나 대용량 파일 전송 성능을 직접 나타내지 못합니다. 연결성 테스트는 대상에 도달할 수 있는지 확인하고, 실제 사용감은 대역폭, 패킷 손실, 대상 사이트와 현재 네트워크의 영향을 함께 받습니다. 따라서 노드는 같은 네트워크와 테스트 방식, 비슷한 시간대에 비교하고 서로 다른 기기의 수치를 직접 비교하지 마세요.

활성 서버를 선택한 뒤에는 안정적인 대상 한두 곳으로 확인하고 많은 노드를 연속해서 전환하지 마세요. 잦은 전환은 DNS 캐시, 기존 연결과 애플리케이션 재시도를 겹치게 하며 로그도 읽기 어렵게 만듭니다. 특정 애플리케이션에서만 노드가 실패한다면 먼저 프록시 모드, 대상 도메인과 실패 시간을 기록한 뒤 로그에서 해당 연결을 찾으세요. 화면 위치에 대한 자세한 설명은 v2rayN 인터페이스 기능 한눈에 보기를 참고하세요.

구독 문제 해결 기록 권장 항목:
1. 그룹 이름과 업데이트 시간
2. 업데이트 안내 또는 오류 문구
3. 업데이트 후 서버 항목 수가 변했는지 여부
4. 현재 활성 서버 이름
5. 사용한 프록시 모드와 테스트 대상

// PROXY MODE

시스템 프록시, 앱 프록시와 트래픽 인계 범위

로컬 포트는 트래픽이 코어로 들어가는 입구입니다

클라이언트가 시작되면 일반적으로 로컬 컴퓨터에서 하나 이상의 프록시 포트를 엽니다. HTTP 프록시는 표준 시스템 프록시를 지원하는 브라우저와 데스크톱 앱에 적합하고, SOCKS 프록시는 해당 프로토콜을 지원하는 소프트웨어에 개별 설정할 수 있습니다. 혼합 포트는 하나의 포트에서 여러 진입 방식을 지원합니다. 포트 자체가 트래픽이 사용할 노드를 결정하는 것은 아니며, 요청을 코어로 전달할 뿐입니다. 노드 선택, DNS 처리와 라우팅 규칙은 실행 설정이 결정합니다.

프록시가 적용되는지 확인할 때는 “코어가 수신 대기 중인지”와 “앱이 실제로 해당 입구를 가리키는지”를 함께 확인해야 합니다. 클라이언트가 실행 중으로 표시되어도 시스템 프록시가 꺼져 있으면 시스템 설정을 따르는 앱은 자동으로 코어에 들어가지 않습니다. 브라우저에 별도 프록시가 설정되어 있으면 시스템 프록시가 꺼져도 해당 브라우저는 로컬 포트를 계속 사용할 수 있습니다. 문제를 해결하기 전에 현재 어떤 인계 방식을 쓰는지 명확히 하고, 시스템 설정, 브라우저 확장 프로그램과 앱 내부 프록시가 동시에 적용되지 않도록 하세요.

시스템 프록시는 일반적인 데스크톱 앱에 적합합니다

시스템 프록시를 켜면 클라이언트가 운영 체제의 프록시 설정을 변경하고, 이를 지원하는 앱이 HTTP 또는 HTTPS 요청을 로컬 포트로 전달합니다. 설정이 간단해 브라우저, 일부 메신저와 일반적인 데스크톱 도구에 적합합니다. 다만 시스템 프록시를 읽지 않는 프로그램, 사용자 지정 네트워크 스택을 사용하는 앱, 일부 명령줄 도구와 특정 UDP 트래픽은 이 입구를 거치지 않을 수 있습니다.

클라이언트를 종료할 때는 정상적으로 종료하거나 먼저 시스템 프록시를 해제하세요. 프로그램이 비정상적으로 종료되면 시스템에 로컬 포트를 가리키는 설정이 남을 수 있지만 해당 포트를 수신하는 프로세스는 사라져 브라우저가 갑자기 인터넷에 연결되지 않을 수 있습니다. 이때는 먼저 시스템 프록시가 루프백 주소를 가리키는지 확인하고 설정을 끄거나 클라이언트를 다시 시작하세요. 노드를 계속 바꿔도 존재하지 않는 로컬 포트 문제는 해결되지 않습니다.

앱 내부 프록시로 정밀하게 제어하세요

개발 도구, 터미널 프로그램과 일부 브라우저는 프록시를 개별 지정할 수 있습니다. 앱 내부 설정은 적용 범위가 명확해 다른 소프트웨어에 영향을 주지 않는 것이 장점이고, 각 프로그램의 주소와 포트를 따로 관리해야 하는 것이 단점입니다. 프록시 주소에는 보통 127.0.0.1을 입력하며, 포트는 클라이언트 설정 페이지의 현재 값과 일치해야 합니다. 앱이 컨테이너, 가상 머신 또는 다른 기기에서 실행된다면 루프백 주소는 해당 환경 자체를 가리키므로 호스트 컴퓨터를 바로 의미하지 않습니다.

명령줄에서 확인할 때는 로컬 프록시를 명시적으로 지정해 “프록시 경로에 문제가 있는지”와 “시스템 프록시를 프로그램이 읽지 못하는지”를 구분할 수 있습니다. 아래 명령은 예시 사이트를 사용해 지정한 입구로 HTTP 요청을 보낼 수 있는지만 확인합니다. 포트 번호는 다른 기기의 설정을 복사하지 말고 클라이언트에 실제로 표시된 로컬 포트로 바꾸세요.

curl --proxy http://127.0.0.1:로컬 포트 https://example.com/

명령에 설명 문구를 넣고 싶지 않다면 먼저 클라이언트 설정 페이지에서 포트를 확인한 뒤 실제 숫자로 실행하세요. 정상적인 웹 응답이 반환되면 로컬 HTTP 프록시와 활성 노드를 기본적으로 사용할 수 있다는 뜻입니다. 로컬 주소에 연결할 수 없다는 메시지가 나오면 코어가 해당 포트를 열지 않았거나 포트 입력이 잘못된 것입니다. 연결은 되었지만 오래 응답하지 않으면 노드, 라우팅과 DNS 로그를 계속 확인해야 합니다.

// ROUTING

라우팅: 일치 조건, 순서와 기본 출구

라우팅은 출구만 결정하며 노드를 고쳐 주지는 않습니다

라우팅은 도메인, IP, 포트와 네트워크 유형 등의 조건에 따라 연결을 프록시 출구, 직접 연결 출구 또는 차단 출구로 전달합니다. 기본 연결이 이미 작동한다는 전제에서 동작합니다. 활성 노드 자체가 연결되지 않는다면 규칙을 더 추가해도 경로가 복구되지 않습니다. DNS가 비정상 결과를 반환하면 도메인 규칙도 예상대로 적용되지 않을 수 있습니다. 따라서 라우팅을 설정하기 전에 단순한 모드에서 노드를 먼저 확인하고 규칙을 단계적으로 추가하세요.

일반적인 규칙 세트에는 domain, ip, port, network, protocol 등의 필드가 포함됩니다. 도메인 규칙은 사이트별 분류에 적합하고, IP 규칙은 명확한 주소 대역에 적합하며, 포트 규칙은 서비스 유형을 제한할 때 사용합니다. 네트워크 규칙은 TCP와 UDP를 구분할 수 있습니다. 규칙의 outboundTag는 이미 존재하는 출구 태그를 가리키므로 태그 철자가 다르면 조건이 맞아도 예상한 결과를 얻을 수 없습니다.

규칙 순서는 구체적인 조건부터 일반적인 조건 순으로 정하세요

라우팅은 보통 목록 순서대로 판단하며 먼저 일치한 규칙을 실행합니다. 따라서 구체적인 예외 규칙은 범위가 넓은 규칙보다 앞에 두어야 합니다. 예를 들어 특정 하위 도메인은 프록시로 보내야 하지만 상위 도메인 집합 전체는 직접 연결한다면 하위 도메인 규칙을 먼저 배치해야 합니다. “모든 도메인”이나 “모든 IP” 같은 기본 조건을 맨 위에 두면 뒤의 규칙이 실행될 기회를 잃습니다. 편집을 마친 뒤에는 위에서 아래로 다시 읽어 각 규칙의 범위가 다음 규칙을 미리 가로채지 않는지 확인하세요.

domain: 접두사는 지정한 도메인과 하위 도메인을 매칭하고, full:은 완전한 도메인만 매칭하며, keyword:는 키워드로 매칭하고, regexp:는 정규 표현식을 사용합니다. 일반적인 설정에서는 명확한 도메인이나 잘 관리되는 geosite 분류를 우선 사용하고, 일반 규칙으로 표현할 수 없을 때만 정규 표현식을 고려하세요. 정규 표현식의 범위가 너무 넓으면 예상하지 못한 매칭이 발생하고 유지 관리 비용도 커집니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:service.example.com",
          "domain:example.net"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "udp",
        "port": "53",
        "outboundTag": "dns-out"
      }
    ]
  }
}

위 예시는 필드 구조만 보여 주며 서버 인증 정보는 포함하지 않습니다. 첫 번째 규칙은 두 개의 예시 도메인을 프록시 출구로 보냅니다. 두 번째 규칙은 사설 주소를 직접 연결해 LAN 기기에 접속할 때 우회하지 않도록 합니다. 세 번째 규칙은 UDP DNS 요청을 전용 출구로 보냅니다. 실제로 사용할 때는 실행 설정에 proxy, direct, dns-out 태그가 존재하는지 반드시 확인하세요. 클라이언트가 인터페이스를 통해 태그를 생성한다면 생성된 결과를 기준으로 삼습니다.

도메인 정책은 IP 규칙의 참여 시점을 좌우합니다

domainStrategy는 도메인 요청을 처리할 때 라우팅이 IP를 해석할지 결정합니다. AsIs에서는 라우팅이 주로 원래 도메인을 기준으로 매칭하며 IP 규칙만을 위해 능동적으로 해석하지 않습니다. IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 주소를 해석해 IP 규칙을 계속 적용합니다. IPOnDemand는 IP 매칭이 필요할 수 있을 때 더 일찍 해석합니다. 정책을 선택할 때는 DNS 설정과 함께 판단하고, 정책 이름을 연결 속도 단계로 이해하지 마세요.

규칙이 도메인을 중심으로 구성되어 있다면 먼저 도메인 정보가 라우팅 계층까지 유지되는지 확인하세요. geoip 분류에 크게 의존한다면 DNS 결과가 안정적이고 해석 경로가 예상과 맞는지 점검해야 합니다. 일부 앱은 도메인 없이 IP로 직접 연결하므로 geosite나 일반 도메인 규칙이 적용되지 않습니다. 이때는 IP 규칙이나 다른 식별 방식을 사용해야 합니다. 반대로 콘텐츠 전송 네트워크의 주소는 바뀔 수 있으므로 공인 IP 하나를 장기간 직접 입력하는 방식은 적합하지 않습니다.

결과를 추측하지 말고 로그로 매칭을 확인하세요

라우팅 문제를 해결할 때는 대상 도메인, 접속 시간, 최종 출구와 매칭된 규칙을 기록하세요. 클라이언트 로그 수준이 너무 낮으면 연결 성공 또는 실패만 보이고 라우팅 판단은 확인할 수 없습니다. 디버깅 중에는 로그 상세도를 일시적으로 높이고, 끝나면 일반 수준으로 되돌려 로그가 빠르게 늘어나지 않게 하세요. 대상이 예상한 규칙과 일치하지 않으면 규칙 순서, 도메인 표기, 출구 태그와 DNS 정책을 차례로 점검합니다.

사용자 지정 규칙은 나누어 추가하세요. 먼저 범위가 명확한 도메인 규칙 하나를 작성해 확인한 다음 분류 규칙과 기본 규칙을 추가합니다. 변경할 때마다 설정을 다시 불러와 해석 오류가 없는지 로그에서 확인하세요. 전체 문법과 우선순위 사례는 V2Ray 사용자 지정 라우팅 규칙 작성법에서 확인할 수 있습니다. 설정이 길어질수록 규칙의 목적을 메모하고 더 이상 필요 없는 예외 항목은 정기적으로 삭제하세요.

// TUN MODE

TUN 모드: 전체 인계, DNS와 제외 항목

TUN은 트래픽을 어디까지 인계할지 해결합니다

TUN은 가상 네트워크 인터페이스를 만들어 시스템 프록시 설정을 읽지 않는 앱의 트래픽도 클라이언트로 보낼 수 있게 합니다. UDP, 명령줄 프로그램, 독립 네트워크 스택 앱을 처리하거나 라우팅 규칙을 일관되게 적용해야 할 때 적합합니다. TUN이 더 빠른 프록시 모드인 것은 아니며 노드 품질을 자동으로 개선하지도 않습니다. 바뀌는 것은 트래픽이 코어로 들어가는 경로입니다. 기본 노드, 구독과 라우팅 설정은 기존 로직을 그대로 따릅니다.

TUN을 켜기 전에 시스템 프록시로 활성 노드가 작동하는지 먼저 확인하세요. 시스템 프록시에서도 연결할 수 없다면 TUN을 바로 켜는 순간 가상 인터페이스, DNS와 라우팅 테이블이라는 세 가지 변수가 추가됩니다. 올바른 순서는 클라이언트와 코어 정상 여부 확인, 노드 연결 확인, 기본 규칙 확인, 마지막으로 TUN 활성화입니다. 문제가 생겼을 때 권한, 가상 인터페이스 또는 인계 규칙으로 범위를 좁힐 수 있습니다.

권한과 시스템 네트워크 구성 요소를 먼저 준비하세요

가상 인터페이스 생성, 라우팅 변경과 DNS 처리는 보통 추가 시스템 권한이 필요합니다. Windows에서는 클라이언트 안내에 따라 권한을 확인하고, macOS에서는 해당 네트워크 구성 요소를 허용해야 합니다. Linux는 현재 실행 방식에 네트워크 인터페이스를 관리할 권한이 있는지 확인하세요. Android 클라이언트는 시스템이 제공하는 네트워크 연결 인터페이스로 로컬 터널을 만들며, 처음 켤 때 사용자의 확인이 필요합니다. 권한 단계가 완료되지 않으면 인터페이스에 잠시 시작 중으로 표시된 뒤 로그에 인터페이스 생성 실패가 기록될 수 있습니다.

다른 가상 네트워크 소프트웨어, 기업 네트워크 구성 요소 또는 보안 도구를 함께 실행하면 여러 프로그램이 라우팅 테이블을 동시에 수정할 수 있습니다. LAN 접속 불가, 비정상적인 DNS 요청 경로, 네트워크 전환 후 연결 중단 등이 나타날 수 있습니다. 문제를 해결할 때는 트래픽을 인계하는 도구 하나만 남겨 TUN이 단독으로 정상 작동하는지 확인한 뒤 다른 구성 요소를 하나씩 다시 켜세요. 여러 프로그램에서 기본 라우트 인계를 동시에 활성화하지 마세요.

DNS는 라우팅 정책과 함께 설계해야 합니다

TUN 모드에서 도메인 해석은 대상 IP뿐 아니라 도메인 규칙이 충분한 정보를 얻을 수 있는지도 결정합니다. 클라이언트에는 DNS 하이재킹, 가상 주소 매핑, 원격 DNS와 로컬 DNS 등의 설정이 있을 수 있습니다. 목표는 옵션을 많이 쌓는 것이 아니라 질의가 예상한 경로로 들어가고 결과가 요청한 앱으로 돌아오며 라우팅 계층에 올바른 도메인 연결 정보가 남도록 하는 것입니다. IP로는 접속되지만 도메인 접속이 실패한다면 먼저 DNS를 확인하고 즉시 프로토콜을 바꾸지 마세요.

LAN 이름, 프린터와 라우터 관리 도메인은 보통 로컬 DNS에 의존합니다. 모든 질의를 원격 DNS로 보내면 이러한 이름을 인식하지 못할 수 있습니다. 사설 주소, LAN 도메인과 시스템에 필요한 해석은 직접 연결 경로로 남겨 두고, 나머지 질의는 규칙에 따라 처리할 수 있습니다. 가상 주소 기능을 켤 때는 해당 주소 대역을 현재 클라이언트만 관리하도록 하고 회사 네트워크, 컨테이너 네트워크나 기존 가상 대역과 겹치지 않는지도 확인하세요.

제외 항목은 로컬 리소스를 보호합니다

일반적인 제외 대상에는 루프백 주소, 사설 네트워크 주소, LAN 기기와 프록시 경로로 보내지 않아야 하는 시스템 서비스가 포함됩니다. 제외 규칙은 최대한 정확하게 작성하세요. 앱 전체를 제외하면 간단하지만 해당 앱의 모든 연결이 라우팅을 우회합니다. 주소 대역을 지나치게 넓게 제외하면 원래 매칭되어야 할 대상이 직접 연결될 수 있습니다. 변경하기 전에 보호할 대상을 명확히 한 뒤 앱, 주소 또는 도메인 기준으로 제외하세요.

모바일 기기에서는 앱별 프록시도 확인해야 합니다. 지정한 앱만 선택하면 선택하지 않은 소프트웨어는 터널에 들어가지 않습니다. 제외 모드에서는 목록의 앱이 직접 연결됩니다. 두 방식은 의미가 반대이므로 설정을 옮긴 후 다시 확인하세요. 데스크톱에서 가상 머신이나 컨테이너가 호스트의 프록시에 접속하게 하려면 네트워크 경계와 전달 설정도 필요합니다. 수신 대기 주소를 모든 인터페이스에 단순히 공개해서는 안 됩니다.

Windows DNS 캐시 새로 고침:
ipconfig /flushdns

Linux 라우팅 확인:
ip route

macOS 기본 라우팅 확인:
route -n get default

// MAINTENANCE

일상적인 유지 관리, 로그 읽기와 문제 격리

관리 대상은 프로그램, 설정과 실행 상태로 나뉩니다

클라이언트 관리는 설치 파일 업데이트에만 집중해서는 안 됩니다. 프로그램 파일은 인터페이스와 기능을 결정하고, 설정 데이터에는 구독, 서버, 라우팅과 환경 설정이 저장되며, 실행 상태에는 현재 노드, 시스템 프록시, TUN, 로그와 네트워크 인터페이스가 포함됩니다. 프로그램을 업데이트한다고 잘못된 구독이 자동으로 고쳐지는 것은 아니며, 구독을 다시 가져온다고 포트 충돌이 해결되는 것도 아닙니다. 문제를 처리하기 전에 어느 계층에 속하는지 판단하면 불필요한 작업을 줄일 수 있습니다.

설정 백업에는 최소한 구독 주소, 사용자 지정 라우팅, DNS 설정과 수동 노드가 포함되어야 합니다. 백업 파일은 프로그램 설치 파일과 분리해 저장하고 어떤 클라이언트에 적용되는지 기록하세요. v2rayN, v2rayNG와 v2flyNG는 설정 구성 방식이 다르므로 데이터 디렉터리 전체를 서로 덮어쓰지 마세요. 복원할 때는 먼저 플랫폼에 맞는 클라이언트를 설치하고, 클라이언트가 제공하는 가져오기 방식으로 인식 가능한 내용을 복원한 뒤 로컬 경로, 포트와 권한을 확인하세요.

시간과 계층을 기준으로 로그를 읽으세요

효과적인 로그 분석은 재현 시간 기록에서 시작합니다. 먼저 이전 로그를 지우거나 표시한 뒤 구독 업데이트, 코어 시작 또는 특정 대상 접속처럼 명확한 작업을 한 번 실행하고 곧바로 새로 추가된 기록을 확인하세요. 수천 줄의 과거 내용에서 무작정 “error”를 검색하지 마세요. 이전 오류가 이미 해결되었을 수 있습니다. 작업이 발생한 정확한 시간을 기록하면 인터페이스 동작과 코어 출력을 서로 대조할 수 있습니다.

시작 단계에서는 설정 해석, 포트 수신 대기와 코어 프로세스를 중점적으로 확인합니다. 연결 단계에서는 DNS, 라우팅 출구, 핸드셰이크와 시간 초과를 확인하고, 실행 단계에서는 네트워크 전환, 인터페이스 종료와 반복 재시도를 살펴봅니다. 연결 거부는 대상 포트가 명시적으로 거부했거나 로컬 포트가 존재하지 않는다는 뜻인 경우가 많습니다. 시간 초과는 제한 시간 안에 응답을 받지 못했다는 뜻이고, 이름 해석 실패는 DNS 문제를 가리킵니다. 설정 해석 실패는 코어가 아직 연결 단계에 진입하지 못했다는 의미입니다. 이러한 오류는 같은 방식으로 처리할 수 없습니다.

유효한 문제 기록에는 다음 항목이 포함되어야 합니다:
- 운영 체제와 클라이언트 이름
- 현재 인계 방식: 시스템 프록시, 앱 프록시 또는 TUN
- 문제가 발생한 시간
- 활성 서버와 구독 그룹
- 문제를 재현할 수 있는 대상
- 해당 시간대의 로그 내용
- 최근 변경한 설정

최소 설정으로 변수를 격리하세요

복잡한 설정에서 문제가 생기면 먼저 최소 경로를 만드세요. 사용 가능한 서버 하나만 남기고 TUN을 끄며 시스템 프록시를 사용하고 사용자 지정 라우팅과 추가 DNS 규칙을 비활성화합니다. 최소 경로에서 복구된다면 DNS, 라우팅, TUN, 앱 제외 항목 순서로 한 종류씩 다시 추가하세요. 매번 한 가지 설정만 바꾸면 어느 계층에서 문제가 생겼는지 명확히 알 수 있습니다.

최소 경로에서도 실패한다면 로컬 포트, 시스템 시간, 현재 네트워크와 서버 매개변수를 계속 확인하세요. 다른 네트워크로 전환하는 것은 현재 접속 환경과 관련된 문제인지 판단하기 위한 격리 방법일 뿐 로그 분석을 대신할 수 없습니다. 동일한 설정이 여러 네트워크에서 모두 실패한다면 노드 매개변수와 코어 출력으로 돌아가고, 특정 네트워크에서만 실패한다면 DNS, 라우팅, 네트워크 인증 페이지와 해당 네트워크의 장시간 연결 처리 방식을 점검하세요.

업데이트와 롤백 모두 검증 가능하게 하세요

클라이언트를 업데이트하기 전에 사용한 모드, 활성 그룹과 주요 사용자 지정 설정을 포함해 현재 정상 상태를 기록하세요. 업데이트 후에는 프로그램 시작, 구독 읽기와 노드 연결을 먼저 확인한 다음 고급 기능을 복원합니다. 업그레이드 후 문제가 생기면 설정 마이그레이션 실패와 실행 동작 변화를 구분해야 합니다. 이전 디렉터리를 바로 덮어쓰면 더 이상 맞지 않는 파일이 남을 수 있고, 완전히 비우면 구독과 규칙을 잃을 수 있습니다. 원본 디렉터리 사본을 보존하고 별도 위치에서 검증하는 방법이 더 안전합니다.

롤백할 때 구독 내용과 클라이언트 프로그램을 동시에 되돌리지 마세요. 어느 항목이 기능을 복구했는지 판단할 수 없게 됩니다. 먼저 프로그램을 복원하고 같은 설정으로 테스트한 뒤, 여전히 문제가 있으면 설정 변경을 확인하세요. 평소에도 만료된 서버, 중복 그룹과 더 이상 사용하지 않는 라우팅 예외를 정리해야 합니다. 설정이 간결할수록 업데이트 후 동작을 검증하기 쉽습니다.

// ADVANCED PATH

고급 활용 경로: 작동하는 설정에서 설명 가능한 설정으로

고급 설정의 기준은 옵션 개수가 아닙니다

안정적인 설정의 핵심은 각 항목에 명확한 목적이 있고 어느 계층에 영향을 주는지 설명할 수 있는 것입니다. 구독을 가져오고 프록시를 켜는 것은 시작에 불과합니다. 특정 트래픽이 왜 프록시를 사용하는지 또는 직접 연결되는지, DNS가 어디에서 해석되는지, TUN이 어떤 앱을 인계하는지 설명할 수 있어야 유지 관리 가능한 시스템을 만든 것입니다. 고급 활용은 모든 고급 스위치를 한 번에 켜는 방식이 아니라 실제 필요에 따라 기능을 하나씩 추가하고 검증 방법을 남기는 과정이어야 합니다.

학습 경로를 네 계층으로 나누는 것이 좋습니다. 첫 번째는 클라이언트 조작으로, 구독, 활성 서버, 로그와 시스템 프록시를 익힙니다. 두 번째는 연결 구조로, 프로토콜, 전송, 보안 매개변수와 코어의 관계를 이해합니다. 세 번째는 트래픽 제어로, 도메인 정책, 출구 태그, DNS와 TUN을 다룹니다. 네 번째는 유지 관리 작업으로, 설정 백업, 문제 격리, 변경 평가와 안전한 롤백을 수행합니다. 이전 계층이 안정되지 않았다면 다음 계층으로 서두르지 마세요.

자신만의 설정 기준선을 만드세요

설정 기준선은 이미 작동하는 것으로 확인했으며 내용이 가능한 한 간결한 설정입니다. 하나의 구독 그룹, 하나의 활성 서버, 기본 로컬 포트, 기본 시스템 프록시와 꼭 필요한 소수의 규칙을 포함해야 합니다. 새 설정을 추가할 때마다 기준선을 복사하고 변경 목적과 검증 결과를 기록하세요. 문제가 생기면 즉시 기준선으로 돌아가 장애가 새 설정에서 발생했는지 외부 네트워크 변화에서 발생했는지 판단할 수 있습니다.

기준선에는 플랫폼별 차이도 기록해야 합니다. 같은 구독이라도 v2rayN, v2rayNG와 v2flyNG에서는 인터페이스 위치, DNS 구현과 라우팅 생성 방식이 다를 수 있습니다. 세 기기의 모든 스위치를 완전히 동일하게 만들 필요는 없습니다. 일관되게 유지해야 할 것은 “LAN은 직접 연결”, “지정한 업무는 프록시 사용”, “일치하지 않는 트래픽은 기본 출구 사용”과 같은 목표 동작이지, 인터페이스 화면의 옵션 순서가 아닙니다.

규칙을 점검 가능한 의사 결정표로 작성하세요

규칙이 늘어나면 먼저 텍스트로 의사 결정표를 작성한 뒤 클라이언트 설정으로 옮겨 보세요. 각 행에는 최소한 매칭 대상, 조건, 예상 출구와 검증 대상을 포함해야 합니다. 예를 들어 “사설 주소—geoip:private—direct—라우터 관리 페이지 접속” 또는 “지정 도메인—domain 규칙—proxy—라우팅 로그 확인”처럼 작성합니다. 이 방식은 규칙 중복을 발견하는 데 도움이 되며 클라이언트를 바꾼 뒤에도 다시 구현하기 쉽습니다.

기본 출구를 명확히 정해야 합니다. 구체적인 규칙이 하나도 일치하지 않을 때 트래픽이 어디로 가는지는 라우팅 설계에서 가장 중요한 경계입니다. 프록시를 기본 출구로 사용한다면 어떤 로컬 리소스를 먼저 직접 연결해야 하는지 정하고, 직접 연결을 기본으로 사용한다면 어떤 대상이 반드시 프록시로 들어가야 하는지 정하세요. 규칙 순서를 기억하는 데 의존하지 말고 설정 구조 자체가 우선순위를 드러내도록 하세요.

설정 변경 기록 예시:

목표: LAN 리소스를 직접 연결 상태로 유지
매칭: geoip:private
출구: direct
위치: 정확한 업무 규칙 뒤, 공용 네트워크 기본 규칙 앞
검증: 로컬 게이트웨이와 LAN 기기에 접속
롤백: 해당 규칙을 비활성화하고 설정 다시 불러오기

DNS와 네트워크 관찰 도구를 단계적으로 익히세요

고급 단계에서는 기본적인 이름 해석과 포트 확인 방법을 익히는 것이 좋습니다. nslookup 또는 dig로 어떤 해석기가 도메인 결과를 반환했는지 확인할 수 있고, ipconfig, ip route, route 등의 도구로 인터페이스와 라우팅을 확인할 수 있습니다. ss는 로컬 수신 대기 포트를 확인하는 데 사용할 수 있습니다. 이러한 도구는 클라이언트 로그를 대신하려는 것이 아니라, 운영 체제 측에서 클라이언트가 구축했다고 표시한 상태가 실제로 존재하는지 검증하기 위한 것입니다.

관찰 결과는 반드시 맥락과 함께 해석해야 합니다. 도메인이 해석된다고 프록시 연결이 성공하는 것은 아니며, 포트가 수신 대기 중이라고 원격 노드를 사용할 수 있는 것도 아닙니다. TUN 인터페이스가 존재해도 모든 앱이 인계된다는 뜻은 아닙니다. 각 도구는 하나의 질문에만 답합니다. 여러 질문을 나누어 확인하면 정상 결과 하나만 보고 너무 일찍 점검을 끝내는 실수를 피할 수 있습니다.

장기 유지 관리 순환 만들기

완전한 순환은 “현재 상태 기록—단일 변경 제안—검증 실행—유지 또는 롤백”으로 구성됩니다. 구독 업데이트, 코어 설정 전환, 라우팅 추가와 TUN 활성화도 이 흐름을 따라야 합니다. 변경에 성공하면 최종 결과를 기록하고, 실패하면 기준선으로 복구하면서 오류 로그를 보존하세요. 기록이 쌓이면 반복적인 시행착오가 재사용 가능한 판단 경로로 바뀝니다.

클라이언트 선택도 주기적으로 재검토할 수 있습니다. 데스크톱에서는 v2rayN을 주요 관리 도구로 사용하고, Android에서는 코어와 설정 요구에 따라 v2rayNG와 v2flyNG 중에서 선택하세요. 세 클라이언트의 차이는 v2rayN, v2rayNG, v2flyNG 클라이언트 비교에서 확인할 수 있습니다. 선택 기준은 플랫폼, 설정 호환성과 유지 관리 요구이지 인터페이스 옵션의 개수가 아닙니다.

이 가이드를 마친 뒤 빠른 시작 가이드로 돌아가 전체 흐름을 다시 진행하며 각 단계의 역할을 설명할 수 있는지 확인하세요. 클라이언트를 교체하거나 추가로 설치해야 한다면 다운로드 페이지에서 플랫폼에 맞는 설치 파일을 선택하고, 구체적인 오류가 발생하면 문제 해결에서 증상으로 검색하세요. 최종 목표는 절대 바뀌지 않는 설정 파일을 보관하는 것이 아니라 검증하고 조정하며 복구할 수 있는 작업 방식을 익히는 것입니다.