전체 플랫폼 설치 및 설정

준비 사항과 설정 범위

클라이언트, 코어, 연결 설정 구분하기

v2rayN은 연결 설정을 저장하고 코어를 실행하며 프록시 관련 설정을 조정하는 데스크톱 GUI 클라이언트입니다. 프로토콜을 처리하고 원격 서버에 연결하며 라우팅 규칙을 적용하는 것은 코어입니다. Project V는 관련 기술 생태계의 배경이며, V2Fly와 Xray는 서로 다른 코어 개발 계열입니다. 인터페이스가 열렸다고 코어가 실행 중인 것은 아니며, 코어가 정상적으로 실행되어도 시스템 앱이 요청을 코어로 전달한다는 뜻은 아닙니다. 이 세 가지를 각각 확인해야 합니다.

데스크톱에서는 이 가이드에 따라 v2rayN을 사용하는 것이 좋습니다. Android에서는 Xray 코어를 사용하는 v2rayNG를 먼저 선택하세요. 기존 설정에서 V2Fly 호환 동작이 명시적으로 필요한 경우에만 v2flyNG를 고려하면 됩니다. 이름이 비슷하다는 이유로 설정 파일을 서로 바꿔 사용하지 마세요. 프로토콜 지원, 전송 매개변수와 확장 필드는 클라이언트와 실제 코어의 조합에 따라 달라지므로, 서비스 제공업체의 호환성 안내가 현재 선택한 조합과 맞는지 확인해야 합니다.

아키텍처, 권한, 네트워크 환경 확인하기

다운로드하기 전에 운영체제 이름만 보지 말고 기기의 프로세서 아키텍처를 확인하세요. 일반적인 데스크톱 프로세서는 x64를 사용하고 일부 기기는 arm64를 사용합니다. macOS에서는 Apple Silicon과 Intel도 구분해야 합니다. Android 역시 프로세서, 운영체제 비트 수, 설치 가능한 앱 아키텍처가 서로 다를 수 있습니다. 패키지 형식도 중요합니다. 설치 프로그램, 디스크 이미지, 배포판 패키지는 각각 설치 절차가 다르므로 파일 확장자를 바꿔 서로 변환할 수 없습니다.

사용 권한이 있고 유효 기간이 남아 있는 구독 주소나 완전한 단일 연결 설정을 준비하세요. 클라이언트에는 사용할 수 있는 원격 서비스가 포함되어 있지 않습니다. 연결에 필요한 정보에는 보통 서버 주소, 포트, 인증 정보, 프로토콜 및 전송 설정이 포함됩니다. TLS 또는 REALITY를 사용하는 경우 서버 이름이나 공개 키 같은 필드가 추가될 수 있습니다. 정보가 부족하면 설정 제공업체에 문의하고, 추측한 값으로 채우지 마세요.

먼저 기기 자체가 정상적으로 인터넷에 연결되는지 확인하고 날짜, 시간, 시간대가 올바른지 살펴보세요. 시간이 크게 어긋나면 인증서 유효성 판단에 영향을 주거나 일부 프로토콜 인증이 실패할 수 있습니다. 브라우저에서 일반 웹페이지가 열리는지 확인한 다음, 회사 네트워크 인증 페이지, 시스템 프록시, 실행 중인 다른 터널 도구 또는 보안 소프트웨어 규칙이 있는지 살펴보세요. 기본 네트워크 연결이 되지 않을 때 구독을 반복해서 업데이트해도 대개 해결되지 않습니다.

시스템 프록시와 TUN의 차이 이해하기

시스템 프록시는 운영체제의 프록시 설정을 통해 해당 설정을 따르는 앱이 로컬 수신 포트에 연결하도록 합니다. 모든 앱의 트래픽이 전달되는 것은 아닙니다. 일부 프로그램은 자체 프록시 설정을 사용하고, 다른 프로그램은 시스템 프록시를 무시합니다. TUN은 가상 네트워크 인터페이스를 통해 조건에 맞는 트래픽을 처리하므로 적용 범위가 더 넓지만, 라우팅 규칙, DNS, 권한과 관련한 변수가 늘어납니다. 일반 프록시 연결이 정상임을 확인한 뒤 사용하는 것이 좋습니다.

같은 기기에서 사용하는 경우와 LAN 공유는 서로 다른 상황입니다. 기기 자체에서 연결할 때는 보통 루프백 주소에만 바인딩하면 됩니다. LAN 연결을 허용하면 다른 기기에서도 수신 포트에 접근할 수 있으므로 방화벽, 바인딩 주소와 접근 범위를 함께 고려해야 합니다. 처음 설치할 때는 LAN 공유를 끄고, 문제 해결을 위해 모든 네트워크 접근을 허용하지 마세요. 공유가 꼭 필요하다면 LAN 프록시 공유 안내를 참고하세요.

되돌릴 수 있는 순서로 작업하기

설치하거나 설정을 이전하기 전에 클라이언트를 완전히 종료하고 설정 디렉터리를 백업하세요. 백업에는 구독 주소, 인증 정보와 사용 기록이 포함될 수 있으므로 안전한 위치에 보관해야 합니다. 변경 전 시스템 프록시 상태, 수신 포트, 라우팅 규칙을 기록해 두세요. 스크린샷을 공유할 때는 전체 구독 링크, 서버 인증 정보와 QR 코드를 가리세요. 이런 정보가 복사되면 다른 사람이 같은 서비스 설정을 사용할 수 있습니다.

설치, 가져오기, 실행, 명시적 프록시 테스트, 시스템 프록시 테스트, TUN 테스트 순서로 진행하는 것이 좋습니다. 한 번에 주요 변수 하나만 바꾸고 변경 전후의 상태를 기록하세요. 업데이트 후 문제가 생기면 백업과 로그를 먼저 비교하고, 모든 설정을 한꺼번에 알 수 없는 상태로 되돌리지 마세요. 롤백하려면 새 클라이언트를 종료한 다음 해당 설정과 맞는 백업을 복원해 두 프로세스가 같은 디렉터리를 동시에 수정하지 않도록 합니다.

Windows 설치 및 프록시 설정

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

Windows 다운로드에서 v2rayN 데스크톱 버전과 클래식 WPF 버전을 먼저 구분하세요. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하고, WPF 버전은 기존 데스크톱 환경의 사용 방식을 유지합니다. 두 버전은 연결 프로토콜의 등급 차이가 아니며, 외관만으로 성능을 판단해서도 안 됩니다. 기기와 운영체제, 사용 습관, 필요한 기능에 맞춰 선택하면 됩니다. 설정을 완료하기 위해 두 인터페이스를 모두 설치할 필요는 없습니다.

