INSTALL / SUBSCRIPTION / ROUTING

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

데스크톱에서는 v2rayN, Android에서는 v2rayNG를 설정합니다. 플랫폼별 설치 후 트래픽 경로를 따라 문제를 확인하세요.

이 페이지는 필요한 내용을 찾아보는 참고 가이드이며, 처음부터 끝까지 읽을 필요는 없습니다. 처음 연결한다면 빠른 시작 가이드를 따라 진행하세요. 설치, 권한, 분할 라우팅 또는 DNS 문제가 생기면 해당 섹션을 확인하면 됩니다. 빠른 시작 가이드는 연결을 설정하는 과정을, 이 페이지는 각 설정이 어느 계층에 적용되는지를 설명합니다.

공통 준비: 설치 파일, 설정, 트래픽 처리 범위

먼저 클라이언트와 기기 아키텍처 확인하기

데스크톱에서는 v2rayN을, Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 권장합니다. V2Fly 코어가 필요하다면 v2flyNG를 고려하세요. 클라이언트는 설정 편집, 구독 관리, 코어 실행을 담당하고, 코어는 실제 연결을 처리합니다. 두 구성 요소는 서로 다른 계층입니다. 클라이언트를 바꾸면 인터페이스와 트래픽 처리 방식은 달라질 수 있지만 서버 설정 오류가 자동으로 해결되지는 않습니다. 설치 전에 운영체제, 프로세서 아키텍처, 프록시를 사용할 앱을 확인하세요. 그러면 설치 파일을 추측해서 고를 필요가 없습니다.

Windows용 데스크톱 설치 파일은 보통 x64 아키텍처를 사용합니다. macOS에서는 Apple Silicon과 Intel을 구분해야 하며, Linux에서는 프로세서 아키텍처와 패키지 형식을 각각 확인해야 합니다. Android 기기는 대체로 arm64를 선택하며, 아키텍처를 모르겠다면 범용 버전을 고려하세요. 운영체제가 64비트라고 해서 프로세서 아키텍처까지 특정 유형이라고 단정할 수는 없습니다. 시스템 정보에 표시된 프로세서 유형을 확인한 다음 다운로드 센터에서 맞는 항목을 선택하세요. 다른 플랫폼의 설치 파일 이름만 바꿔 사용하는 것은 피해야 합니다.

연결 정보가 필요합니다. 예시 주소로는 연결할 수 없습니다.

클라이언트를 설치한 뒤에도 유효한 구독 주소, 공유 링크 또는 수동 설정 정보가 필요합니다. 구독은 보통 노드 목록을 반환하는 웹 주소이고, 공유 링크는 프로토콜 이름으로 시작하며 단일 설정을 담고 있습니다. 이 사이트에서는 클라이언트 사용법을 안내하며, 연결 정보는 이용 권한이 있는 서비스에서 받아야 합니다. 서버 주소, 포트, 사용자 ID, 전송 방식, 보안 설정은 모두 연결 매개변수입니다. 하나라도 빠지면 가져오기는 성공해도 핸드셰이크에 실패할 수 있습니다.

구독을 저장할 때는 '업무용'이나 '테스트용'처럼 용도를 알아볼 수 있게 그룹 이름을 지정하세요. 이름은 로컬 메모일 뿐 연결 동작에는 영향을 주지 않습니다. 공유 화면에는 전체 구독 주소, 사용자 ID, QR 코드를 노출하지 마세요. 이런 정보만으로도 연결 권한이 넘어갈 수 있습니다. 문서의 예시 도메인과 필드는 구조를 설명하기 위한 것으로, 실제 연결 가능한 서비스가 아닙니다. 예시를 클라이언트에 입력하고 연결을 기다리는 것은 쓸모없는 작업을 하나 더 만드는 셈입니다.

시스템 프록시, TUN, 라우팅은 각각 담당하는 단계가 다릅니다.

시스템 프록시는 운영체제에 로컬 프록시 주소를 등록합니다. 해당 설정을 읽는 앱은 요청을 클라이언트로 전달하지만, 모든 프로그램을 강제로 따르게 하지는 않습니다. 특히 독립 네트워크 스택을 사용하는 앱, 일부 명령줄 도구, 자체 프록시를 설정한 앱은 시스템 프록시를 무시할 수 있습니다. TUN은 가상 네트워크 인터페이스로 트래픽을 받아 보통 더 넓은 범위를 처리하지만, 관련 권한이 필요하고 다른 가상 네트워크 어댑터와 충돌할 가능성도 큽니다. 라우팅은 트래픽이 코어에 들어온 뒤 프록시 아웃바운드, 직접 연결 아웃바운드, 차단 중 어디로 보낼지 결정합니다.

처음 설정할 때는 시스템 프록시로 브라우저 접속을 확인한 뒤 TUN을 켤지 결정하세요. 두 클라이언트를 동시에 실행해 같은 로컬 포트를 차지하게 하거나, 두 트래픽 처리 도구가 기본 경로를 동시에 수정하게 하지 마세요. Android의 VPN 트래픽 처리와 데스크톱의 시스템 프록시는 다르지만 확인 순서는 같습니다. 먼저 트래픽이 클라이언트에 들어오는지 확인한 다음 어떤 출구로 나가는지 살펴보세요. 라우팅 모드를 전역으로 설정해도 코어에 들어오지 않은 트래픽이 로그에 나타나지는 않습니다.

되돌릴 수 있는 테스트 기준 만들기

첫 테스트에서는 정상 작동이 확인된 노드 하나를 선택하고 기본 전송 설정을 사용하되 Mux는 꺼 두세요. 당시 라우팅 모드, 로컬 수신 포트, 트래픽 처리 방식을 기록하고 한 번에 한 항목만 변경합니다. 인증서 유효 기간을 확인할 수 있도록 기기 시간도 정확히 맞추세요. 연결하기 전에 기본 네트워크가 정상인지 확인하고, 웹 로그인 인증이 필요한 네트워크라면 먼저 인증을 완료해야 합니다. 기본 네트워크가 연결되지 않은 상태에서는 구독과 노드가 모두 시간 초과로 보일 수 있으니 라우팅부터 바꾸지 마세요.

설치나 업그레이드 전에 클라이언트 설정과 구독 그룹을 백업하고, 본인만 접근할 수 있는 곳에 보관하세요. 백업에도 민감한 연결 정보가 들어 있으므로 공개 문서에 올리면 안 됩니다. 문제가 생기면 오류 유형, 발생 시각, 작업 순서를 기록하세요. 빨간 글자만 찍힌 화면보다 진단에 훨씬 도움이 됩니다. 아래 플랫폼별 섹션은 패키지 선택, 설치, 가져오기, 트래픽 처리, 종료 및 복구라는 같은 흐름으로 설명합니다. 기존 환경이 있다면 차이점만 확인하고 초기 설정을 반복하지 않아도 됩니다.

Windows: v2rayN 설치 및 시스템 프록시

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

다운로드 센터에는 v2rayN 데스크톱 버전과 클래식 WPF 버전이 있습니다. 데스크톱 버전은 차세대 크로스 플랫폼 인터페이스를 사용하고, WPF 버전은 기존 데스크톱 사용 방식을 유지합니다. 처음 설치한다면 데스크톱 버전을 먼저 살펴보세요. WPF에 익숙하다면 해당 버전을 계속 사용할 수 있습니다. 두 버전은 메뉴 위치가 다를 수 있으므로 이 섹션에서는 기능 이름을 기준으로 안내합니다. 특정 버튼의 위치를 모든 버전에 공통인 절차로 간주하지 마세요. 한 버전의 프로그램 파일을 다른 버전의 폴더에 덮어쓰면 설정과 종속성이 섞일 수 있습니다.

