V2Ray 입문부터 고급 활용까지: 설치·구독·트래픽 분할·TUN

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

코어는 연결을 담당하고 클라이언트는 조작 화면을 제공합니다

V2Ray는 하나의 고정된 설치 프로그램이 아니라 프로토콜, 전송 방식, 라우팅과 연결 관리 기능을 포함하는 기술 체계입니다. 실제로 사용할 때 코어는 설정을 읽고 네트워크 연결을 만들며, 그래픽 클라이언트는 구독 가져오기, 노드 전환, 시스템 프록시와 로그 확인 같은 작업을 클릭 가능한 화면으로 정리합니다. v2rayN, v2rayNG, v2flyNG는 모두 그래픽 클라이언트이며, 해당 코어를 호출해 연결을 수행합니다. 문제를 해결할 때는 ‘화면 설정이 적용되지 않은 경우’와 ‘코어 연결이 실패한 경우’를 구분해야 합니다. 전자는 보통 클라이언트 상태와 시스템 프록시를 확인하고, 후자는 노드 매개변수와 네트워크, 코어 로그를 확인합니다.

노드는 연결 매개변수의 묶음이며 구독과는 다릅니다

노드에는 최소한 서버 주소, 포트, 프로토콜과 인증 정보가 포함되며, 일부 프로토콜에는 전송 방식, TLS, 서버 이름, 경로 또는 서비스 이름도 들어갑니다. 노드는 클라이언트가 어디에 어떤 방식으로 연결할지를 결정합니다. 구독은 노드와 그룹 정보를 일괄 배포하는 링크입니다. 클라이언트가 구독을 업데이트하면 링크가 반환한 내용을 해석해 노드 목록을 생성합니다. 업데이트한다고 해서 모든 노드가 사용 가능해지는 것은 아니며, 회선 품질 테스트를 대신하지도 않습니다. 노드 목록이 비어 있다면 먼저 구독 해석이 성공했는지 확인하고, 곧바로 프록시 모드를 반복해서 바꾸지는 마세요.

시스템 프록시와 트래픽 전달은 서로 다른 두 계층의 설정입니다

코어가 실행 중이라는 것은 로컬 프록시 포트가 수신 대기 중이라는 뜻일 뿐, 애플리케이션 트래픽이 반드시 이를 통과한다는 의미는 아닙니다. 브라우저처럼 시스템 네트워크 설정을 따르는 프로그램은 보통 ‘시스템 프록시’를 통해 클라이언트로 들어갑니다. 시스템 프록시를 읽지 않는 프로그램은 별도로 프록시를 설정하거나 TUN 모드가 네트워크 계층에서 인계하도록 해야 할 수 있습니다. 연결 완료 여부는 클라이언트 코어가 실행 중인지, 시스템 또는 애플리케이션이 트래픽을 로컬 프록시 포트로 넘기는지, 현재 노드가 대상에 도달할 수 있는지를 차례로 확인해야 합니다. 트레이 아이콘이나 특정 웹페이지 하나만으로는 문제 계층을 정확히 찾을 수 없습니다.

프로토콜, 전송 방식, 라우팅은 각각 어떤 문제를 해결하나요?

VMess, VLESS, Trojan 같은 이름은 연결 프로토콜 계층에 속하고, TCP, WebSocket, gRPC 등은 데이터를 전달하는 전송 방식입니다. 라우팅 규칙은 요청을 직접 연결할지, 프록시로 보낼지, 차단할지를 결정합니다. 세 요소는 조합할 수 있지만 서로를 대신할 수는 없습니다. 예를 들어 노드가 VLESS를 사용한다고 해서 특정 웹사이트가 직접 연결되는 것은 아닙니다. 직접 연결 여부는 클라이언트가 생성한 라우팅 설정이 결정합니다. 반대로 라우팅 규칙이 아무리 정확해도 서버 주소나 인증 매개변수가 잘못되었다면 해결할 수 없습니다. 문제가 생기면 설정 전체를 무작정 수정하기보다 ‘연결 매개변수, 전송 매개변수, 트래픽 방향’ 세 그룹으로 나누어 차례로 확인하는 편이 효과적입니다.

로그는 검증 가능한 사실이며 부가 정보가 아닙니다

클라이언트 로그에는 보통 설정 로드, 포트 수신 대기, DNS 조회, 연결 수립과 실패 원인이 기록됩니다. 시간 초과가 보이면 먼저 네트워크 도달성, 노드 상태와 회선을 확인하고, 해석 실패라면 도메인과 DNS를 확인하세요. 설정 필드 오류라면 노드 상세 화면으로 돌아가 프로토콜, 전송 방식과 보안 옵션을 대조합니다. 로그의 시간 순서도 중요합니다. 설정 오류가 먼저 발생했다면 이후 연결 실패는 연쇄적인 결과일 수 있습니다. 이러한 대상을 충분히 이해한 뒤 클라이언트 선택과 설치로 넘어가야 이후의 각 스위치가 무엇을 의미하는지 분명해집니다.

플랫폼과 코어 요구 사항에 맞춰 클라이언트를 선택하세요

데스크톱에서는 우선 v2rayN을 선택하세요

Windows, macOS, Linux 데스크톱 환경에서는 우선 v2rayN을 사용하세요. v2rayN은 구독 관리, 노드 목록, 시스템 프록시, 라우팅 규칙과 TUN 모드를 하나의 조작 방식으로 묶어 처음 설정할 때부터 사용자 지정 트래픽 분할까지 대응합니다. Windows 사용자는 데스크톱 버전과 클래식 WPF 버전 중에서 선택할 수 있습니다. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하므로 여러 데스크톱 시스템에서 비슷한 방식으로 조작하고 싶은 사용자에게 적합하고, 클래식 WPF 버전은 전통적인 Windows 데스크톱 프로그램에 가깝습니다. 목표는 같으므로 둘 다 설치할 필요 없이 하나를 기본 환경으로 선택하면 됩니다.

Android에서는 두 가지 코어 방향 중에서 선택하세요

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 추천합니다. 다양한 프로토콜과 전송 방식을 폭넓게 지원해야 하는 환경에 적합합니다. v2flyNG는 v2fly 코어를 사용하며, V2Fly 계열이 필요한 경우의 대안이 될 수 있습니다. 두 클라이언트 모두 구독 가져오기, 노드 전환, 라우팅 설정과 로컬 VPN 인계를 지원하지만 설정 필드와 메뉴 위치는 다를 수 있습니다. 연결에 실패했다고 두 앱 사이를 계속 옮겨 다니지 마세요. 먼저 구독에서 제공하는 프로토콜이 현재 클라이언트에서 지원되는지 확인한 다음, 로그를 보고 코어 방향을 바꿀지 판단하세요.

