V2Ray 종합 가이드v2rayN 설정과 유지 관리

핵심 개념: 클라이언트, 코어와 연결 흐름

그래픽 인터페이스와 프록시 코어의 역할

V2Ray는 일반적으로 Project V와 관련된 프록시 기술 및 도구 생태계를 가리키며, 특정 데스크톱 프로그램 하나를 뜻하지는 않습니다. v2rayN은 서버 정보를 저장하고 구독을 관리하며 실행 설정을 만들고 코어를 구동하는 그래픽 클라이언트입니다. 코어는 로컬 포트를 열고 프로토콜을 처리하며 라우팅 규칙을 적용해 외부 서버와 연결합니다. 인터페이스가 정상적으로 열렸다고 코어까지 실행 중인 것은 아닙니다. 서버 목록이 있다고 해서 사용할 서버가 선택된 것도 아닙니다.

V2Fly는 V2Ray 관련 개발을 이어가고 있으며, Xray는 같은 생태계에서 발전한 또 다른 코어입니다. 두 코어는 지원 프로토콜과 설정 세부 사항이 다르므로 이름이 비슷하다고 모든 설정을 서로 바꿔 쓸 수는 없습니다. v2rayNG는 주로 Xray 코어를 사용하고, v2flyNG는 V2Fly 코어를 사용합니다. 노드를 가져오지 못한다면 주소를 반복해서 수정하기보다 먼저 클라이언트와 코어가 해당 프로토콜 및 전송 방식 조합을 지원하는지 확인하세요.

앱에서 서버까지 이어지는 실제 경로

일반적인 시스템 프록시 환경에서는 앱이 시스템 프록시 설정을 읽고 요청을 로컬 수신 포트로 보냅니다. 코어는 요청을 받아 라우팅 규칙을 적용한 뒤 목적지에 직접 연결할지 원격 서버를 거칠지 결정합니다. 원격 서버는 목적지 서비스에 접속한 다음 응답을 돌려줍니다. 이 과정에는 앱, 로컬 수신, 규칙 판정, 원격 연결 등 최소 네 단계가 관여합니다. 문제를 해결할 때 각 단계를 확인해야 앱이 프록시를 사용하지 않는 문제, 코어 미실행, 잘못된 규칙, 서버 연결 불가를 구분할 수 있습니다.

노드는 서버 주소, 포트, 사용자 식별자, 프로토콜, 전송 방식, 보안 설정 등 연결 매개변수의 묶음입니다. 구독은 이러한 매개변수를 한꺼번에 가져오는 주소로, 그룹 정보나 서비스 안내가 함께 포함될 수 있습니다. 구독 주소는 로컬 프록시 주소가 아니므로 브라우저의 프록시 포트 입력란에 넣으면 안 됩니다. 클라이언트는 연결 도구일 뿐이며, 실제 연결에는 사용 권한이 있고 유효한 서버 설정이 필요합니다.

프로토콜, 전송 방식과 보안 계층

VMess, VLESS, Trojan은 주로 프록시 프로토콜을 나타내고, WebSocket과 gRPC는 전송 방식을 나타냅니다. TLS와 REALITY 등은 연결 보안과 관련된 설정입니다. 하나의 노드에 여러 계층이 함께 포함될 수 있으며 어느 한 부분만 잘못 입력해도 연결에 실패할 수 있습니다. 서버 주소와 TLS에 사용하는 서버 이름이 서로 다를 수도 있고, 경로와 서비스 이름은 정확히 일치해야 하는 경우가 많습니다. 설정 제공자가 안내한 값을 그대로 가져오고 서로 다른 예시의 매개변수를 섞지 마세요.

DNS는 도메인 이름을 주소로 변환하는 과정으로, 운영체제, 앱, 클라이언트 또는 원격 측에서 처리할 수 있습니다. 이름을 어디서 해석하는지에 따라 연결 결과가 달라질 수 있으며, 특히 IP 주소 기반 규칙의 판정에 영향을 줍니다. 도메인이 해석된다는 것은 주소를 얻었다는 뜻일 뿐입니다. 포트 연결에 성공해도 전송 경로가 어느 단계까지 열렸는지만 확인할 수 있습니다. 브라우저에서 콘텐츠를 불러오려면 핸드셰이크 매개변수, 인증서, 대상 서비스와 앱 설정도 맞아야 하므로 단일 테스트만으로 전체 접속 여부를 판단할 수 없습니다.

설정하기 전에 연결 흐름을 간단히 적어 보세요. 어떤 앱이 요청을 보내는지, 어떤 진입 경로를 쓰는지, 어떤 규칙이 적용되는지, 어떤 서버를 선택하는지 확인하면 됩니다. 처음부터 코어의 모든 옵션을 살펴볼 필요는 없습니다. 각 장에서는 이 흐름에 필요한 기능을 하나씩 더합니다. 낯선 용어가 나오면 진입 경로, 규칙, 출구 중 어디에 해당하는지 먼저 파악한 뒤 설정 위치를 결정하세요. 여러 곳을 동시에 바꾸는 혼란을 줄일 수 있습니다.

클라이언트 선택: 플랫폼, 아키텍처와 인터페이스 버전

데스크톱에서는 v2rayN을 우선 고려

데스크톱에서는 v2rayN을 우선 고려한 뒤 운영체제, 프로세서 아키텍처와 배포 형식에 맞춰 설치 방법을 선택하세요. 크로스 플랫폼 데스크톱 인터페이스는 Windows, macOS, Linux에서 사용할 수 있고 WPF 인터페이스는 Windows용입니다. 두 인터페이스 모두 서버, 구독과 라우팅을 관리하지만 메뉴 위치, 창 구성, 실행에 필요한 구성 요소는 다를 수 있습니다. 오래된 스크린샷과 화면을 똑같이 맞추려고 설치 방식을 바꾸지 말고 기능 이름과 설정 목적을 확인하세요.

