V2Ray 전체 플랫폼 설치·설정 가이드

01 · PREPARE

읽는 방법과 공통 준비

빠른 튜토리얼과 이 매뉴얼의 활용법

빠르게 한 번 연결하는 것이 목적이라면 먼저 빠른 시작 튜토리얼을 읽어 보세요. 튜토리얼은 “클라이언트 다운로드, 구독 가져오기, 노드 선택, 프록시 켜기” 순서로 구성되어 처음 사용할 때 화면을 따라 진행하기 좋습니다. 이 매뉴얼은 장기 사용과 문제 확인을 위한 문서입니다. 버튼 위치뿐 아니라 시스템 프록시와 TUN의 적용 범위, 구독 업데이트가 실패하는 이유, 데스크톱과 모바일에서 백그라운드 설정이 다른 이유, 로그의 실패 메시지를 점검 작업으로 바꾸는 방법까지 설명합니다. 플랫폼 권한, 라우팅 충돌 또는 노드 매개변수 불일치가 발생하면 위 목차에서 해당 장으로 바로 이동할 수 있습니다.

이 문서에서는 세 가지 클라이언트만 다룹니다. 데스크톱에서는 Windows, macOS, Linux를 지원하고 구독 관리 방식이 비슷한 v2rayN을 우선 사용합니다. Android에서는 Xray 코어를 사용하는 v2rayNG를 기본으로 선택하고, V2Fly 코어가 필요할 때는 v2flyNG를 사용할 수 있습니다. 클라이언트는 그래픽 인터페이스, 설정 구성과 시스템 네트워크 연동을 담당하며, 실제 프로토콜과 라우팅 규칙을 실행하는 것은 코어입니다. 이 역할을 이해하면 문제 해결 시 원인이 구독, 클라이언트 권한, 코어 설정 또는 로컬 네트워크 중 어디에 있는지 먼저 판단할 수 있어 무작정 삭제하고 재설치하는 일을 줄일 수 있습니다.

시작 전 준비할 네 가지 정보

첫째는 사용할 수 있는 구독 주소 또는 단일 노드 공유 내용입니다. 구독 주소는 보통 서비스 제공자가 생성하며, 클라이언트는 그 안의 노드와 그룹을 읽을 뿐 구독 유효 기간을 복구할 수는 없습니다. 복사할 때는 전체 링크를 유지하고 메신저가 덧붙인 마침표, 공백 또는 줄바꿈이 섞이지 않게 하세요. 둘째는 정확한 시스템 시간입니다. TLS 핸드셰이크와 인증서 검증은 시간에 의존하므로 날짜, 시간대 또는 분 단위 오차가 크면 모든 노드가 동시에 실패할 수 있습니다. 운영체제의 자동 시간과 자동 시간대를 켜고 설정 전에 한 번 동기화하는 것이 좋습니다.

셋째는 기기 아키텍처를 확인하는 것입니다. Windows의 일반적인 기기는 x64를 사용하고, macOS는 Apple Silicon과 Intel을 구분해야 합니다. 최근 Android 스마트폰은 대개 arm64를 선택하며 확인하기 어렵다면 범용 버전을 사용할 수 있습니다. Linux는 x64·arm64 외에도 배포판에 맞춰 deb 또는 rpm을 선택해야 합니다. 넷째는 바로 인터넷에 연결할 수 있는 대체 수단을 확보하는 것입니다. 처음부터 시스템 프록시, TUN과 복잡한 라우팅 규칙을 동시에 켜지 말고 구독을 가져오고 노드를 선택한 뒤 기본 연결을 확인하세요. 이후 기능을 하나씩 추가하면 문제가 생겼을 때 네트워크 동작을 바꾼 단계가 무엇인지 알 수 있습니다.

복구 가능한 기준 상태부터 만들기

설정 전에 현재 시스템 프록시 상태, 클라이언트에 저장된 구독 이름과 사용 중인 라우팅 모드를 기록하세요. 데스크톱에서는 시스템 프록시나 가상 네트워크 카드 라우팅을 변경하는 다른 프로그램을 먼저 완전히 종료하고, 모바일에서는 현재 활성화된 VPN 연결이 있는지 확인합니다. 여러 도구가 동시에 시스템 프록시나 기본 라우팅을 인계하면 요청이 로컬로 되돌아가거나 DNS 해석 경로가 꼬이고, 화면에는 연결됨으로 표시되지만 앱이 접속하지 못할 수 있습니다. 기본 연결을 확인한 뒤 실제로 필요한 프로그램만 하나씩 다시 실행하세요.

구독과 노드에는 보통 서버 주소, 포트, 사용자 식별자, 프로토콜, 전송 방식, TLS와 서버 이름 등의 필드가 포함됩니다. 이 값은 서버 측 설정과 일치해야 하므로 이름만 보고 추측하거나 “더 빠른” 옵션으로 임의 변경해서는 안 됩니다. VMess, VLESS, Trojan과 REALITY는 서로 다른 설정 조합이며 모든 회선에 공통으로 가장 좋은 프로토콜은 없습니다. 사용자는 원본에서 제공한 설정을 그대로 가져오고, 로컬 클라이언트의 프록시 모드, 라우팅 규칙, 로그 레벨과 구독 업데이트 주기만 조정하는 것이 가장 안전합니다.

다운로드와 권한의 기본 원칙

클라이언트 입구는 다운로드 센터에 모아 두었습니다. 다운로드 페이지에는 플랫폼별 설치 형식과 아키텍처 선택 방법이 정리되어 있습니다. 클라이언트 업데이트에 따라 화면 세부 사항은 달라질 수 있으므로 이 매뉴얼에서는 특정 버전을 고정하지 않지만, 핵심 순서는 동일합니다. 설치 또는 압축 해제, 클라이언트 실행, 구독 그룹 생성, 구독 업데이트, 노드 선택, 코어 시작, 시스템 연동 활성화 순서입니다. 시스템에서 네트워크 확장, 방화벽 또는 VPN 연결 권한을 요청하면 권한 대상과 용도를 먼저 확인하세요. 필요한 권한을 거부했다면 연결 버튼을 계속 누르지 말고 시스템 설정에서 다시 허용해야 합니다.

02 · WINDOWS

Windows: v2rayN 설치와 시스템 프록시

데스크톱 버전과 클래식 WPF 버전 선택

Windows에서는 v2rayN을 우선 권장합니다. 다운로드 페이지에는 데스크톱 버전과 클래식 WPF 버전이 있습니다. 데스크톱 버전은 차세대 크로스 플랫폼 인터페이스를 사용해 여러 데스크톱 시스템에서 비슷한 조작 방식을 원하는 사용자에게 적합합니다. WPF 버전은 Windows에서 오랫동안 사용된 클래식 인터페이스로, 메뉴 위치가 기존 튜토리얼과 더 비슷합니다. 두 버전 모두 구독 관리, 노드 전환, 시스템 프록시, 라우팅과 로그 확인을 지원합니다. 하나만 선택하세요. 두 버전을 동시에 실행하면 시스템 프록시 설정과 로컬 수신 포트를 서로 차지하려 할 수 있습니다.

설치 형식을 다운로드한 뒤 실행 중인 기존 클라이언트를 먼저 종료하세요. 설치 프로그램을 사용한다면 시스템 안내에 따라 설치하고, 압축 해제 버전이라면 일반 사용자가 읽고 쓸 수 있는 폴더에 전체 압축을 풀어 실행하세요. 압축 파일 미리보기 창에서 바로 실행하면 안 됩니다. 폴더 경로는 간단하게 유지하고 잦은 동기화·정리 또는 실행 권한 제한이 적용되는 위치는 피하세요. 처음 실행할 때 Windows 방화벽이 네트워크 통신 허용 여부를 물을 수 있습니다. 신뢰할 수 있는 네트워크에서 필요한 범위로만 허용하고, 일반적인 단일 PC 사용에는 공용 네트워크의 인바운드 접근을 열 필요가 없습니다.

