V2Ray 설치 및 설정 가이드

공통 준비: 설정 단계부터 구분하기

클라이언트, 코어, 연결 매개변수

V2Ray 설정은 세 단계로 나눌 수 있습니다. 클라이언트는 그래픽 인터페이스와 구독 관리, 시스템 연동을 담당하고, 코어는 설정을 읽어 연결을 수립하고 라우팅을 처리합니다. 서버 매개변수에는 원격 주소, 포트, 인증, 전송 방식이 포함됩니다. 클라이언트 설치가 끝났다는 것은 로컬 관리 도구를 사용할 준비가 되었다는 뜻일 뿐, 연결까지 자동으로 제공되는 것은 아닙니다. 시작하기 전에 정식으로 제공받은 구독 주소나 단일 공유 링크를 준비하고, 서비스 이용 기간이 남아 있는지도 확인하세요.

v2rayN은 데스크톱용이고, v2rayNG는 Android에서 널리 쓰이는 Xray 코어 클라이언트입니다. v2flyNG에서는 V2Fly 코어를 선택할 수 있습니다. Project V, V2Fly, Xray는 서로 관련된 기술 생태계이지만 모든 설정을 서로 바꿔 쓸 수 있는 것은 아닙니다. 특정 프로토콜이나 전송 기능을 사용할 수 있는지는 클라이언트의 설정 생성 기능, 실제로 사용하는 코어, 서버 요구 사항에 따라 달라집니다. 설정을 계속 바꾸기보다 먼저 호환되는 조합을 선택하는 편이 효과적입니다.

기기 정보와 기존 네트워크 설정 기록하기

다운로드 전에 운영체제와 프로세서 아키텍처를 확인하세요. 데스크톱에서는 x64와 arm64를 구분하고, macOS에서는 Apple Silicon인지 Intel인지 확인해야 합니다. Linux는 아키텍처뿐 아니라 배포판에서 deb와 rpm 중 어떤 패키지를 사용하는지도 확인하세요. 기기 외관만 보고 판단하거나 호환성 계층을 기본 설치 방법으로 삼지 마세요. 다운로드 페이지에서 플랫폼별 요구 사항을 확인하고, 인터페이스 버전이 헷갈리면 클라이언트 비교를 참고하세요.

현재 다른 프록시 도구, 회사 VPN, 사용자 지정 DNS, 네트워크 필터링 프로그램이 실행 중인지도 기록하세요. 처음 연결을 테스트할 때는 트래픽을 처리하는 프로그램을 하나만 남겨 시스템 프록시나 가상 네트워크 어댑터 충돌을 피하는 것이 좋습니다. 설정을 가져오기 전에 일반 네트워크로 자주 사용하는 사이트에 접속할 수 있는지 확인하세요. 기본 네트워크 연결이 끊겨 있으면 구독 업데이트와 원격 연결도 실패합니다. 이때 프로토콜 매개변수까지 수정하면 변수만 늘어납니다.

구독 주소와 공유 링크는 입력 방식이 다릅니다

https://로 시작하는 주소는 구독 주소일 수도 있고 일반 웹페이지일 수도 있으므로 제공자의 안내를 확인해야 합니다. vmess://, vless:// 등으로 시작하는 주소는 대개 단일 공유 링크이며, 클립보드 가져오기나 해당 가져오기 기능을 사용해야 합니다. 공유 링크를 구독 URL 입력란에 넣거나 안내 페이지를 구독 주소로 사용하지 마세요. QR 코드는 정보를 전달하는 한 가지 방법일 뿐입니다. 스캔한 뒤에도 실제 내용이 어떤 유형인지 확인하세요.

시스템 날짜, 시간대, 자동 시간 설정을 확인하세요. 시간이 크게 어긋나면 TLS 인증서 검증에 영향을 주거나 시간 기반 인증이 실패할 수 있습니다. 이후 로그에서 찾기 쉬운 설정 이름을 지정하세요. 구독 주소에는 개인 식별 정보나 액세스 토큰이 포함될 수 있으므로 화면을 캡처하거나 도움을 요청하기 전에 전체 주소를 가리세요. 출처를 알 수 없는 파싱 사이트에 붙여 넣거나 인증 정보가 담긴 QR 코드를 공개하지 마세요.

첫 연결을 위한 기본 테스트 순서

설정 가져오기, 사용할 서버 선택, 프록시 진입점 하나 활성화, 대상 앱에서 확인하는 순서로 진행하세요. 데스크톱에서는 먼저 시스템 프록시를 사용하고, Android에서는 시스템 VPN 권한을 허용해 연결을 설정하세요. 앱이 시스템 프록시를 사용하지 않는다는 점을 확인한 경우에만 TUN을 살펴보세요. 단계마다 결과를 확인하고 라우팅, DNS, 코어를 한꺼번에 변경하지 마세요. 테스트를 마친 뒤에는 시스템 프록시가 원래대로 복원되었는지도 확인해야 합니다. 남아 있는 설정을 기본 네트워크 문제로 오해할 수 있습니다.

Windows: v2rayN 설치

인터페이스와 실행 환경에 맞는 설치 파일 선택

Windows 다운로드 페이지에서 먼저 안내된 시스템 요구 사항을 확인하세요. v2rayN 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하며, 클래식 WPF 버전은 Windows 데스크톱 방식의 인터페이스를 유지합니다. 두 버전은 서로 다른 연결 서비스가 아니므로 연결을 위해 둘 다 설치할 필요는 없습니다. 처음 사용한다면 다운로드 페이지의 권장 버전을 선택하고, 기존 사용자는 인터페이스, 시스템 지원, 실행 종속성을 고려하세요. 자세한 차이는 데스크톱 버전과 WPF 버전 안내를 참고하세요.

