V2Ray 입문부터 고급 활용까지: 구독, 분할 라우팅과 TUN

핵심 개념: 클라이언트, 코어, 프로토콜과 구독부터 구분하기

클라이언트는 조작을, 코어는 연결을 담당합니다

V2Ray을 사용할 때 가장 혼동하기 쉬운 네 가지 요소는 클라이언트, 코어, 프로토콜과 구독입니다. 클라이언트는 사용자가 직접 조작하는 그래픽 인터페이스로, 구독 저장, 노드 선택, 프록시 모드 전환, 실행 설정 생성과 로그 표시를 담당합니다. v2rayN, v2rayNG, v2flyNG는 모두 클라이언트입니다. 코어는 백그라운드에서 설정을 읽고 연결 수립, 트래픽 전달, 도메인 조회와 라우팅 매칭을 수행합니다. 대표적인 코어 계열로는 V2Fly와 Xray가 있으며, 두 계열은 비슷한 설정 방식을 이어받았지만 지원하는 프로토콜 기능과 필드 세부 사항은 다를 수 있습니다.

따라서 “클라이언트에서 특정 링크를 가져올 수 있다”는 사실이 “현재 코어가 그 링크를 반드시 올바르게 실행할 수 있다”는 뜻은 아닙니다. 클라이언트는 먼저 공유 링크나 구독 내용을 인식한 뒤 매개변수를 코어 설정으로 변환해야 하며, 코어 역시 해당 프로토콜·전송 방식·보안 매개변수를 지원해야 합니다. 문제를 해결할 때는 클라이언트를 반복해서 재설치하기보다 가져오기 단계, 설정 생성 단계, 실제 연결 단계 중 어디에서 문제가 발생했는지 먼저 판단해야 합니다. 가져온 뒤 노드가 보이지 않는다면 대개 구독 내용이나 파싱 문제입니다. 노드는 있지만 시작 오류가 난다면 필드 호환성을 확인해야 합니다. 정상적으로 시작되지만 대상 주소에 접속할 수 없다면 프록시, 라우팅과 네트워크 경로를 계속 점검하세요.

프로토콜은 통신 방식을 설명하며, 전송 매개변수는 한 세트로 맞아야 합니다

VMess, VLESS, Trojan 등의 이름은 클라이언트와 서버가 인증하고 데이터를 구성하는 방식을 나타냅니다. 속도 등급이 아니며 연결 품질을 단독으로 결정하지도 않습니다. 같은 프로토콜도 TCP, WebSocket, gRPC 등의 전송 방식과 조합될 수 있고 TLS나 REALITY 같은 보안 설정을 사용할 수 있습니다. 주소, 포트, 사용자 식별자, 전송 방식, 호스트명, 경로와 보안 옵션은 서버 설정과 하나씩 일치해야 합니다. 한 필드만 바꾼다고 “비슷하지만 사용 가능한” 결과가 나오는 경우는 드물며, 대개 핸드셰이크 실패로 이어집니다.

공유 링크는 이러한 매개변수를 전달하기 쉬운 텍스트로 인코딩하고, 구독은 여러 공유 링크나 구조화된 노드 정보를 갱신 가능한 하나의 주소에 모아 둡니다. 구독 주소 자체가 네트워크 노드는 아니며, 원격 설정 목록에 가깝습니다. 클라이언트가 구독을 갱신하면 먼저 목록을 요청하고, 노드를 파싱한 다음 로컬 그룹에 기록합니다. 갱신 성공은 목록을 읽고 파싱했다는 뜻일 뿐, 모든 노드에 연결할 수 있다는 의미는 아닙니다. 반대로 구독을 일시적으로 갱신하지 못해도 클라이언트가 마지막으로 동기화한 설정을 저장하고 있으므로 기존 로컬 노드는 계속 사용할 수 있습니다.

시스템 프록시, 라우팅과 DNS는 서로 다른 계층입니다

시스템 프록시는 프록시 설정을 지원하는 애플리케이션이 요청을 클라이언트로 보낼지 결정합니다. 라우팅 규칙은 클라이언트가 요청을 받은 뒤 프록시 출구, 직접 연결 출구 또는 차단 중 무엇을 선택할지 결정합니다. DNS는 도메인을 주소로 변환하며 도메인 규칙 매칭에도 관여할 수 있습니다. 세 요소는 따로 관찰해야 합니다. 브라우저는 되는데 특정 프로그램이 안 된다면 해당 프로그램이 시스템 프록시를 읽지 않을 수 있습니다. 모든 애플리케이션이 클라이언트로 들어오지만 일부 주소가 잘못된 출구로 나간다면 대개 라우팅 규칙 문제입니다. 도메인은 실패하지만 주소로 직접 접속하면 응답이 있다면 DNS 경로를 확인하세요.

클라이언트 선택: 플랫폼, 코어와 관리 방식

데스크톱에서는 v2rayN을 우선 사용하세요

v2rayN은 Windows, macOS와 Linux를 지원하며 데스크톱용 주 클라이언트로 적합합니다. 구독 그룹, 노드 선택, 시스템 프록시, 라우팅 규칙, TUN과 로그를 하나의 인터페이스에서 관리할 수 있어 장기간 유지 관리가 편리합니다. Windows 사용자는 최신 크로스플랫폼 데스크톱 인터페이스와 기존 WPF 인터페이스 중에서 선택할 수 있습니다. 두 버전의 핵심 기능은 같고, 주된 차이는 인터페이스 기술과 조작 방식입니다. macOS는 프로세서 아키텍처에 맞는 설치 파일을 선택해야 하며, Linux는 배포판의 패키지 형식에 맞춰 선택합니다.

여러 구독을 관리하거나 업무용과 일상용 그룹을 따로 유지하고, 사용자 지정 라우팅을 배워 보려는 경우에는 v2rayN의 데스크톱 관리 방식이 더 적합합니다. 먼저 구독 출처별로 그룹을 만든 다음 그룹 안에서 노드를 선택할 수 있습니다. 이렇게 하면 특정 출처를 갱신할 때 모든 노드가 추적하기 어려운 하나의 목록으로 섞이지 않습니다. 사용하기 전에 “그룹은 설정 출처이고 노드는 연결 대상”이라는 점을 분명히 하세요. 노드 이름을 자주 바꾸는 것으로 그룹 관리를 대신하지 않는 것이 좋습니다.

