V2Ray 처음부터 완벽하게 익히기: 클라이언트·라우팅 분할·TUN

01 / concepts

핵심 개념: 먼저 트래픽 흐름을 한눈에 그려 보기

클라이언트·코어·설정 파일의 역할

V2Ray를 사용할 때 가장 혼동하기 쉬운 대상은 그래픽 클라이언트, 프록시 코어와 설정 데이터입니다. v2rayN, v2rayNG, v2flyNG는 그래픽 클라이언트로, 구독 가져오기, 노드 선택, 시스템 프록시, 라우팅 규칙과 실행 로그를 관리하는 화면을 제공합니다. Xray, V2Fly 같은 코어는 연결, 프로토콜, 전송과 라우팅을 실제로 처리합니다. 설정 파일은 수신 포트, 아웃바운드 매개변수, 도메인 규칙과 DNS 정책을 코어에 전달합니다. 화면에서 한 번 설정을 바꾸면 대개 여러 설정 필드로 변환된 뒤 코어가 다시 불러옵니다.

따라서 문제를 확인할 때는 “클라이언트가 실행 중인가”만 보지 마세요. 더 정확한 순서는 설정이 존재하는지, 현재 설정이 선택되었는지, 코어가 정상적으로 로드되었는지, 로컬 인바운드 포트가 수신을 시작했는지, 애플리케이션 트래픽이 해당 포트로 들어오는지, 라우팅 규칙이 올바른 아웃바운드를 선택했는지, 원격 연결이 완료되었는지를 확인하는 것입니다. 어느 한 단계라도 끊기면 브라우저에서는 모두 접속 불가로 보이지만, 해결 방법은 서로 완전히 다릅니다. 이 흐름을 세우는 것이 이후 모든 장의 판단 기준입니다.

inbounds·outbounds·routing의 관계

inbounds는 트래픽이 코어로 들어오는 방식을 정의합니다. 데스크톱 클라이언트에서는 보통 로컬 SOCKS와 HTTP 수신 포트를 사용하며, TUN을 활성화하면 시스템 네트워크 계층의 트래픽을 받는 가상 입구도 추가됩니다. outbounds는 트래픽이 빠져나가는 경로를 정의하며, 원격 설정일 수도 있고 직접 연결 또는 차단 아웃바운드일 수도 있습니다. routing은 둘 사이에서 도메인, IP, 포트, 프로토콜 또는 인바운드 태그에 따라 사용할 아웃바운드를 판단합니다.

하나의 요청은 “애플리케이션 → 로컬 인바운드 → 라우팅 판단 → 대상 아웃바운드”로 이해할 수 있습니다. 예를 들어 브라우저에 SOCKS 포트를 설정하면 요청이 먼저 로컬 수신 포트로 들어옵니다. 라우팅 규칙이 대상이 직접 연결 목록에 속한다고 판단하면 direct 아웃바운드로 전달하고, 나머지 요청은 현재 원격 아웃바운드로 보냅니다. 규칙에서 사용하는 tag는 각 구간을 연결하는 식별자입니다. 이름은 자유롭게 정할 수 있지만 참조할 때는 일치해야 합니다. 규칙에 outboundTag: "direct"가 있다면 설정에도 direct라는 태그의 아웃바운드가 반드시 있어야 합니다.

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

설정·노드·구독은 서로 다른 대상입니다

단일 노드는 서버 주소, 포트, 사용자 식별자, 프로토콜과 전송 설정으로 이루어진 연결 매개변수 모음입니다. 구독은 업데이트 가능한 데이터 원본으로, 여러 노드와 그룹 정보를 함께 반환할 수 있습니다. 클라이언트 설정은 노드보다 범위가 넓으며 로컬 포트, 프록시 모드, DNS, 라우팅, 로그와 화면 설정까지 포함합니다. 구독을 삭제해도 이미 생성된 로컬 설정이 즉시 삭제되지 않을 수 있고, 노드를 바꿔도 시스템 프록시 모드가 자동으로 바뀌지는 않습니다. 작업 전에 지금 다루는 대상이 구독 원본인지, 설정 목록인지, 현재 실행 중인 인스턴스인지 먼저 확인하세요.

설정 구조를 필드별로 이해하려면 config.json 구조 상세 해설을 이어서 읽어 보세요. 이 글에서는 하나의 최소 설정을 사용해 인바운드, 아웃바운드와 라우팅 태그를 비교하며 설명합니다.

02 / client and install

클라이언트 선택과 설치: 플랫폼에 맞춘 뒤 실행 조건 확인하기

세 클라이언트의 역할

데스크톱 플랫폼에서는 v2rayN을 우선 선택합니다. Windows, macOS와 Linux를 지원하며 설정 목록, 구독 관리, 시스템 프록시, 라우팅과 TUN 같은 주요 기능을 한곳에서 제공합니다. Windows 다운로드 페이지에는 데스크톱 버전과 클래식 WPF 버전이 함께 제공됩니다. 데스크톱 버전은 크로스 플랫폼 UI를 사용해 여러 데스크톱 시스템에서 비슷한 작업 흐름을 원하는 사용자에게 적합하고, WPF 버전은 Windows의 전통적인 사용 방식에 맞춰 화면과 시스템 통합 경로가 더 집중되어 있습니다. 두 버전의 핵심 차이는 UI 프레임워크와 시스템 호환 방식이며, 노드 프로토콜 기능의 단순한 우열이 아닙니다.