Windows 사용자가 데스크톱 버전과 클래식 WPF 버전 중 하나를 고른다면 기존 사용 방식부터 고려하세요. 여러 기기에서 비슷한 방식으로 사용하려면 데스크톱 버전을 먼저 검토할 수 있습니다. WPF 작업 폴더와 설정을 안정적으로 사용 중이라면 먼저 백업한 다음 이전을 검토하세요. 두 버전이 같은 쓰기 가능 설정 폴더를 공유하게 하거나 시스템 프록시를 동시에 제어하게 해서는 안 됩니다. 인터페이스 차이는 데스크톱 버전과 WPF 버전의 차이에서 확인하세요.

프로세서 아키텍처와 설치 형식

아키텍처는 프로그램이 어떤 종류의 프로세서를 대상으로 하는지 나타내며 네트워크 모드와는 다릅니다. macOS에서는 '이 Mac에 관하여'에서 칩 정보를 확인한 뒤 알맞은 설치 항목을 선택하세요. Linux에서는 아래 명령으로 시스템 아키텍처를 확인할 수 있습니다. 일반적으로 x86_64는 x64, aarch64는 arm64에 해당합니다. 배포판에 맞는 패키지 형식도 선택해야 합니다. 한 배포판용 패키지를 다른 형식으로 그대로 사용할 수는 없습니다. 설치에 실패하면 로그를 살펴보기 전에 기본 조건부터 확인하세요.

uname -m
cat /etc/os-release

Android에서는 보통 v2rayNG를 먼저 선택합니다. 최신 주요 기기는 arm64를 사용하는 경우가 많지만 기기가 실제로 지원하는 앱 아키텍처를 확인해야 합니다. 확인하기 어렵거나 아키텍처가 맞지 않는다는 메시지가 표시되면 범용 버전 항목을 살펴보세요. V2Fly 코어가 필요하거나 호환성을 확인하려는 경우에는 v2flyNG가 더 적합할 수 있습니다. 클라이언트 교체부터 시도하지 말고 구독이 유효한지, 프로토콜을 지원하는지, 기기 시간과 네트워크 상태가 정상인지 먼저 확인하세요.

이전 전 설정 범위 확인

클라이언트마다 설정 백업을 서로 바로 가져올 수 있는 것은 아닙니다. 전체 폴더를 복사하는 것보다 표준 노드 공유 링크를 사용하는 편이 이전하기 쉽지만, 양쪽 클라이언트가 프로토콜 필드를 지원해야 합니다. 구독 그룹, 라우팅 규칙, 단축키와 인터페이스 설정은 클라이언트 전용 설정일 수 있으므로 따로 기록하세요. 클라이언트를 바꾸기 전에 기존 클라이언트를 보관하고 프록시 제어를 해제한 다음 새 클라이언트에서 노드 하나를 테스트하세요. 기본 연결이 정상임을 확인한 뒤 복잡한 규칙을 옮기세요.

설치 항목은 클라이언트 다운로드 페이지에서 확인할 수 있습니다. 운영체제, 아키텍처, 인터페이스 형식 순으로 선택하고 개인 취향은 마지막에 고려하세요. 조직에서 관리하는 기기이거나 관리자 권한이 없거나 가상 네트워크 어댑터를 설치할 수 없다면 앱 프록시만 사용할 수 있는지도 미리 검토해야 합니다. 일반 프록시를 쓸 수 있다고 해서 TUN 권한까지 반드시 있는 것은 아닙니다. 권한 제한을 설치 환경의 조건으로 고려하면 설치 파일을 반복해서 바꾸는 것보다 적합한 방법을 찾기 쉽습니다.

설치 및 설정: 작업 폴더와 첫 실행

관리하기 쉬운 설치 위치 선택

먼저 다운로드 페이지에서 올바른 설치 항목을 선택하세요. 설치 프로그램은 안내에 따라 위치를 지정하고, 압축 파일은 전체 압축을 푼 다음 해당 폴더에서 프로그램을 실행하세요. 압축 프로그램의 미리보기에서 바로 실행하면 안 됩니다. 임시 압축 해제 폴더에 코어와 리소스가 없거나 쓰기 권한이 부족할 수 있습니다. 작업 폴더는 알아보기 쉽고 백업하기 편한 곳에 두며, 서로 다른 빌드의 파일을 한곳에 섞지 마세요. 포터블 방식으로 실행한다면 설정이 실제로 저장되는 위치도 확인하세요. 모든 데이터가 실행 파일 옆에 있다고 가정하면 안 됩니다.

Windows에서 v2rayN을 처음 실행할 때 실행 구성 요소가 없다는 메시지가 나오면 안내에 따라 맞는 아키텍처의 실행 환경을 설치한 뒤 클라이언트를 다시 시작하세요. 시스템 라이브러리 파일을 임의로 복사해 의존성 문제를 해결하려고 하지 마세요. 프로그램이 바로 종료되면 클라이언트 폴더의 로그나 시스템 이벤트 정보를 확인해 구성 요소 누락, 권한 부족, 보안 소프트웨어 차단을 구분하세요. 설치 순서는 Windows 설치 및 첫 실행 문제 해결에서 확인할 수 있습니다.

코어와 수신 상태 확인

인터페이스가 시작되면 로그 영역에 실행 실패, 파일 누락 또는 포트 바인딩 실패가 있는지 먼저 확인하세요. 노드가 있고 서비스를 활성화해야 코어가 실제로 수신 중인지 확인할 수 있습니다. 일반적인 로컬 진입점은 루프백 주소와 수신 포트를 사용하며, 포트 값은 현재 설정을 기준으로 확인해야 합니다. 이전 안내서의 포트 번호는 이해를 돕는 예시일 뿐이므로 현재 설정을 그대로 덮어쓰지 마세요. 빌드에 따라 각각 별도의 두 포트 대신 통합 진입점을 사용할 수도 있습니다.

