V2Ray 전체 플랫폼 설치 및 설정 가이드

01 / PREPARE

공통 사전 준비: 클라이언트·코어·구독 구분하기

클라이언트는 노드도, 구독 서비스도 아닙니다

설치하기 전에 세 가지 용어부터 구분해야 합니다. v2rayN, v2rayNG, v2flyNG는 설정을 저장하고 코어를 호출하며 시스템 프록시를 설정하고 실행 로그를 표시하는 그래픽 클라이언트입니다. V2Fly와 Xray는 코어 계열로, 인바운드·아웃바운드·라우팅·DNS·전송 프로토콜을 실제로 처리합니다. 구독 링크는 서비스 제공자가 관리하는 노드 목록이며, 클라이언트가 링크를 읽어 선택 가능한 서버 설정으로 변환합니다. 클라이언트만 설치한다고 연결 가능한 노드가 자동으로 생기지는 않습니다. 반대로 구독 링크만 있고 호환 클라이언트가 없으면 해당 설정으로 시스템 트래픽을 바로 전송할 수도 없습니다.

데스크톱 플랫폼에서는 v2rayN를 우선 선택하세요. Windows에는 데스크톱 버전과 클래식 WPF 버전이 제공되고, macOS와 Linux에도 해당 설치 패키지가 있습니다. 메뉴 위치는 인터페이스 버전에 따라 조금 다르지만 핵심 개념은 같습니다. 구독 그룹은 링크를 저장하고, 서버 목록은 노드를 저장하며, 시스템 프록시는 브라우저처럼 시스템 설정을 따르는 프로그램의 트래픽을 처리합니다. TUN은 가상 네트워크 인터페이스로 더 많은 트래픽을 넘겨받습니다. Android에서는 Xray 코어를 탑재한 v2rayNG를 우선 사용하고, V2Fly 코어 계열이 필요할 때 v2flyNG를 고려하세요. 실제 설치 패키지는 사이트의 클라이언트 페이지에서 플랫폼에 맞게 선택하면 됩니다.

설치 전 확인해야 할 네 가지 기본 정보

설정을 준비할 때는 구독 링크가 완전한지, 기기 시간이 자동으로 동기화되는지, 현재 네트워크에서 일반 웹사이트에 정상적으로 접속할 수 있는지, 시스템 아키텍처가 무엇인지 확인하세요. 구독 링크는 보통 HTTP 또는 HTTPS로 시작하는 주소입니다. 복사할 때 공백, 줄바꿈, 메신저가 덧붙인 문장 부호가 포함되지 않도록 주의하세요. 시스템 시간 오차는 TLS 핸드셰이크와 인증서 판정에 영향을 주어 노드는 보이지만 연결이 즉시 실패하는 현상을 만들 수 있습니다. 먼저 시스템에서 시간과 시간대 자동 설정을 켠 뒤 클라이언트 문제를 확인하는 편이 노드를 계속 바꾸는 것보다 효과적입니다.

시스템 아키텍처에 따라 설치 패키지가 달라집니다. Windows의 일반적인 기기는 x64를 사용합니다. macOS에서는 Apple Silicon과 Intel 패키지 중 하나를 선택해야 합니다. Android 주류 기기는 대개 arm64를 사용하며, 아키텍처를 확인하기 어렵다면 범용 패키지를 사용할 수 있습니다. Linux는 아키텍처뿐 아니라 배포판의 패키지 체계도 확인해야 합니다. Debian, Ubuntu 및 파생 시스템은 보통 deb를 사용하고, Fedora, RHEL 계열 및 관련 배포판은 대개 rpm을 사용합니다. 패키지 형식을 잘못 선택해도 보통 시스템이 손상되지는 않지만, 설치 프로그램이 거부하거나 아키텍처 불일치 오류를 표시합니다.

되돌릴 수 있는 최소 설정 만들기

처음 실행할 때 라우팅, DNS, 전송 계층 매개변수, TUN을 동시에 바꾸지 마세요. 최소 설정은 네 단계면 충분합니다. 구독 가져오기, 구독 업데이트, 노드 하나 선택, 시스템 프록시 또는 모바일 연결 켜기입니다. 이후 브라우저로 원래 안정적으로 접속되던 웹사이트를 열고 클라이언트 로그를 확인하세요. 연결이 성공한 다음 분할 라우팅과 DNS를 추가하고, 한 번에 한 종류의 설정만 변경해야 이상이 생긴 단계를 추적할 수 있습니다. ‘갑자기 전부 작동하지 않는’ 문제는 노드가 동시에 모두 고장 난 것이 아니라 여러 고급 옵션을 한꺼번에 바꿔 원인을 추적하기 어려워진 경우가 많습니다.

초기 구독 그룹에는 알아보기 쉬운 이름을 지정하고 기본 라우팅 설정은 유지하는 것이 좋습니다. 업데이트하기 전에 구독으로 생성된 노드 필드를 수동으로 수정하지 마세요. 다음 업데이트에서 대개 해당 변경 사항이 덮어쓰기됩니다. 특정 노드의 전송 매개변수를 조정해야 한다면 독립 설정으로 복제하거나, 서비스 제공자가 서버 측 수정을 지원하는지 먼저 확인하세요. 구독 링크 자체는 민감한 설정이므로 공개 스크린샷, 로그, 문의 글에 붙여 넣지 않아야 합니다. 문제 해결에 필요한 경우 오류 유형, 발생 시각, 클라이언트 상태만 남기고 도메인, 사용자 식별자, 노드 주소는 필요한 만큼 가리세요.

마지막으로 되돌릴 경로를 준비하세요. 시스템 프록시 스위치의 위치를 기억하고, 클라이언트를 종료한 뒤 시스템 네트워크를 어떻게 복구할지 확인합니다. 데스크톱에서 시스템 프록시를 사용했다면 클라이언트를 종료하기 전에 시스템 프록시를 해제하세요. TUN을 사용했다면 먼저 TUN을 끈 다음 프로그램을 종료합니다. Android는 연결을 끊기만 하면 시스템 연결이 해제됩니다. 이 준비가 끝나면 플랫폼별 설치 과정은 인터페이스와 권한 모델만 다를 뿐, 구독·노드·라우팅·DNS의 기본 원리는 같습니다.

02 / WINDOWS

Windows: v2rayN 설치, 구독 및 시스템 프록시

데스크톱 버전과 클래식 WPF 버전 선택 방법

Windows에서는 v2rayN를 우선 사용하세요. 다운로드 페이지에는 데스크톱 버전과 클래식 WPF 버전이라는 두 가지 선택지가 있습니다. 데스크톱 버전은 차세대 크로스플랫폼 인터페이스를 사용해 새로 설치하거나 여러 데스크톱 시스템을 함께 사용하는 사람에게 적합합니다. 클래식 WPF 버전은 Windows 네이티브 인터페이스 방식으로 메뉴 밀도가 높아 기존 버전의 조작 방식에 익숙한 사용자에게 알맞습니다. 두 버전 모두 구독 관리, 노드 선택, 시스템 프록시, 라우팅, TUN 설정을 지원하므로 동시에 설치할 필요는 없습니다. 망설여진다면 데스크톱 버전을 먼저 사용하고, 인터페이스 호환성·기존 설정 이전·사용 습관에 분명한 이유가 있을 때만 WPF 버전을 선택하세요.

전체 설치 패키지를 다운로드한 뒤 설치 프로그램의 안내에 따라 설치를 완료하세요. 시스템에 사용자 계정 컨트롤 창이 나타나면 프로그램 이름과 현재 작업이 일치하는지 확인한 뒤 계속 진행하도록 허용하세요. 설치 경로는 현재 사용자가 쓰기 가능한 디렉터리를 선택하고, 자동으로 정리될 수 있는 위치에는 프로그램 데이터 디렉터리를 두지 않는 것이 좋습니다. 처음 실행하면 v2rayN가 보통 설정 디렉터리를 만들고 코어 구성 요소를 준비합니다. 방화벽 알림이 나타나면 실제로 필요한 네트워크 범위만 허용하세요. 일반적인 단일 기기 사용에서는 ‘연결 실패 방지’를 이유로 관련 없는 인바운드 접근을 열 필요가 없습니다.