Android에서는 v2rayNG를 우선 선택하며 Xray 코어를 사용합니다. 일반적인 구독, 앱별 프록시, 라우팅과 연결 테스트를 그래픽 화면에서 처리할 수 있습니다. v2flyNG는 V2Fly 코어를 사용하므로 해당 코어 구현이 필요한 경우의 대안이 될 수 있습니다. 두 Android 클라이언트의 설정 목록은 공유되지 않으므로 클라이언트를 바꿀 때 구독이나 설정을 다시 가져와야 합니다. 한 클라이언트가 생성한 내부 데이터베이스 파일을 다른 클라이언트에 그대로 복사하지 마세요. 공용 구독 링크, 공유 링크 또는 표준 설정을 사용하는 편이 이전에 적합합니다.

설치 전 시스템 아키텍처와 기존 인스턴스 확인

다운로드하기 전에 프로세서 아키텍처와 시스템 유형을 확인하세요. macOS에서는 “이 Mac에 관하여”에서 칩 이름을 확인할 수 있습니다. Linux에서는 uname -m을 실행합니다. x86_64는 x64, aarch64는 arm64에 해당합니다. 최근 Android 기기는 대체로 arm64를 사용하지만, 기기 정보가 확실하지 않다면 범용 패키지를 선택할 수 있습니다. 설치 패키지의 아키텍처가 맞지 않으면 실행되지 않거나 설치 프로그램이 실행을 거부하거나 시작 직후 종료될 수 있으며, 이런 문제는 노드 매개변수를 수정해 해결할 수 없습니다.

UI 버전을 업그레이드하거나 바꾸기 전에 실행 중인 기존 인스턴스를 먼저 종료하세요. 데스크톱 클라이언트는 트레이 프로세스를 남길 수 있어 주 창을 닫는 것만으로 프로세스가 끝나지 않을 수 있습니다. 트레이 메뉴에서 종료하거나 시스템 작업 관리 도구로 프로세스가 멈췄는지 확인해야 합니다. 기존 인스턴스가 로컬 포트를 계속 사용하면 새 인스턴스가 로그에 수신 실패를 기록합니다. 설치를 옮기기 전에 현재 구독 주소, 라우팅 규칙과 사용자 지정 포트를 기록해 두면 설치 후 어떤 설정이 기존 환경에서 이어졌는지 판단하기 쉬워집니다.

첫 실행 후 최소 점검

클라이언트를 처음 열었을 때 시스템 프록시와 TUN을 동시에 활성화하지 마세요. 올바른 순서는 클라이언트 화면이 정상인지 확인하고, 설정 하나를 가져온 뒤 선택하고, 코어를 시작한 다음, 로그에 로컬 수신 성공이 표시되는지 확인하고, 마지막으로 시스템 프록시를 켜서 테스트하는 것입니다. 단계별로 진행하면 “프로그램 실행 문제”와 “네트워크 가로채기 문제”를 분리할 수 있습니다. Windows에서 실행 환경 안내가 나타나면 클라이언트 페이지의 요구 사항에 따라 런타임 구성 요소를 설치하세요. Linux는 설치 후 메뉴 항목이 보이지 않으면 터미널에서 한 번 실행해 오류를 확인할 수 있습니다. macOS는 처음 실행할 때 시스템 보안 설정에서 앱 실행이 허용되었는지 확인하세요.

설치가 완료되었다고 프록시가 작동하는 것은 아닙니다. 클라이언트 실행, 코어 실행과 시스템 프록시 활성화는 서로 다른 상태입니다. 화면만 열고 설정을 시작하지 않으면 로컬 포트가 수신하지 않습니다. 코어는 실행 중이어도 시스템 프록시가 꺼져 있으면 프록시를 수동 지정한 앱만 클라이언트로 들어갑니다. 시스템 프록시는 설정되어 있지만 코어가 멈추면 애플리케이션은 서비스가 없는 포트로 요청을 보냅니다. 이 세 가지 상태를 이해하면 설치 문제를 원격 연결 문제로 잘못 판단하는 일을 피할 수 있습니다.

Windows에서 더 자세한 설치 과정과 일반적인 실행 환경 문제를 확인하려면 Windows에서 v2rayN 설치하기를 참고하세요. 두 UI 버전의 선택 기준은 v2rayN 데스크톱 버전과 클래식 WPF 버전 비교에서 확인할 수 있습니다.

03 / subscription

구독과 설정 관리: 가져오기·업데이트·선택·실행을 구분하기

구독 가져오기 후 진행할 네 가지 작업

구독을 추가하는 것은 보통 클라이언트에 데이터 원본 하나를 저장하는 작업입니다. 전체 과정은 구독 정보 저장, 구독 업데이트, 결과에서 설정 선택, 선택한 설정 시작이라는 네 가지 독립적인 단계로 이루어집니다. 일부 클라이언트는 저장 후 즉시 업데이트하지만, 수동으로 “구독 업데이트”를 실행해야 하는 경우도 있습니다. 추가는 완료되었는데 설정 목록이 비어 있다면 바로 삭제 후 재추가하지 말고 업데이트가 실행되었는지 먼저 확인하세요. 업데이트한 뒤에는 현재 그룹과 필터 조건도 확인해야 설정이 존재하지만 목록에서 숨겨진 상황을 피할 수 있습니다.

구독 이름은 로컬에서 구분하기 위한 용도일 뿐 연결에는 사용되지 않습니다. 용도와 출처를 구분할 수 있는 짧은 이름을 사용하고, 날짜를 이름에 넣었다가 자주 바꾸는 방식은 피하세요. 여러 구독이 있을 때 이름만 보고 업데이트 범위를 판단할 수 있어야 합니다. 업데이트하면 해당 구독에서 생성된 기존 설정이 교체될 수 있으며, 수동으로 수정한 노드 매개변수도 다음 업데이트에서 덮어써질 수 있습니다. 오래 유지할 로컬 변경 사항은 클라이언트의 라우팅, DNS 또는 전역 설정에 저장하세요. 특정 설정 하나를 반드시 수정해야 한다면 먼저 로컬 독립 항목으로 복사하고 용도를 표시하는 것이 좋습니다.

