01 · 교통 진입 및 진출

시스템 프록시 설정은 참여 애플리케이션을 로컬 코어로 보냅니다. 모든 앱에서 이를 사용하도록 강요하지는 않습니다. 트래픽이 도착하면 라우팅에서는 직접, 프록시, 차단 또는 다른 아웃바운드를 선택합니다.

자동 시스템 프록시는 선택한 대상을 우회하는 규칙과 공존할 수 있습니다. 라우팅 변경 사항은 트래픽을 코어로 보내지 않는 애플리케이션에는 영향을 미칠 수 없습니다.

  1. 앱
  2. 시스템/수동 프록시/TUN
  3. 코어 라우팅
  4. 직접/프록시/차단

02 · 4가지 시스템 프록시 모드

이 모드는 서비스가 시작되거나 다시 시작될 때 시스템 설정을 제어합니다. 다른 애플리케이션에서도 해당 설정을 관리하는지 확인하세요.

모드행동일반적인 용도
시스템 프록시 지우기프록시 설정 제거일반 네트워킹으로 돌아가기
자동 시스템 프록시로컬 클라이언트 리스너를 가리킵니다.시스템 설정을 사용하는 브라우저 및 앱
그대로 놔두세요기존 설정 유지수동으로 구성된 앱 또는 다른 관리자
PAC(윈도우)스크립트는 직접 또는 프록시를 선택합니다.코어 라우팅 전 목적지 결정

03 · 일상적인 작업 흐름

작업 프로필을 가져와 활성화하고, 코어 시작을 확인하고, 자동 시스템 프록시를 활성화하고, 적절한 기존 라우팅 사전 설정을 선택합니다. 브라우저에 요청하고 로그에서 대상/아웃바운드를 검사합니다.

수동 프록시 설정이 있는 단일 앱의 경우 127.0.0.1에서 HTTP 또는 SOCKS5와 클라이언트의 실제 혼합 수신 포트를 사용합니다. 이것은 원격 서버 포트가 아닙니다.

로컬 포트 참조

04 · PAC 대 자동 모드

자동 모드는 라우팅을 위해 앱 요청을 코어로 보냅니다. PAC는 먼저 애플리케이션 측 스크립트를 실행합니다. DIRECT는 코어를 우회하는 반면 프록시된 요청은 여전히 코어 라우팅을 통과합니다.

Windows의 경우 저장소의 pac.txt에 FindProxyForURL와 같은 JavaScript가 포함되어 있습니다. 편집하기 전에 백업하고 유효한 구문을 유지하세요. 앱이 스크립트를 캐시할 수 있으므로 변경 후 설정을 다시 적용하세요. PAC는 이를 지원하는 애플리케이션에만 영향을 미칩니다.

05 · 사전 설정 및 사용자 정의 라우팅

생성된 라우팅 사전 설정으로 시작합니다. 규칙은 순서대로 평가됩니다. 특정 도메인/IP 규칙은 포괄 규칙보다 먼저 속합니다. 대상에 대한 규칙을 추가하고 편집된 규칙 세트를 활성화합니다.

전역 라우팅 사전 설정은 이미 코어 내부에 있는 트래픽을 제어합니다. 시스템 프록시를 무시하는 애플리케이션이 코어를 사용하도록 강제할 수는 없습니다.

라우팅 규칙 작성

06 · 네트워킹 종료 및 복원

더 이상 필요하지 않은 경우 종료하기 전에 시스템 프록시 지우기를 선택하십시오. 종료, 강제 종료 또는 충돌로 인해 설정이 그대로 유지될 수 있습니다.

클라이언트가 중지되고 검색에 실패하면 여전히 127.0.0.1을 가리키는 프록시가 있는지 확인하세요. 클라이언트를 다시 열어서 지우거나 OS 네트워크 설정을 통해 오래된 설정을 제거한 다음 일반 연결을 테스트하세요.

07 · 규칙은 순서가 지정된 JSON 배열입니다.

각 개체는 규칙입니다. 활성화하면 이를 토글하고 설명에 레이블을 지정하며 outboundTag는 기존 아웃바운드를 선택합니다. 클라이언트 편집기 스키마는 기본 핵심 구성과 동일하지 않습니다. 클라이언트 규칙을 시작점으로 내보냅니다.