Windows 다운로드에서 패키지를 받은 뒤 실제 형식에 맞게 설치하거나 압축을 푸세요. 압축 해제가 필요한 패키지는 별도 폴더에 전체 압축을 풀어야 합니다. 압축 파일 안의 실행 파일을 바로 더블클릭하지 마세요. 경로가 단순하고 현재 사용자가 쓸 수 있는 위치를 선택하는 것이 좋습니다. 설정, 로그, 코어 실행에는 파일 쓰기가 필요할 수 있습니다. 보호된 폴더, 파일을 필요할 때만 내려받는 동기화 폴더, 임시 폴더에서는 실행 후 리소스를 찾지 못하거나 종료 시 설정을 저장하지 못할 수 있습니다.

첫 실행 및 런타임 확인

실행 후 기본 창이 정상적으로 표시되는지 확인하고 로그 영역에 코어 시작 오류가 있는지 살펴보세요. 프로그램 창이 열렸다는 것은 그래픽 인터페이스가 시작되었다는 뜻일 뿐, 코어까지 정상 실행되었다는 의미는 아닙니다. 시스템에서 .NET 런타임이 없다고 안내하면 설치 패키지 설명에 따라 필요한 런타임을 추가하세요. 이름이 비슷한 구성 요소를 짐작으로 설치하지 마세요. 자체 포함 패키지와 시스템 런타임에 의존하는 패키지는 요구 사항이 다릅니다. 계속 재설치하기보다 오류 메시지를 먼저 읽는 편이 빠릅니다.

보안 소프트웨어가 코어를 차단했다면 먼저 차단된 파일이 방금 설치한 클라이언트 패키지에서 온 것인지 확인한 다음 시스템 보호 기록을 살펴보세요. 운에 맡기고 보안 기능 전체를 끄지는 마세요. 인터페이스가 열리자마자 종료된다면 압축이 완전히 풀렸는지, 폴더에 쓸 수 있는지, 다른 인스턴스가 실행 중인지 확인하고 앱 오류 기록도 살펴보세요. 이런 시작 단계 문제는 v2rayN 실행 직후 종료 및 시작 충돌 해결에서 더 확인할 수 있습니다. 이 단계에서는 연결 매개변수를 바꿀 필요가 없습니다.

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

'구독 그룹 설정'에서 그룹을 만들고 이름과 구독 주소를 입력한 뒤 저장하세요. 기본 창으로 돌아와 '구독 그룹' 메뉴에서 '프록시 없이 구독 업데이트'를 실행합니다. 아직 사용 가능한 노드가 없다면 우선 프록시 없이 업데이트하는 편이 기준을 잡기 쉽습니다. 구독 사이트에 접속하려면 기존 연결이 필요한 경우에는 '프록시를 통해 구독 업데이트'를 선택하세요. 단, 현재 작동하는 노드가 있어야 합니다. 비어 있는 목록이 첫 설정을 대신 받아 오게 할 수는 없습니다.

업데이트가 끝나면 노드 목록과 그룹을 확인하고 노드 하나를 선택해 활성 서버로 지정하세요. 행 하나에 포커스가 놓였다고 해서 활성 설정이 바뀐 것은 아닐 수 있으니 클라이언트에 표시된 활성 상태를 확인해야 합니다. 공유 링크는 '클립보드에서 공유 링크 가져오기'로 가져오세요. 구독 주소 입력란에 붙여넣지 마세요. 가져온 뒤 필드가 비어 있다면 원본 링크가 메신저에서 잘리지 않았는지 확인하세요. 특히 끝부분의 매개변수와 퍼센트 인코딩에 주의하고, 복잡해 보이는 부분을 임의로 지우지 마세요.

먼저 시스템 프록시를 사용하고 TUN은 필요할 때 켜기

코어가 정상 실행되면 '시스템 프록시'에서 '시스템 프록시 자동 설정'을 선택하세요. 현재 연결이 필요한 주소에 브라우저로 접속한 뒤 클라이언트 로그에 해당 요청이 기록되는지 확인합니다. 브라우저에서는 되지만 다른 프로그램에서는 안 된다면 그 프로그램이 시스템 프록시를 읽는지 먼저 확인하세요. 일부 앱은 자체 프록시 입력란에 로컬 HTTP 또는 SOCKS 주소를 지정해야 합니다. 포트는 클라이언트의 실제 설정을 기준으로 하며 다른 안내의 기본값을 그대로 옮기지 마세요.

모든 기기의 트래픽을 처리해야 할 때만 TUN을 켜세요. 보통 관리자 권한이나 관련 구성 요소 초기화가 필요하며, 구체적인 절차는 클라이언트 안내를 따르세요. 다른 프록시 도구를 종료하고 남아 있는 가상 네트워크 어댑터가 트래픽을 처리하지 않는지 확인한 뒤 시작하세요. TUN에만 오류가 있고 시스템 프록시는 정상이라면 권한, 네트워크 어댑터, 시스템 라우팅 계층의 문제일 가능성이 높습니다. 서버부터 바꾸지는 마세요. 테스트 중 DNS, 라우팅 규칙, 전송 설정을 동시에 수정하면 무엇이 연결을 복구했는지 알 수 없습니다.

종료 후 복구 및 플랫폼별 주의사항

기본 창을 닫아도 트레이로 최소화된 것일 수 있습니다. 트래픽 처리를 중지하려면 '시스템 프록시'에서 '시스템 프록시 해제'를 선택하고 TUN을 끈 다음 트레이 메뉴에서 프로그램을 종료하세요. 프로그램이 비정상 종료되면 시스템 프록시가 중지된 로컬 포트를 계속 가리킬 수 있습니다. 이때 Windows 프록시 설정에서 수동 프록시 주소가 남아 있는지 확인하고, 주소를 지운 뒤 직접 연결이 복구되는지 먼저 확인하세요. 그런 다음 클라이언트를 다시 시작하면 됩니다. 브라우저의 독립 프록시 확장도 확인하세요. 시스템 설정과 함께 바뀌지 않을 수 있습니다.

자동 시작은 클라이언트의 관련 설정을 우선 사용하고 현재 사용자가 로그인한 뒤 실제로 실행되는지 확인하세요. 자동 시작 항목이 등록되어도 권한 차이로 TUN이 시작되지 않을 수 있습니다. 시작 항목을 여러 개 만들어 해결하려고 하지 마세요. 업그레이드 전에는 기존 프로세스를 종료하고 설정을 백업하세요. 업그레이드 후 시스템 프록시, 활성 서버, 로컬 포트를 다시 확인해야 합니다. 포트가 사용 중이라면 점유한 프로그램을 찾거나 비어 있는 포트로 바꾸고, 앱 쪽 설정도 함께 업데이트하세요. 한쪽만 바꾸면 안 됩니다.

macOS: 칩에 맞는 패키지, 네트워크 권한 및 트래픽 처리

칩에 맞는 v2rayN 설치하기

시스템의 '이 Mac에 관하여'를 열어 칩 이름이 표시되는지 Intel 프로세서가 표시되는지 확인하세요. Apple Silicon은 arm64, Intel은 x64 항목을 선택합니다. 실행 패키지는 칩 아키텍처에 따라 선택하며 시스템 언어나 화면 크기와는 관계가 없습니다. macOS 다운로드에서 해당 디스크 이미지를 받은 뒤 창의 안내에 따라 앱을 '응용 프로그램' 폴더로 옮기세요. 디스크 이미지나 다운로드 폴더에서 계속 실행하면 업데이트, 로그인 시 실행, 경로 권한이 서로 꼬일 수 있습니다.

