전체 플랫폼 설치
및 구독 설정

사전 준비와 설정 범위

클라이언트, 코어, 구독, 시스템 트래픽 처리를 각각 구분해 이해하세요. 클라이언트는 화면을 표시하고 그룹을 저장하며 설정을 생성합니다. 코어는 실제 연결과 라우팅을 담당하고, 구독 URL은 서버 설정을 가져오는 데 사용됩니다. 시스템 프록시나 가상 네트워크 인터페이스는 앱 트래픽을 코어로 전달합니다. 이 네 가지는 각각 별도로 문제가 생길 수 있습니다. 창이 열려도 코어가 실행 중이라는 뜻은 아니며, 구독 업데이트에 성공해도 브라우저가 프록시를 사용한다는 뜻은 아닙니다.

운영체제, 아키텍처, 설치 파일 확인

시스템의 기기 정보에서 운영체제, 프로세서 아키텍처, 남은 저장 공간을 확인하세요. 데스크톱 기기는 외관만으로 아키텍처를 판단하지 마세요. 같은 모델에도 다른 칩이 탑재될 수 있습니다. 클라이언트 다운로드 페이지에서 플랫폼을 먼저 선택한 다음 알맞은 패키지를 고르세요. Windows 데스크톱 버전과 WPF 버전은 서로 다른 실행 환경입니다. macOS에서는 Apple Silicon과 Intel을 구분하고, Linux에서는 패키지 형식을 확인해야 합니다.

Android에서는 기기에 맞는 arm64 패키지를 우선 선택하고, 아키텍처를 확인하기 어렵다면 범용 버전 안내를 살펴보세요. 패키지를 다운로드할 수 있다고 해서 기기에서 반드시 실행되는 것은 아닙니다. 최소 시스템 요구 사항은 다운로드 페이지와 설치 프로그램의 안내를 따르세요. 아키텍처가 맞지 않으면 다운로드 페이지로 돌아가 다른 패키지를 선택하세요. 프록시 설정을 반복해서 바꿀 필요는 없습니다. 설치 오류와 네트워크 연결 오류는 따로 해결해야 합니다.

구독 URL과 네트워크 조건 준비

이용 중인 서비스의 관리 페이지에서 구독 URL 전체를 복사하고 계정이 유효한지, 요금제가 사용을 허용하는지, 기기 수 제한을 초과하지 않았는지 확인하세요. 이 사이트는 설정 방법만 안내하며 구독 정보를 생성하지 않습니다. URL에는 계정 인증 정보가 포함될 수 있으므로 공개 게시판에 올리지 마세요. 화면을 공유할 때도 URL, QR 코드, 개인 메모의 민감한 내용을 가리세요.

구독 URL과 개별 공유 링크를 구분하세요. 구독 URL은 보통 네트워크 요청으로 여러 설정을 가져오고, 개별 공유 링크에는 서버 하나의 설정이 직접 들어 있습니다. 개별 공유 링크를 구독 URL 입력란에 붙여 넣으면 형식 오류가 발생할 수 있습니다. 계정 관리 웹페이지를 구독 URL로 사용하면 서버 정보가 아닌 웹페이지를 내려받을 수도 있습니다. 서비스 페이지에서 클라이언트 구독용으로 안내한 항목을 사용하세요.

URL 앞뒤에 공백, 줄바꿈, 전각 문장부호가 들어갔는지 확인하세요. 쿼리 매개변수가 있는 URL은 물음표 뒤까지 모두 복사해야 합니다. 보기 좋게 줄이려고 매개변수를 삭제하지 말고, 구독 인증 정보를 온라인 변환 도구에 붙여 넣지도 마세요. 형식을 변환해야 한다면 출처와 용도를 확인하고 전체 URL이 제3자에게 전송되는지 먼저 살펴보세요.

한 번에 한 항목씩 확인하는 절차

시스템 자동 시간 설정을 켠 다음 기기의 날짜와 시간대를 확인하세요. 인증서 검증과 일부 프로토콜 인증에는 정확한 시간이 필요합니다. 연결 오류를 해결하려고 시간을 임의로 앞당기지 마세요. 현재 네트워크에 로그인이 완료됐는지도 확인해야 합니다. 호텔, 학교, 게스트 네트워크의 인증 페이지를 통과하지 않으면 클라이언트에 시간 초과만 표시되어 구독이나 서버 문제처럼 보일 수 있습니다.

다른 프록시와 가상 네트워크 인터페이스를 사용하는 도구를 잠시 종료하고 기존 설정을 기록해 두세요. 처음 확인할 때는 클라이언트 하나, 서버 하나, 트래픽 처리 방식 하나만 사용합니다. 먼저 구독을 가져와 코어가 실행되는지 확인하고, 다음으로 시스템 프록시를 켠 뒤 마지막으로 TUN을 시도하세요. 이렇게 하면 여러 설정을 동시에 점검하는 대신 어느 단계에서 문제가 생겼는지 파악할 수 있습니다.

용도가 분명한 테스트 대상을 두 개 선택하세요. 하나는 직접 연결되어야 하는 일반 웹사이트, 다른 하나는 현재 규칙에 따라 프록시를 사용해야 하는 서비스입니다. 브라우저에 캐시된 페이지가 표시되는 것만으로 연결이 정상이라고 볼 수는 없습니다. 테스트할 때 새로고침하고 클라이언트 로그에서 요청을 확인하세요. 노드 옆의 테스트 결과만으로 모든 앱의 연결 상태를 판단하지도 마세요. 보통 특정 탐색 요청의 결과만 보여 줍니다.

마지막으로 회사 네트워크나 관리 대상 기기의 사용 정책을 확인하세요. 관리되는 기기에서는 로컬 프록시, 네트워크 확장 기능, 관리자 권한이 제한될 수 있습니다. 정책에 의해 차단된 것이 분명하다면 기기 관리자에게 문의하세요. 시스템 보안을 꺼서 제한을 우회하지 마세요. 이어지는 플랫폼별 장은 다운로드, 설치, 가져오기, 트래픽 처리, 확인 순으로 구성되어 있으니 한 단계를 완료한 뒤 다음으로 넘어가면 됩니다.

Windows: v2rayN 설치

Windows에서는 플랫폼별 다운로드에서 v2rayN을 선택하세요. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하고, WPF 버전은 기존 데스크톱 방식의 조작 환경을 제공합니다. 사용 습관에 맞는 버전을 선택하면 됩니다. 구독을 가져오려고 두 버전을 모두 설치할 필요는 없습니다. 아래에서는 ‘구독 그룹’, ‘시스템 프록시’와 같은 기능 이름을 기준으로 설명하며, 메뉴 위치는 인터페이스 업데이트에 따라 달라질 수 있습니다.

