V2Ray 사용 설명서

핵심 개념: 유입·매칭·아웃바운드 구분하기

클라이언트, 코어, 서버

V2Ray는 일반적으로 Project V와 관련된 프록시 기술 및 도구 생태계를 가리키며, 하나의 GUI 프로그램을 뜻하지는 않습니다. 클라이언트는 서버 정보를 저장하고 구독을 가져오며, 설정을 전환하고 로그를 표시합니다. 코어는 연결을 만들고 트래픽을 식별해 라우팅과 프로토콜 처리를 담당합니다. 서버는 원격에서 프로토콜 연결을 받아 목적지에 접속합니다. 세 구성 요소의 역할은 서로 다릅니다. GUI가 열린다는 것은 클라이언트가 실행됐다는 뜻일 뿐, 코어가 정상적으로 시작됐거나 원격 연결을 사용할 수 있다는 의미는 아닙니다.

V2Fly와 Xray는 관련 생태계에 속하지만 서로 다른 코어 프로젝트입니다. 일부 설정 개념은 공유하지만 기능 범위, 프로토콜 확장과 매개변수 세부 사항은 완전히 같지 않습니다. v2rayN은 배포 패키지에 따라 여러 코어를 관리할 수 있고, v2rayNG는 주로 Xray를, v2flyNG는 V2Fly를 사용합니다. 특정 필드를 인식하지 못한다면 먼저 현재 실행 중인 코어를 확인한 뒤 해당 코어의 설정 문서를 살펴보세요. 클라이언트 이름만 보고 지원 여부를 판단하면 안 됩니다.

연결은 어떤 단계를 거칠까

접속 과정을 네 단계로 나누면 문제를 찾기 쉽습니다. 먼저 앱이 연결을 로컬 유입 지점에 전달하고, 코어가 규칙에 따라 아웃바운드를 선택합니다. 프록시 아웃바운드는 원격 서버에 연결하고, 원격 서버가 마지막으로 목적지에 접속합니다. HTTP 프록시, SOCKS 프록시, TUN은 서로 다른 유입 방식이며 direct, proxy 같은 태그는 아웃바운드 선택을 나타냅니다. 유입에 실패했는데 원격 프로토콜을 바꾸는 것은 의미가 없습니다. 규칙이 잘못 적용된 상황에서 로컬 수신 포트를 계속 바꿔도 근본 원인은 해결되지 않습니다.

서버 정보에는 보통 주소, 포트, 프로토콜, 인증 정보, 전송 방식과 보안 계층이 포함됩니다. 프로토콜은 클라이언트와 서버의 통신 방식을 정하고, 전송 방식은 데이터를 전달하는 방법을 설명합니다. TLS나 REALITY 설정은 연결 보안과 관련됩니다. VLESS는 전송 방식이 아니며 WebSocket은 암호화 프로토콜이 아닙니다. 가져온 설정은 계층별로 확인해야 합니다. 주소가 같다고 두 설정이 동일한 것은 아니며, 경로, 서비스 이름, 서버 이름 등의 필드도 연결에 영향을 줄 수 있습니다.

도메인 확인과 라우팅의 관계

DNS는 도메인을 IP 주소로 변환하지만, 도메인이 클라이언트에 도달하기 전에 항상 사라지는 것은 아닙니다. 앱에 따라 프록시에 도메인 전체를 전달하기도 하고, 로컬에서 먼저 조회한 뒤 주소만 전달하기도 합니다. 코어가 받는 정보가 달라지면 매칭할 수 있는 규칙도 달라집니다. 도메인 규칙이 적용되지 않을 때는 규칙 데이터가 손상됐다고 단정하지 말고 유입 방식과 로그에 표시된 목적지 유형을 확인하세요. 같은 사이트도 앱마다 DNS 조회 위치가 달라 서로 다른 아웃바운드를 사용할 수 있습니다.

라우팅 매칭과 DNS 조회는 별개의 작업입니다. 주소 규칙에 맞추려고 도메인 조회 전략이 DNS 질의를 발생시킬 수 있지만, 그렇다고 앱의 모든 DNS 요청이 지정한 경로를 이용하는 것은 아닙니다. TUN 환경에서는 시스템 리졸버, 클라이언트의 DNS 가로채기, 브라우저 자체 조회 기능까지 고려해야 합니다. 실제 요청이 거치는 구성 요소를 먼저 정리한 다음 설정을 확인하세요. DNS 옵션을 여러 개 한꺼번에 켜는 것보다 효과적입니다.

검증 가능한 시작점 만들기

처음 설정할 때는 출처가 분명한 서버 정보 하나, 유입 방식 하나, 설명하기 쉬운 라우팅 구성만 있으면 됩니다. 먼저 브라우저에서 시스템 프록시를 사용해 접속한 다음 연결 로그에 목적지와 예상한 아웃바운드가 표시되는지 확인하세요. TUN, 사용자 지정 DNS, 앱별 프록시와 복잡한 분할 라우팅을 한꺼번에 켜면 실패 원인을 찾기 어렵습니다. 기본 설정의 가치는 단순함이 아니라 각 단계의 변화를 이전 상태와 비교할 수 있다는 데 있습니다.

이 설명서의 설정 예시는 개별 필드를 설명하기 위한 것이며, 완전한 서버 연결 정보는 포함하지 않습니다. 실제 설정은 GUI에서 변경한 뒤 클라이언트가 생성한 결과를 확인하는 것이 좋습니다. 실행 중인 설정 파일을 직접 수정하면 재시작, 서버 전환 또는 구독 업데이트 후 변경 내용이 덮어써질 수 있습니다. 이 장을 마친 뒤에는 한 번의 접속을 두고 “트래픽이 어디로 들어와 어떤 규칙에 매칭되고 어느 아웃바운드로 전달되는지” 설명할 수 있어야 합니다. 용어가 헷갈린다면 용어 설명서를 참고하세요.

클라이언트 선택: 플랫폼·코어·설정 호환성

데스크톱에서는 v2rayN부터 시작

Windows, macOS, Linux 데스크톱에서는 v2rayN부터 살펴보세요. 서버, 구독 그룹, 라우팅과 실행 로그를 GUI 한곳에서 관리해 반복 가능한 작업 흐름을 만들기 좋습니다. Windows에서는 데스크톱 버전과 클래식 WPF 버전을 선택할 수 있습니다. 데스크톱 버전은 크로스 플랫폼 UI를 사용하고, WPF 버전은 익숙한 기존 데스크톱 인터페이스를 제공합니다. 시스템 환경과 사용 방식에 맞춰 하나를 선택하세요. 같은 연결에 두 클라이언트를 동시에 실행할 필요는 없습니다.