저장 후 규칙 세트를 활성화하고 프로필을 다시 적용합니다. 첫 번째 일치 규칙에서 평가가 중지됩니다.

08 · 공통 매칭 필드

조건 내의 여러 값은 일반적으로 대안을 제공합니다. 서로 다른 조건은 서로를 제약합니다. v2rayN는 결합 시 도메인, IP 및 프로세스 필드를 분할하므로 규칙당 이 중 하나를 사용합니다.

필드구문 및 효과
domain배열: 전체:example.com 정확; domain:example.com에는 하위 도메인이 포함됩니다. 정규식: 정규식; 지질명소: 카테고리
ipIP, CIDR 또는 geoip: 카테고리; geoip:비공개 일치 비공개 범위
port대상 포트 또는 범위(예: 443 또는 1000-2000
sourcePort / source소스 포트/IP 제약, 핵심 지원에 따라 다름
networktcp, udp 또는 둘 다
protocolhttp, tls 또는 bittorrent와 같은 스니핑된 애플리케이션 프로토콜; 스니핑이 필요하다
inboundTag요청을 받은 인바운드와 일치
outboundTag직접, 프록시, 차단 또는 기존 사용자 정의 태그
enabled / remarks클라이언트 활성화 플래그/레이블

09 · 정확한 규칙부터 시작하세요

이 예에서는 example.com과 해당 하위 도메인을 직접 보내고 그 밖의 모든 항목은 프록시를 통해 보냅니다. 포괄적인 내용은 마지막에 속합니다. 기존 규칙 세트에서 기존 포괄 항목 앞에 특정 규칙을 추가합니다.

JSON · 클라이언트 라우팅 규칙복사
[
  {
    "remarks": "Example domain direct",
    "domain": [
      "domain:example.com"
    ],
    "outboundTag": "direct",
    "enabled": true
  },
  {
    "remarks": "Fallback proxy",
    "port": "0-65535",
    "outboundTag": "proxy",
    "enabled": true
  }
]

10 · 일반적인 규칙 조합

개인 IP 범위 및 개인 도메인에 대한 직접 규칙을 사용하여 일치하는 GEO 데이터가 설치된 상태에서 로컬 리소스에 접근할 수 있도록 합니다. network=udp, port=443 및 outboundTag=block인 규칙은 UDP 443을 차단하고 QUIC/HTTP/3에 영향을 미칠 수 있습니다. 이는 보편적인 연결 수정이 아닙니다.

도메인 규칙에는 도메인 정보가 필요합니다. IP에 직접 연결하는 앱은 IP와 일치하지 않을 수 있습니다. 스니핑, DNS 모드 및 애플리케이션 관리 암호화 DNS는 코어가 볼 수 있는 내용에 영향을 미칩니다.

11 · 도메인 해결 전략

Xray AsIs는 라우팅 중에 도메인을 유지합니다. IPIfNonMatch는 도메인 일치 실패 후 확인합니다. IPOnDemand는 IP 기반 규칙에 필요한 시기를 확인합니다. 이 라우팅 정책은 실제 아웃바운드 DNS 확인과 별개입니다.

도메인 규칙을 의도적으로 배치하고 의도치 않게 광범위한 IP 규칙이 우선 적용되는 것을 방지합니다.

DNS 설정

12 · 가져오기, 검증 및 되돌리기

파일, 클립보드 또는 구독 URL에서 규칙을 가져옵니다. 이전 세트를 유지하고, 주석/후행 쉼표 없이 유효한 JSON를 사용하고, 아웃바운드 태그 및 데이터 카테고리를 확인하고, 지나치게 광범위한 첫 번째 규칙을 피하십시오.

새로운 연결로 특정 대상을 테스트하고 선택한 아웃바운드를 검사합니다. 기존의 수명이 긴 연결은 이전 경로를 유지할 수 있습니다. 필요한 경우 대상 앱을 다시 시작하십시오. 실패 시 이전 규칙 세트로 되돌립니다.

출처공식 문서

이 페이지에는 단계와 매개변수가 제공됩니다. 참조는 출처를 식별합니다. 2026년 10월 19일에 검토되었습니다.