V2Ray 입문부터 고급 설정까지 완벽 가이드

1. 핵심 개념: 클라이언트, 코어와 설정의 경계 이해하기

그래픽 클라이언트와 프록시 코어는 다릅니다

V2Ray을 배울 때 가장 혼동하기 쉬운 부분은 그래픽 클라이언트, 프록시 코어, 노드 설정과 시스템 프록시를 하나의 개념으로 보는 것입니다. 실제로 이들은 서로 다른 계층에 있습니다. v2rayN, v2rayNG와 v2flyNG는 창, 구독 목록, 노드 선택, 로그와 스위치 같은 사용자 인터페이스를 제공합니다. Xray 또는 V2Fly 코어는 설정을 해석하고, 전송 연결을 만들며, 라우팅 규칙을 적용하고, 로컬 프록시 포트를 제공합니다. 구독 또는 개별 공유 링크는 서버 주소, 포트, 사용자 식별자, 프로토콜과 전송 매개변수를 클라이언트에 전달합니다. 시스템 프록시와 TUN은 애플리케이션 트래픽이 로컬 코어로 들어가는 방식을 결정합니다. 이 네 계층이 모두 올바르게 연결되어야 브라우저나 다른 프로그램의 요청이 예상한 경로로 전달됩니다.

따라서 “클라이언트에 실행 중이라고 표시된다”는 것은 로컬 프로세스가 시작되었다는 뜻일 뿐, 구독이 유효하거나 노드에 연결할 수 있거나 애플리케이션 트래픽이 프록시로 들어갔다는 뜻은 아닙니다. 문제를 해결할 때는 데이터 흐름에 따라 계층별로 확인해야 합니다. 먼저 클라이언트가 설정을 인식하는지 확인하고, 다음으로 코어가 정상적으로 시작되는지, 로컬 수신 포트가 존재하는지, 마지막으로 시스템이나 애플리케이션이 실제로 해당 포트를 사용하는지 확인합니다. 각 단계를 분리하면 연결 버튼을 반복해서 누르는 것보다 문제를 빠르게 찾을 수 있습니다.

인바운드, 아웃바운드와 라우팅의 작동 방식

코어 설정에는 일반적으로 세 가지 핵심 부분이 있습니다. 인바운드는 로컬 SOCKS 또는 HTTP 프록시 포트처럼 이 컴퓨터의 애플리케이션에서 전달되는 요청을 받습니다. 아웃바운드는 요청이 컴퓨터를 떠난 뒤 처리되는 방식을 정의하며, 보통 원격 프록시, 직접 연결과 차단을 포함합니다. 라우팅은 그 사이에서 도메인, IP, 프로토콜 유형 또는 프로세스 조건에 따라 사용할 아웃바운드를 선택합니다. 그래픽 클라이언트는 이 개념을 “시스템 프록시”, “라우팅 모드”, “LAN 우회”, “특정 연결 차단” 같은 옵션으로 묶어 보여 주지만, 내부 흐름은 여전히 수신, 판단, 전달 순서로 동작합니다.

도메인 확인도 연결 과정에서 독립적인 위치를 차지합니다. 애플리케이션이 먼저 시스템에서 도메인을 확인한 뒤 IP를 프록시에 전달할 수도 있고, 도메인을 로컬 프록시에 직접 넘겨 코어가 설정에 따라 확인하게 할 수도 있습니다. 두 경로는 도메인 규칙의 적용 여부와 분할 라우팅 결과에 영향을 줍니다. 처음부터 복잡한 DNS 항목을 수정할 필요는 없습니다. 도메인 규칙이 올바르게 보이는데도 적용되지 않는다면, 요청이 코어에 들어올 때 여전히 도메인인지 이미 IP로 변환되었는지 확인하면 됩니다.

프로토콜 이름과 전송 매개변수는 나누어 이해해야 합니다

VMess, VLESS, Trojan 같은 이름은 일반적으로 프록시 프로토콜 계층을 설명합니다. TCP, WebSocket, gRPC 등은 전송 방식에 해당하고, TLS와 REALITY 등은 연결 보안과 핸드셰이크 특성과 관련됩니다. 공유 링크는 여러 계층의 매개변수를 하나의 문자열로 압축하며, 가져온 뒤 클라이언트가 이를 코어가 읽을 수 있는 설정으로 복원합니다. 프로토콜 이름이 같다고 해서 두 노드 설정을 서로 바꿔 쓸 수 있는 것은 아닙니다. 전송 방식, 호스트 이름, 경로, 보안 옵션과 서버 설정이 서로 일치해야 합니다. 노드를 직접 편집할 때는 경험에 의존해 값을 임의로 채우지 말고, 정보가 부족하면 설정 제공자에게 확인해야 합니다.

이 장을 마치면 요청을 하나의 명확한 흐름으로 설명할 수 있어야 합니다. 애플리케이션이 요청을 보내고, 시스템 프록시 또는 TUN이 트래픽을 가로채며, 로컬 인바운드가 요청을 받고, 라우팅이 아웃바운드를 선택한 뒤, 코어가 노드 설정에 따라 연결을 수립합니다. 이후의 모든 설정은 이 흐름에 대입해 이해할 수 있습니다.

2. 클라이언트 선택: 플랫폼, 코어와 유지 관리 방식에 따른 선택

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

Windows, macOS와 Linux의 데스크톱 환경에서는 v2rayN을 우선 선택하는 것이 좋습니다. 구독 그룹, 서버 목록, 시스템 프록시, 라우팅, 로그와 TUN을 하나의 화면에서 관리할 수 있어 기본 사용에서 규칙 관리로 단계적으로 넘어가기 좋습니다. Windows에서는 인터페이스 기술과 사용 습관에 따라 데스크톱 버전 또는 클래식 WPF 버전을 선택할 수 있습니다. macOS에서는 프로세서 아키텍처에 맞는 설치 패키지를 선택해야 하며, Linux에서는 배포판의 패키지 체계에 따라 deb 또는 rpm을 선택합니다. 구체적인 다운로드 경로와 최신 파일명은 다운로드 페이지에서 통합해 안내하며, 이 안내서에는 고정 버전을 기록하지 않습니다.

같은 구독을 사용하면 데스크톱 운영체제가 달라도 노드 내용은 대체로 같지만, 시스템 프록시, 권한 관리, 인증서 저장소, 시작 프로그램과 방화벽 동작은 서로 다릅니다. 설정을 이전할 때 구독 주소와 사용자 지정 규칙의 구성 방식은 재사용할 수 있지만, 로컬 설정까지 모두 그대로 복사할 수 있다고 가정해서는 안 됩니다. 특히 TUN 모드는 각 운영체제가 제공하는 가상 네트워크 인터페이스와 권한 체계에 의존하므로 현재 플랫폼에 맞춰 문제를 해결해야 합니다.

