v2rayN 설정 가이드처음부터 고급 설정까지

1. 핵심 개념: 연결 흐름 파악하기

클라이언트, 코어, 서버의 역할

먼저 그래픽 인터페이스와 실제 연결을 처리하는 프로그램을 구분하세요. v2rayN은 서버 정보를 저장하고 구독을 관리하며 라우팅을 선택하고 코어를 실행합니다. 코어는 로컬 포트를 열고 설정을 해석해 연결을 만듭니다. 인터페이스가 열렸다고 해서 코어까지 정상적으로 실행된 것은 아닙니다. 연결에 실패하면 브라우저 설정을 반복해서 바꾸기보다 시작 로그에 오류가 있는지 먼저 확인하세요. 설정 문법 오류, 포트 충돌, 구성 요소 누락으로 인터페이스는 정상이어도 프록시 입구가 만들어지지 않을 수 있습니다.

Project V는 관련 프록시 기술 생태계의 배경이며, V2Fly와 Xray는 구분해야 할 코어 계열입니다. 코어에 따라 프로토콜 지원, 설정 필드, 기능 구현이 달라질 수 있으므로 이름이 비슷하다고 동작까지 같다고 보면 안 됩니다. 그래픽 클라이언트는 보통 인터페이스의 선택 항목을 코어 설정으로 변환합니다. 전체 설정 파일을 직접 작성할 필요는 없지만 현재 어떤 코어를 사용하는지는 알아두세요. 안내 문서를 볼 때는 클라이언트 설정과 코어 매개변수를 따로 확인하고, 다른 구현의 필드를 그대로 붙여 넣지 않도록 주의하세요.

서버 정보에는 주소, 포트, 인증 정보, 프로토콜, 전송 매개변수 등 원격 접속에 필요한 내용이 포함됩니다. 클라이언트 자체가 이 정보를 제공하는 것은 아니며, 설치만으로 원격 서비스를 이용할 수 있는 것도 아닙니다. 공유 링크는 보통 연결 하나에 필요한 필드를 담고, 구독 주소는 여러 항목을 가져오고 갱신하는 데 사용됩니다. 둘 다 민감한 정보일 수 있습니다. 구독 주소를 공개 게시판에 올리면 접속 경로를 공개하는 것과 같습니다. 화면을 캡처하기 전에도 인증 식별자와 전체 링크를 가리세요.

앱에서 아웃바운드까지, 트래픽 흐름으로 이해하기

일반적인 흐름은 앱이 로컬 프록시 입구에 연결하고, 코어가 라우팅 규칙에 따라 아웃바운드를 선택한 뒤 원격 서버에 연결하거나 대상에 직접 접속하는 순서입니다. ‘인바운드’는 트래픽이 로컬 코어로 들어오는 방식을, ‘아웃바운드’는 코어가 외부로 연결하는 방식을 뜻합니다. 직접 연결도 아웃바운드의 한 종류이지 모든 처리를 우회하는 것은 아닙니다. 로그에 표시된 로컬 원본 주소를 원격 서버 주소로 착각하지 마세요. 대상 도메인이 보인다고 해서 예상한 DNS 서버에서 이미 올바르게 조회됐다는 뜻도 아닙니다.

시스템 프록시는 해당 설정을 따르는 앱에 프록시 위치를 알려주고, TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 처리합니다. 라우팅 규칙은 트래픽이 코어에 들어온 뒤 경로를 결정하며, 트래픽을 코어로 보내는 방식 자체를 대신하지는 않습니다. 시스템 프록시를 읽지 않는 앱은 ‘중국 본토 우회’ 설정을 바꿔도 갑자기 프록시 입구를 사용하지 않습니다. 문제를 확인할 때는 먼저 ‘연결이 코어로 들어왔는지’를 보고, 그다음 ‘어떤 아웃바운드가 선택됐는지’를 확인하세요. 순서를 바꾸면 잘못 판단하기 쉽습니다.

프로토콜, 전송 방식, 암호화를 구분하기

VMess, VLESS, Trojan은 연결 프로토콜이고 TCP, WebSocket, gRPC 등은 전송 방식입니다. TLS와 관련 보안 설정은 또 다른 계층입니다. 연결 정보를 가져온 뒤에는 프로토콜 이름만 같다고 서로 바꿔 쓸 수 있다고 생각하지 말고 각 필드의 조합을 확인하세요. 예를 들어 서버에서 특정 경로나 서비스 이름을 요구하는데 클라이언트에 해당 값이 없으면 인증 정보가 맞아도 연결에 실패할 수 있습니다. 서버가 제공한 전송 매개변수를 임의로 바꾸지 마세요.

도메인 조회도 연결 과정의 일부입니다. 앱이 먼저 도메인을 주소로 변환할 수도 있고, 프록시 프로토콜과 앱 동작에 따라 도메인을 프록시 측에 전달할 수도 있습니다. 도메인 기준 규칙이 적용되는지는 코어가 실제로 어떤 정보를 받는지에 달려 있습니다. ‘웹페이지가 열리지 않는다’는 증상만으로 DNS, 인증, 라우팅 중 무엇이 문제인지 판단할 수는 없습니다. 대상 유형, 앱의 연결 방식, 로그에 나타난 오류 단계를 기록해야 다음 확인 절차가 명확해집니다.

2. 클라이언트 선택: 기기와 코어에 맞춰 고르기

데스크톱에서는 v2rayN 선택

데스크톱에서는 v2rayN을 우선 고려하세요. 먼저 운영체제를 확인하고, 프로세서 아키텍처를 확인한 뒤 적합한 설치 형식을 선택합니다. Windows 데스크톱판은 크로스 플랫폼 인터페이스를 사용하고, 클래식 WPF판은 별도의 데스크톱 인터페이스를 제공합니다. 두 버전의 차이는 프록시 프로토콜이 아닙니다. 처음 사용한다면 다운로드 페이지 안내에 따라 하나를 선택하세요. 이미 안정적으로 설정해 사용 중이라면 인터페이스 차이만으로 옮길 필요는 없습니다. 문제를 해결하는 동안 두 버전을 함께 설치하고 실행하면 수신 포트나 시스템 프록시 설정이 충돌할 수 있습니다.

