V2Ray 전체 플랫폼 설치 및 설정

01 · BEFORE INSTALLATION

공통 준비 작업: 설치 패키지, 구독 및 시스템 상태

먼저 플랫폼과 프로세서에 맞는 클라이언트를 선택하세요

데스크톱 플랫폼에서는 v2rayN을 우선 사용하는 것이 좋습니다. Windows, macOS, Linux를 지원하며 구독 그룹, 시스템 프록시, TUN, 라우팅, 로그 등 필요한 기능을 폭넓게 제공합니다. Android에서는 v2rayNG를 사용할 수 있고, V2Fly 커널 계열이 필요하다면 v2flyNG를 선택할 수 있습니다. 세 클라이언트의 역할은 완전히 같지 않습니다. v2rayN은 데스크톱 환경에 맞춰 설정 항목이 집중되어 있고, v2rayNG와 v2flyNG는 터치 조작에 적합하며 시스템 VPN 인터페이스를 통해 지정된 트래픽을 처리합니다. 클라이언트마다 이름, 메뉴 구조, 기본 동작이 다를 수 있으므로 설정 화면을 항목별로 억지로 비교하지 말고 기능의 목적을 기준으로 판단하세요.

다운로드하기 전에 프로세서 아키텍처를 확인하세요. Windows의 일반적인 장치는 x64를 사용합니다. macOS는 Apple Silicon과 Intel을 구분해야 하며, Android의 최신 주류 기기는 대체로 arm64를 선택합니다. 아키텍처를 확인할 수 없거나 설치에 실패할 때만 범용 버전을 사용하세요. Linux는 x64와 arm64뿐 아니라 배포판에 맞춰 deb 또는 rpm도 선택해야 합니다. deb는 보통 Debian, Ubuntu 및 파생 시스템에 사용되고, rpm은 Fedora, Rocky Linux, AlmaLinux 등에서 주로 사용됩니다. 아키텍처를 잘못 선택하면 설치 프로그램이 실행되지 않거나 패키지 비호환 메시지가 표시되거나, 설치 직후 프로그램이 종료될 수 있습니다. 이런 문제는 구독을 반복해서 수정한다고 해결되지 않습니다.

구독 정보가 어느 계층에 속하는지 확인하세요

클라이언트는 설정을 읽고 커널을 호출해 연결을 수립할 뿐, 사용할 수 있는 서버를 자동으로 만들어 주지는 않습니다. 시작하기 전에 정상적으로 접근 가능한 구독 주소, 단일 공유 링크 또는 완전한 설정 파일을 준비해야 합니다. 구독 주소에는 보통 여러 설정이 포함되며 서비스 제공자가 관리합니다. 단일 공유 링크는 하나의 설정만 나타내고, JSON 파일에는 인바운드, 아웃바운드, DNS 및 라우팅 규칙이 모두 들어 있을 수 있습니다. 세 자료의 가져오기 메뉴와 문제 해결 방법은 서로 다릅니다. 구독 업데이트에 실패하면 주소와 네트워크 연결 가능성을 확인하고, 단일 노드 연결에 실패하면 프로토콜 매개변수를 확인하세요. 완전한 설정으로 시작되지 않을 때는 JSON 구조와 로그의 필드 오류를 살펴봐야 합니다.

구독 주소는 민감한 정보로 관리해야 합니다. 계정 식별자가 포함될 수 있으므로 공개 토론, 스크린샷 또는 브라우저 동기화 메모에 붙여 넣지 마세요. 여러 기기에서 사용해야 한다면 신뢰할 수 있는 기기에서 직접 입력하고, 클라이언트의 구독 그룹으로 출처를 구분하세요. 하나의 클라이언트에서 여러 구독을 관리한다면 이름을 “용도 또는 제공자 이름”으로 정하는 것이 좋습니다. “구독 1”, “구독 2”처럼 추적하기 어려운 번호는 피하세요. 이후 업데이트 실패, 중복 노드 또는 규칙 차이가 발생했을 때 명확한 그룹 이름이 문제 위치를 찾는 시간을 크게 줄여 줍니다.

되돌릴 수 있는 초기 상태를 만들어 두세요

설치하기 전에 시스템 시간과 시간대가 정확한지 확인하세요. TLS 핸드셰이크는 시간에 의존하므로 기기 시간이 크게 어긋나면 모든 노드가 동시에 실패하는 것처럼 보일 수 있습니다. 그런 다음 현재 시스템 프록시 상태, VPN 상태, DNS 설정 및 실행 중인 네트워크 도구를 기록하세요. 최초 테스트에서는 프록시 클라이언트 하나만 실행해 여러 프로그램이 시스템 프록시나 가상 네트워크 카드를 동시에 수정하지 않도록 하세요. 회사 네트워크, 학교 네트워크, 공용 핫스팟에는 인증 페이지가 있을 수 있으므로 브라우저에서 먼저 네트워크 로그인을 완료한 뒤 클라이언트 연결 문제를 판단해야 합니다.

먼저 클라이언트 기본 설정으로 한 번 연결한 다음 TUN, 분할 라우팅, 사용자 지정 DNS를 추가하는 것이 좋습니다. 한꺼번에 변수를 너무 많이 도입하면 문제 증상에서 단서를 찾기 어려워집니다. 초기 확인은 세 단계로 진행하세요. 클라이언트 로그에 시작 오류가 없어야 하고, 브라우저에서 원하는 웹사이트에 접속할 수 있어야 하며, 프록시를 끈 뒤 네트워크가 원래 상태로 돌아와야 합니다. 특히 세 번째 확인은 시스템 프록시가 해제되지 않았거나 가상 네트워크 카드가 남아 있거나 DNS가 고정 변경된 문제를 조기에 발견하는 데 중요합니다.

준비가 끝났다면 v2rayN 최초 연결 튜토리얼에서 속도 측정과 적용 여부 확인 방법을 먼저 살펴볼 수 있습니다. 여러 출처를 관리하려면 구독 그룹 설정 실전을 참고하세요. 해당 글들은 각각의 작업을 다루며, 이 장에서는 이후 모든 플랫폼에 공통으로 적용할 판단 기준을 제공합니다.

02 · TRAFFIC CONTROL

연결 모드와 설정 범위: 시스템 프록시, TUN 및 앱 내 프록시

시스템 프록시는 브라우저와 시스템 설정을 따르는 프로그램에 적합합니다

시스템 프록시의 본질은 클라이언트가 수신 대기하는 로컬 HTTP 또는 SOCKS 포트를 운영체제의 프록시 설정에 등록하는 것입니다. 브라우저, 일부 업무용 소프트웨어 및 대부분의 시스템 네트워크 프레임워크를 따르는 앱은 요청을 로컬 포트로 보낸 뒤, V2Ray 커널이 라우팅 규칙에 따라 직접 연결 또는 프록시 아웃바운드를 선택합니다. 동작이 명확하고 켜고 끄기 쉬우며 필요한 권한도 적다는 장점이 있어 최초 설정에 우선 사용하기 좋습니다. 다만 시스템 프록시를 읽지 않는 프로그램, 일부 명령줄 도구와 게임, 자체 네트워크 스택을 사용하는 소프트웨어는 이를 완전히 우회할 수 있습니다.

