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

공통 준비 작업과 설정 범위

설치 전에 기기 아키텍처, 구독 유형, 프록시 적용 대상과 현재 네트워크 상태를 확인하세요. 준비 단계에서 범위를 명확히 해 두면 이후 연결 실패가 발생해도 문제를 한 단계로 좁히기 쉽습니다.

클라이언트, 커널, 구독을 먼저 구분하기

v2rayN, v2rayNG, v2flyNG는 그래픽 클라이언트로, 서버 정보를 저장하고 실행 설정을 생성하며 커널을 시작하고 시스템 프록시를 제어합니다. Xray와 V2Fly는 실제 연결, 전송, 라우팅을 처리하는 커널 계열입니다. 구독은 서비스 제공자가 전달하는 서버 설정 모음으로, 일반적으로 주소, 포트, 사용자 식별자, 프로토콜, 전송 방식, TLS 매개변수와 서버 이름이 포함됩니다. 세 가지는 같은 계층이 아닙니다. 클라이언트는 조작 화면을 제공하고, 커널은 설정을 실행하며, 구독은 사용할 연결 매개변수를 제공합니다.

데스크톱에서는 v2rayN을 우선 선택하세요. Windows, macOS, Linux에서 구독 그룹, 서버 목록과 라우팅 설정 구조가 비슷해 기기 간 이전 시 대조하기 쉽습니다. Android 기기에서는 일반적으로 Xray 커널을 사용하는 v2rayNG를 선택하고, V2Fly 커널 동작과의 호환이 필요할 때 v2flyNG를 사용합니다. 프로토콜 이름만 보고 연결 가능 여부를 판단하지 말고 전송 계층, TLS, 보안 매개변수와 서버 설정이 모두 일치하는지 확인하세요.

프로세서 아키텍처와 설치 패키지 유형 확인

Windows의 일반적인 데스크톱 기기는 x64 패키지를 사용합니다. macOS는 칩에 맞춰 Apple Silicon 또는 Intel 설치 패키지를 선택해야 합니다. Android의 최신 기기는 대부분 arm64가 적합하며, 아키텍처를 확인할 수 없거나 호환성이 복잡하면 범용 패키지를 사용할 수 있습니다. Linux는 프로세서 아키텍처뿐 아니라 패키지 체계도 구분해야 합니다. Debian, Ubuntu 및 파생 배포판은 deb를 사용하고, Fedora, Rocky Linux, openSUSE 등의 환경은 대개 rpm을 사용합니다. 패키지 유형을 잘못 고르면 설치 관리자가 실행을 거부하거나, 프로그램이 시작 직후 종료될 수 있습니다.

원본 정보 보관 및 기준선 설정

가져오기 전에 구독 주소의 원문을 보관하고, 채팅 전달이나 메모 동기화, QR 코드 스크린샷에 장기간 노출하지 마세요. 구독 주소에는 보통 전체 노드를 읽을 수 있는 권한이 있어 유출되면 다른 사람이 사용할 수 있습니다. 최초 설정에서는 구독 그룹 하나만 가져오고, 사용 가능 여부가 확인된 서버 하나를 선택해 기본 라우팅과 기본 DNS로 기준선을 만드세요. 기준선 연결에 성공한 뒤 사용자 지정 라우팅, TUN, FakeDNS, Mux 또는 앱별 프록시를 하나씩 활성화하세요. 여러 매개변수를 한꺼번에 변경하면 오류 원인이 겹쳐 어떤 항목이 문제인지 판단하기 어렵습니다.

시작하기 전에 유사한 프록시 클라이언트를 종료하고 시스템 시간, 시간대와 기본 네트워크가 정상인지 확인하세요. TLS 핸드셰이크는 정확한 시간에 의존하므로 시간 차이가 크면 인증서 오류나 연결 직후 끊김으로 나타납니다. 회사 네트워크, 게스트 네트워크와 공용 핫스팟은 특정 포트나 UDP를 제한할 수 있으므로 먼저 브라우저로 일반 웹사이트에 직접 접속해 DNS와 기본 네트워크를 확인하세요. 기기에 수동 프록시가 설정되어 있다면 기존 값을 기록한 뒤 클라이언트에 관리를 맡겨 종료 후 오래된 주소가 남지 않게 하세요.

반복 가능한 작업 순서 만들기

1. 알맞은 설치 패키지 선택플랫폼, 프로세서 아키텍처와 패키지 체계에 맞춰 선택하고, 파일명이 비슷한 다른 빌드로 대체하지 마세요.
2. 구독 그룹 하나 가져오기이름과 구독 주소를 입력하고 업데이트 후 서버 항목이 정상적으로 생성되는지 확인하세요.
3. 활성 서버 선택먼저 실제 연결을 테스트한 뒤 일괄 속도 측정이나 정렬 변경을 결정하세요.
4. 적용 방식 하나 활성화시스템 프록시와 TUN 중 하나만 먼저 선택해 확인하고 네트워크 경로를 동시에 바꾸지 마세요.
5. 정상 설정 기록라우팅 모드, DNS 방식과 클라이언트 설정을 저장해 업그레이드나 이전 후 쉽게 복원하세요.

준비 단계의 목표는 모든 옵션을 미리 조정하는 것이 아니라 반복 가능하고 되돌릴 수 있는 설정 흐름을 만드는 것입니다. 이후 어떤 플랫폼에서 문제가 생기더라도 “설치가 완전한가, 구독이 파싱되는가, 서버가 사용 가능한가, 커널이 실행되는가, 트래픽이 클라이언트로 들어오는가, DNS가 맞는가”의 여섯 단계 순서로 확인하세요. 이렇게 하면 노드 장애를 설치 장애로 오해하거나 시스템 프록시가 남은 상태에서 구독을 계속 수정하는 일을 피할 수 있습니다.

Windows 설치, 시스템 프록시와 TUN

Windows에서는 v2rayN을 사용합니다. 데스크톱 버전은 크로스 플랫폼 인터페이스를 제공하고, 클래식 WPF 버전은 전통적인 Windows 조작 방식을 선호하는 사용자에게 적합합니다. 두 버전의 구독, 서버와 라우팅 개념은 동일합니다.

다운로드 및 설치 선택

Windows 다운로드 영역에서 사용 방식에 따라 데스크톱 버전 또는 클래식 WPF 버전을 선택하세요. 새로 설치한다면 보통 데스크톱 버전으로 시작합니다. 기존 트레이 조작 방식, WPF 설정 디렉터리 또는 익숙한 작업 흐름이 필요하면 클래식 버전을 선택할 수 있습니다. 설치 전에 실행 중인 기존 클라이언트를 종료해 설치 관리자가 사용 중인 파일을 교체하지 못하는 상황을 피하세요. 설치가 끝나면 시작 메뉴에서 실행하고, 최초 실행 시 기본 창이 열리는지, 트레이 영역에 클라이언트 메뉴가 나타나는지, 커널 유형이 정상적으로 표시되는지 확인하세요.

시스템에서 네트워크 접근 권한을 요청하면 실제 네트워크 환경에 맞춰 클라이언트 통신을 허용하세요. 이 권한은 인바운드 리스닝과 LAN 기능에 관한 것으로, 시스템 프록시 활성화와는 다릅니다. 관리 대상 기기에서는 일반 사용자가 네트워크 구성 요소를 설치하거나 서비스를 만들 수 없을 수 있습니다. 권한 요청이 표시되면 다른 디렉터리에 반복해서 압축을 풀기보다 기기 관리자가 허용한 방식으로 설치하세요. 포터블로 사용할 때는 자동 정리 대상, 읽기 전용 또는 경로가 지나치게 긴 위치도 피해야 합니다.

구독 가져오기 및 활성 서버 선택

