시스템 프록시·전체 모드·중국 본토 우회 모드 차이: 세 가지 프록시 방식 선택 가이드

v2rayN의 ‘시스템 프록시’, ‘전체’, ‘중국 본토 우회’는 같은 계층에 있는 상호 배타적인 세 가지 스위치가 아닙니다. 시스템 프록시는 어떤 애플리케이션이 연결을 로컬 클라이언트에 넘길지 결정하고, 전체와 중국 본토 우회는 연결이 Xray 또는 V2Ray 코어에 들어온 뒤 어떤 아웃바운드를 사용할지 결정합니다. 트래픽 인계 지점과 코어 라우팅을 먼저 구분해야 브라우저는 접속되는데 특정 프로그램은 직접 연결되는 현상, 전체 모드로 바꾸면 중국 본토 웹사이트가 느려지는 현상, 게임 트래픽이 노드를 거치지 않는 현상을 설명할 수 있습니다.

시스템 프록시, 전체 모드, 중국 본토 우회 모드는 각각 무엇을 제어할까

시스템 프록시는 운영체제의 진입 계층에 해당합니다. v2rayN 7.13.2의 일반적인 기본 설정을 예로 들면, 클라이언트는 로컬에서 SOCKS 포트 127.0.0.1:10808와 HTTP 포트 127.0.0.1:10809를 수신 대기합니다. 트레이 메뉴에서 ‘시스템 프록시’ → ‘시스템 프록시 자동 구성’을 선택하면 Windows 프록시 설정이 로컬 HTTP 진입점으로 지정됩니다. 브라우저, 일부 오피스 프로그램 및 시스템 네트워크 설정을 따르는 프로그램은 요청을 v2rayN에 전달합니다.

전체 모드는 코어 라우팅 계층에 해당합니다. 연결이 로컬 프록시 포트로 들어온 뒤에는 코어가 프록시 가능한 트래픽을 현재 선택한 VMess, VLESS 또는 다른 노드 아웃바운드로 일괄 전송합니다. 여기서 ‘전체’는 시스템의 모든 프로세스가 자동으로 프록시를 사용한다는 뜻이 아닙니다. 시스템 프록시 설정을 읽지 않거나 소켓을 직접 생성하거나 독립 네트워크 스택을 사용하는 프로그램은 여전히 로컬 수신 포트를 우회할 수 있습니다.

중국 본토 우회 모드 역시 라우팅 계층에 속하지만, 도메인과 대상 IP를 기준으로 트래픽을 분류합니다. 일반적인 규칙에서는 geosite:cn, geoip:cn 및 로컬 네트워크 주소를 직접 연결하고 나머지 일치 항목은 프록시로 보냅니다. 이 결과는 GeoSite 및 GeoIP 데이터의 최신 상태뿐 아니라 도메인 조회 결과, 규칙 순서와 최종 기본 규칙에도 영향을 받습니다. 모든 웹사이트의 위치를 실시간으로 판별하는 기능으로 이해해서는 안 됩니다.

• 트래픽 인계: 시스템 프록시, HTTP/SOCKS 포트 수동 입력, TUN 또는 투명 프록시가 트래픽을 코어로 진입시킵니다.
• 라우팅 판단: 전체 모드, 중국 본토 우회 및 사용자 지정 규칙이 코어에 들어온 뒤 직접 연결·프록시·차단 중 어떤 아웃바운드를 사용할지 결정합니다.
• 노드 프로토콜: VMess, VLESS 등은 클라이언트와 서버 사이의 연결 방식을 설명하며, 트래픽 인계 모드와는 다릅니다.

시스템 프록시를 켜도 일부 프로그램이 직접 연결되는 이유

시스템 프록시는 운영체제 수준의 전체 트래픽 리디렉션이 아닙니다. 브라우저는 대체로 Windows 프록시 설정을 읽지만, 게임 런처·업데이터·명령줄 도구 및 UDP 기반 일부 프로그램은 이 설정을 무시할 수 있습니다. 일부 앱은 시작 시점의 프록시 상태만 읽으므로 v2rayN에서 모드를 바꾼 뒤 앱을 완전히 종료하고 다시 시작해야 합니다. 다른 앱은 자체 프록시 옵션을 제공하므로 소프트웨어 내부에 127.0.0.1과 해당 포트를 입력해야 합니다.