다운로드 페이지의 Windows 기본 다운로드는 x64용입니다. 다른 아키텍처의 기기라면 먼저 시스템 호환성을 확인하고 x64 파일을 arm64용 패키지로 착각하지 마세요. 설치할 때는 설치 프로그램의 안내에 따라 설치 위치와 필요한 구성 요소를 설정합니다. 시스템에서 실행 환경이 없다고 알리면 오류 내용에 맞는 구성 요소를 설치하세요. 출처가 불분명한 동적 라이브러리를 복사해서는 안 됩니다. 설치는 완료되지만 실행되지 않는 경우에도 원래 오류 메시지를 보관하세요.

처음 실행할 때 설정 디렉터리를 읽기 전용 위치에 두거나 동기화 프로그램이 동시에 수정하도록 하지 마세요. 설치 디렉터리와 사용자 설정 디렉터리는 다를 수 있으므로 클라이언트의 디렉터리 메뉴나 로그에서 실제 경로를 확인하세요. 일반적인 시스템 프록시 사용에는 지속적인 관리자 권한이 필요하지 않습니다. 가상 인터페이스, 드라이버 또는 권한이 필요한 작업에 대해서만 안내에 따라 권한을 부여하고, 권한 상승을 일반적인 해결책으로 사용하지 마세요.

구독을 가져오고 코어 실행 확인하기

구독 그룹 설정을 열어 용도를 알아보기 쉬운 이름을 만들고, 구독 주소를 주소 입력란에 빠짐없이 붙여 넣은 다음 저장하고 업데이트하세요. 업데이트가 완료되면 목록에서 사용할 연결 설정을 선택합니다. 가져오기는 연결 정보를 기기에 저장하는 작업일 뿐, 원격 서버를 사용할 수 있다는 보장은 아닙니다. 업데이트 후 목록이 비어 있다면 먼저 업데이트 결과를 확인하고, 주소가 계정 로그인 페이지가 아닌 연결 설정을 실제로 반환하는지 살펴보세요.

연결 설정을 선택한 뒤 코어를 실행하거나 다시 불러오고, 로그에 실행 실패, 포트 사용 중 또는 지원되지 않는 필드 오류가 있는지 확인하세요. 특정 설정에서 Xray 확장 기능을 사용한다면 선택한 코어가 해당 매개변수를 처리할 수 있어야 합니다. 별도의 안내가 없다면 코어 설정을 모두 바꾸지 마세요. 그룹이 여러 개라면 활성 설정이 방금 업데이트한 그룹에 속하는지 확인해야 합니다. 그래야 이전 설정의 연결 상태를 새 구독의 상태로 착각하지 않습니다.

먼저 로컬 프록시를 테스트한 뒤 시스템 프록시 설정하기

설정에서 로컬 수신 포트를 확인하세요. 흔히 10808을 사용하지만 실제 값은 기기의 인터페이스에서 확인해야 합니다. 이 포트는 컴퓨터의 수신 포트이지 서버 포트가 아닙니다. 수신 유형을 확인한 다음 수동 프록시를 지원하는 앱에서 루프백 주소와 해당 포트를 직접 지정해 테스트할 수 있습니다. 명시적 프록시 테스트가 성공하면 시스템 프록시를 자동 설정으로 지정하고 브라우저가 새 설정을 사용하는지 확인하세요.

브라우저 정책, 확장 프로그램, 앱 자체 설정도 시스템 프록시 적용에 영향을 줍니다. 한 브라우저는 정상인데 다른 앱에서 실패한다면 원격 설정을 바꾸기 전에 해당 앱이 시스템 프록시를 지원하는지 확인하세요. 터미널 도구에 별도의 프록시 설정이 필요하면 해당 프로세스에만 적용하고, 사용 후에는 해제하세요. 시스템 프록시와 터미널 환경 변수는 별개의 설정이므로 한쪽을 바꿔도 다른 쪽은 바뀌지 않을 수 있습니다.

TUN 사용 및 Windows 특유 문제 해결

시스템 프록시를 따르지 않는 앱의 트래픽도 처리해야 한다면 TUN을 사용해 보세요. 현재 클라이언트의 안내에 따라 필요한 권한을 부여한 뒤 가상 인터페이스, 기본 경로와 DNS에 문제가 없는지 확인합니다. 처음 테스트할 때는 단순한 라우팅 규칙을 유지하고 다른 가상 네트워크 도구는 잠시 종료하세요. TUN을 켠 뒤 정상적으로 직접 연결되던 네트워크까지 끊기면 먼저 TUN을 끄고 네트워크를 복구한 다음 로그와 인터페이스 상태를 확인하세요. 인증서, 구독, 방화벽을 동시에 수정하지 마세요.

Windows 방화벽 알림에서는 외부로 나가는 연결과 다른 기기가 로컬 서비스에 접근하도록 허용하는 것을 구분해야 합니다. 기기에서만 프록시를 쓴다면 알림을 없애려고 모든 네트워크의 인바운드 접근을 허용할 필요가 없습니다. 포트가 사용 중이라면 v2rayN 인스턴스가 중복 실행 중인지 확인하고, 시스템 트레이에 이전 프로세스가 남아 있는지 살펴보세요. 포트를 바꾼 경우 프록시 주소를 직접 입력한 모든 앱도 함께 수정해야 이전 포트에 계속 연결되지 않습니다.

종료하기 전에 시스템 프록시를 해제하고 클라이언트를 정상적으로 닫으세요. 프로그램이 비정상 종료된 뒤 브라우저에서 인터넷이 되지 않는다면 시스템 프록시 설정이 중지된 로컬 포트를 가리키는지 확인합니다. 자동 실행은 수동 실행이 안정된 뒤 설정하고, 다시 로그인했을 때 인스턴스가 하나만 실행되는지 확인하세요. 절전 모드에서 깨어난 뒤 연결되지 않으면 먼저 기본 네트워크가 복구됐는지 확인한 다음 코어를 다시 불러오세요. 네트워크 연결이 완료되기 전 상태를 설정 손상으로 오해하지 않도록 합니다.

업데이트 전에 필요한 설정을 내보내고 설정 디렉터리를 백업하세요. 설치가 끝나면 수신 포트, 활성 설정과 라우팅 규칙을 먼저 비교합니다. 인터페이스 간에 설정을 이전할 때 모든 창의 옵션이 일대일로 대응하지 않을 수 있습니다. 먼저 연결에 필요한 데이터를 복원하고 플랫폼 설정을 다시 확인하세요. 기본 절차는 사용 가이드의 프록시 설정 단계를 참고하고, 이전 과정에서 새 라우팅 규칙을 한꺼번에 추가하지 마세요.

macOS 설치 및 권한 설정