업데이트 중 현재 사용 가능한 상태를 보존하는 방법

업데이트 전 현재 설정 이름과 실행 상태를 확인하세요. 업데이트 후 클라이언트가 고유 식별자를 기준으로 선택 상태를 유지할 수도 있지만, 설정이 교체되면서 다른 항목으로 돌아갈 수도 있습니다. 가장 안전한 방법은 업데이트 후 현재 설정을 다시 확인하고 연결 테스트를 한 번 실행하는 것입니다. 구독이 빈 내용을 반환하더라도 모든 설정을 연속해서 덮어쓰거나 삭제하지 마세요. 먼저 클라이언트 로그의 HTTP 상태, 응답 형식과 파싱 안내를 확인하고, 이전에 작동하던 설정을 비교용으로 남겨 두세요.

구독 업데이트 실패는 “주소에 요청할 수 없음”, “요청은 성공했지만 내용을 파싱할 수 없음”, “파싱은 성공했지만 사용 가능한 설정이 없음”의 세 가지로 나눌 수 있습니다. 첫 번째는 네트워크 경로, 시스템 시간과 구독 주소의 완전성을 확인하고, 두 번째는 응답 내용이 클라이언트가 지원하는 구독 형식인지와 웹페이지 주소를 구독 주소로 잘못 사용하지 않았는지 확인합니다. 세 번째는 구독 그룹, 필터 규칙과 클라이언트 코어의 호환성을 확인하세요. 로그에 요청 성공 후 파싱 수가 0으로 표시된다면 프록시 모드를 계속 바꾸는 것은 도움이 되지 않으며, 구독 내용과 형식부터 다시 확인해야 합니다.

공유 링크·JSON 설정·구독의 사용 범위

단일 공유 링크는 하나의 명확한 설정을 가져오는 데 적합하며 주소, 포트와 전송 설정을 항목별로 확인하기 쉽습니다. JSON 설정은 인바운드, 아웃바운드, 라우팅과 DNS를 완전히 제어해야 할 때 적합하고, 구독은 같은 출처에서 여러 설정을 관리하며 주기적으로 업데이트할 때 적합합니다. 세 가지를 함께 사용할 수 있지만, 여러 출처에서 이름이 같은 설정을 만들지 않도록 주의하세요. 전환할 때 현재 어떤 항목이 실행 중인지 판단하기 어려워집니다.

JSON을 수동으로 가져오기 전에 전체 코어 설정인지, 클라이언트가 인식하는 설정 조각인지 확인하세요. 전체 설정에는 일반적으로 inbounds, outbounds 같은 최상위 필드가 포함되지만 공유 링크는 하나의 아웃바운드 연결만 설명합니다. 그래픽 클라이언트는 자체 설정에 따라 인바운드와 라우팅을 다시 생성할 수 있으므로, 클라이언트가 실행 중 생성한 임시 파일을 직접 수정하면 다음 시작 때 덮어써질 수 있습니다. 지속적으로 유지할 설정은 클라이언트 화면, 사용자 지정 설정 메뉴 또는 명확한 설정 파일 관리 기능을 통해 적용하세요.

구독 데이터의 기본 관리 원칙

구독 주소에는 접근 식별 정보가 포함될 수 있으므로 사용하는 클라이언트에만 저장하고 공개 페이지, 로그 캡처 또는 공유 문서에 게시하지 마세요. 진단을 위해 로그를 보여줘야 한다면 전체 구독 주소, 서버 주소와 사용자 식별자를 가리고 오류 유형, 상태 코드와 시간 순서만 남기세요. 클라이언트의 내보내기 기능에도 연결 매개변수가 포함될 수 있으므로 전송 전에 내보내기 범위를 확인해야 합니다.

일상적으로는 구독 업데이트와 클라이언트 업그레이드를 나누어 실행하세요. 기존 클라이언트 환경에서 먼저 구독 업데이트를 확인한 뒤 클라이언트를 업그레이드하거나, 클라이언트를 먼저 업그레이드하고 기존 설정이 작동하는지 확인한 다음 구독을 업데이트합니다. 두 변수를 동시에 바꾸면 호환성 문제가 생겼을 때 파서, 코어와 구독 내용 중 무엇이 원인인지 판단하기 어렵습니다. 안정적인 유지 관리의 핵심은 자주 조작하는 것이 아니라, 한 번의 변경에 명확한 목적 하나만 두는 것입니다.

04 / proxy mode

프록시 모드와 로컬 포트: 어떤 애플리케이션을 클라이언트로 보낼지 결정하기

시스템 프록시·수동 프록시·TUN의 적용 범위

시스템 프록시는 데스크톱에서 첫 연결을 확인할 때 가장 적합한 모드입니다. v2rayN은 시스템 프록시 주소를 로컬 수신 포트로 설정하고, 시스템 프록시 설정을 따르는 브라우저와 애플리케이션의 요청을 클라이언트로 전달합니다. 동작이 명확하고 끄기 쉽다는 장점이 있지만, 일부 앱은 시스템 프록시를 읽지 않으며 명령줄 도구와 독립 실행 환경이 자체 프록시 설정을 사용할 수도 있습니다. “브라우저는 되는데 특정 앱은 안 된다”면 설정이 무효라고 단정하지 말고 해당 앱이 시스템 프록시를 따르는지 먼저 확인하세요.