Android에서는 v2rayNG와 v2flyNG 중에서 선택하세요

v2rayNG는 Xray 코어를 사용하는 방식으로, 일반적으로 Android에서 우선 선택됩니다. v2flyNG는 V2Fly 코어를 사용하며 해당 코어의 기능이나 설정 호환성이 필요한 경우에 활용할 수 있습니다. 두 클라이언트 모두 구독 가져오기, 노드 전환과 VPN 인터페이스 기반 트래픽 처리를 지원하지만 메뉴 이름, 라우팅 옵션과 코어 지원 범위는 완전히 같지 않습니다. 데스크톱에서 내보낸 고급 규칙 전체가 모바일에서 그대로 이전된다고 보장할 수 없으므로 클라이언트가 실제로 인식하는 필드를 기준으로 판단해야 합니다.

설치 파일의 아키텍처는 기기와 일치해야 합니다. 대부분의 최신 Android 기기는 arm64를 사용하며, 범용 버전은 아키텍처를 확인하기 어렵거나 다른 아키텍처와의 호환성이 필요한 경우에 적합합니다. 아키텍처는 설치 파일 실행 가능 여부에만 영향을 주며 구독 내용이나 프로토콜 매개변수는 바꾸지 않습니다. arm64 버전이 정상적으로 설치된다면 연결 문제 때문에 범용 버전으로 바꿀 필요는 없습니다. 연결 이상은 로그, 노드 매개변수와 네트워크 조건을 다시 점검하세요.

설정 문제를 클라이언트 교체로 가리지 마세요

같은 설정도 클라이언트에 따라 다르게 동작할 수 있지만, 클라이언트 교체를 첫 번째 문제 해결 방법으로 삼아서는 안 됩니다. 먼저 프로토콜, 전송, 보안 매개변수와 오류 로그를 기록한 뒤 코어 기능 차이인지 판단하세요. 특정 클라이언트에서 설정을 가져올 수 없다면 공유 형식이 완전한지 확인해야 합니다. 가져올 수 있지만 시작되지 않는다면 생성된 설정이나 코어 로그를 확인하세요. 특정 네트워크 환경에서만 실패한다면 클라이언트 비호환으로 단정하지 말고 네트워크 경로와 DNS를 비교하세요.

클라이언트 선택을 마쳤다면 주 도구 하나를 정해 로그 위치, 설정 디렉터리와 복구 방법을 익히는 것이 좋습니다. 여러 클라이언트 사이에서 설정을 반복해서 가져오면 중복 노드, 오래된 그룹과 서로 다른 기본 라우팅 값이 생겨 이후 판단이 어려워집니다. 데스크톱은 v2rayN을 관리 중심으로 사용하고, 모바일은 코어 요구 사항에 따라 v2rayNG 또는 v2flyNG를 선택하는 조합이 비교적 명확합니다. 구체적인 설치入口와 시스템 아키텍처 설명은 플랫폼별로 클라이언트 다운로드 페이지에서 확인할 수 있습니다.

설치 및 초기 설정: 복구 가능한 기준 상태부터 만들기

다운로드 전에 시스템과 프로세서 아키텍처를 확인하세요

Windows에서는 데스크톱 버전과 기존 WPF 버전 중 무엇을 사용할지 먼저 결정해야 합니다. 여러 데스크톱 시스템에서 비슷한 인터페이스를 유지하고 싶다면 데스크톱 버전을, 전통적인 Windows 조작 방식이 익숙하다면 WPF 버전을 선택할 수 있습니다. macOS 기기는 Apple Silicon과 Intel 프로세서를 구분해야 하며, 설치 파일 아키텍처를 잘못 고르면 시작되지 않거나 별도의 호환 처리가 필요할 수 있습니다. Linux 사용자는 배포판에 맞는 deb 또는 rpm 패키지를 사용하고 x64와 arm64도 구분해야 합니다. Android에서는 기기가 arm64인지 먼저 확인하고, 확인하기 어려울 때 범용 버전을 고려하세요.

설치 디렉터리는 현재 사용자가 읽고 쓸 수 있는 위치여야 합니다. 클라이언트는 실행 중 구독, 로그, 라우팅 설정과 인터페이스 설정을 저장하므로 접근이 엄격히 제한된 디렉터리에 두면 갱신 후 설정을 저장하지 못할 수 있습니다. Windows 포터블 환경에서는 프로그램을 임시 압축 해제 폴더에 장기간 두지 마세요. macOS는 처음 실행한 뒤 앱이 설정을 저장할 수 있는지 확인해야 합니다. Linux는 설치가 완료되었다는 사실만으로 판단하지 말고 애플리케이션 메뉴나 터미널에서 정상 실행되는지 확인하세요.

첫 실행에서는 필요한 항목만 설정하세요

처음 v2rayN을 열면 인터페이스 언어, 설정 저장 위치와 로그 위치부터 확인하고 고급 옵션을 모두 즉시 활성화하지 마세요. 기본 라우팅은 유지하고 TUN은 끈 상태로 두며, 자동 연결도 설정하지 말고 최소 연결 테스트 한 번만 완료하는 것이 좋습니다. 최소 기준 상태는 네 가지입니다. 클라이언트가 정상적으로 시작되고, 구독을 가져올 수 있으며, 선택한 노드로 코어가 실행되고, 시스템 프록시를 켠 뒤 브라우저가 클라이언트를 통해 대상 주소에 접속할 수 있어야 합니다. 이 네 가지가 안정된 다음 자동 갱신, 시작 시 실행과 사용자 지정 분할 라우팅을 추가하세요.

