플랫폼별 설치 및 설정

공통 준비 사항

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

클라이언트는 그래픽 인터페이스와 구독 관리, 시스템 설정을 담당하고, 코어는 연결 수립과 프로토콜 처리, 라우팅을 담당합니다. 데스크톱에서는 v2rayN을, Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 권장합니다. V2Fly 코어와 호환되는 환경이 필요한 경우 v2flyNG를 고려하세요. 클라이언트를 설치해도 사용할 수 있는 서버가 생기는 것은 아닙니다. 시작하기 전에 사용 권한이 있는 구독 주소, 단일 공유 링크 또는 전체 설정 파일과 서비스 제공자가 안내한 프로토콜 및 전송 방식 정보를 준비해야 합니다.

먼저 받은 연결 정보의 형식을 확인하세요. 프로토콜 이름으로 시작하는 공유 링크는 보통 서버 하나를 나타냅니다. 일반 웹 주소는 구독 API일 수도 있고 관리 페이지일 수도 있으므로 서로 바꿔 사용할 수 없습니다. 전체 JSON 설정에는 인바운드, 아웃바운드, 라우팅과 DNS가 함께 포함될 수 있어 구독 주소 입력란에 그대로 붙여 넣으면 안 됩니다. 반복해서 업데이트를 누르기보다 가져오기 전에 형식을 확인하는 편이 효과적입니다. 자세한 메뉴와 형식 차이는 구독 링크 가져오기 가이드를 참고하세요.

구독 주소에는 로그인 정보가 포함되는 경우가 많으므로 계정 정보처럼 안전하게 보관하세요. 주소 전체가 보이는 화면을 공개하거나 출처가 불분명한 웹사이트에 형식 변환을 맡기지 마세요. 문제를 설명할 때는 프로토콜, 전송 방식, 오류 메시지만 남기고 주소의 쿼리 매개변수, 사용자 식별 정보와 비밀번호는 가리세요. 기기를 바꿀 때는 클라이언트의 내보내기 기능을 우선 사용하고, 내보낸 파일이 서버 목록인지 로컬 설정을 포함한 전체 백업인지 확인하세요.

아키텍처, 네트워크 및 권한 확인

시스템의 기기 정보 화면에서 운영체제, 프로세서 아키텍처, 설치 파일 유형을 확인하세요. 데스크톱용 다운로드의 x64와 arm64는 명령어 집합을 뜻하므로 기기 브랜드만으로 판단할 수 없습니다. macOS에서는 '이 Mac에 관하여'에서 칩을 확인하고, Linux에서는 시스템 설정의 '정보'에서 아키텍처를 확인할 수 있습니다. Android arm64 패키지는 대부분의 최신 기기에서 사용할 수 있으며, 아키텍처를 확인하기 어렵다면 범용 패키지를 먼저 선택하세요. 설치 파일은 클라이언트 다운로드 페이지에서 확인할 수 있으며 이 안내서에는 파일을 별도로 제공하지 않습니다.

문제를 진단하기 전에 다른 프록시나 터널 프로그램을 종료하고 트래픽을 처리하는 방식을 하나만 남기세요. 일반 네트워크가 정상적으로 연결되는지 확인하고, 브라우저 로그인이 필요한 네트워크 인증을 마친 뒤 시스템 날짜, 시간, 시간대를 올바르게 설정하세요. 시간 오차는 TLS 인증서 검증 실패를 일으킬 수 있고, 네트워크 인증이 끝나지 않으면 구독 요청이 로그인 페이지로 리디렉션될 수 있습니다. 두 경우 모두 설정 오류처럼 보이지만 클라이언트 외부에서 먼저 해결해야 합니다.

일반 프록시와 TUN을 나눠 테스트하세요. 일반 프록시는 보통 시스템 프록시 설정이나 로컬 수신 포트만 변경합니다. TUN은 가상 네트워크 인터페이스, 라우팅과 DNS도 다루므로 관리자 권한이나 보조 서비스가 필요할 수 있습니다. 일반 프록시를 먼저 확인한 다음 TUN을 켜면 '서버에 연결할 수 없음'과 '시스템 트래픽 처리 실패'를 구분할 수 있습니다. 처음부터 코어, DNS, 라우팅과 권한을 한꺼번에 바꾸지 마세요. 연결이 복구되더라도 어떤 변경이 효과가 있었는지 파악하기 어렵습니다.

복구할 수 있는 기준 설정 만들기

로컬 수신 주소와 포트를 기록해 두세요. SOCKS는 127.0.0.1:10808, HTTP는 127.0.0.1:10809를 예로 들 수 있지만 실제 설정과 시작 로그를 기준으로 확인해야 합니다. 일부 빌드는 혼합 포트를 사용하므로 두 포트를 각각 열지 않을 수도 있습니다. 루프백 주소는 현재 기기에서만 접근할 수 있어 초기 설정에 적합합니다. 특별한 이유가 없다면 모든 네트워크 인터페이스에서 수신하도록 바꾸거나 방화벽의 인바운드 규칙을 추가하지 마세요.

설치가 끝나면 구독을 업데이트하거나 규칙을 조정하기 전에 정상 작동이 확인된 설정을 백업하세요. 기준 설정에는 최소한 현재 서버, 코어 유형, 로컬 포트, 시스템 프록시 상태, 라우팅 모드와 TUN 활성화 여부가 포함되어야 합니다. 백업 파일은 접근을 통제할 수 있는 위치에 보관하세요. 복원하려면 클라이언트를 종료한 다음 해당 클라이언트의 백업 기능으로 가져와야 실행 중인 프로그램이 이전 상태를 다시 저장하는 일을 막을 수 있습니다. 기기 간에 설정을 옮길 때 설정 디렉터리, 권한과 절대 경로가 모두 같다고 가정하지 마세요.

버튼 색상만으로 정상 여부를 판단하지 마세요. 시작 로그에 오류가 없는지, 앱이 현재 로컬 포트를 사용하는지, 대상 요청의 연결 기록이 남는지, 종료 후 시스템 네트워크가 복구되는지 차례로 확인하세요. 클라이언트의 연결 테스트는 특정 방식의 탐지 결과만 보여주므로 브라우저나 실제 업무용 앱의 테스트를 대신할 수 없습니다. 이 점검을 마친 뒤 해당 플랫폼 안내를 확인하면 설치, 가져오기, 코어, 트래픽 처리 중 문제가 발생한 지점을 명확히 구분할 수 있습니다.