macOS에서는 Apple Silicon과 Intel을 구분해야 합니다. 외관만으로 판단하지 말고 시스템의 ‘이 Mac에 관하여’에서 칩 정보를 확인한 뒤 해당 다운로드 항목을 선택하세요. Linux는 배포판의 패키지 관리 방식과 프로세서 아키텍처를 모두 확인해야 합니다. deb와 rpm 중 무엇을 쓸지는 선호도가 아니라 배포판에 따라 결정됩니다. 아키텍처 불일치와 의존성 누락은 설치 단계의 문제이므로, 아직 연결 단계에 도달하지 않았습니다. 구독이나 서버 매개변수를 바꿔도 보통 해결되지 않습니다.

클라이언트를 고를 때는 브라우저 프록시만 필요한지, 시스템 프록시를 읽지 않는 프로그램까지 처리해야 하는지, 가상 네트워크 인터페이스에 필요한 권한이 있는지도 고려하세요. 현재 필요한 최소 기능부터 사용하고 고급 설정은 차례로 추가하세요. 특정 기능이 메뉴에 있다는 이유만으로 기기에서 반드시 쓸 수 있다고 단정해서는 안 됩니다. 운영체제 권한, 코어 지원, 네트워크 환경이 실제 동작에 영향을 줍니다.

Android에서는 v2rayNG를 우선 선택하고 필요에 따라 v2flyNG 사용

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 고려하세요. v2flyNG는 V2Fly 코어를 사용하며, 해당 코어의 동작이 필요한 경우에 적합합니다. 두 앱 모두 실제로 지원하는 프로토콜과 전송 조합을 확인해야 합니다. 가져오기에 성공했다고 연결까지 보장되는 것은 아닙니다. 최신 스마트폰 대부분은 arm64를 사용하지만 출시 연도만으로 아키텍처를 판단할 수는 없습니다. 확실하지 않다면 기기 정보와 다운로드 페이지 안내를 확인한 뒤 아키텍처별 패키지와 범용 패키지 중에서 고르세요.

모바일에서는 시스템 VPN 인터페이스 권한을 받아 로컬 트래픽 처리 경로를 만듭니다. 처음 연결할 때 시스템 확인 창이 나타나는 것은 정상적인 권한 절차입니다. 다른 서비스가 이미 해당 인터페이스를 사용 중이라면 동시에 활성화하지 못할 수 있습니다. 앱에 실행 중이라고 표시되는 것은 로컬 서비스가 시작됐다는 뜻일 뿐, 원격 연결과 대상 접속까지 정상이라는 증거는 아닙니다. 로그, 실제 앱 접속, 라우팅 결과를 확인해 검증해야 합니다.

옮기기 전에 호환성 범위 확인

다른 클라이언트로 옮길 때는 구독 주소나 표준 공유 링크를 옮기고 프로그램 디렉터리 전체를 복사하지 마세요. 인터페이스 설정, 라우팅 템플릿, 로컬 데이터베이스 형식은 호환되지 않을 수 있습니다. 두 클라이언트가 같은 프로토콜을 지원하더라도 인식하는 확장 매개변수의 범위가 다를 수 있습니다. 이전한 뒤에는 사용 가능한 것으로 확인된 항목 하나를 선택하고 전송 매개변수는 그대로 둔 채 기본 접속을 확인하세요. 그다음 사용자 지정 규칙과 앱별 라우팅을 추가하면 됩니다.

구독 내용이 범용 공유 링크 모음인지, 특정 프로그램용 전체 설정인지도 확인하세요. 후자는 전용 필드, 스크립트, 템플릿을 포함할 수 있어 파일 확장자만 바꾼다고 일반 구독으로 사용할 수 있는 것은 아닙니다. 형식이 지원되지 않으면 임의로 변환하지 말고 제공처에 출력 형식을 확인하세요. 클라이언트 선택에서 중요한 것은 기능 수가 아니라 현재 연결 정보, 기기 권한, 유지 관리 방식이 안정적으로 맞물리는지입니다.

이 장을 마치면 기기 운영체제, 프로세서 아키텍처, 클라이언트 이름, 사용 중인 코어를 명확히 기록할 수 있어야 합니다. 이 정보를 개인 문제 해결 기록에 남기면 나중에 문서를 볼 때 플랫폼별 안내를 혼동하지 않습니다. 세 클라이언트의 사용 차이를 비교하려면 클라이언트 비교 리뷰를 확인하세요. 설치 파일은 언제나 다운로드 센터에서 선택해 소개 글을 설치 파일 목록으로 착각하지 않도록 하세요.

3. 설치 및 초기 설정: 로컬 서비스부터 확인

설치 형식에 맞춰 첫 실행하기

다운로드 전에 운영체제와 아키텍처를 확인하고, 설치 후에는 기본 설정 그대로 실행하세요. 설치 프로그램을 사용한다면 화면 안내에 따라 설치 경로를 선택하고 설치를 마칩니다. 압축 파일을 받았다면 먼저 쓰기 가능한 고정 경로에 전체 압축을 풀고 주 프로그램을 실행하세요. 압축 미리보기 창에서 바로 실행하거나 실행 파일 하나만 따로 꺼내면 안 됩니다. 코어, 리소스, 설정 파일이 같은 디렉터리나 인접한 경로에 있을 수 있습니다. 관련 파일이 없으면 인터페이스는 열려도 백그라운드 구성 요소가 작동하지 않을 수 있습니다.

프로그램 디렉터리는 나중에 백업하기 쉬운 위치에 두고 임시 다운로드 캐시나 자동 정리되는 경로는 피하세요. 여러 기기에서 설정을 동기화한다면 파일 동기화 프로그램이 실행 중인 데이터베이스를 동시에 수정하지 않도록 합니다. 디렉터리에 쓸 수 없다는 시스템 알림이 나오면 보안 기능을 모두 끄기보다 경로 권한과 설치 위치를 먼저 확인하세요. 일반 실행은 일반 사용자 권한으로 하고, 가상 네트워크 인터페이스 등 보호된 작업이 필요한 경우에만 해당 기능이 요구하는 권한을 부여하세요.

macOS는 다운로드 형식에 따라 설치하고 시스템의 개인정보 보호 및 보안 설정에서 신뢰할 수 없는 출처 관련 안내를 확인하세요. Linux는 해당 배포판의 설치 방식에 맞춰 설치하고, 의존성 오류가 발생하면 패키지 관리자의 메시지를 먼저 읽으세요. 배포판별 절차를 무작정 섞어 따라 하면 안 됩니다. 처음 실행한 뒤 창을 정상적으로 닫았다가 다시 열고 설정이 저장되는지 확인하세요. 이 단계에서 읽기 전용 디렉터리, 불완전한 설치, 실행 환경 누락을 미리 찾아 구독을 가져온 뒤에야 문제를 확인하는 상황을 피할 수 있습니다.

