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

// 01 · PREPARE

공통 준비 작업 및 설정 범위

클라이언트를 설치하기 전에 플랫폼, 프로세서 아키텍처, 구독 출처와 트래픽을 가로챌 범위를 먼저 정하세요. 설치 실패의 대부분은 클라이언트 자체의 문제가 아니라 잘못된 설치 패키지 아키텍처, 포트를 점유한 이전 프로세스, 시스템 시간 오차 또는 서버와 맞지 않는 구독 매개변수에서 발생합니다. 준비 단계에서 이러한 변수를 확정하면 네 플랫폼의 후속 작업을 훨씬 명확하게 진행할 수 있습니다.

클라이언트와 플랫폼 대응 관계

데스크톱에서는 v2rayN을 공통으로 사용합니다. Windows, macOS, Linux를 지원하며 구독 그룹, 서버 목록, 시스템 프록시, TUN, 라우팅 규칙과 로그 확인 기능을 그래픽 화면에서 제공합니다. Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 선택하고, v2fly 코어가 필요하면 v2flyNG를 사용할 수 있습니다. 두 Android 클라이언트의 화면 구성과 설정 가져오기 방식은 비슷하지만 코어 기능, 일부 실험 옵션과 설정 호환 범위가 다를 수 있으므로 동일한 고급 설정을 완전히 같은 것으로 간주해서는 안 됩니다.

설치 패키지의 아키텍처는 기기의 프로세서와 일치해야 합니다. Windows의 일반적인 기기는 x64를 선택하고, macOS는 Apple Silicon인지 Intel인지 먼저 확인해야 합니다. Linux는 프로세서 아키텍처뿐 아니라 배포판에 따라 deb 또는 rpm을 선택해야 하며, 최근 Android 주류 스마트폰은 보통 arm64를 사용합니다. 확인할 수 없을 때만 범용 패키지를 선택하세요. 이 사이트의 설치 패키지 페이지는 플랫폼과 아키텍처별로 입구를 나누어 두었으므로 파일명 목록을 보고 직접 추측할 필요가 없습니다.

구독, 단일 노드 및 로컬 설정

구독 주소는 업데이트 가능한 원격 노드 목록입니다. 클라이언트에 주소를 저장하면 구독 그룹별로 서버 이름, 프로토콜, 포트와 전송 매개변수를 가져옵니다. 단일 노드 링크는 임시로 가져오거나 특정 매개변수 조합을 확인할 때 적합하며, 로컬 JSON 설정은 세밀한 라우팅, 여러 아웃바운드와 복잡한 DNS 정책에 적합합니다. 세 방식은 서로 다른 문제를 해결합니다. 일상적인 사용에서는 구독 그룹을 유지해 업데이트할 때마다 수동으로 다시 입력하지 않도록 하세요. 고급 규칙을 시험해야 한다면 기존 설정을 별도 그룹에 복사해 테스트 변경 사항이 안정적인 설정을 덮어쓰지 않게 하세요.

구독 주소에는 보통 접속 자격 증명이 포함되므로 계정 정보와 동일하게 관리해야 합니다. 전체 주소를 공개 로그, 스크린샷 또는 온라인 변환 페이지에 붙여 넣지 마세요. V2Ray 구독 변환이 필요하다면 먼저 변환 서비스의 출처와 출력 형식을 확인하고, 변환 후 protocol, security, network, flow, SNI와 공개 키 같은 핵심 필드가 유지되는지 점검하세요. 변환은 클라이언트가 읽을 수 있는 표현 형식만 바꿀 뿐, 서버와 클라이언트의 매개변수 차이를 자동으로 수정하지 않습니다.

연결 전 환경 점검

먼저 시스템 날짜, 시간과 시간대를 정확하게 맞추세요. TLS와 REALITY 핸드셰이크는 시간 범위에 의존하므로 큰 오차가 있으면 노드가 계속 시간 초과되는 것처럼 보일 수 있습니다. 다음으로 이전 클라이언트를 종료하고 로컬 프록시 포트를 다른 프로세스가 사용하고 있지 않은지 확인하세요. 보안 프로그램과 시스템 방화벽이 클라이언트와 코어의 로컬 리스닝 및 외부 연결을 허용하는지도 점검해야 합니다. 마지막으로 정상적으로 접속할 수 있는 구독 주소를 준비하고 계정 상태, 트래픽 잔량과 만료일을 확인하세요. 노드 이름이 표시된다는 것은 구독 내용을 읽었다는 뜻일 뿐, 해당 노드가 현재 반드시 연결된다는 의미는 아닙니다.

