v2rayN 전체 플랫폼 설정
및 Android 구독 설정

공통 준비 사항 및 설정 범위

클라이언트, 코어, 구독의 차이

먼저 어떤 구성 요소를 설정하는지 확인하세요. v2rayN은 서버 정보를 저장하고 구독 그룹을 관리하며 실행 설정을 만들고 코어를 제어하는 데스크톱 GUI 클라이언트입니다. 실제 연결은 선택한 코어가 처리합니다. Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 고려하고, V2Fly 코어가 필요한 경우에는 v2flyNG를 선택할 수 있습니다. 구독은 서비스 제공업체가 제공하는 주소나 데이터이며 클라이언트 계정과는 다릅니다. 프로그램을 설치해도 사용할 수 있는 서버가 자동으로 생기지는 않으며, 아무 웹 주소나 구독 주소로 사용할 수도 없습니다. 먼저 유효한 구독을 준비한 뒤 플랫폼별 안내를 확인하세요.

구독 제공업체가 안내한 형식, 프로토콜 및 이용 제한을 확인하세요. 구독에는 공유 링크, 인코딩된 링크 목록 또는 특정 클라이언트용 설정 데이터가 포함될 수 있으며, 가져올 수 있는지는 클라이언트의 실제 지원 여부에 달려 있습니다. 파일 확장자만으로 호환성을 판단하지 말고, 전체 실행 설정을 “可选地址 Url”에 붙여 넣지 마세요. 서버 공유 링크 하나만 받은 경우에는 클립보드에서 서버를 가져오는 메뉴를 이용하세요. 구독 주소를 받은 경우에는 구독 그룹을 만드세요. 두 가져오기 방식은 데이터 출처와 이후 업데이트 방법이 서로 다릅니다.

아키텍처, 시간, 네트워크 환경 확인

다운로드 센터로 이동하기 전에 시스템 정보에서 프로세서 아키텍처와 운영체제 종류를 확인하세요. 데스크톱 설치 파일은 프로세서와 배포판에 맞아야 하며, 컴퓨터 브랜드만 보고 선택하면 안 됩니다. Windows의 시스템 종류, macOS의 칩 정보, Linux의 머신 아키텍처, Android의 프로세서 사양에 따라 적절한 설치 항목이 달라집니다. 설치 파일 형식이 맞더라도 운영체제 버전이 요구 사항을 충족한다는 뜻은 아닙니다. 런타임, 시스템 인터페이스 또는 설치 프로그램의 제한이 나타나면 안내에 따라 처리하세요. 프로그램이 정상적으로 시작되지 않는 문제를 구독을 반복해서 가져오는 방식으로 해결하려 하지 마세요.

자동 시간 설정을 켜고 시간대와 현재 시간이 올바른지 확인하세요. TLS 인증서 검증에는 시스템 시간이 사용되므로 시계가 크게 어긋나면 모든 서버에서 핸드셰이크 오류가 발생할 수 있습니다. 이어서 현재 네트워크에서 일반 도메인 이름을 확인할 수 있는지 점검하고, 필요한 경우 먼저 네트워크 로그인 페이지를 통과하세요. 공용 네트워크 인증이 끝나지 않았거나 포털 페이지가 연결을 가로막거나 로컬 DNS에 문제가 있으면 구독 요청이 시간 초과될 수 있습니다. 준비 단계에서는 기본 네트워크만 확인하고, 처음부터 TUN이나 복잡한 라우팅을 켜지 마세요. 최소한의 설정으로 재현 가능한 연결을 만든 다음 기능을 추가하세요.

자료를 보관하고 확인 순서를 정하세요

설정을 바꾸기 전에 현재 시스템 프록시 상태, 로컬 리스닝 포트, 구독 그룹 이름을 기록하세요. 기존 클라이언트에서 옮겨 오는 경우 이전 인스턴스를 먼저 종료하세요. 이전 프로그램이 포트를 계속 점유하거나 시스템 프록시를 다시 설정할 수 있습니다. 설정을 백업할 때 구독 주소는 민감 정보로 취급하세요. 주소의 token이 접근 권한을 나타낼 수 있으므로 공개 화면에서는 전체 주소, 사용자 식별 정보, 서버 인증 정보를 가리세요. 이 문서의 예시 주소는 입력 위치를 설명하기 위한 것이므로 실제 구독 업데이트에 사용할 수 없으며, 이미 유효하다고 확인한 주소를 대체해서도 안 됩니다.

“프로그램 실행, 구독 업데이트, 서버 테스트, 트래픽 적용, 외부 연결 확인” 순서로 진행하세요. 각 단계의 결과를 확인하고 기록한 뒤 다음 단계로 넘어가세요. 코어, DNS, 라우팅, 프록시 모드를 한꺼번에 바꾸면 실패 원인을 찾기 어렵습니다. 처음 사용하는 경우 빠른 시작 과정에 따라 연결한 다음 이 페이지에서 플랫폼별 세부 설정을 확인하세요. 설치가 끝나지 않았다면 먼저 설치 문제를 해결하세요. 클라이언트 테스트는 성공했는데 브라우저에서 실패한다면 모든 서버를 바꾸기보다 앱이 프록시를 사용 중인지 확인하세요.

