Clash 프록시 모드 선택 가이드: 규칙·전체·직접 연결 차이 총정리

세 모드가 바꾸는 것은 아웃바운드 결정입니다

Clash Meta, 즉 현재 널리 사용되는 mihomo 코어는 로컬 프록시 포트나 TUN 가상 네트워크 인터페이스로 들어온 연결을 먼저 받은 뒤 연결의 출구를 결정합니다. 규칙·전체·직접 연결 모드는 이 결정 방식을 바꾸며, 구독에 포함된 노드 수를 변경하거나 코어로 들어오지 않은 트래픽까지 자동으로 처리하지는 않습니다.

브라우저로 HTTPS 웹사이트에 접속하는 경우를 예로 들어 보겠습니다. 연결은 먼저 로컬 컴퓨터의 HTTP 또는 mixed 포트(설정에서 흔히 7890)로 들어올 수 있고, TUN 모드가 시스템 네트워크 스택을 인계할 수도 있습니다. 코어는 대상 도메인, 대상 IP, 포트와 네트워크 유형을 확인한 뒤 현재 모드에 따라 프록시 노드 또는 로컬 네트워크를 선택합니다. 시스템 프록시가 꺼져 있고 앱에 별도 프록시가 설정되지 않았으며 TUN도 인계하지 않은 경우, 해당 앱의 연결은 Clash를 우회합니다. 이때는 모드를 바꿔도 대개 영향을 받지 않습니다.

모드	코어에 들어온 뒤의 결정	대표적인 용도	주요 확인 항목
규칙	위에서부터 규칙을 매칭하고 해당 정책 그룹 또는 DIRECT로 전달	일상적인 웹 사용, 장시간 실행, 사이트별 분기	규칙 순서, 규칙 세트 상태, 마지막 규칙
전체	대개 GLOBAL 정책 그룹에서 현재 선택한 출구로 전달	일시적으로 규칙의 영향을 배제하고 단일 노드 연결 상태 테스트	GLOBAL에서 현재 선택한 항목, 로컬 네트워크 우회 설정
직접 연결	DIRECT를 사용해 로컬 네트워크에서 연결 수립	로컬 네트워크 기준선, 내부망 디버깅, 프록시 출구 일시 중지	DNS를 여전히 코어가 처리하는지, 연결이 다시 수립되는지

규칙 모드: 매칭 순서에 따라 출구 선택

규칙 모드는 장기간 사용하기에 적합합니다. 설정 파일의 rules 목록을 위에서부터 하나씩 확인하며, 처음으로 일치하는 규칙이 즉시 적용되고 이후 규칙은 처리되지 않습니다. 도메인 규칙, IP 규칙, 프로세스 규칙과 규칙 세트를 함께 사용할 수 있으므로 규칙 수보다 순서가 중요합니다.

mode: rule
mixed-port: 7890
external-controller: 127.0.0.1:9090

rules:
  - DOMAIN-SUFFIX,example.cn,DIRECT
  - DOMAIN,api.example.net,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,Proxy

이 예시는 먼저 지정한 중국 본토 도메인을 직접 연결하고, 이어서 한 API 도메인을 Proxy라는 정책 그룹으로 보냅니다. 두 개의 사설 주소 대역은 내부망 직접 연결에 사용되며, 마지막 MATCH가 앞에서 매칭되지 않은 연결을 처리합니다. MATCH,Proxy를 첫 줄에 배치하면 나머지 규칙은 적용될 기회를 얻지 못합니다.

규칙 모드에서 실제로 확인할 세 가지

어떤 정책에 규칙이 매칭되었는가. 클라이언트의 연결 화면에는 보통 규칙 이름이나 경로가 표시됩니다. 예: DOMAIN-SUFFIX → DIRECT, MATCH → Proxy. 노드 이름만 봐서는 규칙이 올바른지 판단할 수 없습니다.
정책 그룹에서 현재 무엇을 선택했는가. 규칙이 Proxy로 연결되어도 최종 출구는 해당 정책 그룹에 따라 달라집니다. 수동 선택 그룹이면 현재 노드를 사용하고, url-test 또는 fallback 그룹이면 그룹 내부의 테스트 결과가 결정합니다.
도메인이 이미 IP로 변환되었는가. 일부 연결에서는 대상 IP만 확인할 수 있어 도메인 규칙이 적용되지 않을 수 있습니다. DNS 가로채기, 스니핑 또는 적절한 TUN 설정을 활성화하면 코어가 더 많은 도메인 정보를 얻을 수 있지만, 실제 동작은 설정과 프로토콜에 따라 달라집니다.