구독 그룹 생성 및 업데이트

구독 그룹 또는 구독 설정으로 이동해 그룹 이름을 추가하고 전체 구독 주소를 주소 입력란에 붙여 넣으세요. 그룹 이름은 로컬에서 구분하기 위한 것이므로 용도에 맞게 정할 수 있으며 원격 구독에는 영향을 주지 않습니다. 저장한 뒤 “현재 구독 업데이트” 또는 이에 해당하는 업데이트 명령을 실행합니다. 정상이라면 노드 목록에 새 항목이 나타납니다. 목록이 바뀌지 않으면 상태 표시줄과 로그를 먼저 확인하고 버튼을 연속해서 누르지 마세요. HTTP 상태 코드, 인증서 오류 또는 시간 초과 정보가 화면의 짧은 안내보다 문제를 더 정확히 보여 주는 경우가 많습니다.

업데이트가 완료되면 노드 하나를 선택해 활성 서버로 지정한 뒤 서비스를 시작하세요. 처음부터 모든 노드를 속도 측정할 필요는 없습니다. 일괄 측정은 많은 연결을 동시에 만들 수 있고 로컬 방화벽, 네트워크 변동과 대상 사이트 응답의 영향을 받습니다. 설정이 완전한 노드 하나를 먼저 선택하고 시스템 프록시를 켠 다음 브라우저로 서로 다른 사이트 두 곳에 접속해 보세요. 기본 연결이 확인된 뒤 지연 시간을 측정하거나 하나씩 전환하는 편이 안정적입니다. 지연 시간은 측정 시점의 일부 경로 상태만 보여 줄 뿐 지속적인 처리량을 의미하지 않습니다.

시스템 프록시 모드 선택 방법

v2rayN이 코어를 시작하면 보통 로컬에서 HTTP, SOCKS 등의 포트를 수신하지만, 포트가 열려 있다는 사실만으로 모든 프로그램이 자동으로 사용하는 것은 아닙니다. “시스템 프록시 자동 구성”을 켜면 시스템 프록시 설정을 따르는 브라우저와 데스크톱 프로그램이 요청을 클라이언트로 전달합니다. 시스템 프록시를 지워도 코어는 계속 실행될 수 있지만 시스템 앱은 더 이상 자동으로 전달되지 않습니다. 문제를 해결할 때는 “코어가 실행 중”인 상태와 “시스템 프록시가 인계된” 상태를 구분해야 하며, 트레이 아이콘만 보고 모든 프로그램에 프록시가 적용됐다고 판단해서는 안 됩니다.

일부 프로그램은 자체 프록시 설정을 사용하므로 Windows 시스템 프록시를 무시합니다. 이 경우 프로그램 안에 v2rayN이 표시한 로컬 HTTP 또는 SOCKS 주소를 입력할 수 있습니다. 호스트는 보통 루프백 주소이며 포트는 클라이언트의 현재 설정을 따라야 합니다. 다른 기기의 포트를 그대로 복사하거나 원격 서버 포트를 로컬 프록시 포트로 입력하지 마세요. 시스템 프록시와 수동 프록시를 모두 지원하는 프로그램이라면 한 가지 경로만 남겨 중복 전달을 방지하세요.

TUN 모드와 관리자 권한

시스템 프록시를 읽지 않는 프로그램, 명령줄 도구 또는 일부 게임 트래픽까지 인계해야 한다면 TUN을 고려할 수 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅 규칙으로 트래픽을 처리하므로 시스템 프록시보다 적용 범위가 넓고 권한, DNS와 다른 가상 네트워크 카드의 영향을 더 크게 받습니다. 처음 활성화할 때 관리자 권한이나 네트워크 구성 요소 설치를 요구할 수 있습니다. 활성화한 뒤 브라우저와 자주 쓰는 앱을 먼저 확인하고 LAN 기기, 회사 네트워크 클라이언트와 가상 머신 네트워크에 영향이 없는지 점검하세요.

TUN을 켠 뒤 시스템 전체가 인터넷에 연결되지 않으면 먼저 TUN을 끄고 일반 시스템 프록시가 작동하는지 확인하세요. 그런 다음 다른 VPN, 가상 머신 브리지, 컨테이너 네트워크 또는 보안 프로그램 드라이버와 충돌하는지 살펴봅니다. 문제가 발생한 상태에서 MTU, DNS, 라우팅 규칙과 노드 매개변수를 동시에 바꾸지 말고 한 번에 한 항목만 변경하세요. v2rayN을 종료하기 전 시스템 프록시를 지우거나 클라이언트의 정상 종료 명령을 사용하면 종료된 포트를 가리키는 프록시가 남는 일을 줄일 수 있습니다.

netsh winhttp show proxy
ipconfig /flushdns
nslookup example.com

Windows에서만 발생하는 문제

브라우저는 되지만 스토어 앱이나 명령줄이 되지 않는다면 프로그램마다 다른 프록시 출처를 읽고 있다는 뜻일 수 있습니다. 먼저 앞서 안내한 명령으로 WinHTTP 상태를 확인한 뒤 프로그램 자체의 프록시 설정을 점검하세요. 클라이언트를 종료한 후 모든 웹페이지가 열리지 않으면 Windows 프록시 설정에서 수동 프록시를 끄거나 v2rayN을 다시 시작한 뒤 시스템 프록시를 지우세요. 백신 또는 보안 프로그램이 코어 프로세스를 차단한다면 로그에 표시된 실제 프로세스 경로를 기준으로 규칙을 확인하고, 권한 문제를 반복 재설치로 덮으려 하지 마세요. 자주 발생하는 오류는 문제 해결에서 증상별로 찾을 수 있습니다.

03 · MACOS

macOS: v2rayN 설치, 권한과 네트워크 연동

칩 아키텍처 확인 및 설치

macOS에서 v2rayN을 사용할 때는 먼저 “이 Mac에 관하여” 또는 시스템 정보에서 칩 유형을 확인하세요. Apple Silicon 기기는 arm64 설치 패키지를, Intel 기기는 x64 설치 패키지를 선택합니다. 아키텍처가 맞지 않으면 앱이 열리지 않거나 지원되지 않는다는 안내가 나타날 수 있으며, 호환 계층에서 실행되어 리소스 사용량이 비정상적으로 높아질 수도 있습니다. 다운로드 후 설치 패키지 형식에 맞게 앱을 “응용 프로그램” 폴더에 넣고 그곳에서 실행하세요. 업데이트, 권한과 설정 저장이 달라질 수 있으므로 다운로드 폴더나 마운트된 이미지에서 장기간 실행하지 마세요.

처음 실행할 때 출처 확인, 네트워크 접근 또는 백그라운드 항목에 관한 안내가 나타날 수 있습니다. 시스템 설정에서 해당 앱을 찾아 필요한 권한을 명확히 허용하세요. 앱 창이 보이지 않으면 먼저 Dock, 메뉴 막대와 활성 상태 보기를 확인해 이미 백그라운드에서 실행 중인지 살펴봅니다. 여러 인스턴스를 반복 실행하면 로컬 포트가 충돌할 수 있습니다. 시스템이 앱 실행을 차단할 때는 기기 전체의 보안 정책을 바꾸지 말고 시스템이 제공하는 개별 앱 확인 절차를 이용하세요.

구독 가져오기와 기본 연결