설정 → 매개변수 설정 → Core 기본 설정 근처에서 로컬 수신 관련 옵션을 확인하세요. SOCKS와 HTTP 진입점은 지원하는 앱 유형이 다르므로 앱에 프록시를 입력할 때 프로토콜, 주소와 포트를 맞춰야 합니다. 처음에는 루프백 주소에서만 수신하도록 설정하세요. 다른 기기에 서비스를 제공해야 할 때만 LAN 수신을 고려합니다. LAN에 공개하면 접근 범위가 넓어지므로 접근 제한, 방화벽과 기기 신뢰 범위도 함께 관리해야 합니다.

netstat -ano | findstr :10808

위에는 Windows에서 예시 포트의 사용 여부를 확인하는 명령이 있습니다. 실제 점검 시 포트 번호를 매개변수 설정의 값으로 바꾸세요. 출력 마지막 열에서 프로세스를 확인한 뒤 소유자를 파악하고 종료하거나 포트를 변경할지 결정하면 됩니다. 사용 중이라는 이유만으로 정체를 모르는 시스템 프로세스를 종료하지 마세요. 다른 프록시 프로그램이 사용 중이면 중복 실행을 먼저 종료하세요. 정상적인 앱이 포트를 사용 중이라면 수신 포트를 변경한 뒤 프록시를 수동 입력한 앱의 설정도 함께 바꾸세요. 자세한 방법은 로컬 포트 충돌 해결을 참고하세요.

기타 데스크톱 및 모바일 기기

macOS에서는 설치 후 시스템 안내에 따라 앱 실행을 허용하세요. 전역 시스템 보호를 끄는 대신 설치 출처와 앱 정보를 확인하고 해당 앱만 허용해야 합니다. Linux에서는 배포판에 맞는 패키지 관리 도구로 설치하고, 의존성 안내가 나오면 누락된 구성 요소를 확인하세요. 데스크톱 환경, 그래픽 디스플레이 백엔드와 시스템 트레이 지원에 따라 인터페이스 동작이 달라질 수 있습니다. 창을 닫아도 프로세스가 종료되지 않을 수 있으니 트레이와 프로세스 목록을 함께 확인하세요.

Android에 클라이언트를 설치한 뒤 처음 연결할 때 시스템 VPN 권한 요청이 표시될 수 있습니다. 트래픽 진입점을 만들기 위해 필요한 시스템 권한입니다. 먼저 유효한 설정을 가져온 다음 요청이 현재 앱에서 나온 것인지 확인하세요. 처음 연결을 검증할 때는 네트워크를 제어하는 다른 도구를 꺼서 두 진입점이 서로 덮어쓰지 않게 하세요. 이 단계의 완료 기준은 '앱이 열림'이 아닙니다. 설정 위치를 찾고 시작 로그를 읽으며 서비스 실행 여부를 확인할 수 있어야 다음 장에서 구독을 가져올 준비가 된 것입니다.

구독 관리: 가져오기, 업데이트와 그룹

그룹을 만든 뒤 서버 업데이트

구독 주소에는 개인별 접근 정보가 포함되는 경우가 많으므로 인증 정보처럼 관리해야 합니다. 허가된 설정 제공자에게서만 주소를 받고 전체 링크를 공개 댓글, 스크린샷 또는 온라인 변환 서비스에 올리지 마세요. 브라우저에서 주소가 열리더라도 현재 클라이언트에 맞는 내용이라는 뜻은 아닙니다. 계정 페이지, 오류 메시지 또는 다른 형식이 반환될 수 있습니다. 가져오기 전에 주소가 완전한지, 설명 문구나 줄바꿈, 메신저가 덧붙인 문장부호가 섞이지 않았는지 확인하세요.

v2rayN에서 먼저 구독 그룹 → 구독 그룹 설정으로 이동해 그룹을 추가하고 알아보기 쉬운 메모를 입력한 다음 구독 주소를 붙여넣으세요. 저장한 뒤 해당 그룹을 업데이트하거나 전체 구독 업데이트를 실행합니다. 빌드에 따라 그룹 메뉴가 메뉴바나 목록 도구 영역에 있을 수 있습니다. 중요한 것은 주소를 저장한 다음 업데이트하는 순서입니다. 주소만 붙여넣고 업데이트하지 않으면 서버 목록에 바로 나타나지 않는 경우가 많습니다. 메모만 추가해도 노드가 생기지는 않습니다.

업데이트가 끝나면 로그와 목록의 그룹을 확인하세요. 성공으로 표시됐는데 목록이 비어 있다면 콘텐츠 형식이 지원되지 않거나 오류 페이지가 반환됐을 수 있고, 현재 필터가 서버를 모두 숨기고 있을 수도 있습니다. 기존 설정을 바로 삭제하지 말고 먼저 검색과 필터를 해제한 다음 해당 그룹으로 전환해 확인하세요. 같은 주소가 다른 기기에서는 정상이라면 양쪽 클라이언트의 지원 기능과 업데이트 시각을 비교하면 호환성 차이와 네트워크 가져오기 실패를 구분하는 데 도움이 됩니다.

노드 업데이트와 수동 수정의 관계

구독 제공자는 서버 주소, 메모와 매개변수를 변경할 수 있으며 다음 업데이트에서 클라이언트 규칙에 따라 항목 일부가 다시 만들어지거나 바뀔 수 있습니다. 구독 노드를 직접 수정해도 변경 내용이 계속 유지되는 것은 아닙니다. 시험이 필요하면 먼저 수동 노드로 복사하고 용도를 적은 다음 한 번에 하나의 매개변수만 수정하세요. 일괄 업데이트 후에는 예전 메모만 보고 같은 설정이라고 판단하지 마세요. 테스트가 끝나면 임시 복사본을 삭제해 만료된 설정을 나중에 잘못 선택하지 않도록 하세요.

