V2Ray 클라이언트완벽 설정 가이드

핵심 개념과 클라이언트 선택

먼저 클라이언트, 코어, 노드와 구독을 구분하세요

V2Ray 사용 과정은 네 가지 계층으로 나눌 수 있습니다. 클라이언트는 창, 메뉴, 구독 관리와 시스템 연결 기능을 제공하고, 코어는 프로토콜을 해석해 아웃바운드 연결을 만들고 라우팅 규칙을 실행합니다. 노드는 사용할 수 있는 서버 연결 정보의 묶음이며, 구독은 노드와 변경 사항을 일괄 배포하고 업데이트하는 주소입니다. v2rayN, v2rayNG, v2flyNG는 모두 클라이언트이지 프로토콜 자체가 아닙니다. Xray와 V2Fly는 대표적인 코어 계열이며, 클라이언트가 설정에 따라 해당 코어를 호출해 실제 연결을 처리합니다.

계층을 이해하면 많은 문제를 더 쉽게 찾을 수 있습니다. 클라이언트 창이 열린다는 것은 UI 계층이 정상이라는 뜻일 뿐입니다. 구독 목록에 노드가 표시되어도 구독 내용이 해석되었다는 의미에 그칩니다. 노드를 활성 서버로 지정했다고 해서 앱 트래픽이 클라이언트로 전달되는 것도 아닙니다. 코어가 정상적으로 시작되었는지, 로컬 리스닝 포트에 충돌이 없는지, 시스템 프록시나 TUN이 대상 앱을 인계했는지까지 확인해야 합니다. 어느 한 단계에서 중단되어도 최종 증상은 “웹페이지가 열리지 않음”으로 같을 수 있지만 해결 방법은 전혀 다릅니다.

세 클라이언트 선택 기준

Windows, macOS, Linux 데스크톱 환경에서는 v2rayN을 우선 선택하세요. 구독, 서버, 라우팅 규칙, 시스템 프록시와 TUN을 통합 관리할 수 있어 처음 사용하는 단계부터 복잡한 분할 라우팅까지 확장하기 좋습니다. Windows에서는 데스크톱 버전과 클래식 WPF 버전 중에서 선택할 수 있습니다. 데스크톱 버전은 크로스 플랫폼 UI를 사용해 운영체제가 달라도 비슷한 조작 흐름을 제공하고, WPF 버전은 Windows 전용으로 보다 전통적인 UI와 의존성 체계를 사용합니다. 설치 패키지는 현재 환경에 맞춰 Windows 다운로드 영역에서 선택하세요.

Android 기기에서는 v2rayNG를 우선 사용하세요. Xray 코어를 주 실행 계층으로 사용하며, 일반적인 프로토콜과 라우팅 설정을 한 화면에서 관리할 수 있습니다. V2Fly 코어 체계가 필요하다면 v2flyNG를 선택할 수 있습니다. 두 클라이언트의 구독 가져오기, 노드 선택과 연결 시작 과정은 비슷하지만 코어 기능과 일부 설정 필드는 완전히 같지 않습니다. 한 클라이언트에서 내보낸 고급 설정 전체를 다른 클라이언트가 그대로 읽을 수 있다고 가정하지 마세요. 이전할 때는 먼저 프로토콜 필드와 라우팅 규칙을 확인해야 합니다.

프로토콜 이름과 클라이언트 이름은 다릅니다

VMess, VLESS, Trojan 등의 이름은 연결 프로토콜이나 인증 방식을 설명하고, REALITY, TLS 등의 필드는 전송 보안과 핸드셰이크 특성을 설명합니다. TCP, WebSocket, gRPC는 전송 계층 설정입니다. 클라이언트는 이 필드들을 코어가 실행할 수 있는 설정으로 정리합니다. 노드를 가져올 때는 주소, 포트, 사용자 식별자, 전송 방식, 암호화 또는 보안 옵션이 서로 맞아야 합니다. 프로토콜 이름이 같다는 이유만으로 두 노드의 설정이 동일하다고 판단해서는 안 됩니다.

초보 단계에서는 모든 필드를 직접 입력할 필요가 없습니다. 가장 안전한 방법은 먼저 구독으로 가져오고, 제공자가 관리하는 전체 매개변수를 사용한 뒤 노드 정보와 로그를 확인하는 법을 익히는 것입니다. 수동으로 수정하기 전에는 노드를 복사해 원본 설정이 덮어써지지 않게 하세요. 각 필드의 의미를 더 이해하고 싶다면 용어집에서 프로토콜, 코어, 구독과 라우팅 개념을 함께 확인하세요. “UI에서 관리하고, 코어가 실행하며, 노드가 매개변수를 제공하고, 구독이 배포한다”는 구조를 이해하는 것이 설치와 문제 해결의 기반입니다.

설치와 첫 실행

다운로드 전에 운영체제와 프로세서 아키텍처를 확인하세요

설치 패키지는 운영체제, 프로세서 아키텍처와 클라이언트 UI 분기에 모두 맞아야 합니다. Windows의 일반적인 기기는 x64 패키지를 사용하고, macOS는 Apple Silicon과 Intel 중 무엇인지 먼저 확인해야 합니다. Linux는 배포판 패키지 형식뿐 아니라 x64와 arm64도 구분해야 합니다. Android 주요 기기는 보통 arm64를 우선 선택하며, 아키텍처가 불분명하거나 시스템에서 설치를 거부할 때만 범용 패키지를 사용하세요. 모든 다운로드 경로는 다운로드 페이지에 모아 두었습니다. 다른 플랫폼의 파일 이름을 바꿔 설치하려고 하지 마세요.

Windows 사용자는 데스크톱 버전과 WPF 버전 중에서도 선택해야 합니다. macOS와 Linux에 가까운 UI 흐름을 원한다면 데스크톱 버전을, 기존 설정과 사용 습관이 클래식 Windows UI를 기반으로 한다면 WPF 버전을 선택하세요. 둘 다 v2rayN이지만 실행 환경, UI 구성 요소와 일부 메뉴 위치가 다릅니다. 튜토리얼의 화면과 현재 UI가 다를 때는 기능이 없다고 판단하기 전에 사용 중인 분기를 먼저 확인하세요.

Windows, macOS, Linux 실행 시 확인할 점

Windows 설치 후에는 일반 사용자 디렉터리에서 실행하고, 설정 디렉터리에 쓰기 권한이 있어야 합니다. 더블 클릭해도 창이 나타나지 않으면 필요한 실행 환경이 완비되었는지 먼저 확인한 다음 설치 경로가 지나치게 깊지 않은지, 디렉터리가 읽기 전용인지, 보안 정책이 설정 및 로그 파일 생성을 막고 있지 않은지 점검하세요. 압축 파일 미리보기 창에서 프로그램을 직접 실행하지 말고 먼저 전체 압축을 풀거나 설치를 완료해야 합니다. 시작 직후 종료되는 문제는 런타임과 권한 점검에서 계층별 확인 방법을 참고하세요.