구독을 가져오고 활성 노드 선택하기

구독 그룹 관리로 들어가 그룹 이름을 추가한 뒤, 전체 구독 주소를 URL 입력란에 붙여 넣고 저장하세요. 이어서 구독 업데이트를 실행합니다. 업데이트가 성공하면 기본 목록에 서버 항목이 나타납니다. 링크만 저장하고 업데이트하지 않았다면 목록이 비어 있는 것이 정상입니다. 노드 하나를 선택해 활성 서버로 지정하면 상태 표시줄이나 목록의 표시로 현재 선택을 확인할 수 있습니다. 노드 이름은 구독에 포함된 설명일 뿐 연결 품질을 의미하지 않습니다. 처음 테스트할 때는 여러 노드를 연속으로 측정하지 말고 설정이 완전한 항목 하나를 골라 기본 연결부터 확인하세요.

업데이트에 실패하면 먼저 링크 앞뒤에 공백이 붙었는지, 브라우저에서 구독 주소를 열 수 있는지, 그룹이 활성화되어 있는지 확인하세요. 구독 내용은 Base64 텍스트, 공유 링크 모음, 구조화된 설정일 수 있으며 클라이언트가 내용에 따라 형식을 판별합니다. 전체 구독 내용을 단일 노드 편집기에 직접 붙여 넣지 말고, 단일 VMess 또는 VLESS 공유 링크를 구독 URL에 잘못 입력하지도 마세요. 단일 공유 링크는 클립보드에서 서버로 가져오고, 구독 URL은 구독 그룹에 입력해야 합니다. 두 입력 경로의 용도가 다릅니다.

먼저 시스템 프록시를 켜고 TUN 필요 여부를 판단하세요

노드를 선택한 뒤 서비스를 시작하고, 시스템 프록시 모드를 ‘시스템 프록시 자동 설정’ 또는 활성화 상태가 명확히 표시된 모드로 지정하세요. 이제 Windows 시스템 프록시를 따르는 브라우저와 데스크톱 앱의 트래픽이 v2rayN로 전달됩니다. 로컬 수신 포트는 클라이언트가 관리하므로 보통 직접 입력할 필요가 없습니다. 프로그램 자체에 프록시 설정이 있다면 ‘시스템 프록시 사용’을 선택하세요. 시스템 설정을 읽지 않는 경우에만 v2rayN에 표시된 현재 로컬 HTTP 또는 SOCKS 포트를 확인해 별도로 입력하면 됩니다.

시스템 프록시는 먼저 설정을 검증하기에 적합합니다. 경로가 짧고 필요한 권한이 적으며 끄기도 쉽기 때문입니다. 게임, 일부 명령줄 프로그램, 스토어 앱, 자체 네트워크 스택을 구현한 소프트웨어가 시스템 프록시를 우회할 때 TUN을 고려하세요. TUN을 켜려면 관리자 권한이 필요하고 가상 네트워크 어댑터가 생성되는 경우가 많습니다. 처음 활성화한 뒤에는 DNS, 로컬 네트워크 접근, 절전 모드 해제 후 상태를 다시 테스트하세요. 브라우저에서 웹페이지가 열리는지만 확인해서는 안 됩니다. 켠 뒤 전체 네트워크가 끊기면 먼저 TUN을 끄고 시스템 프록시가 여전히 작동하는지 확인한 다음 드라이버·라우팅·DNS를 점검하세요.

Windows에서 흔한 잔여 프록시 및 권한 문제

클라이언트 종료 후 인터넷이 끊기는 가장 흔한 원인은 시스템 프록시가 이미 종료된 로컬 포트를 계속 가리키는 것입니다. v2rayN를 다시 열어 시스템 프록시 해제를 실행한 뒤 정상적으로 종료하세요. 또는 Windows의 네트워크 및 인터넷 설정에서 수동 프록시와 설정 스크립트가 남아 있는지 확인할 수 있습니다. 처음부터 전체 네트워크 스택을 초기화하지 마세요. 다른 네트워크 소프트웨어와 저장된 설정에도 영향을 줍니다. 먼저 프록시 주소가 루프백 주소를 가리키는지, 해당 포트가 아직 수신 중인지 확인하면 대개 원인을 찾을 수 있습니다.

클라이언트가 설정을 저장하지 못하거나 업데이트 후 설정이 사라지고 로그에 액세스 거부가 표시된다면 설치 디렉터리와 보안 소프트웨어의 제어된 폴더 액세스 정책을 확인하세요. 일상적인 실행에서 관리자 모드를 계속 강제하는 것은 권장하지 않습니다. 관리자 권한이 필요한 기능은 작업 시 안내에 따라 허용하세요. TUN만 실패하고 시스템 프록시는 정상이라면 구독·노드·코어는 대체로 작동하는 것이므로 가상 어댑터, 라우팅 충돌, 권한으로 범위를 좁혀야 합니다. 시스템 프록시도 실패한다면 노드·시간·구독 필드·코어 로그로 돌아가세요.

명령줄 프로그램이 이전 프록시 환경 변수를 물려받고 있는지도 먼저 확인할 수 있습니다. 아래 PowerShell 명령은 현재 환경만 읽으며 설정을 변경하지 않습니다. 이미 사용할 수 없는 주소가 출력되면 클라이언트 노드를 계속 바꾸지 말고 해당 터미널 설정이나 시스템 환경 변수에서 삭제하세요.

Get-ChildItem Env:HTTP_PROXY
Get-ChildItem Env:HTTPS_PROXY
Get-ChildItem Env:ALL_PROXY

Windows가 절전 모드에 들어갔다가 복귀하거나 네트워크를 전환한 뒤 가상 어댑터와 이전 라우팅이 즉시 갱신되지 않을 수 있습니다. 먼저 클라이언트 연결을 끊고 네트워크 아이콘이 복구될 때까지 기다린 다음 서비스를 다시 시작하세요. 자주 발생한다면 일상적인 웹 사용에는 시스템 프록시를 우선 사용하고, 더 많은 프로그램을 연결해야 할 때만 TUN을 켜는 것이 좋습니다. 첫 설정 순서는 입문 가이드에서 확인할 수 있으며, 이 장에서는 버전 선택과 Windows 특유의 문제를 다룹니다.

03 / MACOS

macOS: 칩 선택, 권한 및 프록시 설정

Apple Silicon 또는 Intel부터 확인하세요

macOS에서 v2rayN를 사용할 때 첫 단계는 운영체제 이름이 아니라 프로세서 아키텍처를 확인하는 것입니다. 시스템 정보 또는 ‘이 Mac에 관하여’를 열어 Apple 계열 칩이면 Apple Silicon용 arm64 설치 패키지를 선택하고, Intel 프로세서면 x64 패키지를 선택하세요. 아키텍처를 잘못 고르면 시스템이 실행을 거부하거나 별도의 변환 계층이 필요할 수 있어 변수가 늘고 문제 해결도 어려워집니다. 다운로드 페이지에는 칩별 선택지가 나뉘어 있으므로 확인 후 설치하면 됩니다.

설치는 보통 dmg를 연 뒤 애플리케이션을 Applications로 옮기는 방식입니다. 처음 실행할 때 보안 확인이 나타나면 시스템 설정의 개인정보 보호 및 보안 페이지에서 차단 이유를 확인하고, 출처와 현재 다운로드 작업이 일치하는지 확인한 뒤 실행을 허용하세요. 앱 하나 때문에 전체 시스템의 보안 정책을 장기간 낮추지 마세요. v2rayN가 시스템 프록시를 수정하거나 네트워크 확장을 만들 때는 별도의 권한을 요청합니다. 이러한 권한은 일반 파일 접근 권한과 다르므로 해당 기능을 실제로 활성화할 때 안내에 따라 부여하세요.

구독 가져오기와 노드 선택