Android에서는 v2rayNG와 v2flyNG를 구분

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 선택하는 것이 좋습니다. 다양한 프로토콜과 전송 특성을 지원하는 설정에 적합합니다. v2flyNG는 V2Fly 코어를 사용하며 V2Fly 생태계를 선호하는 경우의 대안이 될 수 있습니다. 두 클라이언트 모두 구독 가져오기, 노드 전환과 로컬 VPN 방식의 트래픽 가로채기를 지원하지만, 코어 기능과 설정 항목의 이름, 일부 설정의 호환성은 다를 수 있습니다. 구독이 특정 코어 기능을 요구한다면 화면 모양만 비교하지 말고 사용 중인 코어가 해당 기능을 지원하는지 먼저 확인해야 합니다.

설치 패키지의 아키텍처도 선택해야 합니다. 최신 주류 Android 기기는 대체로 arm64를 사용하며, 기기 아키텍처를 확인하기 어렵거나 더 많은 기기 유형을 지원해야 한다면 범용 버전이 적합합니다. 아키텍처는 설치 패키지에 포함된 네이티브 코드의 종류만 결정하며 구독 내용은 바꾸지 않습니다. 시스템에서 설치 패키지와 기기가 호환되지 않는다고 표시되면 구독을 새로 만들 필요 없이 먼저 범용 버전으로 바꿔 보세요.

노드 수로 호환성을 판단하지 마세요

클라이언트 선택의 핵심은 “몇 개의 기록을 가져올 수 있는가”가 아니라 현재 설정을 코어가 완전히 해석할 수 있는지, 시스템 트래픽을 안정적으로 코어에 전달할 수 있는지입니다. 구독 목록에 노드가 표시된다는 것은 텍스트 형식이나 공유 링크가 인식되었다는 뜻일 뿐입니다. 연결 단계에서는 전송 매개변수 누락, 코어 미지원, 시스템 시간 오차 또는 네트워크 연결 불가로 실패할 수 있습니다. 더 신뢰할 수 있는 방법은 사용 가능성이 확인된 설정 하나를 대상 클라이언트에서 실행해 코어가 시작되는지, 로그에 설정 오류가 나타나는지, 로컬 프록시가 요청을 처리하는지 확인하는 것입니다.

데스크톱과 Android를 함께 사용하는 경우 서로 다른 기기에서 같은 구독 주소를 참조할 수 있지만, 클라이언트의 로컬 설정은 각각 관리하는 것이 좋습니다. 데스크톱에서는 시스템 프록시와 세분화된 라우팅을 자주 사용하고, 모바일에서는 운영체제가 제공하는 VPN 인터페이스에 의존하는 경우가 많습니다. 백그라운드 실행, 배터리 절전 정책과 LAN 접근 방식도 다릅니다. 구독은 원격 설정을 동기화할 뿐 각 기기의 트래픽 가로채기 정책까지 동기화하지는 않습니다.

클라이언트를 선택한 뒤에는 하나의 주 클라이언트로 이후 학습을 진행하는 것이 좋습니다. 여러 클라이언트를 계속 오가면 인터페이스 차이를 설정 오류로 오해하기 쉽습니다. 데스크톱은 v2rayN, Android는 v2rayNG부터 시작하는 것이 더 명확한 학습 경로입니다.

3. 설치 준비: 시스템 아키텍처, 권한과 첫 실행 확인

다운로드 전에 시스템과 프로세서 아키텍처 확인

설치 전에 운영체제 종류, 프로세서 아키텍처, 현재 계정의 설치 및 네트워크 설정 권한 여부를 확인하세요. Windows 사용자는 최신 데스크톱 인터페이스와 클래식 WPF 인터페이스 중 무엇을 사용할지도 결정해야 합니다. macOS 사용자는 Apple Silicon과 Intel을 구분해야 합니다. Linux 사용자는 배포판이 deb와 rpm 중 어느 패키지를 사용하는지, x64와 arm64 중 어떤 아키텍처인지 확인해야 합니다. Android 사용자는 기기 아키텍처를 확실히 알고 있다면 arm64를 선택하고, 그렇지 않으면 범용 버전을 사용하면 됩니다. 아키텍처를 잘못 선택하면 대개 노드 연결 오류가 아니라 설치 또는 실행 실패로 나타납니다.

다운로드는 사이트의 클라이언트 다운로드 페이지에서 시작하세요. 다운로드 페이지는 네 가지 플랫폼별로 설치 패키지를 정리하고 각 아키텍처를 설명합니다. 설치 패키지가 업데이트되면 파일명이 바뀔 수 있으므로 오래된 파일명을 장기 메모에 적어 두는 것은 권장하지 않습니다. 대신 “v2rayN, macOS, arm64”처럼 클라이언트 이름, 플랫폼과 아키텍처를 기록해 두고 재설치할 때 해당 플랫폼 패널을 다시 확인하는 편이 안전합니다.

첫 실행 시 디렉터리와 권한부터 확인

데스크톱 클라이언트는 일반적으로 구독, 로그, 라우팅 규칙과 인터페이스 환경설정을 저장해야 합니다. 프로그램을 읽기 전용 디렉터리에 두거나 현재 계정에 설정 디렉터리 쓰기 권한이 없으면 설정 저장 실패, 재시작 후 구독 삭제, 코어 압축 해제 실패 등이 발생할 수 있습니다. 첫 실행 후 중요하지 않은 인터페이스 옵션 하나를 바꾸고 재시작하여 설정이 유지되는지 확인하세요. 클라이언트가 로그 디렉터리 메뉴를 제공한다면 해당 디렉터리에 파일을 정상적으로 만들 수 있는지도 확인해야 합니다.

시스템 프록시 변경, 시작 프로그램 등록과 TUN 모드에 필요한 권한은 서로 완전히 같지 않습니다. 일반적인 시스템 프록시는 현재 사용자 계정의 프록시 설정만 변경하지만, TUN은 가상 네트워크 인터페이스를 만들거나 라우팅 테이블을 수정해야 하므로 더 높은 권한이 필요한 경우가 많습니다. 기초 단계에서는 시스템 프록시만으로 연결을 먼저 확인하고, 첫 실행부터 TUN, 복잡한 라우팅, LAN 공유와 사용자 지정 DNS를 동시에 켜지 마세요. 한 번에 하나의 변수만 추가해야 오류 발생 시 되돌리기 쉽습니다.