칩에 맞는 설치 패키지 선택하기

시스템의 ‘이 Mac에 관하여’에서 칩 또는 프로세서를 확인하세요. Apple Silicon 기기는 arm64, Intel 기기는 x64를 선택한 다음 macOS 다운로드에서 v2rayN을 받습니다. 컴퓨터를 구입한 연도만으로 아키텍처를 판단하지 마세요. 같은 해에도 서로 다른 칩을 탑재한 모델이 있을 수 있습니다. 아키텍처가 맞지 않으면 앱이 열리지 않거나 변환 실행 환경이 필요하고 호환성 문제가 생길 수 있으므로 기기에 맞는 패키지를 선택하세요.

디스크 이미지를 연 뒤 패키지에 포함된 설치 안내에 따라 앱을 응용 프로그램 폴더로 복사하고, 해당 위치에서 실행하세요. 디스크 이미지에서 계속 실행하지 마세요. 이미지를 추출하거나 경로가 바뀌거나 로그인 후 이미지가 마운트되지 않으면 이후 실행에 문제가 생길 수 있습니다. 설정 파일을 응용 프로그램 패키지 내부에 직접 넣어서도 안 됩니다. 앱 업데이트 과정에서 패키지 내용이 교체될 수 있으므로 사용자 데이터는 클라이언트가 실제로 사용하는 설정 위치에 저장해야 합니다.

시스템 보안 경고가 나타나면 먼저 파일 출처와 경고 유형을 확인한 뒤, 시스템의 보안 및 개인정보 보호 절차에 따라 권한을 부여하세요. 앱 손상 판정, 아키텍처 비호환, 출처 확인은 서로 다른 문제이므로 해결 방법도 다릅니다. 처음부터 시스템 보안 기능을 전역으로 끄거나 출처가 불분명한 터미널 명령을 그대로 복사해 속성을 삭제하지 마세요. 원인을 판단하기 어렵다면 전체 경고 내용을 보관하고 다운로드 페이지로 돌아가 선택한 파일을 다시 확인하세요.

설정 가져오기와 프록시 연결 확인

실행한 뒤 먼저 구독 그룹을 만들고 주소를 저장한 다음 업데이트하세요. 메모 앱이나 메신저에서 내용을 복사했다면 전각 문자, 줄 바꿈, 끝부분의 공백이 들어가지 않았는지 확인합니다. 업데이트에 성공하면 사용할 설정을 선택하고 코어를 실행한 뒤 로그를 확인하세요. macOS의 인터페이스 이름은 Windows와 다를 수 있으므로 버튼 위치를 똑같이 찾으려 하지 말고 설정의 의미를 기준으로 살펴보세요. 서버 매개변수와 로컬 수신 매개변수는 별도로 확인해야 합니다.

수동 프록시를 지원하는 앱에서 루프백 주소와 수신 포트를 먼저 테스트하세요. 코어가 정상적으로 작동하는 것을 확인한 뒤 시스템 프록시를 사용합니다. macOS의 프록시 설정은 네트워크 서비스별로 관리되므로 Wi-Fi, 유선 네트워크와 다른 네트워크 서비스의 상태가 다를 수 있습니다. 네트워크를 바꾼 뒤 특정 앱이 프록시를 사용하지 않는다면 클라이언트에 마지막으로 표시된 스위치 상태만 보지 말고 현재 서비스의 프록시 항목을 확인하세요.

일부 앱은 시작할 때 프록시 설정을 읽기 때문에 시스템 프록시를 변경한 뒤 앱을 다시 열어야 할 수 있습니다. 자체 네트워크 설정을 사용하는 앱도 있으므로 브라우저 연결이 된다고 다른 앱도 반드시 프록시를 사용하는 것은 아닙니다. 테스트할 때는 같은 대상과 같은 프록시 적용 방식을 사용하고, 브라우저 캐시, 기존 연결과 새 연결을 섞지 마세요. 필요하다면 기존 창을 닫고 다시 테스트해 현재 설정에 따른 결과를 확인하세요.

TUN 권한 및 네트워크 전환

TUN은 가상 네트워크 인터페이스와 시스템 라우팅 규칙을 사용하며, 구체적인 권한 부여 방식은 현재 클라이언트 구현에 따라 다릅니다. 앱에서 명시적으로 요청할 때만 필요한 권한을 부여하고, 권한 부여 후 코어가 실제로 실행되는지 확인하세요. 인터페이스에서 스위치가 켜져 있어도 시스템에 유효한 인터페이스가 만들어졌다는 뜻은 아닙니다. 권한 부족, 인터페이스 생성 실패, 경로 추가 실패 메시지가 나오면 로그를 따라 하나씩 해결하세요. 스위치를 반복해서 눌러 저절로 복구되기를 기대하지 마세요.

회사 네트워크 도구, 가상 머신 브리지 네트워크, 다른 터널 서비스를 함께 사용하면 라우팅 규칙과 DNS 설정이 충돌할 수 있습니다. 먼저 v2rayN만 실행한 상태에서 기본 동작을 확인한 다음 다른 도구를 하나씩 다시 켜세요. 함께 사용해야 한다면 어떤 주소를 직접 연결하고 어떤 주소를 다른 네트워크가 처리하는지 명확히 정해야 합니다. 웹페이지를 잠시 열기 위해 알 수 없는 시스템 경로를 삭제하지 마세요. 원격 접근이나 회사 네트워크 리소스에 영향을 줄 수 있습니다.

절전 모드에서 복귀하거나 유선에서 무선으로 전환하거나 웹 인증이 필요한 네트워크에 연결하면 기존 연결이 끊길 수 있습니다. 먼저 프록시 적용을 해제하고 기본 네트워크 인증을 완료한 다음 코어를 실행하고 프록시를 다시 설정하세요. 깨어날 때마다 연결에 실패한다면 실패 시 일반 웹페이지에 직접 접근할 수 있는지, 로컬 수신 포트가 열려 있는지, 로그에 원격 재연결이 표시되는지 기록하세요. 이런 정보는 단순히 ‘네트워크가 멈췄다’고 설명하는 것보다 문제 범위를 구분하는 데 도움이 됩니다.

종료, 업데이트 및 설정 이전

정상 종료 전에 시스템 프록시와 TUN을 끄고 시스템 네트워크 설정이 복원됐는지 확인하세요. 프로세스를 강제 종료하면 로컬 포트를 가리키는 프록시 설정이 남을 수 있습니다. 이 경우 앱은 더 이상 수신하지 않아 브라우저 연결이 계속 실패합니다. 네트워크를 복구할 때는 현재 네트워크 서비스의 프록시 항목을 확인하고 이번 클라이언트와 관련된 설정만 지우세요. 조직에서 관리하는 기기라면 관리자가 미리 설정한 프록시를 덮어쓰지 마세요.