처음 실행할 때 보안 확인 창이 뜨면 앱 출처와 방금 받은 클라이언트 파일이 맞는지 확인한 뒤 시스템의 '개인정보 보호 및 보안' 안내에 따라 처리하세요. 프로그램 하나를 실행하려고 전체 보안 기능을 끄거나 출처가 불분명한 제한 해제 스크립트를 실행하지 마세요. 시작 오류가 아키텍처 불일치를 가리키면 다운로드 페이지로 돌아가 올바른 패키지를 선택하세요. 변환 실행 가능 여부는 빌드에 따라 다르므로 잘못 고른 패키지를 항상 변환으로 해결할 수 있다고 보면 안 됩니다.

구독 가져오기 및 코어 실행 확인

'구독 그룹 설정'에 이름과 주소를 추가하고 저장한 뒤 구독을 업데이트하세요. 활성 노드가 없다면 먼저 프록시 없이 업데이트합니다. 활성 노드가 있고 구독 주소에 프록시 접속이 필요하다면 프록시를 통해 업데이트하세요. 목록이 표시되면 활성 서버를 선택하고 코어 로그에 시작 정보가 기록되는지 확인하세요. 그래픽 창 열기, 구독 가져오기, 노드 연결은 서로 별개의 동작입니다. 앞의 두 가지가 성공했다고 세 번째도 성공한 것은 아닙니다.

공유 링크를 직접 가져올 때는 '클립보드에서 공유 링크 가져오기' 기능을 사용하세요. 클립보드에는 완전한 링크만 있어야 하며 설명 문구나 메신저 인용 기호가 섞이면 안 됩니다. 가져온 뒤 주소, 포트, 전송 방식, TLS 관련 필드를 확인하세요. 암호 관리 도구나 다른 앱이 시스템 클립보드를 자동으로 비울 수 있습니다. 링크를 인식하지 못하면 다시 복사해 가져오세요. 한 번 가져오기에 실패했다고 구독 그룹에 같은 주소를 반복해서 만들지 마세요. 중복 그룹은 다음 업데이트 때 구분하기 어렵습니다.

시스템 프록시와 현재 네트워크 서비스

먼저 v2rayN의 '시스템 프록시' 기능에서 자동 설정을 켜고 브라우저로 확인하세요. macOS 프록시 설정은 특정 네트워크 서비스에 연결되어 있으므로 Wi-Fi, 유선 네트워크, 다른 인터페이스로 바꾸면 실제 사용 서비스도 달라질 수 있습니다. 네트워크를 바꾼 뒤 연결이 끊기면 시스템의 '네트워크' 설정에서 현재 서비스의 프록시 항목을 확인하고 클라이언트 설정을 다시 적용하세요. 목록에 있는 아무 인터페이스가 아니라 현재 사용하는 서비스를 확인해야 합니다.

앱이 별도의 프록시 설정을 사용할 수도 있습니다. 브라우저 하나는 정상인데 다른 앱이 실패한다면 해당 앱이 시스템 프록시를 읽는지 먼저 확인하고, 필요하면 로컬 HTTP 또는 SOCKS 인바운드를 직접 설정하세요. 주소와 포트를 수동으로 입력할 때는 클라이언트의 실제 수신 설정을 사용해야 합니다. 로컬 주소는 보통 루프백 주소이며 원격 서버 주소가 아닙니다. 원격 노드 포트를 앱의 로컬 프록시 항목에 넣으면 클라이언트의 프로토콜 처리를 건너뛰게 되어 연결만 계속 기다리는 경우가 많습니다.

TUN 권한 및 네트워크 전환

TUN은 시스템 프록시를 읽지 않는 트래픽을 처리하는 데 사용합니다. 켜기 전에 현재 빌드가 해당 기능을 지원하는지 확인하고 클라이언트가 요구하는 권한 절차를 마치세요. 권한 상승을 승인해야 한다면 안내에 나온 적용 범위를 읽으세요. 시스템 암호를 설정 파일이나 스크립트에 쓰면 안 됩니다. 처음 켤 때는 확인이 끝난 활성 노드와 기본 규칙을 유지하고 트래픽 처리 방식만 바꾸세요. TUN은 실패해도 시스템 프록시가 작동한다면 시스템 프록시로 작업을 계속하면서 가상 인터페이스 초기화와 권한 기록을 확인하세요.

다른 VPN, 네트워크 필터링 소프트웨어, 가상 머신 네트워크 구성 요소가 라우팅에 영향을 줄 수 있습니다. 문제를 진단할 때 트래픽 처리 도구를 하나만 일시 종료해 고장이 사라지는지 확인하세요. 모든 도구를 한꺼번에 다시 시작하지 마세요. 기기가 절전 모드에서 깨어나거나 네트워크를 전환하면 기존 연결과 인터페이스 상태가 무효화될 수 있습니다. 먼저 클라이언트 연결을 중지했다가 다시 시작해 세션을 재구성하세요. 그래도 문제가 있으면 TUN을 다시 켜서 확인하면 됩니다. 깨어나자마자 설정 전체를 삭제할 필요는 없습니다.

종료, 업그레이드 및 시스템 복구

종료 전에 시스템 프록시를 해제하고 TUN을 끈 뒤 직접 접속이 복구되는지 확인하고 앱을 종료하세요. 비정상 종료 후 네트워크를 사용할 수 없다면 현재 네트워크 서비스가 중지된 로컬 프록시를 계속 가리키는지 확인하세요. 시스템 프록시 주소가 남아 있으면 다른 앱이 로컬 포트에 계속 연결하려고 합니다. 네트워크가 갑자기 고장 난 것이 아닐 수 있습니다. 남은 프록시를 해제한 뒤에도 접속되지 않으면 다른 트래픽 처리 도구와 시스템 DNS 설정을 계층별로 확인하세요. 여러 문제를 한 번에 '초기화'로 뭉뚱그리지 마세요.

업그레이드 전에 그룹과 설정을 백업하고 실행 중인 앱을 종료한 뒤 프로그램을 교체하세요. 로그인 후 자동 실행이 되지 않으면 시스템의 '로그인 항목'과 클라이언트 자동 시작 설정이 충돌하는지 확인하고 한 가지 명확한 실행 방식만 남기세요. 앱을 삭제할 때는 먼저 트래픽 처리를 해제해야 합니다. 앱을 휴지통으로 옮기는 것만으로 모든 네트워크 설정이 복구되는 것은 아닙니다. 설정 폴더를 정리하기 전에 정보를 내보내세요. 특히 직접 만든 노드는 구독을 업데이트해도 다시 생성되지 않습니다.

Linux: 패키지 설치, 데스크톱 프록시 및 자동 시작

패키지 형식과 아키텍처를 각각 확인하기

Linux 데스크톱에서는 v2rayN을 우선 사용하세요. Ubuntu와 Debian은 보통 deb, Fedora와 openSUSE는 보통 rpm을 선택합니다. 기기가 x64인지 arm64인지도 확인해야 합니다. 패키지 형식이 맞아도 아키텍처가 틀리면 실행할 수 없습니다. Linux 다운로드에서 맞는 패키지를 선택하세요. deb의 확장자만 바꿔 rpm으로 만들 수는 없습니다. 배포판 이름, 패키지 형식, 프로세서 아키텍처는 별개의 정보이므로 설치 전에 각각 확인하세요. 데스크톱 테마만 보고 배포판을 추측하면 안 됩니다.

