전체 플랫폼 가이드

클라이언트와 플랫폼은 어떻게 대응하나요?

데스크톱에서는 v2rayN을 우선 사용합니다. Windows, macOS, Linux를 지원하며 그래픽 인터페이스에서 구독, 노드, 라우팅과 프록시 상태를 관리하기 좋습니다. Android에서는 v2rayNG를 우선 고려하고, 구독이나 사용 환경이 V2Fly 코어 설정을 중심으로 구성되어 있다면 v2flyNG를 선택할 수 있습니다. 두 Android 클라이언트는 인터페이스와 코어의 중점이 다르지만 기본 흐름은 같습니다. 구독 가져오기, 노드 업데이트, 구성 선택, 로컬 VPN을 통한 트래픽 전환을 차례로 진행한 뒤 접속을 확인합니다.

클라이언트, 코어와 구독을 같은 개념으로 보면 안 됩니다. 클라이언트는 인터페이스, 설정 관리와 시스템 트래픽 전환을 담당하고, Xray 또는 V2Fly 같은 코어는 설정에 따라 연결을 만들고 트래픽을 처리합니다. 구독 링크는 서비스 제공자가 생성하며 일반적으로 서버 주소, 포트, 사용자 식별자, 전송 방식과 TLS 또는 REALITY 등의 매개변수를 포함합니다. 클라이언트를 설치한다고 사용할 수 있는 노드가 자동으로 생기는 것은 아니며, 구독을 성공적으로 가져왔다고 해서 모든 노드에 연결되는 것도 아닙니다.

구독 정보를 준비하되 반복해서 가져오지는 마세요

시작하기 전에 유효 기간이 남아 있고 정상적으로 접속할 수 있는 구독 주소를 준비하세요. 구독 링크는 민감한 설정 정보이므로 공개 게시물, 스크린샷 또는 여러 사람이 공유하는 문서에 붙여 넣지 마세요. 제공자가 단일 VMess, VLESS 또는 다른 공유 링크를 제공했다면 클라이언트의 ‘클립보드에서 가져오기’ 기능을 사용할 수 있습니다. 구독 주소라면 구독 그룹을 만든 뒤 한 번 업데이트하세요. 두 입력 방식은 대상이 다릅니다. 단일 링크는 보통 하나의 노드를 만들고, 구독 주소는 제공자가 관리하는 여러 노드를 가져올 수 있습니다.

처음 가져오기 전에 링크 앞뒤에 공백이 있는지, 메신저가 매개변수를 잘라내지 않았는지, 브라우저가 특수 문자를 변경하지 않았는지 확인하세요. 가져온 뒤에는 즉시 연속으로 업데이트를 누르기보다 노드 이름과 개수가 예상과 맞는지 먼저 확인합니다. 구독 업데이트에 실패하면 주소 자체에 접근할 수 없는지, 시스템 시간이 잘못되었는지, 인증서 핸드셰이크가 실패했는지, 또는 현재 네트워크에서 기존 프록시를 거쳐야 구독 서비스에 접근할 수 있는지를 구분하세요. 업데이트를 계속 반복해도 같은 로그만 늘어날 뿐 근본 원인은 바뀌지 않습니다.

기존 프록시 및 DNS 상태 기록하기

설정 전에 시스템 프록시가 켜져 있는지, LAN 주소가 수동으로 설정되어 있는지, 브라우저에 별도 프록시 규칙이 설치되어 있는지, 시스템 DNS가 수동 값인지 기록하세요. 시스템 네트워크 설정을 캡처하거나 주요 값을 로컬 메모에 적어 두는 것이 가장 안전합니다. 이후 웹페이지가 열리지 않거나 LAN 기기에 연결할 수 없거나 클라이언트를 종료한 뒤에도 프록시가 남아 있으면 기존 상태로 복구할 수 있습니다. 회사, 학교 또는 고정 프록시가 필요한 네트워크에서는 기록 없이 기존 설정을 바로 덮어쓰지 마세요.

시스템 시간과 시간대도 올바른지 확인하세요. TLS와 REALITY 연결은 합리적인 시간 판단에 의존하므로 시간이 크게 어긋나면 인증서 오류, 핸드셰이크 중단 또는 연결 직후 종료로 나타날 수 있습니다. 시간 문제는 라우팅 규칙을 바꿔도 해결되지 않으므로 프로토콜 매개변수보다 먼저 확인해야 합니다.

다운로드 경로와 아키텍처 선택

모든 클라이언트 다운로드 경로는 다운로드 페이지에 모아 두었습니다. Windows에서는 일반적으로 x64를 선택합니다. macOS는 ‘이 Mac에 관하여’의 칩 유형에 따라 Apple Silicon 또는 Intel을 선택하세요. 최근 Android 기기는 대부분 arm64를 사용하며, 확실하지 않다면 범용 패키지를 선택할 수 있습니다. Linux는 x64와 arm64 외에도 배포판에 맞춰 deb 또는 rpm을 선택해야 합니다. 아키텍처를 잘못 고르면 설치 프로그램이 실행을 거부하거나 형식 오류가 발생하고 앱이 바로 종료될 수 있지만, 이는 구독 사용 가능 여부와는 관계가 없습니다.

설치하기 전에 기존 클라이언트를 종료하고 아직 적용 중인 시스템 프록시를 해제하세요. 여러 클라이언트가 하나의 로컬 포트를 동시에 사용하도록 두지 않는 것이 좋습니다. 병렬 비교가 꼭 필요하다면 각 클라이언트에 서로 다른 로컬 수신 포트를 설정하고, 현재 시스템 프록시를 어느 클라이언트가 수정하는지 명확히 하세요. 준비가 끝나면 해당 플랫폼 장으로 이동해 순서대로 진행합니다.

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

다운로드 페이지에는 v2rayN 데스크톱 버전과 클래식 WPF 버전이 있습니다. 데스크톱 버전은 새로운 크로스 플랫폼 인터페이스를 사용하므로 여러 데스크톱 시스템에서 비슷한 조작 방식을 유지하고 싶은 사용자에게 적합합니다. WPF 버전은 Windows에서 오래 사용된 클래식 인터페이스로 메뉴 위치와 관련 안내 자료가 비교적 안정적입니다. 두 버전 모두 구독 관리, 노드 선택, 라우팅 설정과 시스템 프록시 제어를 지원합니다. 처음 사용할 때는 한 가지만 설치해 두 인스턴스가 같은 시스템 프록시를 동시에 수정하지 않게 하세요.

Windows 다운로드 경로에서 적합한 설치 패키지를 받은 뒤 실행 중인 기존 버전을 먼저 종료하세요. 설치 방식이라면 설치 화면에서 현재 사용자가 쓸 수 있는 폴더를 선택합니다. 압축 해제 방식이라면 장기간 보관할 수 있고 쓰기 권한이 있는 위치에 풀어 사용하세요. 압축 파일 미리보기 창에서 바로 실행하지 마세요. 클라이언트는 설정, 로그와 코어 관련 파일을 기록해야 하므로 폴더에 쓸 수 없으면 설정 저장에 실패하거나 매번 처음 실행한 것처럼 동작할 수 있습니다.

