v2rayN 전체 가이드
설정 및 관리

핵심 개념: 연결 흐름 이해하기

클라이언트, 코어, 원격 서버 구분하기

먼저 연결을 네 단계로 나눠 보겠습니다. 앱이 요청을 보내면 로컬 프록시가 이를 받고, 코어가 설정에 따라 처리해 전달한 뒤 원격 서버가 대상 웹사이트에 연결합니다. v2rayN은 설정과 실행 상태를 관리하는 그래픽 클라이언트이지 원격 서버가 아니며, 설치만으로 사용할 수 있는 연결이 자동으로 생기지도 않습니다. 클라이언트는 구독 그룹, 서버 선택, 시스템 프록시, 코어 실행을 관리합니다. 실제 프로토콜과 전송, 라우팅을 처리하는 것은 코어입니다. 이 관계를 이해하면 ‘프로그램이 실행된다’와 ‘연결이 이루어진다’가 별개의 문제임을 알 수 있습니다.

Project V는 관련 프록시 기술 생태계의 배경이며, V2Fly와 Xray는 서로 다른 코어 프로젝트입니다. 일부 개념은 공유하지만 기능, 설정 필드, 지원 범위가 항상 같지는 않습니다. 공유 링크를 가져올 수는 있지만 실행되지 않는다면 클라이언트 이름만 볼 것이 아니라 현재 코어가 해당 조합을 지원하는지 먼저 확인하세요. 그래픽 인터페이스에 옵션이 표시된다고 해서 모든 코어에서 작동하는 것은 아닙니다. 코어를 바꾼 뒤에는 생성된 설정과 시작 로그를 다시 확인해 변경 사항이 실제로 적용됐는지 살펴보세요.

프로토콜, 전송 방식, 보안 계층 구분하기

VMess, VLESS, Trojan은 서로 다른 프록시 프로토콜을 가리킵니다. TCP, WebSocket, gRPC 등은 데이터를 전달하는 전송 방식이며, TLS와 REALITY는 연결 보안 방식과 관련이 있습니다. 서로 다른 계층이므로 대신 사용할 수 없습니다. 예를 들어 VLESS를 선택해도 올바른 전송 및 보안 매개변수를 입력해야 합니다. REALITY도 선택만 하면 연결되는 범용 스위치가 아닙니다. 서버 측에 맞는 공개 키, 서버 이름 및 기타 매개변수가 필요하므로 서비스 제공업체가 전달한 전체 설정을 기준으로 구성하세요.

노드는 보통 원격 연결을 설정하는 데 필요한 설정 항목을 뜻하며, 주소, 포트, 사용자 식별자, 비밀번호, 전송 매개변수가 포함될 수 있습니다. 구독 주소는 여러 설정을 가져오는 경로로, 업데이트하면 항목이 추가·삭제되거나 변경될 수 있습니다. 구독을 정상적으로 내려받았다는 것은 설정을 가져오는 단계가 성공했다는 뜻일 뿐, 모든 설정을 사용할 수 있다는 의미는 아닙니다. 반대로 기존 설정으로 연결할 수 있어도 구독 업데이트가 반드시 되는 것은 아닙니다. 설정을 가져오는 과정과 프록시 연결을 각각 테스트하면 문제를 더 쉽게 찾을 수 있습니다.

로컬 포트와 원격 포트 구분하기

로컬 수신 포트는 브라우저나 터미널 같은 프로그램이 클라이언트에 연결할 때 사용하고, 원격 포트는 서버 측 서비스에 속합니다. 두 포트가 같아야 할 이유는 없습니다. 흔히 사용하는 로컬 SOCKS 포트는 10808이지만, 실제 값은 현재 클라이언트의 매개변수 설정에서 확인하세요. 127.0.0.1은 루프백 주소로, 서버 주소가 아닙니다. 브라우저의 로컬 프록시 설정에 원격 주소를 입력하거나 서버 설정에 로컬 포트를 입력하면 겉보기에는 비슷한 시간 초과 오류가 발생할 수 있습니다.

DNS는 도메인을 주소로 변환하고, 라우팅은 요청을 직접 연결할지 프록시로 보낼지 차단할지 결정합니다. 시스템 프록시는 해당 설정을 읽는 앱에만 영향을 주며, TUN은 가상 네트워크 인터페이스를 통해 더 많은 트래픽을 받습니다. 따라서 시스템 프록시를 켰다고 모든 프로그램이 연결되는 것은 아니며, 전체 라우팅을 선택했다고 운영체제의 모든 연결이 제어되는 것도 아닙니다. 설정을 바꿀 때마다 두 가지를 확인하세요. 요청이 클라이언트에 들어왔는지, 들어온 뒤 어떤 규칙과 일치했는지입니다.

설정하기 전에 운영체제 종류와 프로세서 아키텍처, 사용 가능한 구독 또는 전체 공유 설정을 준비하고 시스템 시간이 자동으로 동기화되는지 확인하세요. 구독 주소와 공유 링크에는 접속 인증 정보가 포함될 수 있으므로 비공개 비밀번호 관리 도구에 보관하고 공개 게시판에는 올리지 마세요. 도움을 요청할 때는 주소의 인증 정보를 가리고 프로토콜, 전송 방식, 오류가 발생한 단계를 설명하세요. 이 습관은 설정을 처음 가져올 때부터 들이는 것이 좋습니다.

클라이언트 선택: 플랫폼과 코어

데스크톱에서는 v2rayN 우선 사용

Windows, macOS, Linux 데스크톱에서는 v2rayN을 기본 클라이언트로 사용할 수 있습니다. 설치 파일을 고를 때는 먼저 운영체제, 다음으로 프로세서 아키텍처를 확인한 뒤 인터페이스 종류와 패키지 형식을 살펴보세요. 파일 크기나 이름의 길이로 최신 버전인지 판단하거나 다른 운영체제용 파일을 반복해서 압축 해제하지 마세요. 다운로드 센터에서 플랫폼별 안내를 확인하세요. 시스템에서 형식을 지원하지 않는다고 표시되면 시스템 보호 기능을 바로 끄기보다 플랫폼과 아키텍처를 먼저 다시 확인하세요.

Windows에서는 데스크톱 버전과 클래식 WPF 버전을 사용할 수 있습니다. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하고, WPF 버전은 기존 인터페이스 구성을 유지합니다. 메뉴 배치와 설정 저장 방식은 다를 수 있습니다. 처음 사용한다면 데스크톱 버전부터 시작하고, 클래식 인터페이스에 익숙하다면 사용 환경에 맞춰 WPF 버전을 선택하세요. 설정 문제를 해결하려고 두 인터페이스를 자주 오가면 메뉴 위치뿐 아니라 작업 디렉터리와 실행 조건까지 달라질 수 있어 원인을 파악하기가 더 어려워집니다.

기기 정보에 맞는 설치 파일 선택

