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

01 / PREPARATION

공통 준비: 클라이언트, 코어, 구독과 노드 구분하기

네 가지 구성 요소의 역할

설치하기 전에 화면 프로그램, 프록시 코어, 구독과 노드를 구분해 이해해야 합니다. v2rayN, v2rayNG, v2flyNG는 설정 관리와 조작을 담당하는 클라이언트이고, Xray, V2Fly 등의 코어는 프로토콜 해석, 전송 연결, 라우팅 매칭과 로컬 리스닝을 담당합니다. 구독은 업데이트 가능한 서버 설정 모음이며, 노드는 그 안에 포함된 개별 아웃바운드 설정입니다. 클라이언트를 설치한다고 구독이 자동으로 생성되지는 않으며, 구독을 가져왔다고 사용 가능한 노드가 자동 선택되는 것도 아닙니다. 전체 연결 경로에는 클라이언트, 실행 가능한 코어 설정, 현재 노드와 올바른 로컬 프록시 진입점이 차례로 필요합니다.

데스크톱 플랫폼에서는 기본적으로 v2rayN을 사용하는 것이 좋습니다. Windows에서는 데스크톱 버전과 클래식 WPF 버전 중에서 선택할 수 있고, macOS와 Linux에서는 해당 아키텍처에 맞는 v2rayN 설치 패키지를 사용합니다. Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 선택하고, V2Fly 코어가 필요할 때 v2flyNG를 선택하세요. 세 클라이언트의 실제 설치 경로는 설치 패키지 페이지에 모아 두었으며, 이 안내서에서는 파일을 직접 배포하거나 특정 버전을 고정하지 않습니다.

다운로드 전 시스템과 프로세서 아키텍처 확인

Windows의 일반적인 기기는 x64를 선택합니다. macOS는 먼저 프로세서 유형을 확인해야 합니다. 시스템 정보에 Apple 칩으로 표시되면 arm64, Intel로 표시되면 x64를 선택하세요. Linux는 아키텍처와 함께 패키지 형식도 구분해야 합니다. Debian, Ubuntu 및 파생 배포판은 보통 deb를 선택하고, Fedora, Rocky Linux, openSUSE 등은 대체로 rpm을 선택합니다. 최근 Android 기기는 대부분 arm64를 사용하며, 아키텍처를 확인할 수 없거나 설치 중 호환되지 않는다는 메시지가 나타날 때만 범용 패키지로 바꾸세요.

구독 저장 전 출처와 필드 확인

구독 주소는 서비스 제공자가 생성하며 보통 접근 자격 증명을 포함하므로 민감한 설정으로 취급해 보관해야 합니다. 주소를 공개 로그, 스크린샷 또는 온라인 분석 페이지에 붙여 넣지 마세요. 가져오기 전에 주소가 메신저에서 잘리지 않았는지, 앞뒤에 공백이 없는지, 브라우저에서 복사할 때 줄바꿈이 섞이지 않았는지 확인하세요. 제공자가 일반 구독, 클라이언트 전용 구독, 단일 노드 링크를 함께 제공한다면 현재 클라이언트와 호환된다고 명시된 구독 형식을 우선 선택하세요. 구독 업데이트가 계속 실패할 때만 단일 노드 링크로 클라이언트 자체가 정상인지 확인합니다.

노드 설정에는 최소한 서버 주소, 포트, 프로토콜 인증 필드와 전송 파라미터가 포함됩니다. TLS 또는 REALITY를 활성화하면 서버 이름, 지문, 공개 키, 짧은 식별자 또는 경로가 추가로 필요할 수 있습니다. 직접 편집할 때는 이 필드들을 하나의 세트로 일관되게 유지해야 하며 주소와 포트만 바꿔서는 안 됩니다. VMess, VLESS, Trojan 등은 인증과 세션 방식을 나타내고, WebSocket, gRPC, TCP 등은 전송 방식을 나타내므로 서로 대체할 수 없습니다.

먼저 최소 검증 경로를 구성하기

처음 설정할 때 TUN, 사용자 지정 DNS, 복잡한 라우팅과 여러 구독을 한꺼번에 활성화하지 마세요. 클라이언트 설치, 구독 하나 가져오기, 서버 목록 업데이트, 노드 하나 선택, 코어 시작, 시스템 프록시 활성화 후 브라우저 접속 테스트 순서가 더 안정적입니다. 이 최소 경로가 정상인지 확인한 뒤 그룹, 자동 업데이트, TUN과 사용자 지정 규칙을 추가하세요. 문제가 생겨도 어느 단계에서 변수가 추가되었는지 명확히 판단할 수 있습니다.

테스트할 때는 클라이언트 로그 창을 열어 두세요. 정상적으로 시작되면 최소한 로컬 SOCKS 또는 HTTP 리스닝이 생성되었다는 내용이 표시되어야 하며, 포트 충돌, 설정 해석 실패 또는 권한 거부가 없어야 합니다. 접속 결과는 전체 경로의 사용 가능 여부만 보여 줄 뿐 특정 계층이 올바르다는 것을 단독으로 증명하지는 않습니다. 클라이언트에는 연결됨으로 표시되지만 웹페이지가 열리지 않는다면 노드를 계속 바꾸기보다 시스템 프록시가 클라이언트의 실제 리스닝 포트를 가리키는지 확인하세요. 더 자세한 단계별 점검은 프록시 연결됨으로 표시되지만 웹페이지가 열리지 않을 때의 점검 목록을 참고하세요.

02 / WINDOWS

Windows: v2rayN 설치, 구독 가져오기와 시스템 트래픽 처리

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

Windows용 v2rayN은 데스크톱 버전과 클래식 WPF 버전을 제공합니다. 데스크톱 버전은 크로스플랫폼 인터페이스를 사용하므로 macOS 및 Linux와 비슷한 화면 구성을 원하는 사용자에게 적합합니다. WPF 버전은 전통적인 Windows 조작 방식을 따르며 기존 안내서와 메뉴 위치가 더 유사합니다. 두 버전 모두 구독, 노드, 코어와 라우팅을 관리하므로 동시에 설치할 필요는 없습니다. 버전을 바꾸기 전에는 사용자 지정 서버와 규칙을 내보내고 실행 중인 기존 클라이언트를 종료해 두 인스턴스가 같은 로컬 포트를 차지하지 않도록 하세요.

