V2Ray 초보자부터 고급 사용자까지 종합 가이드

핵심 개념: 클라이언트·코어·설정의 관계부터 이해하기

그래픽 클라이언트는 프로토콜 자체가 아닙니다

사용하기 전에 자주 혼용되는 몇 가지 이름부터 구분해야 합니다. V2Ray는 일반적으로 Project V에서 발전한 기술 생태계를 가리키며, 여러 프록시 프로토콜과 코어, 그래픽 클라이언트를 통칭하는 말로도 사용됩니다. v2rayN, v2rayNG, v2flyNG는 플랫폼별 그래픽 클라이언트로, 설정 저장, 서버 전환, 시스템 프록시 제어, 로그 표시를 담당하고 정리된 매개변수를 코어에 전달해 실행합니다. Xray와 V2Fly는 코어 계열에 속하며 연결 수립, 프로토콜 인코딩·디코딩, 전송 계층과 라우팅 매칭을 실제로 처리합니다. 이 관계를 이해하면 문제가 발생했을 때 화면 조작, 설정 데이터, 시스템 트래픽 제어, 코어 실행 중 어느 부분에서 문제가 생겼는지 판단할 수 있습니다.

프로토콜은 VMess, VLESS, Trojan처럼 클라이언트와 서버가 필요한 정보를 주고받는 방식을 정의합니다. 전송 방식은 TCP, WebSocket, gRPC처럼 데이터가 전달되는 방식을 설명하며, TLS와 REALITY 같은 보안 계층은 또 다른 위치에서 작동합니다. 사용 가능한 노드는 프로토콜 이름만으로 결정되지 않고 주소, 포트, 사용자 식별자, 전송 방식, 보안 계층, 도메인 등의 매개변수가 함께 구성합니다. 어느 하나라도 서버와 다르면 연결 실패로 나타날 수 있습니다. 이름만 보고 매개변수를 추측하거나 한 노드의 필드를 다른 노드에 기계적으로 복사하지 마세요.

설정은 어디에서 오고 어디로 전달될까요

일반적인 설정 입력 방식은 두 가지입니다. 단일 노드 공유 링크는 설정 하나를 임시로 추가할 때 적합하고, 구독 주소는 서비스 제공자가 관리하는 여러 노드를 관리하는 데 사용합니다. 클라이언트가 구독을 읽으면 항목을 내부 설정으로 변환해 구독 그룹에 넣습니다. 연결할 때는 현재 선택한 노드, 프록시 모드, 라우팅 규칙과 로컬 포트가 함께 실행 설정을 만듭니다. 따라서 구독 업데이트는 ‘연결 시작’과 같은 의미가 아닙니다. 업데이트는 목록만 새로 고치며, 노드를 선택하고 연결을 시작해야 새 설정이 현재 세션에 적용됩니다.

시스템 프록시와 TUN도 같은 계층에 있지 않습니다. 시스템 프록시는 운영체제의 프록시 설정을 바꾸며, 해당 설정을 따르는 앱만 요청을 클라이언트로 보냅니다. TUN은 가상 네트워크 인터페이스를 만들어 더 낮은 계층에서 트래픽을 받으므로 적용 범위가 넓지만 권한, 라우팅과 DNS 요구 사항도 더 높습니다. 처음에는 시스템 프록시부터 익히고 노드와 구독이 정상인지 확인한 뒤 TUN이 필요한지 검토하세요. 이렇게 하면 문제 범위를 작은 영역으로 제한할 수 있습니다.

계층적으로 문제 해결하기

체계적인 점검은 가장 짧은 경로부터 시작해야 합니다. 먼저 클라이언트가 정상적으로 시작되는지 확인하고, 다음으로 구독을 읽을 수 있는지 확인합니다. 그 후 노드를 선택해 코어가 정상 실행되는지 보고, 마지막으로 앱 트래픽이 프록시로 들어가는지 확인합니다. 클라이언트가 시작하자마자 종료되면 실행 환경, 디렉터리 권한과 남은 프로세스를 먼저 점검합니다. 구독 업데이트에 실패하면 주소 형식, 네트워크 연결 가능 여부와 시스템 시간을 확인합니다. 코어는 실행 중인데 브라우저에 변화가 없으면 시스템 프록시와 브라우저 자체 설정을 확인합니다. 특정 앱만 작동하지 않는다면 해당 앱이 시스템 프록시를 무시하는지, TUN이 필요한지 검토합니다.

지연 시간 테스트는 선별을 위한 참고 자료일 뿐, 노드의 전체적인 사용 가능성을 단독으로 입증하지는 못합니다. 테스트 방식에 따라 TCP 연결 수립, 핸드셰이크 또는 특정 대상만 확인할 수 있으며 결과는 로컬 네트워크, 테스트 대상과 순간 부하의 영향을 받습니다. 더 신뢰할 수 있는 판단 방법은 설정 핸드셰이크 성공 여부를 먼저 확인한 뒤 실제 필요한 앱으로 접속을 테스트하고, 로그에서 반복 재시도, DNS 실패 또는 라우팅 거부가 있는지 확인하는 것입니다. ‘클라이언트—설정—코어—시스템—앱’이라는 계층 모델을 세우는 것이 이후 각 장의 기반입니다.

클라이언트 선택: 플랫폼·코어·사용 목적에 맞춰 결정하기

데스크톱 플랫폼에서는 v2rayN을 우선 선택

Windows, macOS, Linux 데스크톱 환경에서는 v2rayN을 우선 선택하세요. v2rayN은 구독 그룹, 서버 목록, 시스템 프록시, 라우팅 규칙, TUN과 로그를 하나의 화면에서 관리할 수 있어 장기 관리용 주력 클라이언트로 적합합니다. 데스크톱에서는 브라우저, 개발 도구, 업무용 앱과 명령줄 프로그램을 함께 다루는 경우가 많으므로 v2rayN의 그룹 및 라우팅 기능으로 안정적인 작업 흐름을 만들기 쉽습니다. Windows 사용자는 다운로드 페이지에서 데스크톱 버전과 클래식 WPF 버전을 볼 수 있습니다. 데스크톱 버전은 최신 크로스 플랫폼 인터페이스를 사용하고, 클래식 WPF 버전은 기존 Windows 인터페이스에 익숙한 사용자에게 적합합니다. 둘 중 하나만 선택해 계속 사용하면 되며 동시에 실행할 필요는 없습니다.

macOS에서 다운로드할 때는 프로세서 아키텍처에 맞춰 Apple Silicon 또는 Intel 설치 패키지를 선택해야 합니다. Linux는 배포판의 패키지 체계에 따라 deb 또는 rpm을 선택하고 x64와 arm64도 구분해야 합니다. 아키텍처를 잘못 고르면 일반적으로 네트워크 연결 문제가 아니라 설치 또는 실행 실패로 나타납니다. 따라서 설치 후 노드를 계속 조정하기보다 먼저 시스템 정보를 확인하는 편이 효율적입니다. 모든 설치 경로는 설치 패키지 페이지에 모여 있으며, 네 가지 플랫폼별 선택 방법이 정리되어 있습니다.

Android에서는 v2rayNG와 v2flyNG

