V2Ray 처음부터 완벽하게 익히기 완벽 가이드

CHAPTER 01

핵심 개념: 코어, 클라이언트와 설정을 먼저 구분하기

V2Ray, V2Fly와 Xray는 각각 어느 계층에 속할까

설정을 시작하기 전에 메뉴 위치를 외우는 것보다 자주 함께 등장하는 이름을 올바른 계층에 배치하는 일이 중요합니다. V2Ray는 일반적으로 Project V에서 발전한 프록시 기술 생태계와 설정 체계를 가리키며, V2Fly는 그중 하나의 코어 계열을 이어받아 유지 관리합니다. Xray는 같은 기술 계열에 속하는 또 다른 코어 구현입니다. 코어는 설정을 해석하고 인바운드와 아웃바운드를 만들며 프로토콜 핸드셰이크, DNS 정책 실행과 라우팅 규칙에 따른 트래픽 전달을 담당합니다. 보통 백그라운드에서 실행되며 구독 목록, 트레이 메뉴와 시스템 프록시 전환 같은 그래픽 작업을 직접 처리하지는 않습니다.

v2rayN, v2rayNG와 v2flyNG는 클라이언트 계층에 속합니다. 클라이언트는 구독 관리, 서버 선택, 로그 확인과 프록시 모드를 조작 가능한 화면으로 제공하고 해당 코어를 호출해 연결을 처리합니다. 데스크톱에서는 Windows, macOS와 Linux를 지원하는 v2rayN을 우선 선택합니다. Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 사용하고, v2fly 코어 계열이 필요한 경우 v2flyNG를 선택합니다. 이 관계를 이해하면 문제가 화면 설정, 구독 내용, 코어 실행 또는 네트워크 환경 중 어디에 속하는지 판단할 수 있어 클라이언트 전체를 반복해서 재설치할 필요가 없습니다.

하나의 연결은 어떤 요소로 구성될까

연결을 만들 수 있는 설정에는 최소한 인바운드, 아웃바운드와 라우팅이라는 세 가지 논리적 부분이 포함됩니다. 인바운드는 로컬 SOCKS 포트, HTTP 프록시 포트 또는 TUN 가상 네트워크 인터페이스에서 받은 데이터처럼 로컬 프로그램이 트래픽을 코어에 전달하는 방식을 설명합니다. 아웃바운드는 코어가 트래픽을 처리하는 방식을 정의하며 프록시 연결, 직접 연결과 차단이 대표적입니다. 라우팅은 그 사이에서 도메인, IP, 포트, 네트워크 유형 또는 인바운드 태그에 따라 어떤 아웃바운드를 사용할지 결정합니다. 그래픽 클라이언트가 설정 일부를 생성하므로 평소에는 전체 파일을 직접 작성할 필요가 없지만, 구조를 이해하면 로그를 읽고 규칙을 점검하는 데 도움이 됩니다.

서버 항목은 원격 연결에 필요한 주소, 포트, 인증 정보, 프로토콜과 전송 매개변수를 제공합니다. 프로토콜은 양측이 데이터를 교환하는 방식을 정하고 전송 계층은 TCP, WebSocket, gRPC 등의 어떤 채널로 데이터를 운반할지 결정합니다. TLS 또는 REALITY 같은 보안 매개변수는 핸드셰이크 방식에 추가 제약을 둡니다. 핵심 필드 하나라도 일치하지 않으면 연결이 실패합니다. 클라이언트가 링크를 가져올 수 있다고 해서 설정이 유효하다는 뜻은 아닙니다. 가져오기는 문법을 인식했다는 의미일 뿐이며 실제 사용 가능 여부는 DNS 해석, 네트워크 연결, 시스템 시간과 원격 상태를 여러 단계로 확인해야 합니다.

구독은 프로토콜이 아니며 노드는 클라이언트가 아닙니다

구독 주소는 설정을 배포하는 진입점입니다. 클라이언트가 주소를 요청하면 서버가 서버 항목 묶음이나 구조화된 설정을 반환하고, 클라이언트가 이를 목록으로 변환합니다. 구독 자체가 트래픽을 전달하는 것은 아니며 특정 프로토콜을 의미하지도 않습니다. 흔한 오해는 “구독 업데이트 성공”을 “프록시 활성화 완료”로 이해하는 것입니다. 전자는 클라이언트가 목록을 가져와 해석했다는 뜻일 뿐이고, 후자는 서버를 선택하고 코어를 시작한 뒤 애플리케이션 트래픽이 로컬 프록시 또는 TUN 인바운드로 들어와야 합니다.

“노드”는 화면에서 서버 설정 항목을 부르는 관용적인 표현입니다. 하나의 항목에는 VMess, VLESS, Trojan 등의 프로토콜 매개변수가 포함될 수도 있고 같은 원격 진입점에 대한 서로 다른 전송 조합이 포함될 수도 있습니다. 현재 환경에 적합한지 판단할 때는 먼저 클라이언트 코어가 해당 프로토콜과 전송을 지원하는지 확인하고, 다음으로 주소 해석과 포트 연결 가능 여부를 점검한 뒤 라우팅 모드를 확인해야 합니다. 표시 이름만으로 용도를 판단하지 마세요. 표시 이름은 대개 구독 제공자가 정한 메모일 뿐 실제 핸드셰이크에는 사용되지 않습니다.

애플리케이션 요청부터 원격 아웃바운드까지의 전체 경로

브라우저로 웹사이트에 접속하는 경우를 예로 들면, 브라우저가 먼저 도메인을 해석한 다음 운영체제 프록시 설정에 따라 요청을 v2rayN의 로컬 리스닝 포트로 전달합니다. 코어는 대상 도메인과 대상 IP를 확인한 뒤 라우팅 규칙을 위에서부터 매칭합니다. direct에 해당하면 로컬 네트워크로 직접 접속하고, proxy에 해당하면 현재 서버 아웃바운드를 사용하며, block에 해당하면 전달을 중지합니다. 애플리케이션이 시스템 프록시를 읽지 않으면 요청은 이 경로로 들어오지 않으므로 애플리케이션에서 별도로 프록시를 설정하거나 TUN으로 네트워크 트래픽을 넘겨받아야 합니다.

이 과정은 “클라이언트 실행 중”으로 표시되는데도 실제 프록시 효과가 없을 수 있는 이유를 설명합니다. 실행 중이라는 표시는 코어 프로세스가 존재한다는 뜻일 뿐입니다. 시스템 프록시가 켜지지 않았거나 애플리케이션이 시스템 설정을 우회했거나 규칙이 대상을 직접 연결로 분류했을 수 있습니다. 반대로 특정 웹사이트가 열렸다고 해서 모든 규칙이 올바르다는 뜻도 아닙니다. 해당 사이트가 우연히 직접 연결되었을 수 있기 때문입니다. 설정은 웹페이지 하나의 로딩 여부가 아니라 클라이언트 로그, 시스템 프록시 상태와 대상 요청의 라우팅 결과를 함께 관찰해 검증해야 합니다.

CHAPTER 02

클라이언트 선택과 설치: 플랫폼별로 안정적인 출발점 만들기

세 클라이언트의 역할과 범위

데스크톱 플랫폼에서는 v2rayN을 우선 선택합니다. 구독 그룹, 서버 목록, 시스템 프록시, 라우팅 규칙, TUN과 로그를 하나의 작업 화면에 모아 기본 연결부터 복잡한 분할 설정까지 단계적으로 확장하기 좋습니다. Windows에서는 화면 구현에 따라 데스크톱 버전이나 클래식 WPF 버전을 선택할 수 있습니다. 전자는 크로스 플랫폼 데스크톱 인터페이스를 사용하고 후자는 전통적인 Windows 조작 방식을 유지합니다. 핵심 역할은 같으므로 두 버전을 동시에 실행할 필요는 없습니다. macOS와 Linux에서는 해당 플랫폼의 v2rayN 설치 패키지를 사용하고, 다운로드할 때 프로세서 아키텍처와 배포판의 패키지 형식에 맞춰 선택합니다.

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 선택합니다. 설정 개념은 데스크톱과 비슷하지만 프록시 연결은 시스템 VPN 인터페이스로 처리되며 화면 구성은 더 간결합니다. v2flyNG는 v2fly 코어 계열 설정이 필요한 경우에 적합한 대체 클라이언트입니다. 두 Android 클라이언트를 각각 설치할 수는 있지만 일상적인 연결에서는 시스템 VPN 세션 하나만 활성화해야 두 클라이언트가 연결 권한을 놓고 충돌하지 않습니다. 전체 설치 패키지와 플랫폼 안내는 다운로드 페이지에 정리되어 있습니다.

