v2rayN 전체 플랫폼 설치 및 설정 가이드

1. 읽는 방법과 전체 설정 구조

클라이언트, 코어, 구독은 각각 무엇을 담당하나요?

사용 가능한 설정을 구성하려면 먼저 클라이언트 인터페이스, 프록시 코어, 구독 내용이라는 세 가지 계층을 구분해야 합니다. v2rayN, v2rayNG, v2flyNG는 노드를 표시하고 설정을 저장하며 시스템 기능을 호출하는 그래픽 클라이언트입니다. Xray와 V2Fly는 프로토콜, 라우팅, 연결을 처리하는 코어입니다. 구독은 서비스 제공자가 제공하는 설정 모음으로, 일반적으로 서버 주소, 포트, 사용자 식별자, 전송 방식, TLS 매개변수, 이름 등이 포함됩니다. 클라이언트가 구독을 가져왔다고 해서 모든 애플리케이션의 네트워크가 즉시 프록시로 전환되는 것은 아닙니다. 먼저 노드가 코어로 전달되고, 시스템 프록시 또는 TUN이 어떤 애플리케이션 트래픽을 로컬 프록시 진입점으로 보낼지 결정합니다.

따라서 ‘클라이언트가 실행 중으로 표시됨’과 ‘브라우저가 프록시를 사용함’은 별개의 문제입니다. 코어가 정상적으로 실행된다는 것은 로컬 수신 포트가 열렸다는 뜻일 뿐입니다. 브라우저 요청이 해당 포트를 거치는지는 시스템 프록시 설정, 브라우저 자체의 프록시 정책, 라우팅 규칙, DNS 요청 처리 방식에 따라 달라집니다. 문제를 해결할 때는 데이터 흐름을 따라 단계별로 확인해야 합니다. 구독 내용을 해석할 수 있는지, 선택한 노드가 연결되는지, 로컬 진입점이 수신 중인지, 애플리케이션이 요청을 진입점으로 전달하는지, 라우팅이 올바른 아웃바운드를 선택하는지, DNS가 사용할 수 있는 결과를 반환하는지를 차례로 점검하세요. 이 과정을 한꺼번에 보고 반복해서 재설치하면 실제 원인을 찾기 어렵습니다.

네 플랫폼별 권장 클라이언트 범위

데스크톱 플랫폼에서는 비슷한 인터페이스 구조로 구독, 라우팅, 로그를 관리할 수 있도록 v2rayN을 우선 사용하는 것이 좋습니다. Android에서는 v2rayNG를 우선 선택하고, V2Fly 코어를 사용해야 한다면 v2flyNG를 선택할 수 있습니다. 두 Android 클라이언트의 기본 조작은 비슷하지만 설정 데이터베이스와 코어 기능이 완전히 호환된다고 가정해서는 안 됩니다. 클라이언트를 바꿀 때는 기존 클라이언트의 내부 데이터 폴더를 복사하지 말고 원본 구독을 다시 가져오세요.

전체 설정의 표준 순서

1. 플랫폼과 아키텍처를 확인합니다. 먼저 기기의 운영체제, 프로세서 아키텍처, 배포판 패키지 형식을 확인한 뒤 다운로드 센터에서 알맞은 설치 파일을 선택합니다.
2. 클라이언트를 설치합니다. 처음 실행할 때 시스템 권한, 방화벽 또는 네트워크 인터페이스 승인을 처리하고 인터페이스가 정상적으로 열리는지 확인합니다.
3. 구독을 가져오고 업데이트합니다. 구독 그룹을 만들고 전체 주소를 입력한 다음 한 번 직접 업데이트하여 노드 목록이 나타나는지 확인합니다.
4. 노드와 모드를 선택합니다. 먼저 기본 시스템 프록시로 연결을 확인한 뒤 애플리케이션 적용 범위에 따라 TUN을 활성화할지 결정합니다.
5. 요청 경로를 확인합니다. 클라이언트 로그, 브라우저 접속, 시스템 프록시 상태를 점검하고 단순 지연 시간 하나만으로 실제 연결을 판단하지 않습니다.
6. 마지막으로 라우팅을 조정합니다. 기본 연결이 확인된 뒤에만 직접 연결, 프록시 또는 차단 규칙을 추가하고, 한 번에 한 종류의 조건만 변경합니다.

시스템 프록시는 브라우저와 시스템 네트워크 설정을 따르는 데스크톱 애플리케이션에 적합하며, 설정이 간단하고 적용 범위가 명확합니다. TUN은 가상 네트워크 인터페이스를 통해 더 넓은 트래픽을 처리하므로 시스템 프록시를 읽지 않거나 UDP만 사용하거나 자체 네트워크 스택을 만드는 프로그램에 유용합니다. 다만 관리자 권한, 라우팅 테이블, DNS 적용, 다른 네트워크 도구와의 충돌이라는 변수가 추가됩니다. 모든 기능을 기본으로 켜기보다는 최소한의 설정에서 시작해 기본 경로가 정상인지 확인한 뒤 적용 범위를 넓히는 것이 좋습니다. 각 플랫폼 장에서 ‘설치, 구독, 시스템 프록시, TUN, 플랫폼별 문제’ 순서를 따르는 이유도 여기에 있습니다.

2. 설치 전 준비: 플랫폼, 아키텍처, 구독 및 권한

시스템과 프로세서 아키텍처 확인

다운로드하기 전에 운영체제 버전, 프로세서 아키텍처, 설치 패키지 유형을 확인해야 합니다. Windows의 일반적인 데스크톱 기기는 x64를 사용합니다. macOS는 Apple Silicon과 Intel을 구분해야 합니다. Linux는 x64와 arm64뿐 아니라 배포판이 deb 또는 rpm 패키지 관리 체계를 사용하는지도 확인해야 합니다. 최근 Android 기기는 대부분 arm64를 사용하며, 아키텍처를 확인할 수 없거나 설치에 실패할 때만 범용 패키지를 고려하세요. 아키텍처를 잘못 선택하면 설치 프로그램이 실행되지 않거나 패키지가 호환되지 않는다는 메시지가 표시되거나, 설치 후 앱이 바로 종료될 수 있습니다. 이는 구독, 노드, 네트워크 상태와 무관하므로 프록시 매개변수를 수정해서 해결할 문제가 아닙니다.

Windows에서는 ‘설정 → 시스템 → 시스템 정보’에서 시스템 종류를 확인할 수 있습니다. macOS에서는 ‘이 Mac에 관하여’를 열어 칩 항목에 Apple 계열 이름이 표시되면 Apple Silicon을, Intel 프로세서가 표시되면 Intel 패키지를 선택하세요. Linux에서는 터미널에서 uname -m을 실행할 수 있습니다. x86_64는 x64에 해당하고, aarch64 또는 arm64는 arm64에 해당합니다. Android 아키텍처는 보통 별도 도구가 필요하지 않습니다. 우선 arm64 패키지를 설치하고 시스템에서 명확히 거부할 때만 범용 패키지를 사용하세요. 출처가 불분명한 확인 사이트에 기기 정보를 업로드하지 마세요.

uname -m

# Debian, Ubuntu 및 파생 배포판에서 패키지 아키텍처 확인
dpkg --print-architecture

# Fedora, Rocky Linux 등 배포판에서 시스템 아키텍처 확인
rpm --eval '%{_arch}'

유효한 구독과 기본 정보 준비