포트, 코어, 로그 확인

v2rayN 설정과 실행 로그에서 로컬 수신 정보를 확인하세요. 흔히 SOCKS 포트는 10808, HTTP 포트는 10809를 사용하지만 배포판이나 기존 설정에 따라 다른 포트 또는 혼합 입구를 사용할 수도 있습니다. 예시 숫자만 따라 적지 말고 현재 인터페이스와 시작 로그를 기준으로 삼으세요. 원격 서버 포트는 연결 정보에 포함되며 로컬 수신 포트와는 별개입니다. 둘 중 하나를 바꿔도 다른 하나가 자동으로 바뀌지는 않습니다.

로그에 주소가 이미 사용 중이라고 나오면 다른 클라이언트 인스턴스나 같은 종류의 로컬 서비스가 실행 중인지 먼저 확인하세요. 중복 인스턴스를 종료한 뒤 다시 시작하거나, 현재 인스턴스의 수신 포트를 충돌하지 않는 값으로 바꾸고 앱의 프록시 설정도 함께 수정하세요. 오류를 숨기는 것만으로 해결되지는 않습니다. 수신에 실패하면 브라우저가 로컬 주소를 올바르게 사용해도 연결할 수 없습니다. 트래픽이 로컬 프록시 입구를 벗어나지 못한 상태이므로 서버를 바꾸는 것은 의미가 없습니다.

최소한의 초기 설정 유지

처음 설정할 때는 TUN, LAN 공유, 불필요한 사용자 지정 라우팅을 끄고 로컬 입구와 연결 정보 하나만 남기세요. 그러면 문제가 생겼을 때 코어 시작, 인증, 원격 접속 가능성에 집중할 수 있습니다. 기본 연결이 정상인지 확인한 뒤 기능을 하나씩 추가하세요. 처음부터 규칙을 많이 가져오고 DNS를 바꾸고 여러 트래픽 처리 방식을 켜면 접속에 실패했을 때 어느 계층이 실제 경로를 바꿨는지 파악하기 어렵습니다.

Android에 설치한 뒤 앱을 열어 초기 설정을 마치고 연결 정보 하나를 가져온 다음 연결을 시작해 시스템 권한을 확인하세요. 로그가 나타나기를 기다리는 대신 시작 버튼을 연속해서 누르지 마세요. 다른 앱으로 전환한 뒤 연결이 끊긴다면 시스템의 백그라운드 실행 및 배터리 관리 설정을 확인하되 필요한 앱에만 조정하세요. 백그라운드 제한, 시스템 권한, 원격 인증은 서로 다른 계층입니다. 문제를 확인할 때 이를 전부 ‘노드 오류’라고 뭉뚱그리지 말고 각각 기록하세요.

초기 설정 완료 기준은 설정 저장, 코어 실행, 로컬 입구의 포트 충돌 없음, 로그 위치 확인입니다. 모든 앱이 이미 프록시를 사용해야 하는 것은 아닙니다. 현재 수신 주소와 포트, 기본 라우팅 이름을 기록해 첫 기준 상태를 만들어 두세요. 이후 설정 변경에 실패하면 이 상태로 되돌리세요. 기준 상태조차 실행되지 않으면 프로그램 파일과 시스템 환경부터 확인해야 합니다. 일반적인 시작 오류는 자주 묻는 질문을 참고해 계속 확인하세요.

4. 구독 가져오기: 주소, 업데이트, 항목 관리

입력 내용의 종류를 확인하고 가져오기 메뉴 선택

먼저 받은 내용이 구독 주소인지, 단일 공유 링크인지, 전체 설정인지 확인하세요. 구독 주소는 콘텐츠를 가져오는 네트워크 주소입니다. 공유 링크는 보통 프로토콜 접두사로 항목 하나를 식별합니다. 전체 설정에는 인바운드, 아웃바운드, 라우팅 등의 구조가 포함됩니다. 세 가지를 같은 입력란에 붙여 넣으면 안 됩니다. 복사할 때 앞뒤 공백과 줄바꿈, 메신저가 덧붙인 문장부호를 확인하세요. 특히 긴 링크가 여러 줄로 나뉘면 겉보기에는 온전해도 필드가 누락됐을 수 있습니다.

v2rayN에서 구독을 관리하려면 ‘구독 그룹’으로 이동해 그룹을 추가하고 알아보기 쉬운 메모와 구독 주소를 입력한 뒤 저장하세요. 저장 후 ‘전체 구독 업데이트’나 해당 그룹 업데이트를 실행합니다. 주소 저장과 콘텐츠 가져오기는 별도의 단계입니다. 저장 직후 목록이 비어 있다고 주소가 잘못됐다고 단정할 수 없습니다. 업데이트를 실제로 실행했는지 확인한 다음 로그에서 가져오기에 성공했는지 살펴보세요. 출처별로 그룹을 나누면 업데이트 범위와 보관 방식을 구분하기 쉽습니다.

단일 공유 링크는 ‘클립보드에서 공유 링크 가져오기’를 사용하세요. 데스크톱 인터페이스에서 지원한다면 Ctrl+V로 가져올 수도 있습니다. 가져온 뒤 편집 창을 열어 프로토콜, 주소, 포트, 전송 방식을 확인하세요. 목록에 항목 이름이 표시된다고 모든 매개변수가 올바르게 인식된 것은 아닙니다. 전송 옵션이 추가된 링크라면 보안 설정, 서버 이름, 경로, 서비스 이름이 원본 정보와 일치하는지 특히 주의해서 확인하세요. 빈 값을 흔한 예시 값으로 임의 보완하지 마세요.

업데이트 실패 시 가져오기와 파싱을 구분

구독 업데이트는 크게 두 단계로 진행됩니다. 먼저 구독 주소에 접속한 다음 응답 내용을 파싱합니다. 접속 시간 초과, 인증서 오류, DNS 조회 실패는 가져오기 단계의 문제입니다. 주소에는 접속할 수 있지만 형식이 지원되지 않는다는 메시지가 나오면 콘텐츠 파싱 단계의 문제입니다. 로그인 페이지, 만료 안내, 일반 웹페이지 본문은 유효한 구독이 아닙니다. 서버가 성공 상태를 반환해도 그대로 가져올 수 있는 것은 아닙니다. 로그에 간단한 오류만 나온다면 주소 출처와 유효 기간을 확인하고 전체 주소를 무관한 사람에게 보내지 마세요.

