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

준비하기: 설정과 연결 경로 확인

클라이언트, 코어, 서버 설정 구분하기

먼저 세 부분을 구분하세요. GUI 클라이언트는 서버, 구독, 라우팅, 시스템 연결을 관리하고, 코어는 연결과 트래픽 전달을 담당하며, 서버 설정에는 원격 주소, 포트, 프로토콜, 인증 정보가 포함됩니다. 클라이언트를 설치했다고 연결을 바로 사용할 수 있는 것은 아니며, 설정을 가져왔다고 원격 서버가 반드시 작동하는 것도 아닙니다. 문제를 해결할 때 이 세 부분을 나눠 확인하면 주소 오류가 있는데 시스템 프록시를 반복해서 바꾸거나, 화면이 정상적으로 열렸다는 이유로 코어도 정상 작동한다고 착각하는 일을 줄일 수 있습니다.

데스크톱에서는 v2rayN을, 안드로이드에서는 v2rayNG를 우선 살펴보고, V2Fly 코어 설정이 필요한 경우 v2flyNG를 고려하세요. 세 클라이언트는 인터페이스와 지원하는 설정이 서로 다릅니다. 같은 공유 링크를 인식하더라도 문법을 해석할 수 있다는 뜻일 뿐, 모든 전송 옵션을 지원한다는 의미는 아닙니다. 서버에서 제공하는 프로토콜과 전송 방식, 필요한 코어 기능을 확인한 뒤 클라이언트를 선택하세요. 가져오기를 성공시키려고 모르는 필드를 함부로 삭제하지 마세요.

운영체제 버전, 프로세서 아키텍처, 설치 패키지 유형을 확인하세요. 시스템 설정에서 프로세서와 운영체제 정보를 확인할 수 있으며, 아키텍처는 브랜드가 아니라 기기에서 실제로 실행되는 환경을 기준으로 봐야 합니다. 데스크톱은 설치 프로그램, 디스크 이미지, 배포판 패키지에 따라 설치 방법이 다릅니다. 안드로이드도 범용 패키지와 특정 아키텍처용 패키지를 파일 크기만으로 구분할 수 없습니다. 클라이언트 다운로드 페이지에서 플랫폼을 선택하고, 설치 전에 카드에 표시된 아키텍처 정보를 확인하세요.

구독을 준비하고 기존 네트워크 설정 기록하기

유효한 구독 주소나 단일 공유 링크를 준비하세요. 구독에는 업데이트할 수 있는 서버 목록이 포함되는 경우가 많고, 단일 공유 링크에는 하나의 연결 설정이 담깁니다. 가져오기 메뉴가 서로 다를 수 있습니다. 복사할 때 공백, 따옴표, 줄바꿈이 섞이지 않았는지 확인하고 웹페이지 제목까지 복사하지 마세요. 구독 주소에는 개인 접속 정보가 포함될 수 있으므로 비밀번호처럼 관리해야 합니다. 스크린샷, 로그, 공개 문의 글에 전체 주소를 노출하지 말고, 다른 사람의 설정을 테스트 자료로 사용하지 마세요.

기존 프록시, 다른 터널 프로그램, 수동 DNS 설정을 기록해 두면 나중에 원상 복구하기 쉽습니다. 처음 설정할 때는 연결 방식을 하나만 사용하세요. 먼저 시스템 프록시로 브라우저를 테스트한 뒤 필요하면 TUN을 시도합니다. 클라이언트를 여러 개 동시에 켜면 수신 포트 충돌, 시스템 프록시 덮어쓰기, 라우팅 루프가 발생할 수 있습니다. 회사나 학교에서 관리하는 기기는 네트워크 확장 기능과 관리자 권한이 제한될 수도 있습니다. 정책으로 차단된다면 먼저 허용 범위를 확인하고, 보안 정책을 강제로 바꿔 설치하지 마세요.

최소한의 테스트 환경 구성하기

테스트 전에 시스템 날짜와 시간대를 확인하세요. 암호화 연결은 인증서 유효기간에 영향을 받을 수 있어 시스템 시간이 맞지 않으면 핸드셰이크가 실패할 수 있습니다. 로컬 네트워크에 정상적으로 연결되는지, 브라우저에 별도의 프록시 확장 프로그램이 켜져 있지 않은지도 확인하세요. 접속 가능한 테스트 사이트 하나를 기준으로 정하고 테스트 조건을 동일하게 유지하세요. 클라이언트 연결 테스트, 브라우저 요청, 다른 앱 트래픽은 서로 다른 경로를 이용할 수 있으므로 한 가지 결과만으로 모든 연결을 판단할 수는 없습니다.

로컬 수신 주소와 포트를 확인하세요. 개인 기기에서는 보통 루프백 주소만 수신하면 충분합니다. LAN 연결을 허용하면 접근 범위가 넓어지므로 연결 실패를 해결하는 만능 설정이 아닙니다. 혼합 포트는 클라이언트가 지원하는 프록시 요청을 하나의 진입점에서 받을 수 있지만, 실제 기능은 설정에 따라 달라집니다. 여기 나오는 10808은 흔히 쓰이는 예시일 뿐입니다. 현재 설정을 확인하고, 예시 포트를 그대로 입력한 뒤 수신이 정상적으로 시작됐다고 가정하지 마세요.

처음 연결에 성공한 설정을 기준으로 저장하고, 사용한 클라이언트, 연결 방식, 라우팅 프리셋, 로컬 포트만 기록하세요. 민감한 인증 정보는 기록할 필요가 없습니다. 이후 DNS, 코어, TUN 설정을 바꿀 때는 한 번에 한 항목만 변경하고 같은 네트워크에서 다시 테스트하세요. 문제가 생기면 직전 설정으로 되돌릴 수 있어 여러 설정을 동시에 추측할 필요가 없습니다. 첫 연결만 필요하다면 빠른 시작 안내로 돌아가 준비, 가져오기, 모드 선택, 연결 확인 순서로 진행하세요.

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

데스크톱 버전 또는 WPF 버전 선택

Windows 다운로드 페이지를 열고 v2rayN 카드에서 데스크톱 버전 또는 클래식 WPF 버전을 선택하세요. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하고, WPF 버전은 Windows용입니다. 레이아웃, 설정 메뉴, 실행에 필요한 요소가 서로 다를 수 있으므로 한 버전의 스크린샷 위치를 다른 버전에서도 동일하게 적용하지 마세요. 설치 전에 패키지 안내를 읽고 운영체제와 아키텍처가 맞는지 확인하세요. 인터페이스 차이는 데스크톱 버전과 WPF 버전 선택 가이드에서 비교할 수 있습니다.