macOS 사용자는 ‘이 Mac에 관하여’에서 칩 정보를 확인할 수 있습니다. Apple 칩으로 표시되면 Apple Silicon용을, Intel 프로세서로 표시되면 Intel용을 선택하세요. 외관이나 구입 연도만으로 추측하지 마세요. Linux 사용자는 배포판의 패키지 관리 체계를 확인한 다음 deb 또는 rpm을 선택하세요. 같은 패키지 형식 안에서도 데스크톱에서 흔히 사용하는 x64와 일부 기기에 쓰이는 arm64가 나뉠 수 있습니다. 패키지 형식과 아키텍처를 모두 맞춰야 합니다.

Android에서는 v2rayNG를 우선 사용할 수 있으며 Xray 코어를 사용합니다. v2flyNG는 V2Fly 코어를 사용하므로 해당 코어가 필요한 경우 대안으로 선택할 수 있습니다. 최신 스마트폰은 arm64를 선택하는 경우가 많지만, 기기 출시 연도는 참고 사항일 뿐입니다. 시스템 환경과 칩의 지원 범위가 기기마다 다를 수 있으니 확실하지 않으면 시스템 정보를 확인하거나 범용 버전을 선택하세요. 두 앱은 이름만 다른 동일한 앱이 아니므로 지원 필드와 메뉴 구성을 각각 확인해야 합니다. 특히 새로운 보안 방식이 둘 다 지원된다고 가정하지 마세요.

프로토콜 이름의 순위가 아니라 설정 요구 사항에 맞춰 선택

클라이언트를 고를 때는 현재 설정에 어떤 기능이 필요한지도 확인해야 합니다. 서비스 설정에서 특정 전송 방식이나 보안 필드를 사용한다면 인터페이스 취향보다 먼저 클라이언트에 포함된 코어가 이를 지원하는지 살펴보세요. ‘프로토콜은 최신일수록 좋다’는 이유로 이미 작동하는 설정을 직접 고칠 필요는 없습니다. 프로토콜, 전송 방식, 인증서, 네트워크 환경이 함께 결과에 영향을 주므로 이름만 바꾼다고 연결이 개선되지는 않습니다. 구독 사용자는 제공업체가 전달한 필드를 그대로 유지하는 편이 직접 매개변수를 추측하는 것보다 안전합니다. 호환성 문제가 있다면 오류를 기록하고 지원 범위를 확인하세요.

설정을 옮길 때는 공유 형식과 클라이언트 설정을 구분해야 합니다. 단일 공유 링크에는 원격 연결에 필요한 필드만 포함되는 경우가 많으며 라우팅, DNS, 로컬 포트, 인터페이스 설정은 들어 있지 않을 수 있습니다. 두 클라이언트가 같은 링크를 인식한다고 해서 전체 환경까지 복사된 것은 아닙니다. 이전한 뒤에는 로컬 수신 주소, 시스템 프록시 상태, 현재 활성 항목, 기본 라우팅을 다시 확인하세요. 기기만 바꾸려는 경우 새 기기에서 최소한의 연결을 먼저 구성하고 성공 여부를 확인한 다음 사용자 지정 규칙을 옮기세요.

초기 설정 단계에서는 한 기기에서 네트워크를 제어하는 클라이언트를 하나만 실행하세요. 여러 프로그램이 로컬 포트, 시스템 프록시, 가상 인터페이스를 두고 충돌하면 화면은 정상처럼 보여도 요청이 어디로 향하는지 불분명해질 수 있습니다. 테스트를 전환하기 전에 기존 프로그램의 프록시 연결을 끄고 프로그램을 종료한 뒤 새 클라이언트를 실행하세요. 여러 클라이언트를 설치해 번갈아 실행하기보다 정상 작동하는 설정 하나를 기준으로 보관하는 편이 문제 진단에 도움이 됩니다. 클라이언트 다운로드와 설정 출처도 따로 관리하세요. 설치에 성공했다고 서비스 설정까지 확보한 것은 아닙니다.

설치 및 첫 실행

쓰기 가능한 디렉터리와 실행 환경 준비

설치 전에 실행 중인 구버전 클라이언트를 종료하고 현재 로컬 포트와 시스템 프록시 상태를 기록하세요. 설치 프로그램을 사용한다면 시스템 안내에 따라 설치하고, 압축 파일을 사용한다면 완전히 압축을 푼 뒤 해당 디렉터리에서 실행하세요. 압축 프로그램의 임시 미리보기에서 바로 실행하지 마세요. 클라이언트는 코어 파일을 읽고 설정을 저장해야 하므로 읽기 전용 위치나 임시 디렉터리, 제한이 엄격한 공유 디렉터리에 두면 설정을 저장하지 못하거나 구성 요소를 찾지 못할 수 있습니다. 바탕 화면 바로가기는 실행 경로일 뿐, 실제 작업 파일이 바탕 화면에 있다는 뜻은 아닙니다.

Windows에서 실행되지 않는다면 먼저 시스템 메시지에 필요한 실행 환경이 없다고 명시되어 있는지 확인하세요. 배포 패키지에 필요한 구성 요소가 포함될 수도 있고 데스크톱 런타임을 따로 설치해야 할 수도 있으므로 설치 안내를 기준으로 판단하세요. 실행 라이브러리를 무조건 여러 번 설치하지 마세요. 클래식 WPF 인터페이스와 크로스 플랫폼 인터페이스의 실행 요구 사항도 각각 확인해야 합니다. 권한 오류가 발생하면 디렉터리에 쓸 수 있는지, 보안 소프트웨어가 파일을 격리했는지, 오류 메시지가 어디서 표시됐는지 살펴보세요. 항상 관리자 권한으로 실행하는 것을 일반적인 해결책으로 삼아서는 안 됩니다.

플랫폼별 첫 실행 확인

macOS에 설치한 뒤 앱을 적절한 응용 프로그램 디렉터리로 옮기고 그 위치에서 실행하세요. 시스템에서 실행을 차단하면 다운로드 출처와 안내 내용을 확인한 다음 시스템에서 제공하는 승인 절차를 따르세요. 앱을 실행하려고 보안 기능 전체를 끄지 마세요. 아키텍처가 호환되지 않는다는 안내가 나오면 기기 정보를 확인해 칩 유형을 살펴보세요. 업데이트하기 전에는 앱을 종료하세요. 이전 프로세스가 실행 중인 상태에서 파일을 교체하면 화면과 실제 구성 요소가 서로 다른 설치 상태를 사용할 수 있어 문제 판단이 어려워집니다.

Linux에서는 배포판에 맞는 패키지 설치 방식을 사용한 뒤 앱 메뉴나 설치된 실행 항목에서 시작하세요. 의존성 또는 그래픽 인터페이스 오류가 발생하면 패키지 관리자에서 설치가 실패한 것인지, 설치 후 실행이 실패한 것인지 먼저 구분하세요. 전자는 패키지 형식과 의존성 안내를, 후자는 그래픽 환경, 권한, 실행 출력을 확인합니다. 다른 배포판용 명령을 현재 시스템에 그대로 복사하지 마세요. 시스템 네트워크를 제어하는 권한은 해당 기능을 켤 때 필요한 만큼만 부여하고, 일반적인 설정 관리 단계에서 미리 권한을 확대하지 마세요.