구독 그룹 관리에서 그룹 이름을 추가하고 구독 주소를 붙여 넣으세요. 저장 후 업데이트하면 기본 목록에 프로토콜, 별칭과 서버 정보가 표시되어야 합니다. 목록이 비어 있으면 주소가 완전한지, 공백이 섞이지 않았는지, 브라우저로 열었을 때 서버가 유효한 내용을 반환하는지부터 확인하세요. 업데이트에 성공하면 서버 하나를 선택해 활성 서버로 지정합니다. 속도 측정은 특정 테스트 방식의 응답만 보여 주며 모든 트래픽에 적합하다는 뜻은 아니므로, 최초 확인은 실제 웹 요청과 대상 앱 연결을 기준으로 하세요.

구독 업데이트는 서버 내용에 따라 항목을 추가, 수정하거나 삭제합니다. 구독에서 생성된 서버 매개변수를 수동으로 바꾸면 다음 업데이트에서 덮어써질 수 있습니다. 개인 설정을 보존해야 한다면 변경 사항은 클라이언트 라우팅, DNS 또는 별도의 수동 서버 그룹에 두는 것이 좋습니다. 구독을 삭제하기 전에 유일하게 사용할 수 있는 설정이 포함되어 있지 않은지 확인하세요. 같은 주소를 다시 추가하면 새 그룹 식별자가 생성될 수 있어 기존 정렬과 선택 상태가 유지되지 않을 수 있습니다.

시스템 프록시의 세 가지 사용 상태

Windows 시스템 프록시는 시스템 프록시 설정을 따르는 브라우저와 데스크톱 프로그램에 주로 영향을 줍니다. 일반적인 상태는 시스템 프록시 지우기, 시스템 프록시 설정, 시스템 프록시 변경 안 함입니다. 일상적인 사용에서는 “시스템 프록시 설정”을 선택하고 종료할 때 “시스템 프록시 지우기”를 실행하는 것이 보통입니다. “변경 안 함”은 브라우저 프록시를 수동 설정하거나 특정 프로그램만 로컬 포트에 연결하거나 다른 네트워크 도구가 시스템 프록시를 관리할 때 사용합니다. 전환 후 Windows 프록시 설정을 열어 주소가 로컬 루프백 주소를 가리키고 포트가 v2rayN의 현재 리스닝 포트와 같은지 확인하세요.

클라이언트 종료 후 브라우저가 인터넷에 연결되지 않으면 먼저 시스템 프록시가 남아 있는지 확인하세요. v2rayN을 다시 시작해 지우기를 실행하거나 시스템 설정에서 수동 프록시를 끌 수 있습니다. 로컬 리스닝 포트를 구독에 있는 원격 서버 포트로 바꾸지 마세요. 전자는 앱이 v2rayN에 연결하는 입구이고 후자는 커널이 서버에 연결할 대상이므로 역할이 완전히 다릅니다.

ipconfig /flushdns
netsh winhttp show proxy
Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess

위 명령은 각각 Windows DNS 캐시 갱신, WinHTTP 프록시 상태 확인, 로컬 리스닝 포트 점검에 사용됩니다. 브라우저의 시스템 프록시와 WinHTTP 프록시는 같은 설정이 아니므로 netsh winhttp show proxy가 직접 연결로 표시되어도 브라우저는 시스템 프록시를 사용하고 있을 수 있습니다. 문제를 해결할 때는 Windows 설정, 클라이언트 상태와 대상 프로그램 자체의 프록시 옵션을 함께 확인해야 합니다.

TUN 모드 및 플랫폼별 문제

TUN은 가상 네트워크 인터페이스를 만들어 시스템 프록시를 읽지 않는 프로그램도 클라이언트로 들어오게 합니다. 활성화하기 전에 시스템 프록시로 안정적인 연결을 한 번 확인하고, v2rayN의 TUN 구성 요소와 권한이 준비되었는지 점검하세요. 최초 활성화 시 관리자 권한 요청이나 네트워크 인터페이스 설치가 나타날 수 있습니다. 성공하면 시스템 라우팅 테이블에 해당 인터페이스가 표시되고, 클라이언트를 중지하면 기존 경로가 복원되어야 합니다. 절전 모드, 네트워크 전환과 비정상 종료 후에는 가상 인터페이스만 남고 커널이 실행되지 않아 모든 앱이 인터넷에 연결되지 않을 수 있습니다.

게임, 가상 머신, 컨테이너 소프트웨어와 기업 네트워크 클라이언트가 동시에 라우팅이나 DNS를 변경할 수 있습니다. 충돌이 발생하면 먼저 TUN을 끄고 시스템 프록시를 복원해 확인한 뒤, 라우팅 규칙으로 대상 네트워크를 제외할지 가상 네트워크 카드 우선순위를 조정할지 결정하세요. LAN 프린터, 네트워크 저장 장치와 원격 데스크톱 주소는 일반적으로 직접 연결을 유지해야 합니다. 사설 주소 대역을 모두 원격으로 보내면 LAN 기기에 접근할 수 없거나 도메인 계정 인증이 느려지고 로컬 개발 서비스가 끊길 수 있습니다.

Windows 업데이트나 네트워크 드라이버 변경 후 TUN이 갑자기 작동하지 않으면 시스템을 재시작하고 가상 인터페이스가 정상적으로 로드되는지 확인하세요. 보안 소프트웨어가 새로 생성된 리스닝 포트나 네트워크 인터페이스를 제한할 수 있으므로 프로세스 경로와 로컬 리스닝 목적에 맞는 명확한 규칙을 설정해야 합니다. 로그에 커널이 시작되었다고 표시되지만 브라우저 요청 기록이 전혀 없다면 문제는 보통 시스템 프록시나 앱 프록시 계층에 있습니다. 요청이 클라이언트에 들어온 뒤 원격 연결에 실패한다면 서버 매개변수, DNS, TLS와 현재 네트워크 제한을 계속 확인하세요.

macOS 설치, 칩 선택과 네트워크 권한

macOS에서는 v2rayN 데스크톱 버전을 사용합니다. 올바른 칩용 빌드를 선택하고 최초 실행 권한을 허용하며, 시스템 프록시와 네트워크 확장 권한의 범위를 이해하는 것이 핵심입니다.

칩 확인 및 설치 완료

시스템의 “이 Mac에 관하여”에서 칩 또는 프로세서를 확인하세요. Apple 칩 이름이 표시되면 Apple Silicon 설치 패키지를, Intel 프로세서가 표시되면 Intel 설치 패키지를 선택합니다. macOS 다운로드 영역에서 해당 DMG를 받아 디스크 이미지를 연 다음 앱을 “응용 프로그램” 폴더로 드래그하고 응용 프로그램 폴더에서 실행하세요. 마운트된 디스크 이미지에서 앱을 장기간 직접 실행하면 업그레이드, 권한 저장과 자동 실행이 불안정할 수 있습니다.

최초 실행 시 시스템에서 앱 출처와 네트워크 접근 권한을 확인합니다. 시스템 안내에 따라 권한을 허용한 뒤 설정을 가져오세요. 더블 클릭해도 반응이 없으면 먼저 “개인정보 보호 및 보안”에서 차단된 실행 요청이 있는지 확인하고, 설치 패키지 아키텍처가 기기와 일치하는지 점검하세요. Apple Silicon 기기에 Intel 빌드를 잘못 설치하면 호환 변환 계층이 필요할 수 있습니다. 일부 환경에서는 실행되지만 기본 선택으로 삼아서는 안 됩니다. 네이티브 빌드는 시작, 리소스 사용량과 네트워크 구성 요소 호환성 면에서 더 직접적입니다.

구독 가져오기 및 메뉴 막대 상태