설치 프로그램은 마법사의 안내에 따라 설치하세요. 압축 배포본을 받았다면 쓰기 권한이 있는 별도 폴더에 압축을 완전히 푼 다음 실행하세요. 압축 프로그램의 미리보기 창에서 실행하지 말고, 서로 다른 배포 패키지의 프로그램과 코어 파일을 섞지 마세요. 폴더에 충분한 쓰기 공간을 확보하고 임시 정리 대상 위치에는 설정을 저장하지 마세요. 처음 실행할 때 런타임 구성 요소가 없다는 메시지가 나오면 해당 배포본의 안내에 따라 설치하세요. 출처가 불분명한 같은 이름의 시스템 파일을 따로 내려받아 덮어쓰지 마세요.

실행한 뒤 메인 화면의 로그를 확인해 코어가 바로 종료되지 않는지 살펴보세요. 창을 닫아도 프로그램은 시스템 트레이에서 계속 실행 중일 수 있습니다. 다시 열기 전에 트레이를 확인해 중복 실행을 피하세요. 설치 경로에 개인 설정 파일이 있다면 업그레이드 전에 설정을 내보내고 기존 폴더를 보관하세요. 클라이언트 실행 중에는 사용 중인 파일을 덮어쓰지 말고, 실행 파일만 복사해 같은 배포 패키지의 리소스를 빠뜨리지 마세요. 업그레이드 후 수신 포트와 시스템 프록시 상태도 다시 확인해야 합니다.

구독을 가져오고 프록시 연결 방식 하나만 사용하기

구독 그룹 설정에서 새 그룹을 만들고 알아보기 쉬운 이름과 구독 주소를 입력한 뒤 저장하고 해당 그룹을 업데이트하세요. 단일 공유 링크를 받았다면 클립보드에서 가져오는 기능을 사용하세요. 업데이트 후 예상한 서버 항목이 목록에 있는지 확인하고 하나를 선택해 활성 서버로 지정하세요. 가져오기는 설정 목록만 바꾸며 현재 사용 중인 서버를 자동으로 바꾸지 않을 수 있습니다. 각 화면 영역은 v2rayN 메인 창 안내에서 확인할 수 있습니다.

처음 연결을 확인할 때는 시스템 프록시 자동 설정을 선택하고 TUN은 끄세요. 시스템 프록시는 기기의 시스템 설정에 로컬 프록시 주소를 등록하지만, 해당 설정을 따르는 앱에만 영향을 줍니다. 브라우저는 첫 테스트에 적합하지만 게임, 업데이트 프로그램, 자체 네트워크 설정을 사용하는 소프트웨어는 시스템 프록시를 따르지 않을 수 있습니다. 브라우저에 프록시 확장 프로그램이 있다면 테스트 전에 끄세요. 앱에서 직접 프록시를 설정해야 한다면 클라이언트가 실제로 수신 중인 루프백 주소와 포트를 입력하고 해당 진입점에 맞는 프록시 유형을 선택하세요.

더 많은 앱의 트래픽을 처리해야 할 때 TUN을 시도하세요. 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 전달하며, 관리자 권한이 필요한 경우가 많습니다. 필요한 권한은 클라이언트와 시스템 환경에 따라 달라집니다. 먼저 시스템 프록시를 해제한 뒤 화면 안내에 따라 TUN을 켜고, 로그에서 권한, 인터페이스 생성, 라우팅 오류가 있는지 확인하세요. 코어가 실행 중이고 활성 서버가 바뀌지 않았는지도 확인하세요. TUN이 켜졌다고 모든 네트워크에서 이 방식이 적합한 것은 아닙니다. 다른 터널, 가상 네트워크 카드, 관리 정책과 충돌할 수 있습니다.

포트 충돌과 종료 후 인터넷 연결 문제 해결

수신에 실패하면 먼저 오류 줄에 주소가 이미 사용 중이라고 표시되는지 확인하세요. 아래 명령은 로컬 포트를 진단할 뿐 프로세스를 자동으로 종료하지 않습니다. 예시는 10808 포트를 확인합니다. 현재 설정값에 맞게 바꾸세요. 출력의 마지막 열은 프로세스 번호이므로 작업 관리자에서 해당 프로세스를 찾을 수 있습니다. 어떤 프로그램인지 확인한 다음 중복 실행을 종료하거나 포트를 변경하세요. 포트 번호만 보고 시스템 프로세스를 종료하지 마세요.

netstat -ano | findstr :10808

포트를 바꿨다면 수동으로 프록시를 설정한 앱도 함께 업데이트하세요. 시스템 프록시를 자동 설정하는 경우 프록시 설정을 다시 적용해 이전 포트를 계속 가리키지 않는지 확인하세요. 자세한 확인 방법은 로컬 포트 사용 중 오류 해결에서 볼 수 있습니다. 방화벽 알림이 표시되면 실제 사용 목적에 맞는 네트워크 범위를 선택하세요. 개인 기기를 로컬에서만 사용한다면 테스트를 위해 LAN 수신을 열 필요가 없으며, 항목별로 확인하는 대신 방화벽 전체를 끄지 마세요.

클라이언트를 종료하기 전에 시스템 프록시를 해제하고 TUN을 끈 다음 정상 종료하세요. 프로그램이 비정상적으로 종료된 뒤 브라우저가 인터넷에 연결되지 않으면 시스템 프록시 설정에 루프백 프록시 주소가 남아 있는지 확인하세요. 클라이언트가 중지된 것을 확인한 뒤 남은 설정을 해제하고 직접 연결을 테스트하세요. 절전 모드에서 깨어나거나 Wi-Fi를 바꾼 뒤 문제가 발생하면 현재 서버에 다시 연결하고 연결 방식을 다시 적용해 보세요. 프록시 설정 잔류 문제를 해결하려고 반복해서 재설치하지 마세요. 재설치로 시스템 설정이 복구되지 않을 수 있습니다.

macOS: 칩 확인 및 네트워크 권한

칩에 맞는 버전 선택 및 첫 실행

macOS 다운로드 페이지로 이동해 ‘이 Mac에 관하여’에 표시된 칩 유형에 맞는 v2rayN을 선택하세요. Apple Silicon은 arm64, Intel은 x64에 해당합니다. 외관이나 구입 연도로 아키텍처를 추측하지 말고, 호환성 계층이 모든 네트워크 확장 문제를 해결한다고 생각하지 마세요. 다운로드가 끝나면 디스크 이미지를 열고 배포본의 안내에 따라 앱을 응용 프로그램 폴더에 넣으세요. 마운트된 이미지 안의 앱을 계속 실행하지 말고 설치한 위치에서 실행하세요.