macOS 설치 파일을 고를 때는 ‘이 Mac에 관하여’에서 칩 정보를 확인하세요. Apple Silicon은 arm64, Intel은 x64에 해당합니다. Linux는 아키텍처뿐 아니라 배포판의 패키지 형식도 확인해야 합니다. deb 패키지를 사용하는 환경에는 deb, rpm 패키지를 사용하는 환경에는 rpm을 선택하세요. 아키텍처는 프로세서에서 프로그램을 실행할 수 있는지 결정하고, 패키지 형식은 설치 도구가 파일을 관리하는 방식을 결정합니다. 두 조건을 모두 맞춰야 하며 파일 확장자만 보고 고르면 안 됩니다.

안드로이드: 기본 클라이언트와 대안

Android에서는 v2rayNG를 우선 사용하며, 주로 Xray 코어를 사용합니다. V2Fly 설정과의 호환성이 필요하다면 v2flyNG도 검토하세요. 둘 다 GUI 클라이언트지만 지원 프로토콜이 완전히 같다고 볼 수는 없습니다. 서버 정보가 특정 코어 확장 기능에 의존한다면 가져오기 방식부터 시도하지 말고 해당 클라이언트의 코어가 그 기능을 지원하는지 먼저 확인하세요. 가져오기에 성공했다고 호환성이 입증되는 것은 아닙니다. 링크를 읽어들이는 단계와 실제 연결을 수립하는 단계는 서로 다릅니다.

안드로이드 패키지 아키텍처는 기기의 OS와 프로세서 지원 여부를 기준으로 선택하세요. 최신 기기 대부분은 arm64를 지원하지만 프로세서와 시스템 환경이 맞지 않을 수도 있습니다. 확인하기 어렵다면 범용 패키지를 고려할 수 있지만 파일 크기가 더 큰 편입니다. 설치 프로그램에서 호환되지 않는다고 나오면 기기 정보와 패키지 선택을 다시 확인하세요. 같은 파일을 계속 설치하지 마세요. 다운로드 경로는 Android 다운로드 안내에서 확인할 수 있으므로 여러 출처의 설치 파일을 조합할 필요가 없습니다.

이름으로 추측하지 말고 요구 사항에 맞춰 확인

선택 전 세 가지를 정리하세요. 서버에서 사용하는 프로토콜과 전송 방식, 적용해야 할 앱, TUN이 꼭 필요한지 여부입니다. 브라우저 위주로 데스크톱을 사용한다면 시스템 프록시부터 시작하면 됩니다. 시스템 프록시를 따르지 않는 앱은 별도 설정이나 TUN을 검토해야 합니다. 안드로이드에서는 시스템 VPN 연결과 앱별 목록의 동작을 이해해야 합니다. 기능이 많다고 설정이 더 적합한 것은 아닙니다. 필요한 기능을 제공하면서 관리하기 쉬운 구성을 선택하세요.

구독 호환성은 별도로 확인해야 합니다. 구독 주소라고 불리는 항목도 실제로는 프로토콜 링크 모음, 인코딩된 목록 또는 전용 설정 파일을 반환할 수 있습니다. 특정 프로토콜을 지원하는 클라이언트라고 해서 모든 구독 형식까지 지원하는 것은 아닙니다. 이미 서버 정보를 갖고 있다면 다운로드 전에 제공 업체가 안내한 클라이언트 유형과 가져오기 방법을 확인하세요. 형식이 맞지 않으면 올바른 원본 주소를 요청하세요. 개인 구독 주소를 출처가 불분명한 온라인 변환 사이트에 입력하지 마세요.

기기 이전 시 되돌릴 방법 마련하기

다른 기기에서 이전할 때는 새 클라이언트에 별도 구독 그룹을 만들고 서버 하나만 확인하세요. 기존의 라우팅, DNS, 유입 설정을 한꺼번에 복사하지 마세요. 플랫폼마다 시스템 프록시, 권한 관리, 네트워크 인터페이스 동작이 달라 이전 기기의 설정이 그대로 작동하지 않을 수 있습니다. 기본 연결을 확인한 다음 업무 규칙을 하나씩 옮기고, 각 변경이 앱 접속에 미치는 영향을 기록하세요.

여러 클라이언트를 동시에 실행하면 프록시 포트 충돌, 시스템 프록시 변경, VPN 연결 점유가 발생할 수 있습니다. 대체 클라이언트를 검토할 때는 기존 클라이언트의 유입 기능을 먼저 중지한 다음 새 클라이언트를 실행하세요. 되돌릴 수 있도록 기존 설정은 보관하되 두 클라이언트가 동시에 시스템 트래픽을 관리하게 두지 마세요. 세 클라이언트의 차이는 클라이언트·코어·플랫폼 비교 노트에서 확인할 수 있습니다. 선택을 마쳤다면 다음 장에서 설치와 첫 실행을 진행하세요.

설치 및 초기 설정: 권한·디렉터리·수신 포트

설치 파일과 데이터 저장 위치 확인

플랫폼과 아키텍처에 맞는 설치 파일은 클라이언트 다운로드 페이지에서 선택하세요. 설치 전에 실행 중인 인스턴스를 종료하고 사용할 클라이언트의 패키지를 받았는지 확인합니다. 설치 프로그램을 제공한다면 안내에 따라 설치하세요. 배포 패키지를 압축 해제해 실행해야 한다면 별도 디렉터리에 완전히 풀어 둔 다음 실행합니다. 압축 파일 미리보기에서 프로그램을 바로 실행하면 관련 파일을 찾지 못하거나 업데이트 및 데이터 저장에 문제가 생길 수 있습니다.

프로그램 디렉터리와 설정 데이터 디렉터리는 다를 수 있습니다. 배포 방식에 따라 사용자 디렉터리에 데이터를 저장하거나 별도의 데이터 디렉터리를 지정할 수 있습니다. 첫 실행 후 설정에서 데이터 위치나 백업 기능을 확인해 구독과 라우팅 설정이 어디에 저장되는지 알아두세요. 기기를 이전할 계획이라면 바탕 화면 바로 가기만 복사하지 말고 클라이언트가 관리하는 데이터 범위를 백업하세요. 여러 사람이 쓰거나 자주 정리되는 임시 디렉터리에 실행 파일을 두는 것도 권장하지 않습니다.

데스크톱에서 첫 실행하기

Windows에서는 설치 후 일반 사용자 권한으로 실행해 화면과 로그가 정상적으로 표시되는지 확인하세요. WPF 버전에서 실행 구성 요소가 없다는 안내가 나오면 배포 패키지의 요구 사항에 따라 해당 환경을 설치하거나 현재 시스템에 맞는 설치 파일을 선택하세요. 실행에 실패했다고 계속 관리자 권한으로 실행하지 마세요. 일반 프록시와 가상 네트워크 어댑터 관리에는 필요한 권한이 다릅니다. 후자는 관련 기능을 켤 때 안내에 따라 권한을 부여하면 됩니다.