설치 전에 아키텍처와 권한 확인

프로세서 아키텍처에 따라 설치 패키지가 실행될 수 있는지가 결정됩니다. Windows와 Linux의 일반적인 데스크톱 컴퓨터는 보통 x64를 사용하며 ARM 프로세서 기기에는 arm64가 필요합니다. macOS에서는 시스템 정보의 칩 또는 프로세서 항목으로 확인할 수 있습니다. Apple 칩으로 표시되면 Apple Silicon용 패키지를, Intel로 표시되면 x64 패키지를 선택합니다. Android에서는 기기 정보나 하드웨어 검사 화면에서 ABI를 확인할 수 있습니다. 최근의 일반적인 기기는 대개 arm64를 지원하며 확인하기 어려울 때는 범용 패키지를 사용할 수 있지만 보통 용량이 더 큽니다.

설치 권한은 시스템 프록시, 가상 네트워크 인터페이스와 서비스 등록에 영향을 줍니다. 일반적인 시스템 프록시는 현재 사용자 설정만 수정하므로 보통 별도 권한이 필요하지 않습니다. TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅 테이블을 조정해야 하므로 관리자 승인이 필요할 수 있습니다. 승인은 사용자가 해당 기능을 직접 켤 때 이루어져야 합니다. 클라이언트는 열리지만 TUN을 시작할 수 없다면 서버 프로토콜을 먼저 바꾸기보다 권한과 드라이버 상태를 확인하세요. 기업 기기는 정책에 따라 프록시나 네트워크 확장이 중앙 관리될 수 있으므로 시스템 관리 범위에서 처리해야 합니다.

첫 실행 후 최소 점검

처음 클라이언트를 열었을 때 모든 옵션을 즉시 켜지 마세요. 먼저 기본 화면이 정상적으로 표시되는지, 설정 영역에서 코어 경로를 찾을 수 있는지, 로그 창을 열 수 있는지 확인한 다음 구독을 가져옵니다. v2rayN의 기본 화면에는 보통 구독 그룹, 서버 목록, 시스템 프록시와 라우팅 설정이 포함됩니다. v2rayNG는 설정 목록, 현재 선택 항목과 연결 버튼을 중심으로 구성됩니다. 이 단계에서는 시스템 프록시를 꺼 두어 설치 문제와 설정 문제를 분리하세요.

그다음 시스템 시간, 시간대와 네트워크 기본 상태를 확인합니다. TLS와 REALITY 등의 핸드셰이크는 시간 오차에 민감하므로 시스템 시간이 잘못되면 인증서 또는 핸드셰이크 오류처럼 나타날 수 있습니다. 먼저 프록시를 거치지 않는 네트워크에서 일반 웹사이트와 DNS가 작동하는지 확인한 뒤 클라이언트를 시작하세요. 현재 네트워크에서 웹 로그인 인증이 필요하다면 먼저 인증을 완료하는 편이 안정적입니다. 인증 페이지는 프록시를 시작하기 전에 처리하는 경우가 많기 때문입니다. 네트워크 환경을 전환한 뒤에는 시스템이 새 주소와 DNS를 받을 때까지 기다렸다가 다시 연결하세요.

Windows PowerShell
Get-Date
Get-NetIPConfiguration
Test-NetConnection example.com -Port 443

macOS / Linux
date
curl -I https://example.com

이 명령은 로컬 시간, 네트워크 카드 설정과 기본 HTTPS 연결만 확인하며 프록시 서버의 유효성을 판단하지 않습니다. 기본 연결 자체가 실패하면 먼저 로컬 네트워크를 복구하세요. 기본 연결은 정상인데 클라이언트 코어를 시작할 수 없다면 설정 해석과 포트 점유를 확인합니다. 이렇게 하면 네트워크가 끊긴 상태에서 구독 항목을 반복해서 바꾸는 일을 피할 수 있습니다.

업그레이드, 병행 설치와 설정 디렉터리

클라이언트를 업그레이드하기 전에 실행 중인 코어를 종료하고 현재 구독 그룹, 라우팅 모드와 사용자 규칙을 기록해야 합니다. 클라이언트 설정은 보통 사용자 디렉터리나 애플리케이션 데이터 디렉터리에 저장되며 정확한 위치는 플랫폼과 설치 방식에 따라 다릅니다. 덮어쓰기 설치 전에 클라이언트의 백업 또는 내보내기 기능으로 필요한 설정을 저장하세요. 캐시, 로그와 서버 목록을 유일한 백업으로 간주하면 안 됩니다. 구독 주소는 다시 업데이트할 수 있지만 수동으로 추가한 서버, 라우팅 규칙과 DNS 설정은 구독에서 복원되지 않을 수 있습니다.

한 컴퓨터에 마이그레이션 테스트를 위해 서로 다른 화면 구현을 유지할 수는 있지만, 두 클라이언트가 같은 로컬 포트를 동시에 리슨하게 하거나 시스템 프록시를 동시에 수정하게 해서는 안 됩니다. 포트 충돌은 대개 로그에 “주소가 이미 사용 중” 또는 리스닝 실패로 표시됩니다. 클라이언트를 전환할 때는 먼저 이전 클라이언트가 설정한 시스템 프록시를 해제하고 완전히 종료한 다음 새 클라이언트를 시작하세요. 비정상 종료 후에도 시스템에 프록시 주소가 남아 있다면 운영체제 네트워크 설정에서 프록시를 끈 뒤 클라이언트에서 다시 활성화합니다.

CHAPTER 03

구독 가져오기: 주소에서 설정을 받아 그룹 만들기

구독 주소의 구조와 저장 방법

구독 주소는 보통 HTTPS URL이며 경로나 쿼리 매개변수에 계정을 식별하는 토큰이 포함됩니다. 클라이언트가 주기적으로 서버 목록을 가져오도록 하는 주소이므로 계정 인증 정보처럼 관리해야 하며 공개 페이지, 스크린샷이나 로그에 게시하지 마세요. 주소를 복사할 때는 프로토콜 시작 부분부터 마지막 문자까지 빠짐없이 보존하고 메신저가 쿼리 매개변수를 자동으로 잘라내지 않았는지 확인합니다. 클라이언트에 저장되는 것은 웹페이지 본문이 아니라 주소입니다. 브라우저에서 열었을 때 인코딩된 텍스트나 다운로드 응답이 표시되어도 주소가 잘못된 것은 아닙니다.

https://example.com/sub?token=xxxx

위 주소는 일반적인 구조만 보여 줍니다. 실제 구독은 다른 경로와 매개변수 이름을 사용할 수 있습니다. 가져올 때 불필요해 보이는 등호, 슬래시 또는 퍼센트 인코딩을 임의로 삭제하지 마세요. 이런 문자가 토큰이나 서명에 포함되어 있을 수 있습니다. 복사한 주소 끝에 공백이나 줄바꿈이 붙었다면 먼저 보이지 않는 문자를 제거합니다. 구독 주소가 교체되었을 때는 새 그룹을 계속 만들기보다 기존 그룹을 편집해 이전 서버와 새 서버가 한 목록에 섞이지 않게 하는 것이 좋습니다.

v2rayN에서 가져오고 업데이트하기

데스크톱에서는 먼저 구독 그룹을 만든 다음 그룹 설정에 주소를 입력합니다. “구독 그룹” 관련 메뉴를 열어 그룹 이름과 구독 주소를 추가하고 저장한 뒤 업데이트를 실행하세요. 그룹 이름은 로컬에서 구분하기 위한 것이므로 용도나 설정 출처에 따라 정하면 되며 원격 응답에는 영향을 주지 않습니다. 업데이트가 완료되면 구독 내용에 따라 서버 목록이 만들어집니다. 이전 항목 삭제 옵션이 켜져 있다면 클라이언트가 해당 그룹의 기존 항목을 이번 결과로 교체하므로 수동 서버는 별도 그룹에 두는 것이 좋습니다.

업데이트가 끝나면 먼저 항목 수가 적절한지, 프로토콜이 인식되었는지, 주소와 포트 열이 존재하는지 확인한 뒤 하나를 선택해 활성 서버로 지정합니다. 업데이트 중에 여러 번 연속 클릭하지 마세요. 동시 요청으로 구독 서버의 빈도 제한이 발생할 수 있고 로그도 읽기 어려워집니다. 여러 구독을 함께 사용할 때는 출처별로 독립 그룹을 만들고 필요에 따라 업데이트 간격을 설정하세요. 서버를 더 정리하려면 여러 구독 그룹과 키워드 필터링을 참고해 그룹, 필터와 라우팅 용도를 분리해 관리할 수 있습니다.