v2rayN의 구독 절차는 Windows와 같습니다. 구독 그룹 생성, 주소 입력, 업데이트 실행, 활성 서버 선택 순서로 진행하세요. 기본 창을 닫아도 프로그램이 메뉴 막대에서 계속 실행될 수 있으므로 창만 보지 말고 메뉴 막대 상태로 종료 여부를 확인해야 합니다. 구독을 업데이트한 뒤 서버 목록이 바뀌지 않으면 현재 선택한 그룹을 먼저 확인하고 업데이트 로그를 살펴보세요. 여러 그룹의 이름이 같으면 잘못 선택하기 쉬우므로 용도나 서비스 출처를 기준으로 짧고 명확한 이름을 사용하세요.

서버 선택을 마치면 먼저 커널을 시작하고 로그에 설정 파싱 오류가 없는지 확인하세요. 그다음 시스템 프록시를 활성화합니다. macOS는 네트워크 서비스별로 프록시 설정을 저장하므로 무선, 유선 또는 다른 네트워크 서비스마다 상태가 다를 수 있습니다. 네트워크를 전환한 뒤 브라우저가 갑자기 직접 연결되면 현재 활성 네트워크 서비스에 클라이언트 프록시가 적용되어 있는지 확인하세요. 반대로 클라이언트 종료 후 웹페이지에 접근할 수 없다면 시스템 네트워크 설정의 HTTP, HTTPS, SOCKS 프록시에 오래된 주소가 남아 있는지 확인하세요.

시스템 프록시, 터미널 및 독립 프록시 프로그램

시스템 프록시는 macOS 네트워크 프록시 설정을 따르는 앱을 주로 지원합니다. 터미널 명령, 개발 도구와 일부 크로스 플랫폼 프로그램은 환경 변수를 읽거나 시스템 설정을 완전히 무시할 수 있습니다. 특정 명령줄 프로그램이 로컬 프록시를 사용하게 하려면 현재 터미널 세션에서만 해당 변수를 설정하고 포트를 v2rayN의 실제 리스닝 값으로 바꾸세요. 작업이 끝난 뒤 터미널 세션을 닫으면 지워지므로 프록시 변수를 전역 시작 스크립트에 영구적으로 넣지 마세요.

export http_proxy=http://127.0.0.1:로컬 HTTP 포트
export https_proxy=http://127.0.0.1:로컬 HTTP 포트
export all_proxy=socks5://127.0.0.1:로컬 SOCKS 포트
env | grep -i proxy

여기서 “로컬 HTTP 포트”와 “로컬 SOCKS 포트”는 클라이언트 설정에서 확인해야 하며 다른 기기의 값을 그대로 사용하면 안 됩니다. 프로그램이 HTTP 프록시만 지원한다면 SOCKS 주소를 입력하지 마세요. 일부 명령줄 도구는 대소문자 환경 변수를 다르게 처리하므로 해당 도구의 문서를 확인하고 env | grep -i proxy로 현재 세션에 어떤 변수가 존재하는지 확인하세요.

TUN, DNS 및 절전 모드 복귀

TUN 모드에는 더 높은 수준의 네트워크 권한이 필요합니다. 처음 켤 때 시스템에서 네트워크 확장 승인, 기기 암호 입력 또는 백그라운드 항목 허용을 요청할 수 있습니다. 권한 허용은 구성 요소 로드만 해결할 뿐 라우팅이 올바르다는 뜻은 아닙니다. 활성화 후 일반 웹페이지, LAN 주소, 터미널 요청과 대상 앱을 차례로 확인하세요. LAN만 작동하지 않으면 사설 주소 직접 연결 규칙을 확인하고, 모든 도메인이 실패하지만 알려진 주소에 직접 접근할 수 있다면 DNS를 중점적으로 점검하세요. 절전 모드 복귀 후 완전히 오프라인이면 먼저 TUN을 중지하고 클라이언트를 종료한 뒤 다시 시작하세요.

macOS의 네트워크 서비스 순서, 비공개 릴레이 계열 네트워크 기능, 기업 구성 프로파일과 다른 가상 네트워크 프로그램이 트래픽 경로를 바꿀 수 있습니다. 문제를 해결할 때는 기본 라우팅을 담당하는 프로그램 하나만 실행하세요. 가정용 Wi-Fi에서 공용 네트워크로 전환하면 서버 도달성, UDP 지원과 DNS 응답이 달라질 수 있으므로 전환 전 상태만으로 클라이언트 오류라고 판단할 수 없습니다. 먼저 적용 기능을 끄고 직접 연결을 복원한 뒤 커널을 재시작하고 마지막으로 프록시를 다시 활성화하는 순서가 가장 안전합니다.

업그레이드 및 설정 이전

업그레이드 전에 메뉴 막대의 v2rayN을 종료하고 현재 구독 그룹, 라우팅 모드, 커널 유형과 로컬 포트를 기록하세요. 앱을 덮어써도 설정이 자동으로 변경되지는 않지만, 기존 디렉터리의 실행 파일을 통째로 복사하면 오래된 캐시나 만료된 구성 요소가 따라올 수 있습니다. 더 안전한 방법은 구독 주소와 명확한 사용자 지정 규칙을 보관하고 새 프로그램에서 기본 기능을 확인한 뒤 이전하는 것입니다. 새 빌드와 기존 빌드의 설정 구조가 호환되지 않으면 내부 데이터베이스를 수동으로 수정하기보다 구독을 다시 가져오세요.

이전이 끝나면 로그인 시 실행과 백그라운드 항목 목록을 확인해 이전 프로그램과 새 프로그램이 동시에 시작되지 않게 하세요. 메뉴 막대에 비슷한 항목이 두 개 나타나면 모든 인스턴스를 종료한 뒤 “응용 프로그램” 폴더에서 원하는 버전을 실행하세요. 로그 디렉터리와 임시 설정에 서버 정보가 포함될 수 있으므로 진단 자료를 공유하기 전에 구독 주소, 사용자 식별자, 도메인과 포트를 삭제하세요. 오류 유형, 발생 단계와 필요한 커널 메시지만 남겨도 문제를 파악하는 데 충분한 경우가 많습니다.

Linux 설치, 데스크톱 통합과 권한

Linux에서는 v2rayN 데스크톱 버전을 사용합니다. 설치 전에 배포판의 패키지 체계, 프로세서 아키텍처, 데스크톱 세션과 그래픽 의존성을 함께 확인해 인터페이스 문제를 커널 문제로 오해하지 않도록 하세요.

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

Debian, Ubuntu, Linux Mint 등의 환경에서는 보통 deb를 선택하고, Fedora, Rocky Linux 및 RPM 패키지 관리 체계를 사용하는 배포판에서는 rpm을 선택합니다. 기기 아키텍처는 uname -m으로 확인할 수 있습니다. 일반적인 x86_64는 x64에, aarch64는 arm64에 해당합니다. Linux 다운로드 영역에서는 이 두 조건을 모두 맞춰야 합니다. 패키지 형식만 맞추고 아키텍처를 무시하면 설치 관리자가 거부하며, 아키텍처만 맞추고 패키지 체계를 잘못 선택하면 필요한 패키지 관리 메타데이터가 없습니다.

uname -m
cat /etc/os-release
echo "$XDG_CURRENT_DESKTOP"
echo "$XDG_SESSION_TYPE"

/etc/os-release는 배포판과 기본 체계를 식별하는 데 사용하고, XDG_CURRENT_DESKTOP와 XDG_SESSION_TYPE은 데스크톱 환경과 현재 X11인지 Wayland인지 판단하는 데 사용합니다. v2rayN의 프록시 커널은 특정 데스크톱 프로토콜에 의존하지 않지만 트레이 아이콘, 창 배율, 로그인 시 실행과 시스템 프록시 저장은 데스크톱 환경의 영향을 받을 수 있습니다. 완전한 그래픽 세션이 없는 서버나 최소 설치 시스템에는 그래픽 클라이언트를 시스템 서비스처럼 배포하지 않는 것이 좋습니다.