아키텍처와 설치 패키지 형식이 일치해야 합니다

클라이언트 이름을 올바르게 고른 뒤에는 프로세서 아키텍처와 설치 패키지 형식도 확인해야 합니다. macOS에서는 ‘이 Mac에 관하여’에서 칩 유형을 확인할 수 있습니다. Apple 칩은 arm64, Intel 프로세서는 x64를 선택하세요. 최근 Android 기기는 대체로 arm64를 사용합니다. 확인하기 어렵거나 특수한 아키텍처라면 범용 버전을 선택할 수 있지만 패키지 용량이 더 클 수 있습니다. Linux는 x64와 arm64뿐 아니라 패키지 체계도 구분해야 합니다. Debian, Ubuntu 등은 deb를 사용하고 Fedora, RHEL 계열은 보통 rpm을 사용합니다. 아키텍처가 맞지 않으면 설치 프로그램이 실행되지 않거나 시스템에서 지원하지 않는다고 알리는 경우가 많습니다.

기능 수를 실제 필요와 혼동하지 마세요

클라이언트를 선택할 때 먼저 필요한 작업을 나열하세요. 시스템 프록시가 필요한지, 시스템 프록시를 읽지 않는 프로그램이 있는지, 사용자 지정 도메인 트래픽 분할이 필요한지, 로컬 네트워크 공유가 필요한지를 확인합니다. 일반적인 브라우저와 업무용 앱에는 구독, 노드 전환과 시스템 프록시만 있으면 됩니다. 더 많은 애플리케이션 트래픽을 포함해야 할 때 TUN을 고려하고, 트래픽 방향을 정밀하게 제어해야 할 때 사용자 지정 라우팅으로 넘어가세요. 기능이 많을수록 설정 계층과 장애 원인도 늘어납니다. 처음에는 최소한의 사용 가능한 설정을 만든 뒤 기능을 하나씩 추가하고, 추가할 때마다 검증 가능한 결과를 남기세요.

클라이언트를 바꾸기 전에 설정의 출처를 보존하세요

기기나 클라이언트를 바꾸기 전에는 최소한 구독 출처, 현재 라우팅 모드와 사용자 지정 규칙을 기록하세요. 노드가 구독에서 제공된 것이라면 하나씩 수동 복사할 필요 없이 새 클라이언트에서 구독을 다시 가져온 다음 라우팅과 프록시 모드만 복원하면 됩니다. 수동 노드는 서버와 포트만 적지 말고 프로토콜 필드를 모두 보존해야 합니다. 인증 정보가 포함된 설정은 관리되는 위치에 보관하고 공개 페이지에 붙여 넣지 마세요. 이 사이트의 클라이언트 비교에서는 세 클라이언트의 적합한 사용 범위를 정리했으니, 선택을 확정한 뒤 설치로 넘어가세요.

설치를 완료하고 되돌릴 수 있는 초기 설정을 만드세요

설치 전에 기존 클라이언트의 인계 상태를 해제하세요

한 기기에 여러 클라이언트를 보관할 수는 있지만, 시스템 프록시나 TUN을 동시에 인계하게 두지는 마세요. 설치 전에 기존 클라이언트를 종료하고 시스템 네트워크 설정에 남아 있는 수동 프록시 주소가 없는지 확인하세요. 기존 프로그램이 비정상 종료되면 시스템 프록시가 이미 수신 대기를 멈춘 로컬 포트를 가리킬 수 있으며, 모든 웹페이지가 연결되지 않는 현상이 나타납니다. 이때는 먼저 시스템 수동 프록시를 끈 다음 새 클라이언트를 시작하세요. 목적은 기존 설정을 삭제하는 것이 아니라, 첫 테스트에서 트래픽 진입점을 하나로 제한해 문제가 새 클라이언트 때문인지 남은 기존 설정 때문인지 판단하기 쉽게 만드는 것입니다.

Windows: 설치 형태와 실행 권한을 결정하세요

Windows에서 v2rayN을 사용할 때는 먼저 다운로드 센터의 Windows 섹션에서 데스크톱 버전 또는 클래식 WPF 버전을 선택하세요. 설치가 끝나면 시작 메뉴에서 실행하고, 처음 실행할 때 주 창이 열리는지, 코어 디렉터리를 프로그램이 읽을 수 있는지, 로그에 로컬 포트 수신 대기 정보가 나타나는지 확인합니다. 일반적인 시스템 프록시 기능은 계속 관리자 권한으로 실행할 필요가 없습니다. 시스템 네트워크 드라이버나 라우팅 변경이 필요한 기능을 활성화할 때만 클라이언트가 권한 상승을 요청할 수 있습니다. ‘항상 관리자 권한으로 실행’을 만능 해결책으로 사용하지 마세요. 디렉터리 권한이나 설정 경로 문제를 가릴 수 있습니다.

macOS: 칩에 맞춰 선택하고 시스템 권한을 확인하세요

macOS에 v2rayN을 설치할 때는 먼저 프로세서 유형을 확인한 뒤 해당 dmg를 선택하세요. 디스크 이미지를 연 다음 앱을 시스템 응용 프로그램 폴더로 옮기고, 읽기 전용 이미지에서 계속 직접 실행하지 않도록 합니다. 처음 시작할 때 출처 확인 메시지가 나타나면 시스템 보안 설정의 안내에 따라 허용하세요. 시스템 프록시와 TUN에 필요한 권한은 다릅니다. 시스템 프록시는 주로 현재 네트워크 서비스의 프록시 설정을 변경하고, TUN은 추가 네트워크 권한을 요구할 수 있습니다. 초기 단계에서는 시스템 프록시만 설정하고 TUN은 동시에 켜지 마세요. 먼저 구독과 노드 연결이 정상인지 확인하는 것이 좋습니다.

Linux: 배포판에 맞추고 데스크톱 세션을 확인하세요

