규칙·전역·직접 연결 모드 비교: Clash 프록시 모드 선택 가이드

먼저 규칙 모드를 선택하고 트래픽이 코어로 들어오는지 확인하세요

일상적인 사용에는 먼저 규칙 모드(Rule)를 선택하세요. 구독이 활성화되어 있고 대상 정책 그룹에서 노드가 선택되어 있는지 확인한 다음 테스트할 사이트에 접속합니다. 특정 사이트만 문제가 있다면 잠시 전역 모드로 바꿔 비교해 보세요. 현재 네트워크에서 대상에 직접 접속할 수 있는지 확인하려면 직접 연결 모드로 전환하면 됩니다. 설정은 한 번에 하나씩 바꿔야 결과를 정확히 판단할 수 있습니다.

세 모드는 Clash 또는 Clash Meta(mihomo) 코어에 이미 들어온 연결을 어떤 방식으로 내보낼지 결정합니다. 어떤 앱의 트래픽을 가로챌지 정하는 기능은 아닙니다. 시스템 프록시, 앱 내 프록시, TUN은 트래픽을 코어로 보내고, 규칙·전역·직접 연결 모드는 코어에 들어온 트래픽을 처리합니다. 이 두 설정은 구분해서 살펴봐야 합니다.

모드	코어에 들어온 뒤의 처리 방식	사용하기 좋은 상황	먼저 확인할 항목
규칙 Rule	규칙을 위에서부터 확인하고 해당 아웃바운드 또는 정책 그룹으로 전달	일상적인 트래픽 분기, 직접 연결과 프록시 구분	일치한 규칙과 정책 그룹에서 실제로 선택된 항목
전역 Global	대개 내장 GLOBAL 정책 그룹으로 전달	규칙 누락을 잠시 점검하거나 출구를 통일해 테스트	GLOBAL에서 최종 선택된 아웃바운드
직접 연결 Direct	코어가 대상에 직접 연결	로컬 네트워크와 비교하거나 프록시 노드 문제 점검	로컬 DNS와 네트워크 연결 가능 여부

세 가지 트래픽 흐름: 진입 경로는 같고 아웃바운드 결정은 다릅니다

아래 그림은 가로채기가 이미 적용된 앱 연결 하나를 예로 듭니다. 그림의 ‘프록시 선택’은 예시 정책 그룹 이름이며, 모든 구독에 고정으로 포함되는 이름이 아닙니다. 실제 설정에는 ‘노드 선택’, ‘자동 선택’ 또는 다른 이름이 쓰일 수 있습니다.

규칙 모드: 위에서부터 확인하고 처음 일치한 규칙 적용

앱 연결
  ↓ 시스템 프록시 / 앱 프록시 / TUN
Clash 또는 mihomo 코어
  ↓ rules를 위에서부터 확인
  ├─ 직접 연결 규칙 일치 → DIRECT → 대상 서비스
  ├─ 프록시 규칙 일치 → 프록시 선택 → 현재 노드 → 대상 서비스
  ├─ 차단 규칙 일치 → REJECT → 연결 종료
  └─ MATCH 기본 규칙까지 도달 → 지정된 정책 → 대상 서비스

규칙은 ‘더 구체적인 항목이 자동으로 먼저 적용’되는 방식이 아닙니다. 보통 위에서부터 확인하며, 먼저 일치한 규칙이 적용됩니다. 적용 범위가 넓은 규칙을 앞에 두면 뒤쪽의 세부 도메인 규칙은 적용되지 않을 수 있습니다. 구독에 포함된 규칙 집합도 rules 목록에서 참조되는 위치를 확인해야 합니다.

전역 모드: 일반적인 규칙 분기를 건너뜁니다

앱 연결
  ↓ 이미 트래픽 가로채기가 적용됨
Clash 또는 mihomo 코어
  ↓ Global 모드
GLOBAL 정책 그룹
  ↓ 현재 선택된 노드 또는 다른 사용 가능한 아웃바운드
대상 서비스