시스템 패키지 관리자로 설치하기

deb 패키지는 그래픽 소프트웨어 설치 관리자로 열거나 시스템 패키지 관리 명령으로 설치할 수 있으며, rpm도 마찬가지입니다. 명령줄 설치의 장점은 배포판의 소프트웨어 관리를 우회하는 것이 아니라 누락된 의존성을 명확히 보여 준다는 데 있습니다. 설치 파일명은 실제 다운로드 결과를 기준으로 사용하고 예시 텍스트를 그대로 경로로 입력하지 마세요.

sudo apt install ./다운로드한v2rayN패키지.deb
sudo dnf install ./다운로드한v2rayN패키지.rpm

설치가 끝나면 데스크톱 앱 목록에서 실행하세요. 창이 나타나지 않으면 먼저 터미널에서 앱 실행 파일을 실행해 오류 출력을 확인한 뒤 그래픽 런타임, 디스플레이 서버 환경 변수와 사용자 디렉터리 쓰기 권한을 점검하세요. 그래픽 클라이언트를 root로 장기간 실행하지 마세요. root로 실행하면 관리자 홈 디렉터리에 별도의 설정이 만들어지고 이후 생성된 파일을 일반 사용자가 읽지 못할 수 있습니다. 소프트웨어 패키지 설치, TUN 설정 또는 시스템 수준 네트워크 설정 변경 시에만 안내에 따라 권한을 높이면 됩니다.

구독, 시스템 프록시 및 데스크톱 환경 차이

구독 가져오기는 그룹 추가, 콘텐츠 업데이트, 서버 선택, 커널 시작 순서를 따릅니다. 커널이 시작되면 먼저 로컬 HTTP와 SOCKS 리스닝 포트를 확인하고 앱 트래픽을 클라이언트로 보낼 방법을 결정하세요. GNOME, KDE Plasma와 다른 데스크톱 환경은 시스템 프록시 저장 위치가 다르며 v2rayN이 자동으로 기록할 수 있는지는 현재 데스크톱 통합에 달려 있습니다. 자동 설정 후 브라우저가 프록시를 사용하지 않으면 데스크톱 네트워크 설정에서 루프백 주소와 포트를 수동으로 확인하되 이전 클라이언트의 프록시 값은 함께 남겨 두지 마세요.

터미널 프로그램은 일반적으로 http_proxy, https_proxy 또는 all_proxy 환경 변수를 읽습니다. 그래픽 프로그램은 데스크톱 프록시를 따를 수도 있고 자체 설정을 사용할 수도 있습니다. systemd가 관리하는 백그라운드 서비스는 로그인한 터미널의 환경 변수를 자동으로 상속하지 않으므로 서비스 설정에 명시해야 합니다. 문제를 해결할 때 대상이 브라우저인지, 터미널 프로세스인지, 데스크톱 앱인지, 시스템 서비스인지 먼저 구분한 뒤 해당 진입점을 확인하세요. 데스크톱 프록시 스위치만 확인해서는 안 됩니다.

TUN, 라우팅 테이블 및 로컬 서비스

Linux의 TUN에는 커널 지원, 디바이스 노드와 네트워크 인터페이스를 생성할 권한이 필요합니다. 활성화하기 전에 /dev/net/tun이 존재하는지 확인할 수 있습니다. 컨테이너, 가상 머신, 네트워크 네임스페이스와 방화벽 관리자가 정책 라우팅이나 패킷 마크를 추가할 수 있습니다. v2rayN에서 TUN이 시작되었다고 표시되지만 트래픽이 커널로 들어가지 않으면 기본 라우팅, 정책 라우팅, DNS 대상과 방화벽의 가상 인터페이스 전달 허용 여부를 확인하세요. 기존 규칙을 이해하지 못한 상태에서 방화벽을 통째로 비우지 마세요. 시스템 서비스와 컨테이너 네트워크에 영향을 줍니다.

ip address
ip route
ip rule
ss -lntup
resolvectl status

ip route는 기본 라우팅과 사설 네트워크 경로를 확인하고, ip rule은 정책 라우팅을 조회하며, ss는 로컬 프록시 포트의 리스닝 여부를 확인하는 데 사용합니다. resolvectl status로 systemd-resolved를 사용하는 시스템의 현재 DNS를 볼 수 있습니다. 배포판이 다른 리졸버를 사용한다면 해당 네트워크 관리 서비스를 확인하고 /etc/resolv.conf를 반복해서 덮어쓰지 마세요. 많은 배포판에서 이 파일은 NetworkManager나 이름 해석 서비스가 동적으로 생성하므로 수동 변경이 네트워크 재연결 후 사라질 수 있습니다.

트레이, 로그인 시 실행 및 업그레이드

일부 데스크톱 환경은 기존 트레이 아이콘을 기본으로 표시하지 않아 창을 닫은 뒤에도 클라이언트가 실행 중인지 확인하기 어렵습니다. 처음 사용할 때 창 닫기 동작을 테스트하고 프로세스 목록으로 종료 방식을 확인하세요. 로그인 시 실행을 설정할 때는 데스크톱 자동 시작 항목을 하나만 남겨 사용자 자동 시작 파일과 데스크톱 설정이 중복되지 않게 하세요. 중복 인스턴스는 같은 로컬 포트를 차지하려 하며 두 번째 인스턴스가 시작되지 않거나 구독 업데이트는 되지만 프록시 리스닝이 없는 현상이 나타날 수 있습니다.

업그레이드 전에 모든 인스턴스를 종료하고 배포판의 소프트웨어 관리자로 새 패키지를 설치하세요. 의존성 충돌이 발생하면 소프트웨어 관리자가 제시한 정확한 패키지 이름과 버전 조건을 먼저 확인하고 데스크톱 런타임을 무작정 삭제하지 마세요. 설정 이전은 구독, 라우팅과 DNS 설정을 중심으로 진행하고 캐시와 실행 중 생성된 파일은 통째로 복사할 필요가 없습니다. 업그레이드 후 “인터페이스 시작, 커널 시작, 로컬 리스닝, 시스템 프록시, TUN” 순서로 단계별 확인하면 변경이 어느 계층에서 발생했는지 정확히 파악할 수 있습니다.

Android 설치, 백그라운드 실행과 앱별 프록시

Android에서는 v2rayNG를 우선 사용하며 기본적으로 Xray 커널을 사용합니다. V2Fly 커널 동작이 필요할 때는 v2flyNG를 선택하세요. 두 클라이언트의 가져오기, 연결과 앱별 프록시 사용 방식은 비슷합니다.

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

최근 출시된 주요 Android 스마트폰과 태블릿은 대부분 arm64를 사용하므로 해당 설치 패키지를 우선 선택할 수 있습니다. 기기 아키텍처를 확인할 수 없거나 시스템이 오래되었거나 설치 시 호환되지 않는다는 메시지가 표시되면 범용 패키지를 사용하세요. 범용 패키지는 더 많은 아키텍처 코드를 포함해 파일이 큰 편이지만 호환 범위가 넓습니다. Android 다운로드 영역에서는 먼저 클라이언트를 선택한 다음 아키텍처를 고르세요. 일반적으로 v2rayNG를 사용하고, V2Fly 커널이 명확히 필요한 경우에만 v2flyNG를 설치합니다.