일부 인터페이스에서는 직접 연결로 업데이트할지 프록시를 통해 업데이트할지 선택할 수 있습니다. 사용할 수 있는 프록시가 이미 있을 때만 프록시 경유 업데이트가 의미가 있습니다. 처음 설치해 사용할 연결이 없는데 구독 업데이트를 해당 연결에 의존하게 하면 순환 문제가 생깁니다. 제공처에서 허용한 방식으로 콘텐츠를 가져오거나, 유효한 공유 링크 하나를 먼저 가져와 기본 연결을 만드세요. 업데이트 방식을 바꾼 뒤에는 한 번에 그룹 하나만 재시도해 여러 요청이 동시에 진행되며 원인이 가려지는 일을 피하세요.

구독 항목은 업데이트 후 추가·삭제되거나 이름이 바뀔 수 있으며, 직접 수정한 내용도 다음 새로 고침 때 덮어써질 수 있습니다. 중요한 사용자 지정 항목은 별도로 관리하고 클라이언트에서 보존 또는 복사 기능을 제공하는지 확인하세요. 구독에서 생성된 항목을 직접 고쳐 장기간 유지하려 하지 마세요. 그룹을 삭제하기 전에는 그룹 내 항목도 함께 삭제되는지 확인하세요. 업데이트 실패를 해결하려고 목록을 전부 비울 필요는 없습니다. 복구 부담을 줄이려면 사용 가능한 자료를 먼저 보관하세요.

가져온 항목 검증과 개인정보 보호

Android의 v2rayNG와 v2flyNG도 구독 주소를 관리한 뒤 콘텐츠를 업데이트하는 방식입니다. 메뉴 위치는 앱의 현재 인터페이스를 기준으로 확인하세요. 가져온 뒤 항목 하나를 선택해 연결을 시작하고 실행 로그를 살펴보세요. 목록 정렬, 속도 측정 결과, 현재 선택 항목은 서로 다른 정보입니다. 첫 번째 항목이 자동으로 사용된다고 생각하면 안 됩니다. 항목을 바꾼 뒤 연결 서비스에 새 설정이 적용됐는지 확인하고, 필요하면 인터페이스에서 제공하는 방식으로 연결을 다시 시작하세요.

검증할 때는 출처와 매개변수가 분명한 항목 하나를 사용하세요. 여러 출처의 항목을 한꺼번에 가져온 뒤 이름만 보고 추측하지 마세요. 연결에 실패하면 오류가 발생한 단계를 기록하되 인증 정보는 공개하지 마세요. 구독 주소에 접근 토큰이 포함될 수 있고, 공유 링크에 사용자 식별 정보가 들어갈 수 있으며, 내보낸 설정에 서버 인증 필드가 포함될 수도 있습니다. 백업 파일도 민감 정보로 취급하세요. 텍스트 파일이라고 해서 공개 공유 폴더나 검토되지 않은 동기화 공간에 두면 안 됩니다.

5. 프록시 모드: 앱이 코어에 연결되는 방식 확인

시스템 프록시의 세 가지 동작은 서로 다른 라우팅이 아닙니다

데스크톱에서는 먼저 시스템 프록시로 기본 연결을 확인하세요. v2rayN의 ‘시스템 프록시 자동 설정’은 이 설정을 따르는 앱이 사용할 수 있도록 로컬 프록시 입구를 시스템 설정에 등록합니다. ‘시스템 프록시 해제’는 프록시 설정을 제거하고, ‘시스템 프록시 변경 안 함’은 기존 시스템 설정을 유지하며 새로 쓰지 않습니다. 세 번째 옵션은 기본값으로 자동 복원하거나 시스템을 직접 연결 상태로 유지한다는 뜻이 아닙니다. 전환 전에 다른 프로그램이 설정한 프록시가 있다면 그 설정이 그대로 남아 있을 수 있습니다.

시스템 프록시와 ‘전역’, ‘중국 본토 우회’ 같은 라우팅 선택은 서로 다른 계층입니다. 시스템 프록시는 앱이 트래픽을 로컬 입구로 보낼지를 결정하고, 라우팅은 코어에 들어온 뒤 어떤 아웃바운드를 사용할지 정합니다. 라우팅을 전역으로 설정해도 모든 앱이 자동으로 처리되는 것은 아닙니다. 브라우저는 되지만 다른 프로그램은 안 된다면 프로토콜을 바꾸거나 구독 전체를 다시 만들기 전에 해당 프로그램이 시스템 프록시를 읽는지, 별도 네트워크 설정이 있는지 확인하세요.

일부 앱은 시작할 때만 시스템 프록시를 읽으므로 설정을 바꾼 뒤 완전히 종료했다가 다시 열어야 합니다. 이미 만들어진 장기 연결도 새 경로로 즉시 바뀌지 않을 수 있습니다. 전환 효과를 확인하려면 관련 연결을 닫거나 테스트 앱을 다시 시작한 뒤 새 요청을 보내세요. 이전 탭에 내용이 계속 표시된다고 연결이 정상이라고 판단하지 마세요. 캐시에서 불러온 내용일 수 있습니다. 기존 연결이 유지되는 것을 새 설정이 적용됐다는 증거로 오해하지도 마세요.

수동 프록시에서는 프로토콜과 수신 주소 확인

앱에서 별도 프록시를 설정할 수 있다면 로컬 주소와 실제 수신 포트를 정확히 입력하세요. 앱과 클라이언트가 같은 기기에서 실행 중이라면 보통 루프백 주소 127.0.0.1을 사용합니다. HTTP 프록시와 SOCKS 프록시의 프로토콜 유형은 해당 입구와 일치해야 합니다. 포트만 같다고 두 방식이 같은 것은 아닙니다. 현재 코어가 혼합 입구를 제공한다면 그 입구가 지원하는 범위를 확인하세요. 각각 별도로 수신한다면 프로토콜에 맞는 포트를 입력해야 합니다.

앱의 ‘원격 DNS 조회’와 비슷한 옵션은 도메인을 로컬에서 조회할지 프록시 경로에서 처리할지에 영향을 줍니다. 이 옵션이 없다고 조회가 반드시 특정 위치에서 이루어진다고 단정할 수는 없습니다. 도메인으로 접속할 때만 실패하고 주소로 접속하면 결과가 다른 경우, 앱의 프로토콜과 조회 방식을 기록한 뒤 DNS를 확인하세요. 특정 사이트의 주소를 도메인 대신 테스트하는 데에도 한계가 있습니다. HTTPS 인증서와 가상 호스트가 도메인에 의존할 수 있으므로 접속 실패만으로 네트워크가 끊겼다고 볼 수 없습니다.

