V2Ray 전체 플랫폼
설치 및 설정

공통 준비 사항: 설정 출처와 트래픽 처리 방식 확인

클라이언트, 코어, 노드의 역할

클라이언트는 구독을 저장하고 노드를 표시하며 설정을 생성하고 연결을 제어합니다. 코어는 프로토콜 핸드셰이크, 라우팅 규칙 적용, 데이터 전달을 담당합니다. 노드는 실제로 연결되는 원격 서버입니다. v2rayN이나 v2rayNG를 설치해도 사용할 수 있는 노드가 자동으로 생기지는 않습니다. 같은 프로토콜을 사용하더라도 주소, 인증 정보, 전송 설정을 서로 바꿔 쓸 수 있는 것은 아닙니다. 시작하기 전에 사용 권한이 있는 구독 주소나 노드 설정 정보를 확보하고, 운영체제에 맞는 클라이언트를 선택하세요.

데스크톱에서는 v2rayN을 사용하면 Windows, macOS, Linux에서 비슷한 방식으로 설정할 수 있습니다. Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 고려하고, V2Fly 생태계 설정이 필요하다면 v2flyNG를 선택하세요. 지원되는 프로토콜은 이름이 아니라 실제 코어와 클라이언트 구현에 따라 달라집니다. 가져오기 전에 설정 제공자에게 공유 형식, 전송 방식, TLS 요구 사항을 확인해 코어가 인식하지 못하는 필드를 네트워크 오류로 오해하지 않도록 하세요.

시스템 아키텍처와 설치 위치 확인

Windows에서는 ‘설정 → 시스템 → 시스템 정보’에서 시스템 종류를 확인하세요. macOS에서는 Apple 메뉴의 ‘이 Mac에 관하여’에서 칩을 확인하고, Linux에서는 시스템의 ‘정보’ 페이지에서 배포판과 프로세서 아키텍처를 확인합니다. Android에서는 ‘설정 → 휴대전화 정보’에서 기기 모델을 확인한 뒤 사양과 대조하세요. 설치 파일 아키텍처는 기기와 호환되어야 하며 파일 크기만으로 판단해서는 안 됩니다. 모든 플랫폼의 설치 파일은 다운로드 페이지에서 찾을 수 있습니다. 운영체제를 선택한 뒤 해당 아키텍처와 패키지 형식을 고르세요.

사용자 디렉터리에 쓰기 권한이 있는지, 디스크 공간이 충분한지, 시스템 날짜와 시간대가 올바른지도 확인하세요. 인증서 검증에는 정확한 시간이 필요하며, 시간 오차는 시간 제한이 있는 프로토콜에도 영향을 줄 수 있습니다. 기존 클라이언트를 사용 중이라면 노드 그룹, 라우팅 모드, 수신 대기 포트, 구독 업데이트 방식을 먼저 기록하세요. 기존 디렉터리의 파일을 새 설치에 통째로 덮어쓰지 마세요. 화면 구성이나 코어에 따라 설정 형식이 달라질 수 있으므로 먼저 백업한 다음 필요한 항목을 하나씩 옮기세요.

시스템 프록시, 앱 프록시, TUN 구분하기

시스템 프록시는 시스템 설정을 따르는 앱에 로컬 프록시 주소를 알리는 방식이며, 모든 프로그램이 이를 사용하는 것은 아닙니다. 앱 프록시는 특정 프로그램의 네트워크 설정에 주소와 포트를 직접 입력합니다. TUN은 가상 네트워크 인터페이스로 트래픽을 받아 더 넓은 범위를 처리하지만 권한, 라우팅, DNS 설정이 함께 맞아야 합니다. 이 세 가지는 트래픽이 클라이언트로 들어오는 방식입니다. 클라이언트의 ‘전역’ 또는 ‘우회’ 라우팅은 트래픽이 들어온 뒤 어디로 전달할지를 결정하므로 서로 혼동하지 마세요.

구독과 복구용 설정 기록 준비

구독은 업데이트할 수 있는 노드 정보 모음이지 계정 로그인 페이지가 아닙니다. 복사할 때 전체 경로와 쿼리 매개변수를 유지하고 공백, 줄바꿈, 메시지 끝의 문장 부호가 섞이지 않도록 하세요. 계정 식별 정보가 포함된 구독 주소는 민감한 정보입니다. 공개 스크린샷이나 온라인 디코더, 공유 문서에 넣지 마세요. 구독별로 별도 그룹을 만들고 업데이트, 교체, 삭제를 그룹 단위로 관리하면 수동으로 추가한 노드와 구독 노드가 뒤섞이는 일을 줄일 수 있습니다.

처음 설정할 때는 트래픽 처리 방식을 하나만 활성화하고 시스템 프록시의 기존 상태를 기록하세요. 연결을 확인한 뒤 TUN, 복잡한 분기 규칙, 사용자 지정 DNS를 추가합니다. 이렇게 하면 문제가 생겼을 때 어느 단계로 되돌려야 하는지 명확해집니다. 조직에서 관리하는 기기라면 네트워크 설정 권한부터 확인하세요. 시스템 프록시를 바꾸거나 가상 인터페이스를 만들 수 없다면 기기 관리 정책을 따라야 하며, 권한 제한을 설치 오류로 오해하지 마세요.

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

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

Windows 다운로드 옵션에서 v2rayN 데스크톱 버전과 클래식 WPF 버전을 선택할 수 있습니다. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하며, WPF 버전은 기존 Windows 화면 구성을 유지합니다. 두 버전 모두 올바른 노드 설정과 실행 가능한 코어가 필요합니다. 화면 차이가 노드 품질 차이를 뜻하지는 않습니다. 처음 설치한다면 데스크톱 버전을 우선 고려하세요. WPF 버전에 익숙하다면 설정을 백업한 뒤 전환 여부를 결정하면 됩니다. 두 버전을 동시에 실행할 필요는 없습니다.

설치 프로그램을 실행하고 안내에 따라 설치를 마치세요. 처음 실행할 때 실행 환경이 없다는 메시지가 나타나면 해당 배포 패키지에서 안내하는 시스템 구성 요소를 설치하세요. 다른 프로그램 디렉터리에서 런타임 파일을 임의로 복사하지 마세요. 설치 후 메인 창을 열어 로그 영역에 시작 오류가 계속 나타나지 않는지 확인합니다. 일반적인 시스템 프록시 사용에는 관리자 권한이 필요하지 않습니다. TUN, 서비스, 네트워크 인터페이스 관리가 필요한 경우에만 클라이언트 안내에 따라 권한을 부여하세요.