전역 모드로 바꾼 뒤에도 프록시 페이지에서 GLOBAL의 선택 항목을 확인해야 합니다. 전역 모드가 ‘가장 빠른 노드 자동 선택’을 뜻하는 것도, 반드시 프록시 노드를 통해 나가는 것도 아닙니다. GLOBAL에서 DIRECT를 선택했거나 선택한 하위 정책 그룹이 최종적으로 직접 연결을 가리키면 트래픽은 그대로 직접 나갑니다. 일부 클라이언트는 이 그룹을 현지화된 이름으로 표시합니다.

직접 연결 모드: 코어를 거치되 프록시 노드는 거치지 않습니다

앱 연결
  ↓ 이미 트래픽 가로채기가 적용됨
Clash 또는 mihomo 코어
  ↓ Direct 모드
DIRECT
  ↓ 현재 기기에서 사용할 수 있는 네트워크 출구
대상 서비스

직접 연결 모드는 클라이언트를 종료하는 기능도, TUN을 끄는 기능도 아닙니다. 코어가 연결과 DNS 요청을 계속 처리할 수 있지만 아웃바운드가 직접 연결로 바뀝니다. 따라서 직접 연결이 성공했다는 것은 현재의 트래픽 가로채기 및 이름 해석 환경에서 해당 연결이 직접 접속 가능하다는 뜻일 뿐입니다. 시스템 프록시, DNS, 라우팅이 클라이언트를 실행하기 전 상태로 돌아왔다고 단정할 수는 없습니다.

규칙과 정책 그룹의 연동 방식: 간단한 예제로 확인

아래는 규칙 적용 순서를 설명하기 위한 YAML 일부이며, 완전한 구독 설정을 대체하지 않습니다. ‘프록시 선택’은 proxy-groups에 미리 정의되어 있어야 합니다. example.com과 하위 도메인은 작성 방법을 보여주는 예시이며, 특정 서비스가 반드시 프록시를 사용해야 한다는 뜻은 아닙니다.

mode: rule
mixed-port: 7890
rules:
  - DOMAIN-SUFFIX,example.com,프록시 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,프록시 선택

mode: rule: 기본 처리 방식을 규칙 모드로 설정합니다. 클라이언트 UI에서 실행 중 모드를 바꾸면 이 값이 덮어써질 수 있으며, 설정을 다시 불러온 뒤에도 모드가 유지되는지는 클라이언트의 모드 덮어쓰기 저장 방식에 따라 달라집니다.
mixed-port: 7890: 하나의 진입 포트에서 HTTP와 SOCKS5 프록시 연결을 모두 받습니다. 7890은 예시이며 모든 클라이언트의 고정 포트가 아닙니다.
DOMAIN-SUFFIX: 지정한 도메인과 하위 도메인을 일치시킵니다. 일치한 트래픽은 ‘프록시 선택’으로 전달되며, 실제 노드는 정책 그룹에서 결정됩니다.
IP-CIDR: 대상 IP 대역을 기준으로 일치시킵니다. 여기서는 흔히 사용하는 사설 IP 대역 두 개만 예로 들었으며, 전체 LAN 직접 연결 규칙은 아닙니다.
no-resolve: 이 IP 규칙에 일치시키기 위해 도메인을 별도로 조회하지 않도록 합니다. 연결 전체에 DNS가 필요 없다는 뜻은 아닙니다.
MATCH: 마지막에 적용하는 기본 규칙입니다. 앞쪽에 두면 뒤에 있는 규칙은 일치 여부를 확인할 수 없습니다.

전역 또는 직접 연결 모드로 전환하면 일반적으로 rules 목록을 하나씩 확인해 아웃바운드를 결정하지 않습니다. 따라서 ‘규칙에 사설망 직접 연결이 설정되어 있다’고 해서 ‘전역 모드에서도 같은 규칙이 적용되어 직접 연결된다’고 볼 수는 없습니다. 로컬 프린터, 라우터 관리 페이지, 사내 네트워크 서비스를 사용할 때는 규칙 모드를 유지하는 편이 제어하기 쉽습니다.

전역 모드를 잠시 사용할 때와 규칙 모드로 돌아갈 때

특정 사이트만 열리지 않을 때: 전역 모드로 비교 테스트