macOS에서는 앱을 사용할 위치로 옮긴 뒤 실행하세요. 임시 마운트 위치에서 반복해서 실행하지 마세요. 시스템 보안 안내가 표시되면 먼저 파일 출처, 패키지 유형, 시스템 지원 여부를 확인한 뒤 시스템의 앱 보안 절차를 따르세요. Linux에서는 해당 패키지 관리 도구로 설치한 후 앱 메뉴에서 실행하고 로그를 확인하세요. 데스크톱 구성 요소나 권한이 부족하다면 구체적인 안내에 따라 해결하고, 시스템 디렉터리 권한을 광범위하게 바꿔 문제를 우회하지 마세요.

안드로이드 설치 후 시스템 권한 설정

Android에 설치할 때 실제로 사용하는 설치 출처에만 필요한 권한을 부여하세요. 설치가 끝난 뒤에는 필요에 따라 권한을 회수할 수 있습니다. 첫 실행에서는 서버 정보 하나를 가져온 뒤 연결을 시작하세요. 시스템에 표시되는 VPN 연결 요청은 클라이언트가 로컬 트래픽 유입을 설정하도록 허용하는 절차입니다. 권한을 부여했다고 원격 연결까지 성공한 것은 아닙니다. 서버 설정과 실제 접속 결과를 확인해야 합니다. 다른 VPN 앱이 실행 중이면 유입 리소스 충돌을 방지하기 위해 먼저 연결을 중지하세요.

설치 문제와 백그라운드 문제를 구분하려면 첫 테스트에서 앱을 화면에 띄우고 화면을 켠 상태로 연결이 되는지 확인하세요. 그다음 화면 잠금과 백그라운드 동작을 테스트합니다. 화면을 잠근 뒤에만 연결이 끊긴다면 재설치하지 말고 배터리 최적화, 백그라운드 실행 제한, 제조사 시스템의 작업 정리 설정을 확인하세요. 자세한 내용은 안드로이드 권한·배터리 절약·앱별 설정을 참고하세요.

코어와 로컬 수신 상태 확인

데스크톱 클라이언트를 연 뒤 로그나 상태 영역에서 코어가 실제로 실행됐는지 확인하세요. 실행 파일을 찾지 못하는 문제, 설정 구문 분석 실패, 포트 사용 중 오류는 서로 다른 원인입니다. 첫 번째는 설치 파일이 제대로 포함됐는지 확인하고, 두 번째는 최근 변경을 되돌리며, 세 번째는 이전 인스턴스나 다른 프로그램이 같은 포트를 사용하는지 살펴보세요. 수신 포트가 열리기 전에 브라우저 프록시를 테스트하면 로컬 연결 거부 오류만 표시됩니다.

수신 주소, 포트, 프록시 프로토콜을 확인한 뒤 앱의 연결 방법을 정하세요. 시스템 프록시는 클라이언트가 실제로 수신하는 위치를 가리켜야 합니다. 앱을 수동 설정할 때도 HTTP와 SOCKS 주소를 구분해야 합니다. 반드시 사용해야 하는 포트 번호는 따로 없으므로 현재 설정을 기준으로 하세요. 포트를 바꾸면 앱 설정도 함께 업데이트해야 합니다. 앱이 이전 포트에 계속 연결하지 않도록 하고, 원격 서버 포트를 로컬 프록시 포트로 잘못 입력하지 마세요.

초기 설정 단계에서는 시작 시 자동 실행과 자동 트래픽 가로채기를 잠시 미뤄 두세요. “코어 시작 → 앱 연결 → 유입 중지 → 프로그램 종료” 과정을 한 번 완료하고 종료 후 시스템 네트워크가 정상으로 돌아오는지 확인한 뒤 자동화 옵션을 켜세요. 이렇게 하면 클라이언트가 시스템 설정을 어떻게 변경하는지 파악할 수 있습니다. 종료 후에도 인터넷에 접속할 수 없다면 전체 네트워크를 초기화하기 전에 시스템 프록시가 남아 있는지 확인하세요. 일반적인 해결 방법은 FAQ 문제 해결에서 살펴볼 수 있습니다.

구독 가져오기: 그룹·업데이트·필드 확인

서버 정보 유형과 접근 범위부터 확인

구독 주소는 내용을 업데이트하는 경로이지, 단일 서버 연결을 뜻하지는 않습니다. 여러 서버 정보를 반환하며 이후 업데이트 과정에서 항목이 추가되거나 삭제될 수 있습니다. 단일 프로토콜 링크는 연결 하나를 설명하고, QR 코드는 링크를 전달하는 방법일 뿐입니다. 가져오기 전에 받은 것이 구독 주소인지, 단일 공유 링크인지, 완전한 설정 파일인지 구분해 알맞은 기능을 사용하세요. 구독 주소를 단일 서버 입력란에 붙여 넣으면 연결할 수 없는 설정이 만들어지는 경우가 많습니다.

구독 주소에는 비공개 서버 정보에 접근할 수 있는 식별값이 포함될 수 있으므로 연결 자격 증명처럼 관리해야 합니다. 문제 해결을 위해 다른 사람에게 도움을 요청할 때는 전체 주소를 보내지 말고 QR 코드를 공개 페이지에 올리지도 마세요. 반환 형식, 오류 유형, 클라이언트 이름만으로도 기본적인 점검을 시작할 수 있습니다. 주소가 실수로 공개됐다면 대화 기록이나 브라우저 기록만 삭제하지 말고 제공 업체의 관리 기능을 통해 주소를 교체하세요.

그룹을 만들어 업데이트 관리하기

v2rayN에서 구독 그룹 관리 메뉴를 열고 그룹을 추가한 뒤 알아보기 쉬운 설명과 실제 구독 주소를 입력하고 저장한 다음 업데이트를 실행하세요. 출처마다 그룹을 하나씩 만들면 업데이트가 영향을 주는 범위를 파악하기 쉽습니다. 설명은 로컬에서 항목을 구분하는 용도이며 연결 기능을 바꾸지는 않습니다. 첫 업데이트 후 서버 항목이 생성됐는지, 올바른 그룹에 속하는지, 로그에 형식 분석 오류가 표시되는지 확인하세요. 화면에 성공 메시지가 떴는지만 봐서는 안 됩니다.

v2rayNG와 v2flyNG에서는 구독 관리 메뉴를 찾아 주소를 추가하고 업데이트하세요. 메뉴 이름은 실제 화면을 기준으로 확인하면 됩니다. 단일 공유 링크가 있다면 클립보드 가져오기나 QR 코드 스캔 등 해당 기능을 사용하세요. 가져오기 전에 클립보드에 링크 앞뒤로 설명 문구가 섞이지 않았는지 확인하고, 스캔 후에는 프로토콜, 주소와 메모를 점검하세요. QR 코드를 여러 개 연속으로 가져올 때는 같은 항목이 중복 추가되지 않았는지도 확인해 오래된 항목을 선택하지 않도록 하세요.