최초 실행 및 구독 그룹

v2rayN을 실행한 뒤 먼저 구독 그룹 관리로 이동해 그룹 이름을 추가하고 구독 주소를 붙여 넣습니다. 그룹 이름은 ‘일상 구독’이나 ‘테스트 그룹’처럼 용도를 나타내도록 하고, 전체 구독 주소를 이름으로 사용하지 않는 것이 좋습니다. 저장한 뒤 구독 업데이트를 실행하고 기본 목록에 노드가 실제로 기록되었는지 확인하세요. 목록이 비어 있다면 안내 메시지와 로그를 확인합니다. 주소가 구독 내용이 아닌 웹페이지를 반환하거나, 링크가 만료되었거나, 로그인 페이지로 리디렉션되면 파싱에 실패할 수 있습니다.

구독 그룹은 관리 진입점이지 연결 상태가 아닙니다. 업데이트 성공은 클라이언트가 설정을 가져와 파싱했다는 뜻일 뿐입니다. 다음으로 노드 하나를 현재 활성 항목으로 선택하고 실제 연결 테스트를 실행하세요. 테스트에서는 다운로드 속도만 보지 말고 연결 수립 여부와 로그의 명확한 오류를 우선 확인합니다. 속도 측정은 대상 서버, 회선 혼잡과 로컬 대역폭의 영향도 받으므로 시스템 프록시가 브라우저를 실제로 제어한다는 것을 단독으로 증명하지 못합니다.

단일 링크 가져오기 및 매개변수 확인

단일 공유 링크를 받았다면 복사한 뒤 ‘클립보드에서 URL 일괄 가져오기’를 사용하세요. 가져온 후 노드 편집 화면에서 서버 주소, 포트, 사용자 식별자, 전송 방식, 보안 계층과 서버 이름 등의 필드가 모두 갖춰졌는지 확인합니다. VLESS 설정에서 TLS 또는 REALITY를 사용하는 경우 flow, 지문, 공개 키, 짧은 식별자와 serverName이 포함될 수도 있습니다. ‘호환성’을 이유로 모르는 매개변수를 임의로 삭제하지 마세요. 이런 값은 서버 측과 일치해야 하는 경우가 많습니다.

VMess와 VLESS 중 무엇을 선택할지 모르겠다면 프로토콜 이름만으로 속도를 판단할 필요는 없습니다. 프로토콜은 인증과 데이터 형식을 담당하고, TLS·REALITY·WebSocket·gRPC 등은 보안 및 전송 조합에 해당합니다. 실제 사용 가능 여부는 전체 매개변수가 일치하는지에 달려 있습니다. 자세한 내용은 VMess와 VLESS의 매개변수 차이를 읽은 뒤 클라이언트에서 항목별로 비교하세요.

먼저 시스템 프록시 테스트하기

대부분의 브라우저와 Windows 시스템 프록시를 따르는 데스크톱 앱은 처음 설정할 때 시스템 프록시를 사용하는 편이 문제를 찾기 쉽습니다. v2rayN의 시스템 프록시 메뉴에서 ‘시스템 프록시 자동 설정’을 선택한 다음 필요에 따라 라우팅 모드를 고르세요. 이 작업은 시스템 프록시를 클라이언트의 로컬 수신 포트로 지정하지만 모든 앱이 자동으로 따르는 것은 아닙니다. 일부 게임, 명령줄 도구, 가상 머신과 자체 네트워크 스택을 사용하는 소프트웨어는 시스템 프록시를 우회할 수 있습니다.

활성화한 뒤 평소 안정적으로 열리는 일반 웹사이트에 먼저 접속해 기본 네트워크가 끊기지 않았는지 확인하고, 이어서 프록시 경로를 확인할 대상 사이트에 접속하세요. 동시에 클라이언트 로그에 해당 연결이 나타나는지 확인합니다. 브라우저가 이전 연결을 계속 사용한다면 브라우저를 완전히 종료했다가 다시 열거나 캐시가 없는 새 창에서 재시험하세요. 자세한 교차 확인 방법은 v2rayN 최초 연결 확인을 참고하세요.

TUN의 권한과 범위

앱이 시스템 프록시를 따르지 않거나 더 많은 네트워크 트래픽을 한꺼번에 전환해야 할 때 TUN을 고려하세요. TUN은 가상 네트워크 인터페이스를 만들고 라우팅 규칙으로 트래픽을 받아 처리하므로 일반적으로 관리자 권한과 드라이버 지원이 필요합니다. 활성화하기 전에 시스템 프록시를 해제하거나 두 방식의 역할을 명확히 하여 동시에 켠 뒤 실제 경로를 판단하지 못하는 상황을 피하세요. 권한 부족 메시지가 나오면 클라이언트를 종료한 뒤 관리자 권한으로 실행하고, 가상 인터페이스 생성에 실패하면 기존 TUN 드라이버, 다른 VPN 소프트웨어와 보안 정책의 충돌을 확인하세요.

TUN은 ‘더 빠른 연결’을 위한 스위치가 아니라 트래픽 전환 범위를 바꾸는 기능입니다. LAN 접속, 가상 머신 네트워크, 개발 환경과 회사 내부망이 라우팅의 영향을 받을 수 있습니다. 활성화한 뒤 로컬 게이트웨이, LAN 기기와 자주 사용하는 내부 도메인을 테스트하고 사설 주소가 직접 연결 규칙에 포함되는지 확인하세요. 내부망에 접근할 수 없으면 먼저 TUN을 꺼서 복구되는지 확인한 뒤 geoip:private 또는 사설 대역 직접 연결 규칙을 점검하세요. 바로 노드를 바꾸지는 마세요.

Windows에서 자주 발생하는 충돌

포트 점유는 Windows에서 흔히 발생하는 문제입니다. 로그에 로컬 수신 실패가 나타나면 다른 v2rayN 인스턴스, 기존 클라이언트 또는 디버깅 도구가 같은 포트를 사용하고 있는지 확인하세요. 포트 번호만 무작정 큰 값으로 바꾸지 말고, 변경 후 시스템 프록시, 브라우저 확장 프로그램과 해당 포트를 사용하는 앱도 함께 업데이트해야 합니다. 보안 소프트웨어가 코어 프로세스를 차단하면 인터페이스는 정상인데 연결 로그가 전혀 없을 수도 있으므로 시스템 이벤트와 클라이언트 로그를 함께 확인하세요.

또 다른 오해는 ‘지연 시간 테스트에 결과가 나왔다’고 연결이 완료된 것으로 보는 것입니다. 지연 시간 테스트는 TCP 연결만 확인할 수 있지만, 실제 연결 테스트는 노드 프로토콜에 따라 실제 요청을 보냅니다. 실제 연결에 성공했더라도 시스템 프록시가 켜져 있지 않으면 브라우저는 직접 연결할 수 있습니다. 완전한 확인 순서는 노드 선택, 실제 연결 테스트, 한 가지 트래픽 전환 방식 활성화, 브라우저에서 새 요청 전송, 로그에서 해당 도메인 또는 대상 연결 확인, 마지막으로 다른 앱 테스트입니다.