처음 실행할 때 시스템에서 인터넷으로 다운로드한 앱인지 확인하라는 메시지가 표시될 수 있습니다. 파일 출처와 앱 이름을 확인하고 시스템 설정에 표시된 해당 앱의 안내에 따라 진행하세요. 앱 하나를 열기 위해 보안 검사를 전체적으로 끄거나 출처가 불분명한 제한 해제 명령을 실행하지 마세요. 아키텍처가 호환되지 않거나 시스템 버전이 요구 사항을 충족하지 않는다고 나오면 파일 권한을 반복해서 바꾸지 말고 다운로드 안내로 돌아가 알맞은 패키지를 선택하세요. 앱이 정상적으로 시작되기 전에는 구독이나 DNS 문제를 살펴볼 필요가 없습니다.

앱이 설정을 저장하고 다시 열어도 유지하는지 확인한 뒤 구독을 가져오세요. 응용 프로그램 폴더와 사용자 설정 폴더는 서로 다른 역할을 합니다. 업그레이드할 때는 클라이언트의 백업 또는 내보내기 기능을 사용하세요. 앱 아이콘만 보관하고 설정도 저장됐다고 생각하지 마세요. 시스템 백업은 추가 복구 수단이 될 수 있지만, 클라이언트 설정을 복원한 뒤에도 로컬 포트, 권한, 네트워크 인터페이스를 확인해야 합니다. 다른 기기에서는 이 항목들이 달라질 수 있으므로 그대로 적용하지 마세요.

설정을 가져오고 시스템 프록시 확인하기

구독 그룹에 주소를 추가하고 저장한 뒤 업데이트하세요. 활성 서버를 선택하고 실행 로그를 확인합니다. 단일 공유 링크를 가져오는 경우 내용이 완전한지 확인한 다음 클립보드에서 가져오세요. 다른 데스크톱 플랫폼에서 만든 링크를 입력으로 사용할 수는 있지만, 프로그램이 생성한 설정 전체를 그대로 복사해 이 기기의 설정으로 대체할 수는 없습니다. 설정에 원래 기기에만 있는 인증서 경로, 스크립트 경로, 인터페이스 이름이 포함됐다면 화면에서 항목별로 다시 지정하세요. 오래된 경로가 계속 실행에 사용되지 않도록 하세요.

먼저 시스템 프록시로 브라우저 연결을 확인하세요. macOS 프록시 설정은 네트워크 서비스별로 적용되므로 Wi-Fi를 사용하는지 유선 네트워크를 사용하는지에 따라 확인할 서비스가 달라집니다. 자동 설정 후 브라우저에 변화가 없다면 시스템 네트워크 설정에서 현재 서비스의 프록시 항목을 열고 주소가 이 기기를 가리키며 포트가 클라이언트와 일치하는지 확인하세요. 네트워크 서비스를 바꾼 뒤에도 다시 점검하세요. 사용하지 않는 서비스 하나에서 프록시가 켜진 것만 보고 현재 연결이 설정됐다고 판단하지 마세요.

명령줄 도구와 자체 프록시 설정을 사용하는 앱은 시스템 프록시를 따르지 않을 수 있습니다. 별도로 테스트하려면 프록시 진입점을 명시해 앱 동작과 시스템 설정을 분리하세요. 아래 명령은 현재 혼합 포트가 HTTP 프록시 요청을 받는 경우에 사용할 수 있습니다. 로컬 진입점을 통해 요청 한 건이 처리되는지 확인할 뿐 시스템 프록시는 변경하지 않습니다. 응답이 반환되면 요청이 완료된 것이지만, 예상한 원격 출구를 사용했는지는 라우팅 로그와 출구 테스트 결과를 함께 확인해야 합니다.

curl -I --proxy http://127.0.0.1:10808 https://example.com

TUN 활성화 및 네트워크 전환 대응

TUN이 필요하다면 먼저 정상 작동하는 시스템 프록시 상태를 기록하고, 시스템 프록시를 해제한 다음 TUN을 켜세요. 클라이언트 안내에 따라 필요한 권한을 허용하세요. 권한 요청 화면은 시스템과 배포 방식에 따라 다를 수 있습니다. 로그에 작업이 허용되지 않음, 가상 인터페이스 생성 실패, 라우팅 추가 실패가 표시되면 권한이 제대로 승인됐는지 먼저 확인하세요. 원격 프로토콜 설정을 계속 바꾸지 마세요. TUN은 트래픽이 클라이언트로 들어오는 방식을 담당하며 서버 주소, 인증 정보, 전송 방식 오류를 해결하지는 않습니다.

다른 터널 프로그램과 함께 실행할 때는 기본 라우트와 DNS를 어느 프로그램이 관리하는지 특히 주의하세요. 테스트 중에는 네트워크를 제어하는 클라이언트를 하나만 남겨 설정을 서로 덮어쓰지 않도록 하세요. 회사 네트워크, 핫스팟, 공용 Wi-Fi에 연결하면 프록시를 다시 연결하기 전에 네트워크 로그인 절차를 완료해야 할 수도 있습니다. 직접 인터넷에 연결되지 않는다면 기본 네트워크 문제부터 해결하세요. 이때 서버를 계속 바꾸더라도 네트워크 인증 페이지가 열리지 않는 문제는 해결되지 않습니다.

절전 모드에서 깨어난 뒤 일부 사이트만 열리지 않으면 먼저 연결을 다시 설정하고 DNS 오류와 라우팅이 갱신됐는지 확인하세요. 모든 시스템 네트워크 설정을 바로 초기화하지 마세요. 클라이언트를 종료하고 시스템 프록시가 원래대로 돌아왔는지 확인한 뒤 직접 연결을 테스트하고, 이후 연결 방식 하나를 다시 켜세요. 수동 DNS, 브라우저 보안 DNS, 클라이언트 코어 DNS는 서로 다른 계층입니다. 사용자 지정 설정이 여러 곳에 남아 있으면 실제 요청 경로를 파악하기 어렵습니다. 이 페이지의 라우팅 섹션을 참고해 단계별로 확인하세요.

정상 종료할 때는 TUN을 먼저 중지하고, 시스템 프록시를 해제한 다음 앱을 종료하세요. 제거하기 전에도 같은 절차를 진행해야 합니다. 앱을 삭제해도 모든 네트워크 설정이 자동으로 지워지는 것은 아닙니다. 종료 후 인터넷이 연결되지 않으면 현재 네트워크 서비스의 프록시 설정이 중지된 로컬 포트를 가리키는지 확인하세요. 정상 연결에 사용한 설정, 특히 로컬 포트와 연결 방식을 기록해 두면 시스템 업데이트나 기기 교체 후 쉽게 복구할 수 있어 설정을 하나씩 추측할 필요가 없습니다.

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