Android에서는 v2rayNG를 우선 선택하세요. v2rayNG는 Xray 코어를 기반으로 하며 일반적인 프로토콜, 구독 관리, 앱별 프록시와 시스템 VPN 제어가 필요한 사용자에게 적합합니다. 설치 패키지는 보통 arm64와 범용 버전으로 나뉘며 최근 주류 기기는 대체로 arm64를 사용합니다. 기기 아키텍처를 확인하기 어렵다면 범용 버전의 호환 범위가 더 넓지만 용량은 보통 더 큽니다. 처음 연결할 때 시스템에서 VPN 연결 권한을 요청하는데, 이는 Android가 앱 트래픽을 클라이언트로 전달하기 위해 필요한 단계입니다. 권한을 허용했다고 해서 구독이 가져와졌거나 노드를 사용할 수 있다는 뜻은 아닙니다.

v2flyNG는 Android에서 V2Fly 코어를 주로 사용하는 대안 클라이언트입니다. 설정이 V2Fly의 동작에 명확히 의존하거나 같은 플랫폼에서 서로 다른 코어 구현을 비교하려는 사용자에게 적합합니다. 이름만 보고 어느 클라이언트가 ‘더 빠르다’고 판단하지 마세요. 실제 사용 경험은 설정된 프로토콜, 로컬 네트워크, 원격 상태와 코어 호환성에 따라 달라집니다. 대부분의 Android 초보 사용자는 먼저 v2rayNG로 안정적인 연결을 완성하는 편이 쉽습니다. 설정 출처, 프로토콜 지원과 코어 요구 사항을 명확히 알고 있을 때만 v2flyNG로 전환하세요.

클라이언트 전환으로 문제 원인을 대신하지 마세요

연결에 실패했을 때 여러 클라이언트를 연달아 설치해도 문제 범위를 좁히기 어렵습니다. 먼저 하나의 클라이언트를 고정하고 구독 성공 여부, 코어 시작 여부와 로그가 멈춘 지점을 기록하는 편이 효과적입니다. 같은 구독의 모든 노드가 실패하면 구독 상태, 시스템 시간, 네트워크와 설정 호환성을 먼저 확인합니다. 특정 노드 하나만 실패하면 해당 노드와 정상 노드의 프로토콜 및 전송 필드를 비교합니다. 시스템 프록시는 작동하지만 TUN이 작동하지 않는다면 노드 연결은 대체로 정상일 가능성이 높으므로 권한, DNS와 라우팅을 점검해야 합니다.

클라이언트를 이전할 때 기존 설정 디렉터리를 바로 덮어쓰지 마세요. 먼저 구독 그룹, 라우팅 규칙과 로컬 포트를 내보내거나 기록하고, 이전 클라이언트와 코어 프로세스를 종료한 뒤 시스템 프록시가 복원되었는지 확인합니다. 그 다음 새 클라이언트를 시작하세요. 두 클라이언트가 동시에 시스템 프록시를 제어하거나 같은 포트를 수신하면 무작위처럼 보이는 연결 장애가 발생할 수 있습니다. Android에서 v2rayNG와 v2flyNG를 전환할 때도 현재 VPN 연결을 먼저 중지한 뒤 다른 클라이언트를 시작해 이전 세션이 남지 않도록 해야 합니다.

명확한 선택 기준 세우기

클라이언트 선택은 세 가지 질문으로 정리할 수 있습니다. 현재 운영체제는 무엇인지, 구독이 어떤 코어를 요구하는지, 고급 라우팅이나 TUN이 필요한지입니다. 데스크톱에서는 v2rayN으로 시작하고 Android에서는 v2rayNG로 시작하세요. 설정 제공자가 V2Fly 동작을 명확히 지정한 경우에만 v2flyNG를 고려합니다. 인터페이스 선호도는 최종 선택에 영향을 줄 수 있지만 프로토콜 호환성과 시스템 아키텍처보다 우선할 수는 없습니다. 세 클라이언트의 차이는 비교 평가에서 확인할 수 있으며, 설치 패키지 종류는 다운로드 페이지의 최신 목록을 기준으로 하세요.

클라이언트를 정한 뒤에는 도구를 바꾸기보다 최소 한동안 연속해서 사용하세요. 인터페이스를 자주 바꾸는 것보다 안정적인 설정 습관이 더 중요합니다. 구독 메모를 통일하고, 라우팅 규칙 이름을 고정하며, 시스템 프록시 전환을 명확히 하고, 필요한 로그를 보관하면 이후 관리가 반복 가능한 절차가 됩니다. 다음 장에서는 이 관점으로 설치와 최초 시작을 다룹니다.

설치 및 최초 시작: 복구 가능한 기본 환경부터 만들기

설치 전에 시스템과 프로세서 아키텍처 확인

설치의 첫 단계는 파일을 더블클릭하는 것이 아니라 운영체제 버전, 프로세서 아키텍처와 쓰기 가능한 디렉터리를 확인하는 것입니다. Windows는 보통 x64이고, macOS는 Apple Silicon과 Intel을 구분해야 합니다. Linux는 x64와 arm64 외에도 배포판에 따라 deb 또는 rpm을 선택해야 하며, Android는 arm64와 범용 패키지 중에서 선택합니다. 시스템 정보의 ‘시스템 유형’, ‘칩’ 또는 ‘프로세서’ 항목이 기기 마케팅 명칭보다 신뢰할 수 있습니다. 아키텍처가 맞지 않으면 설치 패키지를 다시 선택해야 하며 확장자를 바꾸거나 실행 파일을 복사해 제한을 우회하려고 하지 마세요.

데스크톱에서는 경로가 명확하고 현재 계정에 읽기·쓰기 권한이 있는 위치에 클라이언트를 두는 것이 좋습니다. 클라이언트는 구독, 로그, 라우팅 규칙과 화면 설정을 저장하므로 읽기 전용 디렉터리에서는 설정 저장 실패, 업데이트 후 설정 복원 또는 코어 파일 해제가 발생할 수 있습니다. 경로는 가능한 한 짧게 유지하고 실행 중인 디렉터리를 필요할 때 파일을 자동으로 해제하는 동기화 도구에 맡기지 마세요. 이전할 때는 클라이언트를 먼저 종료한 뒤 설정 디렉터리 전체를 복사하세요. 주 프로그램만 복사하면 구독 그룹과 사용자 지정 규칙을 보존할 수 없습니다.

최초 시작에서는 필요한 설정만 완료하기

처음 시작한 뒤에는 화면이 정상적으로 열리는지, 코어 구성 요소를 호출할 수 있는지, 로그 창에 지속적인 오류가 없는지 확인하세요. 이때 TUN, 사용자 지정 DNS와 복잡한 라우팅을 서둘러 활성화하지 마세요. 기본 로컬 포트와 기본 프록시 모드를 유지하고 출처가 명확한 구독 또는 단일 노드를 가져온 다음 첫 연결을 시도하세요. 이렇게 하면 클라이언트 시작, 설정 읽기, 코어 실행, 시스템 프록시 적용, 앱 접속이라는 가장 짧은 검증 경로를 만들 수 있습니다. 어느 단계에서 실패했는지도 명확해집니다.

Windows에서 시작 직후 종료되면 시스템 실행 환경, 프로그램 디렉터리 권한, 이전 프로세스와 설정 파일 손상 여부를 확인하세요. macOS에서 처음 실행이 차단되면 앱 파일을 반복해서 복사하지 말고 시스템 설정에서 해당 앱의 열기를 허용하세요. Linux에서 설치 후 시작되지 않으면 먼저 터미널에서 한 번 실행해 누락된 의존성이나 권한 메시지를 확인합니다. Android에서는 설치 후 필요한 알림 표시를 먼저 허용해 연결 상태를 확인하기 쉽게 만들고, 최초 연결 시 시스템 VPN 권한을 처리하세요.