v2rayNG와 v2flyNG에서 가져오기

Android 클라이언트에서는 일반적으로 구독 설정에서 주소를 추가한 뒤 기본 화면으로 돌아가 업데이트를 실행합니다. 업데이트하려면 시스템이 클라이언트의 네트워크 접근을 허용해야 합니다. 배터리 절약 제한, 백그라운드 데이터 제한 또는 비공개 DNS 이상으로 요청이 실패할 수 있습니다. 업데이트가 끝나면 설정 항목이 기본 목록에 나타나며 그중 하나를 현재 설정으로 직접 선택해야 합니다. 선택 상태는 다음 연결에 사용할 설정을 지정한 것일 뿐 시스템 VPN 세션이 만들어졌다는 뜻은 아닙니다. 연결을 실행하고 상태 표시줄에 VPN 표시가 나타나는지 확인해야 합니다.

v2rayNG와 v2flyNG의 구독 데이터는 각각 관리해야 합니다. 일부 범용 공유 링크는 두 클라이언트에서 모두 인식되지만 두 코어는 새 프로토콜 필드와 확장 옵션을 지원하는 시점이 다를 수 있습니다. 어떤 설정이 한 클라이언트에서 해석되지 않는다면 먼저 현재 코어가 지원하지 않는 필드를 포함하는지 확인하세요. 곧바로 구독 전체가 무효라고 판단하지 마세요. 구독에서 코어별 진입점을 따로 제공한다면 클라이언트에 맞는 진입점을 사용합니다.

업데이트 성공, 해석 성공과 연결 성공의 차이

구독 업데이트는 서로 독립적으로 판단할 수 있는 세 단계로 이루어집니다. 첫 번째는 HTTP 요청 성공으로, 클라이언트가 구독 주소에 접근해 응답을 받았다는 뜻입니다. 두 번째는 콘텐츠 해석 성공으로, 반환 형식을 서버 항목으로 변환할 수 있다는 뜻입니다. 세 번째가 되어야 항목을 선택하고 프록시 연결을 만들 수 있습니다. 응답 상태는 정상이지만 목록이 비어 있다면 콘텐츠 형식, 계정 상태 또는 필터 조건의 문제일 가능성이 큽니다. 목록은 존재하지만 모두 연결되지 않는다면 서버 매개변수, 시간, DNS와 현재 네트워크를 확인해야 합니다.

로그의 오류 메시지는 단계별로 읽어야 합니다. 도메인 해석 실패는 구독 도메인에서 IP를 얻지 못했다는 뜻입니다. 연결 시간 초과는 기한 내 요청이 완료되지 않았다는 뜻입니다. 인증되지 않음 또는 접근 금지는 주소 토큰, 계정 상태나 요청 정책과 관련된 경우가 많습니다. 해석 실패는 응답 콘텐츠가 클라이언트가 예상한 형식이 아니라는 뜻입니다. “프록시를 통해 구독 업데이트”가 설정되어 있는데 현재 프록시 자체가 작동하지 않으면 업데이트가 의존성 순환에 빠집니다. 문제를 확인할 때는 일시적으로 직접 연결 업데이트로 바꾼 뒤 성공하면 원래 정책을 복원하세요.

그룹, 필터와 중복 제거 전략

그룹의 가치는 보기 좋게 정리하는 데만 있지 않습니다. 업데이트와 삭제 작업의 범위도 그룹으로 제한됩니다. 업무, 일상적인 브라우징과 테스트 설정을 나누어 저장하면 한 출처를 업데이트해도 다른 그룹을 덮어쓰지 않습니다. 서버 이름에 지역이나 용도 키워드가 포함되어 있다면 클라이언트 필터 기능으로 목록을 줄일 수 있지만, 필터는 표시 또는 선택 범위만 바꿀 뿐 원격 설정은 변경하지 않습니다. 필터 규칙을 만들기 전에 이름 규칙을 먼저 살펴 너무 넓은 키워드로 관련 없는 항목까지 선택하지 않도록 하세요.

같은 항목이 반복되는 원인은 동일한 구독을 여러 번 가져왔거나 구독 서버가 중복 반환했거나 마이그레이션 과정에서 이전 그룹을 남겨 둔 경우가 많습니다. 먼저 항목이 어느 그룹에 속하는지 확인한 뒤 이전 출처를 삭제하세요. 표시 이름만으로 일괄 삭제하면 서로 다른 설정이 같은 메모를 사용할 수 있습니다. 구독 업데이트 후에도 이전 항목이 남는다면 해당 그룹의 업데이트 방식이 추가 방식인지 확인합니다. 장기적으로는 자동 업데이트를 구독 항목에 맡기고 수동 설정은 별도 그룹에 두세요. 두 데이터의 수명 주기가 다르므로 섞어 저장하면 잘못 삭제할 가능성이 커집니다.

구독 업데이트 실패 시 가장 짧은 진단 경로

먼저 프록시를 통한 구독 업데이트 옵션을 끄고 현재 기본 네트워크로 한 번 요청합니다. 이어서 주소가 완전한지, 시스템 시간이 올바른지, 구독 도메인을 해석할 수 있는지 확인합니다. 특정 주소 하나만 실패하고 다른 주소는 정상이라면 해당 구독의 권한이나 응답 문제일 가능성이 큽니다. 모든 주소가 실패한다면 DNS, 시스템 프록시 잔여 설정과 보안 소프트웨어의 네트워크 정책을 확인하세요. 업데이트 후 서버가 나타나지 않는다면 클라이언트에서 이름 필터가 켜져 있는지, 반환 콘텐츠가 웹 오류 페이지로 인식되었는지 살펴봅니다.

단일 구독 오류를 해결하려고 자주 삭제하고 재설치하지 마세요. 클라이언트를 재설치해도 원격 응답은 바뀌지 않으며 잘못된 주소도 수정되지 않습니다. 실패 로그를 한 번 보존하고 요청 단계와 상태 정보를 확인한 뒤 주소 수정, 업데이트 네트워크 전환 또는 해석 방식 조정을 결정하세요. 더 많은 사례는 자주 묻는 질문에서 “설치 및 설정”과 “문제 해결” 분류로 찾을 수 있습니다.

CHAPTER 04

프록시 모드: 어떤 애플리케이션의 요청을 클라이언트로 보낼지 결정하기

시스템 프록시와 코어 라우팅은 서로 다른 문제를 해결합니다

시스템 프록시는 운영체제의 프록시 설정을 지원하는 애플리케이션 요청을 클라이언트의 로컬 포트로 보냅니다. 코어 라우팅은 요청이 클라이언트에 들어온 뒤 최종적으로 프록시, 직접 연결 또는 차단 중 어디로 보낼지 결정합니다. 전자는 “들어올지”를 제어하고 후자는 “들어온 뒤 어디로 갈지”를 제어합니다. 두 기능을 같은 스위치로 생각하면 설정이 혼란스러워집니다. 라우팅이 전체 프록시로 설정되어도 시스템 프록시를 읽지 않는 애플리케이션은 자동으로 들어오지 않으며, 시스템 프록시가 켜져 있어도 라우팅이 특정 대상을 직접 연결로 보낼 수 있습니다.

v2rayN의 “시스템 프록시 자동 설정”은 브라우저와 시스템 설정을 따르는 데스크톱 애플리케이션에 적합합니다. 활성화하면 클라이언트가 운영체제의 프록시 주소를 로컬 리스닝 포트로 지정합니다. 시스템 프록시 해제는 이 설정을 취소하고, 시스템 프록시를 변경하지 않음은 코어만 시작한 뒤 다른 애플리케이션이 로컬 포트에 수동으로 연결하는 경우에 사용합니다. PAC 모드는 규칙 파일을 통해 애플리케이션에 서로 다른 프록시 결정을 반환합니다. 일상적으로는 시스템 프록시 자동 설정을 먼저 선택하고 코어 라우팅으로 분할하는 방식이 가장 이해하기 쉽습니다.

전체 프록시, 규칙 모드와 중국 본토 우회 모드 이해하기

클라이언트 화면의 “전체 프록시”는 일반적으로 코어로 들어온 트래픽을 기본적으로 프록시 아웃바운드로 보내는 것을 뜻합니다. 규칙 문제를 짧게 점검할 때 적합하지만 모든 애플리케이션을 강제로 연결하지는 않습니다. 규칙 모드는 라우팅 테이블을 위에서부터 매칭하며 LAN, 사설 주소와 특정 도메인 집합은 직접 연결하고 나머지는 프록시로 보내는 방식이 일반적입니다. 중국 본토 우회 모드는 미리 설정된 규칙 조합으로, 보통 중국 본토 도메인과 IP를 직접 연결로 분류하고 다른 대상은 프록시로 보냅니다. 미리 설정된 규칙은 시작하기 편하지만 실제 애플리케이션에서 오분류가 없는지 확인해야 합니다.