macOS에서 처음 열 때 앱 출처와 네트워크 관련 권한을 확인하라는 메시지가 나타날 수 있습니다. 시스템 설정의 개인정보 보호 및 보안 페이지에서 명시적으로 허용한 뒤 클라이언트를 다시 시작하세요. 시스템 프록시나 TUN을 켤 때 관리자 확인을 요구할 수도 있는데, 이는 네트워크 설정을 변경하는 데 필요한 절차입니다. 전체 과정은 macOS 설치 및 네트워크 권한 설정에서 확인할 수 있습니다. 프로그램은 열리지만 네트워크 설정을 변경하지 못한다면 구독을 반복해서 가져오기보다 권한을 먼저 확인하세요.

Linux 사용자는 먼저 배포판에 맞는 deb 또는 rpm 패키지를 선택한 다음 현재 데스크톱 세션이 시스템 프록시 인터페이스를 제공하는지 확인하세요. 설치가 완료되었다는 것은 프로그램 파일이 준비되었다는 뜻일 뿐입니다. 트레이 아이콘, 자동 시작과 시스템 프록시 저장은 데스크톱 환경에도 영향을 받습니다. 최소 구성의 윈도 매니저를 사용한다면 브라우저나 터미널에서 로컬 프록시를 별도로 지정해야 할 수 있습니다. 클라이언트 로그와 설정 디렉터리는 현재 사용자가 소유하도록 하여 매번 권한 상승에 의존하지 않게 하세요.

Android 설치와 시스템 연결 확인

Android에 v2rayNG 또는 v2flyNG를 설치한 뒤 처음 연결하면 시스템 수준의 연결 확인 창이 나타납니다. 승인하면 상태 표시줄에 시스템이 제공하는 연결 상태 아이콘이 보통 표시됩니다. 이 확인은 시스템이 클라이언트의 로컬 네트워크 인터페이스 생성을 허용했다는 뜻일 뿐, 선택한 노드가 반드시 작동한다는 의미는 아닙니다. 시작 버튼을 누르자마자 중지되면 앱 로그를 열어 노드 필드, 도메인 확인, 포트 연결성과 코어 시작 결과를 확인하세요.

화면이 꺼진 뒤 시스템의 절전 정책이 백그라운드 실행을 제한할 수 있습니다. 연결을 장시간 유지해야 한다면 시스템 앱 관리에서 실제 필요에 맞게 클라이언트의 백그라운드 실행을 허용하고, 네트워크 전환 후 복구되는지도 관찰하세요. 기기마다 배터리 관리 메뉴의 이름은 다르므로 모든 권한을 무조건 켜기보다 클라이언트 프로세스가 시스템에 의해 중지되는지를 기준으로 판단해야 합니다. 전면에서만 사용할 경우 기본 배터리 정책을 유지하는 편이 리소스를 절약할 수 있습니다.

첫 실행 후 기본 점검

메인 화면에 들어간 직후 여러 고급 기능을 한꺼번에 켜지 마세요. 클라이언트가 설정을 저장할 수 있는지, 코어 파일을 호출할 수 있는지, 로컬 포트가 다른 프로그램에 점유되지 않았는지, 로그 창에 시작 기록이 남는지를 순서대로 확인합니다. 데스크톱에서는 먼저 기본 로컬 리스닝 주소를 유지해 LAN에 직접 노출되지 않도록 하세요. 그런 다음 설정 하나 또는 구독을 가져오고, 활성 노드를 선택한 뒤 마지막으로 시스템 프록시를 켭니다. 한 번에 하나의 변수만 바꿔야 문제가 어느 단계에서 생겼는지 알 수 있습니다.

Windows:
netstat -ano | findstr LISTENING

macOS / Linux:
lsof -nP -iTCP -sTCP:LISTEN

위 명령은 이 컴퓨터에서 리스닝 중인 포트를 확인하는 데 사용합니다. 클라이언트에서 포트가 이미 사용 중이라고 표시되면 설정에서 HTTP, SOCKS, API 등의 로컬 포트를 확인한 뒤 프로세스 목록으로 충돌하는 프로그램을 찾으세요. 정체를 모르는 시스템 프로세스를 함부로 종료하지 마세요. 사용하지 않는 포트로 클라이언트 포트를 변경하고 브라우저, 터미널 또는 다른 수동 프록시 앱의 포트도 함께 수정하는 편이 안전합니다.

구독 가져오기와 노드 관리

구독의 역할과 가져오기 순서

구독 주소는 노드 설정을 일괄적으로 가져오는 데 사용되며, 보통 이름 조정, 매개변수 업데이트와 만료된 노드 삭제도 담당합니다. 클라이언트 설치 패키지도, 고정된 단일 노드도 아닙니다. 가져올 때는 전체 주소를 복사해 클라이언트의 구독 그룹 또는 구독 설정에서 항목을 추가하고, 알아보기 쉬운 메모를 입력한 뒤 수동 업데이트를 한 번 실행하세요. 업데이트가 끝나면 서버 목록으로 돌아가 새 노드가 예상한 그룹에 있는지, 업데이트 로그에 해석 오류가 없는지 확인합니다.

v2rayN에서는 보통 먼저 구독 항목을 만든 뒤 업데이트를 실행합니다. v2rayNG와 v2flyNG는 메뉴 이름이 조금 다를 수 있지만 흐름은 같습니다. 주소에 쿼리 매개변수나 긴 인코딩 문자열이 포함되어 있다면 복사할 때 끝부분이 빠지지 않게 하세요. 메신저로 전달한 뒤 잘린 표시 텍스트를 그대로 사용해서도 안 됩니다. 구독은 민감한 설정이므로 필요한 클라이언트에만 저장하고, 스크린샷이나 공개 로그, 공유 문서에 넣지 마세요.

업데이트 성공, 해석 성공과 노드 사용 가능 여부는 서로 다릅니다

클라이언트에 가져오기가 완료되었다고 표시되어도 구독 내용이 다운로드되었다는 뜻일 뿐입니다. 목록에 노드가 나타나면 내용이 인식된 것이고, 특정 노드로 연결을 수립해야 현재 네트워크, 노드 매개변수와 코어 기능이 모두 조건을 충족했다는 뜻입니다. 문제를 확인할 때는 네트워크 요청이 유효한 내용을 반환했는지, 해석 후 노드가 생성되었는지, 활성 노드 시작 뒤 성공 또는 오류 로그가 명확히 남았는지 세 가지를 확인하세요. 이 셋을 섞으면 노드 문제인데도 구독 주소를 반복해서 수정하게 됩니다.

구독 업데이트에 실패하면 먼저 현재 기기의 네트워크 자체가 정상인지 확인하고, 시스템 날짜와 시간이 크게 어긋나지 않았는지 확인한 뒤 주소가 완전한지 검토하세요. 이미 만료된 프록시를 사용해 구독을 업데이트 중이라면 시스템 프록시를 잠시 끄거나 구독 설정에서 업데이트에 사용할 프록시 정책을 조정할 수 있습니다. 업데이트 후 노드 수가 바뀌지 않았다고 반드시 실패한 것은 아닙니다. 서버 내용이 그대로라면 목록도 변하지 않을 수 있으므로 업데이트 시간과 로그 결과를 기준으로 판단하세요.