Windows 설치 및 설정

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

Windows 다운로드 페이지에서 v2rayN을 선택하세요. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하고 클래식 WPF 버전은 Windows 인터페이스 환경을 사용합니다. 메뉴 배치, 설정 디렉터리와 기능 위치가 다를 수 있으므로 같은 포트를 비교하려고 두 버전을 동시에 실행하지 마세요. 인터페이스 차이가 궁금하다면 Desktop 버전과 WPF 버전 선택 안내를 참고하세요. 먼저 한 버전으로 기본 설정을 마치고 정상 작동을 확인한 뒤 이전 여부를 결정하세요.

설치 프로그램의 안내에 따라 설치 위치와 바로 가기를 선택하세요. 기존 설치를 업그레이드하기 전에 트레이의 클라이언트를 종료하고 구독과 로컬 설정을 백업하세요. 기본 창만 닫아도 백그라운드 프로세스가 계속 실행될 수 있습니다. 설치 후 시작 메뉴에서 실행하고 로그에 실행 환경, 코어 파일 또는 규칙 리소스 누락이 표시되는지 확인하세요. 시스템 보안 경고가 나타나면 파일 출처와 게시자 정보를 먼저 확인하고, 모든 시스템 보호 기능을 끄는 방식으로 해결하지 마세요.

설정 디렉터리와 프로그램 디렉터리는 다를 수 있으므로 설치 위치만 백업 위치로 간주해서는 안 됩니다. 인터페이스에 설정 디렉터리 열기 또는 설정 백업 기능이 있다면 이를 우선 사용하세요. '설정을 쓸 수 없음' 오류가 발생하면 현재 사용자에게 디렉터리 쓰기 권한이 있는지, 동기화 소프트웨어나 제어된 폴더 접근이 차단하고 있지는 않은지 확인하세요. 일반적인 사용에서 관리자 권한을 계속 사용하는 것은 바람직하지 않습니다. 서비스 설치나 TUN 권한 변경이 필요한 경우에만 인터페이스 안내에 따라 권한을 높이세요.

구독을 가져오고 사용할 서버 선택하기

v2rayN의 '구독 그룹 설정'에서 새 그룹을 만들고 알아보기 쉬운 이름과 구독 주소를 입력하세요. 처음 가져올 때는 '필터 키워드'를 비워 두고 저장한 뒤 메인 화면으로 돌아가 해당 그룹의 구독을 업데이트하세요. 업데이트 성공은 데이터를 가져와 해석했다는 뜻일 뿐입니다. 서버 목록에서 항목 하나를 선택해 활성 서버로 지정해야 합니다. 항목을 두 번 눌러 편집 창을 열었을 뿐이라면 창을 닫고 활성 표시가 실제로 바뀌었는지 확인하세요.

메뉴에 프록시를 통한 업데이트와 프록시를 사용하지 않는 업데이트가 구분되어 있다면, 사용 가능한 연결이 없는 첫 설정에서는 보통 프록시를 사용하지 않는 업데이트를 먼저 시도하세요. 연결을 사용할 수 있고 구독 API가 해당 경로를 요구하는 경우에는 프록시를 통한 업데이트를 선택하세요. 업데이트 실패를 클라이언트 문제로 단정해서는 안 됩니다. 요청 시간 초과, 웹페이지 응답, 인증 만료, 파싱 실패를 구분해야 합니다. 브라우저에서 구독 관리 페이지가 열리더라도 구독 API가 클라이언트가 인식할 수 있는 내용을 반환한다는 뜻은 아닙니다.

서버를 직접 추가할 때는 프로토콜, 주소, 포트, 사용자 식별자, 전송 방식과 TLS 설정을 같은 연결 정보에서 확인하세요. 서로 다른 예시의 전송 경로와 서버 포트를 조합하지 마세요. 저장한 뒤 선택한 코어가 해당 조합을 지원하는지 확인하세요. 특히 REALITY 같은 기능이 포함된 설정은 주의해야 합니다. 구독 업데이트로 서버 항목이 다시 생성될 수 있으므로 임시로 수정할 때는 별도 그룹에 복사해 두어 업데이트가 로컬 변경 사항을 덮어쓰지 않도록 하세요.

시스템 프록시, TUN 및 종료 후 복구

코어가 시작된 것을 확인한 뒤 '시스템 프록시'를 '시스템 프록시 자동 설정'으로 지정하세요. 일반적으로 Windows의 프록시 대상이 클라이언트의 로컬 수신 주소로 바뀌지만 모든 프로그램이 이를 따르는 것은 아닙니다. 브라우저는 대체로 시스템 프록시를 사용하지만 명령줄 도구나 자체 네트워크 스택을 구현한 소프트웨어는 별도 설정이 필요할 수 있습니다. 앱에서 SOCKS 주소를 요구하면 실제 SOCKS 수신 포트를 입력하세요. 포트 번호가 비슷하다는 이유로 HTTP와 SOCKS 유형을 혼동하지 마세요.

시스템 프록시를 따르지 않는 프로그램까지 처리해야 할 때 TUN 모드를 고려하세요. 사용 가능 여부는 선택한 빌드, 보조 백엔드와 권한 준비에 따라 달라지며, 체크박스를 선택한다고 모든 코어가 같은 기능을 지원하는 것은 아닙니다. 인터페이스 안내에 따라 필요한 서비스를 설치하거나 시작하고 가상 네트워크 카드, 라우팅과 DNS가 정상적으로 설정되는지 확인하세요. 첫 테스트에서는 기본 트래픽 처리 설정을 유지하세요. 기업 네트워크, 가상 머신과 다른 터널 프로그램에는 별도 라우팅이 있을 수 있으므로 먼저 기록한 다음 충돌 여부를 항목별로 확인하세요.

Windows에서 흔히 발생하는 가짜 오류는 프록시 설정이 남아 있는 경우입니다. 클라이언트를 종료하기 전에 '시스템 프록시 해제'를 선택한 뒤 트레이 프로세스를 정상 종료하세요. 이전에 비정상 종료했다면 '설정 → 네트워크 및 인터넷 → 프록시'에서 수동 프록시가 중지된 로컬 포트를 가리키는지 확인하세요. TUN을 끈 뒤 네트워크가 복구되었는지도 확인해야 합니다. 브라우저는 정상인데 특정 서비스 프로세스만 실패한다면 클라이언트를 바로 재설치하지 마세요. 서비스 계정의 프록시 설정은 현재 데스크톱 사용자와 다를 수 있으므로 해당 앱에서 확인해야 합니다.