구독 주소는 본질적으로 클라이언트가 설정 모음을 가져오는 진입점이므로 전체 주소를 그대로 유지해야 합니다. 복사할 때 흔히 발생하는 문제는 끝부분 매개변수 누락, 줄바꿈 혼입, 실제 주소가 아닌 웹페이지 표시 문구 복사, 서버 측에서 이미 비활성화된 구독 사용입니다. 구독 이름, 업데이트 주소, 용도를 미리 기록해 두는 것이 좋지만, 계정 식별에 사용되는 토큰이 포함될 수 있으므로 스크린샷, 로그, 공개 문의 글에 전체 주소를 노출하지 마세요. 클라이언트에서는 출처별로 독립적인 그룹을 만들어 여러 구독을 같은 그룹에 덮어쓰지 않도록 해야 노드의 출처를 쉽게 확인할 수 있습니다.

서비스 제공자가 여러 구독 형식을 제공한다면 V2Ray, Xray 또는 해당 클라이언트용이라고 명확히 표시된 형식을 우선 선택하세요. 일반 웹페이지 주소, 관리 콘솔 로그인 주소, 구독 주소는 서로 다른 내용입니다. 가져오기가 성공했다는 기준도 ‘오류 팝업이 없었다’가 아닙니다. 구독 그룹에 식별 가능한 설정 항목이 나타나고, 수동 업데이트 로그에 가져오기와 해석이 완료되었다는 기록이 있어야 합니다. 목록이 비어 있다면 먼저 구독 응답과 형식을 확인하고 TUN, DNS, 라우팅 모드를 바로 바꾸지 마세요.

권한, 시간 및 네트워크 환경

클라이언트의 일반 프록시 기능은 보통 사용자 권한만 필요하지만, TUN은 가상 네트워크 인터페이스 생성, 라우팅 테이블 기록, DNS 변경이 필요할 수 있어 관리자 승인을 요청합니다. 승인은 운영체제의 기본 안내 창에서 처리하세요. 기기가 조직 정책으로 관리된다면 관련 권한이 제한될 수 있으므로 먼저 기기 관리 규정을 확인하고 클라이언트를 반복 실행하지 마세요. Windows 방화벽은 코어를 처음 실행할 때 네트워크 접근 범위를 물을 수 있습니다. macOS는 네트워크 구성을 허용해야 할 수 있고, Linux는 polkit 또는 터미널을 통한 권한 상승을 사용할 수 있습니다. Android에서는 처음 연결할 때 시스템 VPN 승인 대화상자가 표시됩니다. 승인을 거부해도 인터페이스 버튼은 작동하는 것처럼 보일 수 있지만 트래픽 적용은 완전히 구성되지 않습니다.

기기 시간은 TLS 핸드셰이크와 유효 기간이 있는 인증에도 영향을 줍니다. 시스템 자동 시간 동기화를 켜고 시간대가 올바른지 확인하세요. 날짜, 시간 또는 시간대가 틀리면 인증서가 아직 유효하지 않거나 만료되었거나 인증 시간 범위가 맞지 않을 수 있습니다. 또 다른 준비 단계는 네트워크 변수를 일시적으로 줄이는 것입니다. 처음 설정할 때는 다른 프록시, 네트워크 필터, 유사한 가상 네트워크 카드를 끄고 현재 클라이언트만 남기세요. 안정적인 가정용 또는 모바일 네트워크에서 먼저 확인하는 것이 좋습니다. 공용 네트워크에서 인증 페이지를 요구한다면 프록시를 켜기 전에 인증을 완료하세요. 그렇지 않으면 모든 연결이 로그인 페이지로 리디렉션될 수 있습니다.

복구 가능한 설정 습관 만들기

설치 전에 출처가 불분명한 전체 설정을 옮길 필요는 없습니다. 구독 출처 설명, 라우팅 규칙의 목적, 꼭 필요한 일부 설정만 저장한 뒤 새 클라이언트에서 다시 구성하는 편이 안전합니다. 이전 버전 클라이언트를 업데이트할 때는 먼저 실행 중인 코어를 종료한 뒤 현재 설치 방식에 따라 덮어쓰거나 병행 설치하세요. 동일한 로컬 포트를 수신하는 인스턴스를 동시에 실행하지 마세요. 나중에 시작한 프로세스가 주소가 이미 사용 중이라고 보고할 수 있습니다. 포터블 폴더도 자주 쓰기 권한을 요구하는 위치에 두지 않는 것이 좋습니다. 로그, 데이터베이스, 업데이트 파일에는 안정적인 쓰기 권한이 필요합니다.

준비가 끝나면 다운로드 센터에서 플랫폼에 맞는 클라이언트를 선택하세요. 다운로드 페이지에서는 Windows 데스크톱 버전과 클래식 WPF 버전, macOS의 두 칩 아키텍처, Linux의 deb 및 rpm 패키지, Android의 v2rayNG 및 v2flyNG 설치 경로를 제공합니다. 설치 파일 선택은 플랫폼과 아키텍처로 결정되며 구독 프로토콜로 결정되지 않습니다. VMess, VLESS, Trojan 등의 프로토콜은 가져온 뒤 코어 설정에 속하므로 프로토콜마다 다른 클라이언트를 설치할 필요가 없습니다.

3. Windows: v2rayN 설치, 구독 및 시스템 프록시

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

Windows에서는 v2rayN을 우선 사용하세요. 다운로드 센터는 데스크톱 버전과 클래식 WPF 버전을 제공합니다. 데스크톱 버전은 최신 크로스 플랫폼 인터페이스를 사용하므로 macOS, Linux와 비슷한 사용 경험을 원하는 사용자에게 적합합니다. WPF 버전은 기존 Windows 인터페이스 구조를 유지하므로 이전 버전의 메뉴 위치와 조작 방식에 익숙한 사용자에게 적합합니다. 두 버전 모두 구독 관리, 코어 실행, 시스템 프록시 설정에 사용할 수 있지만 인터페이스 배치는 다를 수 있습니다. 두 버전을 동시에 실행하지 마세요. 로컬 수신 포트, 시스템 프록시 상태 또는 설정 폴더를 서로 차지할 수 있습니다.

설치하거나 압축을 풀 때는 일반 사용자가 쓰기 가능한 안정적인 경로를 선택하세요. 설치 프로그램을 사용한다면 시스템 안내에 따라 진행하면 됩니다. 독립 실행형 패키지를 사용한다면 먼저 전체 압축을 푼 뒤 실행하고, 압축 미리보기 창에서 바로 실행하지 마세요. 처음 실행할 때 방화벽 안내가 표시되면 신뢰할 수 있는 현재 네트워크 범위의 접근을 허용하여 로컬 애플리케이션이 클라이언트의 수신 포트에 연결할 수 있도록 하세요. 클라이언트 자체는 보통 LAN에 서비스를 제공할 필요가 없으므로 명확한 이유가 없다면 ‘LAN에서 연결 허용’을 켜지 마세요.

구독 가져오기와 활성 노드 선택

구독 그룹 관리로 이동해 식별하기 쉬운 그룹 이름을 정하고 전체 구독 주소를 붙여넣어 저장하세요. 저장은 출처 기록을 만드는 작업일 뿐이므로, 이후 ‘현재 구독 업데이트’ 또는 ‘모든 구독 업데이트’를 실행해야 합니다. 업데이트가 끝나면 서버 목록으로 돌아가 이름, 주소 유형, 전송 정보가 표시되는지 확인하세요. 노드 수가 많다고 사용할 수 있다는 뜻은 아닙니다. 설정 항목 하나를 활성 서버로 지정한 뒤 실제 연결 테스트를 진행하세요. 업데이트 후에도 목록이 비어 있다면 로그의 HTTP 상태, 해석 오류, 형식 안내를 먼저 확인하고 같은 그룹을 반복해서 만들지 마세요.