구독 그룹 관리에서 이름과 구독 주소를 추가하고 저장한 뒤 업데이트를 실행하세요. macOS와 Windows의 구독 내용은 같아도 시스템 프록시 상태, TUN 권한, LAN 우회 규칙과 로그 레벨 같은 클라이언트 로컬 설정은 자동으로 공유되지 않으므로 각각 설정해야 합니다. 노드가 나타나면 하나를 활성 노드로 선택하고 코어를 시작한 다음 시스템 프록시를 켜세요. 브라우저로 테스트할 때는 기존 연결, DNS 캐시 또는 이미 열린 HTTP/3 세션의 영향을 피하기 위해 새 창을 여는 것이 좋습니다.

구독 업데이트 중 도메인을 해석할 수 없다는 메시지가 나오면 먼저 클라이언트가 네트워크를 인계하지 않은 상태에서 시스템 DNS가 정상인지 확인하세요. 인증서 또는 핸드셰이크 오류라면 시스템 시간, 구독 주소와 현재 네트워크 환경을 점검합니다. 구독 업데이트만 실패하고 이미 가져온 노드는 연결된다면 구독 요청 경로와 노드 연결 경로가 별개라는 뜻입니다. 현재 노드를 계속 사용하면서 구독 서비스만 따로 점검할 수 있으므로 유효한 설정을 삭제할 필요는 없습니다.

시스템 프록시와 앱별 차이

시스템 프록시를 켜면 대부분 macOS 네트워크 설정을 따르는 브라우저와 앱이 클라이언트가 제공하는 로컬 프록시를 사용합니다. 터미널 명령이 시스템 프록시를 따르는지는 명령줄 도구의 구현에 따라 다릅니다. 일부 도구는 환경 변수를 읽고, 일부는 시스템 네트워크 설정을 읽으며, 또 일부는 명시적인 매개변수를 요구합니다. 브라우저가 작동한다고 해서 모든 터미널 트래픽도 같은 경로를 사용한다고 단정하지 마세요. 현재 터미널 세션에 임시 프록시를 설정할 때는 클라이언트 화면에 표시된 실제 포트를 사용해야 합니다.

export HTTP_PROXY=http://127.0.0.1:v2rayN에 표시된 HTTP 포트
export HTTPS_PROXY=http://127.0.0.1:v2rayN에 표시된 HTTP 포트
export ALL_PROXY=socks5://127.0.0.1:v2rayN에 표시된 SOCKS 포트

scutil --proxy
dscacheutil -flushcache

위 예시의 포트 설명은 v2rayN에 현재 표시된 숫자로 바꿔야 하며, 현재 터미널 세션에만 적용됩니다. 더 이상 필요하지 않다면 터미널 창을 닫거나 unset HTTP_PROXY HTTPS_PROXY ALL_PROXY를 사용해 변수를 삭제하세요. 클라이언트가 실행되지 않을 때 명령이 연결을 어떻게 처리하는지 이해한 경우가 아니라면 임시 변수를 모든 터미널 시작 파일에 영구적으로 기록하지 마세요. 시스템 프록시와 터미널 환경 변수가 함께 있어도 반드시 충돌하는 것은 아니지만 문제 해결 경로가 늘어납니다.

TUN과 네트워크 확장 권한

TUN 모드는 더 깊은 수준의 네트워크 인계가 필요하므로 처음 활성화할 때 네트워크 확장, VPN 구성 또는 시스템 암호 확인이 나타날 수 있습니다. 권한을 허용한 뒤 시스템 팝업이 사라진 것만 보지 말고 클라이언트로 돌아가 상태가 실제로 활성화되었는지 확인하세요. 시스템 설정에 여러 네트워크 필터나 기업 관리 구성이 있으면 TUN이 생성되지 않거나 즉시 끊기거나 LAN 접근 경로가 바뀔 수 있습니다. 다른 네트워크 인계 프로그램을 먼저 종료한 뒤 클라이언트를 다시 시작해 테스트하세요.

Wi-Fi, 유선 네트워크 또는 핫스팟을 전환하면 이전 라우팅과 DNS 상태가 잠시 남을 수 있습니다. “네트워크를 바꾼 직후 모든 노드가 실패”한다면 시스템이 주소를 완전히 할당할 때까지 기다린 뒤 클라이언트 코어를 중지하고 다시 시작하세요. 그래도 이상하면 TUN을 끄고 DNS를 새로 고친 다음 시스템 프록시 모드로 기본 연결을 확인합니다. 시스템 프록시는 정상인데 TUN만 실패한다면 원격 노드보다 권한, 가상 인터페이스와 라우팅 충돌을 먼저 점검하세요.

절전 모드, 메뉴 막대와 종료 후 복구

노트북이 장시간 절전 모드에서 복귀하면 기존 TCP 연결, 네트워크 인터페이스와 DNS 상위 서버가 바뀌었을 수 있습니다. 클라이언트 화면에 실행 중으로 표시되어도 기존 연결을 재사용할 수 있다는 뜻은 아닙니다. 먼저 한 번 연결을 끊었다가 다시 연결한 뒤 새 요청을 테스트하세요. 앱 창을 닫아도 메뉴 막대에서 계속 실행되는 것은 데스크톱 클라이언트의 일반적인 동작입니다. 완전히 종료하려면 앱 메뉴의 종료 명령을 사용하세요. 완전히 종료하기 전에 시스템 프록시를 지우면 닫힌 로컬 포트로 트래픽을 계속 보내는 일을 막을 수 있습니다.

LAN 프린터, 파일 공유 또는 개발 기기 검색에 문제가 생기면 라우팅 규칙이 사설 주소를 프록시로 보내고 있지 않은지 확인하세요. 일반적인 사설 네트워크 대역과 로컬 도메인은 실제 네트워크에 맞춰 직접 연결로 유지해야 합니다. 회사 네트워크, 가정용 게이트웨이와 개발 환경의 사설 주소 범위는 완전히 같지 않으므로 출처를 모르는 전체 라우팅 규칙을 그대로 복사하지 마세요. 접속할 수 없는 기기의 주소를 먼저 기록한 뒤 정확한 직접 연결 규칙을 추가하는 편이 모든 트래픽을 허용하는 것보다 검증하기 쉽습니다.

04 · ANDROID

Android: v2rayNG와 v2flyNG 설정

클라이언트와 설치 패키지 선택

Android에서는 Xray 코어를 사용하는 v2rayNG를 기본으로 선택하며, 대부분의 일반적인 구독과 프로토콜 설정에 적합합니다. V2Fly 코어가 필요하면 v2flyNG를 사용할 수 있습니다. 두 클라이언트의 기본 조작은 비슷하지만 설정 데이터베이스, 코어 기능과 일부 메뉴는 완전히 같지 않으므로 동시에 연결해 두면 안 됩니다. 최근 스마트폰은 대개 arm64 설치 패키지를 사용합니다. 기기 아키텍처를 확인할 수 없거나 arm64 패키지가 설치되지 않으면 Android 다운로드 영역으로 돌아가 범용 버전을 선택하세요.

시스템에 설치하기 전 현재 브라우저나 파일 관리자가 앱을 설치하도록 허용해야 할 수 있습니다. 설치가 끝나면 이 임시 권한을 끌 수 있습니다. 처음 클라이언트를 열었을 때 모든 백그라운드 권한을 서둘러 허용하지 말고, 구독 가져오기와 기본 연결을 완료한 뒤 기기의 배터리 정책에 맞춰 하나씩 조정하세요. 그러면 설정 오류인지 백그라운드 제한인지 구분하기 쉽습니다. 이전 버전에서 옮겨 온 경우 기존 설정이 여전히 보이는지 먼저 확인한 뒤 다시 가져올지 결정해 중복 노드와 그룹이 선택을 방해하지 않게 하세요.