연결 검증은 세 단계로 나누어야 합니다. 코어가 정상적으로 시작되었는지, 로컬 프록시 포트가 리스닝 중인지, 애플리케이션 트래픽이 프록시로 들어오는지 확인하세요. 웹페이지가 열리는지만 봐서는 어느 단계의 문제인지 파악하기 어렵습니다. 로그에 시작 완료가 표시되는데 브라우저 트래픽이 없다면 시스템 프록시나 브라우저의 별도 프록시를 확인해야 합니다. 로컬 포트가 나타나지 않으면 설정 파싱, 포트 충돌 또는 코어 파일 권한부터 처리하세요. 핸드셰이크 단계에서 실패한다면 서버 매개변수와 로컬 시간을 다시 확인하세요.

업데이트 및 백업 원칙

클라이언트를 업데이트하기 전에 구독 그룹, 사용자 지정 라우팅, DNS 규칙과 로컬 설정을 내보내거나 백업하세요. 데스크톱에서는 현재 시스템 프록시 모드와 로컬 리스닝 포트도 기록해 두는 것이 좋습니다. 큰 UI 세대가 바뀌는 업데이트에서는 이전 설정을 대체로 이전할 수 있지만 기본값이 달라질 수 있으므로, 처음 실행한 뒤 핵심 설정을 페이지별로 확인하세요. Android에서는 업데이트 전에 구독 주소에 여전히 접속할 수 있는지 확인해 앱 내부에 펼쳐진 임시 노드 목록에만 의존하지 않도록 하세요.

이 문서의 모든 후속 장에서는 동일한 검증 순서를 사용합니다. 설치가 끝나면 클라이언트를 시작하고, 구독을 가져와 그룹을 업데이트한 다음, 노드를 선택해 코어를 시작합니다. 이후 시스템 프록시 또는 TUN을 결정하고 마지막으로 로그와 실제 트래픽을 확인하세요. 순서를 고정하면 여러 변수를 동시에 변경하는 일을 피할 수 있습니다. 첫 설정을 10분 안에 끝내고 싶다면 v2rayN 사용 가이드로 이동하세요. 설정의 의미를 항목별로 이해하려면 해당 플랫폼 장을 계속 읽어 보세요.

// 03 · MACOS

macOS: 칩 선택, 권한 및 프록시 설정

macOS용 v2rayN은 다른 데스크톱 버전과 주요 기능을 공유하지만 설치 패키지는 프로세서 아키텍처와 일치해야 합니다. 처음 실행할 때는 앱 확인, 네트워크 설정과 TUN 권한도 처리해야 합니다. 노드와 프로토콜 문제를 판단하기 전에 시스템 권한을 먼저 해결하면 불필요한 재설치를 줄일 수 있습니다.

프로세서 확인 및 설치 완료

시스템 정보 또는 “이 Mac에 관하여”에서 칩 이름을 확인하세요. Apple 칩으로 표시되면 arm64 설치 패키지를, Intel 프로세서로 표시되면 x64 설치 패키지를 선택합니다. 아키텍처가 맞지 않으면 앱이 시작되지 않거나 호환 변환을 통해 실행되더라도 동작이 불안정할 수 있습니다. macOS 설치 페이지에서 해당 DMG를 다운로드하고, 연 뒤 창의 안내에 따라 앱을 “응용 프로그램” 폴더로 옮겨 해당 폴더에서 실행하세요.

처음 실행할 때 시스템에서 앱 출처나 네트워크 액세스 확인을 요청할 수 있습니다. 시스템 설정의 보안 안내에 따라 확인을 완료하고 앱을 여러 디렉터리에 반복해서 복사하지 마세요. 복사본이 여러 개면 설정 위치, 자동 시작 항목과 현재 실행 버전을 파악하기 어려워집니다. 업데이트 후에도 이전 화면이 보이면 활성 상태 보기에서 이전 프로세스가 종료되었는지 확인한 뒤 “응용 프로그램” 폴더의 새 복사본을 실행하세요.