그룹, 이름과 활성 노드

여러 구독을 사용한다면 출처마다 명확한 이름을 지정하고 모든 노드를 이름 없는 하나의 목록에 쌓지 마세요. 그룹은 업데이트 시 출처를 확인하고, 문제 발생 시 빠르게 전환하며, 정리할 때 다른 설정을 실수로 삭제하지 않도록 하는 세 가지 역할을 합니다. 노드 메모에는 서버가 제공한 지역이나 용도 정보를 남기는 것이 좋습니다. “노드 1”, “예비 2”처럼만 적지 마세요. 수동 설정은 별도 그룹에 두어 구독 업데이트로 덮어쓰거나 원격 항목과 섞이지 않게 하세요.

활성 노드는 현재 클라이언트가 주요 아웃바운드 연결을 만드는 데 사용하는 항목입니다. 노드를 선택한 뒤에는 목록에서 강조 표시만 된 것이 아니라 실제 활성 서버로 지정되었는지도 확인해야 합니다. UI에 따라 더블 클릭, 마우스 오른쪽 버튼 메뉴 또는 별도 명령으로 지정할 수 있습니다. 전환 후 상태 표시줄과 코어 로그를 확인해 아웃바운드 설정이 다시 로드되었는지 확인하세요. 목록 행만 선택하고 코어가 다시 로드되지 않았다면 실제 트래픽은 이전 노드를 계속 사용할 수 있습니다.

업데이트 정책과 설정 보존

자동 업데이트는 내용이 자주 바뀌는 구독에 적합하지만 간격을 지나치게 짧게 설정하지 마세요. 자주 새로 고친다고 노드 품질이 좋아지는 것은 아니며, 불필요한 요청이 늘고 수동으로 문제를 확인할 때 목록이 언제 바뀌었는지 판단하기 어려워집니다. 평소에는 적절한 주기로 자동 업데이트를 유지하고, 사용하기 전에 한 번 수동 업데이트를 실행하세요. 연결 문제가 발생하면 먼저 현재 설정을 테스트한 뒤 업데이트 여부를 결정해 노드 목록과 클라이언트 설정을 동시에 바꾸지 않도록 합니다.

구독 업데이트로 같은 이름의 노드가 교체되거나 원격에서 삭제된 항목이 사라질 수 있습니다. 특정 노드의 전송 매개변수를 로컬에서 수정했다면 먼저 독립 설정으로 복사하고 수정 이유를 기록하세요. 그렇지 않으면 다음 업데이트에서 원격 값으로 되돌아갈 수 있습니다. 클라이언트 전체를 이전하기 전에는 기본 제공 백업 또는 내보내기 기능으로 구독 그룹, 라우팅 설정과 환경 설정을 저장하세요. 노드 공유 텍스트만 복사해서는 클라이언트 전체 설정을 보존할 수 없습니다.

업데이트 후 모든 노드가 동시에 이상해졌다면 먼저 구독 내용, 클라이언트 코어와 로컬 네트워크를 확인하세요. 한 노드만 이상하다면 해당 항목의 매개변수나 서버 상태 문제일 가능성이 큽니다. 자세한 실패 유형은 사이트에서 “v2rayN 구독 업데이트 실패”를 검색해 관련 설명으로 이동할 수 있습니다. 이 장을 마치면 구독을 수동으로 업데이트하고, 노드 그룹을 명확히 관리하며, 활성 노드를 분명하게 전환하고, 로그로 가져오기와 연결 결과를 구분할 수 있어야 합니다.

시스템 프록시와 프록시 모드

로컬 리스닝과 시스템 프록시의 관계

코어가 시작되면 컴퓨터에 HTTP, SOCKS 등의 리스닝 포트를 만듭니다. 앱은 이 포트로 요청을 전달하고, 클라이언트는 라우팅 규칙에 따라 직접 연결, 프록시 또는 차단을 선택합니다. 시스템 프록시는 시스템 설정을 따르는 앱에 요청을 어디로 보낼지 알려주는 메커니즘이며, 그 자체가 프로토콜 연결을 처리하지는 않습니다. 클라이언트를 종료한 뒤에도 시스템에 이전 프록시 주소가 남아 있으면 브라우저가 로컬 포트에 연결하지 못해 인터넷에 접속할 수 없습니다. 따라서 종료할 때는 클라이언트가 시스템 설정을 정상적으로 복구하게 해야 합니다.

대부분의 데스크톱 브라우저는 시스템 프록시를 읽지만 명령줄 도구, 일부 개발 환경, 게임과 독립적인 네트워크 구성 요소는 이를 무시할 수 있습니다. 브라우저가 작동한다고 해서 모든 앱의 트래픽이 인계되었다고 볼 수 없고, 터미널에서 작동하지 않는다고 해서 노드에 문제가 있다는 뜻도 아닙니다. 앱 유형에 따라 시스템 프록시, 앱 내부의 수동 프록시 또는 TUN을 선택해야 합니다. 관련 점검 방법은 브라우저와 터미널 프록시 문제 해결을 참고하세요.

전역, 규칙과 직접 연결 모드

전역 모드는 보통 인계 조건을 충족하는 대부분의 트래픽을 프록시 아웃바운드로 보냅니다. 노드와 로컬 리스닝이 정상인지 짧게 확인할 때 적합합니다. 규칙 모드는 도메인, IP, 포트, 프로세스 또는 규칙 집합에 따라 출구를 결정하며 일상적인 사용에 주로 활용됩니다. 직접 연결 모드는 인계된 트래픽을 로컬 네트워크로 바로 보내므로 비교 테스트나 프록시 경로를 잠시 끌 때 사용합니다. 클라이언트마다 모드 이름의 번역이 다를 수 있으므로 실제 아웃바운드 동작을 기준으로 판단하세요.

처음 문제를 확인할 때는 전역 모드로 전환해 보세요. 전역 모드는 작동하지만 규칙 모드가 작동하지 않는다면 라우팅 매칭이나 DNS 판단에 문제가 있을 가능성이 큽니다. 둘 다 작동하지 않으면 노드, 코어와 로컬 포트를 다시 확인하세요. 직접 연결 모드도 이상하다면 시스템 프록시 잔류 설정, 앱 자체 설정 또는 로컬 네트워크가 원인일 수 있습니다. 이 비교 방법은 범위를 빠르게 좁혀 주지만, 규칙 설계 대신 전역 모드를 장기간 사용하는 것은 권장하지 않습니다.

수동 프록시 앱에 입력하는 방법