Linux 사용자는 배포판에 맞춰 deb 또는 rpm을 선택하고 프로세서 아키텍처도 확인하세요. 설치 후 데스크톱 앱 목록에서 실행합니다. 화면이 나타나지 않으면 터미널에서 애플리케이션 명령을 직접 실행해 시작 오류를 확인할 수 있습니다. 데스크톱 환경마다 시스템 프록시를 읽는 방식이 완전히 같지는 않습니다. 일부 앱은 데스크톱 프록시 설정을 따르고, 일부 앱은 자체 네트워크 설정을 사용합니다. 따라서 Linux에서 ‘클라이언트가 실행 중’이라는 사실을 ‘모든 앱이 인계된 상태’와 동일하게 볼 수 없습니다. 처음에는 시스템 프록시를 확실히 따르는 브라우저로 검증한 뒤 별도 프록시 설정이 필요한 프로그램을 처리하세요.

sudo apt install ./v2rayN-linux-x64.deb

# rpm 계열 배포판은 해당 설치 패키지를 사용하세요
sudo rpm -Uvh v2rayN-linux-x64.rpm

Android: 활성 상태인 로컬 VPN은 하나만 유지하세요

Android에 v2rayNG 또는 v2flyNG를 설치한 뒤 처음 연결하면 로컬 VPN 생성 권한을 요청합니다. 이는 시스템이 앱 트래픽을 클라이언트로 전달하는 데 필요한 단계입니다. 동시에 이런 인계 상태를 유지할 수 있는 앱은 하나뿐이므로 새 클라이언트를 테스트하기 전에 다른 네트워크 도구의 연결을 끊어야 합니다. 구독을 가져온 뒤 노드 하나를 선택하고 라우팅은 기본값으로 둔 채 연결을 누르세요. 상태 표시줄의 연결 아이콘은 시스템 권한이 설정되었다는 뜻일 뿐입니다. 노드 연결 성공 여부는 로그와 실제 접속으로 다시 확인해야 합니다.

첫 실행 후 확인할 다섯 가지

첫째, 클라이언트 창과 트레이 메뉴가 정상적으로 열리는지 확인합니다. 둘째, 코어가 시작된 뒤 설정 오류가 없는지 확인합니다. 셋째, 로컬 HTTP, SOCKS 또는 혼합 프록시 포트를 기록해 다른 프로그램과 충돌하지 않도록 합니다. 넷째, 시작 시 자동 실행이 사용 습관에 맞는지 확인하고 당장 필요하지 않다면 꺼 둡니다. 다섯째, 클라이언트를 종료할 때 시스템 프록시를 자동으로 복구하는지 확인합니다. 이 다섯 가지를 마친 뒤 구독을 가져오세요. 설치 단계에서 이미 오류가 발생했다면 오류가 있는 상태로 구독 설정을 계속하지 마세요. 이후 로그에 여러 계층의 문제가 섞여 문제 해결이 훨씬 어려워집니다.

구독을 가져오고 노드를 업데이트하며 해석 결과를 판단하세요

구독 이름을 출처를 알아볼 수 있게 작성하세요

클라이언트의 구독 관리에서 새 구독을 추가할 때는 ‘일상 회선’이나 ‘테스트 회선’처럼 용도나 출처를 알 수 있는 이름을 사용하세요. ‘구독 1’, ‘새 그룹’처럼 의미 없는 이름은 피합니다. 이름 자체는 연결에 영향을 주지 않지만 업데이트와 문제 해결 효율에 직접 영향을 줍니다. 링크는 앞뒤 공백 없이 완전히 복사하고, 웹페이지에 표시된 문구를 구독 주소로 착각하지 마세요. 저장한 뒤 수동 업데이트를 한 번 실행하고 알림과 로그를 확인합니다. 노드 목록이 실제로 늘어나거나 갱신되어야 가져오기가 완료된 것입니다. 구독 기록만 저장했다고 해서 해석에 성공한 것은 아닙니다.

업데이트 실패는 반환 단계별로 분류하세요

구독 업데이트는 대략 가져오기, 디코딩, 해석, 저장의 네 단계로 나뉩니다. 가져오기 실패는 보통 시간 초과, 네트워크 오류 또는 서버의 비정상 응답으로 나타나므로 현재 네트워크에서 구독 주소에 접근할 수 있는지 먼저 확인해야 합니다. 디코딩 실패는 반환 내용이 클라이언트가 예상한 형식이 아니라는 뜻입니다. 링크가 불완전하게 복사되었거나 구독이 만료되었거나 서버가 안내 페이지를 반환했을 수 있습니다. 해석 실패는 노드 필드 형식, 인코딩 또는 클라이언트 지원 범위와 관련된 경우가 많습니다. 저장 실패라면 설정 디렉터리 권한, 디스크 공간과 기존 설정 상태를 확인하세요. 단계를 구분한 뒤 처리하는 편이 업데이트 버튼을 계속 누르는 것보다 원인을 찾기 쉽습니다.

업데이트 전후의 노드 변화를 따로 확인하세요

구독을 업데이트하면 노드가 추가, 삭제 또는 수정될 수 있습니다. 업데이트 전에 사용하던 노드가 제거되면 클라이언트가 다른 노드로 전환할 수도 있고, 구독 연결이 끊긴 기존 기록을 남길 수도 있습니다. 업데이트 후에는 현재 선택된 노드가 여전히 존재하는지 확인하고 사용자 지정 그룹이 예상대로 유지되는지도 점검하세요. 클라이언트에 ‘기존 노드 삭제’ 또는 ‘구독으로 덮어쓰기’ 옵션이 있다면, 활성화하기 전에 수동으로 추가한 노드가 영향을 받는지 확인해야 합니다. 수동 노드와 구독 노드는 가급적 별도 그룹으로 관리해 업데이트 때 출처를 구분할 수 있게 하세요.

지연 시간 테스트는 특정 질문에만 답합니다

노드 지연 시간 테스트는 보통 대상 주소가 일정 시간 안에 응답할 수 있는지를 확인하는 데 사용되며, 실제 다운로드 속도나 모든 웹사이트의 접속 품질을 의미하지는 않습니다. 일부 노드는 특정 탐지 방식에 응답하지 않아도 실제 프록시는 작동할 수 있고, 지연 시간이 낮아도 회선 혼잡으로 처리량이 떨어질 수 있습니다. 올바른 방법은 먼저 클라이언트 테스트로 명백히 접근할 수 없는 노드를 제외한 뒤, 동일한 로컬 네트워크 조건에서 고정된 웹페이지나 파일로 실제 접속을 비교하는 것입니다. 한 번의 결과 변동이 크다면 즉시 프로토콜 매개변수를 바꾸지 말고 시간대를 달리해 반복 테스트하세요.

