시스템 프록시·전체 모드·중국 본토 우회 모드 완벽 비교: 세 가지 모드 선택 가이드

시스템 프록시, 전체 모드, 중국 본토 우회 모드는 같은 클라이언트 화면에 함께 표시되는 경우가 많지만 동일한 계층의 기능은 아닙니다. 시스템 프록시는 애플리케이션이 연결을 로컬 프록시 포트로 전달할지 결정하고, 나머지 두 모드는 해당 연결이 V2Ray 또는 Xray 코어에 들어온 뒤 어느 아웃바운드로 나갈지 결정합니다. “트래픽 진입점”과 “코어 라우팅”을 나누어 이해하는 것은 웹페이지가 열리지 않거나 중국 본토 사이트가 느려지거나 일부 프로그램이 프록시를 사용하지 않는 문제를 해결하는 기본입니다.

이 글 한눈에 보기

이 글은 v2rayN 또는 v2rayNG를 처음 사용하며 트레이 메뉴와 라우팅 프리셋을 혼동하기 쉬운 사용자를 위한 안내입니다. 읽고 나면 애플리케이션 트래픽이 코어로 들어가는지 확인하고, 전체 모드와 중국 본토 우회 규칙의 실제 범위를 이해하며, 웹 탐색·개발·다운로드·모바일 네트워크 상황에 맞는 모드를 선택할 수 있습니다.

먼저 두 제어 계층을 구분하세요: 시스템 프록시는 진입점, 라우팅 모드는 출구입니다

데스크톱 시스템에서 v2rayN은 코어를 시작한 뒤 로컬 포트를 수신 대기합니다. 일반적인 설정에서는 SOCKS 진입점이 127.0.0.1:10808, HTTP 진입점이 127.0.0.1:10809입니다. 구형 설정 마이그레이션, 포트 충돌 또는 사용자의 변경으로 값이 달라질 수 있으므로 실제 포트는 v2rayN의 「설정」→「매개변수 설정」에서 확인해야 합니다.

시스템 프록시를 켜면 클라이언트가 운영체제의 프록시 주소를 이 로컬 포트로 지정합니다. 브라우저와 시스템 프록시 설정을 따르는 데스크톱 프로그램은 곧바로 요청을 v2rayN으로 전달합니다. 시스템 프록시를 끄는 것은 운영체제의 진입점 지정만 취소할 뿐 코어를 중지하거나 이미 연결된 세션을 반드시 종료하는 것은 아닙니다. SOCKS 주소를 직접 입력한 프로그램은 계속 로컬 프록시를 사용할 수 있습니다.

시스템 프록시만 켜기

운영체제 설정을 따르는 애플리케이션을 로컬 프록시 포트에 연결하며, 최종 경로는 현재 라우팅 규칙과 아웃바운드 설정이 결정합니다.

적합: 브라우저, 일반 데스크톱 앱, 필요할 때만 연결하는 일상적인 사용

전체 라우팅 모드

코어에 들어온 일반 요청을 우선 프록시 아웃바운드로 보내 복잡한 규칙이 연결성 판단에 미치는 영향을 줄입니다.

적합: 단기 문제 해결, 규칙 매칭 이상 확인, 단일 출구 테스트

중국 본토 우회 모드

시스템 프록시의 적용 범위: 일부 프로그램이 여전히 직접 연결하는 이유

시스템 프록시는 데스크톱 시스템의 모든 기기 트래픽을 가로채는 기능이 아닙니다. 대부분의 브라우저는 시스템 설정을 읽지만, 일부 다운로드 도구·명령줄 도구·게임 런처와 자체 네트워크 스택을 사용하는 프로그램은 이를 무시할 수 있습니다. 따라서 v2rayN 트레이 아이콘에 시스템 프록시가 활성화된 것으로 표시되어도 해당 프로그램은 대상 주소에 직접 연결할 수 있습니다.

10808

일반적인 로컬 SOCKS 포트

10809

일반적인 로컬 HTTP 포트

127.0.0.1

이 컴퓨터에서만 접근할 수 있는 수신 대기 주소

4개

진입점·라우팅·아웃바운드·DNS 확인 지점