1. 클라이언트를 설치합니다. 운영체제와 프로세서 아키텍처에 맞는 설치 패키지를 선택하고 시스템의 설치 절차를 완료합니다.
2. 실행 후 쓰기 권한을 확인합니다. 클라이언트가 설정을 저장하고 로그를 만들며 정상적으로 종료되는지 확인합니다.
3. 코어 시작 여부를 확인합니다. 많은 설정을 한꺼번에 가져오지 말고 로그에 구성 요소 누락, 포트 충돌 또는 권한 오류가 있는지 확인합니다.
4. 기본 로컬 포트를 기록합니다. 애플리케이션 프록시 설정이나 충돌 문제를 확인할 때 SOCKS, HTTP 또는 혼합 포트를 알아야 합니다.

로컬 수신 포트 이해하기

코어가 시작되면 일반적으로 루프백 주소에서 하나 이상의 로컬 포트를 수신합니다. 루프백 주소는 이 컴퓨터에서만 접근할 수 있으며 보통 127.0.0.1로 표시합니다. SOCKS 인바운드는 SOCKS 프록시를 지원하는 애플리케이션에 적합하고, HTTP 인바운드는 HTTP 프록시를 지원하는 애플리케이션에 적합합니다. 혼합 포트는 두 종류의 요청을 모두 받을 수 있습니다. 실제 포트는 클라이언트 설정 화면을 기준으로 해야 하며 다른 사람의 숫자를 그대로 사용해서는 안 됩니다. 포트가 다른 프로그램에서 사용 중이면 코어가 시작되지 않고, 로그에 수신 실패나 주소가 이미 사용 중이라는 메시지가 나타나는 경우가 많습니다.

데스크톱 운영체제의 네트워크 상태 도구로 포트가 수신 중인지 확인할 수 있습니다. 다음 명령은 로컬 수신 상태를 확인하는 용도이며, 예시의 10808은 클라이언트 화면에 표시된 실제 값으로 바꿔야 합니다. Windows에서는 터미널에서 첫 번째 명령을, macOS와 Linux에서는 두 번째 명령을 실행하세요:

netstat -ano | findstr 10808
lsof -nP -iTCP:10808 -sTCP:LISTEN

출력이 없다면 구독을 바로 수정하지 말고 먼저 클라이언트 로그를 확인하세요. 포트를 다른 프로세스가 사용 중이라면 충돌하는 프로그램을 종료하거나 클라이언트에서 사용하지 않는 포트로 변경한 뒤, 프록시를 수동으로 설정한 애플리케이션에도 새 포트를 반영해야 합니다. 시스템 프록시를 클라이언트가 자동 관리한다면 대체로 포트 변경을 따라갑니다. 하지만 브라우저, 개발 도구 또는 터미널에 수동으로 설정한 프록시는 자동으로 갱신되지 않습니다.

설치 단계의 목표는 처음부터 모든 기능을 켜는 것이 아니라 재현 가능한 최소 환경을 만드는 것입니다. 클라이언트 이름, 시스템 아키텍처, 로컬 포트와 설정 디렉터리 위치를 기록해 두면 이후 업그레이드, 이전과 문제 해결이 훨씬 수월해집니다.

4. 구독 관리: 가져오기, 업데이트, 그룹과 형식 인식

구독 주소와 개별 공유 링크의 차이

구독 주소는 일반적으로 여러 설정을 반환하며, 클라이언트가 업데이트할 때 다시 가져와 해당 그룹의 내용을 덮어쓰거나 병합합니다. 개별 공유 링크는 노드 하나만 나타내며 가져온 뒤 원격 목록의 변경 사항을 자동으로 따라가지 않습니다. 장기간 사용할 때는 구독 주소를 별도 그룹에 넣고 그룹 이름을 명확하게 지정하는 것이 좋습니다. 임시 테스트용 공유 링크는 별도 그룹에 두어 업데이트 시 원격에서 관리되는 항목과 로컬에서 직접 추가한 항목을 구분하기 쉽게 하세요.

일반적인 구독 내용은 base64로 인코딩된 여러 줄의 공유 링크일 수도 있고, 클라이언트가 직접 해석할 수 있는 원시 JSON이나 다른 구조일 수도 있습니다. base64는 인코딩 방식이지 암호화 프로토콜이 아니며, 노드가 VMess, VLESS 또는 Trojan 중 무엇을 사용하는지도 결정하지 않습니다. 형식 인식에 실패했다면 프록시 모드를 반복해서 바꾸지 말고, 반환 내용이 완전한지, 클라이언트가 해당 구독 형식을 지원하는지, 복사한 주소에 공백이나 줄바꿈이 섞이지 않았는지 먼저 확인하세요. 형식의 관계는 구독 형식 자세히 보기에서 확인할 수 있습니다.

관리하기 쉬운 그룹 구조 만들기

그룹은 목록을 정리하는 것뿐 아니라 업데이트 정책과 로컬 규칙을 분리하는 역할도 합니다. 최소한 “일상 구독”, “임시 테스트”, “수동 설정”은 구분하는 것이 좋습니다. 일상 구독은 자동 업데이트를 유지하고, 임시 테스트는 필요할 때만 업데이트하며, 수동 설정은 원격 내용으로 덮어쓰지 않도록 합니다. 같은 주소를 여러 그룹에 반복해서 추가하면 업데이트 후 내용이 중복되어 속도 측정, 정렬과 현재 노드 선택이 더 혼란스러워집니다. 중복 기록을 발견하면 노드를 하나씩 삭제하기보다 먼저 구독 목록을 확인하세요.

구독을 업데이트하기 전에 클라이언트가 구독 주소에 접근해야 합니다. 이 요청은 현재 네트워크를 통해 직접 가져올 수도 있고, 클라이언트 옵션에 따라 기존 프록시를 통해 가져올 수도 있습니다. 현재 노드가 이미 만료되었는데 구독 업데이트도 프록시를 사용하도록 설정되어 있으면 “사용 가능한 노드를 얻으려면 업데이트해야 하지만 업데이트 요청은 기존 노드에 의존하는” 순환이 생길 수 있습니다. 이 경우 잠시 직접 연결로 업데이트하거나, 사용 가능성이 확인된 설정으로 업데이트를 완료하세요. 업데이트가 성공하면 원래 정책으로 되돌리면 됩니다.

• 구독 주소 추가
• 그룹 이름 지정
• 업데이트 실행
• 노드 필드 확인
• 현재 설정 선택

업데이트 후 확인할 항목

“업데이트 완료”가 표시되었다고 모든 설정을 사용할 수 있는 것은 아닙니다. 업데이트 후에는 세 단계로 확인하세요. 첫째, 그룹에 노드가 생성되었는지 확인합니다. 비어 있다면 반환 형식과 필터 조건을 중점적으로 살펴보세요. 둘째, 설정 하나를 무작위로 열어 주소, 포트, 프로토콜, 전송과 보안 옵션이 크게 누락되지 않았는지 확인합니다. 셋째, 설정 하나를 선택해 코어를 시작하고 로그에 해석 오류가 나타나는지 확인합니다. 노드 이름만 보고 내용을 판단하지 마세요. 이름은 메모일 뿐 실제 연결에는 사용되지 않습니다.