지연 시간 테스트는 초기 선별에만 사용할 수 있습니다. 일부 서버는 일반 탐색에 응답하지 않아도 실제 프록시 연결은 가능하고, 반대로 탐색 결과가 정상이어도 실제 핸드셰이크가 실패할 수 있습니다. 더 신뢰할 수 있는 방법은 노드를 선택한 뒤 실제 연결 지연 테스트를 실행하고, 시스템 프록시를 켠 다음 캐시되지 않은 새 웹페이지를 여는 것입니다. 테스트 중에는 로그에서 연결 성공, 핸드셰이크 실패, 시간 초과, 인증 거부가 나타나는지 확인하세요. 노드 선택 방법을 더 자세히 알아보려면 v2rayN 첫 연결 가이드를 참고하세요.

시스템 프록시 모드의 적용 범위

시스템 프록시를 켜면 v2rayN이 Windows 프록시 설정을 로컬 수신 주소로 지정합니다. 시스템 설정을 따르는 브라우저와 데스크톱 프로그램은 HTTP, HTTPS 요청을 클라이언트로 전달하고, 라우팅 규칙이 직접 연결 또는 프록시 여부를 결정합니다. 처음 확인할 때는 ‘시스템 프록시 자동 설정’ 또는 인터페이스에서 이에 해당하는 표준 모드를 사용하고 기본 로컬 포트를 유지하세요. 노드를 바꿀 때 일반적으로 시스템 프록시를 끌 필요는 없습니다. 클라이언트가 새 활성 설정으로 이후 연결을 처리하기 때문입니다. 이미 만들어진 장시간 연결은 기존 경로를 계속 사용할 수 있으므로 필요하면 애플리케이션을 다시 여세요.

명령줄 프로그램이 Windows 그래픽 인터페이스의 시스템 프록시를 반드시 읽는 것은 아닙니다. PowerShell, 패키지 관리자, 개발 도구는 각각 다른 프록시 규칙을 사용합니다. 환경 변수를 읽는 프로그램도 있고, 별도 매개변수가 필요한 프로그램도 있으며, WinHTTP를 직접 사용하는 경우도 있습니다. ‘브라우저는 되는데 터미널은 안 됨’이라는 상황은 노드가 갑자기 고장 난 것이 아니라 애플리케이션별 프록시 방식이 다르다는 뜻일 수 있습니다. 먼저 WinHTTP의 현재 상태를 확인할 수 있지만, 이를 브라우저 프록시와 동일하게 보아서는 안 됩니다.

netsh winhttp show proxy

# 현재 세션에 프록시 환경 변수가 설정되어 있는지 확인
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

현재 터미널 세션에서만 로컬 SOCKS 또는 HTTP 진입점을 사용하려면 사용하는 도구의 문서에 따라 임시 매개변수를 설정하고 세션을 종료할 때 복원하세요. 영향 범위를 모르는 상태에서 프록시 환경 변수를 시스템 전체 설정에 기록하지 마세요. 클라이언트가 실행되지 않으면 해당 프로그램이 존재하지 않는 로컬 포트에 계속 연결을 시도할 수 있습니다. 브라우저와 터미널을 나누어 점검하는 전체 절차는 시스템 프록시가 적용되지 않을 때에서 확인할 수 있습니다.

TUN, 권한 및 Windows 특유의 문제

TUN 모드는 시스템 프록시를 읽지 않거나 UDP가 필요하거나 더 많은 애플리케이션을 통합적으로 처리하려는 경우에 적합합니다. 활성화하기 전에 다른 유사 클라이언트를 종료하고 시스템 승인으로 가상 인터페이스를 생성한 뒤 v2rayN 로그에서 인터페이스 초기화, 라우팅 기록, DNS 수신이 완료되는지 확인하세요. 켠 직후 인터넷이 끊기면 먼저 TUN을 끄고 시스템 프록시를 복원하여 기본 연결이 여전히 정상인지 확인합니다. 이후 다른 가상 네트워크 카드, 기업용 네트워크 소프트웨어, 게임 가속기, 보안 프로그램이 라우팅 테이블을 함께 수정하는지 점검하세요. 기본 라우팅을 담당하는 도구는 한 번에 하나만 남기는 것이 좋습니다.

Windows가 절전 모드에 들어갔거나 네트워크가 전환되었거나 클라이언트가 비정상 종료된 뒤 시스템 프록시가 켜진 상태로 남을 수 있습니다. 대표적인 현상은 v2rayN이 종료되었는데도 브라우저가 로컬 수신 포트에 접속하려는 것입니다. 클라이언트를 다시 시작한 뒤 시스템 프록시를 정상적으로 끄면 대개 복구됩니다. Windows 프록시 설정에서 수동 프록시가 꺼져 있는지 직접 확인할 수도 있습니다. 문제가 확실하지 않은 상태에서 모든 네트워크 카드를 삭제하거나 전체 네트워크 프로토콜을 초기화하지 마세요. 무선 네트워크, 가상화 환경, 기업용 설정까지 영향을 받을 수 있습니다. 로그에 포트 사용 중이라는 메시지가 표시되면 먼저 중복 인스턴스를 종료하고 시스템 도구로 수신 프로세스를 확인하세요.

netstat -ano | findstr LISTENING

# 시스템 DNS 캐시를 확인하고 문제 해결 전에 현재 상태를 기록
ipconfig /displaydns

4. macOS: 칩 아키텍처, 네트워크 권한 및 프록시 적용

칩에 맞는 v2rayN 설치 패키지 선택

macOS에서 v2rayN을 사용할 때 첫 단계는 올바른 아키텍처를 선택하는 것입니다. Apple Silicon 기기는 arm64 설치 패키지를, Intel 기기는 x64 설치 패키지를 사용합니다. 시스템의 ‘이 Mac에 관하여’에 표시되는 칩 또는 프로세서 정보가 판단 기준입니다. 아키텍처가 맞지 않으면 앱이 열리지 않거나 호환 변환 계층에 의존해야 실행될 수 있으므로 이를 구독 문제로 오해하지 마세요. 설치할 때는 앱을 일반적인 응용 프로그램 폴더에 넣고, 다운로드 폴더나 디스크 이미지에서 계속 직접 실행하지 않는 것이 좋습니다. 설정 저장, 업데이트, 권한 기록에는 안정적인 경로가 필요합니다.

처음 열 때 시스템에서 앱 출처 또는 네트워크 권한 확인을 요청할 수 있습니다. 시스템 설정의 개인정보 보호 및 보안 화면에서 현재 앱에 대한 안내를 처리하고, 앱을 반복해서 복사해 여러 인스턴스를 만들지 마세요. 클라이언트 인터페이스는 열리지만 코어가 시작되지 않는다면 먼저 앱 로그에서 실행 파일 권한, 권한 부족, 아키텍처 오류가 표시되는지 확인하세요. 코어가 시작되어 로컬 수신 포트를 열어야 시스템 프록시와 TUN이 사용할 진입점이 생깁니다.

구독 관리와 노드 확인

v2rayN에서 독립적인 구독 그룹을 만들고 전체 주소를 입력한 뒤 직접 업데이트하세요. macOS의 구독 작업 흐름은 Windows와 같습니다. 구독 출처를 저장하고, 업데이트를 실행하고, 목록을 확인하고, 활성 노드를 선택한 다음 실제 연결을 검증합니다. 클립보드에 앞뒤 공백이나 줄바꿈이 포함되어 있다면 주소를 깨끗하게 다시 복사하세요. 구독 응답 시간 초과는 현재 네트워크, DNS, 서버 상태에서 발생할 수 있으며, 해석 실패는 형식 불일치일 가능성이 더 큽니다. 두 오류는 해결 방향이 다르므로 실행 로그의 첫 번째 명확한 오류가 최종 인터페이스 안내보다 유용한 경우가 많습니다.

연결 확인은 TUN을 바로 켜지 말고 시스템 프록시부터 사용하세요. 시스템 프록시는 현재 네트워크 서비스의 프록시 설정을 변경하므로 Safari와 대부분의 시스템 네트워크 설정을 따르는 앱이 해당 진입점을 사용합니다. 켠 뒤에는 터미널에서 시스템 프록시 상태를 확인하여 HTTP, HTTPS 또는 SOCKS 항목이 로컬 주소를 가리키는지 점검할 수 있습니다.