설치가 끝나면 시작 메뉴에서 v2rayN을 실행합니다. 처음 실행할 때 네트워크 액세스 권한을 묻는다면 현재 실제로 사용하는 네트워크 유형만 허용하세요. 회사나 공용 네트워크에서는 추가 네트워크 범위를 무조건 허용하지 않는 것이 좋습니다. 클라이언트의 로컬 리스닝 주소는 보통 루프백 주소로 유지하면 되며 LAN에 리스닝할 필요는 없습니다. 포터블 방식으로 실행할 때는 시스템 임시 폴더나 동기화 프로그램이 계속 잠그는 폴더를 피하고, 설정 파일과 로그에 안정적인 쓰기 권한이 있는지 확인하세요.

구독을 가져오고 현재 서버 선택

구독 그룹 관리에서 그룹을 추가하고 구독 주소를 입력합니다. 그룹 이름은 서비스 출처나 용도를 사용하는 것이 좋으며 “그룹 1”처럼 식별하기 어려운 이름은 피하세요. 저장한 뒤 구독 업데이트를 실행하고 주 목록에 노드가 나타나야 해석이 완료된 것입니다. 이후 이름, 지역 또는 프로토콜로 필터링해 서버 하나를 선택하고 활성 서버로 지정하세요. 목록에서 클릭해 강조 표시하는 것만으로는 현재 아웃바운드가 전환되지 않을 수 있으므로 상태 영역에 표시되는 현재 서버 이름을 확인해야 합니다.

구독 업데이트는 원격 목록을 다시 읽어 옵니다. 직접 추가한 노드는 별도 그룹에 넣어 업데이트 과정에서 구독 내용으로 덮어써지지 않게 하세요. 여러 구독을 함께 사용할 때는 그룹마다 독립적인 업데이트 주기를 설정할 수 있지만 너무 짧은 간격은 권장하지 않습니다. 시작 후 한 번 업데이트하고 필요할 때 수동으로 업데이트하는 편이 변경 원인을 파악하기 쉽습니다. 노드가 많다면 구독 그룹과 서버 필터링 실전을 참고해 메모, 키워드와 정렬을 정리하세요.

시스템 프록시부터 검증하기

시스템 프록시는 먼저 브라우저와 Windows 프록시 설정을 따르는 애플리케이션을 검증할 때 적합합니다. 코어를 시작한 뒤 트레이 메뉴에서 시스템 프록시 설정을 선택하고 대상 사이트에 접속하세요. 이 모드에서는 보통 시스템의 HTTP 및 HTTPS 프록시가 v2rayN의 로컬 리스닝 포트를 가리키며, 코어가 현재 라우팅 규칙에 따라 직접 연결, 프록시 또는 차단을 결정합니다. 브라우저만 작동하고 특정 프로그램이 작동하지 않는다면 해당 프로그램이 시스템 프록시를 무시하는 경우가 많으며, 노드가 고장 났다는 뜻은 아닙니다.

포트를 확인해야 한다면 터미널에서 리스닝 상태를 확인할 수 있습니다. 구체적인 포트는 클라이언트 설정 페이지를 기준으로 하며 모든 설치가 같은 값을 사용한다고 가정하지 마세요.

netstat -ano | findstr LISTENING
Get-NetTCPConnection -State Listen | Sort-Object LocalPort

로그에 포트가 이미 사용 중이라고 표시되면 먼저 설정에서 SOCKS, HTTP와 API 포트가 서로 중복되지 않는지 확인한 다음 프로세스 번호로 점유 프로그램을 찾으세요. 식별할 수 없는 시스템 프로세스를 바로 종료하지 마세요. 기존 클라이언트를 종료하고 중복 시작 항목을 끄거나, v2rayN의 로컬 포트를 사용되지 않는 범위로 변경한 뒤 코어를 재시작하는 방법이 더 안전합니다.

TUN 모드와 Windows 특유의 문제

TUN은 가상 네트워크 인터페이스를 통해 시스템 프록시 설정을 읽지 않는 더 많은 트래픽을 처리합니다. 활성화하기 전에 다른 유사 네트워크 도구를 종료하고 v2rayN에 가상 인터페이스를 생성하는 데 필요한 권한이 있는지 확인하세요. 처음 켤 때 시스템이 네트워크를 다시 식별하면서 잠시 연결이 끊길 수 있습니다. 네트워크가 계속 끊겨 있다면 즉시 TUN을 끄고 시스템 프록시 모드가 작동하는지 확인한 뒤 가상 인터페이스, DNS와 라우팅 규칙을 점검하세요. 클라이언트를 동시에 다시 설치할 필요는 없습니다.

Windows에서 흔한 특유의 문제로는 보안 프로그램이 코어 하위 프로세스를 일시적으로 차단하는 경우, 절전 모드에서 복귀한 뒤 가상 인터페이스 상태가 동기화되지 않는 경우, 클라이언트가 비정상 종료된 후 시스템 프록시가 남는 경우, 기업 정책이 프록시 설정을 덮어쓰는 경우가 있습니다. 클라이언트를 정상 종료할 때는 먼저 시스템 프록시 또는 TUN을 끄세요. 프로그램이 이미 종료되었는데 브라우저가 계속 로컬 프록시에 연결하려 한다면 Windows 프록시 설정에서 수동 프록시를 끈 다음 클라이언트를 다시 시작하세요. 절전 모드 복귀 후 인터넷이 되지 않으면 먼저 코어를 재시작하고, 그래도 해결되지 않을 때 TUN을 껐다가 다시 활성화하세요. 보통 전체 설정을 삭제할 필요는 없습니다.

03 / MACOS

macOS: 칩에 맞는 v2rayN 설치와 권한 및 프록시 잔여 설정 처리

칩을 확인하고 알맞은 패키지 설치

시스템 정보 또는 “이 Mac에 관하여”를 열어 먼저 프로세서 유형을 확인하세요. Apple 칩 기기는 arm64 설치 패키지, Intel 기기는 x64 설치 패키지를 선택합니다. 아키텍처를 잘못 선택하면 애플리케이션이 실행되지 않거나 실행 직후 종료되거나 호환 변환 계층에 의존해 실행될 수 있습니다. 올바른 방법은 macOS 다운로드 페이지로 돌아가 알맞은 패키지를 다시 선택하는 것이며, 애플리케이션 권한을 계속 바꿔 아키텍처 문제를 감추면 안 됩니다.

설치할 때 v2rayN을 “응용 프로그램” 폴더에 넣은 뒤 해당 폴더에서 실행하세요. 처음 실행하면서 네트워크 액세스, 알림 또는 백그라운드 항목 권한을 요청하면 실제로 필요한 항목만 허용합니다. 시스템에서 애플리케이션 출처를 확인할 수 없다고 표시되면 먼저 파일이 공식 다운로드 경로에서 받은 것인지 확인한 다음 시스템의 “개인정보 보호 및 보안” 페이지에서 차단된 앱을 확인하고 허용하세요. 출처가 불분명한 재배포 페이지에서 의존성 프로그램을 추가로 설치하지 마세요.