시스템 시간은 쉽게 놓치는 기본 조건입니다. 일부 보안 연결은 시간 오차에 민감하므로 기기의 시간이나 시간대가 크게 틀리면 인증서 검증과 핸드셰이크 문제가 발생할 수 있습니다. 먼저 시스템 자동 시간 동기화를 켠 뒤 프로토콜 매개변수를 점검하세요. 프록시 포트도 로컬의 다른 프로그램과 충돌하지 않아야 합니다. 로그에 수신 주소가 이미 사용 중이라고 표시되면 이전 클라이언트를 종료하거나 점유 프로그램을 확인하세요. 브라우저나 다른 애플리케이션이 이전 포트를 계속 참조할 수 있으므로 포트를 연달아 여러 개 바꾸지 않는 것이 좋습니다.

설정 디렉터리와 종료 방법 이해하기

그래픽 창을 닫았다고 클라이언트 프로세스가 반드시 종료되는 것은 아닙니다. 데스크톱 클라이언트가 시스템 트레이에 상주하면 창을 닫은 뒤에도 코어와 시스템 프록시가 계속 실행될 수 있습니다. 설치 디렉터리를 수정하거나 프로그램 파일을 교체하거나 백업을 복원하기 전에 트레이 메뉴에서 종료를 실행하고 관련 프로세스가 끝났는지 확인하세요. 창만 닫은 뒤 디렉터리를 바로 옮기면 파일 점유, 설정 저장 중단 또는 시스템 프록시가 이전 포트를 계속 가리키는 문제가 생길 수 있습니다.

설정 디렉터리에는 보통 클라이언트 설정, 노드 데이터베이스, 구독 정보, 라우팅 규칙과 로그가 들어 있습니다. 백업할 때는 클라이언트를 완전히 종료한 뒤 현재 노드만 내보내지 말고 설정 디렉터리 전체를 복사해야 합니다. 공유 링크만 저장하면 그룹, 사용자 지정 라우팅과 인터페이스 설정을 보존할 수 없습니다. 프로그램 디렉터리만 복사하면 시스템이 별도로 저장한 사용자 데이터를 놓칠 수 있습니다. 위치는 플랫폼과 클라이언트 형태에 따라 달라지므로 클라이언트의 설정 디렉터리 열기 또는 백업 기능을 우선 사용하고 실제 경로를 기록하세요.

최초 설치 점검 순서
1. 시스템과 프로세서 아키텍처 확인
2. 장기간 사용할 위치에 설치하거나 압축 해제
3. 클라이언트를 시작하고 로그 위치 찾기
4. 기본 라우팅 유지, TUN은 아직 활성화하지 않기
5. 구독 하나를 가져오고 노드 하나 선택
6. 시스템 프록시를 켜고 브라우저 테스트 완료
7. 클라이언트를 종료하고 시스템 프록시가 복원되었는지 확인

종료 테스트는 매우 중요합니다. 정상적으로 종료한 뒤에도 시스템이 로컬 프록시 포트를 계속 가리키면 일반 네트워크 요청에 영향을 줄 수 있습니다. 클라이언트를 다시 시작할 때는 시스템 프록시 상태와 인터페이스 표시가 일치하는지 확인하세요. 일치하지 않으면 먼저 클라이언트의 시스템 프록시 정리 기능을 사용한 다음 시스템 네트워크 설정에서 확인합니다. “기기를 재부팅하면 복구된다”는 방법을 일상적인 해결책으로 삼지 마세요. 프록시 스위치와 프로세스 상태를 이해하면 대부분 직접 해결할 수 있습니다.

구독 및 노드: 가져오기, 갱신, 그룹화와 필터링

구독 가져오기는 노드를 한 번 복사하는 작업이 아닙니다

구독 주소는 노드 목록을 지속적으로 가져오는 데 사용됩니다. 공유 링크 하나를 직접 붙여 넣는 방식은 임시 테스트에 적합하지만, 장기간 사용할 때는 구독을 별도 그룹에 저장해야 합니다. 가져오기 전에 주소가 완전한지 확인하고, 특히 복사 과정에서 앞뒤 공백, 줄바꿈 또는 메신저가 덧붙인 문장 부호가 포함되지 않았는지 살펴보세요. 구독 이름은 “일상 구독”, “테스트 설정”처럼 출처나 용도를 나타내야 합니다. 노드는 갱신되지만 출처 관계는 유지되어야 하므로 현재 노드 이름을 구독 이름으로 사용하지 않는 것이 좋습니다.

v2rayN에서 구독을 추가한 뒤에는 먼저 구독 설정을 저장하고 갱신을 실행해야 합니다. 일부 사용자는 “구독 추가”와 “구독 갱신”을 한 단계로 생각해 주소만 저장하고 노드를 생성하지 못합니다. 갱신이 끝나면 세 가지를 확인하세요. 대상 그룹이 나타났는지, 그룹 안에 노드가 있는지, 기존 수동 노드가 별도 그룹에 남아 있는지 확인합니다. 갱신 후 목록 전체가 비어 있다면 바로 다시 덮어써서 갱신하지 말고 구독 로그를 확인해 응답이 비어 있는지, 형식을 파싱할 수 없는지, 그룹 필터가 결과를 숨겼는지 판단하세요.

변경과 추적 가능성을 함께 고려한 갱신 전략

자동 갱신 간격을 지나치게 짧게 설정하지 마세요. 구독 내용은 보통 분 단위로 갱신할 필요가 없으며, 잦은 요청은 실제 이득 없이 문제 해결 중 노드 목록만 계속 바꿀 수 있습니다. 설정 출처의 갱신 빈도에 따라 몇 시간에서 하루 정도로 정하고 수동 갱신入口도 남겨 두세요. 특정 노드를 점검할 때는 자동 갱신을 잠시 중지하거나 노드의 핵심 매개변수를 기록해 원격 목록 때문에 테스트 중 이름, 주소나 정렬 순서가 바뀌지 않도록 하세요.

구독 갱신과 노드 테스트는 별개의 작업입니다. 갱신은 설정 목록을 가져올 수 있는지만 확인하고, 연결성 테스트는 실제 노드를 호출합니다. 테스트 결과도 TCP 연결 가능 여부, 실제 연결 지연 시간과 다운로드 속도를 구분해야 합니다. TCP 연결은 대상 주소와 포트가 응답한다는 뜻일 뿐입니다. 실제 연결 지연 시간에는 프로토콜 핸드셰이크가 포함되고, 다운로드 속도는 대역폭, 서버 부하와 대상 리소스의 영향을 받습니다. 숫자 하나만으로 정렬하지 않으려면 지연 시간 테스트의 차이와 사용 순서를 이어서 읽어 보세요.