구독 가져오기 및 서버 선택

구독 관리로 이동해 그룹을 새로 만들고 구독 주소를 저장한 다음 그룹 업데이트를 실행하세요. 노드가 나타나면 설정이 명확한 서버 하나를 활성 노드로 선택합니다. 구독 업데이트에 실패하면 현재 네트워크에서 구독 주소에 접속할 수 있는지, 주소가 완전히 복사되었는지와 시스템 날짜가 정확한지 확인하세요. 구독 링크에 특수 문자가 포함되어 있다면 전체를 그대로 붙여 넣고 쿼리 매개변수를 임의로 삭제하거나 수정하지 마세요.

macOS에서 노드 매개변수를 확인하는 방법은 Windows와 같습니다. VLESS 설정에서는 사용자 식별자, 암호화 필드, 전송 계층과 flow를 확인하고, REALITY에서는 serverName, fingerprint, publicKey와 shortId를 추가로 점검하세요. WebSocket 또는 gRPC는 경로, 호스트 이름이나 serviceName이 일치해야 합니다. 다른 기기에서 노드가 작동한다는 것은 서버에 전반적으로 접근할 수 있다는 뜻일 뿐이며, 현재 기기로 가져온 설정에서 필드가 누락되었을 가능성은 여전히 있습니다.

시스템 프록시와 애플리케이션별 차이

시스템 프록시를 활성화하면 v2rayN이 현재 네트워크 서비스의 프록시 설정을 변경합니다. 대부분의 브라우저와 시스템 네트워크 프레임워크를 따르는 앱은 이 설정을 자동으로 사용합니다. 명령줄 프로그램, 개발 도구와 일부 크로스 플랫폼 앱은 자체 프록시 환경 변수를 읽거나 시스템 프록시를 완전히 우회할 수 있습니다. 트래픽이 인계되었는지는 클라이언트 로그에서도 확인해야 합니다. 대상 앱을 열고 새 요청을 보냈는데 로그에 연결 기록이 없다면 트래픽이 아직 v2rayN으로 들어오지 않은 것입니다.

터미널의 임시 프록시는 v2rayN의 로컬 HTTP 리스닝 포트를 명시적으로 가리킬 수 있습니다. 포트는 클라이언트 설정 화면에 실제로 표시된 값을 기준으로 하며, 아래 예시는 환경 변수 작성법을 보여 주기 위한 일반적인 로컬 주소입니다:

export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809
export ALL_PROXY=socks5://127.0.0.1:10808

# 현재 터미널 세션이 끝나면 더 이상 유지되지 않음
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

포트를 확인하지 않은 상태에서 예시를 shell 설정에 장기간 기록하지 마세요. 나중에 클라이언트 포트를 변경하면 이전 환경 변수가 터미널을 작동하지 않는 포트에 계속 연결하게 됩니다. 장기간 사용할 경우 포트 변경 기록과 v2rayN 설정을 일치시키고, 클라이언트를 종료할 때 프록시 변수를 명시적으로 해제하세요.

TUN, DNS 및 시스템 권한

TUN 모드는 시스템 프록시를 따르지 않는 애플리케이션을 인계하는 데 적합합니다. 처음 활성화할 때 시스템에서 관리자 권한이나 네트워크 확장 허용을 요청할 수 있습니다. 권한 부여가 끝나면 메뉴 막대의 네트워크 상태와 v2rayN 로그를 확인해 가상 인터페이스가 생성되었는지 점검하세요. 라우팅이나 DNS를 변경하는 다른 도구도 실행 중이라면 먼저 종료하고 인계 주체를 하나만 남겨 두세요. 여러 도구가 동시에 기본 라우팅을 기록하면 웹페이지는 간헐적으로 열리지만 LAN이 끊기거나 DNS 요청이 순환하는 현상이 나타날 수 있습니다.