구독 가져오기와 설정 디렉터리 관리

구독 설정으로 이동해 그룹을 추가하고 완전한 구독 주소를 붙여 넣은 뒤 저장하고 업데이트를 실행합니다. 업데이트는 성공했지만 목록이 비어 있다면 먼저 현재 보기에 키워드 필터가 적용되었거나 특정 그룹만 표시되고 있지 않은지 확인한 다음 로그에서 구독 해석 결과를 확인하세요. 브라우저에서는 주소가 내용을 반환하지만 클라이언트에서는 계속 실패한다면 시스템 시간, 프록시 순환과 인증서 서버 이름을 확인해야 하며 구독이 만료되었다고 바로 단정하지 마세요.

수동 노드와 구독 노드는 그룹을 나누어 저장해야 합니다. 설치 패키지 아키텍처를 바꾸거나 클라이언트를 다시 설치하기 전에는 클라이언트의 내보내기 기능으로 사용자 지정 노드와 라우팅 규칙을 저장하세요. 설정 디렉터리는 여러 사람이 공유하는 폴더로 사용하기에 적합하지 않습니다. 동기화 도구가 클라이언트가 파일을 쓰는 중 충돌 사본을 만들면 JSON 설정이 중복되거나 잘릴 수 있습니다. 시작 후 설정이 갑자기 이전 상태로 돌아갔다면 먼저 클라이언트를 종료하고 여러 설정 사본이 동시에 동기화되고 있지 않은지 확인하세요.

시스템 프록시의 적용 범위

시스템 프록시를 활성화하면 v2rayN이 현재 네트워크 서비스의 웹 프록시 설정을 조정합니다. 브라우저와 시스템 네트워크 설정을 따르는 앱은 로컬 HTTP 또는 SOCKS 진입점에 연결하지만 자체 네트워크 스택을 구현한 앱은 이 설정을 무시할 수 있습니다. 무선 네트워크, USB 네트워크 또는 유선 네트워크로 전환한 뒤에는 새 네트워크 서비스에도 프록시 설정이 적용되었는지 확인하세요. macOS는 네트워크 서비스별로 일부 설정을 저장하기 때문입니다.

시스템 명령으로 현재 네트워크 서비스를 확인한 다음 프록시 상태를 점검할 수 있습니다. 네트워크 서비스 이름은 현지화되어 표시될 수 있으므로 첫 번째 명령의 출력 결과를 기준으로 하세요.

networksetup -listallnetworkservices
scutil --proxy

클라이언트가 이미 종료되었는데 웹페이지가 열리지 않는다면 먼저 시스템 네트워크 설정에서 현재 네트워크 서비스의 웹 프록시와 보안 웹 프록시를 끈 다음 v2rayN을 다시 시작하세요. 클라이언트가 실행 중일 때 시스템 프록시 포트를 수동으로 다른 값으로 바꾸면 화면 표시와 실제 시스템 설정이 분리될 수 있습니다. 포트를 사용자 지정해야 한다면 클라이언트에서 변경하고 코어를 재시작해 시스템 프록시 설정도 함께 갱신되도록 하세요.

TUN, DNS와 절전 모드 복귀

macOS의 TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅을 조정하므로 처음 활성화할 때 시스템 권한이 필요할 수 있습니다. 권한을 허용한 뒤에는 기본 라우팅과 DNS 설정으로 먼저 테스트하고 사용자 지정 도메인 규칙을 바로 추가하지 마세요. TUN을 끈 뒤에도 네트워크가 복구되지 않으면 가상 인터페이스가 사라졌는지, 기본 경로가 현재 물리 네트워크로 돌아왔는지, 시스템 DNS가 중지된 로컬 포트를 여전히 가리키는지 차례로 확인하세요.

덮개를 닫아 절전 모드로 전환하거나 네트워크와 핫스팟을 바꾸면 인터페이스 순서가 달라질 수 있습니다. 복귀 후 클라이언트는 실행 중으로 표시되지만 접속할 수 없다면 먼저 구독을 새로 고칠 것이 아니라 코어를 재시작해 리스닝 포트, 라우팅과 DNS를 현재 네트워크에 다시 연결해야 합니다. 시스템 프록시가 정상이고 단일 노드 테스트가 가능한 경우에만 TUN을 다시 켜세요. TLS 연결 오류가 계속되면 시스템 시간이 자동으로 동기화되는지, 서버 이름이 노드 설정과 일치하는지도 확인하세요. 관련 판단 방법은 TLS 핸드셰이크와 인증서 오류 점검을 참고하세요.

macOS 방화벽 또는 단말 관리 정책이 백그라운드 네트워크 확장을 제한할 수 있습니다. 로그에 권한 거부가 명확히 표시되면 계속 재설치하지 말고 기기 관리 규칙에 따라 처리하세요. 관리되는 기기의 프록시 정책은 로그인할 때 일괄 적용될 수 있으므로 클라이언트 설정에는 문제가 없어도 시스템 프록시가 계속 유지되지 않을 수 있습니다. 시스템 프록시 조회 결과와 클라이언트 리스닝 상태를 함께 확인해 문제가 정책 계층인지 코어 계층인지 판단하세요.

04 / LINUX

Linux: 패키지 설치, 데스크톱 프록시, 환경 변수와 TUN

배포판과 아키텍처에 맞는 패키지 선택

Linux용 v2rayN은 deb 및 rpm 패키지를 제공하며 x64와 arm64로 구분됩니다. 먼저 아키텍처 조회 명령을 실행하세요. x86_64가 출력되면 x64, aarch64 또는 arm64가 출력되면 arm64를 선택합니다. Debian, Ubuntu 및 파생 배포판은 보통 deb를 사용하고, Fedora, Rocky Linux와 RPM 패키지 관리 방식을 사용하는 배포판은 rpm을 사용합니다. 다른 배포판에서 압축을 강제로 풀어 설치하면 데스크톱 실행 항목, 의존성 관계와 제거 기록이 제대로 관리되지 않을 수 있습니다.

uname -m
cat /etc/os-release

다운로드한 뒤 파일이 있는 디렉터리에서 해당 설치 명령을 실행하세요. 명령의 파일 이름은 다운로드 페이지에 표시된 실제 파일 이름으로 바꿔야 합니다.

sudo apt install ./v2rayN-package.deb
sudo dnf install ./v2rayN-package.rpm