Windows: 설정 → 시스템 → 시스템 정보 → 시스템 종류
macOS: Apple 메뉴 → 이 Mac에 관하여 → 칩
Linux：uname -m
Android: 시스템 정보 도구에서 ABI를 확인하고 arm64-v8a를 우선 식별

종료, 재시작과 시스템 프록시 복원

데스크톱 클라이언트는 창을 닫아도 즉시 종료되지 않을 수 있으며 일부 설정에서는 프로그램이 계속 백그라운드에 남습니다. 업데이트, 이전 또는 포트 사용 여부를 점검하기 전에 클라이언트의 종료 명령을 사용하고 코어 프로세스도 끝났는지 확인하세요. 프로세스를 강제로 종료하면 시스템 프록시가 이전 로컬 포트를 계속 가리킬 수 있어 이후 브라우저의 모든 요청이 실패할 수 있습니다. 이때 노드 자체가 정상이어도 먼저 시스템 프록시를 복원한 다음 클라이언트를 다시 시작해야 합니다.

안전한 종료 순서는 현재 연결 중지, 시스템 프록시 또는 TUN 해제, 클라이언트 종료, 프로세스 종료 확인입니다. 재시작할 때는 반대로 클라이언트를 먼저 열고 설정 로드가 끝났는지 확인한 뒤 노드를 선택해 코어를 시작하고 마지막에 시스템 프록시 또는 TUN을 켭니다. 이 순서를 지키면 아직 수신 대기 중이 아닌 로컬 포트로 트래픽이 전송되는 것을 막을 수 있습니다. Android에서는 최근 앱 화면에서 앱을 밀어 닫는 것만으로도 제조사 백그라운드 정책에 의해 종료될 수 있습니다. 지속적인 연결이 필요하다면 이후 관리 장에서 절전 예외 목록과 백그라운드 실행 권한을 설정하세요.

이후 문제 해결을 위한 기준 상태 보관

처음 연결에 성공한 뒤 바로 설정을 추가하지 마세요. 현재 클라이언트, 구독 그룹, 노드 유형, 프록시 모드와 TUN 활성화 여부를 기록하고 브라우저 하나와 일상적인 앱 하나가 안정적으로 접속되는지 확인하세요. 이 상태가 이후 조정의 기준선입니다. 라우팅이나 DNS를 변경한 뒤 문제가 생기면 모든 구성 요소를 다시 설치하지 말고 기준선으로 돌아가 어떤 변경이 영향을 주었는지 판단할 수 있습니다.

로그 위치와 설정 백업 위치도 함께 익혀 두는 것이 좋습니다. 로그에서는 오류가 발생한 단계, 대상 주소, 프로토콜 핸드셰이크 결과와 DNS 메시지가 가장 중요하며 장기간 상세 디버그 출력을 보관할 필요는 없습니다. 백업은 클라이언트를 완전히 종료한 뒤 수행하고 최소한 구독 정보, 라우팅 규칙과 주요 기본 설정을 포함하세요. 실행 라이브러리와 권한으로 인한 시작 문제는 클라이언트 시작 직후 종료 문제 해결 가이드에서 계속 확인할 수 있습니다.

구독 및 노드: 설정 출처를 관리 가능한 그룹으로 정리하기

구독 주소, 공유 링크와 수동 설정

구독 주소는 여러 노드를 한 번에 가져와 지속적으로 업데이트하는 방식으로 장기 관리에 적합합니다. 공유 링크는 보통 단일 노드만 설명하므로 임시 가져오기나 정밀 테스트에 적합합니다. 수동 설정은 주소, 포트, 사용자 식별자, 전송과 보안 매개변수를 하나씩 입력해야 하며 가져오기 형식을 사용할 수 없거나 세부 사항을 확인해야 할 때 사용합니다. 세 입력 방식 모두 클라이언트에서 선택 가능한 서버 항목을 만들지만 업데이트 방식은 다릅니다. 구독 노드는 구독 업데이트로 관리해야 하며 수동 변경 사항은 다음 새로 고침 때 덮어써질 수 있습니다.

구독을 추가할 때는 먼저 알아보기 쉬운 그룹 메모를 만든 다음 전체 주소를 붙여 넣으세요. 메모에는 서비스 이름, 용도 또는 환경을 사용할 수 있습니다. ‘구독 1’, ‘예비 2’처럼만 적으면 출처가 여러 개일 때 어떤 대상을 업데이트해야 하는지 판단하기 어렵습니다. 저장 후 직접 한 번 업데이트해 클라이언트가 항목을 반환하는지, 형식 오류가 발생하는지 확인하세요. 구독 주소에는 접근 자격 증명이 포함될 수 있으므로 관리되는 기기와 클라이언트 설정에만 보관하고 공개 문서, 스크린샷이나 공유 로그에는 넣지 마세요.

업데이트가 즉시 전환을 의미하지는 않습니다

구독 업데이트는 현재 그룹의 노드를 추가, 삭제 또는 수정하지만 현재 사용 중인 연결을 자동으로 바꾸지는 않습니다. 업데이트가 끝나면 현재 선택한 항목이 여전히 존재하는지 확인하고 필요하면 노드를 다시 선택해 재연결하세요. 목록에 변화가 없다면 먼저 대상 그룹을 업데이트했는지 확인한 다음 키워드 필터, 중복 제거 또는 정렬 규칙이 활성화되었는지 점검합니다. 이름이 같은 노드가 필터 결과에서 변화가 없어 보일 수 있지만 내부 매개변수는 실제로 업데이트되었을 수 있습니다.

업데이트에 실패하면 주소 형식, 네트워크 연결 가능 여부, 시스템 시간과 클라이언트 로그 순서로 확인하세요. 주소를 복사할 때 앞뒤 공백이나 줄바꿈이 들어가지 않도록 합니다. 브라우저에서 특정 페이지가 열린다고 해서 구독 API에도 연결할 수 있다는 뜻은 아닙니다. 시스템 시간 오차는 보안 연결에 영향을 줄 수 있으며 로그의 상태 코드나 파싱 메시지는 요청 실패와 지원되지 않는 콘텐츠 형식을 구분하는 데 도움이 됩니다. 같은 순간에 업데이트를 반복해서 클릭하지 마세요. 연속 요청은 형식 문제를 해결하지 못하고 로그만 읽기 어렵게 만듭니다.

구독 그룹 이름 예시:
업무 환경｜주 구독
모바일 기기｜자주 사용
프로토콜 테스트｜임시

필터 규칙 예시:
포함 키워드: VLESS|Trojan
제외 키워드: 유지 관리|만료|남은 기간

노드 선택은 프로토콜·위치·실제 작업을 함께 고려하기

노드 목록의 이름은 대개 설정 제공자가 붙인 메모일 뿐 안정성을 보장하지 않습니다. 지연 시간 테스트는 연결할 수 없거나 응답이 지나치게 느린 항목을 빠르게 제외하는 데 유용하지만 결과는 회선, 테스트 방식과 순간 상태의 영향을 받습니다. 노드를 선택할 때는 현재 코어가 해당 프로토콜을 지원하는지, 전송 매개변수가 완전한지, 실제 앱이 안정적으로 작동하는지, 연속 사용 중 재연결이 자주 발생하지 않는지를 함께 고려하세요. 한 번의 낮은 수치가 지속적인 접속 테스트를 대신할 수는 없습니다.