Apple Silicon 또는 Intel 먼저 확인하기

시스템의 ‘이 Mac에 관하여’에서 칩 정보를 확인하세요. Apple M 시리즈로 표시되면 arm64 설치 패키지를, Intel 프로세서로 표시되면 x64 설치 패키지를 선택합니다. 아키텍처에 따라 클라이언트 기능의 우열이 생기는 것은 아니며 기기에 맞추기만 하면 됩니다. Apple Silicon 기기에 Intel 빌드를 잘못 설치하면 추가 변환 환경이 필요하거나 성능 및 호환성 문제가 생길 수 있으므로 기본적으로 네이티브 arm64 버전을 사용하세요.

macOS 다운로드 경로에서 해당 dmg 파일을 받은 뒤 디스크 이미지를 열고 앱을 ‘응용 프로그램’ 폴더로 드래그한 다음 그 폴더에서 실행하세요. 읽기 전용 디스크 이미지에서 장기간 실행하지 마세요. 앱 업데이트, 보조 구성 요소와 설정 기록이 제한될 수 있습니다. 최초 실행이 시스템에 의해 차단되면 전체 보안 기능을 끄지 말고 ‘개인정보 보호 및 보안’ 설정에서 이번 차단 기록을 확인한 뒤 실행을 허용하세요.

구독 가져오기 및 노드 선택

구독 그룹 관리로 이동해 구독 이름과 주소를 추가하고 저장한 뒤 업데이트하세요. macOS에서 구독 실패가 항상 클라이언트 때문인 것은 아닙니다. 시스템 DNS가 이름을 해석하지 못하거나, 현재 네트워크에 웹 인증이 필요하거나, 시간이 부정확하거나, 구독 서비스 인증서에 문제가 있어도 요청이 실패할 수 있습니다. 먼저 브라우저에서 네트워크 인증을 완료했는지 확인한 뒤 로그에서 이름 해석 실패인지, 연결 시간 초과인지, 인식할 수 없는 내용이 반환되었는지 확인하세요.

노드가 나타나면 하나를 선택해 실제 연결 테스트를 실행하세요. 같은 구독에서 일부 노드만 실패한다면 실패한 노드의 서버 이름, 포트, 전송 방식과 TLS 또는 REALITY 매개변수를 비교하고 구독 전체를 바로 삭제하지 마세요. 모든 노드가 핸드셰이크 단계에서 실패한다면 시스템 시간, 네트워크의 대상 포트 차단 여부와 구독이 새 사용자 식별자로 업데이트되었는지를 먼저 확인하세요.

시스템 프록시는 어떤 앱에 적합한가요?

macOS 시스템 프록시는 현재 네트워크 서비스의 프록시 항목에 기록됩니다. 브라우저와 시스템 네트워크 설정을 따르는 앱은 대체로 사용할 수 있지만, 터미널 명령, 일부 개발 도구와 자체적으로 연결을 관리하는 프로그램은 따르지 않을 수 있습니다. 활성화한 뒤 시스템 네트워크 세부 정보에서 프록시 상태가 바뀌었는지 확인하고 현재 사용 중인 네트워크 서비스를 조작했는지 확인하세요. 무선, 유선 네트워크 또는 여러 네트워크 위치를 동시에 유지하는 경우 잘못된 서비스를 수정하면 클라이언트는 켜졌다고 표시하지만 실제 트래픽에는 변화가 없을 수 있습니다.

명령줄 도구는 일반적으로 자체 환경 변수나 설정이 필요합니다. 현재 터미널 세션에서만 클라이언트의 수신 포트를 사용하려면 클라이언트에 실제로 표시된 로컬 포트에 맞춰 환경 변수를 설정하세요. 아래는 작성 형식만 보여 주는 예시이며 포트는 이 기기의 설정을 기준으로 해야 합니다:

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 포트"

이러한 환경 변수는 현재 shell과 그 하위 프로세스에만 적용됩니다. 포트를 확인하지 않은 상태에서 시작 파일에 영구적으로 기록하지 마세요. 테스트가 끝나면 unset http_proxy https_proxy all_proxy를 실행해 복구할 수 있습니다. 도구 자체에서 별도 프록시 설정을 지원한다면 도구 안에서 명시적으로 설정하는 편이 출처를 나중에 확인하기 쉽습니다.

TUN 및 네트워크 확장 권한

시스템 프록시를 읽지 않는 앱까지 전환해야 한다면 TUN을 검토할 수 있습니다. 처음 활성화할 때 관리자 확인이나 네트워크 확장 권한 요청이 나타날 수 있습니다. 권한을 허용한 뒤에도 클라이언트에서 가상 인터페이스가 성공적으로 생성되었는지 확인하고 로그에서 라우팅 기록 결과를 살펴보세요. 시스템 팝업에서 허용을 눌렀다고 해서 TUN이 안정적으로 실행 중이라는 뜻은 아닙니다. 인터페이스 생성, DNS 전환과 라우팅 전달은 각각 실패할 수 있습니다.

macOS에서 다른 VPN 도구, 네트워크 필터, 기업 보안 소프트웨어 또는 가상화 네트워크를 함께 실행하면 라우팅 우선순위가 서로 영향을 줄 수 있습니다. 문제를 찾을 때는 기본 경로 또는 DNS를 수정하는 다른 프로그램을 먼저 종료하고 v2rayN과 기본 네트워크만 남겨 두세요. 문제가 사라지면 프로그램을 하나씩 다시 활성화합니다. 노드, 라우팅 모드와 여러 네트워크 확장을 동시에 바꾸지 마세요. 로그의 시간 흐름이 섞입니다.

잠자기 해제 후 DNS 캐시

기기가 잠자기 상태에서 깨어나면 네트워크 인터페이스와 기본 경로가 다시 배정될 수 있습니다. 클라이언트 인터페이스는 실행 중으로 표시되지만 새 요청이 계속 시간 초과된다면 먼저 트래픽 전환을 중지하고 네트워크가 복구될 때까지 기다린 뒤 다시 시작하세요. 무선 네트워크를 자주 바꿀 때도 같은 방법을 사용합니다. 도메인 연결은 실패하지만 알려진 IP로 직접 테스트하면 정상인 경우 DNS 경로 문제일 가능성이 큽니다. 클라이언트 DNS 설정, 시스템 해석 결과와 DNS 요청을 연결할 수 없는 출구로 보내는 라우팅 규칙을 확인하세요.

DNS 캐시 삭제를 무조건 수행할 필요는 없습니다. 도메인 기록이 확실히 오래되었거나 해석 정책을 바꾼 뒤에도 이전 값이 반환될 때만 처리하세요. 대부분의 프록시 문제는 트래픽 전환 방식, 라우팅 매칭 또는 노드 매개변수에서 발생하므로 캐시를 반복해서 새로 고쳐도 핸드셰이크 실패는 해결되지 않습니다. 클라이언트를 종료하기 전에 시스템 프록시를 해제하세요. TUN을 사용했다면 먼저 TUN을 정상적으로 중지해 클라이언트가 인터페이스와 라우팅을 철회한 뒤 종료합니다.

