V2Ray 초보부터 고급 설정까지 완벽 설정 매뉴얼

01

모델 세우기

핵심 개념: 클라이언트, 코어와 트래픽 경로

그래픽 클라이언트와 프록시 코어를 먼저 구분하기

v2rayN, v2rayNG, v2flyNG는 서로 다른 플랫폼을 위한 그래픽 클라이언트입니다. 구독 저장, 노드 표시, 실행 설정 생성, 시스템 프록시 변경, 시작·중지 작업을 보기 쉬운 화면으로 제공합니다. 실제 연결, 프로토콜, 전송과 라우팅을 처리하는 것은 클라이언트가 호출하는 코어입니다. v2rayN은 데스크톱 시스템에서 해당 코어를 관리할 수 있고, v2rayNG는 Xray 코어를 주요 실행 구성 요소로 사용하며, v2flyNG는 V2Fly 코어에 대응합니다. 문제를 해결할 때는 문제가 화면 계층, 시스템 프록시 계층, 코어 계층 중 어디에서 발생했는지 구분해야 합니다. 화면에 실행 중이라고 표시되는 것은 프로세스가 시작되었다는 뜻일 뿐, 대상 애플리케이션의 트래픽이 로컬 프록시로 들어갔다는 증거는 아닙니다.

Project V는 관련 프로토콜, 도구와 구현으로 이루어진 기술 생태계이며, V2Fly와 Xray는 그 안에서 자주 사용되는 코어 계열입니다. 일반 사용자에게 코어 차이는 주로 프로토콜 지원 범위, 설정 필드와 전송 조합에서 나타납니다. 클라이언트를 선택할 때 모든 하위 필드를 먼저 공부할 필요는 없지만, 구독의 노드 프로토콜은 현재 코어가 인식할 수 있어야 합니다. 예를 들어 노드가 VLESS와 REALITY 조합을 사용한다면 클라이언트와 코어 모두 해당 필드를 지원해야 합니다. 구독 업데이트가 성공했다는 사실만으로 노드 매개변수가 실제로 작동한다고 볼 수는 없습니다.

인바운드·아웃바운드·라우팅으로 하나의 요청 이해하기

V2Ray 설정은 우선 세 부분으로 나눠 생각할 수 있습니다. 인바운드는 로컬 애플리케이션의 트래픽을 받아들이며, 일반적으로 로컬 SOCKS 또는 HTTP 포트를 사용하거나 TUN이 넘겨받은 가상 네트워크 트래픽을 처리합니다. 아웃바운드는 트래픽이 다음에 어디로 갈지를 결정하며, 보통 프록시 아웃바운드, 직접 연결 아웃바운드, 차단 아웃바운드를 포함합니다. 라우팅은 그 사이에서 도메인, IP, 포트, 네트워크 유형 또는 프로세스 등의 조건에 따라 아웃바운드를 선택합니다. 이 흐름을 이해하면 화면의 옵션도 서로 연결됩니다. 시스템 프록시는 애플리케이션이 사용할 인바운드를 지정하고, 노드 선택은 프록시 아웃바운드의 매개변수를 정하며, 분기 규칙은 요청마다 다른 아웃바운드를 선택합니다.

브라우저로 웹사이트에 접속하는 경우를 예로 들어 보겠습니다. 브라우저는 먼저 시스템 프록시 설정에 따라 클라이언트가 수신 대기 중인 로컬 포트로 요청을 보냅니다. 코어는 대상 도메인을 확인한 뒤 위에서부터 라우팅 규칙을 검사합니다. 프록시 규칙에 일치하면 현재 노드로 전달하고, 직접 연결 규칙에 일치하면 로컬 네트워크로 직접 연결합니다. 브라우저가 시스템 프록시를 읽지 않거나 애플리케이션이 자체 네트워크 스택을 구현했거나, 규칙 판단 전에 대상 주소가 잘못 해석되면 트래픽 경로가 달라집니다. 따라서 ‘클라이언트 실행’, ‘시스템 프록시 활성화’, ‘애플리케이션 트래픽 인계’는 각각 따로 확인해야 합니다.

노드·공유 링크·구독은 서로 다른 계층의 객체입니다

노드는 연결을 설정할 수 있는 매개변수 묶음으로, 일반적으로 서버 주소, 포트, 사용자 식별자, 프로토콜, 전송 방식, TLS 옵션과 서버 이름을 포함합니다. 공유 링크는 단일 노드를 직렬화한 표현으로, 예를 들어 vmess:// 또는 vless://로 시작하는 텍스트입니다. 구독 주소는 여러 노드나 그룹 설정을 가져오고 이후 업데이트하는 데 사용됩니다. 구독은 프록시 서버 자체가 아니라 새로고침할 수 있는 목록에 가깝습니다. 로컬에서 구독을 삭제해도 원격 내용은 바뀌지 않으며, 구독에서 생성된 개별 노드를 수정해도 다음 업데이트에서 덮어써질 수 있습니다.

프로토콜과 전송도 계층을 나누어 이해해야 합니다. VMess, VLESS 등은 연결 프로토콜을 설명하고, TCP, WebSocket, gRPC 등은 이를 전달하는 방식을 설명하며, TLS, REALITY 등은 특정 보안 및 핸드셰이크 조합을 담당합니다. 각 필드는 서버 설정과 일치해야 하므로 로컬 옵션을 무작정 바꿔 가며 추측해서는 안 됩니다. 용어를 더 확인하려면 용어 설명 →을 참고하세요. 이 구조를 먼저 익힌 뒤 설치와 설정으로 넘어가면 ‘구독 업데이트 실패’, ‘노드 핸드셰이크 실패’, ‘시스템이 트래픽을 인계하지 않음’을 같은 문제로 혼동하지 않게 됩니다.

02

환경 준비

클라이언트 선택과 설치 완료

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

데스크톱에서는 구독 관리, 시스템 프록시, 라우팅 규칙과 TUN이 필요한 사용자에게 적합한 v2rayN을 우선 권장합니다. Android에서는 v2rayNG 또는 v2flyNG를 선택할 수 있습니다. v2rayNG는 Xray 코어를 사용하므로 최신 Xray 프로토콜 조합이 포함된 구독에 적합하고, v2flyNG는 V2Fly 코어를 사용하므로 V2Fly 설정 체계에 맞는 선택입니다. 세 클라이언트의 설치 경로, 시스템 아키텍처와 설치 패키지 유형은 다운로드 페이지 →에 모아 두었습니다. 파일명에 비슷한 단어가 있다는 이유만으로 플랫폼을 판단하지 마세요.

Windows, macOS, Linux별 설치 시 유의 사항