다른 컴퓨터로 옮길 때는 먼저 구독과 필요한 설정을 백업한 뒤 새 칩에 맞는 프로그램을 설치하세요. 연결 설정은 이전할 수 있지만 원래 기기의 경로, 로그인 시 실행 항목, 네트워크 권한까지 그대로 복사할 수는 없습니다. 이전 후 수신 주소, 시스템 프록시와 TUN을 다시 확인하고 정상 작동을 확인한 뒤 이전 백업을 삭제하세요. 인증 정보가 포함된 백업을 공용 공유 디렉터리에 오래 보관하지 말고 가져오기를 마친 뒤 적절히 관리하세요.

Linux 설치 및 데스크톱 환경

배포판 패키지 형식과 프로세서 아키텍처 구분하기

Linux 다운로드에서 배포판에 맞는 deb 또는 rpm 패키지를 고른 뒤 프로세서 아키텍처를 확인하세요. Debian, Ubuntu 등은 보통 deb를 사용하고 Fedora 등은 보통 rpm을 사용합니다. 파생 배포판은 해당 배포판의 패키지 관리 안내를 따르세요. x64와 arm64는 아키텍처 차이이지 패키지 형식 차이가 아닙니다. 같은 패키지 형식이라도 아키텍처별 파일이 제공될 수 있으며, 파일을 다운로드할 수 있다고 시스템에 설치할 수 있는 것은 아닙니다.

시스템 설정에서 운영체제와 프로세서 정보를 확인할 수 있습니다. 터미널 사용에 익숙하다면 아래 읽기 전용 명령으로 확인해도 됩니다. 일반적으로 x86_64는 x64, aarch64는 arm64에 해당합니다. 설치 방법은 배포판 정보를 기준으로 선택하고 데스크톱 화면만 보고 판단하지 마세요. 비슷한 그래픽 인터페이스를 사용하는 시스템도 패키지 관리 도구와 의존성 구성은 다를 수 있습니다.

uname -m
cat /etc/os-release

배포판의 그래픽 패키지 설치 프로그램으로 다운로드한 패키지를 열고 의존성과 권한 안내를 확인하세요. 설치에 실패하면 아키텍처 불일치, 의존성 누락, 패키지 관리자가 데이터베이스를 사용 중인 상황을 구분합니다. 의존성을 무시하고 강제로 설치하거나 다른 업데이트 작업이 끝나기 전에 패키지 관리 잠금 파일을 삭제하지 마세요. 앱 디렉터리를 반복해서 덮어쓰기보다 시스템 패키지 상태를 먼저 해결한 뒤 다시 설치하는 편이 안전합니다.

일반 사용자로 실행하고 설정 디렉터리 확인하기

설치가 완료되면 앱 메뉴에서 일반 사용자 계정으로 v2rayN을 실행하세요. 편의를 위해 그래픽 클라이언트를 계속 높은 권한으로 실행하지 마세요. 다른 사용자 소유의 설정 파일이 만들어져 다음 일반 실행 때 쓸 수 없게 될 수 있습니다. 저장에 실패한다면 실제 설정 경로와 파일 소유자를 먼저 확인하세요. 앱에서 설정 디렉터리를 표시하면 해당 경로를 기준으로 하며, 모든 배포판이 같은 위치에 사용자 데이터를 저장한다고 가정하지 마세요.

구독 그룹을 만들고 구독을 업데이트한 다음 사용할 설정을 선택하고 코어를 실행하세요. 로그에 실행 권한, 포트 사용 중 또는 코어 파일 누락 메시지가 있는지 확인합니다. 패키지가 제대로 설치되어도 프로그램에서 코어를 실행할 수 없다면 보안 정책, 마운트 옵션, 파일 권한을 확인해야 합니다. 사용자 디렉터리 전체의 권한을 재귀적으로 완화하지 마세요. 먼저 오류가 발생한 파일을 찾아 배포판의 권한 규칙에 따라 처리하세요.

시스템 프록시가 모든 프로그램에 공통으로 적용되지는 않습니다

Linux의 시스템 프록시는 데스크톱 환경, 앱 툴킷, 프로그램 자체 구현에 따라 다르게 적용됩니다. 데스크톱 설정에서 프록시를 켜면 일부 브라우저는 사용할 수 있지만 터미널 프로그램은 직접 연결을 유지할 수 있습니다. 이는 설정 경로가 다른 것이며 반드시 클라이언트 문제는 아닙니다. 먼저 프록시를 직접 지정할 수 있는 앱에서 로컬 수신을 테스트해 코어 연결을 확인한 다음, 현재 세션에서 사용하는 위치에 데스크톱 시스템 프록시가 기록됐는지 살펴보세요.

그래픽 앱, 터미널 환경 변수, 백그라운드 서비스는 일반적으로 프록시 설정을 자동으로 공유하지 않습니다. 터미널에서 변수를 설정해도 데스크톱 세션 전체 설정이 바뀌지는 않으며, 백그라운드 서비스에는 별도의 실행 환경이 있을 수 있습니다. 문제를 해결할 때는 어떤 프로그램이 요청을 보냈고 프록시 설정을 어디서 읽는지 기록하세요. 특히 수신 포트를 바꾸거나 클라이언트를 제거한 뒤 서로 충돌하는 프록시 주소가 여러 곳에 남아 있지 않도록 합니다.

앱에서 SOCKS 프록시를 직접 설정해야 한다면 해당 앱이 도메인 이름을 어떻게 해석하는지 확인하세요. 일부 구현은 먼저 로컬에서 도메인을 해석한 뒤 주소를 프록시에 전달하고, 다른 구현은 도메인 해석을 프록시에 맡깁니다. 이에 따라 DNS 동작도 달라집니다. ‘SOCKS’라는 표시만 보고 해석 경로까지 같다고 판단하지 말고 앱 옵션, 클라이언트 로그와 실제 테스트 결과를 함께 확인하세요.

TUN, 권한 작업 및 네트워크 관리 서비스

TUN은 보통 장치 접근 및 네트워크 관리 권한이 필요하며, 클라이언트는 권한 요청이나 보조 기능을 통해 관련 작업을 수행할 수 있습니다. 먼저 오류 내용을 확인한 뒤 현재 앱의 권한 절차에 따라 권한을 부여하세요. 프로그램 디렉터리 전체에 광범위한 기능을 임의로 추가하지 마세요. 시스템에서 사용하는 네트워크 관리 및 DNS 해석 서비스는 배포판마다 다를 수 있으므로 라우팅 규칙과 DNS 설정 방식도 다릅니다. 배포판을 가리지 않고 같은 해결 명령을 사용하면 기존 네트워크 설정을 덮어쓸 수 있습니다.