구독 가져오기, 공유 내용과 QR 코드

클라이언트 메뉴에서 구독 그룹 설정을 찾아 그룹을 만들고 전체 구독 주소를 붙여 넣으세요. 저장한 뒤 메인 화면으로 돌아가 구독 업데이트를 실행합니다. 구독 출처가 단일 공유 내용을 제공한다면 클립보드로 가져올 수 있습니다. QR 코드는 출처가 명확할 때만 사용하고, 가져온 뒤 주소, 포트, 프로토콜과 서버 이름이 모두 올바른지 확인하세요. 카메라 QR 스캔은 입력 방식일 뿐 설정 만료 여부를 판단하거나 누락된 필드를 자동으로 수정하지 않습니다.

노드 목록이 나타나면 하나를 눌러 현재 설정으로 선택하고 연결 버튼을 누르세요. Android에서는 시스템 VPN 연결 요청이 나타나는데, 이는 로컬에 가상 네트워크 인터페이스를 만들기 위한 시스템 확인 절차입니다. 허용한 뒤 상태 표시줄에 시스템 VPN 표시가 나타나는지 확인하세요. 먼저 브라우저를 열어 테스트한 다음 자주 사용하는 앱을 점검합니다. 연결 버튼이 곧바로 연결 해제 상태로 돌아가면 즉시 로그를 확인하세요. 설정 구문 분석 실패, 포트 사용 중, 권한 중단 또는 코어 시작 실패의 구체적인 원인을 확인할 수 있습니다.

앱별 프록시와 라우팅 모드

모바일 기기의 앱 트래픽은 보통 시스템 VPN 인터페이스를 통해 클라이언트로 들어갑니다. 일부 앱만 사용하게 하려면 앱별 프록시를 활성화하고 포함 모드 또는 제외 모드를 선택할 수 있습니다. 포함 모드는 선택한 앱만 클라이언트로 들어가고, 제외 모드는 선택한 앱이 클라이언트를 우회합니다. 앱 목록을 바꾼 뒤에는 시스템이 라우팅을 다시 만들도록 연결을 끊었다가 재연결하는 것이 좋습니다. 시스템 구성 요소, 브라우저 내장 페이지와 앱이 호출하는 외부 서비스는 서로 다른 프로세스일 수 있으므로 실제 테스트를 기준으로 판단하세요.

라우팅 모드는 클라이언트에 들어온 요청을 프록시, 직접 연결 또는 차단 중 어디로 보낼지 결정합니다. 처음 연결할 때는 클라이언트가 제공하는 기본 규칙을 사용하고 출처가 불분명한 규칙 세트를 여러 개 동시에 가져오지 마세요. 어떤 앱이 첫 화면은 열지만 이미지나 로그인이 실패한다면 여러 도메인을 사용하면서 규칙이 일부 요청만 포함한 것일 수 있습니다. 로그에서 실패한 도메인을 찾아 프록시 또는 직접 연결 규칙을 보완할지 결정하세요. 앱 전체를 한 경로로 바꾸면 빠르지만 규칙을 이해하고 관리하기 어려워집니다.

백그라운드 실행과 배터리 절약 정책

휴대폰 시스템마다 백그라운드 앱 제한이 크게 다릅니다. 대표적인 증상은 화면을 잠근 뒤 몇 분 후 연결이 끊기거나, 앱으로 돌아오면 즉시 복구되거나, 시스템이 백그라운드를 정리한 뒤 VPN 표시가 사라지는 것입니다. 배터리 최적화, 백그라운드 활동, 자동 시작과 최근 작업 잠금을 차례로 확인하세요. 현재 클라이언트와 관련된 설정만 조정하고 기기 전체의 배터리 절약 기능을 끌 필요는 없습니다. 구독 자동 업데이트 주기도 너무 짧게 설정하지 마세요. 모바일 네트워크에서 잦은 깨우기, 대규모 그룹 업데이트와 속도 측정은 배터리와 데이터 사용량을 늘립니다.

백그라운드 배터리 소모에 관해서는 v2rayNG 배터리 소모와 절전 정책 점검을 참고하세요. 문제를 확인할 때는 먼저 시스템 배터리 통계에서 화면을 켠 상태의 사용량, 클라이언트 자체 실행과 프록시를 사용하는 앱의 네트워크 활동을 구분해야 합니다. 클라이언트에 VPN 서비스가 계속 표시된다고 해서 반드시 비정상적인 배터리 소모는 아닙니다. 반복 요청, 지속적인 로그 기록, 잦은 구독 업데이트, 지나치게 세분화된 라우팅 규칙과 불안정한 네트워크 신호가 모두 깨우기 횟수를 늘릴 수 있습니다.

Android에서만 발생하는 문제

연결 후 일부 앱만 사용할 수 없다면 먼저 앱별 프록시 목록과 비공개 DNS 설정을 확인하세요. 비공개 DNS에 특정 호스트 이름을 사용하면 클라이언트 DNS 라우팅과 조합되어 결과가 달라질 수 있으므로 원인 파악을 위해 잠시 자동 모드로 바꿔 보세요. Wi-Fi와 모바일 네트워크를 전환한 뒤 연결이 끊기면 시스템 전환이 끝난 후 수동으로 다시 연결합니다. 계속 복구되지 않으면 먼저 시스템 VPN 연결을 끊고 클라이언트를 강제 종료한 뒤 다시 여세요. 연결된 상태에서 v2rayNG와 v2flyNG를 자주 전환하지 마세요.

설정을 가져온 뒤 형식 오류가 표시되면 원본으로 돌아가 다시 복사하고, 불필요해 보이는 문자를 수동으로 삭제하지 마세요. REALITY, TLS, 전송 경로와 서버 이름 등의 필드는 서로 연결되어 있어 하나만 달라도 핸드셰이크가 실패할 수 있습니다. 모든 노드가 동시에 시간 초과되면 현재 네트워크, 시스템 시간, 구독 유효성 및 DNS를 먼저 확인하세요. 한 노드만 실패한다면 같은 그룹의 다른 노드와 해당 노드의 매개변수를 비교합니다. 이처럼 범위가 큰 항목부터 작은 항목 순으로 점검하는 것이 코어를 계속 바꾸는 것보다 효과적입니다.

05 · LINUX

Linux: v2rayN 설치, 데스크톱 프록시와 TUN

deb, rpm 및 프로세서 아키텍처 선택

Linux 데스크톱에서는 v2rayN을 사용합니다. Debian, Ubuntu와 일반적인 파생 배포판은 보통 deb를 선택하고, Fedora, Rocky Linux, openSUSE처럼 rpm 패키지 관리 체계를 사용하는 배포판은 rpm을 선택할 수 있습니다. 기기 프로세서에 맞춰 x64 또는 arm64도 선택해야 합니다. 특히 개발 보드, 미니 PC와 클라우드 데스크톱 환경에서는 배포판 이름만으로 아키텍처를 판단할 수 없습니다. 터미널에서 uname -m을 실행하면 됩니다. 일반적인 x86_64는 x64, aarch64는 arm64에 해당합니다.

그래픽 소프트웨어 설치 관리자를 사용한다면 패키지를 두 번 클릭하고 의존성을 확인하면 됩니다. 명령줄을 사용한다면 다운로드 폴더에서 실제 파일에 로컬 설치를 실행하세요. 패키지 관리자는 의존성도 함께 처리하므로 하위 수준 설치 명령을 직접 호출하는 것보다 대체로 안전합니다. 아래 명령의 파일명은 작업 형식을 보여 주기 위한 것이므로 실행할 때는 다운로드 페이지에 제공된 실제 파일명을 사용해야 합니다.

uname -m

