V2Ray 초보자부터 고급 활용까지
클라이언트 설정 완벽 가이드

핵심 개념: 설정 계층부터 구분하기

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

GUI 클라이언트는 설정을 입력하고 관리하는 도구라고 이해하면 됩니다. v2rayN은 구독을 관리하고 노드를 선택해 실행 설정을 만들며, 해당 코어를 호출합니다. 프로토콜 연결과 트래픽 전달은 코어가 처리합니다. 서버는 연결의 반대편에 있으며 클라이언트와 같은 프로토콜 및 인증 매개변수를 사용해야 합니다. 클라이언트는 무료로 다운로드할 수 있지만, 설치만으로 사용할 수 있는 서버 설정이 자동으로 제공되지는 않습니다. 사용을 시작하기 전에 출처가 명확하고 유효한 노드 정보나 구독 주소를 준비하세요.

Project V는 관련 프록시 기술 생태계의 출발점이며, V2Fly는 V2Ray의 커뮤니티 개발을 이어가고 있습니다. Xray는 별도의 관련 코어 개발 경로입니다. sing-box도 일부 클라이언트에서 사용할 수 있는 프록시 코어지만 V2Ray의 다른 이름은 아닙니다. 코어마다 설정 구조와 기능 지원, 매개변수 해석이 다릅니다. GUI에서 일부 옵션을 공통으로 표시하더라도 모든 설정을 어느 코어에서나 그대로 실행할 수 있다는 뜻은 아닙니다.

프로토콜, 전송 방식, 보안 매개변수를 함께 이해하기

VMess, VLESS, Trojan, Shadowsocks는 프록시 프로토콜을 선택할 때 사용하는 이름입니다. TCP, WebSocket, gRPC 등은 연결에 사용하는 전송 방식입니다. TLS와 REALITY는 연결 보안과 관련된 메커니즘이므로 프로토콜 이름과 혼동하면 안 됩니다. 노드 주소와 포트가 맞더라도 전송 경로, 서버 이름, 보안 매개변수가 일치하지 않으면 연결에 실패할 수 있습니다. 가져온 뒤에는 매개변수를 온전히 유지하고 이름이 비슷하다는 이유만으로 임의로 바꾸지 마세요.

VLESS를 예로 들면 노드를 식별할 때 서버 주소, 포트, 사용자 ID, 전송 방식, 보안 설정을 함께 확인해야 합니다. TLS를 사용하면 서버 이름이 필요할 수 있고, REALITY를 사용하면 해당 공개 키와 짧은 ID 등의 매개변수가 일치해야 합니다. VLESS 자체가 완전한 암호화 연결 방식인 것은 아닙니다. 보안 계층을 사용할지, 어떤 조합을 적용할지는 서버 설정에 따라야 합니다. 다른 노드의 매개변수를 가져와 섞어 쓰지 마세요.

트래픽 흐름에 따라 설정 위치 찾기

일반적으로 요청은 앱에서 시작해 클라이언트로 들어온 뒤, 라우팅 규칙에 따라 출구가 선택되고, 코어가 서버에 연결한 다음 서버가 목적지에 접근합니다. 시스템 프록시와 TUN은 트래픽이 클라이언트로 들어오는 방식을 주로 결정합니다. 라우팅 규칙은 들어온 트래픽을 직접 연결, 프록시 또는 차단 중 무엇으로 처리할지 정하고, 노드 매개변수는 프록시 연결 성립 여부에 영향을 줍니다. DNS는 도메인 이름을 해석하며 규칙 매칭과 실제 연결 주소에도 영향을 줄 수 있습니다. 각 계층을 구분하면 문제를 해결할 때 노드 목록만 들여다보지 않아도 됩니다.

이 장의 목표는 모든 용어를 외우는 것이 아니라 현재 구성을 설명할 수 있는 것입니다. 어떤 클라이언트를 사용하고 어떤 코어를 호출하는지, 노드 프로토콜은 무엇인지, 앱이 어떤 경로로 연결되는지, 기본 라우팅은 무엇인지 정리해 보세요. 이 항목들을 짧게 기록해 두면 이후 변경 시 한 번에 한 계층만 수정할 수 있습니다. 낯선 용어는 용어집에서 확인하세요. 오류가 나타나면 실행, 해석, 핸드셰이크, 목적지 접근 중 어느 단계에 해당하는지 먼저 판단한 뒤 점검할 항목을 정하세요.

클라이언트 선택: 운영체제와 설정 요구에 맞추기

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

Windows, macOS, Linux 데스크톱 사용자라면 이 가이드의 구독 그룹, 시스템 프록시, 라우팅 설정을 그대로 따라가기 편한 v2rayN을 우선 고려하세요. 다운로드 전에 운영체제 종류와 프로세서 아키텍처를 확인한 뒤 해당 배포 패키지를 선택해야 합니다. 운영체제 이름이 같아도 설치 파일이 모두 호환되는 것은 아닙니다. 예를 들어 x64와 arm64는 서로 다른 프로세서 명령어 집합을 대상으로 합니다. 실행되지 않는다면 네트워크 설정을 바꾸기 전에 먼저 패키지의 지원 범위를 확인하세요.

Windows 다운로드 페이지에는 Desktop과 클래식 WPF 두 가지 선택지가 있습니다. Desktop은 크로스 플랫폼 인터페이스를 사용해 여러 데스크톱 운영체제에서 비슷한 방식으로 쓰고 싶은 사용자에게 적합합니다. WPF는 기존 Windows 인터페이스를 유지해 해당 방식에 익숙한 사용자에게 알맞습니다. 두 패키지는 주로 인터페이스와 배포 방식이 다르며, 어느 쪽이 특정 노드에서 더 빠르다는 뜻은 아닙니다. 실행 시 필요한 런타임, 인터페이스 항목, 설정 저장 방식은 실제 배포 패키지의 안내를 확인하세요. 두 폴더의 프로그램 파일을 섞어 쓰지 마세요.