연결 확인 및 정상 종료

일반 브라우저에서 새 요청을 보내고 같은 시간대의 클라이언트 로그를 확인하세요. 먼저 새 연결이 들어왔는지 확인한 뒤 인증, 전송 핸드셰이크, 대상 연결 단계에 오류가 있는지 살펴봅니다. 브라우저 확장 프로그램, 사용자 지정 프록시 플러그인, 앱 내 설정이 시스템 프록시를 덮어쓸 수 있으므로 테스트 중에는 입구 방식을 하나만 명확히 유지하세요. 로그에 관련 활동이 전혀 없다면 원격 서버만 문제라고 단정하기보다 앱의 진입 경로부터 확인하는 것이 좋습니다.

클라이언트를 종료하기 전에 클라이언트가 설정한 시스템 프록시를 먼저 해제한 뒤 정상적으로 종료하세요. 비정상 종료 후 시스템이 중지된 로컬 포트를 계속 가리키면 시스템 프록시를 따르는 앱에서 연결 실패가 이어집니다. 복구하려면 클라이언트를 다시 열어 설정을 해제하거나 시스템 네트워크 설정에서 프록시 주소를 확인하세요. 기존 환경을 모르는 상태에서 기업용 프록시 설정 등을 지우지 마세요. 테스트 전에 기존 값을 기록해야 나중에 올바르게 복원할 수 있습니다.

Android는 일반적으로 데스크톱 시스템 프록시의 세 가지 옵션을 사용하지 않고 앱이 만드는 VPN 인터페이스로 트래픽을 처리합니다. 앱별 분할 및 우회 설정도 해당 클라이언트에서 확인해야 합니다. 이 장을 마치면 테스트 앱이 시스템 프록시, 앱 자체 프록시, 가상 인터페이스 중 어떤 입구를 사용하는지 설명할 수 있어야 합니다. 답을 알 수 없다면 먼저 입구 확인으로 돌아가세요. 입구가 분명해야 다음 장에서 다루는 규칙 순서와 직접 연결 정책을 검증할 수 있습니다.

6. 라우팅 및 DNS: 규칙과 조회 경로 맞추기

내장 방식을 먼저 고르고 예외 추가

처음 트래픽을 나눌 때는 클라이언트에 내장된 라우팅 방식을 우선 사용하고 실제 대상에 필요한 규칙만 조금씩 추가하세요. ‘중국 본토 우회’는 보통 해당 도메인이나 주소를 직접 연결로 보내고 나머지는 선택한 방식에 따라 처리한다는 뜻이지만, 규칙 집합과 템플릿의 구현이 모두 같다고 볼 수는 없습니다. 방식을 선택한 뒤 규칙 설명과 로그 결과를 확인해 로컬 서비스, 국내 대상, 그 밖의 대상이 실제로 어떤 경로를 사용하는지 검증하세요. 인터페이스에 방식 이름이 표시되는 것은 템플릿이 선택됐다는 뜻일 뿐, 모든 도메인이 올바르게 분류됐다는 증거는 아닙니다.

규칙 순서는 매우 중요합니다. 순서대로 일치 항목을 확인하는 목록에서는 앞에서 일치한 규칙이 뒤에 있는 규칙의 적용에 영향을 줍니다. 구체적인 예외는 일반적인 규칙보다 앞에 두는 것이 보통입니다. 규칙을 추가할 때는 일치 조건과 아웃바운드 태그를 함께 확인하세요. 도메인이 맞아도 태그가 없으면 작동하지 않고, 태그가 맞아도 앞의 광범위한 규칙이 먼저 적용되면 예상한 결과가 나오지 않습니다. 대상 하나만 추가하고 저장·적용한 뒤 새 연결을 만들어 일치 결과를 확인하고 범위를 넓히세요.

아래는 테스트 도메인을 보존하는 완전한 일치 방식을 보여주는 Xray 스타일 라우팅 조각입니다. 단독 실행 가능한 전체 파일은 아니며 direct라는 이름의 아웃바운드가 이미 있어야 합니다. full:은 정확한 도메인 일치를 뜻하고 domain:은 해당 도메인과 하위 도메인까지 일치시키는 데 사용합니다. 예시 도메인을 실제 서비스 목록으로 보거나, 그래픽 인터페이스의 공유 링크 가져오기 입력란에 라우팅 객체를 붙여 넣지 마세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

DNS는 접속 가능성과 규칙 판단 모두에 영향을 줍니다

DNS 설정에서는 먼저 ‘어떤 도메인을 누가 조회할지’를 정해야 합니다. 로컬 네트워크에서 접속할 수 있는 조회 서버는 직접 연결 대상 일부에 적합하고, 다른 대상은 지정한 경로로 DNS 서버에 접속해야 할 수 있습니다. 서버 주소를 입력하는 것만이 아니라 조회 요청 자체가 해당 서버에 어떻게 도달하는지도 중요합니다. DNS 서버에 접속하려면 프록시가 필요한데 프록시 서버 주소는 같은 DNS 서버에서 조회해야 한다면 시작 단계에서 순환 의존성이 생길 수 있습니다. 먼저 서버 주소를 초기 조회할 수 있게 한 뒤 대상 도메인별로 세분화하세요.

라우팅의 도메인 조회 정책과 DNS 모듈의 조회 정책은 서로 다른 매개변수입니다. 전자는 라우팅 판단을 위해 도메인을 주소로 변환해야 하는지에 영향을 주고, 후자는 조회 주소 유형 등의 동작을 결정합니다. 아래 DNS 조각은 도메인별 DNS 서버 지정과 조회 유형 제한 문법만 보여주는 예시이며 모든 네트워크에 적합한 권장 설정은 아닙니다. 사용하기 전에 DNS 서버에 접속할 수 있는지, 전체 설정에서 DNS 트래픽이 어떤 아웃바운드를 사용하는지 확인하세요. 일부만 복사했다고 DNS가 자동으로 처리되는 것은 아닙니다.

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["full:example.com"]
      }
    ],
    "queryStrategy": "UseIPv4"
  }
}

IPv6도 별도로 확인해야 합니다. 앱이 IPv6 주소를 우선 사용할 수 있으며 프록시나 직접 연결 경로를 IPv4로만 검증했다면 간헐적으로 실패하거나 오래 기다린 뒤 성공할 수 있습니다. 시스템 주소, DNS 응답, 아웃바운드 지원, 규칙 범위를 각각 확인하세요. 한 주소 계열을 비활성화하는 방법을 언제나 쓸 수 있는 해결책으로 여기지 마세요. 조회 유형을 일시적으로 제한하면 원인을 찾는 데 도움이 될 수 있지만, 이유를 기록한 뒤 다시 검토해 해결 가능한 네트워크나 라우팅 문제를 숨기지 않도록 하세요.