수동 프록시는 정확한 테스트에 적합합니다. 브라우저, 개발 도구 또는 명령줄 프로세스에 127.0.0.1과 SOCKS/HTTP 포트를 직접 입력할 수 있습니다. 다른 앱에는 자동으로 적용되지 않으므로 로컬 인바운드가 작동하는지 확인하기 쉽습니다. TUN은 시스템 네트워크 계층에 더 가까운 위치에서 동작해 명시적 프록시를 지원하지 않는 트래픽도 더 많이 받을 수 있지만, 가상 네트워크 어댑터, 라우팅 테이블, DNS 가로채기와 권한 문제가 추가됩니다. 먼저 시스템 프록시로 연결을 확인한 뒤 TUN으로 넘어가는 것이 올바른 순서이며, TUN을 첫 연결의 기본 스위치로 사용하지 마세요.

SOCKS와 HTTP 포트 선택 방법

SOCKS 인바운드는 TCP를 처리하며 설정에서 허용하면 UDP도 처리할 수 있습니다. HTTP 프록시는 주로 HTTP CONNECT를 지원하는 애플리케이션을 대상으로 합니다. 클라이언트가 두 로컬 포트를 동시에 만들거나 혼합 인바운드를 제공하는 경우도 있습니다. 앱 프록시를 설정할 때는 프로토콜 유형과 포트를 맞춰야 합니다. SOCKS 포트를 HTTP 프록시 전용 입력란에 넣으면 연결 실패나 프로토콜 오류가 발생하며, 반대의 경우도 마찬가지입니다. 포트 번호에 정해진 값은 없고, 클라이언트의 실제 수신 포트, 시스템 프록시 값과 앱 설정이 서로 일치하는지가 중요합니다.

로컬 수신 주소는 보통 127.0.0.1로 설정하며, 이는 본인 컴퓨터의 연결만 허용한다는 뜻입니다. 같은 LAN의 다른 기기가 접속해야 할 분명한 이유가 있을 때만 LAN 연결 허용을 고려하고, 시스템 방화벽과 접근 범위도 함께 확인하세요. LAN 수신을 개방한 뒤 주소만 바꾸고 인증과 네트워크 범위를 무시해서는 안 됩니다. 일반적인 단일 기기 사용에서는 로컬 수신을 유지하는 편이 관리하기 쉽고, LAN 환경 변화가 문제 판단에 미치는 영향도 줄일 수 있습니다.

포트 충돌과 남은 시스템 프록시 설정

코어를 시작할 때 주소가 이미 사용 중이라는 메시지가 나오면 예정된 수신 포트를 다른 프로세스가 사용하고 있다는 뜻입니다. 먼저 기존 클라이언트 인스턴스를 종료한 뒤 점유 프로세스를 확인하세요. Windows에서는 netstat -ano | findstr :10808을 실행해 프로세스 식별자를 확인할 수 있습니다. macOS에서는 lsof -nP -iTCP:10808 -sTCP:LISTEN, Linux에서는 ss -lntp | grep 10808을 실행합니다. 프로세스 용도를 확인한 뒤 종료하거나 클라이언트 포트를 변경하세요. 점유되어 있다는 이유만으로 정체를 알 수 없는 시스템 서비스를 바로 종료해서는 안 됩니다.

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

포트를 변경한 뒤에는 시스템 프록시나 앱의 프록시 포트도 함께 수정해야 합니다. 클라이언트의 수신 포트만 바꾸고 기존 시스템 프록시를 그대로 두면 “클라이언트는 실행 중이지만 앱은 이전 포트에 연결하는” 상태가 됩니다. 클라이언트가 비정상 종료되면 시스템 프록시 설정이 남을 수도 있습니다. 이때 코어가 실행되지 않아도 브라우저는 로컬 프록시에 연결을 시도합니다. 클라이언트를 다시 열어 시스템 프록시를 끄거나 시스템 네트워크 설정에서 직접 복원하세요. 자세한 포트 확인 절차는 포트 사용 중 원인 확인과 변경 방법을 참고하세요.

05 / routing

라우팅 분할: 규칙으로 트래픽 유형별 출구 결정하기

규칙 수보다 중요한 것은 규칙 매칭 순서입니다

라우팅 규칙은 보통 위에서 아래로 매칭되며, 일치하면 지정된 아웃바운드로 전달됩니다. 규칙이 많다고 결과가 더 정확해지는 것은 아닙니다. 조건이 서로 겹치지 않는지, 우선순위가 합리적인지, 기본 출구가 명확한지가 더 중요합니다. 구체적인 규칙은 포괄적인 규칙보다 앞에 배치해야 합니다. 예를 들어 한 도메인이 사용자 지정 직접 연결 목록에 속하면서 뒤의 일반 프록시 규칙에도 해당한다면 사용자 지정 규칙을 먼저 배치하세요. 클라이언트에 사전 설정 라우팅 모드가 있다면 목표에 가장 가까운 사전 설정을 먼저 선택한 뒤 소수의 사용자 지정 규칙을 추가하는 편이 빈 설정에서 많은 목록을 쌓는 것보다 관리하기 쉽습니다.

일반적인 조건에는 도메인, IP, 포트, 네트워크 유형, 프로토콜과 인바운드 태그가 있습니다. 도메인 규칙은 전체 도메인, 접미사 또는 GeoSite 분류에 적합하고, IP 규칙은 사설 주소와 GeoIP 분류에 적합합니다. 포트 규칙은 특정 서비스에, 인바운드 태그는 서로 다른 로컬 입구에 다른 정책을 적용할 때 유용합니다. 도메인 조건과 최종적으로 해석된 IP 조건을 완전히 같은 것으로 보지 마세요. 요청이 라우팅 단계에 들어올 때 도메인이 유지되는지는 DNS 처리 과정과 domainStrategy 설정에 따라 달라집니다.

direct·proxy·block 세 가지 출구