프로그램이 프록시 경로에 들어갔는지 판단할 때 노드 지연 시간만 봐서는 안 됩니다. 코어 로그, 프로그램 자체의 프록시 설정, 출구 주소를 함께 확인하는 편이 정확합니다. 예를 들어 명령줄 도구에서 HTTP 프록시를 명시해 비교 요청을 보낼 수 있습니다. 프록시를 지정했을 때 새 연결이 로그에 나타나고 지정하지 않았을 때 기록이 없다면, 해당 도구가 기본적으로 시스템 프록시를 사용하지 않는다는 뜻입니다.

curl --proxy http://127.0.0.1:10809 https://api.ipify.org
curl https://api.ipify.org

두 번의 요청으로 최소한의 비교 조건을 만들 수 있습니다. 첫 번째 요청은 로컬 HTTP 진입점을 명시적으로 거치고, 두 번째 요청은 명령줄 도구의 기본 네트워크 설정을 사용합니다. 출구 주소가 달라지는지는 노드·현재 라우팅·로컬 네트워크에 따라 다르지만, 코어 로그에 해당 연결이 나타나는지는 요청이 v2rayN에 들어갔는지 직접 보여 줍니다. 테스트가 끝난 뒤 구독이나 노드 매개변수를 수정할 필요는 없습니다.

포트는 반드시 로컬 설정을 기준으로 확인하세요

10808과 10809는 흔한 예시일 뿐 모든 설치 환경에서 고정된 값은 아닙니다. 로그에 주소가 이미 사용 중이라는 메시지가 표시되면 노드를 계속 바꾸지 말고 「설정」→「매개변수 설정」에서 수신 대기 포트를 확인하세요.

Android에서는 v2rayNG와 v2flyNG가 일반적으로 시스템에서 제공하는 VPN 서비스를 통해 트래픽을 받으므로 데스크톱 시스템 프록시와 개념이 다릅니다. v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용하며, 두 클라이언트 모두 트래픽이 코어에 들어온 뒤 라우팅 규칙을 계속 적용할 수 있습니다. 애플리케이션별 프록시를 사용한다면 먼저 대상 앱이 선택한 범위에 포함되어 있는지도 확인해야 합니다.

전체 모드의 실제 의미: 전체 라우팅이 모든 트래픽을 가로채는 것은 아닙니다

전체 모드는 일반적으로 코어에 들어온 트래픽 대부분을 프록시 아웃바운드로 보낸다는 뜻입니다. 노드 연결성을 임시로 확인할 때 유용합니다. 중국 본토 우회 모드에서 특정 도메인이 열리지 않다가 전체 모드에서 정상으로 돌아온다면, 문제는 노드 자체보다 도메인 분류·DNS 결과·규칙 순서에 있을 가능성이 큽니다.

권장 방법: 먼저 진입점을 확인한 뒤 전체 모드로 짧게 비교하세요

데스크톱 v2rayN

트레이 메뉴에서 시스템 프록시 켜기
「설정」→「매개변수 설정」에서 로컬 포트 확인
전체 라우팅으로 잠시 전환한 뒤 코어 로그 확인

Android v2rayNG

VPN 서비스가 연결되었는지 확인
「설정」→「라우팅 설정」에서 사전 정의 규칙 확인
애플리케이션별 프록시에 대상 앱이 포함되어 있는지 확인

전체 모드는 문제 범위를 좁히는 데 효과적이지만, 장기간 사용하기 전에는 로컬 서비스 접근성·대역폭 경로·규칙 요구 사항을 함께 고려해 유지 여부를 결정해야 합니다.

전체 모드에도 한계가 있습니다

“전체”는 현재 라우팅 정책을 설명하는 이름일 뿐 모든 애플리케이션의 네트워크 구현을 자동으로 바꾸지는 않습니다. 시스템 프록시를 무시하는 데스크톱 프로그램은 여전히 직접 연결할 수 있습니다. 로컬 HTTP 또는 SOCKS 진입점만 수신 대기하는 클라이언트 역시 진입점으로 들어오지 않은 연결을 라우팅 프리셋만으로 가로챌 수 없습니다. LAN 기기의 트래픽도 이 컴퓨터에서 전체 모드로 전환했다고 자동으로 프록시를 거치지 않습니다.

