V2Ray Windows 버전 초급부터 고급까지

핵심 개념: 클라이언트, 코어와 프록시 설정

세 계층을 먼저 구분한 뒤 시작하세요

v2rayN, v2rayNG, v2flyNG는 모두 그래픽 클라이언트입니다. 클라이언트는 서버 정보를 저장하고 구독을 관리하며 코어 설정을 생성하고 시스템 프록시, 라우팅, 로그 등의 기능을 제공합니다. Xray와 V2Fly는 프록시 코어로, 설정에 따라 연결을 만들고 프로토콜과 전송을 처리하며 도메인 및 IP 라우팅을 수행합니다. 두 개념을 혼동해서는 안 됩니다. 클라이언트에서 ‘시작’을 눌렀다고 그래픽 화면이 모든 네트워크 트래픽을 직접 처리하는 것은 아니며, 클라이언트가 설정을 정리한 뒤 코어를 호출하는 방식입니다. 문제를 해결할 때는 먼저 문제가 화면 관리, 코어 실행, 원격 설정 중 어디에서 발생했는지, 아니면 애플리케이션이 로컬 프록시에 전혀 연결되지 않았는지 판단해야 합니다.

세 번째 계층은 프록시 설정입니다. 서버 주소, 포트, 사용자 식별자, 프로토콜, 전송 방식, TLS, 라우팅과 DNS 등의 매개변수를 정의합니다. 클라이언트는 이 데이터를 관리하는 도구일 뿐이며, 실제 사용 가능 여부는 각 필드가 서로 맞는지에 달려 있습니다. 구독은 설정을 일괄 배포하는 방식이지 클라이언트나 코어 자체가 아닙니다. 구독 업데이트가 성공했다는 것은 클라이언트가 내용을 받아 파싱했다는 뜻일 뿐, 모든 설정이 연결에 성공한다는 의미는 아닙니다. 반대로 구독 업데이트 실패가 로컬 코어 손상을 뜻하는 것도 아닙니다. 구독 주소, 네트워크 진입 경로 또는 응답 형식이 원인일 수 있습니다.

요청은 어떤 경로를 거치는가

브라우저로 웹페이지에 접속하는 경우를 예로 들면 일반적인 전체 경로는 다음과 같습니다. 브라우저가 시스템 프록시 설정을 읽고 요청을 v2rayN의 로컬 HTTP 또는 SOCKS 수신 포트로 전달합니다. 코어는 라우팅 규칙에 따라 직접 연결 또는 프록시 출구를 선택하고, 프록시를 선택하면 서버 설정에 따라 원격 연결을 만듭니다. 어느 한 단계라도 끊기면 겉으로는 그저 ‘웹페이지를 열 수 없음’으로 보일 수 있습니다. 따라서 처음부터 설정을 계속 바꾸지 마세요. 먼저 로컬 수신 포트가 존재하는지 확인하고, 애플리케이션이 해당 포트로 트래픽을 보내는지 확인한 다음, 코어 로그에 요청이 기록되는지 보고 마지막으로 원격 매개변수와 네트워크 조건을 점검해야 합니다.

시스템 프록시와 라우팅도 서로 다른 계층입니다. 시스템 프록시는 ‘시스템 설정을 따르는 애플리케이션이 어떤 요청을 클라이언트에 넘기는가’를 결정하고, 라우팅 규칙은 ‘코어가 요청을 받은 뒤 어떤 출구를 사용할지’를 결정합니다. 터미널 프로그램이 시스템 프록시를 읽지 않는다면 라우팅 규칙을 열 번 바꿔도 결과는 달라지지 않습니다. 요청이 코어에 들어오지 않았기 때문입니다. 마찬가지로 TUN을 켠다고 잘못된 서버 주소, TLS 매개변수 또는 사용자 식별자가 자동으로 수정되지는 않습니다. 이 경계를 명확히 이해하는 것이 이후 설정 간 간섭을 줄이는 출발점입니다.

되돌릴 수 있는 학습 환경 만들기

처음 설정할 때는 신뢰할 수 있는 출처의 서버 설정 하나만 남기고 기본 라우팅을 사용하며 TUN과 DNS 변경은 잠시 보류하세요. 먼저 브라우저가 시스템 프록시를 통해 반복 가능한 검증을 완료하도록 한 뒤 기능을 하나씩 추가합니다. 각 단계가 끝날 때마다 클라이언트의 주요 옵션, 로컬 포트와 현재 설정 이름을 기록하세요. 이후 분할 라우팅에 문제가 생겨도 클라이언트를 다시 설치하지 않고 ‘단일 설정, 기본 라우팅, 시스템 프록시’ 기준으로 되돌릴 수 있습니다. 재설치는 대개 화면이나 파일만 정리할 뿐 구독 내용, 원격 매개변수와 애플리케이션 자체 프록시 설정을 자동으로 고치지 못합니다.

클라이언트 선택: 플랫폼과 코어 요구 사항으로 판단하기

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

Windows, macOS, Linux의 기본 선택은 v2rayN입니다. 데스크톱 그래픽 인터페이스에서 구독, 설정, 시스템 프록시, 라우팅, DNS, TUN과 로그를 통합 관리할 수 있습니다. Windows 다운로드 페이지에는 데스크톱 버전과 클래식 WPF 버전이 함께 제공됩니다. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하므로 여러 데스크톱 시스템에서 비슷한 조작 방식을 원하는 사용자에게 적합하고, 클래식 WPF 버전은 Windows 기본 데스크톱 기술을 사용하므로 기존 v2rayN의 메뉴 위치에 익숙한 사용자에게 적합합니다. 둘 다 클라이언트 선택의 문제이며 프로토콜이나 코어 유형과 혼동해서는 안 됩니다.

데스크톱 패키지를 선택할 때는 프로세서 아키텍처와 패키지 형식도 확인해야 합니다. 일반적인 Windows 데스크톱은 x64를 선택하고, macOS는 Apple Silicon인지 Intel 칩인지 먼저 확인하세요. Linux는 x64와 arm64 외에도 배포판에 맞춰 deb 또는 rpm을 선택해야 합니다. 아키텍처가 맞지 않으면 설치 프로그램이 실행되지 않거나 지원되지 않는 형식이라는 메시지가 표시되며, 실행 직후 종료될 수도 있습니다. 이 문제는 클라이언트 실행 계층에서 발생하므로 구독 주소나 서버 설정과 무관합니다. 클라이언트 다운로드 페이지로 돌아가 플랫폼 항목을 다시 확인하세요.

Android에서 v2rayNG와 v2flyNG 선택하기

Android에서는 v2rayNG를 우선 권장합니다. Xray 코어를 주요 실행 구성 요소로 사용하며 일반적인 프로토콜, 라우팅과 앱별 프록시 설정에 적합합니다. v2flyNG는 V2Fly 코어를 사용하므로 V2Fly 동작이 필요하거나 해당 설정 절차가 이미 있는 경우의 대안입니다. 두 앱은 화면과 설정 위치가 완전히 같지 않으며, 같은 구독을 가져올 수 있는지도 설정 필드와 코어 기능에 따라 달라집니다. 이름이 비슷하다고 모든 옵션이 일대일로 대응한다고 가정해서는 안 됩니다.