Android에 설치한 뒤에는 먼저 앱을 열어 기본 화면을 확인하고 바로 연결할 필요는 없습니다. 앱 설치 허용을 요청하면 현재 신뢰할 수 있는 설치 출처에 필요한 권한만 부여하고 설치가 끝난 뒤에는 해당 출처의 설치 권한을 해제할 수 있습니다. 처음 프록시 연결을 시작할 때 표시되는 VPN 권한 요청은 로컬 네트워크 연결을 만들기 위한 별도 권한이며 설치 권한과 다릅니다. 기기에서 다른 VPN이 실행 중이라면 먼저 기존 연결을 종료하세요. 권한 요청을 반복해서 승인해도 네트워크를 제어하는 두 서비스의 충돌은 해결되지 않습니다.

코어와 로컬 수신 상태 확인

처음 실행한 뒤 매개변수 설정에서 로컬 수신 주소와 포트를 확인하고 로그에 코어 파일 누락, 설정 파싱 실패, 포트 사용 중 메시지가 있는지 살펴보세요. 원격 설정을 가져오기 전에는 일부 기능의 연결 테스트를 완료할 수 없을 수 있습니다. 이는 설치 손상이 아니라 필요한 조건이 아직 갖춰지지 않은 상태입니다. 설치 디렉터리의 구성 요소가 격리되었다면 보안 소프트웨어의 처리 내역을 먼저 확인하세요. 원인을 파악한 뒤 신뢰할 수 있는 배포 안내에 따라 복구하고, 출처가 불분명한 곳에서 같은 이름의 코어 파일을 내려받아 임의로 넣지 마세요.

기본적으로 프록시 수신 주소는 로컬 루프백으로 제한하세요. 모든 네트워크 인터페이스에 열면 같은 네트워크의 다른 기기에서도 접근할 수 있으므로 방화벽과 접근 제어를 함께 설정해야 합니다. 학습 단계에서 다른 기기와 공유할 필요가 없다면 LAN 연결 허용을 켜지 마세요. 포트가 이미 사용 중이면 해당 포트를 점유한 이전 클라이언트를 종료하거나 용도를 확인한 뒤 수신 포트를 바꾸세요. 포트를 변경했다면 앱의 프록시 주소도 함께 수정해야 합니다. 클라이언트는 새 포트를 사용하지만 브라우저가 이전 포트에 계속 연결하면 오류가 반복됩니다.

마지막으로 설치 위치, 클라이언트 종류, 수신 포트, 시작 프로그램 등록 여부, 현재 시스템 프록시 사용 여부를 기록하세요. 인증 정보는 기록하지 말고 나중에 환경을 복원할 수 있을 정도의 정보만 남기면 됩니다. 자동 실행, 자동 구독 업데이트, TUN을 한꺼번에 설정하지 마세요. 먼저 수동 실행으로 최소 설정이 작동하는지 확인한 다음 자동화 기능을 추가하세요. 그래야 문제가 생겼을 때 설치 단계의 문제인지 새로운 설정으로 네트워크 경로가 바뀐 것인지 구분할 수 있습니다.

구독 가져오기: 그룹 및 업데이트

먼저 주소 유형 확인하기

가져오기 전에 구독 주소, 단일 공유 링크, 전체 설정 파일 중 무엇을 받았는지 확인하세요. 구독 주소는 설정 목록을 가져오는 네트워크 주소입니다. 공유 링크는 보통 프로토콜 이름으로 시작하며 하나의 원격 설정을 나타냅니다. QR 코드는 텍스트를 담는 방식으로, 안에는 공유 링크나 구독 주소가 들어 있을 수 있습니다. 모든 내용을 구독 입력란에 붙여 넣거나 구독 웹페이지의 로그인 주소를 구독 주소로 사용하면 형식 오류가 발생합니다. 먼저 내용의 용도를 확인한 뒤 알맞은 가져오기 메뉴를 선택하세요.

v2rayN에서 구독 그룹 설정을 열고 용도를 쉽게 알아볼 수 있는 그룹 이름을 추가한 다음 전체 구독 주소를 주소 입력란에 붙여 넣고 저장하세요. 복사하면서 주소 앞뒤에 들어간 공백이나 줄 바꿈은 제거하되 쿼리 매개변수는 임의로 삭제하지 마세요. 인증 정보로 사용될 수 있습니다. 그룹 이름은 로컬에서 관리하기 위한 표시일 뿐 원격 설정을 바꾸지 않으며 업데이트 완료를 의미하지도 않습니다. 그룹을 저장한 뒤 업데이트를 실행해야 클라이언트가 실제 서버 항목을 가져옵니다.

올바른 업데이트 방식 선택하기

처음 설정하는 중이고 아직 프록시를 사용할 수 없다면 ‘현재 구독 업데이트(프록시 사용 안 함)’와 같은 메뉴를 먼저 시도하세요. 아직 연결되지 않은 프록시에 구독 요청이 의존하는 상황을 피할 수 있습니다. 구독 제공업체가 프록시를 통한 접속을 요구한다면 먼저 사용할 수 있는 설정 하나를 확인한 다음 프록시를 사용하는 업데이트 방식을 선택하세요. 어느 방식이 더 낫다고 정해져 있는 것은 아니며 현재 네트워크에서 구독 서버에 접속할 수 있는지가 중요합니다. 업데이트에 실패하면 오류를 읽고 주소 조회 실패, 연결 시간 초과, 인증 실패, 응답 내용 파싱 실패를 구분하세요.

업데이트한 뒤 목록에 현재 그룹의 항목이 표시되는지 확인하고 검색 조건이나 그룹 필터로 숨겨져 있지 않은지도 살펴보세요. 목록이 계속 비어 있다면 업데이트 로그를 확인한 다음 주소가 구독 콘텐츠를 반환하는지 점검하세요. 일부 주소는 브라우저에서 열면 로그인 페이지, 구독 만료 안내, 일반 웹페이지를 표시합니다. 정상적으로 내려받았더라도 유효한 설정이 아닐 수 있습니다. 인증 정보가 포함된 구독 내용을 공개 변환 사이트에 올리지 마세요. 형식을 알 수 없다면 제공업체에 지원하는 클라이언트와 내보내기 방식을 문의하세요.

클립보드, QR 코드, 인코딩 콘텐츠 가져오기

v2rayNG에서는 작업 메뉴를 통해 클립보드의 공유 내용을 가져오거나 QR 코드를 스캔할 수 있습니다. 스캔하기 전에 이미지 출처를 확인하고, 가져온 뒤 프로토콜과 보안 필드가 모두 있는지 살펴보세요. 구독 주소를 받았다면 서버 항목 하나로만 가져오지 말고 구독 그룹 설정에서 저장한 다음 업데이트하세요. 카메라 권한은 QR 코드를 스캔할 때만 허용하세요. 이미 텍스트가 있다면 클립보드 메뉴가 더 간편합니다. 가져온 뒤 사용할 설정을 선택하고 연결에 필요한 VPN 권한을 허용해야 합니다. 목록에 항목이 나타나는 것만으로는 연결 설정이 끝난 것이 아닙니다.