업데이트 오류는 네트워크와 형식을 나눠 점검

업데이트에 실패했다면 먼저 프로토콜 접두어, 경로, 쿼리 매개변수를 포함해 주소가 완전한지 확인하세요. 복사 방식에 따라 마지막 문자가 빠질 수 있습니다. 다음으로 연결 시간 초과, 접근 거부, 인증서 오류, 콘텐츠 분석 실패 중 어떤 문제인지 구분하세요. 앞의 두 오류는 네트워크 경로와 주소 접근 권한을 우선 확인합니다. 인증서 오류는 시스템 시간과 인증서 환경을 점검해야 합니다. 분석 실패라면 반환 내용이 클라이언트에서 지원하는 구독 형식인지, 웹 로그인 페이지나 오류 안내문은 아닌지 확인하세요.

클라이언트에 프록시를 통해 구독을 업데이트하는 옵션이 있을 수 있습니다. 직접 연결로 내용을 가져오지 못하면 이미 사용 가능한 연결이 있는 경우 시도해 볼 수 있습니다. 현재 사용할 수 있는 연결이 없다면 ‘프록시를 통한 업데이트’를 자동 해결책으로 기대할 수 없습니다. 먼저 작동하는 연결을 만들거나 제공 업체에 접근 가능한 업데이트 방법을 문의하세요. 업데이트 경로, DNS, 코어를 동시에 바꾸면 실제로 어떤 설정이 결과를 바꿨는지 파악하기 어렵습니다.

메모만 보지 말고 가져온 내용 확인

목록에서 서버 하나를 선택해 프로토콜, 주소, 포트, 인증 필드, 전송 방식과 보안 계층을 차례로 확인하세요. WebSocket은 경로와 Host를, gRPC는 서비스 이름을, TLS는 서버 이름과 인증서 검증 조건을 중점적으로 살펴봅니다. 프로토콜마다 필드 역할이 다르므로 서로 바꿔 쓸 수 없습니다. 값이 비어 있어도 문제가 없을 수 있고 정보가 부족하다는 신호일 수도 있으므로 서버 요구 사항에 따라 판단하세요.

업데이트 전 현재 선택한 서버와 그룹을 기록하고, 업데이트 후 선택 상태를 다시 확인하세요. 일부 클라이언트는 기존 항목을 찾아 선택 상태를 유지하지만, 상황에 따라 항목이 교체되거나 삭제될 수도 있습니다. 비슷한 메모가 화면에 남아 있다고 실제 매개변수가 그대로라는 뜻은 아닙니다. 업데이트 후에만 문제가 생겼다면 모든 데이터를 바로 삭제하지 말고 구체적인 필드와 코어 오류를 비교하세요. 검증을 마친 독립 테스트 항목 하나를 보관하면 구독 변경과 로컬 환경 변경을 구분하는 데 도움이 됩니다.

구독 관리를 마쳤다고 볼 수 있는 기준은 출처가 명확하고, 그룹을 구분할 수 있으며, 업데이트 동작을 설명할 수 있고, 항목 하나 이상으로 연결을 만들 수 있는 것입니다. 서버 목록의 테스트 결과는 그 시점의 관찰일 뿐 실제 사용 환경에서의 검증을 대신하지 않습니다. 다음으로 정해 둔 유입 방식으로 대상 앱을 접속하게 한 뒤 라우팅 최적화를 검토하세요. 처음 설정만 마치면 된다면 빠른 시작 가이드로 돌아가고, 프로토콜 필드가 궁금하다면 프로토콜·전송 용어를 참고하세요.

프록시 모드: 유입 범위와 트래픽 방향

시스템 프록시: 앱의 연결 경로 설정

시스템 프록시는 운영체제가 앱에 제공하는 프록시 설정입니다. 데스크톱 클라이언트에서 기능을 켜면 일반적으로 HTTP 등의 프록시 주소가 시스템 설정에 등록되고, 그 설정을 따르는 앱만 클라이언트로 연결을 전달합니다. 브라우저는 대개 시스템 프록시를 사용할 수 있지만 일부 게임, 명령줄 도구, 자체 네트워크 구성 요소를 사용하는 프로그램은 그렇지 않을 수 있습니다. 시스템 프록시를 켰는데 일부 앱만 작동한다면 유입 범위 문제일 가능성이 높으며 원격 서버 탓으로 바로 돌려서는 안 됩니다.

v2rayN에서 먼저 사용할 수 있는 서버를 연결한 다음 시스템 프록시를 설정하고 브라우저에서 새 연결을 시도하세요. 테스트 전에 브라우저의 별도 프록시 확장 프로그램이 시스템 설정을 덮어쓰지 않는지 확인하거나 사용 중지하세요. 이미 만들어진 장시간 연결은 기존 경로를 계속 사용할 수 있으므로 프록시 설정을 바꾼 뒤 페이지를 새로고침하고 필요하면 앱을 다시 여세요. 스위치 색상만 보고 새 연결이 클라이언트로 들어왔는지 판단할 수는 없습니다.

전역·우회 모드: 유입된 트래픽의 경로 설정

전역 프록시는 클라이언트로 들어온 트래픽 중 필요한 예외 규칙에 해당하지 않는 흐름을 프록시 아웃바운드로 보내는 방식입니다. 시스템의 모든 앱이 자동으로 연결된다는 뜻은 아닙니다. 중국 본토 우회 모드 등은 도메인과 주소 규칙에 따라 일부 목적지는 직접 연결하고 나머지는 프록시를 사용합니다. 이 둘은 라우팅 선택 방식이며 시스템 프록시와는 다른 계층입니다. 시스템 프록시를 켜고 우회 규칙을 사용할 수도 있고, TUN으로 트래픽을 유입시킨 뒤 같은 라우팅 원칙을 적용할 수도 있습니다.

문제 해결을 위해 전역 모드를 사용할 때의 목적은 대상별 분할 라우팅으로 생기는 변수를 잠시 줄이는 것이지, 모든 로컬 요구 사항을 계속 무시하는 것이 아닙니다. LAN 기기, 루프백 주소, 원격 서버로 향하는 연결은 여전히 적절히 처리해야 합니다. 클라이언트마다 예외 규칙이 다를 수 있으므로 ‘전역’이 모든 규칙을 삭제한다는 뜻은 아닙니다. 목적지가 실제로 어떤 경로를 사용하는지 확인하려면 모드 이름만 보고 추측하지 말고 현재 프리셋과 실행 로그를 살펴보세요.

앱 하나를 골라 연결 경로 확인