Android 다운로드 패키지는 보통 arm64와 범용 버전으로 나뉩니다. 최신 주류 스마트폰은 대개 arm64를 사용하며, 아키텍처를 확인하기 어렵다면 범용 버전을 선택하세요. 설치 후 VPN 연결을 처음 시작하면 시스템 권한 요청이 표시됩니다. 이 권한은 로컬 가상 네트워크 인터페이스를 만드는 데 필요하며 애플리케이션이 트래픽을 처리하기 위한 시스템 메커니즘입니다. 기기에서 다른 VPN 연결이 이미 활성화되어 있다면 먼저 종료하세요. 일반적으로 이런 인터페이스는 한 번에 하나만 활성화할 수 있습니다. 백그라운드 실행은 배터리 절전 정책의 영향도 받으므로 연결 기준이 정상화된 뒤 처리하는 것이 좋습니다.

기능 수를 실제 필요보다 우선하지 마세요

클라이언트 선택은 세 가지 질문에서 시작해야 합니다. 기기 플랫폼은 무엇인지, 기존 설정에는 어떤 코어 기능이 필요한지, 애플리케이션은 어떤 방식으로 연결할지입니다. Windows 브라우저와 일반 데스크톱 프로그램이 주된 대상이라면 v2rayN과 시스템 프록시만으로도 충분한 경우가 많습니다. Android에서 앱별 프록시가 필요하면 v2rayNG에서 포함 또는 제외 범위를 설정할 수 있습니다. 시스템 프록시를 읽지 않는 프로그램이 있을 때만 애플리케이션 자체 프록시 매개변수나 TUN을 추가로 검토하세요. 최소한의 구성으로 요구 사항을 충족하는 것이 처음부터 모든 고급 기능을 켜는 것보다 유지 관리 비용이 낮습니다.

기존 클라이언트에서 옮길 때는 프로그램 폴더 전체를 복사하지 말고 구독이나 표준 공유 설정을 다시 가져오는 것을 우선하세요. 이전 폴더에는 오래된 라우팅 파일, 포트 설정, 로그와 화면 상태가 남아 있을 수 있어 문제까지 함께 가져오기 쉽습니다. 이전 후에는 설정 하나를 선택해 로컬 수신을 확인하고 분할 라우팅 규칙을 하나씩 복원하세요. 서버 설정은 민감한 연결 정보이므로 관리되는 기기와 신뢰할 수 있는 백업 위치에만 보관해야 합니다. 스크린샷이나 문제 해결 기록에는 구독 주소, 사용자 식별자와 인증 정보를 가리세요.

그래도 결정하기 어렵다면 먼저 클라이언트 비교를 읽어보세요. 플랫폼과 클라이언트를 정한 뒤 설치 단계로 넘어가야 잘못된 아키텍처나 패키지 형식으로 인한 실행 실패를 구독 또는 네트워크 문제로 오해하지 않을 수 있습니다.

설치와 최초 실행: 코어와 수신 포트부터 확인

Windows의 설치와 디렉터리 경계

Windows에서 시스템 아키텍처에 맞는 v2rayN 패키지를 받은 뒤 다운로드 페이지에 표시된 패키지 형식에 따라 설치하거나 압축을 해제하세요. 압축 해제가 필요한 형식이라면 현재 계정에 읽기·쓰기 권한이 있는 고정 디렉터리에 보관하고, 압축 파일 미리보기 창이나 임시 다운로드 폴더에서 장기간 실행하지 마세요. 클라이언트는 설정을 저장하고 구성 요소를 업데이트하며 로그를 기록해야 합니다. 디렉터리 권한이 부족하면 화면은 열리지만 설정이 저장되지 않거나 코어가 종료되지 않고 업데이트 후 파일이 사라지는 등의 문제가 발생할 수 있습니다.

처음 실행한 뒤에는 많은 구독을 바로 가져오지 마세요. 클라이언트의 설정 또는 로그 영역을 열어 코어 프로세스를 호출할 수 있는지 확인하고 로컬 HTTP와 SOCKS 수신 주소를 기록합니다. 일반적인 수신 주소는 루프백 인터페이스인 127.0.0.1이며, 본체의 프로그램만 접근할 수 있다는 뜻입니다. 포트는 클라이언트 설정에 따라 달라지므로 안내서의 예시 포트를 현재 기기의 고정값으로 간주하지 마세요. 시스템 보안 도구가 네트워크 접근을 요청하면 로컬 사용 범위에 맞춰 판단하세요. 로컬 루프백 프록시를 위해 수신을 공용 네트워크에 노출할 필요는 없습니다.

macOS, Linux와 Android의 최초 권한 승인

macOS에서 처음 다운로드한 앱을 실행하면 시스템이 앱 출처 확인이나 네트워크 구성 관련 권한을 요구할 수 있습니다. 권한을 승인한 뒤 메뉴 막대나 클라이언트 화면에서 시스템 프록시 기능이 현재 네트워크 서비스에 적용되는지 확인하세요. Wi-Fi, 유선 네트워크 또는 다른 네트워크 서비스로 전환하면 네트워크 서비스마다 설정이 다를 수 있으므로 시스템 프록시 상태를 다시 확인해야 합니다. Linux 데스크톱 환경은 시스템 프록시 지원 방식이 서로 다릅니다. 일부 애플리케이션은 데스크톱 프록시 설정을 읽지만 일부 명령줄 프로그램은 자체 매개변수나 환경 변수만 읽습니다. 따라서 ‘클라이언트가 실행 중’인 것과 ‘모든 프로그램이 연결됨’은 별개의 문제입니다.

Android에서 처음 연결할 때는 시스템 VPN 권한을 승인해야 합니다. 승인 후 상태 표시줄에 시스템이 제공하는 VPN 아이콘이 나타나지만, 이는 가상 인터페이스가 만들어졌다는 뜻일 뿐 원격 설정이 정상이라는 의미는 아닙니다. 먼저 설정 하나를 선택하고 클라이언트에 명확한 오류가 표시되는지 확인한 뒤 브라우저로 기본 접속을 테스트하세요. 앱이 백그라운드로 전환된 직후 끊긴다면 배터리 최적화, 백그라운드 활동 권한과 시스템 작업 정리 정책을 확인하세요. 일부 앱만 연결되지 않는다면 계속 재설치하지 말고 앱별 프록시 범위를 점검해야 합니다.

1. 클라이언트 자체가 안정적으로 시작되는지 확인 같은 이름으로 중복 실행된 프로세스를 종료한 뒤 인스턴스 하나만 시작합니다. 화면이 즉시 사라지면 시스템 아키텍처, 실행 권한과 클라이언트 로그부터 확인하고 구독은 아직 다루지 마세요.
2. 코어가 정상적으로 호출되는지 확인 로그에서 설정 파싱, 수신 실패 또는 권한 관련 내용을 찾습니다. 이 단계에서는 로컬 실행 경로만 판단하며 웹페이지 접속 결과로 코어 상태를 대신 판단하지 않습니다.
3. 로컬 포트가 수신 중인지 확인 HTTP, SOCKS 또는 혼합 수신의 실제 포트를 기록합니다. 이후 브라우저, 터미널과 시스템 프록시는 같은 포트 유형을 가리켜야 합니다.
4. 초기 설정 기록을 보관 클라이언트 유형, 코어 선택, 수신 주소, 포트와 시스템 프록시 활성화 여부를 기록해 이후 문제 해결의 기준으로 삼습니다.

Windows에서 지정 포트가 수신 중인지 확인합니다. 예시 포트는 10809입니다:

netstat -ano | findstr :10809

명령 결과가 없다면 해당 포트가 현재 수신 중이 아니거나 실제 포트가 예시값과 다르다는 뜻입니다. 클라이언트의 로컬 수신 설정으로 돌아가 확인하세요. 다른 프로세스가 포트를 사용 중이라면 마지막 열의 PID로 작업 관리자에서 해당 프로세스를 찾을 수 있습니다. v2rayN을 중복 실행하거나 다른 로컬 프록시 프로그램 및 개발 도구를 실행하면 충돌이 발생할 수 있습니다. 자세한 절차는 v2rayN 로컬 포트 사용 중 문제 해결을 참고하세요.