읽기 쉬운 라우팅은 일반적으로 최소한 세 가지 결과를 구분합니다. direct는 직접 연결, proxy는 현재 원격 아웃바운드로 전달, block은 차단을 의미합니다. 이름은 태그일 뿐 실제 동작은 연결된 아웃바운드 프로토콜이 결정합니다. 규칙에서 태그를 참조할 때는 아웃바운드 태그와 한 글자까지 일치해야 합니다. 화면에서 “직접 연결”, “프록시”, “차단”을 선택할 수 있다면 클라이언트가 태그를 관리하지만, JSON을 직접 작성할 때는 참조 관계를 직접 보장해야 합니다.

사설 주소는 일반적으로 우선 직접 연결해야 라우터, 프린터 또는 LAN 서비스에 접근할 때 원격 아웃바운드로 우회하지 않습니다. 차단할 트래픽에는 명확한 조건을 사용하고 너무 포괄적인 도메인 키워드는 피하세요. 마지막으로 이해하기 쉬운 기본 정책을 남겨야 합니다. 어떤 규칙에도 일치하지 않는 트래픽을 기본적으로 프록시로 보낼지 직접 연결할지는 현재 클라이언트 모드와 일치해야 합니다. 문제 해결 중에는 일시적으로 단순한 전역 정책으로 바꿔 라우팅이 원인인지 확인할 수 있지만, 확인이 끝나면 분할 설정을 복원하고 임시 모드에 장기간 의존하지 마세요.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "protocol": ["bittorrent"],
        "outboundTag": "direct"
      }
    ]
  }
}

domainStrategy와 DNS의 조합

AsIs는 라우팅에 들어온 도메인을 그대로 매칭하는 방식으로, IP 규칙을 위해 별도로 해석하지 않는 경향이 있습니다. IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 해석을 시도한 뒤 IP 규칙을 계속 적용합니다. IPOnDemand는 IP가 필요한 규칙을 만났을 때 더 적극적으로 해석합니다. 어떤 방식을 선택할지는 규칙 구조에 따라 달라집니다. 도메인 규칙이 중심이면 AsIs 경로가 직관적이고, GeoIP 조건을 많이 사용한다면 IPIfNonMatch가 IP 규칙을 판단에 참여시키기 쉽지만 DNS 결과에 더 의존합니다.

DNS와 라우팅은 하나의 순환 구조를 이룹니다. DNS 요청 자체도 출구를 선택해야 하고, 해석 결과는 이후 라우팅에 영향을 줍니다. 도메인 해석이 적절하지 않은 네트워크 경로를 거치면 접근할 수 없는 주소를 받을 수 있으며, 규칙이 IP 기준 판단을 요구하는데 유효한 해석 결과를 얻지 못하면 예상대로 매칭되지 않습니다. 문제를 확인할 때는 “도메인을 누가 해석하는지”, “DNS 요청이 어느 아웃바운드로 나가는지”, “결과가 어느 라우팅 규칙으로 들어가는지”를 각각 기록하세요. DNS 주소만 바꾸고 출구 경로를 무시하지 마세요.

GeoIP·GeoSite 업데이트 범위

GeoIP는 IP 주소를 기준으로 분류하고, GeoSite는 도메인 목록을 기준으로 분류합니다. 두 데이터베이스가 오래되면 새 도메인과 주소 대역이 예상한 분류에 들어가지 않을 수 있습니다. 업데이트 후 라우팅이 갑자기 달라졌다면 코어 이상으로 단정하기 전에 데이터베이스 버전 변경으로 분류가 조정되었는지 확인하세요. 우선순위가 높은 사용자 지정 규칙은 적은 수로 유지하고 추가 이유를 기록해야 합니다. 데이터베이스 업데이트가 이미 해당 상황을 포함한다면 중복 규칙을 삭제해 이후 충돌을 줄이세요.

데이터베이스의 역할, 업데이트 경로와 확인 방법은 GeoIP·GeoSite 데이터베이스 업데이트 가이드에서 확인할 수 있습니다. 여러 클라이언트의 라우팅 기능과 지원 플랫폼을 비교하려면 클라이언트 비교를 참고하세요.

06 / tun

TUN 모드: 시스템 프록시에서 네트워크 계층 가로채기로 확장하기

TUN을 활성화해야 하는 경우

TUN 모드는 가상 네트워크 인터페이스를 통해 시스템 트래픽을 받으므로 시스템 프록시 설정을 읽지 않는 앱, UDP 지원이 필요한 프로그램, 앱별 설정을 줄이고 싶은 데스크톱 환경에 적합합니다. 연결 품질을 높이는 스위치도 아니며 잘못된 원격 매개변수를 자동으로 고쳐 주지도 않습니다. 시스템 프록시 모드에서 기본적인 웹페이지조차 열리지 않는다면 먼저 설정, 포트, DNS 또는 원격 연결 문제를 해결한 뒤 TUN을 활성화하세요. 그렇지 않으면 추가된 라우팅 테이블과 가상 네트워크 어댑터가 문제 해결 변수를 늘릴 뿐입니다.

활성화하기 전에 세 가지 기준 테스트를 완료해야 합니다. 현재 설정이 시작되고, 시스템 프록시에서 하나 이상의 앱이 안정적으로 접속하며, 클라이언트 로그에 지속적인 연결 또는 해석 오류가 없어야 합니다. 그다음 시스템 프록시를 끄거나 클라이언트 권장 방식에 따라 두 기능의 관계를 정리한 뒤 TUN을 켜세요. 테스트할 때는 기본 네트워크 스택과 기본 MTU를 유지하고 DNS, 엄격한 라우팅, 우회 규칙과 네트워크 어댑터 매개변수를 동시에 변경하지 마세요. 기본 설정에 구체적인 문제가 확인된 경우에만 해당 옵션을 조정해야 합니다.

가상 네트워크 어댑터·라우팅 테이블·권한