DNS 설정은 라우팅 정책과 함께 이해해야 합니다. 도메인을 먼저 해석한 뒤 IP로 매칭하는 방식과 도메인 규칙으로 바로 매칭하는 방식은 결과가 다를 수 있습니다. FakeDNS를 사용한다면 대상 앱과 LAN 서비스가 이러한 매핑 방식에 적합한지 확인하세요. 주소 매핑 보존과 TUN 환경의 적용 범위는 FakeDNS 가상 DNS 매핑 원리 자세히 알아보기에서 확인할 수 있습니다. LAN 프린터, 파일 공유와 개발 기기 검색에 문제가 생기면 사설 주소와 로컬 도메인을 우선 직접 연결로 설정하고 고급 DNS 기능을 잠시 꺼서 비교하세요.

절전 모드, 네트워크 전환 및 종료 후 복구

노트북이 절전 모드에서 복귀하거나 무선 네트워크를 전환하면 기존 연결, DNS 캐시와 기본 라우팅이 이미 무효화될 수 있습니다. 이때는 현재 연결을 먼저 중지한 뒤 노드를 다시 선택해 시작하세요. 시스템 프록시가 올바른 로컬 주소를 가리키는데도 트래픽이 없으면 클라이언트를 재설치하는 것보다 코어를 재시작하는 편이 효과적입니다. 회사 환경에서 가정 환경으로 전환할 때는 내부망용 직접 연결 규칙이 현재 요구 사항에도 맞는지 확인하세요.

v2rayN을 종료하기 전에 시스템 프록시 또는 TUN을 먼저 끄고 일반 네트워크 경로를 복원하세요. 프로세스를 강제 종료한 후 네트워크에 문제가 생기면 시스템 네트워크 설정에서 현재 네트워크 서비스의 HTTP, HTTPS와 SOCKS 프록시가 여전히 로컬 포트를 가리키는지 확인하세요. 남은 항목을 확인한 뒤 끄고 네트워크 서비스 전체를 삭제하지는 마세요. 앱이 시작되고, 코어가 실행되며, 시스템 프록시가 복원되는지는 macOS 설치 완료 후 별도로 확인해야 할 세 가지 항목입니다.

// 05 · ANDROID

Android: v2rayNG 가져오기, 연결 및 앱별 분할

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 선택하고, v2flyNG는 v2fly 코어가 필요한 경우의 대안으로 사용합니다. 모바일에서는 시스템 VPN 인터페이스로 트래픽을 인계하며 데스크톱 시스템 프록시는 사용하지 않습니다. 권한, 배터리 정책, 백그라운드 제한과 앱별 분할이 모바일과 데스크톱의 가장 큰 차이입니다.

arm64 또는 범용 설치 패키지 선택

최근 주류 Android 스마트폰은 보통 arm64를 선택합니다. 기기 아키텍처를 확인할 수 없거나 arm64 패키지를 설치할 수 없을 때만 범용 버전을 사용하세요. v2rayNG와 v2flyNG에는 각각 해당 입구가 있으며 자세한 순서와 아키텍처 설명은 Android 설치 페이지에서 확인할 수 있습니다. 같은 기기에서 클라이언트를 바꿀 때는 먼저 현재 연결을 중지해 시스템 VPN 인터페이스를 다른 앱이 계속 점유하지 않도록 하세요.

처음 실행한 뒤 연결을 시작하면 클라이언트가 VPN 연결 생성을 요청합니다. 시스템은 한 번에 하나의 이런 연결에만 현재 트래픽을 맡길 수 있으므로 다른 VPN 앱 때문에 권한이 덮어써지거나 연결이 즉시 끊길 수 있습니다. 연결을 눌렀는데 상태 아이콘이 나타나지 않으면 시스템 권한 부여가 완료되었는지 확인하고 기기 관리 정책의 제한 여부도 점검하세요.

구독 및 공유 링크 가져오기

구독 설정을 열고 그룹 이름과 구독 주소를 추가한 뒤 저장하고 업데이트를 실행하세요. 모바일 네트워크에서 업데이트에 실패하면 안정적인 무선 네트워크로 전환해 다시 테스트하세요. 두 네트워크 모두 실패한다면 구독 주소, 계정 상태와 로그를 확인해야 합니다. 업데이트가 성공하면 기본 목록으로 돌아가 노드를 선택한 뒤 연결 버튼을 누르세요. 업데이트 중에 앱을 자주 전환하거나 백그라운드 앱을 정리하면 다운로드와 파싱이 중단될 수 있습니다.