최종 점검에서는 정상 시작, 서버 전환, 구독 업데이트, 종료 후 복구를 모두 확인하세요. 수동 사용이 안정된 뒤 시작 시 자동 실행을 설정해도 늦지 않습니다. 네트워크가 연결되기 전에 시작하면 자동 업데이트가 실패할 수 있으며, 이것만으로 구독이 만료됐다고 볼 수는 없습니다. 네트워크 연결을 기다린 다음 직접 업데이트하고 로그를 확인하세요. 시스템 절전 모드에서 깨어난 뒤 연결 문제가 생기면 설정을 삭제하지 말고 먼저 코어를 재시작한 뒤 절전 전 네트워크 인터페이스나 DNS 상태가 남아 있는지 확인하세요.

macOS 설치 및 설정

칩에 맞는 설치 파일 선택

Apple 메뉴에서 '이 Mac에 관하여'를 열어 칩 이름 또는 Intel 프로세서가 표시되는지 확인한 다음 macOS 다운로드 페이지에서 맞는 v2rayN 설치 파일을 선택하세요. Apple Silicon에는 arm64, Intel에는 x64를 선택합니다. 시스템 모양이나 기기 크기로 판단하지 마세요. 다운로드한 디스크 이미지를 열고 앱을 '응용 프로그램' 폴더로 드래그한 다음 해당 폴더에서 실행하세요. 이미지 안의 앱을 계속 직접 실행하면 업데이트, 권한과 앱 경로를 판단하기 어려워질 수 있습니다.

처음 실행할 때 시스템 보안 기능이 차단하면 다운로드 출처를 확인한 뒤 '시스템 설정 → 개인정보 보호 및 보안'에 표시된 절차에 따라 해당 앱을 허용하세요. 시스템 보안 기능을 한꺼번에 끄거나 출처를 알 수 없는 터미널 명령을 그대로 따라 하지 마세요. 앱을 실행할 수 없다는 메시지가 나오면 먼저 아키텍처와 시스템 요구 사항을 확인하고 다운로드가 중단되거나 설치가 불완전하지 않았는지 살펴보세요. 권한, 아키텍처와 설정 문제는 서로 다른 단계이므로 순서대로 점검해야 합니다.

업그레이드하기 전에 메뉴 막대나 백그라운드에서 실행 중인 이전 인스턴스를 종료하고 설정을 백업한 뒤 '응용 프로그램' 폴더의 앱을 교체하세요. '다운로드' 폴더, 디스크 이미지와 응용 프로그램 폴더에 여러 복사본이 있으면 로그인 항목에서 이전 버전이 실행될 수 있습니다. 실행 후 예상한 구독이 보이지 않으면 모든 정보를 다시 가져오기 전에 현재 실행 중인 앱의 위치와 사용자 계정을 먼저 확인하세요. 설정 파일은 보통 현재 사용자에게 속하므로 다른 계정으로 실행한다고 같은 설정이 자동 공유되지는 않습니다.

구독 가져오기 및 시스템 네트워크 프록시

v2rayN에서 구독 그룹 설정을 열고 알아보기 쉬운 이름으로 새 그룹을 만든 다음 구독 주소를 붙여 넣어 저장하고 구독을 업데이트하세요. 단일 공유 링크를 가져올 때는 서버 가져오기 메뉴를 사용하고 구독 주소 입력란에는 넣지 마세요. 목록이 업데이트되면 활성 서버를 선택하고 프로토콜과 코어가 호환되는지 확인하세요. 처음 테스트할 때 필터 키워드까지 켜지 마세요. 목록이 비어 있는 이유가 요청 실패인지 필터가 모든 항목을 제외했기 때문인지 구분하기 어렵습니다.

시스템 프록시를 켠 뒤 '시스템 설정 → 네트워크'에서 현재 사용하는 네트워크 서비스를 선택하고 '세부사항 → 프록시'에서 설정을 확인하세요. 시스템 설정 메뉴의 위치는 인터페이스에 따라 달라질 수 있지만 현재 활성화된 네트워크 서비스를 확인해야 한다는 점은 같습니다. Wi-Fi와 유선 네트워크는 프록시 옵션을 각각 저장할 수 있습니다. 연결 방식을 바꾼 뒤에는 프록시 주소와 포트를 다시 확인하세요. Wi-Fi에서 작동했다고 유선 네트워크에도 같은 설정이 적용되었다고 가정하지 마세요.

브라우저는 보통 시스템 프록시를 따르지만 확장 프로그램이나 브라우저 자체의 프록시 설정이 이를 덮어쓸 수 있습니다. 문제를 진단할 때는 먼저 프록시 관련 확장 프로그램을 끄고 앱에 별도 프록시가 지정되어 있는지 확인하세요. 앱이 HTTP 프록시만 지원한다면 실제 HTTP 수신 포트를 입력하고, SOCKS만 지원한다면 SOCKS 포트를 입력하세요. 서버의 원격 주소를 시스템 프록시 항목에 직접 입력하지 마세요. 시스템 프록시는 로컬 클라이언트에 연결하고, 프로토콜 핸드셰이크와 라우팅은 클라이언트가 처리해야 합니다.

TUN 권한, 절전 및 네트워크 전환

TUN 트래픽 처리는 현재 빌드의 보조 기능과 시스템 권한에 따라 달라지므로 Windows의 서비스 설치 방식을 macOS에 그대로 적용할 수 없습니다. 먼저 일반 프록시로 연결을 확인한 뒤 v2rayN의 실제 안내에 따라 필요한 권한을 준비하세요. 권한 요청 창의 내용이 방금 수행한 작업과 일치해야 합니다. 권한이 거부되었다면 시스템 설정에서 확인하고 해당 기능을 다시 시작하세요. 인터페이스에 트래픽 처리 메뉴가 없다면 관련 없는 코어 항목을 수정해 기능을 억지로 구현하지 마세요.