scutil --proxy

# 현재 시스템의 기본 라우팅 확인
route -n get default

scutil --proxy는 시스템 설정이 기록되었다는 것만 보여 줄 뿐, 노드 연결 성공을 의미하지는 않습니다. 실제 웹페이지를 열고 클라이언트 로그를 계속 확인해야 합니다. 시스템 프록시가 활성화되어 있는데도 앱 요청이 로그에 나타나지 않는다면 해당 앱이 독립 프록시를 사용하는지, 우회 규칙이 켜져 있는지, 프록시를 켜기 전에 만든 연결을 재사용하는지 확인하세요. 앱을 종료했다가 다시 열면 연결 재사용으로 인한 영향을 배제할 수 있습니다.

시스템 프록시와 네트워크 서비스별 설정

macOS는 무선 네트워크, 유선 네트워크, 기타 네트워크 서비스에 설정을 각각 저장합니다. 네트워크를 전환하면 프록시 상태를 다시 적용해야 할 수 있습니다. v2rayN에는 시스템 프록시가 켜진 것으로 표시되지만 새로 연결한 네트워크가 계속 직접 연결된다면 시스템 프록시를 한 번 껐다가 다시 켜서 현재 활성 서비스에 설정을 기록하세요. 공용 네트워크에 인증 페이지가 있다면 프록시를 끄고 인증을 완료한 뒤 다시 활성화해야 합니다. 그렇지 않으면 인증 리디렉션이 프록시로 전달되어 모든 페이지가 열리지 않을 수 있습니다.

터미널 도구와 그래픽 앱 사이에도 프록시 처리 방식의 차이가 있습니다. 일부 명령은 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 환경 변수를 읽고, 일부 도구는 그래픽 시스템 프록시를 무시합니다. 현재 터미널 세션에서만 변수를 설정하면 터미널을 닫을 때 다른 작업에 영향을 주지 않아 복구하기 쉽습니다. v2rayN의 로컬 진입점이 장기간 같은 포트를 유지하고 클라이언트가 실행되지 않았을 때 취소하는 방법까지 알고 있는 경우가 아니라면 고정 포트를 전역 셸 설정에 기록하지 마세요.

TUN과 네트워크 확장 기능의 충돌

macOS에서 TUN을 활성화하면 시스템이 네트워크 관련 권한을 요청할 수 있습니다. 권한을 승인한 뒤 로그에서 가상 인터페이스가 생성되고 라우팅이 기록되었는지 확인하세요. 연결 버튼을 켠 직후 네트워크가 완전히 끊기면 다른 네트워크 도구가 실행 중인지, 병렬 필터 확장이 있는지, 여러 프로그램이 DNS를 동시에 변경하는지, 절전 모드 복귀 후 이전 인터페이스가 해제되지 않았는지 확인합니다. 먼저 다른 트래픽 적용 도구를 끄고 v2rayN을 다시 시작한 뒤 시스템 재시작이 필요한지 판단하세요. 정체를 모르는 시스템 네트워크 서비스를 바로 삭제하지 마세요.

TUN은 보통 시스템 프록시보다 적용 범위가 넓어 LAN 기기 검색, 프린터 서비스, 개발 환경에도 더 큰 영향을 줄 수 있습니다. TUN을 켠 뒤 인터넷은 되지만 LAN 주소에 접근할 수 없다면 사설 주소 직접 연결 등 라우팅 규칙이 유지되는지 확인하세요. 예를 들어 geoip:private 또는 이에 해당하는 LAN 규칙이 일반 프록시 규칙보다 앞에 있어야 합니다. 규칙 순서가 잘못되면 LAN 요청이 원격 아웃바운드로 전달되어 기기가 응답하지 않습니다. 로컬 서비스를 이용해야 한다면 LAN 직접 연결 유지는 TUN 활성화 전 필수 점검 항목으로 삼으세요.

앱이 종료되지 않거나 시스템 프록시가 복원되지 않으면 먼저 v2rayN에서 시스템 프록시를 끈 다음 정상적으로 종료하세요. 앱이 이미 비정상 종료되었다면 시스템 네트워크 설정에서 현재 네트워크 서비스의 프록시 항목을 확인하세요. 복원한 뒤 클라이언트를 다시 시작하고 기본 설정으로 연결을 한 번 확인합니다. 같은 문제가 반복될 때만 로그를 바탕으로 권한, 인터페이스, 앱 수명 주기 문제인지 판단하세요.

5. Linux: 패키지, 데스크톱 프록시, 환경 변수 및 TUN

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

Linux에서 v2rayN을 사용하려면 아키텍처와 소프트웨어 패키지 체계를 모두 확인해야 합니다. Debian, Ubuntu 및 파생 배포판은 일반적으로 deb를 사용하고, Fedora, Rocky Linux 등은 보통 rpm을 사용합니다. x64 기기는 x64 패키지를, arm64 기기는 arm64 패키지를 선택하세요. 패키지 형식이 틀리면 패키지 관리자가 바로 거부하고, 아키텍처가 틀리면 실행되지 않거나 의존성을 충족할 수 없습니다. 설치 전에 uname -m으로 아키텍처를 확인하고 배포판에 내장된 패키지 관리자로 설치하면 데스크톱 메뉴, 의존성, 제거 기록을 일관되게 유지하기 쉽습니다.

# deb 패키지 설치 예시, 파일 이름은 실제 다운로드 결과에 따름
sudo apt install ./v2rayN-linux-x64.deb

# rpm 패키지 설치 예시, 파일 이름은 실제 다운로드 결과에 따름
sudo dnf install ./v2rayN-linux-x64.rpm

위 명령은 로컬 소프트웨어 패키지를 설치하는 방법만 보여 줍니다. 파일 이름은 다운로드 센터에서 실제로 받은 파일을 기준으로 해야 합니다. 패키지 관리자가 의존성 문제를 표시하면 먼저 현재 배포판의 소프트웨어 저장소를 갱신하고 시스템 의존성을 처리하세요. 출처가 불분명한 곳에서 공유 라이브러리를 임의로 조합하지 마세요. 그래픽 앱을 실행한 뒤에는 현재 사용자가 설정 폴더에 쓸 수 있어야 합니다. 전체 데스크톱 클라이언트를 root 권한으로 계속 실행하지 마세요. TUN 생성이나 라우팅 변경이 필요할 때만 시스템 승인을 통해 해당 네트워크 작업에 필요한 권한을 높이세요.

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

구독 절차는 다른 데스크톱 플랫폼과 같습니다. 그룹을 만들고 주소를 붙여넣고 저장한 뒤 직접 업데이트하고 활성 노드를 선택하세요. 앱이 클립보드 내용을 읽지 못하면 일반 텍스트 편집기에서 주소가 완전한지 확인한 뒤 붙여넣으세요. Wayland와 X11은 클립보드, 트레이, 창 동작이 다를 수 있지만 구독 형식은 바뀌지 않습니다. 트레이 아이콘이 보이지 않는다고 코어가 실행되지 않는 것은 아닙니다. 클라이언트 주 창과 프로세스 로그를 기준으로 확인하세요. 일부 데스크톱 환경은 기존 트레이 항목을 표시하려면 확장이 필요합니다.

구독을 업데이트한 뒤에는 먼저 서버 목록에 내용이 나타나는지 확인하고 코어를 시작하세요. 로그에 로컬 포트가 이미 사용 중이라고 표시되면 ss로 수신 상태를 확인할 수 있습니다. 포트가 있다는 이유만으로 시스템 프로세스를 바로 종료하지 말고, 다른 v2rayN 인스턴스, 남아 있는 코어, 다른 프록시 프로그램이 같은 포트를 사용하는지 먼저 확인하세요.