첫 연결에서는 가장 짧은 경로만 검증

로컬 점검을 마친 뒤 설정 하나를 가져와 활성 항목으로 선택합니다. 먼저 클라이언트 기본 라우팅과 기본 DNS를 사용하고 복잡한 규칙은 켜지 마세요. 시스템 프록시를 활성화한 뒤 시스템 프록시를 확실히 읽는 브라우저로 일반 HTTPS 페이지를 열면서 로그에 해당 도메인 요청이 기록되는지 확인합니다. 브라우저 요청은 있지만 연결이 실패하면 문제는 원격 설정 또는 네트워크 계층에 있습니다. 로그에 요청이 전혀 없다면 브라우저가 독립 프록시를 사용하는지, 시스템 프록시가 정상 적용됐는지와 포트가 일치하는지를 우선 확인하세요.

검증이 끝나면 ‘시스템 프록시 지우기’를 직접 테스트하세요. 클라이언트를 종료하기 전에 시스템 프록시를 복원하면 운영체제가 이미 중지된 로컬 포트를 계속 가리키는 일을 막을 수 있습니다. 클라이언트가 비정상 종료된 후 모든 웹페이지가 열리지 않는다면 첫 단계는 DNS 변경이 아니라 잔류 시스템 프록시를 확인하고 지우는 것입니다. 설치 단계의 목표는 모든 기능을 켜는 것이 아니라 시작·수신·연결·종료가 가능한 로컬 기준선을 만드는 것입니다.

구독과 설정 관리: 가져오기, 파싱과 연결을 구분하기

구독 업데이트에는 세 가지 별도 결과가 있습니다

구독 업데이트는 최소한 주소 접속, 내용 파싱과 설정 저장의 세 단계를 거칩니다. 클라이언트가 먼저 구독 주소에 접속하고, 응답을 받으면 내용 형식을 확인해 설정을 파싱한 뒤 유효한 항목을 해당 그룹에 저장합니다. 세 단계가 모두 완료되어야 목록이 갱신됩니다. 네트워크 요청 실패가 표시되면 현재 네트워크에서 구독 주소에 접근할 수 있는지, 시스템 시간이 정확한지와 클라이언트가 적절한 네트워크 경로로 업데이트를 요청하는지 확인하세요. 파싱 실패라면 로컬 포트를 계속 바꾸지 말고 응답 내용이 클라이언트가 지원하는 형식인지 확인해야 합니다.

구독 주소는 보통 접근 권한을 포함하므로 민감한 데이터로 취급해야 합니다. 전체 주소를 공개 스크린샷, 로그 첨부 파일이나 브라우저 동기화 메모에 넣지 마세요. 구독을 추가할 때는 용도나 출처를 기준으로 명확한 그룹 이름을 지정하고 ‘구독 1’, ‘구독 2’처럼만 쓰지 않는 것이 좋습니다. 그룹 이름은 연결 동작을 바꾸지 않지만 어떤 업데이트가 어떤 설정을 덮어썼는지 판단하는 데 도움이 됩니다. 여러 출처를 한 그룹에 섞으면 같은 이름의 항목이나 필드 차이가 생겼을 때 어느 쪽이 원인인지 확인하기 어렵습니다.

가져온 뒤 확인할 것은 ‘목록에 표시됨’만이 아닙니다

설정이 목록에 들어온 뒤에는 프로토콜 유형, 서버 주소, 포트, 전송 방식, TLS 상태와 서버 이름 등 주요 필드를 최소한 확인해야 합니다. 사용자 식별자 같은 인증 데이터는 일상 화면에서 전체를 표시하지 않아도 되지만 존재 여부와 형식은 정확해야 합니다. VLESS, VMess 등의 프로토콜 이름은 설정 일부만 설명합니다. WebSocket, gRPC, TCP 등의 전송 방식과 TLS, SNI, 경로 또는 서비스 이름도 서로 맞아야 합니다. 프로토콜 필드만 같은 이름으로 바꾼다고 다른 필드의 불일치가 해결되지는 않습니다.

일괄 테스트 결과는 선별을 위한 단서일 뿐입니다. 테스트 실패는 현재 네트워크, 원격 상태, 테스트 대상 또는 DNS 때문일 수 있고, 테스트 성공도 모든 애플리케이션이 올바르게 연결되었다는 뜻은 아닙니다. 더 신뢰할 수 있는 방법은 설정 하나를 선택해 기본 라우팅을 유지하고 브라우저에서 실제 요청을 보낸 뒤 코어 로그와 함께 판단하는 것입니다. 같은 문제에서 여러 설정을 계속 번갈아 사용하면 로그와 시스템 프록시 상태가 자주 바뀌어 원인과 결과를 확인하기 어렵습니다.

1. 구독을 추가하고 그룹 이름 지정 클라이언트의 구독 관리 메뉴에서 주소를 추가하고 앞뒤 공백이나 줄바꿈이 없는지 확인합니다. 저장한 뒤 방금 추가한 그룹만 업데이트하면 결과를 확인하기 쉽습니다.
2. 업데이트 메시지와 그룹 변화 확인 요청 실패, 파싱 실패와 저장 후 유효 항목 없음은 구분해야 합니다. 단계마다 점검 대상이 다르므로 모든 문제를 코어 탓으로 돌리지 마세요.
3. 설정 하나를 선택해 필드 확인 프로토콜, 주소, 포트, 전송 방식과 TLS 관련 필드를 모두 확인한 뒤 활성 설정으로 지정하고 코어를 시작합니다.
4. 최근 사용 가능한 대체 설정 보관 업데이트 전에 현재 설정 데이터베이스를 내보내거나 백업합니다. 출처의 내용이 바뀌었을 때 문제가 업데이트 때문인지 로컬 환경 변화 때문인지 빠르게 판단할 수 있습니다.

업데이트 실패 시 단계별 확인

클라이언트가 구독 주소에 연결할 수 없다고 표시하면 먼저 주소가 완전한지 확인하고 시스템 프록시가 실행되지 않는 로컬 포트를 가리키고 있지 않은지 점검하세요. 브라우저가 접속된다고 해서 클라이언트의 구독 요청도 같은 경로를 사용한다는 뜻은 아닙니다. 두 요청이 서로 다른 프록시 설정을 사용할 수 있기 때문입니다. 응답이 로그인 페이지, 오류 페이지 또는 일반 텍스트라면 클라이언트는 보통 형식 오류를 보고합니다. 이때는 웹페이지 내용을 공유 설정으로 직접 가져오지 말고 구독 출처를 확인해야 합니다.

업데이트는 성공했지만 목록이 비어 있다면 특정 항목을 필터링하는 그룹 설정이 켜져 있는지, 응답 내용에 현재 클라이언트가 인식할 수 있는 설정이 포함되어 있는지 확인하세요. 목록을 갱신한 뒤 기존 항목이 사라졌다면 연속으로 새로 고침하지 말고 해당 구독이 덮어쓰기 방식인지 확인한 다음 보존할 수동 항목을 백업에서 복원하세요. 자세한 분류 절차는 구독 업데이트 자주 묻는 질문에서 확인할 수 있으며, 최초 가져오기의 간단한 절차는 빠른 시작의 구독 단계를 참고하세요.

수동 설정은 필드를 정확히 확인할 때 적합합니다