TUN은 가상 네트워크 인터페이스를 만들고 시스템 라우팅을 수정하므로 데스크톱 시스템에서 관련 권한이 필요한 경우가 많습니다. 권한이 부족하면 가상 네트워크 어댑터 생성 실패, 라우팅 추가 실패 또는 클라이언트에는 켜진 것으로 표시되지만 트래픽이 들어오지 않는 현상이 나타날 수 있습니다. 클라이언트 로그에서 구체적으로 어느 단계가 실패했는지 확인한 뒤 시스템 권한 체계에 맞게 처리하세요. 스위치를 반복해서 누르면 짧은 시간 동안 여러 인터페이스나 남은 라우팅이 생겨 현상이 더 복잡해질 수 있습니다.

라우팅 테이블은 어떤 대상이 가상 네트워크 어댑터로 들어갈지 결정하고, 우회 규칙은 LAN, 특정 주소 또는 지정된 앱이 기존 경로를 유지하게 합니다. 엄격한 라우팅을 활성화하면 명시적으로 처리되지 않은 우회 트래픽을 시스템이 차단할 수 있습니다. 경로 일관성에는 도움이 되지만 로컬 개발 환경, 가상 머신이나 LAN 서비스에 영향을 줄 수도 있습니다. 활성화 후 LAN 기기에 접근할 수 없다면 모든 분할 설정을 끄기보다 사설 주소 우회와 direct 규칙부터 확인하세요.

MTU·네트워크 스택·UDP 문제

MTU는 인터페이스가 처리할 수 있는 패킷 크기를 뜻합니다. 값을 너무 크게 설정하면 일부 네트워크 경로에서 패킷을 제대로 분할하지 못해 작은 페이지는 열리지만 큰 파일이나 특정 사이트에서 멈출 수 있습니다. 너무 작으면 패킷 분할 오버헤드가 늘어납니다. 명확한 근거가 없다면 클라이언트 기본값을 유지하세요. MTU가 의심되면 네트워크 환경을 바꿔 비교하고 큰 응답이나 특정 프로토콜에서만 재현되는지 확인한 뒤 조금씩 낮춰 테스트하세요. 매번 변경 값과 결과를 기록해야 합니다.

TUN 네트워크 스택은 호환성, 성능과 시스템 통합 방식에서 서로 다릅니다. 먼저 클라이언트가 권장하는 기본 항목을 사용하고, 명확한 UDP 문제, 절전 모드 복귀 문제 또는 가상화 충돌이 있을 때만 변경하세요. 네트워크 스택을 바꾼 뒤에는 TUN을 다시 시작하고 기존 가상 인터페이스가 정리되었는지 확인해야 합니다. Android의 VPN 가로채기는 시스템이 제공하며, v2rayNG와 v2flyNG는 연결을 시작할 때 필요한 권한을 요청합니다. 시스템에서 같은 방식의 가로채기를 사용하는 다른 앱이 이미 실행 중이면 동시에 사용할 때 충돌이 발생할 수 있습니다.

DNS 누수 오판과 해석 경로

TUN을 켠 뒤 DNS 요청을 클라이언트가 가로챌 수도 있고 시스템 네트워크 인터페이스가 계속 보낼 수도 있습니다. 이는 클라이언트 설정에 따라 달라집니다. 흔한 문제는 도메인은 열리지 않지만 알고 있는 IP 주소에는 응답하는 경우이며, 이때는 원격 프로토콜보다 DNS를 먼저 확인해야 합니다. 반대로 DNS가 결과를 반환했지만 해당 결과가 라우팅 후 잘못된 출구로 나갈 수도 있습니다. 문제를 확인하려면 DNS 로그, 라우팅 매칭과 연결 로그를 함께 보고 세 기록의 시간이 서로 대응하는지 확인하세요.

일부 LAN 도메인이 로컬 DNS에 의존한다면 해당 도메인에는 로컬 해석 경로를 유지하고, 공용 도메인은 정한 정책에 따라 해석하세요. 하나의 DNS 서버로 모든 상황을 처리한 뒤 정적 주소를 대량으로 추가해 보완하는 방식은 피해야 합니다. 기업 네트워크, 가정용 LAN과 공용 네트워크를 오갈 때는 로컬 DNS 접근성도 달라지므로 모바일 기기와 노트북에서는 네트워크 전환 후 복구 동작을 중점적으로 확인하세요.

TUN을 활성화한 직후 시스템 전체의 연결이 끊기면 먼저 TUN을 끄고 기본 라우팅이 복구되는지 확인한 다음 로그에서 권한, 인터페이스와 라우팅 추가 오류를 확인하세요. 네트워크가 완전히 끊긴 상태에서 DNS와 라우팅 설정을 계속 추가로 바꾸지 마세요. 복구 경로를 추적하기 어려워집니다.

07 / maintenance

일상적인 유지 관리와 문제 해결: 계층별로 증거 수집하기

반복 가능한 유지 관리 주기 만들기

안정적인 사용은 되돌릴 수 있는 변경 절차에 달려 있습니다. 클라이언트 업그레이드, 코어 업데이트, 구독 업데이트, 라우팅 데이터베이스 업데이트와 시스템 네트워크 변경은 나누어 실행하세요. 변경 전 현재 클라이언트 유형, 선택한 설정, 로컬 포트, 프록시 모드, 라우팅 사전 설정과 DNS 정책을 기록하고, 변경 후 같은 테스트 목록으로 확인합니다. 이렇게 하면 문제가 생겨도 변경 전후의 차이를 정확히 비교할 수 있습니다.