TUN을 켠 뒤 도메인 이름이 해석되지 않으면 먼저 TUN을 끄고 정상화되는지 확인한 다음 시스템 DNS 해석기 상태, 클라이언트 DNS 설정, 기존 가상 인터페이스를 살펴보세요. LAN 주소에도 접근할 수 없다면 사설 IP 경로와 인터페이스 우선순위를 중점적으로 확인합니다. 가상 머신, 컨테이너, 회사 터널이 추가 네트워크 대역을 사용할 수 있으므로 모든 로컬 네트워크가 가정용 라우터의 한 대역만 사용한다고 가정하지 마세요.

자동 실행을 설정하기 전에 데스크톱에 로그인한 뒤 수동 실행이 안정적인지 확인하세요. 사용자 세션 시작과 시스템 시작 서비스는 권한, 환경 변수, 설정 경로가 다르므로 그래픽 클라이언트를 백그라운드 데몬과 동일하게 취급할 수 없습니다. 종료하거나 제거하기 전에 시스템 프록시를 복원하고 TUN을 끈 다음 네트워크가 정상인지 확인하세요. 설정을 이전해야 한다면 프로세스를 중지하고 파일 소유권을 유지한 뒤 새 시스템에서 경로와 권한을 다시 확인하세요.

업데이트 후 시스템 트레이 아이콘만 사라지고 창과 코어는 계속 작동한다면 구독을 모두 다시 가져오기 전에 데스크톱 환경이 트레이를 지원하는지 확인하세요. 창이 표시되지 않는다면 그래픽 세션과 실행 오류를 살펴보세요. 인터페이스, 코어, 네트워크 문제를 나눠 기록하면 불필요한 변경을 줄일 수 있습니다. 관련 라우팅 데이터 관리 방법은 규칙 파일 업데이트 가이드에서 확인할 수 있습니다.

Android 설치 및 백그라운드 실행

v2rayNG 또는 v2flyNG 선택하기

Android 다운로드에서 우선 v2rayNG를 선택하세요. V2Fly 코어와의 호환 동작이 필요한 경우에는 v2flyNG를 사용하면 됩니다. 두 앱은 별개이므로 구독, 활성 설정, 백그라운드 설정을 각각 확인해야 하며 자동으로 공유된다고 가정해서는 안 됩니다. 여러 클라이언트를 비교하기 위해 설치한 경우 VPN 서비스는 한 번에 하나만 실행하세요. 그래야 시스템이 다른 앱을 중지한 상황을 연결 문제로 오해하지 않습니다.

대부분의 최신 휴대전화에서는 arm64를 우선 고려할 수 있지만, 최종적으로는 시스템이 지원하는 앱 아키텍처를 확인해야 합니다. 아키텍처를 알 수 없거나 관련 설치 오류가 발생하면 기기 정보를 확인하고 범용 버전을 고려하세요. 범용 버전에는 여러 아키텍처에 대응하는 내용이 포함되어 있지만 원격 연결 기능이 더 뛰어나다는 뜻은 아닙니다. TV, 에뮬레이터 환경, 구형 기기는 특히 별도로 확인하고 프로세서의 홍보 명칭만으로 시스템 비트 수를 판단하지 마세요.

설치할 때 파일 관리자나 브라우저가 설치를 시작했다면 시스템에서 해당 출처의 앱 설치 권한을 요청할 수 있습니다. 이번 설치에 필요한 출처에만 권한을 부여하고, 완료 후에는 기기 관리 방식에 따라 권한을 해제할 수 있습니다. 업데이트 설치가 실패하면 서명 불일치, 저장 공간 부족, 아키텍처 불일치, 시스템 제한을 구분하세요. 기존 앱을 백업 없이 삭제하지 마세요. 앱을 제거하면 저장된 구독, 연결 설정과 로컬 설정도 함께 삭제되는 경우가 많습니다.

구독 가져오기 및 VPN 요청 승인

구독 그룹에 주소를 추가하고 저장한 뒤 업데이트하고 사용할 설정을 선택하세요. 클립보드에서 가져올 때는 연결 정보나 구독 주소를 복사했는지 확인하고 공유 페이지의 안내 문구를 붙여 넣지 않도록 합니다. QR 코드로 가져올 때는 단일 연결 QR 코드인지 구독 QR 코드인지 확인하세요. 가져온 뒤 설정 유형과 주요 매개변수를 살펴보세요. 목록에 항목이 표시됐다는 이유만으로 데이터가 완전하다고 판단해서는 안 됩니다.

처음 VPN 모드를 시작하면 시스템에 연결 요청이 표시됩니다. 방금 설치한 클라이언트에서 보낸 요청인지 확인한 뒤 VPN 연결 생성을 승인하세요. 상태 표시줄에 VPN 아이콘이 나타나는 것은 시스템에 해당 서비스가 있다는 뜻일 뿐, 원격 연결이 됐다는 보장은 아닙니다. 클라이언트 로그와 실제 접속 결과를 이어서 확인하세요. 서비스가 바로 종료되면 배터리 설정을 바꾸기 전에 권한, 활성 설정, 코어 실행 오류를 확인하세요.

Android에서는 일반적으로 한 사용자 또는 프로필에서 활성 VPN 서비스를 하나만 사용할 수 있습니다. 다른 네트워크 필터, 회사 접근 도구, 터널 앱이 현재 클라이언트와 충돌할 수 있습니다. 한 앱을 실행했을 때 다른 앱의 연결이 끊기면 시스템 제한과 업무용 프로필을 확인한 다음 사용할 서비스를 정하세요. 여러 앱을 반복해서 동시에 실행하지 마세요. 이렇게 쌓인 연결 해제 로그로는 단일 클라이언트의 안정성을 정확히 판단할 수 없습니다.

앱별 라우팅 규칙과 프록시 적용 범위

일부 앱의 트래픽만 처리하려면 클라이언트의 앱 선택 기능을 사용할 수 있습니다. 현재 목록이 포함 규칙인지 제외 규칙인지 먼저 확인하세요. 앱을 선택하면 프록시를 통과시키는 뜻일 수도 있고, 프록시를 우회시키는 뜻일 수도 있습니다. 변경 후 연결을 다시 시작하고 대상 앱에서 새 요청을 보내 확인하세요. 시스템 구성 요소, 업무 프로필 앱, 다른 사용자 공간의 앱은 같은 목록에 모두 표시되지 않을 수 있습니다.