반복해서 테스트하기 쉬운 앱 하나를 정하고 시스템 설정을 사용하는지 별도 프록시 설정을 사용하는지 확인하세요. 프록시를 직접 입력한다면 원격 서버 주소가 아니라 로컬 수신 주소와 프로토콜에 맞는 포트를 사용해야 합니다. SOCKS 연결에서 도메인을 프록시가 조회하는지는 앱의 옵션 지원 여부에 따라 다릅니다. 로컬 조회와 원격 조회는 서로 다른 규칙 매칭 결과를 낼 수 있습니다. 작업 전에 기존 설정을 기록하고 테스트가 끝나면 복원해 눈에 띄지 않는 설정 덮어쓰기를 남기지 마세요.

검증할 때는 앱의 결과와 클라이언트 로그를 함께 확인하세요. 앱 연결에 실패하고 로그에 목적지 기록도 없다면 먼저 유입을 점검합니다. 기록은 있지만 잘못된 아웃바운드를 사용한다면 라우팅을 확인하세요. 예상한 프록시 아웃바운드를 사용했는데 연결에 실패한다면 프로토콜과 원격 서버를 점검할 차례입니다. 로그 레벨이 낮아 세부 정보가 부족하면 잠시 높인 뒤 한 번 재현하세요. 페이지가 열리는지 여부만으로 문제 계층을 판단하지 말고 캐시된 페이지를 새 네트워크 결과로 오해하지도 마세요.

안드로이드 앱별 설정과 데스크톱 예외

Android VPN 연결에서는 앱별 목록을 사용할 수 있습니다. 목록이 ‘선택한 앱만 프록시 사용’을 뜻하는지 ‘선택한 앱 우회’를 뜻하는지에 따라 결과가 반대이므로 현재 옵션 설명을 반드시 읽으세요. 목록을 수정한 뒤 연결을 다시 만들고 테스트할 앱에서도 새 연결을 시도해야 합니다. 목록에서 제외된 앱은 클라이언트 처리 경로에 들어오지 않으므로 전역 라우팅으로 전환해도 자동으로 포함되지 않습니다.

데스크톱에도 시스템 프록시 예외 목록, 브라우저 자체 설정, 앱별 네트워크 옵션이 있습니다. 로컬 관리 페이지에 접속할 수 없다면 먼저 적절하지 않은 프록시 경로로 요청이 전달되는지 확인하세요. 특정 앱이 항상 직접 연결된다면 시스템 설정을 우회하는지 살펴보세요. 유입 경로를 분석하는 대신 전역 모드와 우회 모드를 계속 바꾸지 마세요. 자세한 비교는 시스템 프록시와 라우팅 모드 노트를 참고하세요. 유입을 확인한 뒤 다음 장에서 규칙을 구성합니다.

라우팅 설정: 순서·조건·아웃바운드 태그

규칙을 실행하는 주체부터 확인

라우팅 규칙은 실행 중인 코어가 처리하고 GUI는 설정을 생성하거나 관리합니다. 변경하기 전에 현재 사용 중인 코어, 활성 라우팅 프리셋, 서버 설정 유형을 확인하세요. 일부 사용자 지정 설정은 자체적으로 라우팅을 정의하므로 클라이언트의 일반 규칙 화면을 사용하지 않을 수 있습니다. 변경 후 결과가 전혀 없다면 사용하지 않는 프리셋을 계속 수정하지 말고 편집한 설정이 실제 실행 구성에 반영됐는지 먼저 확인하세요.

일반적으로 규칙은 순서대로 검사하며 먼저 일치하는 규칙이 아웃바운드를 결정합니다. 구체적인 업무 도메인을 넓은 분류보다 앞에 두고 LAN 예외는 일반 프록시 규칙보다 앞에 배치하면 규칙이 서로 덮어쓰는 일을 줄일 수 있습니다. 한 규칙 안의 조건을 어떤 방식으로 조합하는지도 확인하세요. 일반적인 field 규칙에서는 서로 다른 유형의 조건이 함께 매칭 범위를 제한하고, 같은 유형의 목록은 후보 값을 제공합니다. 도메인과 포트가 함께 있는 규칙을 서로 독립된 두 규칙으로 오해하지 마세요.

domainStrategy와 태그 이해하기

domainStrategy는 라우팅 매칭을 위한 도메인 조회 방식에 영향을 줍니다. AsIs는 주소 매칭을 위해 도메인을 적극적으로 조회하지 않습니다. IPIfNonMatch는 도메인 규칙에 일치하지 않은 경우 주소 조건에 맞추기 위해 조회를 시도합니다. IPOnDemand는 관련 주소 규칙을 만났을 때 먼저 조회할 수 있습니다. 이 설정은 프록시 프로토콜 스위치가 아니며 클라이언트의 모든 DNS 전달 방식을 직접 결정하지도 않습니다. 규칙 내용과 조회 비용을 고려해 선택하세요.

outboundTag는 실제로 존재하는 아웃바운드 태그를 참조합니다. direct, proxy, block은 흔히 쓰이는 이름일 뿐이며 해당 아웃바운드 정의가 있어야 의미가 있습니다. 아래 예시는 라우팅 일부만 보여줍니다. 실행 설정에 direct와 proxy가 정의되어 있고 해당 규칙 데이터 파일도 있다고 가정합니다. 이 조각을 완전한 설정 파일로 저장하지 말고, 태그를 확인하지 않은 채 클라이언트가 생성한 내용을 덮어쓰지 마세요.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

규칙 데이터와 정확한 도메인 매칭

geosite는 도메인 집합을, geoip는 IP 주소 집합을 참조합니다. 사용 가능한 집합 이름과 내용은 실제 설치된 데이터 파일에 따라 달라집니다. 인터넷에서 실시간 조회한 절대적인 판정이 아니며 데이터 업데이트 후 분류가 바뀔 수도 있습니다. 사이트 하나가 여러 관련 도메인을 사용한다면 기본 페이지 도메인만 매칭해서는 로그인, 리소스, API 요청까지 처리하기 부족할 수 있습니다. 로그를 보고 하나씩 확인하고 관련 없는 분류 전체로 범위를 넓히지 마세요.

정확한 예외 규칙을 작성할 때는 완전한 도메인 매칭과 접미사 매칭을 구분하세요. 예를 들어 full:example.com은 해당 도메인 전체와 일치하고, domain:example.com은 일반적으로 하위 도메인까지 포함합니다. 예시 도메인은 문법 설명용이며 실제 규칙에는 대상 서비스의 도메인을 입력하세요. 경계를 명확히 지정하는 대신 모호한 키워드 매칭을 사용하면 우연히 같은 문자열을 포함한 다른 서비스까지 대상이 되어 문제를 찾기 어려울 수 있습니다.

로그로 규칙 매칭 과정 확인하기

규칙을 검증할 때는 한 번에 하나만 바꾸고 저장한 뒤 클라이언트 안내에 따라 다시 불러온 후 새 연결을 만드세요. 목적지가 도메인인지 IP 주소인지, 어떤 조건에 매칭됐는지, 최종적으로 어떤 아웃바운드를 사용했는지 기록합니다. 목적지에 IP 주소만 남았다면 도메인 규칙을 적용할 정보가 부족할 수 있습니다. 더 앞에 있는 포괄적인 규칙이 먼저 매칭되면 뒤쪽의 구체적인 조건은 실행되지 않습니다. 문제 해결을 위해 규칙을 임시로 옮길 때는 원래 위치를 기록하고 테스트 후 복구하세요.