특정 노드를 사용할 수 없으면 먼저 같은 구독 그룹에서 다른 노드를 선택하세요. 다른 노드가 정상이라면 문제 범위는 대개 단일 설정이나 원격 상태에 있습니다. 그룹 전체가 실패하면 구독 만료 여부와 업데이트 내용 이상 여부를 확인하세요. 여러 출처가 동시에 실패한다면 로컬 네트워크, 시스템 프록시와 클라이언트 코어를 추가로 점검합니다. 순서 없이 DNS, 라우팅과 포트를 바꾸는 것보다 이런 비교가 더 효과적입니다.

여러 구독 그룹과 필터 전략

여러 구독을 동시에 관리할 때는 가져온 뒤 하나의 평면 목록에 섞지 말고 출처를 분리하세요. 그룹을 나누면 업데이트 범위가 명확해지고 출처별 필터 규칙도 독립적으로 설정할 수 있습니다. 노드 이름은 프로토콜이나 지역을 먼저 쓰고 원래 메모리를 뒤에 붙이는 식으로 통일할 수 있습니다. 필터 키워드는 단순하게 유지하고 한 번에 하나의 목표만 해결하세요. 예를 들어 관리 알림을 숨기거나 특정 프로토콜을 남기거나 필요 없는 용도를 제외하는 방식입니다. 규칙이 지나치게 길면 새 노드를 실수로 숨기기 쉽습니다.

필터 규칙을 수정한 뒤에는 먼저 필터링하지 않은 원본 항목 수와 이름을 확인하고 조건을 단계적으로 추가하세요. 정규식에서 세로줄은 ‘또는’, 괄호는 그룹화에 사용되며 점과 별표는 특수한 의미를 가집니다. 일반 단어만 찾는다면 명확한 키워드를 직접 사용하는 편이 안전합니다. 여러 구독 소스의 그룹, 메모와 필터링 방법은 여러 서비스 구독 그룹 관리 실전을 참고하세요. 구독 정리가 끝난 뒤 프록시 모드를 설정하면 목록 문제를 시스템 트래픽 제어 문제로 잘못 판단하는 일을 줄일 수 있습니다.

프록시 모드: 시스템 프록시, 규칙 모드와 전체 처리를 이해하기

시스템 프록시는 이를 지원하는 앱을 클라이언트로 연결합니다

데스크톱 환경의 시스템 프록시는 운영체제의 프록시 주소를 클라이언트가 수신 대기 중인 로컬 포트로 설정하는 기능입니다. 브라우저와 많은 데스크톱 앱은 이 설정을 읽고 HTTP 또는 SOCKS 요청을 클라이언트에 전달합니다. 클라이언트는 현재 노드와 라우팅 규칙에 따라 요청을 처리합니다. 시스템 프록시는 적용 범위가 명확하고 필요한 권한이 적어 최초 연결과 일상 사용의 기본 방식으로 적합하지만, 일부 앱은 자체 네트워크 스택이나 독립 프록시 설정을 사용하므로 자동으로 따라오지 않습니다.

시스템 프록시를 켜기 전에 클라이언트 코어가 이미 실행되어 해당 포트를 수신하고 있어야 합니다. 시스템 프록시가 가리키는 포트에 수신 프로그램이 없으면 시스템 설정을 따르는 모든 앱의 연결이 실패합니다. 점검할 때는 먼저 시스템 프록시를 끄고 로컬 네트워크가 복구되는지 확인한 다음 클라이언트를 시작하고 다시 켜세요. 로컬 포트를 임의로 바꾸지 마세요. 꼭 변경해야 한다면 클라이언트 인바운드 포트, 시스템 프록시 주소와 수동 프록시를 설정한 앱이 모두 일치하는지 확인해야 합니다.

규칙, 전체와 직접 연결은 각각 어떤 문제를 해결할까요

규칙 모드는 도메인, IP, 포트, 프로세스 또는 프로토콜 등의 조건에 따라 트래픽을 프록시, 직접 연결 또는 차단으로 보낼지 결정하는 방식으로, 일상 사용에서 가장 균형이 좋습니다. 전체 모드는 대개 제어할 수 있는 트래픽을 현재 프록시로 통일해 노드가 대상 요청을 처리할 수 있는지 짧게 확인하거나 라우팅 규칙의 오판을 배제할 때 유용합니다. 연결 품질이 더 높다는 뜻은 아닙니다. 직접 연결 모드는 원격 프록시를 우회해 일반 네트워크를 임시로 복구하거나 문제가 프록시 경로에서 발생했는지 비교하는 데 사용할 수 있습니다.

문제 해결 시 세 모드를 비교해 볼 수 있습니다. 전체 모드는 작동하지만 규칙 모드가 작동하지 않으면 라우팅 규칙 매칭을 먼저 확인하세요. 전체 모드도 작동하지 않으면 노드, 코어 또는 시스템 트래픽 제어 문제일 가능성이 높습니다. 시스템 프록시를 껐는데도 앱이 계속 프록시를 사용한다면 앱에 독립 프록시가 설정되어 있거나 다른 네트워크 도구가 실행 중일 수 있습니다. 모드를 바꿀 때마다 재연결하고 로그의 아웃바운드 태그를 확인해야 새 설정이 현재 세션에 적용되었는지 알 수 있습니다.

브라우저, 명령줄과 독립 프록시 앱

브라우저는 보통 시스템 프록시를 따르지만 확장 프로그램이나 기업 정책을 통해 독립 설정을 사용할 수도 있습니다. 브라우저를 점검할 때는 먼저 추가 프록시 확장 프로그램을 끄고 새 창에서 대상을 열어 다른 시스템 앱과 비교하세요. 명령줄 도구는 데스크톱 시스템 프록시를 반드시 읽는 것은 아니며 현재 터미널 세션에 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY를 설정해야 할 수 있습니다. 설정은 클라이언트가 실제로 수신 중인 로컬 주소와 포트만 가리켜야 하며 테스트가 끝나면 즉시 삭제해 클라이언트 종료 후 후속 명령이 실패하지 않도록 하세요.

# 현재 터미널 세션에 로컬 프록시를 임시 지정합니다. 포트는 클라이언트 설정과 일치해야 합니다
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

# 테스트가 끝나면 삭제
unset HTTP_PROXY
unset HTTPS_PROXY

일부 개발 도구, 다운로드 도구와 게임 플랫폼은 독립적인 네트워크 설정을 제공합니다. 먼저 해당 앱의 문서를 확인하세요. 시스템 프록시를 따르지 않는 앱 하나를 지원하기 위해 곧바로 TUN으로 전환하지 마세요. 먼저 수동 HTTP 또는 SOCKS 프록시를 지원하는지 확인하는 편이 제어하기 쉽습니다. 앱에서 프록시를 설정할 수 없고 UDP나 하위 프로세스까지 제어해야 할 때 TUN의 필요성을 검토하세요.

연결 상태와 실제 접속은 나누어 판단하기

클라이언트에 ‘연결됨’으로 표시되는 것은 보통 코어가 시작되었거나 로컬 VPN 인터페이스가 만들어졌다는 뜻이지, 모든 원격 요청이 성공했다는 의미는 아닙니다. 실제 접속에는 DNS 조회, 라우팅 매칭, 프로토콜 핸드셰이크와 대상 응답이 모두 필요합니다. ‘연결됨으로 표시되지만 접속할 수 없음’ 문제가 발생하면 로그에서 DNS 실패, 연결 시간 초과, 직접 연결로 라우팅되었는지 또는 원격 거부가 있는지 확인하세요. 로그의 대상과 아웃바운드 태그를 통해 트래픽이 예상 경로로 들어갔는지 판단할 수 있습니다.