구독 업데이트 주기는 변경 필요에 맞추세요

클라이언트를 열 때마다 구독을 연속해서 업데이트할 필요는 없습니다. 노드 출처가 명확하고 목록이 안정적이라면 노드가 작동하지 않거나 설정 변경 알림을 받았을 때, 또는 유지 관리 주기에 맞춰 수동 업데이트하면 됩니다. 자동 업데이트 간격을 지나치게 짧게 설정하지 마세요. 잦은 요청은 노드 품질을 높이지 않고 로그에 반복 기록만 쌓이게 합니다. 업데이트 후 전체적으로 사용할 수 없다면 로그를 보존하고 모든 노드가 교체되었는지 확인한 다음 구독 해석 실패 자가 점검표에 따라 링크, 반환 내용과 업데이트 경로를 차례로 확인하세요.

수동 노드는 필드를 빠짐없이 대조하세요

노드를 수동으로 추가할 때 서버와 포트만 확인하지 마세요. 프로토콜 유형, 사용자 식별자, 암호화 또는 흐름 제어, 보안 계층, 전송 방식, 서버 이름, 경로와 서비스 이름이 제공된 설정과 일치해야 합니다. 빈 필드도 의미가 있습니다. 비워 두어야 하는 항목에 경험상 기본값을 임의로 입력하지 마세요. 노드를 수정하기 전 복구용 기록을 하나 복사해 두고, 변경할 때마다 한 그룹의 필드만 조정하세요. 연결에 성공한 뒤 노드 이름을 지정하되, 민감한 매개변수 대신 용도를 설명하는 이름을 사용합니다. 이제 구독과 노드 계층이 끝났으므로 다음 단계에서는 어떤 앱 트래픽을 로컬 프록시로 보낼지 결정합니다.

시스템 프록시, 전역 모드와 앱별 차이를 이해하세요

시스템 프록시는 대부분의 데스크톱 앱이 사용하는 첫 번째 진입점입니다

v2rayN은 코어가 시작되면 로컬에서 프록시 포트를 수신 대기하고, 시스템 프록시를 켜면 운영체제의 프록시 주소를 해당 포트로 지정합니다. 브라우저, 업무용 소프트웨어와 일부 시스템 구성 요소는 이 설정을 읽어 요청을 클라이언트로 넘깁니다. 시스템 프록시를 꺼도 코어는 계속 실행될 수 있지만 시스템 설정을 따르는 앱은 더 이상 자동으로 프록시를 사용하지 않습니다. ‘클라이언트 연결은 정상인데 브라우저에 변화가 없는’ 경우 클라이언트 트레이 상태와 시스템 네트워크 설정을 함께 확인해 프록시 주소가 로컬을 가리키고 포트가 현재 클라이언트 설정과 일치하는지 점검하세요.

전역 모드는 연결 강도가 아니라 트래픽 선택 정책입니다

전역 모드는 보통 클라이언트로 들어온 트래픽을 현재 프록시 출구로 우선 보내는 것을 뜻합니다. 로컬 네트워크와 중국 본토를 우회하는 등의 규칙 모드는 도메인과 IP 정보를 기준으로 직접 연결 또는 프록시를 결정하고, 사용자 지정 모드는 사용자가 만든 규칙에 따라 일치시킵니다. 전역 모드는 노드 자체를 빠르게 만들거나 구독 필드 오류를 고치는 기능이 아니라 분할 판단을 줄이는 기능이며, 비교 테스트에 적합합니다. 규칙 모드에서는 대상에 실패하지만 전역 모드에서는 성공한다면 노드는 대체로 사용 가능하고 문제는 라우팅 또는 DNS에 있을 가능성이 큽니다. 두 모드 모두 실패한다면 노드와 네트워크 계층으로 돌아가 확인하세요.

앱마다 프록시 설정을 읽는 방식이 다릅니다

브라우저는 대체로 시스템 프록시를 따르지만, 일부 앱은 독립적인 프록시 옵션을 내장하고 일부 명령줄 도구는 환경 변수만 읽습니다. 시스템 프록시를 무시하고 직접 네트워크 연결을 만드는 프로그램도 있습니다. 따라서 한 앱의 결과로 기기 전체를 판단할 수 없습니다. 테스트할 때는 먼저 시스템 프록시를 확실히 따르는 브라우저를 기준으로 삼고 다른 앱을 하나씩 처리하세요. 명령줄 프로그램에는 필요할 때 프록시 환경 변수를 임시로 설정하고, 포트는 예시가 아니라 클라이언트 화면에 표시된 실제 값으로 바꿔야 합니다.

# 현재 터미널 세션에서 HTTP 프록시 사용
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

# SOCKS5를 사용하고 도메인 해석은 프록시 측에서 수행
curl --proxy socks5h://127.0.0.1:10808 https://example.com/

로컬 포트 충돌은 수신 대기 상태부터 확인하세요

코어를 시작할 때 주소가 이미 사용 중이라는 메시지가 나오면 다른 프로세스가 같은 포트를 수신 대기 중이라는 뜻입니다. 먼저 다른 프록시 클라이언트를 종료한 뒤 다시 시작하세요. 계속 충돌하면 클라이언트 설정에서 로컬 포트를 바꾸고, 해당 포트를 수동으로 입력한 모든 앱도 함께 업데이트해야 합니다. 시스템 프록시 포트만 바꾸고 코어의 수신 대기 포트를 바꾸지 않으면 안 됩니다. 두 포트는 일치해야 합니다. 포트 번호 자체가 속도를 결정하지 않으므로 의미 없이 반복해서 바꿀 필요는 없습니다. 로컬 네트워크 공유에는 수신 대기 주소와 방화벽도 관련되므로 기기 자체의 시스템 프록시와 분리해 설정하세요.

클라이언트를 종료할 때 시스템 상태를 복원하세요

클라이언트를 정상 종료하기 전 시스템 프록시를 끄거나, 종료 시 복원하도록 설정했는지 확인하세요. 프로그램이 강제 종료되면 프록시 설정이 남아 이후 시스템 프록시를 따르는 모든 앱이 이미 중지된 로컬 포트에 접속하려 할 수 있습니다. 네트워크 자체는 정상인데 브라우저가 즉시 프록시 연결 실패를 알리는 것이 대표적인 증상입니다. 시스템 네트워크 설정에서 수동 프록시를 끈 다음 클라이언트를 다시 시작해 확인하세요. 이 단계를 일상적인 문제 해결 목록에 넣으면 ‘종료 후 인터넷이 안 되는’ 문제를 빠르게 제외할 수 있습니다.