수동으로 프록시를 설정해야 하는 앱에는 클라이언트가 실제로 리스닝 중인 주소와 포트를 입력하세요. 이 컴퓨터에서 실행되는 앱은 보통 127.0.0.1을 사용하며, 프로토콜 유형은 포트와 일치해야 합니다. SOCKS 포트를 HTTP 프록시만 허용하는 입력란에 넣어서는 안 됩니다. 클라이언트의 기본 포트를 변경했다면 모든 수동 설정도 함께 업데이트하세요. LAN 기기는 자체 127.0.0.1로 데스크톱 클라이언트를 가리킬 수 없습니다. 클라이언트가 실행 중인 컴퓨터의 LAN 주소를 사용하고 LAN 공유를 명시적으로 켜야 합니다.

HTTP 프록시 환경 변수 예시:
set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809

macOS / Linux 현재 터미널 세션:
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

위 변수는 해당 변수를 읽는 프로그램과 현재 범위에만 영향을 줍니다. 터미널을 닫은 뒤에도 유지되는지는 shell 설정 파일에 기록했는지에 따라 달라집니다. 문제를 확인할 때는 먼저 임시로 설정해 효과를 확인한 뒤 영구 적용 여부를 결정하세요. 삭제할 때는 운영체제에 맞는 변수 삭제 방법을 사용해 클라이언트가 종료된 후에도 터미널이 닫힌 로컬 포트로 요청을 보내지 않도록 하세요. SOCKS 프록시는 앱이 프록시를 통해 도메인을 확인하는지 여부도 관련되므로 해당 앱의 옵션을 확인해야 합니다.

LAN 공유의 범위와 주의점

LAN 공유를 켜면 같은 네트워크의 다른 기기가 클라이언트의 리스닝 포트에 접근할 수 있습니다. 활성화하기 전에 리스닝 주소, 시스템 방화벽과 현재 네트워크 환경을 확인하세요. 신뢰할 수 있는 가정용 네트워크와 공용 네트워크에는 서로 다른 정책을 적용해야 하며, 공용 네트워크에서 임시 테스트를 위해 리스닝 범위를 넓혀서는 안 됩니다. 공유 기기에는 클라이언트가 실행 중인 컴퓨터의 LAN 주소와 해당 포트를 프록시 서버로 입력해야 합니다. 컴퓨터가 절전 모드에 들어가거나 네트워크를 전환하거나 주소가 바뀌면 공유 연결이 끊깁니다.

LAN 공유는 로컬 프록시 진입점만 제공하며 다른 기기의 시스템 네트워크 설정을 자동으로 바꾸지는 않습니다. 각 기기에서 앱 프록시 또는 시스템 프록시를 별도로 설정해야 합니다. 같은 네트워크의 기기에서 포트에 연결할 수 없다면 먼저 호스트 로컬에서 포트가 리스닝 중인지 확인한 다음 방화벽 인바운드 규칙과 기기 간 통신 허용 여부를 점검하세요. 포트에는 연결되지만 대상에 접근할 수 없다면 클라이언트 로그와 라우팅 결과를 계속 확인하세요. 포트에 도달할 수 있다는 사실과 아웃바운드 연결 성공을 혼동하지 마세요.

로그로 트래픽이 클라이언트에 들어오는지 확인

프록시가 적용되었는지 확인할 때는 웹페이지 결과만 보는 것보다 클라이언트 연결 로그를 관찰하는 편이 가장 직접적입니다. 캐시되지 않은 새 요청을 열면 로그에 해당 도메인, 대상 주소, 인바운드 유형과 최종 아웃바운드가 나타나야 합니다. 기록이 전혀 없다면 앱 트래픽이 클라이언트에 들어오지 않은 것입니다. 기록은 있지만 직접 연결로 처리되었다면 규칙이 직접 연결로 매칭된 것입니다. 프록시에 들어온 뒤 연결에 실패한다면 노드나 원격 핸드셰이크를 계속 점검하세요. 로그를 통해 “인계되지 않음”과 “인계 후 실패”를 서로 다른 경로로 구분할 수 있습니다.

라우팅과 규칙 설계

라우팅 규칙이 해결하는 문제

라우팅은 트래픽이 클라이언트에 들어온 뒤 대상 특성에 따라 사용할 출구를 결정하는 과정입니다. 일반적인 출구에는 프록시, 직접 연결과 차단이 있습니다. 규칙은 도메인, IP, 포트, 네트워크 유형, 프로세스 또는 미리 정의된 규칙 집합과 매칭할 수 있습니다. 목표는 규칙을 많이 작성하는 것이 아니라 자주 발생하는 트래픽이 안정적이고 설명 가능한 결과를 얻도록 하는 것입니다. 규칙이 지나치게 겹치면 유지 관리 비용이 늘고 매칭 순서도 판단하기 어려워집니다.

기본 규칙은 보통 명확한 경계에서 시작합니다. 컴퓨터 자체와 LAN 주소는 직접 연결하고, 프록시가 필요한 도메인이나 규칙 집합은 프록시로 보내며, 나머지는 예측 가능한 최종 규칙으로 처리합니다. 앞의 조건과 일치하지 않는 요청은 모두 최종 규칙에 도달하므로 이 규칙이 매우 중요합니다. 기본 출구가 명확하지 않으면 같은 규칙도 클라이언트나 버전에 따라 다르게 작동할 수 있습니다.

규칙 순서와 최초 매칭

대부분의 라우팅 시스템은 규칙을 순서대로 확인하고 처음 일치한 결과를 적용합니다. 더 구체적인 범위의 규칙은 더 포괄적인 규칙보다 앞에 배치해야 합니다. 예를 들어 특정 하위 도메인은 프록시를 사용하지만 전체 상위 도메인은 보통 직접 연결한다면 하위 도메인 규칙이 먼저 와야 합니다. 포트, 프로세스와 도메인 조건을 조합할 때는 조건을 모두 충족해야 하는지 하나만 충족해도 되는지 확인하세요. 규칙 문구만 보지 말고 클라이언트의 필드 관계 구현 방식도 함께 확인해야 합니다.

규칙을 수정한 뒤에는 설정을 다시 로드하고 로그에서 매칭된 항목을 확인하세요. 요청이 잘못된 출구로 나가면 실제 도메인과 확인된 주소를 기록한 뒤 어떤 규칙과 일치했는지 점검합니다. 곧바로 더 포괄적인 규칙을 추가하지 마세요. 새 규칙이 기존 조건을 가릴 수 있습니다. 먼저 정확한 규칙 하나로 방향을 검증한 다음 도메인 접미사, IP 대역 또는 규칙 집합으로 확장할지 판단하세요.

도메인 매칭과 IP 매칭의 차이

도메인 규칙은 라우팅 단계에서 클라이언트가 대상 도메인을 볼 수 있어야 작동합니다. 앱이 로컬에서 먼저 도메인을 확인하고 IP만 프록시에 전달한다면 도메인 조건을 사용할 수 없을 수 있습니다. 반대로 IP 규칙은 확인 결과와 주소 소속에 의존하므로 동적 주소를 사용하는 콘텐츠 서비스에서는 자주 바뀔 수 있습니다. 라우터의 도메인 정책, DNS 설정과 인바운드 프로토콜이 함께 가시 정보에 영향을 주므로 도메인 규칙이 작동하지 않을 때 철자만 확인해서는 부족합니다.