구독 설정으로 들어가 새 그룹을 만들고 구독 링크를 붙여 넣어 저장한 다음 업데이트를 실행하세요. macOS 버전은 Windows 버전과 화면 배치가 다를 수 있지만 구독 그룹, 서버 목록, 현재 활성 노드, 프록시 모드라는 네 부분을 중심으로 동작합니다. 업데이트 후 노드 목록이 나타나면 하나를 선택하고 서비스를 시작하세요. ‘구독이 업데이트됨’은 ‘트래픽이 이미 클라이언트를 통과함’을 의미하지 않습니다. 구독 업데이트는 설정 동기화만 완료하며, 실제 연결 여부는 프록시 스위치에 달려 있습니다.

메신저에서 링크를 복사했다면 줄바꿈과 텍스트 자동 변환에 특히 주의하세요. 먼저 일반 텍스트 편집기에 붙여 넣어 링크가 한 줄인지 확인한 뒤 클라이언트에 입력하는 것이 좋습니다. 쿼리 매개변수가 포함된 구독 주소는 끝부분도 잘리지 않아야 합니다. 업데이트 중 인증서 또는 핸드셰이크 오류가 발생하면 시스템 시간, 현재 네트워크, 구독 주소 자체를 먼저 확인하세요. 다른 노드는 정상이고 특정 노드만 실패한다면 해당 노드 필드를 점검하고 전체 구독 그룹을 삭제하지 마세요.

시스템 프록시와 앱 프록시의 경계

시스템 프록시를 활성화하면 Safari, 시스템 네트워크 설정을 따르는 브라우저, 많은 데스크톱 소프트웨어가 v2rayN의 로컬 프록시를 사용합니다. 터미널 명령과 일부 개발 도구가 시스템 프록시를 자동으로 읽는지는 각 도구에 따라 다릅니다. 터미널 요청이 달라지지 않았다고 클라이언트 전체가 고장 났다고 판단하지 말고, 시스템 프록시를 따르는 브라우저에서도 확인하세요. 특정 명령줄 도구가 HTTP 또는 SOCKS 프록시를 명시적으로 지원한다면 해당 도구의 설정에 클라이언트가 표시한 로컬 주소와 포트를 입력하면 됩니다.

클라이언트를 종료하기 전에 시스템 프록시를 해제하세요. 앱은 이미 종료했는데 모든 웹페이지가 열리지 않는다면 시스템 설정의 네트워크 세부 정보에서 HTTP 프록시, HTTPS 프록시, 자동 프록시 구성이 여전히 활성화되어 있는지 확인하세요. 잔여 주소는 127.0.0.1의 특정 포트를 가리키는 경우가 많지만, 이때는 로컬에서 수신 중인 프로세스가 없습니다. 해당 항목을 끄면 네트워크가 복구됩니다. Wi-Fi를 삭제하거나 네트워크를 잊게 하거나 DNS를 초기화할 필요는 없습니다. 먼저 직접적인 프록시 잔여 설정부터 처리하세요.

TUN, 네트워크 확장 및 로컬 네트워크 접근

macOS의 TUN은 네트워크 확장 또는 가상 인터페이스 권한과 관련됩니다. 시스템에서 처음 허용한 뒤에도 기능을 다시 활성화해야 적용될 수 있습니다. 켜기 전에 시스템 프록시 모드에서 연결이 안정적인지 확인하세요. TUN이 실패했을 때 가장 유용한 비교 대상은 ‘같은 노드가 시스템 프록시에서는 작동하는가’이기 때문입니다. 시스템 프록시는 정상이고 TUN을 켠 뒤 인터넷이 끊긴다면 DNS 가로채기, 기본 라우팅, 다른 네트워크 확장과의 충돌부터 확인하세요. 전역 트래픽을 동시에 처리하는 소프트웨어가 여러 개 실행되면 라우팅 우선순위와 DNS 설정이 서로 덮어쓸 수 있습니다.

프린터, 파일 공유, 라우터 관리 페이지에 접근해야 한다면 로컬 네트워크 주소는 직접 연결로 유지하세요. 일반적인 사설 주소 대역은 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16이며 루프백 주소와 링크 로컬 주소도 원격 노드로 보내지 않아야 합니다. 기본 분할 라우팅에는 보통 이러한 규칙이 포함되어 있지만 사용자 지정 라우팅 후에는 다시 확인해야 합니다. 로컬 네트워크 장치만 접근할 수 없다면 노드 프로토콜을 바꾸지 말고 사설 주소가 잘못 프록시 아웃바운드로 전송되는지 라우팅 규칙을 확인하세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

Wi-Fi, 핫스팟, 유선 네트워크를 전환한 뒤에도 이전 시스템 프록시가 남아 있을 수 있지만, 클라이언트를 다시 시작하면 로컬 포트는 복구됩니다. 올바른 순서는 연결을 끊고 네트워크를 전환한 뒤 기본 네트워크가 작동하는지 확인하고 다시 연결하는 것입니다. 네트워크 전환 후 구독은 업데이트되지만 웹페이지가 열리지 않는다면 현재 활성 노드, 프록시 모드, DNS를 확인하세요. 구독도 업데이트되지 않는다면 새 네트워크의 인증 페이지와 연결 상태부터 점검하세요.

macOS에서 중요한 것은 특수 설정을 늘리는 것이 아니라 시스템 권한과 네트워크 확장의 경계를 지키는 것입니다. 시스템 프록시로 충분하다면 단순하게 유지하고, 더 많은 앱을 연결해야 할 때만 TUN을 켜세요. 로컬 네트워크 서비스가 필요하면 사설 주소를 명확히 직접 연결로 남겨 두세요. 네트워크 확장을 변경할 때마다 브라우저, 터미널, 로컬 네트워크라는 세 방향을 다시 확인하면 웹페이지 하나만 테스트할 때보다 경계 문제를 빠르게 찾을 수 있습니다.

04 / LINUX

Linux: 패키지, 데스크톱 프록시 및 TUN 권한

deb, rpm 및 아키텍처 선택

Linux 데스크톱에서는 v2rayN를 사용합니다. 다운로드 전에 배포판의 패키지 체계와 CPU 아키텍처를 확인하세요. Debian, Ubuntu, Linux Mint 등은 보통 deb를 선택하고, Fedora, RHEL 계열 및 rpm 패키지 관리자를 사용하는 배포판은 rpm을 선택합니다. x86_64 기기는 x64 패키지를, arm64 기기는 해당 arm64 패키지를 사용합니다. 터미널에서 uname -m을 실행하면 아키텍처를 확인할 수 있습니다. 일반적으로 x86_64 출력은 x64, aarch64 출력은 arm64에 해당합니다.

uname -m
cat /etc/os-release

로컬 deb 패키지를 설치할 때는 apt로 의존성을 처리하고, rpm 패키지는 현재 배포판의 패키지 관리 명령을 사용하는 것이 좋습니다. 아래 명령의 파일명은 현재 디렉터리에 실제로 다운로드한 파일명으로 바꿔야 하며 존재하지 않는 이름을 그대로 사용하면 안 됩니다. 그래픽 소프트웨어 센터에서도 설치할 수 있지만 의존성 오류가 발생하면 터미널 출력이 원인 파악에 더 유용합니다.

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

sudo dnf install ./v2rayN-linux-x64.rpm

설치 프로그램에서 아키텍처 불일치를 보고하면 검사를 강제로 무시하지 말고 올바른 설치 패키지를 다시 선택하세요. 데스크톱 런타임 라이브러리가 없다는 메시지가 나오면 먼저 배포판 버전이 아직 지원 기간인지 확인하고 시스템 저장소를 통해 의존성을 설치하세요. 관련 없는 출처의 라이브러리를 섞어 설치하지 마세요. 앱이 실행된 뒤에는 창, 트레이 아이콘, 설정 디렉터리가 현재 사용자 소유인지 확인하세요. 그래픽 클라이언트를 root로 계속 실행하면 설정 파일 소유권이 꼬여 이후 일반 사용자가 설정을 저장하지 못할 수 있습니다.

구독을 가져오고 데스크톱 환경 차이 이해하기