이 컴퓨터의 루프백 주소와 LAN 주소는 일반적으로 직접 연결로 유지해야 프린터·라우터 관리 페이지·로컬 개발 서비스의 연결이 끊기지 않습니다.
노드 서버 자체로 향하는 연결은 같은 프록시 아웃바운드로 다시 보내지 않도록 해야 순환이 발생하지 않습니다.
DNS 조회는 시스템·코어·애플리케이션이 각각 수행할 수 있으므로 라우팅 모드 이름만으로 실제 DNS 출구를 판단할 수 없습니다.
이미 연결된 장시간 세션에는 새 규칙이 즉시 적용되지 않을 수 있습니다. 전환 후 대상 프로그램을 다시 열거나 연결을 새로 만들어야 합니다.

전체 모드를 잠깐 사용하기 좋은 경우

구독 업데이트 후 일부 사이트만 비정상인 경우, 사용자 지정 규칙이 잘못 매칭된 것으로 의심되는 경우, 또는 VMess·VLESS 노드 자체가 연결 가능한지 확인해야 하는 경우 전체 모드를 비교용으로 사용할 수 있습니다. 전체 모드는 규칙 분기를 줄여 주지만 노드 매개변수·시스템 시간·전송 계층 설정·포트 충돌을 해결해 주지는 않습니다. 전체 모드에서도 실패한다면 로그로 돌아가 핸드셰이크·DNS·연결 시간 초과 정보를 확인하세요.

상태가 정상인 노드를 하나 선택하고 코어가 시작되었는지 확인합니다.
시스템 프록시를 켜거나 대상 앱에 로컬 프록시가 직접 지정되어 있는지 확인합니다.
전체 라우팅으로 전환한 뒤 대상 페이지를 닫았다가 다시 엽니다.
로그에서 대상 도메인·매칭된 아웃바운드·오류 유형을 기록합니다.
기존 라우팅 모드로 복원한 뒤 같은 요청을 한 번 더 보내 비교합니다.

중국 본토 우회 모드의 작동 원리: 도메인 규칙·IP 규칙·매칭 순서

중국 본토 우회 모드는 일반적으로 도메인 분류와 IP 지역 데이터를 사용해 트래픽을 분할합니다. 중국 본토에서 자주 사용하는 도메인, 중국 본토 대역으로 확인된 주소, 사설 네트워크 주소는 직접 연결로 보내고 나머지 트래픽은 프록시 아웃바운드로 보냅니다. 클라이언트 버전·라우팅 데이터 버전·구독에 포함된 설정에 따라 차이가 있을 수 있으므로, 모드 이름이 같아도 규칙이 모든 항목에서 동일한 것은 아닙니다.

먼저 대상 정보 수집: 코어는 연결에서 도메인·대상 IP·포트·네트워크 유형·인바운드 태그를 가져옵니다.
배열 순서대로 확인: 라우팅 규칙은 일반적으로 위에서 아래로 매칭되며, 매칭되면 지정된 아웃바운드를 사용하고 뒤의 일반 규칙은 계속 확인하지 않습니다.
도메인과 해석 결과 처리: 일부 정책은 도메인 분류를 직접 기준으로 삼고, 일부 규칙은 해석된 IP를 바탕으로 지역을 다시 판단합니다.
기본 아웃바운드로 처리: 앞선 규칙에 매칭되지 않은 연결은 기본 규칙에 따라 프록시 또는 직접 연결로 보냅니다.

필드 작성 순서보다 중요한 것은 규칙 순서입니다

JSON 객체 내부 필드의 순서는 일반적으로 해석 결과를 바꾸지 않지만, 라우팅 규칙 배열의 순서는 첫 번째 매칭 결과에 영향을 줍니다. 사용자 지정 도메인 직접 연결 규칙은 범위가 넓은 프록시 규칙보다 앞에 배치해야 하며, 차단 규칙도 앞선 와일드카드 규칙에 덮이지 않도록 해야 합니다.