시스템 프록시를 켜면 클라이언트에 보통 “지우기”, “자동 설정”, “전역”, “변경하지 않음”과 같은 옵션이 표시됩니다. 버전에 따라 문구는 조금 다를 수 있지만 판단 원칙은 같습니다. 자동 설정은 로컬 수신 주소를 시스템에 기록하고, 지우기는 시스템 상태를 복원하며, 변경하지 않음은 시스템을 수정하지 않고 커널만 실행합니다. 문제를 확인할 때는 메뉴에 체크 표시가 있는지만 보지 말고 시스템 네트워크 설정에서 프록시 주소가 여전히 로컬 컴퓨터를 가리키는지, 포트가 클라이언트의 현재 인바운드 포트와 일치하는지 확인하세요. 다른 프로그램이 포트를 사용 중이면 로그에 수신 대기 실패 또는 주소 사용 중이라는 메시지가 나타나는 경우가 많습니다.

TUN은 더 넓은 트래픽 범위가 필요한 상황에 적합합니다

TUN 모드는 가상 네트워크 카드를 통해 IP 트래픽을 받은 뒤 커널에 전달하므로 시스템 프록시를 따르지 않는 더 많은 앱을 처리할 수 있습니다. 일반적으로 관리자 권한이 필요하며 라우팅 테이블, DNS 가로채기 또는 자동 라우팅이 함께 사용됩니다. TUN이 항상 더 좋은 선택인 것은 아닙니다. 브라우저 프록시만 필요하다면 시스템 프록시가 관리하기 쉽고, 명령줄 도구나 데스크톱 프로그램, 여러 네트워크 스택의 트래픽을 하나의 규칙으로 처리해야 할 때 TUN을 고려하세요. 활성화하기 전에 현재 설정을 저장하고 다른 가상 네트워크 도구를 끄며, 시스템 방화벽이 클라이언트의 인터페이스 생성을 차단하지 않는지 확인해야 합니다.

TUN을 켠 뒤 인터넷에 연결되지 않는다고 해서 반드시 노드 문제인 것은 아닙니다. 흔한 원인으로는 가상 네트워크 카드 권한 부족, 기본 라우트 미등록, 로컬 네트워크 대역의 잘못된 처리, DNS 응답 부재, 절전 모드 복귀 후 인터페이스 상태 오류가 있습니다. 먼저 TUN을 끄고 시스템 프록시로 전환해 같은 노드를 테스트하세요. 시스템 프록시는 작동하지만 TUN만 작동하지 않는다면 문제 범위가 가상 네트워크 카드, 라우팅 또는 DNS로 좁혀진 것이므로 구독 업데이트를 반복하지 마세요. 두 모드 모두 실패할 때만 노드, 커널 로그 및 현재 네트워크를 확인하세요.

앱 내 프록시는 정밀하지만 빠뜨리기 쉬운 세 번째 경로입니다

명령줄 도구와 개발 소프트웨어는 별도로 프록시를 지정할 수 있는 경우가 많습니다. 예를 들어 일부 프로그램은 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 환경 변수를 읽고, 다른 프로그램은 자체 설정 화면에서 HTTP 또는 SOCKS 주소를 입력합니다. 앱 내 프록시는 시스템 프록시 스위치를 자동으로 따르지 않습니다. 영향 범위가 작다는 장점이 있지만 클라이언트를 종료한 뒤 잘못된 주소가 남을 수 있다는 단점도 있습니다. 설정할 때는 클라이언트에 표시된 로컬 수신 포트를 사용하고 원격 서버 주소를 직접 입력하지 마세요. 원격 노드는 커널이 관리하며 앱은 로컬 진입점에 연결하기만 하면 됩니다.

export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809
export ALL_PROXY=socks5://127.0.0.1:10808

curl -I https://example.com

위 예시의 포트는 로컬 프록시 변수 형식을 설명하기 위한 것이며, 실제 값은 클라이언트 설정 화면을 기준으로 해야 합니다. 테스트가 끝나면 현재 터미널에서 unset HTTP_PROXY HTTPS_PROXY ALL_PROXY를 실행할 수 있습니다. 터미널에서는 접속되지만 그래픽 앱에서는 접속되지 않는다면 커널과 노드는 대체로 정상이며 그래픽 앱이 시스템 프록시를 읽는지 확인해야 합니다. 반대로 브라우저는 작동하지만 터미널이 작동하지 않는다면 터미널 프로그램이 시스템 설정을 읽지 않는 경우가 많습니다.

라우팅 모드가 연결 후 트래픽 분배 방식을 결정합니다

시스템 프록시 또는 TUN은 트래픽을 커널로 보내고, 라우팅 규칙은 어느 아웃바운드로 나갈지 결정합니다. 이 두 개념은 자주 혼동됩니다. “전역 프록시”를 켜면 보통 커널로 들어온 요청이 우선 프록시 아웃바운드를 사용하고, 규칙 모드는 도메인, IP, 포트 또는 프로세스 조건에 따라 매칭하며, 직접 연결 모드는 임시 복구에 사용됩니다. 규칙은 순서대로 매칭되므로 위에 있는 넓은 규칙이 아래의 정확한 규칙을 가릴 수 있습니다. 수정 후에는 규칙의 존재뿐 아니라 순서도 확인하세요.

로컬 네트워크 주소, 프린터, 네트워크 저장소 및 라우터 관리 페이지는 보통 직접 연결로 유지해야 합니다. 특히 TUN 모드에서는 사설 주소 대역을 주의하지 않으면 로컬 서비스를 이용할 수 없게 됩니다. 대표적인 사설 네트워크 대역은 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16입니다. 활성화 후 공용 인터넷은 정상인데 로컬 네트워크만 끊겼다면 먼저 해당 대역이 직접 연결로 설정되어 있는지 확인하고, 회사 네트워크나 컨테이너 네트워크와 라우팅이 겹치지 않는지도 살펴보세요.

프록시가 적용됐는지 확인할 때 클라이언트 아이콘만 믿어서는 안 됩니다. 로그, 대상 웹사이트 접속 결과, 외부 네트워크 변화도 함께 확인하세요. 속도 측정에서도 TCP 지연과 실제 연결 테스트를 구분해야 합니다. 전자는 기본 핸드셰이크 응답만 나타내고, 후자는 실제 사용 가능성에 더 가깝습니다. 구체적인 판단 순서는 노드 지연 시간, 지역 및 프로토콜 선택을 참고하세요.

03 · WINDOWS

Windows: v2rayN 설치, 구독 가져오기 및 시스템 프록시 적용

데스크톱 버전과 클래식 WPF 버전 중 무엇을 선택할까요?

Windows 다운로드 페이지에는 v2rayN 데스크톱 버전과 클래식 WPF 버전이 제공됩니다. 데스크톱 버전은 최신 크로스 플랫폼 인터페이스를 사용하므로 여러 데스크톱 시스템에서 비슷한 사용 방식을 유지하고 싶은 사용자에게 적합합니다. 클래식 WPF 버전은 Windows 데스크톱 환경과 더 밀접하게 통합되어 있으며 화면과 트레이 조작 방식도 전통적입니다. 두 버전 모두 구독, 노드 선택, 시스템 프록시, 라우팅 및 로그 확인을 지원하므로 동시에 설치할 필요는 없습니다. 처음 사용하는 경우 데스크톱 버전을 우선 선택하고, WPF 사용 경험이 있거나 기존 설정 흐름을 유지해야 할 때 클래식 버전을 선택하세요.