모드를 선택할 때는 사용 목적부터 생각하세요. 일상적인 브라우징에는 규칙 모드나 중국 본토 우회 모드가 적합해 불필요한 프록시 경로를 줄일 수 있습니다. 특정 대상이 잘못 분류되는지 확인할 때는 일시적으로 전체 프록시 모드로 전환해 비교하세요. 개발 도구 하나만 프록시로 연결하려면 “시스템 프록시 변경 안 함”을 유지하고 해당 도구에 로컬 SOCKS 또는 HTTP 주소를 직접 입력할 수 있습니다. 모드별 차이와 대표적인 사용 사례는 시스템 프록시, 전체 프록시와 중국 본토 우회 모드의 차이에서 확인할 수 있습니다.

로컬 SOCKS 및 HTTP 포트

코어는 보통 SOCKS와 HTTP라는 두 종류의 로컬 인바운드를 동시에 제공합니다. SOCKS는 TCP를 전달하며 클라이언트 구현에 따라 UDP도 처리할 수 있습니다. HTTP 프록시는 HTTP CONNECT를 기본 지원하는 애플리케이션에 더 적합합니다. 포트는 클라이언트 설정에 따라 생성되므로 다른 가이드의 고정 숫자를 그대로 사용하지 마세요. 별도 애플리케이션에서 프록시를 설정할 때는 현재 클라이언트 설정 화면에서 로컬 리스닝 주소와 실제 포트를 확인합니다. 호스트는 보통 루프백 주소 127.0.0.1을 사용해 로컬 프록시가 LAN에 노출되지 않도록 합니다.

애플리케이션 설정에서는 “프록시 DNS”와 “로컬 해석”도 구분해야 합니다. 일부 SOCKS 클라이언트는 먼저 로컬에서 도메인을 해석한 뒤 IP를 프록시에 전달하고, 다른 클라이언트는 도메인을 원격 경로에서 해석합니다. 전자는 코어의 도메인 기반 라우팅 규칙을 우회할 수 있고 후자는 도메인 정보를 유지하는 데 유리합니다. 애플리케이션이 socks5h 같은 모드를 제공한다면 호스트 이름 해석은 일반적으로 SOCKS 요청과 함께 프록시에 전달됩니다. 구체적인 선택은 코어 DNS와 라우팅 정책에 맞춰야 합니다.

HTTP_PROXY=http://127.0.0.1:로컬HTTP포트
HTTPS_PROXY=http://127.0.0.1:로컬HTTP포트
ALL_PROXY=socks5h://127.0.0.1:로컬SOCKS포트

위 표기는 환경 변수의 구조를 설명하기 위한 것입니다. 실제로 사용할 때는 문자로 표시된 포트를 클라이언트에 표시되는 숫자로 바꾸세요. 명령줄 도구는 해당 환경 변수를 읽을 때만 프록시를 사용합니다. 터미널을 닫거나 변수를 삭제하면 직접 연결로 돌아갈 수 있습니다. 시스템 프록시, 환경 변수와 애플리케이션 내 프록시가 서로 다른 클라이언트를 가리키는 것처럼 여러 프록시 출처를 동시에 충돌시키지 마세요. 요청 경로를 판단하기 어려워집니다.

시스템 프록시가 실제로 적용되었는지 확인하는 방법

먼저 v2rayN 상태 표시줄에서 시스템 프록시가 자동 설정으로 표시되는지 확인합니다. 그다음 시스템 프록시를 따르는 브라우저로 요청을 보내면서 클라이언트 접근 로그를 관찰합니다. 로그에 새 연결이 나타나면 요청이 코어에 들어온 것입니다. 로그가 없다면 브라우저가 독립 프록시를 사용하는지, 직접 연결 정책이 켜져 있는지 또는 이전 프로세스에서 환경 변수를 물려받았는지 확인하세요. 브라우저를 완전히 종료한 뒤 다시 열면 일부 연결 풀과 프록시 설정 캐시를 배제할 수 있습니다.

로그는 존재하지만 대상 접속이 실패한다면 라우팅 태그와 아웃바운드 오류를 계속 확인합니다. direct에 해당하면 규칙이 직접 연결을 선택한 것입니다. 프록시 아웃바운드에 해당한 뒤 시간 초과가 발생한다면 원격 경로나 네트워크 문제일 가능성이 큽니다. 시스템 프록시를 끈 뒤에도 직접 연결이 되지 않는다면 운영체제에 이전 주소가 남아 있을 수 있습니다. 시스템 네트워크 설정에서 수동 프록시 필드를 확인하고 더 이상 사용하지 않는 루프백 주소와 포트를 삭제한 뒤 클라이언트가 다시 자동 설정하게 하세요.

모바일에서 트래픽을 넘겨받는 방식

v2rayNG와 v2flyNG는 시스템 VPN 인터페이스로 애플리케이션 트래픽을 받으므로 각 브라우저의 시스템 프록시를 따로 수정할 필요가 없습니다. 연결을 누르면 시스템이 VPN 세션 생성을 요청합니다. 허용한 뒤 클라이언트가 라우팅과 앱별 설정에 따라 트래픽 경로를 결정합니다. 연결 아이콘이 나타나는 것은 인터페이스가 만들어졌다는 뜻일 뿐이며 현재 설정이 원격에 성공적으로 연결되었는지는 로그로 확인해야 합니다. 네트워크 전환, 배터리 절약 모드 또는 장시간 백그라운드 실행 후에는 시스템이 프로세스를 종료할 수 있으므로 배터리 최적화와 백그라운드 실행 권한을 확인하세요.

앱별 프록시는 어떤 애플리케이션을 클라이언트에 연결할지 제한할 수 있어 업무 앱과 다른 트래픽을 분리하는 데 적합합니다. 설정할 때 “선택한 앱만 프록시”와 “선택한 앱 우회” 중 무엇을 사용할지 명확히 해야 하며 두 옵션의 의미는 서로 반대입니다. 목록을 수정한 뒤에는 연결을 다시 만들어 시스템이 라우팅을 다시 로드하도록 하세요. 앱 내부에 별도 프록시가 설정되어 있다면 시스템 VPN과 이중 전달이 생기지 않도록 먼저 앱의 기본 네트워크 설정으로 되돌린 뒤 테스트합니다.

CHAPTER 05

라우팅 분할: 도메인, IP와 인바운드에 따라 아웃바운드 선택하기

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

라우팅 규칙의 핵심은 규칙 수가 아니라 매칭 순서입니다. 코어는 일반적으로 목록을 위에서 아래로 확인하며 요청이 한 규칙에 해당하면 해당 아웃바운드를 사용하고 이후의 일반 규칙은 계속 확인하지 않습니다. 따라서 범위가 작고 의도가 명확한 규칙은 앞에, 범위가 넓은 기본 규칙은 뒤에 배치해야 합니다. 예를 들어 광고 도메인 차단은 일반 도메인 프록시보다 앞에 두고, LAN과 사설 주소 직접 연결은 기본 프록시보다 앞에 둡니다. 순서가 뒤집히면 규칙 문법이 완전히 올바르더라도 잘못된 결과가 발생합니다.

도메인 규칙은 코어가 대상 도메인을 얻을 수 있을 때만 작동합니다. 애플리케이션이 먼저 로컬에서 해석하고 IP만 제출하면 geosite 규칙이 매칭되지 않을 수 있으며 이후에는 geoip나 다른 IP 규칙에 의존해야 합니다. 반대로 IP 규칙에는 해석 결과가 필요합니다. 해석 정책과 DNS 응답이 결과에 영향을 줍니다. 안정적인 분할을 위해서는 애플리케이션 인바운드, DNS와 라우팅을 하나의 설계 안에서 맞춰야 하며 규칙 목록 하나만 복사해서는 안 됩니다.

geosite, geoip와 domainStrategy

geosite는 도메인 집합으로 매칭하는 규칙 데이터입니다. 예를 들어 geosite:cn은 해당 도메인 집합을 뜻하고 geosite:category-ads-all은 광고 도메인 분류에 자주 사용됩니다. geoip는 IP 집합으로 매칭하며 geoip:private는 사설 주소, geoip:cn은 해당 지역 IP에 사용됩니다. 규칙 데이터는 클라이언트 또는 코어 리소스와 함께 업데이트됩니다. 로그에 집합이 없다고 표시되면 리소스 파일이 완전한지, 현재 데이터 세트가 해당 태그를 지원하는지 확인하세요.