구독 그룹에 주소 추가하기

메인 창에서 ‘구독 그룹 → 구독 그룹 설정’으로 이동해 그룹 이름과 구독 주소를 입력하고 저장한 다음 기본 화면으로 돌아오세요. ‘구독 그룹’ 메뉴에서 ‘현재 구독 업데이트(프록시 사용 안 함)’를 실행하면 현재 네트워크에서 구독 서버에 직접 접속할 수 있습니다. 기존에 사용 가능한 프록시를 통해서만 구독 서버에 접속할 수 있다면 프록시를 사용하는 업데이트 항목을 선택하세요. 메뉴 이름은 화면 버전에 따라 달라질 수 있습니다. 현재 그룹과 전체 그룹을 구분해 다른 출처의 구독까지 잘못 업데이트하지 않도록 하세요.

업데이트 후 해당 그룹에서 서버 목록을 확인하세요. 목록이 비어 있다면 먼저 업데이트 로그를 읽어 요청 실패, 로그인 페이지 응답, 콘텐츠 파싱 실패를 구분합니다. 공유 링크를 복사했다면 ‘서버’ 메뉴에서 ‘클립보드에서 URL 일괄 가져오기’를 선택할 수 있습니다. QR 코드는 해당 스캔 메뉴를 이용하세요. 구독 주소, 단일 노드 공유 링크, 코어용 JSON은 서로 다른 입력 형식이므로 모두 주소 입력란에 붙여 넣으면 안 됩니다. 형식별 차이는 구독과 공유 링크 형식 비교에서 확인하세요.

사용할 노드 선택 및 시스템 프록시 활성화

서버 목록에서 노드를 선택하고 마우스 오른쪽 버튼 메뉴의 ‘활성 서버로 설정’ 또는 해당 화면의 기능을 이용해 활성화하세요. 먼저 로그에서 코어가 정상적으로 시작되는지 확인한 다음, 시스템 트레이 아이콘을 마우스 오른쪽 버튼으로 클릭해 ‘시스템 프록시’에서 ‘시스템 프록시 자동 설정’을 선택합니다. Windows의 ‘설정 → 네트워크 및 인터넷 → 프록시’로 돌아가 수동 프록시 주소가 클라이언트의 실제 수신 대기 주소를 가리키는지 확인하세요. 포트는 v2rayN 설정과 로그를 기준으로 확인하고 다른 기기의 값을 그대로 사용하지 마세요.

브라우저에 프록시를 별도로 제어하는 확장 프로그램이 설치되어 있다면 시스템 설정을 덮어쓰지 않도록 먼저 확장 프로그램 규칙을 비활성화하세요. 회사 네트워크에서 자동 구성 스크립트를 사용한다면 스크립트 주소를 먼저 기록해 두세요. 시스템 프록시를 바꾸면 기존 접속 경로에 영향을 줄 수 있습니다. 사용을 마칠 때는 v2rayN의 시스템 프록시 메뉴에서 프록시를 해제한 뒤 프로그램을 종료하세요. 프로세스를 바로 종료하면 시스템이 꺼진 로컬 포트를 계속 가리켜 브라우저 전체가 인터넷에 연결되지 않을 수 있습니다.

TUN 권한, 포트 및 일반적인 충돌

시스템 프록시 연결이 정상인지 확인한 뒤 메인 화면에서 ‘TUN’을 켜세요. 권한이 부족하다는 메시지가 나타나면 프로그램을 종료하고 필요한 경우 관리자 권한으로 실행한 뒤 활성 노드를 다시 확인합니다. TUN을 만들지 못하면 로그에서 가상 인터페이스, 라우팅, 권한 관련 정보를 확인하세요. 클라이언트를 연이어 재설치하지 마세요. 다른 VPN, 가상 머신 네트워크, 보안 프로그램도 라우팅을 변경할 수 있습니다. 먼저 트래픽을 처리하는 도구를 하나만 남겨 충돌 원인을 확인한 뒤 함께 사용할 방법을 검토하세요.

로그에 포트 바인딩 실패가 표시되면 ‘설정 → 매개변수 설정’에서 로컬 수신 대기 포트를 확인하고 같은 포트를 사용하는 이전 인스턴스를 종료하세요. 로컬 바인딩 문제를 해결하려고 ‘LAN 연결 허용’을 켜지 마세요. 이 옵션은 외부에 노출되는 범위를 바꿉니다. 원격 데스크톱에서 TUN을 전환하기 전에 복구 방법을 준비하세요. 라우팅이 바뀌면 세션이 끊길 수 있습니다. 마지막으로 클라이언트를 다시 시작해 구독이 남아 있는지, 활성 노드가 올바른지, 시스템 프록시를 해제한 뒤 정상적으로 복구되는지 확인하세요.

macOS: 칩에 맞는 설치, 권한 승인 및 프록시 복구

칩에 맞는 v2rayN 설치

Apple 메뉴에서 ‘이 Mac에 관하여’를 열고 Apple 칩이 표시되면 Apple Silicon 설치 파일을, Intel 프로세서가 표시되면 Intel 설치 파일을 선택하세요. 해당 파일은 macOS 다운로드 옵션에서 받을 수 있습니다. 디스크 이미지 파일을 연 뒤 설치 화면의 안내에 따라 앱을 ‘응용 프로그램’ 폴더로 옮기고 해당 폴더에서 실행하세요. 임시로 마운트한 이미지에서 계속 실행하지 마세요. 업데이트, 경로 참조, 권한 기록이 실제 설치 위치와 달라질 수 있습니다.

처음 실행할 때 시스템이 앱을 차단하면 파일 출처와 설치 과정을 먼저 확인한 뒤 ‘시스템 설정 → 개인정보 보호 및 보안’에 표시된 구체적인 안내를 살펴보세요. 예상한 앱이 맞는지 확인한 경우에만 시스템에서 제공하는 일회성 허용 기능을 사용하세요. 시스템 전체의 보안 기능을 끄지 마세요. 앱이 손상되었거나 실행할 수 없다는 메시지가 나타나면 먼저 칩에 맞는 설치 파일을 다시 받고 해당 배포 패키지가 시스템 요구 사항을 충족하는지 확인하세요. 이 오류는 노드 설정을 바꿔 해결할 수 없습니다.