arm64 또는 범용 패키지 선택

최근 Android 스마트폰은 대부분 arm64 아키텍처를 사용합니다. 기기 아키텍처를 알고 있다면 arm64 패키지를 우선 선택하고, 확실하지 않거나 설치 프로그램에서 호환되지 않는다고 표시하면 범용 패키지를 사용하세요. 범용 패키지는 지원 범위가 넓지만 여러 아키텍처 리소스를 포함해 용량이 더 큰 경우가 많습니다. 아키텍처는 앱이 프로세서에서 실행될 수 있는지만 결정하며 노드 프로토콜이나 구독 내용은 바꾸지 않습니다. 다운로드 경로는 v2rayNG가 먼저, v2flyNG가 다음 순서로 표시되어 있으므로 Android 다운로드 영역에서 선택하세요.

설치 전에 기기에 같은 이름의 앱이 이미 있다면 서명 출처와 기존 설정을 보존해야 하는지 확인하세요. 시스템이 덮어쓰기를 거부한다고 바로 삭제하지 말고, 구독을 백업하지 않았는지 먼저 확인합니다. 구독 주소, 라우팅 모드, 앱 분할과 DNS 설정을 기록한 뒤 업그레이드 또는 재설치를 결정하세요. 구독 주소는 민감한 정보이므로 백업 파일도 관리되는 위치에만 보관해야 합니다.

구독 및 단일 노드 링크 가져오기

v2rayNG를 열고 구독 그룹에서 주소를 추가해 업데이트하거나, 클립보드에서 단일 공유 링크를 가져올 수 있습니다. QR 코드를 사용한다면 신뢰할 수 있는 출처인지 확인하고, 스캔한 뒤에도 서버 주소, 포트, 사용자 식별자, 전송 방식과 보안 매개변수를 확인하세요. QR 스캔은 수동 입력을 줄여 줄 뿐 설정이 올바른지 검증하지는 않습니다.

구독을 업데이트한 뒤 노드 이름을 눌러 현재 구성으로 지정하고 연결을 시작하세요. Android는 VPN 연결 생성 권한을 요청합니다. 이는 로컬 트래픽 전환을 위한 표준 시스템 권한입니다. 기기에 다른 VPN 연결이 이미 있다면 시스템은 보통 하나만 활성 상태로 둘 수 있으므로 기존 연결을 먼저 중지하세요. 권한 요청을 거부하면 클라이언트가 백그라운드 서비스만으로 트래픽을 전환할 수 없으므로 다시 시작해 허용해야 합니다.

앱 분할 및 우회 선택

앱 분할은 어떤 앱의 트래픽을 로컬 VPN 인터페이스로 보낼지 결정합니다. 처음 연결할 때는 복잡한 분할을 잠시 사용하지 말고 브라우저 하나로 먼저 확인하세요. 기본 연결이 정상임을 확인한 뒤 ‘선택한 앱만 프록시’ 또는 ‘선택한 앱 우회’ 방식으로 설정합니다. 두 모드는 의미가 서로 반대이므로 전환한 뒤 목록을 다시 확인해 대상 앱을 잘못된 쪽에 넣지 않도록 하세요.

은행, LAN 제어, 화면 전송과 기기 검색 앱은 로컬 네트워크에 의존할 수 있으므로 실제 필요에 따라 직접 연결로 설정하세요. 앱을 직접 연결로 지정해도 DNS의 영향을 받지 않는다는 뜻은 아닙니다. DNS 요청이 클라이언트에서 계속 처리되면 도메인 해석 결과도 달라질 수 있습니다. 특정 앱만 이상하고 브라우저가 정상이라면 먼저 해당 앱의 분할 제한을 해제해 다시 테스트한 뒤 QUIC, 비공개 DNS 또는 고정 주소를 사용하는지 확인하세요. 전역 노드를 먼저 바꾸지는 마세요.

백그라운드 제한 및 연결 재시도

Android 제조사는 백그라운드 서비스에 배터리 최적화, 절전과 자동 시작 제한을 적용하는 경우가 많습니다. 화면을 잠근 뒤 연결이 멈추거나, 네트워크를 바꿔도 복구되지 않거나, 시스템이 클라이언트 프로세스를 종료하는 식으로 나타납니다. 먼저 시스템 배터리 사용량에서 클라이언트가 제한되었는지 확인한 뒤 적절한 백그라운드 정책을 선택하세요. 모든 기기에서 제한을 완전히 해제할 필요는 없습니다. 먼저 관찰한 뒤 연결에 영향을 주는 항목만 조정해 지속적인 트래픽을 시스템 제한으로 잘못 판단하지 않도록 하세요.

연결을 자주 다시 시도하면 배터리도 더 많이 소모됩니다. 로그에 네트워크 변경, 연결 시간 초과와 즉시 재시도가 반복되면 모바일 네트워크 신호 불안정, 접근할 수 없는 노드, 시스템의 백그라운드 네트워크 일시 중지 중 무엇인지 구분해야 합니다. 같은 장소에서 화면을 켠 채 잠시 테스트한 뒤 화면을 잠갔을 때와 비교하세요. 자세한 순서는 v2rayNG 백그라운드 배터리 이상 문제 해결을 참고하세요.

비공개 DNS와 클라이언트 DNS

시스템 비공개 DNS, 브라우저 내장 보안 DNS와 클라이언트 DNS가 동시에 존재할 수 있습니다. 처음 문제를 확인할 때는 현재 누가 도메인을 해석하는지 명확히 하세요. 시스템 비공개 DNS가 엄격한 호스트 이름으로 설정되어 있는데 해당 서비스가 현재 네트워크에서 접근 불가능하면 프록시가 시작되기 전에 도메인 해석이 실패할 수 있습니다. 먼저 자동 모드로 되돌려 확인한 뒤 클라이언트가 DNS를 맡을지 결정하세요.

클라이언트 DNS의 역할은 ‘다른 서버로 바꾸기’에만 그치지 않습니다. 도메인 요청을 어느 출구로 보낼지, 라우팅 규칙이 도메인과 해석된 IP 중 무엇으로 매칭되는지, 로컬 결과와 프록시 출구의 불일치를 피해야 하는지도 관련됩니다. 도메인만 실패하고 노드의 서버 주소가 IP라면 DNS를 중점적으로 확인하세요. 서버 주소 자체에서 TCP 또는 프로토콜 핸드셰이크를 만들 수 없다면 DNS 서버를 바꿔도 효과가 없습니다.

무선 네트워크와 모바일 네트워크 전환

네트워크를 전환하면 로컬 주소, 기본 경로와 NAT 상태가 바뀌어 기존 연결을 계속 사용하지 못할 수 있습니다. 전환 후 시스템 네트워크가 안정될 때까지 기다리고 클라이언트가 자동으로 다시 연결하는지 확인하세요. 인터페이스에는 연결됨으로 표시되지만 새 로그가 없다면 로컬 VPN을 중지한 뒤 다시 시작합니다. 이전 서비스가 인터페이스를 해제하기 전에 새 인스턴스를 만들 수 있으므로 시작 버튼을 빠르게 반복해서 누르지 마세요.