v2rayN의 구독 절차는 다른 데스크톱 플랫폼과 같습니다. 그룹 생성, 링크 붙여넣기, 저장, 업데이트, 활성 노드 선택 순서입니다. 차이는 주로 Linux 데스크톱 환경에서 발생합니다. GNOME, KDE 및 다른 데스크톱은 시스템 프록시 설정 위치와 앱이 설정을 상속하는 방식이 완전히 같지 않습니다. 브라우저는 대개 데스크톱 프록시를 읽지만 터미널 프로그램, 컨테이너, 백그라운드 서비스는 그렇지 않은 경우가 많습니다. 처음에는 데스크톱 브라우저로 검증하고 코어와 노드가 정상임을 확인한 뒤 명령줄 도구를 별도로 설정하세요.

일부 경량 데스크톱 환경에는 통합 시스템 프록시 인터페이스가 없습니다. 이 경우 v2rayN의 ‘시스템 프록시 설정’이 모든 앱에 적용되지 않을 수 있습니다. 클라이언트가 현재 수신 중인 HTTP 및 SOCKS 포트를 확인해 대상 앱의 프록시 설정에 주소를 입력하세요. 현재 터미널에서만 임시로 테스트할 때는 환경 변수를 설정할 수도 있습니다. 테스트가 끝나면 터미널을 닫아 되돌리고, 사용할 수 없는 포트를 셸 설정에 장기간 기록하지 않도록 하세요.

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

예시 포트는 형식을 설명하기 위한 것이며 실제 값은 반드시 클라이언트 화면에 표시된 값을 사용해야 합니다. v2rayN에서 로컬 포트를 변경했다면 환경 변수도 함께 바꿔야 합니다. 대소문자를 구분하는 변수는 도구마다 다르게 읽을 수 있으므로 문제 해결 시 env | grep -i proxy를 실행해 현재 세션을 확인하세요. 명령줄은 작동하지만 브라우저가 작동하지 않는다면 데스크톱 프록시가 설정되지 않았을 가능성이 높습니다. 브라우저는 작동하지만 명령줄이 작동하지 않는다면 도구가 시스템 프록시를 상속하지 않은 경우가 많습니다. 두 상황을 같은 문제로 보면 안 됩니다.

TUN에 필요한 권한과 라우팅 확인

Linux에서 TUN을 켜려면 /dev/net/tun에 접근하고 가상 인터페이스를 만들며 라우팅을 수정해야 합니다. v2rayN는 권한 상승 메커니즘을 통해 이러한 작업을 수행할 수 있습니다. 화면에 TUN 시작 실패가 표시되면 먼저 코어 모듈과 장치 노드가 존재하는지 확인하고, 로그에서 권한 오류를 확인하세요. 앱 전체를 영구적으로 root로 실행하지 마세요. 네트워크 관리 권한이 필요한 구성 요소에만 제한적으로 권한을 부여하고 사용자 설정은 일반 계정 소유로 유지하는 것이 올바른 방향입니다.

ls -l /dev/net/tun
ip address
ip route

TUN을 켜기 전과 후에 기본 라우팅과 DNS 상태를 각각 기록하세요. 켠 뒤 인터넷이 완전히 끊기면 TUN을 끈 후 기본 라우팅이 복구되는지 확인합니다. 알려진 주소에는 응답하지만 도메인만 열리지 않는다면 DNS 문제로 범위를 좁힐 수 있습니다. 로컬 네트워크 장치에 접근할 수 없다면 사설 주소가 TUN으로 잘못 전송되는지 확인하세요. NetworkManager, systemd-resolved, 데스크톱 환경의 DNS 관리가 동시에 존재할 수 있으므로 최종적으로 어느 계층이 적용되는지 확인하고 세 곳에 서로 다른 서버를 반복해서 입력하지 마세요.

절전 모드, 트레이 및 백그라운드 프로세스

일부 데스크톱 환경에서는 창을 닫아도 트레이로 숨겨지고, 다른 환경에서는 트레이 확장이 없어 창을 닫으면 프로그램이 종료됩니다. 처음 사용할 때 v2rayN의 종료 동작을 확인해 클라이언트가 종료된 것으로 착각하면서 시스템 프록시를 남겨 두지 않도록 하세요. 프로세스 목록과 포트 수신 상태로 코어가 계속 실행 중인지 확인할 수 있습니다. 시스템 프록시는 로컬 포트를 가리키지만 프로세스가 종료된 경우 브라우저의 모든 페이지 연결이 실패합니다.

절전 모드에서 복귀하면 네트워크 인터페이스 이름, 기본 라우팅, DNS가 다시 생성될 수 있습니다. 시스템 프록시 모드는 보통 다시 연결하기만 하면 되지만 TUN 모드는 껐다가 다시 켜야 할 수 있습니다. 복귀 후에도 로그에 이전 인터페이스가 표시되면 시스템 네트워크가 안정된 뒤 클라이언트를 재시작하세요. 컨테이너와 가상 머신은 독립적인 네트워크 네임스페이스를 사용하므로 호스트 시스템 프록시가 내부 트래픽까지 자동으로 처리하지 않습니다. 컨테이너에서 프록시를 사용하려면 프록시 주소를 명시적으로 설정하고 호스트의 수신 포트에 접근할 수 있는지 확인하세요.

Linux 문제 해결에서 가장 중요한 것은 ‘클라이언트 코어가 작동하는가’, ‘데스크톱 앱이 프록시를 읽는가’, ‘시스템 라우팅이 TUN에 의해 인계되었는가’라는 세 계층을 구분하는 것입니다. 한 명령의 결과로 모든 것을 판단하지 마세요. 브라우저, 프록시 환경 변수가 설정된 터미널 요청, ip route는 각각 다른 계층을 확인합니다. 계층별로 검증하면 데스크톱 환경의 차이를 노드 문제로 잘못 판단하는 일을 피할 수 있습니다.

05 / ANDROID

Android: v2rayNG, v2flyNG 및 연결 권한

클라이언트와 설치 패키지 선택

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 추천합니다. 대부분의 구독과 일반적인 프로토콜 설정에 적합합니다. v2flyNG는 V2Fly 코어를 사용하며 다른 코어 계열을 선택해야 할 때 대안이 될 수 있습니다. 두 클라이언트 모두 arm64와 범용 설치 패키지를 제공합니다. 2015년 이후 출시된 주류 스마트폰이라면 먼저 arm64를 선택하고, 기기 아키텍처가 불확실하거나 설치 시 호환되지 않는다는 메시지가 나오거나 더 다양한 기기를 지원해야 할 때 범용 패키지를 선택하세요. 두 클라이언트를 동시에 연결 상태로 두지 마세요. 시스템은 한 번에 이러한 연결 하나에만 네트워크를 할당합니다.

설치 패키지를 열면 현재 브라우저나 파일 관리자가 앱을 설치하도록 허용할지 시스템이 물을 수 있습니다. 이 권한은 실제 설치를 수행하는 앱에만 부여하고 설치가 끝나면 시스템 설정에서 끌 수 있습니다. 설치할 수 없다는 메시지가 나오면 다운로드가 완전한지, 아키텍처가 맞는지, 기기에 서명 출처가 다른 동일한 이름의 앱이 있는지 먼저 확인하세요. 직접 덮어쓰기가 실패하면 클라이언트의 중요한 설정을 먼저 백업한 뒤 기존 앱을 삭제할지 결정해야 구독과 수동 노드를 함께 잃지 않습니다.

구독 가져오기, 클립보드 링크 및 QR 코드

v2rayNG를 연 뒤 구독 설정에서 새 구독 주소를 추가하고 저장한 다음 기본 화면으로 돌아가 구독 업데이트를 실행할 수 있습니다. 업데이트가 성공하면 노드 목록이 생성되며, 항목 하나를 눌러 현재 설정으로 지정합니다. 단일 공유 링크는 ‘클립보드에서 가져오기’와 같은 메뉴를 사용하세요. QR 코드는 단일 노드나 클라이언트가 인식할 수 있는 설정을 가져올 때 적합합니다. 구독 QR 코드와 단일 노드 QR 코드는 겉모양이 같으므로, 스캔 결과가 구독 관리로 이동하는지 노드 목록으로 이동하는지 확인해 구분하세요.