ss -lntp

# 현재 사용자 세션의 프록시 변수 확인
env | grep -i proxy

# 기본 라우팅 확인
ip route show default

데스크톱 시스템 프록시와 환경 변수

Linux에는 모든 데스크톱 및 명령줄 프로그램에 적용되는 통합 프록시 설정이 없습니다. GNOME, KDE 같은 데스크톱 환경은 그래픽 프록시를 저장할 수 있지만 브라우저가 이를 읽는지는 브라우저 설정에 따라 달라집니다. 터미널 프로그램은 보통 환경 변수나 자체 설정으로 프록시를 결정합니다. v2rayN이 시스템 프록시를 기록한 뒤에는 현재 데스크톱 브라우저로 먼저 확인하고 터미널 도구는 별도로 점검하세요. 터미널이 직접 연결된다고 시스템 프록시 전체가 실패했다고 판단하지 말고, 브라우저가 된다고 모든 백그라운드 서비스가 자동으로 프록시를 사용한다고 가정하지도 마세요.

특정 터미널 세션에서 로컬 HTTP 진입점을 사용해야 한다면 환경 변수를 임시로 설정할 수 있습니다. SOCKS가 필요하다면 대상 도구가 해당 변수와 해석 방식을 지원하는지 확인하세요. 임시 설정에는 v2rayN 인터페이스에 표시된 실제 수신 주소와 포트를 사용해야 합니다. 아래에서는 루프백 주소와 일반적인 로컬 포트로 문법을 보여 줍니다.

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, 권한 및 DNS

Linux의 TUN은 시스템 가상 네트워크 인터페이스, 라우팅, 권한에 의존합니다. 활성화하기 전에 시스템이 TUN 장치를 지원하는지 확인하고 기본 라우팅을 변경하는 다른 프로그램을 종료하세요. v2rayN이 권한 상승을 요청하면 현재 필요한 네트워크 작업만 승인합니다. 활성화 후에는 ip addr와 ip route로 인터페이스 및 라우팅 변화를 확인할 수 있습니다. 기본 라우팅이 잘못 바뀌었다면 먼저 클라이언트에서 TUN을 끈 뒤 다시 점검하세요. 원격으로 관리하는 기기에서는 특히 주의해야 합니다. 잘못된 라우팅으로 현재 원격 연결이 끊길 수 있습니다.

DNS는 systemd-resolved, NetworkManager, 데스크톱 환경, 수동 설정 파일이 함께 관리할 수 있습니다. TUN을 켠 뒤 웹페이지의 도메인은 해석되지 않지만 이미 알고 있는 주소에는 응답이 있다면 DNS 요청이 클라이언트로 들어가는지, 시스템이 현재 어떤 해석기를 가리키는지, 다른 네트워크 도구가 설정을 덮어쓰는지 먼저 확인하세요. 문제를 감추기 위해 시스템 해석 파일을 계속 직접 수정하지 마세요. 다음 연결 때 네트워크 관리자가 파일을 다시 만들 수 있습니다. 시스템, 클라이언트, 로컬 해석 서비스 중 어느 하나가 DNS를 담당할지 명확히 정하고 여러 구성 요소가 같은 수신 포트를 놓고 경쟁하지 않도록 해야 합니다.

Linux에서 가장 안정적인 문제 해결 방식은 계층별 점검입니다. 먼저 v2rayN 그래픽 인터페이스와 코어가 실행되는지 확인하고, 다음으로 브라우저의 시스템 프록시를 검증한 뒤 터미널 환경 변수를 테스트하고 마지막에 TUN을 활성화하세요. 각 계층에서 명확한 결과를 남기면 문제가 데스크톱 설정, 앱 구성, 권한, 라우팅, DNS 중 어디에 있는지 알 수 있습니다. 로그에 timeout, rejected, 해석 오류가 반복되면 실행 로그 읽는 법을 참고해 구체적인 단계를 찾으세요.

6. Android: v2rayNG, v2flyNG 및 앱별 라우팅

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

Android에서는 v2rayNG를 우선 사용하세요. Xray 코어를 기반으로 하며 일반적인 구독과 라우팅 설정에 적합합니다. V2Fly 코어가 필요하다면 v2flyNG를 대안으로 사용할 수 있습니다. 두 클라이언트 모두 시스템 VPN 인터페이스로 트래픽을 처리하지만 코어 지원 범위, 설정 이름, 설정 저장 방식이 완전히 같다고 보장할 수는 없습니다. 클라이언트를 바꿀 때는 기존 앱의 데이터 폴더를 복사하지 말고 원본 구독을 다시 가져오세요. 최근 주류 기기는 arm64 패키지를 우선 사용하고, 아키텍처를 확인할 수 없거나 arm64 설치가 거부될 때만 범용 패키지를 사용하세요.

설치가 끝난 뒤 처음 연결하면 시스템에서 VPN 승인 안내를 표시합니다. 허용하면 상태 표시줄에 시스템이 관리하는 연결 표시가 나타납니다. 이 표시는 가상 인터페이스가 만들어졌다는 뜻일 뿐 원격 노드를 사용할 수 있다는 의미는 아닙니다. 실제 확인은 클라이언트 로그와 실제 웹 요청을 함께 봐야 합니다. 기기에 이미 시스템 VPN 인터페이스를 사용하는 다른 도구가 있다면 새 클라이언트 연결 시 기존 연결이 종료될 수 있습니다. 두 앱이 하나의 시스템 인터페이스를 동시에 제어할 수는 없습니다.

구독 가져오기, 업데이트 및 노드 선택

v2rayNG 또는 v2flyNG에서 구독 그룹 설정을 열고 전체 구독 주소를 추가한 뒤 이름을 지정하고 저장 후 업데이트를 실행하세요. 일부 시스템은 백그라운드 네트워크 접근을 제한합니다. 업데이트가 멈춰 있거나 즉시 실패한다면 앱을 전면에 둔 상태에서 현재 네트워크가 구독 출처에 접근할 수 있는지 확인하세요. 업데이트가 성공하면 설정 목록이 나타나야 합니다. 그중 하나를 활성 설정으로 선택한 뒤 실제 연결을 테스트하세요. QR 코드는 단일 설정을 가져오는 데 적합하고 구독은 장기 업데이트에 적합합니다. 용도가 다르므로 단일 노드 QR 코드를 자동 업데이트되는 구독 그룹으로 간주하지 마세요.

노드 목록에 표시되는 지연 시간은 판단을 돕는 참고값일 뿐입니다. 모바일 네트워크는 기지국 전환, 약한 신호, 절전 상태에서 변동이 커서 한 번의 결과로 지속적인 품질을 판단할 수 없습니다. 노드를 선택해 연결한 뒤 새 브라우저 페이지를 열고 즉시 로그에서 실제 요청이 발생했는지 확인하세요. 인터페이스 시작 정보만 있고 아웃바운드 기록이 없다면 앱 트래픽이 클라이언트로 들어오지 않았을 수 있습니다. timeout, TLS, 인증 오류가 나타난다면 트래픽은 들어온 것이며 문제는 원격 연결 또는 설정 매개변수에 있습니다.

시스템 VPN 인터페이스와 앱별 라우팅

Android 클라이언트는 보통 앱별로 프록시 적용 여부를 결정할 수 있습니다. 앱별 라우팅에는 선택한 앱만 포함하는 방식과 대부분의 앱을 포함하고 일부 앱만 제외하는 방식이 있습니다. 규칙이 복잡할수록 새 앱을 설치했을 때 빠뜨리기 쉽습니다. 처음에는 앱별 라우팅을 끄고 전체 적용이 정상인지 확인한 다음 필요에 따라 허용 목록 또는 제외 목록을 만드세요. ‘브라우저는 되는데 특정 앱은 안 됨’이라면 먼저 해당 앱이 제외되었는지 확인하고 서버 매개변수부터 바꾸지 마세요.