VPN 모드와 프록시 전용 모드는 적용 범위가 다릅니다. 프록시 전용 모드는 주로 로컬 수신 서비스를 제공하며, 대상 앱이 직접 해당 프록시를 사용해야 합니다. 모든 휴대전화 앱이 자동으로 프록시를 사용하지는 않습니다. 가정용 Wi-Fi의 수동 프록시 설정도 클라이언트 VPN 모드와 같지 않으며 특정 네트워크와 일부 프로토콜에만 적용될 수 있습니다. 배터리 사용량이나 연결 상태를 비교할 때는 두 테스트가 같은 모드인지 먼저 확인하세요.

백그라운드 실행, 배터리 사용량, 네트워크 전환

화면이 켜져 있을 때는 연결되지만 잠금 후 끊긴다면 먼저 클라이언트가 계속 실행 중인지 확인한 뒤 배터리 최적화, 백그라운드 활동, 자동 시작, 데이터 절약 설정을 살펴보세요. 시스템마다 설정 이름이 다르므로 실제로 백그라운드 실행을 허용하는 항목을 찾아야 합니다. 현재 클라이언트에 필요한 제한만 먼저 조정하고 개선 여부를 확인하세요. 절전 기능 전체를 한꺼번에 끌 필요는 없습니다. 자세한 설정은 백그라운드 실행 유지 및 배터리 절약 설정을 참고하세요.

지속적인 데이터 전송, 잦은 재연결, 지나치게 빈번한 상태 확인은 배터리 사용량을 늘릴 수 있습니다. 문제를 살펴볼 때는 대기 환경, 네트워크 유형, 대용량 트래픽을 사용하는 앱이 있었는지 기록하세요. 배터리 통계에서 특정 항목의 비율이 높다는 이유만으로 이상이라고 단정하지 마세요. Wi-Fi에서 모바일 네트워크로 전환하면 기존 연결을 다시 만들어야 할 수 있습니다. 모바일 네트워크가 정상인지, 클라이언트의 백그라운드 모바일 데이터 사용이 허용되어 있는지 먼저 확인하세요.

시스템에서 VPN 항상 사용 또는 VPN을 통하지 않는 연결 차단을 설정했다면 클라이언트를 중지한 뒤에도 직접 연결이 되지 않을 수 있습니다. 네트워크를 복구할 때는 앱 내부 스위치만 끄지 말고 시스템 수준 설정도 확인하세요. 앱을 제거하거나 다른 클라이언트로 바꾸기 전에 해당 시스템 설정을 해제하고 필요한 구성을 내보내세요. 내보낸 파일과 스크린샷에도 민감한 주소가 포함될 수 있습니다. 문제 해결 정보를 공유할 때는 오류 유형, 발생 시간과 민감한 정보를 제거한 설정 설명만 남기세요.

구독 가져오기 및 설정 관리

구독 주소, 공유 링크, 설정 파일

구독 주소는 보통 여러 연결 설정을 반환하며 한곳에서 업데이트할 때 편리합니다. 단일 공유 링크는 일반적으로 연결 하나를 설명하고, 설정 파일에는 로컬 수신, 라우팅 규칙, DNS 설정 등이 포함될 수 있습니다. 세 가지는 길이나 모양만 보고 서로 바꿔 쓸 수 없습니다. 가져오기 전에 현재 클라이언트의 입력란이 어떤 데이터를 받는지 확인하세요. 전체 코어 설정을 구독 주소 입력란에 붙여 넣거나 로그인해야 하는 계정 페이지를 구독 주소로 사용하지 마세요.

구독 주소의 경로와 쿼리 매개변수에는 접근 정보가 포함되는 경우가 많으므로 복사할 때 전체 주소를 유지하고 복잡해 보이는 끝부분을 임의로 지우지 마세요. 출처를 알 수 없는 변환 사이트에 링크를 제출해서도 안 됩니다. 서비스 제공업체가 특정 클라이언트용 구독 형식을 제공한다면 호환되는 형식을 선택하세요. 범용 출력은 모든 전송 확장 필드를 유지하지 않을 수 있으므로 가져온 후 실제 연결 매개변수를 확인해야 합니다.

그룹을 만들고 업데이트 순서 정하기

출처나 용도에 따라 그룹을 만들고 계정 정보를 노출하지 않으면서 구분할 수 있는 이름을 사용하세요. 처음 업데이트할 때는 기기에서 현재 사용할 수 있는 네트워크 경로를 이용합니다. 프록시를 통해 업데이트하도록 설정하면 기존 프록시 연결에 의존하게 됩니다. 기존 설정이 모두 작동하지 않으면 업데이트에 프록시가 필요한데 프록시에는 업데이트된 설정이 필요한 순환 문제가 생길 수 있습니다. 이때는 별도로 사용할 수 있는 네트워크 경로를 복구하거나 클라이언트 옵션에서 직접 연결 업데이트를 시도하세요.

업데이트 후 그룹에 설정이 있는지, 개수가 크게 바뀌었는지, 활성 설정이 남아 있는지 확인하세요. 제공업체가 설정 식별자를 바꾸거나 이전 항목을 제거할 수 있으므로 기존 활성 항목이 자동으로 대응되지 않을 수 있습니다. 새 항목을 다시 선택하고 코어를 실행한 다음 접속을 테스트하세요. 이전 로그와 새 설정을 섞어 판단하지 않도록 업데이트 완료 시간을 기록하고 그 이후에 새로 생성된 오류를 확인하세요.

구독에서 생성된 설정을 직접 수정하면 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 계속 사용할 라우팅 규칙, 수신 포트, 앱 설정은 가능한 한 클라이언트의 별도 전역 설정에 저장하세요. 연결 설정을 직접 수정해 보관해야 한다면 업데이트 동작을 이해한 뒤 별도로 관리하고, 서버 측 변경 사항이 자동으로 반영되지 않는다는 점을 기억하세요. 구독 그룹과 수동 설정을 함께 사용할 때는 각 항목의 출처를 기록하는 것이 특히 중요합니다.

구독 업데이트 오류 해결

시간 초과는 요청이 제한 시간 안에 완료되지 않았다는 뜻이며 기본 네트워크, DNS 해석, 선택한 업데이트 경로가 원인일 수 있습니다. 인증 실패는 주소 인증 정보나 계정 상태와 관련될 가능성이 높고, 파싱 실패는 반환된 내용이 예상한 형식과 다르다는 뜻입니다. 오류마다 해결 방법이 다르므로 전체 오류 유형을 먼저 확인하고 해당 계층을 점검하세요. 요청 제한을 피하려면 반복해서 새로고침하지 말고, 인증 정보가 포함된 원본 링크를 공개적으로 올리지 마세요.