도메인 접미사 규칙은 구조가 안정적인 여러 하위 도메인을 묶을 때 적합하고, 전체 도메인 규칙은 정확한 예외를 지정할 때 적합합니다. IP 대역 규칙은 올바른 CIDR 표기를 사용해야 하며, 접두사 길이가 범위를 결정합니다. 너무 넓게 쓰면 관련 없는 트래픽까지 매칭될 수 있습니다. LAN의 사설 주소는 보통 직접 연결해 내부 서비스가 외부 경로로 우회하지 않도록 해야 합니다. 포트 규칙은 프로토콜 경계가 명확한 서비스에 적합하지만, 최신 앱은 여러 포트를 함께 사용할 수 있으므로 하나의 포트만으로 전체 트래픽을 판단해서는 안 됩니다.

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

이 예시는 사설 주소는 직접 연결하고 지정한 테스트 도메인은 프록시로 보내는 일반적인 필드 구조를 보여줍니다. 실제 클라이언트는 그래픽 UI로 설정을 생성할 수 있으며, 아웃바운드 태그도 클라이언트에 이미 존재하는 이름과 일치해야 합니다. 예시에 사용한 예약 테스트 도메인은 문법 설명용입니다. 이 조각을 전체 설정에 병합하기 전에는 현재 규칙을 내보내거나 백업하고 JSON의 쉼표, 괄호와 배열 계층이 올바른지 확인하세요.

DNS와 라우팅을 함께 봐야 하는 이유

DNS는 도메인에서 주소를 얻는 방식을 결정하고, 라우팅은 요청이 어느 출구로 나갈지 결정합니다. DNS 조회와 이후 연결이 서로 다른 경로를 사용하면 한 네트워크에 적합한 주소를 확인한 뒤 실제 연결은 다른 네트워크에서 시도하는 상황이 생길 수 있습니다. 규칙 모드는 이상하지만 전역 모드는 정상이라면 도메인 정책, DNS 서버 선택, 캐시 결과와 프록시 측에서 요청을 확인하는지를 점검하세요. 설정을 바꾼 뒤에도 기존 캐시가 잠시 판단에 영향을 줄 수 있습니다.

DNS, 라우팅 규칙과 프록시 모드를 동시에 크게 변경하지 마세요. 우선 기본 DNS를 유지하고 정확한 도메인 규칙으로 분할 라우팅을 확인하는 편이 안전합니다. 라우팅이 적용된 뒤 필요에 따라 DNS를 조정하세요. 문제가 발생하면 원래 도메인, 확인된 주소, 매칭된 규칙과 최종 아웃바운드의 네 가지 정보를 기록하세요. 이 정보가 모두 있으면 오류가 확인, 매칭, 연결 중 어느 단계에 있는지 대체로 판단할 수 있습니다.

유지 관리 가능한 규칙 계층 만들기

장기적으로 사용할 규칙은 네 계층으로 나눌 수 있습니다. 가장 앞에는 우선 처리해야 할 예외를 두고, 그다음 LAN과 컴퓨터 자체의 서비스를 배치하며, 주요 도메인이나 규칙 집합을 추가하고, 마지막에 기본 출구를 설정합니다. 모든 사용자 지정 규칙에는 명확한 이름과 용도 설명을 붙이세요. 단기 테스트 규칙은 문제가 해결된 뒤 바로 삭제해 오랜 시간이 지나도 트래픽에 영향을 주지 않게 해야 합니다. 팀이나 여러 기기에서 사용한다면 최종 설정 파일만 보관하지 말고 규칙을 변경한 이유도 기록하세요.

규칙 수가 늘어나면 중복 조건, 절대 매칭되지 않는 뒤쪽 규칙과 더 이상 사용하지 않는 도메인을 정기적으로 점검하세요. 특정 앱에 문제가 생기면 전체 규칙을 재배열하기보다 해당 앱을 대상으로 한 최소 테스트 규칙을 먼저 만드세요. 분할 라우팅을 제대로 이해했다는 기준은 규칙표가 긴 것이 아니라, 로그를 통해 특정 요청이 왜 직접 연결, 프록시 또는 차단으로 처리되었는지 설명하고 수정 후 예상 결과를 검증할 수 있는지에 있습니다.

TUN 모드와 전체 트래픽 인계

TUN과 시스템 프록시의 근본적인 차이

시스템 프록시는 앱이 운영체제 설정을 직접 읽어야 하지만, TUN은 가상 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 수신합니다. 시스템 프록시를 무시하는 앱, 독립적인 네트워크 구성 요소 또는 데스크톱 트래픽을 통합 처리해야 하는 경우 TUN이 더 완전하게 적용되는 편입니다. 하지만 적용 범위가 넓어지는 만큼 설정도 복잡해집니다. DNS, 라우팅 테이블, 가상 네트워크 어댑터 권한과 다른 네트워크 프로그램이 모두 결과에 영향을 줄 수 있습니다. 시스템 프록시로 해결할 수 있는 상황이라면 TUN을 기본으로 켤 필요는 없습니다.

TUN은 “더 빠르게 만드는” 스위치가 아니라 트래픽이 클라이언트로 들어오는 방식을 바꾸는 기능입니다. 노드 연결 품질, 프로토콜 핸드셰이크와 원격 경로는 TUN을 켠다고 자동으로 개선되지 않습니다. 시스템 프록시 모드에서 노드 연결 자체가 실패한다면 TUN으로 바로 전환해도 새로운 변수만 늘어날 가능성이 큽니다. 먼저 시스템 프록시로 노드와 코어를 확인한 뒤, 실제로 인계되지 않는 앱이 있을 때 TUN을 켜는 것이 올바른 순서입니다.

활성화 전 준비

TUN을 켜기 전에는 라우팅 테이블을 수정하거나 가상 네트워크 어댑터를 만드는 다른 네트워크 도구를 끄고, 현재 DNS와 시스템 프록시 상태를 기록하며, 클라이언트가 가상 인터페이스를 만들 권한을 갖췄는지 확인하세요. Windows에서는 가상 네트워크 어댑터 드라이버와 관리자 권한을, macOS에서는 네트워크 확장 및 관련 시스템 확인을, Linux에서는 TUN 장치 접근과 라우팅 기록 조건을 확인해야 합니다. 권한이 부족하면 보통 시작 로그에 인터페이스 생성 또는 라우팅 설정 실패가 명확히 나타납니다.

처음 테스트할 때는 규칙을 단순하게 유지하고 이미 작동이 확인된 활성 노드를 우선 사용하세요. 시작 후에는 가상 인터페이스가 생성되었는지, 기본 또는 정책 라우팅이 예상대로 기록되었는지, DNS 조회가 설정한 경로로 들어가는지 세 가지를 확인합니다. 클라이언트 스위치는 켜져 있지만 인터페이스가 없다면 권한과 드라이버를, 인터페이스는 있지만 트래픽이 없다면 라우팅 테이블을, 트래픽은 들어오지만 도메인이 실패한다면 DNS 설정을 점검하세요.