Android는 기본 선택과 호환 대안을 구분

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 고려하고, V2Fly 코어를 사용하는 v2flyNG는 해당 코어와의 호환성이 필요한 경우 대안으로 선택하세요. 두 앱 모두 노드를 가져오고 연결을 관리할 수 있지만 모든 공유 링크, 전송 매개변수, 고급 기능이 완전히 같다고 볼 수는 없습니다. 기존 설정이 특정 코어 기능에 의존한다면 가져오기 전에 대상 클라이언트가 해당 조합을 지원하는지 확인하세요. 이름이 비슷하다는 이유로 앱을 바꾸면 프로토콜 지원 문제를 구독 오류로 오해할 수 있습니다.

Android 설치 패키지는 보통 arm64와 범용 버전 중에서 선택합니다. 비교적 최신인 대다수 스마트폰은 arm64 지원 여부를 먼저 확인하고, 아키텍처를 알기 어렵거나 호환성 문제가 있다면 범용 버전의 지원 범위를 살펴보세요. 범용 버전이라고 연결 품질이 더 좋은 것은 아니며, 주된 차이는 지원하는 아키텍처의 범위입니다. 설치 전에 현재 파일 출처의 앱 설치를 시스템에서 허용하는지도 확인하세요. 설치가 끝난 뒤 권한을 승인하는 과정은 별도이며, 설치 성공이 프록시 실행을 의미하지는 않습니다.

기능 비교 전 실제 작업부터 정리

기능 개수를 비교하기보다 필요한 작업을 구체적으로 정리하는 편이 효과적입니다. 브라우저에만 프록시를 적용하려면 시스템 프록시나 앱 자체의 프록시 설정부터 확인하세요. 시스템 프록시를 사용하지 않는 프로그램까지 연결해야 한다면 TUN을 살펴보고, 앱별로 트래픽을 나누려면 대상 플랫폼의 앱별 라우팅 지원을 확인하세요. 각각 다른 시스템 기능에 의존합니다. 클라이언트에 스위치가 표시되어도 운영체제 권한, 네트워크 환경, 코어 조합이 활성화 조건을 충족한다는 뜻은 아닙니다.

클라이언트를 고를 때는 유지 관리 비용도 고려하세요. 기기에서 이미 안정적으로 사용하는 설정이 있다면 이전 전에 구독 출처, 라우팅 정책, 특수 매개변수를 기록하고 새 클라이언트에서 같은 설정을 구성할 수 있는지 확인해야 합니다. 내보낸 파일은 다른 클라이언트에서 바로 복원되지 않을 수 있으므로 원본 구독이나 표준 공유 링크로 다시 구성하는 편이 좋습니다. 자세한 비교는 클라이언트 선택 가이드에서, 실제 설치 파일은 다운로드 페이지에서 확인하세요. 이 장을 마칠 때는 우선 사용할 클라이언트 하나를 정하고, 먼저 작동하는 기준 설정을 만든 뒤 교체 필요성을 검토하세요.

설치 및 실행: 먼저 기본 작동 상태 만들기

아키텍처, 설치 위치, 권한 확인

클라이언트 다운로드 페이지에서 운영체제에 맞는 배포 패키지를 선택하세요. Windows는 시스템 정보에서 시스템 종류를 확인하고, macOS는 기기 정보에서 칩을 확인할 수 있습니다. Linux는 아키텍처와 패키지 관리 형식을 모두 확인해야 합니다. 파일 확장자만 보고 기기에 맞는지 판단하지 마세요. 다운로드가 끝나면 설치하거나 압축을 푼 뒤 메인 프로그램을 실행하세요. 압축을 풀어 실행해야 하는 패키지는 압축 파일 미리보기에서 바로 열지 마세요. 상대 경로, 리소스 파일, 설정 저장에 문제가 생길 수 있습니다.

Windows에서는 클라이언트 전용 폴더를 따로 만들어 서로 다른 배포 패키지가 같은 위치의 파일을 덮어쓰지 않도록 하세요. 현재 사용자가 설정을 저장할 수 있는 폴더인지 확인하고, 특히 처음 설정할 때 종료 후에도 변경 사항이 남아 있는지 확인해야 합니다. 편의를 위해 항상 높은 권한으로 실행할 필요는 없습니다. 추가 권한이 필요한 기능을 사용할 때만 클라이언트 안내에 따라 처리하세요. 런타임이 없다는 메시지가 표시되면 오류에 맞는 종속성을 설치하고, 다른 PC의 런타임 파일을 무작정 복사하지 마세요.

macOS에서는 칩에 맞는 설치 항목을 선택해 시스템 안내에 따라 적절한 위치에 놓고 실행하세요. 시스템이 실행을 차단하면 먼저 파일 출처와 시스템 메시지를 확인한 뒤 보안 설정에서 정식 승인 절차를 따르세요. Linux는 배포판에 맞는 deb 또는 rpm 패키지를 선택하고 시스템 패키지 관리자를 통해 종속성을 해결해야 합니다. 그래픽 환경, 권한 승인 방식, 가상 네트워크 어댑터 지원은 배포판에 따라 다를 수 있습니다. 실행 실패와 네트워크 연결 실패를 각각 기록하고 하나의 막연한 연결 문제로 묶지 마세요.

첫 실행에서는 필수 항목만 확인

메인 화면이 열리면 설정을 정상적으로 저장할 수 있는지, 코어가 실행되는지, 로컬 수신 주소와 포트가 충돌하지 않는지 먼저 확인하세요. 수신 포트는 앱이 클라이언트에 연결하는 입구이며 서버 포트와는 용도가 다릅니다. 로그에 주소가 이미 사용 중이라고 표시되면 다른 프록시 프로세스를 종료하거나 로컬 수신 설정을 변경한 뒤 재시작해 확인하세요. 정체를 모르는 시스템 프로세스를 삭제하거나 여러 클라이언트를 같은 포트에서 동시에 실행하지 마세요. 그러면 이후 테스트 결과를 판단하기 어려워집니다.