단일 노드는 클립보드의 표준 공유 링크로 가져오거나 신뢰할 수 있는 출처의 QR 코드를 스캔해 가져올 수 있습니다. 가져온 뒤 편집 화면에서 서버 주소, 포트, 사용자 식별자, 전송 방식, 보안 계층과 SNI를 확인하세요. QR 코드는 정보를 담는 방식일 뿐 매개변수의 일치 여부를 대신 판단하지 않습니다. REALITY 노드는 fingerprint, publicKey, shortId와 flow도 확인해야 합니다. 필드가 누락되면 클라이언트가 설정을 저장할 수는 있어도 핸드셰이크는 실패합니다.

구독 업데이트는 보통 그룹의 원격 노드를 교체합니다. 오래 유지해야 하는 수동 변경 사항은 별도 그룹에 복사해 다음 업데이트에서 덮어쓰이지 않도록 하세요. 노드 이름은 식별 용도일 뿐 이름을 바꿔도 연결 매개변수는 변하지 않습니다. 목록이 길다면 여러 출처를 같은 계층에 섞지 말고 구독 그룹별로 관리하세요.

라우팅 모드 및 앱별 분할

연결하기 전에 적합한 라우팅 모드를 선택하세요. 글로벌 모드는 현재 노드를 확인하기에 편리하고, 규칙 모드는 도메인과 IP에 따라 프록시 또는 직접 연결을 결정합니다. 사용자 지정 설정은 세밀한 DNS, 여러 아웃바운드 또는 특정 규칙 순서가 필요한 사용자에게 적합합니다. 처음에는 간단한 모드로 연결을 확인한 뒤 규칙을 단계적으로 추가하는 것이 좋습니다. 처음부터 복잡한 DNS, 앱별 분할과 여러 라우팅 그룹을 동시에 활성화하면 어느 계층에서 문제가 생겼는지 판단하기 어렵습니다.

앱별 분할을 사용하면 v2rayNG로 들어갈 앱을 지정하거나 직접 연결이 필요한 앱을 명확하게 제외할 수 있습니다. 설정할 때 시스템 구성 요소, 브라우저와 대상 앱 사이의 호출 관계를 주의하세요. 예를 들어 앱이 로그인 과정에서 외부 브라우저를 호출하는데 두 앱이 서로 다른 경로에 있으면 콜백이 실패할 수 있습니다. 앱 목록을 바꾼 뒤에는 연결을 끊었다가 다시 연결해 시스템 VPN 인터페이스가 새 규칙으로 생성되도록 하세요.

LAN 기기, 화면 미러링, 프린터와 파일 전송은 보통 사설 주소 직접 연결이 필요합니다. 연결을 활성화한 뒤 LAN 기능이 작동하지 않으면 먼저 LAN 또는 사설 주소 우회 규칙을 확인하고, DNS가 로컬 도메인을 원격으로 해석하고 있지 않은지 살펴보세요. 규칙 순서도 중요합니다. 더 구체적인 직접 연결 규칙은 먼저 매칭되는 포괄적인 프록시 규칙보다 앞에 있어야 합니다.

배터리 최적화 및 백그라운드 안정성

일부 기기는 화면이 꺼졌거나 배터리가 부족하거나 앱이 장시간 백그라운드에 있을 때 v2rayNG를 제한합니다. 연결 아이콘은 남아 있지만 트래픽이 멈추고 앱을 다시 열면 복구되는 형태로 나타납니다. 시스템 배터리 설정에서 클라이언트가 실제 필요에 따라 실행되도록 허용하고 백그라운드 데이터가 제한되지 않았는지 확인하세요. 제조사마다 메뉴 이름은 다르지만, 핵심은 연결 중 시스템이 클라이언트나 코어 프로세스를 중지하지 않게 하는 것입니다.

