V2Ray 완벽 가이드

1. 핵심 개념과 연결 흐름

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

V2Ray는 일반적으로 Project V와 관련된 프록시 기술 생태계를 가리키며, 서버 회선이 포함된 단일 계정 서비스는 아닙니다. GUI 클라이언트는 서버 정보를 저장하고 구독을 관리하며 설정을 생성하고 코어를 실행합니다. 코어는 인바운드 연결, 프로토콜 통신, 라우팅 규칙을 처리합니다. 원격 서버는 약속된 방식의 연결을 받아 요청을 전달합니다. 클라이언트를 설치하는 것은 로컬 도구를 준비하는 단계일 뿐입니다. 실제 데이터 경로를 구성하려면 사용할 권한이 있는 서버 정보도 필요합니다.

V2Fly와 Xray는 관련 생태계의 서로 다른 코어 프로젝트이며, 지원하는 프로토콜 확장과 설정 세부 사항도 완전히 같지는 않습니다. v2rayN은 데스크톱용 인터페이스를 제공하고, v2rayNG는 Android에서 Xray 설정에 자주 사용되며, v2flyNG는 V2Fly 기반 옵션을 제공합니다. 클라이언트에서 특정 이름을 가져올 수 있다고 해서 현재 코어가 그 설정의 모든 옵션을 지원한다는 뜻은 아닙니다. 호환성을 확인하려면 전송 방식, 보안 계층, 확장 매개변수까지 살펴봐야 합니다.

서버 설정을 세 계층으로 나누기

첫 번째는 VMess, VLESS, Trojan, Shadowsocks 등의 프록시 프로토콜입니다. 양쪽에서 연결을 식별하고 요청을 표현하는 방식을 정합니다. 두 번째는 TCP, WebSocket, gRPC 등의 전송 방식으로, 프로토콜 데이터를 전달하는 방법을 정합니다. 세 번째는 TLS, REALITY, 서버 이름 등의 보안 설정입니다. 세 계층의 조합은 서버 설정과 일치해야 합니다. 주소와 포트가 맞는다고 나머지 항목을 임의로 바꿔도 되는 것은 아닙니다.

서버 이름, 연결 주소, 요청 대상은 서로 다른 개념입니다. 연결 주소는 원격 서버를 찾는 데 사용하고, TLS 서버 이름은 핸드셰이크 과정의 신원 확인에 관여합니다. 요청 대상은 앱이 실제로 접속하는 도메인입니다. 세 값이 같을 때도 있고 다를 때도 있습니다. 공유 링크의 서버 이름을 바꿔 도메인 문제를 해결하려다 오히려 핸드셰이크가 실패할 수 있습니다. 매개변수가 불분명하다면 먼저 제공자가 안내한 원본 설정과 하나씩 대조하세요.

데이터 흐름을 따라 문제 위치 찾기

일반적인 요청은 앱, 로컬 수신 포트, 코어 라우팅, 원격 서버를 차례로 거쳐 대상 서비스에 도달합니다. 시스템 프록시는 해당 설정을 참조하는 앱에만 영향을 줍니다. 로컬 프록시에 들어온 요청도 코어 규칙에 따라 출구가 결정됩니다. DNS는 도메인을 IP 주소로 변환하며, 앱·운영체제·코어가 처리할 수 있습니다. 이 과정을 모두 하나의 ‘프록시 스위치’로 생각하면 엉뚱한 설정을 반복해서 바꾸기 쉽습니다.

문제를 해결할 때는 먼저 어느 구간에서 실패했는지 확인하세요. 클라이언트가 시작되지 않으면 실행 환경과 포트를 살펴봅니다. 브라우저 요청이 클라이언트에 들어오지 않으면 앱의 프록시 설정을 확인합니다. 로그에 핸드셰이크 오류가 있으면 프로토콜 매개변수와 시간을 살펴봅니다. 일부 도메인만 문제가 있다면 규칙과 DNS 결과를 확인하세요. 로그 오류는 발생 시점과 함께 해석해야 합니다. 백그라운드 앱의 요청 실패가 현재 페이지와 관련 없을 수도 있습니다.

재현 가능한 최소 설정 만들기

처음 설정할 때는 사용 가능 여부를 확인한 서버 하나, 앱 연결 방식 하나, 단순한 라우팅 설정 하나만 사용하세요. 불필요한 자동 전환은 잠시 끄고 여러 네트워크 연결 방식을 동시에 활성화하지 않습니다. 이렇게 하면 테스트마다 조건 하나만 바뀌어 결과를 해석하기 쉽습니다. 연결에 성공하면 클라이언트 이름, 코어 선택, 수신 포트, 라우팅 모드를 기록하세요. ‘어제는 됐는데’라는 설명보다 복구에 도움이 됩니다.

다음 장으로 넘어가기 전에 서버 설정을 어디서 받았는지, 어떤 프로그램이 코어를 실행하는지, 테스트 앱이 어느 로컬 포트에 연결하는지 설명할 수 있어야 합니다. 이 세 가지가 불분명하다면 먼저 정보 출처와 설정을 정리하고 복잡한 분할 라우팅은 나중에 구성하세요. 개념을 이해한 다음 장에서는 플랫폼에 맞는 클라이언트를 고르고, 이후 구독 관리, 도메인 규칙, 가상 네트워크 인터페이스를 단계별로 추가합니다. 각 단계마다 이전 상태로 되돌릴 수 있는 테스트 결과를 남겨 두세요.

2. 클라이언트 선택과 플랫폼 준비

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

Windows, macOS, Linux 데스크톱 환경에서는 v2rayN부터 시작하는 것이 좋습니다. 같은 인터페이스로 서버, 구독 그룹, 시스템 프록시, 라우팅을 익힐 수 있습니다. 먼저 클라이언트 다운로드 페이지에서 플랫폼을 선택한 뒤 프로세서 아키텍처와 설치 형식을 확인하세요. 플랫폼 이름이 같아도 설치 파일을 서로 바꿔 쓸 수 있는 것은 아닙니다. 아키텍처를 잘못 선택하면 프로그램이 실행되지 않거나 별도의 호환 실행 환경이 필요할 수 있습니다.