모바일 연결 상태는 앱 로그와 함께 판단하세요

Android 클라이언트는 시스템이 제공하는 로컬 VPN 인터페이스로 트래픽을 인계합니다. 연결을 누른 뒤 먼저 시스템 권한이 성공적으로 부여되었는지 확인하고, 클라이언트 로그에서 노드 연결이 완료되었는지 확인하세요. 일부 앱에는 자체 DNS, 네트워크 가속 또는 비공개 연결 설정이 있어 테스트 결과가 달라질 수 있습니다. 처음 설정할 때는 라우팅과 DNS를 기본값으로 유지하고 노드 하나만 선택해 검증하세요. 기본 연결이 안정된 뒤 실제 필요에 따라 앱별 정책이나 사용자 지정 라우팅을 추가해 노드, DNS와 앱 규칙을 처음부터 동시에 바꾸지 않도록 하세요.

도메인, IP와 규칙 순서로 트래픽 방향을 제어하세요

라우팅 규칙은 이미 클라이언트로 들어온 트래픽을 처리합니다

라우팅은 앱을 능동적으로 인계하는 기능이 아니라 시스템 프록시, 앱 프록시 또는 TUN을 통해 코어로 들어온 요청을 처리하는 기능입니다. 각 규칙에는 보통 조건과 출구 동작이 포함됩니다. 조건은 도메인, IP, 포트, 프로토콜 또는 출처일 수 있고, 동작은 대체로 프록시, 직접 연결 또는 차단입니다. 앱이 클라이언트를 전혀 거치지 않으면 아무리 정확한 라우팅 규칙도 적용되지 않습니다. 따라서 트래픽을 분할하기 전에 로그에서 대상 요청이 실제로 나타나는지 확인하고, 그 다음 어떤 규칙과 출구에 일치했는지 살펴보세요.

도메인 규칙은 서비스 범위를 표현하는 데 적합합니다

전체 도메인 일치는 지정한 호스트 이름에만 적용되고, 접미사 규칙은 하나의 도메인과 그 하위 도메인을 포괄할 수 있습니다. domain:example.com을 사용할 때는 현재 클라이언트 또는 코어가 이 표기를 어떻게 정의하는지 확인하세요. full:api.example.com은 단일 호스트까지 정확하게 지정할 수 있고, geosite: 계열 규칙은 관리되는 도메인 집합을 참조하므로 특정 서비스 유형을 포괄하는 데 적합합니다. 규칙 범위가 넓을수록 잘못 일치할 가능성도 커집니다. 하위 도메인 하나의 접속 문제를 해결하려고 최상위 도메인 전체와 모든 하위 도메인을 같은 출구로 보내지는 마세요.

IP 규칙은 해석 결과와 대상 주소에 좌우됩니다

IP 규칙은 단일 주소나 CIDR 대역과 일치시킬 수 있습니다. 예를 들어 192.168.0.0/16은 하나의 사설 네트워크 범위를 나타냅니다. LAN 주소는 보통 직접 연결해야 프린터, 라우터 관리 페이지와 파일 공유가 원격 출구로 전송되지 않습니다. 도메인 요청이 IP 규칙에 도달할 수 있는지는 코어가 해석된 대상 IP를 얻었는지와 현재 도메인 정책이 어떻게 설정되었는지에 따라 달라집니다. IP 규칙만 작성하고 DNS 과정을 확인하지 않으면 규칙은 맞아 보이지만 실제로 일치하지 않을 수 있습니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "full:intranet.example.com",
          "domain:office.example.com"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      }
    ]
  }
}

규칙 순서가 충돌 시 먼저 실행할 대상을 결정합니다

대부분의 라우팅 구현은 순서대로 규칙을 확인하고, 일치하면 더 이상 비교하지 않습니다. 따라서 구체적인 규칙을 포괄적인 규칙보다 앞에 배치해야 합니다. 예를 들어 특정 업무용 하위 도메인은 직접 연결하고 상위 도메인 전체는 프록시로 보내야 한다면 업무용 하위 도메인 직접 연결 규칙을 먼저 작성한 뒤 상위 도메인 프록시 규칙을 작성합니다. 순서가 반대면 포괄적인 규칙이 요청을 먼저 가로챕니다. 규칙을 수정한 뒤 저장 여부만 확인하지 말고 코어를 재시작하거나 다시 로드한 다음 로그에서 새 규칙이 로드되었는지 확인하세요. 문법과 일치 우선순위는 domain, ip, geosite 규칙 작성법에서 더 확인할 수 있습니다.

DNS와 라우팅은 같은 대상을 기준으로 맞춰야 합니다

트래픽 분할은 도메인 판단과 IP 판단을 함께 사용하는 경우가 많으므로 DNS 결과가 이후 라우팅에 영향을 줍니다. 도메인이 예상과 다른 주소 범위로 해석되면 IP 규칙이 잘못된 출구로 보낼 수 있습니다. 문제를 해결할 때는 DNS 서버만 바꾸지 말고 도메인, 해석 결과, 일치한 규칙과 최종 출구를 기록하세요. 클라이언트가 여러 DNS 그룹을 지원한다면 직접 연결용 조회와 프록시용 조회에 다른 경로를 지정할 수 있지만, 각 조회가 어느 출구에서 수행되는지 먼저 이해해야 합니다. 기본 설정이 안정되지 않았다면 여러 규칙을 추가하기보다 기본 DNS를 유지하는 편이 검증하기 쉽습니다.

최소 테스트 세트로 트래픽 분할을 검증하세요

고정된 테스트 대상 세 가지를 준비하세요. 하나는 LAN 주소, 하나는 직접 연결해야 하는 도메인, 하나는 프록시로 보내야 하는 도메인입니다. 규칙을 수정할 때마다 이 순서로 테스트하고 일치한 출구를 기록하세요. LAN이 실패하면 먼저 사설 주소 규칙을 확인하고, 도메인 출구가 예상과 다르면 규칙 순서와 도메인 형식을 확인합니다. 로그에 요청이 없다면 트래픽 진입점 계층으로 돌아가세요. 무작위 웹페이지 하나만 테스트 대상으로 사용하지 마세요. 웹페이지는 여러 도메인을 동시에 불러올 수 있으므로 메인 페이지가 열렸다고 모든 리소스가 같은 출구를 사용했다는 뜻은 아닙니다. 규칙 모드 검증을 마친 뒤 TUN으로 인계 범위를 넓힐 필요가 있는지 결정하세요.