안정성 테스트는 최소한 포그라운드 웹 탐색, 화면을 끈 뒤 복귀, 무선 네트워크와 모바일 네트워크 전환을 포함해야 합니다. 네트워크를 전환하면 로컬 주소, DNS와 기본 라우팅이 바뀌므로 잠시 재연결되는 것은 정상입니다. 전환할 때마다 복구되지 않는다면 먼저 연결을 끊었다가 다시 연결하고, 로그가 DNS, 핸드셰이크 또는 시스템 VPN 생성 중 어느 단계에서 멈추는지 확인하세요. 상태 표시줄 아이콘만으로 연결 품질을 판단하지 마세요. 아이콘은 인터페이스가 존재한다는 뜻일 뿐 대상 노드의 핸드셰이크 완료를 의미하지 않습니다.

v2rayNG와 v2flyNG의 전환 범위

v2rayNG는 Xray 코어 기능과 관련 프로토콜 설정을 사용하는 데 적합한 Android 우선 클라이언트입니다. v2flyNG는 v2fly 코어를 사용하며 특정 설정 요구 사항에 대한 대안이 될 수 있습니다. 클라이언트를 바꾸기 전에 구독 주소를 내보내거나 저장하고, 두 앱이 내부 데이터베이스를 공유한다고 가정하지 마세요. 같은 구독이라도 두 클라이언트에서 펼쳐지는 기본 노드는 대체로 비슷하지만 고급 설정 필드, 실험 기능과 기본 동작은 다를 수 있습니다.

비교할 때 노드, 네트워크와 라우팅 모드를 동일하게 유지하고 한 번에 변수 하나만 바꾸세요. v2rayNG는 연결되는데 v2flyNG가 연결되지 않는다면 먼저 후자가 현재 처리하지 않는 필드를 설정에서 사용하고 있는지 확인하세요. 반대의 경우에는 가져오기 결과와 기본 설정을 점검합니다. 문제 해결의 목적은 코어를 반복해서 바꾸는 것이 아니라 구독 형식, 프로토콜 매개변수와 클라이언트 기능이 서로 맞는지 확인하는 것입니다.

// 07 · TROUBLESHOOTING

설정 문제와 정해진 문제 해결 순서

문제 해결의 핵심은 먼저 실패한 계층을 파악한 뒤 해당 변수만 처리하는 것입니다. 권장 순서는 시스템 시간과 네트워크, 구독과 노드, 코어 시작, 로컬 리스닝, 트래픽 인계, DNS, 라우팅 규칙입니다. 순서를 고정하면 대부분의 문제에서 클라이언트를 재설치할 필요가 없습니다.

1단계: 기본 네트워크, 시간 및 구독 상태 확인

먼저 클라이언트의 트래픽 인계를 끈 상태에서 현재 네트워크가 일반 사이트에 정상적으로 연결되는지 확인하고 날짜, 시간과 시간대를 맞추세요. 회사 네트워크, 공용 무선 네트워크와 모바일 핫스팟은 포트 정책이 다를 수 있으므로 한 네트워크에서는 노드가 작동하고 다른 네트워크에서는 시간 초과되는 것이 모순은 아닙니다. 그런 다음 구독이 아직 유효한지, 계정이 만료되지 않았는지, 트래픽을 사용할 수 있는지 확인하고 구독을 한 번 업데이트하세요.

구독 업데이트 자체가 실패한다면 문제는 노드 연결 전에 발생한 것입니다. 로그의 HTTP 상태, 시간 초과 또는 파싱 정보를 확인하고 구독 주소가 완전하며 현재 네트워크에서 접근 가능한지 점검하세요. 이 단계에서는 클라이언트가 새 설정을 아직 받지 못했으므로 노드의 프로토콜 필드를 수정하지 마세요. 노드 목록은 업데이트되지만 모든 연결이 실패할 때 다음 단계로 진행합니다.

2단계: 노드 매개변수와 서버 접근성 확인

매개변수가 명확한 노드 하나를 선택해 주소, 포트, 프로토콜, 사용자 식별자, 보안 계층과 전송 방식을 하나씩 확인하세요. REALITY는 serverName, fingerprint, publicKey, shortId와 flow도 점검해야 합니다. WebSocket은 path와 host를, gRPC는 serviceName을 확인하세요. 구독 변환 후에는 특히 고급 필드가 보존되었는지 살펴보세요.