Windows 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하며, 클래식 WPF 버전은 기존 방식의 조작 환경을 제공합니다. 처음 사용한다면 데스크톱 버전을 먼저 선택하세요. 클래식 인터페이스에 익숙하다면 필요에 따라 WPF 버전을 선택해도 됩니다. 두 인터페이스의 배치는 다르므로 튜토리얼 화면에서 버튼 위치만 보고 찾지 마세요. 전환하기 전에 필요한 설정을 내보내고, 새 인터페이스에서 서버를 가져올 수 있는지 확인한 다음 기존 환경을 바꿀지 결정하세요.

칩과 배포판에 맞는 설치 형식 선택

macOS에서는 먼저 시스템의 기기 정보에서 칩 종류를 확인하세요. Apple Silicon은 arm64, Intel은 x64에 해당합니다. 컴퓨터 외관이나 구입 연도로 추측하지 마세요. 설치 후에는 프로그램이 정상 실행에 필요한 권한을 받았는지도 확인해야 합니다. TUN에 필요한 권한은 일반 실행 권한과 다르므로, 인터페이스가 열린다고 모든 네트워크 기능이 준비된 것은 아닙니다. 첫 테스트는 시스템 프록시로 연결 기준을 잡으세요.

Linux에서는 프로세서 아키텍처, 배포판의 패키지 관리 방식, 데스크톱 세션을 함께 확인해야 합니다. deb와 rpm은 서로 다른 패키지 체계이며, arm64와 x64는 서로 다른 명령어 아키텍처입니다. 패키지를 설치한 뒤 트레이 아이콘이나 시스템 프록시 동작에 차이가 있다면 데스크톱 환경의 지원 여부를 확인하세요. 앱에서 로컬 프록시를 직접 설정하는 편이 검증하기 쉬운 경우가 많습니다. 트레이 아이콘의 표시 여부만으로 코어 상태를 판단할 수는 없습니다.

Android는 필요한 코어를 기준으로 선택

Android에서는 우선 v2rayNG를 고려하고, V2Fly 관련 설정을 사용할 때는 v2flyNG도 검토하세요. 최신 주류 기기는 대부분 arm64를 선택할 수 있습니다. 기기 아키텍처를 모르면 시스템 정보를 확인하거나 다운로드 페이지 안내에 따라 범용 버전을 고려하세요. 두 클라이언트를 동시에 실행해 연결을 테스트하지 마세요. 시스템 VPN 인터페이스를 서로 차지할 수 있어 나중에 실행한 연결이 이전 연결을 대체하고 결과도 해석하기 어려워집니다.

Android 클라이언트가 시스템 VPN 인터페이스로 네트워크를 처리하면 시스템 권한 요청이 표시됩니다. 이는 로컬 네트워크 진입점을 만드는 절차일 뿐, 원격 서버가 사용 가능한지 시스템이 확인했다는 뜻은 아닙니다. 배터리 절약 설정, 백그라운드 실행 권한, 앱별 프록시 목록도 확인해야 합니다. 화면이 켜져 있을 때는 되지만 잠금 후 끊긴다면 프로토콜을 바꾸기 전에 백그라운드 제한부터 살펴보세요. 제조사마다 설정 메뉴가 다르므로 권한 이름으로 검색하는 편이 좋습니다.

필요를 먼저 정리하고 기능 수에 끌려가지 않기

클라이언트 선택은 실제로 필요한 프로토콜, 구독 형식, 규칙 기능, 네트워크 연결 방식에 따라 달라집니다. 브라우저만 사용한다면 일반 로컬 프록시로 충분한 경우가 많고, 더 많은 앱의 트래픽을 처리해야 할 때 TUN을 살펴보면 됩니다. REALITY 등의 특정 설정을 사용하기 전에는 선택한 코어가 관련 매개변수를 모두 처리할 수 있는지 확인하세요. 클라이언트에 기능이 많다고 모든 기능을 켜야 하는 것은 아닙니다. 스위치가 늘어날수록 문제 해결 범위도 넓어집니다.

클라이언트를 바꿔도 서버 자체의 문제는 해결되지 않습니다. 같은 설정과 네트워크 환경을 유지한 채 두 클라이언트의 로그와 동작을 비교해야 의미 있는 결과를 얻을 수 있습니다. 관리 방식까지 비교하려면 클라이언트 3종 기능 비교를 참고하세요. 선택을 마쳤다면 한 클라이언트를 정해 설치를 진행하고, 기준 설정을 만들기 전에는 설정을 자주 옮기지 마세요.

3. 설치와 첫 실행 기준선 만들기

설정을 계속 저장할 수 있는 위치에 설치

다운로드 페이지의 안내에 따라 설치하거나 압축을 푼 뒤 클라이언트를 실행하세요. 압축을 풀어야 하는 프로그램은 먼저 별도 폴더에 완전히 풀어야 합니다. 압축 파일 미리보기에서 바로 실행하지 마세요. 현재 사용자 계정으로 설정과 로그를 저장할 수 있고 나중에 백업하기 쉬운 폴더를 선택하세요. 동기화 도구가 파일을 자주 덮어쓰는 폴더에서는 테스트하지 않는 편이 좋습니다. 오래된 설정이 복원되거나 여러 기기가 같은 실행 상태를 동시에 수정할 수 있습니다.

첫 실행 때 실행 환경 안내가 나타나면 필요한 구성 요소를 설치한 뒤 클라이언트를 다시 여세요. 인터페이스는 표시되는데 코어가 시작되지 않는다면 코어 프로그램 경로, 실행 권한, 보안 프로그램의 차단 기록을 확인하세요. 시스템 보호 기능 전체를 끄지 말고 차단된 파일과 원인을 먼저 확인합니다. 시스템 권한이 필요한 작업은 범위를 최소화하세요. 일반 프록시를 테스트할 때 처음부터 TUN을 켤 필요는 없습니다.

코어와 로컬 수신 포트 확인