패키지 형식과 프로세서 아키텍처 선택

Linux 다운로드 페이지에서 배포판에 맞는 v2rayN deb 또는 rpm 패키지를 선택한 다음 x64 또는 arm64 아키텍처를 확인하세요. 데스크톱 모양만으로 패키지 형식을 판단할 수 없습니다. 같은 데스크톱 환경을 사용하는 배포판이라도 패키지 관리 시스템은 다를 수 있습니다. 시스템 정보에서 배포판과 아키텍처를 확인하세요. 추가 확인이 필요하다면 아래의 읽기 전용 명령을 실행할 수 있습니다. 일반적으로 x86_64는 x64, aarch64는 arm64에 해당합니다.

uname -m

배포판의 그래픽 소프트웨어 설치 프로그램에서 해당 패키지를 열고 의존성 정보를 확인한 뒤 설치하세요. 설치 프로그램에서 의존성을 충족할 수 없다고 나오면 시스템 배포판 버전과 소프트웨어 저장소 상태를 먼저 확인하세요. 의존성을 강제로 무시해 설치만 완료하지 마세요. 설치가 끝나면 데스크톱 앱 메뉴에서 실행하고 창과 로그를 확인하세요. GUI는 표시되지만 코어가 종료된다면 코어 로그를 확인하세요. 화면 렌더링 문제와 네트워크 프로토콜 오류를 혼동하지 마세요.

사용자 설정 폴더의 소유권을 정상적으로 유지하세요. 일반 프록시 기능을 사용하려고 GUI 클라이언트 전체를 계속 최고 권한으로 실행하지 마세요. 일반 사용자가 쓸 수 없는 설정 파일이 생성될 수 있습니다. 이후 일반 사용자로 실행하면 저장 실패, 구독 업데이트 오류, 로그 기록 실패가 발생할 수 있습니다. 실행 사용자 권한을 바꾼 적이 있다면 영향을 받은 폴더부터 찾고 배포판 문서에 따라 권한을 복구하세요. 홈 폴더 전체에 재귀적으로 접근 권한을 확대하지 마세요.

구독 가져오기: 데스크톱 설정과 앱 설정 구분

구독 가져오기 방법은 다른 데스크톱 플랫폼과 같습니다. 그룹을 만들고 주소를 입력한 뒤 저장 및 업데이트하고 활성 서버를 선택하세요. 업데이트에 실패하면 해당 요청이 기존 프록시를 통해야 하는지 먼저 확인하세요. 구독 주소와 네트워크 모드를 동시에 바꾸지 마세요. 다른 기기에서 옮기는 경우 클라이언트가 지원하는 공유 링크나 내보내기 기능을 우선 사용하세요. 로컬 경로가 포함된 설정은 다시 구성해야 합니다. 앱 연결을 설정하기 전에 코어가 시작됐는지 확인해, 아직 수신하지 않는 포트에 앱이 계속 연결을 시도하지 않도록 하세요.

Linux 데스크톱의 시스템 프록시 지원 여부는 데스크톱 환경과 앱에 따라 다릅니다. 데스크톱 프록시 설정을 읽는 앱도 있고, 환경 변수를 읽거나 자체 설정만 사용하는 앱도 있습니다. 클라이언트에 시스템 프록시가 설정됐다고 표시돼도 모든 프로그램이 해당 진입점을 사용하는 것은 아닙니다. 먼저 브라우저로 기본 연결을 확인한 뒤 다른 앱을 각각 점검하세요. 트레이 아이콘이 보이지 않는다고 프로그램이 실행되지 않았다고 단정하지 마세요. 앱 창과 프로세스 상태를 확인해 데스크톱 트레이 연동만 다른 것인지 살펴보세요.

프록시를 명시한 단일 요청은 연결 계층 문제를 찾는 데 도움이 됩니다. 아래 명령은 로컬 포트가 SOCKS 요청을 받는 경우에 사용합니다. socks5h는 이번 요청의 대상 호스트 이름을 로컬에서 먼저 해석하지 않고 프록시 진입점에 전달합니다. 그렇다고 이후의 모든 DNS 요청이 반드시 원격 서버를 통과한다는 뜻은 아닙니다. 실제 동작은 코어의 라우팅과 DNS 설정에 따라 달라집니다. 포트를 바꿔 실행하고 전역 환경 변수에는 등록하지 않아도 됩니다.

curl -I --proxy socks5h://127.0.0.1:10808 https://example.com

처음 테스트할 때 시스템 수준의 환경 변수 파일을 수정하는 것은 권장하지 않습니다. 환경 변수 변경은 새로 시작한 프로세스에만 적용될 수 있으며, 이미 실행 중인 브라우저는 새 값을 자동으로 받지 않습니다. 그래픽 데스크톱에서 실행한 앱이 터미널 설정을 읽지 않을 수도 있습니다. 명령줄 앱에 프록시가 꼭 필요하다면 먼저 해당 앱에서만 확인하고, 그다음 영구 적용 여부를 결정하세요. 데스크톱 프록시, 앱 프록시, 전역 환경 변수를 모두 설정한 뒤 특정 프로그램 하나가 연결된다는 이유만으로 전체 설정이 올바르다고 판단하지 마세요.

TUN 권한과 수신 상태 확인

TUN에는 가상 인터페이스와 라우팅을 관리할 권한이 필요합니다. 활성화 방법은 배포판, 커널, 클라이언트 배포 방식에 따라 달라집니다. 현재 클라이언트의 안내에 따라 권한을 허용하고 다른 운영체제의 절차를 그대로 따라 하지 마세요. 활성화 전에 라우팅을 제어하는 다른 도구를 중지하고, 켠 뒤 인터페이스가 실제로 생성됐는지와 규칙이 적용됐는지 확인하세요. 화면의 스위치는 켜져 있어도 로그에 권한 부족이 표시되면 실제 트래픽이 TUN으로 들어가지 않을 수 있습니다. 서버를 바꿔도 이 문제는 해결되지 않습니다.

로컬 진입점에 연결할 수 없다면 ss -lntp로 수신 중인 TCP 포트를 확인할 수 있습니다. 프로세스 정보가 표시되는 범위는 현재 권한에 따라 달라집니다. 대상 포트가 보이지 않으면 코어가 종료됐는지, 설정이 불러와졌는지 먼저 확인하세요. 다른 프로세스가 이미 포트를 사용 중이라면 용도를 확인한 뒤 중복 실행을 종료하거나 수신 포트를 바꾸세요. 원격 연결 실패는 DNS, 인증, 전송 로그를 확인하세요. 원격 오류를 해결하려고 수신 주소를 모든 인터페이스로 바꾸지 마세요.