로그의 시간 초과는 제한된 시간 내에 현재 단계가 완료되지 않았다는 뜻일 뿐 원인이 하나로 정해졌다는 의미는 아닙니다. 서버 주소에 연결하기 전 시간 초과가 발생하면 주소 해석, 접근할 수 없는 포트 또는 현재 네트워크 제한일 수 있습니다. TCP 연결 후 핸드셰이크에서 시간 초과가 발생하면 보안 계층과 서버 상태를 중점적으로 확인하세요. 연결이 곧바로 닫히면 매개변수 불일치나 서버의 거부일 수 있습니다. 노드 시간 초과 6단계 점검 목록에 따라 하나씩 확인해 보세요.

3단계: 코어 시작 및 로컬 포트 확인

로그를 지우고 연결을 중지한 뒤 다시 시작하세요. 먼저 설정 로드와 코어 시작 결과를 찾고, 로컬 HTTP, SOCKS 또는 TUN 리스닝이 생성되었는지 확인합니다. 주소가 이미 사용 중이라는 메시지가 나오면 다른 클라이언트를 종료하거나 충돌하는 포트를 변경하세요. 창을 닫아도 백그라운드 프로세스가 종료되지 않을 수 있으므로 트레이, 활성 상태 보기, 시스템 모니터 또는 앱 목록을 확인해야 합니다.

설정 파싱 오류는 보통 필드 유형, 알 수 없는 옵션 또는 JSON 구조의 위치를 명확하게 표시합니다. 사용자 지정 JSON에 오류가 있으면 먼저 클라이언트가 생성한 기본 설정으로 복원한 뒤 사용자 지정 부분을 구간별로 병합하세요. JSON에는 주석을 넣을 수 없으며 배열과 객체 끝에 불필요한 쉼표를 남겨서도 안 됩니다. 코어가 계속 실행되는 것을 확인한 뒤 시스템 프록시와 트래픽 인계 문제를 점검하세요.

4단계: 애플리케이션 트래픽이 클라이언트로 들어오는지 확인

노드를 시작한 뒤 대상 앱을 열고 완전히 새로운 요청을 보내면서 액세스 로그를 확인하세요. 기록이 전혀 없다면 트래픽이 클라이언트에 도달하지 않은 것입니다. 데스크톱에서는 시스템 프록시 활성화 여부, 앱의 별도 프록시 사용 여부와 터미널 환경 변수를 확인하세요. Android에서는 시스템 VPN 권한과 앱별 분할을 확인하고, TUN 환경에서는 가상 인터페이스와 기본 라우팅을 점검하세요.

로그에 연결 기록은 있지만 대상 동작이 이상하다면 진입점은 생성된 것이므로 아웃바운드, DNS와 라우팅을 계속 확인하세요. 브라우저가 이전 연결을 재사용할 수 있으므로 테스트 전에 관련 탭을 닫거나 브라우저를 다시 시작하세요. 일부 앱은 자체 DNS와 프록시 설정을 사용하므로 시스템 설정만 보고 판단하지 말고 각각 확인해야 합니다.

5단계: DNS와 라우팅 문제 분리

도메인은 실패하지만 직접 IP 연결은 가능하다면 보통 DNS를 확인해야 합니다. 해석 요청이 코어로 들어가는지, 어떤 서버를 사용하는지, 브라우저의 보안 DNS가 이를 우회하는지와 FakeDNS가 현재 앱에 적합한지 살펴보세요. DNS가 주소를 반환했는데 잘못된 아웃바운드로 연결된다면 domainStrategy, 규칙 순서와 geosite·geoip 데이터 매칭을 확인하세요.

일부 사이트만 실패한다면 실패한 도메인과 매칭된 규칙을 기록하고 장기간 사용할 목적으로 바로 글로벌 모드로 바꾸지 마세요. 글로벌 모드는 노드 전체가 작동하는지 확인하는 데 사용할 수 있지만 최종적으로는 규칙 모드로 돌아가 구체적인 조건을 수정해야 합니다. LAN 연결이 실패하면 사설 주소 직접 연결을 먼저 확인하고, 로컬 도메인 해석이 실패하면 시스템 검색 도메인과 로컬 DNS가 덮어써지지 않았는지 점검하세요.