Windows 설치 및 시스템 프록시

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

Windows 다운로드에서 v2rayN 데스크톱 버전과 클래식 WPF 버전 중 하나를 선택하세요. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하고, 클래식 WPF 버전은 Windows 데스크톱 인터페이스를 유지합니다. 메뉴 배치가 다를 수 있으므로 다른 버전의 스크린샷에서 같은 위치를 찾으려 하지 마세요. 시스템 종류에 맞는 설치 항목을 선택하고 설치 안내의 환경 요구 사항을 확인하세요. 이 문서에서는 설정 이름을 기준으로 설명합니다. 모든 배포 패키지의 설치 방식이 같다고 가정하거나 특정 운영체제 버전에서 반드시 작동한다고 단정하지 않습니다.

설치를 마친 뒤 일반 사용자 권한으로 실행하고, 메인 창과 서버 목록, 로그 영역이 정상적으로 열리는지 확인하세요. 압축을 풀어 사용하는 배포판이라면 쓰기 가능한 폴더에 전체 압축을 풀어야 합니다. 압축 파일 미리 보기에서 바로 실행하지 말고, 같은 폴더의 구성 요소를 빠뜨린 채 실행 파일만 옮기지 마세요. 앱 설치 폴더와 실제 설정 폴더가 다를 수 있으므로 데이터를 옮기기 전에 클라이언트의 백업 또는 설정 관리 기능으로 위치를 확인하세요. 파일 저장에 실패하면 구독 문제로 단정하지 말고 폴더 권한과 보안 프로그램 기록부터 확인하세요.

구독을 가져와 서버 테스트

“구독 그룹 설정”을 열고 그룹을 추가한 뒤 알아보기 쉬운 별칭을 입력하고 전체 주소를 “可选地址 Url”에 붙여 넣으세요. 활성화 상태를 확인하고 저장한 다음 “구독 그룹” 메뉴에서 “모든 구독 업데이트(프록시 사용 안 함)”를 실행하세요. 업데이트가 끝나면 해당 그룹을 선택해 서버가 표시되는지 확인하세요. 목록이 비어 있으면 검색어와 필터를 지운 뒤 로그에서 업데이트 결과를 확인하세요. 그룹 업데이트 성공과 서버 연결 성공은 별개의 문제입니다. 메뉴에 오류가 없다는 이유만으로 연결이 완료됐다고 판단하지 마세요.

서버 하나를 선택해 “실제 연결 지연 시간”을 테스트한 뒤, 테스트를 통과한 서버를 활성 서버로 지정하세요. TCPing은 원격 포트에 연결할 수 있는지에 가까운 검사이며 프로토콜 핸드셰이크, 인증, 대상 요청까지 성공했음을 보장하지 않습니다. 실제 연결 지연 시간도 테스트 대상 주소에 영향을 받으므로 브라우저 요청을 통한 추가 확인이 필요합니다. 여러 서버를 한꺼번에 테스트한 뒤 한 번의 결과로 결론 내리지 마세요. 서버 하나와 테스트 대상 하나를 고정하고 로그에서 아웃바운드 연결이 만들어지는지 확인한 다음 다른 서버와 비교하세요.

시스템 프록시 설정 및 종료 시 정리

코어가 실행 중인지 확인한 다음 v2rayN의 시스템 프록시 메뉴에서 “시스템 프록시 자동 설정”을 선택하세요. Windows 설정에서도 프록시 상태를 확인하고, 주소가 로컬 컴퓨터를 가리키며 포트가 클라이언트의 리스닝 설정과 일치하는지 확인하세요. 시스템 프록시는 해당 설정을 사용하는 앱에만 적용됩니다. 일부 명령줄 도구, 게임, 별도 네트워크 프로그램은 자동으로 프록시를 사용하지 않습니다. 브라우저에 프록시 확장 프로그램이나 별도 설정이 있다면 시스템 설정을 덮어쓰는 규칙이 없는지 확인하고 프록시 출처를 하나로 통일하세요. 브라우저에서 일반 웹페이지가 열린다고 해서 요청이 현재 서버를 통해 전송됐다는 뜻은 아닙니다.

외부 연결을 확인한 뒤 TUN을 사용할지 결정하세요. TUN이 필요하다면 클라이언트 안내에 따라 필요한 권한을 부여하세요. 일반 시스템 프록시 연결 문제를 해결하기 위해 관리자 권한으로 계속 실행할 필요는 없습니다. 시작할 때 포트가 이미 사용 중이라는 메시지가 나오면 이전 인스턴스를 종료하고 다른 리스닝 프로그램이 있는지 확인하세요. 포트를 변경했다면 수동으로 설정한 앱도 함께 수정해야 합니다. 종료하기 전에 시스템 프록시를 해제한 뒤 클라이언트를 닫으세요. 그렇지 않으면 중지된 로컬 포트로 앱이 계속 접속할 수 있습니다. 절전 모드에서 복귀하거나 네트워크를 바꾸거나 업데이트한 뒤 연결이 끊기면 구독을 전부 삭제하기보다 시스템 프록시와 코어 상태부터 확인하세요.

macOS 설치 및 권한 설정

칩에 맞는 설치 항목 선택