이 페이지의 Windows 다운로드는 x64 패키지입니다. 먼저 시스템의 ‘정보’에서 기기 아키텍처를 확인하세요. 설치 프로그램은 안내에 따라 실행하면 됩니다. 압축 파일을 받았다면 먼저 전체 압축을 푼 다음, 압축 해제된 폴더에서 실행하세요. 압축 프로그램의 미리보기 창에서 바로 실행하지 마세요. 쓰기 권한이 있는 폴더를 사용하면 로그와 설정을 저장하기 편하지만, 이미 사용 중인 프로그램 폴더를 임의로 옮기지는 마세요. 실행 구성 요소가 없다는 안내가 나오면 해당 아키텍처의 종속성을 설치하고, 출처를 알 수 없는 런타임 모음은 반복해서 내려받지 마세요.

구독을 가져오고 현재 서버 확인하기

v2rayN을 열고 ‘구독 그룹 설정’에서 그룹을 추가한 다음, 알아보기 쉬운 이름을 입력하고 전체 구독 주소를 ‘주소(URL)’ 필드에 붙여 넣으세요. 그룹을 활성화하고 저장한 뒤 구독을 업데이트합니다. 아직 연결을 설정하지 않았다면 먼저 ‘프록시를 사용하지 않고’ 업데이트해 볼 수 있습니다. 제공자가 특정 네트워크 경로를 요구한다면 해당 안내를 따르세요. 업데이트가 끝난 뒤에는 알림 창이 닫혔는지만 보지 말고 실제로 설정이 생성되었는지 확인하세요.

가져온 설정에서 사용할 서버를 선택하고 현재 사용 항목으로 지정하세요. 구독 그룹 활성화, 서버 선택, 시스템 프록시 활성화는 서로 다른 작업입니다. 하나라도 빠지면 ‘가져왔는데 사용할 수 없는’ 상태가 될 수 있습니다. 목록이 비어 있다면 구독 관리 섹션으로 돌아가 응답과 형식을 확인하세요. 원래 설정을 덮어쓸 수 있으니 포트, 식별자, TLS 매개변수를 추측해 입력하지 마세요.

먼저 시스템 프록시를 사용하고, TUN 필요 여부 판단하기

‘시스템 프록시’에서 ‘시스템 프록시 자동 설정’을 선택한 다음 테스트할 앱을 종료했다가 다시 여세요. 시스템 프록시는 해당 설정을 지원하는 앱에 로컬 프록시 진입점을 제공할 뿐, 모든 프로세스가 프록시를 사용하도록 강제하지는 않습니다. 브라우저는 되는데 특정 프로그램만 실패한다면 먼저 그 프로그램에 자체 프록시 설정이 있는지 확인하세요. 한 프로그램이 설정을 따르지 않는다고 서버를 사용할 수 없다고 단정하지 마세요. ‘시스템 프록시 해제’는 구독 삭제를 뜻하지도 않습니다.

시스템 프록시를 사용하지 않는 앱의 트래픽도 처리해야 한다면 ‘Tun 모드 활성화’를 시도하세요. 이 기능은 보통 가상 네트워크 인터페이스와 라우팅, 높은 권한을 필요로 하므로 현재 클라이언트의 안내에 따라 권한을 허용해야 합니다. 활성화한 뒤 로그에서 시작 성공 여부를 확인하고 대상 프로그램을 테스트하세요. 스위치가 켜졌다고 네트워크 연결이 반드시 설정된 것은 아닙니다. 실패하면 TUN을 꺼서 기본 상태로 되돌린 다음 권한, 구성 요소, 다른 VPN과의 충돌을 확인하세요. 모든 문제를 해결하려고 항상 높은 권한을 유지하지 마세요.

Windows에서 자주 발생하는 주의 사항

포트가 사용 중이라는 메시지가 나오면 중복 실행된 클라이언트를 종료하고 다른 프록시 프로그램이 있는지 확인하세요. 애플리케이션 설정을 함께 바꾸지 않은 채 포트만 계속 변경하지 마세요. 방화벽 권한은 실제 사용 범위에 맞춰 허용하세요. 일반적으로 공용 네트워크에서 인바운드 연결을 허용할 필요는 없습니다. ‘LAN 연결 허용’은 실제로 공유해야 할 때만 켜세요. 자세한 설치 관련 사항은 Windows 설정 시 자주 하는 실수를 참고하고, 매번 같은 앱으로 다시 테스트해 조건을 일관되게 유지하세요.

macOS: 칩, 권한, 프록시 설정

칩 종류를 확인한 뒤 앱 설치하기

시스템의 ‘이 Mac에 관하여’를 열어 Apple 칩인지 Intel 프로세서인지 확인한 다음, macOS 다운로드 페이지에서 해당하는 v2rayN 데스크톱 버전을 선택하세요. Apple Silicon은 arm64, Intel은 x64에 해당합니다. 운영체제 이름이나 구매 연도만으로 아키텍처를 판단하지 마세요. 호환성 기능으로 실행할 수 있는 패키지라도 가장 적합한 선택이라는 뜻은 아닙니다. 하드웨어에 맞는 설치 파일을 우선 사용하면 이후 권한과 구성 요소를 확인하기도 쉽습니다.