설치 전에 현재 브라우저나 파일 관리자가 다운로드한 설치 패키지를 열 수 있도록 시스템에서 허용했는지 확인하세요. 이 권한은 보통 출처 앱별로 관리되며 설치가 끝나면 해당 출처의 설치 권한을 끌 수 있습니다. 덮어쓰기 업그레이드는 앱 식별자를 동일하게 유지해야 합니다. 시스템에서 서명이 일치하지 않는다고 표시되면 강제로 덮어쓰지 말고 구독 주소와 사용자 지정 설정을 백업한 뒤 기존 앱과 새 패키지의 출처가 같은지 확인하세요. 앱을 삭제하면 앱 전용 설정이 지워지므로 구독 정보를 저장하지 않은 상태에서 바로 삭제해 문제를 해결하려 하지 마세요.

구독 가져오기 및 QR 코드

구독 주소를 복사한 뒤 구독 그룹에서 설정을 추가하고 업데이트를 실행하세요. QR 코드는 단일 서버나 서비스 제공자가 제공한 구독 정보를 가져오는 데 편리하지만 스캔 전에 출처를 확인해야 합니다. 갤러리 인식에는 저장 공간 또는 사진 읽기 권한이, 카메라 스캔에는 카메라 권한이 필요합니다. 해당 기능을 사용할 때만 허용하세요. 가져온 후 서버 항목에 주소, 포트, 프로토콜과 전송 정보가 포함되어 있는지 확인하세요. 이름이 깨져도 연결에는 영향을 주지 않는 경우가 많지만 모든 항목이 비어 있다면 구독이 제대로 파싱되지 않은 것입니다.

서버를 선택하고 연결 버튼을 누르면 시스템에 네트워크 연결 권한 대화 상자가 표시됩니다. 확인 후 상태 표시줄에 시스템 네트워크 아이콘이 나타나면 앱이 트래픽 진입점을 얻었다는 뜻이며, 원격 연결 성공을 보장하지는 않습니다. 이제 v2rayNG 로그를 확인하고 실제 웹페이지를 열어 보세요. 연결을 누르자마자 다시 끊기면 설정 파싱, 포트 점유와 시스템의 앱 실행 제한을 중점적으로 확인하세요. 연결 상태는 유지되지만 웹페이지가 열리지 않으면 서버 도달성, DNS와 라우팅 모드를 점검하세요.

백그라운드 유지 및 배터리 정책

Android 제조사의 절전 정책이 화면이 꺼진 뒤 v2rayNG를 제한할 수 있습니다. 일정 시간 잠금 상태로 두면 연결이 끊기거나 알림은 남아 있지만 트래픽이 없고, 앱으로 돌아오면 다시 연결되는 현상이 나타납니다. 시스템 배터리 설정에서 클라이언트의 백그라운드 실행을 허용하고 보호 앱 또는 백그라운드 허용 목록에 추가하세요. 메뉴 이름은 기기마다 다르지만 백그라운드 활동 허용, 자동 정지 해제, 시스템 정리 도구의 프로세스 종료 방지가 기준입니다.

백그라운드 유지는 모든 절전 기능을 끄라는 뜻이 아닙니다. 문제가 잠금 화면, 모바일 네트워크 전환 또는 장시간 대기 후에만 발생하는지 먼저 관찰한 뒤 v2rayNG에 맞춰 조정하세요. 배터리 소모가 크게 늘면 불필요한 전체 프록시, 잦은 구독 업데이트, 지속적인 속도 측정 또는 리소스 사용량이 큰 Mux 설정이 활성화되어 있지 않은지 확인하세요. v2rayNG 백그라운드 유지 및 배터리 소모 문제 해결을 참고해 시스템 제한, 앱별 프록시와 연결 매개변수를 하나씩 점검하세요.

앱별 프록시 및 LAN 우회

앱별 프록시는 어떤 앱을 v2rayNG로 보낼지 제어하는 기능입니다. 허용 목록 방식은 선택한 앱만 프록시를 사용하고, 제외 목록 방식은 선택한 앱을 직접 연결로 유지합니다. 활성화하기 전에 현재 모드를 확인해 결제, LAN 제어 또는 회사 인증 앱이 실수로 원격으로 전송되지 않게 하세요. 시스템 구성 요소, 브라우저 엔진과 앱 사이에 호출 관계가 있을 수 있어 주 앱만 선택하면 외부에서 열린 웹페이지나 다운로드 서비스가 같은 경로를 사용하지 않을 수 있습니다.

LAN 기기 주소, 라우터 관리 페이지, 화면 공유 기기와 네트워크 저장 장치는 보통 직접 연결로 유지해야 합니다. v2rayNG 연결 후 이런 기기에 접근할 수 없다면 라우팅 모드에 사설 주소 직접 연결 규칙이 포함되어 있는지 확인하세요. 모바일 네트워크와 Wi-Fi를 전환하면 로컬 네트워크 대역이 바뀌므로 이전 네트워크의 특정 대역 규칙이 새 네트워크에 적용되지 않을 수 있습니다. 일반적인 사설 주소 규칙이 기기별 주소를 나열하는 것보다 안정적이지만, 기업 네트워크는 더 복잡한 내부 대역을 사용할 수 있으므로 실제 환경에 맞춰 추가해야 합니다.

모바일 네트워크 전환 및 연결 복구

Wi-Fi에서 모바일 데이터로 전환하면 하위 네트워크 주소, DNS와 IPv6 조건이 모두 달라집니다. 앱은 시스템 연결 상태를 유지하는 것처럼 보여도 기존 원격 세션은 이미 끊겼을 수 있습니다. 정상적인 경우 커널이 연결을 재구성합니다. 장시간 트래픽이 없으면 구독을 바로 삭제하지 말고 먼저 클라이언트 연결을 한 번 전환해 보세요. 공용 Wi-Fi는 웹 인증을 먼저 요구하는 경우가 있으므로 프록시를 일시 중지하고 인증을 완료한 뒤 다시 연결하세요.

특정 앱 하나만 접근할 수 없다면 먼저 앱별 프록시를 끄고 해당 앱이 비공개 DNS, 자체 QUIC 또는 독립 프록시 설정을 사용하는지 확인하세요. 모든 앱이 실패하면 로그에서 DNS 시간 초과, 연결 거부 또는 TLS 관련 메시지를 확인하세요. 로그를 공유할 때는 오류 단계와 유형만 남기고 전체 서버 주소, 사용자 식별자와 구독 내용을 삭제하세요. 모바일 문제는 백그라운드 제한과 네트워크 전환이 원인인 경우가 많으므로 “포그라운드에서는 정상인가, 백그라운드에서만 문제인가”, “Wi-Fi에서는 정상인가, 모바일 네트워크에서만 문제인가”를 반드시 기록해야 합니다.

구독 관리, 프로토콜 매개변수와 라우팅 분할

구독은 설정을 배포하고 라우팅은 각 트래픽이 어느 출구로 나갈지 결정합니다. 안정적인 설정의 핵심은 서버 측 매개변수와 로컬 정책을 구분하고 잘못된 계층을 반복해서 수정하지 않는 것입니다.

구독 업데이트 전체 과정

클라이언트가 구독을 업데이트하면 구독 주소에 요청을 보내고 반환된 내용을 읽어 각 서버 항목을 파싱한 뒤 로컬 그룹에 저장합니다. 어느 한 단계에서든 실패하면 “업데이트 실패”로 표시될 수 있지만 처리 방법은 다릅니다. 요청 단계의 시간 초과는 현재 네트워크와 구독 주소 도달성을 확인하고, 빈 응답은 구독 상태를 확인하세요. 파싱 실패는 인코딩, 형식과 클라이언트 지원 여부를 점검하고, 저장 후 목록이 비어 있으면 그룹 필터와 제외 규칙을 확인하세요. 구독 링크 만료 또는 파싱 실패 시 6단계 자체 점검에 따라 단계별로 원인을 좁힐 수 있습니다.