기본 프록시가 안정된 뒤 TUN 모드를 활성화하세요

TUN은 시스템 프록시를 읽지 않는 앱의 트래픽을 처리합니다

TUN 모드는 가상 네트워크 인터페이스로 더 많은 시스템 트래픽을 받은 뒤 코어에 라우팅과 전달을 맡깁니다. 시스템 프록시를 따르지 않는 데스크톱 프로그램, 명령줄 도구를 일괄적으로 인계해야 하는 경우, 앱마다 프록시를 설정하는 수고를 줄이고 싶은 환경에 적합합니다. TUN은 노드 가속 스위치가 아니며 프로토콜 성능을 높이지도 않습니다. 기본 노드 연결이 불안정한 상태에서 TUN을 켜면 가상 네트워크 카드, DNS와 라우팅 테이블이라는 세 가지 변수가 추가될 뿐입니다. 따라서 일반 시스템 프록시에서 먼저 구독, 노드와 규칙 모드가 정상적으로 작동하는지 확인해야 합니다.

활성화 전에 현재 네트워크 기준선을 기록하세요

시작하기 전에 현재 네트워크 어댑터, DNS 획득 방식, 클라이언트 로컬 포트와 시스템 프록시 상태를 기록하고 가상 네트워크 카드를 만들 수 있는 다른 프로그램은 종료하세요. 그런 다음 v2rayN에서 TUN을 활성화하고 시스템 안내에 따라 필요한 권한을 부여한 뒤 코어가 다시 로드될 때까지 기다립니다. 시작 후 로그에 가상 인터페이스 생성, 라우팅 기록과 DNS 초기화 정보가 나타나는지 확인하세요. 클라이언트의 스위치만 켜지고 로그에 인터페이스 생성 실패가 표시된다면 노드 매개변수를 계속 수정하지 말고 권한 또는 드라이버 문제부터 처리해야 합니다.

엄격한 라우팅과 자동 라우팅의 범위를 이해하세요

자동 라우팅은 인계에 적합한 시스템 트래픽을 TUN으로 보내고, 엄격한 라우팅은 가상 인터페이스를 우회하는 경로를 더 제한합니다. 구체적인 스위치 이름은 클라이언트 화면에 따라 달라질 수 있지만 원칙은 같습니다. 먼저 필요한 최소 옵션만 활성화하고 브라우저, 명령줄과 대상 앱을 검증한 다음, 트래픽 누수가 있는지에 따라 제한을 추가하세요. 기업 네트워크, 가상 머신, 컨테이너 또는 다중 네트워크 카드 환경에서는 자동 생성된 라우팅이 기존 대역과 겹칠 수 있습니다. 이때는 전역 프록시로 바로 전환하지 말고 먼저 라우팅 테이블을 확인하세요.

DNS 이상은 TUN 문제 해결의 첫 번째 핵심입니다

TUN을 켠 뒤 IP 주소에는 접속되지만 도메인에는 접속되지 않는다면 먼저 DNS를 확인하세요. 클라이언트 DNS 모듈이 시작되었는지, 조회 요청이 예상한 진입점으로 들어가는지, 로컬 보안 프로그램이 가로채고 있지 않은지 확인합니다. 일부 도메인만 실패한다면 해석 결과와 일치한 규칙을 기록하고, 모든 도메인이 실패한다면 DNS 수신 대기 포트, 시스템 DNS 지정과 포트 충돌을 확인하세요. 여러 DNS 인계 기능을 동시에 활성화하지 마세요. 조회가 시스템, 클라이언트와 다른 네트워크 프로그램 사이를 순환할 수 있습니다.

LAN과 다중 네트워크 카드 환경에서는 직접 연결 경로를 유지하세요

TUN을 활성화한 뒤에도 프린터, 네트워크 저장 장치와 라우터 관리 페이지 같은 사설 주소는 로컬 네트워크 카드로 직접 연결되어야 합니다. 라우팅에 사설 주소 범위가 포함되어 있는지 확인하고, 현재 LAN에서 일반적이지 않은 사용자 지정 대역을 사용하는지도 점검하세요. 유선, 무선과 가상 네트워크 카드가 동시에 연결되어 있다면 기본 라우팅이 실제로 어느 카드에서 나가는지도 확인해야 합니다. 네트워크를 전환한 뒤 문제가 생기면 먼저 TUN을 끄고 가상 인터페이스와 라우팅이 철회될 때까지 기다린 다음 네트워크에 다시 연결하고 클라이언트를 시작하세요.

장기간 활성화가 정말 필요한지 판단하세요

일상적으로 사용하는 앱이 모두 시스템 프록시를 안정적으로 읽는다면 설정을 복잡하게 만들기 위해 TUN을 계속 켜 둘 필요는 없습니다. 프록시를 따르지 않는 특정 앱까지 인계해야 할 때 TUN의 가치가 분명해집니다. 안정적으로 작동하는 기준은 재부팅 후 자동 복구, 네트워크 전환 후 라우팅 재생성, 정상적인 LAN 접속, 지속적인 DNS 오류 없음, 클라이언트 종료 후 시스템 네트워크 복원입니다. 이 조건을 충족한 뒤에야 TUN을 시작 프로그램에 추가하세요. 그렇지 않다면 시스템 프록시를 더 단순한 일상 설정으로 유지하는 편이 좋습니다.

업데이트, 백업, 속도 측정과 계층별 문제 해결 절차를 마련하세요

유지 관리를 정기 작업과 이벤트 기반 작업으로 나누세요

정기적인 유지 관리는 클라이언트 업데이트, 구독 상태, 사용자 지정 규칙과 오래된 설정을 확인하는 데 사용합니다. 이벤트 기반 유지 관리는 노드 전체가 작동하지 않거나 네트워크 환경이 바뀌었거나 시스템을 업그레이드한 뒤 수행합니다. 매일 설정을 지우거나 클라이언트를 다시 설치할 필요는 없습니다. 정상적인 경우 먼저 구독을 업데이트하고 노드 변화를 확인한 다음 반복 가능한 연결 테스트를 소수만 수행하세요. 클라이언트를 업그레이드하기 전 현재 설정을 기록하고, 업그레이드 후에는 코어 시작, 시스템 프록시와 자주 사용하는 노드 하나를 먼저 검증한 뒤 TUN이나 복잡한 라우팅을 복원하세요.