구독을 가져오고 활성 서버 확인

v2rayN에서 ‘구독 그룹 → 구독 그룹 설정’으로 이동해 새 그룹을 만들고 주소를 저장한 뒤 현재 구독을 업데이트하세요. 프록시를 아직 설정하지 않았다면 우선 프록시를 사용하지 않고 업데이트해 보세요. 기존에 연결할 수 있는 프록시가 있고 구독 출처에서 해당 경로가 필요한 경우에만 프록시를 사용하도록 변경합니다. 업데이트가 끝나면 로그에서 요청과 파싱 결과를 확인하고 서버 목록에 예상한 내용이 표시되는지 살펴보세요. 그룹 이름은 로컬 메모일 뿐 구독 서버가 반환하는 노드에는 영향을 주지 않습니다.

노드를 선택해 활성 서버로 설정하고 코어가 정상적으로 시작되는지 확인하세요. 다른 컴퓨터에서 설정을 옮길 때는 프로그램 디렉터리 전체를 복사하기보다 구독을 다시 가져오는 방법을 우선 고려하세요. 데스크톱 설정에는 시스템별 경로, 창 상태, 코어 파일 위치가 포함될 수 있어 운영체제가 바뀌면 유효하지 않을 수 있습니다. 수동 노드는 포트, 인증 정보, TLS, SNI, 전송 경로를 하나씩 확인하세요. 메모 이름만 같다고 설정 내용까지 같은 것은 아닙니다.

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

클라이언트에서 시스템 프록시를 켠 뒤 ‘시스템 설정 → 네트워크’로 이동해 현재 사용하는 Wi-Fi 또는 이더넷 서비스를 선택하고 ‘세부사항 → 프록시’를 여세요. 웹 프록시, 보안 웹 프록시, SOCKS 프록시가 클라이언트 설정과 일치하는지 확인합니다. 시스템 버전에 따라 메뉴 이름은 조금씩 다를 수 있습니다. 연결되지 않은 인터페이스가 아니라 현재 사용하는 네트워크 서비스의 설정을 확인하는 것이 중요합니다. 주소와 포트는 실제 수신 대기 설정과 일치해야 하며 프로토콜 유형도 맞아야 합니다.

Wi-Fi를 바꾸거나 유선 네트워크에 연결하거나 네트워크 위치를 변경한 뒤 브라우저 동작이 달라졌다면 현재 서비스의 프록시 설정을 다시 확인하세요. 일부 프로그램은 자체 네트워크 설정을 사용해 시스템 프록시를 따르지 않을 수 있습니다. 프로그램 안에서 ‘시스템 프록시 사용’을 선택했는지 확인하세요. 브라우저 확장 프로그램이 프록시를 제어하는지도 살펴보세요. 확장 프로그램의 영향을 확인하려고 브라우저 데이터를 전부 삭제할 필요는 없습니다. 깨끗한 설정이나 확장 프로그램을 잠시 사용 중지한 창에서 비교하면 됩니다.

TUN, 절전 모드 및 종료 후 설정 복구

시스템 프록시를 따르지 않는 프로그램의 트래픽까지 처리해야 할 때만 TUN을 사용해 보세요. 클라이언트 안내에 따라 필요한 권한을 부여하고, 켠 뒤 로그에서 인터페이스와 라우팅이 정상적으로 설정되었는지 확인합니다. 스위치를 켠 뒤에도 트래픽이 흐르지 않는다면 먼저 TUN을 끄고 일반 시스템 프록시가 작동하는지 확인하세요. 그런 다음 권한, 다른 VPN, DNS 설정을 살펴봅니다. 시스템 프록시와 TUN의 모든 옵션을 번갈아 계속 바꾸면 실제로 어떤 경로가 달라졌는지 파악하기 어렵습니다.

컴퓨터가 절전 모드에서 깨어나면 네트워크 인터페이스가 다시 설정될 수 있습니다. 깨어난 뒤 연결되지 않는다면 네트워크가 복구되었는지 먼저 확인하고 현재 연결을 다시 시작하거나 트래픽 처리 방식을 재활성화하세요. 특정 Wi-Fi에서만 문제가 발생하면 해당 네트워크에 인증 페이지가 있는지 확인하고, 필요하다면 프록시를 잠시 중지해 일반적인 네트워크 인증을 완료하세요. 이때 구독이나 노드 설정을 삭제할 필요는 없습니다. 구독을 다시 가져와 중복 그룹을 만들지 말고 네트워크 복구 단계에서 문제를 먼저 확인하세요.

Android: 구독 가져오기 및 VPN 연결

v2rayNG와 v2flyNG 선택

Android 다운로드 옵션에서는 Xray 코어를 사용하는 v2rayNG를 우선 선택하세요. V2Fly 생태계 설정이 필요하다면 v2flyNG를 대안으로 사용할 수 있습니다. 최신 주류 스마트폰은 보통 arm64 버전을 선택하면 됩니다. 기기 아키텍처를 확인할 수 없다면 범용 버전을 고려하세요. 범용 버전은 더 많은 아키텍처를 지원하지만 운영체제 버전이나 하드웨어 호환성 제한까지 해결하지는 않습니다. 두 클라이언트가 지원하는 노드 형식은 다를 수 있으므로 QR 코드를 스캔할 수 있다는 이유만으로 모든 프로토콜을 함께 지원한다고 생각하지 마세요.

설치 파일을 열면 파일 관리자나 브라우저가 앱을 설치하도록 허용할지 시스템에서 물을 수 있습니다. 이번 설치에 필요한 출처만 허용하고 설치가 끝나면 시스템 설정에서 권한을 취소할 수 있습니다. 기존 앱과 패키지가 충돌한다는 메시지가 나타나면 같은 앱을 업데이트하는 중인지, 설치 출처가 일치하는지 먼저 확인하세요. 곧바로 기존 앱을 삭제하지 마세요. 삭제하면 로컬 노드, 앱별 규칙, 구독 그룹이 사라질 수 있으므로 설정을 백업한 뒤 설치 문제를 해결하세요.