첫 실행에서는 시스템 프록시와 TUN을 끈 상태로 유지하고 설정 하나를 가져온 다음, 클라이언트가 제공하는 연결 테스트나 프록시를 명시적으로 설정한 앱으로 확인하세요. 이렇게 하면 코어 작동 여부와 시스템 트래픽 유입 여부를 분리할 수 있습니다. 화면은 정상인데 코어가 반복해서 종료된다면 실행 로그에서 처음 나타난 오류를 확인하고, 설정 비호환, 리소스 파일 누락, 권한 부족, 포트 충돌을 중점적으로 살펴보세요. 창이 계속 열려 있다는 사실만으로 백그라운드 프록시 서비스가 정상 실행 중인지 알 수는 없습니다.

실행 및 종료 상태 확인

Android 앱을 설치한 뒤 처음 연결하면 시스템 VPN 권한 요청이 나타납니다. 이는 시스템 네트워크 인터페이스로 트래픽을 처리하는 데 필요한 권한이지, 서버에 연결되었다는 뜻은 아닙니다. 권한을 요청한 앱이 맞는지 확인한 뒤 클라이언트 상태를 살펴보세요. 기기에서 이미 다른 VPN 세션을 사용 중이라면 보통 둘 중 하나를 선택해야 합니다. 데스크톱에서도 다른 네트워크 도구의 프록시 설정이 남아 있을 수 있습니다. 첫 문제 해결 단계에서는 이런 도구를 잠시 중지해 새 클라이언트가 정상 실행되더라도 기존 연결 경로의 영향을 받지 않도록 하세요.

마지막으로 클라이언트를 직접 종료한 뒤 다시 열어 구독 그룹과 환경 설정이 유지되는지 확인하세요. 종료 후 시스템 프록시가 복구되는지, 로컬 수신이 꺼진 상태에서도 기본 네트워크에 접근할 수 있는지도 점검해야 합니다. 설치 단계의 완료 기준은 프로그램 실행, 설정 저장, 코어 실행 오류 없음, 실행과 중지 상태의 구분입니다. Windows 인터페이스와 종속성에 관한 자세한 내용은 Windows 설치 과정과 자주 발생하는 문제에서 확인하세요. 설치가 안정되기 전에 복잡한 트래픽 분기를 추가하지 마세요.

구독 및 노드: 지속적으로 업데이트할 설정 출처 만들기

먼저 어떤 종류의 링크인지 확인

구독 주소는 여러 설정을 가져오는 데 사용하며, 이후에도 같은 출처에 접속해 업데이트합니다. 공유 링크는 보통 단일 노드 정보를 담고 있으며, 해당 프로토콜 이름으로 시작하는 경우가 많습니다. 가져오기 경로도 다릅니다. 구독 주소는 구독 그룹에 넣고, 단일 노드 링크는 클립보드나 공유 링크 가져오기 기능을 사용하세요. 브라우저에서 열리는 주소라고 해서 구독 주소인 것은 아닙니다. 계정 페이지나 안내 페이지일 수도 있습니다. 가져오기 전에 출처의 설명을 확인하고, 로그인 페이지 주소를 클라이언트가 바로 해석할 설정으로 착각하지 마세요.

v2rayN에서 구독 그룹을 만들고 출처를 알아볼 수 있는 이름을 입력한 뒤 전체 주소를 붙여 넣으세요. 복사할 때 프로토콜, 경로, 쿼리 매개변수가 모두 포함되었는지 확인하세요. 특히 물음표 뒤의 내용을 빠뜨리거나 공백, 줄바꿈, 한국어 문장 부호를 함께 넣지 않도록 주의해야 합니다. 저장 후 해당 그룹의 구독을 업데이트하고 노드가 표시되는지 확인하세요. 그룹 이름은 로컬 관리용이며 서버 인증에는 사용되지 않습니다. 이름을 바꿔도 만료된 주소나 인증 정보가 무효화된 문제는 해결되지 않습니다.

현재 주소에 접근할 수 있는지에 따라 업데이트 방법 선택

구독 업데이트에 프록시를 사용할지는 현재 네트워크와 주소 접근 가능 여부에 따라 결정하세요. 사용할 수 있는 프록시가 아직 없다면 우선 프록시 없이 업데이트를 시도하세요. 직접 연결이 네트워크 경로의 영향을 받고 정상 작동하는 노드가 이미 있다면 프록시를 통한 업데이트를 시도할 수 있습니다. 두 방식은 구독 내용을 가져오는 경로가 다를 뿐 구독 형식을 복구하는 옵션은 아닙니다. 서버에서 로그인 페이지, 오류 페이지, 빈 내용을 반환한다면 경로를 바꿔도 해결되지 않을 수 있으므로 주소 권한과 출처 상태를 확인해야 합니다.

업데이트에 실패해도 기존 노드를 바로 삭제하지 마세요. 먼저 로그에서 연결 시간 초과, 이름 해석 실패, 인증 거부, 콘텐츠 해석 오류 중 무엇이 발생했는지 확인하세요. 앞의 두 오류는 가져오는 경로 문제일 가능성이 높고, 뒤의 두 오류는 출처 권한이나 콘텐츠 형식과 관련되었을 수 있습니다. 설정 제공자에게 주소 상태를 문의할 수 있지만 구독 주소 전체를 공개 게시판에 붙여 넣지 마세요. 구독의 쿼리 매개변수는 접근 자격 증명으로 쓰일 수 있습니다. 노출되었다면 채팅 기록만 삭제하지 말고 제공자의 절차에 따라 교체하세요.

업데이트 성공 후 실제 사용 가능 여부 확인

노드 목록을 성공적으로 가져왔다는 것은 콘텐츠를 읽고 해석할 수 있다는 뜻일 뿐, 모든 노드가 연결된다는 의미는 아닙니다. 매개변수가 완전하고 현재 용도에 맞는 노드 하나를 선택해 활성 노드로 지정한 뒤 실제 요청을 테스트하세요. 목록에 표시되는 이름은 단순한 라벨이므로 프로토콜, 보안 방식, 사용 가능한 지역을 정확히 나타내지 않을 수 있습니다. 단일 노드를 오래 보관할 경우 출처와 용도를 기록해 두세요. 원래 출처에서 더 이상 서비스를 제공하지 않는다면 표시 이름을 바꾸거나 같은 링크를 다시 가져와도 연결이 복구되지 않습니다.