구독 자동 업데이트 주기를 너무 짧게 설정해 클라이언트 사용을 자주 방해하지 않도록 하세요. 설정 제공자의 변경 빈도에 맞춰 주기를 정하고 수동 업데이트 메뉴도 남겨 두는 것이 좋습니다. 데스크톱 기기를 장시간 실행한다면 일정 간격으로 확인하게 할 수 있지만, 모바일 기기는 백그라운드 제한으로 자동 작업이 지연될 수 있어 수동 새로 고침이 더 확실합니다. 자동 업데이트 여부와 관계없이 마지막으로 업데이트에 성공한 시점을 알아야 문제가 오래된 설정 때문인지 현재 네트워크 때문인지 판단할 수 있습니다.

구독 업데이트 실패를 계층별로 확인하기

업데이트 실패는 대개 네 가지 원인으로 나뉩니다. 주소 자체가 변경되었거나, 현재 네트워크에서 구독 서비스에 접근할 수 없거나, 반환 내용이 클라이언트가 지원하는 형식이 아니거나, 직접 연결 또는 프록시를 통한 업데이트 정책이 적절하지 않은 경우입니다. 주소를 공개하지 않는 조건에서 링크가 완전한지 확인하고, 가져오기 정책을 바꾼 다음 업데이트 로그의 HTTP 상태, 해석 안내 또는 시간 초과 정보를 확인하세요. 응답은 성공했지만 해석에 실패했다면 형식 계층의 문제이고, 응답 자체가 없다면 네트워크 또는 주소 계층의 문제입니다. 전체 점검 절차는 구독 업데이트 실패 해결 절차를 참고하세요.

안정적인 구독 관리는 세 가지를 충족해야 합니다. 출처를 그룹별로 분리하고, 업데이트 경로를 전환할 수 있으며, 업데이트 결과를 검증할 수 있어야 합니다. 이 습관을 들이면 원격 목록이 바뀌어도 로컬 사용자 지정 규칙과 임시 테스트 설정에 영향을 주지 않습니다.

5. 프록시 모드: 시스템 프록시, 애플리케이션 프록시와 전체 선택

시스템 프록시가 제어하는 프로그램

시스템 프록시는 운영체제가 제공하는 네트워크 설정에 프록시 주소를 기록합니다. 시스템 프록시를 따르는 브라우저와 데스크톱 프로그램은 요청을 클라이언트의 로컬 포트로 전달하지만, 모든 프로그램이 이 설정을 읽는 것은 아닙니다. 일부 명령줄 도구, 게임, 가상 머신, 컨테이너 또는 자체 네트워크 스택을 구현한 소프트웨어는 시스템 프록시를 무시할 수 있습니다. “브라우저는 되는데 특정 애플리케이션은 안 된다”면 먼저 해당 애플리케이션이 시스템 프록시를 따르는지 확인하고 노드가 불안정하다고 단정하지 마세요.

클라이언트 화면의 “시스템 프록시 지우기”, “시스템 프록시 자동 설정”, “변경하지 않음” 같은 옵션은 운영체제 설정을 제어하며 코어의 라우팅 모드와는 다릅니다. 시스템 프록시는 “트래픽이 코어로 들어가는가”에 답하고, 라우팅 모드는 “들어온 뒤 어떤 아웃바운드로 가는가”에 답합니다. 이 두 스위치는 자주 혼동됩니다. 올바른 순서는 먼저 트래픽이 들어오는지 확인한 뒤 직접 연결, 프록시 또는 차단 규칙을 확인하는 것입니다.

애플리케이션 프록시는 정밀한 테스트에 적합

프록시 설정을 지원하는 애플리케이션에는 127.0.0.1과 클라이언트에 표시된 로컬 포트를 직접 입력할 수 있습니다. 이 방법은 전체 시스템을 변경하지 않고 대상 애플리케이션에만 적용되므로 로컬 인바운드가 작동하는지 확인하거나 개발 도구에 별도 프록시를 지정할 때 유용합니다. 프록시 유형은 수신 포트와 일치해야 합니다. SOCKS 설정은 SOCKS 인바운드를, HTTP 설정은 HTTP 또는 호환되는 혼합 인바운드를 가리켜야 합니다. 유형을 잘못 입력하면 포트에는 연결되더라도 프로토콜 핸드셰이크는 실패합니다.

터미널 프로그램은 환경 변수를 통해 HTTP 프록시를 읽는 경우가 많습니다. 다음 예시는 로컬 주소와 예시 포트를 사용하며 현재 터미널 세션에서만 적용됩니다. 터미널을 닫으면 보통 다시 설정해야 합니다. 실제로 사용하기 전에 클라이언트 포트를 확인하고 대상 도구가 해당 변수를 지원하는지 알아보세요.

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

Windows PowerShell에서는 현재 세션에서 다음과 같이 환경 변수를 사용할 수 있습니다:

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
$env:ALL_PROXY="socks5://127.0.0.1:10808"

전체, 규칙과 직접 연결 모드의 용도

전체 프록시는 코어로 들어온 요청을 우선 현재 프록시 아웃바운드로 보내는 방식이며, 짧은 시간 동안 연결 가능성을 확인할 때 적합합니다. 규칙 모드는 도메인, IP 또는 다른 조건에 따라 프록시, 직접 연결 또는 차단을 선택하는 일상적인 방식입니다. 직접 연결 모드는 코어로 들어온 요청을 대상에 직접 보내며, 원격 노드가 원인인지 비교할 때 사용합니다. 모드 이름은 클라이언트마다 조금 다를 수 있지만 판단 방식은 대체로 같습니다.

문제를 해결할 때 세 가지 모드를 비교해 볼 수 있습니다. 전체 프록시는 실패하지만 직접 연결은 정상이라면 노드와 원격 전송을 먼저 확인하세요. 전체 프록시는 정상인데 규칙 모드만 실패한다면 라우팅 적용 여부를 먼저 확인하세요. 시스템 프록시를 끈 뒤에도 애플리케이션이 프록시를 사용한다면 애플리케이션 자체에 수동 프록시가 설정되어 있거나 TUN이 활성화된 것일 수 있습니다. 비교 테스트에서는 한 번에 하나의 스위치만 바꾸고 테스트가 끝나면 원래 설정으로 되돌리세요.