분할 라우팅 후 일부 리소스에 접속할 수 없다면 해당 서비스를 잠시 하나의 사용 가능한 아웃바운드로 보내 테스트한 뒤 관련 도메인 범위를 좁히세요. 규칙 범위가 부족한지 원격 서비스 자체에 문제가 있는지 구분할 수 있습니다. 처음부터 많은 규칙 모음을 추가하지 마세요. 집합이 늘어날수록 경로를 설명하기 어려워집니다. 안정적인 라우팅은 각 규칙의 목적과 순서, 취소 방법을 설명할 수 있어야 합니다. 용도를 설명할 수 없는 항목은 알 수 없는 의존성으로 남겨 두기보다 우선 비활성화하고 관찰하세요.

TUN 모드: 가상 네트워크 어댑터·DNS·루프백

일반 프록시 연결부터 확인

TUN은 가상 네트워크 인터페이스로 시스템 트래픽을 받아 프록시를 직접 설정할 수 없거나 시스템 프록시를 따르지 않는 앱에 유용합니다. 바뀌는 것은 유입 경로이며 이후에는 라우팅과 사용 가능한 아웃바운드가 여전히 필요합니다. TUN을 켜기 전에 일반 프록시로 같은 서버에서 목적지에 접속할 수 있는지 확인하세요. 그렇지 않으면 문제가 생겼을 때 원격 연결과 로컬 네트워크 어댑터 중 원인을 구분하기 어렵습니다. TUN은 잘못된 서버 정보를 고치는 기능도 아니고 모든 앱의 네트워크 동작을 같게 만들어 주지도 않습니다.

GUI 클라이언트의 TUN 구현은 코어, 보조 구성 요소와 권한 처리 방식이 서로 다를 수 있으므로 설정 필드가 일반 Xray 라우팅 설정과 같다고 볼 수 없습니다. 다른 구현의 설정 전체를 현재 클라이언트에 붙여 넣지 마세요. 먼저 현재 TUN 설정 화면에서 자동 라우팅, DNS 가로채기, 우회 네트워크 대역, 프로토콜 스택의 역할을 확인하세요. 요구 사항이 명확하지 않으면 적절한 기본값을 유지하고 모든 옵션을 한꺼번에 바꾸지 않는 것이 좋습니다.

권한과 시스템 라우팅

처음 켤 때 관리자 권한을 요청하거나 가상 네트워크 어댑터 구성 요소를 설치해야 할 수 있습니다. 권한을 부여한 뒤 코어 로그, 네트워크 어댑터 생성 여부, 시스템 라우팅이 예상대로 적용됐는지 확인하세요. 어댑터 이름이 나타났다고 트래픽이 코어로 들어오고 있다는 뜻은 아닙니다. 스위치가 켜져 있어도 생성 과정이 실패했을 수 있습니다. 활성화에 실패하면 오류 내용을 보관하고 권한과 구성 요소 상태부터 점검한 뒤 다시 시도하세요. 용도를 알 수 없는 인터페이스를 계속 만들지 마세요.

자동 라우팅은 시스템이 네트워크 출구를 선택하는 방식에 영향을 주므로 클라이언트에서 원격 서버로 향하는 트래픽을 특히 주의해야 합니다. 이 트래픽이 다시 가로채져 같은 프록시 유입 지점으로 전달되면 루프가 발생해 반복적으로 재연결되거나 네트워크 전체가 끊길 수 있습니다. 클라이언트에 해당 상황을 방지하는 기능이 있다면 설계된 처리 방식을 우선 사용하세요. 네트워크 대역이나 프로세스 예외를 직접 추가하기 전에 실제 출구 인터페이스와 원격 주소를 확인해 너무 넓은 범위를 우회하지 않도록 하세요.

DNS 가로채기는 별도로 검증

TUN에서 흔히 발생하는 문제는 IP 주소로는 직접 연결되지만 도메인으로는 접속되지 않는 경우입니다. DNS 요청이 어디에 도달하는지, 클라이언트가 상위 DNS 서버에 접근할 수 있는지, 조회 결과가 이후 라우팅에 사용될 수 있는지 확인하세요. 앱은 시스템 DNS를 사용하거나 자체적으로 암호화된 DNS 연결을 만들 수 있습니다. 클라이언트에서 특정 DNS 서버를 설정했다고 앱의 모든 DNS 조회가 자동으로 가로채지는 않습니다. 설정 화면에 서버 주소가 표시되는지만 보지 말고 실제 요청 경로를 확인하세요.

일부 구현에는 도메인을 예약된 IP 주소 범위에 연결한 다음 이후 연결에서 도메인 정보를 복원하는 FakeDNS 기능이 있습니다. DNS와 트래픽 가로채기가 함께 작동해야 하므로 모든 환경에서 기본값처럼 사용할 수 있는 기능은 아닙니다. 앱에 이전 조회 결과가 캐시돼 있거나 가로채기 경로를 우회하거나 자체 DNS를 사용하면 매핑 정보가 일치하지 않을 수 있습니다. 분명한 요구가 없다면 단순한 DNS 구성을 먼저 사용하고 일반 연결이 안정된 뒤 이 기능을 별도로 테스트하세요.

LAN·듀얼 스택·앱별 동작 범위

웹, LAN 서비스, 절전 모드 해제, 네트워크 전환을 포함해 테스트하세요. 프린터, 파일 공유, 라우터 관리 페이지에 접속할 수 없다면 로컬 네트워크 대역이 실수로 프록시로 전달되는지 먼저 확인하세요. 기업 네트워크는 일반적이지 않은 내부 대역이나 전용 DNS를 사용할 수 있으므로 가정용 네트워크 경험만으로 우회 설정을 정하지 마세요. 내부 DNS 조회를 유지해야 한다면 조회 경로와 접속 경로를 함께 고려해야 합니다. 주소만 직접 연결하도록 설정해도 도메인 문제는 해결되지 않을 수 있습니다.

IPv4와 IPv6도 각각 확인해야 합니다. 한 주소 계열만 가로채면 앱이 다른 주소 계열을 우선 사용해 예상과 다른 경로로 연결할 수 있습니다. 조회 결과에 접근할 수 없는 주소 계열이 포함되면 연결이 성공하기까지 오래 기다릴 수도 있습니다. 실제 목적지 주소와 시스템 연결 결과를 살펴보고 주소 계열 전체를 끄는 것을 첫 번째 해결책으로 삼지 마세요. 안드로이드에서는 VPN 상시 사용, VPN을 거치지 않는 연결 차단 같은 시스템 설정도 확인하세요. 클라이언트를 중지한 뒤의 동작이 달라질 수 있습니다.