구독 추가 및 클립보드에서 가져오기

v2rayNG에서는 사이드 메뉴에서 ‘구독 그룹 설정’으로 이동해 추가 메뉴를 통해 메모와 전체 구독 주소를 입력하고 저장하세요. 기본 목록으로 돌아와 메뉴에서 ‘구독 업데이트’를 실행합니다. 단일 공유 링크를 가져올 때는 메인 화면의 추가 메뉴에서 ‘클립보드에서 가져오기’를 선택하세요. QR 코드는 스캔 메뉴를 이용합니다. v2flyNG는 메뉴 배치가 다를 수 있으므로 ‘구독 그룹 설정’과 구독 업데이트 기능을 찾아보세요. 다른 클라이언트의 버튼 위치가 항상 같다고 가정하지 마세요.

업데이트 후 노드가 표시되지 않으면 복사한 주소가 계정 관리 페이지가 아닌 실제 구독 링크인지 확인하세요. 일부 출처는 추가 요청 조건이 필요한 콘텐츠를 반환해 모바일 클라이언트에서 인식하지 못할 수 있습니다. 로그를 열어 네트워크 접속 실패인지 형식 파싱 실패인지 확인한 뒤 설정 제공자에게 형식을 문의하세요. 전체 구독 링크를 공개된 문의 스크린샷에 올리지 마세요. 노드 주소를 가렸더라도 쿼리 매개변수의 계정 식별 정보는 다른 사람이 사용할 수 있습니다.

연결 시작 및 시스템 VPN 권한

메인 목록에서 노드를 선택해 선택 상태를 확인한 뒤 오른쪽 아래의 연결 버튼을 누르세요. 처음 연결할 때 Android의 VPN 연결 요청이 나타나면 허용해야 클라이언트가 로컬 트래픽 처리 인터페이스를 만들 수 있습니다. 이 권한은 기기 트래픽을 클라이언트에서 처리하도록 허용하는 것이며 원격 노드 연결 성공을 뜻하지는 않습니다. 시스템에 VPN 아이콘이 표시되어도 트래픽 처리 서비스가 실행 중이라는 의미일 뿐입니다. 원격 핸드셰이크와 라우팅이 정상인지 로그와 실제 접속으로 확인하세요.

같은 사용자 환경에서 다른 VPN 앱이 시스템 트래픽 처리 권한을 사용 중일 수 있습니다. 클라이언트를 시작한 뒤 다른 연결이 중지되면 두 앱이 모두 VPN 서비스를 사용하는지 확인하세요. 앱별로 트래픽을 나누려면 클라이언트의 ‘설정 → 앱별 프록시’에서 모드를 선택하고 선택한 앱을 프록시할지, 선택한 앱을 우회할지 설명을 꼼꼼히 읽으세요. 목록을 바꾼 뒤 연결을 다시 설정하고 대상 앱을 열어 확인해야 합니다. 목록에 체크 표시가 있는지만 보고 적용 방향을 판단하지 마세요.

백그라운드 제한 및 네트워크 전환

앱을 백그라운드로 보낸 뒤 연결이 자주 끊긴다면 Android의 ‘설정 → 앱 → v2rayNG → 배터리’에서 백그라운드 제한을 확인하세요. 제조사에 따라 배터리 최적화, 백그라운드 관리, 자동 시작 메뉴에 있을 수 있습니다. 필요한 경우 백그라운드 실행을 허용해 화면이 잠긴 뒤 시스템이 서비스를 종료하지 않도록 하세요. 모든 앱의 제한을 해제하지 말고 계속 연결해야 하는 클라이언트만 조정한 뒤 배터리와 네트워크 사용량을 확인하세요.

Wi-Fi와 모바일 데이터 사이를 전환하면 로컬 주소, 라우팅, DNS 환경이 바뀝니다. 전환 후 연결이 멈췄다면 연결을 중지했다가 다시 시작하고 노드 주소를 다시 확인할 수 있는지 살펴보세요. 특정 앱만 실패하면 앱별 규칙, 앱 자체 프록시 설정, 백그라운드 데이터 권한을 확인하세요. 모든 앱이 동시에 실패한다면 활성 노드와 기본 네트워크를 확인합니다. 연결 아이콘은 표시되지만 로그에 새 요청이 없다면 바로 프로토콜을 바꾸기보다 트래픽이 서비스에 들어오고 있는지 먼저 확인하세요.

다른 휴대전화로 옮길 때는 구독을 다시 추가한 다음 앱별 규칙을 따로 복원하는 방법을 우선 고려하세요. 앱 목록은 새 기기에 실제로 설치된 앱에 따라 달라지므로 이전 목록을 그대로 복사하면 대상 앱이 빠질 수 있습니다. QR 코드와 공유 링크는 해당 노드만 옮길 수 있으며 구독 업데이트 주소, DNS, 라우팅 설정까지 포함하지 않을 수 있습니다. 여러 기기 설정은 노드 및 설정 동기화 안내에서 더 확인하세요.

Linux: 패키지 형식, 데스크톱 프록시 및 권한

배포판과 아키텍처에 맞는 설치 파일 선택

Linux 데스크톱에서는 v2rayN을 사용할 수 있습니다. 먼저 시스템의 ‘정보’ 페이지에서 배포판과 프로세서 아키텍처를 확인한 뒤 Linux 다운로드 옵션에서 설치 파일을 고르세요. Debian 계열은 보통 deb 패키지를 사용하고 RPM 패키지 관리 체계를 사용하는 배포판은 rpm을 선택합니다. 두 형식은 파일 확장자만 바꿔 서로 대체할 수 있는 압축 파일이 아닙니다. 일반적인 데스크톱 프로세서는 x64를 사용하며 ARM 기기에서는 해당 arm64 파일을 선택하세요. 배포판, 아키텍처, 데스크톱 실행 환경이 모두 호환되어야 합니다.