Windows 사용자는 먼저 데스크톱 버전과 클래식 WPF 버전 중 하나를 선택해야 합니다. 데스크톱 버전은 크로스플랫폼 인터페이스를 사용하므로 여러 데스크톱 시스템에서 같은 방식으로 조작하고 싶은 사용자에게 적합합니다. 클래식 WPF 버전은 기존 Windows 화면과 설정 절차에 익숙한 사용자에게 알맞습니다. 두 버전이 동시에 시스템 프록시를 인계하도록 해서는 안 됩니다. 버전을 바꾸기 전 실행 중인 클라이언트를 종료하고 구독 주소, 라우팅 설정과 사용자 지정 포트를 기록하세요. 시스템 트레이에 이전 프로세스가 남아 있다면 사용 중인 프로그램 폴더를 바로 삭제하지 말고 정상적으로 종료해야 합니다.

macOS 설치에서 가장 중요한 것은 칩 아키텍처입니다. Apple Silicon 기기는 arm64 설치 패키지를, Intel 기기는 x64 패키지를 선택하세요. 시스템 정보에서 칩 유형을 확인할 수 있습니다. 처음 실행할 때 애플리케이션 실행 권한을 확인하라는 메시지가 나타날 수 있으며, 시스템 프록시나 TUN을 활성화할 때 네트워크 설정 권한이 추가로 필요할 수 있습니다. 이 권한은 해당 시스템 네트워크 설정을 기록하는 데만 사용되며, 취소하면 관련 모드를 완전히 활성화하기 어렵습니다. 애플리케이션을 다른 폴더로 옮기면 시스템이 기록한 경로가 달라질 수 있으므로, 고정된 위치에 둔 뒤 로그인 시 자동 실행을 설정하는 것이 좋습니다.

Linux 사용자는 먼저 배포판에 맞춰 deb 또는 rpm 패키지를 선택한 뒤 프로세서 아키텍처를 확인하세요. Debian, Ubuntu와 파생 배포판은 대체로 deb를 사용하고, Fedora, Rocky Linux 등은 일반적으로 rpm 계열 패키지를 사용합니다. 데스크톱 환경마다 시스템 프록시 인터페이스가 다르므로 클라이언트가 설정을 기록한 뒤 데스크톱 네트워크 패널에서 HTTP, HTTPS 또는 SOCKS 프록시가 로컬 수신 주소를 가리키는지 다시 확인하세요. 터미널에서만 실행되는 프로그램은 데스크톱 프록시를 자동으로 읽지 않는 경우가 많아 환경 변수를 명시하거나 TUN을 사용해야 할 수 있습니다.

Android 설치 및 백그라운드 실행 조건

최근 주류 Android 기기는 대체로 arm64를 사용하며, 아키텍처를 확인할 수 없다면 범용 설치 패키지를 선택할 수 있습니다. 설치 후 처음 연결을 만들 때 시스템 네트워크 연결 권한 요청이 나타나는데, 이는 로컬 네트워크 인계를 만드는 데 필요한 표준 절차입니다. v2rayNG와 v2flyNG를 동시에 연결 상태로 유지해서는 안 됩니다. 나중에 시작한 클라이언트가 시스템에서 제공하는 네트워크 인계 채널을 차지하기 때문입니다. 클라이언트를 바꿀 때는 먼저 현재 연결을 끊고 같은 구독을 가져와 호환성을 비교하세요.

모바일 운영체제는 화면이 꺼진 뒤 백그라운드 프로세스를 제한할 수 있습니다. 잠금 상태가 일정 시간 이어진 후 연결이 끊긴다면 먼저 클라이언트의 배터리 사용 정책, 백그라운드 활동 권한과 절전 규칙을 확인하세요. 노드 매개변수부터 바꿀 필요는 없습니다. 모바일 네트워크와 Wi-Fi가 전환되면 기존 연결이 끊길 수 있고, 코어는 아웃바운드를 다시 설정해야 합니다. 이때 잠시 끊기는 것은 네트워크 환경 변화로 볼 수 있으며, 계속 복구되지 않을 때 로그를 확인하면 됩니다. 클라이언트를 최근 앱 목록에 고정하거나 백그라운드 활동을 허용하면 시스템 회수로 인한 중단을 줄일 수 있습니다.

설치 후 최소 점검부터 진행하기

설치가 끝나면 먼저 클라이언트를 실행하되, TUN·복잡한 라우팅·사용자 지정 DNS는 잠시 활성화하지 마세요. 화면이 정상적으로 열리는지, 코어 구성 요소가 시작되는지, 로그 디렉터리에 쓸 수 있는지 확인하고 기본 로컬 포트를 기록합니다. 그런 다음 확실히 유효한 구독 또는 노드 하나를 가져와 시스템 프록시로 처음 연결을 테스트하세요. 최소 설정은 기준선을 만들어 줍니다. 이 상태에서 정상 작동한다면 이후 문제는 대개 새로 추가한 라우팅, DNS 또는 TUN 옵션에서 발생합니다. 최소 설정부터 실패한다면 구독, 노드 매개변수와 로컬 포트 점유 상태를 먼저 확인해야 합니다.

03

설정 구축

구독 가져오기, 노드 선택과 업데이트

구독 주소의 범위를 가져오기 전에 확인하기

구독 주소는 대개 HTTPS 주소이며, 클라이언트는 이를 통해 노드 목록을 가져옵니다. 복사할 때 전체 경로와 쿼리 매개변수를 포함해야 합니다. 도메인 부분만 복사하거나 페이지 표시 주소와 구독 API 주소를 혼동하지 마세요. 주소 앞뒤에 공백이나 줄바꿈이 있다면 저장 전에 제거합니다. 구독은 신중하게 보관해야 하는 설정 진입점이므로 공개 스크린샷, 로그 게시물 또는 다른 사람이 읽을 수 있는 동기화 문서에 넣어서는 안 됩니다. 제공자가 주소를 변경했다면 클라이언트에서 구독 항목을 업데이트하고, 이전 주소로 생성된 노드를 계속 수정하지 마세요.

v2rayN에서는 보통 구독 그룹 관리로 이동해 구독 이름과 주소를 추가하고 저장한 뒤 업데이트를 실행합니다. v2rayNG 또는 v2flyNG에서는 구독 설정에서 항목을 추가한 다음 메인 화면으로 돌아와 새로고침합니다. 이름은 로컬 식별용이므로 용도나 환경을 나타내는 이름을 사용하면 됩니다. 가져오기가 끝난 뒤에는 구독 그룹만이 아니라 노드 항목이 표시되어야 합니다. 업데이트 성공 메시지가 떴는데 목록이 비어 있다면 응답 내용이 클라이언트가 인식할 수 있는 구독 형식인지, 현재 그룹 필터가 새 항목을 숨기고 있지 않은지 확인하세요.

구독 업데이트로 덮어써지는 항목

구독 노드는 원격 목록에서 생성되므로 다시 업데이트할 때 같은 노드의 서버, 포트, 프로토콜과 전송 매개변수가 바뀔 수 있습니다. 구독 노드를 직접 편집하는 방식은 임시 진단에는 쓸 수 있지만 장기적인 수정 방법으로는 적합하지 않습니다. 사용자 지정 노드를 보존해야 한다면 별도의 수동 그룹을 만들거나 로컬 노드로 복사하고 용도를 분명히 알 수 있는 이름을 붙이세요. 라우팅 규칙, 시스템 프록시 모드와 로컬 수신 포트는 보통 클라이언트 설정이므로 구독 업데이트로 원격 값에 자동 변경되지는 않습니다. 다만 일부 구독은 그룹이나 규칙 정보를 포함할 수 있으므로 가져오기 미리보기에서 확인해야 합니다.