TUN에서 특정 앱만 문제를 일으킨다면 해당 앱의 연결 특성을 확인하세요. UDP를 사용하는지, 네트워크 어댑터를 지정하는지, 자체 프록시 설정이 있는지, LAN 기기 검색이 필요한지 살펴보세요. MTU를 무작정 낮추는 것보다 항목별 검증이 근거에 맞습니다. 라우터나 보조 라우터를 사용하면 게이트웨이와 응답 경로도 유입 범위에 영향을 줄 수 있으므로 라우터 배포 노트를 참고하세요. 데스크톱 TUN 설정을 게이트웨이 환경에 그대로 적용하지 마세요.

유지 관리: 업데이트·백업·단계별 문제 해결

업데이트 대상을 구분해 관리

클라이언트 프로그램, 프록시 코어, 라우팅 데이터, 구독 내용은 서로 다른 업데이트 대상입니다. 클라이언트 업데이트는 화면과 설정 생성 방식을 바꿀 수 있고, 코어 업데이트는 기능과 매개변수 지원을 변경할 수 있습니다. 규칙 데이터 업데이트는 분류 결과에 영향을 주고 구독 업데이트는 서버 정보를 변경합니다. 업데이트 후 문제가 생겼다면 어느 계층을 방금 업데이트했는지 먼저 확인하세요. 모든 항목을 한꺼번에 업데이트하면 편리하지만 회귀 문제를 비교할 기준이 사라집니다.

업데이트 전에 클라이언트 백업 기능으로 필요한 데이터를 저장하고 현재 유입 방식, 라우팅 프리셋, DNS 설정과 검증된 서버를 기록하세요. 백업에는 민감한 연결 정보가 포함될 수 있으므로 접근이 제한된 위치에 보관하고 공개 동기화 폴더에 바로 넣지 마세요. 업그레이드 후에는 기존의 최소 환경부터 확인한 다음 TUN과 특수 규칙을 테스트하세요. 프로그램이 열리는지만 확인하고 기존 백업을 삭제하거나 곧바로 설정을 더 조정하지 마세요.

유입·코어·원격 연결별로 문제 분리

아무것도 접속되지 않으면 먼저 트래픽 가로채기를 중지해 기본 네트워크가 정상인지 확인하세요. 기본 네트워크도 작동하지 않으면 Wi-Fi, 게이트웨이, 시스템 네트워크 상태를 점검합니다. 기본 네트워크는 정상이지만 프록시가 작동하지 않는다면 로컬 수신 상태와 코어 로그를 확인하세요. 브라우저에서 로컬 연결 거부가 표시되면 원격 프로토콜보다 수신 주소, 포트, 프로세스 상태를 먼저 살펴봐야 합니다. 로그에 설정 분석 오류가 표시된다면 가장 최근에 변경한 설정을 되돌리는 것이 빠릅니다.

목적지 기록은 있지만 원격 연결이 실패한다면 이름 조회 실패, 연결 시간 초과, 연결 거부, 보안 핸드셰이크 실패를 구분하세요. 이름 조회 실패는 DNS 경로를 확인합니다. 시간 초과는 주소, 포트와 도달 가능성을 살펴봅니다. 연결 거부는 일반적으로 대상 포트가 연결을 받아들이지 않는다는 뜻입니다. 핸드셰이크 문제는 시스템 시간, 서버 이름, 전송 방식과 인증 매개변수를 확인하세요. 인증서 검증을 끄는 방식으로 오류를 숨기지 말고 검증에 실패한 이유를 찾으세요.

속도 테스트는 조건을 동일하게 유지

속도 저하가 반드시 프로토콜 문제인 것은 아닙니다. 같은 기기, 네트워크, 목적지와 시간대에 테스트 방법을 통일한 뒤 서버를 비교하세요. 다운로드 대상, Wi-Fi 신호, 통신사 경로, 로컬 백그라운드 작업 모두 결과에 영향을 줍니다. 한 번의 연결 테스트로 지속적인 전송 성능을 판단할 수는 없습니다. 목록에서 같은 테스트만 반복하기보다 성격이 다른 여러 서비스를 확인하는 편이 실제 사용 환경에 가깝습니다.

웹은 정상인데 대용량 파일 전송만 문제라면 대상 서비스 제한, 연결 재사용, 회선 안정성을 확인하세요. 한 앱에서만 느리다면 자체 프록시와 DNS 조회 경로를 점검합니다. 모든 앱이 느리다면 기본 네트워크와 프록시 경로를 비교하세요. TUN 환경에서는 다른 VPN이나 보안 프로그램이 트래픽을 가로채는지도 확인해야 합니다. 자세한 단계별 점검은 속도 저하 문제 해결 노트를 참고하세요. 근거 없이 설정 전체를 계속 바꾸지 마세요.

문제 해결에 필요한 로그만 보관

평소에는 적절한 로그 수준을 사용하고 문제를 재현할 때만 잠시 상세도를 높이세요. 발생 시간, 작업 순서, 유입 모드와 오류 원문을 기록하는 편이 서버 목록 전체를 캡처하는 것보다 도움이 됩니다. 공유하기 전에 주소, 인증 정보, 구독 주소, 개인 업무 도메인이 포함되지 않았는지 확인하세요. 작업이 끝나면 평소 로그 수준으로 되돌려 불필요하게 많은 파일이 쌓이지 않도록 하고 장기간의 접속 기록을 일반 백업처럼 가볍게 공유하지 마세요.

종료와 기기 이전도 유지 관리의 일부

클라이언트를 종료하기 전에 사용 중인 방식에 따라 시스템 프록시나 TUN을 중지하고 네트워크가 복구됐는지 확인하세요. 비정상 종료 후 브라우저가 연결되지 않는다면 시스템 프록시가 이미 종료된 로컬 수신 주소를 가리키는지 점검합니다. TUN 환경에서는 라우팅과 DNS가 복구됐는지 확인하세요. 여러 앱 사이에서 트래픽 가로채기를 전환하면서 이전 상태를 정리하지 않는 일을 피하세요. 재설치가 필요하면 먼저 백업하고 데이터가 손상된 것을 확인한 경우에만 설정 재구성을 고려하세요. 재설치를 모든 문제의 공통 해결책으로 삼지 마세요.

새 기기로 옮긴 뒤에는 필요한 데이터만 복원하고 자동 시작과 백그라운드 옵션을 전부 바로 활성화하지 마세요. 구독 업데이트, 코어 실행, 앱 유입, 라우팅 매칭, 종료 후 복구를 하나씩 테스트한 뒤 자동화를 켜세요. 장기적인 유지 관리의 목표는 설정을 계속 늘리는 것이 아니라 작동 여부가 확인된 복구 경로를 유지하는 것입니다. 자주 묻는 문제는 FAQ 분류 페이지에서 확인하고, 복잡한 문제는 최소 재현 절차를 기록해 계속 분석하세요.