시스템 소프트웨어 설치 프로그램으로 파일을 열어 의존성 안내를 확인하고 배포판의 일반적인 절차에 따라 설치하세요. 설치 프로그램에서 필요한 의존성이 없다고 알리면 현재 시스템의 소프트웨어 저장소가 정상적으로 동작하는지 먼저 확인하세요. 다른 기기에서 동적 라이브러리를 복사해 프로그램 디렉터리에 넣지 마세요. 설치 후 앱 메뉴에서 v2rayN을 실행하고 창과 로그가 정상적으로 표시되는지 확인합니다. 데스크톱 없는 원격 환경은 그래픽 클라이언트 사용 절차에 포함되지 않습니다. 데스크톱 시스템 프록시 설정을 백그라운드 서비스에 그대로 적용하지 마세요.

구독 가져오기 및 설정 디렉터리 권한

‘구독 그룹 → 구독 그룹 설정’에서 주소를 추가하고 저장한 뒤 현재 구독을 업데이트하고 목록에서 활성 서버를 지정하세요. 처음에는 일반 사용자로 실행해 해당 사용자가 관리할 수 있는 위치에 설정을 저장하세요. 이전에 관리자 권한으로 실행한 뒤 저장할 수 없거나 업데이트 오류가 발생한다면 관련 설정 디렉터리의 소유자와 접근 권한을 확인하세요. 디렉터리 권한 문제를 감추려고 그래픽 프로그램 전체를 계속 높은 권한으로 실행하지 마세요.

업데이트에 실패하면 로그에 표시된 요청 오류를 확인하세요. 기본 네트워크가 연결되어 있어도 구독 서버에 접속할 수 없을 수 있습니다. 주소가 만료되었거나 응답 내용이 노드 목록이 아니거나 기존 프록시를 통해 업데이트해야 할 수 있습니다. 가져오기에 성공한 뒤에도 전송 및 TLS 필드가 올바르게 인식되었는지 확인하세요. 데스크톱 프로그램이 열리는 것은 화면이 정상 작동한다는 뜻일 뿐입니다. 코어 실행, 설정 생성, 원격 핸드셰이크는 각각 따로 확인해야 하며 이를 한데 묶어 ‘설치 성공’이라고 판단해서는 안 됩니다.

GNOME, KDE 및 앱의 프록시 적용 범위

GNOME 데스크톱에서는 보통 ‘설정 → 네트워크 → 네트워크 프록시’에서 수동 프록시를 설정합니다. KDE Plasma에서는 보통 ‘시스템 설정 → 네트워크 → 프록시’에서 관련 항목을 확인합니다. 메뉴 분류는 데스크톱 버전에 따라 다를 수 있습니다. 프록시 프로토콜, 주소, 포트를 v2rayN의 실제 수신 대기 설정과 일치시키세요. HTTP와 SOCKS는 포트가 비슷하다고 서로 바꿔 사용할 수 없습니다. 클라이언트의 시스템 프록시 자동 설정이 적용되지 않으면 수동으로 입력하기 전에 데스크톱의 프록시 페이지부터 확인하세요.

데스크톱 프록시 설정이 터미널 프로그램에 전달되지 않을 수 있으며 환경 변수도 이미 실행 중인 그래픽 앱에 영향을 주지 않을 수 있습니다. 특정 프로그램의 요청 기록이 없다면 프로그램 자체의 네트워크 설정이나 프록시 지원 안내를 확인하세요. 격리된 환경에서 실행되는 앱은 별도 네트워크 환경을 사용할 수 있습니다. 컨테이너 내부의 루프백 주소를 호스트의 루프백 주소와 같다고 생각하지 마세요. 호스트 프록시에 연결해야 한다면 네트워크 경계와 접근 제어를 명확히 하고, 수신 대기 주소를 모든 인터페이스로 무작정 확대하지 마세요.

TUN과 기존 네트워크 도구 함께 사용하기

TUN을 켜기 전에 일반 프록시로 접속이 되는지 확인한 뒤 클라이언트 안내에 따라 가상 인터페이스와 권한을 설정하세요. 배포판마다 권한 관리 방식이 다르므로 실제 오류와 배포 패키지 안내를 기준으로 해결해야 합니다. 로그에 인터페이스 생성 실패, 권한 부족, 라우팅 추가 실패가 표시되면 해당 단계의 문제부터 해결하세요. 데스크톱 세션 전체를 관리자 계정으로 전환하거나 관련 없는 프로그램에 네트워크 관리 권한을 함부로 부여하지 마세요.

가상 머신, 컨테이너 네트워크, 다른 VPN은 라우팅을 복잡하게 만들 수 있습니다. TUN을 켠 뒤 LAN 기기에 접속할 수 없다면 사설 IP가 예상대로 직접 연결되는지 확인하고 겹치는 서브넷이 있는지도 살펴보세요. 라우팅 규칙을 바꾸기 전에 현재 설정을 보관하고 한 번에 하나의 조건만 변경하세요. DNS 서비스는 시스템 네트워크 관리자가 관리할 수도 있습니다. 수동으로 해석 설정 파일을 바꾸면 자동으로 덮어써질 수 있으므로 실제로 적용되는 DNS 관리 경로를 먼저 확인한 뒤 클라이언트와 시스템 중 어디서 도메인을 처리할지 결정하세요.

종료 전에 TUN을 끄고 데스크톱 프록시를 복구한 다음 일반 브라우저로 직접 인터넷에 접속할 수 있는지 확인하세요. 터미널만 작동하지 않는다면 현재 세션에 프록시 환경 변수가 남아 있는지 확인하고, 모든 앱이 작동하지 않으면 시스템 프록시와 라우팅을 살펴보세요. 업그레이드 전에 구독과 사용자 지정 규칙을 백업하세요. 업그레이드 후에는 기존의 단순한 모드로 먼저 확인합니다. 한 번의 작업에서 코어 교체, DNS 변경, 새 라우팅 적용을 모두 하지 마세요. 그래야 비교할 기준을 유지할 수 있습니다.

라우팅 및 DNS: 트래픽 유입과 전달 경로를 따로 확인

전역 프록시가 모든 기기 트래픽을 처리하는 것은 아닙니다