domainStrategy는 라우팅이 어떤 조건에서 도메인의 IP를 해석할지 결정합니다. AsIs는 원래 도메인을 기준으로 매칭하는 경향이 있어 IP 규칙을 위해 적극적으로 해석하지 않습니다. IPIfNonMatch는 도메인 규칙이 매칭되지 않을 때 IP를 해석해 계속 매칭합니다. IPOnDemand는 규칙에 IP가 필요할 때 더 적극적으로 해석합니다. 일상적인 도메인·IP 혼합 분할에는 IPIfNonMatch를 자주 사용합니다. 도메인 매칭을 유지하면서 이후 IP 규칙도 작동하게 하지만, 실제 선택은 DNS 설정과 성능을 함께 고려해야 합니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

이 JSON은 Xray 설정에 넣을 수 있는 라우팅 객체의 예시이며, 전체 설정에 block과 direct라는 이름의 아웃바운드가 정의되어 있어야 합니다. 기본 프록시는 보통 규칙에 해당하지 않을 때 클라이언트가 선택하거나 마지막에 범위가 넓은 규칙을 명시해 지정합니다. 조각을 복사하기 전에 클라이언트가 생성한 아웃바운드 태그를 확인하세요. 클라이언트마다 태그 이름이 다를 수 있으며 태그가 일치하지 않으면 코어 시작 시 아웃바운드를 찾을 수 없다는 오류가 발생합니다.

설명 가능한 최소 규칙 집합 만들기

처음 사용자 규칙을 만들 때는 네 가지 의도만 남기는 것이 좋습니다. 명확히 필요 없는 도메인 집합 차단, 사설 네트워크 직접 연결, 확실히 직접 연결해야 하는 도메인과 IP, 나머지는 기본 프록시에 맡기기입니다. 규칙을 하나 추가할 때마다 “무엇과 매칭되는가, 왜 이 위치에 두는가, 매칭되면 어느 아웃바운드로 가는가”에 답할 수 있어야 합니다. 설명할 수 없다면 일단 추가하지 마세요. 출처가 불분명하고 지나치게 큰 규칙 집합은 업데이트 의존성을 높이고 오분류 원인을 찾기 어렵게 합니다.

사설 주소를 직접 연결하는 것은 특히 중요합니다. LAN 프린터, 라우터 관리 페이지, 파일 공유와 로컬 개발 서비스는 보통 사설 네트워크 대역에 있으므로 원격 프록시로 보내면 안 됩니다. geoip:private 외에도 대상 포트, 인바운드 태그 또는 명시적인 네트워크 대역으로 규칙을 보완할 수 있습니다. TUN에서 LAN에 접근하려면 가상 네트워크 인터페이스의 라우팅이 로컬 경로를 덮어쓰지 않는지도 확인해야 합니다. 직접 연결은 코어의 결정일 뿐이며 운영체제 라우팅 테이블도 대상에 도달할 수 있어야 합니다.

도메인, 포트와 프로세스별로 세분화하기

사용자 지정 도메인은 완전한 도메인, 서브도메인 접미사, 키워드 또는 정규식 형식으로 작성할 수 있습니다. 예측하기 쉬운 완전한 도메인과 접미사 매칭을 우선 사용하세요. 키워드는 관련 없는 사이트까지 잘못 매칭할 수 있고 정규식은 복잡도를 낮추며 용도를 기록해야 합니다. 포트 규칙은 특정 서비스를 제한하는 데 적합하지만 포트만으로 웹사이트의 소유자를 판단할 수는 없습니다. 하나의 포트에서 서로 다른 많은 서비스가 실행될 수 있기 때문입니다. 도메인과 포트를 같은 field 규칙에 넣으면 일반적으로 두 조건을 함께 적용한다는 뜻이므로 설정 전에 코어의 필드 조합 매칭 의미를 확인하세요.

프로세스별 분할은 플랫폼 기능과 클라이언트 구현에 의존합니다. 화면에서 프로세스 이름 규칙을 제공하더라도 권한, 프로세스 생성 방식과 컨테이너 환경의 영향을 받을 수 있습니다. 프로세스 규칙은 데스크톱 애플리케이션을 보완하는 제어 수단으로 사용하고 도메인·IP 규칙을 대신하게 해서는 안 됩니다. 애플리케이션 업데이트 후 실행 파일 이름이나 경로가 바뀌면 기존 규칙이 작동하지 않을 수도 있습니다. 관리할 때는 규칙이 남아 있는지만 보지 말고 로그에서 실제 프로세스 식별 결과를 확인하세요.

DNS 누수와 라우팅 불일치

대상 도메인을 로컬 DNS가 직접 해석하고 실제 연결은 프록시를 통과하면 해석 요청과 업무 연결이 서로 다른 경로에 놓입니다. 이로 인해 지역별 결과가 달라지거나 도메인 규칙 정보가 사라지거나 해석이 실패할 수 있습니다. 해결책은 DNS 주소만 단순히 바꾸는 것이 아니라 어떤 도메인을 어느 DNS 서버에서 해석할지, 해당 DNS 요청을 어느 아웃바운드로 보낼지 명확히 정하는 것입니다. 코어 DNS, 시스템 DNS, 브라우저 보안 DNS와 TUN DNS 가로채기가 동시에 존재할 수 있으므로 중복 계층을 최대한 줄이세요.

문제를 확인할 때는 먼저 브라우저의 독립 DNS 기능을 끄고 시스템과 클라이언트의 통합 경로로 테스트합니다. 이어서 로그에 대상 도메인이 남아 있는지, DNS 조회가 어느 아웃바운드로 가는지, 반환 주소가 예상한 IP 규칙에 들어가는지 확인합니다. 더 자세한 내용은 V2Ray DNS 누수 점검과 설정 실습을 참고하세요. DNS를 변경한 뒤에는 시스템과 애플리케이션 캐시를 지우고 다시 연결해야 이전 결과가 판단에 계속 영향을 주지 않습니다.

규칙 변경 후 검증 목록

라우팅을 저장한 뒤 코어를 다시 로드하고 로그에 필드, 태그 또는 리소스 오류가 없는지 확인합니다. 예상되는 직접 연결 대상, 프록시 대상과 LAN 주소를 각각 하나씩 방문하세요. 각 요청의 대상 도메인, 대상 IP와 아웃바운드 태그를 확인하고 마지막으로 네트워크를 전환해 한 번 더 테스트합니다. DNS 캐시와 이전 연결 풀의 영향을 배제하기 위해서입니다. 특정 애플리케이션만 규칙과 다르게 작동한다면 시스템 프록시를 읽는지, 독립 DNS를 사용하는지, 이전 연결을 재사용하는지 또는 QUIC을 켰는지 확인하세요.

규칙을 관리할 때는 간단한 설명과 변경 이유를 남겨야 합니다. 클라이언트가 메모를 지원하면 직접 기록하세요. JSON만 편집할 수 있다면 외부 문서에 규칙 의도를 저장하고 엄격한 JSON 파일에는 주석을 추가하지 마세요. 규칙을 삭제하기 전 다른 인바운드가 해당 규칙에 의존하는지 확인합니다. 장기적으로 안정적인 규칙 집합은 대개 더 짧습니다. 명확한 기본 동작과 적은 예외가 검증하기 쉽기 때문입니다.

CHAPTER 06

TUN 모드: 시스템 프록시를 읽지 않는 트래픽 연결하기

TUN과 시스템 프록시의 근본적인 차이

시스템 프록시는 애플리케이션이 운영체제 설정을 직접 읽어야 하지만, TUN은 가상 네트워크 인터페이스를 만들어 운영체제가 라우팅 테이블에 해당하는 IP 트래픽을 클라이언트로 전달하게 합니다. 프록시 설정을 지원하지 않는 애플리케이션, 일부 명령줄 프로그램과 UDP가 필요한 환경에서는 TUN의 적용 범위가 더 넓습니다. 대신 설정 계층이 늘어납니다. 코어 인바운드와 라우팅 규칙 외에도 가상 네트워크 인터페이스 권한, 시스템 라우팅, DNS 가로채기, MTU와 LAN 우회를 처리해야 합니다.

TUN은 “더 빠른 시스템 프록시”가 아니며 모든 문제의 첫 해결책으로 사용해서도 안 됩니다. 브라우저가 시스템 프록시를 통해 이미 안정적으로 작동한다면 먼저 구독, 서버와 라우팅을 검증한 뒤 TUN을 켜세요. 그러면 문제가 생겼을 때 기본 프록시 경로에는 문제가 없고 진단 범위가 가상 네트워크 인터페이스와 시스템 네트워크 계층으로 좁혀졌다는 것을 알 수 있습니다. 처음부터 TUN을 사용하면 연결 실패 원인이 서버, DNS, 권한 또는 라우팅 테이블 중 어디에 있는지 구분하기 어렵습니다.