구독 노드와 수동 노드는 따로 관리하는 편이 좋습니다. 일부 클라이언트는 그룹을 업데이트할 때 해당 그룹의 항목을 새로 구성하므로 구독에서 생성된 노드의 특수 매개변수를 직접 수정하면 다음 업데이트에서 덮어써질 수 있습니다. 로컬 변경이 필요하다면 클라이언트가 변경 사항을 유지하는 기능을 제공하는지 확인하거나, 별도 설정으로 복사해 출처를 표시하세요. 구독 업데이트가 모든 로컬 라우팅 설정을 대체한다고 단정해서도, 활성 노드에 전혀 영향을 주지 않는다고 단정해서도 안 됩니다. 업데이트 후 현재 선택된 노드와 주요 매개변수를 확인하세요.

안정적인 출처를 확보한 뒤 자동 업데이트를 고려하세요. 업데이트 주기는 제공자의 이용 조건에 맞추는 것이 좋습니다. 너무 자주 업데이트한다고 더 빨리 최신 상태가 되는 것은 아니며 접근 제한이 걸릴 수도 있습니다. 대규모 업데이트 뒤에는 노드 수가 갑자기 달라지지 않았는지, 활성 노드가 바뀌지 않았는지, 실제 요청이 정상적으로 완료되는지 확인하세요. 단일 노드와 구독의 구조 차이는 공유 링크와 구독 주소 안내를 참고하세요. 업데이트 오류는 구독 업데이트 실패 자가 점검 목록을 따라 먼저 가져오기 결과를 확인한 뒤 콘텐츠 호환성을 살펴보세요.

프록시 모드: 앱이 연결되는 경로부터 확인

시스템 프록시는 진입 경로를 제어하며 분기 자체를 정하지 않습니다

시스템 프록시는 앱이 읽는 시스템 네트워크 설정입니다. 이를 켜면 설정을 따르는 앱이 요청을 로컬 프록시 수신 주소로 전달합니다. 시스템 프록시를 읽지 않는 프로그램은 자체적으로 직접 연결할 수 있습니다. 따라서 시스템 프록시를 켰다고 기기의 모든 트래픽이 처리되는 것은 아니며 모든 요청이 원격 노드를 사용하는 것도 아닙니다. 클라이언트에 들어온 뒤 직접 연결할지는 라우팅이 결정합니다. 진입 경로와 출구를 구분하면 앱이 아예 클라이언트에 연결되지 않는 문제를 전체 라우팅 설정으로 해결하려는 일을 막을 수 있습니다.

v2rayN에는 시스템 프록시 설정 지우기, 시스템 프록시 자동 설정, 시스템 프록시 변경 안 함, PAC 모드 등의 옵션이 있습니다. 자동 설정은 해당 시스템 설정이 클라이언트의 로컬 진입 주소를 가리키도록 합니다. 지우기는 관련 프록시 설정을 제거하고, 변경 안 함은 현재 시스템 설정을 유지한다는 의미이지 직접 연결을 강제한다는 뜻은 아닙니다. PAC는 해당 메커니즘을 지원하는 앱이 스크립트 결과에 따라 진입 경로를 선택하도록 합니다. 실제로 영향을 받는 시스템 항목은 운영체제와 클라이언트 구현에 따라 다르므로 전환 전에 기존 네트워크 설정을 기록해 두세요.

앱 하나로 진입 경로가 적용되는지 확인

먼저 TUN을 끈 상태로 두고 사용할 노드를 선택해 코어를 실행한 다음 시스템 프록시 자동 설정을 켜세요. 시스템 프록시를 따르는 브라우저에서 새 요청을 보내고 클라이언트 액세스 로그에 해당 목적지가 나타나는지 확인합니다. 기존 연결의 재사용이 판단을 방해하지 않도록 필요하면 연결을 닫거나 브라우저를 다시 여세요. 관련 요청이 전혀 기록되지 않는다면 원격 노드를 바꾸거나 전송 매개변수를 수정하기보다 앱 자체 프록시 옵션, 시스템 설정, 로컬 수신 주소를 먼저 점검하세요.

앱에서 HTTP 또는 SOCKS 프록시를 직접 입력할 수 있다면 클라이언트 화면에 표시된 수신 유형, 주소, 포트를 확인해 입력하세요. 가이드에 나온 예시 숫자를 그대로 사용하지 마세요. HTTP 수신을 SOCKS 수신처럼 임의로 사용할 수는 없습니다. 혼합 수신을 지원하는 클라이언트에서도 해당 기능이 실제로 활성화되어 있는지 확인해야 합니다. 앱에서 별도의 프록시를 설정했다면 시스템 프록시 스위치가 해당 앱의 동작을 결정하지 않을 수 있습니다. 앱별 설정을 기록해 두면 같은 기기에서 일부 프로그램만 영향을 받는 이유를 문제 해결 시 설명할 수 있습니다.

PAC, 전체 프록시, 중국 본토 우회는 서로 다른 계층입니다

PAC는 앱이 연결되기 전에 일부 경로를 선택하고, 클라이언트 내부의 전체 프록시나 중국 본토 우회 같은 라우팅 프리셋은 트래픽이 들어온 뒤 출구를 결정합니다. 두 규칙이 겹치면 일부 직접 연결 요청은 진입 계층에서 이미 경로가 결정되어 코어 로그에 표시되지 않을 수 있습니다. 처음에는 관찰하기 쉬운 진입 경로 하나만 사용한 뒤 코어 라우팅으로 트래픽을 분기하세요. PAC가 필요하다면 스크립트 출처와 업데이트 방법, 실제 지원 범위를 확인하고 여러 자동 판단 규칙을 동시에 겹치지 마세요.

프록시가 작동하는지 확인할 때는 클라이언트 아이콘 색상만 보지 말고 실제 서비스 요청을 보내세요. 한 목적지에 접근할 수 있다는 사실은 해당 목적지와 현재 요청 경로가 작동한다는 뜻일 뿐입니다. 다른 앱은 다른 프로토콜, DNS 경로, 독립 프록시 설정을 사용할 수 있습니다. 브라우저는 되는데 다른 프로그램이 실패한다면 먼저 진입 경로 차이를 비교하세요. 페이지 일부 리소스가 실패한다면 각 리소스 도메인의 라우팅과 이름 해석을 확인하세요. 메인 페이지가 열린다고 모든 연결이 정상이라고 단정할 수는 없습니다.