설치할 때 일반 사용자가 안정적으로 읽고 쓸 수 있는 위치를 사용하세요. 설치 프로그램이 시스템 권한을 요구하면 출처를 확인한 뒤 시스템 안내에 따라 진행합니다. 처음 실행한 뒤에는 자동 시작과 TUN을 바로 켜지 말고, 주 창이 정상적으로 표시되는지와 로그 영역에서 커널이 성공적으로 로드되는지 먼저 확인하세요. 보안 소프트웨어가 네트워크 접근 권한을 묻는다면 현재 네트워크 유형에서 클라이언트가 로컬 수신 및 외부 연결을 만들 수 있도록 허용해야 합니다. 거부하면 화면은 정상이어도 모든 테스트가 실패할 수 있습니다.

구독 그룹과 최초 업데이트

구독 그룹 설정으로 이동해 새 그룹을 만들고 구독 주소를 입력하세요. 그룹 이름은 출처를 구분하기 위한 것이며 원격 콘텐츠에는 영향을 주지 않습니다. 저장한 뒤 “현재 구독 업데이트” 또는 이에 해당하는 작업을 실행하고 서버 목록이 갱신될 때까지 기다립니다. 목록이 비어 있다면 먼저 업데이트 로그를 확인하세요. 주소 접근 실패라면 구독 주소와 현재 네트워크를 점검하고, 파싱 실패라면 복사 과정에서 줄 바꿈, 공백 또는 누락된 문자가 들어가지 않았는지 확인하세요. 업데이트는 성공했지만 목록이 숨겨졌다면 서버 필터 조건과 현재 그룹 태그를 확인합니다.

여러 구독을 하나의 그룹에 모두 넣지 마세요. 그룹을 분리하면 각각 업데이트, 비활성화, 필터링하기 쉽고 같은 이름의 노드도 추적하기 편합니다. 업데이트 간격을 지나치게 짧게 설정해도 클라이언트가 시작할 때 구독을 자주 요청할 뿐 노드 품질이 좋아지지는 않습니다. 서비스 제공자가 권장하는 주기에 맞춰 업데이트하고, 광범위한 장애나 설정 변경이 있을 때만 수동으로 새로 고치는 편이 안정적입니다. 업데이트 전후 서버 이름이 바뀌는 것은 구독 내용의 변화이며 로컬 설정이 손상됐다는 뜻은 아닙니다.

설정 선택, 실제 연결 테스트 및 시스템 프록시

구독을 업데이트한 뒤 설정 하나를 선택해 활성 서버로 지정하세요. 이름만 보고 판단하지 말고 실제 연결 테스트나 웹사이트 접속 테스트를 먼저 실행해야 합니다. TCP 지연이 시간 초과인 설정은 대체로 사용할 수 없지만, 지연 시간이 짧다고 해서 애플리케이션 계층의 연결까지 성공하는 것은 아닙니다. TLS, 인증, 전송 매개변수 또는 원격 상태 때문에 연결이 실패할 수 있습니다. 최초 테스트에서는 일반적인 회선을 선택하고 복잡한 사용자 지정 라우팅과 DNS를 동시에 활성화하지 않아 작동하는 기준 상태를 먼저 만드세요.

활성 설정을 확인한 뒤 시스템 프록시를 켜세요. Windows 시스템 설정의 프록시 서버는 127.0.0.1과 클라이언트에 표시된 해당 포트를 가리켜야 합니다. 브라우저에 이전 상태가 계속 표시되면 완전히 종료한 뒤 다시 열거나 브라우저가 독립 프록시 확장 프로그램을 사용하는지 확인하세요. v2rayN을 종료하기 전에는 시스템 프록시를 지우는 것이 좋습니다. 프로그램이 비정상 종료됐다면 Windows의 “네트워크 및 인터넷” 프록시 설정에서 남아 있는 수동 프록시를 끈 다음 클라이언트를 다시 시작하세요.

TUN, 권한 및 절전 모드 복귀

시스템 프록시를 따르지 않는 소프트웨어도 규칙에 따라 처리해야 한다면 일반 프록시가 작동하는 것을 확인한 뒤 TUN을 활성화하세요. 처음 가상 네트워크 카드를 만들 때는 보통 관리자 권한이 필요합니다. 시작에 실패하면 먼저 클라이언트를 정상적으로 종료한 뒤 시스템 권한으로 한 번 실행해 구성 요소를 초기화하세요. 장기 사용 시 매번 관리자 권한이 필요한지는 설치 방식과 시스템 정책에 따라 달라집니다. 다른 가상 네트워크 프로그램의 TUN 모드를 동시에 유지하지 마세요. 기본 라우트와 DNS를 서로 차지하려 할 수 있습니다.

Windows가 절전 모드에서 복귀하거나 Wi-Fi를 전환하거나 유선 네트워크에서 무선 네트워크로 바뀐 뒤 가상 인터페이스에 이전 라우트가 남을 수 있습니다. 클라이언트는 실행 중으로 보이지만 새 연결이 수립되지 않는 경우가 많습니다. 시스템 프록시 또는 TUN을 끄고 몇 초 기다린 다음 다시 켜세요. 그래도 해결되지 않으면 커널을 재시작하고, 마지막으로 클라이언트를 재시작합니다. 시스템 네트워크 카드를 바로 삭제하는 것은 권장하지 않습니다. 대부분의 경우 라우트가 갱신되지 않은 문제이기 때문입니다.

v2rayN 주 창의 서버 목록, 구독 그룹, 로그 및 설정 영역은 v2rayN 기본 화면 기능 자세히 보기와 함께 읽으면 좋습니다. 설치 패키지와 현재 사용할 수 있는 다운로드 경로는 Windows 다운로드 영역에 모아 두었습니다. 주 창 스크린샷의 버전 외관만 보고 설치 패키지 유형을 추측하지 마세요.

04 · MACOS

macOS: 칩 선택, 권한 허용 및 프록시 복구

칩 유형을 확인하고 설치를 완료하세요

macOS용 v2rayN은 Apple Silicon과 Intel용 DMG를 각각 제공합니다. 시스템의 “이 Mac에 관하여”에서 칩 정보를 확인할 수 있습니다. Apple 칩 이름이 표시되면 arm64 설치 패키지를, Intel 프로세서가 표시되면 x64 설치 패키지를 선택하세요. 설치 패키지를 잘못 선택하면 프로그램이 열리지 않거나 호환 변환 계층으로 실행되어 추가 문제가 생길 수 있습니다. 앱을 “응용 프로그램” 폴더로 옮긴 뒤 실행하고, 마운트된 디스크 이미지에서 장기간 실행하는 것은 피하세요. 경로가 바뀌면 권한, 자동 시작 및 이후 업데이트에 영향을 줄 수 있습니다.

처음 실행할 때 시스템에서 다운로드한 앱, 네트워크 접근 또는 보조 네트워크 설정 추가를 확인하라는 메시지를 표시할 수 있습니다. 시스템 설정의 개인정보 보호 및 보안 페이지에서 명확한 안내에 따라 처리하고, 프로그램 아이콘을 연달아 클릭하지 마세요. 시스템이 앱을 확인하는 중이라면 검사가 끝날 때까지 기다린 뒤 실행 실패 여부를 판단합니다. 설치 후 창이 보이지 않으면 메뉴 막대와 Dock을 확인하세요. 일부 데스크톱 클라이언트는 주 창을 닫아도 백그라운드에서 계속 실행되므로 완전히 종료하려면 메뉴의 종료 명령을 사용해야 합니다.

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