그룹, 중복 제거와 만료된 설정 처리

여러 구독은 각각 별도 그룹을 만들고 모든 노드를 기본 그룹에 복사하지 않는 것이 좋습니다. 그룹을 사용하면 “이 노드는 어디에서 왔는가”, “어느 구독을 갱신하면 바뀌는가”, “특정 출처를 삭제할 때 수동 설정까지 잘못 지우지 않는가”를 알 수 있습니다. 수동으로 추가한 노드도 전용 그룹에 넣어 구독 갱신 중 같은 이름의 항목으로 덮어쓰이지 않게 하세요. 클라이언트가 별칭, 주소 또는 전체 매개변수 기준의 중복 제거를 제공한다면 먼저 그 규칙을 이해해야 합니다. 이름이 같은 두 노드의 매개변수가 다를 수 있고, 이름이 다른 두 노드가 같은 설정을 가리킬 수도 있습니다.

만료된 노드를 즉시 하나씩 삭제할 필요는 없습니다. 먼저 구독을 한 번 갱신해 원격 목록에서 제거되었는지 확인한 다음 로그를 통해 계속 만료된 것인지 현재 네트워크에서 일시적으로 접근할 수 없는 것인지 판단하세요. 비교용으로 보관해야 하는 노드는 수동 그룹에 복사하고 날짜나 용도를 표시할 수 있습니다. 만료된 설정이 장기간 쌓이면 잘못 선택할 가능성이 커지고 일괄 테스트에도 시간이 걸리므로, 유지 관리할 때 유효한 구독에 더 이상 속하지 않는 고립 노드를 정기적으로 정리하세요.

프록시 모드: 시스템 프록시, 애플리케이션 프록시와 연결 확인

시스템 프록시는 이를 사용하는 애플리케이션에만 영향을 줍니다

v2rayN에서 시스템 프록시를 켜면 운영체제의 HTTP 또는 SOCKS 프록시가 클라이언트의 수신 포트를 가리키게 됩니다. 브라우저와 시스템 네트워크 설정을 따르는 대부분의 애플리케이션은 요청을 클라이언트로 보내지만, 일부 프로그램은 자체 네트워크 스택을 사용해 시스템 프록시를 무시할 수 있습니다. 그 결과 브라우저는 정상인데 명령줄 도구나 특정 애플리케이션은 여전히 직접 연결하는 상황이 생깁니다. 이는 라우팅 규칙이 작동하지 않는 문제가 아니라 트래픽이 애초에 클라이언트로 들어오지 않은 것입니다.

애플리케이션이 프록시로 들어오는지 판단하는 가장 직접적인 방법은 클라이언트 접근 로그를 확인하는 것입니다. 대상 애플리케이션을 사용할 때 로그에 관련 연결이 전혀 나타나지 않는다면 애플리케이션의 프록시 설정을 확인하거나 더 많은 트래픽을 처리해야 할 때 TUN 모드를 검토하세요. 로그에 연결이 나타나지만 출구가 예상과 다르다면 라우팅 규칙을 확인합니다. 웹 페이지가 열리는지만으로 시스템 프록시 상태를 판단하지 마세요. 캐시, 기존 연결과 애플리케이션 자체 프록시가 결론을 흐릴 수 있습니다.

PAC, 자동 설정과 전역 프록시의 차이

클라이언트 인터페이스의 “자동 설정”, “PAC” 또는 “전역”은 시스템 계층에서 요청을 로컬 프록시로 보내는 방식을 뜻하며 코어의 라우팅 모드와 혼동해서는 안 됩니다. PAC는 규칙 스크립트로 어떤 도메인에 시스템 프록시를 사용할지 결정하고, 전역 시스템 프록시는 시스템 프록시를 지원하는 모든 요청을 클라이언트로 보냅니다. 요청이 클라이언트에 들어온 뒤에도 코어 라우팅에 따라 직접 연결로 판단될 수 있습니다. 따라서 “시스템 프록시 전역”과 “라우팅 전역 프록시”는 서로 다른 스위치입니다.

처음 테스트할 때는 시스템 프록시를 켜고 코어 라우팅은 기본 규칙으로 두며, 매개변수가 완전한 것으로 확인된 노드 하나를 선택하는 조합이 좋습니다. 특정 애플리케이션이 시스템 프록시를 지원하는지 확인하려면 잠시 전역 시스템 프록시를 사용한 뒤 로그를 확인하세요. 확인이 끝나면 일상적인 모드로 되돌립니다. PAC, 라우팅 규칙과 노드를 동시에 자주 바꾸면 결과를 바꾼 항목이 무엇인지 확인할 수 없습니다.

기존 연결, 캐시와 확인 방법

노드나 라우팅 모드를 바꿔도 이미 수립된 장기 연결이 항상 즉시 이전되는 것은 아닙니다. 브라우저가 기존 연결을 계속 재사용할 수 있고 DNS도 이전 조회 결과를 보관할 수 있습니다. 테스트할 때는 대상 페이지의 기존 연결을 닫고 필요하면 애플리케이션을 다시 시작한 뒤 새 요청을 보내세요. 페이지 새로 고침만으로는 연결이 재사용될 수 있으므로 두 노드를 비교할 때는 같은 대상, 같은 애플리케이션 상태와 비슷한 시간대를 사용해야 합니다.

Windows에서 로컬 DNS 캐시를 지워야 한다면 시스템 명령을 사용할 수 있지만, 노드를 바꿀 때마다 필요한 절차는 아닙니다. 도메인 조회 결과가 뚜렷하게 오래되었거나 DNS 설정을 변경했는데도 이전 주소를 사용하는 경우에만 다음 명령을 실행하세요:

ipconfig /flushdns