업무용 네트워크는 관리 정책에 따라 프록시 설정이 정해져 있을 수 있으므로 변경 전에 기기 권한과 조직 요구사항을 확인하세요. 개인 프록시 설정을 수정이 허용되지 않는 환경에 그대로 적용하지 마세요. 종료, 절전, 네트워크 전환 후에도 시스템 진입 경로가 예상대로 유지되는지 확인해야 합니다. 이 장의 목표는 어떤 앱이 연결되는지, 진입 주소를 어디에서 가져오는지, 클라이언트를 종료한 뒤 어떻게 복구하는지 설명할 수 있는 것입니다. 더 많은 트래픽을 처리해야 할 때 TUN 장으로 넘어가고, 시스템 프록시가 작동하지 않는 문제를 모두 노드 오류로 돌리지 마세요.

라우팅 분기: 필요한 규칙만으로 목적을 표현

프리셋 하나로 설명 가능한 기본 동작 구성

먼저 현재 용도에 맞는 라우팅 프리셋을 선택하고 필요한 사용자 규칙을 조금씩 추가하세요. 전체 프록시는 클라이언트에 들어온 트래픽을 대체로 프록시 출구로 보내지만 앱이 클라이언트에 진입하는지 여부까지 바꾸지는 않습니다. 중국 본토 우회는 보통 도메인 및 주소 규칙으로 일부 목적지를 직접 연결하며, 실제 범위는 프리셋의 내용과 규칙 리소스에 따라 달라집니다. 프리셋 이름만으로 세부 동작을 단정하지 마세요. 선택한 뒤 실제 규칙과 기본 출구를 확인하고, 어떤 규칙에도 매칭되지 않은 트래픽이 어디로 가는지 특히 살펴보세요.

라우팅 규칙은 보통 순서대로 매칭되며 먼저 일치한 규칙이 이후 처리를 결정합니다. 범위가 지나치게 넓은 규칙이 앞에 있으면 뒤의 세부 규칙을 가릴 수 있습니다. 수정하기 전에 어떤 도메인을 직접 연결하고 어떤 목적지를 프록시로 보내며 어떤 연결을 차단할지 적어 두세요. 그런 다음 적절한 매칭 기준을 선택합니다. 도메인, 목적지 주소, 포트, 앱 정보가 항상 모두 제공되는 것은 아닙니다. 현재 진입 경로에서 주소만 확인할 수 있다면 도메인 규칙을 추가해도 적용되지 않을 수 있으므로 도메인 정보가 어디에서 오는지 확인해야 합니다.

설정 조각을 이해하되 실행 파일 전체를 그대로 붙여 넣지 않기

아래는 Xray 형식의 라우팅 조각으로 루프백 및 사설 주소 직접 연결, 지정 도메인 프록시 연결의 기본 문법을 보여 줍니다. 완전한 클라이언트 설정이 아니며 참조하는 출구 태그가 실제 설정에 존재해야 합니다. GUI 클라이언트는 다른 태그를 사용할 수도 있습니다. 먼저 인터페이스에서 같은 의도를 표현하고, 사용자 설정을 직접 작성해야 할 때는 현재 코어 문서를 확인하세요. sing-box는 규칙 구조가 다르므로 이 내용을 다른 코어의 설정 필드에 그대로 붙여 넣을 수 없습니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "::1/128", "fc00::/7"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      }
    ]
  }
}

이 예시에서 도메인 접미사 매칭은 해당 도메인과 그 하위 도메인을 포함합니다. 같은 문자가 들어간 주소라면 무엇이든 일치한다는 뜻은 아닙니다. 주소 규칙은 목적지 주소를 얻어 매칭할 수 있을 때만 적용됩니다. 도메인을 원래 이름으로 처리하는 정책이라고 해서 모든 도메인을 주소 규칙에 맞추려고 직접 해석하는 것은 아닙니다. 따라서 LAN 서비스는 명확한 로컬 도메인 또는 주소 규칙을 우선 사용하고 실제 접근 방식으로 테스트하세요. 사설 주소 범위를 입력했으니 모든 진입 경로에 자동 적용될 것이라고 생각하지 마세요.

DNS와 스니핑이 규칙에서 볼 수 있는 정보에 미치는 영향

DNS는 도메인 이름을 주소로 바꾸는 방식을 결정하고 라우팅은 연결에 사용할 출구를 정합니다. 서로 영향을 주지만 같은 설정은 아닙니다. 해석된 주소는 네트워크, 해석기, 시점에 따라 달라질 수 있으므로 전체 도메인 규칙 대신 임시 주소를 사용하면 안정적이지 않을 수 있습니다. 스니핑은 일부 프로토콜 데이터에서 목적지 이름을 식별할 수 있지만 모든 트래픽을 알아내지는 못하며 만능 해결책도 아닙니다. 사용하기 전에 목적을 이해하고 호환성을 확인하세요. 관련 옵션을 모두 한꺼번에 켜지 마세요.

새 규칙을 테스트할 때는 먼저 명확한 목적지 하나를 정하고 변경 전 출구를 기록한 뒤 규칙을 추가하고 연결을 다시 만드세요. 로그에 규칙이나 출구가 표시되면 실제 매칭 결과를 확인합니다. 연결 정보만 표시되는 인터페이스라면 제어 가능한 목적지와 요청 결과를 함께 살펴보세요. 테스트가 계속 이전 경로를 사용한다면 연결 재사용, 앱 캐시, 규칙 순서를 먼저 확인한 뒤 이름 해석 차이를 검토하세요. 한 번에 한 항목만 바꾸고 결과를 확인한 다음 다음 항목을 수정해야 어떤 변경이 영향을 줬는지 알 수 있습니다.