구독 절차는 Windows와 비슷합니다. 구독 그룹을 만들고 주소를 입력한 뒤 저장하고 업데이트한 다음 활성 설정을 선택하세요. 주소를 복사할 때 클립보드에 앞뒤 공백이 포함되지 않았는지 주의합니다. 업데이트 중 서버 목록이 생성되지 않으면 먼저 로그에서 HTTP 상태와 파싱 정보를 확인하세요. 브라우저에서 일반 웹페이지가 열린다고 해서 구독 주소에 접근할 수 있다는 뜻은 아닙니다. 해당 주소에 별도의 접근 제한이 있을 수 있습니다. 반대로 구독 업데이트 성공은 설정을 다운로드했다는 뜻일 뿐, 그 안의 모든 노드가 연결된다는 의미는 아닙니다.

설정을 선택한 뒤 먼저 커널을 시작하고 로컬 HTTP 및 SOCKS 수신이 만들어졌는지 확인하세요. 시스템 프록시에는 클라이언트에 현재 표시된 주소와 포트를 입력하며, 주소는 보통 루프백 주소입니다. 로컬 네트워크 주소를 시스템 프록시에 임의로 입력하거나 “LAN 연결 허용”을 기본값처럼 켜지 마세요. 이 옵션은 로컬 수신 범위를 넓히므로 같은 네트워크의 다른 기기에서 현재 프록시를 사용해야 하고 네트워크 경계를 이해하고 있을 때만 설정해야 합니다.

시스템 프록시 및 서비스별 설정

macOS의 프록시 설정은 네트워크 서비스별로 저장되므로 Wi-Fi와 유선 네트워크에 서로 다른 설정이 적용될 수 있습니다. v2rayN이 시스템 프록시를 변경한 뒤 네트워크 서비스를 바꾸면 새 서비스에는 설정이 동기화되지 않을 수 있습니다. 반대로 시스템 설정에서 프록시를 수동으로 수정하면 클라이언트 메뉴 상태와 달라질 수도 있습니다. 브라우저가 프록시를 사용하지 않을 때는 먼저 현재 사용 중인 네트워크 서비스를 확인하고, 웹 프록시와 보안 웹 프록시의 서버 및 포트가 로컬 컴퓨터를 가리키는지 점검하세요.

클라이언트를 종료한 뒤 네트워크에 전혀 접근할 수 없다면 보통 시스템 프록시는 남아 있는데 로컬 수신은 중지된 상태입니다. 현재 네트워크 서비스의 프록시 세부 설정으로 들어가 해당 프록시 항목을 끄고 저장한 뒤 직접 연결을 다시 테스트하세요. 클라이언트가 아직 실행 중이라면 클라이언트의 “시스템 프록시 지우기” 기능을 먼저 사용할 수 있습니다. 로컬 프록시 잔류 문제를 해결하려고 라우터를 반복해서 재시작할 필요는 없습니다. 라우터 재시작은 시스템에 저장된 프록시 주소를 바꾸지 않습니다.

TUN, 네트워크 확장 및 DNS

macOS의 TUN 모드는 가상 네트워크 인터페이스를 만들기 위해 시스템 권한이 필요할 수 있습니다. 처음 활성화할 때는 시스템 팝업과 개인정보 보호 및 보안 페이지를 확인하고, 권한을 허용한 뒤 모드를 다시 시작하세요. 버튼을 켜자마자 다시 꺼진다면 로그에서 권한, 인터페이스 생성 또는 라우트 등록 오류를 확인합니다. TUN은 실행되지만 도메인에 접근할 수 있고 알고 있는 IP에는 응답이 있다면 DNS를 우선 점검하세요. 도메인과 IP 모두 접근할 수 없다면 기본 라우트와 현재 노드를 확인합니다.

가정용 Wi-Fi에서 회사 네트워크, 핫스팟 또는 유선 인터페이스로 전환하면 시스템이 DNS와 기본 라우트를 변경할 수 있습니다. 네트워크가 바뀐 뒤에는 이전 인터페이스를 계속 사용하지 않도록 TUN을 다시 구성해야 합니다. 로컬 네트워크 서비스에 접근할 수 없으면 사설 주소가 직접 연결인지 확인하고, “간단한 호스트 이름 우회”와 유사한 시스템 옵션이 잘못 덮어쓰이지 않았는지도 살펴보세요. 개발 환경의 로컬 도메인은 hosts 파일, 로컬 DNS 또는 컨테이너 네트워크에 의존할 수 있으므로 원격 DNS 규칙으로 대체되지 않았는지 확인해야 합니다.

scutil --proxy
networksetup -listallnetworkservices
route -n get default

위 명령은 현재 시스템 프록시, 네트워크 서비스 목록 및 기본 라우트를 확인하기 위한 것이며 설정을 변경하지 않습니다. 결과에서 프록시가 활성화되어 있다면 서버 주소와 포트를 확인하고, 기본 라우트는 현재 실제 네트워크 인터페이스를 가리키거나 TUN이 올바르게 처리하고 있어야 합니다. 문제를 해결한 뒤에는 명령줄 상태와 클라이언트 상태가 분리되지 않도록 그래픽 인터페이스에서 스위치를 조작하는 것이 좋습니다.

현재 칩에 맞는 설치 경로는 macOS 다운로드 영역에 있습니다. 같은 노드가 시스템 프록시에서는 작동하지만 TUN에서는 작동하지 않는다면 구독과 노드는 그대로 두고 권한, DNS, 라우팅을 집중적으로 확인하세요. 재설치보다 진단에 더 도움이 됩니다.

05 · LINUX

Linux: 패키지 설치, 데스크톱 프록시 및 서비스 범위

deb와 rpm 중 올바르게 선택하기

Linux용 v2rayN은 배포판의 패키지 형식과 프로세서 아키텍처를 모두 맞춰야 합니다. Debian, Ubuntu, Linux Mint 등은 보통 deb를 사용하고, Fedora, Rocky Linux, AlmaLinux 등은 보통 rpm을 사용합니다. x64는 일반적인 Intel 및 AMD 데스크톱 프로세서에, arm64는 해당 ARM 장치에 사용됩니다. uname -m으로 아키텍처를 확인할 수 있으며, 일반적으로 x86_64는 x64, aarch64는 arm64에 해당합니다. 패키지 형식이나 아키텍처 중 하나라도 맞지 않으면 설치 단계에서 패키지 관리자가 거부할 수 있습니다.

uname -m

sudo apt install ./v2rayN*.deb
sudo dnf install ./v2rayN*.rpm

다운로드한 파일이 있는 디렉터리에서 배포판에 맞는 설치 명령 하나를 실행하세요. 직접 압축을 푸는 것보다 패키지 관리자로 설치하는 편이 데스크톱 메뉴 항목과 의존성 처리가 쉽습니다. 의존성을 충족할 수 없다는 메시지가 나오면 현재 배포판의 패키지 인덱스를 먼저 업데이트하고 시스템 버전이 아직 지원되는지 확인하세요. 다른 배포판의 기본 라이브러리를 임의로 섞어 설치하지 마세요. 프로그램은 설치됐지만 메뉴에서 실행되지 않는다면 터미널에서 한 번 실행해 표준 출력을 확인하세요. 그래픽 의존성, 디스플레이 서비스 또는 권한 문제에 대한 구체적인 정보가 표시되는 경우가 많습니다.

데스크톱 환경에 따라 시스템 프록시 자동 등록 여부가 달라집니다

Linux에는 통일된 데스크톱 프록시 인터페이스가 없습니다. GNOME, KDE Plasma 및 기타 데스크톱 환경은 프록시를 저장하는 방식이 다르며, v2rayN의 자동 설정 기능도 데스크톱 세션에 따라 달라질 수 있습니다. 클라이언트에 “시스템 프록시가 켜짐”이라고 표시되어도 데스크톱 네트워크 설정에서 HTTP, HTTPS, SOCKS 항목을 다시 확인하세요. 어떤 앱은 데스크톱 프록시를 따르고, 어떤 앱은 환경 변수만 읽으며, 또 어떤 앱은 자체 설정만 사용합니다. 따라서 Linux에서는 “커널이 정상적으로 실행 중인가”와 “앱이 트래픽을 커널로 보내는가”를 반드시 구분해야 합니다.