구독이 여러 개라면 출처나 용도에 따라 그룹을 나누세요. 전부 한 그룹에 넣고 메모만으로 구분하려 하지 마세요. 키워드 필터는 목록을 좁혀 보여줄 뿐 노드를 삭제하거나 라우팅을 바꾸지 않습니다. 필터 적용 후 활성 서버를 설정할 때는 원하는 그룹에 속한 노드인지 확인하세요. 업데이트 뒤 활성 항목이 바뀌었다면 다시 점검해야 합니다. 자세한 정리 방법은 구독 그룹 및 서버 필터링을 참고하세요.

업데이트 실패 원인별 확인

업데이트에 실패했다면 먼저 주소를 가져오는 단계에서 오류가 발생했는지 확인하세요. 연결 시간 초과는 주소를 가져오는 경로에 문제가 있다는 뜻이고, 응답을 분석할 수 없다면 반환된 내용이 실제 구독 데이터인지 확인해야 합니다. 클라이언트에서 직접 업데이트와 프록시를 통한 업데이트를 선택할 수 있다면 현재 연결 흐름에 맞는 방식을 고르세요. 유효한 프록시 연결이 없는데 프록시를 통해 업데이트하도록 설정하면 '연결하려면 업데이트가 필요하고, 업데이트하려면 연결이 필요한' 상황에 빠질 수 있습니다. 아직 유효한 설정이 남아 있다면 이를 이용해 가져오기 경로를 확인하세요.

업데이트 버튼을 반복해서 누르는 것은 해결 방법이 아닙니다. 먼저 구독 계정과 주소 상태를 확인한 다음 네트워크, 시스템 시간과 오류 로그를 점검하세요. 서버가 일시적으로 응답하지 않으면 현재 유효한 항목을 삭제하고 다시 만드는 것보다 보존하는 편이 안전합니다. 로그를 공유하기 전에 전체 주소, 사용자 식별자와 서버 정보를 가리세요. 항목별 점검은 구독 업데이트 실패 및 빈 목록 문제 해결 체크리스트를 참고하세요. 조치 후 한 번만 다시 시도하고 오류가 달라졌는지 기록하세요.

이 단계의 완료 기준은 그룹 하나 이상을 업데이트할 수 있고, 그 안에서 설정 하나를 찾아 활성 서버로 지정하는 방법을 아는 것입니다. 구독 업데이트 성공과 노드 연결 성공은 서로 다른 결과입니다. 전자는 설정을 가져왔다는 뜻이고, 후자는 서버, 프로토콜과 진입점 설정에도 좌우됩니다. 두 결과를 구분해야 다음 단계에서 시스템 프록시를 확인할 때 가져오기 문제와 실제 접속 문제를 혼동하지 않습니다.

프록시 모드: 시스템 진입점과 연결 확인

시스템 프록시가 모든 기기의 트래픽을 처리하지는 않습니다

활성 서버를 선택하고 코어가 실행 중인지 확인한 다음 시스템 프록시를 설정하세요. v2rayN의 기본 화면이나 트레이에서 시스템 프록시 관련 메뉴를 열고 시스템 프록시 자동 설정을 선택할 수 있습니다. 메뉴 이름은 현재 인터페이스에 따라 다를 수 있습니다. 이 설정은 로컬 프록시 주소를 시스템 설정에 등록하며 해당 설정을 따르는 앱만 사용합니다. 자체 네트워크 스택을 사용하거나 앱 설정에서 프록시 방식을 고정한 프로그램은 시스템 프록시를 켜도 직접 연결할 수 있습니다.

시스템 프록시를 해제해도 시스템 진입점만 복원될 뿐 코어의 수신이 중단되지는 않을 수 있습니다. 이때 로컬 포트를 수동으로 지정한 앱은 여전히 클라이언트를 거칠 수 있습니다. 반대로 클라이언트를 바로 종료해도 모든 환경에서 이전에 설정한 프록시가 자동으로 지워지는 것은 아닙니다. 상태를 판단할 때는 트레이 아이콘만 보지 말고 시스템 프록시, 코어 실행 여부와 앱 설정을 각각 확인하세요. 종료하기 전 시스템 프록시를 해제한 뒤 정상적으로 종료하면 앱이 사용할 수 없게 된 로컬 포트에 계속 연결하는 일을 줄일 수 있습니다.

앱의 수동 프록시와 포트 연결

앱에서 프록시를 직접 설정할 수 있다면 호스트에는 보통 127.0.0.1을 입력하고, 포트에는 클라이언트의 현재 수신 포트를 입력한 다음 HTTP 또는 SOCKS 유형을 선택하세요. 여기서 루프백 주소는 원격 노드 서버가 아니라 이 기기 자체를 가리킵니다. 일반 앱의 프록시 입력란에 원격 노드 포트를 바로 넣어도 보통 연결되지 않습니다. 앱이 노드 프로토콜과 인증을 대신 처리하지 않기 때문입니다. 다른 기기와 공유할 때는 루프백 주소를 그대로 사용할 수도 없습니다.

처음 연결을 확인할 때는 같은 결과를 재현할 수 있는 대상을 하나 정하세요. 먼저 프록시를 끈 상태에서 결과를 기록한 다음 시스템 프록시를 켜고 다시 시도합니다. 앱에 연결 풀이나 이전 페이지 캐시가 남아 있을 수 있으므로 필요하면 완전히 종료한 뒤 다시 시작하세요. 클라이언트에 해당 연결 기록이 나타나는지와 출구 방향도 확인해야 합니다. 요청이 클라이언트에 도착하지 않았다면 원격 서버를 바꾸기보다 앱 진입점을 점검하세요. 요청이 도착했지만 실패했다면 라우팅과 출구 연결을 차례로 확인하세요.

테스트 결과와 실제 사용 경험 구분하기

목록의 지연 시간 테스트, 연결 테스트와 실제 웹페이지 접속은 대상, 프로토콜과 측정 방법이 서로 다를 수 있습니다. 한 번 측정한 수치로 모든 사이트의 속도를 판단하거나 동영상, 다운로드, 실시간 앱이 반드시 정상이라고 단정할 수는 없습니다. 테스트에 실패했다면 구체적인 원인을 확인해야 합니다. 테스트 서버에 접속할 수 없는 문제와 노드 연결 실패는 다릅니다. 같은 기기, 대상과 모드에서 비교해야 결과를 참고할 수 있습니다.