절전 모드에서 깨어나거나 핫스팟을 바꾸거나 Wi-Fi에서 유선 네트워크로 전환하면 기존 연결이 끊길 수 있습니다. 먼저 트래픽 처리를 껐다가 다시 켜고 로그에 현재 네트워크에 다시 연결되는지 확인하세요. 필요하면 코어를 재시작하세요. 기존 연결은 유지되는데 도메인 접속만 실패한다면 서버를 즉시 바꾸기보다 DNS와 네트워크 서비스 전환을 중점적으로 확인하세요. 기업 네트워크의 자동 프록시 설정이 시스템 옵션을 다시 변경할 수도 있으므로 네트워크 관리자 정책을 따르고 두 기능이 서로 덮어쓰지 않도록 하세요.

정상 종료하기 전에 TUN을 끄고 클라이언트가 설정한 시스템 프록시를 해제하세요. 비정상 종료 후 모든 브라우저 요청이 실패하면 현재 네트워크 서비스의 프록시 설정에서 루프백 주소를 가리키는 항목이 남아 있는지 확인하세요. 코어만 종료해도 모든 네트워크 서비스가 기본 설정으로 자동 복구되는 것은 아닙니다. 남은 프록시를 해결하려고 시스템 네트워크 서비스를 함부로 삭제하지 마세요. 클라이언트가 추가한 것으로 확인된 설정만 해제하고 기존 DNS, 자동 설정 주소와 네트워크 인증 정보는 유지하세요.

설치 경로나 권한을 확인할 때는 메인 앱과 보조 프로세스를 구분해야 합니다. 활성 상태 보기에서 프로세스가 계속 보인다고 메인 화면이 종료되지 않은 것은 아닐 수 있습니다. 반대로 화면이 정상이라고 필요한 보조 구성 요소가 작동한다는 뜻도 아닙니다. 로그의 수신 성공, 라우팅 설정과 요청 처리 결과를 기준으로 판단하세요. 일반 프록시, 필요한 TUN 트래픽 처리, 종료 후 직접 연결 복구를 각각 확인한 뒤 로그인 시 자동 실행을 설정하세요. 권한 설정이 끝나지 않은 상태를 매번 로그인할 때 반복하도록 해서는 안 됩니다.

Linux 설치 및 설정

배포판과 패키지 아키텍처 확인

데스크톱 환경에서는 v2rayN을 우선 사용하세요. Linux 다운로드 페이지에서 배포판의 패키지 형식에 맞춰 deb 또는 rpm을 선택한 뒤 프로세서 아키텍처가 x64인지 arm64인지 확인하세요. 패키지 형식이 설치 프로그램과 호환된다고 해서 모든 데스크톱 환경에서 시스템 프록시가 동일하게 작동하는 것은 아닙니다. 설치 전에 배포판 정보를 확인하고 그래픽 소프트웨어 설치 프로그램으로 파일을 여세요. 의존성 문제가 나오면 배포판의 패키지 관리 도구를 먼저 사용하고, 출처를 알 수 없는 스크립트를 일반적인 설치 방법으로 취급하지 마세요.

설치가 끝나면 애플리케이션 메뉴에서 실행하고 그래픽 클라이언트 전체를 슈퍼유저 권한으로 실행하지 마세요. 높은 권한으로 실행하면 설정이 다른 사용자 디렉터리에 기록되어 일반 사용자로 실행할 때 구독이 사라지거나 디렉터리에 쓸 수 없게 될 수 있습니다. 이미 높은 권한으로 실행했다면 프로그램을 종료하고 실제 설정 위치와 파일 소유자를 확인한 뒤 배포판의 관리 방식에 따라 바로잡으세요. 한 번 실행하려고 설정 디렉터리를 모든 사용자가 쓸 수 있게 변경하면 로컬 정보가 노출될 위험이 커집니다.

그래픽 인터페이스가 열리지 않으면 데스크톱 세션 문제와 코어 문제를 구분하세요. 디스플레이 환경, 그래픽 의존성 또는 세션 변수가 없으면 메인 창을 만들지 못할 수 있으며, 이 경우 서버 연결 단계까지 도달하지 않은 상태입니다. 메인 창은 열리지만 로그에서 코어 누락을 알린다면 설치가 완전한지, 보안 정책이 실행을 차단하지 않는지 확인하세요. 컨테이너, 원격 세션과 최소 구성 데스크톱 환경에는 시스템 프록시 연동이 충분하지 않을 수 있습니다. 이 안내서의 그래픽 인터페이스 조작 방법은 해당 환경을 위한 별도 배포 설계를 대신하지 않습니다.

구독 설정과 앱 프록시 설정 구분하기

구독 그룹 설정에 주소를 추가하고 저장한 뒤 구독을 업데이트하고 활성 서버를 선택하세요. 구독 주소에 특수 문자가 포함되어 있으면 쿼리 매개변수를 임의로 지우지 말고 전체를 붙여 넣으세요. 줄 바꿈, 앞뒤 공백 또는 복사된 웹페이지 마크업 때문에 파싱이 실패할 수 있습니다. 첫 업데이트가 실패하면 시스템 라우팅을 바꾸기 전에 네트워크 인증과 API 응답을 확인하세요. 사용 가능한 연결을 만든 뒤 프록시를 통한 업데이트를 시도하면 아직 준비되지 않은 프록시 경로에 업데이트가 의존하는 일을 방지할 수 있습니다.

GNOME, KDE 등 데스크톱 환경마다 시스템 프록시 설정 방식이 다르고 앱이 참조하는 설정도 다를 수 있습니다. v2rayN에서 시스템 프록시를 설정한 뒤에도 데스크톱의 네트워크 설정을 열어 확인하고 실제 앱에서 테스트하세요. 브라우저가 시스템 설정을 읽는다고 패키지 관리 도구나 터미널 프로그램도 같은 설정을 사용한다는 뜻은 아닙니다. 별도 설정이 필요한 프로그램은 네트워크 옵션에 로컬 프록시 유형, 주소와 포트를 입력하세요. '전역 모드'가 운영체제에서 모든 프로세스를 강제로 처리한다는 뜻은 아닙니다.