백업의 핵심은 다시 생성할 수 없는 내용입니다

구독 노드는 보통 다시 가져올 수 있으므로 실제로 백업해야 할 것은 수동 노드, 사용자 지정 라우팅, DNS 설정, 그룹 구성과 LAN 공유 매개변수입니다. 백업 파일에는 인증 정보가 포함될 수 있으므로 관리되는 디렉터리에 보관하세요. 복원할 때는 새 설정 전체를 바로 덮어쓰지 말고 클라이언트 설정 구조가 호환되는지 먼저 확인한 뒤 항목별로 가져옵니다. 기기만 교체하는 경우에는 클라이언트를 새로 설치하고 구독을 가져온 다음 규칙을 수동으로 복원하는 것이 좋습니다. 이렇게 하면 기존 시스템의 경로, 포트 충돌과 네트워크 인터페이스 정보까지 함께 옮겨지는 일을 피할 수 있습니다.

속도 문제는 노드·회선·로컬 환경의 세 계층으로 확인하세요

첫 번째 계층에서는 같은 구독의 노드를 소수만 바꿔 문제가 특정 노드에 집중되는지 확인합니다. 두 번째 계층에서는 시간대를 달리해 같은 노드를 테스트하고 회선 혼잡이 시간대에 따라 달라지는지 관찰합니다. 세 번째 계층에서는 로컬 네트워크, 프록시 모드, DNS, TUN과 보안 프로그램을 확인합니다. 테스트하는 동안 대상 웹사이트, 파일과 기기를 동일하게 유지하고 노드를 바꾸면서 무선 네트워크까지 바꾸지 마세요. 모든 노드가 느리다면 로컬 네트워크와 구독 전체 상태를 먼저 확인하고, 노드 하나만 느리다면 클라이언트를 다시 설치할 필요가 없습니다. 자세한 절차는 V2Ray 속도 저하 계층별 점검을 참고하세요.

로그 수집은 문제가 발생한 시점을 포함해야 합니다

문제 해결 로그에는 최소한 코어 시작, 문제 재현과 테스트 종료의 세 단계가 포함되어야 합니다. 마지막 오류 한 줄만 잘라내면 앞서 발생한 설정 로드 실패를 놓치기 쉽습니다. 재현하기 전에 오래된 로그를 지나치게 많이 정리하거나 현재 시간을 기록한 다음, 구독 한 번 업데이트, 노드 하나 연결 또는 고정 도메인 하나 접속처럼 단일 작업을 수행하세요. 로그를 공유하기 전 서버 주소, 사용자 식별자와 구독 내용 등 민감한 정보는 삭제하되 오류 유형, 시간 순서와 구성 요소 이름은 남기세요. 그래야 문제를 설명하면서도 연결 매개변수를 노출하지 않을 수 있습니다.

일반적인 증상별 첫 확인 지점

클라이언트가 열리지 않으면 먼저 설치 패키지 아키텍처, 실행 환경과 설정 디렉터리를 확인하세요. 구독 업데이트가 실패하면 링크 가져오기와 해석 로그를 먼저 확인합니다. 모든 노드가 시간 초과되면 로컬 네트워크와 구독 상태를 먼저 점검하고, 브라우저에서 프록시 연결 실패가 표시되면 코어 수신 대기와 시스템 프록시 포트를 확인하세요. 특정 도메인 하나만 이상하면 DNS 결과와 라우팅 일치를 먼저 확인하고, TUN을 켠 뒤 전체 네트워크가 끊기면 TUN을 끈 다음 가상 인터페이스와 기본 라우팅을 확인하세요. 증상별 답변은 문제 해결에서 더 찾아볼 수 있습니다.

LAN 공유는 별도의 경계를 관리해야 합니다

LAN 연결을 허용하면 로컬 프록시 포트가 현재 기기뿐 아니라 다른 기기도 서비스하게 됩니다. 수신 대기 주소, 시스템 방화벽, 라우터의 네트워크 격리와 기기 측 프록시 주소를 확인하고 신뢰할 수 있는 LAN에서만 사용하세요. 컴퓨터의 IP가 바뀌면 휴대폰이나 TV에 입력한 프록시 주소도 함께 바꿔야 합니다. 공유에 문제가 생기면 먼저 다른 기기에서 컴퓨터의 LAN 주소에 접근할 수 있는지 테스트하고, 다음으로 포트 허용을 확인한 뒤 클라이언트가 외부 연결을 허용하는지 점검하세요. 전체 절차는 v2rayN LAN 공유 단계에서 확인할 수 있습니다.

유지 관리의 목표는 정상 작동 기준선을 하나 보존하는 것입니다

큰 변경을 하기 전 정상적으로 작동하는 노드, 기본 라우팅과 시스템 프록시 조합을 하나 보존하세요. 변경 후 짧은 시간 안에 원인을 찾지 못하면 기준선으로 되돌린 뒤 항목별로 다시 적용합니다. 구독, DNS, 라우팅, TUN과 로컬 포트를 한꺼번에 모두 바꾸지 마세요. 연결이 복구되더라도 실제로 어떤 변경이 효과가 있었는지 알 수 없습니다. 반복 가능한 유지 관리 절차가 잦은 재설치보다 안정적이며, 이후 고급 설정도 명확한 상태 위에서 진행할 수 있습니다.

안정적인 기준선에서 사용자 지정 규칙과 여러 기기 관리로 나아가세요

고급 활용의 출발점은 현재 설정을 설명할 수 있는 것입니다

기본 사용을 마쳤다고 곧바로 대규모 규칙 모음을 가져올 필요는 없습니다. 먼저 다섯 가지 질문에 답할 수 있는지 확인하세요. 현재 노드는 어떤 프로토콜과 전송 방식을 사용하는지, 앱 트래픽은 어떻게 클라이언트로 들어오는지, DNS 조회는 어느 경로를 거치는지, 대상 요청은 어떤 라우팅 규칙과 일치하는지, 최종적으로 어떤 출구를 사용하는지입니다. 이 중 하나라도 확실하지 않다면 규칙을 더 추가할수록 불확실성만 커집니다. 고급 설정의 목표는 설정 수를 늘리는 것이 아니라, 각 트래픽이 명확하고 검증 가능한 조건에 따라 예상한 출구로 들어가게 하는 것입니다.