대상을 정해 규칙 검증

직접 연결되어야 하는 대상 하나와 프록시를 거쳐야 하는 대상 하나를 선택해 각각 새 요청을 보내고 로그를 확인하세요. 브라우저 캐시, 기존 연결, 시스템 DNS 캐시에 이전 결과가 남아 있을 수 있습니다. 필요하면 앱을 다시 열거나 관련 캐시가 만료될 때까지 기다리세요. 규칙 하나를 검증하려고 설정을 전부 지우지는 마세요. 특정 하위 도메인만 문제가 있다면 도메인 전체를 다른 경로로 바꾸기보다 정확한 일치와 접미사 일치 범위를 먼저 확인하세요.

도메인 스니핑 기능은 앱이 주소만 제공하는 경우 보완에 도움이 될 수 있지만 모든 프로토콜을 인식하는 범용 기능도, 원래 도메인을 반드시 복구하는 기능도 아닙니다. LAN 서비스에서는 로컬 DNS 조회와 사설 주소 접속도 유지해야 합니다. 규칙이 많아질수록 출처, 용도, 우선순위를 기록하는 것이 중요합니다. 필드에 대한 자세한 설명은 DNS 분할 조회 안내에서 확인할 수 있습니다. 이 장에서는 검증 가능한 규칙을 몇 개만 사용해 기준 상태를 만드세요.

7. TUN 모드: 앱 프록시에서 네트워크 트래픽 처리까지

TUN이 정말 필요한지 먼저 확인

대상 앱이 시스템 프록시를 읽지 않거나 더 많은 연결에 통일된 네트워크 경로를 적용하려는 경우 TUN을 고려하세요. TUN은 가상 네트워크 인터페이스와 시스템 라우팅으로 트래픽을 처리하는 기능이지 원격 서버 성능을 높이는 가속 스위치가 아닙니다. 먼저 일반 로컬 프록시 모드에서 정상 접속을 확인한 뒤 TUN을 켜면 권한, 인터페이스, 라우팅, DNS처럼 새로 추가되는 문제 범위에 집중할 수 있습니다. 기본 연결부터 실패한다면 TUN을 켜는 것만으로는 문제를 해결하기 어렵고 확인할 변수만 늘어납니다.

v2rayN의 ‘Tun 활성화’ 기능이 실제로 동작하는 방식은 선택한 코어 구성 요소와 클라이언트 설정에 따라 달라질 수 있습니다. Xray의 일반 인바운드 설정 조각을 모든 TUN 설정에 그대로 사용할 수 있는 것은 아닙니다. 먼저 인터페이스에서 관련 구성 요소를 사용할 수 있는지 확인하고 안내에 따라 권한을 부여하세요. 시스템에서 권한을 요청하면 현재 사용하는 클라이언트에서 나온 요청인지 확인해야 합니다. 시작에 실패했다면 인터페이스 생성, 라우팅 추가, 권한 관련 로그를 읽고 무관한 구성 요소를 반복해서 설치하지 마세요.

TUN을 사용한다고 모든 프로토콜이 자동으로 작동하는 것은 아닙니다. 앱의 UDP 사용 방식, 서버 지원, 네트워크 경로, 현재 코어의 전달 기능이 결과에 영향을 줄 수 있습니다. 웹페이지는 열리지만 특정 실시간 통신이 실패한다면 브라우저 테스트 결과를 그대로 적용하지 말고 해당 앱이 실제로 사용하는 프로토콜을 확인하세요. 단순히 ‘켜고 나니 안 된다’고 설명하는 것보다 UDP에서만 발생하는지, 특정 대상과 관련이 있는지를 기록하는 편이 문제를 찾는 데 도움이 됩니다.

라우팅 루프와 DNS 의존성 방지

활성화하기 전에 기본 라우팅을 변경하거나 가상 인터페이스를 사용하는 다른 서비스를 종료하고 현재 네트워크 상태를 기록하세요. TUN을 사용할 때는 프록시 프로세스가 원격 서버에 연결하는 트래픽이 하위 네트워크를 통해 전송되어야 합니다. 그렇지 않으면 자체 연결이 다시 가상 인터페이스로 들어가 루프가 생길 수 있습니다. 클라이언트가 필요한 예외 처리를 하는 경우가 많지만 여러 네트워크 어댑터, 기업 네트워크, 수동 정적 라우팅 환경에서는 추가 확인이 필요할 수 있습니다. 로그 근거 없이 시스템 라우팅을 임의로 삭제하지 마세요.

DNS도 자주 문제가 생기는 부분입니다. TUN이 네트워크 트래픽을 처리하더라도 시스템, 앱, 코어는 각각 조회 캐시를 유지할 수 있으며 일부 앱은 자체 조회 방식을 사용합니다. 시스템 조회가 어디로 들어오는지, 코어가 어떻게 처리하는지, DNS 서버 접속에 어떤 아웃바운드를 사용하는지 확인하세요. 가상 주소 매핑 기능을 사용한다면 해당 주소 범위를 올바른 인터페이스가 처리하는지도 확인해야 합니다. 기능을 끈 뒤 이전 조회 결과가 남아 있으면 앱 연결을 다시 만들고 캐시가 갱신될 때까지 기다려야 할 수 있습니다.

LAN 접속도 따로 검증해야 합니다. 프린터, 파일 공유, 로컬 관리 페이지는 사설 주소나 로컬 도메인을 사용하는 경우가 많습니다. 광범위한 규칙으로 이를 잘못 처리하면 외부 웹사이트는 정상인데 내부 서비스에 접속하지 못할 수 있습니다. 먼저 사설 네트워크 대역과 로컬 DNS 조회가 어떻게 처리되는지 확인한 다음 제외 규칙을 추가할지 결정하세요. LAN 프록시 공유와 TUN은 서로 다른 기능입니다. TUN을 켠다고 다른 기기에서 로컬 입구를 사용할 수 있게 되는 것은 아니며, 로컬 접속 문제를 해결하려고 공유 기능을 바로 켜서도 안 됩니다.

순서대로 활성화하고 되돌리기 테스트