설정이 하나뿐이거나 특정 필드를 확인해야 할 때는 클라이언트의 수동 추가 기능을 사용할 수 있습니다. 입력할 때는 위에서 아래로 항목을 하나씩 확인하고 이름이 비슷하다는 이유로 추측하지 마세요. 서버 이름은 TLS 핸드셰이크에 사용되므로 설정 요구 사항과 일치해야 하며 전송 경로, Host, 서비스 이름 등도 각각의 역할이 있습니다. 인증서 또는 TLS 핸드셰이크 오류가 발생하면 시스템 시간, 인증서 유효 기간, 도메인 일치 여부와 SNI를 먼저 확인하세요. 원리는 TLS 핸드셰이크와 인증서 오류 문제 해결을 참고할 수 있습니다. 인증서 검증을 끄는 것을 일상적인 해결책으로 사용해서는 안 됩니다.

구독 단계를 마치면 네 가지 질문에 답할 수 있어야 합니다. 설정은 어느 그룹에서 왔는지, 현재 활성 항목은 무엇인지, 코어가 어떤 유형의 설정을 사용하는지, 로컬 수신 포트는 무엇인지입니다. 이 정보가 명확해야 다음 단계의 시스템 프록시와 애플리케이션 연결 테스트를 신뢰할 수 있습니다.

프록시 모드와 애플리케이션 연결 범위

시스템 프록시는 시스템 설정을 읽는 애플리케이션만 대상으로 합니다

v2rayN의 ‘시스템 프록시 자동 설정’은 보통 운영체제의 프록시 주소를 클라이언트의 로컬 수신 포트로 지정합니다. 브라우저와 일부 데스크톱 애플리케이션은 이 설정을 읽으므로 별도 설정 없이 연결됩니다. 반면 독립 프록시 설정을 가진 프로그램이나 시스템 프록시를 완전히 무시하는 프로그램도 있습니다. 일부 터미널 명령, 개발 도구, 게임 플랫폼과 자체 네트워크 스택을 사용하는 앱이 여기에 해당합니다. 시스템 프록시가 켜졌는데 특정 프로그램이 계속 직접 연결된다고 해서 v2rayN이나 코어가 고장 났다는 뜻은 아닙니다. 먼저 해당 프로그램의 연결 방식을 확인하세요.

‘시스템 프록시 지우기’는 클라이언트가 기록한 시스템 설정을 제거합니다. 클라이언트를 중지하거나 로컬 포트가 바뀌었거나 다른 네트워크 도구로 전환할 때는 먼저 기존 프록시를 지워야 합니다. 시스템이 여전히 127.0.0.1의 특정 포트를 가리키는데 해당 포트에 수신 프로세스가 없다면 시스템 프록시를 따르는 애플리케이션은 모두 연결 실패를 겪습니다. 이런 문제는 프로그램이 비정상 종료된 뒤 자주 발생하며, 실제로는 시스템 프록시를 복원하면 해결됩니다.

HTTP와 SOCKS 포트는 임의로 바꿔 쓸 수 없습니다

로컬 HTTP 프록시는 HTTP 프록시를 명시적으로 지원하는 애플리케이션에 적합하고, SOCKS 프록시는 SOCKS 프로토콜로 연결을 전달합니다. 클라이언트는 별도 포트를 제공할 수도 있고 여러 연결 방식을 지원하는 혼합 포트를 제공할 수도 있습니다. 애플리케이션에 입력할 때는 수신 유형이 일치해야 합니다. SOCKS 포트를 HTTP 프록시 전용 필드에 입력하면 프로토콜 핸드셰이크 오류나 연결 재설정이 발생하는 경우가 많습니다. 주소는 일반적으로 127.0.0.1을 사용해 로컬 클라이언트에 연결합니다. LAN 수신과 접근 제어를 명시적으로 설정한 경우가 아니라면 루프백 주소를 임의의 네트워크 어댑터 주소로 바꾸지 마세요.

브라우저는 먼저 시스템 프록시로 기준 테스트를 수행할 수 있습니다. 프록시 확장 프로그램을 설치했다면 ‘시스템 설정 따르기’인지 사용자 지정 모드인지 확인하세요. 확장 프로그램의 고정 포트가 시스템 설정을 덮어쓰면 클라이언트가 포트를 바꾼 뒤에도 브라우저가 이전 수신 포트에 접속할 수 있습니다. 시크릿 창이나 다른 브라우저 프로필도 독립 규칙을 사용할 수 있습니다. 브라우저는 되지만 터미널이 되지 않는다면 두 대상을 나누어 점검하고, 자세한 절차는 브라우저와 터미널의 프록시 범위 확인을 참고하세요.

터미널 프로그램은 보통 명시적인 설정이 필요합니다

많은 명령줄 도구가 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 등의 환경 변수를 읽지만 지원 범위는 도구마다 다릅니다. 환경 변수는 현재 프로세스, 현재 터미널 세션과 시스템 영구 설정으로도 나뉩니다. 문제 해결 시에는 현재 터미널에서만 임시로 설정하고 검증이 끝나면 창을 닫아 복원하는 것이 좋습니다. 오래된 포트를 전역 환경에 장기간 남기지 마세요. 아래 예시는 v2rayN의 HTTP 수신 포트가 실제로 10809라고 가정합니다. 사용 전 클라이언트 화면에 표시된 실제 포트로 바꾸세요.

Windows 명령 프롬프트 현재 세션:

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809
curl https://example.com

PowerShell 현재 세션:

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
curl.exe https://example.com

명령 실행 후에도 코어 로그에 요청이 보이지 않는다면 해당 도구가 이 변수를 읽는지, 변수 이름이 정확한지, 주소와 포트가 HTTP 수신에 해당하는지 확인하세요. 로그에 요청이 기록되지만 연결이 실패한다면 라우팅, DNS 또는 원격 설정을 점검합니다. 터미널 출력의 ‘시간 초과’만으로 계층을 판단하지 마세요. 로컬 포트 미수신, 원격 연결 불가와 도메인 해석 실패도 비슷하게 보일 수 있습니다.

출구 결과만 보지 말고 프록시 범위를 검증하세요

신뢰할 수 있는 검증은 세 가지 신호를 함께 확인해야 합니다. 애플리케이션이 실제로 대상 프록시 설정을 사용하는지, 클라이언트 로그에 해당 애플리케이션의 도메인 또는 연결이 기록되는지, 라우팅 결과가 예상과 일치하는지입니다. 출구 IP를 보여주는 페이지 하나만 확인해서는 모든 애플리케이션이 같은 경로를 사용한다고 볼 수 없고 DNS 요청이 예상대로 처리되었다고도 할 수 없습니다. 테스트할 때는 브라우저, 터미널과 대상 애플리케이션을 각각 열고 한 번에 식별 가능한 요청을 조금만 발생시킨 뒤 로그에서 코어 진입 여부를 확인하세요.

이 단계를 마치면 어떤 애플리케이션이 시스템 프록시를 따르고 어떤 애플리케이션이 자체 설정을 사용하며 어떤 앱이 여전히 연결되지 않는지 명확히 알 수 있어야 합니다. 세 번째 유형의 앱이 실제로 존재하고 하나씩 설정할 수 없을 때만 TUN을 고려할 이유가 있습니다. 시스템 프록시로 안정적으로 작동하는 환경이라면 바로 라우팅으로 넘어가는 편이 더 간단합니다.

분할 라우팅: 코어에 들어온 요청의 출구 선택

라우팅은 출구를 선택하는 기능입니다