다운로드한 디스크 이미지를 열고 창의 안내에 따라 앱을 ‘응용 프로그램’ 폴더로 옮긴 뒤 해당 폴더에서 실행하세요. 마운트된 이미지에서 계속 실행하면 업데이트, 경로 기록, 권한 설정이 복잡해질 수 있습니다. 시스템에서 실행을 차단하면 먼저 파일이 예상한 다운로드 경로에서 왔는지 확인한 뒤 ‘개인정보 보호 및 보안’의 안내를 살펴보세요. 출처를 확인한 앱에 대해서만 시스템이 제공하는 허용 절차를 진행하세요. 편의를 위해 시스템 보안 검사를 전부 끄는 것은 권장하지 않습니다.

구독 설정을 마치고 앱 종료와 창 닫기 구분하기

구독 그룹 설정에서 이름과 주소를 추가하고 저장한 뒤 구독을 업데이트하세요. 주소를 웹페이지의 버튼에서 복사했다면 앞뒤에 공백이나 줄바꿈이 포함되지 않았는지 확인하세요. 특히 버튼 글자까지 함께 복사하지 않도록 주의해야 합니다. 업데이트가 완료되면 현재 서버를 선택하고 프록시를 테스트하세요. 창을 닫아도 앱은 메뉴 막대에서 계속 실행 중일 수 있습니다. 앱을 완전히 종료하기 전에 시스템 프록시를 복원할지 확인하세요. 데스크톱에서 창이 보이지 않는다고 앱이 종료된 것은 아닙니다.

macOS는 네트워크 서비스별로 네트워크 설정을 저장하므로 Wi-Fi, 유선 네트워크, 기타 인터페이스의 프록시 상태가 서로 다를 수 있습니다. 집에서 설정이 잘되다가 다른 연결 방식에서 작동하지 않으면 구독을 전부 다시 가져오기보다 현재 활성화된 네트워크 서비스를 확인하세요. 시스템 프록시 자동 설정을 켠 뒤에는 시스템 네트워크 설정에서 실제 적용된 값을 확인할 수 있습니다. 자체 프록시 설정이 있는 앱은 시스템 설정을 따르는지, 이전에 저장한 주소를 계속 사용하는지도 확인하세요.

시스템 프록시와 TUN의 권한 범위

처음에는 시스템 프록시만 켜세요. 브라우저 접속을 확인한 뒤 TUN이 필요한지 판단하면 됩니다. TUN은 시스템 권한, 보조 구성 요소 또는 높은 권한이 필요할 수 있으므로 현재 클라이언트의 지원 방식에 따라 달라집니다. 기능을 사용할 수 없다면 해당 빌드의 설명을 확인하고 다른 플랫폼의 서비스 설치 방법을 그대로 따라 하지 마세요. 권한 요청은 방금 수행한 작업과 관련이 있어야 합니다. 출처를 알 수 없는 권한 요청은 승인하지 마세요.

TUN을 활성화한 뒤 도메인 이름이 정상적으로 해석되는지, 로컬 네트워크 기기에 접속할 수 있는지, 잠자기에서 깨어난 후 연결이 복구되는지 확인하세요. 깨어난 뒤 일부 앱만 실패하면 먼저 클라이언트 연결을 끊었다가 다시 연결하고 네트워크 서비스가 전환되었는지 확인하세요. 시스템 네트워크 설정을 전부 삭제하지 마세요. 회사 VPN이나 네트워크 확장 기능이 있다면 각각 단독으로 켜서 테스트하세요. 두 도구가 모두 라우팅을 변경하면 인터페이스에 연결됨으로 표시되어도 트래픽 경로가 제대로 설정되지 않을 수 있습니다.

업데이트, 기기 이전, 연결 복구

업데이트 전에 실행 중인 앱을 종료하고 필요한 설정을 백업한 다음 앱 파일을 교체하세요. 백업 경로는 클라이언트에서 제공하는 설정 폴더 바로가기를 기준으로 확인하고, 고정 경로를 추측하지 마세요. 다른 Mac으로 옮기더라도 기존 기기의 시스템 권한이 파일과 함께 이전되지 않을 수 있으므로 새 기기에서 다시 확인해야 합니다. 앱을 종료한 뒤 네트워크에 문제가 생기면 현재 네트워크 서비스에 로컬 컴퓨터를 가리키는 프록시가 남아 있는지 먼저 확인하세요. 원래 값으로 복원한 뒤 클라이언트 기능을 하나씩 켜서 테스트하면 이전 상태가 새 테스트에 영향을 주지 않습니다.

Linux: 패키지와 데스크톱 환경

패키지 형식과 프로세서 아키텍처 모두 확인

Linux를 설치할 때는 배포판의 패키지 형식과 기기 프로세서 아키텍처 두 가지를 확인하세요. Linux 다운로드 페이지의 deb와 rpm은 서로 다른 배포판 계열의 패키지 형식이고, x64와 arm64는 아키텍처입니다. 시스템에서 파일을 다운로드할 수 있다고 바로 설치할 수 있는 것은 아닙니다. 시스템의 ‘정보’ 화면에서 아키텍처와 배포판 정보를 확인하세요. 여전히 불분명하다면 배포판의 패키지 관리 안내를 먼저 확인하고, 여러 형식을 운에 맡겨 연달아 설치하지 마세요.

데스크톱 패키지 설치 프로그램에서 맞는 패키지를 열고 종속성과 권한 안내를 확인한 뒤 설치하세요. 종속성이 없다면 배포판의 공식 패키지 저장소를 이용하세요. 패키지 관리자의 잠금 파일을 직접 삭제하거나 출처를 알 수 없는 사이트에서 공유 라이브러리를 내려받아 조합하지 마세요. 설치는 되었는데 메뉴에 앱이 보이지 않는다면 데스크톱 세션에 다시 로그인한 뒤 앱 목록을 확인하세요. 이 문서는 그래픽 클라이언트 사용을 중심으로 하며 데스크톱 앱을 백그라운드 시스템 서비스로 바꾸도록 요구하지 않습니다.