설치 후 코어 실행 확인

설치 프로그램을 실행할 때 대상 폴더에 쓰기 권한이 있는지 확인하세요. 압축을 풀어 사용하는 배포 형식이라면 전체 압축을 푼 뒤 대상 폴더에서 실행해야 합니다. 압축 파일 미리보기 창에서 프로그램을 바로 실행하거나 주 실행 파일만 따로 꺼내지 마세요. 관련 구성 요소와 설정 파일이 상대 경로를 참조할 수 있어 파일이 빠지면 창은 열려도 코어가 시작되지 않을 수 있습니다.

처음 실행할 때 로그 영역에서 구성 요소 누락, 설정 파싱 실패, 포트 사용 중 오류가 없는지 확인하세요. 실행 환경이 부족하다는 안내가 나오면 해당 빌드에 필요한 구성 요소를 안내에 따라 설치한 다음 클라이언트를 다시 시작하세요. 출처를 알 수 없는 사이트에서 같은 이름의 동적 링크 라이브러리를 받아 폴더에 넣지 마세요. 의존성이 맞는다는 보장이 없고, 이후 문제 해결의 기준도 불분명해집니다.

일반적인 시스템 프록시 사용에는 보통 관리자 권한이 필요하지 않습니다. 먼저 일반 권한으로 구독을 가져오고 브라우저에서 연결을 확인하세요. 높은 권한이 필요한 기능을 사용할 때만 안내에 따라 권한을 올리면 됩니다. 관리자 권한으로 실행한 뒤 서버 목록이 비어 있다면 다른 프로그램을 실행했거나 설정 디렉터리가 달라졌는지 먼저 확인하세요. 데이터를 덮어쓰며 다시 가져오지 마세요.

구독 그룹 추가 및 서버 업데이트

구독 그룹 설정을 열고 새 그룹을 만든 다음 알아보기 쉬운 용도를 메모에 적고 주소 입력란에 구독 URL 전체를 붙여 넣으세요. 해당 그룹의 업데이트 옵션을 켜고 저장한 뒤 구독 업데이트를 실행합니다. 자동 업데이트 간격은 이후 새로고침 주기를 정하는 설정이며, 첫 업데이트를 대신하지 않습니다. 처음에는 기본 User-Agent를 사용하고 서비스 제공자가 별도 값을 요구할 때만 지정하세요.

업데이트가 끝나면 서버 목록으로 돌아가 다른 그룹이나 검색 조건으로 목록이 필터링되지 않았는지 확인하세요. 서버 하나를 선택해 활성 항목으로 지정한 다음 로그에 새 설정이 생성됐는지 살펴보세요. 구독에 현재 코어가 지원하지 않는 필드가 포함되면 서버 이름은 표시되지만 시작 단계에서 오류가 날 수 있습니다. 이때는 주소를 반복해서 복사하는 대신 프로토콜과 코어의 지원 여부를 확인하세요.

구독 업데이트에 직접 연결과 프록시 연결 옵션이 있다면 처음에는 현재 네트워크에서 접속 가능한 방식을 시도하세요. 프록시를 통한 업데이트는 이미 사용 가능한 연결이 있어야 하므로 모든 서버가 작동하지 않을 때 구독을 복구해 주지는 않습니다. 기존 그룹을 유지한 채 업데이트 응답을 확인하고 가져오기 방식을 바꾸세요. 사용 가능한 복구 경로를 잃지 않도록 모든 서버를 먼저 삭제하지 마세요.

시스템 프록시 설정 및 포트 확인

시스템 프록시 자동 설정을 선택하면 Windows 시스템 프록시를 따르는 앱이 로컬 수신 주소를 사용합니다. 시스템 설정의 프록시 페이지를 열어 수동 프록시 주소와 포트가 클라이언트의 현재 설정과 일치하는지 확인하세요. 로컬 포트는 원격 서버 포트도, 구독 URL에 있는 포트도 아닙니다. 세 항목은 용도가 다르므로 서로 복사해 입력하면 안 됩니다.

현재 용도에 적합한 라우팅 사전 설정을 유지한 채 브라우저에서 새 요청을 보내세요. 브라우저가 여전히 연결되지 않으면 프록시를 별도로 제어하는 확장 프로그램이 설치되어 있는지, 브라우저 자체에 다른 주소가 지정되어 있는지 확인하세요. 시스템 프록시가 적용되는 범위는 앱마다 다릅니다. 한 프로그램이 직접 연결된다고 해서 코어가 작동하지 않는다고 단정할 수는 없습니다. 이런 앱까지 트래픽을 처리해야 한다면 시스템 프록시와 TUN 장을 확인하세요.

Windows의 종료 및 권한 문제

TUN을 켜기 전에 진행 중인 네트워크 작업을 저장하고 클라이언트 안내에 따라 권한을 올리세요. 가상 네트워크 인터페이스 생성 실패와 서버 연결 실패는 서로 다른 문제입니다. 전자는 권한, 드라이버, 네트워크 도구 간 충돌을 확인하고, 후자는 서버와 라우팅을 점검해야 합니다. 오류가 보인다고 클라이언트를 재설치하고, 인터페이스를 삭제하고, 시스템 네트워크를 초기화하는 작업을 한꺼번에 하지 말고 구체적인 오류를 먼저 보존하세요.

클라이언트를 종료할 때는 시스템 프록시를 먼저 해제한 다음 프로그램을 닫으세요. 실수로 종료한 뒤 브라우저에서 인터넷에 접속할 수 없다면 Windows 프록시 설정에 이미 수신이 중단된 로컬 포트가 남아 있는지 확인하세요. 남아 있는 수동 프록시를 끄고 직접 연결을 테스트하세요. 연결이 복구되면 트래픽 처리 설정이 원인인 것이므로 구독을 바꾸거나 전체 설정을 삭제할 필요는 없습니다.

시작 프로그램을 설정할 때는 앱 자동 실행과 트래픽 처리 자동 시작을 구분하세요. 재부팅 후 동작을 한 번 확인한 다음 자동 연결 여부를 결정하세요. 여러 사용자가 쓰는 PC라면 실제 사용 계정에서 프록시 설정을 확인해야 합니다. 설정을 옮길 때는 클라이언트를 종료하고 백업하세요. 실행 중인 인스턴스 두 개 사이에서 설정 파일을 바로 덮어쓰지 마세요.

macOS: 설치 및 네트워크 권한