DNS도 관찰 결과에 영향을 줍니다. 애플리케이션이 먼저 시스템 DNS로 IP를 얻은 뒤 SOCKS 또는 HTTP 진입점으로 연결할 수 있고, 원격 DNS·FakeDNS 또는 TUN을 활성화하면 조회 경로가 달라집니다. 웹페이지가 열린다는 사실만으로 도메인 조회와 데이터 연결이 같은 출구를 사용한다고 판단할 수는 없습니다. 점검할 때는 브라우저 화면만 보지 말고 v2rayN 실시간 로그의 대상 주소, 인바운드 태그와 아웃바운드 태그를 확인해야 합니다.

v2rayN 세 가지 모드의 설정 및 확인 순서

조정하기 전에 먼저 구독을 업데이트하고, 사용 가능한 것으로 확인된 노드를 하나 선택합니다. 구독은 서버 설정 목록일 뿐 시스템 프록시 상태를 자동으로 결정하지 않습니다. VMess 또는 VLESS 노드로 바꿔도 모든 프로그램의 트래픽이 자동으로 인계되지는 않습니다. 한 번에 하나의 변수만 변경하고 기존 시스템 프록시와 라우팅 모드를 기록하는 것이 좋습니다.

v2rayN 7.x에서는 먼저 ‘설정’ → ‘매개변수 설정’ → ‘기본 설정’으로 들어가 로컬 수신 포트가 다른 프로그램과 충돌하지 않는지 확인합니다. 그런 다음 트레이 메뉴에서 ‘시스템 프록시’ → ‘시스템 프록시 자동 구성’을 선택하고, 라우팅 메뉴에서 ‘전체’ 또는 ‘중국 본토 우회’를 선택합니다. 세부 버전에 따라 메뉴 문구는 조금 다를 수 있지만, 진입 계층과 라우팅 계층은 여전히 따로 설정해야 합니다.

1. 노드를 선택한 뒤 지연 시간 테스트를 한 번 실행합니다. 지연 시간은 탐색 결과만 보여 줄 뿐 실제 웹페이지나 다운로드 연결 테스트를 대신할 수 없습니다.
2. 시스템 프록시를 켜고 테스트할 브라우저를 다시 시작한 다음, 자주 사용하는 중국 본토 웹사이트와 프록시 출구가 필요한 서비스에 접속합니다.
3. v2rayN 실시간 로그를 열어 요청이 로컬 HTTP 또는 SOCKS 인바운드로 들어오는지 확인하고, direct와 proxy 중 어떤 아웃바운드를 사용했는지 살펴봅니다.
4. 먼저 전체 모드로 전환해 노드 자체를 확인합니다. 전체 모드는 정상인데 중국 본토 우회에서 문제가 생긴다면 라우팅 순서, GeoSite, GeoIP 및 DNS를 집중적으로 점검합니다.
5. 테스트가 끝나면 원래 모드로 복원합니다. 앱에 프록시를 수동으로 입력했다면 중복 프록시 체인이 생기지 않도록 해당 설정도 함께 되돌려야 합니다.

일상 브라우징·해외 서비스·게임 연결에는 어떤 모드를 선택할까

일상적인 웹페이지와 오피스 소프트웨어

‘시스템 프록시 + 중국 본토 우회’를 우선 선택합니다. 중국 본토 웹페이지, 소프트웨어 업데이트와 로컬 서비스는 대체로 직접 연결되고, 해외 서비스는 규칙에 따라 프록시를 사용하므로 노드 트래픽과 연결 지연을 더 쉽게 관리할 수 있습니다. 특정 도메인이 잘못 분류되면 전체 모드로 계속 바꾸기보다 우선순위가 높은 도메인 규칙을 추가하는 편이 좋습니다.

해외 서비스를 일시적으로 점검할 때

먼저 전체 모드를 사용해 문제 범위를 좁힙니다. 중국 본토 우회에서는 페이지가 로드되지 않지만 전체 모드에서 즉시 복구된다면, 해당 도메인이 직접 연결 규칙에 걸렸는지, DNS가 예상과 다른 주소를 반환했는지, 규칙 목록에 더 앞선 일치 항목이 있는지 확인합니다. 원인을 확인한 뒤 규칙을 수정하고 다시 분할 라우팅으로 돌아갑니다.

게임 및 실시간 UDP