프록시 모드의 핵심은 “어떤 방식이 가장 넓게 적용되는가”가 아니라 애플리케이션의 동작에 맞는 트래픽 가로채기 방식을 선택하는 것입니다. 시스템 프록시는 일반적인 데스크톱 트래픽에, 수동 프록시는 정밀한 제어에 적합하며, TUN은 기본 연결이 안정된 뒤 활성화하는 것이 좋습니다.

6. 라우팅: 규칙 순서부터 도메인과 IP 매칭까지

라우팅 규칙은 순서대로 적용됩니다

라우팅의 기본 동작은 요청의 특성에 따라 프록시, 직접 연결 또는 차단 아웃바운드를 선택하는 것입니다. 대부분의 규칙 시스템은 정해진 순서대로 확인하고 일치하면 다음 규칙을 계속 보지 않으므로, 규칙 내용이 정확해도 순서가 잘못되면 예상과 다른 결과가 나옵니다. 범위가 넓은 규칙을 너무 앞에 두면 뒤의 정밀한 규칙이 무시됩니다. 범위가 좁은 예외 항목은 대개 해당하는 일반 규칙보다 앞에 배치해야 합니다. 수정하기 전에 현재 모드와 규칙 순서를 기록해 두면 테스트 실패 시 빠르게 되돌릴 수 있습니다.

일반적인 매칭 조건에는 전체 도메인, 도메인 접미사, IP 또는 네트워크 대역, 포트, 네트워크 유형과 프로세스 이름이 있습니다. 도메인 규칙은 읽기 쉽고 안정적인 도메인을 기준으로 구성하기 좋습니다. IP 규칙은 명확한 주소 대역에 적합하지만 대상 서비스가 동적 주소를 사용하면 유지 관리 비용이 커집니다. 프로세스 규칙은 클라이언트와 운영체제의 지원에 의존하므로 프로그램 업데이트나 경로 변경 후 작동하지 않을 수 있습니다. 처음에는 도메인과 예약 주소 대역부터 사용해 논리를 확인한 뒤 더 복잡한 조건을 추가하세요.

도메인 매칭이 실패할 수 있는 이유

규칙이 도메인을 볼 수 있는지는 요청이 코어에 들어올 때 어떤 정보를 가지고 있는지에 달려 있습니다. 애플리케이션이 먼저 DNS 확인을 끝내고 IP만 프록시에 전달하면 순수 도메인 규칙이 직접 적용되지 않을 수 있습니다. 코어가 스니핑이나 다른 방식을 통해 대상 도메인을 복원할 수도 있지만 모든 트래픽에 적용되는 것은 아닙니다. 반대로 애플리케이션이 SOCKS를 통해 도메인을 코어에 전달하면 도메인 규칙이 더 직접적으로 적용됩니다. 문제를 확인할 때는 규칙 문구만 보지 말고 라우팅 로그의 대상 형식을 확인하세요.

도메인 접미사 규칙에서는 경계도 주의해야 합니다. 예를 들어 example.com에 대한 접미사 규칙은 일반적으로 하위 도메인에 적용되지만, 같은 문자열을 포함한 다른 도메인을 같은 사이트로 잘못 판단해서는 안 됩니다. 클라이언트가 “전체 도메인”, “도메인 접미사”, “키워드” 유형을 제공한다면 의미가 가장 정확한 유형을 우선 선택하세요. 키워드 매칭은 범위가 넓어 임시 확인에만 적합하며 장기 규칙의 기반으로는 부적절합니다.

최소 라우팅 설정 읽는 법

아래 JSON은 라우팅 부분의 기본 구조를 보여 줍니다. 첫 번째 규칙은 LAN과 예약 주소를 직접 연결하고, 두 번째 규칙은 예시 도메인을 프록시로 보내며, 나머지 트래픽은 이후의 기본 아웃바운드가 처리합니다. direct와 proxy는 완전한 설정에 이미 존재하는 아웃바운드 태그와 일치해야 합니다. 이 조각은 필드 관계를 이해하기 위한 예시이며 인바운드, 아웃바운드와 DNS 설정 없이 단독으로 실행할 수 없습니다.

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

AsIs는 라우팅 단계에서 요청의 원래 대상을 우선 사용하며, IP 규칙을 위해 모든 도메인을 적극적으로 확인하지 않는다는 뜻입니다. 정책에 따라 도메인과 IP 규칙의 협력 방식이 달라지므로 특정 값이 언제나 더 좋다고 말할 수는 없습니다. 현재 클라이언트 규칙이 안정적으로 작동한다면 매개변수를 복잡하게 만들기 위해 정책을 바꿀 필요가 없습니다. 도메인과 IP의 매칭 관계가 예상과 다르다는 사실을 명확히 확인했을 때만 DNS 설정과 로그를 함께 보며 조정하세요.

기본 동작부터 규칙 설계하기

규칙 집합을 만들기 전에 “어떤 규칙에도 일치하지 않을 때 어떻게 처리할 것인가”를 먼저 결정하세요. 기본 프록시는 직접 연결 예외를 중심으로 한 규칙 체계에, 기본 직접 연결은 소수의 명확한 대상만 프록시로 보내는 체계에 적합합니다. 두 방식 모두 사용할 수 있지만 섞어 쓰면 읽기 어려워집니다. 규칙 설명에 기본 아웃바운드를 명시하고, 각 그룹에 “LAN 직접 연결”, “지정 도메인 프록시”, “특정 프로토콜 차단”처럼 목적을 부여하세요. 의미가 모호한 번호만 사용하지 않는 것이 좋습니다.

규칙 검증에는 반복해서 사용할 수 있는 대상을 정하고 로그에서 실제로 적용된 아웃바운드 태그를 확인해야 합니다. 웹 페이지가 열리는지만으로는 라우팅이 올바른지 알 수 없습니다. 대상이 직접 연결과 프록시를 모두 허용할 수 있기 때문입니다. 클라이언트에 라우팅 디버그 로그가 있다면 검증하는 동안만 로그 수준을 높이고 완료 후 되돌리세요. 여러 규칙을 수정할 때는 전체 규칙 집합을 한 번에 가져오기보다 그룹별로 활성화하고 하나씩 테스트해야 충돌을 찾기 쉽습니다.

신뢰할 수 있는 라우팅 체계에는 명확한 기본 동작, 정밀한 조건에서 넓은 조건으로 이어지는 매칭 순서, 식별하기 쉬운 아웃바운드 태그와 반복 가능한 검증 대상이 있어야 합니다. 규칙 수는 완성도의 기준이 아닙니다. 설명할 수 있고 되돌릴 수 있는지가 더 중요합니다.

7. TUN 모드: 가상 네트워크 카드 가로채기, 권한과 DNS 경로

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