일부 앱은 IP를 직접 사용하거나 특정 UDP 트래픽을 사용하거나 기존 HTTP 프록시를 따르지 않습니다. 따라서 Android 클라이언트는 시스템 VPN 인터페이스를 통해 데스크톱 시스템 프록시보다 폭넓게 트래픽을 처리할 수 있습니다. 동시에 로컬 LAN, 화면 공유, 프린터, 기기 검색도 영향을 받을 수 있습니다. 같은 네트워크의 기기에 접근해야 한다면 LAN 우회 또는 사설 주소 직접 연결 규칙을 설정하세요. 앱별 라우팅과 코어 라우팅 규칙이 함께 있으면 시스템이 먼저 클라이언트 진입 여부를 결정하고, 진입한 뒤에야 코어 라우팅이 아웃바운드를 결정합니다. 시스템 분류에서 제외된 앱은 코어 규칙과 다시 매칭되지 않습니다.

백그라운드 제한, 배터리 및 네트워크 전환

Android의 배터리 절전 정책은 클라이언트의 백그라운드 실행을 제한할 수 있습니다. 대표적인 현상은 화면을 잠근 뒤 일정 시간이 지나 연결이 끊기거나, 화면을 다시 켜면 복구되거나, 시스템이 백그라운드를 정리한 뒤 상태 표시가 사라지는 것입니다. 시스템 앱 설정에서 필요한 백그라운드 활동을 허용하고 공격적인 자동 정리 기능은 피하세요. 기기마다 설정 메뉴 이름은 다르지만 기준은 같습니다. 화면이 꺼진 뒤에도 클라이언트의 시스템 VPN 서비스가 계속 실행되어야 합니다. 네트워크와 관계없는 권한까지 부여할 필요는 없습니다.

무선 네트워크에서 모바일 네트워크로 전환하면 기존 연결이 끊기고 코어가 아웃바운드를 다시 설정해야 할 수 있습니다. 전환 후 오랫동안 복구되지 않으면 클라이언트에서 한 번 중지했다가 다시 시작하세요. 구독을 삭제할 필요는 없습니다. 공용 Wi-Fi에서 웹 인증을 요구하면 클라이언트 연결을 먼저 끊고 인증을 완료한 뒤 다시 연결하세요. 무선 네트워크는 되지만 모바일 네트워크가 실패한다면 모바일 네트워크의 DNS, IPv6, 통신사 접속 차이를 확인하세요. 모든 노드가 특정 네트워크에서만 실패한다면 모든 구독이 동시에 만료된 것보다 네트워크 경로 문제일 가능성이 큽니다.

‘항상 켜기’와 같은 시스템 옵션을 활성화하기 전에 클라이언트가 안정적으로 작동하는지 확인하고 시스템의 차단 정책을 이해해야 합니다. ‘연결되지 않으면 네트워크 차단’을 함께 켜면 클라이언트가 비정상 종료되거나 업데이트되는 동안 다른 앱도 인터넷을 사용할 수 없습니다. 이 설정은 장기간 검증을 마친 구성에 적합하며 처음 설치할 때 기본으로 적용할 항목은 아닙니다. 인터넷이 끊겼을 때는 시스템 VPN 화면에서 이런 제한이 켜져 있는지 확인하여 시스템의 의도적인 차단을 노드 문제로 오해하지 않도록 하세요.

v2rayNG와 v2flyNG는 로그 메뉴 위치가 다를 수 있지만 문제 해결 방식은 같습니다. 반복 재시도 후 쌓인 정보보다 첫 실패 전후의 오류에 주목하세요. 로그를 공유할 때는 구독 주소, 사용자 식별자, 서버 주소 등 민감한 내용을 삭제하고 오류 유형, 발생 단계, 시스템 환경만 남기세요. 클라이언트에는 연결됨으로 표시되지만 웹페이지에 접속할 수 없다면 프록시는 연결됐지만 인터넷이 되지 않을 때 점검 목록을 참고하세요.

7. 라우팅, DNS 및 TUN: 기본 규칙부터 관리 가능한 분류까지

라우팅 규칙의 매칭 순서

라우팅은 클라이언트로 들어온 요청을 어떤 아웃바운드로 보낼지 결정합니다. 일반적인 아웃바운드는 직접 연결, 프록시, 차단입니다. 규칙은 보통 위에서 아래로 매칭되며 일치하면 이후 규칙을 더 확인하지 않습니다. 따라서 구체적인 규칙을 일반 규칙보다 앞에 둬야 합니다. 예를 들어 LAN과 명확한 직접 연결 도메인을 먼저 처리하고, 마지막에 나머지 트래픽을 프록시로 보내는 기본 규칙을 둡니다. ‘전체 프록시’를 맨 앞에 두면 뒤의 LAN 직접 연결 규칙은 작동하지 않습니다. 반대로 범위가 지나치게 넓은 직접 연결 규칙을 앞에 두면 프록시가 필요한 요청도 조기에 빠져나갈 수 있습니다.

도메인 규칙과 IP 규칙은 서로 다른 단계의 문제를 해결합니다. 요청에 처음부터 도메인만 있다면 geosite 또는 명시적인 도메인 규칙과 매칭할 수 있고, 해석 후 IP를 얻으면 geoip, 사설 주소 또는 네트워크 대역 규칙과 매칭할 수 있습니다. 하나의 연결에 도메인과 대상 IP가 모두 있을 수 있지만 클라이언트가 얻는 정보는 진입 프로토콜, DNS 흐름, 앱 동작에 따라 달라집니다. 특히 IP로 직접 연결하는 앱은 도메인 규칙을 거치지 않으므로 단일 규칙에 모든 상황을 맡기지 마세요. 더 완전한 규칙은 일반적으로 도메인 집합, IP 집합, 최종 기본 규칙을 함께 유지합니다.

권장 기본 라우팅 구조

기본 설정은 세 계층으로 시작할 수 있습니다. LAN과 사설 주소는 직접 연결하고, 로컬 네트워크 환경에 해당하는 사이트와 주소 집합도 직접 연결하며, 나머지 요청은 프록시로 보냅니다. 차단 규칙을 추가할지는 실제 필요에 따라 별도로 관리하고, 영향 범위를 확인하지 않은 대규모 도메인 목록을 그대로 합치지 마세요. 아래 JSON 조각은 Xray 스타일 라우팅 구조의 핵심 관계를 보여 줍니다. 실제 그래픽 클라이언트에서는 라우팅 설정 화면을 통해 동일한 규칙을 구성할 수 있습니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

domainStrategy는 도메인 규칙이 일치하지 않을 때 IP를 추가로 해석할지 제어합니다. IPIfNonMatch는 먼저 도메인 매칭을 시도하고, 일치하지 않으면 IP를 해석해 IP 규칙을 다시 시도한다는 뜻입니다. 그렇다고 무조건 적극적인 설정이 좋은 것은 아닙니다. 추가 해석은 DNS 관여를 늘리고, 반대로 전혀 해석하지 않으면 도메인 요청이 IP 규칙과 매칭되지 않을 수 있습니다. 그래픽 클라이언트에서는 이 매개변수를 ‘도메인 전략’ 드롭다운으로 표시할 수 있습니다. 변경하기 전에 해결하려는 문제를 명확히 하고, 옵션이 더 포괄적으로 보인다는 이유만으로 전환하지 마세요.

DNS 요청이 연결에 영향을 주는 이유