문제 해결 후 특정 무선 네트워크에서만 실패하고 모바일 네트워크에서는 정상이라면 해당 네트워크에 웹 로그인 절차가 필요한지, 대상 포트를 제한하는지, DNS가 비정상적인 결과를 반환하는지 확인하세요. 두 네트워크에서 모두 실패한다면 노드 매개변수, 구독 유효성 및 시스템 시간으로 돌아갑니다. 이렇게 비교하면 기기 설정 문제와 현재 네트워크 문제를 구분할 수 있습니다.

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

Debian, Ubuntu와 일반적인 파생 배포판은 보통 deb를 사용합니다. Fedora, Rocky Linux, openSUSE 등은 rpm을 사용하는 경우가 많지만 구체적인 기준은 배포판의 패키지 관리 체계를 따라야 합니다. 일반적인 데스크톱 컴퓨터는 x64가 많고 arm64는 일부 개발 보드와 ARM 데스크톱 기기에서 주로 사용됩니다. uname -m을 실행해 아키텍처를 확인할 수 있습니다. 일반적으로 x86_64는 x64, aarch64는 arm64에 해당합니다.

uname -m
cat /etc/os-release

Linux 다운로드 경로에서 호환되는 v2rayN 패키지를 받으세요. 로컬 deb를 설치할 때는 패키지가 있는 폴더에서 시스템 패키지 관리자로 의존성을 처리하고, rpm 배포판도 파일을 단순히 압축 해제하지 말고 자체 패키지 관리자를 사용해야 합니다. 아래 명령의 파일 패턴은 실제 다운로드 이름과 일치해야 하며 폴더에 오래된 패키지가 여러 개 남아 있지 않은지 확인하세요:

sudo apt install ./v2rayN*.deb
sudo dnf install ./v2rayN*.rpm

시스템에서 아키텍처가 일치하지 않는다고 표시되면 다운로드 페이지로 돌아가 다시 선택하세요. 강제 옵션으로 오류를 건너뛰지 마세요. 의존성이 없다는 메시지가 나오면 먼저 배포판 소프트웨어 저장소를 새로 고치고 데스크톱 환경 버전이 지원되는지 확인합니다. 의존성을 강제로 무시하고 설치하면 대개 오류가 실행 단계로 미뤄질 뿐입니다.

최초 실행 및 설정 폴더

데스크톱 앱 메뉴에서 v2rayN을 실행해 인터페이스, 트레이 아이콘과 설정 저장이 모두 정상인지 확인하세요. 터미널에서는 오류가 보이지만 데스크톱 메뉴에서 반응이 없다면 터미널에서 앱 실행 파일을 실행해 누락된 라이브러리, 디스플레이 서비스 또는 권한 메시지를 확인합니다. 전체 그래픽 클라이언트를 root 권한으로 계속 실행하지 마세요. 설정 폴더가 root 소유가 되어 일반 사용자가 실행할 때 기록하지 못할 수 있습니다.

구독 관리 절차는 다른 데스크톱 플랫폼과 같습니다. 그룹 추가, 구독 주소 붙여 넣기, 저장, 업데이트, 노드 선택과 실제 연결 테스트를 차례로 진행합니다. Linux 데스크톱은 시스템 세션과 사용자 세션의 프록시 설정을 구분하는 경우가 많으므로 클라이언트에 ‘설정 성공’이 표시된 뒤에도 데스크톱 네트워크 설정에서 현재 사용자의 프록시 값을 확인하세요. 경량 데스크톱이나 독립 창 관리자를 사용하면 통합 시스템 프록시 인터페이스가 없을 수 있어 브라우저와 앱별로 설정해야 합니다.

데스크톱 프록시 및 환경 변수

GNOME, KDE 등 데스크톱 환경은 시스템 프록시 설정을 제공하지만 앱이 이를 따르는지는 네트워크 구현에 따라 다릅니다. 브라우저는 데스크톱 프록시를 따르는 경우가 많고, 터미널 도구는 환경 변수나 자체 설정을 읽는 경우가 많습니다. 임시 테스트에서는 현재 shell에 프록시 변수를 설정하고 끝난 뒤 즉시 해제하세요:

export http_proxy="http://127.0.0.1:로컬 HTTP 포트"
export https_proxy="$http_proxy"
export all_proxy="socks5://127.0.0.1:로컬 SOCKS 포트"

# 테스트 종료
unset http_proxy https_proxy all_proxy

이 포트는 v2rayN 설정에서 확인해야 합니다. 클라이언트가 로컬 루프백 주소에서만 수신하도록 설정되어 있으면 다른 LAN 기기는 해당 포트를 직접 사용할 수 없으며, 이는 더 안전한 기본 경계입니다. 프록시를 공유해야 하는 경우에만 LAN 주소에서 수신하도록 설정하고 방화벽과 접근 제어도 확인해 같은 네트워크의 다른 기기에 인증되지 않은 프록시入口가 노출되지 않게 하세요.

TUN, 권한 및 라우팅 충돌

Linux TUN은 커널 장치, 네트워크 관리 권한과 라우팅 기록 권한에 의존합니다. 먼저 /dev/net/tun이 존재하는지 확인한 뒤 클라이언트 로그에서 장치를 사용할 수 없는지, 권한이 부족한지, 라우팅 규칙 기록에 실패했는지 판단하세요. 앱 전체에 영구적으로 root 권한을 부여하지 마세요. 클라이언트가 제공하는 권한 절차나 시스템 capability 설정을 우선 사용하고, 업데이트 후 실행 파일이 바뀌면 기존 권한이 무효화될 수 있음을 알아 두세요.

ls -l /dev/net/tun
ip route
ip rule

컨테이너, 가상 머신, 회사 VPN과 여러 네트워크 카드 환경에는 정책 라우팅이 이미 설정되어 있을 수 있습니다. TUN을 활성화하기 전에 ip route와 ip rule 출력을 저장하고 활성화 후 새로 생긴 항목을 비교하세요. 내부망에 연결할 수 없으면 사설 대역이 TUN으로 전달되는지, 기본 경로 우선순위가 바뀌었는지, DNS 요청이 다른 네임스페이스로 들어갔는지를 중점적으로 확인합니다. TUN을 끈 뒤에는 새 인터페이스와 규칙이 철회되었는지 확인하세요.

DNS 및 systemd-resolved

Linux의 이름 해석 경로에는 앱, glibc, NetworkManager, systemd-resolved와 상위 DNS가 포함될 수 있습니다. 클라이언트 DNS를 바꾼 뒤 /etc/resolv.conf의 겉으로 보이는 내용만 확인해서는 안 됩니다. 이 파일은 로컬 해석 서비스로 연결된 링크일 수 있습니다. resolvectl status로 인터페이스별 DNS와 도메인 설정을 확인한 뒤 클라이언트 로그와 함께 조회가 실제로 프록시로 들어갔는지 판단하세요.

resolvectl status
getent hosts example.com
ss -lntup