먼저 요청이 클라이언트에 들어왔는지 확인하고, 들어왔다면 어떤 경로로 전달되는지 살펴보세요. 시스템 프록시는 프록시 설정을 따르는 앱에만 영향을 줍니다. 라우팅 메뉴에서 ‘전역’을 선택해도 클라이언트에 들어오지 않은 요청은 처리되지 않습니다. 반대로 TUN을 켠 뒤에도 라우팅 규칙을 통해 LAN이나 특정 도메인을 직접 연결할 수 있습니다. 따라서 ‘전역 프록시가 작동하지 않음’을 해결할 때는 트래픽 처리 방식, 활성 라우팅 규칙, 대상 앱을 함께 기록하세요. 모드 이름만 확인해서는 안 됩니다.

v2rayN에서는 메인 화면의 라우팅 선택 메뉴에서 프리셋을 바꾸고 ‘설정 → 라우팅 설정’에서 규칙을 확인할 수 있습니다. Android 클라이언트에서는 ‘설정’의 라우팅 관련 항목을 확인하세요. 화면마다 프리셋 이름이 다를 수 있으므로 실제로 일치하는 조건을 펼쳐서 살펴보세요. 규칙은 보통 순서대로 검사합니다. 앞쪽의 포괄적인 조건이 뒤쪽의 구체적인 조건을 먼저 적용하지 못하게 할 수 있습니다. 모든 트래픽에 이미 일치하는 규칙 뒤에 예외 도메인을 추가해도 대개 예상대로 작동하지 않습니다.

도메인 규칙과 출력 태그 이해하기

아래는 코어 설정의 라우팅 구조를 설명하기 위한 예시이며 단독으로 실행할 수 있는 완전한 설정이 아닙니다. 사용할 수 있는 geosite 데이터가 필요하고 전체 설정에 direct 태그가 지정된 출구가 있어야 합니다. 프록시 출구는 실제 노드 설정에서 정의해야 합니다. 클라이언트가 완전한 설정 파일을 생성하므로 수정하기 전에 라우팅 규칙 입력란을 편집하는지 사용자 지정 설정 파일을 편집하는지 확인하세요. 이 예시를 구독 주소나 노드 공유 링크 입력란에 붙여 넣지 마세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

geosite:cn은 도메인 목록을 참조하는 값이지 모든 중국 IP 주소를 실시간으로 판별하는 기능이 아닙니다. 목록 내용은 데이터 파일에 따라 달라지며 대상 도메인에서도 별칭이나 다른 리소스 도메인을 통해 콘텐츠를 불러올 수 있습니다. outboundTag는 이미 존재하는 출구 태그와 일치해야 합니다. 그럴듯한 이름을 임의로 입력하면 안 됩니다. 테스트할 때는 명확한 도메인 몇 개로 규칙이 적용되는지 확인한 뒤 목록 범위를 넓히세요. 웹페이지 언어만 보고 규칙이 올바른지 판단하지 마세요.

시스템 DNS와 코어 DNS의 차이

DNS는 도메인을 IP 주소로 변환하지만, 요청은 시스템, 앱, 코어 또는 원격 프록시에서 시작될 수 있습니다. 앱이 먼저 직접 주소를 확인한 뒤 IP 요청을 보내면 클라이언트는 원래 도메인을 알지 못할 수 있습니다. 앱이 도메인을 프록시에 넘기면 이후 연결 경로에서 처리할 수 있습니다. 브라우저의 암호화 DNS도 조회 경로를 바꿀 수 있습니다. 따라서 ‘DNS 변경’은 한 가지 설정을 뜻하지 않습니다. 시스템 네트워크 설정, 브라우저 설정, 클라이언트가 생성하는 코어 DNS 중 어디를 바꾸는지 먼저 확인하세요.

v2rayN의 ‘설정 → DNS 설정’이나 Android 클라이언트의 ‘설정’에서 로컬 및 원격 DNS 항목을 확인할 때는 기본 설정을 유지해 기준 상태를 확인한 뒤 조회 경로를 하나씩 바꾸세요. 아직 프록시 연결이 만들어지지 않았는데 원격 DNS가 프록시를 필요로 하고 노드 도메인도 해당 DNS에 의존하면 시작 과정에서 순환 의존성이 생길 수 있습니다. 노드 주소를 처음 조회하는 경로가 작동하도록 설정해야 합니다. 모든 DNS 요청을 무조건 프록시 경로로 보내지 마세요.

LAN, IPv6 및 연결 확인 범위

LAN 기기, 프린터, 로컬 서비스는 보통 직접 연결해야 합니다. 연결 후 외부 웹사이트는 열리지만 공유기 관리 페이지에 접속할 수 없다면 모든 분기를 끄지 말고 사설 IP 라우팅과 로컬 도메인 조회를 확인하세요. IPv6도 따로 확인해야 합니다. 시스템이 IPv6 주소를 받았다고 해서 현재 노드, TUN, DNS 설정이 같은 경로를 지원한다는 뜻은 아닙니다. IPv4 접속만 성공했다고 해서 듀얼 스택 환경의 모든 요청이 같은 규칙으로 처리된다고 판단하지 마세요.

복잡한 문제가 발생하면 먼저 클라이언트 기본 프리셋으로 되돌린 뒤 사용자 지정 규칙을 하나씩 추가하세요. 대상 도메인, 실제 조회 결과, 적용된 출구, 오류가 발생한 단계를 기록하는 편이 DNS 주소를 반복해서 바꾸는 것보다 효과적입니다. UDP를 사용하는 앱만 실패한다면 웹 프록시만 조정하지 말고 노드 프로토콜, 전송 방식, 트래픽 처리 방식이 해당 트래픽을 지원하는지 확인하세요. 모아 둔 질문과 답변은 자주 묻는 질문에서 확인할 수 있습니다. 문제 해결 기록에는 필드 이름만 남기고 개인 식별 정보는 공개하지 마세요.

연결 확인: 로그, 속도 측정 및 기기 간 이전

기본 네트워크, 코어, 요청 순서로 확인

먼저 트래픽 처리를 중지하고 현재 네트워크에서 허용하는 일반 웹사이트에 기기가 접속할 수 있는지 확인하세요. 호텔, 학교, 게스트 네트워크는 먼저 인증해야 할 수 있으므로 아직 인터넷에 연결되지 않은 상태를 노드 시간 초과로 오해하지 마세요. 다음으로 클라이언트를 시작하고 활성 노드를 하나 지정해 코어가 정상적으로 실행되는지 확인합니다. 마지막으로 대상 앱 하나만 열어 요청을 보내고 로그에 해당 연결이 표시되는지 확인하세요. 이 순서대로 진행하면 기본 네트워크, 설정 생성, 프록시 전달 단계를 분리할 수 있어 여러 설정을 한꺼번에 바꾸는 일을 줄일 수 있습니다.