QR 코드를 스캔해도 반응이 없으면 카메라 권한, QR 코드가 화면에 완전히 표시되었는지, 화면 반사를 먼저 확인하세요. 민감한 QR 코드를 온라인 인식 도구에 업로드할 필요는 없습니다. 링크를 복사할 때도 텍스트가 잘리지 않았는지 주의하세요. 구독 업데이트 후 노드가 비어 있다면 그룹 활성화 여부, 현재 코어가 구독 형식을 지원하는지, 링크가 로그인 페이지나 오류 페이지를 반환하지 않는지 확인하세요. 구독 입력 경로의 자세한 차이는 구독 링크 가져오기 단계에서 확인할 수 있습니다.

첫 연결과 앱별 프록시

노드를 선택한 뒤 연결 버튼을 누르면 시스템에서 네트워크 연결 권한을 요청합니다. 허용하면 상태 표시줄에 연결 표시가 나타나고 클라이언트 로그에 연결 과정이 기록됩니다. 첫 테스트에서는 기본 라우팅을 유지하고 복잡한 앱별 규칙은 켜지 마세요. 브라우저로 연결을 확인한 뒤 다른 앱을 점검하세요. Android에서는 데스크톱처럼 별도로 ‘시스템 프록시’를 전환할 필요가 없습니다. 연결 권한을 허용하면 시스템이 규칙에 맞는 앱 트래픽을 클라이언트로 전달합니다.

앱별 프록시는 어떤 앱을 클라이언트로 보낼지 결정합니다. 보통 선택한 앱만 프록시하거나 선택한 앱을 우회하는 두 가지 방식이 있습니다. 설정 전에 모드 이름을 정확히 읽어 논리가 반대로 적용되지 않도록 하세요. 시스템 구성 요소, 브라우저 엔진, 앱 본체가 서로 다른 패키지일 수 있습니다. 특정 앱이 예상대로 작동하지 않으면 외부 브라우저나 시스템 다운로드 관리자를 호출하는지 확인하세요. 처음에는 앱별 프록시를 활성화하지 않는 것이 좋습니다. 전체 연결이 성공한 뒤 앱을 하나씩 추가하거나 제외해야 문제를 쉽게 찾을 수 있습니다.

백그라운드 제한, 배터리 최적화 및 네트워크 전환

일정 시간 후 연결이 자동으로 끊기는 흔한 원인은 시스템의 백그라운드 앱 배터리 제한입니다. 앱 정보에서 v2rayNG 또는 v2flyNG의 백그라운드 실행을 허용하고, 기기에서 제공하는 옵션에 따라 해당 클라이언트에 적용된 강한 배터리 최적화를 해제하세요. 모든 앱을 제한 없음으로 바꿀 필요 없이 현재 클라이언트만 조정하면 됩니다. 작업 정리 도구가 백그라운드 프로세스를 강제로 종료한다면 해당 정리 규칙에서도 클라이언트를 제외하세요.

Wi-Fi와 모바일 네트워크를 전환할 때 기존 연결이 잠시 끊길 수 있습니다. 먼저 시스템이 주소를 할당받을 때까지 기다리고 클라이언트가 자동으로 복구되는지 확인하세요. 복구되지 않으면 수동으로 연결을 끊었다가 다시 연결합니다. Wi-Fi에 웹 인증이 필요하다면 클라이언트 연결을 먼저 끊고 인증을 완료한 뒤 다시 연결하세요. 특정 Wi-Fi에서만 실패하고 모바일 네트워크에서는 정상이라면 클라이언트 설정은 대체로 문제없습니다. 해당 네트워크의 DNS, 인증 페이지, IPv6 경로를 점검하고 앱을 재설치하지 마세요.

DNS, IPv6 및 로컬 네트워크 접근

Android에서 ‘앱에는 연결됨으로 표시되지만 도메인이 열리지 않는’ 경우 DNS부터 확인하세요. 클라이언트 내장 DNS, 시스템 프라이빗 DNS, 노드의 원격 해석이 함께 영향을 줄 수 있습니다. 처음 문제를 해결할 때는 클라이언트 기본 DNS를 유지하고 시스템 프라이빗 DNS가 현재 네트워크에서 접근할 수 없는 서버를 가리키지 않는지 확인하세요. 특정 도메인만 비정상적으로 해석된다면 모든 조회 경로를 바꾸지 말고 분할 DNS를 설정하세요.

IPv6 사용 가능 여부는 현재 모바일 네트워크, Wi-Fi, 노드 설정에 따라 달라집니다. 로그에 IPv6 주소를 선택했지만 연결 시간이 초과되었다고 표시되면 클라이언트 DNS 정책에서 현재 경로에 맞는 주소 계열을 우선 반환하도록 하거나 노드가 해당 출구를 지원하는지 확인하세요. 모든 시간 초과를 IPv6 탓으로 돌리지 말고 로그의 대상 주소와 오류 단계를 먼저 확인하세요. 로컬 네트워크 장치에 접근할 수 없다면 사설 주소 우회를 허용했는지, 앱별 규칙이 파일 관리자나 화면 전송 구성 요소를 부적절한 아웃바운드로 보내고 있지 않은지 확인하세요.

v2rayNG와 v2flyNG의 메뉴 이름은 인터페이스 업데이트에 따라 달라질 수 있지만 기본 흐름은 안정적입니다. 설정 가져오기, 노드 선택, 시스템 연결 허용, 로그 확인 순서입니다. 먼저 기본 설정으로 이 흐름을 완료한 뒤 앱별 설정, DNS, 백그라운드 제한을 조정하면 대부분의 Android 문제를 단일 변수로 나눌 수 있습니다. 두 클라이언트를 비교할 때도 같은 노드를 사용해야 차이가 코어 호환성 때문인지 노드 자체 때문인지 판단할 수 있습니다.

06 / SUBSCRIPTION

구독 및 노드 관리: 업데이트, 덮어쓰기와 호환성

구독 업데이트에서 실제로 하는 일

구독 업데이트는 속도 측정도 아니고 코어 재설치도 아닙니다. 클라이언트가 구독 주소에 요청을 보내 반환된 내용을 읽고 노드 필드를 파싱한 다음 해당 그룹의 서버 목록을 갱신합니다. 노드 이름, 주소, 포트, 사용자 식별자, 전송 방식, TLS 매개변수는 보통 구독에서 가져옵니다. 업데이트가 완료된 뒤 현재 활성 노드가 계속 유지될 수도 있고, 기존 항목이 삭제되어 다시 선택해야 할 수도 있습니다. ‘업데이트는 성공했지만 연결이 달라지지 않는다’면 현재 활성 노드가 여전히 이전 항목인지 먼저 확인하세요.

구독 그룹은 서로 다른 출처의 설정을 분리하는 데 유용합니다. 여러 구독을 구분하기 어려운 하나의 이름에 모두 넣지 말고 용도별로 그룹을 만드는 것이 좋습니다. 그룹을 업데이트하기 전에 현재 활성 서버를 기억해 두세요. 새 목록에 문제가 있으면 이미 검증한 다른 그룹으로 전환해 계속 확인할 수 있습니다. 클라이언트의 구독 링크는 접근 식별자를 포함할 수 있으므로 민감한 정보로 취급해야 합니다. 스크린샷에 주소 표시줄, QR 코드, 전체 노드 필드가 보이지 않게 하세요.

자동 업데이트와 수동 업데이트의 구분

수동 업데이트는 처음 가져올 때, 설정 변경 후 즉시 동기화할 때, 문제를 해결할 때 적합합니다. 자동 업데이트는 장기 관리에 편리하지만 너무 짧은 간격으로 설정하지 마세요. 구독 내용이 바뀌지 않았다면 반복 요청해도 노드 연결이 좋아지지 않습니다. 자동 업데이트에 실패해도 이미 저장된 이전 노드에는 영향이 없을 수 있으며, 클라이언트는 보통 로컬 목록을 계속 사용합니다. 이때 ‘구독 주소에 접근할 수 없는 문제’와 ‘기존 노드에 연결할 수 없는 문제’를 나누어 판단해야 합니다. 둘은 같은 장애가 아닙니다.