macOS에서 v2rayN을 사용하려면 먼저 ‘이 Mac에 관하여’에서 칩 종류를 확인하세요. Apple 칩이 표시되면 Apple Silicon 빌드를, Intel 프로세서가 표시되면 Intel 빌드를 선택하세요. macOS 다운로드에서 칩에 맞는 패키지를 받으면 됩니다. 아키텍처에 따라 프로그램 실행 여부가 달라질 뿐 구독 내용은 바뀌지 않습니다. 시작 오류를 해결하려고 프로토콜을 수정하지 마세요.

앱을 안정적인 설치 위치에 배치

디스크 이미지를 연 다음 설치 화면의 안내에 따라 앱을 ‘응용 프로그램’ 폴더에 넣고 해당 폴더에서 실행하세요. 마운트된 이미지나 임시 다운로드 폴더에서 계속 실행하지 마세요. 안정적인 위치에 설치하면 시스템이 권한과 시작 항목을 인식하기 쉽고, 업데이트 후 같은 이름의 앱이 두 개 생기거나 이전 복사본을 잘못 실행하거나 설정 위치를 찾지 못하는 문제도 줄어듭니다.

처음 실행할 때 시스템 보안 경고가 나타나면 설치 파일의 출처와 앱 이름을 확인한 다음 시스템 설정의 개인정보 보호 및 보안에서 허용할 수 있는 작업을 살펴보세요. 시스템 버전에 따라 메뉴 위치가 다를 수 있으므로 실제 시스템 안내를 따르세요. 시스템 보안 기능을 일괄 해제하거나 경고를 없애려고 출처 불명의 터미널 명령을 실행하지 마세요.

실행한 뒤 로그에서 코어가 정상적으로 로드됐는지 확인하세요. 앱을 실행할 수 없다는 메시지가 나오면 시스템 요구 사항, 칩 아키텍처, 설치 완료 여부를 먼저 확인하세요. 창은 정상적으로 열리는데 코어에서 오류가 발생한다면 구체적인 오류에 따라 구성 요소나 설정을 점검하세요. 두 단계를 구분하면 시스템 호환성 문제를 구독 서비스 장애로 오인하지 않을 수 있습니다.

구독 가져오기 및 첫 연결 설정

구독 그룹 설정에서 새 그룹을 만들고 메모와 전체 주소를 입력한 뒤 저장하고 수동으로 업데이트하세요. 주소를 붙여 넣을 때 클립보드 내용이 비밀번호 관리자나 서식 있는 웹페이지에서 왔는지 확인하고 끝에 공백이 남지 않도록 하세요. 업데이트를 마치면 활성 서버를 선택하고 기본 연결 매개변수를 유지하세요. 구독에 포함된 전송 방식, 서비스 이름, 인증서 관련 필드를 임의로 수정하지 마세요.

업데이트 후 이름이 비슷한 서버가 여러 개 나타나면 서비스 안내를 보고 용도에 맞는 서버를 선택하세요. 이름이 같다고 설정까지 완전히 같은 것은 아닙니다. 구독을 업데이트하면 서버 매개변수가 바뀔 수 있으며 수동 변경 사항이 다음 업데이트에서 덮어쓰일 수도 있습니다. 장기간 유지할 사용자 지정 설정은 별도 그룹이나 클라이언트가 지원하는 지속 규칙으로 관리하고 변경 이유를 기록하세요.

현재 네트워크 서비스의 프록시 상태 확인

클라이언트에서 시스템 프록시를 켠 뒤 현재 네트워크 연결의 상세 정보에서 프록시 설정을 확인하세요. macOS 프록시 설정은 네트워크 서비스별로 관리되므로 Wi-Fi와 유선 네트워크의 상태가 다를 수 있습니다. 도킹 스테이션을 연결하거나 네트워크를 바꾼 뒤 브라우저가 갑자기 프록시를 사용하지 않으면 서버를 바꾸기 전에 현재 사용 중인 네트워크 서비스를 확인하세요.

웹 프록시, 보안 웹 프록시, SOCKS 프록시 필드를 각각 구분하세요. 클라이언트가 일부 항목을 자동 설정했다면 수신 방식에 맞춰 유지하세요. ‘모두 선택’하려고 모든 프로토콜에 같은 포트를 입력하지 마세요. 수동 프록시를 사용하는 앱에서는 HTTP와 SOCKS 중 유형을 정확히 선택해야 합니다. 유형과 수신 포트가 맞지 않으면 대개 연결이 바로 실패합니다.

브라우저 테스트가 성공하면 실제로 사용할 앱도 확인하세요. 일부 앱은 시스템 프록시를 읽고, 일부는 자체 네트워크 설정을 사용하며, 일부는 실행할 때 한 번만 설정을 읽습니다. 프록시를 변경한 뒤 대상 앱을 종료하고 다시 열어 로그에 요청이 나타나는지 확인할 수 있습니다. 기존 연결이 계속 재사용되는 현상을 새 설정이 적용되지 않은 것으로 오해하지 마세요.

필요할 때 TUN을 사용하고 복구 경로 확인

선택한 빌드가 TUN을 지원한다면 클라이언트 안내에 따라 필요한 권한을 부여하고 로그에서 가상 인터페이스와 라우팅 초기화 결과를 확인하세요. 시스템에서 제공하지 않는 옵션을 다른 플랫폼의 명령을 복사해 억지로 추가하지 마세요. 시스템 프록시로 대상 앱을 처리할 수 없을 때만 TUN 사용을 검토하세요. 일반적인 브라우저 사용을 위해 먼저 트래픽 처리 단계를 늘릴 필요는 없습니다.

절전 모드에서 깨어난 뒤 연결이 멈추면 트래픽 처리를 잠시 중지했다가 다시 켜고 네트워크가 복구됐는지 테스트하세요. 절전 해제 중에 IP 주소, 게이트웨이, DNS가 바뀔 수 있으므로 기존 연결이 끊겼다고 구독을 업데이트할 필요는 없습니다. 매번 절전 해제 후 실패한다면 TUN에서만 발생하는지, 특정 네트워크 서비스나 앱에서 나타나는지 기록해 원인을 좁히세요.

종료하거나 제거하기 전에 TUN과 시스템 프록시를 끄고 현재 네트워크 서비스에 남은 설정이 없는지 확인하세요. 그런 다음 직접 연결을 테스트해 정상으로 돌아온 뒤 앱을 제거하세요. 설정을 보관해야 한다면 별도로 백업하되 설정 디렉터리 전체를 공개하지 마세요. 네트워크 전환 후 연결이 반복해서 끊기면 문제 해결 가이드에서 권한과 트래픽 처리 충돌도 확인하세요.

Linux: 패키지 및 데스크톱 프록시