안정적인 사용 습관을 만든 뒤에는 일상적으로 규칙 모드를 사용하고 전체 모드는 진단 도구로 남겨 두면 됩니다. 구독, 노드 또는 모드를 바꿀 때마다 한 가지 항목만 수정하고 재연결한 뒤 같은 테스트 대상으로 확인하세요. 이렇게 쌓은 결과는 비교할 수 있으며 다음 장에서 라우팅 규칙을 작성하는 기반이 됩니다.

라우팅 분할: 트래픽 유형별 출구를 명확한 규칙으로 제어하기

규칙은 매칭 조건, 대상과 순서로 구성됩니다

라우팅 분할의 핵심은 규칙을 쌓는 것이 아니라 두 가지 질문에 답하는 것입니다. 어떤 트래픽을 특별히 처리해야 하며 어느 출구로 보낼 것인가입니다. 일반적인 매칭 조건에는 전체 도메인, 도메인 접미사, IP 대역, 포트, 네트워크 유형과 프로세스 이름이 있으며 대상은 보통 프록시, 직접 연결 또는 차단입니다. 클라이언트는 화면의 규칙을 코어 설정으로 변환하고 정해진 순서대로 매칭합니다. 일반적으로 구체적인 규칙을 앞에 두고 범위가 넓은 기본 규칙을 뒤에 둡니다.

도메인 규칙은 DNS 조회 전후에 다르게 동작할 수 있습니다. 앱이 IP로 직접 접속하면 단순한 도메인 접미사 규칙은 매칭되지 않으며, 클라이언트가 원래 도메인을 얻지 못하면 조회된 IP로만 판단할 수 있습니다. 프로세스 규칙은 시스템 권한과 프로세스 식별 기능에 의존하고 데스크톱 플랫폼마다 지원 방식도 다를 수 있습니다. 따라서 규칙을 작성하기 전에 클라이언트 화면에서 어떤 조건을 제공하는지 확인하고 다른 도구의 문법을 그대로 붙여 넣지 마세요.

최소 규칙 세트부터 시작하기

관리하기 쉬운 규칙 세트는 보통 명확한 직접 연결 항목, 명확한 프록시 항목과 최종 기본 규칙으로 구성됩니다. 먼저 로컬 네트워크 주소는 직접 연결하고 특정 업무 도메인은 지정 출구로 보내는 등 확실한 조건을 작성한 뒤 나머지 트래픽의 기본 경로를 정하세요. 처음부터 출처가 불명확한 규칙을 대량으로 가져오지 마세요. 규칙이 겹칠 수 있고 업데이트 후 변경 사항을 추적하기도 어렵습니다. 규칙을 하나 추가할 때마다 무엇과 매칭되는지, 왜 필요한지, 왜 현재 위치에 두는지 알고 있어야 합니다.

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

위 구조는 일반적인 코어 라우팅 논리를 보여 줍니다. 사설 주소는 먼저 직접 연결하고 지정한 도메인은 프록시로 보내며 나머지 TCP와 UDP는 프록시 출구를 사용합니다. 실제 v2rayN 또는 모바일 클라이언트에서는 아웃바운드 태그가 화면에서 생성될 수 있으므로 이름을 임의로 가정하지 마세요. 설정 조각을 복사하기 전에 클라이언트가 전체 설정 직접 편집을 지원하는지 확인하세요. 그래픽 규칙 편집기를 사용한다면 전체 JSON을 하나의 입력란에 넣지 말고 조건을 각 필드에 나누어 입력해야 합니다.

도메인 전략과 DNS의 연동 이해하기

AsIs는 원래 도메인을 우선 매칭하고 라우팅 판단을 위해 IP를 추가로 조회하지 않는다는 뜻입니다. 다른 전략에서는 도메인 규칙이 매칭되지 않을 때 계속 조회해 IP 규칙을 시도할 수 있습니다. 전략이 적극적일수록 DNS 조회가 늘어날 수 있고 DNS 설정에 더 크게 의존합니다. 주로 도메인 접미사로 분할한다면 도메인 처리 로직을 단순하게 유지하는 편이 문제 해결에 쉽습니다. IP 대역으로 처리해야 한다면 조회 결과, DNS 출구와 IP 규칙이 일치하는지 확인해야 합니다.

DNS와 라우팅은 서로 영향을 줍니다. DNS 조회 자체도 트래픽이므로 어느 서버가 조회하고 어느 출구로 전송할지 정해야 하며, 조회 결과는 이후 IP 규칙에도 사용됩니다. 흔한 이상 현상으로는 현재 회선에 적합하지 않은 주소로 도메인이 조회되거나, 잘못된 출구로 조회가 전송되거나, 캐시에 이전 결과가 남아 있는 경우가 있습니다. 문제를 해결할 때는 먼저 특정 도메인의 조회 결과를 관찰한 뒤 해당 조회와 실제 연결이 각각 어떤 규칙에 매칭되었는지 확인하세요. 여러 DNS, 도메인 전략과 라우팅 세트를 동시에 바꾸면 어느 변경이 적용되었는지 확인하기 어렵습니다.

규칙 매칭 테스트와 충돌 원인 찾기

규칙을 검증할 때는 특징이 분명한 대상을 선택하고 로그의 도메인, 대상 IP와 아웃바운드 태그를 확인하세요. 구체적인 규칙이 매칭되지 않으면 더 넓은 규칙 뒤에 배치되었는지, 도메인 형식이 올바른지, 앱이 IP를 직접 사용하는지, 기존 연결을 재사용하는지 점검합니다. 브라우저는 장시간 연결을 유지할 수 있어 규칙을 바꾼 뒤 페이지 새로 고침만으로는 모든 요청이 다시 만들어지지 않을 수 있습니다. 필요하면 관련 탭을 닫거나 앱을 재시작한 뒤 테스트하세요.

프로세스 분할에서는 하위 프로세스도 고려해야 합니다. 브라우저의 주 프로그램과 네트워크 서비스 프로세스의 이름이 다를 수 있고 런처와 실제 프로그램이 분리되어 있을 수도 있습니다. 모바일 앱별 프록시는 앱 패키지를 기준으로 선택하는 방식이 더 적합합니다. 규칙 결과는 클라이언트의 ‘선택한 앱 우회’ 또는 ‘선택한 앱만 프록시’ 의미에 따라 달라지므로 전환하기 전에 옵션 설명을 정확히 읽어야 합니다. Android 권한, 절전 예외 목록과 앱별 프록시는 v2rayNG Android 사용 핵심에서 확인할 수 있습니다.

규칙을 읽기 쉽고 되돌릴 수 있게 유지하기

각 규칙 그룹의 용도를 명확히 적고 큰 변경 전에는 백업을 내보내세요. 규칙 이름은 ‘로컬 네트워크 직접 연결’, ‘업무 도메인 프록시’, ‘특정 앱 직접 연결’처럼 용도를 바로 설명하는 방식이 추상적인 번호보다 관리하기 쉽습니다. 규칙을 삭제하기 전에는 먼저 비활성화하고 일정 기간 관찰한 뒤 의존성이 없는지 확인하세요. 외부에서 업데이트되는 구독 규칙 세트는 개인 규칙과 분리해 저장하여 업데이트가 수동 조정을 덮어쓰지 않도록 합니다.