네트워크 전환, 절전, 클라이언트 종료 후 데스크톱 프록시 설정이 남아 있는지 확인하세요. 패키지를 제거해도 프록시를 수동으로 설정한 모든 앱이 자동으로 원래대로 돌아오는 것은 아닙니다. 터미널 환경 변수도 별도로 해제해야 합니다. 변경 범위를 명확히 되돌릴 수 있는 위치로 제한하고, 작업 전에 수정 사항을 기록하세요. 테스트가 끝나면 브라우저, 필요한 앱, 직접 연결 복구를 각각 확인하세요. 세 가지 동작이 모두 예상대로여야 데스크톱 설정이 완료된 것입니다.

Android: 설치, 권한, 백그라운드 실행

클라이언트와 아키텍처에 맞는 패키지 선택

Android 다운로드 페이지에서 먼저 Xray 코어를 사용하는 v2rayNG를 확인하세요. V2Fly 코어 설정이 필요하다면 v2flyNG를 대안으로 사용하세요. 비교적 최신 기기는 대부분 arm64를 사용하지만, 최종적으로는 기기가 지원하는 앱 아키텍처를 확인해야 합니다. 알 수 없다면 여러 아키텍처 패키지를 번갈아 설치하지 말고 범용 패키지를 고려하세요. 설치 실패는 시스템 버전, 아키텍처, 기존 앱의 서명 충돌 등에서 비롯될 수 있으므로 원인별로 처리해야 합니다.

브라우저나 파일 관리자에서 설치 패키지를 열면 시스템에서 해당 출처의 앱 설치를 허용하라고 요청할 수 있습니다. 보통 파일을 여는 데 사용한 앱에 설치 권한을 부여합니다. 설치를 마친 뒤 필요에 따라 해당 권한을 해제할 수 있습니다. 시스템에서 이미 설치된 앱과 충돌한다고 나오면 기존 앱의 출처를 확인하고 설정을 내보내세요. 복구 방법을 생각하기도 전에 앱을 삭제하지 마세요. 클라이언트마다 앱 데이터가 따로 저장되므로 다른 클라이언트를 설치해도 기존 구독, 서버, 라우팅 설정은 자동으로 옮겨지지 않습니다.

처음 실행한 뒤 알림과 네트워크 관련 안내를 확인하고 구독 관리로 이동하세요. 안드로이드 클라이언트는 시스템 VPN 서비스를 통해 트래픽 진입점을 만듭니다. 여기서 시스템 권한을 허용했다고 원격 서버에 연결된 것은 아닙니다. 이 권한은 앱이 네트워크 통로를 만들도록 허용할 뿐이며, 이후에도 유효한 설정과 정상 작동하는 코어가 필요합니다. 업무 프로필이나 관리 정책이 적용된 기기는 사용 가능한 VPN 서비스가 제한될 수 있으니 같은 패키지를 반복 설치하지 말고 관리 요구 사항을 먼저 확인하세요.

구독 가져오기 및 연결 범위 확인

구독 설정에서 그룹을 만들고 이름과 구독 주소를 입력한 뒤 저장하고 업데이트하세요. 단일 공유 링크만 있다면 클립보드에서 가져오기 기능을 사용하세요. 설정을 스캔할 때만 해당 스캔 기능에 카메라 권한이 필요합니다. 가져온 뒤 서버 이름, 프로토콜, 전송 설정이 빠짐없이 들어왔는지 확인하고 설정 하나를 선택해 연결하세요. 만료된 구독 주소를 단일 공유 링크로 계속 가져오지 마세요. 두 메뉴는 서로 다른 유형의 내용을 처리하므로 반복해도 주소가 유효해지지 않습니다.

연결을 누르고 시스템 VPN 권한 대화상자를 확인하세요. 상시 알림과 클라이언트 로그를 살펴 서비스가 바로 중지되지 않았는지 확인합니다. 안드로이드는 일반적으로 같은 사용자 환경에서 활성 VPN 서비스를 하나만 허용하므로 다른 네트워크 도구가 현재 연결을 대체할 수 있습니다. 테스트할 때는 특히 VPN 인터페이스를 사용하는 필터링 도구 등 비슷한 서비스를 먼저 중지하세요. 시스템에 VPN 표시가 나타나는 것은 통로가 설정됐다는 뜻일 뿐입니다. 실제 요청으로 원격 연결과 분할 터널링 결과를 확인해야 합니다.

앱별 프록시 설정을 확인하세요. 허용 목록을 사용하면 선택하지 않은 앱은 프록시를 거치지 않을 수 있습니다. 제외 목록을 사용하면 목록에 있는 앱이 직접 연결될 수 있습니다. 두 방식은 의미가 반대이므로 목록에 앱이 있는지만 확인해서는 안 됩니다. 기준을 잡으려면 기본 연결 범위로 브라우저를 테스트한 다음 필요한 앱을 하나씩 추가하세요. 브라우저의 보안 DNS, 캐시, 기존 연결이 결과에 영향을 줄 수도 있습니다. 규칙을 바꾼 뒤에는 열려 있던 페이지를 새로고침하는 데 그치지 말고 새 요청을 보내세요.

백그라운드 실행과 배터리 사용량 균형 맞추기

화면이 꺼진 뒤 연결이 끊기면 시스템이 서비스를 중지했는지, 서비스는 실행 중이지만 요청이 실패하는지 먼저 확인하세요. 전자라면 앱의 배터리 최적화, 백그라운드 활동, 자동 시작 제한을 확인하고, 후자라면 로그와 현재 네트워크, 서버 상태를 살펴보세요. 제조사마다 설정 메뉴가 다르므로 해당 시스템에서 같은 기능을 하는 항목을 찾으세요. 모든 백그라운드 제한을 한꺼번에 해제하지 말고 실행에 직접 영향을 주는 항목 하나를 먼저 조정한 뒤 화면을 끄고 다시 켰을 때 동작을 확인하세요.

상시 알림은 서비스 상태를 알려줍니다. 알림이 사라졌다고 서비스가 중지됐다고 단정할 수는 없지만 문제를 찾는 단서가 될 수 있습니다. 연결을 계속 유지해야 한다면 상태를 확인할 수 있는 알림을 켜 두는 편이 좋습니다. 배터리 소모가 크다면 자주 실행되는 연결 테스트, 반복 재연결, 지나치게 높은 로그 수준, 백그라운드 앱의 지속적인 트래픽을 확인하세요. 배터리 최적화 예외 목록에 앱을 추가하면 계속 실행되는 데 도움이 될 수 있지만, 코어의 전력 사용량을 직접 줄이거나 원격 연결 불안정을 해결하지는 않습니다.