Linux에서는 배포판의 패키지 시스템과 기기 아키텍처를 확인한 다음 Linux 다운로드에서 v2rayN을 선택하세요. Debian 계열은 보통 deb, RPM 계열은 rpm을 사용하며 같은 형식 안에서도 x64와 arm64 패키지가 나뉠 수 있습니다. 데스크톱 그래픽 클라이언트에는 사용 가능한 데스크톱 환경이 필요합니다. 패키지 압축을 풀 수 있다고 해서 그래픽 프로그램의 실행 조건을 갖췄다고 볼 수는 없습니다.

시스템 패키지 관리자로 설치

다운로드한 패키지는 배포판의 소프트웨어 설치 프로그램으로 열어 패키지 관리자가 의존성을 처리하도록 하세요. 설치 프로그램에서 의존성이 부족하다고 알리면 필요한 항목과 시스템 버전의 지원 여부를 확인한 다음 배포판의 정식 소프트웨어 저장소를 이용하세요. 다른 배포판의 저장소를 섞어 쓰거나 의존성을 무시하고 강제로 설치하지 마세요. 이후 프로그램 창이 열리지 않거나 시스템 구성 요소가 충돌할 수 있습니다.

아래 명령으로 아키텍처를 확인할 수 있습니다. 이 명령은 시스템 종류만 표시하며 설정을 변경하지 않습니다. 일반적인 출력에서 x86_64는 보통 x64 패키지, aarch64는 보통 arm64 패키지에 해당합니다. 컨테이너, 원격 데스크톱, 호환 계층에서 실행 중이라면 호스트 시스템과 실제 실행 환경을 구분해야 합니다. 호스트 하드웨어 이름만 보고 패키지를 선택하지 마세요.

uname -m

설치가 끝나면 데스크톱 메뉴에서 실행하고 처음에는 일반 사용자 권한을 사용하세요. 창이 열리지 않는다면 터미널에서 설치된 프로그램을 실행해 오류를 확인할 수 있지만, 문제를 피하려고 그래픽 클라이언트 전체를 관리자 계정으로 실행하지 마세요. 일반 사용자와 관리자 계정은 설정 디렉터리가 다릅니다. 계정을 섞어 쓰면 구독, 권한, 파일 소유권이 뒤섞여 유지 관리가 어려워집니다.

구독 가져오기 및 로컬 수신 확인

구독 그룹을 열고 메모와 주소를 추가한 뒤 저장하고 업데이트한 다음 활성 서버를 선택하세요. 코어가 시작된 것을 확인한 뒤 데스크톱 프록시를 설정합니다. 로그에 포트 사용 중 오류가 나오면 다른 프록시 프로그램과 중복 인스턴스를 먼저 종료하세요. 일반적인 기본 예시 포트를 확인하려면 아래 명령을 사용할 수 있습니다. 로컬 설정이 다르면 실제 포트 번호로 바꾸세요.

ss -ltnp 'sport = :10808'
ss -ltnp 'sport = :10809'

명령 결과가 없다고 해서 반드시 오류인 것은 아닙니다. 해당 포트에서 수신 중인 서비스가 없거나 클라이언트가 다른 포트를 사용할 수 있고, 일부 프로세스 정보는 권한에 따라 보이지 않을 수도 있습니다. 예시 포트만 보고 문제를 단정하지 말고 클라이언트 설정을 먼저 확인하세요. 일반적인 로컬 사용에서는 루프백 주소에 바인딩하는 것이 좋습니다. LAN 기기에서 사용해야 하는 경우에만 외부 수신과 방화벽 규칙을 검토하세요.

데스크톱 프록시와 터미널 환경 변수 구분

데스크톱 환경마다 시스템 프록시를 저장하는 방식이 달라 클라이언트의 자동 설정이 모든 앱에 적용되지 않을 수 있습니다. 시스템 프록시를 켠 뒤 데스크톱 네트워크 설정에서 모드와 포트를 확인하고 브라우저로 테스트하세요. 트레이 아이콘이 표시되는지와 코어가 작동하는지는 별개의 문제입니다. 트레이를 지원하지 않는 환경에서는 창과 로그를 확인하세요.

터미널 프로그램은 자체 프록시 처리 규칙을 따르는 경우가 많아 데스크톱 설정을 사용하지 않을 수 있습니다. 테스트할 때는 로그인 환경 전체를 먼저 수정하는 대신 단일 명령에만 프록시를 지정할 수 있습니다. 아래 예시는 HTTP 수신 포트 10809와 SOCKS 수신 포트 10808을 가정합니다. 실제 사용 전 포트를 확인하세요. 테스트 대상에서 웹페이지가 반환돼도 모든 업무 프로토콜이 작동한다는 뜻은 아닙니다.

curl --proxy http://127.0.0.1:10809 --head https://example.com
curl --proxy socks5h://127.0.0.1:10808 --head https://example.com

두 번째 명령의 socks5h는 대상 도메인 이름을 프록시 측에서 해석한다는 뜻이며 일부 로컬 DNS 해석 방식과 다릅니다. 터미널 테스트는 성공하지만 브라우저가 실패하면 데스크톱 프록시나 브라우저 설정을 확인하세요. 둘 다 실패하면 수신 상태, 활성 서버, 로그를 살펴보세요. 환경 변수를 설정한 터미널은 데스크톱 프록시를 꺼도 로컬 포트를 계속 가리킬 수 있습니다.

TUN, 권한, 기본 경로를 신중하게 설정

TUN 사용 여부는 클라이언트 빌드, 시스템 기능, 권한 부여 방식에 따라 다르므로 실제 인터페이스의 안내를 따르세요. 가상 인터페이스 생성에 실패하면 로그에서 권한이나 기기 지원 문제를 확인하세요. 프로그램을 항상 높은 권한으로 실행하도록 바꾸지 마세요. 원격으로 접속 중인 기기라면 복구 방법을 확보해야 합니다. 기본 경로를 변경하면 사용 중인 원격 세션이 끊길 수 있습니다.

다른 VPN, 컨테이너 네트워크, 추가 방화벽 관리 도구가 설치되어 있다면 라우팅과 규칙을 각각 확인하세요. 연결을 복구하려고 시스템 방화벽을 바로 비우지 마세요. 다른 서비스가 중단될 수 있습니다. 클라이언트를 종료한 다음 직접 연결을 테스트하고 데스크톱 프록시와 터미널 환경 변수가 남아 있는지 확인하세요. 필요하면 새 터미널을 열어 깨끗한 세션에서 다시 테스트하세요.