라우팅 규칙은 이미 코어에 들어온 트래픽만 처리합니다. 도메인, IP, 포트, 네트워크 유형과 인바운드 태그 등의 조건에 따라 요청을 프록시, 직접 연결 또는 차단 등의 출구로 보냅니다. 가장 흔한 목적은 LAN과 명확한 내부 주소는 직접 연결하고 나머지 요청은 프록시로 보내는 것입니다. 도메인 목록으로 더 세분화할 수도 있습니다. 어떤 전략을 사용하든 먼저 기본 동작을 정한 뒤 범위가 분명한 예외 규칙을 추가하세요. 예외 몇 개만 작성하고 최종 기본 출구를 이해하지 못하면 일치하지 않는 요청이 예상과 다른 경로로 갈 수 있습니다.

규칙은 보통 순서대로 일치하므로 앞쪽의 넓은 조건이 뒤쪽의 정밀한 조건을 가릴 수 있습니다. 예를 들어 모든 TCP와 UDP를 대상으로 하는 프록시 규칙을 먼저 작성하면 뒤의 사설 주소 직접 연결 규칙은 일치할 기회를 잃습니다. 순서를 설계할 때는 반드시 직접 연결하거나 별도로 처리해야 하는 정밀 규칙을 먼저 두고, 범위가 큰 분류 규칙을 뒤에 배치한 다음 마지막에 기본 규칙을 사용하세요. 변경 후에는 명확한 도메인으로 규칙을 하나씩 검증하고, 긴 규칙 세트를 한 번에 가져온 뒤 웹페이지 하나만 테스트하지 마세요.

도메인 규칙, IP 규칙과 해석 전략

도메인 규칙은 코어가 원래 대상 도메인을 알고 있을 때 가장 직관적이며 전체 도메인, 도메인 접미사 또는 사전 정의된 분류와 일치시킬 수 있습니다. IP 규칙은 대상 IP에 의존합니다. 요청이 처음 도메인으로 들어왔을 때 라우팅을 위해 추가 해석을 수행할지는 domainStrategy 등의 설정에 영향을 받습니다. 해석 전략을 지나치게 공격적으로 바꾸면 DNS 조회가 늘고 일치 경로가 달라질 수 있습니다. 반대로 전혀 해석하지 않으면 IP 조건만 작성한 규칙이 도메인 요청을 처리하지 못할 수 있습니다. 전략 이름을 보편적인 최적값으로 여기지 말고 실제 규칙 조건에 맞춰 선택하세요.

사설 주소 직접 연결은 보통 로컬 기기, LAN 장치와 내부 서비스에 사용하지만 실제 네트워크 환경과 함께 판단해야 합니다. 기업 네트워크, 가상 머신, 컨테이너와 개발 환경은 서로 다른 사설 대역을 사용할 수 있으며 여러 가상 네트워크 어댑터가 있으면 시스템 라우팅도 연결 방향에 영향을 줍니다. 도메인이 최종적으로 사설 주소로 해석될 때는 DNS 결과가 현재 네트워크에서 나온 것인지도 확인해야 합니다. ‘도메인 접속은 실패하지만 내부 IP를 직접 입력하면 된다’면 프록시 출구만 바꾸지 말고 도메인 해석 결과와 라우팅 일치 여부를 비교하세요.

규칙 구조를 설명하기 위한 Xray 라우팅 조각입니다. 출구 태그는 전체 설정의 outbound 태그와 일치해야 합니다:

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:intranet.example.com"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

이 설정은 지정한 내부 도메인을 직접 연결하고 사설 IP도 직접 연결하며, 나머지 TCP와 UDP는 proxy라는 출구로 보낸다는 뜻입니다. 전체 설정 중 라우팅 부분일 뿐 클라이언트 전체 설정으로 단독 실행할 수 없습니다. 클라이언트가 그래픽 인터페이스로 라우팅을 관리한다면 해당 규칙 편집기에서 같은 논리를 표현하고 클라이언트가 생성한 다른 필드를 직접 덮어쓰지 마세요. 출구 태그가 없으면 코어가 설정 오류를 보고하며, 규칙 데이터 파일이 없거나 지원되지 않는 이름을 사용해도 시작 또는 일치 단계에서 메시지가 표시됩니다.

최소 규칙 세트부터 단계적으로 확장

라우팅을 구성할 때는 먼저 사설 주소 직접 연결 규칙 하나와 명확한 기본 출구 하나만 남겨 브라우저, 터미널과 LAN 서비스가 예상대로 작동하는지 확인하세요. 그런 다음 한 번에 도메인 규칙 한 묶음씩 추가하고 각 묶음의 목적과 관리 출처를 적습니다. 규칙 이름은 ‘LAN 직접 연결’, ‘개발 서비스 직접 연결’처럼 용도를 드러내야 하며 ‘규칙 1’처럼만 쓰지 마세요. 특정 규칙이 문제를 일으키면 해당 묶음을 임시로 비활성화하고 이전의 안정적인 상태로 돌아갈 수 있습니다.

DNS와 라우팅은 따로 기록해야 합니다. 라우팅은 출구를 결정하고 DNS는 주소를 얻는 방식을 결정하며 서로 영향을 주지만 같은 설정은 아닙니다. 도메인만 실패하면 먼저 해석 결과를 비교하고, IP 연결도 실패하면 출구와 원격 연결을 확인하세요. 요청이 로그에 전혀 들어오지 않으면 애플리케이션 연결 계층으로 돌아가야 합니다. 이 세 현상을 분리하면 라우팅 화면에서 DNS를 계속 바꾸면서 시스템에는 또 다른 해석 서비스를 설정하는 일을 피할 수 있습니다.

분할 라우팅 완료 후 점검

최소한 세 가지 대상을 각각 테스트하세요. LAN 주소 하나, 직접 연결이 명확히 필요한 도메인 하나, 프록시 출구를 사용하는 일반 도메인 하나입니다. 각 대상에 대해 애플리케이션 연결 방식, 해석 결과, 일치 규칙과 최종 출구를 기록합니다. 프록시를 켠 뒤 LAN 접속이 끊기면 먼저 사설 주소가 더 넓은 프록시 규칙에 먼저 일치했는지 확인하세요. 특정 도메인이 가끔 다른 경로를 사용한다면 여러 주소로 해석되는지, 규칙이 도메인 기준인지 IP 기준인지 확인합니다.

라우팅이 안정된 뒤에 TUN을 고려하세요. 이때 트래픽 연결 범위를 넓혀도 이미 검증한 규칙으로 출구를 판단할 수 있습니다. 시스템 프록시 단계에서 라우팅을 아직 정리하지 않은 채 TUN을 켜면 더 많은 프로그램과 시스템 트래픽이 검증되지 않은 규칙으로 들어가 장애 범위가 커집니다.

TUN 모드: 시스템 프록시를 읽지 않는 트래픽 처리

TUN은 트래픽 진입점을 바꿉니다

TUN은 가상 네트워크 인터페이스를 통해 시스템 트래픽을 받아 HTTP 또는 SOCKS 프록시 설정을 지원하지 않는 애플리케이션도 코어에 들어갈 수 있게 합니다. 해결하는 것은 애플리케이션 연결 범위이지 프로토콜 변경이 아니며, 잘못된 원격 설정을 자동으로 복구하지도 않습니다. 활성화하면 시스템 라우팅, 가상 네트워크 어댑터, DNS와 코어 인바운드가 함께 작동하므로 시스템 프록시보다 문제 지점이 늘어납니다. 기본 설정을 시스템 프록시로 검증했고 별도 프록시 설정이 불가능한 앱이 실제로 있을 때만 이 단계로 넘어가는 것이 좋습니다.