브라우저에서는 접속되지만 터미널 명령이 작동하지 않는다면 노드가 갑자기 중단된 것이 아니라 터미널이 데스크톱 프록시를 읽지 않는 경우가 많습니다. 현재 터미널에서 프록시 변수를 임시로 내보내 테스트할 수 있으며 포트는 클라이언트의 실제 값을 사용하세요. 테스트가 성공한 뒤에야 shell 설정에 기록할지 결정합니다. 환경 변수를 장기간 유지하면 패키지 관리자, 컨테이너 도구 및 로컬 네트워크 접근에 영향을 줄 수 있으므로 영향 범위를 모르는 상태에서 전역으로 설정하지 않는 것이 좋습니다. 클라이언트를 종료한 뒤에도 해당 변수를 지워야 명령이 중지된 로컬 포트에 계속 연결을 시도하지 않습니다.

구독 디렉터리, 권한 및 설정 저장

구독 가져오기는 여전히 v2rayN 그래픽 인터페이스에서 진행합니다. 한 번 관리자 권한으로 실행한 뒤 일반 사용자가 설정을 저장할 수 없다면 설정 디렉터리의 소유자가 바뀌었을 가능성이 있습니다. 그래픽 클라이언트는 보통 현재 데스크톱 사용자로 실행하고, TUN 생성이나 특정 시스템 작업을 할 때만 권한을 높여야 합니다. 관리자 계정으로 장기간 실행하면 다운로드 파일, 로그, 설정의 소유권이 뒤섞이고 프로그램이 접근할 수 있는 범위도 넓어집니다. 저장에 실패하면 구독을 반복해서 삭제하지 말고 사용자 설정 디렉터리의 권한을 확인하세요.

데스크톱 세션 종료, 시스템 업그레이드 또는 앱의 비정상 종료 후 시스템 프록시가 남을 수 있습니다. 복구 방법은 데스크톱 환경에 따라 다릅니다. 먼저 네트워크 설정에서 “프록시 없음” 또는 “자동”으로 전환한 뒤 터미널 환경 변수도 삭제됐는지 확인하세요. 앱이 독립 프록시를 사용한다면 앱 설정에서도 로컬 주소를 삭제해야 합니다. 문제를 확인할 때 v2rayN을 종료한 뒤 일반 네트워크 요청을 실행해 볼 수 있습니다. 요청이 여전히 127.0.0.1에 접근하려 한다면 어딘가에 프록시 설정이 남아 있는 것입니다.

TUN, 라우팅 테이블 및 컨테이너 네트워크 충돌

Linux TUN은 커널 장치, 네트워크 관리 방식 및 권한에 의존합니다. 활성화에 실패하면 먼저 /dev/net/tun이 존재하는지 확인하고 로그에 권한 부족이 표시되는지 살펴보세요. TUN은 시작되지만 일부 주소에 접근할 수 없다면 ip route와 ip rule을 확인해야 합니다. Docker, Podman, 가상 머신 및 회사 VPN은 추가 네트워크 대역을 만들 수 있으며, 로컬 네트워크나 프록시 규칙과 겹치면 트래픽이 잘못된 인터페이스로 들어갈 수 있습니다. 라우트가 여러 개 보인다고 모두 삭제하지 말고 각 라우트가 어느 소프트웨어에 속하는지 먼저 확인하세요.

ip route
ip rule
cat /etc/resolv.conf
ss -lntp

ip route와 ip rule은 라우팅 결정을 확인하는 데 사용하고, /etc/resolv.conf는 현재 DNS 조회 진입점을 보여 주며, ss -lntp는 로컬 수신 포트를 확인하는 데 사용할 수 있습니다. 클라이언트가 커널이 시작됐다고 표시하지만 해당 포트가 존재하지 않는다면 먼저 시작 로그를 확인하세요. 포트는 존재하지만 앱 연결이 거부된다면 주소 유형, 프로토콜 유형 및 방화벽을 점검합니다. HTTP 요청을 SOCKS 포트로 보내거나 SOCKS 설정을 HTTP만 받는 프로그램에 입력해도 로컬 연결 실패처럼 나타납니다.

설치 패키지 경로와 arm64 항목은 Linux 다운로드 영역에 있습니다. 장기간 안정적으로 사용할 데스크톱 환경이라면 먼저 일반 사용자 세션에서 그래픽 클라이언트가 정상 작동하도록 한 뒤 자동 시작, TUN, 사용자 지정 라우팅을 단계적으로 추가하세요.

06 · ANDROID

Android: v2rayNG·v2flyNG 가져오기 및 시스템 VPN 적용

클라이언트와 설치 패키지 선택

Android에서는 Xray 커널 계열을 사용하는 v2rayNG를 우선 선택할 수 있습니다. V2Fly 커널이 필요하다면 v2flyNG를 사용하세요. 두 클라이언트 모두 구독, 설정 목록, 라우팅, 시스템 VPN 적용을 제공하지만 메뉴 이름과 일부 프로토콜 지원은 다를 수 있습니다. 두 클라이언트에서 동시에 연결을 시작하지 마세요. 시스템에서는 이런 VPN 세션 하나만 동시에 활성 상태로 둘 수 있습니다. 클라이언트를 바꿀 때는 현재 클라이언트에서 먼저 연결을 끊은 뒤 다른 클라이언트에서 시작하세요.

대부분의 최신 주류 기기에서는 arm64 설치 패키지를 선택하면 됩니다. 아키텍처를 확인할 수 없거나 arm64 패키지가 설치되지 않거나 기기 호환성이 특수한 경우에만 범용 버전을 선택하세요. 설치하기 전에 현재 파일 관리자나 브라우저가 이번 설치를 진행할 수 있도록 시스템에서 허용하고, 설치가 끝나면 해당 출처의 설치 권한을 다시 끌 수 있습니다. 앱이 설치되지 않는다는 메시지가 나오면 모든 네트워크 설정을 삭제하지 말고, 서명이 다른 동명의 앱이 이미 있는지, 저장 공간이 충분한지, 설치 패키지 아키텍처가 맞는지 먼저 확인하세요.

스캔, 클립보드 및 구독 가져오기

단일 설정은 QR 코드 스캔, 클립보드에서 공유 링크 가져오기 또는 수동 입력으로 추가할 수 있습니다. QR 코드 가져오기에는 카메라 권한이 필요하고, 클립보드에서 가져오기 전에는 전체 링크를 복사했는지 확인해야 합니다. 수동 입력은 적은 수의 매개변수를 직접 확인할 때 적합합니다. 구독은 구독 그룹 또는 구독 설정으로 들어가 주소를 추가한 뒤 업데이트하세요. 구독 주소를 단일 노드 링크처럼 가져오면 원하는 목록이 생성되지 않을 수 있고, 단일 공유 링크를 구독 주소에 입력해도 오류가 표시될 수 있습니다.

업데이트 후 설정 목록이 비어 있다면 현재 그룹, 필터 키워드 및 업데이트 로그를 확인하세요. 목록은 있지만 연결되지 않는다면 설정 하나를 활성 항목으로 지정한 뒤 실제 연결 테스트를 실행합니다. 모바일 네트워크와 Wi-Fi는 경로가 다르므로 같은 설정도 결과가 달라질 수 있습니다. 문제를 판단할 때 현재 네트워크 유형을 기록하세요. Wi-Fi에서 구독을 업데이트하고 모바일 네트워크로 전환해 테스트한 뒤 곧바로 노드가 실패했다고 결론 내리지 않도록 주의합니다.