DNS는 도메인을 주소로 변환하며, 이 작업은 시스템이 수행할 수도 있고 클라이언트가 전달하거나 가로채거나 규칙에 따라 분류할 수도 있습니다. 흔한 문제로는 시스템이 접근할 수 없는 주소를 받는 경우, 클라이언트와 시스템이 서로 다른 결과를 사용하는 경우, TUN 적용 후 DNS 요청이 예상한 수신 포트로 들어오지 않는 경우, IPv4와 IPv6 반환 순서가 현재 네트워크에 맞지 않는 경우가 있습니다. 도메인 접속 실패, 주소 직접 접속은 가능함, 특정 사이트만 계속 시간 초과가 발생함 등의 형태로 나타날 수 있습니다. 이때 노드를 계속 바꾸는 것은 증상을 우연히 피할 뿐 해석 경로를 고치지 못합니다.

DNS를 점검할 때는 먼저 세 가지 질문에 답하세요. 앱이 조회를 어디에 맡기는가, 해석 요청은 어떤 아웃바운드로 전송되는가, 최종적으로 어떤 유형의 주소가 반환되는가입니다. 시스템 프록시 모드에서 브라우저는 보안 DNS를 자체 처리할 수도 있고 시스템에 맡길 수도 있습니다. TUN 모드에서는 클라이언트가 더 많은 조회를 처리할 수 있습니다. 브라우저에 독립 DNS 설정이 켜져 있으면 시스템과 클라이언트가 예상한 경로를 우회할 수 있습니다. 먼저 브라우저의 기본 네트워크 설정으로 확인한 뒤 사용자 지정 DNS를 추가할지 결정하세요. 여러 DNS 방식을 동시에 켜면 로그와 결과를 서로 연결하기 어려워집니다.

시스템 프록시와 TUN 선택 방법

먼저 시스템 프록시로 기본 연결을 확인한 뒤 TUN이 필요한지 결정하세요. 대상 앱이 이미 시스템 프록시로 작동한다면 TUN을 켠다고 노드 품질이 향상되는 것은 아니며 트래픽 진입 방식만 바뀝니다. 시스템 프록시를 읽지 않거나 UDP가 필요하거나 통합 관리가 필요한 앱이 있을 때만 TUN을 활성화하고 LAN 직접 연결은 유지하세요. 활성화하기 전에 현재 시스템 프록시, DNS, 다른 가상 네트워크 카드의 상태를 기록해 두어야 문제가 생겼을 때 복구할 수 있습니다.

규칙 변경 검증 방법

한 번에 하나의 규칙 그룹만 변경하고 명확한 대상으로 검증하세요. 예를 들어 LAN 직접 연결을 추가했다면 LAN 기기와 인터넷을 각각 한 번씩 테스트합니다. geosite 규칙을 바꿨다면 로그에서 대상 도메인과 최종 아웃바운드를 확인하세요. DNS를 조정했다면 새 도메인과 이미 캐시된 도메인을 각각 테스트합니다. 대규모 규칙을 한꺼번에 가져오고 DNS를 바꾸고 TUN을 켜면서 노드까지 교체하면 성공하거나 실패해도 어떤 변경이 원인이었는지 알 수 없습니다.

라우팅 규칙 이름은 ‘LAN 직접 연결’, ‘주요 로컬 도메인 직접 연결’, ‘나머지 프록시’처럼 목적을 표현해야 하며 이해하기 어려운 임시 번호를 사용하지 않는 것이 좋습니다. 장기적으로 관리할 때는 먼저 규칙의 목적을 적고 매칭 조건과 아웃바운드를 기록하세요. 구독 업데이트는 일반적으로 서버 설정만 갱신하며 사용자 지정 라우팅을 덮어쓰지 않아야 합니다. 다만 클라이언트마다 가져오기 방식이 달라 현재 선택에 영향을 줄 수 있으므로 업데이트 후 동작이 바뀌었다면 활성 라우팅 설정이 여전히 올바른지 확인하세요.

8. 일반적인 설정 문제와 계층별 해결

먼저 데이터 경로에서 문제가 발생한 계층 찾기

효율적인 문제 해결은 ‘클라이언트 재설치’에서 시작하지 않고 요청이 어느 계층에서 멈췄는지 판단하는 데서 시작합니다. 첫 번째 계층은 구독 가져오기입니다. 업데이트하고 해석하여 노드를 생성할 수 있는지 확인합니다. 두 번째는 코어 시작입니다. 설정을 불러오고 로컬 포트를 열 수 있는지 확인합니다. 세 번째는 원격 연결입니다. 노드가 DNS, TCP, TLS, 프로토콜 핸드셰이크를 완료할 수 있는지 확인합니다. 네 번째는 앱 적용입니다. 시스템 프록시, 환경 변수, 시스템 VPN 인터페이스가 트래픽을 클라이언트로 보내는지 확인합니다. 다섯 번째는 라우팅과 DNS입니다. 들어온 요청이 올바른 아웃바운드를 선택하는지, 도메인이 접근 가능한 주소로 해석되는지 확인합니다. 각 계층에는 독립적인 근거가 있으므로 가장 먼저 실패한 지점을 찾으세요.

로그를 읽을 때는 한 번의 작업에 해당하는 시간대를 집중해서 확인하세요. 먼저 현재 위치를 비우거나 기억한 뒤 구독 업데이트, 연결, 웹페이지 접속 중 하나를 실행하고 새로 생성된 내용을 읽습니다. 이후 계속 재시도하면 timeout이 반복되어 처음 발생한 해석, 권한, 인증 오류가 가려질 수 있습니다. 자주 보이는 키워드 중 timeout은 정해진 시간 안에 완료되지 않았다는 뜻으로, 네트워크 접근 불가, 서비스 무응답, DNS 지연 등이 원인일 수 있습니다. rejected는 규칙, 원격 서버, 프로토콜 조건에 의해 연결이 거부되었다는 뜻입니다. invalid user는 일반적으로 사용자 식별자, 인증 정보, 서버 설정이 일치하지 않을 때 나타납니다. 구체적인 판단은 실행 로그 읽는 법에서 확인할 수 있습니다.

구독 업데이트 실패 또는 업데이트 후 노드가 없음

먼저 구독 주소가 완전하고 줄임표가 표시된 문구를 복사한 것이 아닌지 확인하세요. 주소 앞뒤의 공백과 줄바꿈을 삭제하되 원본 매개변수는 유지합니다. 그런 다음 클라이언트에서 해당 그룹을 한 번 수동 업데이트하고 로그를 확인하세요. 로그에 네트워크 시간 초과가 표시되면 현재 네트워크와 DNS를 점검합니다. 반환 내용을 해석할 수 없다면 선택한 구독 형식이 현재 클라이언트에 맞는지 확인하세요. 응답이 비어 있거나 권한이 거부되었다면 구독 출처에서 상태를 확인해야 합니다. 같은 구독을 계속 새로 추가하지 마세요. 실패한 복사본만 여러 개 생깁니다.

업데이트 성공으로 표시되지만 목록이 비어 있다면 현재 인터페이스에서 그룹, 검색어, 설정 유형 필터가 적용되어 있는지 확인하세요. 노드가 어느 그룹으로 가져와졌는지도 확인해야 합니다. 다른 클라이언트에서 옮겨올 때 내부 데이터베이스를 직접 복사하지 말고 원본 구독을 다시 가져오는 편이 안정적입니다. 구독 업데이트 후 이전 노드가 계속 남아 있다면 클라이언트가 기존 설정을 보존하도록 되어 있을 수 있습니다. 먼저 새 내용이 생성되었는지 확인한 뒤 정리 여부를 결정하고, 출처 정보의 백업 없이 모든 그룹을 한꺼번에 삭제하지 마세요.

클라이언트는 실행되지만 시스템 프록시가 적용되지 않음