합리적인 업데이트 순서는 다음과 같습니다. 먼저 중요한 연결을 중지하고 구독을 업데이트한 뒤 추가·삭제된 항목과 이름 변화를 확인합니다. 그다음 노드 하나를 선택해 테스트하세요. 업데이트 직후 DNS, 라우팅, 프록시 모드를 동시에 수정하지 마세요. 문제가 생겼을 때 원인을 구분하기 어려워집니다. 이전 노드가 사라졌다면 먼저 구독 목록이 변경되었는지 확인하고, 노드는 남아 있지만 연결되지 않는다면 프로토콜 필드의 변화와 코어 지원 여부를 살펴보세요.

노드 선택 시 단일 테스트 결과에 의존하지 않기

클라이언트가 제공하는 연결성 테스트, 지연 시간 테스트와 실제 연결 테스트는 검사 대상이 완전히 같지 않습니다. TCP 포트에 연결된다는 것은 지정된 포트까지 네트워크가 도달했다는 뜻일 뿐입니다. 프로토콜 핸드셰이크가 성공해야 주요 매개변수가 일치한다고 볼 수 있고, 대상 웹사이트 접속 여부에는 DNS, 라우팅과 대상 서비스 상태도 영향을 줍니다. 따라서 한 가지 테스트 결과만으로 전체 접속을 판단해서는 안 됩니다. 더 안전한 방법은 노드를 선택하고 시스템 프록시를 활성화한 뒤 정상 작동을 확인한 HTTPS 페이지에 접속하면서 클라이언트 로그에 해당 연결 기록이 남는지 확인하는 것입니다.

노드 이름은 용도를 식별하는 데 도움이 되지만 프로토콜의 사실로 간주해서는 안 됩니다. 노드 상세 정보에서 address, port, 프로토콜 유형, 전송 방식, TLS 활성화 여부, serverName과 관련 식별자를 확인하세요. 구독에 여러 프로토콜 조합이 있다면 현재 클라이언트 코어가 명확히 지원하는 노드를 우선 선택합니다. v2rayNG와 v2flyNG에서 같은 구독의 표시 항목이 다를 수 있는데, 이는 대개 코어 지원 범위나 구독 변환 결과와 관련 있으며 구독 주소 자체가 반드시 만료되었다는 뜻은 아닙니다.

공유 링크와 JSON 수동 가져오기

단일 노드 공유 링크는 임시 가져오기나 개별 테스트에 적합합니다. 가져오기 전에 접두사가 클라이언트가 지원하는 프로토콜인지 확인한 뒤 ‘클립보드에서 가져오기’와 같은 기능을 사용하세요. 여러 링크를 한 번에 복사할 때는 한 줄에 완전한 링크 하나만 있도록 해야 합니다. JSON 설정에는 인바운드, 아웃바운드, 라우팅과 DNS 정보가 더 많이 포함되므로 그래픽 클라이언트가 자동 생성한 설정과 직접 섞어서는 안 됩니다. 클라이언트가 ‘사용자 지정 설정’ 기능을 제공한다면 별도 설정 항목에서 실행하여 자동 노드 설정이 해당 필드를 덮어쓰지 않도록 하세요.

{
  "address": "server.example.com",
  "port": 443,
  "id": "11111111-2222-3333-4444-555555555555",
  "security": "auto",
  "network": "tcp",
  "tls": "tls",
  "serverName": "service.example.com"
}

위 필드는 노드 매개변수 간 관계만 보여 주며, 바로 연결할 수 있는 서비스를 의미하지 않습니다. 실제 설정에서는 주소, 포트, 사용자 식별자, 전송 방식과 서버 이름이 서버 측과 일치해야 합니다. 핸드셰이크 오류가 발생하면 암호화나 TLS 옵션을 무작정 바꾸지 말고 하나씩 대조하세요. 공유 링크와 구독의 차이를 더 이해하려면 vmess 링크와 구독 주소의 차이 →를 읽어 보세요.

04

트래픽 인계

시스템 프록시, 로컬 포트와 애플리케이션 범위

시스템 프록시는 애플리케이션의 접속 입구를 바꿉니다

시스템 프록시 모드는 운영체제의 프록시 주소를 클라이언트의 로컬 수신 포트로 지정합니다. 시스템 프록시를 읽는 브라우저와 데스크톱 애플리케이션은 이후 해당 포트로 요청을 전달하고, 코어가 라우팅과 아웃바운드 연결을 처리합니다. 모든 네트워크 패킷을 자동으로 바꾸는 것은 아니며 모든 프로그램이 시스템 설정을 따른다고 보장할 수도 없습니다. 일부 명령줄 도구, 게임, 가상 머신, 컨테이너와 자체 네트워크 스택을 사용하는 프로그램은 시스템 프록시를 무시할 수 있습니다. ‘브라우저는 되는데 다른 프로그램은 안 된다’면 먼저 대상 프로그램이 HTTP 또는 SOCKS 프록시를 지원하는지 확인하세요. 노드를 의심하는 것은 그다음입니다.

클라이언트 화면에는 ‘시스템 프록시 지우기’, ‘시스템 프록시 설정’, ‘시스템 프록시 변경 안 함’과 같은 상태가 표시됩니다. 시스템 프록시 설정은 일반적인 데스크톱 애플리케이션에 적합하고, 지우기는 종료 시 시스템 네트워크를 복원하는 데 사용되며, 변경 안 함은 로컬 포트만 시작하고 사용자가 애플리케이션별로 직접 입력하는 방식입니다. 클라이언트를 종료하기 전에는 정상 종료 절차를 사용해 기존 설정을 복원하세요. 프로그램을 강제 종료하면 시스템에 로컬 포트를 가리키는 프록시 주소가 남아 클라이언트가 꺼진 뒤 웹페이지에 접속하지 못할 수 있습니다. 이때는 클라이언트를 다시 열어 시스템 프록시를 지우거나 시스템 네트워크 설정에서 직접 복원하세요.

HTTP·SOCKS·혼합 포트의 차이

HTTP 프록시는 브라우저와 CONNECT를 지원하는 애플리케이션에 적합합니다. SOCKS 프록시는 더 다양한 TCP 요청을 전달할 수 있으며 애플리케이션 구현에 따라 도메인 해석도 처리할 수 있습니다. 일부 클라이언트는 하나의 수신 주소에서 HTTP와 SOCKS 요청을 식별하는 혼합 포트를 제공합니다. 포트 번호 자체에는 프로토콜 기능이 없고, 해당 포트에 연결된 인바운드 유형이 중요합니다. 애플리케이션을 수동 설정할 때는 선택한 프록시 유형이 클라이언트의 수신 유형과 일치해야 합니다. SOCKS 포트를 HTTP 프록지만 받는 입력란에 넣으면 대개 즉시 연결이 실패합니다.