브라우저는 정상인데 다른 앱만 실패한다면 해당 앱이 시스템 프록시를 지원하는지, 별도 프록시가 설정되어 있는지, 이전 환경 변수가 남아 있는지 확인하세요. 개발 도구, 터미널과 데스크톱 프로그램의 설정은 서로 다를 수 있습니다. 모든 앱에 한꺼번에 프록시를 설정하면 어떤 진입점이 작동했는지 알아내기 어렵습니다. 먼저 한 앱에서 프록시를 명시적으로 설정해 작동을 확인하고, 이후 다른 앱의 기존 설정을 하나씩 복원해 설정이 겹치는 지점을 찾아보세요.

시스템 프록시를 켠 뒤 해당 설정을 따르는 모든 앱이 접속하지 못한다면 먼저 로컬 포트가 계속 수신 중인지, 활성 서버가 삭제되지 않았는지, 코어 로그에 오류가 있는지 확인하세요. 시스템 프록시를 잠시 해제해 일반 네트워크가 복구되는지 확인하면 로컬 진입점 문제와 기본 네트워크 문제를 구분하는 데 도움이 됩니다. 간단한 질문은 자주 묻는 질문에서 확인하세요. 이 장을 마치면 특정 요청이 클라이언트에 들어왔는지 설명할 수 있어야 합니다.

라우팅: 규칙 적용 순서와 DNS 조건

먼저 프리셋을 사용하고 예외는 필요한 만큼 추가

라우팅은 코어에 들어온 요청을 분류한 뒤 직접 연결, 프록시, 차단 등의 처리 방식을 결정합니다. v2rayN의 라우팅 설정에서 중국 본토 우회(Whitelist) 같은 프리셋을 선택할 수 있습니다. 이러한 모드는 보통 도메인과 주소 규칙에 따라 직접 연결과 프록시를 나누지만, 실제 적용 범위는 규칙 내용과 데이터 파일에 따라 달라집니다. 프리셋 이름만으로 특정 도메인에 어떤 규칙이 적용될지 단정할 수는 없습니다.

처음에는 용도에 맞는 프리셋 하나를 유지하면서 자주 쓰는 앱부터 확인하고 명확한 예외만 조금씩 추가하세요. 비교를 위해 전체 프록시로 바꿨을 때 대상에 접속할 수 있었다면 기존 규칙이 다른 출구를 선택했을 가능성이 있습니다. 그래도 로그로 확인해야 합니다. 이 결과만으로 '항상 전체 프록시가 더 적합하다'고 판단해서는 안 됩니다. 로컬 서비스, LAN 주소와 일부 계정 서비스는 계속 직접 연결해야 할 수 있습니다.

규칙 순서, 범위와 기본 처리

일반적인 규칙은 순서대로 확인하며 먼저 일치한 유효 규칙이 처리 결과를 결정합니다. 정확한 동작은 코어와 클라이언트가 생성한 설정을 기준으로 확인하세요. 특정 도메인 예외는 범위가 더 넓은 분류 규칙보다 앞에 두어야 적용될 수 있습니다. 규칙을 추가할 때는 일치 조건, 출구, 삽입 위치와 예상 결과를 기록하세요. 도메인만 저장하고 출구를 올바르게 선택하지 않거나, 이미 범위에 포함된 규칙 뒤에 예외를 추가하면 규칙이 적용되지 않는다고 오해하기 쉽습니다.

정확한 도메인과 도메인 접미사는 적용 범위가 다릅니다. 특정 호스트 하나만 처리하려면 도메인 전체를 포괄하는 표현을 잘못 사용하지 않도록 주의하세요. 웹사이트는 로그인, 이미지와 API 등 여러 도메인에 의존할 수 있으므로 메인 페이지가 열린다고 필요한 요청이 모두 정상인 것은 아닙니다. 실패한 요청을 기준으로 꼭 필요한 조건만 추가하고 관련 없는 도메인을 대량으로 예외에 넣지 마세요. 입력란에서 어떤 문법을 사용하는지 모르겠다면 해당 항목의 설명을 먼저 확인하세요. 코어의 원시 필드를 아무 인터페이스에나 붙여넣으면 안 됩니다.

{
  "type": "field",
  "domain": ["full:example.com", "domain:example.org"],
  "outboundTag": "direct"
}

위는 Xray 라우팅 규칙 객체의 예시이며 완전한 실행 설정은 아닙니다. 정확한 도메인, 도메인 접미사와 출구 태그의 관계를 보여 줍니다. 전체 설정의 규칙 배열에 추가하고 direct라는 이름의 출구가 있어야 해당 기능이 작동합니다. 예시 도메인은 형식을 설명하기 위한 것입니다. 그래픽 클라이언트에서 설정을 관리한다면 라우팅 편집 기능을 우선 사용하세요. 자동 생성 파일을 직접 수정하면 다음 실행이나 노드 전환 시 변경 사항이 덮어써질 수 있습니다.

DNS와 주소 규칙의 관계

도메인 기반 규칙을 사용하려면 코어에서 도메인 정보를 확인할 수 있어야 하고, 주소 기반 규칙은 실제로 얻은 주소를 사용합니다. 앱이 먼저 이름을 해석한 뒤 주소만 전달하면 도메인 규칙을 적용하는 데 필요한 정보가 부족할 수 있습니다. 코어가 설정에 따라 별도로 이름을 해석할 수도 있습니다. 일부 프로토콜에서는 스니핑으로 도메인 정보를 보완할 수 있지만 모든 트래픽에서 복원되는 것은 아니며 호환성도 고려해야 합니다. 스니핑을 켜면 모든 라우팅 문제가 해결된다고 생각해서는 안 됩니다.