로그에 대상 요청이 없다면 트래픽 유입 경로부터 확인하세요. 시스템 프록시가 다른 도구에 의해 덮어쓰였는지, 앱이 별도의 프록시를 사용하는지, 앱별 목록의 선택 방향이 반대인지 살펴봅니다. 요청은 표시되지만 핸드셰이크가 실패하면 노드 설정, 시스템 시간, TLS, 네트워크 연결을 확인하세요. 요청 전달은 성공했는데 페이지가 완전히 표시되지 않는다면 다른 페이지 리소스 도메인의 라우팅과 DNS를 살펴보세요. 웹페이지 하나를 불러올 때 여러 연결이 생길 수 있으므로 첫 화면이 보인다고 모든 리소스가 정상인 것은 아닙니다.

포트 테스트, 실제 연결, 다운로드 속도 측정 구분

TCPing과 같은 테스트는 주로 대상 포트와 연결을 설정할 수 있는지 확인하며, 프록시 프로토콜 전체가 작동한다는 뜻은 아닙니다. 실제 연결 지연 시간은 프록시 핸드셰이크와 테스트 대상 요청까지 포함하므로 실제 사용 경로에 더 가깝습니다. 다운로드 속도 측정은 일정 시간 동안의 처리량을 확인합니다. 세 가지는 확인하려는 항목이 다르므로 같은 수치로 순위를 매기면 안 됩니다. 포트에는 연결되지만 실제 연결이 실패한다면 포트 테스트를 최종 정상 판정으로 삼지 말고 인증 정보, 전송 방식, TLS를 확인하세요.

속도 측정 결과는 로컬 네트워크, 테스트 대상, 노드 출구, 동시 부하의 영향을 받습니다. 기기, 시간, 테스트 주소가 다르면 결과를 직접 비교할 수 없습니다. 영향을 줄이려면 한 번에 후보 노드를 소수만 측정하고 다른 대용량 작업을 중지하세요. 실제로 사용할 때는 지연 시간과 처리량보다 대상 앱에서 요청을 안정적으로 완료할 수 있는지 먼저 확인하세요. 원리는 TCPing, 실제 연결 지연 시간, 다운로드 속도의 차이에서 확인할 수 있습니다. 한 번의 측정 결과를 장기적인 품질 보증으로 간주하지 마세요.

마지막 한 줄만 보지 말고 오류가 발생한 단계를 확인

포트 바인딩 오류는 보통 로컬 시작 단계에서 발생합니다. 연결 시간 초과는 네트워크 연결이나 이후 핸드셰이크 단계에서 발생할 수 있으며, 인증서 오류는 호스트 이름, 시스템 시간, 검증 요구 사항을 함께 살펴봐야 합니다. 오류 앞뒤의 로그를 읽고 당시 어떤 노드와 출구가 활성화되어 있었는지 확인하세요. 오래된 로그에는 이전 연결 오류가 섞여 있을 수 있습니다. 노드를 바꾼 뒤에는 테스트 시각을 기록해 이전 노드의 실패 정보를 현재 노드의 동작으로 오해하지 않도록 하세요.

문의할 때는 클라이언트 이름, 운영체제, 트래픽 처리 방식, 오류 키워드, 재현 절차를 남기세요. 구독 주소, 인증 정보, 민감한 도메인, 계정 정보를 제거합니다. 화면을 선명하게 찍기 위해 설정 파일 전체를 공개하지 마세요. 보통 관련 필드와 오류 구간만 있으면 충분합니다. 노드 시간 초과를 반복해서 재현할 수 있다면 시스템 시간, 포트, TLS, 라우팅 순서대로 점검을 참고해 기록하세요. 확인한 항목에는 결과를 적고 ‘다 해 봤음’이라고만 쓰지 마세요.

구독 동기화 및 로컬 설정 이전

여러 기기에서 같은 노드를 사용하려면 먼저 각 기기에 사용할 권한이 있는 동일한 구독 출처를 추가하고 개별적으로 업데이트하세요. 구독으로 동기화되는 것은 서버에서 제공하는 노드 목록뿐이며 활성 노드, 시스템 프록시, TUN, 앱별 목록, 사용자 지정 DNS까지 자동으로 동기화되지는 않습니다. 컴퓨터와 휴대전화의 네트워크 환경이 다르면 적합한 라우팅도 달라질 수 있습니다. 같은 노드 출처를 사용하더라도 트래픽 처리 방식은 기기마다 따로 확인하세요. 모든 스위치를 똑같이 맞출 필요는 없습니다.

수동 노드 공유는 노드 하나를 임시로 옮길 때, 전체 백업은 로컬 구성을 보관할 때 적합합니다. 두 방식의 목적은 다릅니다. 백업을 복원하기 전에 현재 설정을 저장하고 파일 경로와 플랫폼별 옵션을 확인하세요. 클라이언트나 코어를 바꾼 뒤에는 노드를 몇 개만 먼저 가져와 테스트하고 프로토콜 필드가 온전한지 확인한 다음 전체 그룹을 옮기세요. 구독 업데이트가 해당 출처에서 관리하는 노드를 덮어쓸 수 있으므로 수동으로 수정하기 전에 복사본을 따로 저장하세요. 이전 백업을 복원해도 이미 만료된 원격 계정은 되살아나지 않습니다.

설정 관련 자주 묻는 질문: 문제 범위를 나눠 해결

구독은 업데이트되는데 노드에 연결할 수 없는 이유

구독 서버와 노드 서버는 서로 다른 주소를 사용할 수 있습니다. 업데이트 성공은 클라이언트가 설정을 가져와 파싱했다는 뜻일 뿐 노드의 포트, 계정, 전송 방식이 작동한다는 뜻은 아닙니다. 목록에서 예상한 노드가 실제로 활성화되어 있는지 확인한 뒤 실제 연결을 테스트하고 로그를 확인하세요. 모든 노드가 실패하면 기본 네트워크, 시스템 시간, 코어 시작, 공통 라우팅 설정부터 확인하세요. 일부 노드만 실패한다면 해당 노드의 주소, 계정 상태, 서버 설정을 확인하고 클라이언트를 반복해서 재설치하지 마세요.