명령줄 도구는 프록시 변수를 명시적으로 확인해야 함

Linux, macOS 또는 Windows 터미널에서 실행되는 많은 도구는 데스크톱 프록시 설정을 자동으로 읽지 않습니다. 현재 명령이나 현재 터미널 세션에 프록시 환경 변수를 설정할 수 있습니다. 다음 예시는 클라이언트의 HTTP 인바운드가 로컬 10809 포트에서 수신 대기한다고 가정합니다. 실제 사용 시에는 클라이언트 화면에 표시된 값을 기준으로 하세요. 환경 변수 이름은 대소문자와 도구에 따라 다를 수 있으므로 설정 후 도구 자체의 상세 출력으로 적용 여부를 확인해야 합니다.

export http_proxy="http://127.0.0.1:10809"
export https_proxy="http://127.0.0.1:10809"

curl -I https://example.com

unset http_proxy
unset https_proxy

SOCKS 인바운드를 사용하는 경우 일부 도구는 socks5h://127.0.0.1:10808을 지원합니다. h가 붙은 형식은 일반적으로 도메인 해석도 프록시 측에서 처리한다는 뜻으로, 로컬 해석 결과와 라우팅 예상이 어긋나는 문제를 줄이는 데 도움이 됩니다. 모든 프로그램이 이 표기를 인식하는 것은 아니므로 프로그램 자체의 매개변수를 확인하세요. 클라이언트가 안정적으로 시작하는지 확인하기 전에는 환경 변수를 전역 시작 파일에 영구적으로 기록하지 마세요. 클라이언트가 중지된 뒤 해당 변수를 상속받은 모든 터미널 프로그램이 존재하지 않는 로컬 서비스를 계속 연결하려 할 수 있습니다.

로컬 포트가 실제로 수신 대기 중인지 확인하기

애플리케이션에 ‘연결이 거부됨’이 표시되면 원격 서버보다 먼저 로컬 인바운드를 확인해야 합니다. Windows에서는 PowerShell로 수신 대기 상태를 확인할 수 있고, Linux에서는 ss를 사용할 수 있습니다. 포트가 수신 대기하지 않는다면 코어 미실행, 설정 생성 실패, 다른 프로세스의 포트 점유 또는 보안 정책에 의한 바인딩 차단이 원인일 수 있습니다. 포트는 정상적으로 열려 있지만 접속 로그가 전혀 없다면 애플리케이션 트래픽이 해당 인바운드로 들어오지 않은 것입니다. 인바운드 기록이 있고 원격 핸드셰이크 오류가 나타날 때에만 노드 매개변수를 점검하세요.

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -In 10808,10809

ss -lntp | grep -E '10808|10809'

여러 클라이언트를 동시에 실행할 때는 같은 로컬 포트를 사용하지 말고, 두 클라이언트가 동시에 시스템 프록시를 기록하게 하지 마세요. 테스트 중인 두 번째 클라이언트에는 다른 포트를 사용하고 시스템 프록시는 현재 검증할 클라이언트 하나를 가리키도록 하는 것이 좋습니다. 비교가 끝나면 사용하지 않는 수신 설정을 정리해 자동 시작 시 포트 충돌을 피하세요. 프록시 모드의 목적은 명확하고 관찰 가능한 트래픽 입구를 만드는 것이지 모든 스위치를 동시에 켜는 것이 아닙니다.

05

출구 제어

라우팅 분기 규칙과 매칭 순서

라우팅 규칙의 본질은 아웃바운드 선택입니다

라우팅은 노드 프로토콜을 바꾸지 않고 특정 트래픽이 사용할 아웃바운드만 결정합니다. 일반적인 아웃바운드 태그에는 proxy, direct, block이 있으며 각각 프록시 연결, 직접 연결, 차단을 뜻합니다. 규칙은 도메인, IP, 포트, 네트워크 유형과 인바운드 태그를 기준으로 매칭할 수 있습니다. 그래픽 클라이언트의 ‘글로벌’, ‘LAN 우회’, ‘규칙 모드’ 같은 이름은 일련의 라우팅 동작을 화면에 묶어 표현한 것입니다. 실제 결과는 생성된 설정의 규칙 순서, 조건과 최종 기본 아웃바운드에 따라 결정됩니다.

규칙을 만들 때는 먼저 대상이 명확한 좁은 범위의 규칙을 작성하고, 넓은 범위의 집합을 처리한 뒤 기본 경로를 남겨 두세요. 예를 들어 로컬 및 LAN 주소는 일반적으로 직접 연결을 우선하고, 명확히 차단할 도메인은 일반 프록시 규칙보다 앞에 둡니다. 나머지 요청은 프록시 또는 직접 연결로 보냅니다. 적용 범위가 매우 큰 규칙을 위에 배치하면 뒤의 세부 규칙은 실행되지 않습니다. ‘규칙을 작성했는데 적용되지 않는다’면 가장 먼저 더 앞선 규칙에 이미 매칭된 것은 아닌지 확인하세요.

도메인 규칙과 IP 규칙은 서로 다른 판단 단계에 있습니다

도메인 규칙은 요청에 포함된 도메인으로 매칭하며, 완전한 도메인, 하위 도메인 접미사, 키워드 또는 geosite 분류를 사용할 수 있습니다. IP 규칙은 대상 IP로 매칭하며 CIDR 대역이나 geoip 분류를 사용할 수 있습니다. 요청에 도메인과 IP 정보가 모두 있는지는 인바운드 프로토콜, DNS 정책과 도메인 해석 수행 여부에 따라 달라집니다. IP 규칙만 사용하면 코어가 먼저 도메인을 해석해야 할 수 있습니다. 해석 경로가 예상한 아웃바운드와 다르면 순환이나 잘못된 결과가 발생할 수 있습니다. 따라서 도메인으로 안정적으로 표현할 수 있는 서비스는 도메인 규칙을 우선 사용하고, 네트워크 주소 범위에는 IP 규칙을 사용하세요.

domain:은 일반적으로 정확한 도메인을 뜻하고, full:은 완전 일치를 강조하며, keyword:는 지정한 텍스트가 포함된 도메인을 매칭하므로 범위가 넓어 신중히 사용해야 합니다. geosite:와 geoip:는 분류 데이터 집합을 참조하므로 대량의 규칙을 관리하기에 적합하지만, 분류 데이터는 클라이언트 리소스와 함께 업데이트해야 합니다. 사용자 지정 규칙은 이해하기 쉬운 이름을 사용하고 외부 문서에 주석과 함께 기록하여 몇 달 뒤 출처와 필요성을 확인할 수 있도록 하세요.

최소 라우팅 설정의 구조

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

domainStrategy는 도메인 규칙으로 바로 결과가 나오지 않을 때 IP를 해석할지, 해석한다면 언제 할지를 결정합니다. AsIs는 원래 도메인으로 매칭하는 경향이 있어 IP 규칙을 위해 적극적으로 해석하지 않습니다. IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 IP를 해석한 뒤 IP 조건을 계속 확인합니다. 일부 코어에는 더 적극적인 해석 정책도 있습니다. 선택할 때는 DNS 설정과 규칙의 목적을 고려해야 하며, ‘더 많이 해석한다’고 해서 반드시 더 정확한 것은 아닙니다. 도메인 규칙이 이미 충분하다면 단순한 정책을 유지하고, 대상 대역을 기준으로 분기해야 할 때만 추가 해석을 도입하세요.