규칙 모드는 내부망과 개발 환경을 처리할 때도 유용합니다. 예를 들어 localhost, 127.0.0.0/8, 192.168.0.0/16과 사내 내부망 도메인을 앞쪽에 배치하면 내부망 요청이 원격 노드로 전송되는 일을 줄일 수 있습니다. 디버깅 전에는 기업 VPN, 가상 머신 네트워크 또는 컨테이너 네트워크가 이러한 주소 대역과 겹치는지도 확인해야 합니다.

일상적인 웹 사용에서 규칙 모드를 우선하는 이유

로컬 서비스, 프린터, NAS와 라우터 관리 페이지를 직접 연결로 유지할 수 있습니다.
사이트마다 다른 정책 그룹을 사용하므로 하나의 노드에 고정되지 않습니다.
규칙 세트를 업데이트해도 앱별로 프록시 설정을 수정할 필요가 없습니다.
연결 기록에 매칭된 규칙이 남아 특정 도메인이 잘못된 출구로 연결되는 원인을 찾기 쉽습니다.

전체 모드: 일반 규칙을 건너뛰고 단일 출구 테스트

전체 모드는 흔히 “모든 기기 트래픽을 강제로 프록시한다”고 이해되지만 정확한 설명은 아닙니다. 이미 Clash 코어에 들어온 연결만 처리하며, 대개 이러한 연결을 GLOBAL 정책 그룹으로 전달합니다. 프록시 포트로 들어오지 않았거나 TUN이 인계하지 않았거나 라우팅에서 제외된 연결은 모드 이름이 바뀌어도 그대로 처리 대상에서 벗어납니다.

전체 모드의 핵심 가치는 장애 격리입니다. 규칙 모드에서 열리지 않던 웹사이트가 전체 모드로 전환하자 즉시 복구된다면 노드 자체에는 접속 능력이 있고, 문제는 규칙 매칭·정책 그룹 선택·직접 연결 네트워크에 있을 가능성이 높습니다. 전체 모드에서도 실패한다면 노드 연결 상태, DNS, TLS 시간, 네트워크 방화벽과 대상 서비스 상태를 계속 확인해야 합니다.

전체 모드를 사용하기 좋은 상황

단일 노드 확인. GLOBAL 그룹에서 하나의 노드를 고정 선택한 뒤 웹페이지 로딩, TCP 연결 수립과 UDP 요구 사항을 각각 테스트합니다. 테스트 중 자동 선택 그룹이 출구를 바꾸는 일을 피할 수 있습니다.
일시적으로 규칙 문제 배제. 같은 URL의 결과가 규칙 모드와 전체 모드에서 다르면 연결 기록으로 돌아가 매칭 경로를 확인합니다.
재현 가능한 프록시 속도 측정. 서버, 노드와 측정 시간을 고정해 규칙이 서로 다른 테스트 도메인을 다른 출구로 보내면서 생기는 편차를 줄입니다.

재현 가능한 속도 측정 기록

먼저 직접 연결 모드에서 로컬 네트워크 기준선을 측정한 뒤 전체 모드로 전환해 같은 노드를 테스트합니다. 1Gbps 유선 네트워크에서 측정한 한 기록의 직접 연결 속도는 다운로드 742 Mbps, 업로드 93 Mbps, 유휴 지연 시간 8 ms였고, 같은 프록시 노드를 고정했을 때는 다운로드 186 Mbps, 업로드 61 Mbps, 유휴 지연 시간 48 ms였습니다. 이 수치는 해당 네트워크·노드·시간대의 경로만 보여 주며 다른 기기의 속도 기준으로 삼아서는 안 됩니다.

파일 동기화, 업데이트 다운로드 또는 동영상 재생 중인 앱을 종료합니다.
직접 연결 모드에서 같은 속도 측정 서버를 세 번 테스트하고 중앙값을 기록합니다.
전체 모드로 전환한 뒤 GLOBAL 그룹에서 노드 하나를 고정합니다.
속도 측정 페이지를 닫았다가 다시 열어 새 연결을 만든 다음 세 번 측정합니다.
다운로드, 업로드, 유휴 지연 시간, 부하 지연 시간과 패킷 손실률을 함께 기록합니다.

클라이언트 노드 목록의 지연 시간 테스트는 보통 지정한 테스트 URL에 짧은 HTTP 요청을 보내 도달 가능성과 왕복 시간을 확인하는 기능입니다. 52 ms로 표시되어도 노드가 대역폭을 안정적으로 전부 사용할 수 있다는 뜻은 아니며, UDP·장시간 연결·대용량 파일 전송이 정상이라는 의미도 아닙니다.

직접 연결 모드: 인계는 유지하고 출구만 로컬 네트워크로 변경