apt install ./파일.deb은 저장소에서 제공되는 의존성도 함께 처리하므로 하위 수준의 압축 해제 명령을 직접 호출하는 것보다 일반적인 설치에 적합합니다. rpm 계열 배포판에서는 dnf install도 의존성 해석을 유지합니다. 의존성을 충족할 수 없다면 먼저 배포판 소프트웨어 저장소를 새로 고치고 누락된 라이브러리 이름을 확인하세요. 서로 다른 배포판의 기본 라이브러리를 섞어 설치하지 마세요. 설치가 끝나면 데스크톱 애플리케이션 메뉴에서 실행하고, 터미널에서 실행할 때는 그래픽 환경과 권한 오류를 확인할 수 있도록 출력을 유지하세요.

구독 가져오기와 데스크톱 세션

v2rayN의 구독 작업은 다른 데스크톱 플랫폼과 같습니다. 그룹 생성, 구독 주소 입력, 서버 업데이트, 활성 노드 선택, 코어 시작 순서로 진행합니다. Linux에서는 그래픽 세션 환경에도 주의해야 합니다. 관리자 권한으로 그래픽 클라이언트를 실행하면 설정 디렉터리의 소유자가 바뀌어 이후 일반 사용자가 실행할 때 설정을 쓰지 못할 수 있습니다. 따라서 소프트웨어 패키지 설치와 TUN 권한 설정에만 권한 상승 명령을 사용하고, v2rayN을 장기간 관리자 권한으로 실행하지 마세요.

데스크톱 환경에 따라 시스템 프록시 진입점도 다릅니다. GNOME, KDE 등에는 보통 네트워크 프록시 설정이 있지만 모든 앱이 이를 읽는지는 애플리케이션의 네트워크 구현에 따라 달라집니다. v2rayN 시스템 프록시를 켠 뒤 브라우저와 터미널 프로그램을 각각 테스트하세요. 브라우저는 정상인데 명령줄 도구가 직접 연결된다면 터미널이 데스크톱 프록시를 읽지 않는다는 뜻이며 코어 오류가 아닙니다.

터미널 프로그램의 프록시 환경 변수

현재 터미널 세션에서만 로컬 HTTP 프록시를 사용하려면 환경 변수를 임시로 설정할 수 있습니다. 포트는 v2rayN의 HTTP 인바운드와 일치해야 합니다. 명령이 끝나면 unset으로 삭제해 패키지 관리자나 내부 네트워크 도구가 모르는 사이 로컬 프록시를 계속 사용하지 않게 하세요.

export http_proxy=http://127.0.0.1:로컬HTTP포트
export https_proxy=http://127.0.0.1:로컬HTTP포트
export no_proxy=localhost,127.0.0.1
unset http_proxy https_proxy no_proxy

여기서 “로컬HTTP포트”는 설명용 문구이므로 실행 전에 클라이언트 설정에 표시된 숫자로 바꿔야 합니다. 로그인, 업데이트, 컨테이너와 백그라운드 작업에 미치는 영향을 명확히 검토한 경우가 아니라면 모든 사용자의 전역 설정에 환경 변수를 영구적으로 저장하지 마세요. SOCKS 프록시는 모든 프로그램에서 HTTP 프록시로 바로 사용할 수 없습니다. 프로그램이 SOCKS를 명시적으로 지원한다면 해당 매개변수 형식에 따라 socks5://127.0.0.1:포트를 입력하세요.

TUN 권한, 라우팅과 DNS

Linux의 TUN은 시스템의 가상 네트워크 장치, 라우팅 기능과 적절한 권한에 의존합니다. 활성화에 실패하면 먼저 장치가 존재하는지 확인한 뒤 로그를 통해 권한 부족, 모듈 사용 불가 또는 라우팅 추가 실패인지 판단하세요. 클라이언트 전체에 제한 없는 관리자 권한을 바로 부여하지 마세요. 배포판이 권한 부여나 서비스 구성 요소를 통해 TUN을 구현한다면 클라이언트가 제공하는 설치 절차를 사용하고 업데이트 후에도 권한이 유지되는지 확인하세요.

ls -l /dev/net/tun
ip address
ip route
resolvectl status

TUN을 켠 뒤 도메인은 해석되지 않지만 알고 있는 주소에 직접 접속하면 응답이 있다면 문제는 대개 DNS 경로에 있습니다. 둘 다 실패한다면 기본 라우팅, 정책 라우팅과 방화벽을 먼저 점검하세요. systemd-resolved를 사용하는 시스템에서는 /etc/resolv.conf의 겉으로 보이는 내용만 보지 말고 현재 인터페이스가 실제로 사용하는 DNS도 확인해야 합니다. NetworkManager는 연결이 끊겼다가 다시 연결될 때 DNS와 라우팅을 덮어쓸 수 있으므로 네트워크 전환 후 코어를 재시작하고 다시 확인하세요.

Linux에서 발생하는 또 다른 특유의 문제는 데스크톱 세션과 백그라운드 프로세스가 분리되는 것입니다. 창을 닫아도 클라이언트가 트레이에 남아 있을 수 있고 데스크톱 환경이 종료될 때 함께 끝날 수도 있습니다. 원격 세션을 종료하기 전에는 시스템 프록시 또는 TUN을 직접 중지해 로컬 리스닝이 사라진 뒤에도 환경 변수가 남지 않도록 하세요. 로그에 “address already in use”가 표시되면 ss -lntup으로 리스닝 프로세스를 찾고, v2rayN이나 이전 코어 인스턴스가 중복 실행되고 있지 않은지 확인하세요.

05 / ANDROID

Android: v2rayNG, v2flyNG 설치와 앱 트래픽 처리

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

Android에서는 Xray 코어를 사용하고 일반적인 프로토콜과 전송 설정을 지원하는 v2rayNG를 우선 선택합니다. V2Fly 코어가 필요하다면 v2flyNG를 사용할 수 있습니다. 두 앱을 각각 설치할 수는 있지만 일상적으로는 하나의 클라이언트만 시스템 VPN 인터페이스를 생성하도록 해야 합니다. 나중에 실행한 앱이 이전 연결을 대체하기 때문입니다. 설치 패키지는 arm64와 범용 버전을 제공하며 최근 주류 기기에서는 arm64를 우선 선택하세요. 설치 호환성 문제가 발생하거나 아키텍처를 확인할 수 없을 때만 범용 버전을 사용합니다.

Android 다운로드 페이지에서 설치 패키지를 받은 뒤 시스템에서 현재 브라우저나 파일 관리자가 앱을 설치하도록 허용해야 할 수 있습니다. 설치가 끝나면 해당 출처의 임시 설치 권한을 끄세요. 업그레이드할 때는 같은 클라이언트에 맞는 설치 패키지로 덮어 설치하면 기존 설정을 유지할 수 있습니다. 시스템에서 서명이 일치하지 않는다고 표시되면 앱을 삭제하고 무작정 다시 설치하지 말고 먼저 다운로드 출처와 앱 이름을 확인하세요. 필요하면 설정을 내보낸 뒤 처리합니다.