엄격한 라우팅, 자동 라우팅과 우회 범위

자동 라우팅은 보통 클라이언트가 인계해야 할 시스템 경로를 자동으로 생성해 수동 설정을 줄입니다. 엄격한 라우팅은 트래픽이 가상 인터페이스를 우회할 가능성을 낮추지만 LAN 서비스, 가상 머신, 컨테이너 또는 기업 네트워크 정책과 충돌할 수 있습니다. 엄격한 정책을 켜기 전에 프린터, 파일 공유, 개발 서비스와 로컬 관리 페이지를 직접 연결로 유지해야 하는지 확인하고, 사설 주소에 명확한 우회 또는 직접 연결 규칙을 지정하세요.

LAN 접근에 문제가 생겼다고 TUN 설정 전체를 바로 끄지 마세요. 먼저 사설 주소가 잘못 프록시로 전송되는지, LAN 도메인이 부적절한 DNS로 확인되는지, 시스템 방화벽이 가상 인터페이스를 다른 네트워크로 취급하는지 점검하세요. 가상 머신과 컨테이너는 호스트 NAT, 브리지 네트워크 또는 독립 인터페이스 중 무엇을 사용하는지도 확인해야 합니다. 네트워크 토폴로지에 따라 트래픽이 호스트의 TUN을 통과하는 방식이 달라집니다.

일반적인 충돌을 찾는 방법

TUN을 켠 뒤 인터넷이 완전히 끊기면 먼저 TUN을 중지해 기본 네트워크가 복구되는지 확인한 다음, 시작 로그에서 마지막으로 성공한 단계를 찾으세요. 중지한 뒤에도 문제가 계속되면 클라이언트가 시스템 DNS, 기본 라우팅과 시스템 프록시를 복구했는지 점검합니다. IP에는 접근되지만 도메인에 접근할 수 없다면 DNS를, LAN만 사용할 수 없다면 사설 주소 라우팅을, 특정 앱만 실패한다면 프로세스 자체의 네트워크 스택, IPv4와 IPv6 선택 및 특정 인터페이스 바인딩 여부를 확인하세요.

시스템 절전, 네트워크 전환과 클라이언트 비정상 종료로 인해 가상 인터페이스 상태가 실제 연결과 동기화되지 않을 수 있습니다. 복구된 뒤에는 먼저 연결을 중지하고 인터페이스와 라우팅이 정리될 때까지 기다린 다음 다시 시작하세요. 스위치를 빠르게 연속해서 전환하지 마세요. 시스템 네트워크 서비스가 변경 사항을 적용할 시간이 필요합니다. 매번 재현된다면 시작 전후의 라우팅 테이블과 로그를 보관해 일정하게 실패하는 단계를 찾고, 무작위 재시도를 반복하지 마세요.

Windows 라우팅 확인:
route print

macOS 기본 라우팅 확인:
route -n get default

Linux 라우팅 확인:
ip route

이 명령은 시스템 라우팅을 확인할 뿐 네트워크를 변경하지 않습니다. TUN을 켜기 전후로 비교할 때는 기본 라우팅, 가상 인터페이스에 해당하는 라우팅과 사설 네트워크 대역의 경로를 확인하세요. 필요한 인터페이스와 네트워크 대역 정보만 기록하고, 로그를 공유하기 전에는 구독 주소, 노드 인증 정보와 로컬 기기 식별자를 삭제하세요. 이 장을 마치면 문제가 인터페이스 미생성, 라우팅 미인계, DNS 불일치 또는 잘못된 규칙 출구 중 어디에 해당하는지 판단할 수 있어야 합니다.

일상적인 관리, 백업과 문제 해결

안정적인 업데이트 주기 만들기

클라이언트, 코어와 구독은 서로 다른 세 가지 업데이트 경로입니다. 클라이언트 업데이트는 UI, 설정 마이그레이션과 시스템 통합에 영향을 줄 수 있고, 코어 업데이트는 프로토콜 구현과 라우팅 동작에 영향을 줄 수 있으며, 구독 업데이트는 주로 노드 내용을 바꿉니다. 일상적인 관리에서는 각각을 따로 기록하고 문제가 발생했다고 모든 구성 요소를 한꺼번에 업데이트하지 마세요. 한 번에 한 계층만 변경하고 시작, 연결과 분할 라우팅을 확인한 뒤 다음 단계로 진행해야 문제가 되돌아왔을 때 원인을 찾을 수 있습니다.

클라이언트를 업데이트하기 전 UI에 표시된 변경 사항을 읽고 현재 운영체제와 설치 분기가 계속 호환되는지 확인하세요. 업데이트 후에는 이전 설정 백업을 바로 삭제하지 말고 구독 목록, 활성 노드, 라우팅 규칙, 로컬 포트, 시스템 프록시와 TUN을 먼저 검증합니다. 새 UI가 기본 설정을 다시 만들었다면 포트와 아웃바운드 태그를 중점적으로 확인하세요. 수동 프록시 앱과 사용자 지정 규칙이 이전 값을 계속 참조할 수 있습니다.

노드만 복사하지 말고 무엇을 백업해야 할까

전체 백업에는 최소한 구독 그룹, 수동 노드, 사용자 지정 라우팅, DNS 설정, 포트 환경 설정과 클라이언트 공통 옵션이 포함되어야 합니다. 단일 노드 공유 텍스트에는 보통 시스템 프록시 모드, 창 설정, 자동 업데이트 일정과 전체 라우팅 규칙이 들어 있지 않습니다. 클라이언트가 제공하는 백업 또는 내보내기 기능을 우선 사용하고 백업 파일은 관리되는 위치에 보관하세요. 복원할 때는 실행 중인 코어를 먼저 중지해 설정 파일이 동시에 기록되지 않게 해야 합니다.

백업은 파일이 존재하는지가 아니라 실제로 복구 가능한지를 기준으로 판단해야 합니다. 백업을 만든 뒤에는 기본 설정에 영향을 주지 않는 환경에서 내용 구조를 확인해 구독과 라우팅 파일이 포함되어 있는지 확인할 수 있습니다. 여러 플랫폼으로 이전할 때 시스템 경로, 권한 또는 UI 분기와 관련된 파일 전체를 그대로 덮어쓰지 마세요. 공통 설정을 가져온 뒤 시스템 프록시, 시작 시 자동 실행과 TUN 권한을 별도로 다시 설정하는 편이 안전합니다.

로그를 읽는 순서

로그는 마지막 줄만 보지 말고 처음 나타난 명확한 오류부터 확인해야 합니다. 코어 시작에 실패하면 이후에 포트를 사용할 수 없음, 연결 거부 또는 상태 중지와 같은 파생 정보가 연속해서 나타나는 경우가 많습니다. 설정 로드, 리스닝 포트, DNS 초기화와 아웃바운드 연결 과정에서 처음 실패한 지점을 찾은 뒤 문법, 포트, 권한 또는 네트워크 문제인지 판단하세요. 사이트의 로그로 설정 오류 찾기에서 일반적인 오류와 처리 방법을 확인할 수 있습니다.