설정에서 현재 코어가 서버 설정과 호환되는지 확인한 다음 로컬 수신 주소와 포트를 살펴보세요. 이 가이드에서는 포트 예시로 10808을 사용하지만 실제 값은 클라이언트 화면을 기준으로 해야 합니다. 일부 인터페이스는 HTTP, SOCKS, 혼합형 진입점을 따로 표시하고, 다른 인터페이스는 통합 진입점을 제공합니다. 앱에서 선택한 프록시 유형은 해당 수신 방식과 일치해야 합니다. 포트 번호만 복사해서는 안 됩니다.

로컬 앱은 보통 127.0.0.1에 연결합니다. 이 주소는 현재 기기 자체를 뜻하므로 다른 기기에서 같은 주소를 입력하면 그 기기 자신에 연결됩니다. 처음에는 로컬 기기에서만 수신하도록 유지하고 LAN 연결은 켜지 마세요. 다른 기기에서도 사용해야 한다면 수신 범위, 접근 제어, 방화벽 규칙을 확인하세요. 포트를 열면 단순히 편리한 진입점이 하나 늘어나는 것이 아니라 접근 가능한 범위도 넓어집니다.

변수를 최소화해 첫 테스트 진행

사용 권한이 확인된 서버 하나를 가져와 활성 항목으로 설정하고 TUN은 꺼 둡니다. 시스템 프록시 자동 설정을 선택한 뒤 해당 설정을 따르는 브라우저에서 새 요청을 보내고 클라이언트 로그를 확인하세요. 브라우저 캐시나 기존 장기 연결은 이전 경로를 계속 사용할 수 있으므로 필요하면 테스트 탭을 닫았다가 다시 여세요. 로그 전체를 훑기보다 테스트 시각을 기록해 같은 요청을 찾는 편이 좋습니다.

‘코어가 시작됨’은 프로그램 프로세스가 실행 상태가 되었다는 뜻일 뿐, 원격 핸드셰이크에 성공했다는 뜻은 아닙니다. 페이지가 열리지 않으면 먼저 로그에 해당 요청이 나타나는지 확인하세요. 기록이 없다면 앱 진입점을 우선 점검하고, 요청은 기록되지만 연결에 실패하면 서버 주소, 포트, 보안 계층을 살펴보세요. 설정 로드 오류가 있다면 먼저 그 오류를 해결해야 합니다. 노드를 계속 바꿔도 같은 잘못된 설정의 결과는 달라지지 않습니다.

네트워크 권한과 프로그램 권한 구분

시스템 방화벽에서 프로그램의 인터넷 연결을 허용하는 것과 LAN 기기가 로컬 포트에 접근하도록 허용하는 것은 서로 다른 방향의 권한입니다. 처음에는 현재 테스트 경로에 필요한 권한만 허용하세요. 문제를 해결하려고 모든 인바운드 규칙을 한꺼번에 열어서는 안 됩니다. macOS 보안 알림, Linux 실행 권한, Windows 실행 환경 문제도 각각 따로 처리해야 합니다. 설치 시 확인할 사항은 첫 설치 설정 노트에서 살펴보세요.

연결에 성공하면 프로그램 폴더, 설정 저장 위치, 현재 코어, 수신 포트, 테스트 앱을 기록하세요. 그런 다음 클라이언트를 정상 종료하고 시스템 프록시가 예상대로 정리되는지 확인한 뒤 다시 실행해 설정이 유지되는지도 살펴봅니다. 종료 후에도 브라우저가 로컬 포트에 연결한다면 시스템 프록시 설정이 남아 있는지 확인하세요. 시작, 연결, 종료 테스트를 모두 마쳐야 반복 가능한 설치 기준선이 됩니다. 이후 구독과 규칙을 추가하세요.

4. 구독 가져오기와 서버 관리

구독 주소와 공유 링크 구분

구독 주소는 여러 서버 정보를 내려받고 갱신하는 데 사용하며, 공유 링크는 보통 서버 하나를 설명합니다. vmess://, vless://, trojan://, ss://로 시작하는 문자열은 공유 링크 가져오기 메뉴에 입력하고, 구독 주소는 구독 그룹의 주소 입력란에 넣으세요. 둘을 바꿔 입력하면 파싱에 실패하거나 텍스트만 가져오고 사용 가능한 서버가 생성되지 않을 수 있습니다.

구독 주소에는 사용자별 인증 정보가 포함되는 경우가 많으므로 민감한 정보로 취급하고 공개 스크린샷이나 대화 기록에 올리지 마세요. 복사할 때 앞뒤가 잘리지 않았는지, 줄바꿈·설명·문장부호·공백이 함께 들어가지 않았는지 확인하세요. QR 코드에서 가져온 경우에도 클라이언트가 식별한 데이터 유형을 확인해야 합니다. 출처가 불분명한 변환 서비스에 구독을 입력하지 마세요. 변환 과정에서 주소와 서버 설정이 제3자에게 노출될 수 있습니다.

그룹을 만든 다음 구독 업데이트

v2rayN의 구독 그룹 관리에서 새 그룹을 만들고 알아보기 쉬운 이름과 구독 주소를 입력한 뒤 저장하세요. 그런 다음 해당 그룹을 업데이트합니다. 첫 업데이트에서는 결과 메시지를 확인하고 서버 목록에 실제 변화가 있었는지 살펴보세요. 그룹 이름은 로컬 관리용이며 원격 서버를 바꾸지 않습니다. 출처별로 그룹을 나누면 업데이트 실패 원인을 찾기 쉽고, 수동으로 추가한 서버가 구독 항목과 섞여 덮어써지는 것도 막을 수 있습니다.

업데이트에 실패하면 다운로드 실패와 파싱 실패를 먼저 구분하세요. 다운로드 실패라면 현재 네트워크에서 주소에 접근할 수 있는지, 이미 사용 가능한 프록시가 필요한지, 인증서와 시스템 시간이 정상인지 확인합니다. 파싱 실패라면 응답 내용이 클라이언트가 지원하는 구독 형식인지 살펴보세요. 계정 페이지, 오류 안내 페이지, 만료 응답도 일반 텍스트로 반환될 수 있습니다. ‘다운로드 완료’라고 표시되어도 가져오기가 성공한 것은 아닙니다.