연결 권한, 앱별 프록시 및 백그라운드 제한

처음 연결 버튼을 누르면 시스템에서 VPN 연결 권한을 요청합니다. 승인하면 상태 표시줄에 해당 시스템 표시가 나타나는 경우가 많습니다. 연결을 눌러도 반응이 없으면 이미 다른 VPN 세션이 실행 중인지, 업무용 프로필 정책이나 시스템 네트워크 기능이 인터페이스를 사용 중인지 확인하세요. 클라이언트에는 연결됨으로 표시되지만 모든 앱이 접근할 수 없다면 먼저 연결을 끊고 이미 작동하는 것으로 확인된 다른 설정으로 전환하세요. 특정 앱만 네트워크가 되지 않는다면 앱별 프록시 설정을 확인합니다.

앱별 프록시를 사용하면 어떤 앱의 트래픽을 클라이언트가 처리할지 선택하거나 우회 목록을 지정할 수 있습니다. 규칙의 방향을 반드시 확인하세요. “선택한 앱만 프록시”와 “선택한 앱은 프록시 사용 안 함”은 완전히 반대 결과를 만듭니다. 최초 설정에서는 앱별 제한을 끄고 전체 연결이 정상인지 확인한 뒤 하나씩 추가하는 것이 좋습니다. 활성화 후 새로 설치한 앱만 연결되지 않는다면 기존 목록에 포함되지 않았을 수 있으므로 선택 범위를 다시 확인하세요.

일부 시스템은 백그라운드 앱, 절전 중 네트워크 또는 자동 프로세스 정리를 제한하며, 화면을 잠근 뒤 한동안 지나면 연결이 끊기는 현상이 나타날 수 있습니다. 시스템 배터리 설정에서 클라이언트가 필요한 백그라운드 작업을 유지하도록 허용하고 해당 앱에 적용된 과도한 절전 제한을 해제하세요. 모든 절전 기능을 끌 필요는 없으며 현재 클라이언트에만 조정하면 됩니다. 연결이 자주 재수립되는 원인이 Wi-Fi와 모바일 네트워크의 자동 전환일 수도 있으므로 먼저 한 가지 네트워크로 고정해 테스트하세요.

라우팅, 원격 DNS 및 로컬 네트워크 접근

Android 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 처리하고, 라우팅 모드가 도메인과 IP의 외부 연결 방향을 결정합니다. 규칙 모드를 사용할 때는 LAN 주소를 직접 연결로 유지해야 합니다. 그렇지 않으면 화면 미러링, 프린터, 네트워크 저장소, 라우터 관리 페이지에 접근하지 못할 수 있습니다. 공용 인터넷은 정상인데 로컬 기기가 사라졌다면 노드 프로토콜 매개변수를 바꾸지 말고 LAN 우회 설정과 사설 주소 규칙을 먼저 확인하세요.

DNS 설정은 라우팅 대상과 일치해야 합니다. 원격 도메인을 프록시로 접속할 때 원격 DNS를 사용하면 로컬 DNS 결과와 프록시 출구가 달라지는 문제를 줄일 수 있습니다. 반면 로컬 도메인, 라우터 도메인, LAN 서비스는 로컬 DNS에 의존할 수 있습니다. 설정이 지나치게 단순하면 한 종류의 도메인은 정상인데 다른 종류는 실패할 수 있습니다. 처음에는 클라이언트 기본 DNS를 유지하고, 안정적으로 재현되는 조회 문제가 있을 때만 변경하세요. 변경할 때마다 연결을 끊었다가 다시 연결해야 합니다.

두 Android 클라이언트의 arm64 및 범용 버전 다운로드 경로는 Android 다운로드 영역에 있습니다. Xray, V2Fly 및 그래픽 클라이언트의 관계를 이해하려면 Project V, V2Fly 및 Xray 생태계 정리를 읽어 보세요. 클라이언트 이름, 커널 이름, 프로토콜 이름을 하나의 계층으로 혼동하지 않는 데 도움이 됩니다.

07 · CONFIGURATION

구독, 라우팅 및 DNS: 플랫폼을 아우르는 설정의 핵심

구독 업데이트와 노드 매개변수는 서로 다른 경로입니다

구독 업데이트는 구독 주소에 요청을 보내고, 반환된 내용을 읽고, 설정을 파싱한 뒤 로컬 그룹에 저장하는 과정입니다. 노드 연결은 특정 설정을 읽고, 커널을 시작하고, 서버 도메인을 조회하고, 전송을 수립한 뒤 프로토콜 핸드셰이크를 완료하는 과정입니다. 업데이트 성공은 첫 번째 경로가 완료됐다는 뜻일 뿐 모든 노드가 작동한다는 의미는 아닙니다. 노드 연결 성공 역시 이후 구독이 반드시 업데이트된다는 뜻은 아닙니다. 문제를 해결할 때는 어느 경로에서 실패했는지 먼저 확인하세요. 그렇지 않으면 구독 주소 오류를 “노드 변경”으로 처리하거나 단일 노드 매개변수 문제를 “구독 재가져오기”로 처리하게 됩니다.

구독을 업데이트하기 전에 현재 작동하는 설정을 기록해 두세요. 업데이트 후 항목이 크게 바뀌었다면 먼저 그룹이 올바른지 확인합니다. 여러 구독에 같은 이름의 노드가 있다면 표시 이름만으로 출처를 판단하지 마세요. 그룹별로 필터링한 뒤 속도를 측정하거나 키워드로 필요 없는 지역 및 배율 표시를 제외할 수 있습니다. 필터 조건이 너무 넓으면 정상 노드가 숨겨지고, 너무 좁으면 관리 의미가 사라집니다. 여러 출처를 정리하는 자세한 방법은 다중 구독 그룹 및 서버 필터링을 참고하세요.

라우팅 규칙은 매칭 범위와 순서에 따라 작동합니다

일반적인 라우팅 조건에는 도메인, IP 주소, 포트, 프로토콜 및 프로세스가 있습니다. 도메인 규칙은 특정 사이트를 처리하는 데 적합하고, IP 규칙은 LAN과 고정 네트워크 대역에 적합합니다. 프로세스 규칙은 데스크톱 앱을 분할 라우팅하기 편리하지만 플랫폼별 지원 여부가 다릅니다. 규칙은 보통 위에서 아래로 매칭되며, 일치하면 프록시, 직접 연결 또는 차단 아웃바운드를 선택합니다. 따라서 더 정확한 규칙을 더 넓은 규칙보다 앞에 배치해야 합니다. 예를 들어 LAN과 로컬 도메인은 먼저 직접 연결하고, 특정 도메인을 처리한 뒤, 마지막으로 기본 아웃바운드가 매칭되지 않은 트래픽을 처리하도록 구성하세요.

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

예시는 라우팅 구조의 기본 관계를 보여 줍니다. 사설 주소는 직접 연결하고 지정한 도메인은 프록시를 사용합니다. 실제 완전한 설정에는 direct 및 proxy 태그에 대응하는 아웃바운드 정의도 있어야 합니다. 클라이언트의 그래픽 라우팅 화면은 보통 JSON을 직접 작성하지 않아도 되게 해 주지만, 태그 관계를 이해하는 것은 여전히 중요합니다. 존재하지 않는 아웃바운드 태그를 규칙에서 참조하면 커널이 시작을 거부할 수 있고, 도메인 규칙 형식이 현재 커널과 맞지 않으면 규칙이 적용되지 않을 수 있습니다.