“이 Mac에 관하여”에서 칩 또는 프로세서 정보를 확인한 다음 macOS 다운로드로 이동하세요. Apple Silicon에는 해당하는 arm64 설치 항목을, Intel에는 x64 항목을 선택하세요. 호환 모드를 기본 설치 방식으로 삼지 말고 기기에 맞는 네이티브 패키지를 우선 사용하세요. 다운로드한 디스크 이미지를 열고 패키지 안내에 따라 v2rayN을 응용 프로그램 폴더에 넣은 뒤 해당 폴더에서 실행하세요. 마운트한 디스크 이미지에서 계속 실행하면 업데이트, 경로 접근, 종료 후 재실행 시 혼란이 생길 수 있습니다.

처음 실행할 때는 시스템 안내를 먼저 읽으세요. 다운로드 출처 제한 때문에 실행할 수 없다면 파일 출처를 확인한 뒤 시스템의 “개인정보 보호 및 보안” 화면에서 해당 안내에 따라 처리하세요. 앱 하나를 실행하려고 컴퓨터 전체의 보안 기능을 끄지 마세요. 파일 손상, 아키텍처 불일치, 구성 요소 로드 실패가 명확히 표시되면 다운로드 항목과 시스템 요구 사항, 설치 과정을 다시 확인하세요. 임의의 터미널 명령으로 보안 제한을 강제로 우회하지 마세요. 클라이언트 창이 열린 뒤에도 코어가 정상적으로 시작되는지 확인해야 합니다. 인터페이스가 실행된다는 사실만으로 코어의 작동 상태를 확인할 수는 없습니다.

구독 그룹을 만들고 현재 네트워크 서비스 확인

“구독 그룹 설정”에 별칭과 “可选地址 Url”을 입력하고 저장한 뒤 구독을 업데이트하세요. 처음에는 프록시를 사용하지 않고 업데이트하는 방법을 우선 시도하세요. 주소에 기존 연결이 필요한 경우에는 먼저 해당 연결이 작동하는지 확인한 뒤 프록시를 통한 업데이트를 선택하세요. 인증 페이지가 표시되더라도 웹페이지 내용을 구독 파일로 저장하지 마세요. 업데이트가 끝나면 활성 서버를 선택해 실제 연결 지연 시간을 테스트하고 로그에 인증 또는 핸드셰이크 오류가 반복되는지 확인하세요. 인터페이스 언어와 메뉴 위치는 버전에 따라 달라질 수 있지만 주소, 그룹, 업데이트 방식의 관계는 같습니다.

시스템 프록시가 필요하면 클라이언트가 자동으로 설정하도록 한 다음 시스템 설정에서 현재 네트워크 서비스를 확인하세요. Wi-Fi, 유선 네트워크 등 서비스마다 프록시 설정이 다를 수 있으므로 네트워크를 바꾼 뒤에도 실제 사용 중인 서비스가 올바른 로컬 리스닝 포트를 가리키는지 확인하세요. 클라이언트가 자동으로 설정을 변경하지 못하면 안내에 따라 권한을 부여하거나, 포트 유형을 정확히 알고 있는 경우에만 직접 설정하세요. HTTP 프록시 포트와 SOCKS 포트는 이름만 보고 서로 바꿔 쓸 수 없습니다. 클라이언트 설정에서 리스닝 유형을 확인한 뒤 시스템의 해당 항목에 입력하세요.

앱 프록시, 권한, 네트워크 복구 구분

특정 앱이 시스템 프록시를 따르지 않으면 자체 네트워크 설정을 사용하는지 먼저 확인하세요. 명령줄 프로그램은 시스템 그래픽 설정 대신 환경 변수를 읽을 수 있으므로 터미널과 브라우저의 요청 결과가 다르다고 해서 서버에 문제가 있다고 단정할 수 없습니다. 브라우저 확장 프로그램은 다른 포트를 지정하고 시스템 프록시는 별도로 사용하는 식으로 설정을 겹치지 마세요. 테스트 앱에서 프록시 출처를 하나로 정한 뒤 직접 연결과 프록시 결과를 비교하세요. 외부 연결을 확인할 때는 같은 대상과 같은 요청 방식을 사용해 캐시나 주소 계열 차이로 잘못 판단하지 않도록 하세요.

TUN을 켜기 전에 다른 네트워크 트래픽 제어 프로그램을 종료하고, 현재 클라이언트 안내에 따라 권한과 구성 요소를 설정하세요. 데스크톱 인터페이스에 스위치가 있다고 해서 실행 조건이 모두 충족됐다고 가정하지 마세요. 절전 모드에서 깨어난 뒤 연결에 문제가 있으면 연결을 중지했다가 다시 시작하고 기본 경로와 DNS가 복구됐는지 확인하세요. 네트워크를 바꾼 뒤에는 활성 서버를 다시 테스트하세요. 앱을 삭제하거나 옮기기 전에는 TUN을 끄고 시스템 프록시를 해제한 다음 정상적으로 종료하세요. 프로그램을 삭제했는데도 네트워크에 문제가 남아 있다면 시스템 설정에서 남은 프록시 항목을 제거하고 다른 네트워크 서비스를 확인하세요. 전체 네트워크 설정을 무작정 초기화하지 마세요.

Linux 설치 및 데스크톱 환경별 차이