이 섹션에서는 그래픽 설치 프로그램을 기준으로 안내합니다. 패키지를 내려받아 열고 앱 이름, 종속성 안내, 설치 위치를 확인한 뒤 시스템 안내에 따라 권한을 승인하세요. 설치 프로그램에서 종속성이 부족하다고 표시되면 해당 배포판의 소프트웨어 관리 도구로 설치하세요. 다른 배포판의 공유 라이브러리를 시스템 폴더에 복사하지 마세요. 구버전이 있다면 업데이트 전에 프로세스를 종료하세요. 메뉴에 앱 아이콘이 보이면 데스크톱 실행 항목이 만들어진 것입니다. 실제로 실행되는지는 따로 확인해야 합니다.

첫 실행 및 디렉터리 권한

앱 메뉴에서 v2rayN을 실행하고 기본 화면과 코어 로그를 확인하세요. 그래픽 앱은 일반 사용자로 실행해야 합니다. 권한 오류를 피하려고 클라이언트 전체를 관리자 계정으로 계속 실행하지 마세요. 설정, 캐시, 로그는 현재 사용자의 데이터입니다. 실행 계정을 바꾸면 다른 디렉터리가 사용되어 '노드가 전부 사라졌다'거나 '설정이 저장되지 않는다'고 오해할 수 있습니다. 앱 문제라고 판단하기 전에 사용자 디렉터리에 쓰기 권한이 있는지 확인하세요.

아이콘을 눌러도 창이 나타나지 않으면 데스크톱 실행기가 올바른 프로그램을 가리키는지 확인하고 설치 중 종속성이 빠지지 않았는지 살펴본 뒤 시스템 앱 오류 정보를 확인하세요. 그래픽 구성 요소, 동적 라이브러리, 디스플레이 환경이 부족한 문제라면 프록시 설정은 아직 실행에 관여하지 않았으므로 구독을 바꿀 필요가 없습니다. 데스크톱 세션이 없는 서버는 여기서 설명하는 Linux 데스크톱 환경과 다릅니다. 그래픽 클라이언트에는 데스크톱 환경이 필요하므로 터미널만 제공되는 서버에 데스크톱 설치 절차를 그대로 적용할 수 없습니다.

설정 가져오기 및 시스템 프록시의 적용 범위

정상적으로 시작되면 '구독 그룹 설정'에 주소를 저장하고 프록시 없이 구독을 업데이트한 뒤 활성 서버를 선택하세요. 구독 업데이트와 연결 테스트는 따로 확인해야 합니다. 목록이 표시되었다는 것은 설정을 가져왔다는 뜻일 뿐, 실제 연결을 위해서는 전송 및 보안 필드를 확인해야 합니다. 공유 링크 하나를 가져오려면 클립보드 가져오기 기능을 사용하고 원본 링크를 보관해 점검할 수 있게 하세요. 여러 번 업데이트한 뒤 이름이 같은 노드가 있다면 표시 이름만 보지 말고 그룹과 서버 필드로 구분하세요.

'시스템 프록시 자동 설정'을 켠 뒤 데스크톱 브라우저로 먼저 테스트하세요. 데스크톱 환경마다 시스템 프록시를 읽는 방식이 다릅니다. 일부 앱은 데스크톱 설정을 따르고, 다른 앱은 환경 변수나 자체 프록시 항목만 사용할 수 있습니다. 브라우저는 되는데 터미널 프로그램이 안 된다면 진입 경로가 다른 것일 수 있습니다. 바로 TUN을 켜거나 라우팅을 '전역'으로 설정하면 모든 앱이 자동으로 처리된다고 생각하지 마세요. 먼저 대상 프로그램이 어떤 프록시 설정을 읽는지 확인하세요.

프록시를 직접 입력해야 한다면 앱 설정에 클라이언트의 로컬 수신 주소와 포트를 입력하고 HTTP와 SOCKS 프로토콜을 구분하세요. 클라이언트 포트를 바꾸면 앱 설정도 함께 변경해야 합니다. 여러 설정 파일에 이전 포트를 남겨 두지 마세요. 환경 변수는 시스템 또는 앱 환경 설정에서 확인할 수 있습니다. 클라이언트를 종료한 뒤에도 환경 설정이 로컬 프록시를 가리키면 프로그램 동작에 계속 영향을 줍니다. 해당 설정은 별도로 복구해야 하며 데스크톱의 '시스템 프록시 해제'가 사용자 지정 항목까지 바꾸지는 않을 수 있습니다.

TUN, 권한 및 배포판별 차이

TUN은 가상 인터페이스와 시스템 라우팅을 다루므로 대개 추가 권한이나 클라이언트가 제공하는 보조 기능이 필요합니다. 현재 빌드의 안내에 따라 초기화하고, 출처를 알 수 없는 권한 명령을 필수 절차로 간주하지 마세요. 켤 때 권한 오류가 발생하면 먼저 승인 절차가 완료되었는지 확인한 뒤 배포판의 보안 정책과 로그를 살펴보세요. 시스템 보안 모듈이 특정 작업을 막을 수도 있습니다. 보안 정책 전체를 끄기보다 거부된 동작을 찾아야 합니다.

방화벽, 다른 VPN, 가상 머신 네트워크 구성 요소가 TUN에 영향을 줄 수 있습니다. 테스트 전에 다른 트래픽 처리 도구를 종료하고 로컬 인바운드 포트를 다른 프로세스가 사용하지 않는지 확인하세요. 네트워크를 바꾼 뒤 직접 연결은 되지만 TUN이 작동하지 않는다면 트래픽 처리를 다시 시작해 경로를 갱신하세요. 시스템 프록시로 노드에 연결할 수 있다면 가상 인터페이스와 라우팅을 먼저 확인하고 같은 구독을 반복해서 가져오지 마세요. 한 번에 변수 하나만 바꾸세요. Linux 오류 메시지는 대체로 구체적이므로 끝까지 읽어볼 가치가 있습니다.

로그인 시 자동 시작 및 제거 마무리

데스크톱 자동 시작은 현재 사용자가 그래픽 세션에 로그인한 뒤 앱이 실행되는 것을 뜻합니다. 기기 전원을 켜는 즉시 연결된다는 뜻은 아닙니다. 클라이언트의 자동 시작 옵션이나 데스크톱 환경의 '시작 애플리케이션' 설정 중 하나를 사용하세요. 앱은 자동으로 실행되지만 TUN이 시작되지 않는다면 두 번째 시작 항목을 추가하지 말고 권한 초기화와 세션 환경을 확인하세요. 여러 인스턴스가 포트를 두고 경쟁하면 안정적이던 설정도 간헐적으로 실패할 수 있습니다.

제거하거나 업그레이드하기 전에 TUN을 끄고 시스템 프록시를 해제한 뒤 프로세스를 종료하세요. 그런 다음 배포판의 패키지 관리 도구로 설치 패키지를 처리합니다. 설정 디렉터리는 프로그램 패키지와 별도로 남을 수 있으므로 프로그램을 제거해도 연결 정보가 삭제되는 것은 아닙니다. 마이그레이션할 계획이라면 먼저 설정을 내보내고, 정리할 때는 데이터 범위를 확인하세요. 제거 후에도 네트워크에 문제가 있다면 삭제된 프로그램 파일만 보지 말고 앱 자체 프록시, 환경 설정, 다른 트래픽 처리 도구를 확인하세요.

Android: v2rayNG 가져오기 및 VPN 트래픽 처리

v2rayNG 선택 및 아키텍처에 맞는 설치

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 권장합니다. v2flyNG는 V2Fly 코어를 사용하는 대안입니다. 아이콘이나 이름이 비슷해서가 아니라 설정에 필요한 코어 기능을 기준으로 대안을 선택하세요. 대부분의 Android 기기는 arm64를 사용하며, 아키텍처를 모르겠다면 범용 버전을 고려할 수 있습니다. Android 다운로드에서 맞는 패키지를 받아 시스템 안내에 따라 설치하세요. 설치 권한은 실제 다운로드 앱이나 파일 관리자에만 허용하고, 설치 후 필요하지 않으면 회수할 수 있습니다.