업데이트 방식과 덮어쓰기 범위 이해

일부 클라이언트는 직접 업데이트와 프록시를 통한 업데이트를 모두 지원합니다. 사용 가능한 서버가 없는 초기 설정에서는 프록시를 거치는 업데이트가 순환 의존을 만들 수 있습니다. 연결 가능한 서버가 생긴 뒤에야 프록시를 이용해 구독 주소에 접근할 수 있습니다. 선택하기 전에 업데이트 트래픽이 어느 경로를 통과하는지 확인하고, 잘못된 진입점에서 반복해서 클릭하지 마세요. 제공자가 특정 형식을 요구한다면 호환된다고 명시된 클라이언트의 구독 메뉴를 사용하세요.

구독을 업데이트하면 해당 그룹의 항목이 교체될 수 있으므로 구독 노드를 직접 수정해 변경 사항이 계속 유지되리라 기대하지 마세요. 로컬에서 조정해야 한다면 별도의 수동 그룹에 복사하고 수정 이유를 기록하세요. 업데이트 전후에 활성 서버가 남아 있는지 확인하세요. 특히 항목 이름이나 식별자가 바뀐 경우 주의해야 합니다. 클라이언트에 이전 이름이 보인다고 같은 주소로 연결 중이라고 단정할 수는 없습니다. 세부 정보를 열어 확인하세요.

가져온 서버의 주요 항목 확인

공유 링크를 성공적으로 파싱했다면 프로토콜, 주소, 포트, 사용자 ID 또는 비밀번호, 전송 방식, 보안 계층을 차례로 확인하세요. WebSocket에는 경로와 Host가, gRPC에는 서비스 이름이, REALITY에는 공개 키·짧은 ID·서버 이름 등의 매개변수가 필요할 수 있습니다. 각 항목은 제공된 설정과 일치해야 하며 다른 노드의 값을 일괄 적용하면 안 됩니다. 별칭은 자유롭게 정리해도 되지만 연결 매개변수의 의미는 그대로 유지해야 합니다.

업데이트가 끝나면 먼저 현재 서버를 테스트한 뒤 자동 업데이트를 설정하세요. 업데이트 주기는 제공자의 안내에 맞추면 됩니다. 자주 업데이트한다고 안정성이 높아지는 것은 아닙니다. 오랫동안 사용하지 않는 그룹은 자동 업데이트를 끄고 필요한 기록만 남겨도 됩니다. 특정 그룹만 문제가 있고 다른 그룹은 정상이라면 해당 구독 출처부터 확인하세요. 자주 발생하는 문제는 도움말 센터에서 살펴보고, 국소적인 문제 때문에 전체를 다시 설치하는 일은 피하세요.

5. 시스템 프록시와 트래픽 진입점

시스템 프록시가 모든 기기 트래픽을 처리하는 것은 아닙니다

시스템 프록시는 앱에 로컬 프록시 주소를 알려주는 설정이며, 그 주소를 사용할지는 앱이 결정합니다. 브라우저는 대개 시스템 설정을 참조하지만 일부 도구는 별도 프록시 항목을 제공하고, 시스템 프록시를 무시하는 앱도 있습니다. 따라서 ‘시스템 프록시 자동 설정’을 켠 뒤 앱 하나의 결과만 보고 모든 트래픽이 코어에 들어간다고 판단할 수는 없습니다. 진입점을 확인할 때는 해당 설정을 따르는 것으로 확인된 테스트 앱을 사용하세요.

‘시스템 프록시 해제’는 보통 현재 시스템의 프록시 설정을 제거하고, ‘시스템 프록시 변경 안 함’은 기존 상태를 유지합니다. 두 옵션은 같지 않습니다. 시스템에 다른 프록시 설정이 이미 있다면 사용하기 전에 기록해 두어야 복구할 수 있습니다. 클라이언트를 종료했는데도 시스템에 로컬 프록시 주소가 남으면 앱이 이미 닫힌 포트에 계속 연결해 종료 후 오히려 네트워크가 이상해질 수 있습니다.

라우팅 모드는 진입점 다음 단계에서 적용

전역, 중국 본토 우회, 직접 연결 등의 라우팅 모드는 이미 코어에 들어온 요청이 어떤 출구를 사용할지 정합니다. 시스템 프록시와는 서로 다른 계층입니다. 라우팅을 전역으로 바꿔도 시스템 프록시를 무시하는 앱이 자동으로 연결되는 것은 아닙니다. 시스템 프록시를 자동 설정해도 모든 요청이 원격 서버를 거치는 것은 아닙니다. 먼저 요청이 클라이언트에 들어오는지 확인한 다음 출구를 살펴봐야 모드 변경의 효과를 정확히 이해할 수 있습니다.

전역 프록시는 원격 연결을 임시로 확인하는 데 유용하지만, 현재 프리셋에서 사설 네트워크 등의 예외가 유지되는지 살펴봐야 합니다. ‘중국 본토 우회’는 보통 도메인 및 IP 데이터셋을 기준으로 해당 대상에 직접 연결을 적용합니다. 직접 연결 모드는 코어에 들어온 트래픽이 우선 직접 접속하도록 합니다. 클라이언트마다 프리셋이 다를 수 있습니다. 모드 이름은 시작점일 뿐이므로 규칙 내용을 열어 실제 동작을 확인하세요.

개별 앱에 프록시 설정

앱에서 별도 프록시 옵션을 제공하면 클라이언트의 실제 수신 방식에 맞춰 HTTP 또는 SOCKS를 선택하세요. 주소에는 로컬 루프백 주소를, 포트에는 해당 로컬 포트를 입력합니다. 일반 프록시 입력란에 원격 서버 주소를 넣지 마세요. 원격 프로토콜은 보통 코어가 처리해야 합니다. 앱에 ‘프록시를 통해 도메인 해석’ 같은 옵션이 있다면 어느 쪽에서 도메인을 해석하는지 달라질 수 있으므로 이후 라우팅 정책과 함께 확인하세요.