브라우저에서 주소를 열었을 때 웹페이지가 표시되면 로그인 페이지인지, 오류 페이지인지, 정상적인 구독 표시 페이지인지 구분해야 합니다. 웹페이지 본문을 연결 목록으로 그대로 붙여 넣지 마세요. 반환 내용이 예상과 다르면 주소가 만료됐는지, 특정 출력 형식이 필요한지 설정 제공업체에 문의하세요. 클라이언트는 지원하는 구조만 처리할 수 있으며 임의의 계정 웹페이지를 연결 설정으로 자동 변환하지 않습니다.

가져오기는 성공했지만 실행 중 지원하지 않는 필드 오류가 발생하면 코어와 프로토콜 매개변수를 중점적으로 확인하세요. VMess, VLESS, Trojan은 서로 다른 프로토콜이며 REALITY는 관련 연결 설정에서 사용하는 보안 기능입니다. 이름만 바꾼다고 변환이 완료되는 것은 아닙니다. 전송 방식, 서버 이름, 인증 정보는 각각 용도가 다릅니다. 코어를 업데이트하거나 바꾸기 전에 원본 데이터를 보관하고, 변경이 로그에 표시된 문제를 해결하기 위한 것인지 확인하세요.

백업, 이전, 정보 최소 공개

설정을 이전할 때는 클라이언트에서 공식적으로 제공하는 가져오기 및 내보내기 기능을 우선 사용하세요. 디렉터리 전체를 복사하려면 먼저 클라이언트를 종료하고 대상 플랫폼이 같은 구조를 이해하는지 확인합니다. 시스템 프록시 스위치, 파일 경로, 인증서 위치와 권한 상태는 기기별 환경이므로 연결 정보와 함께 자동으로 이전된다고 가정해서는 안 됩니다. 대상 기기에 가져온 뒤 먼저 연결 하나를 테스트하고 그룹과 다른 설정을 복원하세요. 많은 설정을 한꺼번에 옮기면 문제를 찾기 어렵습니다.

구독이 유출되었다면 로컬 그룹 이름을 바꾸는 것만으로는 보호되지 않습니다. 접근 정보를 취소하거나 재설정하는 것이 중요합니다. 문제 해결 정보를 공유할 때는 프로토콜 유형, 전송 방식, 오류 범주만 남기고 서버 주소, 사용자 식별 정보, 구독 쿼리 매개변수, QR 코드는 가리세요. 백업에도 보관 기간을 정하고 오래된 계정, 종료된 서비스, 중복 내보내기 파일을 무기한 쌓아 두지 마세요.

일상적인 관리에서 업데이트를 지나치게 자주 실행할 필요는 없습니다. 서비스 설정이 얼마나 자주 바뀌는지 파악한 뒤 적절한 수동 또는 예약 업데이트 주기를 정하세요. 업데이트와 연결 확인은 서로 다른 작업입니다. 기본 절차는 구독 가져오기 가이드에서 다시 확인할 수 있습니다. 특정 그룹 하나만 업데이트에 실패했다면 다른 그룹과 분리해 점검하고, 단일 출처의 문제를 해결하려고 클라이언트 전체를 초기화하지 마세요.

라우팅 규칙 및 DNS 설정

적용 범위를 정한 뒤 출구를 선택하기

프록시 적용과 라우팅 규칙은 서로 다른 문제를 다룹니다. 시스템 프록시나 TUN은 요청을 클라이언트로 보낼지 결정하고, 라우팅 규칙은 클라이언트에 들어온 요청이 어떤 출구를 사용할지 결정합니다. 앱이 시스템 프록시를 사용하지 않으면 라우팅 모드를 전역으로 설정해도 해당 요청이 코어에 도달하지 않을 수 있습니다. 반대로 TUN으로 요청을 처리하더라도 라우팅 규칙에 따라 직접 연결, 프록시 또는 차단을 선택할 수 있습니다. 트래픽 적용 방식과 출구 모드를 혼동하지 마세요.

처음 설정할 때는 클라이언트에 포함된 단순한 라우팅 규칙을 사용해 일반 웹페이지, LAN 리소스, 필요한 원격 대상에 예상대로 접근할 수 있는지 확인하세요. 중국 본토 우회는 보통 도메인, IP 데이터와 규칙의 조합에 의존하며 실시간 위치 판정이 아닙니다. 전역 프록시는 분기 변수를 일시적으로 줄이는 데 유용하지만 로컬 서비스나 회사 네트워크에도 영향을 줄 수 있습니다. 테스트가 끝나면 문제 해결용 설정을 계속 쓰지 말고 실제 환경에 맞는 규칙으로 되돌리세요.

규칙 순서와 일치 조건 이해하기

라우팅은 일반적으로 규칙 순서대로 비교하며 먼저 일치하는 규칙이 이후 규칙의 적용 여부에 영향을 줍니다. 정확한 도메인, 도메인 접미사, 분류 데이터베이스, IP 범위, 포트는 서로 다른 조건입니다. 여러 조건을 조합한 결과는 코어의 규칙 문법에 따라 달라지므로 한 줄에 여러 필드가 있다고 해서 그중 하나만 일치하면 된다고 해석해서는 안 됩니다. 수정하기 전에 대상 요청에 어떤 정보가 있고 어느 출구로 보내려는지 먼저 정하세요.

아래는 사설 IP 주소를 직접 연결하는 방법을 설명하기 위한 Xray 라우팅 객체 예시입니다. 단독으로 실행할 수 있는 완전한 설정이 아니므로 병합할 때 기존 인바운드와 아웃바운드를 유지하고, direct라는 이름의 아웃바운드가 있는지 확인해야 합니다. 클라이언트가 설정 파일을 생성하면 수동 변경 사항이 덮어써질 수 있으므로 임시 생성 파일을 직접 수정하지 말고 해당 라우팅 설정 기능을 사용하세요.

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

AsIs는 라우팅 규칙에서 주소 일치를 위해 도메인을 능동적으로 해석하지 않는다는 뜻이지, 시스템 전체에서 DNS 요청이 발생하지 않는다는 뜻은 아닙니다. 요청에 이미 IP 주소가 포함되어 있다면 주소 규칙이 여전히 적용될 수 있습니다. geoip:private는 해당 규칙 데이터를 필요로 하며 다른 분류 이름도 데이터 파일이 있어야 사용할 수 있습니다. 파일 누락, 분류 항목 부재, 규칙 순서 오류는 서로 다른 증상을 일으키므로 코어 로그에서 실제 원인을 확인하세요.

DNS 경로를 단계별로 확인하기