아키텍처와 패키지 형식 확인

배포판의 패키지 관리 방식을 먼저 확인한 다음 Linux 다운로드에서 v2rayN을 선택하세요. deb와 rpm은 서로 다른 패키지 관리 체계에 해당하며 x64와 arm64는 프로세서 아키텍처를 나타내므로 두 조건을 모두 맞춰야 합니다. 다운로드할 수 있다고 설치까지 가능한 것은 아니며, 파일 확장자만 다른 형식으로 바꾸어도 안 됩니다. 배포판의 그래픽 소프트웨어 설치 프로그램으로 파일을 열고 의존성과 권한 안내를 확인하세요. 의존성 누락이 표시되면 배포판의 소프트웨어 저장소를 이용해 해결하고 출처가 불분명한 구성 요소를 조합하지 마세요.

아래의 읽기 전용 터미널 명령으로 머신 아키텍처와 시스템 정보를 확인할 수 있습니다. 일반적으로 x86_64는 x64, aarch64는 arm64에 해당하지만 최종 기준은 패키지 안내와 배포판 지원 여부입니다. 설치가 끝나면 앱 메뉴에서 실행하고 디스플레이 환경, 런타임 또는 실행 권한 관련 오류가 있는지 확인하세요. 원격 터미널, 순수 명령줄 서버, 일반 데스크톱 세션은 실행 환경이 서로 다릅니다. 이 페이지는 데스크톱 GUI 클라이언트를 다루며 그래픽 앱을 헤드리스 서비스로 배포하는 방법을 안내하지 않습니다.

uname -m
cat /etc/os-release

구독을 가져오고 데스크톱 프록시 확인

“구독 그룹 설정”에서 그룹을 추가하고 구독 주소를 저장한 뒤 구독 업데이트를 실행하고 활성 서버를 선택하세요. 데스크톱 프록시를 설정하기 전에 실제 연결 지연 시간을 테스트해 코어가 요청을 처리할 수 있는지 확인하세요. 업데이트에 실패하면 앱의 인터넷 연결 문제인지, 구독 주소에 접근할 수 없는지, 응답 형식을 인식하지 못하는지 구분하세요. 시스템 소프트웨어 설치 프로그램이 인터넷에 연결된다고 해서 클라이언트도 같은 프록시 경로를 사용하는 것은 아닙니다. 환경 변수와 네트워크 설정이 서로 다를 수 있습니다. 오류 근거 없이 패키지 형식을 반복해서 바꾸지 마세요.

Linux에는 모든 데스크톱 환경에 공통으로 적용되는 시스템 프록시 스위치가 없으며, 앱마다 프록시 설정을 읽는 방식이 다릅니다. 클라이언트가 시스템 프록시를 자동 설정한 뒤 현재 데스크톱 환경의 네트워크 설정에서 상태를 확인하세요. 데스크톱 프록시를 읽지 않는 앱은 앱 자체 설정이나 임시 프록시 환경 변수를 사용해야 합니다. 먼저 클라이언트의 실제 리스닝 포트와 프로토콜을 확인하세요. 아래 예시는 로컬 포트를 명시해 HTTP 프록시 요청을 테스트하는 방법입니다. 실행 전에 포트를 클라이언트에 표시된 값으로 바꾸세요. 이 테스트는 앱 설정을 분리해 확인하며 시스템 프록시를 영구적으로 변경하지 않습니다.

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

권한, 컨테이너, 종료 후 복구

일반 데스크톱 연결은 가능하면 일반 사용자 세션에서 사용하세요. TUN은 가상 네트워크 장치에 접근하고 라우팅을 변경하므로 필요한 권한과 설정은 클라이언트와 시스템에 따라 다릅니다. 화면 안내에 따라 처리하고 편의를 위해 그래픽 프로그램 전체를 항상 높은 권한으로 실행하지 마세요. 코어 로그에 장치 없음, 권한 부족, 경로 추가 실패가 표시되면 해당 시스템 조건부터 해결한 뒤 서버를 테스트하세요. 포트를 이미 사용 중이라면 점유한 프로그램을 찾거나 리스닝 포트를 변경하고 앱 설정도 함께 수정하세요. 코어만 계속 재시작하지 마세요.

컨테이너, 샌드박스 앱, 원격 세션에서는 127.0.0.1이 데스크톱 클라이언트가 있는 네트워크 환경을 가리키지 않을 수 있습니다. 프록시를 명시한 요청이 실패하면 리스닝 주소를 모든 네트워크 인터페이스에 바꾸기 전에 프로그램과 클라이언트가 같은 네트워크 네임스페이스를 사용하는지 확인하세요. LAN에서 접근해야 한다면 방화벽, 인증, 접근 가능한 범위도 고려해야 합니다. 로그아웃, 절전 모드 진입, 데스크톱 전환 후 프록시 설정이 남아 있는지 확인하세요. 정상적으로 종료하기 전에 데스크톱 프록시를 해제하고 TUN을 중지하세요. 앱을 업데이트할 때는 설정을 백업하고, 설치 후 권한을 다시 확인하세요. 이전 권한이 항상 유효하다고 가정하지 마세요.

Android 설치 및 백그라운드 연결

v2rayNG 또는 v2flyNG 선택