cd ~/Downloads
sudo apt install ./v2rayN-linux-x64.deb

sudo dnf install ./v2rayN-linux-x64.rpm

같은 기기에 서로 다른 아키텍처의 패키지를 반복해서 설치하지 마세요. 패키지 관리자가 의존성 누락을 보고하면 먼저 배포판 소프트웨어 저장소를 새로 고치고 시스템을 정상적으로 업데이트한 뒤 다시 설치합니다. 시스템 버전의 지원이 이미 종료된 상태라면 시스템 라이브러리를 강제로 교체할 경우 다른 데스크톱 앱에 영향을 줄 수 있으므로, 아직 지원되는 배포판 버전으로 먼저 업그레이드하는 편이 적절합니다. 설치 후 앱 메뉴에서 v2rayN을 실행하고 로그에서 코어와 설정 디렉터리를 정상적으로 읽는지 확인하세요.

구독 가져오기와 데스크톱 환경별 차이

구독 그룹을 만들고 주소를 붙여 넣은 뒤 노드를 업데이트하고 활성 서버를 선택하는 과정은 다른 데스크톱 플랫폼과 같습니다. Linux의 차이는 주로 데스크톱 프록시 설정에 있습니다. GNOME, KDE, 경량 데스크톱과 순수 윈도 매니저는 프록시를 읽는 방식이 다릅니다. 일부 앱은 데스크톱 설정을 사용하고, 일부는 환경 변수를 읽으며, 브라우저에는 별도 프록시 옵션이 있을 수도 있습니다. v2rayN의 시스템 프록시를 켠 뒤 브라우저, 터미널과 사용할 데스크톱 프로그램을 각각 테스트하세요.

브라우저는 정상인데 터미널 명령이 직접 연결된다면 명령줄 도구가 데스크톱 프록시를 읽지 않는 것입니다. 도구 문서에 따라 현재 세션의 HTTP, HTTPS 또는 SOCKS 프록시를 설정하고 포트는 v2rayN 화면을 기준으로 입력하세요. 클라이언트가 실행되지 않으면 이 환경 변수는 수신 중인 프로그램이 없는 로컬 포트를 가리킵니다. 따라서 모든 Shell 시작 스크립트에 무조건 기록하는 것은 권장하지 않습니다. 서버나 그래픽 환경이 없는 시스템은 이 매뉴얼의 주요 대상이 아니며, 이 페이지는 그래픽 클라이언트와 로컬 데스크톱 세션을 기준으로 합니다.

TUN, 권한과 DNS

TUN 모드는 가상 인터페이스를 만들고 라우팅을 변경하므로 관리자 승인, 시스템 권한 또는 네트워크 관리 서비스가 필요할 수 있습니다. 활성화하면 데스크톱 프록시를 읽지 않는 프로그램까지 포함할 수 있지만 컨테이너 네트워크, 가상 머신 브리지, 기업 VPN과 사용자 지정 방화벽 규칙의 영향을 더 쉽게 받습니다. 처음 테스트할 때는 추가 네트워크 계층을 모두 끄고 v2rayN의 TUN만 정상 작동하는지 확인한 뒤 하나씩 다시 켜세요. 인터페이스 생성에 실패하면 시스템 디렉터리 권한을 무작정 넓히지 말고 클라이언트 로그와 시스템 로그의 권한 정보를 확인하세요.

Linux의 DNS는 systemd-resolved, NetworkManager, 데스크톱 네트워크 서비스 또는 로컬 리졸버가 관리할 수 있습니다. 도메인 접속은 실패하지만 이미 알고 있는 주소에는 응답이 있다면 해석 경로를 확인해야 합니다. resolvectl status로 현재 DNS 상위 서버와 각 인터페이스 상태를 확인하고, resolvectl query example.com으로 해석을 테스트할 수 있습니다. 해당 명령이 없다면 배포판에서 사용하는 네트워크 서비스에 맞는 동등한 도구를 선택하세요. 변경 전 원래 설정을 기록해 문제 해결 후 복구할 수 있게 하세요.

ip address
ip route
resolvectl status
resolvectl query example.com
ss -lntup

포트 사용 중과 세션 시작

클라이언트가 코어를 시작할 때 포트 사용 중 오류가 나오면 ss -lntup으로 로컬 수신 프로그램을 찾을 수 있습니다. 흔한 원인은 이전 인스턴스가 종료되지 않았거나 다른 프록시 도구가 같은 포트를 사용하거나, 데스크톱 세션 복원 후 프로세스가 백그라운드에 남아 있는 경우입니다. 먼저 기존 프로세스를 정상 종료한 뒤 클라이언트를 다시 시작하세요. 정체를 모르는 시스템 서비스를 함부로 종료하지 마세요. 로컬 포트를 바꾸면 해당 포트를 수동으로 입력한 브라우저, 개발 도구와 환경 변수도 모두 함께 업데이트해야 합니다.

로그인 시 시작하도록 설정했다면 클라이언트가 사용자 데스크톱 네트워크 서비스보다 늦게 시작하는지 확인하고, 비정상 종료 후 시스템 프록시가 복구되는지도 검증하세요. 공유 컴퓨터에서는 개인 구독을 전역에서 읽을 수 있는 설정 디렉터리에 저장하지 마세요. 설정 파일과 로그에는 서버 주소, 구독 요청 정보와 실행 오류가 포함될 수 있으므로 현재 사용자 디렉터리로 제한하고 더 이상 필요하지 않은 오래된 로그는 정기적으로 삭제하세요. 문제 해결이 끝나면 로그 레벨을 디버그에서 정보 또는 경고로 되돌려 디스크 기록을 줄이세요.

배포판 업데이트 후 확인 사항

시스템 주요 버전 업데이트로 그래픽 라이브러리, 네트워크 서비스, 방화벽 백엔드 또는 코어 모듈이 바뀔 수 있습니다. 업데이트 후 시스템 프록시는 작동하지만 TUN이 실패한다면 먼저 가상 인터페이스 권한과 라우팅 서비스를 다시 확인하세요. 클라이언트가 실행되지 않으면 터미널에서 한 번 실행해 누락된 라이브러리나 표시 서비스 오류를 읽습니다. 데스크톱 실행기가 반응하지 않는 것을 곧바로 노드 문제로 보지 마세요. 기본 환경을 복구한 뒤 구독과 연결을 확인합니다. 장기간 안정적으로 사용하려면 정상 작동했던 프록시 모드, DNS 정책과 사용자 지정 라우팅을 기록하고 시스템 업데이트 후 같은 목록으로 하나씩 검증하세요.

06 · SUBSCRIPTION

구독, 노드와 프로토콜 매개변수 관리

구독이란 무엇이며 클라이언트는 무엇을 저장하는가

구독은 원격 주소가 반환하는 설정 모음이며, 클라이언트는 업데이트 후 그 안의 노드를 로컬 그룹에 저장합니다. 실시간 연결 통로가 아니므로 네트워크 요청마다 구독 주소에 접속하지도 않습니다. 노드 연결 가능 여부는 가져온 서버 주소, 포트, 사용자 식별자, 프로토콜, 전송, 암호화와 TLS 매개변수에 달려 있습니다. 구독 업데이트가 실패해도 기존 노드는 보통 남아 있으며, 계속 사용할 수 있는지는 업데이트 버튼이 아니라 서버 측 상태에 따라 결정됩니다.