클라이언트의 ‘프록시 모드’에서 현재 모드가 ‘규칙’인지 확인하세요. 일부 클라이언트에서는 트레이 메뉴의 ‘프록시 모드’에서 설정할 수 있으며, 메뉴 이름은 사용하는 프로그램에 따라 다를 수 있습니다.
‘연결’ 페이지를 연 뒤 대상 사이트에 접속하고, 도메인과 일치한 규칙, 최종 정책 경로를 기록하세요.
모드를 ‘전역’으로 바꾸고 GLOBAL에서 사용 가능한 노드를 선택하세요. 조건을 둘 이상 바꾸지 않도록 규칙 모드에서 사용하던 노드와 같은 노드를 선택하는 것이 좋습니다.
대상 사이트의 기존 연결을 닫고 다시 접속하세요. 필요한 경우 해당 도메인의 연결만 끊으면 되며, 모든 앱의 연결을 바로 끊을 필요는 없습니다.
전역 모드에서는 정상인데 규칙 모드에서 문제가 생긴다면 규칙 모드로 돌아가 도메인이 실수로 DIRECT에 일치하는지, 규칙 집합이 누락되었는지, 기본 규칙이 다른 정책 그룹을 가리키는지 확인하세요.

이 비교만으로 원인을 확정할 수는 없습니다. 같은 노드를 사용해도 모드별 DNS 설정 같은 구성 요소의 영향을 받을 수 있습니다. 모드를 바꾼 뒤 DNS 응답이 달라졌다면 규칙 문제로 단정하지 말고 DNS도 함께 점검하세요.

출구를 통일해 테스트할 때: 전역 모드를 잠시 사용할 수 있습니다

프록시 노드의 출구 위치를 확인하거나 특정 서비스에 해당 노드로 접속할 수 있는지 테스트할 때는 전역 모드가 규칙 분기의 영향을 줄여줍니다. 다만 이 시간에는 가로채기가 적용된 다른 앱도 같은 출구를 사용할 수 있습니다. 여기에는 시스템 업데이트와 클라우드 드라이브 동기화도 포함됩니다. 사용량에 따라 요금이 부과되는 구독이라면 백그라운드 다운로드에 특히 주의하세요.

일상적인 웹 탐색과 로컬 서비스: 규칙 모드로 돌아가기

테스트가 끝나면 규칙 모드로 돌아가 자주 사용하는 정책 그룹을 다시 확인하세요. 프록시가 필요한 도메인은 프록시로, 로컬에서 직접 접속할 수 있는 서비스는 DIRECT로 보내야 불필요한 우회를 줄일 수 있습니다. 전역 모드는 규칙 모드보다 ‘고급’인 것이 아니라 일반적인 규칙 선택 과정을 생략하는 모드이며, 짧은 비교 테스트에 적합합니다.

시스템 프록시, TUN, DNS: 모드 전환으로 해결되지 않는 문제

앱의 트래픽이 코어에 들어오지 않으면 전역 모드로도 가로챌 수 없습니다

데스크톱 클라이언트에서 ‘시스템 프록시’를 켜면 일부 앱은 시스템 설정을 따르지만, 다른 앱은 자체 네트워크 설정을 사용합니다. 명령줄 프로그램은 환경 변수에 따라 다르게 동작할 수도 있습니다. 로컬 혼합 포트가 7890인지 확인한 다음 아래 명령으로 프록시 진입점을 직접 지정하면 시스템 프록시 설정으로 인한 변수를 줄일 수 있습니다:

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

Windows PowerShell에서 시스템에 포함된 curl 프로그램을 명시적으로 실행하려면 명령 앞부분을 curl.exe로 작성하세요. 실행할 때 클라이언트의 연결 기록도 확인하세요. 해당 요청이 기록에 나타나면 지정한 프록시 진입점을 거친 것입니다. HTTP 응답을 받았다는 사실만으로 원격 노드를 사용했다고 볼 수는 없으므로 최종 정책 경로도 확인해야 합니다. 명령의 10초는 연결 시간 초과, 20초는 전체 요청 시간 제한이며 지연 시간 측정값이 아닙니다.