일부 구독은 여러 공유 링크를 Base64로 인코딩해 전달합니다. 인코딩은 암호화가 아니며 내용을 공개해도 된다는 뜻도 아닙니다. 클라이언트는 대개 구독을 업데이트할 때 지원되는 형식을 처리하므로 직접 디코딩할 필요는 없습니다. 응답이 다른 구조의 설정 파일이라면 Base64로 변환하는 것만으로 호환되지 않습니다. 가져오기 방식별 차이를 자세히 알아보려면 구독 그룹, 클립보드, QR 코드로 가져오기를 참고하고 콘텐츠 유형에 맞춰 확인하세요.

수동 수정 사항이 업데이트로 덮어쓰이지 않도록 하기

구독 항목은 다음 업데이트 때 다시 생성될 수 있으므로 오래 유지해야 하는 사용자 지정 변경 사항을 구독 항목에만 저장하지 마세요. 설정을 조정하려면 클라이언트에서 독립 항목으로 복사할 수 있는지 확인하거나 별도 그룹에서 관리하고, 변경 목적과 기존 필드를 기록하세요. 구독이 자주 업데이트된다면 표시 이름만 보고 같은 설정인지 판단하지 마세요. 프로토콜, 주소, 주요 매개변수를 함께 확인해야 합니다. 이름이 바뀌어도 서비스가 달라진 것은 아닐 수 있고, 이름이 그대로여도 내부 필드가 유지된다는 보장은 없습니다.

자동 업데이트는 수동 업데이트가 안정적으로 작동한 뒤에 켜고 실제 사용 방식에 맞는 간격을 설정하세요. 업데이트가 실패해도 사용 가능한 기존 설정을 유지하고 그룹 전체를 바로 삭제해 다시 만들지 마세요. 원격에서 권한이 취소되었거나 서비스가 만료됐다면 로컬 업데이트 방식을 바꿔도 접속이 복구되지 않으므로 구독 상태를 확인해야 합니다. 기기를 옮길 때는 그룹과 필요한 설정을 먼저 옮긴 뒤 직접 업데이트해 확인하세요. 출처가 불분명한 오래된 목록을 그대로 복사하면 만료된 설정까지 새 환경으로 가져올 수 있습니다.

시스템 프록시: 연결 및 확인

코어를 실행한 다음 앱 연결하기

구독을 가져온 뒤 사용할 설정을 선택해 활성 항목으로 지정하고 코어가 실행 중인지 확인하세요. 다음으로 시스템 프록시 자동 설정을 선택하면 시스템 프록시를 읽는 앱의 요청이 로컬 수신 지점으로 전달됩니다. 메뉴의 ‘시스템 프록시 지우기’는 보통 운영체제의 프록시 설정을 제거하는 기능이지 코어를 반드시 중지하는 기능은 아닙니다. ‘시스템 프록시를 변경하지 않음’은 대개 현재 시스템 상태를 그대로 둔다는 의미이며 프록시를 끄는 것과 같지 않습니다. 이름만 보고 기능을 추측하지 말고 현재 클라이언트의 설명을 확인하세요.

Windows와 macOS의 많은 브라우저는 시스템 프록시를 따르지만 브라우저 확장, 사용자 지정 실행 매개변수, 기업 정책이 이를 덮어쓸 수 있습니다. Linux에서는 데스크톱 환경과 앱마다 시스템 프록시를 읽는 방식이 달라 앱에 로컬 주소를 직접 입력해야 할 수도 있습니다. 터미널 프로그램은 데스크톱 프록시 설정을 따르지 않는 경우가 많습니다. 따라서 브라우저에서 웹사이트에 접속된다고 명령줄 프로그램도 같은 경로를 이용한다는 뜻은 아닙니다. 터미널에서 접속되지 않아도 시스템 프록시가 작동하지 않는다고 바로 단정할 수 없습니다.

연결 방식과 라우팅 방식 구분하기

시스템 프록시는 ‘요청을 어떻게 클라이언트로 보낼지’를 정하고, 라우팅은 ‘클라이언트에 들어온 요청을 어디로 보낼지’를 정합니다. 흔히 말하는 전체 프록시 라우팅은 코어에 들어온 요청을 프록시 출구로 보내는 방식이지 기기의 모든 프로그램을 강제로 제어하는 것은 아닙니다. 직접 연결 규칙도 로컬 코어를 거친 뒤 출구만 직접 연결로 선택할 수 있습니다. PAC는 규칙 스크립트가 앱의 프록시 사용 여부를 결정하므로 연결 단계에서 적용되며 코어 내부의 라우팅과 혼동해서는 안 됩니다. 문제를 진단할 때는 명확한 연결 방식을 하나만 사용하세요.

Android에서 v2rayNG는 보통 로컬 VPN 인터페이스로 앱 트래픽을 전달하며 앱별 프록시 설정도 제공할 수 있습니다. 앱을 포함하거나 제외하는 옵션의 의미는 현재 모드에 따라 다릅니다. 목록에 앱 이름이 있다고 해서 해당 앱이 프록시로 연결된다고 단정하지 마세요. 별도의 프록시 설정이 없는 일반 앱 하나로 먼저 확인한 뒤 다른 앱으로 범위를 넓히세요. 브라우저를 테스트할 때는 프록시 확장을 잠시 꺼서 설정이 겹치지 않도록 하세요.

한 웹페이지에만 의존하지 말고 단계별로 확인하기

첫째, 코어 로그에 시작 오류가 없는지 확인합니다. 둘째, 로컬 포트가 실제로 수신 중인지 확인합니다. 셋째, 프록시를 지원하는 프로그램 하나로 요청을 보냅니다. 넷째, 대상 앱이 시스템 프록시 설정을 사용하는지 확인합니다. 아래 명령으로 SOCKS 주소를 직접 지정할 수 있으며, 포트는 매개변수 설정에 표시된 실제 값으로 바꾸세요. 여기서 socks5h는 대상 도메인 조회를 프록시 측에서 처리하므로 로컬 DNS 문제와 프록시 연결 문제를 구분하는 데 유용합니다. 다만 이것만으로 시스템 프록시 설정이 올바르다고 확인할 수는 없습니다.

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --head https://example.com/

명령이 적절한 HTTP 응답을 반환하면 해당 요청에서 필요한 연결 절차는 적어도 진행된 것입니다. 대상 웹사이트가 리디렉션하거나 접속을 거부할 수도 있으므로 성공 상태 코드만 진단에 의미가 있는 것은 아닙니다. 로컬 포트에 연결하지 못했다는 메시지가 바로 나오면 코어와 수신 주소를 확인하세요. 로컬 진입점에 연결된 뒤 핸드셰이크 오류가 발생한다면 원격 설정과 시간을 살펴보세요. 테스트 대상 자체가 작동하지 않을 수도 있으므로 필요하다면 정상 작동이 확인된 다른 대상으로 교차 확인하고 웹사이트 오류를 전체 프록시 연결 오류로 오해하지 마세요.

정상 종료 및 원상 복구 순서 확인하기