먼저 클라이언트 로그를 열고 브라우저에서 새 요청을 발생시키세요. 로그에 아무 기록도 없다면 문제는 앱과 로컬 진입점 사이에 있습니다. 시스템 프록시가 기록되지 않았거나, 브라우저가 독립 설정을 사용하거나, 앱이 연결을 다시 만들지 않았거나, 현재 네트워크 서비스에 프록시가 적용되지 않았을 수 있습니다. 로그에 요청은 나타나지만 원격 연결이 실패한다면 시스템 프록시는 적용된 것이므로 노드, DNS, 라우팅을 점검해야 합니다. 이렇게 구분하면 프록시 적용 문제와 서버 문제를 혼동하지 않을 수 있습니다.

Windows와 macOS에서는 시스템 네트워크 설정에서 프록시 상태를 확인할 수 있습니다. Linux는 데스크톱 프록시와 터미널 환경 변수를 각각 점검해야 합니다. Android는 시스템 VPN 승인과 앱별 라우팅을 확인하세요. 터미널 도구가 브라우저처럼 작동하지 않는 것은 흔한 방식 차이이므로 해당 도구가 지원하는 프록시 매개변수를 확인해야 합니다. 클라이언트를 종료한 뒤 인터넷이 되지 않는다면 시스템 프록시 또는 ‘연결되지 않으면 네트워크 차단’ 설정이 남아 있는지 확인하세요. 관련 데스크톱 점검 절차는 브라우저와 명령줄 터미널을 나누어 점검하기에서 이어서 확인할 수 있습니다.

연결됨으로 표시되지만 웹페이지가 열리지 않음

‘연결됨’은 보통 코어 또는 가상 인터페이스가 시작되었다는 뜻일 뿐입니다. 먼저 실제 연결이 확인된 노드로 전환하고 기기 시간과 시간대가 올바른지 확인하세요. 다음으로 웹 요청이 로그에 들어오는지 확인하고, DNS 오류와 라우팅의 예상 아웃바운드 선택 여부를 점검합니다. 마지막으로 시스템 프록시 또는 TUN이 다른 네트워크 도구와 충돌하는지 확인하세요. 같은 기기와 네트워크에서 모든 노드가 실패하지만 다른 네트워크에서는 작동한다면 현재 네트워크 경로를 우선 조사해야 합니다. 단일 노드만 실패한다면 해당 설정이나 원격 상태일 가능성이 더 큽니다.

Ping 결과를 최종 판단 기준으로 사용하지 마세요. 서버가 일반 탐색에 응답하지 않아도 프록시 프로토콜은 연결될 수 있고, 반대로 주소가 탐색에 응답해도 인증과 TLS 핸드셰이크 성공을 의미하지는 않습니다. 실제 연결 테스트와 실제 웹 요청이 사용 경로에 더 가깝습니다. 전체 점검 목록은 v2rayN 및 v2rayNG 단계별 문제 해결 목록에서 확인할 수 있으며, 노드, 시간, DNS, 라우팅, 시스템 프록시 순서로 항목을 정리했습니다.

TUN을 켠 뒤 인터넷이 끊기거나 LAN에 접근할 수 없음

즉시 클라이언트에서 TUN을 끄고 기본 네트워크가 복구되는지 확인하세요. 복구되지 않으면 시스템 프록시, 시스템 VPN 차단 옵션, 남아 있는 가상 인터페이스를 점검합니다. 기본 네트워크가 복구되면 현재 클라이언트만 남기고 라우팅이나 DNS를 변경하는 다른 프로그램을 종료한 뒤 TUN을 다시 켜고 첫 번째 오류를 확인하세요. 권한 부족은 보통 인터페이스 생성 단계에서 실패하고, 포트 충돌은 수신 단계에서 발생하며, 기본 라우팅 또는 DNS 오류는 인터페이스가 만들어진 뒤 요청 시간 초과로 나타나는 경우가 많습니다.

인터넷은 되지만 LAN에 접근할 수 없다면 사설 주소 직접 연결 규칙이 존재하고 기본 프록시 규칙보다 앞에 있는지 확인하세요. 일반적인 사설 주소와 로컬 링크는 원격 아웃바운드로 보내면 안 됩니다. Android에서는 앱 설정의 LAN 우회를 추가로 확인하고, 데스크톱 플랫폼에서는 방화벽이 새 가상 인터페이스를 부적절한 네트워크 범위로 분류하지 않았는지 확인하세요. 변경 후에는 LAN 주소와 일반 도메인을 각각 테스트해야 하며 한쪽만 확인해서는 안 됩니다.

포트 사용 중, 중복 인스턴스 및 설정 복원

로그에 주소가 이미 사용 중이라고 표시되면 대개 다른 클라이언트 인스턴스, 남은 코어 프로세스, 다른 프록시 프로그램이 같은 포트를 사용하고 있는 것입니다. 먼저 작업 관리자, 활성 상태 보기, 프로세스 목록에서 소유자를 확인한 뒤 해당 프로그램을 정상적으로 종료하세요. 포트를 무작정 바꾸면 현재 인스턴스는 시작될 수 있지만 시스템 프록시, 환경 변수, 앱 내부의 고정 설정도 함께 수정해야 하므로 새로운 불일치가 생길 수 있습니다. 먼저 중복 인스턴스를 해결하고 포트 변경은 그다음에 고려하세요.

문제가 설정 변경 직후 발생했다면 모든 설정을 복원하기보다 가장 최근 항목 하나를 되돌리는 것이 효과적입니다. TUN, 사용자 지정 DNS, 새 라우팅, 앱별 라우팅을 역순으로 끄고 구독과 단일 노드는 유지하세요. 기본 연결이 복구되면 항목을 하나씩 다시 추가합니다. 클라이언트 설정을 더 이상 판단하기 어렵다면 구독 출처를 기록하고 새 최소 설정을 만들어 비교하세요. 새 설정이 작동하면 이전 설정의 충돌을 의미하고, 새 설정도 실패하면 플랫폼 권한, 네트워크, 구독 내용을 계속 점검해야 합니다.

최종 점검 목록

1. 설치 패키지가 현재 플랫폼, 프로세서 아키텍처, 배포판 형식과 일치합니다.
2. 구독 그룹을 직접 업데이트할 수 있고 노드 목록이 비어 있지 않으며 필터 조건에 숨겨져 있지 않습니다.
3. 활성 노드가 실제 연결 테스트를 통과하고 시스템 시간과 시간대가 올바릅니다.
4. 코어가 정상적으로 시작되었고 로컬 수신 포트를 중복 인스턴스가 사용하지 않습니다.
5. 브라우저 또는 대상 앱의 요청이 클라이언트 로그에 나타납니다.
6. 라우팅 규칙이 구체적인 항목부터 일반적인 항목 순서로 배치되고 LAN 및 사설 주소는 직접 연결로 유지됩니다.
7. DNS를 담당하는 단일 경로가 명확하며 여러 도구가 동시에 설정을 덮어쓰지 않습니다.
8. 기본 시스템 프록시를 확인한 뒤에만 TUN을 활성화하고, 문제가 생기면 끄고 복구할 수 있습니다.

위 점검을 완료해도 원인을 찾지 못했다면 문제를 하나의 플랫폼, 하나의 클라이언트, 하나의 구독 그룹, 하나의 노드, 하나의 트래픽 적용 방식으로 좁힌 뒤 전체 재현 과정을 기록하세요. ‘어느 단계에서 실패했는지’를 먼저 설명하고 ‘로그에 무엇이 표시되었는지’를 덧붙이는 편이 단순히 ‘연결할 수 없다’고 말하는 것보다 정확한 판단을 받기 쉽습니다. 가장 짧은 작업 흐름을 다시 진행하려면 빠른 시작 가이드로 돌아가고, 설치 패키지를 바꾸거나 플랫폼별 경로를 확인하려면 다운로드 센터로 이동하세요.