TUN은 가상 네트워크 인터페이스와 라우팅을 통해 더 많은 IP 트래픽을 가로챌 수 있지만, 적용 범위는 라우팅, 제외 항목, 권한 및 구현 방식에 따라 달라집니다. TUN을 켠다고 노드가 UDP를 지원하게 되거나 노드 자체의 연결 불가 문제가 해결되는 것은 아닙니다. 시스템 프록시를 따르지 않는 앱의 트래픽을 가로채야 한다면 클라이언트 안내에 따라 TUN 권한과 라우팅 설정을 확인하세요.

모드를 바꿔도 DNS 상태가 초기화되지는 않습니다

Fake-IP를 사용하면 코어가 도메인 매핑용 가상 주소를 앱에 반환하고, 매핑 정보를 통해 실제 도메인을 식별할 수 있습니다. 이는 연결이 실제로 공인 IP의 대상에 전송되었다는 뜻이 아닙니다. DNS 업스트림, Fake-IP 필터, 앱 자체의 암호화 DNS, 로컬 캐시가 모두 문제 확인 결과에 영향을 줄 수 있습니다.

전역 모드로 바꿨는데도 접속되지 않는다고 해서 DNS, TUN, 구독 설정을 한꺼번에 수정하지 마세요. 먼저 연결 기록이 나타나는지 확인하고, 이어 도메인과 정책 경로를 살펴본 다음 DNS 응답과 노드 연결 오류를 점검하세요. 여러 계층을 동시에 바꾸면 재현 가능한 문제가 간헐적인 문제로 바뀔 수 있습니다.

모드를 바꿔도 달라지지 않을 때: 연결 기록을 항목별로 확인

증상	우선 확인할 사항	조치
전역 모드로 바꿔도 출구가 달라지지 않음	기존 연결을 계속 사용 중이거나 GLOBAL에서 DIRECT를 선택함	GLOBAL 선택 항목을 확인하고 대상 연결을 끊은 뒤 다시 요청
브라우저는 되지만 게임은 안 됨	게임이 시스템 프록시를 따르지 않거나 필요한 UDP를 지원하지 않음	먼저 게임 연결이 코어에 들어오는지 확인한 뒤 TUN과 노드 지원 여부를 점검
규칙 모드에서는 안 되지만 전역 모드에서는 정상	일치한 규칙과 최종 정책이 서로 다름	같은 노드로 비교하고 규칙 순서, 규칙 집합, 기본 규칙을 확인
직접 연결은 되지만 전역 모드는 실패	선택한 노드를 사용할 수 없거나 대상 서비스가 해당 출구를 거부함	핸드셰이크 또는 시간 초과 오류를 확인하고 사용 가능한 다른 노드로 다시 테스트
세 가지 모드 모두 실패	진입 포트, DNS, 네트워크 또는 대상 서비스 자체의 문제	먼저 로컬 진입점과 연결 기록을 확인하고 단계별로 점검

모드 전환은 일반적으로 새로 만드는 연결에 적용되며, 기존 TCP 장기 연결이나 QUIC 세션이 즉시 다른 경로로 바뀐다고 보장하지 않습니다. 웹페이지를 새로고침해도 기존 연결을 재사용할 수 있습니다. 연결 기록에 이전 정책이 표시되면 해당 연결을 먼저 닫고 요청을 다시 보내세요. 진행 중인 다운로드, 회의, 원격 세션이 끊길 수 있으므로 작업 전에 영향을 확인하세요.

마지막으로 세 가지를 확인하세요. 연결이 코어에 들어왔는가? 최종 아웃바운드는 무엇인가? 새 연결이 예상한 모드로 처리되었는가? 이 세 가지를 확인한 뒤 규칙 수정, 트래픽 가로채기 방식 조정, 노드 변경 중 필요한 조치를 결정하세요. 일상적으로는 규칙 모드를 유지하고 문제를 확인할 때만 전역 또는 직접 연결 모드를 잠시 사용하는 편이 클라이언트를 반복해서 재설치하는 것보다 원인을 찾기 쉽습니다.