한 번의 테스트에서는 명확한 앱 프록시 출처 하나만 사용하세요. 브라우저 확장 프로그램, 시스템 프록시, 앱 내부 설정이 함께 있으면 우선순위를 먼저 확인해야 합니다. 시스템 프록시를 바꿨다고 생각했지만 실제 요청은 확장 프로그램에 저장된 이전 포트를 계속 사용할 수 있습니다. 전환 후에는 기존 연결을 닫고 다시 시도해 어떤 설정이 적용되는지 기록하세요. 장기적으로는 중복 진입점을 줄이는 편이 복구와 이전에 유리합니다.

사용 시나리오에 맞게 조합 선택

일반적인 웹 브라우징은 시스템 프록시 자동 설정과 명확한 분할 라우팅 규칙으로 시작할 수 있습니다. 개발 도구 하나만 연결하려면 앱별 프록시를 사용하세요. 시스템 프록시를 따르지 않는 프로그램까지 연결해야 할 때 TUN을 검토하면 됩니다. LAN 기기의 접근에는 수신 범위와 방화벽 설정이 따로 필요하며 시스템 프록시 스위치만으로 처리할 수 없습니다. 진입점을 하나 추가할 때마다 별도로 테스트해 기존 트래픽의 출구가 예상대로인지 확인하세요.

브라우저는 정상인데 다른 앱이 실패하면 도메인 규칙을 바로 바꾸지 말고 해당 앱의 요청이 클라이언트에 들어오는지 확인하세요. 앱들의 요청이 모두 들어오지만 특정 대상만 실패한다면 라우팅, DNS, 원격 접근 상태를 살펴봅니다. 조합별 자세한 예시는 시스템 프록시와 라우팅 모드의 차이에서 확인할 수 있습니다. 다음 장에서는 진입점이 명확하다는 전제에서 규칙 순서와 도메인 정책을 설명합니다.

6. 라우팅과 DNS 정책

위에서 아래로 규칙 매칭 이해하기

라우팅 규칙은 어떤 요청을 어느 아웃바운드로 보낼지 정합니다. 조건에는 도메인, 대상 IP, 포트, 네트워크 유형 등이 포함될 수 있습니다. 하나의 규칙에 있는 서로 다른 조건은 대개 함께 충족해야 하며, 같은 종류의 후보는 해당 조건의 의미에 따라 판단합니다. 코어는 규칙을 순서대로 확인해 일치하는 항목을 찾은 뒤 해당 아웃바운드를 선택합니다. 따라서 구체적인 예외 규칙은 보통 범위가 넓은 규칙보다 앞에 둡니다. 일치하는 규칙이 없을 때의 동작은 기본 아웃바운드와 클라이언트가 생성한 설정까지 확인해야 합니다.

먼저 원하는 동작을 정한 다음 매칭 조건을 선택하세요. 예를 들어 내부 도메인 하나를 직접 연결하려면 클라이언트가 도메인을 받는지, IP만 받는지부터 확인해야 합니다. 그에 따라 도메인 규칙이나 주소 규칙을 선택할 수 있습니다. 공개 도메인 하나에 직접 연결 규칙을 추가해도 그 페이지가 불러오는 모든 리소스까지 처리되는 것은 아닙니다. 실제 로그를 보고 필요한 규칙을 조금씩 추가하세요. 한 곳에서 실패했다고 넓은 범위의 대상을 모두 같은 출구로 보내지 마세요.

도메인 정책은 해석을 시도하는 시점을 결정

AsIs는 기존 대상 정보를 기준으로 매칭하며 라우팅을 위해 도메인을 추가로 해석하지 않습니다. IPIfNonMatch는 도메인이 해당 규칙과 일치하지 않을 때 주소 해석을 시도한 다음 IP 조건을 계속 확인합니다. IPOnDemand는 IP 조건이 필요한 규칙을 만났을 때 해석을 시도합니다. 정확한 동작은 선택한 코어의 구현을 기준으로 이해해야 합니다. 도메인 정책을 바꾸면 라우팅 판단 과정이 달라질 뿐, 시스템의 모든 앱이 사용하는 DNS가 교체되는 것은 아닙니다.

geosite:cn은 도메인 데이터셋을 선택하는 방식이고 geoip:cn은 주소 데이터셋을 선택하는 방식입니다. 서로 대체할 수 없습니다. 데이터 파일이 있는지, 내용이 현재 요구에 맞는지도 매칭 결과에 영향을 줍니다. 도메인 해석 결과는 네트워크와 시점에 따라 바뀔 수 있으므로 한 번의 주소 정보만으로 라우팅이 항상 맞다고 판단하지 마세요. 데이터를 업데이트한 뒤에는 핵심 도메인을 직접 확인해야 합니다.

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

위 예시는 라우팅 일부이며 전체 실행 설정은 아닙니다. 사용 가능한 데이터 파일과 direct라는 직접 연결 아웃바운드가 필요하고, 다른 요청의 최종 출구는 정의되어 있지 않습니다. GUI 클라이언트에서는 태그 이름이 다르게 생성될 수 있으므로 해당 규칙 화면에서 연결하세요. 전체 설정을 덮어쓰지 마세요. 첫 번째 규칙은 사설 주소를, 두 번째 규칙은 도메인 집합을 처리합니다. 나머지 트래픽은 다른 규칙과 기본 아웃바운드에 따라 결정됩니다.

DNS 문제와 연결 문제 구분

도메인을 해석할 수 없다면 보통 대상 서비스의 핸드셰이크 단계까지 연결이 진행되지 않은 상태입니다. 해석은 성공했지만 연결 시간이 초과되면 주소 접근성, 라우팅 출구, 원격 서버 상태가 원인일 수 있습니다. 로그에서 오류가 발생한 단계를 먼저 확인한 뒤 관련 설정을 바꾸세요. 일부 앱은 직접 도메인을 해석하고 프록시에는 주소만 전달할 수 있습니다. 이 경우 도메인 규칙을 추가해도 효과가 없을 수 있습니다. 트래픽 탐색으로 대상 정보를 보완할 수는 있지만 모든 프로토콜을 식별하는 것은 아닙니다.