트래픽 분기 규칙은 적고 명확하게 유지하는 것이 중요합니다. 더는 필요하지 않은 임시 규칙을 정기적으로 삭제하고 예외 규칙을 둔 이유를 기록하세요. 규칙 리소스를 업데이트한 뒤 자주 사용하는 목적지와 LAN 접근을 다시 테스트합니다. 문제가 생기면 마지막으로 정상 작동한 프리셋으로 되돌린 다음 사용자 규칙을 하나씩 추가하세요. 복잡성을 높이느라 설정의 설명 가능성을 포기하지 마세요. 학습 단계의 목표는 기본 출구, 예외 조건, 매칭 순서를 설명하고 실제 요청으로 규칙이 적용됨을 확인하는 것입니다. 저장 완료 메시지만 확인해서는 충분하지 않습니다.

TUN 모드: 안정적인 설정에서 트래픽 처리 범위 넓히기

가상 네트워크 인터페이스의 역할부터 이해

TUN은 가상 네트워크 인터페이스를 통해 시스템이 전달하는 네트워크 데이터를 받아 시스템 프록시를 읽지 않는 앱도 프록시 처리 경로로 들어올 수 있게 합니다. 트래픽 유입 범위를 넓히는 기능이지 만료된 구독, 잘못된 인증, 연결할 수 없는 서버를 자동으로 해결하지는 않습니다. 활성화 전에 같은 노드가 기본 프록시 경로에서 정상 작동하는지 확인해야 합니다. 그렇지 않으면 진입 경로, 라우팅, 원격 연결 문제를 한꺼번에 다루게 됩니다. 브라우저만 사용하는 간단한 환경이라면 이 계층이 꼭 필요하지 않을 수도 있습니다.

데스크톱 운영체제에서는 관리자 권한, 서비스 지원, 추가 네트워크 권한이 필요할 수 있으며 구체적인 절차는 운영체제와 배포 패키지에 따라 달라집니다. 클라이언트 안내에 따라 진행하고 출처를 알 수 없는 범용 드라이버를 다운로드하지 마세요. 활성화 후 가상 인터페이스가 생성되었는지, 코어가 계속 실행되는지, 라우팅 설정에서 즉시 오류가 발생하지 않는지 확인하세요. Android 클라이언트는 보통 시스템 VpnService를 통해 트래픽을 처리합니다. 권한 화면과 데스크톱 TUN 스위치는 방식이 다르므로 설정을 항목별로 그대로 옮겨 적용할 수 없습니다.

프록시 연결이 다시 자기 자신을 거치지 않도록 하기

TUN에서는 프록시 서버 자체의 연결을 올바르게 처리해야 합니다. 그렇지 않으면 트래픽이 가상 인터페이스에 반복해서 다시 유입될 수 있습니다. GUI 클라이언트가 보통 이를 자동으로 처리하지만 여러 클라이언트를 동시에 사용하거나 라우팅을 직접 바꾸거나 다른 VPN을 함께 실행하면 예상과 달라질 수 있습니다. 처음 켤 때는 다른 네트워크 처리 도구를 중지하고 진입 경로를 하나만 사용하세요. 로그에 연결 반복, 요청 적체, 실행 직후 네트워크 중단이 나타나면 먼저 TUN을 꺼서 기본 상태로 되돌린 뒤 출구와 시스템 라우팅을 확인하세요.

시스템 프록시를 함께 켤지는 현재 클라이언트가 권장하는 조합을 따르세요. 두 기능을 함께 사용한다고 반드시 문제가 생기는 것은 아니지만 경로를 파악하기 어려워질 수 있습니다. 테스트할 때는 시스템 프록시를 끄고 원래 시스템 프록시를 따르지 않는 앱 하나를 골라 TUN 활성화 전후의 액세스 로그를 비교할 수 있습니다. 클라이언트에서 자동 라우팅, 엄격 라우팅, 인터페이스 선택 등의 옵션을 제공한다면 우선 기본값을 유지하고 작동 방식을 이해한 뒤 조정하세요. 코어마다 이름이 같은 옵션의 동작이 다를 수 있으므로 이름만 보고 설정을 옮기면 안 됩니다.

DNS, LAN, 절전 후 복구까지 확인

TUN은 DNS를 가로채거나 별도의 해석 경로를 사용하는 경우가 많습니다. 활성화 후 IP 주소로는 접속되지만 도메인으로는 실패한다면 먼저 DNS 경로를 확인하세요. 도메인은 해석되지만 연결이 시간 초과된다면 출구 선택과 서버 연결을 점검합니다. 합성 주소 방식을 사용할 때는 이에 맞는 매핑과 라우팅 절차가 함께 필요합니다. 그런 주소를 목적지의 실제 주소로 간주해 영구 규칙에 넣지 마세요. 사내 도메인, LAN 기기 이름, 특정 DNS 해석기가 필요한 서비스를 각각 테스트하세요.

검증 목록에는 일반 웹페이지, 별도 프록시 설정이 필요했던 앱, LAN 기기 접근, 절전 후 복구를 포함하세요. Wi-Fi나 유선 네트워크를 전환한 뒤에는 출구 인터페이스도 확인해야 합니다. 특정 네트워크에서만 실패한다면 해당 네트워크의 DNS, 포털 로그인, 관리 정책이 관련되었을 수 있습니다. 먼저 네트워크 자체에서 요구하는 로그인 절차를 완료한 뒤 트래픽 처리를 활성화하세요. 시스템이 네트워크 설정을 정상적으로 받지 못하는 상태에서 코어를 계속 재시작하면 네트워크 접속 문제를 클라이언트 오류로 오해할 수 있습니다.

Android에서는 백그라운드 제한도 확인해야 합니다. 시스템 절전 정책이 화면이 꺼진 뒤 앱을 중지해 연결이 간헐적으로 끊길 수 있습니다. 모든 권한을 무제한으로 허용하기보다 기기 설정에서 필요한 백그라운드 실행을 허용하세요. 앱별 설정에서는 목록이 포함 목록인지 제외 목록인지 구분해 대상 앱을 반대 범위에 넣지 않도록 합니다. 자세한 내용은 VPN 권한, 배터리 절약, 앱별 프록시 안내를 참고하세요. 이 장의 목표는 처리 범위를 설명하고 자주 쓰는 상황에서 검증하며 종료 후 정상 네트워크 상태로 돌아갈 수 있는 것입니다.