플랫폼별 복구 방법

Windows에서 강제 종료 후에는 시스템 프록시가 더 이상 유효하지 않은 로컬 포트를 가리키는지 확인하고 이전 프로세스가 종료되었는지 점검하세요. TUN 사용 후 네트워크가 복구되지 않으면 클라이언트를 종료한 뒤 현재 네트워크 어댑터를 다시 활성화하세요. macOS에서는 현재 네트워크 서비스의 프록시 항목과 가상 네트워크 권한을 확인하고 네트워크 설정 전체를 삭제하지 마세요. Linux에서는 가상 인터페이스, 기본 라우팅, DNS 서비스와 프로세스 리스닝을 확인하며 원격 기기라면 관리 트래픽의 반환 경로를 먼저 보장하세요. Android에서는 시스템 VPN을 이전 앱이 계속 점유하고 있는지, 배터리 정책이 백그라운드를 중지했는지와 네트워크 전환 후 재연결이 완료되었는지 확인하세요.

이러한 복구 방법은 시스템 트래픽 인계 설정의 잔여 문제만 처리하며 노드 매개변수를 수정하지는 않습니다. 일반 네트워크를 복원한 뒤에도 클라이언트가 연결되지 않으면 로그 단계로 돌아가세요. 반복적인 재설치는 일부 상황 정보를 지울 뿐 구독 상태, 서버 매개변수와 현재 네트워크 조건을 바꾸지 못하므로, 앱 파일 손상이나 업그레이드 마이그레이션 오류가 확인된 경우에만 사용하세요.

유효한 로그 정리 방법

문제 해결 기록을 제출하거나 직접 보관할 때는 플랫폼, 클라이언트 이름, 트래픽 처리 방식, 프로토콜 유형, 문제 발생 시간, 작업 단계와 관련 오류 행을 포함하세요. 구독 주소, 사용자 식별자, 공개 키 외의 계정 자격 증명과 전체 공유 링크는 가려야 합니다. 로그는 기록을 지운 뒤 문제를 한 번 완전히 재현한 구간에서 추출해 여러 노드와 여러 번의 시작 기록이 섞이지 않게 하세요.

유효한 설명은 다음과 같습니다. “Windows에서 v2rayN을 시스템 프록시 모드로 사용 중입니다. 구독 업데이트와 코어 리스닝은 성공했지만, 브라우저 요청은 로그에 나타나고 활성 노드를 선택한 뒤 REALITY 핸드셰이크가 실패합니다.” 이 설명만으로도 구독, 코어와 트래픽 진입점 세 계층은 이미 제외할 수 있습니다. “사용할 수 없음”이라고만 쓰면 어디서부터 확인해야 할지 판단할 수 없습니다. 자주 묻는 질문은 문제 해결에서 확인할 수 있으며, 기본 개념, 설치 및 설정, 활용 팁과 문제 해결로 분류되어 있습니다.

되돌릴 수 있는 안정적인 설정 만들기

문제가 해결되면 현재 구독 그룹, 활성 노드, 라우팅 모드, DNS 정책, 로컬 포트와 플랫폼 권한을 기록하세요. 사용자 지정 설정은 기준본으로 별도 저장하고 이후 변경은 복사본에서 시작합니다. 데스크톱은 업데이트 전에 설정을 백업하고 Android는 구독 출처와 핵심 노드 매개변수를 보관하세요. 안정적인 설정의 가치는 영원히 바뀌지 않는 데 있는 것이 아니라, 실험 후 검증된 상태로 빠르게 돌아갈 수 있는 데 있습니다.

전체 검증에는 시작, 구독 업데이트, 노드 핸드셰이크, 시스템 트래픽 처리, 직접 연결 규칙, 프록시 규칙, LAN 접근과 네트워크 전환이 포함되어야 합니다. 네 플랫폼의 버튼 위치는 달라도 판단 순서는 같습니다. 먼저 데이터 출처를 확인하고, 다음으로 코어와 트래픽 진입점을 확인한 뒤 마지막으로 DNS와 아웃바운드를 점검하세요. 이 순서로 관리하면 설정 규모가 커져도 문제 계층을 구체적으로 찾을 수 있습니다.