Wi-Fi에서 모바일 데이터로 전환하면 기존 연결이 끊겨 다시 연결해야 할 수 있습니다. 특정 네트워크에서만 실패한다면 해당 네트워크 자체가 인터넷에 연결되는지 확인한 다음 같은 서버와 동일한 설정으로 비교 테스트하세요. 공용 네트워크는 로그인 페이지 인증이 필요할 수 있고, 모바일 데이터는 데이터 절약 기능과 백그라운드 데이터 권한의 영향을 받을 수 있습니다. 네트워크 전환 후 첫 요청이 시간 초과됐다고 바로 구독 전체를 다시 만들지 마세요. 재연결 결과와 로그를 먼저 확인하는 편이 원인을 찾기 쉽습니다.

사용을 마칠 때는 클라이언트에서 연결을 끊고 시스템의 연결 표시와 상시 알림 상태를 확인하세요. 다른 클라이언트로 바꾸기 전에 기존 서비스를 중지해 권한 전환 문제를 서버 오류로 착각하지 않도록 하세요. 백그라운드 제한과 배터리 사용량을 조정하려면 v2rayNG 백그라운드 및 배터리 설정을 참고하세요. 필요한 로그를 보관한 뒤 데이터를 정리하세요. 앱 데이터를 삭제하면 로컬 설정도 사라지므로 연결이 끊길 때마다 사용하는 일반적인 해결 방법으로 삼지 마세요.

구독 및 마이그레이션: 복구할 수 있는 설정 관리

올바른 가져오기 메뉴 선택

구독 주소, 공유 링크, 전체 설정 파일은 각각 용도가 다릅니다. 구독 주소는 목록을 주기적으로 가져오고, 공유 링크는 단일 연결 설정을 전달하며, 전체 설정 파일에는 로컬 진입점, 아웃바운드, 라우팅, DNS가 함께 들어갈 수 있습니다. 클라이언트가 한 형식을 지원한다고 나머지 두 형식도 같은 메뉴에서 가져올 수 있는 것은 아닙니다. 먼저 내용 유형을 확인하세요. 일반 웹페이지 주소를 구독 주소로 사용하거나 전체 설정 텍스트를 링크만 받는 입력란에 붙여넣지 마세요.

구독 그룹을 만들 때 출처나 용도를 알아볼 수 있게 이름을 정하고 인증 정보는 포함하지 마세요. 저장한 뒤 그룹 하나씩 업데이트하고 결과를 확인하세요. 업데이트에 성공했는데 목록이 비어 있다면 응답이 비어 있는지, 구독 형식이 호환되지 않는지, 필터가 항목을 숨기는지 살펴보세요. 업데이트 후 같은 이름이 중복돼도 표시 이름만 보고 서버를 삭제하지 마세요. 이름은 고유한 식별자가 아닙니다. 먼저 그룹과 현재 활성 서버의 관계를 확인한 뒤 오래된 항목을 정리해야 필요한 설정을 지우지 않습니다.

관리할 때는 구독으로 관리되는 항목과 수동으로 추가한 항목을 구분하세요. 구독을 업데이트하면 원격에서 제공하는 설정이 덮어써질 수 있으므로 구독 항목의 전송 설정을 직접 수정해도 다음 업데이트 때 사라질 수 있습니다. 임시 테스트가 필요하다면 클라이언트가 지원하는 복사 또는 독립 설정 기능을 이용하고, 테스트용임을 표시해 원본을 보관하세요. 임시로 수정한 설정을 장기적인 출처로 사용하지 마세요. 원격 서비스가 변경됐다면 구독을 업데이트하거나 설정 제공자에게 확인하세요.

구독 업데이트 실패 단계 확인

먼저 업데이트 요청이 전송됐는지 확인하세요. 주소가 비어 있거나 형식이 잘못됐거나 복사한 내용에 문자가 더 들어가면 연결 전에 실패합니다. 도메인 이름 확인 오류는 연결을 설정하기 전에 발생하고, 시간 초과, 인증서 오류, 접근 거부는 이후 단계의 문제입니다. 일부 주소는 로그인 페이지로 이동하거나 오류 페이지를 반환할 수 있습니다. 네트워크 요청에 성공했더라도 응답이 구독 내용이라는 뜻은 아닙니다. 로그의 상태와 오류 요약을 확인하고 서비스 만료, 접근 제한, 내용 형식 오류를 모두 ‘클라이언트가 열리지 않음’으로 뭉뚱그리지 마세요.

‘구독 업데이트 시 프록시 사용 안 함’은 업데이트 요청의 경로에만 영향을 주며 일반 앱 트래픽의 라우팅은 바꾸지 않습니다. 현재 서버를 사용할 수 없고 업데이트 요청이 해당 서버에 의존한다면 직접 업데이트를 테스트할 수 있습니다. 구독 주소에 프록시로만 접근할 수 있다면 먼저 작동하는 연결을 준비한 뒤 업데이트해야 합니다. 한 번에 이 항목만 바꾸고 오류 결과를 비교할 수 있도록 기록하세요. DNS, 활성 서버, 업데이트 방식을 동시에 바꾸면 업데이트에 성공해도 어떤 조건이 작용했는지 알기 어렵습니다.

업데이트한 뒤 활성 서버가 여전히 유효한지 확인하세요. 원격 목록에서 오래된 항목이 삭제되거나 내부 설정이 바뀔 수 있으며, 현재 선택을 자동으로 바꾸는지는 클라이언트 구현에 따라 다릅니다. ‘업데이트 완료’만 확인하고 창을 닫지 말고 현재 연결을 테스트하고 그룹 필터가 새 항목을 숨기지 않는지도 확인하세요. 필요하면 서버를 다시 선택합니다. 모든 항목이 동시에 실패한다면 포트를 하나씩 바꾸기보다 구독 내용, 계정 상태, 로컬 네트워크에 공통된 원인이 있는지 먼저 확인하세요.

설정을 옮기고 복구 결과 확인하기