구독 가져오기와 노드 선택

v2rayNG를 열고 구독 그룹 설정으로 이동해 구독 주소를 추가하고 저장한 다음 메뉴에서 구독 업데이트를 실행합니다. 업데이트가 끝나면 주 목록으로 돌아와 노드 하나를 선택해 현재 설정으로 지정하세요. 목록 왼쪽 또는 상태 영역의 선택 표시로 현재 노드를 확인할 수 있습니다. 업데이트 성공 메시지가 떴는데 새 노드가 없다면 잘못된 그룹에 들어간 것은 아닌지, 구독이 빈 내용을 반환한 것은 아닌지, 목록 필터가 새 항목을 숨기고 있지는 않은지 확인하세요.

클립보드에서 단일 링크를 가져와 특정 노드를 검증하거나 구독 해석 문제를 분리할 수도 있습니다. 클립보드에는 메신저 텍스트와 링크가 함께 들어 있을 수 있으므로 가져오기 전에 완전한 설정 링크만 복사하세요. QR 코드는 다른 기기로 단일 설정을 옮길 때 유용하지만 접근 파라미터가 포함되므로 공개해서는 안 됩니다. 노드가 많다면 구독 그룹으로 관리해 서버 파라미터를 하나씩 업데이트하는 일을 피하세요.

연결 시작과 앱별 라우팅

노드를 선택한 뒤 연결 버튼을 누르면 시스템이 처음 VPN 인터페이스를 만들 때 권한 승인 대화상자를 표시합니다. 승인하면 클라이언트가 로컬에 트래픽 진입점을 만들고 라우팅 설정에 따라 어떤 연결을 프록시 아웃바운드로 보낼지 결정합니다. 상태 표시줄의 연결 표시는 인터페이스가 생성되었다는 뜻일 뿐 원격 핸드셰이크가 성공했다는 의미는 아닙니다. 클라이언트 테스트 결과와 로그도 계속 확인하세요. 노드 테스트에 실패하면 먼저 같은 구독의 다른 노드로 바꿔 단일 노드 문제인지 모든 설정의 문제인지 판단합니다.

Android의 앱별 프록시는 어떤 앱을 클라이언트로 보낼지 지정할 수 있어 프록시가 필요 없는 로컬 트래픽을 줄이는 데 적합합니다. 설정할 때 “선택한 앱만 프록시”와 “선택한 앱 우회” 중 어느 방식인지 명확히 확인해야 하며 두 논리는 서로 반대입니다. 목록을 바꾼 뒤에는 다시 연결해 시스템 인터페이스가 새 규칙을 읽도록 하세요. 브라우저는 접속되지만 대상 앱이 작동하지 않는다면 먼저 앱별 목록, 대상 앱 자체의 DNS 동작과 백그라운드 네트워크 제한을 확인하세요.

백그라운드 제한, 비공개 DNS와 모바일 네트워크 전환

시스템 절전 정책이 v2rayNG 또는 v2flyNG의 백그라운드 실행을 제한할 수 있습니다. 일정 시간 화면을 잠근 뒤 연결이 끊기거나 앱으로 돌아와야 복구되는 현상이 대표적입니다. 시스템 배터리 관리에서 클라이언트가 필요한 백그라운드 활동을 유지하도록 허용하고 데이터 절약 모드가 네트워크 연결을 차단하지 않는지 확인하세요. 네트워크 기능과 무관한 권한을 클라이언트에 부여할 필요는 없습니다. 백그라운드 정리 도구가 VPN 앱을 강제 종료한다면 현재 클라이언트를 자동 종료 목록에서 제외하세요.

시스템의 “비공개 DNS”를 활성화하면 도메인 요청이 클라이언트가 예상한 DNS 경로를 우회하거나 노드 설정과 다른 방식으로 해석될 수 있습니다. 주소 연결은 정상인데 도메인에 접속할 수 없다면 일시적으로 자동 DNS로 되돌려 비교 테스트한 뒤 시스템 설정을 유지할지 클라이언트가 통합 처리하게 할지 결정하세요. 사용자 지정 DNS 계층을 여러 개 동시에 활성화하지 마세요. 로그에는 최종 실패만 남아 요청이 어느 계층에서 바뀌었는지 확인하기 어렵습니다.

무선 네트워크와 모바일 네트워크를 전환하면 로컬 출구가 바뀝니다. 전환 후 연결된 것처럼 보여도 하위 세션은 이미 무효화되었을 수 있으므로 연결을 끊었다가 다시 연결하세요. 공용 네트워크에서 웹 인증이 필요하면 먼저 클라이언트를 일시 중지하고 네트워크 로그인을 완료한 뒤 연결을 복구합니다. 특정 네트워크에서만 작동하지 않는다면 해당 네트워크의 DNS, IPv6와 포트 제한을 비교하고 구독을 바로 삭제하지 마세요. TLS 오류가 있으면 시스템 시간이 자동으로 동기화되는지와 노드의 서버 이름이 완전한지도 확인해야 합니다.

06 / SUBSCRIPTION · ROUTING

구독, 노드와 라우팅 분할: 플랫폼 공통 관리 방법

구독 업데이트는 노드 전환이 아닙니다

구독 업데이트는 지정된 주소에서 노드 모음을 다시 가져오는 작업이고, 노드 전환은 현재 사용할 아웃바운드를 바꾸는 작업이므로 서로 독립적입니다. 업데이트 후 기존 노드가 삭제되거나 이름과 파라미터가 바뀔 수 있습니다. 클라이언트에 이전 이름이 계속 표시되면 서버 목록으로 돌아가 현재 선택 항목을 다시 확인하세요. 자동 업데이트를 설정할 때는 적절한 간격을 유지하고 수동 업데이트 결과를 한 번 확인해야 합니다. 지나치게 자주 요청해도 노드 사용 가능성이 높아지지 않으며 오히려 설정 변경을 추적하기 어려워집니다.

여러 구독을 사용하는 환경에서는 출처별로 그룹을 만들고 메모에 지역, 회선 또는 용도를 기록하는 것이 좋습니다. 노드의 원래 이름만으로 프로토콜과 보안 파라미터를 판단하지 마세요. 이름은 표시용 텍스트일 뿐입니다. 노드 설정을 확인해야 한다면 상세 정보에서 프로토콜, 주소, 포트, 전송, 보안 계층과 서버 이름을 확인하세요. 구독 노드를 제공자가 관리한다면 차이를 명확히 아는 경우가 아니면 핵심 필드를 개별적으로 수정하지 않는 것이 좋습니다. 다음 업데이트에서 로컬 수정 사항이 덮어써질 수 있습니다.