구독에서 반환한 필드가 현재 클라이언트나 코어에서 지원되지 않을 수도 있습니다. 가져오기에 성공해도 모든 확장 필드가 적용되었다는 뜻은 아닙니다. 특히 전송 방식, TLS, 특정 보안 매개변수를 확인하세요. 모르는 필드를 삭제해 저장한 뒤 호환된다고 판단하지 마세요. 제공자의 요구 사항을 확인하고 이에 맞는 클라이언트와 코어를 선택하세요. 구독 업데이트 후 수동 노드가 바뀐다면 같은 출처 그룹에서 계속 수정하지 말고 별도의 그룹에 저장하세요.

포트에는 접속되지만 TLS 또는 실제 연결이 실패하는 경우

TLS를 점검할 때는 시스템 시간, 서버 이름, 인증서 요구 사항부터 확인하세요. 연결 주소와 검증에 사용하는 서버 이름은 다를 수 있으며, SNI를 접속하려는 웹사이트 도메인으로 임의 설정해서는 안 됩니다. 원래 노드 설정을 기준으로 확인하고 주소 모양만 보고 추측하지 마세요. 서버가 요구하는 전송 경로나 Host 필드도 정확히 일치해야 합니다. 포트와 인증 정보만 확인하면 핸드셰이크 실패의 실제 원인을 놓칠 수 있습니다.

인증서 검증을 끄는 방법을 일반적인 해결책으로 사용하지 마세요. 연결의 보안 범위가 달라지고 잘못된 설정을 가리는 데 그칠 수 있습니다. 시간이 맞는데도 이름이 일치하지 않는다는 오류가 발생하면 오래된 설정을 가져왔는지, 잘못된 서버에 연결했는지, 현재 네트워크의 인증 페이지가 방해하는지 확인하세요. 원래 설정이 잘못되었다면 올바른 정보를 받아 다시 테스트하세요. 여러 항목을 연이어 바꾸면 이후 로그를 비교하기 어렵습니다. 원래 설정을 보관하고 항목별로 확인하는 편이 효과적입니다.

연결 후 웹페이지와 LAN의 동작이 다른 경우

브라우저는 작동하지만 다른 프로그램이 작동하지 않는다면 노드를 바로 바꾸지 말고 해당 프로그램이 시스템 프록시를 따르는지 확인하세요. TUN을 켠 뒤 LAN만 문제가 생겼다면 사설 네트워크 직접 연결과 로컬 도메인 조회를 먼저 확인합니다. 특정 웹사이트만 실패하고 다른 사이트는 정상이라면 해당 사이트의 리소스 도메인이 서로 다른 규칙으로 분기되는지, 앱이 이전 조회 결과를 저장하고 있는지 살펴보세요. 대상 앱을 재시작해 다시 확인할 수 있지만 모든 설정을 초기화하거나 구독을 전부 삭제할 필요는 없습니다.

외부 접속과 LAN이 모두 실패하면 TUN을 끄고 단순한 시스템 프록시 설정으로 비교하세요. 단순 모드가 작동한다면 문제 범위를 TUN 권한, 라우팅, DNS 또는 다른 네트워크 도구와의 충돌로 좁힐 수 있습니다. 원격으로 기기를 조작할 때는 기본 라우트가 바뀌면 관리 연결이 끊길 수 있으므로 특히 주의하세요. 복구할 로컬 경로를 준비하거나 기존 세션을 유지한 뒤 전체 기기의 트래픽에 영향을 주는 설정을 바꾸세요. 복구할 방법이 없는 환경에서 여러 네트워크 설정을 동시에 변경하지 마세요.

클라이언트를 종료한 뒤에도 인터넷이 되지 않는 이유

시스템이 아직 클라이언트의 로컬 수신 대기 포트를 가리키는지 확인하세요. Windows에서는 네트워크 프록시 설정을, macOS에서는 현재 네트워크 서비스의 프록시 페이지를, Linux에서는 데스크톱 프록시와 앱 환경을 확인합니다. 클라이언트가 종료되면 해당 포트에서 실행 중인 서비스가 없어 프록시 설정을 따르는 앱은 연결할 수 없습니다. 클라이언트를 다시 실행해 시스템 프록시를 해제하거나 기존 네트워크 설정을 기록해 둔 뒤 직접 복구하세요. 회사 네트워크에 설정된 프록시 스크립트까지 함께 삭제해서는 안 됩니다.

Android에서는 VPN이 중지되었는지, 시스템 ‘VPN’ 설정에서 ‘항상 켜기’ 또는 VPN 미사용 연결 차단 옵션이 켜져 있는지 확인하세요. 차단 정책을 사용하면 VPN 서비스가 중지된 뒤 일반 연결도 제한될 수 있습니다. 실제 사용 방식에 맞게 설정을 복구한 뒤 기본 네트워크를 확인하세요. 컴퓨터에 가상 인터페이스나 라우팅 오류가 남아 있다면 다른 네트워크 도구를 정상적으로 종료하고 네트워크 연결을 다시 시작하세요. 단일 클라이언트 문제를 해결하려고 네트워크 어댑터를 전부 함부로 삭제하지 마세요.

언제 기본 설정으로 돌아가야 할까요?

로그, 프록시 상태, 실제 앱 동작이 서로 맞지 않는다면 현재 설정을 저장한 뒤 노드 하나, 트래픽 처리 방식 하나, 기본 라우팅으로 돌아가세요. 이 기준 설정이 작동하는지 확인한 후 DNS, 분기 규칙, 앱별 설정, TUN을 차례로 복원합니다. 기본 설정 절차는 사용 가이드에서, 클라이언트 선택은 클라이언트 비교에서 확인하세요. 추가로 문의할 때는 ‘프로그램이 안 됨’처럼 막연하게 설명하기보다 구독 요청 실패나 TLS 핸드셰이크 실패처럼 문제가 발생한 단계를 구체적으로 적으면 원인을 찾기 쉽습니다.