Android 다운로드로 이동해 일반적으로 Xray 코어를 사용하는 v2rayNG를 먼저 선택하세요. V2Fly 코어가 꼭 필요하고 프로토콜 호환성을 확인한 경우에만 v2flyNG를 선택하세요. 두 앱은 같은 프로그램의 테마만 다른 버전이 아니므로 가져오기 결과와 지원 프로토콜이 완전히 같지 않을 수 있습니다. 일반적인 arm64 기기에는 해당 설치 항목을 우선 선택하세요. 아키텍처를 확인하기 어렵다면 범용 버전을 고려하되 시스템 요구 사항도 확인해야 합니다. 범용 버전의 파일 크기가 더 크다고 프록시 기능이 더 많다는 뜻은 아닙니다. 아키텍처 패키징과 프로토콜 기능은 별개의 기준입니다.

설치할 때 시스템 안내에 따라 현재 출처에서 앱을 설치하도록 허용하세요. 설치를 마치면 해당 출처의 앱 설치 권한을 다시 취소할 수 있습니다. 업데이트 전에 구독 주소와 필요한 설정을 보관하세요. 서명이 일치하지 않는 등의 설치 충돌이 발생하면 먼저 안내를 읽고, 로컬 데이터가 사라질 수 있으므로 바로 삭제하지 마세요. 설치 후 클라이언트를 열고 데이터를 가져온 다음 연결을 시작하세요. 서버 목록이 표시된다고 해서 네트워크 트래픽 제어 권한까지 얻은 것은 아닙니다. 처음 연결할 때 시스템 VPN 권한 안내에 따라야 하며, 권한을 거부했다면 연결을 다시 누르고 안내에 따라 승인하세요.

그룹을 가져와 VPN 연결 설정

v2rayNG에서 구독 그룹 메뉴를 열고 별칭과 구독 주소를 추가한 뒤 저장하고 구독을 업데이트하세요. 화면 버전에 따라 업데이트 메뉴가 다른 위치에 있을 수 있으므로 “구독 그룹”과 “구독 업데이트” 항목을 찾아보세요. 공유 링크 하나만 있다면 클립보드에서 설정을 가져오는 메뉴를 사용하고 구독 URL 입력란에 넣지 마세요. v2flyNG는 메뉴 이름과 배치가 다를 수 있으므로 실제 구독 관리 메뉴를 이용하세요. 다른 클라이언트의 스크린샷과 경로가 반드시 같다고 가정하지 마세요.

사용할 서버를 선택하고 연결을 눌러 시스템 VPN 권한을 승인하세요. VPN 상태 아이콘은 시스템이 앱에서 제공하는 트래픽 제어 통로를 만들었다는 뜻일 뿐, 원격 인증이 성공했다는 의미는 아닙니다. 연결 후 클라이언트의 실제 연결 테스트를 실행하거나 브라우저에서 고정된 테스트 대상으로 접속하고 로그를 확인하세요. Android의 VPN 적용 방식은 데스크톱 시스템 프록시와 다르므로 Wi-Fi 수동 프록시를 다시 설정할 필요는 보통 없습니다. 이전 Wi-Fi 프록시 설정이 남아 있다면 존재하지 않는 로컬 포트를 가리키는지 확인해 설정이 겹치지 않도록 하세요.

앱별 설정, 백그라운드 실행, 네트워크 전환

앱별 프록시를 켜기 전에 현재 목록이 “선택한 앱만 프록시 사용”을 뜻하는지, “선택한 앱은 우회”를 뜻하는지 확인하세요. 두 설정은 정반대이므로 잘못 선택하면 브라우저만 또는 특정 앱만 연결되지 않는 일이 생깁니다. 목록을 바꾼 뒤에는 클라이언트 안내에 따라 다시 연결해야 새 설정이 VPN에 적용됩니다. 문제를 해결하는 동안에는 복잡한 앱별 규칙을 끄고 전체 트래픽이 적용되는지 확인한 뒤 하나씩 다시 설정하세요. 업무 프로필과 기본 사용자 공간에는 별도 제한이 적용될 수 있습니다. 기본 공간에서 연결됐다고 해서 다른 공간의 앱도 같은 통로를 사용하는 것은 아닙니다.

화면을 잠근 뒤 연결이 중단되면 앱 배터리 정책, 백그라운드 활동 제한, 시스템의 백그라운드 정리 설정을 확인하고 기기에 실제로 있는 옵션에서 필요한 백그라운드 실행을 허용하세요. 모든 절전 기능을 무조건 끄기보다 잠금이나 정리 작업 직후 연결이 끊기는지 먼저 확인하세요. Wi-Fi와 모바일 네트워크를 전환하면 기존 연결을 다시 설정해야 할 수 있습니다. 먼저 재연결한 뒤 서버 주소 확인과 핸드셰이크 결과를 살펴보세요. 시스템 VPN 통로를 사용하는 다른 앱은 현재 연결과 충돌할 수 있으므로 트래픽을 제어하는 앱을 하나만 사용하세요. 클라이언트를 바꿀 때는 이전 연결을 먼저 중지한 뒤 새 클라이언트에서 그룹을 설정해 두 앱이 통로를 번갈아 점유하지 않도록 하세요.