되돌릴 수 있는 설정 기준 만들기

복잡한 규칙을 추가하기 전에 작동하는 기본 설정을 하나 보존하세요. 구독 하나, 검증된 노드 하나, 기본 라우팅과 기본 DNS로 구성하면 됩니다. 매번 한 종류의 설정만 수정하세요. 예를 들어 도메인 직접 연결 규칙을 추가하고 검증한 다음 주소 규칙을 추가합니다. 문제가 생기면 이전에 작동하던 상태로 되돌릴 수 있습니다. 클라이언트에 내보내기 기능이 있다면 그룹과 라우팅을 크게 조정하기 전에 설정을 내보내세요. 내보낸 파일에는 노드 접근 파라미터가 포함되므로 민감한 파일로 보관해야 합니다.

노드 테스트는 필터링 도구로만 사용해야 합니다. TCP 연결 성공은 서버 포트에 연결할 수 있다는 뜻이지 인증, TLS, 전송 경로와 최종 아웃바운드가 모두 정상이라는 뜻은 아닙니다. 실제 판단은 코어 로그와 완전한 접속 테스트를 함께 확인해야 합니다. 테스트 결과가 갑자기 모두 실패하면 전체 노드를 동시에 삭제하기보다 로컬 네트워크, 시스템 시간, DNS와 구독 필드를 먼저 확인하세요.

라우팅 매칭 순서 이해하기

라우팅 규칙은 보통 순서대로 매칭되며 먼저 일치한 규칙이 직접 연결, 프록시 또는 차단을 결정합니다. 범위가 넓은 규칙을 앞에 두면 뒤의 정밀한 규칙이 덮어써질 수 있습니다. 예를 들어 모든 도메인에 적용되는 프록시 규칙을 먼저 작성하면 뒤에 있는 특정 도메인 직접 연결 규칙은 실행될 기회를 얻지 못합니다. 관리하기 쉬운 순서는 명확한 LAN 및 로컬 대상, 별도 처리가 필요한 정확한 도메인, 분류 규칙, 마지막으로 기본 아웃바운드입니다.

아래는 코어 라우팅 구조를 단순화한 예시로, 필드 계층과 매칭 방식을 보여 줍니다. 실제 아웃바운드 태그는 클라이언트가 생성한 설정과 일치해야 하며 이름을 임의로 가정해서는 안 됩니다.

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

geoip:private는 일반적인 사설 주소 범위를 매칭해 LAN 장치가 원격 서버로 전송되지 않도록 합니다. 예시 도메인은 규칙 형식을 설명하기 위한 용도입니다. 클라이언트 그래픽 인터페이스가 이 필드를 사전 설정 규칙으로 묶어 제공할 수 있지만, 활성화하기 전 사전 설정의 매칭 순서와 기본 아웃바운드를 확인해야 합니다. 주소 규칙과 도메인 규칙은 완전히 같지 않습니다. 앱이 먼저 도메인을 해석한 후 주소로 연결하면 코어가 어느 계층의 정보를 볼 수 있는지는 트래픽 처리 방식과 DNS 흐름에 따라 달라집니다.

분할 라우팅이 작동하지 않을 때 확인할 정보

시스템 프록시 모드에서는 HTTP 프록시를 지원하는 앱이 보통 도메인을 프록시 진입점에 전달하므로 도메인 규칙이 비교적 쉽게 적용됩니다. 일부 앱은 로컬에서 먼저 해석한 뒤 주소로 연결하므로 IP 규칙만 매칭될 수 있습니다. TUN 모드는 더 넓은 트래픽을 처리할 수 있지만 DNS 스니핑과 라우팅 설정도 함께 필요합니다. 분할 결과가 예상과 다르면 웹사이트 표시만 보고 출구를 추측하지 말고 먼저 로그에서 실제로 어떤 규칙이 매칭되었는지 확인한 뒤 순서를 조정하세요.

LAN 프린터, 라우터 관리 페이지 또는 개발 서버를 직접 연결로 유지해야 한다면 사설 주소 직접 연결을 유지하고 클라이언트가 로컬 네트워크 액세스를 허용하는지 확인하세요. 시스템 프록시가 루프백 주소에만 바인딩되어 있으면 로컬 앱은 사용할 수 있지만 LAN의 다른 기기는 이를 프록시 진입점으로 사용할 수 없습니다. 명확한 필요가 없다면 LAN 리스닝을 활성화하지 마세요. 공유 리스닝에는 방화벽, 접근 제어와 네트워크 경계 설정도 필요하므로 일반적인 단일 기기 설정에 해당하지 않습니다.

07 / PROXY · TUN · DNS

시스템 프록시, TUN과 DNS: 세 경로의 연동 방식

시스템 프록시는 프록시를 능동적으로 사용하는 앱만 처리합니다

시스템 프록시는 운영체제의 HTTP, HTTPS 또는 SOCKS 프록시 설정을 클라이언트의 로컬 리스닝 포트로 지정하는 방식입니다. 브라우저와 시스템 설정을 따르는 프로그램이 해당 포트에 직접 연결하면 클라이언트가 요청을 현재 노드로 전달합니다. 경로가 명확하고 권한 요구가 낮으며 문제가 생겨도 복구하기 쉽다는 장점이 있지만, 일부 프로그램은 시스템 프록시를 읽지 않고 UDP 트래픽과 사용자 지정 네트워크 스택도 이 진입점을 거치지 않을 수 있습니다.

시스템 프록시를 점검할 때는 시스템 설정의 프록시 주소, 프록시 포트와 클라이언트의 실제 리스닝 주소라는 세 값을 함께 확인해야 합니다. 흔한 오류는 클라이언트가 로컬 포트를 변경했는데 시스템에는 이전 값이 남아 있거나, 클라이언트가 종료된 뒤에도 시스템이 존재하지 않는 로컬 포트에 계속 연결하는 경우입니다. 정상적으로 종료하기 전에 시스템 프록시를 끄면 잔여 설정을 줄일 수 있습니다. 시스템 프록시는 작동하지만 특정 앱만 작동하지 않는다면 앱 자체의 프록시 옵션을 확인하고 곧바로 전체 라우팅으로 바꾸지 마세요.

TUN은 네트워크 인터페이스와 라우팅을 처리합니다