macOS와 Linux의 DNS 캐시는 시스템 서비스가 관리하며 구체적인 명령은 시스템 버전과 배포판에 따라 달라집니다. 무작정 명령을 실행하기보다 먼저 문제가 실제로 조회 계층에서 발생했는지 확인하는 편이 안전합니다. 같은 도메인이 클라이언트 로그에서 조회되었는지, 예상한 규칙에 매칭되었는지, 알려진 주소를 직접 사용했을 때 현상이 달라지는지 살펴보세요. 도메인과 주소 접속 결과가 다르다면 해당 시스템이 사용하는 조회 서비스에 맞춰 캐시를 처리합니다.

클라이언트를 종료하기 전에 시스템 프록시를 복원해야 하며, 특히 프로그램이 비정상 종료되거나 강제 종료된 뒤에는 더욱 중요합니다. 클라이언트가 실행되지 않는데 시스템 프록시가 로컬 포트를 계속 가리키면 애플리케이션 대부분이 인터넷에 연결되지 않습니다. 이때는 먼저 시스템 네트워크 설정에서 프록시를 끈 뒤 클라이언트를 다시 시작해 종료 동작을 확인하세요. 기본 프록시 흐름이 안정된 다음 라우팅과 TUN을 설정하면 변수 수를 크게 줄일 수 있습니다.

라우팅 분할: 규칙 순서, 매칭 조건과 확인 방법

라우팅 규칙은 위에서 아래로 매칭됩니다

라우팅 분할의 목적은 서로 다른 요청을 서로 다른 출구로 보내는 것입니다. 대표적인 출구는 프록시, 직접 연결과 차단입니다. 규칙은 보통 순서대로 매칭되며 앞의 규칙이 일치하면 뒤의 규칙은 더 이상 참여하지 않습니다. 따라서 규칙 내용이 올바르더라도 위치가 잘못되면 예상과 다른 결과가 나옵니다. 예를 들어 적용 범위가 매우 넓은 도메인 규칙을 먼저 두면 뒤에 있는 특정 도메인 예외 규칙은 영원히 실행되지 않을 수 있습니다.

규칙을 설계할 때는 명확하고 범위가 좁은 예외를 앞에 두고, 범위가 넓은 기본 규칙을 뒤에 두세요. 도메인, IP, 포트, 네트워크 유형과 프로세스명은 서로 다른 매칭 기준이므로 논리 관계를 이해하지 못한 채 조건을 한꺼번에 너무 많이 추가하지 않는 것이 좋습니다. 어떤 설정에서는 한 규칙의 여러 필드를 모두 만족해야 하고, 다른 클라이언트 인터페이스에서는 조건을 독립 규칙으로 펼쳐 보이기도 합니다. 외부 규칙을 가져온 뒤에는 인터페이스의 규칙 이름만 보지 말고 클라이언트가 최종 생성한 설정을 확인하세요.

도메인 규칙과 IP 규칙의 범위

도메인 규칙은 클라이언트가 원래 도메인을 볼 수 있어야 합니다. 애플리케이션이 IP로 직접 연결하거나 클라이언트에 들어오기 전에 도메인이 이미 조회되었다면 규칙은 IP 기준으로만 판단할 수 있습니다. 반대로 IP 규칙은 조회 결과와 주소 변경의 영향을 받으며, 같은 도메인도 시간에 따라 다른 주소를 반환할 수 있습니다. 비교적 안정적인 전략은 명확한 서비스에는 도메인 규칙을, 로컬 네트워크와 예약 주소에는 IP 규칙을 사용하고, 마지막에는 기본 출구로 매칭되지 않은 트래픽을 처리하는 것입니다.

일반적인 도메인 매칭에는 전체 도메인, 하위 도메인 접미사와 규칙 집합이 있습니다. 전체 도메인은 지정한 호스트만 매칭하고, 접미사 규칙은 모든 하위 도메인에 적용되어 범위가 더 넓습니다. 규칙 집합은 특정 유형의 도메인을 관리하기 편리하지만 갱신 출처와 포함 범위를 이해해야 합니다. 이름만 보고 규칙 집합의 내용을 추측하지 마세요. 규칙을 수정한 뒤 로그에서 실제 매칭 항목을 확인해야 요청이 도메인, IP 또는 기본 규칙 중 무엇을 통해 나갔는지 알 수 있습니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.com",
          "full:service.example.net"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

이 예시는 먼저 로컬 네트워크와 예약 주소를 직접 연결하고, 지정한 도메인은 프록시로 보내며, 마지막으로 아직 매칭되지 않은 TCP와 UDP 트래픽을 프록시 출구로 보냅니다. 실제 클라이언트가 생성하는 설정에서는 출구 태그 이름이 다를 수 있으므로 예시의 태그를 기존 설정에 그대로 복사해 덮어쓰면 안 됩니다. 먼저 클라이언트의 현재 아웃바운드 항목에서 tag를 확인한 뒤 라우팅 규칙이 이미 존재하는 값을 참조하도록 하세요. 태그 철자가 일치하지 않으면 코어가 설정 로드를 거부하거나 요청을 기본 출구로 보낼 수 있습니다.

기본 규칙에서 예외를 단계적으로 추가하기

안정적인 분할 라우팅 설정은 단순한 구조에서 시작해야 합니다. 먼저 클라이언트 기본 “로컬 네트워크와 중국 본토 우회” 또는 유사한 사전 설정으로 기본 동작을 확인한 다음, 명확한 규칙을 조금씩 추가하세요. 규칙 그룹을 하나 추가할 때마다 해당 대상 주소로 테스트하고 매칭 결과를 기록합니다. 규칙을 한꺼번에 많이 가져온 뒤 문제를 해결하려 하면 충돌 원인이 순서인지, 데이터 집합인지, 도메인 조회인지, 출구 태그인지 판단하기 어렵습니다.

프로세스 분할은 시스템 프록시를 따르지 않지만 클라이언트가 프로세스 정보를 식별할 수 있는 데스크톱 애플리케이션에 적합합니다. 프로세스 규칙은 애플리케이션 출처에 따라 출구를 결정하고, 도메인 규칙은 접속 대상에 따라 출구를 결정하므로 해결하는 문제가 다릅니다. 하나의 애플리케이션이 여러 대상에 서로 다른 정책을 적용해야 한다면 도메인이나 IP 규칙을 우선 사용하세요. 특정 애플리케이션의 모든 트래픽을 고정 출구로 보내려면 프로세스 규칙이 더 직접적입니다. TUN을 사용할 때는 프로세스 식별 기능이 플랫폼 권한과 클라이언트 구현의 영향을 받을 수 있습니다.