간단한 규칙부터 단계적으로 확장하기

처음 라우팅을 설정할 때는 사설 네트워크 직접 연결, 명확한 도메인 규칙, 그 밖의 트래픽을 기본 아웃바운드로 보내는 세 단계만 유지하는 것이 좋습니다. 안정적으로 작동하는 것을 확인한 뒤 광고 차단, 특정 프로세스, 포트 또는 프로토콜 규칙을 추가하세요. 출처가 불분명한 규칙을 한꺼번에 많이 넣으면 문제를 찾기 어려워지고 소프트웨어 업데이트, LAN 장치 검색 또는 DNS 요청이 잘못된 아웃바운드로 전달될 수 있습니다. 규칙을 추가할 때마다 직접 연결되어야 하는 대상 하나와 프록시되어야 하는 대상 하나 이상을 확인하고 로그에서 최종 아웃바운드 태그를 확인하세요.

포트 규칙은 대상 포트가 분명한 프로토콜을 처리하는 데 적합하지만, 현대 서비스는 443 포트를 공유하는 경우가 많아 포트만으로 특정 사이트를 구분할 수 없습니다. 프로세스 규칙은 플랫폼과 인계 방식에 의존하므로 시스템 프록시 모드에서는 완전한 프로세스 정보를 얻지 못할 수 있고, TUN 환경의 지원 여부도 클라이언트 구현에 따라 달라집니다. 한 플랫폼에서 작동한 프로세스 규칙을 모든 기기에 그대로 복사하지 마세요. 여러 플랫폼에서 동기화할 때는 도메인과 IP 규칙을 우선 맞추고, 프로세스 조건은 플랫폼별로 관리하세요.

라우팅 문제는 최종 매칭 결과를 확인해야 합니다

웹사이트가 잘못된 출구로 연결되면 먼저 요청 도메인을 기록하고 로그에서 해당 연결의 outbound 태그를 찾으세요. 로그에 IP만 표시된다면 DNS와 스니핑 설정이 도메인을 보존하는지 확인합니다. 그다음 규칙 목록의 위에서부터 해당 도메인이나 IP가 앞에서 매칭될 가능성이 있는지 하나씩 판단하세요. 대상 도메인을 임시로 첫 번째 명시 규칙에 넣어 우선순위가 원인인지 확인할 수 있습니다. 확인이 끝나면 해당 규칙을 적절한 위치로 옮기고, 예외 규칙을 계속 최상단에 두지는 마세요.

중국 본토 네트워크 환경에서 국내 트래픽은 직접 연결하고 해외 트래픽은 프록시로 보내는 방법은 라우팅 분기 규칙 실전 →에서 더 확인할 수 있습니다. 설정 전에 규칙 데이터와 클라이언트 리소스가 정상적으로 사용 가능한지도 확인하세요. 라우팅은 결정적인 매칭 절차입니다. 대상, 매칭 규칙과 아웃바운드 태그 세 가지 증거만 남기면 노드를 무작정 바꾸지 않고도 계층별로 원인을 찾을 수 있습니다.

06

더 많은 애플리케이션에 적용하기

TUN 모드, DNS와 라우팅 테이블 연동

TUN은 시스템 프록시가 다루지 못하는 트래픽을 처리합니다

TUN 모드는 가상 네트워크 인터페이스로 시스템 트래픽을 받은 뒤 코어에 전달해 라우팅하고 포워딩합니다. 시스템 프록시를 읽지 않는 애플리케이션, 일부 명령줄 프로그램과 데스크톱 환경 전체를 인계해야 하는 경우에 적합합니다. 시스템 프록시보다 네트워크 계층에 가깝기 때문에 가상 인터페이스 주소, 시스템 라우팅, DNS 인계, MTU, 우회 주소와 권한 등 더 많은 요소가 결과에 영향을 줍니다. TUN을 처음 사용할 때는 먼저 일반 시스템 프록시 모드에서 같은 노드가 연결되는지 확인하여 노드 문제와 TUN 환경 문제를 분리하세요.

활성화할 때 클라이언트는 일반적으로 가상 인터페이스를 만들고 라우팅을 기록하기 위한 시스템 네트워크 권한을 요구합니다. 클라이언트를 정상 종료하면 이러한 임시 설정도 삭제되어야 합니다. 프로세스가 비정상적으로 종료되면 이전 인터페이스나 라우팅이 남을 수 있습니다. ‘클라이언트를 닫은 뒤에도 네트워크가 이상하다’면 먼저 클라이언트를 다시 시작해 TUN을 정상적으로 종료한 뒤 시스템 네트워크 인터페이스와 기본 라우팅을 확인하세요. 가상 네트워크 카드나 라우팅 테이블을 수정하는 도구를 여러 개 동시에 실행하면 같은 대상 대역이 서로 다른 규칙으로 반복 덮어써질 수 있습니다.

DNS는 라우팅에 보이는 정보를 결정합니다

애플리케이션이 도메인에 접속하려면 먼저 해석 결과를 얻어야 합니다. DNS 요청이 클라이언트를 우회하면 코어는 이후 연결의 IP만 볼 수 있습니다. DNS 요청이 TUN에 의해 인계되면 도메인 규칙에 따라 DNS 서버와 아웃바운드를 선택할 수 있습니다. 모든 조회를 같은 경로로 보내는 것이 목표가 아니라, 해석 결과·라우팅 판단·실제 연결을 일치시키는 것이 목표입니다. 예를 들어 직접 연결할 내부 도메인은 해당 내부 영역을 해석할 수 있는 DNS가 처리해야 하고, 도메인 기준으로 프록시할 요청은 코어가 규칙 매칭에 사용할 원래 도메인을 계속 얻을 수 있어야 합니다.

일반적인 문제로는 도메인 해석은 성공했지만 접근할 수 없는 주소가 반환되는 경우, DNS 요청이 로컬 인바운드로 다시 라우팅되어 순환하는 경우, 애플리케이션이 이전 결과를 캐시한 경우, IPv6 결과가 우선되지만 현재 경로가 이를 지원하지 않는 경우, 브라우저가 별도 DNS 설정을 사용해 시스템 방식을 우회하는 경우가 있습니다. 문제를 해결할 때는 먼저 애플리케이션과 시스템 DNS 캐시를 정리하고 클라이언트 로그에 조회 기록이 남는지 확인하세요. 대상 IP에 직접 접속되는데 도메인만 실패한다면 DNS를 중점적으로 확인하고, 도메인은 해석되었지만 핸드셰이크에서 연결이 실패한다면 노드와 전송 매개변수로 돌아가세요.

Fake DNS와 실제 DNS 사용 범위