업데이트 전에 구독 그룹과 사용자 지정 규칙을 백업하고 같은 패키지 관리 방식으로 업데이트하세요. 업데이트 후 인터페이스에만 문제가 생겼다면 데스크톱 환경과 오류 출력을 기록하고 설정을 바로 삭제하지 마세요. 코어에서 설정 파싱 오류가 발생하면 사용자 지정 매개변수가 현재 지원 범위에 맞는지 확인하세요. 그래픽 문제, 패키지 문제, 네트워크 문제를 따로 기록해야 되돌릴 계층을 판단할 수 있습니다.

Android: 구독 및 VPN 권한

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 권장합니다. V2Fly 코어가 필요하고 설정이 호환된다면 v2flyNG를 대안으로 선택할 수 있습니다. Android 다운로드에서 기기에 맞는 arm64 패키지를 먼저 받고, 아키텍처를 확인하기 어렵거나 기기 환경이 특수하면 범용 버전 안내를 살펴보세요. 화면을 비교하려고 클라이언트 두 개의 연결 서비스를 동시에 시작하지 마세요.

앱 설치 및 시스템 권한 허용

다운로드한 파일을 열어 설치할 때 시스템에서 해당 출처의 앱 설치를 허용하라고 요청할 수 있습니다. 출처를 확인한 뒤 이번 설치에 사용하는 브라우저나 파일 관리자에만 필요한 권한을 부여하세요. 설치에 실패하면 시스템 안내를 확인하세요. 저장 공간 부족, 아키텍처 불일치, 시스템 요구 사항, 기존 앱과 서명 충돌은 각각 해결 방법이 다르며 구독을 다시 가져온다고 해결되지 않습니다.

같은 이름의 앱이 이미 설치되어 있다면 백업 없이 바로 삭제하지 마세요. 기존 구독과 규칙이 저장되어 있는지 확인하고 정상적으로 덮어쓸 수 있는지 살펴보세요. 시스템에서 서명이 다르다고 안내하면 설치 출처를 확인하고 앱을 혼합 설치하지 마세요. 앱을 제거하면 데이터도 함께 삭제될 수 있습니다. 서버 이름만으로는 구독 URL 전체와 로컬 설정을 복원할 수 없습니다.

구독 그룹 생성 및 활성 항목 선택

구독 설정을 열고 항목을 추가해 메모와 주소를 입력한 다음 업데이트를 켜고 저장한 뒤 구독 업데이트를 실행하세요. 일부 인터페이스에서는 서버 목록과 구독 관리 메뉴가 분리되어 있으므로 대상 그룹이 업데이트되는지 확인해야 합니다. 클립보드에 개별 공유 링크가 있다면 해당 가져오기 기능을 사용하세요. 네트워크에서 데이터를 가져오는 구독 URL 입력란에 넣지 마세요.

업데이트가 성공하면 목록으로 돌아가 활성 서버를 선택하고 연결을 시작하세요. 메모는 표시용일 뿐 인증에는 사용되지 않습니다. 주소, 포트, 사용자 식별자, 전송 및 보안 매개변수는 서버 설정과 일치해야 합니다. 서버 이름에 특정 용도가 적혀 있다고 해서 모든 프로토콜이나 앱을 지원한다고 추측하지 마세요. 서비스 제공자가 구독을 업데이트한 뒤에는 활성 항목이 그대로 있는지도 확인하세요.

설정의 ‘안전하지 않은 연결 허용’은 네트워크 오류를 해결하는 만능 옵션이 아닙니다. 인증서 오류가 발생하면 시스템 시간, 대상 도메인, 서비스 안내를 먼저 확인하고 인증서 검증은 유지하세요. 검증을 임의로 끄면 연결의 보안 경계가 달라지며 주소 만료, 포트 연결 실패, 계정 정지 문제는 해결되지 않습니다.

로컬 VPN 트래픽 처리와 앱 적용 범위

처음 연결할 때 시스템에서 VPN 연결 요청을 표시하는 경우가 많습니다. 방금 설치한 클라이언트가 요청한 것이 맞는지 확인한 뒤 허용하세요. 이 권한은 기기에서 트래픽 처리 경로를 만드는 데 사용되며 원격 서버가 사용 가능한지 검증했다는 뜻은 아닙니다. 시스템에 연결 표시가 나타나도 실제 요청을 보내고 앱 로그에서 코어의 연결이 완료됐는지 확인해야 합니다.

Android의 로컬 VPN 방식은 데스크톱의 시스템 프록시 설정과 다르므로 Windows 프록시 페이지의 항목을 그대로 따라 할 필요가 없습니다. 시스템에서는 보통 이 방식의 VPN 서비스를 하나만 활성화할 수 있어 같은 방식을 사용하는 다른 네트워크 도구가 연결을 차지할 수 있습니다. 자동으로 연결이 끊기면 구독을 삭제하기 전에 다른 서비스가 실행 중인지 확인하세요.

앱별 프록시를 켰다면 현재 모드가 ‘선택한 앱만 프록시 사용’인지 ‘선택한 앱은 프록시 우회’인지 확인하세요. 두 목록의 의미는 서로 반대이므로 잘못 이해하면 브라우저는 되는데 다른 앱은 연결되지 않을 수 있습니다. 적용 범위를 바꾼 뒤 연결을 다시 설정하고 대상 앱을 여세요. 필요하다면 앱 필터를 사용하지 않는 기본 설정으로 먼저 확인하세요.

네트워크 전환, 절전, 도메인 해석 확인

Wi-Fi에서 모바일 네트워크로 전환하면 기존 연결을 다시 설정해야 할 수 있습니다. 먼저 모바일 데이터 자체가 작동하는지 확인한 다음 클라이언트를 다시 연결하세요. 특정 Wi-Fi에서는 되지만 모바일 네트워크에서 실패한다면 네트워크 차이를 기록하고 IPv6, 대상 포트, DNS 경로를 살펴보세요. 자동 재연결이 무한 재시도를 뜻하지는 않습니다. 계속 실패하면 일시 중지하고 관련된 첫 오류를 확인하세요.

시스템의 비공개 DNS, 앱 자체의 암호화 DNS, 클라이언트 DNS가 동시에 설정되어도 역할은 서로 다를 수 있습니다. 다른 요청은 정상인데 도메인만 실패한다면 현재 설정을 기록한 다음 하나씩 확인하세요. 모든 DNS 경로를 한 번에 바꾸면 연결이 복구되더라도 어떤 설정이 영향을 줬는지 알 수 없습니다.