출처나 용도에 따라 그룹을 만들고 모든 주소를 하나의 이름에 넣지 않는 것이 좋습니다. 그룹을 명확히 나누면 각각 업데이트·삭제·변경 사항 확인을 할 수 있고, 특정 노드 묶음이 동시에 실패하는 원인이 같은 구독인지 판단하기도 쉽습니다. 구독 주소를 바꿀 때는 새 그룹을 추가해 정상 업데이트되는 것을 확인한 뒤 기존 그룹을 삭제하세요. 복사 오류로 사용할 수 있는 설정이 모두 사라지는 일을 막을 수 있습니다. 업데이트 시 기존 노드 정리 옵션이 있다면 그룹 단위 교체인지 전체 삭제인지 먼저 이해해야 합니다.

업데이트 실패 시 고정 점검 순서

첫째 일반 네트워크와 시스템 시간을 확인합니다. 둘째 전체 주소를 다시 복사합니다. 셋째 구독 요청 로그의 상태를 확인합니다. 넷째 현재 클라이언트에서 시스템 프록시를 끄거나 구독 업데이트 경로를 바꾼 뒤 다시 시도합니다. 다섯째 출처에서 추가 인증을 요구하는지 확인합니다. 구독 요청은 보통 일반 HTTPS 요청이므로 노드 내부의 VMess, VLESS 또는 Trojan 매개변수와 같은 계층이 아닙니다. 프로토콜부터 바꾸지 마세요. 전체 과정은 설치 및 설정 관련 질문을 참고할 수 있습니다.

로그에 시간 초과가 표시되면 DNS, 현재 네트워크와 구독 서비스에 접근할 수 있는지 확인하세요. 인증서 시간 오류라면 먼저 시스템 시계를 동기화합니다. 인증되지 않았거나 접근이 거부되었다면 구독 출처에서 주소와 상태를 확인하세요. 반환 내용을 해석할 수 없다면 웹페이지 주소, 로그인 주소를 복사했거나 중간 앱에서 내용이 잘렸을 수 있습니다. 짧은 간격으로 계속 재시도하면 서비스 제한이 걸리고 로그가 쌓여 읽기 어려워질 수 있습니다. 한 번에 한 항목만 바꾼 뒤 업데이트하고 결과를 기록하세요.

노드 필드 간 관계

완전한 노드에는 보통 주소, 포트, 사용자 식별자, 프로토콜, 보안 방식, 전송 유형, TLS 설정, 서버 이름과 경로가 포함됩니다. 프로토콜 이름이 같다고 설정을 서로 바꿔 쓸 수 있는 것은 아닙니다. 예를 들어 VLESS라도 TLS, REALITY, WebSocket, gRPC 또는 다른 전송을 사용하는지에 따라 필요한 필드가 달라집니다. 서버 이름은 인증서 또는 핸드셰이크 판단에 사용되는 경우가 많고, 경로는 서로 다른 서비스 입구를 구분할 수 있습니다. 수동 편집 시에는 출처가 제공한 매개변수를 그대로 사용하고, 다른 노드의 그럴듯한 필드를 조합하지 마세요.

VMess, VLESS, Trojan과 REALITY

프로토콜 선택은 서버 측 설정과 구독 내용을 기준으로 해야 합니다. VMess에는 자체 사용자 인증과 보안 매개변수가 포함됩니다. VLESS는 설정이 비교적 단순하며 TLS나 REALITY 등과 함께 사용하는 경우가 많습니다. Trojan은 인증 방식과 TLS 설정이 서버와 일치해야 합니다. REALITY는 보통 특정 핸드셰이크 조합의 일부로 사용되며 모든 노드에서 단독으로 켠다고 속도가 빨라지는 옵션이 아닙니다. 클라이언트가 특정 프로토콜을 지원한다는 것은 해당 설정을 해석하고 실행할 수 있다는 뜻일 뿐, 어떤 서버든 그 설정을 받아들인다는 의미는 아닙니다.

구독에서 가져올 때는 필드를 가능한 한 원본 그대로 유지하세요. 서버 측 변경을 명확히 알고 있을 때만 해당 항목을 수동으로 수정합니다. 연결에 실패하면 같은 구독에서 작동하는 노드와 작동하지 않는 노드의 차이를 먼저 비교하세요. 모두 같은 도메인을 사용하고 포트만 다르면 포트와 원격 상태를 확인하고, 특정 전송만 실패하면 경로, 서비스 이름과 TLS를 점검합니다. TLS 노드가 모두 동시에 실패하면 시간과 네트워크 환경을 확인하세요. 코어 관계와 프로토콜 지원 범위는 Xray와 V2Fly 코어의 차이에서 확인할 수 있습니다.

속도 측정, 정렬과 업데이트 주기

노드 속도 측정은 기본 연결 확인, 연결 지연 시간과 실제 다운로드 테스트로 나눌 수 있습니다. 연결 테스트는 요청을 만들 수 있는지 확인하고, 지연 시간 테스트는 당시 테스트 대상까지의 왕복 시간을 보여 주며, 실제 다운로드는 회선 부하, 대상 사이트와 로컬 네트워크의 영향을 더 크게 받습니다. 한 번의 지연 시간 결과로 영구 정렬하지 말고 모바일 네트워크에서 일괄 테스트를 자주 실행하지도 마세요. 실제 접속으로 확인한 노드 몇 개를 남겨 두고 문제가 생길 때 그룹별로 전환하는 편이 실용적입니다.

구독 자동 업데이트 주기는 출처의 변경 속도와 기기 사용 습관에 따라 정해야 합니다. 항상 켜 두는 데스크톱은 적절한 예약 업데이트를 설정할 수 있지만, 모바일은 백그라운드 깨우기와 데이터 사용량을 더 고려해야 합니다. 업데이트 후 현재 노드가 삭제되면 클라이언트가 다음 재시작까지 기존 설정을 유지할 수도 있고 즉시 다시 선택하라고 할 수도 있습니다. 구체적인 동작은 클라이언트 구현에 따라 다릅니다. 중요한 작업 전 수동으로 업데이트하고 노드 하나를 확인하는 것이 사용 중 잦은 자동 변경보다 제어하기 쉽습니다.

07 · ROUTING

시스템 프록시, TUN, DNS와 라우팅 분할

네 가지 경로 계층을 섞지 않기

트래픽 경로를 이해하는 것이 라우팅 설정의 기초입니다. 첫 번째 계층은 앱이 요청을 클라이언트로 넘기는지 여부입니다. 브라우저는 시스템 프록시를 읽을 수 있고, 터미널 도구는 환경 변수를 읽을 수 있으며, Android 앱은 보통 시스템 VPN 인터페이스를 통해 들어옵니다. 두 번째는 HTTP, SOCKS 또는 TUN 같은 클라이언트의 로컬 입구입니다. 세 번째는 라우팅 규칙이 프록시, 직접 연결 또는 차단을 결정하는 단계입니다. 네 번째가 선택한 원격 노드와 프로토콜입니다. 웹페이지가 열리지 않을 때는 이 네 계층을 따라 차례로 확인하고 곧바로 노드가 문제라고 단정하지 마세요.

시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 적합하고 설정이 간단하며 적용 범위가 명확합니다. TUN은 더 넓은 범위의 트래픽을 인계해 프록시 옵션이 없는 프로그램도 처리할 수 있지만 라우팅과 DNS 경로를 바꾸고 다른 가상 네트워크와 충돌하기 쉽습니다. 수동 프록시는 특정 개발 도구나 브라우저만 사용하게 할 때 적합합니다. 세 방식은 상황에 따라 조합할 수 있지만 처음 설정할 때는 주요 인계 방식 하나만 활성화하세요. 그렇지 않으면 같은 요청이 중복 전달되거나 앱마다 완전히 다른 경로를 사용할 수 있습니다.

직접 연결, 프록시와 차단 규칙

