데스크톱에서는 v2rayN, Android에서는 v2rayNG를 권장합니다. 운영체제와 아키텍처를 선택한 뒤 가이드에 따라 기존 설정을 가져오세요.
데스크톱 버전은 크로스 플랫폼 인터페이스를 제공하며, 클래식 WPF 버전은 익숙한 Windows 화면 구성을 유지합니다. 처음 설치할 때는 시스템 요구 사항을 확인하고 쓰기 권한이 있는 폴더에 프로그램을 설치하세요. 구독을 가져온 뒤 사용할 구성을 선택하고 시스템 프록시 자동 설정을 켠 다음 브라우저에서 연결을 확인합니다. 두 인터페이스의 메뉴 위치는 다를 수 있지만 구독, 라우팅, 로컬 수신 포트를 확인하는 순서는 같습니다.
다운로드 페이지로 이동 →Xray 코어를 사용하는 v2rayNG를 우선 권장하며, V2Fly 코어가 필요할 때 v2flyNG를 고려하세요. 일반적인 기기에서는 arm64를 선택하고, 아키텍처를 모를 때는 범용 패키지 안내를 확인하면 됩니다. 처음 연결할 때는 Android 시스템의 VPN 권한을 허용해야 합니다. 앱별 프록시 설정과 백그라운드 배터리 제한에 따라 실제로 처리되는 트래픽 범위가 달라질 수 있습니다. 클라이언트를 바꾸기 전 설정을 저장하세요. 두 앱의 설정은 자동으로 동기화되지 않습니다.
다운로드 페이지로 이동 →먼저 ‘이 Mac에 관하여’에서 칩 종류를 확인한 뒤 Apple Silicon 또는 Intel 설치 파일을 선택하세요. 설치 후 시스템 안내에 따라 앱 실행 권한을 설정하고, 클라이언트가 코어를 실행했는지 확인한 다음 시스템 프록시를 켭니다. 브라우저는 연결되지만 다른 앱은 연결되지 않는다면 해당 앱이 시스템 프록시를 사용하는지 확인하세요. 더 많은 트래픽을 처리해야 하는 경우에만 TUN의 권한과 라우팅 요구 사항을 살펴보세요.
다운로드 페이지로 이동 →배포판의 패키지 형식에 따라 deb 또는 rpm을 선택하고 기기의 아키텍처가 x64인지 arm64인지 확인하세요. 그래픽 클라이언트에서 설정을 관리할 수 있지만, 데스크톱 환경에서 시스템 프록시를 사용할지는 별도로 확인해야 합니다. 터미널 프로그램은 자체 프록시 매개변수를 사용할 수도 있으므로 브라우저 연결만으로 모든 요청이 처리된다고 판단할 수 없습니다. 실행에 실패하면 먼저 의존성과 폴더 권한을 확인한 다음 클라이언트 로그를 살펴보세요.
다운로드 페이지로 이동 →구성 소스, 요청 경로, 트래픽 처리 범위를 구분해 이해하세요. 한 번에 한 종류의 설정만 바꾸고 확인한 뒤 다음 단계로 넘어가세요.
소스별로 관리하고 업데이트 후 구성을 선택하세요
구독 링크는 여러 연결 구성을 가져오는 주소이지, 단일 노드 주소가 아닙니다. 먼저 클라이언트에 구독 그룹을 만든 다음 전체 링크를 입력하고 업데이트하세요. 소스별로 구분해 저장하면 각 구성이 어떤 구독에서 생성됐는지 확인하기 쉽고, 직접 추가한 항목과 섞이는 일도 줄어듭니다. 업데이트가 끝나면 그룹에 선택 가능한 구성이 표시되는지 확인하고 사용할 서버로 지정하세요. 설정을 주기적으로 바꾸는 경우에는 공유 링크를 하나씩 관리하는 것보다 구독 그룹을 업데이트하는 편이 편리하지만, 소스가 유효한지는 계속 확인해야 합니다.
구독 가져오기 가이드 →구독 주소와 단일 구성 링크 구분하기
단일 공유 링크에는 보통 프로토콜, 주소, 포트, 전송 매개변수가 포함되며, 임시로 항목을 추가하거나 특정 구성을 확인할 때 적합합니다. 복사할 때 줄바꿈이나 공백이 들어가거나 메신저에서 내용이 잘리지 않도록 전체 링크를 유지하세요. 가져온 뒤 프로토콜과 전송 유형이 올바르게 인식됐는지, 현재 클라이언트와 코어가 해당 옵션을 지원하는지 확인합니다. 공유 링크와 구독 주소는 가져오기 메뉴가 다를 수 있습니다. 잘못된 곳에 붙여 넣으면 목록이 비거나 파싱 안내가 표시될 수 있으므로, 한 번 파싱에 실패했다고 곧바로 네트워크 문제로 판단하지 마세요.
가져오기 단계 보기 →먼저 연결 여부를 확인하고 사용 경험은 따로 살펴보세요
노드 테스트 결과는 특정 테스트 방식과 당시 네트워크 상태만 보여 줍니다. 브라우저나 다른 앱에서 실제로 사용하는 경험과 같다고 볼 수는 없습니다. 먼저 테스트 성공 여부를 확인한 뒤 대상 앱으로 필요한 서비스에 접속해 보세요. 모든 연결이 시간 초과되면 로컬 네트워크, 코어 실행 상태, 구독 유효성을 먼저 확인합니다. 특정 구성만 실패한다면 서버 주소와 전송 매개변수를 점검하세요. 테스트 메뉴마다 결과를 한데 모아 순위를 매기지 말고, 수치 하나만 보고 설정을 계속 바꾸지도 마세요.
연결 문제 진단 →링크 상태부터 업데이트 경로까지 확인하기
구독 목록이 비어 있는 문제와 이미 가져온 노드로 연결되지 않는 문제는 발생 단계가 다릅니다. 먼저 링크가 만료되지 않았는지, 전체 내용을 빠짐없이 복사했는지 확인한 다음 클라이언트가 요청 실패와 콘텐츠 파싱 실패 중 어떤 메시지를 표시하는지 살펴보세요. 현재 네트워크에서 구독 주소에 접속할 수 없다면, 이미 사용할 수 있는 연결이 있을 때 프록시를 통해 업데이트해 볼 수 있습니다. 요청은 성공했지만 구성이 생성되지 않는다면 응답 내용과 형식 지원 여부를 확인하세요. 구독 링크에 접근 권한이 포함될 수 있으므로 문제 화면을 공유할 때 전체 주소를 가리고 공개 게시판에 붙여 넣지 마세요.
구독 실패 자가 진단 →프리셋으로 요청 경로부터 확인하세요
라우팅 규칙은 코어로 들어온 요청을 프록시로 보낼지, 직접 연결할지, 차단할지 결정합니다. 시스템 프록시가 담당하는 트래픽 처리와는 별개의 기능입니다. 처음에는 용도에 맞는 프리셋을 선택하고 자주 사용하는 사이트와 로컬 서비스가 정상적으로 연결되는지 확인한 뒤 사용자 지정 규칙을 추가하세요. 전역 모드는 보통 규칙에 해당하는 요청을 프록시 출구로 보내는 설정이지, 모든 앱이 클라이언트를 거친다는 뜻은 아닙니다. 분기 문제를 진단할 때는 먼저 앱의 요청이 코어에 들어오는지 확인하고, 그다음 어떤 규칙에 일치했는지 살펴보세요. 잘못된 단계에서 모드를 반복해서 바꾸지 않도록 주의하세요.
라우팅 설정 시작하기 →구체적인 규칙을 앞에, 기본 규칙을 뒤에
여러 라우팅 규칙이 같은 요청에 적용될 수 있다면 순서에 따라 결과가 달라집니다. 사용자 지정 도메인이나 주소 규칙을 추가하기 전에 현재 코어의 매칭 방식을 확인하고, 앞쪽의 포괄적인 규칙이 새 규칙을 먼저 처리하지 않는지 살펴보세요. 직접 연결이 필요한 로컬 리소스는 명시적으로 설정해야 하며, 전역 모드를 자주 바꿔 접속을 유지해서는 안 됩니다. 수정 전에 기존 설정을 저장하고 규칙을 조금씩 추가한 뒤 실제 요청으로 적용 결과를 확인하세요. 규칙이 많다고 분기가 정확해지는 것은 아니므로 사용하지 않는 중복 항목은 정리하는 것이 좋습니다.
라우팅 규칙 이해하기 →도메인 확인과 연결 경로를 함께 점검하세요
사이트가 열리지 않는다고 노드를 사용할 수 없는 것은 아닙니다. 도메인 확인 단계에서 문제가 생겼을 수도 있습니다. 도메인 규칙, 주소 규칙, 도메인 정책이 함께 매칭 결과에 영향을 주며, 주소만 있는 요청과 도메인 정보가 유지되는 요청은 서로 다르게 처리될 수 있습니다. 먼저 로그에서 이름 확인 오류를 찾고 DNS 요청이 도달 가능한 경로를 사용하는지 확인하세요. 시스템 DNS, 브라우저의 암호화 DNS, 클라이언트 DNS를 한꺼번에 바꾸면 어떤 변경이 효과가 있었는지 알기 어렵습니다. 복구 가능한 기본 설정을 유지하고 하나씩 확인하면 원인을 찾기 쉽습니다.
DNS 문제 해결 →LAN 및 로컬 서비스 연결 유지하기
프린터, 라우터 관리 페이지, LAN 파일 서비스는 보통 원격 프록시를 거칠 필요가 없습니다. 새 라우팅 규칙이나 TUN을 켠 뒤 해당 리소스에 접속할 수 없다면 주소가 로컬 네트워크에 속하는지 확인하고 직접 연결 및 제외 설정을 점검하세요. 기기 검색은 일반 웹 브라우징과 다른 종류의 트래픽을 사용할 수 있으므로 웹 페이지가 열린다고 LAN 기능 전체가 정상인 것은 아닙니다. 규칙을 수정할 때 주소 범위를 무작정 넓히지 마세요. 영향을 받는 대상을 기록하고 필요한 범위만 적용해 확인한 뒤 되돌릴 방법을 남겨 두세요.
네트워크 진단 보기 →먼저 코어를 실행한 뒤 앱에서 프록시를 사용하도록 설정하세요
시스템 프록시를 자동 설정하면 해당 설정을 지원하는 앱이 클라이언트의 로컬 수신 주소로 요청을 보냅니다. 유효한 구성을 선택하고 코어가 정상적으로 실행됐는지 확인한 다음 이 옵션을 켜세요. 브라우저에서 별도의 프록시 확장 프로그램을 사용한다면 시스템 설정을 덮어쓰는지 확인해야 합니다. 시스템 프록시를 해제해도 구독이나 노드는 삭제되지 않으며, 시스템 프록시 변경 안 함을 선택하면 기존 설정이 유지됩니다. 클라이언트를 종료한 뒤 네트워크에 문제가 생기면 이미 종료된 포트를 가리키는 프록시 설정이 남아 있는지 확인하세요.
시스템 프록시 설정 →시스템 프록시를 사용하지 않는 앱의 트래픽 처리
TUN은 가상 네트워크 인터페이스로 트래픽을 처리하므로 일반 시스템 프록시가 적용되지 않는 앱에 적합합니다. 다만 권한, 라우팅, DNS 등의 추가 설정이 필요합니다. 사용 전에 같은 노드가 일반 프록시 모드에서 작동하는지 확인하고 클라이언트 안내에 따라 필요한 권한을 허용하세요. 연결에 문제가 생기면 다른 VPN이나 유사한 트래픽 처리 도구를 잠시 끄고 비교해 보세요. TUN은 유효하지 않은 구독을 고치는 기능이 아니며 모든 트래픽이 예상대로 전달된다고 보장하지도 않습니다. 문제가 생기면 확인된 기본 모드로 먼저 되돌리세요.
TUN 문제 해결 →클라이언트와 앱에서 동일한 연결 매개변수 사용하기
로컬 수신 포트는 앱이 클라이언트에 접속하는 진입점이며 원격 서버의 포트가 아닙니다. 그림의 10808은 예시이므로 실제 값은 현재 매개변수 설정 화면에서 확인하세요. 포트를 다른 프로그램이 사용 중이라면 먼저 충돌한 프로세스를 찾고, 중복 실행을 종료할지 수신 포트를 변경할지 결정합니다. 변경한 뒤에는 시스템 프록시, 브라우저, 수동으로 설정한 앱도 함께 확인하고 프록시 프로토콜 유형이 올바른지 점검하세요. 숫자 한 곳만 바꾸고 끝내면 코어가 실행 중이어도 요청이 들어오지 않을 수 있습니다.
포트 충돌 해결 →VPN 인터페이스를 사용할 앱을 지정하세요
Android의 VPN 모드는 데스크톱 시스템 프록시와 작동 방식이 다르며, 처음 실행할 때 시스템 권한을 허용해야 합니다. 앱별 프록시로 트래픽 처리 범위를 좁힐 수 있지만, 현재 목록이 허용 앱인지 제외 앱인지 먼저 확인하세요. 선택 결과가 예상과 반대가 될 수 있습니다. 브라우저는 연결되지만 다른 앱이 연결되지 않으면 해당 앱이 처리 범위에 포함됐는지 확인한 다음 라우팅을 점검하세요. 화면을 잠근 뒤 연결이 끊긴다면 백그라운드 실행과 배터리 최적화 설정을 확인합니다. 테스트할 때는 트래픽을 처리하는 도구를 하나만 켜 두면 VPN 인터페이스 충돌 여부를 판단하기 쉽습니다.
모바일 설정 단계 보기 →클라이언트는 설정을 관리하고 코어는 연결을 처리합니다
클라이언트는 구독, 설정, 로그 화면을 제공하고 코어는 설정을 해석해 네트워크 연결을 만듭니다. 둘의 업데이트 주기와 기능 범위가 항상 같지는 않습니다. 따라서 화면에서 특정 필드를 가져올 수 있더라도 현재 코어가 해당 기능을 지원한다고 단정할 수 없습니다. 실행 오류가 발생하면 로그를 읽고 설정 생성이 실패했는지 코어가 매개변수를 거부했는지 확인하세요. 앱 이름만 보는 것보다 실제로 실행 중인 코어를 확인하는 편이 프로토콜 호환성 문제를 해결하는 데 도움이 되며, 화면 차이를 연결 방식의 차이로 오해하는 일도 줄어듭니다.
코어 용어 보기 →설정 요구 사항에 따라 호환 범위를 확인하세요
Xray와 V2Fly는 관련은 있지만 독립적으로 발전하는 코어 프로젝트입니다. 프로토콜 구현, 설정 필드, 신기능 지원 여부가 다를 수 있습니다. 코어를 선택할 때는 이름이나 출시 시점만으로 우열을 판단하지 말고 서버에서 요구하는 설정을 기준으로 삼으세요. 같은 구독에 서로 다른 요구 사항의 구성이 들어 있을 수도 있으므로 전환 전에 프로토콜과 전송 방식의 조합을 확인해야 합니다. 특정 구성이 특정 코어에서만 작동한다면 검증된 조합을 유지하고 차이를 따로 살펴보세요. 전송 옵션을 여러 개 한꺼번에 바꾸는 것보다 신뢰할 수 있는 결과를 얻기 쉽습니다.
클라이언트 비교 보기 →설정을 보존해 테스트를 되돌릴 수 있도록 하세요
코어를 전환하거나 클라이언트를 업그레이드하기 전에 구독 그룹, 사용자 지정 라우팅, 필요한 매개변수 설정을 저장하세요. 현재 작동하는 구성을 기록하되 공개 메모에 인증 정보를 남기지는 마세요. 업데이트 후 기존 구성으로 기본 연결을 확인하고 새 기능을 테스트하세요. 실행에 실패하면 설정을 전부 덮어쓰기보다 로그에서 오류가 난 필드를 비교하세요. 프로젝트가 발전하면서 설정 형식이 바뀔 수 있으므로 백업은 복구 기준을 남기는 용도입니다. 복원할 때도 대상 버전이 해당 설정을 올바르게 인식하는지 확인해야 합니다.
실행 문제 진단 →플랫폼을 먼저, 코어 요구 사항은 다음으로
데스크톱에서는 v2rayN을 우선 선택해 구독과 프록시 설정을 일관된 방식으로 관리하세요. Android에서는 v2rayNG를 권장하며 V2Fly 코어가 필요할 때 v2flyNG를 고려하면 됩니다. 클라이언트를 고를 때는 먼저 기기 플랫폼을 기준으로 하고, 다음으로 설정 요구 사항과 자주 쓰는 기능을 살펴보세요. 화면이 다르다는 이유만으로 자주 옮겨 다닐 필요는 없습니다. 이전할 때 유효한 구독은 다시 가져올 수 있지만 라우팅, 앱별 목록, 권한은 대개 다시 확인해야 합니다. 이런 기기별 설정은 노드 공유 링크에 모두 포함되지 않습니다.
용도에 맞는 클라이언트 선택 →오픈 소스 프로젝트, 연결 코어, 그래픽 클라이언트를 구분해 무엇을 다운로드하고 어디를 설정할지 확인하세요.
V2Ray는 Project V의 모듈형 네트워크 프록시 설계에서 시작했습니다. 인바운드, 아웃바운드, 라우팅, 전송을 분리해 구성하므로 각 요청을 규칙에 따라 서로 다른 출구로 보낼 수 있습니다. 오늘날 V2Ray를 검색하면 V2Fly, Xray, v2rayN, v2rayNG도 함께 접하게 됩니다. 각 이름은 서로 다른 계층을 가리키므로 같은 설치 패키지의 다른 이름으로 보면 안 됩니다. 각 구성 요소의 역할을 먼저 이해하면 문제가 생겼을 때 확인 범위를 올바른 곳으로 좁힐 수 있습니다.
일상적인 사용에서는 그래픽 클라이언트가 주된 조작 창구입니다. 구독은 연결 구성을 제공하고, 코어는 이를 읽어 연결을 수립합니다. 시스템 프록시나 VPN 인터페이스는 어떤 앱의 요청이 클라이언트로 들어올지 결정하고, 라우팅은 요청이 들어온 뒤의 경로를 정합니다. 네 단계는 서로 관련되어 있지만 서로를 대신할 수는 없습니다. 구독에 성공해도 연결된 것은 아니며, 연결에 성공해도 모든 앱이 프록시를 사용하는 것은 아닙니다. 이 순서대로 확인하면 구독을 반복해서 가져오거나 앱을 재설치하는 것보다 문제를 정확히 찾을 수 있습니다.
Project V는 모든 네트워크 동작을 하나의 스위치로 묶는 대신, 각 작업을 조합 가능한 모듈로 나누는 방식을 취합니다. 인바운드는 앱 요청을 받고, 아웃바운드는 목적지나 프록시 서버에 연결하며, 라우팅은 출구를 선택하고, 전송 계층은 연결을 어떤 방식으로 전달할지 정합니다. 클라이언트에 구독, 라우팅, DNS, 수신 포트 등 여러 설정 메뉴가 있는 이유도 이런 역할 분담에 있습니다. 메뉴 이름은 많지만 각 설정에는 적용 범위가 있습니다.
예를 들어 로컬 수신 포트를 바꾸면 앱이 클라이언트에 접속하는 위치가 달라집니다. 원격 서버 포트를 바꾸면 클라이언트가 서버에 접속하는 위치가 달라집니다. 둘 다 포트라고 부르지만 서로 대신할 수는 없습니다. 마찬가지로 전역 라우팅은 코어에 들어온 요청의 경로에 영향을 주지만 시스템 프록시를 무시하는 앱이 자동으로 프록시를 사용하게 만들지는 않습니다. 이런 경계를 이해하면 기본 설정으로 연결을 먼저 만든 다음 라우팅과 트래픽 처리 기능을 단계적으로 추가할 수 있습니다.
기술 자료를 찾을 때는 해당 자료가 어떤 클라이언트, 코어, 설정 계층을 다루는지 함께 확인하세요. 코어 설정 파일을 다루는 글이라고 해서 모든 필드를 그래픽 인터페이스의 입력란에 그대로 넣을 수 있는 것은 아닙니다. 먼저 개념을 파악한 뒤 현재 화면과 대조하면 서로 다른 프로젝트의 설명을 섞어 생기는 오류를 줄일 수 있습니다.
전문 용어 살펴보기 →V2Fly 커뮤니티는 V2Ray 관련 구현을 계속 유지 관리하고 있으며, Xray는 관련 코드 기반에서 출발해 독립적으로 발전하는 코어 프로젝트가 되었습니다. 두 프로젝트는 기술적 배경을 공유하지만 구현 방식과 기능 개발 주기는 서로 다릅니다. 사용자에게 중요한 것은 어느 쪽이 더 낫다고 순위를 매기는 일이 아니라 현재 노드에 필요한 프로토콜, 전송 방식, 보안 옵션을 실행 중인 코어가 지원하는지 확인하는 것입니다.
v2rayN은 버전과 구성에 따라 적합한 코어를 사용할 수 있습니다. Android의 v2rayNG는 주로 Xray 코어를 연결 기반으로 사용하고, v2flyNG는 V2Fly 코어를 선택할 수 있습니다. 코어 전환이 모든 문제를 해결하는 것은 아닙니다. 구독 링크 만료, 시스템 시간 오류, 로컬 포트 충돌이 원인이라면 코어를 바꿔도 같은 증상이 계속될 수 있습니다. 먼저 로그에서 문제가 발생한 단계를 확인한 다음 구현을 변경할지 결정하세요.
서버에서 제공한 매개변수를 호환성 확인의 기준으로 삼으세요. 오류 메시지를 없애려고 인증서 검증을 함부로 끄거나 인식하지 못하는 필드를 전부 지운 뒤 사용하지 마세요. 먼저 원래 구성을 보존하고 클라이언트와 코어가 서로 맞는지 확인하세요. 매개변수의 의미를 알기 어렵다면 관련 용어 설명과 문제 해결 안내를 살펴보세요.
증상별 문제 진단 →v2rayN, v2rayNG, v2flyNG는 모두 오픈 소스 그래픽 클라이언트이며 앱 자체는 무료로 사용할 수 있습니다. 오픈 소스란 프로젝트 코드와 해당 라이선스를 확인할 수 있다는 뜻이지, 원격 서버, 구독 용량, 연결 구성이 자동으로 제공된다는 뜻은 아닙니다. 앱을 설치한 뒤 실제로 연결하려면 접근 권한이 있는 구독을 사용하거나 직접 관리하는 서버 구성을 준비해야 합니다.
오픈 소스 생태계의 모든 구성 요소가 같은 라이선스를 사용하는 것은 아닙니다. v2rayN, v2rayNG, v2flyNG 프로젝트는 GPL-3.0을, V2Fly와 Xray 관련 코어 프로젝트는 MPL-2.0을 사용합니다. 배포 패키지에 포함된 다른 구성 요소에는 별도의 라이선스가 적용될 수도 있습니다. 일반적인 사용과 수정·재배포에는 서로 다른 의무가 따르므로, 코드를 수정하거나 다시 배포할 계획이라면 해당 프로젝트와 구성 요소의 라이선스 전문을 확인하세요.
설정 관리와 네트워크 서비스도 구분해서 봐야 합니다. 클라이언트에서 구독을 저장하고 파싱할 수 있어도 구독의 유효성을 결정할 수는 없으며 서버 운영을 대신하지도 않습니다. 연결 문제가 발생하면 앱 설정, 구성 내용, 원격 서버 상태 중 어느 쪽이 원인인지 먼저 확인한 뒤 적절한 방법으로 대응하세요. 기존 설정을 보존하면서 구성 제공자에게 실제 증상을 명확하게 설명하는 데도 도움이 됩니다.
세 클라이언트 비교하기 →앱 업데이트는 화면과 설정 관리 방식을 바꿀 수 있고, 코어 업데이트는 프로토콜 기능과 매개변수 지원에 영향을 줄 수 있습니다. 구독 업데이트는 주로 연결 구성을 새로 고칩니다. 세 가지 업데이트는 목적이 다르므로 문제를 진단하는 동안 한꺼번에 실행하지 않는 것이 좋습니다. 원래 연결되던 상태에서 문제가 생겼다면 장애 전에 바꾼 내용을 기록하고 한 단계씩 확인해야 업데이트가 원인이었는지 판단할 수 있습니다.
업그레이드 전에 구독 그룹과 사용자 지정 라우팅을 저장하고 설치 파일이 현재 운영체제와 프로세서 아키텍처에 맞는지 확인하세요. 업그레이드 후에는 기존 구성으로 기본 연결을 먼저 테스트한 다음 시스템 프록시와 필요한 앱을 확인합니다. TUN이나 앱별 프록시 같은 추가 설정은 기본 연결을 확인한 뒤 적용하세요. 새 기능만 문제를 일으킨다면 검증된 모드로 되돌린 다음 로그를 확인해 권한이나 호환성 문제를 점검하세요.
로그는 실패 단계를 찾는 데 유용하지만 서버 주소, 구독 링크, 기타 민감한 매개변수가 포함될 수 있습니다. 문제를 공유할 때는 필요한 오류 정보만 남기고 인증 정보를 가리세요. 기기 플랫폼, 실행 모드, 영향을 받는 앱도 함께 설명하세요. 처리하지 않은 설정 화면을 통째로 공유하는 것보다 재현 단계를 명확히 적는 편이 도움이 되며, 논의 중 접근 정보가 유출되는 일도 막을 수 있습니다.
자주 묻는 질문 보기 →처음 설정할 때는 확인 경로를 단순하게 유지하세요. 구독을 가져오고 구성을 하나 선택한 뒤 코어가 실행되는지 확인합니다. 그런 다음 시스템 프록시나 모바일 VPN 모드를 켜고 대상 앱을 테스트하세요. 기본 연결이 정상일 때만 라우팅 규칙, 앱별 목록, TUN 설정을 추가합니다. 각 단계는 개별적으로 되돌릴 수 있어야 이후 문제가 생겨도 확인을 시작할 지점을 찾기 쉽습니다.
브라우저는 되지만 다른 앱에서 실패한다면 모든 노드를 즉시 업데이트하지 말고 먼저 해당 앱의 프록시 진입점을 확인하세요. 모든 구성이 동시에 시간 초과되면 로컬 네트워크와 코어 상태를 먼저 점검하고, 구독 업데이트 결과만 비어 있다면 링크 형식과 요청 방식을 다시 확인하세요. 증상별 안내는 문제 해결에서 순서대로 살펴보거나 빠른 시작에서 기본 사용법을 다시 확인할 수 있습니다.
포트 충돌, 인증서 오류, 구독 파싱 실패 등 구체적인 증상부터 확인하세요.
클라이언트 실행 시 포트 충돌이 발생하거나 시스템 프록시가 작동하지 않을 때 시스템 명령으로 10808 및 10809을 사용하는 프로세스를 찾고, 매개변수 설정에서 로컬 수신 포트를 바꾼 뒤 브라우저와 시스템 프록시도 함께 조정하는 방법을 안내합니다.
포트 문제 해결 가이드 →인증서 무효, 핸드셰이크 실패, x509 오류가 발생하면 먼저 시스템 시간을 맞춘 뒤 SNI, 위장 도메인, allowInsecure 설정을 확인하세요. 각 오류의 원리와 해결 방법을 설명합니다.
인증서 문제 해결 가이드 →구독을 가져온 뒤 목록이 비거나 파싱 실패 메시지가 표시되거나 업데이트가 계속 실패할 때, 링크 만료 여부와 Base64 인코딩, 공유 링크 형식, 프록시를 통한 구독 업데이트까지 단계별로 확인하는 방법을 안내합니다.
구독 문제 자가 진단 →