구독은 실제 변경 빈도에 맞춰 업데이트하면 되며, 실행할 때마다 반복해서 새로 고칠 필요는 없습니다. GeoIP와 GeoSite는 라우팅 규칙의 분류가 뚜렷하게 어긋나거나 정해진 유지 관리 일정에 따라 업데이트하세요. 클라이언트를 업그레이드하기 전 화면에 표시되는 이전 안내를 읽고 설정 저장 위치와 권한 요구 사항이 바뀌었는지 확인합니다. 업데이트가 끝나면 먼저 기존 설정으로 작동을 확인한 뒤 새 기능을 도입하세요. 업그레이드와 설정 재구성을 한 번에 진행하면 명확한 복구 지점을 잃게 됩니다.

로그로 문제 발생 계층 판단하기

로그는 시간 순서대로 읽어야 합니다. 시작 단계에서는 설정 파싱, 포트 수신, 코어 프로세스와 TUN 인터페이스를 확인하고, 연결 단계에서는 도메인 해석, 라우팅 매칭, 아웃바운드 연결과 핸드셰이크를 확인합니다. 실행 단계에서는 시간 초과, 연결 재설정과 네트워크 전환을 중점적으로 봅니다. 첫 번째 핵심 오류가 이후 반복되는 오류보다 중요합니다. 뒤의 실패는 앞 단계가 끊긴 결과일 수 있기 때문입니다.

설정 파싱 오류에는 필드 경로나 JSON 행·열 위치가 표시되는 경우가 많으므로 먼저 문법과 필드 유형을 수정하세요. 수신 오류는 대개 포트 점유나 권한 문제를 가리키고, 해석 오류는 DNS 경로를 가리킵니다. 연결 시간 초과는 요청이 로컬을 떠나려 했지만 제한 시간 안에 대상 경로가 완료되지 않았다는 뜻이며, 핸드셰이크 오류는 프로토콜, 전송 방식과 시간을 확인해야 합니다. 로그의 마지막 한 줄만 잘라 보내지 말고, 진단할 때는 시작 전후와 완전한 요청 한 번에 해당하는 연속 구간을 최소한 보존하세요.

모든 설정을 동시에 초기화하지 말고 최소 조건으로 재현하기

재현 환경은 최대한 단순해야 합니다. 정상 작동이 확인된 설정 하나를 선택하고 기본 로컬 포트를 사용하며 사용자 지정 라우팅을 끄고 TUN은 먼저 활성화하지 마세요. 시스템 프록시 또는 단일 앱의 수동 프록시만 남깁니다. 최소 환경이 작동하면 DNS, 라우팅, TUN과 앱 규칙을 하나씩 복원하세요. 최소 환경에서도 실패한다면 설정 매개변수, 시스템 시간, 포트와 네트워크 경로에 집중합니다. 이렇게 하면 복잡한 문제를 제한된 단계로 나눌 수 있습니다.

“기본값 복원”은 설정 오염 여부를 확인하는 데 유용하지만 실행 전에 현재 설정을 기록해야 합니다. 모든 설정을 바로 지우면 비교 자료를 잃고 여전히 사용할 수 있는 구독 정보까지 삭제할 수 있습니다. 대신 독립적인 테스트 설정을 만들거나 클라이언트의 백업 및 복사 기능을 사용하세요. 테스트가 끝나면 유효한 변경 사항을 유지 관리 기록에 남기고, 변경 항목, 이유, 확인 방법과 복구 방법을 적습니다. 기록은 길 필요가 없지만 다음 문제 발생 시 판단 과정을 재현할 수 있어야 합니다.

네트워크 전환·절전 모드·시스템 업데이트 후 점검

노트북이 한 네트워크에서 다른 네트워크로 전환되면 이전 DNS, 가상 네트워크 어댑터 상태와 라우팅 캐시가 잠시 남을 수 있습니다. 전환 후 연결에 문제가 생기면 현재 설정을 중지했다가 다시 시작하세요. TUN 사용자는 가상 인터페이스도 다시 만들어야 합니다. 절전 모드에서 복귀한 뒤 클라이언트 화면에는 계속 실행 중으로 표시될 수 있지만 하위 네트워크 인터페이스가 바뀌었을 수 있으므로 화면 상태가 아니라 새 요청 로그를 기준으로 판단하세요.

시스템 업데이트 후 문제가 발생하면 방화벽 권한, 가상 네트워크 어댑터 드라이버 상태, 시스템 프록시가 초기화되었는지와 클라이언트에 네트워크 인터페이스 생성 권한이 남아 있는지를 확인하세요. Android 기기는 네트워크 전환 후 연결을 중지했다가 다시 시작해 시스템이 현재 네트워크 경로에 필요한 권한을 다시 부여하도록 할 수 있습니다. 어떤 플랫폼에서도 문제가 안정적으로 재현되기 전에 여러 설정을 연속해서 바꾸지 마세요. 시스템 상태 변화와 설정 차이가 뒤섞이기 때문입니다.

08 / advanced route

고급 설정 경로: 화면 설정에서 관리 가능한 규칙으로 전환하기

1단계: 현재 설정을 설명할 수 있게 되기

고급 설정은 필드를 먼저 늘리는 것이 아니라 현재 설정을 설명할 수 있게 되는 것에서 시작합니다. 어떤 인바운드가 있는지, 각 인바운드가 어느 주소와 포트를 수신하는지, 기본 아웃바운드가 무엇인지, direct와 block이 어떻게 정의되었는지, 라우팅 규칙이 어떤 순서로 매칭되는지, DNS 요청이 어디에서 나가는지를 명확히 파악해야 합니다. 클라이언트에서 내보낸 설정이나 실행 로그로 항목별 대조는 가능하지만, 임시로 생성된 파일을 직접 수정하지 마세요. 먼저 화면의 선택 항목과 최종 필드 사이의 관계를 정리해야 클라이언트 업그레이드 후 특정 동작이 달라진 이유를 판단할 수 있습니다.