DNS가 도메인을 라우팅 판단으로 넘기는 방식을 결정합니다

도메인에 접근할 때 클라이언트가 먼저 도메인 규칙으로 매칭할 수도 있고, IP로 조회한 뒤 계속 판단할 수도 있습니다. domainStrategy는 도메인을 언제 조회할지 제어하지만, 커널과 클라이언트에 따라 제공되는 옵션은 조금씩 다를 수 있습니다. AsIs는 규칙 매칭을 위해 도메인을 유지하는 경향이 있고, IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 IP를 조회합니다. 더 적극적인 조회 전략은 DNS 참여 정도를 높입니다. 특정 값을 만능 가속 옵션으로 여기지 말고 라우팅 규칙의 필요에 따라 선택하세요.

DNS 문제는 도메인이 열리지 않거나, 최초 접속이 오래 걸리거나, 같은 웹사이트가 네트워크에 따라 다르게 표시되거나, TUN 모드에서 모든 도메인이 실패하는 형태로 나타나는 경우가 많습니다. 먼저 도메인과 IP의 접근 가능성을 비교한 뒤 클라이언트 DNS 로그를 확인하세요. 시스템 DNS, 클라이언트 DNS, 브라우저 보안 DNS, 라우팅 정책을 동시에 바꾸지 마세요. 한 번에 한 계층만 변경해야 어느 계층이 적용됐는지 알 수 있습니다. 브라우저에 독립 DNS 설정이 내장되어 있을 수 있으므로 브라우저와 다른 앱의 결과가 다르면 시스템 및 클라이언트 조회를 우회하는지 확인해야 합니다.