구독을 가져오고 로컬 진입점 확인하기

v2rayN을 실행하고 구독 그룹 설정에서 이름과 구독 URL을 입력한 다음 저장하고 업데이트하세요. 현재 서버를 선택한 뒤 데스크톱 프록시를 설정하기 전에 클라이언트가 코어를 정상적으로 실행하는지 확인하세요. Linux 데스크톱 환경과 앱 프레임워크는 다양하므로 ‘시스템 프록시 자동 설정’이 적용되는지는 대상 프로그램이 실제로 설정을 읽는 방식에 따라 다릅니다. 데스크톱 설정 패널에 프록시 주소가 표시되어도 이미 실행 중인 모든 프로세스에 즉시 적용된다는 뜻은 아닙니다.

앱에서 프록시를 직접 설정해야 한다면 클라이언트 화면에서 현재 수신 주소, 포트, 진입점 유형을 확인한 뒤 입력하세요. HTTP 진입점을 SOCKS로 설정하거나 다른 컴퓨터의 포트를 로컬 기본값으로 사용하지 마세요. 이 컴퓨터에서만 사용할 경우 수신 주소는 루프백 범위로 설정하는 편이 적절합니다. 앱에서 연결 거부 메시지가 나오면 원격 인증을 의심하기 전에 코어가 실행 중인지, 수신 포트가 바뀌었는지 확인하세요.

데스크톱 프록시, 환경 변수, TUN을 혼동하지 않기

일부 그래픽 앱은 데스크톱 환경의 프록시 설정을 읽고, 다른 앱은 자체 설정을 사용하며, 일부 명령줄 프로그램은 주로 환경 변수를 읽습니다. 서로 다른 진입점이므로 자동으로 동기화되지 않습니다. 따라서 브라우저는 되는데 터미널 프로그램이 실패하더라도 라우팅 규칙이 잘못되었다는 뜻은 아닙니다. 테스트할 프로그램이 어떤 프록시 방식을 사용하는지 확인한 뒤 해당 진입점을 설정하세요. ‘시스템 프록시가 켜져 있다’는 이유만으로 모든 네트워크 동작을 설명하려 하지 마세요.

TUN은 보통 가상 네트워크 장치에 접근하고 라우팅을 변경해야 하므로 일반 사용자 권한으로는 부족할 수 있습니다. 클라이언트에서 권한 오류가 표시되면 해당 빌드의 통합 방식을 따르세요. 그래픽 데스크톱 전체를 높은 권한으로 계속 실행하지 마세요. 샌드박스 방식으로 설치했거나 제한된 세션을 사용하는 경우에도 네트워크 장치 접근이 영향을 받을 수 있습니다. 활성화에 실패하면 로그에서 처음 나타난 명확한 오류를 보존한 뒤 권한, 시스템 구성 요소, 기존 VPN을 확인하세요. 스위치를 반복해서 눌러도 부족한 조건이 해결되지는 않습니다.

데스크톱 연동과 네트워크 복구

시스템 트레이 아이콘이 보이지 않으면 해당 데스크톱이 트레이 확장 기능을 지원하는지 확인하세요. 아이콘이 없다고 코어가 종료된 것은 아닙니다. 네트워크 전환 후 DNS가 작동하지 않으면 현재 네트워크 관리 구성 요소가 기존 설정을 덮어썼는지 확인한 뒤 클라이언트가 지원하는 방법으로 복구하세요. 여러 DNS 설정 파일을 동시에 직접 수정하지 마세요. 일부 파일은 시스템이 동적으로 생성하므로 다음에 네트워크에 연결할 때 덮어써져 원인을 알기 어려운 문제가 생길 수 있습니다.

앱을 업데이트하기 전에 설정을 저장하고 클라이언트를 종료한 다음 기존과 같은 패키지 관리 방식으로 업그레이드하세요. 출처가 다른 설치 방식끼리 서로 덮어쓰지 않도록 해야 합니다. 삭제 전에 클라이언트에서 설정한 시스템 프록시를 해제하고 TUN을 끄세요. 앱 파일을 제거해도 데스크톱 환경에 저장된 프록시 값은 남을 수 있습니다. 재부팅 후에도 네트워크에 연결할 수 없다면 기존 네트워크 설정부터 복원한 뒤 다시 설치하고 테스트하세요. 복잡한 규칙을 계속 수정하는 것보다 작동하는 기본 설정을 하나 보존해 두는 편이 대체로 시간을 절약합니다.

Android: 설정 가져오기와 VPN 권한

클라이언트와 설치 패키지 아키텍처 선택

Android 다운로드 페이지에서 Xray 코어를 사용하는 v2rayNG를 우선 고려하세요. V2Fly 코어가 필요한 경우에는 v2flyNG를 선택하면 됩니다. 두 클라이언트의 인터페이스와 기능 지원은 완전히 같지 않으며, 이름이 비슷하다는 이유로 모든 매개변수가 그대로 이전된다고 기대하지 마세요. 최신 휴대전화 대부분은 arm64를 사용하지만 시스템 아키텍처를 기준으로 판단해야 합니다. 확인할 수 없다면 다운로드 페이지의 범용 패키지 설명을 참고하세요. 화면 크기로 아키텍처를 판단할 수는 없습니다.