자신만의 트래픽 경로 표를 만들어 보세요. 애플리케이션 이름, 진입 방식, 인바운드 태그, 매칭 규칙, 대상 아웃바운드와 DNS 경로를 기록합니다. 표의 각 열은 설정이나 로그에서 근거를 찾을 수 있어야 합니다. 어떤 열을 감으로만 채울 수 있다면 해당 단계는 아직 확인이 필요하다는 뜻입니다. 이 과정을 마친 뒤에야 복잡한 앱별 설정, 다중 진입점이나 다중 아웃바운드 환경을 다루세요. 규칙이 늘어난 뒤에도 설명 가능성을 유지할 수 있습니다.

2단계: 태그로 다중 진입점과 다중 출구 구성하기

다중 인바운드는 앱이나 용도별로 트래픽을 분리할 때 유용합니다. 예를 들어 하나의 SOCKS 인바운드는 브라우저에, 다른 인바운드는 개발 도구에 사용한 뒤 inboundTag로 서로 다른 아웃바운드를 지정할 수 있습니다. 다중 아웃바운드는 direct, block과 여러 원격 연결을 조합할 수 있게 합니다. 태그 이름은 socks-browser, direct, block처럼 역할이 드러나야 하며 기억하기 어려운 임시 번호는 피하세요. 태그 이름을 바꿀 때는 모든 참조도 함께 수정해야 합니다.

다중 아웃바운드가 반드시 복잡한 자동 선택을 필요로 하는 것은 아닙니다. 먼저 명확한 정적 규칙을 만들고 각 트래픽 유형이 예상한 출구로 안정적으로 들어가는지 확인한 뒤 장애 조치나 부하 분산을 고려하세요. 자동 정책은 상태 확인, 연결 상태와 코어 기능에 의존하므로 문제가 발생했을 때 더 많은 로그가 필요합니다. 기본 라우팅이 안정되지 않은 상태에서 자동 정책을 추가하면 실제 출구를 예측하기만 더 어려워집니다.

3단계: DNS를 독립적인 하위 시스템으로 관리하기

복잡한 설정에서 DNS는 단순한 서버 주소 하나가 아닙니다. 조회 유형, 도메인 분류, 해석 출구, 캐시 동작과 대체 조건을 명확히 정해야 합니다. LAN 도메인에는 로컬 DNS가 필요할 수 있고, 공용 도메인은 라우팅 정책에 따라 해석 경로를 선택할 수 있으며, 특정 도메인에는 별도의 규칙을 적용할 수도 있습니다. 모든 옵션을 사용할 수 있다는 이유만으로 일괄 활성화하지 말고 실제 필요에 따라 나누세요.

DNS를 확인할 때는 먼저 어느 계층에서 요청을 시작했는지, 다음으로 반환된 주소가 예상과 맞는지, 마지막으로 해당 주소가 어느 라우팅 경로를 통과하는지 확인하세요. 해석 결과만 보면 조회 출구의 네트워크 경로 차이를 놓칠 수 있고, 라우팅만 보면 잘못된 주소로 인한 연결 실패를 라우팅 문제로 오해할 수 있습니다. DNS 변경과 GeoIP·GeoSite 업데이트는 분리해 한 번에 하나의 판단 기준만 바꾸도록 하세요.

4단계: 설정 변경과 복구 규칙 만들기

장기간 유지할 설정은 읽기 쉬운 설명을 남겨야 하지만 표준 JSON 자체는 주석을 지원하지 않습니다. 주석은 별도의 설명 문서, 클라이언트 메모 또는 변경 기록에 작성하세요. 변경할 때마다 목표, 기존 값, 새 값, 확인 결과와 복구 단계를 기록합니다. 특히 라우팅 규칙은 “왜 필요한지”를 적어야 합니다. 그렇지 않으면 몇 달 뒤 오래된 규칙을 필수 조건으로 오해하기 쉽습니다.

설정 백업에는 구독 이름, 사용자 지정 라우팅, DNS, 수신 포트와 TUN 옵션을 포함하되 저장 위치의 접근 범위는 제한해야 합니다. 복구할 때는 기존 상태를 한꺼번에 가져오지 말고 구독과 기본 설정부터 복원한 뒤 작동을 확인하고 라우팅과 TUN을 복원하세요. 플랫폼을 옮길 때는 공통 로직만 이전하고 시스템 프록시, 가상 네트워크 어댑터와 권한 설정까지 그대로 복사할 수 있다고 가정하지 마세요.

5단계: 고정된 확인 목록 만들기

완전한 확인 목록에는 클라이언트가 정상적으로 시작되는지, 코어 설정이 성공적으로 로드되는지, 로컬 포트가 수신 중인지, 시스템 프록시 또는 TUN 상태가 예상과 맞는지, 도메인 해석이 가능한지, 사설 주소가 직접 연결되는지, 지정한 도메인이 예상 규칙에 매칭되는지, 네트워크 전환 후 복구되는지, 클라이언트를 종료했을 때 시스템 프록시와 가상 인터페이스가 올바르게 정리되는지를 포함할 수 있습니다. 목록의 각 항목에는 “네트워크 정상”처럼 추상적인 표현이 아니라 구체적인 확인 방법이 있어야 합니다.

새 문제가 발생하면 먼저 현상을 설정, 인바운드, DNS, 라우팅, 아웃바운드 또는 시스템 가로채기 중 어느 계층에 해당하는지 분류한 뒤 이 안내서의 관련 장을 확인하세요. 빠른 시작은 입문 가이드로 돌아가고, 설치 패키지를 다시 선택하려면 클라이언트 다운로드 페이지로 이동하세요. 클라이언트 기능 차이는 클라이언트 비교에서 확인할 수 있습니다. 설정 구조, 포트 충돌 또는 라우팅 데이터베이스 문제라면 본문 링크의 관련 문서에서 계속 원인을 좁혀 가세요.