클라이언트를 종료하기 전에 시스템 프록시를 지우거나 기존 시스템 설정을 복원한 다음 프로그램을 종료하세요. 그러지 않으면 시스템이 더 이상 수신하지 않는 로컬 포트를 계속 가리켜 브라우저에서 인터넷에 접속할 수 없게 될 수 있습니다. 시스템 절전, 비정상 종료, 프로세스 강제 종료 뒤에도 이 설정을 확인하세요. 기존 시스템 프록시가 회사 네트워크나 다른 관리 프로그램에서 설정한 것이라면 원래 값을 기록하고 무조건 삭제하지 마세요. 새 설정을 더하기보다 먼저 연결을 복구하는 것이 중요합니다. 필요하면 직접 연결 상태로 되돌린 뒤 최소 연결 흐름을 단계별로 다시 구성하세요.

프록시를 명시한 명령은 작동하지만 브라우저에서 작동하지 않는다면 브라우저 확장, 별도 프록시 설정, 이전 연결 캐시를 확인하세요. 브라우저는 작동하지만 터미널에서 안 된다면 터미널 환경 변수와 프로그램 자체의 프록시 매개변수를 살펴보세요. 두 문제는 각각 진단할 수 있으므로 바로 클라이언트를 재설치할 필요는 없습니다. 자세한 내용은 브라우저와 터미널에서 시스템 프록시가 작동하지 않을 때를 참고하세요. 테스트 대상, 연결 방식, 오류 발생 단계를 기록해 ‘된다’ 또는 ‘안 된다’는 모호한 결론만 남기지 마세요.

라우팅: 규칙 및 DNS

기본 출구와 규칙 순서부터 정하기

라우팅은 요청이 코어에 들어온 뒤 도메인, 주소, 포트, 프로토콜 등의 조건에 따라 출구를 선택하는 기능입니다. 설정을 시작하기 전에 규칙과 일치하지 않는 요청이 어느 출구로 나갈지 정하고 필요한 규칙 몇 개만 추가하세요. 흔히 LAN 주소는 직접 연결하고 특정 도메인은 프록시로 보내며 나머지는 기본 정책에 맡깁니다. 규칙이 많다고 더 정확해지는 것은 아닙니다. 중복 규칙이나 지나치게 넓은 조건, 출처를 알 수 없는 규칙 목록은 결과를 이해하기 어렵게 만듭니다. 규칙을 추가할 때마다 어떤 요청과 일치하는지, 왜 해당 위치에 두는지 설명할 수 있어야 합니다.

많은 코어는 규칙을 순서대로 확인하므로 먼저 일치하는 규칙이 출구를 결정합니다. 범위가 좁고 명확한 예외를 더 넓은 규칙보다 앞에 두세요. 예를 들어 특정 도메인은 프록시로 보내야 하지만 더 넓은 도메인 목록이 직접 연결로 설정되어 있다면 두 규칙의 순서를 확인해야 합니다. 사설 네트워크 주소를 직접 연결하면 라우터, 프린터, 파일 서버에 접속할 때 요청이 원격 서버를 거치는 일을 피할 수 있습니다. 하지만 이것만으로 모든 내부 이름이 올바르게 조회되는 것은 아닙니다. 이름 조회와 주소 라우팅을 각각 확인해야 하며 규칙 하나로 두 문제가 모두 해결됐다고 가정해서는 안 됩니다.

규칙 예시를 살펴보고 전체 설정 덮어쓰기 피하기

다음은 Xray 라우팅 객체의 구조를 보여주는 예시입니다. 먼저 사설 주소는 직접 연결하고, 예시 도메인과 하위 도메인은 프록시로 보냅니다. 전체 설정이 아니므로 direct와 proxy는 현재 설정에 실제로 존재하는 출구 태그로 바꿔야 합니다. geoip:private가 작동하려면 해당 주소 데이터도 사용할 수 있어야 합니다. 그래픽 클라이언트는 대개 전체 설정을 생성하므로 이 조각으로 설정 파일 전체를 덮어쓰지 마세요. 인터페이스의 규칙 편집기를 사용하는 경우 같은 의도를 해당 규칙 항목으로 구성하세요.

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

이 예시의 주소 규칙은 일치시킬 주소 조건이 있을 때만 적용됩니다. 요청에 도메인만 포함되어 있고 현재 도메인 정책에서 일치 여부를 판단하기 위해 주소를 조회하지 않는다면 ‘사설 주소로 해석되는 모든 도메인이 이 규칙에 걸린다’고 볼 수 없습니다. 도메인 규칙이 작동하려면 코어가 도메인 정보를 받아야 합니다. 앱이 주소만 전달하면 원래 도메인 이름을 알 수 없을 수도 있습니다. 일부 트래픽은 스니핑으로 도메인 정보를 보완할 수 있지만 암호화된 트래픽을 모두 식별하지는 못하므로 항상 규칙에 일치시키는 만능 기능으로 생각해서는 안 됩니다.

DNS를 별도의 경로로 이해하기

DNS를 설정할 때는 앱이 어디에서 이름을 조회하는지, 클라이언트가 어떤 리졸버를 사용하는지, DNS 요청 자체가 어떤 출구를 이용하는지 각각 확인하세요. 앱이 암호화 DNS를 직접 사용하면 시스템 리졸버를 우회할 수 있습니다. SOCKS 요청을 명시할 때도 로컬에서 조회할지 프록시 측에서 조회할지 선택할 수 있습니다. 코어의 DNS 설정이 시스템에 있는 모든 프로그램의 조회를 제어하는 것은 아닙니다. 도메인은 열리지 않지만 직접 입력한 주소로는 접속된다면 원격 포트를 바꾸기 전에 조회 결과와 DNS 요청 경로를 확인하세요. 조회 경로에 따라 다른 주소가 반환되면 이후 라우팅 규칙도 달라질 수 있습니다.

DNS 리졸버와 프록시 연결이 서로를 기다리는 순환 의존을 피하세요. 원격 서버에 연결하려면 먼저 서버 도메인을 조회해야 하는데 그 조회 요청을 아직 연결되지 않은 동일한 연결로 보내도록 설정하면 시작 단계에서 멈출 수 있습니다. 초기 도메인 조회에 사용할 수 있는 경로를 남기고 서버 도메인의 조회 방식을 확인하세요. 조회 정책을 바꾼 뒤에도 앱, 운영체제, 코어가 각각 캐시를 보유할 수 있습니다. 기존 설정을 기록한 다음 관련 부분을 따로 비우거나 다시 시작하고 새 연결을 테스트하세요. 이전 캐시 때문에 새 규칙이 적용되지 않은 것처럼 보이는 일을 피할 수 있습니다.

라우팅 결과를 규칙별로 확인하기

규칙을 테스트할 때는 대상을 하나 정하고 앱이 도메인을 전달하는지, 어떤 조건이 규칙에 지정되어 있는지, 최종 출구가 무엇인지 기록하세요. 로그에서 일치한 규칙을 확인할 수 있다면 테스트하는 동안만 로그 수준을 높이고 테스트가 끝나면 원래대로 되돌리세요. 접속 성공만으로 판단하지 마세요. 직접 연결과 프록시 모두 성공할 수 있습니다. 반대로 프록시 출구가 대상 서비스에 의해 제한되어도 규칙이 일치하지 않은 것은 아닐 수 있습니다. 먼저 트래픽이 코어에 들어왔는지 확인하고, 다음으로 규칙이 예상 출구를 선택했는지, 마지막으로 대상 응답을 확인하면 라우팅 문제와 서비스 문제를 구분할 수 있습니다.