마지막으로 연결을 중지한 뒤 상태를 확인하세요. 상시 연결 VPN이나 VPN 미사용 연결 차단을 켰다면 클라이언트를 멈춘 뒤에도 직접 연결이 되지 않을 수 있습니다. 이는 시스템 정책에 따른 동작입니다. 필요에 따라 해당 정책을 유지하거나 조정하고 네트워크 고장으로 오해하지 마세요. 클라이언트를 바꾸기 전에 기존 서비스를 중지한 다음 새 앱을 가져와 프로토콜 지원과 백그라운드 안정성을 각각 확인하세요.

시스템 프록시, TUN, 트래픽 처리

앱이 트래픽을 보내는 방식을 먼저 확인한 뒤 처리 방법을 선택하세요. 시스템 프록시는 앱에 ‘프록시 주소가 어디인지’를 알려줄 뿐이며 실제 사용 여부는 앱에 달려 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 일치하는 트래픽을 처리 프로그램에 전달합니다. 둘 다 원격 서버가 아니며 도메인이 직접 연결될지 프록시를 사용할지를 직접 결정하지 않습니다. 이는 주로 라우팅 규칙에 따라 정해집니다.

트래픽 처리 범위와 아웃바운드 규칙 구분

‘시스템 프록시 켜기’와 ‘전역 라우팅 사용’은 다른 작업입니다. 전자는 앱 요청이 클라이언트로 들어오는지 정하고, 후자는 들어온 요청이 어떤 아웃바운드를 사용할지 정합니다. 전역 라우팅만 바꿔도 시스템 프록시를 무시하는 앱의 네트워크 경로가 강제로 바뀌지는 않습니다. TUN을 켰다고 모든 요청이 반드시 원격 프록시를 거치는 것도 아닙니다. 직접 연결 규칙이 적용될 수 있습니다.

시스템 프록시 지우기, 자동 설정, 변경 안 함은 서로 다른 관리 작업입니다. 지우기는 일반적으로 현재 관리 중인 시스템 프록시 설정을 제거하고, 자동 설정은 클라이언트의 수신 주소를 기록하며, 변경 안 함은 현재 시스템 상태를 유지합니다. 구체적인 동작은 클라이언트 안내를 따르세요. 특히 조직 정책이나 수동 설정이 이미 있다면 작업 전에 기존 값을 기록하세요.

최소 범위부터 단계적으로 활성화

먼저 시스템 프록시를 사용하는 브라우저가 정상적으로 접속되는지 확인한 다음 대상 앱이 해당 설정을 따르는지 테스트하세요. 대상 앱에서 프록시를 직접 지정할 수 있다면 로컬 HTTP 또는 SOCKS 진입점을 사용해 코어와 서버가 작동하는지 확인할 수 있습니다. 이후 TUN에 실패하더라도 문제를 시스템 트래픽 처리 계층으로 좁힐 수 있어 구독 연결 전체를 다시 의심하지 않아도 됩니다.

TUN을 켜기 전에 다른 트래픽 처리 도구를 종료하고 작업을 저장한 다음 안내에 따라 필요한 권한을 부여하세요. 시작 후 인터페이스 생성, 라우트 설치, DNS 초기화가 성공했는지 확인하세요. 빌드에 따라 보조 구성 요소가 다를 수 있으므로 다른 플랫폼의 드라이버 처리 절차를 그대로 따라 하지 마세요. 로그가 인터페이스 초기화 단계에서 멈춘다면 먼저 로컬 기기 문제를 해결해야 합니다.

TUN과 시스템 프록시를 함께 사용할지는 클라이언트 구현과 사용 환경에 따라 달라지므로 일괄적으로 판단하면 안 됩니다. 기본 상태를 확인할 때는 주요 트래픽 처리 경로를 하나만 유지하세요. 두 가지를 함께 사용해야 한다면 로컬 프록시 연결이 다시 잘못 처리되지 않는지 확인하세요. 연결이 반복되거나 리소스 사용량이 비정상적이고 출구가 계속 바뀌면 단일 경로로 되돌려 점검하세요.

UDP, LAN, 가상 네트워크 확인

웹페이지가 열린다고 UDP 앱도 작동한다고 볼 수는 없습니다. 대상 앱의 UDP 사용 여부, 선택한 프로토콜과 서버의 지원 여부, 클라이언트 인바운드의 트래픽 처리 여부를 각각 확인해야 합니다. UDP가 실패한다고 전역 라우팅으로 바꾸지 마세요. 규칙은 아웃바운드를 선택할 수 있지만 서버가 제공하지 않는 기능을 추가할 수는 없습니다. 먼저 서비스 안내를 확인한 다음 로그에서 연결 유형을 살펴보세요.

프린터, 파일 공유, LAN 관리 페이지는 보통 로컬에서 접근 가능한 경로가 필요합니다. TUN을 켠 뒤 해당 리소스를 사용할 수 없다면 LAN 주소가 원격으로 잘못 전달되는지 확인하고 클라이언트의 제외 규칙을 살펴보세요. 조직 내부 네트워크에는 여러 사설 대역이 사용될 수 있습니다. 집 공유기의 대역 하나만 처리하고 전체가 해결됐다고 판단하지 마세요.

가상 머신, 컨테이너, 다른 VPN도 네트워크 인터페이스, DNS, 라우트를 추가할 수 있습니다. 충돌이 발생하면 현재 켜진 네트워크 도구를 기록하고 하나씩 일시 중지해 확인하세요. 모든 라우트를 지우지 마세요. 원격 근무나 원격 관리 환경에서는 특히 주의해야 합니다. 트래픽 처리 규칙을 변경하기 전에 로컬 복구 방법이 있는지 확인해 현재 연결을 유지하는 경로까지 바뀌지 않도록 하세요.

요청 경로로 결과 확인

확인할 때 앱, 수신 진입점, 라우팅 규칙 일치 여부, 원격 연결을 각각 살펴보세요. 로그에 앱 요청이 없다면 트래픽 처리부터 확인합니다. 요청이 들어왔지만 직접 연결 규칙에 걸렸다면 규칙을 확인하세요. 프록시 규칙에 걸린 뒤 연결이 시간 초과될 때 서버와 네트워크를 점검하면 됩니다. 자세한 활성화 범위는 v2rayN TUN 모드 안내를 참고하세요. TUN을 모든 연결 문제의 만능 해결책으로 보지 마세요.

연결을 끈 뒤 같은 앱에서 다시 테스트해 결과가 예상과 일치하는지 확인하세요. 브라우저는 기존 연결을 재사용할 수 있고 일부 앱도 자체 연결 풀을 유지하므로 새 경로를 확인하려면 새 요청을 만들어야 합니다. 성공 상태를 기록한 다음 자동 시작, 앱별 적용 범위, 복잡한 제외 규칙을 하나씩 추가하세요. 기능을 한꺼번에 적용하는 것보다 유지 관리하기 쉽습니다.