데스크톱 시스템에서는 가상 인터페이스 생성이나 라우팅 변경에 추가 권한이 필요할 수 있습니다. 권한이 부족하면 클라이언트 화면의 스위치는 켜진 것처럼 보여도 로그에는 인터페이스 생성, 라우팅 기록 또는 드라이버 접근 실패가 나타납니다. Android의 VPN 연결도 시스템이 제공하는 가상 네트워크 메커니즘을 사용하지만 권한, 다른 VPN 충돌, 앱별 범위와 백그라운드 제한을 확인해야 합니다. 플랫폼마다 구현 세부 사항이 다르므로 다른 플랫폼의 드라이버나 권한 처리 절차를 그대로 적용하지 마세요.

활성화 전에 기준선 고정

• 현재 활성 설정은 시스템 프록시로 브라우저 테스트를 완료했습니다.
• 로컬 수신 포트와 코어 로그가 정상이며 지속적인 설정 오류가 없습니다.
• 라우팅 규칙은 최소한 사설 주소 직접 연결과 기본 출구 검증을 완료했습니다.
• 시스템에서 다른 VPN이나 가상 네트워크 관리 도구를 동시에 실행하지 않습니다.
• 활성화 전 DNS, 시스템 프록시와 클라이언트 설정을 기록했습니다.

이 조건을 충족했다면 먼저 중복된 네트워크 관리 방식을 정리하세요. TUN으로 주요 트래픽을 처리할 예정이라면 클라이언트 안내에 따라 시스템 프록시를 조정해 같은 요청이 불필요하게 여러 진입점을 거치지 않도록 합니다. 활성화 후에는 기본 웹페이지를 먼저 테스트하고, 시스템 프록시를 읽지 못했던 대상 애플리케이션을 테스트한 다음 LAN 서비스를 테스트하세요. 매 단계마다 로그에 요청이 기록되는지와 라우팅 선택이 올바른지 확인합니다. 처음 켤 때 새 DNS, 복잡한 규칙과 여러 우회 목록을 동시에 가져오지 마세요.

1. 충돌할 수 있는 가상 네트워크 연결 종료 다른 VPN 세션과 같은 종류의 관리 프로그램을 종료하고 정상적인 물리 네트워크만 남깁니다. 가상 머신과 컨테이너 네트워크를 무작정 삭제할 필요는 없지만 해당 대역과 라우팅을 기록하세요.
2. 필요한 권한으로 TUN 활성화 클라이언트 로그에서 가상 인터페이스가 생성되고 라우팅이 기록되었는지 확인합니다. 스위치 색상만으로 시스템 계층의 완료 여부를 판단하지 마세요.
3. DNS와 일반 TCP 요청 검증 먼저 도메인 해석을 테스트한 다음 브라우저 연결을 테스트합니다. IP는 되지만 도메인이 실패하면 TUN이 사용하는 DNS 경로를 집중적으로 확인하세요.
4. 대상 애플리케이션과 LAN 테스트 이전에 연결되지 않던 프로그램이 로그에 들어오는지 확인하고 프린터, 라우터 관리 페이지와 내부 서비스가 규칙에 따라 계속 직접 연결되는지도 확인합니다.

일반적인 충돌을 계층별로 판단하기

활성화 후 네트워크가 완전히 끊기면 먼저 가상 인터페이스와 기본 라우팅이 만들어졌는지 확인한 뒤 코어가 계속 실행 중인지 확인하세요. TUN을 끈 직후 복구된다면 문제는 TUN 진입점, 라우팅 또는 DNS에 집중되어 있으므로 클라이언트를 재설치할 필요가 없습니다. 도메인만 실패하고 IP는 된다면 DNS 서버 접근성, 조회가 예상한 출구로 나가는지와 해석 결과를 먼저 확인하세요. LAN만 실패한다면 사설 주소 규칙과 시스템 라우팅 우선순위를 확인하고, 특히 가상 네트워크 어댑터와 실제 LAN이 같은 대역을 사용할 때를 주의하세요.

특정 애플리케이션이 여전히 프록시에 들어오지 않는다면 앱별 규칙에서 제외되었는지, 독립 네트워크 인터페이스를 사용하는지, 대상 트래픽이 현재 TUN 구현의 관리 범위에 포함되는지 확인하세요. Android에서는 앱이 ‘선택한 앱만 프록시’인지 ‘선택한 앱 우회’인지도 확인해야 하며 두 모드는 의미가 반대입니다. 백그라운드와 앱별 연결 문제는 Android 권한, 절전 설정과 앱별 프록시를 참고하세요.

DNS는 TUN 문제 해결의 핵심입니다

TUN의 관리 범위가 넓어지면 시스템 서비스와 더 많은 애플리케이션의 DNS 요청도 처리 경로에 들어올 수 있습니다. 누가 조회를 받고 어떤 서버를 사용하며 조회 결과가 라우팅에 활용되는지, 반환된 주소에 현재 출구로 접근할 수 있는지 명확히 해야 합니다. 시스템 DNS, 클라이언트 DNS와 앱 내부 암호화 DNS를 동시에 설정하면 실제 경로가 예상과 달라질 수 있습니다. 계층을 임시로 줄이고 먼저 명확한 클라이언트 DNS 구성 하나로 검증한 뒤 필요에 따라 앱 설정을 복원하세요.

로그에 도메인 해석 성공 후 연결 실패가 나타나면 해석된 주소와 라우팅 출구를 계속 확인하세요. 조회 기록이 없다면 애플리케이션이 캐시나 자체 해석 방식을 사용할 수 있습니다. 캐시 삭제는 검증에 사용할 수 있지만 반복적인 캐시 삭제를 장기 해결책으로 삼아서는 안 됩니다. 최종 목표는 같은 네트워크 조건에서 같은 도메인이 설명 가능하고 반복 가능한 해석 및 라우팅 결과를 얻도록 하는 것입니다.

TUN 종료 시 시스템 상태 복원

TUN을 끈 뒤 가상 인터페이스와 임시 라우팅이 정리되었는지 확인하고 시스템 프록시가 아직 실행 중인 클라이언트를 가리키는지도 점검하세요. 클라이언트 비정상 종료로 라우팅이 남았다면 먼저 클라이언트를 다시 시작해 TUN을 정상적으로 끈 뒤 시스템 네트워크 도구로 라우팅을 확인할 수 있습니다. 복구 과정에서 모든 네트워크 설정을 동시에 초기화하지 마세요. 기존 고정 주소, 기업 네트워크 또는 가상 머신 설정을 잃을 수 있습니다. 활성화 전 기록을 남겨 두면 변경 사항을 하나씩 대조할 수 있습니다.

TUN 단계의 완료 기준은 ‘스위치가 켜져 있음’이 아닙니다. 대상 애플리케이션이 실제로 코어에 들어오고, LAN에 계속 접근할 수 있으며, DNS 경로가 명확하고 종료 후 시스템이 복원되어야 합니다. 시스템 프록시만으로 모든 요구를 충족한다면 더 단순한 연결 방식을 계속 사용하는 것도 합리적입니다.

일상 유지 관리와 문제 해결: 최근 변경부터 확인

유지 관리의 핵심은 설정, 상태와 변경 기록입니다

일상적인 유지 관리에는 잦은 재설치가 필요하지 않습니다. 구독 그룹, 수동 설정, 라우팅 규칙, DNS 설정과 로컬 포트 기록을 보관하고 클라이언트를 업데이트하거나 규칙을 조정하기 전에 백업을 만드는 것이 더 중요합니다. 백업에는 구독 주소와 연결 인증 정보가 포함될 수 있으므로 관리되는 위치에 보관하고 일반 텍스트로 공개 전송하지 마세요. 복원할 때는 최소 설정을 먼저 가져와 검증한 뒤 큰 규칙 세트를 복원해야 백업 자체와 새 환경 중 어디에서 문제가 생겼는지 판단할 수 있습니다.