설치 패키지를 열면 시스템에서 현재 브라우저나 파일 관리자가 출처를 알 수 없는 앱을 설치하도록 허용할지 물을 수 있습니다. 권한은 설치를 시작한 앱에만 적용되며 시스템 전체에 적용되는 것은 아닙니다. 설치가 끝난 뒤 필요에 따라 해당 권한을 해제할 수 있습니다. 설치에 실패하면 패키지 아키텍처, 남은 저장 공간, 같은 이름의 기존 앱을 설치한 출처부터 확인하세요. 업데이트 충돌이 발생해도 바로 삭제하지 마세요. 구독과 로컬 설정이 지워질 수 있으므로 먼저 클라이언트가 지원하는 방식으로 필요한 데이터를 백업하세요.

구독, 클립보드, QR 코드에서 가져오기

구독을 추가하려면 구독 그룹이나 구독 설정 메뉴를 열고 이름과 URL을 입력한 뒤 저장하고 업데이트하세요. 인터페이스에 따라 업데이트 메뉴의 위치는 다를 수 있지만, 핵심은 ‘구독 주소를 저장한 뒤 설정을 가져오는 것’입니다. 공유 링크가 하나뿐이라면 ‘클립보드에서 가져오기’와 같은 기능을 사용하세요. QR 코드를 받았다면 스캔 후 가져오는 항목의 유형을 확인하세요. QR 코드가 포함된 화면을 공개 인식 사이트에 업로드하지 마세요. 인증 정보 전체가 들어 있을 수 있습니다.

가져온 뒤 서버 하나를 선택하고 연결 버튼을 누르세요. 처음 연결하면 Android에서 시스템 VPN 권한을 요청합니다. 방금 조작한 클라이언트에서 요청한 것인지 확인하고 승인하세요. 권한을 허용해야 클라이언트가 시스템의 가상 네트워크 인터페이스를 통해 트래픽을 처리할 수 있습니다. 여기서 VPN은 시스템 인터페이스의 종류를 뜻하며 특정 원격 프로토콜을 선택했다는 의미는 아닙니다. 실제 연결은 현재 설정의 프로토콜, 전송 방식, 인증 매개변수에 따라 결정됩니다.

모바일에서 트래픽을 처리하는 방식 이해하기

모바일에서는 데스크톱의 ‘시스템 프록시 자동 설정’ 방식을 그대로 사용할 필요가 없습니다. 일반적인 연결 모드는 Android VPN 서비스를 사용합니다. 앱별 적용 범위, DNS 처리 방식, LAN 우회 여부는 현재 클라이언트에서 제공하는 옵션에 따라 다릅니다. 처음에는 기본 처리 범위로 연결을 확인한 뒤 앱별 규칙을 설정하세요. 그렇지 않으면 특정 앱이 적용 범위에 포함되지 않은 문제를 서버 장애로 오해하기 쉽습니다.

앱별 프록시를 설정했다면 현재 모드가 ‘선택한 앱만 적용’인지 ‘선택한 앱 제외’인지 확인하세요. 두 설정의 의미는 반대입니다. 설정을 바꿀 때마다 연결을 다시 설정하고 대상 앱을 열어 테스트하세요. 일반적으로 시스템 VPN 서비스는 한 번에 하나만 활성화할 수 있습니다. 다른 VPN, 광고 차단, 패킷 캡처 도구가 진입점을 차지할 수 있으므로 테스트할 때는 먼저 종료하세요. 시스템에서 다른 클라이언트를 항상 켜기로 설정했는지도 확인해 연결이 곧바로 대체되지 않도록 하세요.

백그라운드 제한, 네트워크 전환, 연결 복구

화면이 켜져 있을 때는 정상인데 잠금 후 연결이 끊기면 배터리 최적화, 백그라운드 실행, 제조사의 자동 시작 관리 설정을 확인하세요. 기기마다 메뉴 이름은 다르므로 연결 유지가 필요한 클라이언트에만 제한을 완화하고 시스템 절전 기능을 전부 끄지는 마세요. 백그라운드 서비스가 상시 알림을 표시할 수도 있습니다. 알림을 숨기려고 필요한 서비스를 중지하지 마세요. 프로세스가 종료되었다는 로그는 원격 핸드셰이크 실패와 다른 문제이므로 각각 따로 확인해야 합니다.

Wi-Fi와 모바일 네트워크를 전환하면 기존 연결을 다시 설정해야 할 수 있으며 DNS와 네트워크 접근 조건도 달라질 수 있습니다. 먼저 연결을 끊었다가 다시 연결하고 현재 네트워크의 기본 접속이 정상인지 확인한 뒤 구독이나 서버 문제를 살펴보세요. 핫스팟에서 클라이언트가 처리한 트래픽을 전달할 수 있는지는 시스템과 기기 구현에 따라 다릅니다. 휴대전화에서 연결된다고 핫스팟에 연결된 기기도 사용할 수 있는 것은 아닙니다. 종료하기 전에 ‘항상 켜기 VPN’과 ‘VPN 없이 연결 차단’ 같은 시스템 옵션을 확인하세요. 클라이언트를 중지한 뒤 모든 앱의 네트워크 연결이 차단될 수 있습니다.

구독 관리: 주소, 업데이트, 백업

입력 내용의 유형을 확인한 뒤 가져오기 방식 선택

구독 주소를 사용하면 클라이언트가 여러 설정을 가져오고 이후에도 다시 업데이트할 수 있습니다. 공유 링크는 보통 단일 연결 정보를 담고 있습니다. 둘 다 복사나 QR 코드로 전달될 수 있지만 같은 입력란에 넣어서는 안 됩니다. 받은 내용의 유형을 먼저 확인한 뒤 구독 설정이나 공유 링크 가져오기를 선택하세요. 자세한 작동 방식과 메뉴는 공유 링크와 구독 주소의 차이를 참고하세요. 입력 내용이 무엇인지 먼저 파악하면 대부분의 파싱 오류를 피할 수 있습니다.