터미널의 프록시 환경 변수에는 적용 범위가 있습니다. 특정 터미널 세션에서만 설정하면 앱 메뉴에서 실행한 프로그램에는 자동 적용되지 않습니다. 로그인 환경에 추가해도 이미 실행 중인 프로세스에는 바로 적용되지 않을 수 있습니다. 처음부터 여러 시작 파일에 동시에 설정하지 마세요. 대상 앱에서 프록시가 작동하는지 확인한 다음 영구 설정 여부를 결정하세요. 설정을 해제할 때도 같은 위치를 정리해야 클라이언트를 종료한 뒤에도 중지된 로컬 포트를 가리키는 오래된 변수가 남지 않습니다.

권한, 포트 및 DNS 확인

TUN이 필요하다면 현재 빌드의 권한 안내에 따라 보조 서비스나 필요한 권한을 준비하세요. 배포판마다 서비스 관리 방식과 보안 정책이 다르므로 다른 플랫폼의 명령을 그대로 사용하지 마세요. 가상 인터페이스가 생성되었는지, 라우팅이 예상한 인터페이스를 가리키는지, DNS 요청이 의도한 처리 경로로 들어가는지 확인하세요. 데스크톱 네트워크 관리자와 클라이언트가 모두 DNS를 변경하면 연결은 되지만 도메인 확인이 불안정해질 수 있습니다. 먼저 일반 프록시로 돌아가 기본 연결을 확인한 뒤 트래픽 처리 설정을 하나씩 복구하세요.

시스템 도구로 로컬 포트 사용 여부를 확인할 수 있습니다. 아래 두 명령은 수신 상태만 확인하며 네트워크 설정을 변경하지 않습니다. 포트 번호는 현재 인터페이스에 표시된 값으로 바꾸세요. 수신 항목이 보여도 이번에 시작한 코어의 것이라고 단정할 수 없으므로 프로세스 정보와 클라이언트 로그를 함께 확인해야 합니다. 프로세스 이름이 표시되지 않는다면 권한 문제일 수 있습니다. 프로세스 목록이 비어 있다고 포트가 사용 중이지 않다고 판단하지 마세요.

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

구독은 업데이트되지만 앱이 접속하지 못한다면 앱의 프록시 설정 출처와 프로토콜 유형부터 확인하세요. 일반 프록시는 되지만 TUN이 실패하면 권한, 라우팅과 DNS를 확인하세요. 코어가 수신 대기조차 하지 않는다면 설치, 설정 구문과 파일 접근 권한을 점검해야 합니다. 이 순서로 확인하면 배포판 설정을 반복해서 바꾸지 않고 문제 상황을 유지하기 쉽습니다. 보안 정책이 실행이나 접근을 거부했다면 시스템 로그에서 구체적인 차단 항목을 확인하고 보안 정책 전체를 끄지 마세요.

종료 후 점검도 중요합니다. 먼저 TUN을 끄고 시스템 프록시를 해제한 뒤 클라이언트를 종료하고 데스크톱 네트워크 설정과 앱별 설정이 복구되었는지 확인하세요. 노트북의 네트워크를 바꾸거나 절전에서 복귀하거나 유선 네트워크 카드를 연결한 뒤에는 현재 인터페이스를 다시 확인해야 합니다. 부팅 시 실행과 사용자 로그인 시 실행은 실행 환경이 다릅니다. 그래픽 클라이언트는 보통 사용자 세션이 준비된 뒤 시작해야 합니다. 정상 작동 기준을 마련하기 전에는 백그라운드 자동 실행이나 중복 서비스 인스턴스를 추가하지 마세요. 포트 충돌이나 설정 디렉터리 분리를 일으킬 수 있습니다.

Android 설치 및 설정

v2rayNG 또는 v2flyNG 선택

Android 다운로드 페이지에서 v2rayNG를 우선 선택하세요. V2Fly 코어 환경이 필요한 경우에만 v2flyNG를 선택합니다. 두 앱은 서로 다른 애플리케이션이므로 하나를 설치한다고 다른 앱의 코어가 바뀌는 것은 아닙니다. 최신 기기 대부분은 arm64를 사용할 수 있으며 아키텍처를 확인하기 어려우면 범용 패키지를 선택하세요. 설치 전에 현재 브라우저나 파일 관리자가 앱 설치를 허용하는지 확인하세요. 실제로 설치 파일을 여는 앱에만 권한을 부여하고 사용 후에는 기기 관리 방식에 따라 해당 권한을 해제할 수 있습니다.

설치 또는 업그레이드 중 패키지 충돌, 덮어쓰기 실패, 서명이 일치하지 않는 문제가 발생하면 반복 시도를 멈추고 현재 앱의 정체와 설치 출처를 확인하세요. 서버 목록과 로컬 설정이 함께 삭제될 수 있으므로 바로 앱을 제거하지 마세요. 먼저 현재 앱의 내보내기 기능으로 필요한 정보를 저장한 다음 다른 앱을 설치했는지, 맞지 않는 패키지를 선택했는지, 이전 설치 위에 현재 패키지를 바로 설치할 수 없는지 확인하세요. 기기 저장 공간이 부족해도 설치가 실패할 수 있으므로 아키텍처 문제와 구분해 점검해야 합니다.

처음 실행할 때 기본 설정을 확인하고 출처가 불분명한 전체 설정을 바로 가져오지 마세요. 전체 설정에는 사용자 지정 DNS, 라우팅과 로컬 수신 주소가 포함되어 앱의 기본 동작이 바뀔 수 있습니다. 연결 정보가 일반 구독이라면 구독 메뉴를 사용하세요. 서버를 직접 추가해야 한다면 프로토콜, 전송 방식과 TLS를 하나씩 확인하세요. v2flyNG가 모든 Xray 기능을 대체할 수 있는 것은 아닙니다. 사용할 수 있는 기능은 앱 아이콘이나 이름이 아니라 실제 코어에 따라 달라집니다.

구독 설정 및 연결 권한

v2rayNG 메뉴에서 '구독 설정'을 열고 구독 이름과 주소를 추가한 뒤 저장하고 메인 화면에서 구독을 업데이트하세요. 인터페이스 빌드에 따라 추가 버튼 위치는 달라질 수 있지만 구독 항목을 먼저 저장하고 서버 목록을 업데이트하는 순서는 같습니다. 단일 링크는 클립보드 가져오기 메뉴로 추가하고 공유 내용을 스캔할 때는 QR 코드 메뉴를 사용하세요. QR 코드에 담긴 구독 주소를 일반 서버 링크로 착각하거나 단일 서버 링크를 구독으로 반복 추가하지 마세요.