설정 문법 오류에는 필드 이름이나 행·열 위치가 함께 표시되는 경우가 많습니다. 포트 점유 문제는 리스닝 주소를 알려 주고, 권한 문제는 쓰기 디렉터리, 인터페이스 생성 또는 시스템 네트워크 설정 변경 과정에서 주로 발생합니다. 노드 핸드셰이크 실패는 아웃바운드 연결 단계에 나타나는 경우가 많습니다. 로그에 도메인 확인 실패가 표시되면 클라이언트 자체 확인인지, 프록시 측 확인인지, 시스템 확인인지 구분해야 합니다. 오류 한 줄만 잘라내지 말고 앞뒤 초기화 맥락을 함께 보관하세요.

증상별 문제 해결 트리 만들기

클라이언트를 시작할 수 없음: 실행 환경, 설치 경로, 디렉터리 권한과 손상된 설정을 확인합니다. 클라이언트는 시작되지만 코어가 실패함: 포트 점유, 설정 필드와 코어 로그를 확인합니다. 코어는 시작되지만 웹 요청 기록이 없음: 시스템 프록시, 앱 설정 또는 TUN 인계를 확인합니다. 로그에는 요청이 있지만 잘못된 출구로 나감: 라우팅 매칭과 DNS를 확인합니다. 요청이 프록시에 들어갔지만 연결 실패: 같은 그룹의 다른 노드로 비교하고 노드 매개변수와 현재 네트워크를 확인합니다.

앱 하나만 이상할 때는 클라이언트 전체를 초기화하지 마세요. 먼저 해당 앱이 시스템 프록시를 따르는지, DNS를 캐시하는지, 독립적인 네트워크 구성 요소를 사용하는지, 자체 프록시가 설정되어 있는지 확인합니다. 노드 하나만 이상할 때도 전체 구독을 삭제하지 마세요. 같은 그룹의 다른 노드로 바꿔 보면 단일 노드 문제인지 클라이언트 문제인지 구분할 수 있습니다. 모든 노드가 동시에 이상할 때 구독 변경, 코어 상태, 로컬 네트워크와 시스템 시간을 확인하세요.

종료, 절전과 네트워크 전환

클라이언트를 종료하기 전에는 코어를 정상적으로 중지하고 시스템 네트워크 설정을 복구하게 하세요. 프로세스를 강제로 종료하면 시스템 프록시 주소, 가상 인터페이스 또는 임시 라우팅이 남을 수 있습니다. 종료 후 인터넷에 연결되지 않으면 먼저 시스템 프록시가 여전히 로컬 포트를 가리키는지 확인한 다음 TUN 인터페이스와 DNS를 점검하세요. 상태를 확인하기 전 여러 네트워크 구성 요소를 동시에 초기화하지 마세요. 어느 항목이 연결을 복구했는지 알 수 없게 됩니다.

절전 모드에서 복구하거나 유선·무선 네트워크 사이를 전환한 뒤에는 기존 노드 연결, DNS 캐시와 LAN 주소가 무효화될 수 있습니다. 먼저 클라이언트가 자동으로 다시 연결하는지 관찰하고 새 요청을 보내 로그를 확인하세요. 상태가 이전 연결에 머물러 있다면 코어를 중지한 뒤 다시 시작합니다. 복구 실패가 반복되면 네트워크 전환 전후의 인터페이스와 라우팅 차이를 기록하고 동시에 켜는 자동 네트워크 기능을 줄이세요.

안정적인 관리의 기본 조건은 복구 가능한 설정 백업, 명확한 구독 출처와 그룹, 클라이언트와 코어를 분리한 업데이트, 언제든 찾을 수 있는 로그 진입점, 시스템 프록시와 TUN 복구 방법입니다. 이 조건을 갖추면 대부분의 문제를 기존 설치에서 찾아낼 수 있으므로 재설치를 첫 번째 선택으로 삼을 필요가 없습니다.

고급 설정과 장기 학습 경로

작동하는 수준에서 동작을 설명할 수 있는 수준으로

고급 단계의 목표는 스위치를 더 많이 켜는 것이 아니라 앱에서 아웃바운드까지 요청의 전체 경로를 설명하는 것입니다. 앱은 시스템 프록시, 수동 프록시 또는 TUN을 통해 클라이언트에 들어오고, 인바운드는 도메인을 유지하거나 대상 IP를 얻습니다. DNS는 설정된 경로에 따라 확인되며, 라우팅 규칙은 직접 연결, 프록시 또는 차단을 선택합니다. 코어는 노드 프로토콜에 따라 아웃바운드 연결을 만들고 로그는 각 단계의 결과를 기록합니다. 이 경로가 명확하면 복잡한 문제도 제한된 단계로 나눌 수 있습니다.

먼저 매일 사용하는 앱 하나를 관찰 대상으로 정하고 시스템 프록시 모드에서 인바운드 유형, 도메인, 매칭 규칙과 아웃바운드를 기록하세요. 그런 다음 TUN으로 전환해 경로가 어떻게 달라지는지 비교합니다. 실험 중에는 노드를 바꾸지 않아 네트워크 변동을 모드 차이로 잘못 판단하지 않도록 하세요. 많은 규칙을 한꺼번에 가져오는 것보다 완전한 비교를 한 번 수행하는 편이 더 확실한 이해를 만드는 데 도움이 됩니다.

인바운드, 아웃바운드와 태그 이해

인바운드는 로컬 HTTP, SOCKS 또는 TUN처럼 클라이언트가 트래픽을 받는 방식을 정의합니다. 아웃바운드는 프록시 노드, 직접 연결 또는 차단처럼 트래픽이 최종적으로 나가는 방식을 정의합니다. 태그는 라우팅 규칙이 이러한 객체를 참조할 수 있게 합니다. 사용자 지정 설정에서 흔히 발생하는 오류는 규칙의 아웃바운드 태그가 실제 설정과 일치하지 않거나 여러 인바운드가 같은 포트를 리스닝하는 경우입니다. 생성된 설정을 읽을 때는 먼저 인바운드 목록과 아웃바운드 목록을 찾고, 그다음 라우팅이 둘을 어떻게 연결하는지 확인하세요.

그래픽 클라이언트는 일부 태그와 포트를 자동으로 관리합니다. 전체 설정을 수동으로 수정한 뒤 UI에서 다시 저장하면 관련 필드가 재생성될 수 있으므로 “클라이언트가 관리하는 설정”과 “사용자 지정 조각”을 구분해야 합니다. 그래픽 UI에서 가능한 일반 설정은 UI를 우선 사용하세요. 더 세밀한 조건이 필요할 때만 사용자 지정 설정을 편집하고 수정 전 버전을 보관합니다. 코어 시작에 실패하면 설정 오류 로그 확인 방법을 참고하세요.