구독 그룹을 만들 때는 구분하기 어려운 숫자만 연속해서 쓰기보다 출처나 용도를 알아볼 수 있는 이름을 지정하세요. 제공자가 준 전체 경로와 쿼리 매개변수를 그대로 유지하고, 길어 보이는 부분을 임의로 삭제하거나 공개하지 마세요. 메신저에서 복사했다면 한글 문장 부호, 보이지 않는 줄바꿈, 주소 잘림 여부를 확인하세요. 예시 https://example.com/your-sub은 입력란 형식만 보여 줍니다. 설정을 가져올 수 있는 실제 서비스 주소가 아닙니다.

업데이트 실패를 가져오기와 파싱으로 나눠 확인하기

구독 업데이트는 ‘주소 요청’과 ‘응답 내용 읽기’ 두 단계로 진행됩니다. 요청 시간 초과, 도메인 해석 실패, TLS 오류는 첫 번째 단계의 문제입니다. 내용을 내려받았는데 설정이 생성되지 않았다면 형식과 코어 지원 여부를 확인하세요. 상태 코드가 성공이어도 로그인 페이지, 만료 안내, 기타 텍스트가 반환될 수 있으므로 완료 표시만 확인해서는 안 됩니다. 클라이언트 로그에 응답 유형이나 파싱 이유가 표시되면 해당 정보를 우선 확인하세요. 관련 없는 라우팅 옵션을 반복해서 바꾸지 마세요.

업데이트에 직접 연결을 사용할지 기존 프록시를 사용할지는 주소에 접근할 수 있는 경로에 따라 결정하세요. 처음 설치했을 때는 사용 가능한 프록시가 없는 경우가 많으므로 먼저 프록시 없이 업데이트해 볼 수 있습니다. 해당 주소가 이미 설정된 연결을 통해서만 접근 가능하다면 반대로 선택해야 합니다. 두 방식 모두 실패하면 네트워크와 주소 유효성부터 확인하세요. 짧은 간격으로 계속 새로고침하거나 전체 구독 주소를 제삼자에게 보내 테스트하지 마세요. 자세한 확인 절차는 구독 업데이트 실패 및 빈 파싱 결과 문제 해결을 참고하세요.

업데이트 덮어쓰기와 로컬 수정 구분하기

구독 설정은 다음 업데이트 때 다시 생성될 수 있으므로 서버 주소, 이름, 고급 매개변수를 직접 수정해도 계속 유지되지 않을 수 있습니다. 비교 테스트를 하려면 먼저 로컬 설정으로 복사하고 변경 목적을 기록하세요. 테스트용 설정을 구독 원본 항목처럼 계속 사용하지 마세요. 업데이트 후에는 현재 사용 항목이 여전히 존재하는지도 확인해야 합니다. 제공자가 설정을 삭제하거나 이름을 바꾸고 내용을 수정할 수 있어 이전 선택이 새 항목으로 자동 연결되지 않을 수 있습니다.

자동 업데이트는 정상적으로 가져오는 것을 확인한 구독에 적합하지만, 처음에는 수동으로 테스트하세요. 클라이언트에서 업데이트 간격을 설정할 수 있다면 필요에 맞춰 지정하고, 연결 문제를 해결하려고 자주 업데이트하지 마세요. 업데이트는 제공자가 현재 반환하는 설정을 가져올 뿐 로컬 포트 충돌을 해결하거나 잘못된 시스템 프록시를 자동으로 해제하지는 않습니다. 업데이트 성공 후에도 현재 서버, 프록시 진입점, 대상 앱을 확인해야 합니다. ‘구독 업데이트 완료’를 연결 성공의 증거로 간주하지 마세요.

백업 내용과 개인정보 보호

백업 전에 내보내기 기능에 어떤 내용이 포함되는지 확인하세요. 연결 설정만 내보내는 기능도 있고 구독 주소와 환경설정까지 포함하는 기능도 있습니다. 시스템 권한은 보통 함께 이전되지 않습니다. 백업 파일은 신뢰할 수 있는 로컬 위치에 보관하고, 다른 사람과 공유하기 전에 주소, 사용자 식별 정보, 인증 항목을 삭제하세요. 기기를 바꾼 뒤에는 먼저 설정 하나를 가져와 테스트한 다음 라우팅과 기타 사용자 설정을 복원하세요. 구독 정보가 유출되었다고 의심되면 제공자에게 문의해 주소나 인증 정보를 변경하세요. 로컬 그룹을 삭제하는 것만으로 이미 유출된 주소가 무효화되지는 않습니다.

프록시와 라우팅: 진입점과 출구 구분하기

시스템 프록시, TUN, 라우팅은 서로 다른 역할

시스템 프록시는 이를 지원하는 앱이 요청을 로컬 수신 포트로 전달하도록 합니다. TUN은 가상 네트워크 인터페이스를 통해 처리 범위에 포함된 트래픽을 받습니다. 이후 라우팅 규칙이 해당 요청에 사용할 출구를 결정합니다. 이 세 가지는 서로 다른 단계에 있으므로 대신 사용할 수 없습니다. TUN을 켜도 모든 요청이 원격으로 전달되는 것은 아니며, 글로벌 라우팅을 선택해도 클라이언트에 전혀 전달되지 않은 앱이 자동으로 프록시를 사용하지는 않습니다. 문제를 확인할 때는 먼저 ‘요청이 들어왔는가’를 살피고 그다음 ‘들어온 요청이 어디로 갔는가’를 확인하세요.