성숙한 라우팅 구성은 규칙 수가 가장 많은 구성이 아니라 매번 어떤 규칙에 매칭되었는지 안정적으로 설명할 수 있는 구성입니다. 주요 사용 목적을 먼저 충족한 뒤 소수의 예외를 처리하세요. 예외가 계속 늘어나면 기본 출구가 적절한지 다시 검토해야 합니다. 라우팅 기초를 마친 뒤에도 시스템 프록시를 따르지 않는 앱, UDP 트래픽 또는 복잡한 하위 프로세스를 제어해야 할 때 TUN 모드로 넘어가세요.

TUN 모드: 트래픽 제어 범위를 넓히고 복잡도 관리하기

TUN은 왜 더 많은 앱을 포함할까요

TUN 모드는 가상 네트워크 인터페이스로 시스템 트래픽을 받은 뒤 클라이언트 코어에 라우팅 판단을 맡깁니다. 각 앱이 HTTP 또는 SOCKS 프록시를 직접 지원할 필요가 없으므로 시스템 프록시를 무시하는 프로그램, 일부 UDP 트래픽과 여러 프로세스로 구성된 앱까지 포함할 수 있습니다. Android 클라이언트가 만드는 시스템 VPN 연결도 비슷한 방식으로 트래픽을 제어합니다. 적용 범위가 넓어지면 시스템 라우팅, DNS, 권한과 제외 항목이 모두 관여하므로 기본 노드와 규칙 모드가 정상임을 확인한 뒤 TUN을 활성화하는 것이 좋습니다.

TUN을 사용한다고 모든 트래픽이 원격 프록시로 가야 하는 것은 아닙니다. 트래픽이 가상 인터페이스로 들어온 뒤에도 라우팅 규칙에 따라 프록시, 직접 연결 또는 차단을 선택합니다. 로컬 네트워크 접속, 프린터 서비스나 개발 환경을 직접 연결로 유지해야 한다면 활성화 전에 사설 주소와 관련 도메인 규칙을 확인하세요. 기본 라우팅이 잘못되면 로컬 기기에 접근할 수 없고 DNS 설정이 잘못되면 ‘IP로는 접속되지만 도메인으로는 접속되지 않음’ 현상이 나타날 수 있습니다.

활성화 전 점검 목록

먼저 가상 인터페이스를 만들거나 라우팅 테이블을 수정할 수 있는 다른 네트워크 도구를 종료한 뒤 v2rayN의 일반 시스템 프록시 연결이 작동하는지 확인하세요. 현재 노드가 필요한 네트워크 유형을 지원하는지 점검하고 기존 DNS 설정과 라우팅 모드를 기록한 다음 TUN을 활성화합니다. 데스크톱 시스템은 관리자 권한이나 필요한 구성 요소 설치를 요구할 수 있으므로 클라이언트의 안내에 따라 완료하세요. 권한이 거부되면 스위치를 반복해서 전환해도 해결되지 않으며 시스템 권한 설정으로 돌아가야 합니다.

활성화 후에는 세 가지 계층을 테스트하세요. 일반 도메인 접속, 직접 IP 접속, 로컬 네트워크 리소스 접속입니다. 일반 도메인만 실패하고 IP는 성공하면 DNS를 먼저 확인합니다. 둘 다 실패하면 가상 인터페이스, 기본 라우팅과 코어 로그를 점검하세요. 외부 접속은 정상인데 로컬 네트워크만 실패하면 사설 대역 직접 연결 규칙을 확인합니다. 테스트 대상은 고정하고 항목 하나를 조정할 때마다 재연결해 캐시와 이전 세션이 결론에 영향을 주지 않도록 하세요.

DNS, 엄격한 라우팅과 루프백 문제

TUN은 DNS도 제어해야 하는 경우가 많으므로 도메인 조회와 이후 연결이 일관된 라우팅 전략을 사용하는지 확인해야 합니다. DNS 서버를 많이 설정한다고 신뢰성이 자동으로 높아지는 것은 아니며 오히려 결과가 달라질 수 있습니다. 시작할 때는 클라이언트가 권장하는 단순한 방식을 사용하고 조회가 코어로 들어가는지 확인한 뒤 실제 필요에 따라 직접 연결과 프록시 조회를 나누세요. 조회 루프가 발생하면 DNS 요청이 다시 같은 로컬 수신 포트로 전송되고 있는지 확인해야 합니다.

엄격한 라우팅은 트래픽이 가상 인터페이스를 우회할 가능성을 줄이지만 가상 머신, 컨테이너, 로컬 네트워크 공유와 사용자 지정 네트워크 카드에 영향을 줄 수 있습니다. 활성화하기 전에 시스템의 기존 대역과 인터페이스를 기록하세요. 특히 개발 환경에서 사용하는 사설 주소를 확인해야 합니다. 컨테이너 접속이 갑자기 실패하면 노드 프로토콜을 먼저 바꾸지 말고 TUN 전후의 라우팅 테이블을 비교한 뒤 필요한 대역을 명확히 처리하세요. 규칙은 좁고 정확하게 작성해 지나치게 넓은 대역이 정상 시스템 라우팅을 덮지 않도록 해야 합니다.

Android 연결 권한과 앱별 프록시

v2rayNG 또는 v2flyNG로 처음 연결할 때 시스템 VPN 권한을 요청합니다. 시스템은 보통 동시에 하나의 활성 VPN 세션만 허용하므로 클라이언트를 바꾸기 전에 현재 연결을 중지해야 합니다. 앱별 프록시는 서로 반대되는 두 가지 논리를 가집니다. 선택한 앱만 프록시에 넣거나 선택한 앱을 프록시에서 제외하는 방식입니다. 설정할 때 화면 설명을 먼저 확인하고 검증하기 쉬운 앱 하나로 테스트하세요. 처음부터 많은 앱을 선택하지 마세요.

화면을 잠근 뒤 연결이 자주 끊긴다면 시스템 절전 정책, 백그라운드 제한 또는 제조사 작업 관리가 원인인 경우가 많습니다. 클라이언트를 절전 예외 목록에 추가하고 백그라운드 실행을 허용하며 지속 알림을 유지하면 VPN 서비스를 계속 유지하는 데 도움이 됩니다. 로그 수준을 장기간 상세 디버그로 유지하지 마세요. 기록과 처리 비용이 늘어날 수 있습니다. 모바일 배터리와 백그라운드 실행에 대한 자세한 점검 방법은 v2rayNG 배터리 소모 및 백그라운드 실행 점검에서 확인할 수 있습니다.

언제 시스템 프록시로 돌아가야 할까요

주요 요구 사항이 브라우저와 일부 프록시 지원 데스크톱 앱뿐이라면 시스템 프록시가 보통 더 간단합니다. TUN은 명확한 문제를 해결하기 위해 사용해야 하며 기본 복잡도로 삼을 필요는 없습니다. 활성화한 뒤 로컬 네트워크, 컨테이너 또는 DNS 충돌이 계속되면 먼저 시스템 프록시로 돌아가 일상 작업을 복구한 다음 제어가 필요한 앱을 따로 분석하세요. 검증된 일반 프록시 설정 하나를 유지하는 것은 TUN 장애를 처리할 때 중요한 대안입니다.

TUN을 끌 때는 클라이언트의 스위치를 통해 정상적으로 중지하여 가상 인터페이스와 라우팅이 정리되도록 한 뒤 시스템 네트워크가 복구되었는지 확인하세요. 프로세스를 강제 종료한 뒤 네트워크에 문제가 생기면 클라이언트를 다시 시작해 정상 종료하거나 시스템 네트워크 설정에서 남은 인터페이스를 확인합니다. 이 기본 작업을 마치면 다음 장에서 업데이트, 백업, 로그와 문제 진단을 반복 가능한 관리 절차로 정리합니다.