분할 라우팅과 DNS 설정

라우팅은 코어에 들어온 요청의 아웃바운드를 선택하고 DNS는 도메인을 IP 주소로 해석합니다. 서로 영향을 주지만 같은 기능은 아닙니다. 먼저 어떤 서비스는 직접 연결할지, 어떤 서비스는 프록시를 사용할지, 어떤 서비스는 차단할지 정한 다음 목적에 맞는 사전 설정을 선택하세요. 출처가 불분명한 대규모 규칙 모음을 기존 설정에 통째로 덮어쓰지 마세요.

사전 설정으로 안정적인 기준 만들기

전역, 중국 본토 우회, 블랙리스트 같은 이름은 클라이언트의 사전 설정을 가리키며 실제 규칙은 규칙 리소스와 설정에 따라 달라질 수 있습니다. 전역은 일반적인 대상을 프록시로 보내는 경향이 있지만 필요한 로컬 예외를 유지할 수 있습니다. 중국 본토 우회는 도메인과 IP 분류를 사용합니다. 블랙리스트의 실제 의미는 규칙 내용을 확인해야 하며 이름만 보고 모든 대상의 경로를 추측해서는 안 됩니다.

사전 설정을 바꾼 뒤 준비한 직접 연결 대상과 프록시 대상에 각각 요청을 보내고 라우팅 규칙이 어떻게 적용됐는지 확인하세요. 출구 IP만 확인하지 마세요. 특정 요청의 경로만 보여 줍니다. 앱 하나가 인증, 콘텐츠, 업데이트 등 여러 도메인에 동시에 접속할 수 있습니다. 메인 페이지는 열리는데 특정 기능만 실패한다면 전체 설정을 전역으로 바꾸기보다 해당 요청을 확인하세요.

규칙 순서와 도메인 일치 방식 이해

대부분의 규칙은 순서대로 판단하며 먼저 일치한 규칙에 따라 처리 방향이 정해집니다. 특정 대상에 예외를 추가하려면 해당 대상을 덮는 포괄 규칙보다 앞에 배치하세요. 서비스 주소는 바뀔 수 있으므로 임의로 특정 IP를 고정하는 것보다 도메인 규칙을 사용하는 편이 관리하기 쉽습니다. 다만 앱이 IP에 직접 접속한다면 도메인 규칙이 적용되지 않을 수 있으므로 별도로 확인해야 합니다.

아래는 사설 주소와 지정 도메인을 직접 연결하는 Xray 형식 라우팅 예시입니다. 단독으로 실행할 수 있는 완전한 설정은 아니며 아웃바운드 태그가 기존 설정과 일치해야 합니다. 그래픽 클라이언트가 설정을 생성하는 경우 해당 라우팅 편집 화면에서 같은 의미로 설정하는 것을 우선하세요. 실행 중 생성되는 파일을 바로 덮어쓰면 다음 시작 때 다시 생성될 수 있습니다.

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

domain 일치는 지정한 도메인과 하위 도메인까지 처리할 수 있으며, 호스트를 정확히 지정하려면 full 일치를 고려할 수 있습니다. geosite와 geoip는 해당 리소스 파일이 있어야 하며 분류 이름도 실제로 존재해야 합니다. AsIs는 ‘도메인을 절대 해석하지 않음’을 뜻하지 않습니다. 라우팅 단계의 정책을 설명하는 값으로, 다른 연결이나 DNS 처리 과정에서 해석이 일어날 수 있습니다. 이 필드 하나만으로 전체 요청 경로를 판단하지 마세요.

대상 도메인과 서버 도메인의 해석을 따로 확인

클라이언트는 사용자가 접속하는 대상 도메인을 해석해야 할 수도 있고, 프록시 서버의 도메인을 먼저 해석해야 할 수도 있습니다. 후자가 아직 연결되지 않은 프록시 경로에 의존하면 시작 단계에서 순환 문제가 생길 수 있습니다. 초기화 중 해석 오류가 계속되면 어느 도메인에서 발생하는지 구분하세요. 아직 사용할 수 없는 프록시로 모든 DNS 요청을 무조건 보내지 마세요.

시스템, 브라우저, 클라이언트에서 각각 DNS를 설정할 수 있습니다. 브라우저에서 별도의 암호화 DNS를 사용하면 클라이언트 로그에 예상한 시스템 DNS 요청이 나타나지 않을 수 있습니다. TUN을 켜면 클라이언트가 일부 DNS 트래픽을 처리할 수도 있습니다. 문제를 확인할 때는 누가 해석을 요청하고 누가 응답하며 요청이 어떤 경로를 지나는지 정리한 뒤 조정할 계층을 결정하세요.

규칙이나 DNS를 변경해도 기존 캐시와 연결이 계속 사용될 수 있습니다. 새 요청을 보내고 필요하면 대상 앱을 다시 시작한 뒤 결과를 확인하세요. 페이지를 한 번 새로고침해도 달라지지 않는다고 규칙을 계속 추가하지 마세요. 임시 설정이 쌓이면 복잡한 라우팅 아래에 실제 DNS 문제가 가려지고, 복구할 때도 유지할 설정을 판단하기 어려워집니다.

IPv6 및 분할 라우팅 범위 확인

IPv4와 IPv6를 모두 사용할 수 있는 네트워크에서는 앱에 따라 우선 사용하는 주소 체계가 다를 수 있습니다. 특정 도메인이 간헐적으로 실패하면 로그에 표시된 대상 주소를 기록하고 각 경로가 모두 사용 가능한지 확인하세요. 주소 체계를 하나로 제한하면 원인을 찾는 데 도움이 될 수 있지만, 특히 IPv6에 의존하는 네트워크에서는 분석 없이 IPv6를 계속 비활성화하는 것을 일반적인 해결책으로 삼지 마세요.

조직 내부 도메인은 보통 조직에서 제공하는 DNS 경로를 사용해야 합니다. 공용 DNS에는 내부 레코드가 없을 수 있습니다. 내부 웹페이지에 접속할 수 없다면 도메인 해석과 인트라넷 라우팅을 함께 확인하세요. 직접 연결 규칙만 추가해서는 해결되지 않을 수 있습니다. 반대로 DNS가 올바르게 해석돼도 라우팅이 도달 가능한 것은 아니므로 두 단계를 따로 검증해야 합니다.