고급 설정: 최소 실험과 관리하기 쉬운 구성

명확한 문제 하나부터 확장

고급 설정의 목표는 기능을 더 많이 켜는 것이 아니라 이미 확인된 문제를 해결하는 것입니다. 먼저 “특정 업무 도메인은 항상 직접 연결”, “특정 앱은 프록시로 전달”, “네트워크 전환 후 자동 복구”처럼 요구 사항을 구체적으로 적으세요. 그런 다음 유입, 라우팅, DNS 조회, 실행 관리 중 어느 계층의 문제인지 판단합니다. 요구 사항을 명확하게 분류할수록 변경 범위를 줄일 수 있습니다. 단순히 “전체적으로 더 빠르게”가 목표라면 반복 가능한 측정 방법과 증상을 먼저 정리한 뒤 변경할 항목을 결정하세요.

각 실험의 기준 상태를 보관하고 라우팅 프리셋을 복사하거나 별도의 서버 테스트 항목을 만들어 일상 설정을 덮어쓰지 마세요. 입력 조건, 예상 결과, 관찰 방법과 되돌리는 절차를 기록하세요. 예를 들어 완전한 도메인 규칙을 추가한 뒤 새 연결에서 아웃바운드를 확인하고 다른 도메인의 매칭 범위가 넓어지지 않았는지 살펴볼 수 있습니다. 실험에 성공했다고 계속 사용해도 된다는 뜻은 아닙니다. 재시작, 구독 업데이트, 네트워크 변경 후에도 동작이 같은지 추가로 확인해야 합니다.

프로토콜·보안 계층·전송 방식을 따로 평가

VLESS, VMess, Trojan을 알아볼 때는 이름만으로 성능을 판단하지 말고 현재 서버와 코어의 호환 조건을 확인하세요. 프로토콜은 통신 방식을 정의하고 TLS와 같은 보안 메커니즘은 연결을 보호합니다. 전송 방식은 서버 배포 환경과 중간 네트워크 조건의 영향을 받습니다. 한 환경에서 조합이 작동했다고 다른 회선에서도 같은 결과가 나온다는 뜻은 아닙니다. 서버가 지원해야만 클라이언트 매개변수도 의미가 있습니다.

전송 필드를 조정할 때는 양쪽 설정이 일치해야 합니다. 경로, 서비스 이름, 서버 이름, 인증 매개변수는 각각 역할이 있으므로 같은 문자열로 임의 대체하면 안 됩니다. 공유 링크에 필드가 빠져 있다면 다른 서버에서 복사하지 말고 정보 제공처에 확인하세요. 보안 핸드셰이크 전후 중 어느 시점에 연결 문제가 발생했는지에 따라 점검 방향도 달라집니다. 의미를 설명하지 않은 ‘범용 매개변수 모음’을 모으기보다 로그의 진행 단계를 이해하는 것이 실질적인 도움이 됩니다.

DNS와 라우팅 경로 함께 검증

고급 DNS 설정을 다루기 전에 세 가지를 확인하세요. 누가 조회를 요청하는지, 누가 실제 조회를 수행하는지, 결과가 어떤 연결에 사용되는지입니다. 도메인 규칙은 조회 없이 아웃바운드를 결정할 수 있고 주소 규칙은 결과 조회가 필요할 수 있습니다. 앱 자체의 DNS 조회는 클라이언트를 우회할 수도 있습니다. 경로를 각각 기록해야 특정 상위 DNS 서버 설정이 어느 구간에 영향을 주는지 알 수 있습니다. 설정 화면을 깔끔하게 보이게 하려고 모든 조회를 내부 네트워크에 맞지 않는 하나의 서버로 강제하지 마세요.

DNS 분할이 필요하다면 DNS 서버에 접근하는 경로와 반환된 주소에 실제로 접속할 수 있는지를 함께 확인해야 합니다. DNS 요청이 성공했다고 반환 결과가 현재 네트워크에서 사용 가능하다는 뜻은 아닙니다. IP 주소에 연결할 수 있어도 도메인 분류가 예상대로라는 보장은 없습니다. 실험에서는 분명한 목적지 몇 개만 골라 도메인, 반환 주소, 아웃바운드를 각각 기록하세요. 처음부터 여러 규칙 모음, 상위 DNS 서버, 복잡한 캐시 정책을 도입하면 캐시 상태가 매번 달라져 재현하기 어려워집니다.

생성된 설정을 읽고 출처 명확히 하기

GUI 조작에 익숙해지면 클라이언트가 생성한 설정을 살펴 인바운드 태그, 라우팅 조건, 아웃바운드 정의의 참조 관계를 추적할 수 있습니다. 모든 필드를 외우기보다 서버 정보에서 가져온 항목, 전역 설정에서 온 항목, 라우팅 프리셋에서 온 항목을 구분하는 것이 중요합니다. 실행 중인 파일은 다시 생성될 수 있으므로 유지할 변경 사항은 해당 관리 화면에서 수정하세요. 사용자 지정 설정이 꼭 필요하다면 어떤 역할을 대신하며 어떤 GUI 옵션이 더 이상 적용되지 않는지 분명히 알아야 합니다.

한 번에 끝내지 말고 단계별로 검증

먼저 안정적인 연결을 만들고, 다음으로 설명 가능한 분할 라우팅을 설정하세요. 그다음 특수 앱과 TUN을 다루고 마지막에 여러 코어와 복잡한 DNS 설정을 검토하는 순서가 좋습니다. 각 단계에는 완료 기준이 있어야 합니다. 연결 단계에서는 성공과 실패를 재현할 수 있어야 하고, 라우팅 단계에서는 목적지가 어떤 아웃바운드를 사용하는지 설명할 수 있어야 합니다. 트래픽 유입 설정 단계에서는 시스템 네트워크를 정상적으로 복구할 수 있어야 하며, 유지 관리 단계에서는 백업에서 최소 환경을 복원할 수 있어야 합니다. 앞 단계의 기준을 통과하지 못했다면 다음 설정을 추가하지 마세요.

코어를 바꿀 때는 프로토콜, 라우팅 데이터, DNS 동작을 다시 확인해야 합니다. 코어가 실행됐다고 설정까지 같다는 뜻은 아닙니다. 일상적으로 사용할 코어와 프리셋을 하나 정하고 다른 구성은 명확한 기능 테스트에만 사용하면 전환에 따른 불확실성을 줄일 수 있습니다. 설정 과정을 다시 따라가려면 사용 안내서로, 설치 파일을 찾으려면 클라이언트 다운로드로 이동하세요. 용어와 문제 해결은 각각 용어 설명서와 FAQ에서 확인할 수 있습니다. 최종 구성은 설명하고 검증하며 되돌릴 수 있어야 합니다.