예를 들어 중국 본토 서비스가 해외 CDN을 사용하거나 해외 서비스가 정적 리소스를 중국 본토 노드에 배치한 경우, IP 지역만 기준으로 삼으면 사용자가 기대한 출구와 달라질 수 있습니다. 도메인 규칙은 “이 서비스가 어느 경로를 사용해야 하는가”를 표현하는 데 더 적합하고, IP 규칙은 도메인이 없는 연결과 해석 결과를 보완하는 데 적합합니다. 잘못된 분할이 발생하면 먼저 로그에서 코어가 도메인을 확인했는지 순수 IP만 확인했는지 살펴보세요.

DNS도 판단 결과에 영향을 줍니다. 애플리케이션이 직접 암호화된 DNS를 사용하거나, 코어가 도메인 해석을 담당하거나, 시스템 DNS가 다른 주소를 반환하면 같은 도메인도 서로 다른 IP 규칙에 매칭될 수 있습니다. 문제를 해결할 때 DNS·노드·라우팅을 동시에 크게 변경하면 어떤 항목이 변화를 일으켰는지 확인하기 어렵습니다. 한 번에 하나의 변수만 바꾸고 연결을 새로 만드는 방법이 가장 안전합니다.

사용 상황별 선택: 일상·개발·다운로드·모바일 네트워크

대부분의 데스크톱 일상 사용에서는 시스템 프록시를 켜고 중국 본토 우회 모드를 선택하는 것이 좋은 출발점입니다. 중국 본토 서비스는 짧은 직접 연결 경로를 유지하고, 나머지 트래픽은 규칙에 따라 프록시로 보냅니다. 규칙 오판이 발생하거나 단일 출구가 필요하거나 문제를 비교해야 할 때만 전체 모드로 잠시 전환하세요.

브라우저는 열리는데 명령줄 다운로드가 계속 시간 초과됩니다. 전체 모드로 바꿔야 하나요?

먼저 라우팅을 바꾸지 마세요. 「설정」→「매개변수 설정」에서 HTTP 포트를 확인한 다음 명령줄 도구에 http://127.0.0.1:10809을 명시적으로 설정하세요. 이후 코어 로그에 요청이 나타난다면 원래 문제는 프로그램이 시스템 프록시를 사용하지 않았던 것입니다.

중국 본토 우회 모드에서 특정 웹사이트가 열리지 않지만 전체 모드에서는 정상입니다. 어떻게 해야 하나요?

코어 로그에서 도메인과 아웃바운드 태그를 확인해 직접 연결로 분류되었는지 살펴보세요. 해당 도메인에 프록시 규칙을 추가하고, 범위가 넓은 중국 본토 도메인 또는 중국 본토 IP 규칙보다 앞에 배치한 뒤 연결을 새로 만들어 테스트하세요.

모드를 전환했는데 페이지의 출구가 왜 그대로인가요?

브라우저가 기존 장시간 연결을 재사용했을 수 있습니다. 해당 탭을 닫고 연결이 해제될 때까지 기다리세요. 필요하면 대상 애플리케이션을 재시작한 뒤 출구 확인 페이지에 다시 접속하세요. 이전 페이지를 새로 고치는 것만으로 규칙 적용 여부를 판단하지 마세요.

전체 모드를 켠 뒤 로컬 개발 주소에 접속할 수 없습니다. 어떻게 해야 하나요?

localhost·127.0.0.0/8·실제로 사용하는 LAN 대역에는 직접 연결 규칙을 유지하고, 이 규칙이 전체 프록시 기본 규칙보다 앞에 오도록 하세요. 로컬 포트 서비스는 원격 노드로 보내면 안 됩니다.

v2rayNG는 연결되었지만 특정 Android 앱에 트래픽 기록이 없습니다

애플리케이션별 프록시 설정으로 이동해 현재 포함 방식인지 제외 방식인지 확인하고, 대상 앱이 해당 목록에 있는지 점검하세요. 그런 다음 VPN 서비스를 연결 해제했다가 다시 연결해 앱 범위 설정을 적용하세요.