업데이트가 끝나면 서버 항목 하나를 눌러 선택 표시를 확인하고 연결을 시작하세요. 처음 연결할 때 시스템에서 VPN 연결 권한을 요청합니다. 이는 Android의 트래픽 처리 인터페이스를 사용하는 것이며 다른 VPN 앱을 설치해야 한다는 뜻은 아닙니다. 권한을 허용한 뒤 상태 표시줄과 앱 로그에서 서비스가 실제로 시작되었는지 확인하세요. 같은 인터페이스를 사용하는 다른 네트워크 도구가 동시에 실행되면 시스템이 둘 중 하나를 전환하거나 중지할 수 있습니다. 문제를 진단할 때는 현재 클라이언트만 남겨두어 두 앱이 트래픽 처리 권한을 번갈아 차지하지 않도록 하세요.

v2flyNG도 구독과 단일 설정을 먼저 구분한 다음 선택한 항목과 코어의 호환성을 확인해야 합니다. 목록에 항목이 표시된다고 현재 코어가 해당 전송 매개변수를 실행할 수 있는 것은 아닙니다. 연결이 실패하면 설정을 연달아 바꾸기보다 핸드셰이크와 관련된 첫 오류를 기록하세요. 특정 Xray 기능이 필요한 연결 정보라면 보안 항목을 지워 겉으로만 시작되게 하지 말고 제공자의 설정 안내와 앱 선택부터 다시 확인하세요.

앱별 트래픽 처리, 백그라운드 및 DNS

Android의 주된 트래픽 처리 방식은 앱이 만드는 VPN 인터페이스로, 데스크톱의 '시스템 프록시 자동 설정'과는 다릅니다. 데스크톱의 로컬 프록시 설정을 그대로 적용할 필요가 없습니다. 일부 앱만 프록시를 거치게 하려면 클라이언트의 앱별 설정에서 처리하거나 제외할 앱을 선택하세요. 저장 후 연결을 다시 설정해야 할 수 있습니다. 앱 목록이 허용 목록인지 제외 목록인지 먼저 확인하세요. 두 모드에서 같은 앱을 선택하면 결과가 반대로 나올 수 있으므로 테스트할 때 대상 앱 하나만 확인하세요.

백그라운드로 전환한 뒤 일정 시간이 지나 연결이 끊긴다면 배터리 최적화, 백그라운드 활동 제한과 제조사 절전 정책부터 확인하세요. 필요한 백그라운드 실행과 알림을 허용하면 시스템이 연결 서비스를 유지하는 데 도움이 됩니다. 다만 문제를 진단한다고 모든 앱 권한을 한꺼번에 허용하지 마세요. 화면을 잠근 뒤에만 실패하면 백그라운드 서비스가 종료되는지 확인하고, Wi-Fi와 모바일 네트워크를 전환할 때 실패하면 다시 연결한 뒤 네트워크 변경 로그를 확인하세요. 두 문제를 모두 서버 불안정으로 돌려서는 안 됩니다.

시스템의 '비공개 DNS', 클라이언트 DNS 설정, 브라우저의 암호화 DNS가 모두 도메인 확인에 영향을 줄 수 있습니다. 도메인에 접속할 수 없다면 먼저 명확한 DNS 경로 하나로 되돌린 다음 사용자 지정 설정을 단계별로 추가하세요. 여러 곳에서 특수 DNS를 동시에 켠 채 라우팅 규칙을 판단하지 마세요. 일부 제조사의 앱 복제, 업무 프로필 또는 보안 공간에는 별도의 격리 기능이 있습니다. 대상 앱과 클라이언트가 같은 사용자 환경에 있는지 확인하고 앱별 목록의 앱 항목도 올바르게 선택했는지 확인하세요.

연결을 중지한 뒤 알림 표시와 실제 네트워크가 복구되었는지 확인하세요. 시스템에서 상시 VPN 또는 VPN을 통하지 않는 연결 차단을 켰다면 클라이언트 중지 후 네트워크 동작이 일반 종료와 다를 수 있으므로 시스템 네트워크 설정에서 해당 옵션을 확인하세요. 공용 네트워크에 인증이 필요하다면 네트워크 안내에 따라 먼저 로그인한 다음 연결을 시작하세요. 마지막으로 화면이 켜진 상태, 백그라운드, 잠금 화면, 네트워크 전환 상황을 각각 테스트하고 안정적인 설정을 유지한 뒤 앱별 규칙을 추가하세요. 백그라운드 제한을 구독이나 프로토콜 오류로 오인하지 않도록 해야 합니다.

라우팅 및 트래픽 처리

서로 다른 두 문제부터 구분하기

트래픽 처리는 요청을 클라이언트로 전달하고, 분할 라우팅은 전달된 요청이 어느 아웃바운드로 나갈지 결정합니다. 시스템 프록시, 앱별 프록시와 TUN은 트래픽 처리 단계에 속하며 도메인, IP, 포트와 아웃바운드 태그는 라우팅 단계에 속합니다. 라우팅 모드를 전역으로 바꿔도 시스템 프록시를 무시하는 앱이 클라이언트를 거치도록 강제할 수는 없습니다. 문제를 진단할 때는 먼저 대상 앱의 요청이 로그에 나타나는지 확인하세요. 요청 기록이 없다면 도메인 규칙을 계속 추가하지 말고 트래픽 처리 경로부터 확인해야 합니다.

라우팅 규칙은 보통 순서대로 검사하고 일치한 규칙의 아웃바운드를 선택하므로 구체적인 규칙을 포괄적인 규칙보다 앞에 두세요. 광고 차단, 로컬 네트워크 직접 연결, 지정 도메인 직접 연결, 나머지 트래픽 프록시를 기본 정책으로 구성할 수 있지만 모든 규칙에 명확한 목적이 있어야 합니다. 규칙 안의 여러 필드가 어떻게 조합되는지도 확인하세요. '도메인 또는 IP 중 하나만 일치하면 됨'이라는 조건을 아무렇게나 하나의 규칙 객체에 넣지 마세요. 각각 독립적으로 판단해야 한다면 규칙을 분리해야 로그로 확인하고 유지 관리하기 쉽습니다.