도메인 해석은 앱, 시스템 DNS 해석기, 클라이언트 내부에서 이뤄질 수 있으며 DNS 요청 자체도 서로 다른 출구를 사용할 수 있습니다. 브라우저에서 별도의 암호화 DNS를 사용하면 또 다른 경로가 생깁니다. 따라서 클라이언트의 DNS 설정을 바꿔도 모든 앱의 도메인 해석을 제어할 수 있는 것은 아닙니다. 문제를 확인할 때는 먼저 어떤 구성 요소가 해석을 요청했는지 파악하고, 요청이 어디로 어떤 연결을 통해 전달되는지, 반환된 주소가 라우팅에 어떻게 사용되는지 살펴보세요. 서버 주소 하나만 바꾸고 점검을 끝내지 마세요.

시스템 프록시는 앱이 프록시에 직접 전달한 트래픽을 주로 처리하므로 시스템의 모든 DNS 요청이 함께 처리된다고 보장하지 않습니다. TUN은 적용 범위를 넓힐 수 있지만 DNS를 올바르게 처리하는지는 인터페이스, 라우팅 규칙과 클라이언트 설정에 따라 달라집니다. 확인이 필요하면 DNS 요청 경로 확인 방법에 따라 하나씩 점검하세요. 검사 페이지에서 표시되는 DNS 출구는 캐시와 네트워크 서비스의 영향을 받을 수 있으므로 한 번의 결과만으로 모든 요청 경로를 단정하지 마세요.

FakeDNS는 가상 주소를 도메인 이름과 연결해 이후 도메인 정보를 복원하도록 돕는 기능으로, 특정 트래픽 처리 및 라우팅 상황에 사용됩니다. 일반 공용 DNS와 같은 뜻이 아니며 단독으로 켜도 모든 앱과 자동으로 호환되는 것은 아닙니다. 요청 차단, 주소 매핑, 도메인 복원 경로가 함께 작동해야 합니다. 앱이 가상 주소를 캐시한 뒤 직접 연결로 전환하면 연결이 실패할 수 있습니다. 관련 기능을 켜거나 끈 뒤에는 상황에 따라 연결을 다시 만들고 캐시를 처리해야 합니다.

규칙 유지보수 및 확인 방법

GeoIP와 GeoSite 데이터는 분류 규칙의 적용 범위에 영향을 주지만, 파일을 업데이트해도 잘못된 규칙 문법이 고쳐지지는 않습니다. 먼저 클라이언트가 어떤 파일을 읽는지와 업데이트가 성공했는지 확인한 다음 분류 이름과 사용 위치를 점검하세요. 자세한 배경은 GeoIP·GeoSite 업데이트 및 규칙 작성 방법을 참고하세요. 설정에서 실제로 존재하지 않는 분류를 참조하면 이름이 그럴듯해 보여도 적용되지 않습니다.

한 번에 규칙 하나만 추가하고 같은 대상으로 새 연결을 만들어 확인한 뒤 로그에서 선택된 출구를 살펴보세요. 앱의 기존 장시간 연결은 이전 경로를 계속 사용할 수 있으므로 규칙을 수정한 뒤 화면을 새로고침하는 것만으로 판단해서는 안 됩니다. 대상에 여러 도메인이나 리디렉션 과정이 포함되어 있다면 기본 페이지, 리소스 도메인, API 요청을 구분하세요. 페이지 일부가 로드됐다고 모든 관련 도메인이 같은 규칙을 사용한 것은 아닙니다.

계속 사용할 때는 LAN 리소스에 명확한 직접 연결 범위를 두고 사용자 지정 규칙의 용도를 기록하세요. 복잡한 DNS 설정을 추가하기 전에 FakeDNS 원리와 사용 시점을 읽어볼 수 있습니다. 네트워크를 복구할 때는 최근 변경 사항을 역순으로 되돌리세요. 추가한 규칙을 먼저 제거하고, DNS 설정을 복원한 뒤, 마지막으로 트래픽 적용 방식을 바꿉니다. 검증된 단순 설정을 보관하면 다음 문제 해결 시간을 크게 줄일 수 있습니다.

자주 발생하는 설정 문제와 해결 순서

증상을 바탕으로 문제 범위 좁히기

먼저 재현 가능한 증상으로 문제를 설명하세요. 사용 플랫폼과 클라이언트, 시스템 프록시 또는 TUN 사용 여부, 실패하는 앱, 프록시를 끄면 복구되는지를 확인합니다. 그런 다음 구독 업데이트, 포트 변경, DNS 기능 사용, 네트워크 전환 중 가장 최근의 변경을 확인하세요. 모든 설정을 동시에 기본값으로 되돌리면 문제 원인을 설명하는 단서가 사라지고, 원래 정상 작동하던 부분도 복구하기 어려워질 수 있습니다.

기본 네트워크부터 로컬 프로세스, 원격 연결, 앱 동작 순서로 확인하세요. 기기가 인터넷에 연결되는지 확인하고, 코어가 정상 실행되어 포트에서 수신하는지 확인한 다음, 명시적 프록시로 연결을 테스트합니다. 마지막으로 시스템 프록시, TUN, 라우팅 규칙을 점검하세요. 한 단계가 통과되지 않으면 그보다 상위 설정은 수정하지 마세요. 이렇게 하면 포트 점유 문제를 DNS 설정으로 해결하려 하거나, 시스템에 남은 프록시를 클라이언트 재설치로 해결하려는 상황을 피할 수 있습니다.

실행, 구독, 연결 문제

앱별 차이와 네트워크 복구

유용한 정보 기록 및 롤백 설정 보관

로그는 오류 발생 전후의 짧은 구간을 기록하고 오류 유형, 시간, 클라이언트 이름, 운영체제, 트래픽 적용 방식만 포함하면 됩니다. 공유 전에 구독 주소, 서버 인증 정보, QR 코드, 계정 정보를 가리세요. 연결 시간 초과, 인증서 오류, 도메인 해석 실패, 설정 필드 미지원은 각각 구분해서 설명하고 모두 ‘작동하지 않음’으로 뭉뚱그리지 마세요. 많은 로그를 정리 없이 공유하는 것보다 문제 범위를 명확히 기록하는 편이 다시 확인하기 쉽습니다.

문제를 해결한 뒤 최종 변경 내용을 로컬 관리 노트에 기록하고 검증된 설정 사본을 보관하세요. 자동 시작, 백그라운드 제한, 다른 도구 설정을 변경했다면 하나씩 원래대로 돌리고 매번 다시 테스트해 새로운 충돌이 생기지 않았는지 확인합니다. 가장 짧은 연결 절차를 다시 진행하려면 사용 가이드를 확인하고, 플랫폼이나 설치 파일을 바꿔야 한다면 클라이언트 다운로드 페이지로 돌아가세요. 이 페이지의 각 장은 이후 업데이트와 이전 작업을 점검하는 체크리스트로 활용할 수 있습니다.