업데이트 중 서명이 일치하지 않는다고 표시되면 바로 삭제하지 말고 기존 패키지와 새 패키지가 같은 클라이언트 및 배포 출처에서 나온 것인지 확인하세요. 앱을 삭제하면 로컬 노드와 설정도 함께 지워질 수 있으므로 먼저 백업해야 합니다. 아키텍처 불일치, 저장 공간 부족, 시스템 호환성 조건도 설치 실패 원인이 될 수 있습니다. 원인에 따라 해결 방법이 다릅니다. v2rayNG와 v2flyNG의 앱 데이터는 서로 분리되어 있으므로 다른 클라이언트를 설치해도 기존 구독이 자동으로 이전되지 않습니다.

구독과 공유 링크는 각각 가져오기

v2rayNG의 '구독 그룹 설정'에서 그룹 이름과 구독 주소를 추가하고 저장하세요. 기본 화면으로 돌아와 메뉴에서 '구독 업데이트'를 실행합니다. 업데이트가 끝나면 그룹의 설정을 확인하고 사용할 노드를 선택하세요. 빌드에 따라 메뉴 이름과 위치는 달라질 수 있지만 기능은 같습니다. 그룹은 갱신 가능한 주소를 저장하고 노드 목록에서는 실제 연결에 사용할 설정을 선택합니다. 새 그룹을 만든 직후 노드가 나타나지 않는다면 보통 업데이트를 실행하지 않은 것이며 저장에 실패한 것은 아닙니다.

공유 링크 하나를 가져오려면 '클립보드에서 가져오기'를 사용하세요. 복사할 때 링크 전체를 포함하고 메신저에서 화면에 보이는 부분만 잘려 복사되지 않도록 주의하세요. QR 코드도 설정을 가져오는 방법이므로 스캔 결과에 인식 가능한 전체 내용이 있어야 합니다. QR 코드나 링크에 민감한 매개변수가 포함되어 있다면 공개 문의 화면에 올리지 마세요. 가져온 뒤 전송 유형, TLS, 서버 이름을 확인하세요. 항목이 하나 표시되더라도 서버 설정과 일치한다는 보장은 없습니다.

VPN 모드 승인 및 라우팅 선택

VPN 모드로 처음 연결하면 시스템 권한 승인 안내가 표시됩니다. 이는 앱이 기기의 트래픽을 받을 로컬 VPN 인터페이스를 만들도록 허용하는 절차이며 원격 서버 연결에 성공했다는 뜻은 아닙니다. 승인한 뒤 클라이언트로 돌아가 연결 버튼 상태와 로그를 확인하고 실제 접속을 테스트하세요. Android에서는 VPN 트래픽을 처리하는 앱 두 개를 동시에 활성 상태로 유지할 수 없는 경우가 많습니다. 다른 앱으로 연결이 대체되었다고 표시되면 어느 앱을 사용할지 먼저 결정하세요. 두 도구가 번갈아 트래픽 처리를 차지하게 두지 마세요.

'설정'에서 VPN 모드와 라우팅 옵션을 확인하세요. 일반적인 분할 라우팅은 우선 'LAN 및 중국 본토 주소 우회'를 사용할 수 있고, 비교 테스트가 필요할 때만 잠시 전역 모드로 바꾸세요. 라우팅은 클라이언트에 이미 들어온 트래픽의 경로를 바꾸는 기능이지 잘못된 서버 주소를 고치는 기능이 아닙니다. 특정 앱이 트래픽 처리 대상에서 제외되었다면 전역 모드로 바꿔도 요청이 코어에 들어오지 않습니다. 앱마다 동작이 다르면 먼저 앱별 분할 설정을 확인한 다음 라우팅을 살펴보세요.

데스크톱 가이드의 '시스템 프록시 설정' 절차를 Android VPN 모드에 그대로 적용하면 안 됩니다. Android는 보통 시스템 VPN 인터페이스를 통해 코어에 트래픽을 전달하고, 데스크톱의 시스템 프록시는 앱이 해당 설정을 읽어야 작동합니다. 같은 서비스에 연결하려면 설정 정보를 옮길 수 있지만 트래픽 처리 스위치는 플랫폼별로 따로 설정해야 합니다. 웹 페이지에 먼저 접속해 인증해야 하는 네트워크라면 클라이언트 연결 전에 인증을 마치세요. 그렇지 않으면 VPN과 구독 업데이트가 모두 시간 초과로 멈출 수 있습니다.

백그라운드 실행, 배터리 정책 및 네트워크 전환

연결 후 일정 시간이 지나면 자동으로 끊기는 경우 먼저 시스템이 백그라운드 프로세스를 종료하는지 확인하세요. 기기마다 배터리 관리 메뉴 이름은 다르지만 앱 정보에서 배터리 최적화, 백그라운드 활동, 자동 시작 제한을 살펴볼 수 있습니다. 이 클라이언트에 필요한 권한만 조정하세요. 모든 앱에 권한을 확대할 필요는 없습니다. 알림과 포그라운드 서비스 상태는 연결 유지에 도움이 되지만 알림이 표시된다고 원격 세션이 계속 유효한 것은 아닙니다. 네트워크 전환 후에는 실제로 접속되는지 확인해야 합니다.

Wi-Fi에서 모바일 네트워크로 바꾸면 기존 연결을 다시 설정해야 할 수 있습니다. 먼저 연결을 중지했다가 다시 시작해 복구되는지 확인하세요. 특정 네트워크에서만 실패할 때 DNS, 서버 접근성, 네트워크 인증 조건을 비교하면 됩니다. 네트워크 전환으로 한 번 끊겼다고 고급 옵션을 전부 켜지 마세요. 기준을 잡을 때는 Mux를 꺼 두는 것이 좋으며, 스니핑도 라우팅 요구에 맞춰 사용해야 합니다. 고급 설정을 많이 켠다고 안정성이 높아지는 것은 아닙니다. 기능이 추가될수록 확인할 변수도 늘어납니다.

로컬 DNS 및 종료 확인

도메인 접속 문제라면 '로컬 DNS' 설정을 확인하고 현재 라우팅 및 코어 동작과 함께 조회 경로를 살펴보세요. 코어와 클라이언트 빌드에 따라 옵션이 다를 수 있으므로 오래된 화면의 값을 전부 그대로 복사하면 안 됩니다. DNS 서버는 현재 네트워크 또는 현재 프록시 경로에서 접근할 수 있어야 합니다. 순수 IP 주소로는 접속되지만 도메인으로는 실패한다면 DNS를 중점적으로 확인할 수 있습니다. 다만 일부 서비스는 올바른 호스트 이름과 TLS 설정이 필요하므로 IP 주소로 대체하는 것을 최종 해결책으로 삼아서는 안 됩니다.

종료할 때는 먼저 연결을 중지하고 시스템 VPN 상태가 해제되었는지 확인하세요. v2flyNG로 바꾸려면 v2rayNG를 중지한 뒤 호환 설정을 다시 가져오고 권한을 승인하세요. 기존 설정이 자동으로 동기화된다고 가정하면 안 됩니다. 제거 전에 구독과 수동 노드를 백업하고 마이그레이션 후 라우팅과 앱별 분할 설정을 다시 확인하세요. 일반적인 설치 및 연결 질문은 자주 묻는 질문에서 확인할 수 있습니다. 문의할 때는 운영체제 버전, 클라이언트 이름, 민감 정보를 가린 오류 내용을 제공하세요. 전체 구독 주소를 공개할 필요는 없습니다.