활성화 전 권한과 충돌 점검

가상 네트워크 인터페이스를 만들려면 보통 관리자 권한이 필요합니다. v2rayN에서 TUN을 켤 때 권한 승인이나 관련 구성 요소 설치를 요청할 수 있으며 작업 후 시스템 네트워크 인터페이스 목록에 새 가상 인터페이스가 나타나야 합니다. 로그에 인터페이스 생성 실패, 접근 거부 또는 라우팅 쓰기 실패가 표시되면 먼저 시스템이 허용하는 방식으로 권한을 부여하고 보안 정책이 가상 네트워크 인터페이스를 차단하지 않는지 확인하세요. 오류를 우회하려고 스위치를 반복해서 누르지 마세요. 여러 임시 라우팅이 남을 수 있습니다.

다른 VPN, 가상 머신 네트워크, 컨테이너 네트워크와 보안 소프트웨어도 라우팅 테이블이나 DNS를 변경할 수 있습니다. TUN을 켜기 전에 필요하지 않은 유사 도구를 종료하고 기본 네트워크의 기본 게이트웨이와 DNS를 기록한 뒤 클라이언트를 시작하세요. 두 도구가 모두 기본 라우트를 선언하면 트래픽이 잘못된 인터페이스로 들어가거나 루프가 발생할 수 있습니다. 병행 사용이 꼭 필요하다면 양쪽이 모든 트래픽을 가져가게 하지 말고 더 구체적인 네트워크 대역과 라우팅 우선순위로 경계를 나누세요.

라우팅 테이블, 엄격한 라우팅과 자동 라우팅

자동 라우팅은 TUN 인터페이스에 시스템 라우팅을 추가해 대상 트래픽이 가상 네트워크 인터페이스로 들어가게 합니다. 엄격한 라우팅은 TUN을 우회할 수 있는 경로를 더 제한해 DNS와 업무 트래픽의 경로를 일치시키는 데 도움이 되지만, 가상 머신, LAN 검색 또는 특수 네트워크 카드에 영향을 줄 수도 있습니다. 처음에는 클라이언트가 권장하는 자동 라우팅 설정을 사용해 기본 접속을 확인한 뒤 필요에 따라 더 엄격한 정책을 활성화하세요.

LAN 접속에 문제가 생기면 먼저 사설 네트워크 대역에 직접 연결하는 시스템 라우팅이 유지되는지 확인한 다음 코어에서 geoip:private가 direct를 가리키는지 확인합니다. 두 조건이 모두 필요합니다. 운영체제는 LAN 대상을 올바른 게이트웨이로 보내야 하고 코어도 직접 연결을 선택해야 합니다. 회사 네트워크가 흔하지 않은 내부 대역을 사용한다면 모든 내부 주소가 일반적인 사설 범위에 포함된다고 가정하지 말고 명시적인 대역 규칙을 추가하세요.

Windows PowerShell
Get-NetRoute | Sort-Object RouteMetric
Get-DnsClientServerAddress

macOS
netstat -rn
scutil --dns

Linux
ip route
ip address

이 명령은 TUN을 켜기 전후의 인터페이스, 기본 라우팅과 DNS 변화를 확인하는 데 사용합니다. 기본 라우팅이 예상한 인터페이스에 의해 연결되었는지, LAN 대역에 더 구체적인 라우팅이 남아 있는지, TUN을 끈 뒤 임시 라우팅이 삭제되는지가 핵심입니다. 시스템마다 출력 형식이 다르므로 다른 사람의 인터페이스 이름이나 게이트웨이 주소를 그대로 사용하지 마세요.

DNS 가로채기와 FakeDNS

TUN이 받는 것은 IP 패킷이지만 라우팅 규칙은 도메인에 의존하는 경우가 많습니다. DNS 가로채기는 시스템 DNS 요청을 코어로 보내 코어가 도메인과 해석 결과의 관계를 유지하게 합니다. FakeDNS는 도메인에 임시 매핑 주소를 할당하고 애플리케이션이 해당 주소로 연결하면 코어가 원래 도메인을 복원해 라우팅합니다. 이러한 방식은 도메인 분할을 개선할 수 있지만 주소 풀이 LAN, 가상 머신 또는 다른 VPN 대역과 충돌하지 않아야 합니다.

“해석은 되지만 연결되지 않음”이 발생하면 FakeDNS 주소를 다른 라우팅이 가로채고 있는지 확인합니다. “클라이언트를 종료해도 네트워크가 계속 이상함”이 나타나면 시스템 DNS와 라우팅이 복원되었는지 확인하세요. 일부 애플리케이션은 내장 DNS나 암호화 DNS를 사용해 시스템의 일반 DNS 요청을 우회할 수 있습니다. 이때는 애플리케이션에서 독립 해석을 끄거나 TUN 라우팅으로 해석 연결도 클라이언트에 들어오게 해야 합니다. 시스템 DNS, 클라이언트 DNS와 브라우저 DNS가 서로 덮어쓰지 않도록 한 번에 하나의 주요 DNS 로직만 사용하세요.

MTU, UDP와 연결 이상

MTU는 하나의 네트워크 패킷이 가질 수 있는 최대 크기를 결정합니다. TUN 위에 프록시 전송이 추가되면 오버헤드가 늘어납니다. 경로가 조각화를 허용하지 않거나 필요한 제어 메시지를 버리면 MTU가 너무 클 때 작은 페이지는 열리지만 대용량 파일이나 특정 웹사이트가 오랫동안 멈출 수 있습니다. 이런 증상이 있으면 클라이언트가 허용하는 범위에서 TUN MTU를 조금씩 낮추고 매번 다시 연결해 같은 대상을 테스트하세요. 처음부터 지나치게 작은 값을 사용하면 패킷 수와 처리 오버헤드가 늘어나므로 피해야 합니다.

UDP는 서버 프로토콜, 아웃바운드 기능과 클라이언트 설정이 함께 지원해야 합니다. 음성 통화, 게임, DNS와 QUIC 기반 연결은 UDP를 사용할 수 있습니다. UDP는 되지 않지만 TCP는 정상이라면 현재 설정이 UDP를 허용하는지 먼저 확인하고, TUN 인바운드가 UDP를 받는지와 라우팅 규칙이 올바른 아웃바운드로 보내는지 점검하세요. 빠르게 원인을 좁히려면 브라우저에서 QUIC을 일시적으로 끄고 웹페이지가 복구되는지 확인할 수 있습니다. 이는 진단 수단일 뿐이며 최종적으로는 UDP 또는 라우팅 설정을 수정해야 합니다.

TUN을 장기간 사용하기에 적합한 경우

시스템 프록시를 지원하지 않는 여러 애플리케이션을 통합 연결해야 하거나 UDP에 의존하거나 하나의 라우팅 정책으로 데스크톱 프로그램을 처리하려면 TUN이 적합합니다. 브라우저와 일반적인 업무 도구만 사용한다면 시스템 프록시가 더 간단하고 LAN 서비스와 공존하기도 쉽습니다. TUN을 장기간 사용할 때는 시스템 업데이트 후 가상 네트워크 인터페이스 권한이 바뀌었는지, 네트워크 전환 후 기본 라우팅이 다시 만들어졌는지, 절전 모드에서 복구한 뒤 DNS가 여전히 유효한 인터페이스를 가리키는지 정기적으로 확인하세요.

시스템 프록시에서 TUN으로 전환할 때는 동일한 요청이 먼저 로컬 프록시에 들어간 뒤 TUN에 다시 포착되지 않도록 시스템 프록시를 먼저 해제합니다. 활성화 후 로그에서 인바운드 태그가 TUN에서 온 것인지 확인하고 TCP, UDP, LAN과 DNS를 각각 테스트하세요. 전체 활성화 절차와 플랫폼별 차이는 v2rayN TUN 모드 원리와 활성화 단계에서 확인할 수 있습니다.

CHAPTER 07

일상 관리: 업데이트, 백업, 로그와 문제 진단

관리 대상을 네 계층으로 나누기

안정적인 사용에는 클라이언트 프로그램, 코어와 규칙 리소스, 구독 데이터, 로컬 사용자 설정이라는 네 가지 대상이 관련됩니다. 각각 업데이트 출처와 위험이 다릅니다. 클라이언트 업데이트는 화면과 설정 마이그레이션 로직을 바꿀 수 있고, 코어 업데이트는 프로토콜과 설정 필드에 영향을 줍니다. 규칙 리소스 업데이트는 geosite와 geoip 매칭에 영향을 주며 구독 업데이트는 서버 항목을 교체합니다. 모든 내용을 한 번에 업데이트하면 문제가 발생했을 때 어느 계층의 변화가 원인인지 판단하기 어렵습니다.