실제 테스트는 세 단계로 나눌 수 있습니다. 먼저 브라우저의 새 연결을 확인하고, 다음으로 원래 시스템 프록시를 읽지 않던 앱을 확인한 뒤 LAN 서비스와 절전 모드 복귀를 검증하세요. 각 단계에서 같은 시간대의 로그와 앱 동작을 확인합니다. 시스템 프록시와 TUN을 동시에 사용하면 경로를 파악하기 더 어렵습니다. 처음 테스트할 때는 기존 환경에 문제가 생기지 않는지 확인한 뒤 시스템 프록시를 잠시 해제하고 TUN 경로만 검증하세요. 그다음 일상적으로 함께 사용할지 판단하면 됩니다.

전체 네트워크가 끊기면 먼저 TUN을 끄고 클라이언트를 정상 종료한 뒤 기본 네트워크 연결이 복구되는지 확인하세요. 여전히 문제가 있으면 다른 프록시 서비스를 더 추가하지 말고 시스템 프록시 설정이 남아 있는지, 가상 인터페이스와 DNS 설정이 어떤지 확인하세요. 절전 모드, 네트워크 전환, 어댑터 재연결로 하위 인터페이스가 달라질 수 있으므로 복귀 후 다시 검증해야 합니다. 오래 사용하기 전에 유선에서 무선으로 바꾸거나 연결을 끊었다가 다시 연결하는 테스트를 한 번 이상 수행해 첫 실행에서만 작동하는 것이 아닌지 확인하세요.

8. 유지 관리: 백업, 업데이트, 문제 기록

복구 가능한 상태를 보관하기

연결, 라우팅, 앱 트래픽 처리가 안정되면 먼저 설정 기준 상태를 저장하세요. 클라이언트 이름, 사용 코어, 로컬 포트, 라우팅 방식, DNS 변경 사항, TUN 상태를 기록합니다. 내보내기 기능과 설정 디렉터리 위치는 설치 형식에 따라 다르므로 클라이언트에서 제공하는 백업 방식을 우선 사용하고 어떤 설정이 포함되는지 확인하세요. 구독 주소만 저장해서는 로컬 규칙을 복원할 수 없고 인터페이스를 캡처한 화면만으로는 인증 정보를 복구할 수 없습니다. 어느 쪽도 완전한 복구 계획을 대신하지 못합니다.

클라이언트가 설정 저장을 마친 뒤 백업하세요. 필요하다면 먼저 정상 종료해 데이터베이스가 기록 중인 상태에서 복사하지 않도록 합니다. 파일 이름에 용도와 백업 시각을 적을 수 있지만 구독 토큰은 넣지 마세요. 복구 테스트도 중요합니다. 가져오기 위치, 덮어쓰기 범위를 알고 있는지, 기존 설정을 어떻게 보존할지 확인하세요. 검증하지 않은 백업은 파일이 있다는 사실만 보여줄 뿐 재설치 후 같은 동작을 복원할 수 있다는 보장은 아닙니다.

구독 주소, 공유 링크, 내보낸 파일은 모두 민감한 정보로 보관하세요. 문제 해결 정보를 제공할 때는 오류 종류와 관련 필드 이름만 남기고 사용자 식별자, 전체 서버 인증 정보, 사설 주소를 가리세요. 로그에도 접속 대상과 구독 요청 내용이 포함될 수 있으므로 통째로 공개하지 마세요. 다른 사람이 형식을 확인하도록 도와야 한다면 실제 연결 정보를 유포하지 말고 일부 값을 바꾼 구조만 제공하면서 어떤 값을 바꿨는지 설명하세요.

모든 변수를 한꺼번에 바꾸지 말고 나눠서 업데이트

클라이언트 업데이트, 코어 업데이트, 구독 업데이트, 규칙 데이터 업데이트는 서로 다른 작업입니다. 인터페이스 업데이트는 메뉴와 설정 생성 방식을 바꿀 수 있고, 코어 업데이트는 지원하는 필드를 바꿀 수 있으며, 구독 업데이트는 주로 원격 항목을 변경합니다. 안정적인 환경에서는 각 작업을 따로 진행하고 업데이트 전에 백업한 뒤 기본 테스트를 반복하세요. 모든 항목을 한꺼번에 바꾸면 문제가 생겼을 때 원인을 찾기 어렵습니다. 복구 준비가 되지 않은 상태에서 업데이트 횟수만 늘리려고 실행 중인 프로그램 파일을 바꾸지 마세요.

클라이언트를 업데이트하기 전에 정상 종료하고 백그라운드 프로세스가 파일을 사용하지 않는지 확인한 뒤 설치 형식에 맞게 진행하세요. 설치 경로가 여러 개라면 실제로 어느 경로의 프로그램이 실행되는지 확인해 오래된 바로가기가 이전 설정을 여는 일을 방지하세요. 업데이트 후 처음 실행할 때는 인터페이스가 열리는지만 보지 말고 로그를 확인한 뒤 시스템 프록시, 라우팅, TUN을 검증하세요. 설정 항목이 이동했다면 인터페이스 안내를 읽고 기존 사용자 지정 값을 확인하세요. 기본값 변화가 원격 서버 문제라고 오해하지 마세요.

규칙 리소스에도 유효 기간이 있습니다. 도메인 분류나 주소 집합이 변경되면 기존 일치 결과도 달라질 수 있습니다. 하지만 특정 대상 하나에 문제가 생겼다고 출처를 모르는 규칙으로 전부 바꾸지는 마세요. 먼저 어떤 규칙이 적용됐는지 확인한 다음 분류 변경, DNS 변경, 대상 서비스 이전 중 무엇이 원인인지 판단하세요. 더 이상 필요하지 않은 예외 규칙은 정리하고 삭제 전에 이유를 기록하세요. 규칙이 계속 쌓이면 우선순위를 나중에 설명하기 어려워집니다.

반복 재설치보다 연결 단계별로 문제 기록

문제 해결 기록에는 발생 시각, 영향을 받은 앱, 현재 입구 방식, 선택된 항목, 오류 메시지, 최근 변경 사항을 포함하세요. 모든 대상이 실패하는지 일부 대상만 실패하는지, 모든 앱이 실패하는지 특정 앱만 실패하는지 먼저 구분합니다. 전체적으로 문제가 생기면 코어 시작, 입구, 기본 네트워크를 우선 확인하고 특정 대상만 실패하면 도메인, 라우팅, 대상 서비스 상태를 더 살펴봅니다. 연결 항목을 계속 바꾸는 것보다 범위를 좁혀야 반복 확인 가능한 결론을 얻기 쉽습니다.