구독 및 마이그레이션: 주소, 목록, 로컬 수정

구독 주소와 노드 주소는 다릅니다

구독은 설정 목록을 가져오는 경로이고, 노드는 목록에 포함된 실제 연결 항목입니다. 구독은 일반 웹 주소를 사용할 수 있지만 노드에는 프로토콜, 서버, 포트, 인증 매개변수가 들어갑니다. 구독 업데이트는 목록을 내려받아 해석하는 작업이지 각 서버를 테스트하는 작업이 아닙니다. 따라서 '업데이트 성공'과 '노드 연결 가능'은 각각 확인해야 합니다. 공유 링크는 보통 노드 하나를 설명하므로 임시로 가져오기에 적합하지만 구독처럼 지속적으로 갱신되지는 않습니다. 서버 정보가 바뀌면 새 링크를 받아야 하는 경우가 많습니다.

구독 주소의 쿼리 매개변수는 권한 확인에 사용될 수 있으므로 도메인과 경로만 남기면 안 됩니다. 복사할 때 끝부분 매개변수가 빠지면 서버에서 오류 페이지, 로그인 페이지, 빈 응답을 반환할 수 있습니다. 브라우저에서 주소가 열린다고 클라이언트가 이를 해석할 수 있다는 뜻은 아닙니다. 웹 페이지와 구독 데이터는 서로 다른 형식입니다. 계정 페이지 주소가 아니라 서비스에서 제공한 클라이언트용 구독 주소를 사용하세요. 전체 링크를 구분하는 방법은 공유 링크와 구독의 차이에서 확인할 수 있습니다.

프록시 없이 업데이트와 프록시를 통한 업데이트

프록시 없이 업데이트하면 보통 현재 기본 네트워크를 통해 구독을 가져옵니다. 프록시를 통한 업데이트는 이미 만들어진 로컬 프록시 연결을 사용합니다. 처음 설정해 노드가 없다면 우선 전자를 시도하세요. 전자가 실패했지만 사용할 수 있는 연결이 있다면 후자를 시도하면 됩니다. 두 방식 모두 같은 목록을 가져오며, 선택 기준은 어느 방식이 더 빠른지가 아니라 구독 사이트에 접근할 수 있는 경로입니다. 기존 연결이 불안정하다면 프록시 업데이트는 문제 하나를 두 문제로 늘릴 수 있습니다.

업데이트에 실패하면 오류가 어느 단계에서 발생했는지 확인하세요. 도메인 조회, 연결, TLS 핸드셰이크, 서버 응답, 콘텐츠 해석 중 어느 단계인지 살펴봅니다. 해석 오류는 반환된 내용이 구독 형식이 아닐 때 자주 발생하고, 연결 오류라면 주소와 접근 경로를 확인해야 합니다. 시스템 시간이 맞지 않아 보안 연결이 실패할 수도 있습니다. 같은 그룹을 반복해서 새로 만들어도 조건은 바뀌지 않고 중복 기록만 늘어납니다. 기존 그룹을 유지하고 전체 오류를 한 번 기록한 뒤 네트워크 경로와 반환 내용을 나눠 확인하세요.

그룹 이름 지정 및 업데이트 후 변경사항

출처나 용도에 따라 그룹을 만들고 알아보기 쉬운 메모를 남기세요. 업데이트 후 노드 수, 이름, 정렬 순서가 바뀔 수 있으며 활성 항목도 다시 확인해야 할 수 있습니다. 표시 이름은 메모일 뿐 안정적인 식별자가 아닙니다. 이름이 같은 노드라도 주소와 포트가 다를 수 있고, 이름이 달라도 같은 서비스를 가리킬 수 있습니다. 선택할 때는 프로토콜과 서버 필드를 확인하세요. 목록 순서가 계속 유지된다고 가정해서는 안 됩니다. 자동 테스트 결과는 현재 환경에서 참고 자료로만 사용하고 실제 앱으로 최종 검증해야 합니다.

구독 노드를 클라이언트에서 로컬 편집하면 다음 업데이트 때 변경사항이 덮어써질 수 있습니다. 특수 설정을 계속 보관해야 한다면 별도의 수동 설정 영역에 복사하고 변경 목적을 기록하세요. 구독 노드를 직접 수정한 뒤 출처를 잊지 마세요. 서버 주소나 인증 정보가 바뀌어도 복사한 설정은 자동으로 갱신되지 않으므로 직접 관리해야 합니다. 구독은 수동 업데이트를 줄이고 수동 설정은 개별 수정을 보관합니다. 자동 갱신과 영구 보존을 동시에 기대할 수는 없습니다.

플랫폼 간 마이그레이션 시 유지할 항목

데스크톱에서 Android로 옮길 때는 구독 주소를 다시 추가해 대상 클라이언트가 자체 형식으로 설정을 생성하도록 하는 것이 좋습니다. 노드 하나만 옮길 때는 공유 링크를 사용할 수도 있습니다. 한 플랫폼에서 내보낸 앱 설정 전체를 다른 플랫폼에 그대로 가져오지 마세요. 로컬 포트, 경로, 시스템 프록시, 트래픽 처리 방식은 공통으로 사용할 수 없습니다. 프로토콜 매개변수와 서비스 정보는 공통으로 쓸 수 있지만 권한, 인터페이스, 백그라운드 정책, 앱별 분할은 대상 기기에서 다시 확인해야 합니다.

전체 설정 가져오기는 코어 형식을 잘 아는 사용자에게 적합합니다. Xray와 V2Fly는 공통된 설정 개념이 있지만 지원 필드와 기능에는 차이가 있습니다. 클라이언트에 프로토콜 이름이 표시된다고 관련 전송 조합을 모두 지원하는 것은 아닙니다. 마이그레이션 후 알 수 없는 필드나 지원되지 않는 보안 방식이 표시되면 대상 코어가 이를 지원하는지 먼저 확인하세요. 오류가 난 필드를 무작정 삭제하지 마세요. 파일은 시작되더라도 연결 동작이 달라져 오류가 시작 단계에서 핸드셰이크 단계로 옮겨갈 수 있습니다.

백업 및 민감 정보 가리기

백업에는 최소한 구독 그룹, 수동 노드, 중요한 라우팅 설정을 포함하세요. 본인이 관리할 수 있는 위치에 저장하고 출처 클라이언트와 백업 시각을 적어 두세요. 플랫폼별 파일을 한 폴더에 섞지 않는 것이 좋습니다. 복원 전에 대상 클라이언트가 백업 형식을 지원하는지 확인한 뒤 가져오세요. 문제 해결을 위해 민감 정보를 가린 사본을 만들고 유일한 백업 파일을 직접 수정하지 마세요. 구독은 다시 추가할 수 있지만 백업하지 않은 수동 매개변수는 인터페이스 기록에서 복구하지 못할 수 있습니다.

구독을 정기적으로 업데이트하기 전후에 활성 노드를 확인하세요. 특히 서비스 제공자가 이름이나 목록 구조를 변경한 뒤에는 다시 살펴봐야 합니다. 자동 업데이트는 연결을 복구하는 기능이 아니며 업데이트 시각이 노드 정상 여부를 보장하지도 않습니다. 구독이 계속 인식할 수 없는 내용을 반환한다면 먼저 제공자에게 호환되는 클라이언트 형식을 확인한 뒤 가져오기 방식을 바꿀지 판단하세요. 문제 해결 후 중복 테스트 그룹을 지우고 출처와 용도가 명확한 설정 하나만 남기면 다음 업그레이드 때 원인을 구분하기 쉽습니다.