일부 TUN 설정은 Fake DNS를 사용합니다. 코어가 먼저 애플리케이션에 예약 주소를 반환한 뒤 매핑 정보를 통해 원래 도메인을 복원하고 라우팅합니다. 이를 통해 도메인 정보를 보존하고 애플리케이션이 도메인 규칙을 우회하는 상황을 줄일 수 있습니다. 하지만 관련 트래픽이 계속 같은 코어의 매핑을 통과해야 합니다. 애플리케이션이 예약 주소를 캐시한 상태에서 클라이언트가 중지되면 접속이 실패할 수 있습니다. LAN 서비스, 실제 IP가 필요한 프로그램과 일부 P2P 환경은 일반적으로 제외 범위에 넣어야 하며, 모든 트래픽을 Fake DNS로 처리하는 것은 적합하지 않습니다.

활성화 여부는 실제 필요에 따라 결정하세요. 일반 브라우저와 시스템 프록시를 지원하는 애플리케이션이 이미 안정적으로 작동한다면 ‘설정을 더 완전하게’ 만들기 위해 켤 필요는 없습니다. 시스템 프록시를 따르지 않는 특정 프로그램까지 인계해야 한다면 먼저 실제 DNS를 사용하는 TUN 설정으로 라우팅과 MTU가 정상인지 확인한 뒤 Fake DNS 도입을 검토하세요. 처리 계층을 하나 추가할 때마다 비활성화했을 때의 비교 결과를 남겨야 합니다.

MTU, IPv6와 LAN 우회

MTU는 가상 인터페이스가 하나의 패킷에 담을 수 있는 크기를 결정합니다. 값을 너무 크게 설정하면 일부 네트워크 경로에서 단편화나 패킷 손실이 발생해 작은 페이지는 열리지만 큰 응답이 멈출 수 있습니다. 너무 작으면 불필요한 오버헤드가 늘어납니다. 뚜렷한 증상이 없다면 클라이언트 기본값을 유지하세요. 특정 네트워크에서만 TLS 핸드셰이크가 멈추거나 업로드가 실패한다면 MTU를 조금씩 낮춰 비교하고, 변경할 때마다 TUN 인터페이스를 다시 만들며 결과를 기록하세요. 여러 네트워크 매개변수를 연속으로 바꾸지는 마세요.

IPv6는 시스템, DNS, 노드와 아웃바운드 경로 네 계층에서 함께 봐야 합니다. 시스템이 IPv6 주소를 받았다고 해서 프록시 아웃바운드가 반드시 이를 지원하는 것은 아닙니다. DNS가 AAAA 레코드를 반환하면 애플리케이션이 IPv6를 먼저 시도할 수 있습니다. 현재 설정에 완전한 IPv6 라우팅이 없다면 시스템과 클라이언트 사이에서 일부만 활성화하거나 차단하지 말고 클라이언트가 제공하는 정책을 명확히 사용하세요. LAN 대역은 일반적으로 직접 우회하여 프린터, 라우터 관리 페이지, 파일 공유와 로컬 개발 서비스가 원격 아웃바운드로 전송되지 않게 해야 합니다.

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "port": "53",
        "network": "udp",
        "outboundTag": "dns-out"
      }
    ]
  }
}

예시는 규칙 관계를 보여 줍니다. 사설 주소는 우선 직접 연결하고 조건에 맞는 DNS 트래픽은 전용 아웃바운드로 보냅니다. 실제 설정에는 dns-out이라는 이름의 아웃바운드가 반드시 정의되어 있어야 하며, 그렇지 않으면 규칙 참조가 실패합니다. 그래픽 클라이언트가 이러한 구조를 자동 생성할 수 있으므로 생성 로직을 이해하지 못한 상태에서 전체 설정을 바로 덮어쓰지 마세요. 사용자 지정이 필요하다면 먼저 현재 실행 설정을 내보내 인바운드와 아웃바운드 태그를 확인한 후 최소 규칙을 추가하세요.

네 단계로 TUN 활성화하기

1단계에서는 시스템 프록시 모드로 노드와 구독을 검증합니다. 2단계에서는 네트워크 라우팅을 기록하는 다른 프로그램을 종료합니다. 3단계에서는 기본 DNS와 MTU를 유지한 채 TUN을 활성화하고 브라우저, 명령줄 도구와 LAN 주소를 테스트합니다. 4단계에서 로그를 바탕으로 DNS 분기나 우회 규칙을 추가합니다. 어느 단계에서 실패하면 이전 단계로 돌아가 확인하고 Fake DNS 활성화, MTU 변경, IPv6 전환과 대규모 라우팅 가져오기를 동시에 진행하지 마세요. 안정적인 TUN 설정은 스위치의 개수가 아니라 계층별 검증에서 나옵니다.

07

안정적으로 유지하기

일상 유지 관리, 로그 읽기와 문제 해결

업데이트를 클라이언트·코어·구독·규칙 데이터로 나누기

일상적인 유지 관리는 클라이언트를 반복해서 재설치하는 것이 아닙니다. 최소한 네 가지 대상을 확인해야 합니다. 그래픽 클라이언트는 화면과 설정 생성을 담당하고, 코어는 프로토콜을 실행하며, 구독은 노드 매개변수를 제공하고, 규칙 데이터는 geosite와 geoip 분류를 제공합니다. 이들의 업데이트 주기와 관리 방식은 서로 다를 수 있습니다. 문제가 발생하면 최근 변경된 계층을 기록하세요. 클라이언트 업데이트 후 화면 동작이 이상해진 문제와 구독 업데이트 후 특정 노드만 작동하지 않는 문제는 다릅니다. 규칙 데이터가 오래된 경우에는 모든 노드가 동시에 시작되지 않기보다 분류 매칭이 어긋나는 형태로 나타날 가능성이 높습니다.

업데이트 전에 구독 이름, 사용자 지정 라우팅, 로컬 포트와 중요한 스크린샷을 보관하세요. 업데이트 후에는 기존 노드와 단순한 시스템 프록시로 먼저 확인한 다음 TUN이나 복잡한 규칙을 복원합니다. 클라이언트 업데이트, 구독 새로고침과 라우팅 대규모 수정은 한 번의 작업에 함께 진행하지 마세요. 되돌려야 한다면 가장 최근에 변경한 한 항목만 되돌리고 설정 디렉터리가 여전히 호환되는지 확인하세요. 자동 시작을 사용하는 경우 업데이트 후 시작 경로가 바뀌지 않았는지, 시스템 트레이에 이전 프로세스가 남아 있지 않은지도 확인해야 합니다.

로그는 시간과 연결 단계에 따라 읽기

유효한 로그에는 일반적으로 설정 로드, 인바운드 수신 대기, DNS 조회, 라우팅 결과, 아웃바운드 다이얼링과 프로토콜 핸드셰이크 단계가 포함됩니다. 문제를 확인할 때는 먼저 이전 로그를 지우거나 현재 시간을 기록한 뒤 대상 작업을 한 번만 실행하세요. 오래된 기록이 많으면 실제 오류가 묻힐 수 있습니다. connection refused가 보이면 거부가 로컬 포트에서 발생했는지 원격 주소에서 발생했는지 구분해야 합니다. 시간 초과라면 DNS, TCP 연결 설정, 프로토콜 핸드셰이크 중 어느 단계에서 발생했는지 판단하세요. 설정 필드 오류가 보인다면 코어가 네트워크 연결 단계에 진입하기도 전이라는 뜻입니다.