트래픽 탐색은 연결 정보에서 도메인을 식별하려고 시도합니다. 식별 결과를 라우팅에 사용할지, 대상 주소까지 바꿀지는 설정에 따라 달라집니다. 모든 DNS 문제를 자동으로 해결하는 스위치로 생각하면 안 됩니다. LAN 이름에 접근해야 한다면 적절하지 않은 원격 DNS가 로컬 해석 경로를 덮어쓰지 않는지도 확인하세요. 회사나 학교 네트워크에는 내부 도메인이 있을 수 있으므로 변경 전에 기존 해석 방식과 필요한 접근 경로를 기록하세요.

범위를 좁혀 변경하고 회귀 테스트

규칙을 한 번에 하나만 추가하고, 일치해야 하는 대상 하나와 일치하면 안 되는 대상 하나를 테스트한 뒤 출구가 예상과 맞는지 확인하세요. 통과한 뒤에만 범위를 넓히고 규칙 용도를 기록합니다. 문제가 생기면 가장 최근 변경을 되돌리고 최소 규칙 집합을 복구한 뒤 하나씩 다시 추가하세요. DNS, 도메인 정책, 서버를 동시에 바꾸지 마세요. 연결이 복구되어도 무엇이 원인이었는지 알 수 없어 이후 유지 관리의 근거가 사라집니다.

7. TUN 모드와 시스템 네트워크 연결

가상 네트워크 인터페이스로 진입점 확장

TUN은 가상 네트워크 인터페이스를 통해 시스템 라우팅이 전달한 IP 패킷을 받아 해당 구성 요소로 넘깁니다. 주로 트래픽이 프록시 처리 경로에 들어오는 방식을 확장하며, 서버 설정·구독·원격 네트워크 문제를 자동으로 해결하지는 않습니다. 활성화하기 전에 일반 프록시로 같은 서버가 작동하는지 확인하세요. 기본 연결이 되지 않는 상태에서 가상 인터페이스를 추가하면 권한, 시스템 라우팅, DNS 등 변수가 늘어나 문제 위치를 찾기 어려워집니다.

TUN을 켠다고 모든 요청이 반드시 원격 프록시를 거치는 것은 아닙니다. 처리 범위에 들어온 트래픽도 규칙에 따라 직접 연결, 프록시 또는 다른 동작을 선택할 수 있습니다. 시스템 라우팅이나 앱의 네트워크 인터페이스 지정 때문에 일부 트래픽이 처리 범위에 들어오지 않을 수도 있습니다. 화면에 활성화로 표시되는 것은 상태의 일부일 뿐입니다. 가상 인터페이스 생성 여부, 관련 경로 적용 여부, 테스트 앱 요청의 로그 기록까지 확인해야 합니다.

활성화 전에 인터페이스 충돌 해결

네트워크를 처리 중인 다른 VPN 연결이나 중복 TUN 인스턴스를 먼저 끄고 일반 네트워크가 작동하는지 확인한 뒤 현재 설정을 저장하세요. 클라이언트 안내에 따라 필요한 권한을 허용하고 시작 후 드라이버, 인터페이스 생성, 라우팅 기록, 권한 오류가 있는지 로그를 살펴봅니다. 복구될 때까지 스위치를 반복해서 누르지 마세요. 시작에 실패했다면 가장 먼저 나타난 명확한 오류부터 해결해야 합니다. 이후의 연결 시간 초과는 인터페이스 미생성에 따른 연쇄 증상일 수 있습니다.

원격 서버 연결에 필요한 출구는 계속 접근 가능해야 합니다. 라우팅을 통해 같은 처리 경로로 다시 보내 순환이 생기지 않도록 해야 합니다. 클라이언트가 필요한 경로를 자동으로 설정하는 경우가 많지만 여러 네트워크 인터페이스, 다른 네트워크 도구, 수동 라우팅에 따라 결과가 달라질 수 있습니다. 활성화 직후 인터넷이 완전히 끊기면 먼저 TUN을 꺼 기준 상태를 복구한 뒤 기본 경로와 충돌하는 도구를 확인하세요. 네트워크가 끊긴 상태에서 규칙과 구독을 한꺼번에 업데이트하지 마세요.

DNS·UDP·LAN을 나눠 확인

TUN을 켠 뒤에는 일반 웹페이지를 먼저 테스트하고 UDP를 사용하는 실제 앱과 공유기 관리 페이지, 프린터, 내부 서비스도 확인하세요. 웹페이지가 열린다고 모든 프로토콜이 정상인 것은 아닙니다. UDP 전달 여부는 클라이언트의 연결 방식, 코어, 원격 프로토콜, 서버 설정에 따라 달라집니다. 테스트에 실패하면 같은 경로를 따라 점검하고 모든 문제를 시스템 권한 탓으로 돌리지 마세요.

DNS 연결 처리가 기존 해석 경로를 바꿀 수 있으므로 활성화 전후의 도메인 동작을 비교하세요. 공개 도메인은 되는데 내부 이름만 실패한다면 로컬 DNS와 LAN 예외를 먼저 확인합니다. 특정 주소 대역만 접근할 수 없다면 사설 주소 규칙과 라우팅을 살펴보세요. MTU는 패킷 분할이나 특정 전송 문제의 근거가 있을 때 조정해야 합니다. 이유 없이 작은 값을 적용하면 실제 문제를 가릴 뿐 아니라 다른 연결의 효율을 떨어뜨릴 수 있습니다.

데스크톱과 Android의 복구 절차를 따로 준비

데스크톱 클라이언트의 TUN은 추가 네트워크 구성 요소를 사용할 수 있습니다. 구체적인 기능은 클라이언트에 포함된 구성 요소와 구현에 따라 다르므로 모든 코어에 같은 기본 인터페이스가 있다고 보면 안 됩니다. Android 클라이언트가 시스템 VPN 인터페이스를 사용할 때는 앱별 목록과 백그라운드 제한도 확인해야 합니다. 특정 앱이 목록에서 제외되었거나 시스템이 클라이언트를 중지하면 일부 앱만 작동하지 않을 수 있으며, 이는 원격 서버 문제와 해결 방법이 다릅니다.