TUN 모드는 가상 네트워크 인터페이스를 만들고 시스템 라우팅을 통해 더 많은 트래픽을 클라이언트로 보냅니다. 시스템 프록시를 지원하지 않는 앱, 통합 분할 라우팅이 필요한 데스크톱 환경과 일부 UDP 상황에 적합합니다. 더 낮은 계층에서 작동하므로 인터페이스 권한, 기본 라우팅, DNS, 방화벽과 다른 가상 네트워크 도구가 모두 결과에 영향을 줍니다. 먼저 같은 노드가 시스템 프록시 모드에서 작동하는지 확인해야 합니다. 그렇지 않으면 원격 노드와 로컬 인터페이스를 동시에 점검해야 해 판단이 어려워집니다.

TUN을 켜면 시스템에 물리 인터페이스, 루프백 인터페이스와 가상 인터페이스가 함께 존재하게 됩니다. 기본 라우팅 또는 정책 라우팅이 트래픽이 들어갈 경로를 결정합니다. 활성화 직후 전체 네트워크가 끊기면 먼저 TUN을 꺼서 기본 네트워크를 복구한 다음 로그에서 인터페이스 생성과 라우팅 추가 결과를 확인하세요. 네트워크가 끊긴 상태에서 여러 DNS와 MTU 파라미터를 연달아 바꾸면 복구 후 어떤 변경이 효과가 있었는지 알 수 없게 됩니다.

DNS는 도메인이 라우팅 판단으로 들어가는 방식을 결정합니다

DNS는 도메인을 주소로 변환하는 것뿐 아니라 도메인 규칙이 정확히 매칭될 수 있는지에도 영향을 줍니다. 시스템 프록시 모드에서 앱은 도메인을 로컬 프록시에 전달할 수도 있고 먼저 직접 해석할 수도 있습니다. TUN 모드에서는 클라이언트가 DNS를 처리해 도메인과 연결 사이의 연관성을 유지할 수 있습니다. 해석 요청이 클라이언트를 우회하면 라우팅 계층에는 대상 주소만 보일 수 있어 도메인 기준으로 설정한 규칙이 예상대로 실행되지 않습니다.

일반적인 DNS 이상은 세 가지로 나눌 수 있습니다. 요청이 예상한 해석기에 도달하지 않는 경우, 해석 결과는 올바르지만 잘못된 경로로 분할되는 경우, 해석기에는 도달하지만 현재 네트워크에 적합하지 않은 결과를 반환하는 경우입니다. 문제를 확인할 때는 먼저 시스템 도구로 도메인이 결과를 반환하는지 확인하고, 클라이언트 로그에 DNS 요청과 라우팅 매칭이 기록되었는지 살펴보세요. 운영체제, 클라이언트와 브라우저가 각각 캐시를 유지할 수 있으므로 브라우저 캐시만 지워서 판단하지 마세요.

전체 프록시와 규칙 프록시의 적용 범위

전체 프록시는 처리 가능한 트래픽을 현재 프록시 아웃바운드로 통일하는 방식이며, 노드를 짧게 검증할 때 적합합니다. 전체 모드에서는 작동하지만 규칙 모드에서는 작동하지 않는다면 문제는 대개 라우팅 규칙, DNS 또는 매칭 순서에 있습니다. LAN, 시스템 업데이트와 로컬 서비스는 직접 연결이 필요할 수 있으므로 모든 환경의 기본 해법으로 사용하기에는 적합하지 않습니다. 검증이 끝나면 점검이 완료된 규칙 모드로 되돌리세요.

규칙 프록시는 도메인, 주소, 포트, 네트워크 유형 또는 프로세스 조건에 따라 출구를 선택합니다. 규칙이 많아질수록 유지 관리 비용이 커집니다. 용도를 설명할 수 있는 규칙만 남기고 사용자 지정 항목에는 명확한 메모를 작성하세요. 규칙을 삭제하기 전 다른 항목이 해당 아웃바운드 태그에 의존하는지 확인해야 합니다. 클라이언트 업데이트나 구독 업데이트는 보통 별도로 저장한 라우팅 설정을 덮어쓰지 않지만, 전체 설정을 가져오면 현재 설정이 바뀔 수 있으므로 먼저 되돌릴 수 있는 사본을 내보내세요.

요청이 실제로 어느 진입점을 통과하는지 확인하려면 먼저 코어 액세스 로그를 관찰하고 앱의 프록시 설정과 대조하세요. 로그에 연결 기록이 전혀 없다면 문제는 앱과 로컬 진입점 사이에 있습니다. 인바운드 기록은 있지만 원격 연결이 없다면 라우팅과 아웃바운드 설정을 확인하세요. 원격 연결은 시작되었지만 핸드셰이크에 실패했다면 노드 파라미터, 시스템 시간과 네트워크 도달 가능성을 점검합니다. 이런 계층별 판단이 모드를 계속 바꾸는 것보다 빠릅니다.

08 / TROUBLESHOOTING

설정 문제 해결: 로컬 환경, 코어, 구독과 원격 서버를 계층별로 점검

먼저 현상을 기록한 뒤 문제 계층을 좁히기

문제를 점검하기 전에 네 가지 사실을 기록하세요. 현재 플랫폼과 클라이언트, 시스템 프록시와 TUN 중 어떤 방식을 사용하는지, 문제가 모든 노드에 영향을 주는지, 로그에 나타난 첫 번째 명확한 오류입니다. “사용할 수 없음”이라고만 기록하면 안 됩니다. 시작 실패, 도메인 해석 실패, 원격 핸드셰이크 실패와 특정 앱이 프록시를 사용하지 않는 현상은 처리 경로가 완전히 다릅니다. 한 번에 하나의 설정만 변경하고 다시 테스트해 여러 변화가 서로의 원인을 가리지 않게 하세요.

가장 짧은 점검 경로는 다음과 같습니다. 일반 네트워크가 작동하는지 확인하고, 클라이언트 프로세스와 코어 프로세스가 모두 실행 중인지 확인한 다음, 로컬 리스닝 포트가 존재하는지 확인합니다. 이어서 현재 노드가 선택되었는지, 시스템 프록시 또는 TUN이 적용되었는지 확인하고 마지막으로 원격 핸드셰이크와 라우팅 매칭을 점검하세요. 모든 노드가 동시에 실패하면 로컬 네트워크, 시간, DNS, 구독과 클라이언트 설정을 우선 확인합니다. 노드 하나만 실패한다면 해당 노드와 정상 노드의 주소, 포트, 전송과 보안 파라미터를 먼저 비교하세요.

코어가 시작 직후 종료됨