TUN 모드: 트래픽 연결 및 복구

더 넓은 범위의 연결이 필요한지 확인하기

TUN은 가상 네트워크 인터페이스로 시스템 트래픽을 받아 해당 처리 구성 요소에 전달합니다. 시스템 프록시를 읽지 않고 별도의 프록시 설정도 지원하지 않는 앱에서 유용하지만 모든 시간 초과 오류를 해결하는 빠른 방법은 아닙니다. 로컬 프록시를 직접 지정한 테스트에서 원격 연결이 되지 않는다면 TUN을 켜도 같은 오류가 더 많은 앱에 영향을 줄 가능성이 큽니다. 먼저 일반 프록시 모드에서 원격 설정, DNS, 라우팅을 확인한 뒤 이 장의 안내에 따라 설정하세요. 그래야 새 문제가 기존 문제와 섞이지 않고 트래픽 연결 단계에서 비롯됐는지 판단할 수 있습니다.

플랫폼과 클라이언트 빌드, 선택한 구성 요소에 따라 TUN 구현 방식이 다를 수 있으며 메뉴 이름, 네트워크 스택 옵션, 권한도 같지 않을 수 있습니다. 화면 캡처와 똑같은 스위치를 찾거나 특정 프록시 코어를 선택하면 모든 트래픽 제어 기능이 자동으로 제공된다고 가정하지 마세요. 현재 인터페이스의 기능 설명과 시작 로그, 필요한 구성 요소 안내를 확인하세요. Android의 로컬 VPN 인터페이스와 데스크톱의 TUN 설정은 사용 방식이 비슷해 보일 수 있지만 권한 모델과 선택 가능한 매개변수는 그대로 비교할 수 없습니다.

기본 네트워크 상태를 기록하고 하나씩 활성화하기

TUN을 켜기 전에 현재 활성 네트워크 어댑터, 시스템 DNS, 다른 VPN 사용 여부, 클라이언트의 현재 연결 방식을 기록하세요. 라우팅을 변경하는 다른 프로그램을 종료해 중복 연결 제어를 잠시 중지한 다음 TUN을 켜고 시스템 안내에 따라 필요한 권한을 허용하세요. 실행 실패를 모두 권한 부족 탓으로 돌리지 마세요. 로그에 표시되는 인터페이스 생성 실패, 경로 추가 실패, 포트 사용 중, 설정 미지원은 서로 다른 문제입니다. 오류가 권한 문제를 명확히 가리킬 때만 현재 플랫폼에 필요한 범위로 권한을 조정하세요.

기본 네트워크 스택과 매개변수는 그대로 두고 최대 전송 단위, 엄격한 라우팅, DNS 가로채기 같은 고급 옵션을 동시에 바꾸지 마세요. 일반 웹페이지부터 테스트하고, 이전에 시스템 프록시를 사용하지 않던 앱을 확인한 뒤 LAN 기기 연결과 절전 모드 복귀를 테스트할 수 있습니다. 웹페이지는 열리는데 특정 실시간 앱이 작동하지 않는다면 먼저 원격 프로토콜과 출구가 해당 트래픽을 지원하는지 확인한 뒤 UDP 경로와 앱 제한을 살펴보세요. TUN이 데이터를 받는다고 해서 원격 서버가 모든 전송 방식을 전달할 수 있거나 전달해 준다는 뜻은 아닙니다.

순환 경로, DNS, LAN 연결 확인하기

모든 경로를 TUN으로 연결할 때는 원격 서버에 연결하는 클라이언트 자체의 트래픽이 같은 가상 인터페이스로 되돌아가지 않도록 해야 합니다. 그렇지 않으면 순환 경로가 생길 수 있습니다. 일반적인 구현은 이를 처리하지만 사용자 지정 라우팅, 여러 트래픽 제어 프로그램, 수동 네트워크 어댑터 설정으로 문제가 생길 수 있습니다. 코어는 정상적으로 시작되지만 트래픽 제어를 켠 직후 연결이 끊긴다면 TUN을 끄고 기본 프록시가 복구되는지 확인한 다음 원격 연결이 잘못 가로채지고 있는지 살펴보세요. 시스템 라우팅 테이블의 모든 항목을 바로 삭제하지 마세요.

DNS 트래픽 제어와 FakeDNS도 별개의 기능으로 이해해야 합니다. DNS 트래픽 제어는 조회 요청을 지정된 경로로 보내고, FakeDNS는 가상 주소를 반환하면서 도메인과의 매핑을 관리합니다. 두 기능을 함께 사용할 수는 있지만 같은 스위치는 아닙니다. 가상 매핑을 켠 상태에서 일부 앱이 해당 처리 경로를 우회하면 직접 접속할 수 없는 가상 주소를 받을 수 있습니다. 기업 내부 도메인, LAN 기기 검색, 자체 DNS 기능을 사용하는 앱은 특히 따로 확인하세요. 명확한 요구 사항이 없다면 일반 DNS를 유지해 설정 동작을 파악하기 쉽게 하세요.

종료 테스트까지 포함해 활성화 확인하기

활성화에 성공한 뒤에도 기능 끄기, 클라이언트 종료, 네트워크 전환, 절전 모드 복귀를 테스트하세요. 비활성화한 뒤 가상 인터페이스와 관련된 경로 및 DNS 설정이 복구되고 일반 네트워크를 사용할 수 있는지 확인해야 합니다. 종료 후에도 연결되지 않으면 시스템에 로컬 프록시 설정이 남아 있는지 먼저 확인하고 활성 네트워크 인터페이스와 리졸버를 살펴보세요. 기본적인 문제 상황을 기록한 뒤 운영체제의 정상적인 네트워크 재연결 절차를 이용해 복구하세요. 용도를 모르는 상태에서 네트워크 어댑터를 일괄 삭제하거나 방화벽 설정을 모두 지우지 마세요.

트래픽 연결, 라우팅, LAN, 종료 후 복구까지 모두 확인한 뒤에만 부팅 시 자동 실행을 고려하세요. 자동 실행은 네트워크가 아직 준비되지 않았거나 시스템 권한을 아직 허용하지 않은 상황도 고려해야 합니다. 로그인 후 수동으로 실행하는 경우만 테스트해서는 부족합니다. 설정에 문제가 생겼을 때 가장 확실한 복구 방법은 TUN을 끄고 기존 시스템 프록시와 DNS를 복원한 다음, 작동 여부를 확인한 일반 프록시 설정으로 계속 진단하는 것입니다. 고급 기능은 명확한 필요를 충족하는 데 의미가 있으며 모든 스위치를 켜 두는 것이 목표는 아닙니다.

일상 관리: 백업 및 문제 해결

복구 가능한 설정 상태 저장하기