시스템 프록시는 애플리케이션이 운영체제의 프록시 설정을 직접 읽어야 하지만, TUN은 가상 네트워크 인터페이스와 라우팅 테이블을 통해 더 넓은 범위의 IP 트래픽을 가로챕니다. 시스템 프록시를 무시하는 프로그램에는 TUN이 더 효과적일 수 있습니다. 동시에 시스템 권한, 가상 인터페이스, 라우팅 충돌, DNS 경로와 로컬 네트워크 접근이라는 추가 변수가 생깁니다. 따라서 TUN은 기본 연결이 실패했을 때 쓰는 만능 해결책이 아니라, 기본 프록시가 안정된 뒤 트래픽 가로채기 범위를 넓히는 독립적인 방식입니다.

TUN을 켜도 애플리케이션이 프록시의 존재를 알 필요는 없습니다. 운영체제가 트래픽을 가상 인터페이스로 보내면 클라이언트가 이를 코어가 처리할 수 있는 연결로 변환하고 라우팅을 실행합니다. 이 과정은 더 낮은 계층에서 이루어지므로 브라우저, 명령줄 도구와 프록시 설정을 지원하지 않는 일부 프로그램도 통합적으로 처리할 수 있습니다. 하지만 가상 머신, 컨테이너, 다른 VPN 계열 소프트웨어나 보안 프로그램도 라우팅 테이블을 수정할 수 있어 여러 구성 요소가 동시에 작동하면 우선순위 충돌이 발생하기 쉽습니다.

활성화 전에 비교 기준선 만들기

TUN을 켜기 전에 시스템 프록시로 현재 노드, 구독과 라우팅 규칙이 작동하는지 확인하고 TUN을 끈 상태의 결과를 기록하세요. 그런 다음 애플리케이션의 수동 프록시를 끄고, 같은 요청이 수동 프록시를 거친 뒤 TUN에 다시 가로채이지 않도록 합니다. 활성화 후에는 가상 인터페이스 생성 여부, 클라이언트 로그의 권한 오류, 기본 라우팅 변경 상태, LAN 접근 여부와 도메인 확인 결과를 차례로 점검하세요. 모든 단계가 정상인 뒤에야 기존에 시스템 프록시를 따르지 않던 프로그램을 테스트해야 합니다.

클라이언트가 권한 상승을 요구한다면 운영체제가 제공하는 승인 절차를 사용하세요. 권한 부족은 가상 인터페이스 생성 실패, 라우팅 기록 실패 또는 모드가 켜졌다가 즉시 꺼지는 현상으로 나타나는 경우가 많습니다. 이런 오류는 노드 프로토콜과 관계가 없으므로 구독을 바꿔도 해결되지 않습니다. 데스크톱에서는 다른 가상 네트워크 인터페이스가 작동 중인지 확인하고, Android에서는 시스템 VPN 가로채기 상태와 백그라운드 실행 제한을 확인하세요.

1. 중복 진입 경로를 끕니다. 애플리케이션 내부의 수동 프록시를 정리하고 명확한 트래픽 진입 경로 하나만 남깁니다.
2. TUN을 활성화하고 시스템 권한을 승인합니다. 클라이언트가 가상 인터페이스를 정상적으로 생성하는지 확인합니다.
3. 기본 네트워크를 확인합니다. 도메인 접근, 직접 IP 접근과 LAN 기기 접근을 각각 테스트합니다.
4. 규칙 적용을 검증합니다. 기존의 직접 연결, 프록시와 차단 규칙이 TUN에서도 예상대로 실행되는지 확인합니다.
5. 대상 애플리케이션을 테스트합니다. 마지막으로 시스템 프록시로 가로채지 못했던 프로그램을 확인합니다.

DNS는 TUN 문제 해결의 핵심입니다

TUN을 켠 뒤 “IP로는 접근되지만 도메인으로는 접근되지 않는” 현상이 나타난다면 연결 경로는 존재하지만 DNS 단계에 문제가 있을 가능성이 큽니다. DNS 요청이 예상한 경로로 들어가지 않거나, 클라이언트 DNS 설정과 시스템 설정이 충돌하거나, 라우팅 규칙이 확인 요청을 차단하거나, 다른 네트워크 소프트웨어가 여전히 DNS를 가로채고 있을 수 있습니다. 먼저 클라이언트 로그에 확인 시간 초과가 기록되는지 확인하고 TUN을 끈 뒤의 결과와 비교하세요. 노드, DNS 서버와 라우팅 규칙을 동시에 바꾸면 어떤 변경이 효과가 있었는지 알 수 없습니다.

또 다른 현상은 도메인은 확인되지만 규칙이 잘못된 대상을 기준으로 적용되는 경우입니다. TUN 환경에서 코어가 스니핑으로 도메인을 복원할 수도 있고, 확인된 IP만 볼 수도 있습니다. 현재 라우팅 정책에 따라 규칙이 도메인과 IP 중 무엇에 매칭되는지 판단해야 합니다. 도메인 기반 분할 라우팅이 반드시 필요하다면 DNS와 트래픽 가로채기 경로에서 충분한 정보가 유지되는지 확인하세요. 대상 주소가 안정적이라면 명확한 IP 또는 네트워크 대역 규칙을 보완책으로 사용할 수도 있지만 주소 변경에 따른 유지 관리 비용을 고려해야 합니다.

LAN과 절전 모드 복귀 문제

TUN이 라우팅을 변경하면 로컬 프린터, 저장 장치 또는 개발 서비스가 실수로 프록시로 전송될 수 있습니다. LAN과 예약 주소는 일반적으로 우선 직접 연결해야 하며 넓은 프록시 규칙보다 앞에 배치해야 합니다. TUN을 끈 뒤에만 LAN에 접근할 수 있다면 사설 네트워크 대역 규칙과 우회 설정을 확인하고 전체 규칙 체계를 직접 연결로 바꾸지는 마세요. 기기 이름과 LAN IP도 따로 테스트해야 합니다. 전자는 로컬 도메인 확인과 관련되고 후자는 주로 라우팅과 관련됩니다.

컴퓨터가 절전 모드에 들어갔다가 복귀하거나 네트워크를 전환하거나 유선에서 무선으로 바꾸면 이전 가상 인터페이스와 라우팅 상태가 즉시 갱신되지 않을 수 있습니다. 클라이언트는 실행 중으로 표시되지만 새 요청이 시간 초과되는 식으로 나타납니다. 먼저 클라이언트에서 TUN을 끈 뒤 다시 켜 인터페이스를 재생성하세요. 그래도 복구되지 않으면 코어를 재시작하고 시스템 라우팅을 확인합니다. 시스템 재시작은 가장 마지막에 시도하세요. 바로 재시작하면 가장 중요한 오류 현장을 잃게 됩니다.