절전 모드에서 깨어난 뒤, 무선 네트워크를 바꾼 뒤, 유선 네트워크를 연결한 뒤에는 트래픽 처리 상태를 다시 확인하세요. 이전 인터페이스나 DNS 상태가 잠시 남을 수 있습니다. 오류를 기록한 다음 클라이언트를 정상 종료하고 다시 실행하면 환경을 새로 구성하는 데 도움이 됩니다. 네트워크를 바꿀 때마다 같은 문제가 생기면 네트워크 유형, 발생 순서, 인터페이스 상태, 관련 로그를 정리한 뒤 도움말 센터에서 증상에 맞는 항목을 찾아보세요. 프로세스를 강제 종료하는 방법에 계속 의존해서는 안 됩니다.

8. 유지 관리와 문제 해결

프로그램·설정·구독을 따로 관리

일상적인 유지 관리 대상은 서로 독립적인 세 가지입니다. 클라이언트와 네트워크 구성 요소, 사용자가 저장한 설정, 원격 구독 내용입니다. 클라이언트를 업데이트해도 구독이 갱신되는 것은 아니며 구독을 새로 받아도 로컬 라우팅 규칙이 바뀌지는 않습니다. 유지 관리를 시작하기 전에 이번에 해결할 문제가 무엇인지 확인하고 관련된 부분만 업데이트하세요. 클라이언트, 코어, 규칙을 한꺼번에 바꾸면 문제가 생겨도 어느 계층에서 변화가 시작됐는지 판단하기 어렵습니다.

프로그램을 업데이트하기 전에 필요한 설정을 내보내고 백업에 어떤 내용이 포함되는지 확인하세요. 일부 내보내기 기능은 서버만 저장하고 라우팅, 구독 그룹, 인터페이스 설정은 포함하지 않을 수 있습니다. 실행 폴더 전체를 복사해도 다른 플랫폼에서 복구하기에 적합하지 않을 수 있습니다. 백업 파일이 해당 가져오기 기능에서 인식되는지 확인하세요. 백업에는 계정 정보와 구독 인증 정보가 포함될 수 있으므로 접근을 적절히 제한하고 공개 공유 폴더에는 저장하지 마세요.

고정된 점검 순서 만들기

전혀 연결되지 않으면 먼저 네트워크 처리를 끄고 기본 네트워크를 확인하세요. 다음으로 클라이언트 프로세스와 코어 상태, 앱 진입점, 활성 서버, 핸드셰이크, 대상 접근을 차례로 살펴봅니다. 일부 앱만 실패하면 같은 진입점을 사용하는지 비교하세요. 일부 도메인만 실패하면 라우팅과 DNS를 중점적으로 확인합니다. 이 순서는 의존 관계에 따라 진행되므로 앞 단계가 정상화되기 전에 뒤쪽 규칙을 바꿔 설명하기 어려운 변화를 늘리는 일을 막아 줍니다.

로그는 명확한 작업 한 번을 기준으로 수집하세요. 테스트 시각, 앱, 대상 유형, 당시 모드를 기록하고 관련 없는 이전 출력을 정리한 뒤 문제를 재현합니다. 설정 파싱 오류가 있으면 해당 항목과 코어 호환성을 확인하세요. 인증이나 핸드셰이크 오류라면 매개변수와 시스템 시간을 확인합니다. 시간 초과가 발생하면 연결 주소, 출구, 네트워크 환경을 살펴보세요. ‘시간 초과’라는 문구만으로 서버가 영구적으로 중단됐거나 특정 프로토콜을 사용할 수 없다고 판단할 수는 없습니다.

테스트 지표는 실제 작업에 맞춰 선택

지연 시간은 보통 특정 탐색의 왕복 시간을 나타내며, 속도 테스트는 특정 연결 조건에서의 데이터 전송량을 보여 줍니다. 서로 대체할 수 없습니다. 탐색 결과가 좋은 서버도 대상 서비스, 동시 연결 수, 시간대에 따라 현재 작업에는 적합하지 않을 수 있습니다. 평소 사용할 앱을 포함해 검증하고 테스트 횟수를 조절하세요. 일괄 테스트 자체도 연결과 트래픽을 발생시켜 진행 중인 다운로드나 화상 회의에 영향을 줄 수 있습니다.

시스템 시간이 잘못되면 보안 핸드셰이크에 영향을 줄 수 있으며 절전 모드에서 깨어난 뒤에도 시간과 네트워크 상태를 확인해야 합니다. 다른 네트워크로 바꾸자마자 복구됐다면 기존 네트워크 경로를 살펴볼 이유는 있지만 특정 기기가 원인이라고 단정할 수는 없습니다. 같은 클라이언트와 설정을 유지하고 네트워크만 바꿔 비교하거나, 네트워크를 그대로 두고 사용 가능 여부가 확인된 서버 하나만 바꿔 보세요. 한 번에 주요 조건 하나만 변경해야 합니다.

진단 정보를 공유하기 전에 민감한 항목 제거

도움을 요청할 때는 클라이언트 이름, 시스템 플랫폼, 코어 선택, 모드, 전체 오류 발생 단계를 제공하는 것부터 시작하면 됩니다. 스크린샷에서는 구독 주소, 사용자 ID, 비밀번호, 공개 키 관련 정보, 공개하기 어려운 서버 세부 정보를 가리세요. 설정 폴더 전체를 업로드하지 마세요. 로그에는 대상 도메인과 로컬 경로도 포함될 수 있습니다. 공유 전에 앞뒤 내용을 확인해 문제 해결에 필요한 오류 정보는 남기고 개인 정보는 줄이세요.

설정이 안정되면 최근 변경 사항, 변경 이유, 확인 방법, 되돌리는 방법을 간단히 기록하세요. 문제가 생기면 같은 구독을 반복해서 가져오거나 프로그램을 재설치하기보다 마지막으로 정상 동작한 상태를 복구하세요. 자주 묻는 짧은 질문은 초보자 연결 문제 빠른 확인에서 살펴볼 수 있습니다. 복구 후에도 같은 문제가 재현되면 진입점, DNS 해석, 라우팅, 원격 연결 순서로 계속 점검하세요.