처음 설정할 때는 클라이언트가 제공하는 라우팅 프리셋부터 사용하세요. 예를 들어 ‘중국 본토 우회(Whitelist)’는 로컬 규칙 리소스와 실제 설정을 바탕으로 매칭합니다. 모든 도메인의 지리적 위치를 정확히 판단한다는 뜻은 아닙니다. 규칙 파일, DNS 결과, 코어 동작이 최종 경로에 영향을 줍니다. 먼저 기본 프리셋을 테스트하고 필요한 규칙만 조금씩 추가하세요. 출처가 다른 규칙을 여러 개 바로 합치면 우선순위 덮어쓰기나 태그 불일치가 생길 수 있습니다.

규칙은 순서대로 매칭되며 출구 태그가 있어야 합니다

라우팅 규칙은 일반적으로 순서대로 매칭됩니다. 앞쪽의 범위가 넓은 규칙이 뒤에서 처리하려던 트래픽을 먼저 잡을 수 있습니다. 규칙을 작성하기 전에 도메인, 대상 주소, 포트, 앱 범위 중 무엇을 기준으로 구분할지 정하세요. 아래는 Xray/V2Ray 형식의 라우팅 예시로, 매칭된 도메인을 direct라는 출구로 보내는 방법을 보여 줍니다. 완전한 설정이 아니므로 기존 라우팅 구조에 넣어야 하며, 해당 출구와 규칙 리소스가 이미 있어야 합니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

geosite:cn은 로컬 geosite 데이터의 도메인 목록을 참조하므로 해당 리소스가 없으면 작동하지 않습니다. outboundTag는 이미 존재하는 출구를 참조하는 값이지, 영문 단어를 적으면 기능이 자동으로 생기는 설정이 아닙니다. 클라이언트에서 생성한 태그는 예시와 다를 수 있으므로 실제 설정을 기준으로 확인하세요. 그래픽 라우팅 편집기를 사용할 때는 다른 도구에서 내보낸 필드 구조를 섞지 말고 편집기에서 기존 출구를 선택하는 편이 좋습니다.

DNS와 규칙 매칭을 함께 확인하기

도메인 기준 매칭과 IP 기준 매칭은 필요한 조건이 다릅니다. 클라이언트가 대상 IP만 받는 경우 일부 도메인 규칙은 적용되지 않을 수 있습니다. 먼저 도메인을 조회한 뒤 주소 목록과 매칭하는 방식이라면 DNS 결과가 매칭에 영향을 줍니다. 규칙을 확인하는 대신 DNS 서버를 반복해서 바꾸지 마세요. 요청이 클라이언트에 들어올 때 어떤 정보를 포함하는지 확인하고 현재 도메인 정책과 DNS 조회 경로를 함께 살펴야 같은 웹사이트의 요청이 서로 다른 출구를 사용하는 이유를 파악할 수 있습니다.

LAN 접근도 별도로 고려해야 합니다. 프린터, 가정용 저장 장치, 라우터 관리 페이지는 보통 원격을 거칠 필요가 없지만 관련 트래픽이 먼저 TUN으로 들어갈 수 있습니다. 모든 라우팅을 끄기보다 클라이언트의 LAN 우회 설정이나 명시적 규칙을 사용하세요. 회사 내부 도메인은 전용 DNS에 의존할 수 있으므로 공개 DNS로 바꾸면 오히려 작동하지 않을 수 있습니다. 내부 네트워크 문제가 발생하면 먼저 기존 DNS 조건을 복원하고 이름이 올바르게 해석되는지 확인한 뒤 프록시 경로를 조정하세요.

전체 설정을 바꾸는 대신 작은 범위로 검증하기

한 번에 규칙 하나만 추가하고 대상, 예상 출구, 테스트 결과를 기록하세요. 테스트 전에 연결을 다시 설정하고 필요하면 대상 앱도 재시작하세요. 기존 연결이 새 규칙에 따라 항상 경로를 다시 선택하는 것은 아닙니다. 웹페이지 접속 여부보다 로그에 표시되는 매칭 정보가 라우팅 동작을 더 잘 보여 줍니다. 페이지가 열려도 다른 경로를 사용했을 수 있습니다. 새 규칙이 제대로 작동하는지 확인한 뒤 안정된 설정으로 저장하고 테스트 과정의 규칙은 정식 설정에 남기지 마세요.

규칙을 바꾼 뒤 전체 연결이 작동하지 않으면 먼저 이전 프리셋으로 돌아가 연결이 다시 설정되는지 확인한 뒤 추가한 부분을 비교하세요. JSON 쉼표와 배열 구조, 리소스 이름, 태그 참조를 중점적으로 살펴보고 코어와 구독을 동시에 바꾸지 마세요. 용어를 확인하려면 용어 설명을 참고하고, 첫 연결을 설정하려면 입문 가이드로 돌아가세요. 고급 규칙의 목적은 이미 작동하는 연결을 필요에 맞게 나누는 것입니다. 기본 네트워크, 올바른 인증, 유효한 구독을 대신하지 않습니다.

설정 문제 해결: 증상에 따라 범위 좁히기

현재 상태를 기록한 뒤 가까운 항목부터 확인