{
  "dns": {
    "servers": [
      "https+local://1.1.1.1/dns-query",
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

DNS 설정 기능은 커널 버전과 클라이언트 구현에 따라 달라집니다. 위 예시는 서버 목록과 조회 전략의 계층을 설명하기 위한 것이므로 클라이언트의 지원 방식을 확인하지 않고 완전한 설정을 그대로 덮어쓰지 마세요. 그래픽 클라이언트에서 DNS 프리셋을 제공한다면 현재 커널에 맞는 프리셋을 우선 사용하고 로그를 보며 조금씩 조정하세요. 사용자 지정 설정을 적용하기 전에는 원래 값을 저장해야 조회 문제가 생겼을 때 빠르게 되돌릴 수 있습니다.

속도 측정 결과는 실제 연결과 함께 판단해야 합니다

노드 목록의 지연 시간은 TCP 탐색, 연결 테스트 또는 대상 웹사이트 테스트에서 나온 값일 수 있으므로 측정 방법이 다르면 단순 비교할 수 없습니다. TCP 지연이 낮다는 것은 기본 연결이 빠르게 수립된다는 뜻이지만 완전한 앱 요청은 포함하지 않습니다. 실제 연결 테스트는 사용 상황에 더 가깝지만 테스트 주소, DNS, 현재 네트워크의 영향을 받습니다. 노드를 선택할 때는 연결 성공률, 실제 접속 결과, 지역 요구 사항, 트래픽 배율을 종합하고 목록에서 숫자가 가장 작은 항목만 고르지 마세요.

대량 속도 측정은 여러 연결을 동시에 만들기 때문에 네트워크가 약하거나 노드가 많으면 일시적인 시간 초과가 발생할 수 있습니다. 구독 그룹별로 나누어 테스트한 뒤 후보 노드에 실제 접속해 확인하세요. 노드 상태가 시간에 따라 바뀌는 것은 정상적인 네트워크 현상이며, 너무 자주 전환하면 오히려 문제를 재현하기 어려워집니다. 모든 노드가 같은 시각에 실패한다면 각 노드를 하나씩 편집하기보다 로컬 네트워크, 시스템 시간, 구독 상태, 커널 시작 여부를 먼저 확인하세요.

08 · TROUBLESHOOTING

주요 설정 문제: 증상에 따른 점검 경로

클라이언트를 시작할 수 없거나 시작 직후 종료됩니다

먼저 설치 계층의 문제인지 설정 계층의 문제인지 판단하세요. 설치 프로그램이 실행되지 않거나 패키지 비호환 메시지가 표시되면 플랫폼, 아키텍처 또는 패키지 형식을 잘못 선택했을 가능성이 큽니다. 프로그램 창이 잠깐 나타났다가 종료되면 실행 의존성, 권한, 설정 파싱 또는 커널 로드 실패일 수 있습니다. 데스크톱 플랫폼에서는 터미널에서 프로그램을 실행해 출력을 확인하고, Windows에서는 클라이언트 로그 디렉터리도 확인하세요. macOS는 시스템 알림을, Linux는 표준 출력과 데스크톱 세션 정보를 살펴봅니다. 오류를 기록하지 않은 채 연속으로 재설치하지 마세요. 재설치가 현장을 덮어쓸 뿐 아키텍처나 권한 문제를 해결하지 못할 수 있습니다.

설정을 삭제한 뒤 시작된다면 사용자 지정 라우팅, DNS 또는 완전한 JSON이 원인일 수 있습니다. 모든 내용을 다시 가져오기보다 최근 변경 사항부터 되돌리세요. 기본 설정에서도 시작되지 않는다면 시스템 시간, 디스크 공간, 사용자 디렉터리 쓰기 권한, 보안 소프트웨어 차단을 확인합니다. 앱이 읽기 전용 위치에 설치됐거나 설정 디렉터리의 소유자가 관리자이거나 커널 파일의 실행이 차단된 경우에도 비슷한 현상이 나타날 수 있습니다.

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

구독 문제가 생기면 먼저 요청이 실제로 전송됐는지 확인하세요. 주소 형식 오류, 불완전한 복사, 네트워크 접근 불가, 서버 응답 이상은 요청 단계에서 실패합니다. 요청은 성공했지만 파싱에 실패했다면 반환된 내용이 클라이언트가 지원하는 구독 형식인지 중점적으로 확인하세요. 파싱은 성공했는데 목록이 비어 있다면 현재 그룹, 필터 키워드, 숨김 조건이 실수로 활성화됐는지 확인합니다. 그룹이 여러 개라면 현재 그룹을 업데이트한 것인지 다른 출처를 업데이트한 것인지도 확인해야 합니다.

구독 주소가 브라우저에서 열린다고 해서 클라이언트에 복사한 주소와 완전히 같다는 뜻은 아닙니다. 브라우저는 주소를 자동으로 보완하거나 로그인 상태를 유지할 수 있지만, 클라이언트는 원본 주소로 요청합니다. 다시 복사할 때는 제공자가 구독을 제공하는 위치에서 복사 기능을 사용하고, 메신저가 링크를 잘라내지 않도록 주의하세요. 업데이트를 너무 자주 요청하면 서버 측 제한이 발생할 수 있으므로 연속으로 클릭하기보다 적절한 시간 후 다시 시도하는 편이 효과적입니다.

노드는 사용 가능으로 표시되지만 브라우저에서 웹페이지가 열리지 않음

먼저 활성 노드가 실제로 선택됐는지 확인한 다음 시스템 프록시가 등록됐는지 점검하세요. 클라이언트 테스트는 지정된 대상에 대한 커널 연결만 검증하지만, 브라우저도 트래픽을 로컬 포트로 보내야 합니다. 시스템 프록시 설정에서 루프백 주소와 포트를 확인한 뒤 브라우저를 완전히 재시작하세요. 브라우저에 독립 프록시 확장 프로그램이 설치되어 있다면 잠시 비활성화해 시스템 설정을 덮어쓰지 않도록 합니다. 특정 웹사이트 하나만 실패한다면 전체 프록시가 작동하지 않는다고 판단하지 말고 라우팅 규칙, DNS, 대상 웹사이트 상태를 확인하세요.

모든 브라우저에서 실패하지만 명령줄이 앱 내 프록시로 작동한다면 문제는 시스템 프록시 또는 브라우저 설정에 집중됩니다. 브라우저는 작동하지만 다른 앱이 작동하지 않는다면 해당 앱이 시스템 프록시를 따르지 않는 것이므로 앱 내 프록시 또는 TUN을 고려할 수 있습니다. 앱 유형별 결과를 비교하면 트래픽이 어느 계층에서 클라이언트로 들어오지 않는지 빠르게 판단할 수 있습니다.

TUN을 켠 뒤 인터넷이 완전히 끊김

즉시 TUN을 끄고 일반 네트워크가 복구되는지 확인하세요. 끈 뒤에도 접근할 수 없다면 시스템 프록시가 남아 있는지 확인한 다음 DNS와 기본 라우트를 점검합니다. 일반 네트워크가 복구되면 같은 노드로 시스템 프록시를 켜서 테스트하세요. 시스템 프록시가 작동한다면 노드와 커널은 기본적으로 정상이며, 이후에는 TUN 권한, 가상 인터페이스, 자동 라우팅, DNS만 확인하면 됩니다. 시스템 프록시도 작동하지 않는다면 먼저 노드 또는 커널 문제를 해결하고 가상 네트워크 카드를 계속 조정하지 마세요.

TUN 문제는 여러 VPN, 컨테이너 네트워크, 가상 머신 또는 회사 네트워크 클라이언트를 동시에 실행할 때 자주 발생합니다. 충돌 가능성이 있는 네트워크 도구를 한 번에 하나씩 비활성화하고 라우팅 변화를 관찰하세요. LAN에는 접근할 수 없지만 공용 인터넷은 된다면 사설 네트워크 대역의 직접 연결을 확인하고, 도메인은 실패하지만 IP는 접근 가능하다면 DNS를 확인합니다. 모든 트래픽이 외부로 나가지 않는다면 기본 라우트와 인터페이스 권한을 점검하세요. “네트워크 전체 초기화”보다 증상별로 나누어 확인하는 편이 정상 설정을 보존하기 쉽습니다.

한동안 연결된 뒤 자동으로 끊김

모바일 기기에서는 먼저 백그라운드 제한과 네트워크 자동 전환을 확인하고, 데스크톱 기기에서는 절전 모드 복귀와 네트워크 인터페이스 변화를 확인하세요. 매번 일정한 시간에 끊긴다면 클라이언트의 예약 업데이트, 커널 재시작 또는 시스템 절전 정책을 살펴봅니다. Wi-Fi 신호가 바뀔 때만 발생한다면 네트워크 전환으로 기존 연결이 무효화됐을 수 있으며, 연결을 끊었다가 다시 연결하면 복구되는 경우가 많습니다. 로그에 원격에서 연결을 종료했다는 내용이나 연속 핸드셰이크 실패가 표시될 때 노드 교체를 비교하세요.

한 번 끊겼다는 사실만으로 노드의 안정성을 판단하지 마세요. 발생 시각, 네트워크 유형, 현재 모드, 로그의 주요 행을 기록하고 두세 번 반복한 뒤 패턴을 찾으세요. 모든 노드가 동시에 끊긴다면 로컬 네트워크나 클라이언트 상태일 가능성이 높고, 특정 노드 하나만 반복해서 실패한다면 노드 측 문제에 가깝습니다. 후보 노드의 실제 연결 테스트 방법은 최초 연결 및 프록시 적용 확인을 참고하세요.

클라이언트를 종료한 뒤에도 네트워크가 비정상임

가장 흔한 원인은 시스템 프록시 또는 환경 변수가 로컬 포트를 계속 가리키는 것입니다. Windows와 macOS에서는 현재 네트워크의 프록시 설정으로 들어가 수동 프록시를 끄세요. Linux는 데스크톱 프록시뿐 아니라 터미널의 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY도 확인해야 합니다. Android에서는 시스템 VPN 세션이 끊겼는지 확인하세요. TUN을 사용했다면 가상 인터페이스와 라우트가 정리될 때까지 기다린 뒤 네트워크를 다시 연결합니다.

브라우저가 계속 비정상이라면 완전히 종료한 뒤 다시 시작하고, 필요하면 브라우저의 독립 프록시와 DNS 설정을 확인하세요. 특정 앱 하나만 복구되지 않는다면 해당 앱의 네트워크 설정에서 로컬 프록시를 삭제합니다. 브라우저 데이터 삭제를 첫 단계로 삼지 마세요. 프록시 잔류와 웹페이지 캐시는 서로 다른 계층의 문제입니다. 먼저 시스템 직접 연결을 복구한 뒤 클라이언트 설정을 계층별로 되돌리는 것이 간단한 문제를 키우지 않는 방법입니다.

구독 업데이트, 노드 변경, 재설치 중 무엇을 선택해야 할까요?

구독 요청이 실패하거나 서버 목록이 계속 갱신되지 않으면 구독을 처리해야 합니다. 특정 설정 하나만 핸드셰이크에 실패하고 다른 설정은 정상이라면 노드를 바꾸거나 원격 복구를 기다리세요. 모든 노드가 실패하지만 커널은 정상이라면 네트워크, 시간, 시스템 프록시, DNS를 확인합니다. 프로그램이 시작되지 않거나 의존성이 손상됐거나 설치 패키지 아키텍처가 잘못된 경우에만 설치 계층을 처리하세요. 대부분의 연결 문제는 설정과 시스템 네트워크 계층에서 발생하므로 재설치는 점검 과정의 후반에 두는 것이 좋습니다.

복잡한 문제를 처리할 때는 최소 설정을 구성하세요. 구독 그룹 하나, 작동이 확인된 설정 하나, 기본 라우팅, 기본 DNS만 남기고 시스템 프록시로 테스트합니다. 최소 설정이 성공하면 사용자 지정 설정을 하나씩 복원하세요. 문제가 다시 발생한 단계가 원인 계층일 가능성이 큽니다. 최소 설정에서도 실패한다면 클라이언트 로그, 시스템 플랫폼, 네트워크 유형, 재현 절차를 수집하세요. “연결을 누른 뒤 로그에 무엇이 표시되는지, 시스템 프록시가 등록됐는지, 시스템 프록시와 TUN의 결과가 어떻게 다른지”를 설명하면 단순히 “작동하지 않는다”고 말하는 것보다 원인을 찾는 데 훨씬 도움이 됩니다.

문제 해결이 끝나면 확인된 클라이언트 유형, 구독 그룹 이름, 자주 사용하는 연결 모드, 사용자 지정 규칙을 기록해 두는 것이 좋습니다. 다시 설치해야 한다면 먼저 클라이언트 다운로드 페이지에서 플랫폼별 경로를 확인하세요. 기본 절차만 다시 진행하면 된다면 빠른 시작 튜토리얼로 돌아가면 됩니다. 이 매뉴얼은 경계 조건과 예외 상황을 다루고, 빠른 시작 튜토리얼은 가장 짧은 정상 경로를 복구하는 데 적합합니다.