일상 관리: 업데이트, 백업, 로그와 안정성 점검

업데이트를 클라이언트·구독·규칙 세 가지로 나누기

일상적인 업데이트는 하나의 작업이 아닙니다. 클라이언트 업데이트는 화면, 코어 또는 기능 동작을 바꾸고, 구독 업데이트는 노드 매개변수를 새로 고치며, 규칙 업데이트는 트래픽 출구를 바꿀 수 있습니다. 세 가지 업데이트는 나누어 실행하고 각 업데이트 후 기본 검증을 완료하는 것이 좋습니다. 같은 날 클라이언트를 바꾸고 구독을 새로 고치며 새 규칙을 가져오면 이상이 발생했을 때 원인을 찾기 어렵습니다. 안정적인 환경에서는 먼저 설정을 백업하고 클라이언트를 업데이트한 뒤 시작과 기존 설정이 정상인지 확인하고, 그 다음 구독을 새로 고치며 마지막으로 규칙을 처리하세요.

클라이언트 업데이트 전에는 실행 중인 코어를 종료하고 현재 설치 유형과 아키텍처를 기록하세요. 이전 프로그램이 실행 중인 상태에서 파일을 덮어쓰지 마세요. 업데이트 후에는 구독 그룹, 라우팅 모드, 로컬 포트와 TUN 설정이 유지되는지 확인한 뒤 이미 사용 가능하다고 확인한 노드 하나를 시작합니다. 구독을 업데이트할 때는 항목 수, 현재 선택과 필터 규칙을 확인하세요. 규칙 업데이트 후에는 재연결하고 로그를 통해 주요 대상이 여전히 예상 출구를 사용하는지 확인합니다.

백업의 핵심은 파일 수가 아니라 복구 가능성입니다

가치 있는 백업에는 최소한 구독 그룹, 수동 노드, 사용자 지정 라우팅, DNS 기본 설정과 중요한 클라이언트 설정이 포함되어야 합니다. 백업할 때는 클라이언트를 완전히 종료해 아직 작성 중인 설정 파일을 복사하지 않도록 하세요. 백업 디렉터리는 날짜와 클라이언트 이름으로 구분할 수 있지만 구독 자격 증명이 포함된 파일을 공개 위치에 업로드하지 마세요. 복원할 때는 동일한 클라이언트 계열에서 먼저 테스트한 뒤 다른 버전이나 클라이언트로 이전하는 것을 검토하세요.

시스템 플랫폼, 프로세서 아키텍처, 클라이언트 이름, 프록시 모드, 사용자 지정 로컬 포트와 TUN 활성화 여부처럼 간단한 환경 기록도 함께 보관하는 것이 좋습니다. 노드 자격 증명은 포함할 필요가 없지만 재설치 후 작업 방식을 빠르게 복원하는 데 도움이 됩니다. 복잡한 라우팅 규칙에는 용도 설명을 덧붙여 몇 달 뒤에도 조건을 이해할 수 있도록 하세요. 복구 가능한 설정은 ‘빈 환경에서 시작해 안정적인 상태로 돌아가는 데 최소한 어떤 단계가 필요한가’라는 질문에 답할 수 있어야 합니다.

오류 단어만 찾지 말고 로그에서 단계를 확인하기

로그를 점검할 때는 시간 순서를 먼저 보세요. 클라이언트가 설정을 읽은 시점, 코어가 시작된 시점, 로컬 포트가 수신을 시작한 시점, DNS 조회, 라우팅 매칭, 원격 연결과 앱 요청이 각각 어디에서 발생했는지 확인합니다. error라는 단어 하나는 단순한 재시도일 수 있으며 같은 오류가 연속해서 반복되는지가 어느 단계에서 막혔는지를 더 잘 보여 줍니다. 문제가 발생한 정확한 시간을 기록하고 앞뒤 관련 행만 추출하는 편이 전체 로그를 복사하는 것보다 분석하기 쉽고 구독 주소 같은 민감한 정보의 노출도 줄일 수 있습니다.

문제 해결 기록 템플릿
1. 플랫폼과 클라이언트: Windows / v2rayN
2. 트래픽 제어 방식: 시스템 프록시 또는 TUN
3. 영향 범위: 모든 앱, 특정 앱 또는 특정 도메인
4. 최근 변경 사항: 클라이언트, 구독, 규칙, DNS
5. 비교 결과: 직접 연결, 규칙, 전체 모드에서 각각 어떻게 작동하는가
6. 로그 단계: 시작, 조회, 라우팅, 핸드셰이크 또는 시간 초과

클라이언트가 시작되지 않으면 실행 환경, 디렉터리 권한, 설정 손상과 포트 사용 여부를 먼저 확인하세요. 구독을 업데이트할 수 없으면 주소와 요청 오류를 점검합니다. 코어가 시작된 뒤 모든 노드가 실패하면 시스템 시간, 네트워크와 프로토콜 호환성을 확인하세요. 규칙 모드만 실패하면 규칙 순서를 확인하고, TUN만 실패하면 권한, DNS와 시스템 라우팅을 점검합니다. 단계를 기준으로 분류하면 대부분의 문제를 한두 개 모듈로 좁힐 수 있습니다.

포트 사용, 남은 프록시와 백그라운드 제한 처리

포트 사용은 클라이언트 비정상 종료, 중복 실행 또는 여러 도구의 동시 실행 중에 자주 발생합니다. 먼저 관련 클라이언트를 모두 정상적으로 종료한 뒤 남은 프로세스를 확인하세요. 로컬 포트를 변경하면 시스템 프록시와 수동으로 프록시를 지정한 앱도 함께 업데이트해야 합니다. 시스템 프록시가 남아 있으면 클라이언트를 종료한 뒤 브라우저에 접속할 수 없게 됩니다. 이때는 구독을 삭제하거나 시스템을 재설치할 필요 없이 먼저 운영체제의 프록시 설정을 복원한 다음 클라이언트를 다시 시작하세요.

Android에서 백그라운드 중단이 발생하면 절전 최적화, 백그라운드 활동 제한, 자동 시작 권한과 지속 알림을 확인하세요. 기기마다 설정 위치는 다르지만 판단 방법은 같습니다. 전면에서는 안정적이고 화면을 잠근 뒤 중단되면 대개 백그라운드 관리 문제입니다. 전면에서도 연결되지 않으면 설정과 VPN 권한을 먼저 확인하세요. 서비스를 유지하려고 로그 수준을 무한히 높이지 마세요. 로그는 관찰을 위한 것일 뿐 시스템 스케줄링을 바꾸지 않습니다.

주기적인 가벼운 점검 체계 만들기

일상 관리에서는 자주 설정을 바꿀 필요가 없습니다. 정기적으로 구독을 업데이트하고 명확히 만료된 임시 설정을 삭제하며 필터 규칙이 새 노드를 잘못 숨기지 않는지 확인하고 클라이언트 설정이 현재 요구에 맞는지 점검하세요. 라우팅 규칙은 업무가 바뀔 때만 조정하고 TUN은 적용 범위가 실제로 필요할 때만 켜세요. 새로운 옵션을 계속 쫓기보다 장기적인 안정성이 중요합니다.

이상이 발생하면 최근에 무엇이 바뀌었는지 먼저 떠올린 뒤 ‘고급 기능 해제—기본 노드 복원—시스템 프록시 검증—설정을 하나씩 다시 추가’ 순서로 진행하세요. 재설치가 필요하더라도 먼저 설정을 백업하고 이전 프로세스가 종료되었는지 확인해야 합니다. 시작 충돌, 권한과 남은 프로세스 처리 방법은 실행 라이브러리 및 권한 문제 점검에서 더 확인할 수 있습니다. 다음 장에서는 이러한 기본 능력을 프로토콜, 코어와 설정 읽기로 확장합니다.