라우팅 및 DNS: 트래픽이 들어오는 곳부터 나가는 곳까지

먼저 트래픽이 코어에 들어오는지 확인하기

라우팅은 코어에 들어온 요청만 처리합니다. 데스크톱 앱이 시스템 프록시를 읽지 않거나, Android 앱이 트래픽 처리 대상에서 제외되거나, TUN이 정상 시작되지 않았다면 라우팅 규칙은 실행될 기회조차 없습니다. 문제를 확인하기 전에 요청 로그를 살펴 대상 앱의 접속이 기록되는지 확인하세요. 기록이 전혀 없다면 시스템 프록시나 트래픽 처리 설정으로 돌아가세요. 기록은 있는데 출구가 예상과 다르면 라우팅을 확인합니다. 이 순서를 따르면 진입 단계 문제를 분할 규칙 문제로 오해하지 않을 수 있습니다.

전역 모드는 보통 전달받은 트래픽을 프록시 아웃바운드로 보내고, 우회 모드는 규칙에 따라 일부 목적지를 직접 연결 아웃바운드로 보냅니다. 시스템 프록시와 라우팅 모드는 같은 설정이 아닙니다. 하나는 트래픽이 들어오는 경로를, 다른 하나는 들어온 뒤 이동할 경로를 정합니다. 클라이언트 인터페이스의 모드 이름은 구체적인 규칙으로 변환되므로 원리를 이해한 뒤에도 실제 생성된 설정을 확인해야 합니다. 계층별 설명은 시스템 프록시 및 라우팅 모드 안내에서 확인할 수 있습니다.

규칙 순서 및 아웃바운드 태그

일반적인 라우팅 규칙은 순서대로 검사하며 먼저 일치한 규칙이 처리 방식을 결정합니다. 특정 도메인에 대한 세부 규칙은 범위가 넓은 규칙보다 앞에 둬야 합니다. 그렇지 않으면 뒤의 예외 규칙이 적용되지 않을 수 있습니다. 아웃바운드 태그는 설정에서 참조하는 이름이지 프로토콜 이름이 아닙니다. 규칙에 outboundTag를 지정했다면 같은 이름의 아웃바운드가 있어야 합니다. 태그 이름이 틀리면 시작 오류가 발생하거나 예상과 다르게 동작할 수 있습니다. 도메인 목록만 확인하고 출구 정의를 빠뜨리지 마세요.

아래는 Xray 또는 V2Fly 클라이언트 설정에 합칠 수 있는 라우팅 조각입니다. 전체 설정에 direct라는 직접 연결 아웃바운드가 이미 있다고 가정합니다. 루프백 및 사설 주소는 직접 연결로 보내고 나머지 요청은 전체 설정의 기본 아웃바운드를 따릅니다. 이 조각에는 원격 서비스 정보가 없으며 단독 연결 설정으로 사용할 수 없습니다. 사설 주소 규칙은 로컬 네트워크 접근을 유지하는 데 유용하지만 실제 배포에서는 로컬 네트워크가 다른 특수 주소 대역을 사용하는지도 확인해야 합니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "127.0.0.0/8",
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "::1/128",
          "fc00::/7",
          "fe80::/10"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

domainStrategy와 도메인 일치

AsIs는 주로 이미 확인된 도메인 정보를 기준으로 일치 여부를 판단합니다. IPIfNonMatch는 도메인 규칙에 일치하지 않을 때 조회를 시도한 뒤 IP 규칙을 확인합니다. IPOnDemand는 일치 판단에 IP 정보가 필요할 때 조회합니다. 이 옵션은 라우팅 규칙을 검사하는 단계의 동작을 설명하며 시스템 DNS 설정과는 다릅니다. 이름이 비슷해도 아웃바운드 연결 단계와 라우팅 단계의 조회 정책을 혼동하면 안 됩니다. 변경 후에는 도메인 접속 여부만 보지 말고 어떤 규칙이 일치했는지 확인하세요.

도메인 규칙에서 full:은 도메인 전체가 일치해야 하며 domain:은 지정 도메인과 하위 도메인을 대상으로 합니다. 일반 문자열은 다르게 동작하므로 모든 표기를 같은 의미로 취급하면 안 됩니다. 규칙 데이터 파일을 사용할 때는 코어가 파일을 찾을 수 있는지, 분류 이름을 인식하는지도 확인하세요. 처음 설정할 때는 전체 목록을 직접 작성하기보다 클라이언트의 기본 라우팅 기능을 사용하는 편이 좋습니다. 먼저 기준을 만든 뒤 필요한 예외만 하나씩 추가하세요.

DNS 조회 위치 및 실패 유형

DNS는 도메인을 주소로 변환합니다. 조회 요청은 설정에 따라 앱, 운영체제, 코어, 트래픽 처리 구성 요소에서 발생할 수 있습니다. 앱이 도메인을 IP로 변환한 뒤 프록시에 전달했다면 코어에 원래 도메인이 남아 있지 않을 수 있습니다. 그러면 IP 규칙은 정상 작동해도 도메인 규칙은 일치하지 않는 것처럼 보입니다. 스니핑으로 일부 프로토콜 트래픽에서 도메인 정보를 보완할 수 있지만 모든 트래픽에서 추출 가능한 것은 아닙니다. 만능 도메인 복구 스위치로 생각하면 안 됩니다.

DNS 서버는 선택한 경로를 통해 접근할 수 있어야 합니다. 직접 연결할 수 없는 DNS 서비스를 직접 연결 경로에 두면 '노드는 정상인데 도메인만 시간 초과'가 발생할 수 있습니다. 아직 만들어지지 않은 프록시를 DNS 조회에 의존하면 시작 단계에서 의존성 문제가 생길 수도 있습니다. 먼저 서버 주소를 조회하는 과정과 대상 웹사이트를 조회하는 과정을 구분한 다음 순환 의존성이 있는지 확인하세요. DNS를 테스트할 때 사용한 네트워크, 트래픽 처리 방식, 캐시 상태를 기록하세요. 네트워크를 바꾼 뒤에는 오래된 캐시가 실제 결과를 가릴 수 있으므로 필요하면 관련 앱을 다시 시작해 확인하세요.

스니핑, Mux 및 검증 방법

스니핑은 도메인 기반 라우팅을 돕는 기능이고 Mux는 연결을 다중화하는 기능입니다. 해결하는 문제가 서로 다릅니다. Mux를 켜도 인증 오류가 해결되지는 않으며 모든 전송 조합의 안정성이 높아진다고 보장할 수도 없습니다. 처음 설정할 때는 기본값을 유지하고 다중화를 끈 채 시작하세요. 연결이 안정된 뒤 필요한 경우에만 시도하면 됩니다. 특정 기능을 켠 뒤 끊김이 생기면 해당 설정을 되돌리고 다시 테스트하세요. 고급 기능은 실제 요구가 있을 때 사용해야 하며 모든 스위치를 켜는 것을 완료 기준으로 삼지 마세요.

JSON을 편집할 때 쉼표, 따옴표, 배열 구조에 주의하고 임의로 주석을 추가하지 마세요. 원본 파일을 보관한 뒤 사본을 수정하고 시작에 실패하면 즉시 되돌리세요. 노드를 바꿀 때 클라이언트가 생성된 설정을 다시 작성할 수 있습니다. 장기간 유지할 규칙은 임시 출력 파일을 반복해서 편집하지 말고 클라이언트의 라우팅 설정에 저장하세요. 필드별 역할은 설정 파일 구조 살펴보기에서 확인할 수 있습니다. 인바운드, 아웃바운드, 라우팅을 나눠 이해하세요.