구독이 빈 내용, 웹페이지 텍스트, 인증 페이지를 반환하면 클라이언트가 형식 오류를 표시할 수 있습니다. 링크를 공개하지 않는 조건에서 로컬 브라우저로 요청 결과가 예상한 형식인지 확인할 수 있습니다. 브라우저에서는 열리지만 클라이언트에서 실패한다면 시스템 프록시 때문에 구독 업데이트 경로가 바뀌었는지, 인증서가 로컬 네트워크에서 교체되었는지, 클라이언트가 반환 형식을 지원하는지 확인하세요. 업데이트 시 프록시를 사용할지 직접 연결할지는 구독 주소의 접근 가능성에 따라 결정해야 하며 모든 네트워크에 하나의 고정 방식을 적용하지 마세요.

수동 수정이 덮어써지는 이유

구독 노드는 원격 목록에서 생성되므로 다음 업데이트에서 필드가 다시 기록됩니다. 노드 이름, 포트, 전송 매개변수를 수동으로 바꾸면 업데이트 과정에서 변경 사항이 덮어써질 수 있으며, 이는 정상적인 구독 관리 동작입니다. 사용자 설정을 유지하려면 노드를 독립 서버로 복제해 자동 업데이트 그룹에서 분리하세요. 또는 구독 제공자의 관리 화면에서 수정한 뒤 다시 동기화하세요. 생성된 결과를 직접 수정하는 방식은 임시 테스트에는 적합하지만 장기 관리에는 적합하지 않습니다.

라우팅과 DNS는 보통 클라이언트 수준의 설정이므로 노드 업데이트로 덮어써지지 않을 수 있습니다. ‘서버 필드’와 ‘로컬 정책’을 분리해 관리하세요. 서버 필드는 원격 연결 방식을 결정하고, 라우팅은 트래픽이 어느 아웃바운드로 갈지 결정하며, DNS는 도메인 해석 방식을 결정합니다. 노드 업데이트 후 모든 웹사이트의 동작이 갑자기 달라졌다면 활성 노드와 서버 필드를 먼저 확인하고, 일부 도메인만 예상과 다르게 연결될 때 라우팅과 DNS를 점검하세요.

프로토콜 필드와 코어 호환성

일반적인 구독에는 VMess, VLESS, Trojan 등의 노드가 포함될 수 있습니다. 프로토콜 이름은 첫 번째 단서일 뿐이며, 실제 연결 여부는 전송 방식, TLS, 보안 매개변수, 서버 이름, 경로 등의 필드에도 좌우됩니다. 클라이언트가 노드 이름을 인식한다고 해서 모든 필드가 완전하다고 볼 수는 없습니다. 로그에 ‘알 수 없는 필드’, ‘지원되지 않는 전송 방식’, 설정 파싱 실패가 표시된다면 구독 생성 형식과 현재 코어의 지원 범위가 맞지 않을 가능성이 큽니다.

Android에서는 v2rayNG와 v2flyNG를 사용해 코어 계열을 비교할 수 있지만, 같은 노드와 네트워크, 가능한 한 동일한 라우팅 설정을 유지해야 합니다. 한 코어에서만 특정 설정이 작동한다고 해서 다른 클라이언트 전체에 문제가 있다는 뜻은 아닙니다. 특정 필드의 구현이나 지원 범위가 다를 수 있습니다. 데스크톱의 v2rayN도 현재 선택한 코어가 노드 요구 사항과 맞는지 확인해야 합니다. 노드 이름만 보고 프로토콜을 추측하지 말고 설정 세부 정보에서 실제 필드를 확인하는 편이 정확합니다.

구독 문제의 계층별 점검

첫 번째 계층은 링크입니다. 완전한지, 만료되지 않았는지, 공백이 섞이지 않았는지 확인하세요. 두 번째 계층은 요청입니다. 현재 네트워크에서 접근 가능한지, 반환값이 실제 구독 본문인지 확인합니다. 세 번째 계층은 파싱입니다. 클라이언트가 형식을 인식하는지, 로그에 필드 오류가 기록되는지 확인하세요. 네 번째 계층은 연결입니다. 노드가 도메인 해석, TCP 연결, TLS 핸드셰이크를 완료할 수 있는지 확인합니다. 계층별로 처리하면 구독을 계속 삭제하고 다시 추가하는 것보다 빠르고, 작동하는 설정도 보존할 수 있습니다.

구독에 포함된 수십 개 노드가 동시에 실패한다면 기기 시간, DNS, 네트워크, 구독 필드의 전체 변경, 코어 설정처럼 공통 조건을 먼저 의심하세요. 하나의 노드만 실패한다면 해당 노드의 주소, 포트, 전송 매개변수를 확인합니다. 노드는 연결되지만 특정 웹사이트만 실패한다면 라우팅과 DNS 계층으로 넘어가세요. 이 판단 트리를 사용하면 모든 문제를 ‘구독이 만료됐다’고 단정하는 일을 피할 수 있습니다.

구독 관리의 목표는 목록을 무작정 늘리는 것이 아니라 설정 출처, 업데이트 시각, 현재 활성 노드를 추적 가능하게 유지하는 것입니다. 그룹을 명확히 구분하고 검증된 노드 하나를 비교 대상으로 남겨 두며, 고급 매개변수를 바꾸기 전에는 기존 값을 기록하세요. 그러면 구독 내용이 바뀌어도 문제가 원격 목록, 클라이언트 파싱, 로컬 네트워크 중 어디에서 발생했는지 빠르게 판단할 수 있습니다.

07 / PROXY AND TUN

시스템 프록시, TUN, 라우팅과 DNS의 관계

시스템 프록시는 이를 읽는 프로그램만 처리합니다

시스템 프록시는 본질적으로 로컬 HTTP 또는 SOCKS 진입점을 운영체제와 앱에 알려 주는 기능입니다. 브라우저와 일부 데스크톱 소프트웨어가 이 설정을 읽고 요청을 v2rayN로 전달합니다. 모든 데이터 패킷을 강제로 가로채지는 않으므로 일부 게임, 명령줄 도구, 백그라운드 서비스, 자체 네트워크 스택을 구현한 프로그램은 우회할 수 있습니다. 시스템 프록시는 필요한 권한이 적고 경로가 명확하며 끄기 쉬워 첫 연결과 일상적인 웹 사용의 기본 방식으로 적합합니다.

클라이언트는 보통 127.0.0.1 같은 루프백 주소에서 HTTP 및 SOCKS 포트를 수신합니다. 루프백 주소는 본인 기기에서만 접근할 수 있어 단일 기기 사용에 적합합니다. 로컬 네트워크 연결 허용을 켤 때는 수신 범위와 방화벽 규칙을 명확히 정하고, 로컬 앱 연결을 위해 모든 네트워크 인터페이스에 포트를 공개하지 마세요. 앱에서 프록시를 수동 설정할 때는 프로토콜과 포트가 일치해야 합니다. SOCKS 포트를 HTTP 프록시 입력란에 넣으면 연결 거부나 프로토콜 핸드셰이크 실패처럼 보이는 결과가 발생합니다.

TUN이 더 많은 앱을 처리할 수 있는 이유

TUN은 가상 네트워크 인터페이스를 만들고 시스템 라우팅을 해당 인터페이스로 향하게 한 뒤, 각 연결을 프록시로 보낼지 직접 연결할지 클라이언트가 판단하도록 합니다. 앱이 프록시 프로토콜을 이해할 필요가 없으므로 시스템 프록시보다 적용 범위가 넓습니다. 대신 더 높은 권한이 필요하고 시스템 라우팅, DNS, 다른 가상 네트워크 소프트웨어와 상호작용할 수 있습니다. TUN은 ‘더 빠른 모드’가 아니며 잘못된 노드를 고쳐 주지도 않습니다. 앱이 시스템 프록시를 읽지 않는 문제를 해결하는 기능입니다.