규칙을 확인할 때는 로그에서 대상, 인바운드, 매칭 규칙과 아웃바운드를 확인해야 합니다. 최종 페이지 결과만 보면 트래픽 경로를 알 수 없습니다. 수정 후에는 새 연결을 만들고 직접 연결되어야 하는 대상, 프록시를 사용해야 하는 대상과 로컬 네트워크 대상을 각각 테스트하세요. 세 종류의 결과가 모두 예상과 일치해야 전체 규칙이 범위가 넓은 항목에 덮이지 않았다고 판단할 수 있습니다. 설정 파일 각 부분의 구조는 inbounds, outbounds와 routing 단계별 해설에서 이어서 확인할 수 있습니다.

TUN 모드: 처리 범위, DNS와 호환성

TUN은 시스템 프록시가 처리하지 못하는 트래픽을 해결합니다

TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 시스템 트래픽을 수신합니다. 시스템 프록시를 읽지 않는 애플리케이션, UDP를 처리해야 하는 프로그램 또는 라우팅 규칙을 일관되게 적용하려는 환경에 적합합니다. “더 빠른 모드”가 아니며 만료된 노드를 자동으로 고쳐 주지도 않습니다. TUN은 네트워크 스택, DNS와 라우팅 테이블이라는 세 가지 변수를 추가하므로 일반 시스템 프록시가 정상 작동하는 것을 확인한 뒤 켜야 합니다. 기본 노드 연결 자체가 실패한다면 TUN을 켜도 현상만 더 복잡해집니다.

TUN을 켤 때 클라이언트는 가상 인터페이스를 만들고 시스템 라우팅을 수정하기 위해 권한 상승을 요구할 수 있습니다. 권한이 부족하면 가상 인터페이스 생성 실패, 라우팅 기록 실패 또는 시작 후 트래픽이 없는 현상으로 나타납니다. 스위치 상태만 보고 판단하지 말고 클라이언트 로그에서 정확한 단계를 확인하세요. Windows, macOS와 Linux는 가상 인터페이스와 시스템 권한을 처리하는 방식이 다르며, 시스템이나 보안 정책을 업그레이드한 뒤 다시 권한을 부여해야 할 수도 있습니다.

엄격한 라우팅과 로컬 네트워크 우회

TUN의 처리 범위가 넓어지면 로컬 네트워크 트래픽을 어떻게 처리할지 명확히 해야 합니다. 프린터, 네트워크 저장소, 라우터 관리 주소와 로컬 개발 서비스는 보통 직접 연결해야 합니다. 라우팅 설정에서는 로컬 네트워크와 예약 주소를 먼저 허용해 원격 프록시로 들어가지 않도록 하세요. TUN을 켠 뒤 로컬 기기에 접근할 수 없다면 먼저 사설 주소 규칙이 존재하고 범위가 넓은 프록시 규칙보다 앞에 있는지 확인한 다음, 가상 인터페이스가 로컬 네트워크 대역으로 가는 경로를 바꾸었는지 점검합니다.

엄격한 라우팅은 트래픽이 TUN을 우회할 가능성을 줄이지만 가상화 소프트웨어, 기업용 네트워크 클라이언트, 컨테이너 네트워크나 다른 네트워크 필터링 프로그램과 충돌할 수 있습니다. 충돌이 발생해도 모든 보안 옵션을 즉시 끄지 말고 어느 라우팅이나 가상 어댑터가 겹치는지 먼저 확인하세요. TUN을 켜기 전후의 라우팅 테이블 차이를 기록하고 우회 대역이나 인터페이스 우선순위를 하나씩 조정합니다. 여러 가상 네트워크 도구를 동시에 실행하면 마지막에 시작한 프로그램이 기본 라우팅을 다시 쓸 수 있어 시작 순서에 따라 결과가 달라집니다.

TUN에서의 DNS 경로

TUN 모드에서는 DNS 요청도 클라이언트가 처리할 수 있습니다. 도메인 조회 결과는 연결 대상뿐 아니라 IP 라우팅 매칭에도 영향을 줍니다. 설정에서 FakeDNS를 사용하면 클라이언트가 먼저 애플리케이션에 예약 주소를 반환하고, 내부에서 원래 도메인을 복원한 뒤 실제 출구를 선택합니다. 이 방식은 도메인 정보를 유지하는 데 유리하지만 실제 IP에 의존하는 일부 애플리케이션은 제대로 동작하지 않을 수 있습니다. 도메인은 조회되지만 애플리케이션 연결에 문제가 생긴다면 바로 노드를 바꾸지 말고 FakeDNS 동작과 관련이 있는지 확인하세요.

FakeDNS를 사용하지 않는다면 DNS 서버 요청을 직접 연결로 보낼지 프록시로 보낼지 명확히 하고 순환을 방지해야 합니다. DNS 요청이 프록시로 전달되는데 프록시 연결을 시작하려면 다시 같은 DNS 결과가 필요한 상황이 생길 수 있습니다. 클라이언트 기본 설정은 일반적인 순환을 피하지만, 직접 설정할 때는 노드 서버 주소를 조회할 수 있는 부트스트랩 DNS를 남겨 두어야 합니다. 노드 주소 자체가 도메인인 경우 특히 중요합니다.

안전한 활성화와 복구 절차

켜기 전에 현재 설정을 저장하고 라우팅을 수정하는 다른 네트워크 도구를 종료하며, 일반 시스템 프록시에서 사용할 수 있는 노드를 기록하세요. 그 다음 TUN을 활성화하고 가상 인터페이스가 정상적으로 생성되었는지 확인한 뒤 로컬 네트워크, 도메인 조회, TCP와 UDP 애플리케이션을 테스트합니다. 실패하면 먼저 TUN을 끄고 기본 네트워크가 복구되는지 확인하세요. 꺼도 이상이 계속되면 클라이언트를 종료하고 남은 가상 인터페이스, 시스템 프록시와 기본 라우팅을 점검합니다. 네트워크가 복구되지 않은 상태에서 클라이언트를 계속 재설치하지 마세요. 남은 라우팅은 보통 재설치로 해결되지 않습니다.