마이그레이션 전에 클라이언트의 내보내기 또는 백업 기능을 사용하고 내보내기 범위를 확인하세요. 일부 기능은 서버 링크만 내보내고, 다른 기능은 구독과 인터페이스 설정도 포함합니다. 파일 이름만 보고 내용을 판단할 수 없습니다. 구독 출처와 필요한 사용자 지정 규칙을 따로 기록해 안전한 곳에 보관하세요. 편의를 위해 전체 설정 폴더를 LAN에 공유하거나 인증 정보가 포함된 파일을 공개 동기화 폴더에 넣지 마세요. 백업 복구가 가능한지는 기존 기기를 계속 사용할 수 있을 때 먼저 확인해야 합니다.

플랫폼 간 마이그레이션에서는 공통으로 사용할 수 있는 서버 정보와 구독 주소를 우선 옮기고, 대상 기기에서 로컬 포트, 시스템 프록시, TUN, 파일 경로를 다시 설정하세요. Windows의 경로와 네트워크 인터페이스 이름은 Linux나 macOS에서 그대로 사용할 수 없습니다. 안드로이드의 앱별 목록도 데스크톱 앱 설정과 같지 않습니다. 코어가 다르면 지원하는 프로토콜 필드도 달라질 수 있습니다. 가져온 뒤 클라이언트가 일부 설정을 무시하지 않았는지 확인하세요. 오류가 없었다고 모든 필드가 완전히 옮겨졌다고 볼 수는 없습니다.

복구가 끝나면 서버 하나를 먼저 테스트하고, 라우팅과 DNS를 복원한 다음 자동 업데이트와 백그라운드 실행을 설정하세요. 각 단계가 성공할 때마다 기록을 저장해 되돌릴 수 있는 확인 지점을 만드세요. 클라이언트 업그레이드에도 같은 순서를 적용할 수 있습니다. 내보내기, 실행 중지, 업그레이드, 포트 확인, 요청 테스트 순으로 진행하세요. 복구 가능한 백업이 없는데 기존 폴더를 바로 삭제하지 말고, 이전 프로그램이 생성한 실행 설정 전체를 새 인터페이스가 관리하는 폴더에 강제로 덮어쓰지 마세요.

라우팅 및 DNS: 연결 진입점, 규칙, 출구 구분

시스템 연결과 라우팅 판단을 구분하기

시스템 프록시와 TUN은 트래픽이 클라이언트에 들어오는 방식을 정하고, 라우팅은 들어온 트래픽이 어떤 출구를 사용할지 결정합니다. 서로 같은 스위치가 아닙니다. 시스템 프록시를 켰더라도 앱이 이를 따르지 않으면 트래픽은 코어에 들어오지 않습니다. TUN을 켜도 규칙에 따라 직접 연결할 수 있습니다. 클라이언트의 전역 프록시는 보통 기본 출구를 프록시로 선택한다는 뜻이지 모든 시스템 프로세스가 반드시 연결된다는 의미는 아닙니다. 결과를 분석할 때는 요청이 들어온 경로, 라우팅, 원격 연결 성공 여부를 차례로 확인하세요.

처음에는 클라이언트가 제공하는 라우팅 프리셋을 선택해 정상 작동하는 기준을 만드세요. 그다음 꼭 필요한 규칙만 추가하고 일치 순서를 확인하세요. 일반적인 규칙은 순서대로 적용되므로 범위가 넓은 조건을 앞에 두면 뒤의 세부 조건이 적용되지 않을 수 있습니다. LAN 주소를 직접 연결하면 라우터, 프린터, 로컬 서비스에 접속하기 편하지만 모든 로컬 환경이 프리셋에 포함되는지는 설정에 따라 다릅니다. 기업 내부 도메인이 사설 IP 주소로 해석될 수 있으므로 공개 도메인 목록만으로 처리할 수는 없습니다.

사용자 지정 규칙을 수정하기 전에 어떤 대상을 일치시키려는지 정하세요. 도메인 조건, 대상 주소 조건, 앱 조건은 서로 다른 기준이므로 서로 대체할 수 없습니다. 앱이 숫자 IP 주소에 직접 연결하면 도메인 규칙만으로는 적용되지 않을 수 있습니다. 트래픽 스니핑을 켜면 추가 도메인 정보를 얻을 수 있지만 모든 연결에서 작동하는 것은 아닙니다. 규칙이 적용되지 않으면 실제 대상, 일치 순서, 기본 출구를 확인하세요. 정상적으로 작동하던 분할 터널링을 잃을 수 있으니 규칙 전체를 곧바로 비우지 마세요.

규칙 예제를 읽고 실제 출구 확인하기

아래는 Xray/V2Fly 형식의 라우팅 객체 예시입니다. LAN 주소는 직접 연결하고 예시 도메인과 하위 도메인은 프록시를 사용합니다. 문법을 설명하기 위한 예시일 뿐, 임의의 클라이언트 입력란에 그대로 붙여넣을 수 있는 전체 설정은 아닙니다. 현재 코어가 사용된 필드를 지원하는지, 생성된 설정에 direct와 proxy라는 아웃바운드 태그가 실제로 있는지 확인해야 합니다. 클라이언트의 GUI 규칙 편집기를 사용한다면 각 조건에 해당하는 항목을 입력하세요. 전체 객체를 도메인 목록 입력란에 붙여넣지 마세요.

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

예시의 사설 주소 규칙은 코어에서 사용할 수 있는 지리 데이터 리소스에 의존하므로 리소스가 없으면 설정을 불러오지 못할 수 있습니다. 코어마다 규칙 문법과 리소스 구성이 다르므로 섞어 사용하지 마세요. 클라이언트가 생성한 설정은 읽기 전용 문제 해결 자료로 보관하는 편이 안전합니다. 생성 파일을 직접 편집하면 화면 설정을 저장하거나 재시작할 때 변경 내용이 덮어써질 수 있습니다. 수정 후 먼저 설정이 정상적으로 불러와지는지 확인하고 규칙 적용을 테스트하세요. 코어가 시작하지 못한다면 웹페이지 접속 결과보다 문법과 리소스 오류를 먼저 해결해야 합니다.

DNS 및 연결 재사용 단계별 점검

DNS 조회는 시스템, 브라우저, 앱, 코어 내부에서 이루어질 수 있습니다. 클라이언트 DNS를 바꿔도 모든 앱의 자체 해석 방식이 자동으로 바뀌지는 않습니다. 브라우저의 보안 DNS와 시스템 비공개 DNS도 실제 조회 경로를 바꿀 수 있습니다. 문제를 찾을 때는 대상 도메인을 누가 해석하는지 기록한 뒤 조회가 예상한 출구를 통과하는지 확인하세요. 특정 공개 DNS 주소가 모든 문제를 해결한다고 생각하지 마세요. 네트워크마다 접근성, 지연 시간, 응답 결과가 다를 수 있으므로 실제 요청으로 확인해야 합니다.