클라이언트를 업데이트한 뒤에는 화면 설정이 보존되었는지, 코어가 시작되는지, 로컬 포트가 바뀌었는지 확인한 다음 시스템 프록시를 테스트하세요. 업데이트, 구독 새로 고침, 라우팅 교체와 TUN 조정을 한 번에 진행하지 마세요. 한 번에 한 종류의 변수만 바꿔야 문제가 생겼을 때 되돌릴 수 있습니다. 기기를 옮겨야 한다면 이전 클라이언트 유형, 아키텍처, 코어 선택, 구독 그룹, 수신 포트, 라우팅 정책과 특수 애플리케이션 프록시 설정을 기록하는 편이 이전 폴더 전체를 복사하는 것보다 위험을 관리하기 쉽습니다.

일관된 문제 분류 만들기

문제 해결 시 발생 시간, 최근 변경 사항과 영향 범위를 먼저 기록하세요. 시스템 프록시를 따르는 모든 앱이 동시에 실패하면 클라이언트 프로세스, 로컬 수신과 시스템 프록시를 확인합니다. 특정 앱 하나만 실패하면 자체 설정을 우선 확인하세요. 같은 설정이 네트워크에 따라 다르게 작동한다면 DNS, 네트워크 경로와 시스템 시간을 살펴봅니다. 범위 판단은 오류 문구 자체보다 가치가 큽니다. 많은 ‘연결 시간 초과’가 어느 계층에서 시간 초과가 발생했는지 알려주지 않기 때문입니다.

로그는 첫 번째 유효한 오류부터 읽어야 합니다

클라이언트와 코어 로그는 한 번의 실패 후 연쇄적인 메시지를 대량으로 남길 수 있습니다. 이번 시작 또는 작업 시점부터 읽기 시작해 설정 파싱, 수신, DNS, TLS 또는 연결 오류가 처음 나타난 지점을 찾으세요. 이후 반복 재시도로 생긴 줄은 대개 결과일 뿐입니다. 로그를 공유하기 전에는 구독 주소, 사용자 식별자, 서버 주소와 기타 민감한 필드를 삭제하고 오류 유형, 시간 순서와 필요한 맥락만 남기세요.

코어가 주소가 이미 사용 중이라고 알리면 먼저 해당 포트를 점유한 프로세스를 찾으세요. 설정 필드가 유효하지 않다는 메시지가 나오면 최근 편집이나 구독 업데이트로 돌아가 현재 코어가 인식하지 못하는 필드가 가져와졌는지 확인합니다. TLS 인증서 오류가 발생하면 시스템 시간을 동기화한 뒤 서버 이름과 인증서 도메인을 대조하세요. DNS 조회가 시간 초과되면 DNS 요청의 경로와 서버 접근성을 확인하고 바로 서버 설정 탓으로 돌리지 마세요.

포트, 시스템 프록시와 비정상 종료

로컬 포트가 사용 중이면 먼저 같은 클라이언트가 중복 실행되었는지 확인한 뒤 다른 프로그램을 점검하세요. 포트를 직접 변경하면 충돌을 피할 수 있지만 모든 수동 연결 대상에 영향을 줍니다. 변경 후 브라우저 확장, 터미널 변수, 개발 도구와 LAN 기기의 설정을 함께 업데이트해야 합니다. 더 이상 필요하지 않은 이전 프로세스가 포트를 사용하고 있다면 포트를 계속 바꾸기보다 해당 프로세스를 정상 종료하는 편이 유지 관리하기 쉽습니다.

클라이언트가 비정상 종료되면 시스템 프록시가 남을 수 있습니다. 그러면 브라우저는 존재하지 않는 로컬 포트로 계속 요청을 보냅니다. v2rayN을 다시 열어 ‘시스템 프록시 지우기’를 사용하거나 운영체제 네트워크 설정에서 복원하세요. 웹페이지가 모두 실패한다고 네트워크 어댑터를 바로 삭제하지 마세요. TUN을 사용했다면 가상 인터페이스와 라우팅도 정리되었는지 추가로 확인해야 합니다. 시스템 프록시 잔류와 TUN 라우팅 잔류는 서로 다른 문제이므로 따로 점검해야 합니다.

구독, 시간과 인증서의 주기적 점검

매번 시작할 때 구독을 무조건 연속으로 새로 고칠 필요는 없습니다. 실제 업데이트 필요에 맞춰 주기를 설정하고 최근에 사용 가능한 설정을 보관하세요. 새로 고친 뒤 많은 항목이 동시에 바뀌면 먼저 하나의 항목을 검증하고 기존 기록을 즉시 모두 지우지 마세요. TLS 인증서 검증은 정확한 시간에 의존하므로 시스템 시간은 자동 동기화 상태를 유지해야 합니다. 시간 오차는 인증서가 아직 유효하지 않거나 이미 만료된 것처럼 보이게 할 수 있습니다. 서버 이름, SNI와 인증서 도메인도 일치해야 하며 연결을 반복한다고 필드 오류가 해결되지는 않습니다.

장기간 사용하면서 디스크 공간과 로그 증가도 확인해야 합니다. 로그는 문제 해결에 필요하지만 무제한으로 보관하면 원하는 내용을 찾기 어려워집니다. 클라이언트가 제공하는 정리 방법으로 오래된 로그를 처리하고 정체를 알 수 없는 설정 데이터베이스를 직접 삭제하지 마세요. 업데이트 전 화면의 변경 안내를 읽고 업데이트 후 최단 경로를 검증하세요. 더 많은 일반적인 현상은 자주 묻는 질문에서 ‘설치 및 설정’과 ‘문제 해결’ 분류로 찾을 수 있습니다.

재사용 가능한 문제 해결 기록 만들기

유효한 기록에는 플랫폼, 클라이언트, 코어, 연결 방식, 활성 설정 유형, 수신 포트, 라우팅 및 TUN 활성화 여부, 오류 발생 시간, 첫 번째 유효 로그와 이미 검증한 단계를 포함해야 합니다. ‘안 됨’이라고만 쓰지 마세요. 이 정보가 있으면 문제를 클라이언트, 코어, 설정 또는 애플리케이션 범위로 빠르게 좁힐 수 있고 다음에 처음부터 다시 시도하는 일을 피할 수 있습니다. 해결 후에는 실제로 효과가 있었던 변경을 기록하고 문제 해결 중 사용한 임시 설정 중 효과가 없던 것은 되돌려 다음 장애의 원인이 되지 않게 하세요.

고급 설정 로드맵: 작동하는 구성을 설명 가능한 구성으로

고급 설정은 스위치를 더 많이 켜는 일이 아닙니다

기본 단계를 마친 뒤의 목표는 기능을 동시에 더 많이 켜는 것이 아니라 설정을 설명하고 테스트하며 되돌릴 수 있게 만드는 것입니다. 성숙한 환경은 다음 질문에 답할 수 있어야 합니다. 어떤 애플리케이션이 시스템 프록시를 사용하고 어떤 앱이 자체 설정이나 TUN을 사용하는지, DNS 조회는 누가 처리하는지, 각 도메인과 IP가 어느 라우팅 규칙과 일치하는지, 활성 설정이 어떤 프로토콜·전송·TLS 매개변수를 사용하는지, 클라이언트 업데이트나 포트 변경 후 어디를 동기화해야 하는지입니다. 화면에서 몇 개의 옵션을 켰는지보다 이 질문에 답할 수 있는지가 중요합니다.