일상 관리는 업데이트가 아니라 백업부터 시작해야 합니다. 클라이언트의 내보내기 또는 백업 기능을 먼저 사용하고 서버 항목, 구독 그룹, 라우팅 규칙, DNS, 인터페이스 설정이 각각 포함되는지 확인하세요. 설정 디렉터리를 복사해야 한다면 클라이언트를 종료해 데이터 쓰기가 끝난 뒤 진행하세요. 실제 디렉터리는 설치 방식에 따라 다를 수 있으므로 모든 플랫폼의 저장 위치가 같다고 가정하지 마세요. 백업에는 플랫폼, 인터페이스 종류, 당시 사용할 수 있었던 기능 범위를 간단히 기록해 두세요.

백업에는 구독 인증 정보, 서버 비밀번호, 개인 도메인이 포함될 수 있으므로 접근 제어가 가능한 로컬 저장소나 신뢰할 수 있는 암호화 저장소에 보관하세요. 도움 요청에 사용하는 설정과 복구용 전체 백업은 분리해야 합니다. 전자는 민감한 정보를 삭제하고 후자는 복구에 필요한 필드를 유지하세요. 화면 캡처만 백업하면 숨겨진 필드와 규칙 순서를 복원할 수 없는 경우가 많습니다. 업데이트 전에는 정상 작동이 확인된 설정을 하나 이상 보관하고 복구 메뉴를 찾을 수 있는지 확인하세요. 업데이트에 실패한 뒤에야 이전 데이터를 찾기 시작하지 마세요.

클라이언트, 코어, 규칙 데이터를 따로 업데이트하기

클라이언트 업데이트는 그래픽 인터페이스와 관리 방식을 바꾸고, 코어 업데이트는 프로토콜 처리 기능을 바꾸며, 라우팅 데이터 업데이트는 규칙 집합의 일치 범위를 바꿉니다. 세 가지를 같은 작업으로 취급해서는 안 됩니다. 한 번에 한 종류의 구성 요소만 업데이트하세요. 업데이트 후에는 실행, 구독 업데이트, 일반 연결, 종료 후 복구를 확인한 다음 다음 항목을 진행하세요. 안정적으로 작동하던 연결에 갑자기 문제가 생기면 가장 최근에 바뀐 계층부터 확인하세요. 기록 없이 반복해서 재설치하는 것보다 설정 변경 내역을 남기는 편이 도움이 됩니다. 재설치해도 이전 설정이 남거나 문제 상황이 사라질 수 있어 원인을 파악하지 못할 수도 있습니다.

버전 변경으로 일부 필드가 더 이상 사용되지 않거나 기본 동작이 달라질 수 있으므로 업데이트 뒤 로그에서 설정 호환성 안내를 확인하세요. 전체 사용자 지정 설정은 인터페이스의 설정 생성 과정을 우회할 수 있으므로 새 인터페이스 옵션이 사용자 지정 파일에 자동으로 반영될 것이라고 기대하지 마세요. 이전 버전으로 되돌려야 한다면 기존 설정과 호환되는 복구 방식을 사용하고 여러 프로그램이 같은 데이터 디렉터리를 동시에 수정하지 않도록 하세요. 설정 데이터베이스를 마이그레이션한 뒤에는 이전 프로그램이 그대로 읽지 못할 수도 있으므로 변경 전에 백업해야 합니다.

오류가 발생한 단계를 기준으로 로그 읽기

문제를 진단할 때는 오류가 어떤 동작 직후 발생했는지 먼저 기록하세요. 프로그램 실행 실패, 코어 시작 실패, 구독 다운로드 실패, 앱 요청 실패는 각각 확인할 부분이 다릅니다. 프로그램 실행 문제는 실행 환경과 디렉터리 권한을, 코어 시작 문제는 필드와 구성 요소, 포트를 확인하세요. 구독 문제는 주소와 가져오기 경로를 살펴보고 요청 문제는 DNS, 원격 핸드셰이크, 라우팅을 점검합니다. ‘연결 실패’라고만 하는 것보다 오류 원문을 남기는 편이 유용합니다. 로그에는 주소와 사용자 정보가 포함될 수 있으므로 공유 전에 내용을 확인하고 민감한 부분을 가리세요. 작업 디렉터리 전체를 그대로 올리지 마세요.

노드 시간 초과는 시스템 시간, 로컬 수신, 네트워크 연결 가능 여부, 전송 매개변수를 차례로 확인하세요. 시스템 시간 오차는 인증서와 핸드셰이크에 영향을 줄 수 있고, 포트를 다른 프로세스가 사용 중이면 앱이 의도한 프로세스에 연결하지 못할 수 있습니다. 서버 포트에 도달할 수 없는 문제는 또 다른 계층에서 발생합니다. TLS 오류가 있다면 서버 이름, 인증서 상태, 보안 매개변수를 다시 확인하고 인증 검증을 끄는 방법을 계속 사용하지 마세요. 자세한 순서는 시스템 시간, 포트, TLS 핸드셰이크 문제 해결에서 확인하세요. 설정을 바꿀 때마다 요청을 새로 보내 테스트해야 합니다.

테스트 조건을 일관되게 유지하기

변경 전후를 비교할 때는 가능한 한 같은 앱, 대상, 네트워크 연결 방식을 사용하세요. 설정을 바꿔도 이전 연결이 기존 세션을 계속 사용할 수 있으므로 필요하면 테스트 앱을 닫거나 연결을 종료한 뒤 새 요청을 보내세요. 절전 모드, 유선에서 무선으로의 전환, 웹 로그인 인증이 필요한 네트워크 접속은 네트워크 조건을 바꿀 수 있습니다. 현재 네트워크에서 아직 로그인하지 않았다면 기존 프록시 설정을 복원하고 정상적으로 네트워크에 접속한 다음 클라이언트를 켜세요. 네트워크 인증 페이지를 구독 응답이나 대상 사이트 응답으로 오해하지 않도록 주의하세요.

평소에는 기본 또는 적절한 로그 수준을 사용하고 문제가 재현될 때만 잠시 상세 수준을 높이세요. 로그가 지나치게 많으면 저장 공간을 차지할 뿐 아니라 접근 관련 메타데이터가 더 많이 노출될 수 있습니다. 문제가 해결되면 원래 로그 수준으로 되돌리고 필요에 따라 오래된 기록을 정리하세요. 구독이 여전히 유효한지, 백업을 읽을 수 있는지, 시스템 프록시를 정상적으로 종료할 수 있는지 주기적으로 확인하면 충분합니다. 안정적으로 작동하는 설정을 매일 바꿀 필요는 없습니다. 유지 관리의 목적은 예기치 않은 변화를 줄이고 다음 문제에 대비해 비교 기준과 실행 가능한 복구 경로를 확보하는 것입니다.

고급 설정 경로: 확인부터 사용자 지정까지

먼저 필드 간 제약 조건 이해하기