구독 주소에는 접근 자격 증명이 포함될 수 있으므로 공개적으로 공유해서는 안 됩니다. 여러 기기에서 같은 구독을 사용할 때는 업데이트 빈도를 적절히 유지하고 짧은 시간에 연속으로 새로 고침하지 마세요. 클라이언트가 예약 업데이트를 지원한다면 실제 필요에 맞는 주기를 설정하되 노드 속도 측정과 구독 업데이트를 같은 작업으로 보지 마세요. 업데이트는 설정을 동기화할 뿐이고, 속도 측정은 서버에 능동적으로 접속합니다. 서버에서 항목을 삭제하면 다음 업데이트에서 함께 삭제될 수 있으므로 중요한 수동 설정은 별도 그룹에 두세요.

프로토콜과 전송 매개변수는 한 세트로 맞춰야 합니다

VMess, VLESS, Trojan과 Shadowsocks는 서로 다른 프로토콜 체계를 가리키며, WebSocket, gRPC, TCP 등은 전송 계층에 해당합니다. TLS와 REALITY는 보안 핸드셰이크와 서버 신원 매개변수와 관련됩니다. 연결 성립 여부는 프로토콜 이름만 같다고 결정되지 않고 전체 매개변수 세트가 서버와 일치하는지에 달려 있습니다. VLESS 설정에는 일반적으로 사용자 식별자, 전송 방식, 보안 유형, 서버 이름과 흐름 제어가 포함됩니다. Trojan은 비밀번호와 TLS 관련 정보가, Shadowsocks는 암호화 방식과 비밀번호가 일치해야 합니다.

구독에서 정상적으로 생성된 설정은 일반적으로 프로토콜 필드를 수동으로 수정할 필요가 없습니다. 서버에서 명확한 변경 지침을 제공한 경우에만 해당 매개변수를 조정하세요. WebSocket 경로, gRPC 서비스 이름, 서버 이름이나 공개 키를 비워 두면 연결이 실패할 수 있습니다. 클라이언트에 표시되는 서버 메모는 식별용일 뿐 핸드셰이크에 사용되지 않으므로 메모를 바꿔도 연결은 변하지 않습니다. 프로토콜 선택에 대한 비교 설명은 VMess, VLESS, Trojan, Shadowsocks 상황별 선택 가이드를 참고하세요.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-4111-8111-111111111111",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/vless"
        }
      }
    }
  ]
}

이 조각은 필드 계층을 설명하기 위한 예시이며, 예시 도메인과 사용자 식별자는 연결에 직접 사용할 수 없습니다. 실제 설정에는 서버와 일치하는 TLS 서버 이름, 요청 헤더 또는 기타 전송 매개변수가 필요합니다. 그래픽 클라이언트는 보통 구독으로 완전한 구조를 자동 생성하므로 일상적인 설정에서 JSON을 직접 편집할 필요는 없습니다. 로그를 읽거나 필드를 대조하거나 사용자 지정 규칙을 이전할 때만 이러한 계층을 이해하면 됩니다.

라우팅 규칙의 매칭 순서

라우팅은 일반적으로 도메인, IP, 포트, 네트워크 유형과 프로세스 정보를 기준으로 출구를 매칭합니다. 규칙을 위에서 아래로 판단할 때는 더 구체적인 규칙을 앞에 두고 기본 규칙을 마지막에 배치하세요. 일반적인 출구는 프록시, 직접 연결과 차단입니다. LAN과 로컬 주소는 직접 연결하고, 원격 출구가 필요한 도메인은 프록시로 보내며, 접근할 필요가 없는 텔레메트리나 악성 주소는 차단할 수 있습니다. 어떤 규칙에도 매칭되지 않으면 기본 출구를 사용하므로 기본값이 전체 설정의 방향을 결정합니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.net"],
        "outboundTag": "proxy"
      }
    ]
  }
}

IPIfNonMatch는 도메인 규칙이 매칭되지 않았을 때 주소를 다시 해석해 IP 규칙을 판단한다는 뜻입니다. DNS 참여가 늘어나므로 DNS 설정이 안정적이어야 합니다. AsIs를 사용하면 라우팅이 원래의 도메인 규칙에 더 의존하며, 매칭되지 않은 모든 도메인을 IP 매칭을 위해 적극적으로 해석하지 않습니다. 사용 가능한 정책 이름, 규칙 집합의 출처와 업데이트 방식은 커널과 클라이언트마다 다를 수 있으므로 현재 클라이언트 화면의 옵션을 기준으로 하세요.

전체, 우회와 사용자 지정 규칙 중 무엇을 선택할까

전체 모드는 거의 모든 대상이 프록시로 들어가 변수가 적으므로 서버 사용 가능 여부를 짧게 확인할 때 적합합니다. 하지만 모든 환경의 기본 해답은 아닙니다. LAN 기기, 로컬 개발 주소와 기업 내부 서비스에 접근할 수 없게 될 수 있습니다. 중국 본토 우회와 같은 사전 설정은 내장 도메인 및 주소 규칙으로 트래픽을 분할해 관리 부담이 낮지만, 클라이언트 업데이트에 따라 규칙 집합을 갱신해야 합니다. 사용자 지정 라우팅은 업무 경계가 명확한 사용자에게 적합합니다. 적은 수의 규칙부터 시작하고, 규칙을 추가할 때마다 매칭 목적과 예상 출구를 기록하세요.

라우팅이 적용되는지 판단할 때 웹페이지가 열리는지만 보지 마세요. 클라이언트 로그에서 대상 도메인, 매칭 규칙과 최종 출구를 확인해야 합니다. 앱이 도메인을 미리 주소로 해석하면 클라이언트에는 IP만 보일 수 있습니다. 스니핑을 활성화하면 일부 연결에서 도메인 정보를 복원할 수 있지만 모든 프로토콜을 안정적으로 식별할 수 있는 것은 아닙니다. 라우팅 문제는 앱의 요청 형태, DNS 응답과 규칙 순서를 함께 고려해야 합니다. 사용자 지정 규칙이 실패했을 때 빠르게 되돌릴 수 있도록 기본 라우팅 설정을 하나 보관하세요.

시스템 프록시, TUN과 DNS 연동

시스템 프록시는 앱이 로컬 포트에 능동적으로 연결할지 결정하고, TUN은 네트워크 계층에서 트래픽을 가로채며, DNS는 도메인에서 주소를 얻는 방식을 결정합니다. 세 기능의 역할은 다르지만 설정이 잘못되면 모두 “웹페이지가 열리지 않음”으로 나타날 수 있습니다.

시스템 프록시는 어떤 상황에 적합한가

시스템 프록시는 설정 비용이 낮아 브라우저와 운영 체제 프록시 인터페이스를 따르는 데스크톱 프로그램에 적합합니다. 클라이언트는 보통 로컬에서 HTTP, SOCKS 또는 혼합 포트를 열고 시스템 프록시가 루프백 주소를 가리키도록 합니다. 앱 요청이 로컬 포트에 들어오면 커널이 라우팅에 따라 프록시 또는 직접 연결 출구를 선택합니다. 시스템 프록시가 모든 프로그램을 자동으로 포함하는 것은 아닙니다. 명령줄 도구, 게임, 백그라운드 서비스와 자체 네트워크 스택을 구현한 앱은 이를 무시할 수 있습니다.

시스템 프록시를 활성화하기 전에 로컬 포트가 이미 리스닝 중인지 확인하세요. 다른 프로세스가 포트를 사용하면 커널이 다른 포트를 사용하거나 시작에 실패할 수 있는데 시스템은 계속 이전 포트를 가리킬 수 있습니다. 클라이언트를 종료할 때는 시스템 프록시를 지우고, 비정상 종료 후 전체 네트워크가 끊기면 가장 먼저 남은 프록시를 확인하세요. 시스템 프록시는 127.0.0.1 또는 클라이언트가 명시적으로 허용한 로컬 주소만 가리켜야 하며, 원격 서버 주소를 시스템 프록시에 직접 입력하지 마세요.