라우팅 규칙은 보통 도메인, IP, 포트, 네트워크 유형 또는 앱 프로세스를 기준으로 매칭합니다. 규칙은 위에서 아래로 실행되거나 클라이언트가 정의한 우선순위를 따르며, 첫 번째로 명확히 일치한 규칙이 트래픽의 방향을 결정하는 경우가 많습니다. 직접 연결은 LAN 기기, 프린터, 게이트웨이와 로컬 네트워크를 사용해야 하는 서비스에 적합합니다. 프록시는 현재 노드를 통해 전달해야 하는 요청에 사용하고, 차단은 특정 도메인이나 프로토콜을 거부할 때 사용합니다. 매칭되지 않은 트래픽의 동작이 불분명해지지 않도록 마지막에는 기본 출구를 지정해야 합니다.

{
  "type": "field",
  "domain": [
    "domain:intranet.example",
    "full:printer.lan"
  ],
  "outboundTag": "direct"
}

위 구조는 도메인 직접 연결의 기본 의미를 보여 주며, 실제 가져오기 위치와 태그 이름은 클라이언트 라우팅 편집기를 기준으로 해야 합니다. domain:은 보통 지정한 도메인과 해당 범위를 매칭하고, full:은 전체 이름을 정확히 매칭하는 데 사용됩니다. 규칙 문법은 현재 코어 버전과 클라이언트 생성 방식에서 분리해 사용할 수 없으므로 설정 전체를 기존 파일에 덮어쓰지 마세요. 그래픽 인터페이스에서 규칙을 생성할 수 있다면 먼저 인터페이스에서 추가하고 검증해 JSON 계층이나 태그 오타를 줄이세요.

LAN, 사설 주소와 공유

가정용 게이트웨이, 네트워크 저장 장치, 프린터와 개발 기기는 보통 사설 주소를 사용합니다. 글로벌 프록시나 TUN을 켠 뒤 이 기기에 접근할 수 없다면 사설 주소가 원격으로 잘못 전달되고 있지 않은지 확인하세요. 일반적인 범위는 10.0.0.0/8, 172.16.0.0/12와 192.168.0.0/16이지만 실제 환경에서는 로컬 도메인이나 다른 내부 주소를 사용할 수도 있습니다. 직접 연결 규칙을 추가한 뒤 주소 접속, 도메인 접속과 기기 검색을 각각 테스트하세요. 브로드캐스트와 유니캐스트의 동작이 다르기 때문입니다.

LAN 기기가 이 컴퓨터의 프록시를 사용하도록 허용하는 것은 별도의 기능이며, 클라이언트가 루프백 주소 외의 주소에서도 수신하도록 만듭니다. 활성화하기 전에 현재 네트워크를 신뢰할 수 있는지 확인하고 방화벽에서 필요한 네트워크 대역과 포트만 허용하세요. 클라이언트에 표시되는 로컬 프록시 포트는 원격 노드 포트가 아닙니다. 다른 기기에서 수동으로 입력할 때는 클라이언트를 실행 중인 컴퓨터의 LAN 주소와 로컬 수신 포트를 사용해야 합니다. 컴퓨터가 절전 모드에 들어가거나 주소가 바뀌거나 클라이언트가 종료되면 공유도 중단되므로 별도 관리 없이 장기간 게이트웨이로 사용하기에는 적합하지 않습니다.

DNS 경로와 누출로 인한 오판

DNS는 도메인을 먼저 어떤 주소로 해석할지 결정하고, 라우팅은 그 연결을 처리합니다. 도메인 규칙이 해석 전에 매칭되는지, 해석 결과가 판단에 필요한지는 클라이언트와 코어 설정에 따라 다릅니다. 흔한 문제로는 도메인만 실패하고 주소는 접속되는 경우, 일부 도메인이 현재 네트워크에 맞지 않는 결과로 해석되는 경우, TUN을 켠 뒤 해석이 시간 초과되는 경우와 시스템 캐시에 전환 전 기록이 남는 경우가 있습니다. 문제를 해결할 때는 먼저 시스템 도구로 해석을 테스트하고 클라이언트 DNS 로그를 확인하세요. 여러 공용 DNS를 동시에 바꾸지는 마세요.

브라우저 자체가 보안 DNS를 사용해 일부 시스템 해석 경로를 우회할 수 있습니다. 시스템 명령과 브라우저 결과가 다르면 브라우저 네트워크 설정을 확인하세요. Android의 비공개 DNS, macOS의 네트워크 서비스, Windows의 캐시와 Linux의 로컬 리졸버도 서로 다른 계층을 만듭니다. 원인을 찾기 위해 잠시 시스템 DNS를 자동으로 되돌리고 브라우저의 독립 해석을 끈 뒤 클라이언트 기본 설정으로 테스트할 수 있습니다. 기본 경로를 확인한 다음 사용자 지정 설정을 하나씩 다시 적용하세요.

TUN의 MTU, 가상 네트워크 카드와 충돌

TUN은 가상 인터페이스를 통해 트래픽을 받습니다. 일부 네트워크는 패킷 크기, 조각화와 UDP 경로에 민감해 일반 웹페이지는 열리지만 대용량 파일, 동영상 또는 특정 앱이 멈출 수 있습니다. MTU도 가능한 원인 중 하나지만 근거 없이 극단적인 값으로 바꾸면 안 됩니다. 먼저 문제가 TUN에서만 발생하는지 확인하고 시스템 프록시와 비교 테스트하세요. 특정 네트워크에서만 발생한다면 네트워크 유형, 실패한 앱과 로그의 시간 초과 위치를 기록한 뒤 작은 범위에서 조정합니다.

가상 머신, 컨테이너, 기업 VPN, 게임 가속 도구와 보안 필터 프로그램은 모두 가상 인터페이스를 만들거나 라우팅을 변경할 수 있습니다. 충돌이 발생하면 가장 효과적인 방법은 변수를 하나만 남기는 환경을 만드는 것입니다. v2rayN 또는 Android 클라이언트만 인계하도록 두고 정상 작동을 확인한 뒤 다른 프로그램을 하나씩 켜세요. 항목을 하나 복원할 때마다 DNS, 브라우저, LAN과 대상 앱을 테스트합니다. 그러면 기본 라우팅이나 DNS를 실제로 경쟁하는 구성 요소를 찾을 수 있으며, 여러 도구를 모두 시작 프로그램에 등록해 우연한 오류를 기다리는 일을 피할 수 있습니다.

08 · TROUBLESHOOTING

연결 문제, 로그 확인과 일상적인 유지 관리

먼저 영향 범위로 분류하기

문제 해결의 첫 단계는 노드를 바꾸는 것이 아니라 영향 범위를 판단하는 것입니다. 모든 노드와 모든 앱이 실패하면 로컬 네트워크, 시스템 시간, 클라이언트 코어, DNS와 구독 상태를 먼저 확인합니다. 노드 하나만 실패하면 해당 노드의 주소, 포트와 프로토콜 매개변수를 중점적으로 확인합니다. 앱 하나만 실패하면 시스템 프록시를 읽는지, 앱별 규칙에서 제외되었는지, 독립 DNS를 사용하는지 점검합니다. TUN을 켰을 때만 실패한다면 권한, 가상 인터페이스와 라우팅 충돌을 먼저 살펴보세요. 범위를 올바르게 판단하면 점검 항목이 크게 줄어듭니다.

두 번째 단계는 비교 기준을 만드는 것입니다. TUN을 끄고 시스템 프록시로 테스트하고, 사용자 지정 라우팅을 지운 뒤 클라이언트 기본 규칙으로 테스트하세요. 같은 그룹에서 정상 작동하는 노드 하나를 남겨 실패 노드와 비교하고, Wi-Fi에서 다른 정상 네트워크로 바꿨을 때 결과를 기록하세요. 단순히 “아직 안 된다”고 말하는 것보다 비교 테스트가 장애 계층을 특정하는 데 훨씬 유용합니다. 고정된 상세 순서는 노드 시간 초과 문제 해결 가이드에서도 확인할 수 있습니다.