활성화 순서는 다음과 같아야 합니다. 먼저 같은 노드가 시스템 프록시에서 작동하는지 확인하고 현재 DNS와 로컬 네트워크 상태를 기록한 뒤, 기본 라우팅을 가로채는 다른 소프트웨어를 끄고 TUN을 켭니다. 검증할 때는 일반 도메인, 로컬 네트워크 주소, 시스템 프록시를 우회하던 프로그램 하나 이상을 테스트하세요. 브라우저는 작동하지만 로컬 네트워크가 끊기면 사설 주소 직접 연결을 확인하고, 모든 도메인이 실패하면 DNS를 확인하세요. 특정 프로그램만 실패한다면 특수 프로토콜이나 독립 네트워크 환경을 사용하는지 살펴보세요.

라우팅 규칙은 순서대로 매칭됩니다

라우팅 규칙은 트래픽을 어느 아웃바운드로 보낼지 결정합니다. 일반적으로 명확한 사설 주소 직접 연결을 먼저 작성하고, 그다음 프록시가 필요한 도메인이나 주소를 작성한 뒤 마지막에 기본 동작을 설정합니다. 규칙 순서는 중요합니다. 트래픽이 앞쪽 규칙과 일치하면 뒤의 규칙은 보통 적용되지 않습니다. 너무 넓은 도메인 규칙을 맨 위에 두면 뒤의 직접 연결 규칙이 적용될 기회를 잃을 수 있습니다. 분할 라우팅을 점검할 때는 실제 대상 도메인, 해석된 IP, 일치한 규칙, 최종 아웃바운드 태그를 확인하세요.

domainStrategy는 라우팅 단계에서 도메인과 해석 결과를 사용하는 방식을 결정합니다. AsIs는 원래 도메인을 우선 매칭하므로 도메인 규칙이 명확한 설정에 적합합니다. 다른 전략은 필요할 때 주소를 해석한 뒤 IP 규칙에 참여시킬 수 있습니다. 동작을 충분히 이해하지 못한 상태에서 라우팅 전략과 DNS를 동시에 바꾸지 마세요. 먼저 기본값으로 검증한 다음 ‘도메인 규칙이 매칭되지 않음’ 또는 ‘대상 IP 기준 분할 라우팅이 필요함’과 같은 구체적인 요구에 맞춰 조정하세요.

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

DNS 누수, 원격 해석 및 분할 DNS

DNS는 도메인을 주소로 변환하며, DNS와 실제 연결 트래픽은 서로 다른 경로를 사용할 수 있습니다. 도메인은 로컬에서 해석하고 연결은 프록시로 보낼 경우 현재 네트워크의 영향을 받을 수 있고, 모든 조회를 원격으로 보내면 로컬 도메인과 로컬 네트워크 서비스가 올바르게 해석되지 않을 수 있습니다. 도메인 유형에 따라 해석 경로를 정하고 라우팅과 DNS의 판단을 일치시키는 것이 합리적입니다. 자세한 실습은 DNS 누수 점검 및 설정 방법을 참고하세요.

DNS 문제가 발생하면 먼저 해석 실패인지 연결 실패인지 구분하세요. 로그에 도메인을 찾지 못했거나 DNS 조회 시간이 초과되었다고 명확히 표시될 때 DNS 계층을 점검합니다. 주소까지 해석됐지만 TCP 연결이 시간 초과되었다면 노드, 라우팅, 대상 네트워크를 확인해야 합니다. 브라우저가 자체 보안 DNS를 사용해 시스템 설정을 우회할 수도 있습니다. 비교 테스트에서는 클라이언트·시스템·브라우저의 세 가지 해석 설정이 동시에 바뀌지 않도록 브라우저가 일시적으로 시스템 DNS를 따르게 하세요.

누수 방지 설정은 서버 주소 하나를 입력하는 것만으로 끝나지 않습니다. 앱 조회, 시스템 조회, TUN 처리 사이에 의도하지 않은 우회 경로가 없는지 확인해야 합니다. 시스템 프록시와 TUN 모드에서 각각 확인하세요. 시스템 프록시는 보통 모든 시스템 DNS를 강제로 처리하지 않지만 TUN은 조회를 더 집중적으로 처리할 수 있습니다. 변경 후에는 기존 캐시를 삭제하거나 캐시가 만료될 때까지 기다려야 과거 결과를 새 설정의 효과로 오해하지 않습니다.

권장하는 단계적 설정 순서

첫 단계에서는 기본 라우팅과 시스템 프록시만 사용해 구독과 노드를 검증합니다. 두 번째 단계에서 사설 주소 직접 연결과 필요한 도메인 규칙을 추가하고 각 규칙의 매칭을 확인합니다. 세 번째 단계에서 DNS를 설정해 해석 경로와 분할 라우팅을 일치시킵니다. 네 번째 단계에서야 TUN을 켜고 더 많은 앱, 로컬 네트워크, 절전 모드 복귀를 테스트합니다. 각 단계가 끝날 때마다 되돌릴 수 있는 설정을 보존하세요. 한 번에 모든 기능을 켜는 것보다 느려 보이지만 실제로는 방향 없는 시행착오를 크게 줄일 수 있습니다.

시스템 프록시, TUN, 라우팅, DNS는 서로 연결되어 있지만 역할은 다른 네 계층입니다. 시스템 프록시는 앱이 요청을 클라이언트로 보낼지 결정하고, TUN은 시스템 패킷이 가상 인터페이스로 들어갈지 결정하며, 라우팅은 클라이언트 안에서 사용할 아웃바운드를 결정합니다. DNS는 도메인에서 주소를 얻는 방식을 결정합니다. 메뉴 위치를 외우기보다 역할에 따라 문제를 찾는 방식이 오래 유지되며, 플랫폼이나 인터페이스가 바뀌어도 적용할 수 있습니다.

08 / DIAGNOSIS

일반적인 설정 문제: 로그 단계별로 계층적으로 해결하기

먼저 문제가 발생한 계층을 판단하세요

전체 연결 경로는 여섯 계층으로 나눌 수 있습니다. 로컬 앱이 클라이언트로 들어가는지, 도메인이 해석되는지, 클라이언트가 노드 주소에 연결하는지, 전송 계층이 수립되는지, TLS 같은 보안 계층이 완료되는지, 대상 요청이 라우팅에 따라 아웃바운드로 나가는지입니다. 로그의 오류 위치는 ‘웹페이지가 열리지 않는다’는 설명보다 훨씬 많은 정보를 제공합니다. 문제를 해결할 때 발생 시각을 기록하고 요청을 한 번 다시 보낸 뒤 해당 시각 전후의 로그를 확인해 이전 오류와 백그라운드 재시도에 묻히지 않도록 하세요.

로그에 새로운 연결 기록이 전혀 없다면 앱이 시스템 프록시를 우회하거나, 앱별 규칙에서 제외되었거나, TUN이 해당 라우팅을 처리하지 못했을 가능성이 있습니다. DNS 시간 초과가 표시되면 DNS 서버와 조회 경로를 확인하세요. 노드 주소 연결이 시간 초과되면 현재 네트워크, 주소 접근성, 포트를 점검합니다. TLS 핸드셰이크가 실패하면 시스템 시간, 서버 이름, 보안 매개변수를 확인하세요. 연결은 수립됐지만 대상에서 오류가 반환된다면 라우팅과 대상 서비스를 계속 확인하고 즉시 클라이언트를 재설치하지 마세요.

구독은 업데이트되지만 모든 노드에 연결할 수 없음

이는 클라이언트가 적어도 구독 주소에는 접근할 수 있다는 뜻이지 노드 연결 경로가 정상이라는 뜻은 아닙니다. 먼저 기기 시간과 시간대가 자동으로 동기화되는지 확인하고, 노드 하나를 선택해 이전 로그를 지운 뒤 다시 연결하세요. 모든 노드에서 같은 DNS 오류가 발생하면 시스템과 클라이언트 DNS를 확인합니다. 모두 노드 주소 연결 단계에서 시간 초과가 발생하면 현재 네트워크와 라우팅을 점검하세요. 모두 설정 파싱 단계에서 실패하면 구독 형식이나 코어 호환성을 우선적으로 살펴봐야 합니다.