TUN 설정 성공의 기준은 스위치가 켜진 상태로 유지되는 것이 아닙니다. 가상 인터페이스, DNS, 라우팅 규칙, LAN과 대상 애플리케이션이 모두 설명 가능한 결과를 보여야 합니다. 기본 프록시와 TUN을 단계적으로 검증하면 문제 해결 시간을 크게 줄일 수 있습니다.

8. 일상적인 유지 관리: 업데이트, 로그, 백업과 문제 계층화

클라이언트, 코어와 구독 업데이트를 분리하세요

일상적인 유지 관리에는 그래픽 클라이언트 자체 업데이트, 코어 구성 요소 업데이트와 구독 내용 업데이트라는 세 가지가 있습니다. 이들은 해결하는 문제가 서로 다릅니다. 클라이언트 업데이트는 인터페이스, 시스템 통합과 설정 관리를 바꿀 수 있고, 코어 업데이트는 프로토콜 해석, 전송 기능과 실행 동작에 영향을 줍니다. 구독 업데이트는 원격 설정 목록만 바꿉니다. 문제가 발생하면 최근에 변경된 계층부터 확인하세요. 구독 업데이트 실패를 클라이언트 업그레이드 필요로 오해하거나 노드 장애 때 모든 구성 요소를 동시에 업데이트하지 마세요.

업데이트 전에 현재 사용할 수 있는 설정, 프록시 모드와 중요한 사용자 지정 규칙을 기록하세요. 업데이트 후에는 기존 설정으로 기준선 테스트를 먼저 수행하고 새 기능을 확인합니다. 업데이트 직후 새 구독을 가져오고 라우팅을 수정하며 TUN까지 켜면 문제가 발생했을 때 원인을 구분할 수 없습니다. 장기간 안정적으로 사용하는 환경의 유지 관리 목표는 모든 옵션을 쫓는 것이 아니라 변화를 통제하는 것입니다.

로그는 시간 순서로 읽어야 합니다

로그에는 일반적으로 클라이언트 조작, 코어 시작, 설정 해석, DNS, 라우팅과 연결 오류가 포함됩니다. 효과적으로 읽으려면 작업을 실행한 정확한 시간을 기록한 뒤 그 시점 전후의 짧은 구간만 확인하세요. 시작 단계에서는 설정 파일 경로, 필드 해석, 포트 수신과 권한을 우선 확인하고, 연결 단계에서는 도메인 확인, 핸드셰이크, 시간 초과와 라우팅 아웃바운드를 우선 확인합니다. 구독 단계에서는 요청 상태와 내용 해석을 확인하세요. 로그의 마지막 한 줄만 따로 보지 마세요. 근본 원인은 더 앞부분에 나타나는 경우가 많습니다.

로그 수준을 높이면 더 많은 세부 정보를 얻을 수 있지만 기록도 빠르게 늘어납니다. 문제를 재현하기 전에 일시적으로 높이고, 명확한 테스트 한 번을 마친 즉시 수집한 뒤 평소 수준으로 되돌리세요. 로그를 공개적으로 공유할 때는 오류 유형, 시간 순서와 필요한 필드만 남기고 구독 주소, 노드 주소, 사용자 식별자와 로컬 디렉터리의 개인 이름은 숨겨야 합니다. 로그는 과정을 재현하기 위한 것이지 설정 백업이 아닙니다.

백업의 핵심은 복구 가능한 정보입니다

백업할 가치가 있는 항목에는 구독 그룹 구조, 사용자 지정 라우팅 규칙, 클라이언트 환경설정, 로컬 수동 노드와 필요한 설정 설명이 포함됩니다. 구독 주소만으로는 원격 노드를 복구할 수 있지만 모든 로컬 변경 사항까지 복원할 수는 없습니다. 백업 파일은 관리되는 위치에 보관하고 그대로 공개하지 마세요. 클라이언트가 설정 내보내기를 지원한다면 내보내기 범위를 먼저 확인해야 합니다. 어떤 클라이언트는 노드만 내보내고, 어떤 클라이언트는 라우팅과 인터페이스 설정을 포함하며, 일부는 로컬 경로를 참조하기도 합니다.

복원할 때 기존 설정 전체를 한 번에 덮어쓰지 마세요. 먼저 클라이언트를 설치하고 실행해 코어의 기준선이 정상인지 확인한 뒤 구독을 가져오고, 다음으로 라우팅을 복원하며 마지막에 TUN과 시작 프로그램을 처리하는 편이 안전합니다. 각 단계마다 한 번씩 실행하고 로그를 확인하세요. 이렇게 하면 다른 시스템이나 오래된 환경에서 만든 백업이라도 호환되지 않는 지점에서 정확히 멈출 수 있습니다.

최소 재현 설정 만들기

복잡한 장애는 클라이언트 하나, 구독 그룹 하나, 사용 가능성이 확인된 설정 하나, 시스템 프록시와 기본 라우팅만 남기는 방식으로 줄여야 합니다. 자동 선택, 복잡한 DNS, 프로세스 규칙, LAN 공유와 TUN을 끈 뒤 문제를 재현하세요. 최소 설정이 정상이라면 고급 설정을 하나씩 복원하고, 최소 설정에서도 실패한다면 설정 필드, 네트워크와 코어 로그를 확인합니다. 최소 재현은 기능을 영구적으로 삭제하는 것이 아니라 잠시 변수를 줄이는 작업입니다.

노드 선택도 목록의 지연 시간만 보지 말고 실제 연결 결과를 기준으로 해야 합니다. 지연 시간은 일반적으로 특정 탐색 요청의 왕복 시간을 나타낼 뿐 대상 연결, 전송 핸드셰이크와 지속적인 트래픽 성능을 모두 보여 주지는 않습니다. 선택 방법은 노드 선택 기준을 참고하고, 실제 사용 가능성, 프로토콜 호환성과 대상 환경을 중점적으로 비교하세요.

유지 관리의 핵심은 변수를 통제하는 것입니다. 업데이트를 계층별로 나누고, 로그를 시간 순서로 읽으며, 백업을 단계별로 복원하고, 장애를 최소 설정으로 줄이는 네 가지 습관만으로도 장기간 사용 중 발생하는 대부분의 문제를 다룰 수 있습니다.

9. 고급 설정 로드맵: 클라이언트 사용에서 설정 설명까지

1단계: 전체 데이터 흐름을 설명할 수 있어야 합니다