TUN의 적용 범위가 더 넓은 이유

TUN은 가상 네트워크 인터페이스를 만들고 시스템 라우팅이 보낸 패킷을 받으므로 HTTP 또는 SOCKS 프록시를 지원하지 않는 프로그램도 처리할 수 있습니다. 클라이언트는 패킷을 커널이 처리할 수 있는 연결로 변환한 뒤 규칙에 따라 직접 연결 또는 프록시 출구로 보냅니다. 일반적으로 더 높은 권한이 필요하며 다른 가상 네트워크, 기업 보안 프로그램, 가상 머신과 컨테이너 라우팅과 충돌하기도 쉽습니다. TUN을 활성화하기 전에 같은 서버가 시스템 프록시 모드에서 정상적으로 연결되는지 반드시 확인하세요.

TUN 설정에는 최소한 인터페이스 주소, 라우팅 주입, DNS 가로채기, MTU와 우회 범위가 포함됩니다. MTU가 너무 크면 일부 네트워크에서 핸드셰이크는 성공하지만 큰 페이지 로드가 실패할 수 있고, 너무 작으면 분할과 오버헤드가 늘어납니다. 기본값이 대부분의 네트워크에 더 적합하므로 근거 없이 바꾸지 마세요. 문제가 모바일 핫스팟, 기업 네트워크 또는 특정 회선에서만 발생한다면 MTU를 단계적으로 낮춰 확인할 수 있지만, 매번 변경 후 연결을 재구성하고 기존 세션을 정리해야 합니다.

DNS 조회는 어느 계층에서 이루어지는가

앱은 도메인을 시스템 리졸버에 맡길 수도 있고 자체 암호화 DNS를 사용할 수도 있습니다. 시스템 프록시 모드에서 SOCKS 요청은 도메인을 포함할 수도 있고 앱이 미리 해석한 IP만 포함할 수도 있습니다. TUN 모드는 DNS 가로채기를 통해 조회를 클라이언트로 보내 도메인 정보를 라우팅 규칙에 활용하는 경우가 많습니다. DNS는 직접 연결로 나가고 대상 연결은 프록시로 나가면 현재 출구에 적합하지 않은 주소를 받을 수 있고, 모든 DNS를 원격으로 강제하면 LAN 이름이나 기업 내부 도메인에 영향을 줄 수 있습니다.

안정적인 방식은 공용 도메인과 내부 도메인을 나눠 처리하는 것입니다. LAN과 기업 도메인은 로컬 DNS에 맡기고 나머지는 라우팅 정책에 따라 리졸버를 선택하세요. 도메인 기반 분할이 필요하다면 클라이언트가 도메인을 볼 수 있는지 확인하거나 스니핑으로 정보를 보완해야 합니다. 스니핑은 앱 콘텐츠를 복호화하는 기능이 아니라 연결 핸드셰이크에서 보이는 대상 이름을 식별하는 기능입니다. 암호화 수준이 높거나 표준이 아닌 트래픽에서는 식별 결과가 제한될 수 있습니다.

FakeDNS의 적용 범위

FakeDNS는 예약된 주소 풀에서 가상 IP를 반환하고 클라이언트 내부에 가상 주소와 원래 도메인의 매핑을 저장합니다. 이후 앱이 가상 IP에 연결하면 클라이언트가 도메인을 복원해 도메인 라우팅을 먼저 적용할 수 있습니다. TUN 환경에서 안정적인 도메인 분할이 필요하지만 연결에서 도메인을 직접 얻을 수 없을 때 적합합니다. 작동 원리와 조합 방식은 FakeDNS 원리와 적용 시나리오를 참고하세요.

FakeDNS는 클라이언트를 거치지 않는 트래픽에는 적합하지 않으며, 실제 주소에 의존하는 진단 도구, LAN 검색과 일부 앱의 주소 검증에 영향을 줄 수 있습니다. 활성화 후 시스템에 예약된 대역 주소가 표시되는 것은 정상이며 DNS 변조의 증거가 아닙니다. 실제로 확인해야 할 것은 가상 주소 연결을 클라이언트가 받는지, 매핑이 존재하는지, 최종 출구에서 실제 대상의 주소를 해석하고 연결할 수 있는지입니다. FakeDNS를 끌 때는 영향을 받은 앱을 다시 시작하고 필요하면 시스템 DNS 캐시를 갱신해 오래된 가상 주소가 남지 않게 하세요.

권장하는 단계적 설정 방법

1. 먼저 시스템 프록시로 노드 확인구독, 프로토콜, TLS와 원격 연결에 기본 오류가 없는지 확인합니다.
2. 기본 DNS를 유지한 채 도메인 확인일반 웹페이지, LAN 주소와 대상 앱의 기본 동작을 점검합니다.
3. TUN만 별도로 활성화복잡한 라우팅은 추가하지 말고 가상 인터페이스, 기본 라우팅과 앱 적용 범위를 관찰합니다.
4. 사설 주소 직접 연결 추가라우터, 프린터, 네트워크 저장 장치와 내부 서비스 접근을 복구합니다.
5. 마지막으로 DNS와 FakeDNS 조정한 번에 하나만 변경하고 로그에서 도메인, 주소와 출구의 대응 관계를 확인합니다.

설정이 완료되었는지 판단하려면 네 가지 테스트를 해야 합니다. 일반 웹페이지가 로드되는지, LAN 리소스에 직접 연결되는지, 시스템 프록시를 읽지 않는 대상 프로그램이 예상대로 TUN으로 들어가는지, 클라이언트 종료 후 직접 연결 네트워크가 복구되는지 확인하세요. 이 중 하나만 통과했다고 전체 경로가 올바르다는 뜻은 아닙니다. 복잡한 네트워크에서는 “시스템 프록시, 기본 DNS, 기본 라우팅” 설정을 기초 구성으로 보관하고 TUN 설정을 별도로 저장하는 편이 환경 전환 시 매개변수를 반복해서 수동 변경하는 것보다 안정적입니다.

일반적인 설정 문제와 계층별 점검

문제 해결은 데이터 경로를 따라 바깥에서 안쪽으로 진행해야 합니다. 시스템 네트워크, 클라이언트 진입점, 커널 실행, 구독 매개변수, 원격 연결, DNS와 라우팅 순서로 확인하고 각 단계에서 관찰 가능한 결과를 남기세요.

1단계: 직접 연결 네트워크와 시스템 상태 확인

먼저 클라이언트의 트래픽 가로채기를 중지하고 TUN을 끄며 시스템 프록시를 지운 뒤, 현재 네트워크에서 기기가 일반 웹사이트에 직접 접근할 수 있는지 확인하세요. 직접 연결 자체가 실패하면 서버 설정을 바꾸기보다 Wi-Fi 인증, 모바일 데이터, 라우터, 시스템 시간 또는 DNS를 먼저 처리해야 합니다. 공용 네트워크는 인증 페이지를 열어야 할 수 있고, 기업 네트워크는 알 수 없는 포트를 제한할 수 있으며, 절전 모드 복귀 후 네트워크 카드가 주소를 제대로 받지 못할 수도 있습니다. 직접 연결 기준선이 정상이어야 다음 테스트가 의미 있습니다.