9. 고급 설정과 검증 경로

생성된 설정을 살펴본 뒤 직접 수정

GUI에 익숙해지면 클라이언트의 설정 보기나 내보내기 기능으로 생성 결과를 살펴볼 수 있습니다. 인바운드, 아웃바운드, 라우팅, DNS, 로그 항목을 찾아 인터페이스의 옵션 하나가 어떤 설정 필드에 반영되는지 확인하세요. 처음에는 읽기만 하고 바로 수정하지 않는 편이 좋습니다. 클라이언트가 시작할 때 설정 파일을 다시 생성할 수 있으므로 실행 설정을 직접 편집해도 계속 유지된다는 보장은 없습니다. 다음에 서버를 바꾸거나 구독을 업데이트하면 덮어써질 수도 있습니다.

사용자 지정 설정은 인터페이스에서 제공하지 않는 명확한 요구를 해결할 때 적합하며, 기본 연결 흐름을 이해하는 대신 사용할 수는 없습니다. 시작하기 전에 원본 설정을 저장하고 선택한 코어가 해당 구문을 지원하는지 확인한 뒤 최소한으로 수정해 검증하세요. 아웃바운드 태그는 규칙에서 참조하는 이름과 일치해야 하고, 포트는 기존 진입점과 겹치면 안 됩니다. 설정 조각은 필요한 데이터와 구성 요소 없이는 실행되지 않을 수 있습니다. 시작에 실패하면 필드를 계속 추가하지 말고 마지막으로 작동한 설정으로 돌아가세요.

작은 실험으로 설정의 경계 이해

아래는 로컬 SOCKS 인바운드와 직접 연결 아웃바운드만 사용하는 기본 설정 예시입니다. 별도의 테스트 환경에서 진입점과 출구의 관계를 이해하는 용도입니다. 원격 프록시 서버에 연결하지 않으므로 가져온 서버 설정을 대체할 수 없습니다. 예시 포트가 사용 중이 아니고 현재 코어가 해당 필드를 지원하는 경우에만 사용할 수 있습니다. GUI 클라이언트 사용자는 동일한 설정을 인터페이스에서 구성하는 방법을 우선하세요.

{
  "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": {}
    }
  ]
}

이 실험에서는 앱이 지정한 포트에 연결되는지 먼저 확인하고 직접 연결 출구가 작동하는지 살펴봅니다. 원격 인증과 보안 핸드셰이크는 테스트 범위에서 제외하므로 로컬 진입점 문제를 설명하는 데는 적합하지만 원격 서버의 사용 가능 여부를 증명하지는 않습니다. 테스트가 끝나면 원래 설정을 복구해 임시 직접 연결 환경을 일상적인 프록시 환경으로 착각하지 않도록 하세요. 예시의 가치는 변수를 파악하는 데 있으며 모든 예시를 하나의 큰 설정 파일에 복사하는 데 있지 않습니다.

필요에 따라 프로토콜과 전송 방식 학습

프로토콜을 배울 때는 사용자 신원, 전송 방식, 보안 계층, 선택적 확장 등 ‘서로 일치해야 하는 항목’부터 확인하세요. 이어 각 항목이 어느 단계에 관여하는지 이해한 뒤 성능을 살펴보면 됩니다. REALITY와 XTLS Vision은 구체적인 기술 조합이며 사용 가능 여부는 클라이언트 코어와 서버 설정에 따라 달라집니다. 드롭다운 하나만 바꿔 전환할 수 있는 것이 아닙니다. 원리는 REALITY와 XTLS Vision 노트에서 확인하세요.

전송 방식을 비교할 때는 네트워크, 서버 리소스, 테스트 대상, 시간을 가능한 한 동일하게 유지하세요. 대상 서비스마다 응답이 다른 것을 프로토콜 이름 탓으로 바로 돌릴 수는 없습니다. 연결 재사용, UDP 처리, DNS 정책도 사용 경험에 영향을 줄 수 있으므로 항목별로 확인해야 합니다. 실제 필요가 없다면 호환성과 안정성이 확인된 설정을 유지하세요. 이론상 이점을 좇아 여러 단계를 한꺼번에 바꾸면 성능 변화의 원인을 알기 어렵습니다.

고급 설정 결과를 유지 관리 가능한 형태로 정리

고급 설정을 적용한 뒤에는 용도, 사전 조건, 예상 동작, 복구 방법을 기록하세요. 예를 들어 앱별 분할 라우팅을 추가했다면 매칭 조건과 기본 출구를 적습니다. 도메인 정책을 바꿨다면 영향을 받는 DNS 경로를 기록합니다. TUN을 켰다면 LAN 접근과 네트워크 전환 테스트 결과를 남깁니다. 기록은 실제 동작을 설명해야 합니다. 인터페이스 배치가 바뀌면 화면 캡처만으로는 설정의 의도를 알기 어려울 수 있습니다.

최종 회귀 테스트에는 프로그램 재시작, 구독 업데이트, 네트워크 전환, 절전 모드 진입과 복귀, 정상 종료를 포함해 설정이 우연히 유지된 연결 상태에 의존하지 않는지 확인하세요. 특정 순서에서만 작동한다면 그 순서를 영구적인 해결책으로 취급하지 말고 의존성을 살펴봐야 합니다. 요청의 진입점, DNS 해석, 규칙 매칭, 출구를 설명할 수 있고 문제가 생겼을 때 기준 상태를 복구할 수 있다면 입문에서 고급 설정까지의 과정을 제대로 마친 것입니다.

나중에 다시 확인할 때는 문제에 따라 관련 장으로 이동하세요. 재설치는 3장, 서버 업데이트는 4장, 앱이 연결되지 않는 문제는 5장, 대상별 라우팅 오류는 6장, 가상 네트워크 인터페이스 문제는 7장입니다. 가장 짧은 연결 절차를 다시 따라가려면 빠른 사용 가이드로 돌아가세요. 플랫폼이나 설치 형식을 바꾸려면 다운로드 페이지에서 해당 클라이언트를 선택하면 됩니다. 다운로드, 설정, 진단을 각각 구분해 관리하세요.