앞 장의 내용을 익힌 뒤에는 더 많은 스위치를 찾기보다 설정 사이의 제약 관계를 이해하는 데 집중하세요. 정상 작동이 확인된 설정 하나를 기준으로 프로토콜, 전송, 보안, 라우팅 필드가 코어 설정에 어떻게 나타나는지 각각 살펴볼 수 있습니다. 이해할 수 있는 부분부터 읽고 사용자 식별자, 비밀번호, 공개 키 등 원격 서비스가 결정하는 정보는 서둘러 바꾸지 마세요. 설정 문법을 익히는 것과 실제 인증 정보를 수정하는 것은 다른 일입니다. 문법 연습에는 민감한 정보를 지운 예시를 사용하고, 실제 인증 정보를 다룰 때는 연동되는 서버 정보가 필요합니다.

프로토콜을 살펴볼 때는 필요한 인증 필드, 데이터 전달 방식, 함께 사용할 수 있는 보안 메커니즘, 현재 코어의 지원 여부를 먼저 확인하세요. 프로토콜 이름이 새것인지 오래됐는지만으로 호환성을 판단하지 마세요. 예를 들어 REALITY 설정의 서버 이름, 공개 키, 짧은 식별자는 서버 측 요구 사항과 일치해야 합니다. 클라이언트에서 임의로 새 값을 만들더라도 기존 서버가 이를 자동으로 받아들이지는 않습니다. 일부 필드에 여러 값을 입력할 수 있어도 모든 조합이 유효한 것은 아닙니다. 제공업체 안내를 항목별로 확인하고 정상 작동하는 기존 설정을 비교 기준으로 보관하세요.

구체적인 질문에 답할 수 있는 작은 실험 설계하기

실험을 시작하기 전에 ‘이 터미널은 시스템 프록시를 읽지 않는다’처럼 가설을 세우고 조건 하나만 바꿔 테스트하세요. 먼저 직접 연결을 시도하고, 다음으로 로컬 진입점을 명시한 뒤, 마지막에 환경 변수를 확인합니다. 직접 지정한 진입점은 작동하지만 기본 요청이 실패한다면 앱 연결부터 점검하고 라우팅과 DNS를 동시에 바꿀 필요는 없습니다. 실험 결과에는 웹페이지가 열렸는지만 적지 말고 요청 경로, 오류가 발생한 단계, 예상 출구를 기록하세요. 이런 기록을 쌓으면 복잡한 설정을 복사하는 것보다 다른 환경에도 적용할 수 있는 판단 능력을 기를 수 있습니다.

라우팅 실험은 예시 도메인 하나에 규칙을 적용해 일치 여부와 출구를 확인한 다음 도메인 목록과 주소 목록으로 범위를 넓히세요. DNS 실험에서는 앱의 로컬 조회와 프록시 측 조회를 비교하고 캐시로 인한 영향을 고려해야 합니다. TUN 실험에는 LAN 접속, 네트워크 전환, 종료 후 복구 테스트를 추가하세요. 이전 실험을 이해하기 전에 다음 실험을 시작하지 않도록 각 단계의 복구 지점을 따로 보관하세요. 결과가 가설과 다르면 현상을 기록하고 변수를 줄이세요. 겉으로 접속만 되게 하려고 임시 조치를 계속 추가하지 마세요.

설정 문법과 생성 방식 이해하기

JSON 예시에서 큰따옴표, 쉼표, 괄호는 문법에 해당하고 문자열 안의 필드 이름은 각 구성 요소가 정한 설정 규칙입니다. 표준 JSON은 주석과 마지막 항목 뒤의 불필요한 쉼표를 허용하지 않습니다. 온라인에서 읽기 쉽도록 주석을 넣은 예시는 코어에 바로 적용되지 않을 수 있습니다. 설정을 파싱할 수 있다는 것은 문법이 올바르다는 뜻일 뿐, 필드 조합이 의미상 맞거나 원격 서비스가 작동한다는 보장은 아닙니다. 오류가 발생하면 문법 오류, 알 수 없는 필드, 누락된 출구 태그, 연결 오류를 구분한 뒤 해당 부분을 수정하세요.

그래픽 클라이언트는 보통 인터페이스 설정을 바탕으로 실행용 설정을 생성합니다. 생성된 파일을 직접 수정하면 다음 실행이나 항목 전환 때 변경 사항이 덮어써질 수 있습니다. 오랫동안 사용자 지정 설정을 유지하려면 클라이언트가 제공하는 규칙, 사용자 지정 조각, 전체 설정 입력 기능이 각각 어느 단계에 적용되는지 먼저 확인하세요. 필요한 부분만 최소한으로 사용자 지정하고 생성 설정 전체를 장기 관리 파일로 복사하지 않는 것이 좋습니다. 전체 사용자 지정 설정을 사용하면 필드 호환성, 출구 참조, 업데이트 대응을 직접 관리해야 합니다. 이 책임과 변경 사항이 적용되는 위치를 명확히 이해한 뒤 사용하세요.

설계에 보안 경계 포함하기

프록시 연결은 특정 경로의 전송을 보호하는 기능이지 모든 접속 활동을 자동으로 익명화하는 기능은 아닙니다. 대상 웹사이트의 계정 로그인, 브라우저 저장 정보, 앱의 텔레메트리, 원격 서비스의 접속 기록에는 각각 별도의 보안 경계가 있습니다. 구독과 공유 링크 역시 민감한 정보이므로 사용하지 않는 사본은 정기적으로 정리하고 유출이 의심되면 서비스 제공업체가 지원하는 방법으로 인증을 갱신하세요. LAN 수신이나 원격 관리를 열기 전에 누가 접속할 수 있는지, 접근을 어떻게 제한할지, 종료 후 진입점이 멈췄는지 어떻게 확인할지 정하세요.

인증서 오류 하나를 피하려고 보안 검증을 계속 끄지 마세요. 출처를 알 수 없는 전체 설정에서 설명할 수 없는 리졸버, 규칙, 관리 인터페이스를 그대로 가져오는 것도 피해야 합니다. 연결 성공은 최소한의 확인 조건입니다. 관리하기 좋은 설정은 출처가 명확하고 동작을 설명할 수 있으며 권한이 적절하고 종료 후 복구할 수 있어야 합니다. 업무용 기기나 관리 대상 네트워크를 사용한다면 기기 및 네트워크 관리 정책을 먼저 따르세요. 전체 라우팅, 시스템 서비스, 방화벽을 변경할 때는 특히 기존 상태를 기록하고 권한 범위를 확인해야 합니다.

다음 내용을 한 문장으로 설명할 수 있는지 확인해 보세요. 특정 앱이 어떤 경로로 연결되고, 로컬에서 어떤 구성 요소가 처리하며, 도메인은 어디에서 조회되고, 어떤 규칙이 출구를 결정하는지, 원격 서버에 어떤 매개변수가 필요한지, 실패하면 어떻게 복구하는지 말입니다. 각 항목을 설명할 수 있게 된 뒤 복잡한 라우팅, 가상 주소 매핑, 세부 앱별 트래픽 제어를 익히면 탄탄한 기초를 갖출 수 있습니다. 단순하고 검증 가능하며 복구할 수 있는 설정을 항상 보관하세요. 고급 설정은 선택해서 쓰는 도구이지 반드시 의존해야 하는 블랙박스가 아닙니다.