코어 시작 실패는 보통 로그 앞부분에 원인이 표시됩니다. 포트 충돌은 로컬 리스닝을 바인딩할 수 없다는 뜻이고, 설정 해석 오류는 생성된 JSON의 필드, 쉼표 또는 형식이 요구 사항과 맞지 않는다는 뜻입니다. 필수 파라미터 누락은 노드를 직접 편집할 때 보안 계층 필드를 빠뜨려 발생하는 경우가 많고, 권한 거부는 TUN 인터페이스나 보호된 디렉터리에서 자주 나타납니다. 첫 번째 오류부터 처리해야 하며 뒤의 오류는 앞선 실패로 인한 연쇄 결과일 수 있습니다.

포트 충돌이 발생하면 중복 실행된 클라이언트를 종료하거나 리스닝 포트를 변경하세요. 설정 오류라면 가장 최근의 수동 변경을 되돌리거나 최소 노드를 새로 만들어 비교합니다. 전체 로그를 삭제하고 마지막 한 줄만 남기지 마세요. 설정 파일 경로와 구체적인 필드는 보통 앞부분에 표시됩니다. 로그로 코어 시작 실패 원인 찾기를 참고해 오류 유형을 줄 단위로 판단할 수 있습니다.

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

“연결됨”은 클라이언트 상태가 실행 중으로 바뀌었다는 뜻일 뿐 브라우저가 로컬 프록시에 연결되었다는 의미는 아닐 수 있습니다. 먼저 시스템 프록시 주소와 포트를 확인하고 브라우저가 시스템 설정을 덮어쓰지 않는지 확인하세요. TUN 모드에서는 가상 인터페이스와 기본 라우팅을 점검합니다. 로그에 브라우저 요청이 전혀 없다면 문제는 앱과 로컬 진입점 사이에 있습니다. 로그에 요청은 있지만 DNS 실패가 표시되면 해석 경로를 확인하고, 원격 다이얼은 시작되었지만 시간 초과가 발생하면 주소, 포트와 네트워크 도달 가능성을 계속 점검하세요.

전체 모드에서는 작동하지만 규칙 모드에서는 작동하지 않는다면 기본 라우팅 규칙으로 되돌리거나 사용자 지정 규칙의 순서를 확인하세요. 주소에는 연결되지만 도메인에 실패한다면 추가로 설정한 비공개 DNS, 브라우저 보안 DNS 또는 시스템 사용자 지정 해석을 잠시 중지해 비교하세요. LAN 대상만 실패한다면 전체 라우팅을 끄지 말고 사설 주소 직접 연결을 추가하세요. 전체 항목별 목록은 연결 후 웹페이지에 접속할 수 없을 때의 단계별 점검에서 확인할 수 있습니다.

구독 업데이트 실패 또는 업데이트 후 목록이 비어 있음

먼저 구독 주소가 완전하며 공백, 줄바꿈 또는 만료된 파라미터가 없는지 확인하세요. 다음으로 현재 네트워크에서 구독 서비스에 접속할 수 있는지, 시스템 시간이 올바른지, 아직 시작되지 않은 로컬 프록시를 통해 클라이언트가 구독을 업데이트하려는 것은 아닌지 확인합니다. 그룹이 여러 개라면 올바른 그룹에 업데이트를 적용했는지 확인하고 목록 필터를 끈 상태에서 원본 결과를 확인하세요. 반환 내용은 있지만 해석에 실패한다면 구독 형식이 현재 클라이언트와 호환되는지 살펴보세요.

업데이트 후 노드 수가 줄었다고 해서 클라이언트가 데이터를 삭제한 것은 아닐 수 있습니다. 원격 구독 내용이 바뀌었을 가능성도 있습니다. 사용자 지정 노드는 별도 그룹에 넣어 원격 항목과 섞이지 않도록 하세요. 클라이언트의 해석 기능을 확인하려면 호환성이 명확한 단일 노드 설정을 가져올 수 있습니다. 단일 노드는 작동하지만 구독이 실패하면 문제는 구독 가져오기 또는 형식에 집중됩니다. 단일 노드도 실패한다면 코어 로그로 돌아가 계속 점검하세요.

TLS, 서버 이름과 시스템 시간

TLS 관련 오류는 구체적인 메시지와 함께 확인해야 합니다. 인증서가 아직 유효하지 않거나 만료되었다는 메시지가 나오면 먼저 시스템 날짜, 시간과 시간대를 확인하세요. 서버 이름이 일치하지 않는다면 노드의 serverName 또는 SNI가 서비스 설정과 일치하는지 확인합니다. 핸드셰이크가 일찍 종료되는 원인으로 전송 경로, 포트 또는 서버 상태도 고려해야 합니다. “인증서 검증 건너뛰기”를 일반적인 해결책으로 사용하지 마세요. 이는 인증 문제를 숨길 뿐 잘못된 주소, 서버 이름 또는 시간을 고치지 못합니다.

REALITY 설정에서는 공개 키, 짧은 식별자, 서버 이름과 지문 등의 필드도 서로 일치해야 합니다. 노드를 복사할 때 어느 하나라도 빠지면 핸드셰이크에 실패할 수 있습니다. 구독으로 관리되는 노드는 다른 노드를 참고해 필드를 추측하기보다 완전한 설정으로 다시 업데이트하는 것이 우선입니다. 자세한 분류는 TLS 핸드셰이크, SNI와 시간 확인을 참고하세요.

검증 가능한 상태로 되돌리기

여러 번 수정한 뒤 문제 원인을 확인할 수 없다면 모든 데이터를 삭제하지 말고 통제된 방식으로 되돌리세요. 보존할 수동 노드와 규칙을 먼저 내보내고, TUN, 사용자 지정 DNS와 추가 라우팅을 끈 다음 시스템 프록시 모드로 되돌립니다. 구독 하나와 노드 하나만 활성화하고 클라이언트를 재시작한 뒤 시작부터 첫 요청까지의 전체 로그를 관찰하세요. 최소 상태가 작동하면 설정을 하나씩 복구하고 각 항목을 복구할 때마다 테스트합니다.

클라이언트를 업데이트하기 전에도 같은 원칙을 적용해야 합니다. 현재 작동 모드를 기록하고 실행 중인 코어를 종료한 뒤 사용자 지정 설정을 저장하고 해당 플랫폼과 아키텍처에 맞는 패키지를 설치하세요. 업데이트 후에는 먼저 기본 경로를 검증하고 모든 설정을 즉시 변경하지 마세요. 화면은 실행되지만 기존 설정에 문제가 있다면 설정 마이그레이션 로그와 파일 권한을 확인하세요. Linux는 설정 디렉터리 소유권, Windows는 중복 프로세스, macOS는 네트워크 서비스의 프록시 잔여 설정, Android는 시스템 VPN 승인과 백그라운드 제한을 특히 확인해야 합니다.