더 안전한 방법은 나누어 실행하는 것입니다. 먼저 로컬 설정과 사용자 규칙을 내보낸 뒤 클라이언트를 업데이트하고 정상적으로 시작되는지 확인합니다. 그다음 코어와 리소스가 로드되는지 점검하고 마지막으로 구독을 하나씩 업데이트하며 활성 서버를 테스트합니다. 서버만 새로 고치려는 경우 라우팅과 DNS를 동시에 바꿀 필요는 없습니다. 관리할 때마다 무엇을 변경했고 어떤 경로를 테스트했는지 기록하면 문제가 재발했을 때 이전의 정상 설정으로 빠르게 돌아갈 수 있습니다.

복구에 실제로 도움이 되는 백업 항목

구독 서버 목록은 다시 가져올 수 있지만 구독 주소, 그룹 구조, 수동 서버, 라우팅 규칙, DNS, 포트와 TUN 매개변수는 로컬 관리 정보이므로 백업해야 합니다. 클라이언트의 내보내기 기능을 사용할 때 구독 주소와 민감한 필드가 포함되는지 확인하고 백업 파일은 통제된 위치에 보관하세요. 스크린샷은 화면 상태를 기록하는 데는 적합하지만 완전한 백업으로는 부족합니다. 긴 주소, 숨겨진 필드와 규칙 순서를 안정적으로 복원할 수 없기 때문입니다.

다른 기기로 이전할 때 모든 캐시와 실행 상태를 그대로 복사해서는 안 됩니다. 먼저 플랫폼에 맞는 클라이언트를 설치하고 구독과 필요한 규칙을 가져온 다음 새 기기의 프로세서 아키텍처, 권한과 네트워크 환경에 맞춰 조정하세요. 리스닝 포트, 네트워크 카드 이름과 시스템 프록시 상태는 원래 설정을 그대로 옮기기 적합하지 않을 수 있습니다. 복원 후에는 최소 시스템 프록시 테스트부터 시작하고 정상 작동을 확인한 뒤 TUN과 고급 DNS를 활성화하세요.

로그는 첫 번째 오류부터 읽어야 합니다

코어 로그에는 하나의 근본 원인 뒤에 연쇄적인 오류가 여러 개 나타나는 경우가 많습니다. 예를 들어 DNS 해석 실패로 연결 대상이 비어 있으면 이어서 아웃바운드 실패와 요청 종료가 발생합니다. 포트가 이미 사용 중이면 인바운드 생성이 실패하고 이후 모든 애플리케이션이 연결되지 않습니다. 문제를 찾을 때는 마지막 시간 초과보다 이번 시작 이후 처음 나타난 명확한 오류를 찾는 편이 효과적입니다. 다시 테스트하기 전에 로그를 지우거나 시점을 기억해 이전 오류를 현재 상태로 오해하지 않도록 하세요.

일반적인 메시지는 단계별로 분류할 수 있습니다. 설정 해석 오류는 필드, JSON 구조 또는 태그 문제를 의미합니다. 리스닝 실패는 보통 포트 점유나 권한과 관련됩니다. 도메인 해석 실패는 DNS 문제입니다. 연결 거부는 대상에 도달했지만 포트가 연결을 받지 않는다는 뜻입니다. 시간 초과는 로컬 네트워크, 원격 경로 또는 핸드셰이크 단계에서 발생할 수 있습니다. 인증과 핸드셰이크 오류는 서버 항목의 프로토콜 매개변수와 시스템 시간을 확인해야 하는 경우가 많습니다. 로그에 서버 주소나 구독 정보가 포함되어 있다면 공유 전에 민감한 내용을 삭제하세요.

재현 가능한 문제 진단 절차 만들기

첫 번째로 기본 네트워크를 확인합니다. 클라이언트를 끈 뒤 일반 네트워크, DNS와 시스템 시간이 정상인지 확인하세요. 두 번째로 클라이언트 프로세스를 점검합니다. 사용 가능한 설정 하나로 코어를 시작하고 해석 또는 리스닝 오류가 없는지 확인합니다. 세 번째로 시스템 프록시를 활성화하고 시스템 설정을 따르는 브라우저로 테스트하면서 로그를 관찰합니다. 네 번째로 전체 프록시와 규칙 모드를 비교해 분할 문제인지 판단합니다. 다섯 번째에야 TUN을 켜고 가상 인터페이스와 DNS를 확인합니다. 각 단계는 이전 단계가 성공했다는 전제 위에서 진행해야 합니다.

네트워크 전환 후 문제가 발생했다면 먼저 현재 활성 서버에 다시 연결하세요. 이전 TCP 연결과 DNS 결과가 이미 무효화되었을 수 있습니다. 절전 모드에서 복구한 뒤 이상이 생겼다면 코어 프로세스, 가상 인터페이스와 시스템 프록시가 여전히 일치하는지 확인합니다. 클라이언트를 종료했는데 시스템 프록시가 해제되지 않으면 애플리케이션이 존재하지 않는 로컬 포트에 계속 연결하려 해 모든 웹페이지가 즉시 실패할 수 있습니다. 이때는 서버를 바꾸기보다 시스템 프록시를 지우는 것이 직접적인 해결책입니다.

구독과 규칙의 업데이트 주기

클라이언트를 열 때마다 구독을 연속해서 업데이트할 필요는 없습니다. 출처의 변경 빈도에 맞춰 적절한 간격을 설정하고 수동 업데이트 기능도 남겨 두세요. 업데이트가 너무 잦으면 요청 실패와 목록 재정렬이 반복될 가능성이 커지고, 너무 오래 업데이트하지 않으면 이미 만료된 항목이 남을 수 있습니다. 여러 그룹의 업데이트 시간을 분산해 동시에 요청하지 않도록 하세요. 업데이트 전에 사용 중이던 서버가 삭제되면 클라이언트가 다른 항목으로 전환할 수 있으므로 업데이트 후 현재 선택 항목을 확인해야 합니다.

규칙 리소스를 업데이트하면 집합의 내용이 달라질 수 있습니다. 중요한 업무 도메인을 범위가 넓은 집합에만 의존하게 하지 말고 더 명확한 고우선순위 규칙을 추가하세요. 리소스 업데이트 후 자주 사용하는 직접 연결, 프록시와 차단 대상을 표본 검사하고 내부 도메인과 LAN 서비스도 특히 확인합니다. 새 리소스로 문제가 생기면 먼저 사용자 규칙으로 특정 대상을 바로잡은 뒤 집합의 변화를 분석하세요. 서로 덮어쓰는 규칙 패키지를 무작정 쌓지 마세요.

설정과 진단 정보 안전하게 다루기

구독 주소, 서버 인증 필드와 내보낸 전체 설정에는 계정 정보가 포함될 수 있습니다. 백업을 저장할 때는 접근 범위를 제한하고 로그를 보낼 때는 오류 맥락만 남기며 주소, 토큰과 인증 필드를 바꾸세요. 전체 설정을 공개 토론 공간에 그대로 붙여 넣지 마세요. 문제를 보여줄 때는 프로토콜 유형, 전송 방식, 오류 단계와 익명화된 라우팅 구조만으로도 대개 충분히 진단할 수 있습니다.

원격 지원을 받기 전에 임시 백업을 만들고 시스템 프록시와 TUN의 현재 상태를 기록하세요. 작업이 끝난 뒤 구독 그룹, 사용자 규칙과 운영체제 네트워크 설정이 변경되지 않았는지 확인합니다. 클라이언트 동작이 갑자기 달라졌다면 서버만 보지 말고 먼저 로컬 설정을 비교하세요. 더 구체적인 증상과 복구 절차는 자주 묻는 질문의 문제 해결 분류에서 확인할 수 있습니다.

CHAPTER 08

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

1단계: 최소 작업 경로 하나 고정하기

고급 설정의 출발점은 매개변수를 늘리는 것이 아니라 안정적으로 재현할 수 있는 최소 경로를 만드는 것입니다. 클라이언트 하나, 활성 서버 하나, 시스템 프록시 자동 설정과 간단한 라우팅을 선택하고 로컬 인바운드, 기본 아웃바운드와 DNS 동작을 기록하세요. 브라우저 요청이 로그에 들어오고 직접 연결 및 프록시 대상이 각각 예상한 아웃바운드에 매칭되는지 확인합니다. 이후 모든 변경은 이 기준선과 비교해야 무엇이 달라졌는지 알 수 있습니다.