유지 관리: 기본 상태를 보존하고 계층별로 문제 해결

업데이트 전에 복구 가능한 상태 기록

유지 관리는 업데이트 버튼을 누르는 것만이 아닙니다. 현재 클라이언트 종류, 사용하는 코어, 구독 그룹, 활성 노드, 라우팅 프리셋을 기록하고 필요한 로컬 설정을 백업하세요. 구독 주소와 내보낸 설정에 접근 자격 증명이 포함될 수 있으므로 관리되는 안전한 위치에 보관하고 공개 클라우드 저장소나 게시판에 올리지 마세요. 백업을 실제로 복원할 수 있는지도 확인해야 합니다. 가져오기 위치, 파일에 포함된 항목, 복원 시 현재 설정이 덮어써지는지 알고 있어야 합니다. 문제가 발생한 뒤 빈 폴더만 저장했다는 사실을 알아차리지 않도록 하세요.

클라이언트, 코어, 구독, 규칙 리소스 업데이트는 서로 다른 작업입니다. 클라이언트 업데이트는 인터페이스와 설정 관리 방식을 바꿀 수 있고, 코어 업데이트는 프로토콜 구현과 실행 동작에 영향을 줍니다. 구독 업데이트는 출처에서 제공하는 노드를 새로 가져오며 규칙 리소스 업데이트는 라우팅 매칭에 영향을 줍니다. 한 번에 한 종류씩 업데이트하고 실행 후 로그와 자주 사용하는 목적지를 확인한 다음 다음 항목을 진행하세요. 모두 한꺼번에 바꾸면 프로그램, 노드, 규칙 중 무엇을 되돌려야 하는지 파악하기 어렵고 일시적인 네트워크 변동을 업데이트 오류로 오해할 수 있습니다.

연결할 수 없을 때 진입부터 계층별로 좁혀 가기

먼저 기본 네트워크가 정상인지 확인하고 클라이언트와 코어가 실행 중인지 살펴보세요. 다음으로 앱 트래픽이 들어오는지 확인한 뒤 라우팅과 원격 연결을 점검합니다. 액세스 기록이 전혀 없다면 진입 경로를 확인하세요. 기록은 있지만 서버 연결이 시간 초과되면 주소, 포트, 네트워크 경로를 우선 살펴보세요. 핸드셰이크가 거부된다면 인증, 전송, 보안 매개변수를 확인해야 합니다. 시간에 따른 인증이나 인증서 검증 오류라면 시스템 시간도 점검하세요. 모든 오류를 재설치로 해결하려 하지 마세요. 설치 과정은 문제가 발생한 계층과 관련이 없을 수 있습니다.

같은 노드가 앱마다 다르게 작동한다면 시스템 프록시, 앱별 프록시, DNS, 프로토콜 요구 사항을 먼저 비교하세요. 모든 노드가 실패한다면 로컬 수신, 코어 실행, 네트워크 연결, 공통 DNS 설정처럼 공유되는 요소를 중점적으로 확인합니다. 노드 하나만 실패한다면 해당 노드의 서버 상태와 전용 매개변수를 확인하세요. 같은 기기에서 네트워크를 바꾸자 문제가 해결되었다면 네트워크 경로 차이를 조사할 필요가 있습니다. 한 번의 테스트만으로 원인을 단정할 수는 없으니 재현 조건을 기록하세요.

속도 측정 결과와 로그 증거 이해하기

TCPing은 보통 목적지 포트까지의 연결 상태 일부만 보여 주며, 프록시 핸드셰이크와 목적지 요청까지 성공한다는 보장은 아닙니다. 실제 연결 지연 시간은 프록시를 통해 요청을 완료하는 상황에 더 가깝지만 테스트 목적지의 영향을 받습니다. 다운로드 속도 측정은 대역폭, 서버 부하, 대상 사이트, 로컬 네트워크에 좌우되며 트래픽도 사용합니다. 한 가지 숫자만 보고 노드를 선택하지 마세요. 실제 요청이 안정적으로 완료되는지 먼저 확인한 다음 같은 조건에서 여러 번 측정해 비교하세요. 측정 방식이 서로 다른 결과를 섞지 않도록 주의해야 합니다.

로그를 읽을 때는 마지막 요약 메시지보다 실패 시점 전후를 잘라 첫 번째 구체적인 오류를 확인하세요. 시간 초과, 연결 거부, 이름 해석 실패, 인증 실패는 각각 다른 단계를 가리킵니다. 로그를 공유하기 전에 구독 주소, 사용자 ID, 전체 서버 정보, 로컬의 민감한 경로를 삭제하세요. 문제 해결에 필요한 오류 유형과 작업 순서만 남기면 됩니다. 너무 긴 로그는 중요한 맥락을 숨길 수 있습니다. 재현 가능한 짧은 기록이 화면 전체를 캡처한 이미지보다 유용한 경우가 많습니다.

유지 관리가 끝나면 종료 후 복구 상태, 시스템 프록시 설정, 자주 사용하는 앱을 다시 확인하세요. 정상 작동이 확인된 기본 설정은 보관하되 만료된 노드와 임시 규칙을 계속 쌓아 두지 마세요. 속도 측정 원리는 TCPing, 실제 연결 지연, 다운로드 속도 측정의 차이에서, 자주 발생하는 문제는 자주 묻는 질문에서 확인할 수 있습니다. 유지 관리의 목표는 설정 화면의 스위치를 최대한 많이 켜 두는 것이 아니라 변경 사항을 기록하고 문제를 계층별로 찾으며 복구 절차를 실행할 수 있는 것입니다.

고급 활용 경로: 연결에서 설정 설명까지

1단계: 반복 가능한 테스트로 시행착오 줄이기