라우팅 문제를 확인할 때는 대상과 활성 서버를 하나씩 고정하고 기존 모드를 기록한 다음 적용 범위가 가장 좁은 예외 규칙을 임시로 추가하세요. 연결 로그에서 대상과 출구 방향을 비교하고 필요하면 앱 캐시를 지운 뒤 새 연결을 만드세요. 이미 연결된 장기 연결은 규칙을 저장해도 바로 다시 연결되지 않을 수 있습니다. 테스트가 끝나면 효과가 없는 예외를 삭제하세요. 규칙이 계속 쌓이지 않도록 각 규칙의 필요성을 설명할 수 있는 상태로 유지해야 합니다.

TUN 모드: 적용 범위와 복구 순서

일반 프록시가 작동한 뒤 TUN 사용

TUN은 가상 네트워크 인터페이스와 관련 라우팅 설정을 이용해 조건에 맞는 트래픽을 클라이언트로 전달합니다. 일반 시스템 프록시를 사용할 수 없는 앱에 적합하지만 모든 프로토콜, 네트워크 어댑터와 네트워크 환경에서 반드시 작동하는 것은 아닙니다. 먼저 일반 프록시 연결을 확인한 뒤 TUN을 시도해야 실패 원인이 트래픽을 넘겨받는 단계에 있는지 구분할 수 있습니다. 노드 자체가 연결되지 않는 상태에서 TUN을 켜면 확인할 단계만 늘어날 뿐 잘못된 출구 매개변수가 해결되지는 않습니다.

v2rayN에서 TUN 모드 스위치와 관련 설정을 찾아 현재 빌드에 필요한 권한과 구성 요소를 확인하세요. 인터페이스를 만들거나 시스템 라우팅을 변경하기 위해 권한을 높여야 할 수 있습니다. 출처가 명확한 클라이언트에만 필요한 권한을 부여하세요. 조직에서 관리하는 기기, 제한된 계정이나 특수한 데스크톱 환경에서는 이런 작업이 금지될 수 있습니다. 기기 관리 정책을 따르고 전역 보안 설정을 바꿔 제한을 억지로 우회하지 마세요.

진입점 중복과 라우팅 충돌

처음 TUN을 켤 때는 다른 조건을 그대로 두고 TUN만 추가하세요. 시스템 프록시를 유지해야 하는지는 현재 클라이언트의 구현과 안내에 따라 판단해야 합니다. 두 진입점을 함께 사용하면 요청 경로가 달라질 수 있으므로 결과를 확인하는 동안 임의로 켜고 끄지 마세요. 다른 VPN, 가상 네트워크 어댑터 도구나 라우팅을 제어하는 프로그램도 잠시 종료하세요. 여러 도구가 기본 경로를 동시에 수정하면 트래픽이 어디로 가는지와 복구 순서를 파악하기 어려워집니다.

LAN 접속은 TUN을 켠 직후 확인해야 합니다. 라우터 관리 페이지, 프린터, 파일 공유와 로컬 개발 서비스가 포함됩니다. 이 대상에 접속할 수 없다면 사설 주소, 루프백 주소와 로컬 서브넷 우회 설정을 확인하고 로컬 주소 전체를 원격 서버로 보내지 마세요. 여러 네트워크 어댑터, 핫스폿 공유와 가상 머신 네트워크도 서로 다른 서브넷을 사용할 수 있으므로 따로 확인해야 합니다. 적절한 트래픽 범위는 실제 네트워크 구성에 따라 정하고 다른 사람의 제외 목록을 그대로 복사하지 마세요.

DNS, UDP와 앱 동작

TUN 환경에서는 DNS 요청이 서로 다른 경로로 전달될 수 있습니다. 앱 자체의 암호화된 DNS 사용, 시스템 캐시 또는 예상과 다른 경로로 전송된 질의 때문에 일반 프록시와 결과가 달라질 수 있습니다. 먼저 도메인 이름이 해석되는지와 DNS 요청이 어디로 가는지 확인한 다음 연결이 의도한 출구로 전달되는지 점검하세요. DNS 서버, 라우팅 모드와 TUN 네트워크 스택을 한꺼번에 바꾸지 마세요. 한 번에 조건 하나만 변경해야 정상 상태로 되돌릴 수 있습니다.

일부 실시간 앱과 프로토콜은 UDP를 사용합니다. 정상 작동 여부는 로컬에서 트래픽을 넘겨받는 방식, 코어 기능, 노드 설정과 원격 서비스에도 좌우됩니다. 브라우저에서 페이지가 열린다고 UDP 연결도 정상이라고 볼 수는 없습니다. 문제가 발생한 앱에서 직접 테스트하고 연결 기록과 오류를 확인하세요. 특정 유형의 앱만 이상하다면 전체 TUN 기능이 고장 났다고 단정하지 말고 해당 앱의 전송 방식과 DNS 사용을 비교하세요.

스위치를 껐는데도 문제가 계속되면 클라이언트를 정상 종료하고 시스템에 가상 인터페이스, 이전 프록시 설정 또는 다른 도구의 연결이 남아 있는지 확인하세요. 먼저 클라이언트의 복구 기능을 사용하고, 필요하면 시스템을 다시 시작하세요. 정체를 알 수 없는 네트워크 어댑터나 라우팅을 임의로 삭제하지 마세요. 기본 네트워크가 복구되면 일반 프록시를 확인한 다음 TUN만 단독으로 다시 켜세요. 처음 문제가 발생한 시점이 인터페이스 생성, DNS 조회, 대상 연결 중 어디였는지 기록하면 다음 점검 범위를 크게 줄일 수 있습니다.

이 장의 완료 기준은 세 가지입니다. 트래픽을 넘겨받아야 하는 앱이 작동하고, 로컬 네트워크 서비스에 계속 접속할 수 있으며, 모드를 끈 뒤 네트워크가 복구되어야 합니다. 앞의 두 조건이 정상이어도 종료 후 복구할 수 없다면 일상적인 기본 설정으로 사용하기에 적합하지 않습니다. TUN은 명확한 용도가 있을 때 선택하는 진입 방식으로 활용하고 모든 기기에서 반드시 켜야 하는 스위치로 여기지 않아야 이해하기 쉽고 되돌릴 수 있는 네트워크 환경을 유지할 수 있습니다.