상세 정보를 얻기 위해 로그 수준을 일시적으로 높일 수 있지만, 장기간 높은 수준을 유지하면 파일이 많이 생성되고 접속 도메인과 같은 실행 정보가 기록될 수 있습니다. 문제 해결 후에는 일반 수준으로 되돌리세요. 로그를 공유하기 전에는 구독 주소, 서버 주소, 사용자 식별자, 인증 필드와 로컬 경로를 삭제하고 오류 유형, 발생 단계와 필요한 맥락만 남겨야 합니다. 마지막 한 줄만 잘라 공유하지 마세요. 실제 원인은 앞부분의 설정 로드나 DNS 기록에 있을 수 있습니다.

증상에 따라 문제 해결 경로 선택하기

시스템 시간·포트 충돌·권한은 자주 발생하는 기본 문제입니다

TLS와 REALITY 등의 핸드셰이크는 올바른 시스템 시간에 의존합니다. 기기 시간이 크게 어긋나면 인증서 시간이나 핸드셰이크 관련 오류가 발생할 수 있습니다. 시스템 시간 동기화를 활성화하고 시간대 설정도 정확한지 확인하세요. 포트 충돌은 이전 클라이언트, 테스트 버전 또는 다른 로컬 프록시를 동시에 실행할 때 자주 발생합니다. 시스템 명령으로 수신 대기 프로세스를 확인하는 편이 무작위 포트로 계속 바꾸는 것보다 직접적입니다. 포트를 바꾸기로 했다면 시스템 프록시, 애플리케이션 수동 프록시와 환경 변수도 함께 업데이트해야 합니다.

권한 문제는 주로 TUN, 시스템 프록시 기록, 설정 디렉터리와 로그 디렉터리에서 발생합니다. 일반적인 시스템 프록시는 장기간 높은 권한으로 실행할 필요가 없지만, TUN으로 가상 인터페이스를 만들 때는 시스템 권한이 필요할 수 있습니다. 프로그램이 권한 상승 후에만 시작된다면 구체적으로 실패한 파일이나 네트워크 작업을 확인해야 하며, 높은 권한으로 계속 실행하는 것을 기본 해결책으로 삼아서는 안 됩니다. 설정 디렉터리가 쓰기 금지 위치에 있으면 클라이언트는 열리지만 구독과 규칙을 저장하지 못해 종료 후 변경 사항이 모두 사라질 수 있습니다.

네트워크를 복구할 때는 먼저 인계를 해제한 뒤 노드를 확인하기

클라이언트 오류 후 시스템 전체가 네트워크에 접속하지 못한다면 첫 번째 목표는 로컬 네트워크 설정을 복구하는 것입니다. 먼저 TUN을 끄고 시스템 프록시를 지운 뒤 시스템 DNS와 기본 라우팅이 복원되었는지 확인하고, 클라이언트를 거치지 않는 일반 연결을 테스트하세요. 기본 네트워크가 복구된 뒤에야 클라이언트를 다시 시작해 노드를 확인합니다. 처음부터 노드를 연속으로 바꾸면 잘못된 시스템 프록시나 가상 라우팅이 남아 모든 노드가 고장 난 것처럼 보일 수 있습니다.

모바일에서 연결이 끊기면 먼저 Wi-Fi에서 모바일 네트워크로 전환되었는지, 클라이언트가 백그라운드 제한을 받는지, 시스템 네트워크 인계 표시가 남아 있는지 확인하세요. 데스크톱에서 절전 모드 해제 후 복구되지 않는다면 연결을 중지한 뒤 코어를 다시 시작하여 이전 소켓과 DNS 상태를 재생성해 보세요. 자주 발생한다면 로그인 시 자동 시작, 절전 정책과 네트워크 인터페이스 변경 로그를 확인합니다.

월간 유지 관리 목록 만들기

안정적으로 사용한 뒤에는 매월 한 번 가볍게 유지 관리하면 충분합니다. 구독을 업데이트하고 확실히 만료된 로컬 사본을 삭제하며, 클라이언트와 코어의 호환성 업데이트를 확인하세요. 규칙 데이터가 정상적으로 로드되는지, 로그 파일이 지나치게 커지지 않았는지, 자동 시작과 시스템 프록시 종료 복원이 작동하는지 점검합니다. 직접 연결 대상 하나와 프록시 대상 하나로 라우팅도 검증하세요. 변경 기록에는 날짜, 변경 항목과 되돌리는 방법을 적어 두세요. 장애가 발생했을 때 전체 환경을 초기화하지 않고 최근 변경부터 확인할 수 있습니다.

기기를 바꿀 예정이라면 클라이언트가 내보내기를 지원하는 로컬 설정을 저장하고, 구독 진입점과 사용자 지정 규칙은 별도로 기록하세요. 새 기기에서는 해당 플랫폼의 클라이언트를 먼저 설치하고 구독을 복원한 뒤 라우팅과 TUN을 이전합니다. 운영체제마다 경로, 프로세스 규칙과 네트워크 인터페이스 이름이 다르므로 그대로 복사해서는 안 됩니다. 빠른 설정은 사용 설명서 →로 돌아가고, 클라이언트 차이는 선택 가이드 →에서 확인하세요.

08

하위 수준 이해하기

고급 경로와 설정 파일 구조

그래픽 옵션을 하위 설정에 매핑하기

고급 단계에 들어섰다고 해서 그래픽 클라이언트를 바로 포기할 필요는 없습니다. 먼저 클라이언트가 생성한 실행 설정을 내보내거나 확인하고, 화면의 로컬 포트, 현재 노드, 라우팅 모드와 DNS 옵션을 JSON 필드에 대응시켜 보세요. 시스템 프록시는 운영체제 설정이므로 코어 설정에 직접 나타나지 않을 수 있습니다. 로컬 SOCKS 또는 HTTP 포트는 inbounds에, 노드와 직접 연결 출구는 outbounds에, 분기는 routing에, 도메인 해석은 dns에 위치합니다. 이 매핑을 이해해야 화면의 스위치가 설정 파일을 바꾸는지 시스템 환경을 바꾸는지 판단할 수 있습니다.

클라이언트는 보통 시작할 때마다 실행 설정을 다시 생성하므로 임시 파일을 직접 편집해도 다음 시작 때 사라질 수 있습니다. 사용자 지정 JSON을 장기간 사용하려면 클라이언트가 제공하는 사용자 지정 설정 진입점이나 지원되는 템플릿 및 라우팅 편집기를 사용하세요. 수정 전 원본 설정을 복사하고 JSON 파서로 문법을 확인합니다. JSON에는 주석, 후행 쉼표와 이스케이프되지 않은 특수 문자를 사용할 수 없습니다. 이 때문에 설정은 올바르게 보이지만 코어가 시작되지 않는 일이 많습니다.