구독 그룹 및 업데이트 방법

출처별로 주소와 업데이트 방식 관리

출처가 다른 구독은 각각 별도의 구독 그룹에 넣으세요. 별칭은 구분을 위한 이름이므로 원격 서버 이름과 같을 필요는 없습니다. “可选地址 Url”에는 전체 구독 주소를 입력하고 쿼리 매개변수와 대소문자를 그대로 유지하세요. 주소 뒤에 설명을 덧붙이지 마세요. 복사하는 과정에서 메신저가 줄바꿈, 공백, 생략 부호를 넣을 수 있으므로 중간 token을 직접 고치기보다 가져오기 전에 주소의 시작과 끝을 확인하세요. 구독 주소에는 접근 권한 정보가 들어 있을 수 있으므로 백업, 스크린샷, 문의 자료를 공유할 때 민감한 부분을 가리세요. 로컬 그룹 이름은 원격 계정 권한이나 서비스 만료일을 바꾸지 않습니다.

“모든 구독 업데이트(프록시 사용 안 함)”은 현재 네트워크에서 구독 주소에 직접 접근할 수 있을 때 사용하세요. “모든 구독 업데이트(프록시 사용)”은 이미 사용할 수 있는 프록시 경로가 있어야 합니다. 기존 서버가 모두 작동하지 않으면 후자는 업데이트에 필요한 연결을 만들지 못해 반복적으로 실패할 수 있습니다. 한 가지 방법이 항상 정답이라고 생각하지 말고 구독 주소의 실제 접근 가능성에 따라 선택하세요. 업데이트가 실패해도 기존 목록을 먼저 지우지 말고 오류를 확인한 뒤 경로를 바꾸세요. 복구에 사용할 수 있는 기존 연결까지 잃을 수 있습니다.

자동 업데이트, 필터, 요청 식별자 이해

“자동 업데이트 간격(분)”은 업데이트 확인 주기를 설정하지만 실제 실행 시점은 클라이언트 실행 상태, 타이머, 네트워크 환경에도 영향을 받습니다. 서버가 정해진 시각에 업데이트를 보내 준다는 뜻은 아닙니다. 먼저 수동 업데이트가 성공하는지 확인하고 제공업체의 제한에 맞춰 간격을 설정하세요. 지나치게 짧은 주기로 반복 요청하지 마세요. 절전 또는 오프라인 중 업데이트가 실행되지 않았다고 반드시 오류인 것은 아닙니다. 네트워크가 복구된 뒤 수동으로 한 번 업데이트할 수 있습니다. 그룹을 비활성화하면 업데이트 대상에서 제외될 수 있으며 기존 서버가 유지되는지는 클라이언트 동작에 따라 다릅니다. 변경 전에 설정을 백업하세요.

“필터(정규식)”는 구독에 포함된 서버 이름을 걸러냅니다. 필터 표현식으로 서버의 유효성을 바꾸거나 빠진 프로토콜 매개변수를 채울 수는 없습니다. 조건이 너무 엄격하면 업데이트가 성공해도 목록이 비어 있을 수 있습니다. 문제를 확인할 때는 먼저 필터를 비우고 원본 구독을 인식할 수 있는지 확인한 다음 간단한 조건을 하나씩 추가하세요. “User-Agent”는 제공업체가 명시적으로 요구하거나 응답 형식 호환이 필요할 때만 변경하세요. 다른 클라이언트를 임의로 흉내 내면 해석할 수 없는 응답을 받을 수 있습니다. 사용자 지정 값을 적용한 이유를 기록하고 문제가 생기면 기본 요청 방식으로 되돌리세요.

구독 데이터와 실행 설정 구분

구독을 업데이트하면 서버 항목이 다시 생성될 수 있어, 구독에서 가져온 서버를 직접 수정한 내용이 다음 업데이트에서 덮어써질 수 있습니다. 예외 설정을 유지해야 한다면 클라이언트에서 별도 저장이나 사용자 지정 설정을 지원하는지 확인하세요. 덮어써질 수 있는 데이터에 많은 수정을 쌓아 두지 마세요. 그룹을 삭제하기 전에 확인 메시지를 읽고 연결된 서버도 함께 삭제되는지 살펴보세요. 다른 클라이언트로 옮길 때는 먼저 클라이언트가 지원하는 형식으로 데이터를 백업한 다음 구독 주소를 저장하세요. 현재 사용 중인 임시 실행 설정을 복사하는 것만으로는 구독 관계, 필터, 앱 환경 설정이 완전히 복원되지 않을 수 있습니다.

아래는 독립적으로 파싱할 수 있는 Xray JSON 예시입니다. 로컬 SOCKS 인바운드와 직접 연결 아웃바운드만 설정해 실행 구성의 구조를 확인하기 위한 것으로, 원격 프록시 연결이나 구독 데이터는 제공하지 않습니다. 이를 클라이언트가 자동 생성한 설정 대신 사용해 “서버 문제를 해결”하려 하지 마세요. 실제 프로토콜, 전송 방식, 보안 계층, 서버 매개변수는 모두 서로 맞아야 합니다. 설정 구조가 여전히 헷갈린다면 Xray와 V2Fly 코어의 차이를 읽고 클라이언트와 프로토콜의 호환성을 확인하세요.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