로그 레벨과 키워드

일상적인 사용에서는 정보 또는 경고 레벨이면 충분합니다. 문제가 있을 때만 디버그 레벨로 임시 전환해 한 번 재현하고, 핵심 구간을 저장한 뒤 즉시 원래 레벨로 되돌리세요. 연결 버튼을 누르거나 요청을 시작하기 몇 초 전부터 로그를 읽어야 하며 마지막 한 줄만 잘라서는 안 됩니다. 앞부분의 설정 로드, DNS 조회와 연결 대상이 이후의 timeout 또는 rejected를 결정하는 경우가 많습니다. 로그에는 서버 주소, 도메인과 로컬 경로가 포함될 수 있으므로 공유하기 전에 개인 구독 주소와 식별 가능한 정보를 삭제하세요.

timeout 자체는 원인이 아니라 어느 단계의 대기가 끝났다는 뜻입니다. 앞부분의 대상 주소, 네트워크 유형과 단계를 확인하세요. 해석 전 시간 초과는 DNS를, TCP 연결 수립 시간 초과는 네트워크와 포트를, 핸드셰이크 단계 시간 초과는 프로토콜과 TLS 매개변수를 확인해야 합니다. rejected는 라우팅 차단, 원격 거부 또는 로컬 정책에서 발생할 수 있으므로 문맥과 함께 판단해야 합니다. 더 많은 예시는 v2rayN 로그 읽는 방법을 참고하세요.

연결은 성공했지만 웹페이지가 열리지 않음

클라이언트에 연결됨으로 표시되는 것은 코어 또는 가상 인터페이스가 시작되었다는 뜻일 뿐 대상 요청이 성공했다는 의미는 아닙니다. 먼저 시스템 프록시 또는 TUN이 실제로 켜져 있는지 확인하고 브라우저에 독립 프록시가 설정되어 있지 않은지 살펴보세요. 이전에 열지 않은 일반 페이지를 새로 접속해 오래된 캐시와 기존 연결의 영향을 배제합니다. 그런 다음 DNS를 테스트하세요. 도메인만 실패하고 다른 요청은 정상이라면 해석 경로를 확인하고, 모든 요청이 시간 초과되면 현재 노드, 기본 라우팅 출구와 로컬 방화벽을 점검합니다.

일부 웹페이지만 이상하다면 로그에서 관련 도메인이 어느 출구로 나갔는지 확인하세요. 웹페이지는 보통 기본 도메인, 정적 리소스, 로그인 API와 이미지 도메인을 동시에 요청하므로 규칙에 따라 서로 다른 경로를 사용할 수 있습니다. 일시적으로 단순한 기본 라우팅으로 전환해 분할 라우팅 때문인지 확인하세요. 기본 라우팅이 정상이라면 사용자 지정 규칙을 하나씩 되돌립니다. 테스트를 위해 모든 시스템 보안 구성 요소를 끄지 말고 차단된 프로세스, 포트 또는 인터페이스를 특정하세요.

종료 후 인터넷이 끊기고 프록시가 남아 있음

데스크톱 클라이언트가 비정상 종료되면 시스템 프록시가 여전히 로컬 포트를 가리킬 수 있지만 해당 코어는 더 이상 수신하지 않습니다. 그러면 시스템 프록시를 따르는 모든 앱이 인터넷에 연결되지 않습니다. 복구하려면 클라이언트를 다시 시작해 시스템 프록시를 정상적으로 지우거나 운영체제 네트워크 설정에서 수동 프록시를 끄세요. Windows에서는 사용자 시스템 프록시와 WinHTTP를 구분하고, macOS에서는 시스템 네트워크 설정으로 확인하며, Linux에서는 데스크톱 프록시와 터미널 환경 변수를 함께 점검해야 합니다.

TUN이 비정상적으로 종료된 뒤 라우팅이 제때 복구되지 않으면 먼저 네트워크 연결이나 기기를 다시 시작하고 가상 인터페이스가 남아 있는지 확인하세요. 특정 라우팅 항목의 출처를 이해하는 경우에만 수동으로 삭제해 정상 게이트웨이를 잘못 지우지 않도록 합니다. 모바일에서는 시스템 VPN 설정에서 활성 연결을 끊은 뒤 클라이언트를 강제 종료할 수 있습니다. 일반 네트워크를 복구한 다음 클라이언트를 다시 열어 확인하고, 시스템이 아직 비정상 라우팅 상태일 때 구독을 계속 가져오지는 마세요.

설정 백업과 업데이트 관리

장기간 사용할 때는 클라이언트가 제공하는 설정 내보내기 파일을 백업하거나 구독 출처를 기록하되, 개인 구독 주소가 포함된 파일을 공개 공유 위치에 두지 마세요. 기기를 바꿀 때는 새 기기에 클라이언트를 다시 설치하고 구독을 가져온 뒤 이 매뉴얼에 따라 시스템 프록시, TUN과 라우팅을 설정하는 것이 좋습니다. 기존 설정 디렉터리 전체를 바로 복사하면 이전 포트, 경로, 캐시와 새 플랫폼에 맞지 않는 설정이 따라올 수 있습니다. 이전이 끝나면 구독 업데이트, 노드 연결, DNS, LAN과 자주 사용하는 앱을 하나씩 확인하세요.

클라이언트를 업데이트하기 전에 정상적으로 종료하고 현재 작동하는 핵심 설정을 기록하세요. 업데이트 후 라우팅과 노드를 동시에 바꾸지 말고 먼저 기존 구독을 읽는지, 코어가 시작되는지, 시스템 프록시가 작동하는지 확인한 뒤 TUN을 테스트합니다. 새 버전에서 메뉴 위치가 바뀌었다면 고정된 스크린샷에 의존하지 말고 기능 이름을 기준으로 찾으세요. v2rayN, v2rayNG와 v2flyNG의 핵심 작업은 항상 그룹, 노드, 코어, 라우팅과 로그를 중심으로 이루어집니다.

재현 가능한 최종 문제 해결 순서

연결할 수 없을 때는 다음 순서를 고정해 실행하세요. 클라이언트를 사용하지 않아도 로컬 기기가 정상적으로 인터넷에 연결되는지 확인하고, 시스템 시간을 동기화하며, 다른 네트워크 인계 프로그램을 끕니다. 구독이 업데이트되는지 확인하고 설정이 완전한 노드를 선택한 뒤 시스템 프록시 또는 모바일 기본 연결 중 하나만 켭니다. 브라우저에서 새 요청을 보내고, 시작부터 요청 실패까지의 전체 로그를 확인하세요. 실패 단계에 따라 DNS, 포트, 프로토콜 또는 권한을 점검한 다음 마지막으로 TUN, 사용자 지정 라우팅과 백그라운드 자동화를 복원합니다. 각 단계의 결과를 기록하세요.

그래도 원인을 찾지 못하면 운영체제, 클라이언트 이름, 인계 방식, 영향 범위, 로그 키워드와 이미 완료한 점검 내용을 정리한 뒤 문제 해결 페이지에서 분류별로 비교하세요. “어떤 플랫폼에서, 어떤 모드로, 모든 노드인지 하나의 노드인지, 모든 앱인지 특정 앱인지”를 명확히 설명하는 것이 연결 실패 스크린샷 한 장만 제공하는 것보다 훨씬 효과적입니다. 체계적인 문제 해결의 목표는 한 번에 많은 설정을 시도하는 것이 아니라 매번 한 계층씩 제외해 검증과 복구가 가능한 설정만 남기는 것입니다.