목적이 분명한 규칙을 한 번에 하나씩 추가하고 용도를 메모한 뒤 변경 전 설정을 보관하세요. 국내외 분할 라우팅 설정을 먼저 참고해 기본 구성을 만들고, 사용자 지정 규칙 문법에 따라 예외를 처리하세요. 규칙이 구체적일수록 확인할 대상이 명확하고 서비스 주소가 바뀌었을 때 관리할 위치도 쉽게 찾을 수 있습니다.

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

문제 해결은 증상을 먼저 설명한 다음 변경할 설정을 정해야 합니다. 플랫폼, 클라이언트, 트래픽 처리 방식, 활성 서버, 오류가 발생한 작업을 기록하세요. 예를 들면 ‘구독 업데이트 실패’, ‘TUN을 켠 뒤 인트라넷 접속 불가’와 같습니다. 단순히 ‘연결 안 됨’이라고만 적으면 구독 가져오기, 코어 시작, 트래픽 처리, 원격 접속 중 어느 단계인지 알 수 없어 필요한 증거도 달라집니다.

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

먼저 주소가 온전한지와 계정 상태를 확인하고 업데이트 응답이 네트워크 오류인지, 웹페이지 내용인지, 파싱 오류인지 살펴보세요. 네트워크 오류는 현재 가져오기 경로를 확인해야 합니다. 웹페이지 내용은 로그인 페이지나 오류 페이지일 수 있습니다. 파싱 오류라면 구독 형식과 클라이언트 지원 여부를 확인하세요. 내용이 반환됐다고 유효한 구독이라는 뜻은 아니므로 ‘다운로드 성공’이라는 표시만으로 판단하지 마세요.

업데이트 후 목록이 비어 있다면 먼저 검색 조건을 지우고 대상 그룹으로 전환해 해당 그룹의 업데이트가 허용되어 있는지 확인하세요. 업데이트 전 설정을 보관하고 그룹을 반복해서 삭제하고 다시 만들지 마세요. 일부 서버만 사라졌다면 서비스 제공자가 구독을 변경했거나 특정 설정을 파싱할 수 없을 수 있습니다. 누락된 유형과 오류 정보를 기록해 서비스 안내와 비교하고 서버 매개변수를 직접 만들어 넣지 마세요.

코어 시작 실패 또는 로컬 포트 문제

이번 시작 이후 로그에서 관련 오류가 처음 나타난 지점을 찾으세요. 포트 사용 중 오류라면 중복 인스턴스를 확인하고, 설정 필드 오류라면 최근 변경을 되돌리고, 파일 누락이라면 설치가 완전한지 확인하세요. 이후에 발생하는 수많은 연결 실패는 첫 시작 오류의 연쇄 결과일 수 있습니다. 코어가 시작되지 않은 상태에서 뒤이어 나타나는 시간 초과를 하나씩 처리해도 해결되지 않습니다.

여러 배포 형식을 사용 중이라면 현재 실행 경로를 확인하세요. 한 프로그램의 설정을 수정했는데 실제로는 다른 프로그램을 실행할 수 있습니다. 업데이트 후 이전 디렉터리 전체를 새 프로그램 위에 바로 덮어쓰지 말고 기본 실행을 확인한 다음 클라이언트가 지원하는 방식으로 설정을 복원하세요. 실행 파일, 런타임 구성 요소, 사용자 설정은 각각 구분해야 하며 모든 파일이 설정 파일인 것은 아닙니다.

브라우저는 되지만 다른 앱은 연결되지 않음

대상 앱이 시스템 프록시를 사용하는지, 별도 프록시나 앱별 제외 설정이 있는지 먼저 확인하세요. 로그에 해당 요청이 없다면 앱에서 클라이언트까지의 경로를 살펴보세요. 요청이 기록되고 프록시 규칙에 일치했다면 프로토콜, 원격 연결, 앱의 네트워크 동작을 확인하세요. TUN이 필요하다면 앞 장의 안내에 따라 단계적으로 켜고 구독의 인증 필드를 먼저 바꾸지 마세요.

웹페이지는 열리지만 음성, 게임, 실시간 기능이 실패한다면 UDP와 서비스 지원 여부를 확인하세요. 웹 테스트 결과로 다른 프로토콜의 작동 여부를 판단할 수 없습니다. 다운로드 작업은 앱 자체 네트워크 스택이나 여러 도메인과 관련될 수도 있습니다. 서버를 계속 바꾸기보다 실패한 기능과 시간대를 기록하고 주변 로그를 확인하세요.

핸드셰이크 오류, 시간 초과, 일부 기능만 실패

인증서나 핸드셰이크 오류가 발생하면 시스템 시간, 서버 이름, 구독 최신 여부를 먼저 확인한 다음 현재 코어가 해당 매개변수를 지원하는지 살펴보세요. REALITY 설정의 공개 키, 서버 이름, 관련 식별자는 서버와 일치해야 하므로 경험에 따라 임의로 바꾸지 마세요. 구독 서버 매개변수가 변경됐다면 우선 업데이트하고 서비스 제공자에게 확인하세요. 보안 검증을 끄지 마세요.

연결 시간 초과는 서버 주소에 도달할 수 없는 경우, 대상에 접속할 때 시간 초과되는 경우, DNS 시간 초과를 구분해야 합니다. 특정 네트워크에서만 실패한다면 Wi-Fi, 모바일 네트워크, 유선 연결의 차이를 기록하세요. 특정 서버에서만 실패한다면 같은 트래픽 처리와 라우팅 설정으로 다른 서버를 비교하세요. 나머지 조건을 고정해야 비교 테스트 결과를 해석할 수 있습니다.

문제 증거를 보관하고 정상 기준으로 복구

문제를 전달할 때 오류가 발생한 시간, 작업 순서, 민감한 내용을 가린 로그를 보관하세요. 구독 URL, 사용자 식별자, QR 코드, 계정 정보를 제거하세요. 로그의 대상 도메인에도 개인 사용 정보가 드러날 수 있으므로 필요한 부분만 남기세요. 도움을 받으려고 설정 디렉터리 전체를 묶어 보내거나 인증 정보가 포함된 백업을 공개된 곳에 올리지 마세요.

복구할 때는 가장 최근 변경을 먼저 되돌리고 클라이언트 하나, 서버 하나, 트래픽 처리 방식 하나를 사용하는 기본 상태로 돌아가세요. 정상적으로 작동한 설정을 간단히 기록한 다음 사용자 지정 규칙과 자동 시작을 하나씩 다시 적용하세요. 일반적인 문제는 문제 해결 가이드에서 확인할 수 있습니다. 설정 순서를 처음부터 다시 따라야 한다면 빠른 시작 가이드로 돌아가세요. 전체 환경을 먼저 다시 설치할 필요는 없습니다.