설정 문제 해결: 오류 발생 단계별 진단

인터페이스가 열리지 않는 문제는 노드 연결과 별개입니다

실행 직후 종료되거나 창이 나타나지 않거나 런타임 구성 요소가 없다고 표시되면 앱 시작 단계 문제입니다. 설치 패키지 아키텍처, 설치 과정, 폴더 권한, 런타임 환경부터 확인하세요. 이때 코어가 연결 설정을 읽기 전일 수 있으므로 구독을 수정해도 해결되지 않습니다. Windows에서는 런타임과 압축 해제 폴더를, macOS에서는 아키텍처와 보안 안내를, Linux에서는 그래픽 종속성과 사용자 세션을, Android에서는 설치 호환성과 앱 데이터 상태를 확인하세요.

인터페이스는 열리지만 코어 시작에 실패하면 로컬 포트 점유, 설정 형식, 코어 지원 범위를 확인하세요. 클라이언트 두 개가 동시에 실행되면 포트를 두고 경쟁할 수 있고 이전 프로세스가 남아 있어 새 인스턴스가 수신 대기하지 못할 수도 있습니다. 불필요한 인스턴스를 종료하고 수신 주소와 포트를 확인한 뒤 다시 시도하세요. 지원되지 않는 필드라는 오류가 나오면 현재 코어의 기능과 가져온 형식을 확인하세요. 고급 필드를 전부 지운 뒤 해결되었다고 단정하면 연결 동작이 완전히 달라질 수 있습니다.

구독에 노드는 있지만 연결이 계속 시간 초과

시간 초과는 어떤 단계가 예상 시간 안에 끝나지 않았다는 뜻이지 인증 매개변수가 잘못되었다는 의미는 아닙니다. 기본 네트워크가 정상인지, 서버 도메인이 조회되는지 확인한 다음 원격 주소와 포트가 유효한지 살펴보세요. 특정 노드 하나만 시간 초과되고 다른 노드는 정상이라면 해당 서비스나 설정을 우선 확인하세요. 같은 네트워크에서 모든 노드가 실패하고 다른 네트워크에서는 복구된다면 네트워크 환경과 조회 경로를 비교하세요. 서비스가 사용 가능한지는 제공자에게 확인해야 합니다. 클라이언트는 시간 초과 메시지만으로 원인을 특정할 수 없습니다.

TLS 오류가 발생하면 기기 시간, 서버 이름, 인증서 요구 사항을 확인하세요. 연결 주소와 TLS 서버 이름은 서로 다를 수 있으며 각각 용도가 있습니다. 주소가 IP라고 해서 서버 이름까지 IP로 바꾸면 안 됩니다. WebSocket 경로, Host, gRPC 서비스 이름, 기타 전송 매개변수는 서버 설정과 일치해야 합니다. 공유 링크를 가져오면 수동으로 필드를 채우는 것보다 정확한 경우가 많습니다. 직접 설정해야 한다면 원본 정보를 항목별로 확인하고 알 수 없는 값을 기본값으로 추측해 채우지 마세요.

브라우저는 되지만 다른 앱은 실패

이런 차이가 있으면 먼저 트래픽 진입 경로를 확인하세요. 앱이 시스템 프록시를 무시하거나 자체 설정을 사용하거나, Android 앱별 분할 대상에서 제외되었거나, 현재 인바운드가 처리하지 못하는 트래픽을 보낼 수 있습니다. 클라이언트 로그에 해당 요청이 들어왔는지 확인하세요. 기록이 없다면 앱 프록시나 트래픽 처리 범위를 조정하고, 기록이 있다면 라우팅과 아웃바운드를 확인합니다. TUN은 처리 범위를 넓힐 수 있지만 권한과 라우팅이라는 변수를 더합니다. 시스템 프록시가 정상 작동하는지 확인한 뒤 사용하세요. 앱 문제마다 처음부터 TUN을 켤 필요는 없습니다.

웹사이트 첫 화면은 열리지만 일부 리소스가 로드되지 않는다면 도메인 차이, 캐시된 연결, 프로토콜 동작이 원인일 수 있습니다. 실패한 대상을 기록하고 다른 규칙으로 분기되는지 비교하세요. 브라우저의 보안 DNS나 독립 프록시 확장도 경로를 바꿀 수 있으므로 테스트 중에는 명확한 설정 하나만 사용하세요. 오래전에 열어 둔 웹 페이지 하나만 보고 현재 연결을 판단하지 마세요. 이전 페이지와 캐시된 리소스는 새 요청이 성공했다는 증거가 아닙니다. 페이지를 새로고침하거나 새로운 세션으로 접속하는 편이 낫습니다.

클라이언트를 중지한 뒤 기본 네트워크도 사용할 수 없음

가장 먼저 확인할 것은 남아 있는 시스템 프록시입니다. 운영체제가 계속 로컬 주소로 요청을 보내는데 클라이언트는 더 이상 수신하지 않으면 시스템 프록시를 따르는 앱이 모두 실패합니다. 먼저 시스템 프록시를 해제한 뒤 TUN이 중지되었는지, 다른 VPN이 계속 트래픽을 처리하는지 확인하세요. Android에서는 시스템 VPN의 연결 차단 옵션도 살펴봐야 합니다. 직접 연결을 복구한 뒤 클라이언트를 다시 시작하세요. 종료 과정에서만 문제가 발생한다면 노드를 바꾸지 말고 종료 후 복구 설정을 바로잡으세요.

로그 보관 항목과 테스트 변경 사항

로그에는 발생 시각, 작업 순서, 오류 유형, 관련 필드 이름을 남기세요. 마지막 줄만 캡처하면 실제 원인이 빠질 수 있으므로 판단에 필요한 앞뒤 내용을 함께 보관하는 편이 좋습니다. 다만 서버 권한 매개변수, 사용자 ID, 전체 구독 주소는 반드시 가려야 합니다. 일시적으로 로그 상세 수준을 높이면 원인 파악에 도움이 됩니다. 테스트가 끝나면 평소 수준으로 되돌려 데이터가 지나치게 쌓이지 않게 하세요. 로그에 접속 대상이 포함될 수도 있으므로 백업하거나 공유할 때 개인정보를 고려해야 합니다.

간단한 비교표를 만들어 보세요. 같은 노드가 시스템 프록시와 TUN에서 동일하게 작동하는지, 같은 설정이 네트워크를 바꾸어도 동일한지, 같은 네트워크에서 노드를 바꾸면 결과가 달라지는지 기록합니다. 한 번에 하나만 바꾸세요. 노드 교체, DNS 변경, 스니핑 활성화를 동시에 하면 해결된 뒤에도 어떤 조치가 필요했는지 알 수 없습니다. 효과가 확인된 수정만 남기고 나머지 테스트 변경은 되돌려 최소한의 작동 설정을 유지하세요. 안정성은 모든 옵션을 차례로 켜 보는 데서가 아니라 설정을 설명할 수 있는 데서 나옵니다.

문제가 계속 해결되지 않으면 클라이언트 이름, 운영체제와 아키텍처, 트래픽 처리 방식, 오류 발생 단계, 민감 정보를 가린 로그를 정리한 뒤 자주 묻는 질문에서 해당 항목을 확인하세요. 연결을 처음부터 다시 설정해야 한다면 빠른 시작 가이드의 최소 절차로 검증하세요. 업그레이드하거나 패키지를 바꿔야 한다면 다운로드 센터에서 플랫폼에 맞는 항목을 선택하세요. 재설치는 마지막으로 고려할 환경 조치이며 잘못된 매개변수나 서비스 상태 확인을 대신할 수 없습니다.