최소 실험 설정

새 규칙을 테스트할 때는 검증된 노드 하나, 인계 방식 하나, 정확한 규칙 하나와 명확한 대상 하나로 최소 조건을 구성하세요. 요청이 예상대로 매칭되는지 먼저 확인한 뒤 도메인 접미사, 규칙 집합 또는 프로세스 조건을 단계적으로 추가합니다. 최소 설정도 작동하지 않는데 DNS와 라우팅 옵션을 더 추가하면 문제 범위만 넓어집니다. 실험마다 변경 항목, 예상 결과, 실제 로그와 되돌리는 방법을 기록하세요.

{
  "type": "field",
  "domain": [
    "full:api.example.test"
  ],
  "network": "tcp",
  "outboundTag": "proxy"
}

이 규칙은 지정한 테스트 도메인의 TCP 트래픽만 매칭해 proxy라는 이름의 아웃바운드로 보냅니다. 실제로 사용하기 전에는 해당 아웃바운드 태그가 존재하는지, 클라이언트 코어가 해당 필드를 지원하는지 확인하고, 더 포괄적인 규칙보다 앞에 배치해야 합니다. 검증이 끝난 뒤 하위 도메인까지 포함하려면 접미사 규칙으로 명확히 변경하세요. 처음부터 범위가 지나치게 넓은 조건을 사용하지 마세요.

성능은 반복 가능한 비교를 기준으로 판단하세요

연결 환경은 로컬 네트워크, 노드 경로, 프로토콜 설정, DNS, 동시 연결 수와 앱 동작의 영향을 함께 받습니다. 특정 설정이 성능을 개선했는지 판단하려면 노드와 대상을 고정하고 변경 전후를 각각 테스트한 뒤 연결 수립과 지속 전송을 여러 차례 관찰하세요. 한 번의 페이지 로딩 속도는 캐시의 영향을 받기 쉬우므로 안정적인 결론으로 삼을 수 없습니다. 클라이언트 UI의 실시간 상태 역시 당시 조건만 반영하므로 장기적인 점수로 사용하기 어렵습니다.

연결 수립이 느리다면 먼저 DNS 대기, TCP 연결, TLS 또는 프로토콜 핸드셰이크를 구분하세요. 연결 후 전송이 불안정하다면 패킷 손실, 네트워크 전환과 노드 경로를 관찰합니다. 규칙 모드에서만 느리다면 DNS와 규칙 집합을 확인하고, TUN에서만 느리다면 가상 인터페이스, MTU와 중복 인계 여부를 점검하세요. 증상마다 해당 계층이 다르므로 모든 원인을 클라이언트 하나로 돌리면 실제 원인을 놓치게 됩니다.

여러 기기에서 설정을 일관되게 유지하는 방법

데스크톱과 Android에서 같은 구독 출처를 사용할 수 있지만 모든 클라이언트 환경 설정이 자동으로 동기화된다고 가정해서는 안 됩니다. 구독은 노드를 배포할 뿐이며 라우팅 규칙, DNS, 시스템 프록시와 TUN은 별도로 설정해야 할 수 있습니다. 여러 기기를 관리할 때는 먼저 사설 주소 직접 연결, 지정 도메인 프록시, 나머지는 기본 출구처럼 공통 정책을 정한 뒤 각 클라이언트의 기능에 맞춰 구현하세요. 특정 플랫폼의 경로나 프로세스 이름에 의존하는 규칙을 다른 플랫폼에 그대로 복사하지 마세요.

v2rayN, v2rayNG와 v2flyNG는 메뉴 구조와 코어 체계가 서로 다릅니다. 이전할 때는 먼저 프로토콜 필드가 완전한지 비교한 뒤 라우팅과 DNS를 다시 구성하세요. 데스크톱의 LAN 공유, 터미널 환경 변수와 시작 시 자동 실행 설정은 Android 설정에 해당하지 않습니다. Android의 시스템 연결 승인과 백그라운드 배터리 정책도 데스크톱 설정으로 대신할 수 없습니다. 설정 파일을 한 글자까지 동일하게 맞추기보다 정책을 일관되게 유지하는 편이 현실적입니다.

권장 학습 순서

1단계에서는 구독, 활성 노드, 시스템 프록시와 로그를 익힙니다. 2단계에서는 전역 모드와 규칙 모드를 비교하는 방법을 익힙니다. 3단계에서는 정확한 도메인 규칙을 작성하고 최초 매칭을 설명할 수 있어야 합니다. 4단계에서는 DNS와 라우팅의 관계를 이해합니다. 5단계에서 TUN을 켜고 가상 인터페이스와 시스템 라우팅을 분석합니다. 마지막으로 전체 설정 구조, 태그 참조와 여러 기기 정책을 학습하세요. 각 단계마다 작동하는 기준 설정을 하나씩 보관해야 합니다.

새 용어가 나오면 용어집을 확인하고, 처음 연결 과정을 다시 진행해야 한다면 빠른 시작 튜토리얼로 돌아가세요. 세 클라이언트의 용도를 비교할 때는 클라이언트 비교를 확인하면 됩니다. 시스템 문제는 해당 플랫폼 문서를 우선 읽으세요. 시작 직후 종료, 시스템 프록시 미적용과 코어 설정 오류에는 각각 별도의 문제 해결 경로가 있습니다. 지식을 계층별로 정리하면 문제가 생길 때마다 흩어진 답을 처음부터 검색하는 일을 피할 수 있습니다.

가이드를 마친 뒤 확인할 수 있는 역량

전체 장을 마치면 플랫폼에 맞는 클라이언트와 설치 패키지를 선택하고, 구독을 독립적으로 가져오고 업데이트하며, 활성 노드를 명확히 지정할 수 있어야 합니다. 또한 시스템 프록시와 TUN을 구분하고, 로그로 트래픽이 클라이언트에 들어오는지 확인하며, 예외·사설 주소·주요 규칙·기본 출구를 포함한 라우팅 계층을 설계하고, 업데이트 전에 설정을 백업할 수 있어야 합니다. 무엇보다 문제를 실행 환경, 코어, 노드, 인계, DNS, 라우팅 또는 시스템 네트워크 중 하나의 계층으로 분류할 수 있어야 합니다.

다음에 연결 문제가 발생하면 먼저 현재 상태를 보존하고 다섯 가지 질문에 답하세요. 클라이언트가 안정적으로 실행되는가, 코어가 정상적으로 리스닝하는가, 앱 트래픽이 들어오는가, 라우팅은 어느 출구를 선택했는가, 아웃바운드 연결은 어느 단계에서 실패했는가. 이 다섯 가지 답만으로도 보통 다음 조치를 결정할 수 있습니다. 클라이언트를 다시 설치해야 한다면 다운로드 페이지에서 현재 플랫폼을 선택하세요. 설치는 완료했지만 조작 방법이 익숙하지 않다면 빠른 튜토리얼로 돌아가 최소한의 작동 설정을 다시 만드세요.