일상적인 유지 관리: 갱신, 백업, 로그와 속도 문제 점검

클라이언트 갱신과 구독 갱신을 분리하세요

클라이언트 갱신은 프로그램 인터페이스, 설정 변환 로직과 코어 관리 방식을 바꾸고, 구독 갱신은 노드 목록만 바꿉니다. 두 작업은 따로 진행하고 각각 복구 경로를 남겨야 합니다. 클라이언트를 갱신하기 전에 프로그램을 종료하고 설정 디렉터리를 백업하며 현재 사용할 수 있는 모드를 기록하세요. 갱신이 끝나면 먼저 기존 노드와 기존 라우팅으로 테스트하고 구독은 동시에 새로 고치지 마세요. 문제가 생겼을 때 변화가 프로그램 갱신 때문인지 원격 설정 변화 때문인지 판단할 수 있습니다.

구독을 갱신할 때는 그룹 구조를 유지하고 새로 추가된 항목, 제거된 항목과 이름 변경을 확인해야 합니다. 자주 쓰는 노드가 사라졌다면 먼저 구독 출처가 목록을 변경했는지 확인하세요. 오래된 캐시에서 반복해서 복사해 주 그룹에 되돌리지 않는 것이 좋습니다. 단기 비교를 위해 이전 설정을 보존해야 한다면 수동 그룹에 복사하고 용도를 표시하세요. 비교가 끝나면 바로 정리해 만료된 매개변수를 잘못 선택하지 않도록 합니다.

백업 내용과 복원 연습

유효한 백업에는 최소한 구독 설정, 수동 노드, 라우팅 규칙, 클라이언트 환경 설정과 필요한 로컬 설정이 포함되어야 합니다. 로그는 보통 전부 장기간 보관할 필요가 없지만, 안정적으로 재현되는 문제가 있다면 시작 단계와 오류 시점이 포함된 일부를 보존하세요. 백업 파일은 프로그램 디렉터리와 다른 위치에 저장하고, 데이터가 기록되는 중 불일치가 생기지 않도록 클라이언트를 종료한 뒤 백업해야 합니다.

백업만 만들어 두고 복원을 테스트하지 않으면 완전성을 확인할 수 없습니다. 갱신 전에 설정 디렉터리 위치를 기록하고 백업에 최근 수정한 그룹과 라우팅 파일이 있는지 확인하세요. 복원할 때는 먼저 실행 가능한 클라이언트를 설치하고 프로그램이 종료된 상태에서 설정을 되돌린 다음 기본 라우팅부터 검증합니다. 새 설정 디렉터리와 이전 설정 디렉터리를 여러 번 섞어 덮어쓰면 클라이언트가 최종적으로 어느 파일을 읽었는지 판단하기 어려워집니다.

로그는 첫 번째 오류부터 읽으세요

코어 로그는 기본 오류 하나 뒤에 여러 연쇄 메시지를 생성하는 경우가 많습니다. 예를 들어 설정 필드가 유효하지 않으면 코어가 종료되고, 이후 클라이언트가 로컬 포트 연결 실패를 계속 보고할 수 있습니다. 실제로 처리해야 할 것은 마지막 “연결 거부”가 아니라 가장 먼저 나타난 설정 오류입니다. 읽을 때는 코어 시작 위치부터 설정 로드, 수신 포트, DNS 초기화, 아웃바운드 연결과 프로토콜 핸드셰이크 순서로 확인하세요.

로그를 공유하기 전에 구독 주소, 사용자 식별자와 서버 주소 등의 설정 내용을 삭제하고 오류 유형, 시간 순서와 필요한 문맥만 남기세요. 문제 해결에 전체 설정을 공개할 필요는 없습니다. 반복되는 오류라면 “구독을 갱신한 뒤 발생”, “TUN을 켠 뒤 발생” 또는 “특정 노드에서만 발생”처럼 동작 조건을 기록하세요. 마지막 한 줄만 잘라낸 것보다 발생 조건이 판단에 훨씬 유용합니다.

속도 저하는 로컬, 노드와 회선을 나누어 점검하세요

속도 문제는 반복 측정부터 해서 해결하려고 하지 마세요. 첫 번째 계층에서는 로컬 설정을 확인합니다. 전역 프록시를 잘못 사용하고 있는지, 대용량 작업이 부적절한 출구로 들어가고 있지 않은지, TUN이 다른 가상 네트워크 카드와 충돌하지 않는지, 기기에서 백그라운드 다운로드가 실행 중인지 확인하세요. 두 번째 계층에서는 노드를 비교합니다. 같은 시간, 같은 대상과 같은 프록시 모드에서 두 노드를 테스트하세요. 세 번째 계층에서는 회선을 관찰합니다. 시간대와 네트워크 접속 방식을 바꿔 비교해 변동이 혼잡과 관련 있는지 판단합니다.

지연 시간이 낮다고 다운로드 속도가 높은 것은 아닙니다. 지연 시간은 한 번의 연결이나 요청에 걸리는 대기 시간을 나타내고, 처리량은 대역폭, 혼잡 제어, 패킷 손실과 서버 부하의 영향을 함께 받습니다. 영상 끊김은 DNS, 분할 전송과 지속 연결 안정성 때문일 수도 있습니다. 전체적인 계층별 방법은 V2Ray 속도 저하 단계별 점검을 참고하세요. 테스트할 때는 한 번에 하나의 조건만 바꾸고 노드, 모드, 대상과 시간을 기록해야 결과를 비교할 수 있습니다.

고급 학습 경로: 클라이언트 사용에서 설정 해석까지

먼저 인바운드, 아웃바운드와 라우팅의 관계를 이해하세요