로그 수준은 필요한 경우에만 잠시 높이고 원인을 찾은 뒤에는 평소 수준으로 되돌리세요. 출력이 많으면 읽기 어려워지고 민감한 접속 기록이 장기간 쌓일 수 있습니다. 인증 오류는 연결 정보와 시스템 시간을, 핸드셰이크 오류는 보안 및 전송 매개변수를, 연결 거부는 주소와 포트, 서비스 접속 가능성을 확인하세요. 시간 초과만으로는 얻을 수 있는 정보가 적습니다. 어느 단계에서 실패했는지 함께 확인해야 하며, 단어 하나만 보고 서버와 로컬 네트워크 중 무엇이 원인인지 단정할 수 없습니다.

9. 고급 설정: 설명 가능한 실험으로 발전시키기

생성된 설정 읽기부터 시작

고급 설정을 한다고 바로 그래픽 인터페이스를 버릴 필요는 없습니다. 먼저 현재 설정으로 클라이언트가 어떤 인바운드, 아웃바운드, 규칙을 생성하는지 살펴보고 인터페이스와 설정의 관계를 이해하세요. 생성 파일은 설정을 다시 적용할 때 덮어써질 수 있으므로 장기간 직접 편집하는 용도로 적합하지 않습니다. 사용자 지정 설정이 필요하다면 클라이언트가 명시적으로 지원하는 방식을 사용하고, 필드 추가인지 일부 교체인지 전체 설정을 직접 관리하는 방식인지 확인하세요. 방식마다 적용 범위가 다르므로 입력란에 텍스트를 넣을 수 있다는 이유만으로 혼용하면 안 됩니다.

설정은 정해진 순서에 따라 읽을 수 있습니다. 먼저 인바운드가 어떤 주소와 포트를 수신하는지 보고, 다음으로 아웃바운드 태그와 프로토콜을 확인한 뒤 라우팅이 해당 태그를 어떻게 참조하는지 살펴보세요. 이어서 DNS, 로그, 기타 보조 모듈을 확인합니다. 실제 연결 하나의 흐름을 기준으로 시작하면 모든 필드를 한꺼번에 이해할 필요가 없습니다. 파일에 특정 매개변수가 없더라도 코어의 기본 동작일 수 있고 다른 구성 요소가 처리할 수도 있으므로 기능이 꺼졌다고 단정하지 마세요.

아래는 구조를 이해하기 위한 완전한 Xray 최소 설정입니다. 로컬 SOCKS 입구만 제공하고 직접 아웃바운드하며 원격 프록시는 포함하지 않습니다. 인바운드 태그, 라우팅 참조, 아웃바운드 간 관계를 보여주는 예시이지 현재 사용하는 전체 프록시 설정을 대체하는 설정은 아닙니다. 실제 실행 전에는 포트가 사용 중인지 확인하고 클라이언트에서 지원하는 사용자 지정 설정 메뉴를 사용하세요. 실행 후에도 트래픽은 로컬 네트워크를 통해 직접 접속하는 것이 예시의 의도입니다.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  }
}

실험마다 질문 하나만 설정

유효한 실험에는 명확한 질문, 하나의 변경 사항, 관찰 가능한 결과가 있어야 합니다. 예를 들어 특정 도메인이 직접 연결 규칙과 일치하는지 확인하려면 클라이언트와 연결 정보는 그대로 두고 도메인 규칙 하나만 바꾼 뒤 새 연결의 아웃바운드를 확인하세요. DNS 변경, 스니핑 활성화, 전송 방식 변경을 동시에 하지 마세요. 실험에 실패하면 먼저 원래 값으로 되돌리고 기준 상태가 여전히 작동하는지 확인한 뒤 다음 가설을 테스트하세요. 이렇게 해야 우연히 작동하는 복잡한 설정이 아니라 원인과 결과를 파악할 수 있습니다.

규칙 일치, 도메인 조회, 앱 트래픽 처리, LAN 공유 순서로 익혀도 좋습니다. 각 기능은 먼저 단일 기기 환경에서 검증한 뒤 더 많은 기기로 확장하세요. 예를 들어 LAN 연결을 허용하려면 스위치 하나만 켜는 것이 아니라 수신 주소, 방화벽, 클라이언트가 연결된 네트워크를 확인해야 합니다. 다른 기기에서는 해당 컴퓨터의 LAN 주소를 입력해야 하며 자기 자신의 루프백 주소를 입력하면 안 됩니다. 컴퓨터 주소가 바뀌면 사용하는 기기의 설정도 함께 업데이트해야 합니다.

LAN 공유에는 접근 범위도 고려해야 합니다. 신뢰할 수 있는 네트워크에서 필요한 포트만 열고 인증 보호가 없는 입구를 신뢰할 수 없는 네트워크에 노출하지 마세요. 공유 중에도 방화벽 제한을 유지하고 절전, 네트워크 연결 해제, 주소 변경 시 동작을 확인하세요. 공유할 필요가 없다면 관련 설정을 끄세요. 자세한 절차는 LAN 연결 허용 안내를 참고하고 수신 범위를 이해한 뒤 장기간 사용할지 결정하세요.

프로토콜 차이를 이해하고 복구 경로 유지

프로토콜은 실제 필드와 오류 단계에 초점을 맞춰 익히세요. VMess와 VLESS는 인증, 시간 조건, 보안 조합이 다르므로 프로토콜 이름만 바꿔 서로 변환할 수 없습니다. 전송 방식, 보안, 서버 매개변수가 모두 맞아야 합니다. 다른 설정을 공부하기 전에 현재 연결 정보부터 이해하세요. 빠르게 개념을 잡으려면 VMess와 VLESS의 차이를 확인한 뒤 실제 클라이언트에서 지원 범위를 확인하세요. 이름만으로 전체 기능을 추측하지 마세요.

최종 목표는 설명하고 검증하고 복구할 수 있는 설정을 만드는 것입니다. 각 예외 규칙이 필요한 이유, DNS 요청이 이동하는 경로, 앱이 코어에 연결되는 방식, 클라이언트 종료 후 시스템이 어떤 상태로 복원되어야 하는지 알아야 합니다. 새로운 요구가 생기면 현재 기준 설정에 필요한 최소한의 항목만 추가하고 검증한 뒤 유지하세요. 첫 연결 절차는 빠른 시작 가이드에서 다시 확인할 수 있습니다. 설치 형식을 바꾸려면 다운로드 센터로 돌아가면 됩니다. 문제 하나를 해결하려고 모든 단계를 다시 진행할 필요는 없습니다.