ss로 로컬 프록시 포트가 수신 중인지와 충돌이 발생했는지 확인할 수 있습니다. 클라이언트를 종료한 뒤 네트워크가 이상해지면 먼저 데스크톱 프록시와 shell 환경 변수를 해제하고 TUN 인터페이스 및 정책 라우팅을 확인하세요. 기기를 재부팅하면 상태가 복구될 수 있지만 중요한 현장 정보가 사라집니다. 재부팅 전에 로그와 라우팅 출력을 저장해야 근본 원인을 찾기 쉽습니다.

트래픽 전환 방식이 클라이언트로 들어오는 트래픽을 결정합니다

시스템 프록시는 본질적으로 앱에 HTTP 또는 SOCKS 프록시 진입점을 알려 주는 기능입니다. 시스템 설정을 읽고 따르는 앱만 사용한다는 한계가 있지만 범위가 명확하고 켜고 복구하기 쉬워 브라우저와 대부분의 데스크톱 프로그램에 적합합니다. TUN은 가상 인터페이스와 라우팅으로 트래픽을 받아 프록시 설정을 지원하지 않는 앱까지 더 넓게 처리할 수 있지만 LAN, 가상화 환경과 기존 네트워크 도구에 영향을 줄 가능성도 커집니다.

두 방식을 반드시 동시에 켤 필요는 없습니다. 처음에는 시스템 프록시부터 시작하세요. 대상 앱이 정상적으로 전환된다면 ‘더 완전하게’ 사용하려고 TUN을 바로 추가할 필요가 없습니다. 특정 앱이 시스템 프록시를 우회하고 통합 전환이 꼭 필요하다는 것을 확인했을 때 TUN을 활성화하세요. Android의 로컬 VPN 전환은 사용 경험상 TUN에 가깝지만 앱 분할은 시스템 인터페이스와 클라이언트가 함께 처리합니다.

라우팅 규칙은 순서대로 매칭됩니다

라우팅은 이미 코어에 들어온 트래픽이 어느 출구로 갈지 결정합니다. 일반적인 조건에는 도메인 분류, IP 분류, 포트, 네트워크 유형과 프로세스가 있습니다. 규칙은 보통 순서대로 매칭되며 먼저 일치한 규칙이 적용되므로 더 구체적인 규칙을 더 일반적인 규칙보다 앞에 둬야 합니다. 범위가 넓은 프록시 규칙이 앞에 있으면 뒤의 LAN 직접 연결 규칙은 실행될 기회를 얻지 못할 수 있습니다.

다음은 구조를 설명하기 위한 라우팅 조각입니다. 일반적인 사설 주소와 지정된 분류는 먼저 직접 연결하고, 나머지는 설정의 후속 규칙과 기본 출구에 맡깁니다. 실제 사용 시 출구 태그는 클라이언트가 생성한 아웃바운드 설정과 일치해야 합니다:

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

domainStrategy는 라우팅 판단에서 도메인을 해석할지, 언제 해석할지를 결정합니다. AsIs를 사용하면 원래 도메인 규칙으로 먼저 매칭하고, 다른 전략은 필요할 때 IP로 해석한 뒤 판단할 수 있습니다. 모든 환경에 맞는 하나의 전략은 없습니다. 도메인 분류 기반 분할에 의존한다면 요청이 코어에 도달할 때 도메인 정보가 남아 있는지 확인하세요. 앱이 IP에 직접 연결하면 도메인 규칙은 당연히 매칭되지 않습니다.

GeoIP 및 GeoSite 데이터

GeoIP는 IP 분류 데이터이고 GeoSite는 도메인 분류 데이터입니다. 라우팅 규칙이 참조하는 것은 분류 태그이지 ‘자동 지능형 분할’이 아닙니다. 데이터베이스가 없거나, 태그가 존재하지 않거나, 코어 버전이 호환되지 않으면 클라이언트가 시작되지 않거나 로그에 규칙 로드 오류가 나타날 수 있습니다. 데이터를 업데이트한 뒤 로그에서 새 파일이 읽혔는지 확인하고 기존 파일도 복구를 위해 보관하세요. 전체 유지 관리 절차는 GeoIP 및 GeoSite 데이터베이스 업데이트 가이드를 참고하세요.

한 번의 변경에서 데이터베이스, 규칙 세트와 코어를 동시에 바꾸지 마세요. 업데이트 후 문제가 생기면 기존 데이터를 먼저 복구하고 규칙은 그대로 유지합니다. 정상으로 돌아온 뒤 새 데이터에 필요한 태그가 포함되어 있는지 따로 확인하세요. 규칙 태그 이름의 철자가 틀렸다면 노드를 바꿔도 도움이 되지 않습니다.

DNS는 라우팅 경로와 일치해야 합니다

DNS는 도메인에서 어떤 주소를 얻을지 결정하고, 라우팅은 해당 주소에 요청을 어떻게 전달할지 결정합니다. 도메인이 로컬 DNS를 통해 출구와 맞지 않거나 접근할 수 없는 결과를 받으면 프로토콜 핸드셰이크 전에 연결이 실패합니다. DNS 요청 자체를 프록시로 보내야 한다면 시작 단계에 사용할 수 있는 기본 해석 경로가 있어야 합니다. 프록시 서버를 먼저 해석해야 하는데 그 해석이 다시 프록시에 의존하는 순환을 피해야 합니다.

DNS를 확인할 때는 먼저 로그에서 요청이 클라이언트에 도달했는지 확인한 뒤 시스템 도구와 클라이언트 내부의 해석 결과를 비교하세요. 도메인만 실패하고 직접 주소는 접근 가능한 경우에만 해석 경로를 중점적으로 확인합니다. TCP 연결이 수립된 뒤 TLS 또는 REALITY 단계에서 실패한다면 serverName, 공개 키, 짧은 식별자, 지문과 시스템 시간을 확인하세요. 핸드셰이크 오류를 DNS 문제로 보면 잘못된 방향으로 해결하게 됩니다.

4단계 확인 방법

첫째, 구독 업데이트 결과를 확인합니다. 노드 목록에 예상한 내용이 나타나고 현재 노드의 주요 매개변수가 완전해야 합니다. 둘째, 실제 연결 테스트를 실행해 클라이언트가 프로토콜에 따라 실제 요청을 수립하는지 확인합니다. 셋째, 한 가지 트래픽 전환 방식을 켜고 대상 앱에서 새 네트워크 요청을 보냅니다. 넷째, 로그에서 해당 요청 시간에 맞는 도메인, 대상 주소, 라우팅 출구 또는 오류를 찾습니다. 네 단계를 모두 충족해야 ‘노드에 연결할 수 있고 앱 트래픽이 실제로 클라이언트에 들어왔다’고 판단할 수 있습니다.

실제 연결 테스트에는 성공했지만 브라우저에 변화가 없다면 시스템 프록시, 브라우저의 독립 프록시, 기존 연결 캐시와 현재 네트워크 서비스를 먼저 확인하세요. 브라우저 요청이 로그에 들어왔지만 실패한다면 DNS, TCP, TLS, REALITY 또는 원격 종료 중 어느 단계에서 실패했는지 확인합니다. 로그에 대상 요청이 전혀 없다면 트래픽 전환 단계가 아직 성립하지 않은 것이므로 프로토콜 매개변수부터 조정해서는 안 됩니다.