geosite는 도메인 분류 규칙이고 geoip는 IP 분류 규칙입니다. 두 규칙은 해당 항목과 일치하는 리소스 파일 및 태그가 있어야 작동합니다. 태그 이름은 임의의 설명이 아니므로 잘못 입력하거나 리소스가 없으면 시작에 실패할 수 있습니다. 클라이언트의 라우팅 편집기에서 기본 제공 규칙을 선택하면 리소스 경로를 일관되게 유지하기 쉽습니다. 설정 조각을 복사하기 전에 해당 리소스가 로컬에 있는지, 시작할 때 클라이언트가 설정을 다시 생성해 직접 수정한 내용을 덮어쓰는지 확인하세요.

로컬 인바운드와 설정 항목 의미

아래는 로컬 인바운드를 설명하는 완전한 V2Ray 설정 예시입니다. 루프백 주소에서 SOCKS 및 HTTP 연결을 받고 기본 아웃바운드는 직접 연결로 설정합니다. 수신 및 라우팅 구조를 이해하는 데 사용할 수 있지만 원격 프록시 서버는 포함하지 않으므로 구독을 대신할 수 없습니다. 클라이언트는 보통 실행 설정을 자체적으로 생성하므로 이 예시로 현재 사용 중인 설정 디렉터리를 덮어쓰지 마세요. 테스트하려면 별도 설정 환경을 사용하고 예시 포트가 현재 인스턴스에서 사용 중이지 않은지 확인하세요.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

listen은 수신 인터페이스를, port는 로컬 포트를, tag는 인바운드나 아웃바운드의 이름을 지정합니다. 규칙의 outboundTag는 실제로 존재하는 아웃바운드 태그를 참조해야 합니다. 존재하지 않는 이름을 입력해도 프록시 아웃바운드가 자동으로 생성되지는 않습니다. 위 예시에서는 규칙에 일치하지 않으면 첫 번째 아웃바운드인 직접 연결을 사용합니다. 클라이언트 인터페이스의 '최종 규칙'은 보통 구체적인 설정으로 변환되므로 화면에 표시된 문구를 코어의 JSON 필드처럼 그대로 복사하지 마세요.

domainStrategy는 라우팅 단계에서 도메인과 IP를 어떻게 비교할지 결정합니다. AsIs는 도메인을 그대로 두고 판단하며, IPIfNonMatch는 도메인 규칙에 일치하지 않을 때 IP로 해석해 IP 규칙을 추가로 확인하고, IPOnDemand는 IP 판단이 필요할 때 해석합니다. 이 항목은 원격 DNS를 단독으로 설정하는 옵션이 아니며 모든 도메인이 같은 경로로 해석된다고 보장하지도 않습니다. DNS 설정, 아웃바운드 동작과 클라이언트 구현을 함께 고려해야 합니다.

최소 규칙으로 결과 확인하기

규칙을 추가할 때는 반복해서 테스트할 수 있는 대상을 하나 고르고 예상 아웃바운드를 기록한 뒤 로그에서 실제 선택을 확인하세요. 도메인 규칙에는 보통 호스트 이름만 입력하고 전체 웹페이지 경로는 넣지 않습니다. 하위 도메인, 정확히 일치하는 항목, 접미사 일치도 구분해야 합니다. 앱이 IP로 직접 연결하거나 암호화 DNS 또는 연결 재사용을 사용하면 로그에 예상했던 도메인이 남지 않을 수 있습니다. 이때는 실제 요청 정보를 확인하세요. 비슷한 도메인을 계속 추가해 중복되고 설명하기 어려운 규칙을 만들지 마세요.

시스템 프록시는 시스템 설정을 따르는 앱에 적합하고 TUN은 더 넓은 트래픽 처리 범위가 필요한 상황에 적합하지만 TUN 자체가 분할 라우팅 정책을 결정하지는 않습니다. TUN을 켠 뒤에는 코어의 아웃바운드가 터널로 다시 들어가는 일을 막고 DNS와 로컬 네트워크 대상을 올바르게 처리해야 합니다. 첫 사용에서는 클라이언트의 기본 루프 방지 기능을 유지하고 인터페이스 연결이나 제외 라우팅을 임의로 바꾸지 마세요. 로컬 프린터, 파일 공유 또는 가상 머신 통신에 문제가 생기면 사설 IP의 경로를 먼저 확인한 뒤 필요한 경우 정확한 직접 연결 규칙을 추가하세요.

라우팅 규칙은 구독 관리와 분리해서 관리하세요. 구독을 업데이트하면 서버 항목이 다시 만들어질 수 있지만 임의의 라우팅 오류까지 해결되지는 않습니다. 라우팅 리소스 업데이트도 서버 매개변수 업데이트와는 다릅니다. 변경할 때마다 이전 규칙을 보관하고 대상 업무와 로컬 네트워크를 테스트한 뒤 종료 후 복구도 확인하세요. 코어 기능 호환성이 관련된 경우 Xray와 V2Fly 코어의 차이를 참고해 해당 항목을 지원하는지 확인하세요. 호환되지 않는 코어에서 매개변수를 계속 지우고 바꾸며 운에 맡기지 마세요.

자주 발생하는 설정 문제

실패 단계에 맞춰 로그 확인하기

먼저 '어떤 작업이 실패했는지'와 '어떤 오류가 나타났는지'를 기록하세요. 시작 실패, 구독 업데이트 실패, 특정 앱의 연결 실패, 절전 후 연결 끊김은 각각 다르게 다뤄야 합니다. 로그 창을 열고 이전 기록을 지우거나 표시한 다음 문제를 한 번만 재현해 처음 발생한 오류와 앞뒤 내용을 확인하세요. 마지막 줄의 '시작 실패'는 요약일 때가 많으며 실제 원인은 앞부분에 있을 수 있습니다. 더 자세한 진단 방법은 코어 시작 실패 로그 진단을 참고하세요.

로그에 address already in use 같은 메시지가 나타나면 먼저 어떤 프로세스가 로컬 포트를 사용 중인지 확인하세요. 이전 클라이언트와 백그라운드 인스턴스를 종료하고 수신 상태가 해제되었는지 확인하세요. 포트를 바꿔야 한다면 시스템 프록시와 앱별 프록시 설정도 함께 변경해야 합니다. 설정 파싱 오류라면 JSON의 쉼표, 괄호, 필드 유형, 코어의 해당 필드 지원 여부를 확인하세요. 유효한 JSON은 구문이 맞다는 뜻일 뿐 현재 코어가 모든 필드를 지원하거나 참조한 파일과 태그가 존재한다는 뜻은 아닙니다.