수십 개 노드를 연속으로 바꾸면서 화면 색상만 보지 마세요. 전환할 때마다 일정 시간 동안 전체 로그를 남기고 오류 단계가 같은지 비교하세요. 같은 단계에서 실패한다면 공통 조건일 가능성이 높고, 오류 단계가 다를 때만 개별 노드 차이를 의심할 수 있습니다. 시스템 프록시와 TUN 모드를 비교하는 방법도 있습니다. 시스템 프록시는 정상인데 TUN이 실패하면 권한·라우팅·DNS 처리 범위에 문제가 있을 가능성이 높고, 둘 다 실패하면 노드·구독·코어에 더 가까운 문제입니다.

연결됨으로 표시되지만 웹페이지가 열리지 않음

‘연결됨’은 보통 클라이언트 프로세스나 시스템 연결 상태가 수립되었다는 뜻일 뿐 모든 대상 요청이 성공했다는 의미는 아닙니다. 먼저 브라우저가 시스템 프록시를 읽는지, 모바일에서는 대상 앱이 앱별 규칙에 포함되어 있는지 확인하세요. 그다음 로그에 해당 도메인 요청이 있는지 확인합니다. 요청 자체가 없다면 트래픽 처리 계층을 점검하고, DNS 조회는 있지만 결과가 없으면 DNS를 확인하세요. 주소를 얻었지만 연결에 실패하면 라우팅과 노드를 점검합니다.

데스크톱에서는 시스템 프록시 주소가 현재 v2rayN의 로컬 포트와 일치하는지도 확인해야 합니다. 업그레이드, 설정 이전, 수동 조정 후 시스템이 이전 포트를 계속 가리킬 수 있습니다. 브라우저 자체의 프록시 확장이 시스템 설정을 덮어쓸 수도 있으므로 문제 해결 중에는 하나의 프록시 경로만 남겨 두세요. 특정 브라우저에서만 문제가 발생한다면 시스템 프록시를 따르는 다른 앱으로 테스트해 브라우저 문제인지 클라이언트 문제인지 빠르게 구분할 수 있습니다.

일부 웹사이트나 앱만 실패함

부분적인 실패는 대개 분할 라우팅, DNS, IPv4와 IPv6 선택, 앱의 독립 네트워크 스택과 관련됩니다. 먼저 실패한 대상이 예상한 라우팅 규칙과 일치하는지 확인한 뒤 DNS가 반환한 주소를 확인하세요. 도메인 규칙의 매칭 방식도 점검해야 합니다. 전체 도메인, 하위 도메인, 키워드 매칭은 범위가 서로 다릅니다. 규칙이 너무 넓으면 관련 없는 대상에 영향을 주고, 너무 좁으면 단일 호스트 이름만 매칭합니다. 수정한 뒤 관련 캐시를 지우고 다시 테스트하세요.

앱은 실패하지만 브라우저가 정상이라면 해당 앱이 시스템 프록시를 지원하는지, UDP를 사용하는지, 컨테이너나 가상 머신에서 실행되는지 확인하세요. 시스템 프록시는 주로 HTTP 계열 요청을 처리하고 TUN은 더 일반적인 트래픽을 인계할 수 있지만, 클라이언트 설정이 UDP를 어떻게 처리하는지도 확인해야 합니다. Android 앱별 프록시는 패키지 선택을 점검하고, Linux 컨테이너는 네트워크 네임스페이스를 확인하세요. Windows 백그라운드 서비스는 다른 계정 컨텍스트에서 실행될 수 있습니다. 이런 플랫폼 차이는 구독 계층이 아니라 트래픽 처리 계층의 문제입니다.

TUN을 켠 뒤 전체 네트워크가 끊김

첫 번째 단계는 TUN을 끄고 기본 네트워크와 시스템 프록시가 복구되는지 확인하는 것입니다. 두 번째로 가상 인터페이스가 정상적으로 생성되었는지, 기본 라우팅이 예상한 위치를 가리키는지 확인하세요. 세 번째로 DNS가 접근할 수 없는 주소로 바뀌었는지 점검합니다. 네 번째로 다른 가상 네트워크 프로그램과의 라우팅 충돌을 배제하세요. 전체 네트워크가 끊긴 상태에서 노드 프로토콜과 구독 필드를 계속 수정하지 마세요. 가상 인터페이스가 생성되지 않은 문제와 직접적인 관련이 없습니다.

TUN을 꺼도 인터넷이 계속 끊긴다면 잔여 시스템 프록시, 기본 라우팅, DNS를 확인하세요. Windows에서는 수동 프록시를, macOS에서는 네트워크 프록시 항목을, Linux에서는 환경 변수·데스크톱 프록시·ip route를 확인합니다. 기본 네트워크를 복구한 뒤 다시 활성화하세요. 네트워크 전환이나 절전 모드 복귀 후 자주 발생한다면 기기 전체를 재부팅하기보다 먼저 클라이언트 연결을 다시 구성해 보세요. 라우팅이 계속 복구되지 않을 때만 더 깊은 시스템 네트워크 처리를 고려하면 됩니다.

로그 읽는 법과 공유해도 되는 내용

유효한 로그에는 시각, 모듈, 오류 유형, 상황 정보가 포함됩니다. 일반적인 키워드는 파싱 오류, 연결 시간 초과, 연결 거부, 핸드셰이크 실패, 설정 필드 오류, 권한 오류로 나눌 수 있습니다. 문제를 해결할 때는 오류 전후 몇 줄을 복사하고 플랫폼, 클라이언트, 현재 시스템 프록시와 TUN 중 어떤 모드를 사용하는지, 문제가 재현되는지를 함께 설명하세요. ‘failed’ 한 줄만 캡처하지 마세요. 같은 단어라도 발생 단계에 따라 원인이 완전히 다를 수 있습니다.

로그를 공유하기 전에 구독 링크, 노드 주소, 사용자 식별자, 인증 필드, 로컬 개인 경로를 가리세요. 노드 이름에 계정 정보가 포함되어 있다면 그 부분도 처리해야 합니다. 프로토콜 유형, 전송 방식, 오류 모듈, 발생 순서는 보통 충분한 정보가 됩니다. 자주 묻는 질문은 FAQ 페이지에서 확인하고, 생태계와 클라이언트의 관계는 Project V, V2Fly와 Xray의 관계를 참고하세요.

반복해서 사용할 수 있는 복구 절차

설정을 너무 많이 바꿔 추적하기 어려워졌다면 매개변수를 계속 추가하지 마세요. 먼저 현재 설정을 내보내거나 기록한 뒤 TUN을 끄고 시스템 프록시를 해제하며 기본 라우팅과 DNS 정책을 복원하세요. 구독 그룹 하나만 남기고 업데이트한 다음 노드 하나를 선택해 시스템 프록시로 최소 테스트를 진행합니다. 성공하면 ‘라우팅, DNS, TUN, 앱별 설정’ 순서로 하나씩 복구하고, 항목을 추가할 때마다 로그와 대상 동작을 확인하세요.

최소 설정에서도 실패한다면 정상적으로 알려진 다른 네트워크에서 비교해 기기 설정 문제와 현재 네트워크 문제를 구분하세요. 같은 구독의 다른 노드로도 비교해 개별 노드 문제와 공통 설정 문제를 나눌 수 있습니다. Android에서는 v2rayNG와 v2flyNG 사이에서 코어 계열을 비교할 수도 있지만 네트워크와 노드는 동일하게 유지해야 합니다. 비교 실험에서는 한 번에 하나의 변수만 바꿔야 결과를 해석할 수 있습니다.

최종 목표는 로그의 모든 알림을 없애는 것이 아니라 요청이 예상대로 클라이언트에 들어오고, 올바르게 해석되며, 연결에 성공하고, 올바른 아웃바운드와 일치하는지 확인하는 것입니다. 일부 재시도와 중요하지 않은 알림은 실제 사용에 영향을 주지 않을 수 있습니다. 요청을 중단시키는 첫 번째 오류부터 해결한 다음 뒤따르는 파생 오류를 처리하세요. 이 순서를 익히면 인터페이스 이름이 바뀌어도 문제 해결 방법은 흔들리지 않습니다.