시스템 프록시만 켜서는 게임 트래픽을 인계하기에 부족한 경우가 많습니다. 시스템 프록시를 읽지 않는 프로세스까지 인계해야 한다면 v2rayN의 TUN 모드를 검토할 수 있습니다. TUN은 가상 네트워크 인터페이스를 만들어 인계 범위를 넓히지만 DNS, 라우팅 테이블, 관리자 권한과 로컬 네트워크 접근에 관한 점검 항목도 늘어납니다.

• 웹 브라우징: 시스템 프록시 + 중국 본토 우회를 우선 사용하고 도메인 규칙과 브라우저 출구를 중점적으로 확인합니다.
• 해외 서비스: 짧은 시간 동안 전체 모드로 진단한 뒤 도메인 규칙을 사용해 정밀하게 분할 라우팅합니다.
• 실시간 게임: 먼저 서버 지역, 기본 지연 시간과 패킷 손실을 확인한 뒤 TUN을 검토합니다. 프록시 경로가 물리적 거리로 인한 지연을 자동으로 줄여 주지는 않습니다.
• 로컬 네트워크 장치: 프린터, 라우터 관리 페이지와 파일 공유 주소는 직접 연결로 유지해야 하며, 일반적인 사설 주소 대역을 원격 노드로 보내서는 안 됩니다.

중국 본토 우회 모드가 잘못 분류될 때 확인할 규칙

규칙 시스템은 대개 순서대로 매칭하고, 일치하면 지정된 아웃바운드를 사용합니다. 하나의 도메인이 사용자 지정 도메인 규칙과 GeoSite 분류에 동시에 포함될 수 있고, 조회된 IP가 GeoIP에 매칭될 수도 있습니다. 점검할 때는 가장 구체적인 사용자 지정 규칙부터 시작해 데이터 세트 규칙과 최종 기본 규칙을 차례로 확인하고, 여러 규칙 그룹을 동시에 일괄 수정하지 않는 것이 좋습니다.

도메인 처리 정책에 따라 IP 규칙의 판단 참여 여부도 달라집니다. 코어가 도메인만 기준으로 매칭하면 일부 연결은 추가 조회 후 GeoIP 매칭으로 이어지지 않습니다. 반대로 조회가 필요한 정책을 사용하면 DNS 응답 결과가 아웃바운드에 영향을 줄 수 있습니다. 설정 개념은 아래의 단순화된 구조로 이해할 수 있으며, 실제 필드는 현재 코어와 클라이언트가 생성한 설정을 기준으로 해야 합니다.

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

세 가지 모드의 최종 선택 기준

대부분의 데스크톱 사용자에게 안정적인 출발점은 ‘시스템 프록시 자동 구성 + 중국 본토 우회’입니다. 일반 브라우저와 시스템 설정을 따르는 소프트웨어를 지원하면서 중국 본토 및 로컬 네트워크 트래픽은 직접 연결로 유지합니다. 전체 모드는 짧은 진단이나 이미 인계된 모든 연결을 노드로 통일해야 하는 상황에 더 적합하며, 모든 네트워크 문제를 해결하는 고정 스위치로 사용해서는 안 됩니다.

대상 프로그램이 시스템 프록시를 읽지 않는다면 먼저 앱 내부 HTTP/SOCKS 설정을 선택합니다. 더 많은 프로세스, UDP 또는 개별 프록시 설정이 불가능한 트래픽까지 인계해야 할 때만 TUN을 검토합니다. 설정을 바꿀 때마다 실시간 로그로 인바운드와 아웃바운드를 확인해 웹페이지가 열리는지만으로 설정이 올바르다고 판단하지 않도록 합니다.

1. 브라우저와 일반 데스크톱 소프트웨어: 시스템 프록시 + 중국 본토 우회.
2. 노드 또는 프로토콜 연결 점검: 시스템 프록시 + 전체, 확인 후 분할 라우팅으로 복원.
3. 단일 앱의 잘못된 라우팅: 전체 모드로 전환하지 말고 정확한 도메인 또는 IP 규칙을 추가.
4. 시스템 프록시를 읽지 않거나 UDP에 의존하는 경우: 앱 내부 프록시를 확인하고 필요하면 TUN을 검토.
5. 모드가 자주 잘못 분류되는 경우: 지리 데이터 업데이트, DNS·규칙 순서·최종 기본 규칙 확인.