최소 설정에 필요한 구성 요소

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-2222-3333-4444-555555555555",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "service.example.com"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

이 예시는 구조 관계만 보여 주며 연결 가능한 서비스를 포함하지 않습니다. 인바운드는 127.0.0.1에서만 수신 대기하므로 로컬 요청만 받습니다. 모든 인터페이스에서 수신하도록 바꾸면 접근 범위가 넓어지므로 방화벽과 인증을 함께 고려해야 합니다. 프록시 아웃바운드는 예시 VLESS 매개변수를 사용하며, 실제 사용 시 address, port, id, 전송과 TLS 필드를 반드시 교체해야 합니다. direct와 block 아웃바운드는 라우팅 대상을 제공하고, 규칙은 먼저 사설 주소를 direct로 보냅니다. 일치하지 않는 트래픽은 코어의 기본 동작에 따라 다음 아웃바운드를 선택합니다.

인바운드 태그와 아웃바운드 태그는 설정 연결점입니다

tag는 암호화나 네트워크 연결을 담당하지 않고 설정 내부에서 참조하는 이름입니다. 라우팅은 outboundTag로 아웃바운드를 선택하며, inboundTag로 특정 인바운드에만 규칙을 적용할 수도 있습니다. 태그 표기는 완전히 일치해야 하며, 이름을 바꿀 때는 모든 참조도 함께 수정해야 합니다. 설정이 복잡해지면 socks-in, tun-in, proxy, direct, block처럼 용도를 나타내는 이름을 사용하고 숫자 번호는 피하는 것이 좋습니다.

여러 인바운드에 서로 다른 라우팅 정책을 적용할 수 있습니다. 예를 들어 로컬 브라우저의 SOCKS 인바운드는 일반 규칙을 사용하고, TUN 인바운드는 DNS를 추가로 처리하도록 구성할 수 있습니다. 여러 아웃바운드는 서로 다른 노드나 연결 방식을 나타낼 수 있습니다. 이때 balancers 또는 더 복잡한 라우팅 구조로 구성할 수 있지만, 분명한 요구가 없다면 추가하지 마세요. 그래픽 클라이언트가 노드 전환을 충분히 관리한다면 아웃바운드를 여러 개 직접 작성하는 것이 오히려 구독 업데이트 동기화를 어렵게 합니다.

설정을 확장하기 전에 검증부터 익히기

설정 검증은 세 계층으로 나뉩니다. 첫째는 JSON 문법으로 괄호, 배열, 문자열과 쉼표가 올바른지 확인합니다. 둘째는 코어 설정 검사로 필드 이름, 프로토콜 구조와 태그 참조가 유효한지 확인합니다. 셋째는 실행 검증으로 포트 수신 대기, 라우팅 매칭과 핸드셰이크 성공 여부를 확인합니다. 문법 검사를 통과했다고 프로토콜 매개변수가 올바른 것은 아니며, 프로세스가 시작되었다고 애플리케이션이 해당 인바운드를 사용한다는 뜻도 아닙니다. 아웃바운드나 규칙을 하나 추가할 때마다 세 계층을 다시 검증하세요.

복잡한 설정은 테스트 가능한 작은 단계로 나누는 것이 좋습니다. 먼저 SOCKS 인바운드 하나와 프록시 아웃바운드 하나만 유지하고 수동 프록시를 지정한 브라우저가 접속되는지 확인합니다. 다음으로 direct와 기본 라우팅을 추가하고, 이후 DNS를 추가한 뒤 마지막에 TUN을 추가하세요. 클라이언트에서 최종 실행 설정을 볼 수 있다면 최종 파일을 기준으로 해야 합니다. 화면 템플릿이 mux, 로그, 정책 또는 DNS 필드를 자동으로 추가할 수 있기 때문입니다. 각 부분을 더 자세히 읽으려면 설정 파일 구조 상세 설명 →을 참고하세요.

프로토콜 선택은 서버 매개변수와 호환성을 따라야 합니다

VMess와 VLESS는 모두 생태계에서 널리 사용되는 프로토콜입니다. VMess는 자체 인증과 데이터 처리 메커니즘을 포함하고, VLESS는 구조가 더 간결하며 TLS, REALITY 등의 보안 계층과 함께 사용되는 경우가 많습니다. 클라이언트가 프로토콜을 독자적으로 결정할 수는 없습니다. 서버가 제공하는 매개변수에 맞는 설정을 사용해야 합니다. 성능 차이도 네트워크 품질, 전송 방식, 암호화 계층과 기기 성능을 제외하고 판단할 수 없습니다. 일반 사용자는 먼저 코어 지원, 매개변수 일치와 연결 안정성을 확보한 뒤 세부적인 전송 오버헤드를 비교하세요.

구독에 여러 프로토콜이 함께 제공된다면 같은 네트워크 환경에서 연결 설정, 장시간 연결 안정성과 모바일 네트워크 전환 후 복구를 각각 테스트하세요. 포트 탐색 한 번만으로 비교하지 마세요. 프로토콜 개념은 VMess와 VLESS의 차이 →에서 확인할 수 있습니다. OpenWrt 주 라우터나 보조 라우터 배포를 고려한다면 먼저 장치가 담당할 인바운드, 투명 인계, DNS와 라우팅 역할을 이해한 뒤 OpenWrt 배포 핵심 사항 →을 살펴보세요.

자신만의 고급 설정 학습 순서 만들기

이후 학습은 네 단계로 나누는 것이 좋습니다. 1단계에서는 애플리케이션, 시스템 프록시, 로컬 인바운드와 원격 아웃바운드 사이의 경로를 설명할 수 있어야 합니다. 2단계에서는 사설 네트워크 직접 연결, 지정 도메인 프록시와 차단 규칙을 작성하고 로그로 매칭을 확인할 수 있어야 합니다. 3단계에서는 TUN, DNS, MTU와 LAN 우회를 독립적으로 처리합니다. 4단계에서야 다중 인바운드·아웃바운드, 프로세스별 분기 또는 라우터 투명 인계로 넘어갑니다. 각 단계마다 최소한으로 작동하는 설정을 하나씩 보존해 되돌릴 기준으로 삼으세요.

진정한 ‘초보부터 고급 설정까지’란 모든 옵션을 켜는 것이 아니라 요청이 어느 계층에서 멈췄는지 판단하는 것입니다. 애플리케이션이 로컬 포트로 들어왔는지, DNS가 예상한 결과를 반환했는지, 라우팅이 어떤 아웃바운드에 매칭되었는지, 코어가 원격 핸드셰이크를 완료했는지를 확인해야 합니다. 이 네 가지를 익히면 클라이언트 화면, JSON 설정과 시스템 네트워크 설정을 하나의 모델로 이해할 수 있습니다. 설치 패키지를 다시 선택하려면 클라이언트 다운로드 페이지 →로, 최단 단계로 다시 설정하려면 빠른 시작 문서 →로 돌아가세요.