일상적인 유지 관리: 백업, 업데이트와 문제 기록

설정 백업과 업데이트를 분리

안정적으로 작동하면 먼저 클라이언트 설정이 저장되는 위치를 확인하고 백업 계획을 세우세요. 백업에는 보존할 구독 그룹, 수동 노드, 라우팅과 개인 설정이 포함되어야 합니다. 폴더를 그대로 복사해도 되는지는 설치 방식에 따라 다릅니다. 복사 전에 클라이언트를 종료해 데이터베이스나 설정 파일을 쓰는 중이 아닌지 확인하세요. 구독 주소와 사용자 식별자는 민감한 정보이므로 백업 파일 접근을 제한하고 모든 공유 기기나 공개 저장 공간에 자동으로 동기화하지 마세요.

클라이언트, 코어, 구독과 규칙 데이터 업데이트는 각각 다른 작업입니다. 클라이언트 업데이트는 인터페이스와 설정 형식을 바꿀 수 있고, 코어 업데이트는 프로토콜 동작에 영향을 줄 수 있습니다. 구독 업데이트는 서버 매개변수를 바꾸며 규칙 데이터 업데이트는 분류 결과에 영향을 줍니다. 문제가 생겼을 때는 가장 최근에 어떤 항목을 업데이트했는지 알아야 합니다. 한 번의 유지 관리 과정에서 클라이언트, 코어, 노드와 규칙을 모두 바꾸면 결과가 달라진 원인을 찾기 어렵습니다.

업데이트 전후 비교 절차

업데이트 전에 현재 설치 방식, 활성 서버, 프록시 진입점과 라우팅 모드를 기록하고 복구할 수 있는 설정을 백업하세요. 클라이언트를 정상 종료한 뒤 업데이트해 백그라운드 코어가 파일을 사용하지 않게 합니다. 업데이트 후에는 기존의 단순한 설정으로 먼저 확인하고 복잡한 새 규칙은 바로 가져오지 마세요. 설정 이전 안내가 나오면 내용을 먼저 읽으세요. 새 설정 구조를 이전 빌드에서 읽지 못할 수 있으므로 프로그램을 되돌릴 때는 이전 설정 백업도 함께 복원해야 합니다.

자동 시작과 자동 연결은 기본 연결이 안정된 뒤 설정하세요. 부팅 시 네트워크가 아직 준비되지 않아 구독 업데이트나 연결이 실패할 수 있으며, 이것만으로 노드가 유효하지 않다고 단정할 수는 없습니다. 네트워크 연결이 준비된 뒤 수동으로 다시 시도한 결과를 확인하고 시작 순서를 조정하세요. Android 기기에서 백그라운드 연결이 자주 끊기면 클라이언트의 배터리 최적화와 백그라운드 실행 제한을 살펴보세요. 필요한 범위만 조정하고 특정 앱 하나 때문에 기기 관리 기능 전체를 끄지 마세요.

단계별로 로그 읽기

로그에서는 마지막 줄만 보지 말고 관련 오류가 처음 나타난 시점을 찾으세요. 시작 단계에서 포트 바인딩에 실패하면 이후 앱 요청이 모두 실패할 수 있지만, 구독 가져오기 오류가 이미 있는 노드에 영향을 주지는 않을 수 있습니다. 연결 시간 초과, 이름 해석 실패, 인증 또는 핸드셰이크 실패는 각각 네트워크, DNS와 매개변수 관점에서 확인해야 합니다. 같은 오류 문구도 대상에 따라 의미가 달라질 수 있으므로 발생 시각, 대상 주소와 작업 순서를 함께 살펴보세요.

작업: 지정한 구독 그룹 업데이트
진입점: 일반 시스템 프록시, TUN은 꺼짐
증상: 업데이트 실패, 기존 노드는 계속 연결 가능
비교: 시스템 프록시 해제 후 다시 업데이트
기록: 관련 시간대의 오류는 보존하고 민감한 주소는 삭제

위 기록 형식에는 실제 인증 정보가 들어 있지 않아 문제 해결 과정을 정리하는 데 적합합니다. 공유할 때는 전체 구독 주소, 서버 도메인이나 주소, 사용자 식별자와 개인 폴더 이름을 가리세요. 로그에 요청 대상이 포함되면 필요한 범위에 따라 함께 비식별 처리하세요. 앞뒤 맥락을 잘라낸 오류 스크린샷만 보내지 마세요. 클라이언트 종류, 운영체제, 작업 순서와 마지막으로 정상 작동했던 상태를 설명하는 편이 스크린샷을 반복해서 보내는 것보다 문제를 재현하고 해결하는 데 도움이 됩니다.

종료와 복구를 위한 정기 점검

평소 종료할 때는 더 이상 필요하지 않은 TUN을 먼저 끄고 시스템 프록시를 해제한 다음 클라이언트를 정상 종료하세요. 앱에 로컬 프록시를 직접 입력했다면 앱 설정도 복원해야 합니다. 시스템 프록시를 해제해도 앱은 로컬 포트에 계속 연결할 수 있습니다. 네트워크를 바꾼 뒤 문제가 생기면 먼저 기본 네트워크와 인증 페이지가 정상인지 확인하세요. 공용 네트워크의 로그인 절차가 끝나지 않았다면 프록시 소프트웨어로 네트워크 접속 절차를 대신할 수 없습니다.

유지 관리의 목표는 정상 작동이 확인된 기준 구성을 보존하는 것입니다. 사용 가능한 서버 하나, 명확한 진입 방식 하나, 설명할 수 있는 라우팅 규칙과 복구 가능한 백업을 준비하세요. 문제가 생기면 이 기준으로 돌아간 뒤 추가 기능을 하나씩 복원합니다. 임시 노드, 만료된 예외와 중복 그룹을 주기적으로 정리하면 잘못된 선택과 규칙 충돌을 줄일 수 있습니다. 문제가 특정 유형으로 분류된다면 자주 묻는 질문에서 증상에 맞춰 확인하세요. 매번 처음부터 다시 설치할 필요가 없습니다.