시스템 프록시, TUN, 라우팅

먼저 트래픽 진입 방식을 정하고 다음으로 아웃바운드 규칙을 선택하세요

시스템 프록시, TUN, 라우팅은 서로 다른 기능입니다. 시스템 프록시는 해당 설정을 읽는 앱이 요청을 로컬 포트로 보내도록 합니다. TUN은 가상 네트워크 장치를 통해 조건에 맞는 트래픽을 가져옵니다. 라우팅 규칙은 코어에 들어온 요청이 어떤 아웃바운드로 나갈지 결정합니다. 세 기능은 같은 계층이 아닙니다. “전역”은 보통 코어에 들어온 뒤 적용되는 기본 아웃바운드 정책을 뜻하며 모든 앱의 트래픽이 이미 제어되고 있다는 의미는 아닙니다. 따라서 시스템 프록시를 사용하는 상태에서 전역을 선택해도 일부 독립 네트워크 프로그램은 직접 연결될 수 있습니다. 이는 라우팅 설정과 모순되지 않습니다.

브라우저와 시스템 프록시를 따르는 데스크톱 앱만 필요하다면 시스템 프록시부터 사용하세요. 동작을 확인하고 되돌리기도 더 쉽습니다. 시스템 프록시를 따르지 않는 프로그램을 처리해야 한다면 그때 TUN을 검토하세요. 사용 전에 기존 프록시 상태를 기록하고 다른 트래픽 제어 프로그램을 종료한 뒤 권한, 가상 장치, 관련 구성 요소가 준비됐는지 확인하세요. 여러 클라이언트에서 TUN을 동시에 켜고 라우팅 규칙 변경으로 충돌을 해결하려 하지 마세요. TUN을 켠 뒤 전체 네트워크가 끊기면 먼저 TUN을 꺼서 연결을 복구하고 로그를 확인하세요. 기본 네트워크도 사용할 수 없는 상태에서 DNS 설정을 계속 추가하지 마세요.

DNS, 도메인 정책, 규칙 순서 확인

라우팅 규칙은 클라이언트가 실제로 얻은 대상 정보에 따라 적용됩니다. HTTP, SOCKS, TUN, 앱에 따라 도메인이 전달되기도 하고 IP만 전달되기도 하므로 모든 요청이 도메인 규칙에 걸린다고 가정할 수 없습니다. 도메인 정책의 AsIs는 라우팅 매칭을 위해 도메인을 추가로 조회하지 않습니다. IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 IP 규칙을 이어서 확인하기 위해 조회를 시도합니다. IPOnDemand는 IP가 필요한 규칙을 만났을 때 필요에 따라 조회합니다. 정책을 바꾸면 조회 시점은 달라질 수 있지만 작동하지 않는 DNS 서버가 자동으로 고쳐지지는 않습니다.

규칙 순서는 실제 처리 결과에 영향을 주는 경우가 많으며 먼저 일치한 규칙이 요청의 처리 방향을 결정합니다. 사설 주소의 직접 연결 규칙을 적절한 위치에 두면 LAN 리소스가 원격 서버를 거치는 일을 막을 수 있지만, 사용 목적에 맞는 접근 범위인지 확인해야 합니다. geosite:cn, geoip:private 같은 표기는 해당 규칙 데이터와 코어의 지원 여부에 따라 달라집니다. 아웃바운드 태그도 설정에 이미 존재하는 태그와 일치해야 합니다. “proxy”라는 문자열만 복사하고 해당 아웃바운드가 없으면 연결이 자동으로 만들어지지 않습니다. 변경 후에는 생성된 설정이나 로그에서 규칙이 실제로 로드됐는지 확인하세요. 화면에 저장되는 것만으로는 충분하지 않습니다.

트래픽 제어 효과를 확인하고 복구 경로 확보

확인할 때는 활성 서버와 테스트 대상을 고정하세요. 클라이언트에서 실제 연결 지연 시간을 확인한 다음 브라우저에서 같은 유형의 대상에 요청을 보내고 외부 연결 경로를 살펴보세요. 명령줄 프로그램은 프록시를 명시한 요청과 비교할 수 있습니다. 명시적 프록시는 성공하고 기본 요청은 실패한다면 먼저 앱의 프록시 설정 출처를 확인하세요. 두 방식 모두 실패할 때 코어, 서버, 라우팅을 살펴보세요. IPv4와 IPv6는 서로 다른 경로를 사용할 수 있으므로 결과가 다르면 모든 트래픽이 프록시를 우회한다고 단정하지 말고 주소 계열부터 구분하세요. 자세한 확인 방법은 시스템 프록시 설정과 실제 연결 지연 시간 테스트를 참고하세요.

복구할 때는 활성화한 순서의 반대로 처리하세요. TUN을 중지하고 시스템 프록시를 해제한 다음 클라이언트를 정상 종료하세요. 프록시 환경 변수나 앱별 프록시를 직접 설정했다면 각각 복구해야 합니다. 클라이언트를 종료해도 각 앱에 저장된 설정까지 자동으로 바뀌지는 않습니다. LAN 기기, 원격 데스크톱, 업무 네트워크는 라우팅 변경에 민감할 수 있으므로 설정을 바꾸기 전에 로컬 접근 경로를 확보하세요. 특정 앱을 연결하려고 리스닝 주소를 모든 네트워크 인터페이스에 공개하지 마세요. 프록시를 공유해야 한다면 접근 제어와 방화벽을 별도로 검토해야 합니다. 로컬 설정을 그대로 LAN 서비스에 사용하지 마세요.