오류 단계별로 로그 읽기

로그의 ‘해석 실패’는 대개 도메인에서 사용할 수 있는 주소를 얻지 못했다는 뜻입니다. ‘연결 시간 초과’는 제한 시간 내에 네트워크 연결을 완료하지 못했다는 뜻이지만, 대상에 접근할 수 없거나 포트가 제한되었거나 라우팅이 잘못된 것이 원인일 수 있습니다. ‘연결 거부’는 대상 주소가 명확히 응답했지만 해당 포트가 연결을 받아들이지 않았다는 뜻입니다. TLS 또는 REALITY 핸드셰이크 오류라면 서버 이름, 시간, 공개 키, 짧은 식별자와 지문 등의 매개변수를 우선 확인하세요.

로그는 마지막 한 줄만 보지 말고 시간 순서대로 읽어야 합니다. 마지막 줄은 앞선 오류를 상위 계층에서 요약한 것일 수 있습니다. 재현하기 전에 로그를 비우거나 현재 시간을 기록하고, 대상 작업을 한 번만 수행한 뒤 요청 시작부터 실패까지의 연속 구간을 저장하세요. 공개적으로 도움을 요청할 때는 구독 주소, 사용자 식별자, 서버 주소와 기타 민감한 매개변수를 가리되 오류 유형, 시간 순서와 클라이언트 조작 단계는 남겨야 합니다.

비교 실험으로 범위 좁히기

유효한 비교는 변수 하나만 바꿉니다. 같은 노드를 두 네트워크에서 테스트하면 현재 네트워크의 관여 여부를 판단할 수 있습니다. 같은 네트워크에서 같은 구독의 다른 노드로 바꾸면 노드별 차이를 비교할 수 있습니다. 노드를 유지한 채 시스템 프록시와 TUN을 각각 테스트하면 트래픽 전환 방식의 문제를 확인할 수 있습니다. 다른 설정을 그대로 두고 기본 DNS로 되돌리면 사용자 지정 해석이 이상을 일으켰는지 판단할 수 있습니다.

유효하지 않은 비교는 한 번에 너무 많은 것을 바꿉니다. 구독 업데이트, 노드 전환, TUN 활성화, DNS 교체와 규칙 데이터베이스 업데이트를 동시에 진행하는 식입니다. 문제가 잠시 사라져도 무엇이 효과가 있었는지 알 수 없어 다음 장애 때 다시 처음부터 확인해야 합니다. 안정적인 설정은 클라이언트, 트래픽 전환 방식, 라우팅 모드와 필요한 사용자 지정 항목을 포함해 텍스트로 기록해 두세요.

구독 업데이트 및 설정 백업

구독 업데이트로 노드가 추가, 삭제 또는 수정될 수 있습니다. 수동으로 조정한 중요한 설정이 있다면 업데이트 시 덮어써지는지 먼저 확인하세요. 구독 노드와 로컬에서 만든 노드는 별도 그룹으로 관리해 구독 업데이트 중 로컬 내용을 실수로 삭제하지 않도록 하세요. 업데이트 후 노드 수와 이름의 변화를 먼저 비교하고 하나를 선택해 확인하면 됩니다. 모든 노드를 즉시 반복해서 테스트할 필요는 없습니다.

백업에는 구독 그룹 정보, 필요한 라우팅 설정과 사용자 지정 DNS를 포함하되 민감한 자료를 공개 동기화 공간에 저장하지 마세요. 백업을 복원한 뒤에도 시스템 권한, TUN 권한과 로컬 포트를 다시 확인해야 합니다. 이런 상태는 클라이언트 설정에 완전히 포함되지 않을 수 있습니다. 플랫폼을 옮길 때 모든 설정 필드가 일대일로 대응한다고 가정하지 말고, 먼저 구독을 다시 가져온 뒤 필요한 정책만 수동으로 복원하세요.

클라이언트, 코어 및 규칙 데이터 업데이트

클라이언트 인터페이스, 프록시 코어와 GeoIP·GeoSite 데이터는 서로 다른 계층입니다. 클라이언트 업데이트는 인터페이스나 설정 형식에 변화를 줄 수 있고, 코어 업데이트는 프로토콜 매개변수 지원에 영향을 줄 수 있으며, 규칙 데이터 업데이트는 분류 태그에 영향을 줍니다. 안정적인 환경에서는 각각 따로 업데이트하고 매번 기본 연결, 트래픽 전환과 라우팅을 확인하세요. 문제가 생겨도 어느 계층을 되돌려야 하는지 정확히 알 수 있습니다.

온라인에서 본 특정 버전 번호만으로 이 기기를 반드시 업그레이드해야 한다고 판단하지 마세요. 이 페이지는 버전을 고정하지 않으며 실제 사용 가능한 패키지는 다운로드 페이지에 동적으로 표시되는 내용을 기준으로 합니다. 업데이트 전에 실행 중인 클라이언트를 종료하고 현재 작동하는 설정을 보존하세요. 업데이트 후 기존 설정을 불러오지 못하면 원래 설정 폴더를 바로 덮어쓰지 말고 마이그레이션 안내와 로그를 먼저 확인하세요.

구독 업데이트에는 성공했는데 왜 접속할 수 없나요?

구독 업데이트 성공은 클라이언트가 설정을 가져와 파싱했다는 뜻일 뿐입니다. 이후 노드를 선택하고 실제 연결을 완료할 수 있는지 확인한 뒤 한 가지 트래픽 전환 방식을 켜고 앱 요청이 로그에 들어오는지 확인해야 합니다. 먼저 현재 노드가 실제 활성 항목으로 지정되었는지 확인하고 실제 연결 테스트를 실행하세요. 테스트에 실패하면 로그 단계에 따라 네트워크, 시간과 연결 매개변수를 점검합니다. 테스트는 성공했지만 앱 요청 로그가 없다면 시스템 프록시, TUN 또는 Android 앱 분할을 확인하세요.

구독에는 일시적으로 사용할 수 없거나 조건이 다른 노드가 포함될 수 있습니다. 목록의 첫 번째 노드만 테스트하거나 모든 노드 실패를 단순히 클라이언트 문제로 보지 마세요. 같은 구독에서 매개변수 유형이 다른 소수의 노드를 비교하면 단일 노드 문제인지 구독 전체 문제인지 판단하는 데 도움이 됩니다.

시스템 프록시와 TUN을 동시에 켜야 하나요?

대개 그럴 필요는 없습니다. 대상 앱에 따라 한 가지 방식을 선택하세요. 브라우저와 시스템 프록시를 따르는 대부분의 데스크톱 앱은 먼저 시스템 프록시를 사용하고, 시스템 프록시를 읽지 않거나 더 넓은 전환 범위가 필요한 앱만 TUN을 검토합니다. 두 방식을 동시에 사용해도 작동할 수 있지만 특히 DNS, LAN과 가상 네트워크 카드 환경에서 경로 판단이 어려워집니다.