다른 프록시 클라이언트, 가상 네트워크 프로그램이나 남은 환경 변수가 없는지도 확인하세요. Windows에서는 시스템 프록시와 로컬 리스닝을, macOS에서는 현재 네트워크 서비스와 터미널 변수를, Linux에서는 데스크톱 프록시, 환경 변수와 정책 라우팅을, Android에서는 시스템 연결 상태와 백그라운드 제한을 확인합니다. v2rayN이나 v2rayNG를 종료했는데도 네트워크가 계속 가로채어진다면 시스템 계층에 잔여 설정이 있는 것이므로 먼저 복구한 뒤 진행하세요.

2단계: 클라이언트와 커널이 실제로 시작되었는지 확인

창이 열린다고 커널이 실행 중이라는 뜻은 아닙니다. 서버를 선택한 뒤 상태 영역과 로그를 확인해 설정 생성이 성공했고 로컬 포트가 리스닝을 시작했으며 즉시 종료되지 않았는지 확인하세요. 설정 파싱 오류는 보통 필드, 프로토콜 또는 JSON 위치를 명확히 표시하고, 포트 충돌은 리스닝 실패로 나타나며, 권한 문제는 TUN 인터페이스나 네트워크 확장을 생성할 때 자주 발생합니다. 로그의 첫 번째 핵심 오류부터 처리하세요. 이후 오류는 앞선 오류의 연쇄 결과인 경우가 많습니다.

로컬 포트가 리스닝하지 않으면 시스템 프록시가 해당 포트를 가리켜도 연결되지 않습니다. 포트를 변경했다면 시스템 프록시, 브라우저 설정과 터미널 환경 변수도 함께 업데이트하세요. 여러 클라이언트가 동시에 시작되면 나중에 시작한 클라이언트가 기본 포트를 사용하지 못할 수 있습니다. 모든 인스턴스를 종료하고 포트가 해제되었는지 확인한 뒤 대상 클라이언트 하나만 시작하는 것이 충돌을 확인하는 가장 직접적인 방법입니다.

3단계: 구독 실패와 서버 실패 구분

구독 업데이트 성공은 설정을 가져와 파싱할 수 있다는 뜻일 뿐 그 안의 모든 서버가 사용 가능하다는 뜻은 아닙니다. 반대로 구독 업데이트가 실패해도 이미 저장된 기존 서버에는 영향이 없을 수 있습니다. 문제를 해결할 때 두 결과를 별도로 기록하세요. 구독 주소가 업데이트되는지, 기존 서버가 연결을 수립하는지 확인해야 합니다. 모든 항목이 동시에 실패하면 현재 네트워크, 구독의 일괄 변경, 클라이언트 커널 또는 DNS를 우선 확인하고, 항목 하나만 실패하면 해당 서버 매개변수나 원격 상태일 가능성이 큽니다.

설정을 수동으로 확인할 때는 주소, 포트, 사용자 식별자, 프로토콜, 전송 방식, TLS 보안 유형, 서버 이름, 경로와 서비스 이름을 중점적으로 대조하세요. 무작위로 프로토콜을 바꾸거나 TLS를 끄며 운에 맡기지 마세요. 설정이 서버와 더 멀어질 수 있습니다. 서버에서 새 구독을 제공했다면 기존 항목에 수정을 누적하지 말고 다시 업데이트해 새 항목으로 테스트하세요.

4단계: 로그 단계에 따라 방향 판단

“연결 시간 초과”만으로 서버를 사용할 수 없다고 단정할 수는 없습니다. 현재 네트워크, DNS 응답, IPv6 경로와 방화벽도 같은 결과를 만들 수 있습니다. 가장 효과적인 교차 테스트는 서버를 유지한 채 네트워크를 바꾸고, 네트워크를 유지한 채 서버를 바꾸는 것입니다. 같은 서버가 다른 네트워크에서 정상이라면 현재 네트워크 경로 문제일 가능성이 크고, 같은 네트워크에서 다른 서버가 정상이라면 해당 항목이나 원격 서버 문제일 가능성이 큽니다. 한 번에 하나의 변수만 바꿔야 결론을 신뢰할 수 있습니다.

5단계: 연결되지만 정상적으로 사용할 수 없는 문제 처리

클라이언트에는 연결됨으로 표시되지만 웹페이지가 열리지 않으면 먼저 앱 요청이 로그에 들어오는지 확인하세요. 요청이 전혀 없으면 시스템 프록시, 앱별 프록시 또는 TUN 라우팅을 점검하고, 요청은 있지만 DNS가 실패하면 기본 DNS로 복원하세요. 도메인 해석은 성공하지만 원격 연결이 시간 초과되면 서버와 네트워크를 확인하고, 일부 웹사이트만 실패하면 IPv6, MTU, 라우팅 규칙과 대상 주소 선택을 점검하세요. 브라우저에서만 실패한다면 브라우저 내장 프록시, 비공개 DNS, 확장 프로그램 설정과 캐시도 확인해야 합니다.

웹페이지는 열리지만 속도가 비정상적일 때 노드 목록의 응답 시간만 믿지 마세요. 실제 속도는 서버 부하, 회선, 대상 사이트, 전송 방식과 현재 네트워크의 영향을 함께 받습니다. 일괄 속도 측정, 다운로드 작업과 대역폭을 사용하는 다른 프로그램을 끄고 같은 대상을 기준으로 비교하세요. Mux가 모든 환경에서 성능을 높이는 것은 아닙니다. 모바일 네트워크나 불안정한 회선에서는 단일 연결 장애를 키울 수 있으므로 계속 끊기면 기본값으로 복원해 다시 테스트하세요.

6단계: 복구, 이전 및 유효한 로그 제출

복잡한 설정에서 문제 원인을 확인할 수 없으면 먼저 보존할 구독 주소와 사용자 지정 규칙을 내보낸 다음 최소 설정을 구성하세요. 구독 하나, 서버 하나, 기본 DNS, 기본 라우팅, 시스템 프록시만 사용합니다. 최소 설정이 성공하면 라우팅, TUN, DNS, FakeDNS, 앱별 프록시 순서로 하나씩 복원하세요. 특정 단계에서 문제가 다시 나타나면 클라이언트를 바로 재설치하지 않고 해당 설정으로 범위를 좁힐 수 있습니다.

기기 간 이전 시 실행 중인 캐시, 잠금 파일과 임시 설정을 복사하지 마세요. 구독 주소, 별도 수동 서버, 라우팅 규칙 설명과 필요한 DNS 선택을 우선 이전하세요. 플랫폼마다 권한, 경로와 네트워크 인터페이스 처리가 다르므로 설정 디렉터리를 통째로 복사하면 유효하지 않은 경로나 플랫폼 전용 상태가 따라올 수 있습니다. 이전 후에는 각 플랫폼 장의 안내에 따라 시스템 프록시 또는 TUN 권한을 다시 설정하세요.

다른 사람에게 로그를 제공할 때는 플랫폼, 클라이언트 이름, 시스템 프록시와 TUN 중 무엇을 사용하는지, 문제가 설치 후인지 설정 변경 후인지, 직접 연결이 정상인지와 최초의 핵심 오류를 설명하세요. 구독 주소, 전체 서버 도메인, 사용자 식별자, 비밀번호, 경로의 개인 디렉터리 이름과 식별 가능한 네트워크 정보를 삭제하세요. “사용할 수 없음”이라는 결론만 전달하지 마세요. 재현 절차와 계층별 결과가 긴 전체 로그보다 훨씬 유용합니다.

• 설치 패키지가 플랫폼, 프로세서 아키텍처와 패키지 체계에 맞습니다.
• 구독 업데이트와 서버 연결 결과를 각각 기록하고 같은 문제로 묶지 않습니다.
• 시스템 프록시, TUN, 앱 내부 프록시는 현재 필요한 하나의 진입점만 유지합니다.
• LAN과 내부 서비스에 명확한 직접 연결 규칙이 있습니다.
• 로그에서 구독, 사용자 식별자와 서버 민감 정보가 숨겨졌습니다.