자주 발생하는 설정 문제 및 로그 확인

실행, 구독, 연결 단계별로 확인

가장 먼저 실패한 단계부터 확인하세요. 인터페이스가 열리지 않으면 설치, 아키텍처, 실행 환경을 점검하세요. 인터페이스는 정상인데 코어가 시작되지 않으면 로그에서 포트 사용 중, 설정 파싱, 권한 문제를 확인하세요. 코어가 시작된 뒤 구독에 실패하면 주소, 요청 경로, 응답 내용을 살펴보세요. 구독은 성공했는데 연결이 실패할 때 프로토콜 설정과 서버 접근성을 확인하면 됩니다. 모든 문제를 재설치로 해결하려 하지 마세요. 재설치해도 기존 설정이 남을 수 있고, 중요한 오류 기록이 지워질 수도 있습니다. 오류 원문과 발생 동작을 먼저 저장한 뒤 최소한으로 수정하세요.

로그 오류는 앞뒤 상황과 함께 확인하세요. address already in use는 보통 로컬 리스닝 포트가 사용 중이라는 뜻이지, 원격 서버가 연결을 거부했다는 뜻은 아닙니다. JSON 파싱 실패는 해당 필드, 쉼표, 데이터 형식을 확인해야 합니다. 알 수 없는 프로토콜이나 지원되지 않는 필드가 나오면 현재 코어가 해당 설정을 지원하는지 확인하세요. 클라이언트가 자동 생성한 파일은 다시 시작할 때 덮어써질 수 있으므로 화면의 설정 원본부터 수정하세요. 코어 시작 실패 및 설정 오류 해결을 참고해 설정 생성 문제와 실행 환경 문제를 구분하세요.

인증서, 인증, 네트워크 시간 초과 구분

TLS 오류가 발생하면 먼저 시스템 시간을 확인한 다음 서버 주소, SNI, 인증서 도메인 간의 관계를 확인하세요. 연결 주소와 인증서 검증 이름은 다를 수 있지만 제공업체의 설정에 맞아야 하며, 흔히 쓰이는 웹사이트 도메인으로 임의 변경해서는 안 됩니다. 인증서 검증 건너뛰기를 일반적인 해결책으로 사용하지 마세요. 이름 불일치나 신뢰 체인 문제를 가릴 뿐입니다. REALITY 등 관련 설정은 공개 키, 짧은 식별자, 서버 이름과 다른 매개변수를 제공업체 안내에 따라 함께 가져와야 합니다. 다른 서버의 값을 하나씩 조합하지 마세요. 자세한 배경은 시간 동기화 및 SNI 오류 안내를 참고하세요.

시간 초과는 특정 대기 과정이 제한 시간 안에 끝나지 않았다는 뜻입니다. 도메인 조회, 연결 수립, 핸드셰이크, 대상 요청 중 어느 단계에서 발생했는지 확인해야 합니다. 연결 거부와 시간 초과도 다릅니다. 전자는 대상 포트에서 서비스가 실행되지 않는 경우일 수 있고, 후자는 네트워크 경로나 원격 응답 문제일 수 있습니다. 이미 작동한다고 확인한 다른 서버와 먼저 비교한 뒤 네트워크를 바꿔 테스트하세요. 모든 프로토콜 설정을 한꺼번에 수정하지 마세요. 모든 서버에서 동시에 실패하면 구독 전체가 만료됐다고 바로 판단하기보다 로컬 프록시 설정 잔여 항목, DNS, 공용 네트워크 로그인 상태, 코어 실행 여부도 확인하세요.

재현에 필요한 정보를 보관하고 단계적으로 복구

문제를 문의할 때 운영체제, 프로세서 아키텍처, 클라이언트 이름, 트래픽 제어 방식, 실패한 동작, 민감 정보를 가린 로그 일부를 기록하세요. 전체 구독 주소, 인증 식별 정보, 민감한 매개변수가 포함된 설정 파일을 공개하지 마세요. “구독 업데이트 실패”인지 “브라우저가 열리지 않음”인지 구체적으로 설명하면 “작동하지 않음”이라고만 하는 것보다 원인을 찾기 쉽습니다. 화면을 잠근 뒤, 네트워크를 전환한 뒤, 특정 앱에서만 발생하는 문제라면 그 조건도 기록하세요. 복구한 뒤 필터, 앱별 설정, DNS, 사용자 지정 라우팅을 하나씩 다시 추가하고 항목마다 검증하세요. 문제를 다시 불러오지 않도록 한 번에 하나씩 확인하세요.

문제 유형별 안내가 필요하면 자주 묻는 질문을 확인하세요. 최소 설정으로 다시 연결하려면 구독 가져오기 단계로 돌아가세요. 복구가 끝나면 작동하는 설정과 테스트 기록을 보관하세요. 다음에 문제가 생기면 처음부터 모든 설정을 다시 하기보다 변경된 항목부터 비교하세요.