직접 연결 모드는 코어에 들어온 연결에 DIRECT 아웃바운드를 사용합니다. 프록시 노드를 거치지 않는 네트워크 기준선을 측정하거나, 내부망 장치에 접속하고 로컬 서비스를 디버깅하거나, 장애 원인이 원격 노드에 있는지 확인할 때 적합합니다. 직접 연결은 클라이언트를 종료한다는 뜻이 아닙니다. 로컬 수신 포트, TUN 가상 네트워크 인터페이스, 연결 로그와 DNS 모듈은 계속 작동할 수 있습니다.

직접 연결 모드와 Clash 완전 종료의 차이

작업	로컬 프록시 포트	TUN 인계	Clash DNS
직접 연결 모드로 전환	대개 계속 수신 대기	대개 기존 상태 유지	계속 해석될 수 있음
시스템 프록시 끄기	포트가 계속 수신 대기할 수 있음	반드시 꺼지는 것은 아님	TUN 및 시스템 DNS 설정에 따라 달라짐
클라이언트 종료	수신 대기 중지	가상 네트워크 인터페이스와 라우팅을 해제해야 함	코어 DNS 중지

따라서 DNS 문제를 점검할 때 직접 연결 모드로 전환하는 것만으로는 “Clash를 전혀 거치지 않는” 결과를 얻지 못할 수 있습니다. dns.enable, TUN DNS 가로채기 또는 fake-ip가 활성화되어 있으면 조회가 여전히 코어에서 처리될 수 있습니다. 운영체제의 순수 네트워크 기준선을 만들려면 시스템 프록시, TUN, DNS와 라우팅 상태를 기록한 뒤 항목별로 복원해야 합니다.

내부망 디버깅 권장 순서

먼저 규칙 모드에서 대상 주소에 어떤 규칙이 매칭되었는지 확인합니다.
대상이 192.168.1.0/24 같은 실제 내부망 대역에 속하는지 확인하고, 같은 이름의 공용 도메인이 존재하는지도 점검합니다.
직접 연결 모드로 전환하고 기존 연결을 닫은 뒤 서비스를 다시 엽니다.
그래도 실패하면 로컬 라우팅 테이블, 기업 VPN, 컨테이너 네트워크와 서비스의 수신 주소를 확인합니다.
직접 연결은 되지만 규칙 모드에서 실패한다면 해당 도메인 또는 네트워크 대역에 앞쪽 DIRECT 규칙을 추가합니다.

로컬 개발에서는 수신 주소도 구분해야 합니다. 서비스가 127.0.0.1:3000에서만 수신하면 다른 기기는 LAN IP로 접속할 수 없으며, 이는 Clash 모드 때문이 아닙니다. 서비스가 0.0.0.0:3000에서 수신한다면 시스템 방화벽, 내부망 격리와 해당 네트워크 대역의 DIRECT 규칙을 확인합니다.

모드를 바꿔도 기존 연결은 자동으로 경로가 바뀌지 않습니다

Clash는 보통 연결이 수립될 때 아웃바운드를 결정합니다. 규칙 모드에서 전체 모드로 전환해도 이미 존재하는 TCP 연결이 다른 노드로 이동하지는 않습니다. WebSocket, SSH, 동영상 스트리밍, 클라우드 드라이브 동기화와 HTTP/2 장기 연결에서 특히 뚜렷합니다. 화면에 새 모드가 표시되더라도 새로 생성되는 연결부터 새 로직이 적용됩니다.

새 모드가 테스트 결과에 반영되게 하는 방법

웹페이지를 새로 고치기 전에 해당 탭을 닫고, 필요하면 브라우저를 완전히 종료한 뒤 다시 시작합니다.
클라이언트 연결 화면에서 기존 연결을 종료합니다. SSH를 테스트할 때는 세션을 새로 수립합니다.
앱의 연결 풀이 해제될 때까지 기다리거나 백그라운드에서 계속 실행되는 앱을 다시 시작합니다.
노드를 바꾼 뒤 DNS 조회를 다시 실행해 이전 해석 결과와 새 출구를 섞어 판단하지 않도록 합니다.
UDP 앱을 테스트할 때는 세션을 다시 시작합니다. 일부 앱이 매핑을 장시간 재사용하기 때문입니다.

일반적인 그래픽 클라이언트에서는 모드 메뉴가 보통 「프록시」→「모드」에 있으며 「규칙」, 「전체」 또는 「직접 연결」을 선택할 수 있습니다. 일부 클라이언트는 「설정」→「Clash 설정」→「실행 모드」에 배치하고, 트레이 메뉴에 같은 항목을 제공하기도 합니다. 메뉴 이름은 클라이언트 버전에 따라 달라지지만 코어에서 사용하는 값은 rule, global, direct로 동일합니다.

mihomo의 외부 컨트롤러(예: 127.0.0.1:9090)를 활성화한 경우 제어 패널이 제어 인터페이스를 통해 모드를 변경합니다. 요청 본문에도 소문자 영문 값을 사용합니다:

PUT /configs
Content-Type: application/json

{"mode":"rule"}

외부 컨트롤러는 신뢰할 수 있는 인터페이스에서만 수신 대기하도록 하고 접근 인증 정보를 설정해야 합니다. 변경 후 실행 중인 설정을 다시 읽고 연결 기록에서 새 요청을 생성해 실제 모드와 매칭 경로가 일치하는지 확인합니다. 설정 파일을 직접 편집했다면 다시 로드해야 합니다. 디스크의 파일만 수정해서는 실행 중인 코어에 새 값이 즉시 적용된다고 보장할 수 없습니다.

사용 상황에 맞는 모드 선택

일상적인 웹 사용과 장시간 백그라운드 실행

규칙 모드를 선택합니다. 먼저 내부망, 자주 사용하는 직접 연결 서비스와 프록시 서비스를 예상한 규칙에 각각 매칭한 뒤 정책 그룹에서 노드 전환을 처리하게 합니다. 규칙 모드는 트래픽 기록을 더 명확하게 보여 주며 모든 연결이 하나의 원격 출구에 몰리는 것도 막아 줍니다.

특정 웹사이트가 갑자기 열리지 않을 때

규칙 모드를 유지한 채 연결 기록에서 매칭된 규칙과 정책 그룹을 기록한 다음, 전체 모드로 전환해 같은 노드로 연결을 다시 수립합니다. 전체 모드에서 접속되면 규칙을 다시 확인하고, 전체 모드에서도 접속되지 않으면 노드·DNS·대상 서비스를 점검합니다. 테스트가 끝나면 규칙 모드로 복원합니다.

로컬 네트워크와 노드 성능 비교

먼저 직접 연결 모드에서 로컬 기준선을 세 번 측정한 뒤 전체 모드에서 노드를 고정해 세 번 측정합니다. 테스트 서버, 기기의 연결 방식과 시간대는 동일하게 유지해야 합니다. 규칙 모드에서 여러 속도 측정 도메인을 바로 비교하지 마세요. 서로 다른 규칙이나 정책 그룹에 매칭될 수 있습니다.

NAS, 라우터와 개발 서비스에 접속

먼저 규칙 모드의 내부망 DIRECT 규칙을 사용해 봅니다. 일시적으로 직접 연결로 전환하면 프록시 출구가 장애에 관여하는지 확인할 수 있지만, 장기적인 해결책은 내부망 도메인과 네트워크 대역 규칙을 보완하는 것입니다. TUN 라우팅과 기업 VPN이 충돌한다면 라우팅 제외 항목도 조정해야 하며, 직접 연결 모드만으로 라우팅 테이블을 고칠 수는 없습니다.

원격 프록시는 중지하되 클라이언트 상태는 관찰

직접 연결 모드를 선택하면 연결 로그와 로컬 인계 구조를 유지하면서 요청 동작을 비교할 수 있습니다. 운영체제의 순수 네트워크 상태로 되돌리는 것이 목적이라면 시스템 프록시와 TUN도 끄고 DNS, 기본 경로와 가상 네트워크 인터페이스가 복원되었는지 확인해야 합니다.

실행 가능한 모드 문제 해결 체크리스트

앱 트래픽이 시스템 프록시, 수동 프록시 또는 TUN을 통해 Clash로 들어오는지 확인합니다.
현재 실행 모드를 기록하고 모드와 정책 그룹 이름을 혼동하지 않습니다.
연결 화면에서 대상 도메인, 대상 IP, 매칭된 규칙과 실제 경로를 확인합니다.
규칙 모드에 문제가 있으면 같은 노드를 고정한 전체 모드로 대조 테스트를 진행합니다.
로컬 기준선이 필요하면 직접 연결로 전환하되 DNS가 여전히 코어에서 처리될 수 있다는 점에 유의합니다.
전환할 때마다 기존 연결을 닫고 페이지를 다시 열거나 테스트 앱을 재시작합니다.
문제 원인을 파악한 뒤 규칙 모드로 돌아가 규칙 순서, 규칙 세트 또는 정책 그룹 선택을 수정합니다.

세 모드의 속도에는 일관된 우열이 없습니다. 규칙 모드는 매칭된 규칙과 정책 그룹, 전체 모드는 GLOBAL에서 선택한 노드, 직접 연결 모드는 로컬 통신사 경로에 따라 결과가 달라집니다. 모드를 선택할 때는 먼저 테스트 대상을 명확히 해야 합니다. 규칙 결정인지, 원격 노드인지, 로컬 네트워크인지 구분하세요. 세 요소를 나누어 기록해야 연결 로그에서 재현 가능한 결론을 얻을 수 있습니다.