고급 활용: 설정 이해와 단일 변수 테스트

해결할 문제부터 구체적으로 정하기

고급 설정은 모든 기능을 켜는 것이 아니라 요청이 설정을 거쳐 처리되는 과정을 설명할 수 있는 상태를 뜻합니다. 개발 도구 하나에 별도 프록시가 필요하거나, 특정 도메인은 직접 연결해야 하거나, 특정 앱의 트래픽을 TUN으로 처리해야 하는 등 요구 사항을 먼저 적으세요. 목표가 분명해진 다음 필요한 범위만 설정하면 됩니다. 일반 시스템 프록시로 충분하다면 메뉴에 있다는 이유만으로 가상 네트워크 어댑터, 사용자 지정 DNS와 복잡한 다중 출구 규칙을 켤 필요는 없습니다.

현재 설정을 읽고, 생성되는 설정을 이해하고, 규칙 하나를 검증한 뒤 사용자 지정 설정을 살펴보는 순서로 학습하세요. 클라이언트는 노드, 라우팅과 전역 매개변수를 바탕으로 코어 설정을 생성하는 경우가 많으므로 원시 설정 파일만이 모든 설정의 기준은 아닙니다. 그래픽 옵션이 어떤 필드에 대응하는지 찾아 저장 전후를 비교한 다음 적용 범위를 확인하세요. 실행 파일 전체를 직접 교체하면 인터페이스 상태와 실제 설정이 달라질 수 있고 이후 유지 관리도 어려워집니다.

인바운드, 아웃바운드와 태그 참조 이해

원시 설정에서 인바운드는 트래픽을 받고, 아웃바운드는 다음 연결을 만들며, 라우팅은 조건에 맞는 요청을 아웃바운드로 보냅니다. 태그는 각 부분에서 객체를 참조할 때 쓰이며 태그 이름 자체에 특별한 기능이 있는 것은 아닙니다. 존재하지 않는 아웃바운드 태그를 참조하거나 혼동하기 쉬운 태그를 중복 사용하면 설정이 의도대로 작동하지 않을 수 있습니다. 예시를 읽을 때는 정의와 참조를 함께 확인하고 관련 있어 보이는 일부 규칙만 복사하지 마세요.

아래는 독립적으로 읽을 수 있는 Xray 최소 설정 예시입니다. 로컬에 SOCKS 진입점을 만들고 받은 요청을 목적지에 직접 연결합니다. 원격 프록시 노드는 포함되어 있지 않으며 구독을 대신할 수도 없습니다. 포트가 비어 있어야 하고 실행 중인 클라이언트의 진입 포트와 겹치지 않아야 합니다. 필드 간 관계를 살펴보는 예시이므로 일상적인 설정은 그래픽 클라이언트에서 관리하는 편이 좋습니다. 테스트가 끝나면 테스트 프로세스를 종료해 백그라운드에 중복 수신이 남지 않도록 하세요.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10818,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

단일 변수 테스트 방법

테스트할 때는 앱, 대상과 네트워크 조건을 고정하고 매번 옵션 하나만 바꾼 뒤 원래 값을 기록하세요. 도메인 규칙을 확인한다면 서버와 DNS를 동시에 바꾸지 마세요. TUN이 로컬 서비스에 영향을 주는지 확인한다면 라우팅은 그대로 두고 진입 방식만 바꾸세요. 결과가 예상과 다르면 원래 값으로 복원한 다음 다음 비교를 설계하세요. 번거로워 보여도 여러 변경 사항이 서로 영향을 줘 어떤 설정이 실제로 효과가 있었는지 알 수 없는 일을 막아 줍니다.

복잡한 요구 사항은 독립적으로 확인할 수 있는 작은 작업으로 나누세요. 먼저 앱에서 로컬 프록시를 명시적으로 사용하게 한 뒤 대상 도메인 예외를 추가하고, 마지막으로 네트워크 전환 후 동작을 확인합니다. 각 단계마다 성공 조건과 되돌리는 방법을 정해야 합니다. 연결 풀, DNS 캐시와 장기 연결 때문에 결과가 달라지는 경우 앱을 다시 시작하거나 새 연결을 만들어 비교하세요. 설정을 계속 저장하는 것은 도움이 되지 않습니다. 설명할 수 없는 규칙을 많이 관리하기보다 단순한 테스트 설정 하나를 보관하는 편이 유용합니다.

확장을 멈추고 기준 설정으로 돌아가기

서버 측 프로토콜 매개변수, 계정 상태 또는 원격 서비스 제한이 문제라면 클라이언트에서 할 수 있는 일은 정확한 증상과 로그를 제공하는 것입니다. 원격 오류를 감추려고 로컬 규칙을 끝없이 추가하지 마세요. 설정 제공자에게 문의할 때는 프로토콜 유형, 실패 단계와 이미 수행한 비교 결과를 설명하고 개인 인증 정보는 제거하세요. 지원 여부가 확인되지 않은 기능은 이름이 비슷하다는 이유만으로 호환된다고 판단하지 말고 클라이언트와 코어의 지원 여부를 확인하세요.

이 과정을 마치면 진입점, 규칙과 출구의 관점에서 문제를 설명하고 클라이언트 설정, 코어 설정, 서버 측 협조가 필요한 부분을 구분할 수 있어야 합니다. 연결 과정을 다시 확인하려면 빠른 시작 가이드로 돌아가세요. 설치 방식을 바꾸려면 클라이언트 선택 가이드와 다운로드 페이지를 참고하세요. 단순하고 정상 작동하는 기준 구성을 유지하면서 실제 필요에 따라 기능을 하나씩 추가하는 것이 이 가이드를 활용하는 방법입니다.