로그에 리소스 파일이 없다고 표시되면 모든 라우팅 규칙을 삭제하지 말고 규칙 파일 경로, 설치 상태와 접근 권한을 확인하세요. 지원하지 않는 프로토콜이나 전송 방식이라고 표시되면 현재 코어와 연결 정보를 확인해야 합니다. 코어를 바꾸기 전에 특정 기능에 의존하는 설정을 비활성화하고 새 코어가 같은 프로토콜을 지원하는지 확인하세요. '시작할 수 있음'만을 목표로 삼지 마세요. TLS, 인증 또는 검증 필드를 삭제하면 연결의 의미가 달라질 수 있으며, 오류 메시지가 사라져도 설정이 올바르다는 뜻은 아닙니다.

구독 목록이 비어 있음, 연결 시간 초과 및 인증서 오류

구독 업데이트 후 목록이 비어 있다면 현재 선택한 그룹, 필터 키워드, API 응답과 구독 권한 상태를 차례로 확인하세요. 웹페이지나 빈 내용을 정상적으로 받았다고 서버 정보를 가져온 것은 아닙니다. 필터를 잠시 비우고 그룹 하나만 업데이트하면 가져오기 실패와 표시 조건 문제를 구분할 수 있습니다. 여러 출처의 구독을 관리하는 방법은 구독 그룹 및 서버 필터를 참고하세요. 그룹 관계를 명확히 하지 않은 채 같은 구독을 반복해서 가져오지 마세요.

연결 시간 초과는 특정 단계가 예상 시간 안에 완료되지 않았다는 뜻이지만 이 메시지만으로 서버가 고장 났다고 판단할 수는 없습니다. 먼저 로컬 포트가 열려 있는지, 원격 주소가 해석되는지, 연결 수립과 프로토콜 핸드셰이크 중 어느 단계에서 멈췄는지 확인하세요. connection refused가 표시되면 대상 주소, 포트와 서비스 상태를 확인하세요. 대상이 루프백 주소라면 로컬 코어가 시작되었는지도 확인해야 합니다. 다른 서버로 바꿔 비교할 수 있지만 원래 오류와 설정을 보관해야 비교 기준을 잃지 않습니다.

TLS 인증서 오류가 발생하면 먼저 시스템 시간, 서버 이름, 연결 정보의 보안 설정을 확인하세요. 인증서의 이름과 연결 주소는 다를 수 있지만, 이런 차이는 제공자가 명확하게 안내한 설정을 따라야 하며 임의로 추측해서는 안 됩니다. 인증서 검증 생략을 일반적인 해결책으로 사용하지 마세요. 구독의 연결 정보가 만료되었다면 업데이트하거나 서비스 제공자에게 확인하세요. 네트워크 로그인 페이지, 기업 프록시 또는 보안 소프트웨어가 인증서 체인에 개입할 수도 있으므로 현재 네트워크 환경을 함께 고려해야 합니다.

문제 비교 및 복구 순서 정하기

브라우저에서는 되지만 다른 앱에서 안 된다면 먼저 프록시 설정 출처를 비교하세요. 브라우저 확장 프로그램이 있는지, 대상 앱이 시스템 프록시를 사용하는지, 프로토콜 유형과 포트가 일치하는지 확인해야 합니다. 일반 프록시는 되지만 TUN이 안 되면 권한, 가상 인터페이스, 라우팅과 DNS를 살펴보세요. 도메인은 실패하지만 IP 연결은 성공하면 DNS 경로를 의심할 수 있습니다. 다만 TLS 이름이나 가상 호스트 제한 때문에 IP 직접 연결이 실패할 수도 있으므로 한 번의 테스트만으로 다른 원인을 모두 배제할 수는 없습니다.

특정 사이트만 실패하고 다른 서비스는 정상이라면 해당 요청의 아웃바운드, 도메인 규칙과 앱 캐시를 확인하세요. 라우팅을 변경해도 이전 연결이 기존 경로를 계속 사용할 수 있으므로 대상 연결을 다시 수립한 뒤 테스트해야 합니다. 필요하다면 원래 설정을 백업하고 최소 규칙으로 비교하세요. 최소 규칙에서는 작동한다면 사용자 지정 규칙을 하나씩 복구하고, 그래도 작동하지 않는다면 원격 연결 매개변수와 앱의 트래픽 처리 설정을 확인하세요. 요청 기록이 없는데 도메인 분류를 계속 수정하지 마세요. 잘못된 단계에서 문제를 찾고 있을 가능성이 큽니다.

네트워크 전환이나 백그라운드 문제가 있다면 '가끔 실패함'이라고만 기록하는 것보다 발생 조건을 구체적으로 남기는 편이 유용합니다. 화면 잠금, 절전, Wi-Fi 전환, 다른 터널 앱 실행, 구독 업데이트 중 어떤 작업 뒤에 발생했는지 기록하고 관련 로그를 확인하세요. Android에서는 서비스가 시스템에 의해 중지되는지, 데스크톱에서는 현재 네트워크 인터페이스와 남아 있는 프록시를 중점적으로 확인하세요. 재시작으로 상태를 일시적으로 초기화할 수 있지만 같은 작업 뒤에 반복된다면 해당 작업을 기준으로 비교해야 합니다. 재시작을 장기적인 관리 방법으로 삼지 마세요.

문제를 문의할 때는 운영체제, 클라이언트 이름, 선택한 코어, 재현 단계, 원본 오류 메시지와 이미 진행한 비교 테스트를 제공하세요. 전체 구독 주소나 계정 정보는 첨부하지 않아도 됩니다. 로그를 공유하기 전에 서버 주소, 쿼리 매개변수와 인증 정보가 포함되어 있는지 확인하고 민감한 내용은 삭제하세요. 기본 연결을 다시 설정해야 한다면 빠른 시작 가이드로 돌아가고, 다른 플랫폼의 설치 파일이 필요하다면 클라이언트 다운로드 페이지를 확인하세요. 되돌릴 수 있는 기준 설정을 유지하면 모든 설정을 반복해서 지우는 것보다 문제를 쉽게 찾고 해결할 수 있습니다.