문제가 발생하면 어떤 작업을 했는지, 현재 네트워크와 사용 중인 설정, 처음 나타난 명확한 오류를 기록하세요. 단서를 잃을 수 있으니 구독을 지우거나 클라이언트를 재설치하지 마세요. 기본 네트워크 연결, 시스템 시간, 로컬 코어, 수신 진입점, 현재 서버, 원격 매개변수, 복잡한 라우팅과 DNS 순으로 확인하는 것이 좋습니다. 한 번에 변수 하나만 바꾸고 이전 단계의 결과를 기록해야 실제로 어떤 변경이 효과가 있었는지 알 수 있습니다.

클라이언트 화면은 열리지만 코어가 시작되지 않았다면 어떤 서버도 로컬 진입점을 통해 사용할 수 없습니다. 이때는 설정 필드가 지원되지 않거나 파일 접근 권한이 제한되어 있거나 수신 포트가 이미 사용 중인 등 시작 오류를 확인하세요. 브라우저에서 로컬 프록시 연결에 실패하는 문제와 로그에 표시된 원격 핸드셰이크 시간 초과는 서로 다른 단계의 문제입니다. 모든 현상을 ‘노드 연결 안 됨’으로 뭉뚱그리지 말고 먼저 로컬 서비스가 정상적으로 수신하는지 확인한 뒤 원격 연결을 테스트하세요.

핸드셰이크 실패와 시간 초과를 구분해 확인하기

로그에 인증이나 핸드셰이크 오류가 표시되면 서버 요구 사항을 하나씩 확인하세요. 프로토콜 유형, 서버 주소, 포트, 사용자 식별자, TLS, 전송 방식, 필요한 경로와 서비스 이름을 대조해야 합니다. 주소는 연결 대상이고 TLS 서버 이름은 인증과 핸드셰이크에 사용되므로 서로 다를 수 있습니다. 추측해서 바꿔 쓰지 마세요. WebSocket 경로와 gRPC 서비스 이름도 같은 필드에 넣을 수 없습니다. 대소문자와 앞쪽 슬래시 등은 원래 설정을 기준으로 확인하세요.

연결 시간 초과가 발생하면 현재 네트워크에서 대상 경로에 접근할 수 있는지, 특정 설정만 실패하는지, 네트워크를 바꿨을 때 증상이 달라지는지 먼저 확인하세요. 같은 구독의 모든 설정이 실패한다면 로컬 진입점과 공통 매개변수를 우선 점검하세요. 하나만 실패한다면 해당 서비스의 상태와 전송 요구 사항을 확인하세요. TLS 오류를 가리려고 인증서 검증을 끄지 말고 시스템 시간, 도메인, 설정 출처를 먼저 확인하세요. 전체 확인 순서는 노드 연결 시간 초과 단계별 확인을 참고하세요.

연결은 됐지만 앱에서 사용할 수 없는 경우

‘연결됨’은 보통 특정 서비스나 인터페이스가 시작되었다는 뜻이지 모든 앱의 요청이 성공했다는 뜻은 아닙니다. 브라우저는 되는데 다른 프로그램이 실패한다면 해당 프로그램의 프록시 진입점과 처리 범위를 확인하세요. 도메인만 실패하고 IP 주소로는 접속할 수 있다면 DNS를 살펴보세요. TUN을 켠 뒤 일반 네트워크에도 문제가 생기면 TUN을 끄고 시스템 프록시 모드에서 복구되는지 확인하세요. 이렇게 비교하면 가상 인터페이스 문제와 원격 연결 문제를 구분할 수 있으므로 처음부터 전체 설정을 다시 만들 필요가 없습니다.

웹페이지의 일부 콘텐츠가 로드되지 않는다면 여러 도메인, 기존 연결 캐시, 서로 다른 출구 규칙이 원인일 수 있습니다. 먼저 새 테스트 창에서 재현한 뒤 로그에서 실패한 요청의 대상 주소를 확인하세요. 주소 표시줄의 기본 도메인만 보고 규칙을 수정하지 마세요. 일부 앱은 자체 프록시 설정이나 장기 연결을 유지하므로 클라이언트 설정을 바꾼 뒤 재시작해야 할 수 있습니다. 앱별 프록시를 설정했다면 대상 앱이 제외되었는지, 제외 모드가 예상과 반대로 설정되었는지도 확인하세요.

복구, 문제 문의, 이후 관리

복구할 때는 먼저 추가한 규칙과 TUN을 끄고 시스템 프록시와 DNS를 되돌려 기본 네트워크가 정상인지 확인하세요. 저장해 둔 안정 설정으로 연결을 다시 설정한 다음 사용자 지정 기능을 하나씩 복구하세요. 클라이언트를 업데이트하기 전에 작동 상태를 기록하고 설정을 백업하세요. 업데이트 후에는 기본 연결부터 확인하고, 한 번에 코어, 구독, 라우팅 방식을 모두 옮기지 마세요. 한 단계 더 걸리더라도 작업을 나누면 되돌릴 경로를 명확하게 유지할 수 있습니다.

다른 사람에게 도움을 요청할 때는 운영체제, 클라이언트 이름, 실제 사용 중인 코어, 오류가 발생한 단계, 민감 정보를 가린 로그를 제공하면 됩니다. 구독 주소, 사용자 식별자, 인증 매개변수, 개인 네트워크 정보는 가리고 오류 유형과 관련 설정 이름은 남기세요. 메뉴 위치가 궁금하면 해당 플랫폼 섹션을, 형식이 궁금하면 구독 관리를, 네트워크 경로가 궁금하면 프록시와 라우팅을 확인하세요. 먼저 문제를 한 단계로 좁힌 뒤 재설치 여부를 결정하는 편이 전체 설정을 처음부터 다시 하는 것보다 대체로 확실합니다.