고급 활용을 위해 처음부터 완성된 설정 파일을 작성할 필요는 없습니다. 먼저 자주 사용하는 상황에 맞춰 반복 가능한 테스트 방법을 만드세요. 앱 하나, 목적지 하나, 진입 경로 하나를 고정하고 노드, 라우팅, DNS 설정을 기록한 뒤 요청 결과를 관찰합니다. 설정을 바꿀 때는 변수 하나만 수정하고 결과를 확인한 다음 계속 진행하세요. 이렇게 쌓은 지식은 특정 조합이 우연히 작동한 경험에 의존하지 않고 다른 노드와 네트워크에도 적용할 수 있습니다. 작동 이유를 설명할 수 없다면 기록은 남기되 추측을 일반적인 결론으로 적지 마세요.

DNS가 어디까지 영향을 주는지 단계적으로 익히고 시스템 해석, 앱 자체 해석, 코어 해석을 구분하세요. 도메인이 클라이언트에 들어오기 전에 이미 주소로 바뀌는지, 규칙이 원래 도메인 이름을 필요로 하는지, DNS 요청 자체는 어떤 출구를 사용하는지 살펴봅니다. 처음부터 복잡한 해석 경로를 만들기보다 각 계층이 담당하는 부분을 확인하세요. 여러 주소 유형이 있는 목적지는 시스템 네트워크가 해당 주소로 실제 연결할 수 있는지도 점검해야 합니다. 주소를 해석할 수 있다는 사실이 반드시 접속할 수 있다는 뜻은 아닙니다.

2단계: 실제 요구를 중심으로 코어 차이 이해하기

Xray, V2Fly, sing-box 중 무엇을 사용할지는 노드 프로토콜, 전송 방식 조합, 라우팅 기능, 클라이언트 지원을 함께 고려해 결정해야 합니다. 코어를 바꾸기 전에 유지해야 할 기능을 정리하고 클라이언트가 필요한 설정을 정확하게 생성할 수 있는지 확인하세요. 인터페이스의 선택 항목은 일부 기능만 연결할 수 있고 사용자 설정이 GUI 설정을 우회할 수도 있습니다. 코어를 바꾼 뒤 모든 옵션이 같은 방식으로 유지된다고 생각하지 마세요. 프로세스가 실행되는지만 확인하지 말고 연결, 이름 해석, 라우팅을 다시 검증해야 합니다.

매개변수를 익힐 때는 정상 작동이 확인된 노드 하나를 기준으로 항목별로 살펴보세요. 주소와 포트는 서버를 찾는 데 쓰이고 인증 정보는 사용자 확인에, 전송 매개변수는 데이터 전달 방식에, 보안 매개변수는 예상한 보호 방식을 설정하는 데 사용됩니다. TLS 서버 이름은 임의로 입력하는 메모가 아니며 REALITY 공개 키도 직접 생성해 바꿀 수 있는 표시 필드가 아닙니다. 각 항목은 서버 측 조건과 맞아야 합니다. 이 경계를 이해하면 오류가 클라이언트의 설정 표현 능력 때문인지 설정 자체가 불완전해서인지 판단할 수 있습니다.

3단계: 설정 구조와 검증 절차 익히기

전체 설정을 읽을 때는 먼저 로그, 인바운드, 아웃바운드, 라우팅, DNS 영역을 구분하고 태그 참조 관계를 추적하세요. 인바운드는 어떤 트래픽을 받을지, 아웃바운드는 어떻게 연결하거나 처리할지, 라우팅은 어떤 조건을 어떤 아웃바운드에 연결할지를 정의합니다. 태그는 설정 내부에서 참조하는 이름일 뿐이므로 이름만으로 동작을 단정할 수 없습니다. 실제로 어떤 프로토콜과 설정에 연결되는지 확인하세요. 다른 코어를 사용할 때는 구조를 새로 파악하고 한 설정 형식의 필드 이름을 다른 형식에 그대로 적용하지 마세요.

사용자 설정을 작성하기 전에 작업 설정의 복사본을 만들고 별도의 테스트 환경에서 진행하세요. JSON 문법, 필드의 적용 범위, 참조 관계를 확인한 뒤 해당 코어로 의미 검증을 해야 합니다. 문법이 맞다는 것은 형식을 해석할 수 있다는 뜻일 뿐, 필드 지원이나 서버 매개변수의 정확성을 보장하지 않습니다. GUI 클라이언트는 실행 시 설정 파일을 다시 생성할 수 있으므로 덮어써질 임시 파일을 직접 수정하지 마세요. 클라이언트가 명시적으로 제공하는 사용자 설정 기능을 사용하고 어떤 GUI 설정이 계속 적용되는지 기록하세요.

나만의 최소 운영 가이드 만들기

안정적인 절차를 짧은 문서로 정리하세요. 설치 및 가져오기 방법, 기본으로 사용할 모드, 문제 발생 시 먼저 확인할 계층, 트래픽 처리를 해제하고 네트워크를 복구하는 방법, 백업할 설정을 기록합니다. 예외 규칙에는 용도를 표시하고 변경할 때마다 복구 방법을 남기세요. 기기를 옮길 때는 최소한의 연결부터 다시 구성하고 구독 그룹과 자주 쓰는 라우팅을 복원한 뒤 마지막에 TUN을 활성화합니다. 이 순서는 이 페이지의 흐름과 같으며 기존 환경의 숨겨진 의존성을 새 시스템에 한꺼번에 가져오는 일을 막아 줍니다.

마지막으로 네 가지 질문에 답할 수 있어야 합니다. 트래픽은 어디로 들어오는가, 왜 이 출구를 선택하는가, 도메인은 어디에서 해석되는가, 문제가 생기면 어떻게 기본 상태로 되돌리는가. 답을 로그와 실제 요청으로 확인할 수 있어야 유지 관리 가능한 설정을 갖춘 것입니다. 이후에는 필요에 따라 용어집, 자주 묻는 질문, 주제별 블로그를 참고하세요. 모든 고급 기능을 한꺼번에 켤 필요는 없습니다. 가장 짧은 작업 절차를 다시 확인하고 싶다면 빠른 시작 가이드로 돌아가 먼저 정상 작동 상태를 복구한 뒤 기능을 단계별로 추가하세요.