동시에 켜진 상태에서 문제를 확인한다면 먼저 TUN만 끄고 시스템 프록시를 유지한 채 브라우저를 테스트하세요. 시스템 프록시 확인이 끝나면 시스템 프록시를 해제하고 TUN만 따로 테스트합니다. 이렇게 해야 두 진입점이 각각 정상인지 알 수 있습니다. 한 번의 테스트에서 이전 연결을 종료하지 않고 계속 전환하지 마세요. 앱이 기존 세션을 계속 사용할 수 있습니다.

클라이언트를 종료한 뒤 네트워크가 왜 이상해지나요?

가장 흔한 원인은 시스템 프록시가 이미 중지된 클라이언트의 로컬 포트를 계속 가리키는 것입니다. 클라이언트를 다시 열고 ‘시스템 프록시 해제’를 실행한 뒤 정상적으로 종료하세요. Windows와 macOS에서는 시스템 네트워크 설정에서 프록시 값을 확인할 수도 있습니다. Linux는 데스크톱 프록시뿐 아니라 터미널 환경 변수도 확인해야 합니다. Android에서는 시스템 VPN 상태에 기존 연결이 남아 있는지 확인하세요.

이전에 TUN을 사용했다면 가상 인터페이스와 라우팅이 철회되었는지도 확인해야 합니다. TUN을 정상적으로 중지하면 보통 복구되지만 프로세스를 강제 종료했거나 시스템이 충돌했거나 권한에 문제가 있으면 상태가 남을 수 있습니다. Linux에서는 ip route와 ip rule을 확인하고, 데스크톱 시스템에서는 남은 가상 인터페이스를 먼저 비활성화하거나 네트워크 서비스를 다시 시작하세요. 네트워크를 복구한 뒤 로그를 분석하고 처음부터 모든 클라이언트 설정을 삭제하지는 마세요.

특정 앱 하나만 연결되지 않으면 노드를 바꿔야 하나요?

먼저 바꾸지 마세요. 브라우저는 정상인데 앱 하나만 이상하다면 노드와 기본 트래픽 전환은 대체로 정상일 가능성이 큽니다. 해당 앱이 시스템 프록시를 따르는지, Android 앱 분할에서 제외되었는지, 독립 프록시·고정 DNS·QUIC 또는 특수 네트워크 권한을 사용하는지 확인하세요. 데스크톱 앱이 시스템 프록시를 읽지 않는다면 앱 설정에서 로컬 HTTP 또는 SOCKS 포트를 지정하거나 TUN을 별도로 테스트할 수 있습니다.

로그에 해당 앱의 요청이 보이지만 특정 도메인이 직접 연결되거나 차단된다면 라우팅 규칙을 확인하세요. 요청 로그가 전혀 없다면 문제는 여전히 트래픽 전환 계층에 있습니다. 요청이 클라이언트에 들어온 것을 확인했고 원격 연결 단계에서 실패할 때만 노드 교체가 합리적인 비교가 됩니다.

REALITY 설정 연결에 실패하면 어떤 필드를 확인해야 하나요?

먼저 서버 주소, 포트, 사용자 식별자와 flow를 확인한 뒤 serverName, 공개 키, 짧은 식별자와 지문을 점검하세요. 필드 이름은 클라이언트 인터페이스에 따라 조금 다를 수 있지만 값은 서버에서 제공한 설정과 일치해야 합니다. 시스템 시간의 큰 오차, 메신저가 잘라낸 구독 매개변수와 복사 중 누락된 문자가 핸드셰이크 실패를 일으킬 수 있습니다.

누락된 값을 임의로 추측하지 말고, VLESS라는 이유만으로 보안 계층을 끄지도 마세요. REALITY는 연결 보안과 관련된 매개변수 조합이지 단독 노드 이름이 아닙니다. 구독에서 가져온 설정이라면 먼저 구독을 업데이트하고 제공자 안내와 비교하세요. 단일 링크에서 가져온 설정이라면 수동으로 수정하는 것보다 원본 링크를 다시 가져오는 편이 일반적으로 더 안정적입니다.

GeoIP 또는 GeoSite 업데이트 후 클라이언트가 시작되지 않으면 어떻게 하나요?

먼저 로그에 데이터베이스 읽기 실패, 분류 태그 없음 또는 파일 형식 비호환이 보고되었는지 확인하세요. 업데이트 전 데이터 파일을 복구하고 라우팅 규칙은 그대로 둔 채 다시 시작합니다. 복구 후 정상이라면 문제는 새 데이터 또는 호환성에 집중되어 있습니다. 계속 실패한다면 규칙을 편집하는 과정에서 철자 오류나 JSON 구조 오류가 생겼는지 확인하세요.

데이터 오류를 가리기 위해 코어까지 동시에 바꾸지 마세요. 코어, 규칙과 데이터베이스를 각각 검증해야 합니다. 안정된 뒤 현재 코어가 참조한 태그를 지원하는지 확인하세요. 데이터 업데이트와 로드 복구의 전체 절차는 규칙 데이터베이스 유지 관리 글에서 자세히 설명합니다.

DNS에는 어떤 주소를 입력해야 하나요?

모든 네트워크에 맞는 고정 답은 없습니다. 먼저 DNS 요청이 로컬로 직접 나가는지 프록시 출구를 통해 나가는지 확인한 뒤 해당 경로에서 안정적으로 접근할 수 있는 해석 서비스를 선택하세요. 특별한 요구가 없다면 클라이언트 기본 정책을 유지한 채 연결을 확인하는 것이 좋습니다. 도메인 해석 이상, 분할 요구 또는 개인정보 경계가 있을 때만 별도로 조정하세요.

변경한 뒤 시스템 해석 도구, 브라우저 요청과 클라이언트 로그를 교차 확인하세요. 직접 주소에도 연결할 수 없다면 문제는 대개 DNS가 아닙니다. 도메인에서 주소는 얻었지만 TLS 또는 REALITY 단계에서 실패한다면 연결 매개변수를 확인하세요. 여러 DNS 주소를 기록 없이 연속해서 바꾸지 마세요.

최소 작동 설정으로 되돌리려면 어떻게 하나요?

먼저 TUN을 중지하고 시스템 프록시와 앱 분할을 해제한 뒤 기본 DNS와 기본 라우팅을 복원하세요. 출처가 명확한 구독 그룹 하나만 남기고 업데이트한 다음 노드 하나를 선택해 실제 연결 테스트를 실행합니다. 테스트에 성공하면 시스템 프록지만 켜고 브라우저에서 새 요청을 보내 로그를 확인하세요. 데스크톱 환경에서 대상 앱이 시스템 프록시를 따르지 않는다면 시스템 프록시를 별도로 끄고 TUN을 켜서 테스트합니다.

Android에서는 먼저 복잡한 앱 분할을 해제하고 시스템 VPN 권한은 유지한 채 브라우저로 테스트하세요. Linux에서는 shell의 프록시 환경 변수도 지워야 합니다. 최소 설정이 안정된 뒤 라우팅, DNS, 앱 분할과 백그라운드 정책 순서로 항목을 하나씩 복원하세요. 항목을 추가할 때마다 다시 테스트하는 편이 클라이언트를 반복해서 재설치하는 것보다 빠르고 문제 발생의 증거도 보존할 수 있습니다.