학습 경로를 관찰, 규칙, 프로토콜과 자동화의 네 계층으로 나누는 것이 좋습니다. 먼저 클라이언트와 코어 로그를 읽어 애플리케이션에서 출구까지 요청 경로를 파악하고, 다음으로 소규모 라우팅과 DNS 규칙을 관리하세요. 그 후 프로토콜, 전송과 TLS 필드의 조합 관계를 이해하고 마지막으로 설정 백업, 이전과 반복 검증 절차를 고려합니다. 각 계층은 이전 계층의 안정적인 기준선을 전제로 합니다.

프로토콜, 전송과 TLS를 나누어 이해하기

VLESS, VMess 등은 프록시 프로토콜이고 TCP, WebSocket, gRPC 등은 전송 계층을 설명하며 TLS는 암호화된 연결을 만들고 상대방의 신원을 확인합니다. 설정의 연결 성공 여부는 이 계층들의 필드가 함께 일치하는지에 달려 있습니다. ‘프로토콜이 같다’고 해서 전송 경로, 서비스 이름, 서버 이름 또는 보안 매개변수까지 같다고 추정할 수는 없습니다. 새 설정을 학습할 때는 프로토콜 계층, 전송 계층, TLS 계층별로 주요 필드를 나누어 적고 코어 로그와 대조해 어느 단계에서 실패했는지 확인하세요.

TLS 핸드셰이크는 보호된 연결을 설정하는 단계에서 이루어집니다. 시스템 시간 오류, 인증서 유효 기간 불일치, 서버 이름과 인증서 도메인 불일치가 핸드셰이크 실패를 일으킬 수 있습니다. SNI는 연결 시 대상 서버 이름을 알리는 데 사용되므로 설정과 무관한 도메인을 임의로 입력해서는 안 됩니다. 전송 계층의 경로나 서비스 이름은 원격 서비스 설정에 따라 정해지며 이 역시 경험만으로 추측할 수 없습니다. 고급 문제 해결의 핵심은 무작위 조합이 아니라 계층별 대조입니다.

라우팅과 DNS 테스트 목록 만들기

라우팅 규칙을 추가한 뒤에는 고정된 테스트 대상을 관리해야 합니다. LAN 주소, 내부 도메인, 일반 직접 연결 대상, 프록시 대상과 UDP가 필요한 애플리케이션을 포함하세요. 규칙을 변경할 때마다 같은 순서로 테스트하고 일치한 출구를 기록합니다. DNS 테스트에서는 해석 서버, 반환된 주소와 조회가 예상한 진입점을 통과했는지도 기록해야 합니다. 고정 샘플을 사용하면 변화가 규칙 자체에서 왔는지 대상 사이트, 캐시 또는 현재 네트워크에서 왔는지 판단하기 쉽습니다.

규칙 파일과 분류 데이터가 업데이트될 때도 소수의 대상에서 먼저 검증하세요. 분류 이름의 포함 범위가 달라질 수 있으며 넓은 범위 규칙의 위치는 특히 다시 확인해야 합니다. 사용자 지정 규칙에는 작성 이유와 날짜를 적되 근거 없는 성능 수치를 기록할 필요는 없습니다. 장기간 명확한 용도가 없는 규칙은 삭제해 향후 충돌을 줄이는 것이 좋습니다. 단순하고 설명 가능한 규칙 세트가 출처가 불분명한 규칙을 많이 모은 것보다 대체로 신뢰할 수 있습니다.

서로 다른 기기는 독립된 환경으로 취급

데스크톱과 Android는 같은 구독 출처를 사용할 수 있지만 시스템 프록시, VPN 인터페이스, 백그라운드 정책과 앱별 기능은 다릅니다. Windows에서 검증한 연결 방식을 Android에 그대로 복사할 수 있다고 가정하지 말고, Android의 VPN 권한 문제를 구독 탓으로 돌리지도 마세요. 여러 기기에서 문제를 해결할 때는 먼저 양쪽이 같은 설정을 선택했는지, 시스템 시간이 정확한지와 네트워크 조건이 비슷한지 확인한 뒤 코어와 필드 지원을 비교해야 합니다.

여러 데스크톱 기기에서 v2rayN을 사용한다면 구독 그룹 이름과 라우팅 대상을 통일할 수 있지만 수신 포트, 설치 경로와 시스템 프록시는 기기별로 기록해야 합니다. macOS와 Linux의 시스템 프록시 구현은 다르고 명령줄 도구도 각자의 환경 변수를 사용할 수 있습니다. 공유하는 것은 설정 논리이지 운영체제 상태가 아닙니다. 이전 문서에는 ‘달성해야 할 동작’을 설명하고 각 플랫폼의 구체적인 확인 방법도 별도로 남겨야 합니다.

안정적인 설정 프로필 세 가지 설계

일상 설정을 세 단계로 나눌 수 있습니다. 기본 프로필은 활성 설정 하나, 기본 라우팅과 시스템 프록시만 포함해 코어와 브라우저의 최단 경로를 검증합니다. 분할 프로필은 검증된 직접 연결 규칙과 명확한 DNS 경로를 추가해 일상적인 데스크톱 사용에 활용합니다. 확장 프로필은 분할 프로필에 TUN을 더해 시스템 프록시를 읽지 않는 애플리케이션까지 포함합니다. 세 프로필은 각각 독립적으로 되돌릴 수 있어야 하며 문제가 생기면 모든 설정을 삭제하지 말고 먼저 기본 프로필로 낮추세요.

프로필 간 차이는 문서로 기록해야 합니다. 시스템 프록시 상태, TUN 상태, DNS 설정, 라우팅 규칙 그룹과 애플리케이션 독립 프록시를 포함하세요. 전환 후에는 같은 테스트 대상 세트로 검증합니다. 그러면 문제가 원격 설정 변경 때문인지 로컬 고급 기능 때문인지 빠르게 판단할 수 있습니다. 기본 프로필도 실패한다면 TUN을 계속 조정할 필요가 없습니다. 기본 프로필은 정상이고 확장 프로필만 실패한다면 문제 범위가 가상 인터페이스, 라우팅 또는 DNS로 좁혀집니다.

지속적인 학습 자료 순서

먼저 개념 빠른 확인으로 프로토콜, 코어, 구독, 시스템 프록시와 라우팅 용어를 정리한 다음 클라이언트 비교에서 플랫폼별 차이를 이해하세요. 구체적인 문제가 생기면 자주 묻는 질문에서 범주를 찾고 관련 글을 읽습니다. Project V, V2Fly, Xray와 세 클라이언트의 관계는 오픈 소스 생태계와 클라이언트 선택 안내를 참고하세요. 자료는 ‘개념—조작—검증—문제 해결’ 순서로 연결해 읽어야 하며 단편적인 매개변수만 모아서는 안 됩니다.

이 단계에 이르면 설정의 초점은 ‘한 번 연결 성공’에서 ‘동작을 장기간 예측 가능하게 유지’하는 것으로 바뀝니다. 최소 기준선을 보존하고 동시에 바꾸는 변수를 제한하며 애플리케이션 연결 범위를 기록하고 각 라우팅 규칙의 일치 근거를 검증하세요. 구독과 민감한 설정은 관리되는 방식으로 백업해야 합니다. 이 방법은 v2rayN, v2rayNG, v2flyNG에 적용할 수 있으며 클라이언트 화면 차이, 코어 동작과 운영체제 네트워크 메커니즘을 구분하는 데도 도움이 됩니다.