고급 학습을 위해 처음부터 모든 JSON 필드를 외울 필요는 없습니다. 먼저 세 부분으로 나뉜 모델을 세우세요. 인바운드는 애플리케이션 트래픽을 받고, 아웃바운드는 트래픽이 나가는 방식을 결정하며, 라우팅은 그 사이에서 선택합니다. 시스템 프록시는 보통 로컬 HTTP 또는 SOCKS 인바운드에 연결되고, TUN은 가상 네트워크 카드 인바운드에 해당합니다. 프록시 노드, 직접 연결과 차단은 서로 다른 아웃바운드입니다. 라우팅 규칙은 도메인, IP, 포트, 네트워크 또는 프로세스 정보를 바탕으로 요청을 특정 아웃바운드에 보냅니다.

이 모델을 이해하면 인터페이스 옵션을 설정 구조에 대응시킬 수 있습니다. 로컬 수신 포트를 수정하는 것은 인바운드를 조정하는 일이고, 노드를 바꾸는 것은 프록시 아웃바운드 매개변수를 교체하는 일입니다. 로컬 네트워크 우회를 선택하는 것은 라우팅 규칙을 조정하는 것이며, TUN 활성화는 다른 유형의 인바운드를 추가하거나 켜는 작업입니다. 오류가 발생하면 모든 문제를 “노드 사용 불가”로 돌리지 말고 로그를 통해 어느 부분이 수립되지 않았는지 판단할 수 있습니다.

{
  "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로 지정하면 로컬 연결만 허용합니다. 다른 주소로 바꾸면 접근 범위가 넓어질 수 있으므로 로컬 방화벽과 네트워크 경계도 함께 고려해야 합니다. 클라이언트가 생성한 파일을 직접 수정하기 전에 다음 시작이나 노드 전환 때 파일이 덮어써지는지 확인하세요.

최소 재현을 익히세요

복잡한 장애를 처리하는 가장 효과적인 방법은 설정을 줄이는 것입니다. 노드 하나, 로컬 인바운드 하나, 가장 단순한 기본 라우팅과 명확한 DNS 설정만 남겨 문제가 계속되는지 확인하세요. 최소 설정이 정상이라면 구독 그룹, 사용자 지정 규칙, TUN, 프로세스 분할과 자동 갱신을 하나씩 복원합니다. 어느 단계에서 문제가 다시 나타나는지 확인한 뒤 해당 계층을 집중적으로 점검하세요. 최소 재현은 원래 설정을 삭제하는 것이 아니므로 먼저 백업하고 복사본에서 작업해야 합니다.

프로토콜 문제도 필드 그룹별로 확인해야 합니다. 먼저 주소, 포트와 사용자 식별자를 확인하고, 다음으로 전송 방식을 확인한 뒤 TLS, REALITY, 호스트명과 경로 같은 조합 매개변수를 점검하세요. 확실하지 않은 상태에서 임의의 값을 시도하지 마세요. 이 필드들은 서버 설정에 의해 결정됩니다. 로그에 핸드셰이크, 인증서 이름 또는 전송 경로 오류가 표시되면 라우팅 규칙을 조정하지 말고 해당 매개변수 그룹으로 돌아가세요.

자신만의 변경 기록 만들기

기본 사전 설정에서 사용자 지정 규칙으로 설정을 발전시킬 때는 간단한 변경 기록을 남겨야 합니다. 날짜, 변경 목적, 관련 규칙, 테스트 대상과 되돌리는 방법만 기록해도 충분합니다. 예를 들어 “로컬 개발 도메인에 직접 연결 규칙을 추가하고 로컬 서비스와 일반 웹사이트를 확인”, “특정 애플리케이션에 프로세스 규칙을 추가하고 실패하면 해당 규칙 삭제”처럼 작성할 수 있습니다. 이런 기록은 특정 예외가 존재하는 이유를 설명하고, 몇 달 뒤 필요한 규칙을 불필요한 항목으로 착각해 삭제하는 일을 막아 줍니다.

설정 파일을 직접 조정할 때는 먼저 형식 검사 도구로 JSON 문법을 확인한 뒤 태그 참조를 점검하세요. JSON에는 주석을 넣을 수 없고 배열의 마지막 항목 뒤에 불필요한 쉼표를 둘 수도 없습니다. 문법이 올바르다고 의미까지 유효한 것은 아닙니다. 라우팅이 존재하지 않는 아웃바운드 태그를 참조하거나, 포트가 사용 중이거나, 프로토콜 필드가 잘못된 계층에 있으면 코어가 시작되지 않습니다. 클라이언트 로그에 표시된 설정 경로와 오류 위치를 주요 근거로 삼으세요.

전체 문제 해결 트리

1. 클라이언트를 시작할 수 없음: 시스템 아키텍처, 디렉터리 권한, 종속 요소와 이전 프로세스 점유를 확인합니다.
2. 구독을 갱신할 수 없음: 주소의 완전성, 구독 응답, 파싱 형식과 대상 그룹을 확인합니다.
3. 코어가 실행되지 않음: 첫 번째 설정 오류부터 시작해 포트, 필드와 코어 지원 여부를 확인합니다.
4. 애플리케이션 로그가 없음: 시스템 프록시와 애플리케이션의 프록시 지원 여부를 확인하고, 필요할 때 TUN을 검토합니다.
5. 로그는 있지만 출구가 잘못됨: 규칙 순서, 도메인·IP 조건과 아웃바운드 태그를 확인합니다.
6. 도메인만 실패함: DNS 처리, 캐시, 부트스트랩 조회와 FakeDNS 호환성을 확인합니다.
7. 연결은 되지만 속도가 느림: 로컬 설정, 노드 부하와 회선 변동으로 나누어 비교합니다.

이 고급 학습 경로를 마치면 네 가지 질문에 스스로 답할 수 있어야 합니다. 트래픽은 어느 진입점으로 들어오는가, 어떤 규칙에 매칭되었는가, 어느 출구로 나가는가, 실패는 어느 단계에서 발생했는가입니다. 클라이언트 인터페이스는 여전히 일상적인 조작의 중심이고, 설정 파일과 로그는 동작을 설명하는 도구이므로 고급 활용을 위해 그래픽 클라이언트를 포기할 필요는 없습니다. 최초 설치 항목을 다시 확인하려면 v2rayN 최초 설치 설정 체크리스트를 참고하세요. 가장 짧은 실행 경로를 다시 따라가려면 빠른 시작 문서로 돌아가면 됩니다.