고급 활용: 클라이언트 사용에서 설정을 읽는 단계로

1단계: 완전한 노드 하나 이해하기

고급 학습을 전체 설정 작성부터 시작할 필요는 없습니다. 이미 작동하는 노드 하나를 선택하고 클라이언트 화면과 대조하며 주소, 포트, 사용자 식별자, 프로토콜, 전송 방식, 보안 계층, 도메인과 핑거프린트 등의 필드를 하나씩 이해하세요. 모든 옵션을 외우는 것보다 어떤 매개변수가 서버와 일치해야 하고 어떤 항목이 로컬 기본 설정인지 아는 것이 중요합니다. 작동하는 설정을 테스트 항목으로 복사하고 핵심이 아닌 필드 하나만 바꿔 로그를 관찰하면 필드와 동작 사이의 관계를 파악할 수 있습니다.

프로토콜 계층과 전송 계층은 나누어 학습해야 합니다. VLESS, VMess, Trojan은 신원과 프로토콜 상호작용을 설명하고 TCP, WebSocket, gRPC는 데이터 전송 방식을 설명하며 TLS 또는 REALITY는 해당 보안 및 핸드셰이크 요구 사항을 처리합니다. 이름이 비슷하다고 매개변수를 서로 바꿀 수 있는 것은 아닙니다. 설정을 읽을 때는 바깥쪽부터 안쪽으로 나누세요. 먼저 서버 주소와 포트를 확인하고 프로토콜 신원을 확인한 다음 전송 방식을 보고 마지막으로 보안 계층과 도메인을 점검합니다. 이 순서는 연결 실패를 수동으로 확인할 때도 적용할 수 있습니다.

2단계: Xray와 V2Fly 생태계의 관계 이해하기

Xray와 V2Fly는 모두 Project V 기술 생태계에서 발전한 분기에 속하며 클라이언트는 용도에 따라 적절한 코어를 통합합니다. v2rayN은 데스크톱 종합 관리에 자주 사용되고, v2rayNG는 Xray 코어를 주요 기반으로 하며 v2flyNG는 V2Fly 코어 방향의 Android 선택지를 제공합니다. 코어가 다르면 프로토콜 지원, 설정 필드와 업데이트 주기가 달라질 수 있으므로 구독 설정이 특정 기능에 명확히 의존한다면 그에 맞는 클라이언트와 코어를 사용해야 합니다.

코어 차이를 학습할 때 ‘지원 목록’을 절대적인 우열로 단순화하지 마세요. 더 유용한 질문은 현재 설정이 어떤 프로토콜과 전송 필드를 사용하는지, 통합된 코어가 이를 인식할 수 있는지, 업그레이드 후 동작이 바뀌었는지, 로그에 알 수 없는 필드가 표시되는지입니다. 두 코어 계열의 발전과 클라이언트 선택은 Xray와 V2Fly 코어 차이 상세 설명에서 확인할 수 있습니다.

3단계: 그래픽 규칙에서 구조화된 설정으로 넘어가기

클라이언트 라우팅 편집기에 익숙해지면 코어 설정의 기본 구조를 읽기 시작할 수 있습니다. 일반적인 설정은 로그, DNS, 인바운드, 아웃바운드와 라우팅으로 구성됩니다. 인바운드는 시스템 프록시 또는 TUN에서 들어오는 트래픽을 받고, 아웃바운드는 프록시와 직접 연결 등의 출구를 정의하며, 라우팅은 매칭 조건을 아웃바운드에 연결합니다. 읽을 때는 먼저 태그 간 참조 관계를 찾은 다음 각 객체의 구체적인 매개변수를 확인하세요. 태그 철자가 일치하지 않으면 규칙이 존재하지 않는 출구를 가리키게 되며 수동 편집에서 흔히 발생하는 문제입니다.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

이 예시는 로컬 SOCKS 인바운드, 직접 연결 아웃바운드와 사설 주소 규칙만 보여 주며 원격 서버 자격 증명은 포함하지 않습니다. 실제 클라이언트는 보통 인바운드와 주요 아웃바운드를 자동으로 생성하므로 수동 설정 전에 현재 결과를 내보내 읽어 보세요. 현재 사용 중인 설정을 직접 교체하지 마세요. 변경할 때마다 먼저 JSON 구조가 완전한지 확인한 뒤 클라이언트 로그에서 코어가 해당 필드를 받아들였는지 확인해야 합니다.

4단계: 반복 가능한 실험 방법 만들기

고급 설정에서는 ‘많이 바꿨지만 어떤 항목이 효과가 있었는지 모르는’ 상황에 빠지기 쉽습니다. 실험용 독립 구독 그룹이나 테스트 설정을 만들고 안정적인 기준선을 보존하며 매번 변경 사항, 예상 결과와 실제 로그를 기록하세요. 라우팅을 테스트할 때는 노드를 고정하고, 노드를 테스트할 때는 라우팅을 고정하며, DNS를 테스트할 때는 대상 도메인을 고정합니다. 변수를 적게 통제할수록 결론은 더 신뢰할 수 있습니다. 이상이 발생하면 새 매개변수를 계속 추가하지 말고 마지막 변경부터 되돌리세요.

로그 수준은 단기 테스트에서 높일 수 있지만 원인 파악이 끝나면 일반 수준으로 되돌리세요. 상세 로그는 더 많은 정보를 생성하고 접속 대상과 설정 조각을 포함할 수 있으므로 공유하기 전에 구독 주소, 사용자 식별자와 기타 접근 자격 증명을 삭제해야 합니다. 명령줄 테스트에서는 로컬 루프백 주소와 클라이언트가 실제 사용하는 포트만 사용하고 임시 자격 증명을 장기 스크립트에 직접 기록하지 마세요.

5단계: 나만의 관리 문서 만들기

설정에 여러 구독, 라우팅 그룹, TUN과 앱별 규칙이 포함된다면 환경에 대한 간단한 설명을 작성하세요. 클라이언트 선택 이유, 구독 그룹 용도, 기본 프록시 모드, 주요 라우팅, DNS 방식, 백업 위치와 복원 순서를 포함하면 됩니다. 민감한 매개변수를 기록할 필요는 없지만 재설치나 업그레이드 후 사용자가 복원 방법을 알 수 있어야 합니다. 큰 변경을 할 때마다 설명도 함께 업데이트하는 편이 기억에 의존하는 것보다 안정적입니다.

초보자부터 고급 사용자까지 익힌다는 것은 모든 옵션을 켜는 것이 아니라 현재 설정이 왜 이렇게 작동하는지 설명하고 문제가 생겼을 때 어느 계층부터 확인할지 아는 것입니다. 장기적으로는 안정적인 클라이언트를 유지하고, 구독 그룹과 시스템 프록시를 익히며, 최소 라우팅 세트를 작성한 뒤 명확한 요구가 있을 때 TUN을 활성화하고 마지막으로 구조화된 설정과 코어 로그를 읽는 순서를 권장합니다. 아직 첫 연결을 완료하지 않았다면 빠른 시작으로 돌아가 기본 절차를 진행하세요. 플랫폼이나 아키텍처를 바꿔야 한다면 설치 패키지 페이지에서 해당 클라이언트를 선택하세요.