기준선 단계에서는 여러 클라이언트, 여러 시스템 프록시 출처와 여러 DNS 연결 계층을 동시에 사용하지 마세요. v2rayN으로 데스크톱을 연결한다면 시스템 프록시를 수정하는 도구를 v2rayN 하나로 통일합니다. Android에서는 활성 VPN 세션 하나만 유지하세요. 서버 목록은 많아도 되지만 테스트할 때는 항목 하나를 고정합니다. 항목 전환과 설정 변경을 동시에 하면 연결 결과의 원인을 구분할 수 없습니다.

2단계: 설정 객체와 태그 익히기

전체 설정을 읽을 수 있게 되면 inbounds, outbounds, routing, dns와 log를 중점적으로 이해하세요. 인바운드 태그로 시스템 프록시, TUN 또는 특정 애플리케이션 출처를 구분할 수 있습니다. 아웃바운드 태그는 라우팅이 프록시, 직접 연결, 차단 또는 다른 경로를 가리키게 합니다. 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 인바운드, 직접 연결 아웃바운드와 차단 아웃바운드의 관계를 보여 줍니다. 실제 클라이언트는 보통 포트를 자동으로 할당하고 원격 프로토콜 필드를 생성하므로 수동으로 병합할 때 기존 인바운드와 포트가 충돌하지 않게 하세요. 리스닝 주소는 루프백 주소로 유지해 LAN 기기가 로컬 프록시에 접근하지 못하도록 제한할 수 있습니다.

3단계: DNS와 라우팅의 의도를 일치시키기

성숙한 설정은 세 가지 질문에 명확히 답해야 합니다. 특정 도메인 유형을 어느 DNS가 해석하는지, DNS 요청을 어느 아웃바운드로 보낼지, 해석 결과를 어느 라우팅이 처리할지입니다. 공용 DNS 주소 하나만 설정한다고 분할 문제가 자동으로 해결되지는 않습니다. 도메인 집합에 따라 DNS 서버를 선택해 직접 연결 도메인은 직접 연결 DNS로, 프록시가 필요한 도메인은 프록시 경로로 해석하게 하면서 LAN 도메인에 대한 시스템 해석 능력은 유지할 수 있습니다.

DNS를 조정할 때는 사용 가능한 폴백 경로 하나를 먼저 유지하고 브라우저가 독립 DNS를 사용하는지 기록하세요. 테스트에는 도메인 최초 해석, 캐시 적중과 네트워크 전환을 포함해야 합니다. 같은 도메인이 어떤 때는 되고 어떤 때는 안 된다면 서로 다른 주소 계열을 동시에 받는지, 여러 DNS 응답이 존재하는지, IPv4와 IPv6에 서로 다른 결과가 적용되는지 확인하세요. 특정 주소 계열을 끄는 것은 진단 방법으로 사용할 수 있지만 장기적인 해결책은 현재 네트워크와 원격 기능에 맞춰 정해야 합니다.

4단계: 인바운드와 상황별로 정책 나누기

시스템 프록시, TUN과 애플리케이션 전용 포트가 함께 존재할 때는 인바운드 태그로 서로 다른 규칙을 적용할 수 있습니다. 예를 들어 시스템 프록시는 일상적인 분할을 유지하고 전용 SOCKS 인바운드는 기본적으로 프록시를 사용하며 TUN은 LAN 직접 연결을 우선하고 UDP를 처리하게 만들 수 있습니다. 이는 긴 도메인 목록 하나에서 애플리케이션 출처를 추측하는 것보다 명확합니다. 나눌 때는 각 인바운드에 포트, 용도와 호출 주체를 명시하고 사용하지 않는 인바운드는 즉시 끄세요.

상황 전환은 단일 규칙을 반복해서 편집하기보다 라우팅 설정 그룹으로 처리할 수 있습니다. 일상, 디버깅과 전체 프록시를 각각 명확한 프리셋으로 저장하고 전환 후 상태 표시줄에 현재 모드가 표시되는지 확인하세요. 디버깅이 끝나면 일상 규칙으로 돌아가 전체 프록시 상태를 장기간 유지하지 않도록 합니다. 여러 설정 그룹이 사용자 규칙을 공유한다면 업데이트 순서를 확인해 한 프리셋이 이전 리소스를 계속 참조하지 않게 하세요.

5단계: 연결을 추측하지 말고 관찰하기

고급 문제 해결에는 관측 가능성을 확보해야 합니다. 라우팅과 연결 단계 정보를 볼 수 있도록 로그 수준을 일시적으로 높이고 요청을 한 번 재현한 즉시 일상 수준으로 되돌려 로그가 빠르게 늘어나지 않게 하세요. 대상 도메인, 해석 결과, 인바운드 태그, 매칭된 규칙, 아웃바운드 태그와 최종 오류를 기록하면 보통 문제가 발생한 계층을 찾을 수 있습니다. “열리지 않음”만 기록해서는 애플리케이션이 프록시에 들어오지 않은 것인지, DNS 실패인지, 규칙에 따라 직접 연결된 것인지, 원격 핸드셰이크가 실패한 것인지 구분할 수 없습니다.

시스템 도구로 클라이언트 로그를 보완할 수 있습니다. 리스닝 포트를 확인해 코어가 연결을 받고 있는지 점검하고, 라우팅 테이블을 확인해 TUN이 트래픽을 넘겨받는지 확인하며, DNS 설정으로 해석 진입점을 확인하고 연결 테스트로 대상 포트에 도달할 수 있는지 확인하세요. 도구 결과는 클라이언트 상태와 함께 해석해야 합니다. 대상 포트에 도달할 수 있다고 해서 프로토콜 핸드셰이크가 올바른 것은 아니며, 로그에 코어가 실행 중이라고 표시되어도 애플리케이션이 로컬 포트에 연결했다는 뜻은 아닙니다.

6단계: 변경과 복구 원칙 세우기

한 번에 하나의 주요 변수만 바꾸는 것이 설정을 장기적으로 관리하는 핵심입니다. 라우팅을 수정할 때 DNS를 동시에 바꾸지 말고, TUN을 조정할 때 클라이언트를 동시에 업데이트하지 말며, 서버를 전환할 때 전송 매개변수도 함께 바꾸지 마세요. 변경 전에 현재 설정을 내보내고 변경 후 고정된 테스트 대상으로 검증합니다. 실패하면 임시 수정 사항을 계속 쌓기보다 즉시 되돌리세요. 임시 수정이 유효하다는 것을 확인했다면 명확한 규칙으로 정리하고 중복 항목을 삭제해야 합니다.

설정 문서에는 매개변수뿐 아니라 목적을 기록해야 합니다. 예를 들어 geoip:private만 적는 것보다 “LAN 기기에 접근하기 위해 사설 네트워크 대역을 직접 연결”이라고 쓰는 편이 유지 관리에 더 유용합니다. 이후 규칙 리소스나 네트워크 환경이 바뀌어도 목적에 맞게 다시 구현할 수 있기 때문입니다. 구독, 라우팅, DNS와 TUN에는 각각의 복구 방법을 마련해 하나가 손상되었을 때 전체 설정을 초기화하지 않도록 하세요.

권장하는 지속 학습 순서

먼저 시스템 프록시와 최소 라우팅에 익숙해진 다음 구독 그룹과 규칙 순서를 학습하세요. 이어서 DNS, 도메인 전략과 아웃바운드 태그를 이해하고 기본 경로가 안정된 뒤 TUN을 켜 가상 네트워크 인터페이스와 라우팅 테이블을 관찰합니다. 마지막으로 앱별 분할, 다중 인바운드와 복잡한 DNS를 다루세요. 각 단계마다 간단한 설정을 하나 보존해 비교 대상으로 삼아야 합니다. 새 프로토콜이나 필드를 만났을 때는 먼저 프로토콜, 전송, 보안과 라우팅 중 어느 계층에 속하는지 판단한 뒤 관련 문서를 확인하세요.

빠르게 연결을 한 번 완료해야 한다면 빠른 시작 기본 과정으로 돌아가세요. 플랫폼별 설치 패키지를 선택하려면 다운로드 페이지로 이동하고, v2rayN, v2rayNG와 v2flyNG의 적합한 환경을 비교하려면 클라이언트 비교를 확인하세요. 이 설명서는 설정 과정에서 찾아보는 색인으로 활용할 수 있습니다. 먼저 증상에 맞는 장을 찾고 데이터 경로를 따라 계층별로 점검하면 매번 전체 설정을 처음부터 다시 만들 필요가 없습니다.