먼저 이름 지정과 그룹 구성 규칙을 세우세요

구독 이름, 노드 메모, 아웃바운드 태그와 규칙 이름은 일관된 의미를 유지해야 합니다. 예를 들어 ‘출처—지역—용도’ 형식으로 노드 그룹을 이름 붙이고, proxy, direct, block으로 출구 용도를 표시하며, 사용자 지정 규칙에는 대상과 동작을 명시합니다. 이름 규칙은 로그 가독성을 직접 높이고 이전 작업의 판단 비용도 줄여 줍니다. 이름에 전체 인증 정보나 구독 주소를 넣지 마세요. 여러 기기에서 규칙을 공유한다면 기기 경로와 로컬 포트가 없는 공용 버전을 하나 보관하고, 각 기기에서 로컬 차이만 추가하세요.

사용자 지정 규칙에는 테스트·배포·복구 절차가 필요합니다

규칙을 추가하기 전에 ‘업무용 하위 도메인은 직접 연결하고, 같은 도메인의 다른 서비스는 기본 정책으로 처리한다’처럼 기대 결과를 먼저 작성하세요. 그런 다음 최소 규칙을 추가하고 로그에서 일치를 확인한 뒤 도메인이나 대역 범위를 넓힙니다. 일상 설정에 배포하기 전에는 LAN, 직접 연결 대상, 프록시 대상과 DNS를 최소한 테스트하세요. 규칙 순서를 변경한다면 기존 순서의 사본을 보관합니다. 문제가 생기면 패치를 계속 덧붙이지 말고 가장 최근 변경부터 되돌리세요. 장기적으로는 이미 유효하지 않거나 더 넓은 규칙에 의해 가려진 항목을 삭제해야 합니다.

{
  "rules": [
    {
      "name": "private-network-direct",
      "match": [
        "geoip:private"
      ],
      "action": "direct"
    },
    {
      "name": "office-domain-direct",
      "match": [
        "full:portal.example.com",
        "domain:corp.example.com"
      ],
      "action": "direct"
    }
  ]
}

위의 조각은 규칙 설계 방법을 보여 주기 위한 예시이며, 클라이언트 설정을 그대로 덮어쓸 수 있는 완성 파일이 아닙니다. 실제 필드는 현재 코어의 라우팅 구조와 클라이언트 내보내기 형식을 기준으로 작성해야 합니다. 가져오기 전에 태그 이름이 기존 아웃바운드와 일치하는지 확인하세요. 일치하더라도 대응하는 출구를 찾지 못하면 규칙이 작동하지 않습니다.

여러 기기 관리는 공용 설정과 기기별 차이를 나눠야 합니다

Windows, macOS, Linux와 Android는 같은 구독 출처를 사용할 수 있지만 시스템 프록시, TUN 권한, 설치 패키지 아키텍처와 LAN 인터페이스는 기기마다 다르므로 억지로 복사해서는 안 됩니다. 공유할 부분은 구독 그룹, 코어 라우팅 의도와 테스트 대상이고, 기기별 부분은 로컬 포트, 시작 시 자동 실행, 시스템 권한과 앱 인계 방식입니다. 이전할 때는 먼저 공용 부분을 복원한 뒤 기기별로 하나씩 설정하세요. 이렇게 하면 논리는 일관되게 유지하면서도 특정 플랫폼의 네트워크 인터페이스 설정이 다른 플랫폼으로 옮겨지는 일을 막을 수 있습니다.

고급 DNS 설정은 관찰 가능한 결과를 중심으로 설계해야 합니다

기본 DNS 때문에 해석 실패, 예상과 다른 출구 또는 특정 도메인 오염이 명확하게 발생할 때만 조회 경로를 나누세요. 설계하기 전에 대상 도메인이 어느 DNS 그룹에서 해석되는지, 조회가 어느 출구를 통과하는지, 그 결과가 어떤 라우팅에 사용되는지 기록합니다. 캐시, 보조 조회 또는 도메인별 분할을 추가한 뒤에는 최초 조회와 캐시 적중 결과를 각각 검증하세요. 설정 후 간헐적인 실패가 나타나면 먼저 단일 경로로 단순화한 다음 항목별로 복원합니다. DNS 설정은 도메인 라우팅을 대신할 수 없고, 접근할 수 없는 노드를 고칠 수도 없습니다.

학습 경로를 세 가지 순환 과정으로 고정하세요

첫 번째 순환은 연결입니다. 프로토콜 필드를 이해하고 단일 노드의 안정성을 확인합니다. 두 번째 순환은 인계입니다. 시스템 프록시, 앱 프록시와 TUN의 경계를 익힙니다. 세 번째 순환은 트래픽 분할입니다. 도메인, IP, DNS와 규칙 순서를 이해합니다. 각 순환은 ‘기준선 수립—한 가지 추가—결과 검증—복구 방법 기록’ 순서로 진행하세요. 새로운 문제가 생기면 먼저 어느 순환에 해당하는지 판단한 뒤 해당 장으로 돌아가면 됩니다. 처음부터 다시 설치할 필요는 없습니다. 빠른 작업은 사용 가이드로 돌아가고, 클라이언트 패키지와 플랫폼 요구 사항은 다운로드 센터에서 확인하며, 구체적인 증상은 문제 해결에서 찾아보세요.

최종 설정은 재현할 수 있을 만큼 단순해야 합니다

완성도 높은 설정은 규칙이 가장 많은 설정이 아니라, 다른 기기에서도 기록을 보고 다시 구축할 수 있는 설정입니다. 구독 출처 설명, 클라이언트 선택 이유, 프록시 진입점, 라우팅 대상, TUN 사용 조건과 유지 관리 주기의 여섯 가지 문서를 보존하세요. 용도를 설명할 수 없는 스위치와 규칙은 삭제하고 구독과 사용자 지정 설정이 여전히 일치하는지 정기적으로 확인합니다. 이로써 핵심 개념부터 고급 관리까지 완전한 순환이 만들어집니다. 먼저 연결을 성립시키고, 다음으로 트래픽을 진입시키며, 그 후 방향을 제어하고, 마지막으로 로그·백업과 기준선을 통해 설정을 장기간 관리할 수 있게 합니다.