서버 도메인 해석과 대상 웹사이트 도메인 해석도 구분해야 합니다. 원격 연결을 설정하기 전에 클라이언트가 서버 주소를 찾아야 할 수 있습니다. 이 단계에서 아직 만들어지지 않은 프록시 연결을 사용하려고 하면 순환 의존성이 발생할 수 있습니다. 클라이언트 프리셋은 보통 이런 초기 연결 과정을 처리하므로 사용자 지정 설정을 만들 때 임의로 삭제하지 마세요. 연결 로그에 해석 시간 초과가 표시되면 먼저 오류가 난 도메인이 서버인지 대상 웹사이트인지 구분한 다음 기본 네트워크, 코어 DNS, 앱 자체 설정 중 무엇을 확인할지 결정하세요.

규칙을 바꾼 뒤 기존 연결을 닫거나 테스트 앱을 다시 시작해 연결 재사용으로 변경 사항이 가려지지 않게 하세요. 브라우저 캐시와 기존의 긴 연결이 이전 결과를 계속 사용할 수 있으므로 새로고침한다고 항상 새 연결이 만들어지는 것은 아닙니다. 확인할 대상을 명확히 정하고 적용된 출구와 오류 단계를 기록하는 한편 직접 연결 결과도 비교 자료로 남겨 두세요. 라우팅 성공은 예상한 경로를 선택했다는 뜻일 뿐 원격 서비스가 요청을 받아들였다는 의미는 아닙니다. 두 결과를 구분하면 이미 올바른 규칙을 계속 바꾸는 일을 피할 수 있습니다.

설정 관련 자주 묻는 질문: 단계별 문제 해결

먼저 문제가 발생한 범위 파악하기

연결에 문제가 생기면 먼저 ‘어디에서 실패했는지’를 구체적으로 적으세요. 클라이언트가 시작되지 않는지, 코어가 시작된 뒤 종료되는지, 구독을 업데이트할 수 없는지, 브라우저가 열리지 않는지, 특정 앱 하나만 실패하는지 확인합니다. 설치 후, 업그레이드 후, 네트워크 전환 후, 설정 변경 후 중 언제 문제가 시작됐는지도 기록하세요. 범위를 구체적으로 정할수록 다음 단계가 명확해집니다. 모든 증상을 서버 문제로 묶거나 설정을 먼저 초기화하지 마세요. 그러면 가장 중요한 변경 원인을 놓치게 됩니다.

로컬 네트워크, 클라이언트 코어, 로컬 진입점, 원격 연결, 대상 요청을 차례로 확인하세요. 직접 연결부터 실패한다면 기본 네트워크를 점검하고, 코어가 종료되면 처음 발생한 오류를 확인하세요. 포트가 수신 중이지 않다면 시작 오류와 충돌을 해결하세요. 앱 하나만 실패한다면 해당 앱의 프록시 진입점과 앱별 목록을 확인합니다. 모든 대상이 실패하면 공통 DNS, 인증, 원격 접속 가능성 문제를 확인하세요. 한 번에 한 계층씩 테스트하고 여러 서버와 라우팅 규칙을 동시에 바꾸지 마세요.

클라이언트의 연결 테스트는 성공했는데 브라우저가 실패해도 모순은 아닙니다. 테스트 도구는 현재 서버에 직접 연결하지만 브라우저는 시스템 프록시를 사용하지 않거나 직접 연결 규칙을 적용받을 수 있습니다. 반대로 지연 시간 테스트가 실패했다고 실제 요청도 반드시 실패하는 것은 아닙니다. 같은 대상과 명확한 진입점으로 다시 테스트하고, 필요하면 이 페이지의 프록시 지정 명령으로 연결 문제를 구분하세요. 판단은 상태 아이콘 하나가 아니라 요청이 실제로 거친 경로를 바탕으로 해야 합니다.

오류 단계 파악 및 필요한 로그만 보관

‘연결이 거부됨’은 대체로 요청이 도달한 주소와 포트에서 연결을 받아들이지 않았다는 뜻입니다. 로컬 진입점이 시작되지 않았거나 원격 포트가 맞지 않을 수 있으므로 로그에 표시된 대상을 함께 확인해야 합니다. ‘시간 초과’는 정해진 시간 안에 특정 단계가 완료되지 않았다는 뜻일 뿐입니다. 도메인 해석, 연결 설정, 핸드셰이크 중 어디에서든 발생할 수 있으며 서버가 오프라인이라는 뜻으로 단정할 수 없습니다. 오류 전후의 로그를 확인해 로컬 문제인지 원격 문제인지 판단한 뒤 해당 설정을 조정하세요.

핸드셰이크가 실패하면 시스템 시간, 서버 이름, 전송 매개변수, 서버 요구 사항이 일치하는지 확인하세요. 인증서 오류를 장기적인 해결책으로 삼아 검증을 함부로 끄지 마세요. 연결 보안 범위가 달라집니다. 인증에 실패하면 식별 정보를 직접 수정해 문제를 키우지 말고 유효한 설정을 다시 가져오세요. 설정 파싱 오류는 먼저 필드와 코어 호환성을 확인해야 합니다. 자세한 로그 확인 방법은 실행 로그의 자주 발생하는 오류 안내에서 확인할 수 있습니다.

로그 수준을 일시적으로 높여야 한다면 문제를 재현하는 데 필요한 짧은 시간 동안만 적용하고 끝난 뒤 평소 수준으로 되돌리세요. 상세 로그를 계속 기록하면 저장 공간과 성능에 부담이 되고 접속 대상이 노출될 수도 있습니다. 공개적으로 도움을 요청하기 전에 구독 주소, 인증 정보, 개인 경로, 기기 식별자를 삭제하고 오류 유형, 발생 단계, 관련 설정만 남기세요. 생성된 설정 전체를 업로드하거나 문제가 있다는 것을 보여주려고 공유 링크 전체를 공개하지 마세요.

문제에 맞는 설정으로 돌아가기

정상 작동을 복구했다면 실제로 효과가 있었던 변경 사항을 기록하고 임시 테스트 설정은 되돌리세요. 포트 충돌만 문제였다면 새 포트와 앱의 해당 설정만 남기면 됩니다. 네트워크 전환 때문에 연결이 끊긴 것이라면 테스트했던 DNS와 라우팅 설정까지 유지할 필요는 없습니다. 최소 설정부터 다시 구성해야 한다면 가이드의 프록시 모드 설정 단계로 돌아가 진입점 하나만 사용한 뒤 필요한 기능을 하나씩 복원하세요. 최종 설정은 이유를 설명하고 재현하며 원상 복구할 수 있어야 합니다.