개발 환경에서는 패키지 관리자·컨테이너·가상 머신·로컬 콜백 주소를 별도로 처리해야 하는 경우가 많습니다. 브라우저가 시스템 프록시를 사용한다고 해서 터미널·컨테이너 내부·가상 머신도 같은 설정을 자동으로 상속하는 것은 아닙니다. 각 환경의 HTTP·HTTPS·SOCKS 프록시 변수를 따로 확인하고, 사내 저장소·로컬 API·루프백 대역은 직접 연결로 설정해야 합니다.

일상적인 웹 탐색: 시스템 프록시를 켜고 중국 본토 우회 모드를 기본 라우팅으로 사용합니다. 특정 사이트에 문제가 생기면 정확한 도메인 규칙을 추가합니다.
규칙 문제 해결: 전체 모드로 잠시 비교한 뒤 로그를 보관하고 원래 라우팅으로 복원합니다.
다운로드 도구: 시스템 프록시 아이콘만 믿지 말고 먼저 도구 자체의 프록시 메뉴를 확인합니다.
로컬 개발: localhost·루프백 주소·실제 LAN 대역을 직접 연결로 명시해 콜백 요청이 불필요하게 우회하지 않도록 합니다.
Android 기기: 데스크톱 시스템 프록시 개념을 그대로 적용하지 말고 VPN 연결·라우팅 프리셋·애플리케이션별 범위를 각각 확인합니다.

모드 전환 전후의 표준 점검 절차

안정적인 문제 해결은 먼저 진입점을 확인하고, 다음으로 라우팅을 검증한 뒤, 마지막으로 노드를 점검하는 순서로 진행해야 합니다. 여러 노드·DNS 설정·모드 사이를 바로 반복 전환하면 로그의 비교 가치가 떨어집니다. 다음 순서는 v2rayN에 적용할 수 있으며 v2rayNG의 VPN·라우팅·코어 로그 화면에도 대응됩니다.

코어 상태 확인: 클라이언트를 시작한 뒤 로그를 확인하고 로컬 수신 대기가 성공했는지, address already in use와 같은 포트 사용 오류가 없는지 확인합니다.
트래픽 진입점 확인: 데스크톱에서는 시스템 프록시 또는 앱 내 프록시를 확인하고, Android에서는 VPN 서비스와 애플리케이션별 범위를 확인합니다.
테스트 노드 고정: 비교 과정 전체에서 노드 하나만 사용해 노드 차이가 결론에 영향을 주지 않도록 합니다.
두 라우팅을 각각 테스트: 먼저 중국 본토 우회 모드를 사용한 뒤 전체 모드로 전환하고, 매번 대상 연결을 새로 만듭니다.
매칭 결과 확인: 화면의 지연 시간만 보지 말고 대상 도메인·대상 IP·아웃바운드 태그·오류 유형을 기록합니다.
최소한으로 수정: 잘못된 분할임을 확인했다면 정확한 규칙 하나만 추가하고, 진입점 문제라면 애플리케이션 프록시 설정만 조정합니다.

선택 결론

시스템 프록시는 데스크톱 앱이 로컬 프록시로 들어가는 진입 스위치이고, 전체 모드는 단일 출구 확인과 규칙 문제 해결에 유용한 라우팅 전략이며, 중국 본토 우회 모드는 대부분의 혼합 접속 환경에서 장기간 사용하기 좋은 출발점입니다. 세 기능은 진입점과 라우팅이라는 두 계층에 따라 조합해야 하며, 이름만 보고 서로 배타적인 버튼으로 이해해서는 안 됩니다.

특정 프로그램이 모드 전환에 전혀 영향을 받지 않는다면 먼저 코어에 들어갔는지 확인하세요. 같은 프로그램이 전체 모드에서는 정상이고 중국 본토 우회 모드에서는 비정상이라면 규칙 분류와 DNS를 점검하세요. 두 모드 모두 실패한다면 노드 매개변수·네트워크 연결성·시스템 시간·코어 로그로 돌아가 원인을 계속 좁혀야 합니다. 이 순서로 판단하면 진입점 문제를 라우팅 문제로 잘못 판단하는 일을 줄일 수 있습니다.