고급 설정은 곧바로 대규모 설정을 직접 작성하는 것을 뜻하지 않습니다. 첫 단계에서는 애플리케이션에서 원격 서버까지 요청이 이동하는 전체 경로를 설명하고 각 단계의 확인 방법을 말할 수 있어야 합니다. 애플리케이션이 시스템 프록시를 읽는지, 로컬 포트가 수신 중인지, 코어가 정상적으로 시작되었는지, 라우팅이 어떤 아웃바운드를 선택했는지, 노드 전송 매개변수가 완전한지, DNS가 어디에서 확인되는지를 확인하세요. 이 질문에 답할 수 있으면 막연한 “연결되지 않음”을 구체적인 계층의 문제로 나눌 수 있습니다.

연습할 때는 사용 가능성이 확인된 같은 설정 하나로 시스템 프록시, 수동 애플리케이션 프록시와 TUN을 각각 테스트하고 로그 차이를 기록하세요. 그런 다음 규칙 모드에 명확한 도메인 규칙 하나를 추가해 아웃바운드 태그가 어떻게 바뀌는지 확인합니다. 연습의 목표는 복잡한 환경을 만드는 것이 아니라 조작과 로그 사이의 대응 관계를 익히는 것입니다.

2단계: 클라이언트가 생성한 설정 읽기

그래픽 클라이언트는 최종적으로 인터페이스 옵션을 코어 설정으로 변환해야 합니다. 생성된 설정을 내보내거나 확인할 때는 먼저 인바운드, 아웃바운드, 라우팅과 DNS 네 부분을 찾고 이를 인터페이스 설정과 하나씩 대응시켜 보세요. 아래 예시는 로컬에서만 수신하는 SOCKS 인바운드를 보여 줍니다. 필드를 이해하기 위한 예시이며 연결 가능한 원격 아웃바운드가 없으므로 완전한 설정이 아닙니다.

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ]
}

tag는 설정 내부에서 해당 객체를 참조할 때 사용하고, listen은 수신 주소를 제한하며, port는 로컬 포트, protocol은 인바운드 유형을 지정합니다. 수신 주소를 모든 네트워크 인터페이스로 바꾸면 LAN의 다른 기기가 해당 포트에 접근할 수 있어 보안 경계가 달라집니다. 명확한 공유 목적이 없다면 루프백 주소를 유지하세요. 설정을 배울 때는 기존 필드의 역할부터 이해하고, “최적화”를 위해 출처가 불분명한 매개변수를 추가하지 마세요.

3단계: Xray와 V2Fly 코어의 경계 비교

Xray와 V2Fly는 모두 Project V 관련 생태계에 속하지만 유지 관리 방향과 기능 집합이 완전히 같지는 않습니다. 클라이언트는 담는 역할을 할 뿐, 특정 프로토콜 확장이나 전송 기능을 사용할 수 있는지는 코어와 클라이언트의 설정 변환 방식이 실제로 결정합니다. 같은 공유 링크가 클라이언트마다 다르게 작동한다면 플랫폼 차이로 단순히 돌리지 말고 링크가 사용하는 프로토콜과 보안 기능을 확인한 뒤 대상 코어가 이를 지원하는지 확인해야 합니다.

코어를 비교할 때는 실제 요구 사항을 기준으로 삼아야 합니다. 현재 구독이 어떤 프로토콜을 사용하는지, VLESS, REALITY 또는 XTLS 관련 기능에 의존하는지, 클라이언트가 해당 설정을 올바르게 생성하는지, 로그가 충분한 문제 해결 정보를 제공하는지를 확인하세요. 현재 설정이 양쪽에서 모두 지원하는 일반적인 기능만 사용한다면 플랫폼과 유지 관리 습관에 더 잘 맞는 클라이언트를 선택하면 됩니다. 자세한 비교는 Xray와 V2Fly 코어 차이에서 확인할 수 있습니다.

4단계: 테스트 가능한 규칙 체계 만들기

완성도 높은 라우팅 규칙은 개수로 승부하지 않고 명확한 기본 동작, 그룹 목적과 검증 방법을 갖춥니다. LAN과 예약 주소는 직접 연결하고, 요구에 따라 명확한 도메인 그룹의 아웃바운드를 선택하며, 나머지는 기본 정책으로 보내는 세 그룹부터 시작할 수 있습니다. 각 그룹에 반복해서 테스트할 대상을 하나씩 준비하고 수정 후 로그에서 적용 결과를 확인하세요. 새 규칙을 추가하기 전에 어떤 문제를 해결하는지 설명해야 하며, 목적을 설명할 수 없는 규칙은 장기 설정에 바로 넣지 않는 것이 좋습니다.

DNS 조정도 구체적인 문제를 중심으로 해야 합니다. 확인 경로 때문에 규칙이 적용되지 않거나 시간 초과 또는 결과 불일치가 발생한다는 사실을 확인했을 때만 조회 방식과 라우팅 관계를 수정하세요. DNS, 스니핑, 라우팅 정책과 TUN을 동시에 복잡한 구성으로 바꾸면 단기적으로 우연히 작동할 수 있지만 장기적으로 유지하기 어렵습니다. 고급 설정 능력은 변경 범위를 줄이고 왜 그 변경이 필요한지 설명하는 데서 드러납니다.

5단계: 개인 운영 매뉴얼 만들기

개인 운영 매뉴얼은 길 필요가 없지만 클라이언트와 플랫폼, 설치 패키지 아키텍처, 설정 디렉터리, 로컬 포트, 구독 그룹, 사용자 지정 규칙, TUN 활성화 여부, 업데이트 방식과 되돌리기 절차를 포함해야 합니다. 여기에 최소 테스트 두 가지를 추가하세요. 하나는 시스템 프록시를 확인하고 다른 하나는 라우팅 적용을 확인하는 테스트입니다. 기기를 이전하거나 업그레이드한 뒤 이 목록을 따라 단계별로 복원하면 기억에 의존하는 것보다 훨씬 안정적입니다.

환경에 새로운 문제가 생기면 먼저 운영 매뉴얼에 현상과 처리 결과를 업데이트한 뒤 추가 규칙을 도입할지 결정하세요. 장기간 기록을 쌓으면 자신의 기기와 애플리케이션에 맞는 안정적인 기준선이 만들어집니다. 이때 클라이언트 인터페이스가 바뀌어도 핵심 판단은 인바운드, 아웃바운드, 라우팅, DNS와 트래픽 가로채기를 중심으로 이루어지므로 큰 영향을 받지 않습니다.

입문부터 고급 설정까지의 경로는 다음과 같이 요약할 수 있습니다. 먼저 최소한의 사용 가능한 연결을 만들고 트래픽 가로채기 범위를 넓히세요. 먼저 규칙 적용을 이해하고 규칙 수를 늘리세요. 먼저 복원 가능한 기준선을 만든 뒤 클라이언트와 코어를 업그레이드하세요. 문제가 생기면 무작위로 설정을 바꾸지 말고 항상 데이터 흐름으로 돌아가야 합니다.