2026-11-02 입문 가이드 예상 읽기 시간 9분

Clash 규칙 모드, 전역 모드와 직접 연결 모드 비교와 사용 팁

Clash 규칙·전역·직접 연결 모드의 트래픽 처리 방식과 용도를 비교하고, 평소 규칙 모드를 권장하는 이유와 전역 모드 전환 시 주의점을 안내합니다.

먼저 규칙 모드를 선택한 뒤 트래픽이 Clash에 들어오는지 확인하세요

평소에는 규칙 모드를 권장합니다. 프록시가 필요한 요청은 프록시 그룹으로 보내고, 로컬 기기와 직접 연결이 적합한 사이트는 바로 연결합니다. 전역 모드는 트래픽 분할 문제를 잠시 점검할 때, 직접 연결 모드는 일반 네트워크 상태와 비교할 때 유용합니다. 세 모드는 이미 전달된 연결을 커널이 처리하는 방식을 바꾸는 기능이지, 인터넷 속도 설정이 아닙니다.

먼저 두 가지 설정을 구분해야 합니다. 시스템 프록시, TUN 또는 Android VPN은 트래픽이 커널에 들어오는 경로를 정하고, 규칙·전역·직접 연결 모드는 들어온 트래픽의 출구를 정합니다. 모드만 전역으로 바꾸고 시스템 프록시를 켜지 않거나 대상 프로그램이 프록시를 사용하도록 설정하지 않았다면, 해당 프로그램은 계속 네트워크에 직접 연결할 수 있습니다.

세 가지 프록시 모드의 트래픽 흐름

모드 및 설정값	연결의 출구 선택 방식	주요 용도
규칙: `rule`	규칙을 차례로 확인하고, 처음 일치하는 규칙에 지정된 정책을 사용합니다	일상적인 트래픽 분할, 로컬 네트워크 접속, 도메인별 출구 선택
전역: `global`	내장 `GLOBAL` 프록시 그룹에서 현재 선택된 항목을 사용합니다	규칙에 따른 트래픽 분할을 잠시 건너뛰고 접속 결과를 비교
직접 연결: `direct`	`DIRECT`를 통해 대상에 직접 연결합니다	로컬 네트워크 점검, 프록시 사용 전후 차이 비교

규칙 모드: 일치한 규칙에 따라 출구가 결정됩니다

규칙은 일반적으로 설정에 작성된 순서대로 위에서 아래로 확인하며, 처음 일치하는 규칙이 정책을 결정합니다. 정책은 DIRECT, REJECT, 특정 노드 또는 프록시 그룹일 수 있습니다. 규칙 모드라고 해서 ‘해외 사이트는 모두 자동으로 프록시를 사용한다’는 뜻은 아닙니다. 실제 동작은 구독에 포함된 규칙, 규칙 세트와 기본 정책에 따라 달라집니다.

예를 들어 도메인 규칙이 특정 서비스를 PROXY로 보내더라도, 해당 그룹에서 현재 DIRECT를 선택했다면 연결은 결국 직접 이루어집니다. 문제를 확인할 때는 모드 버튼만 보지 말고 ‘일치한 규칙’과 ‘프록시 그룹의 현재 선택’을 모두 확인해야 합니다.

전역 모드: GLOBAL의 출구를 따로 선택해야 합니다

전역 모드로 바꾸면 일반 규칙 목록은 해당 연결의 트래픽을 분할하지 않고, 커널은 GLOBAL에서 현재 선택된 항목을 사용합니다. 클라이언트에 따라 이 항목이 ‘전역’ 또는 ‘GLOBAL’로 표시될 수 있습니다. 여기서 직접 연결을 선택하면 전역 모드로 바꿔도 프록시를 사용하지 않습니다. 다른 프록시 그룹을 선택한 경우에는 그 그룹에서 어떤 노드를 선택했는지도 확인하세요.

전역 모드로 바꿔도 만료된 구독, 노드 인증 실패, 서버 연결 불가 문제가 해결되지는 않습니다. 규칙 모드에서 로컬 네트워크 직접 연결에 사용하던 규칙은 더 이상 적용되지 않으므로 프린터, NAS 또는 라우터 관리 페이지에 접속할 때 동작이 달라질 수 있습니다. 단, TUN 라우팅에서 제외된 트래픽은 애초에 이 단계로 들어오지 않습니다.

직접 연결 모드: 프록시 노드를 거치지 않을 뿐, 커널이 멈추는 것은 아닙니다

직접 연결 모드에서는 커널에 들어온 연결이 로컬 네트워크를 통해 대상에 직접 접속합니다. 클라이언트는 계속 포트를 수신하거나 시스템 프록시 요청을 받고, TUN과 DNS 서비스를 실행할 수 있습니다. 따라서 ‘직접 연결로 전환’하는 것과 ‘클라이언트를 종료하고 시스템 네트워크 설정을 복원’하는 것은 서로 다른 테스트입니다. TUN 라우팅이나 DNS 설정이 원인일 가능성이 있다면 직접 연결로 바꾸는 것만으로는 해당 요인을 배제할 수 없습니다.

YAML의 mode, rules와 프록시 그룹 연결 방식

최상위 설정 필드는 mode이며, 일반적인 값은 rule, global, direct입니다. 아래는 규칙 일부이며 완전한 구독 설정이 아닙니다. 사용하기 전에 기존 설정에 PROXY라는 이름의 노드 또는 프록시 그룹이 있는지 확인하세요. 실제 그룹 이름이 ‘노드 선택’이라면 두 곳의 PROXY를 모두 해당 그룹 이름과 정확히 일치하도록 바꿔야 합니다.

# 기존 설정에 병합하세요. 이 부분으로 전체 구독 설정을 덮어쓰지 마세요.
mode: rule

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,PROXY

DOMAIN-SUFFIX,example.com,PROXY: 예시 도메인과 모든 하위 도메인에 적용됩니다. 도메인별 트래픽 분할을 설명하기 위한 예시이며, 실제 서비스에 권장하는 규칙은 아닙니다.
IP-CIDR: 여기서는 흔히 쓰이는 사설 IPv4 대역 세 개를 다룹니다. 로컬 주소 예외 목록 전체가 아니므로 루프백, 링크 로컬, IPv6 주소 등은 네트워크 환경에 맞게 별도로 고려해야 합니다.
no-resolve: 이 IP 규칙을 적용하기 위해 도메인 조회를 새로 시작하지 않습니다. 클라이언트 전체의 DNS 기능을 끈다는 뜻은 아닙니다.
MATCH,PROXY: 앞선 규칙에 일치하지 않은 연결을 처리합니다. MATCH를 첫 번째 규칙으로 두면 뒤에 있는 규칙은 일치할 기회가 없습니다.

전역 모드로 전환하려면 최상위 필드를 아래 한 줄로 바꿀 수 있습니다. 실제 출구는 실행 중인 GLOBAL의 선택에 따라 결정됩니다.

mode: global

커널에 들어온 연결을 직접 연결하려면 다음을 사용하세요.

mode: direct

Clash와 Clash Meta(현재는 보통 mihomo라고 부름)는 세부 확장 필드가 완전히 같지 않으며, 특히 DNS, TUN, 프로세스 매칭 기능에 차이가 있습니다. 이 글에서 설명하는 세 가지 모드는 기본 개념입니다. 다른 고급 필드를 복사하기 전에 앱 이름만 보지 말고 클라이언트의 ‘정보’ 또는 커널 정보에서 실제 사용 중인 커널을 확인하세요.

일상적인 선택: 규칙 모드의 실질적인 장점

규칙 모드의 장점은 요청마다 적절한 출구를 선택할 수 있다는 데 있습니다. 모든 사이트가 더 빨라진다는 뜻은 아닙니다. 프록시 노드의 대역폭과 회선 품질, 대상 사이트, 로컬 네트워크가 실제 이용 경험을 좌우합니다. 규칙을 적절히 설정하면 로컬 네트워크 접속, 프록시가 필요 없는 다운로드, 특정 출구가 필요한 서비스를 한 회선에 몰아넣지 않을 수 있습니다.

웹사이트 및 업무 서비스: 도메인별로 트래픽을 나누세요. 한국에서 직접 접속할 수 있는 서비스는 보통 직접 연결하고, 프록시가 필요한 서비스에는 지정된 프록시 그룹을 사용합니다.
NAS, 프린터 및 라우터: 실제 로컬 네트워크 대역은 직접 연결로 설정하고 TUN 라우팅 제외 설정도 확인해 로컬 접속이 원격 출구로 전송되지 않도록 하세요.
계정 로그인: 같은 서비스와 관련된 도메인은 가능한 한 동일한 출구를 사용하세요. 로그인 도중 노드를 반복해서 바꾸면 추가 인증이 요구될 수 있습니다.
다운로드 및 대용량 작업: 먼저 연결 패널에서 출구를 확인하세요. 전역 모드에서는 이런 작업도 프록시 회선의 트래픽 한도를 소모할 수 있습니다.

‘더 확실하게’ 처리하려고 전역 모드를 계속 사용하지 마세요. 전역 모드는 규칙에 따른 트래픽 분할이라는 변수를 줄일 뿐, 노드 품질을 높이거나 시스템 프록시가 트래픽을 처리하는 범위를 넓히지 않습니다. 규칙 모드에서 특정 사이트 하나만 문제가 생긴다면 모든 연결의 출구를 장기간 바꾸기보다 해당 사이트의 규칙이나 프록시 그룹을 수정하는 것이 일반적입니다.

규칙 모드에서는 안 열리지만 전역 모드에서는 열린다면: 5단계 점검

이런 상황은 전역 모드를 잠시 사용해 보기 적합합니다. 테스트할 때는 같은 노드, 같은 URL, 같은 네트워크를 유지하고 모드만 바꾸세요. 여러 조건을 동시에 바꾸면 규칙과 회선 중 무엇이 원인인지 알 수 없습니다.

현재 설정을 기록합니다. 현재 모드, 일치한 규칙의 그룹, 해당 그룹에서 선택한 노드를 적어 두세요. 클라이언트의 ‘연결’ 또는 ‘Connections’ 페이지를 열고 새 연결을 확인할 준비를 합니다.
규칙 모드에서 문제를 재현합니다. 대상 사이트의 탭을 닫았다가 다시 열고 도메인, 일치한 규칙, 최종 경로를 확인하세요. 실수로 DIRECT, REJECT 또는 잘못된 기본 그룹에 일치하지 않았는지 살펴보세요.
전역 모드로 바꾸고 같은 노드를 선택합니다. ‘프록시’ 또는 ‘Proxies’ 페이지에서 GLOBAL을 찾아 비교할 출구를 선택하세요. 메뉴 위치는 클라이언트마다 다르므로 실제 인터페이스를 기준으로 확인하고, ‘시스템 프록시’ 스위치를 모드 선택으로 착각하지 마세요.
연결을 새로 만든 뒤 비교합니다. 모드를 바꿔도 이미 열린 TCP 연결은 보통 다른 출구로 이동하지 않습니다. 연결 패널에서 대상 연결을 닫거나 해당 앱을 완전히 종료한 후 다시 실행하세요. 다운로드 중인 작업을 실수로 종료하지 않도록 주의하세요.
규칙 모드로 돌아가 원인을 수정합니다. 전역 모드에서는 정상인데 규칙 모드에서 실패한다면 규칙 순서, 원격 규칙 세트 로드 여부, 그룹 이름의 일치 여부, 관련 하위 도메인 누락을 우선 확인하세요. 수정한 다음 규칙 모드로 돌아가 다시 테스트합니다.

명시적인 프록시 포트로 요청이 커널에 들어오는지 확인

현재 설정에서 실제로 mixed-port: 7890을 사용한다면 데스크톱 터미널에서 아래 명령을 실행해 HTTPS 요청이 로컬 HTTP 프록시를 통과하는지 확인할 수 있습니다. Windows PowerShell에서는 오래된 환경의 동명 명령 별칭으로 인한 인자 차이를 피하려면 curl.exe를 사용하는 것이 좋습니다.

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

Windows 명령은 다음과 같습니다.

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

실제 수신 포트가 7891이라면 명령에서도 포트를 바꿔야 합니다. 이 테스트로 확인할 수 있는 것은 해당 요청이 지정한 포트를 통과했다는 사실뿐입니다. 모든 앱의 트래픽이 처리되는지, 응답 상태 코드만으로 원격 노드를 사용했는지는 알 수 없습니다. 최종 출구는 연결 패널의 정책 경로를 함께 확인하세요. 연결이 거부되면 규칙을 바로 수정하지 말고 먼저 커널 실행 여부와 포트가 일치하는지 확인합니다.

모드를 바꿔도 문제가 계속된다면 DNS, TUN, 기존 연결을 확인하세요

전역 모드로 바꿔도 DNS 문제가 자동으로 해결되지는 않습니다

프록시 모드와 DNS 설정은 별개의 기능입니다. mihomo에서는 dns.enhanced-mode, nameserver, nameserver-policy 등의 필드도 이름 조회 방식에 영향을 줄 수 있습니다. 전역 모드로 바꿨다고 모든 DNS 요청이 프록시를 통과한다고 단정할 수 없으며, 앱 자체의 암호화 DNS까지 처리된다고 볼 수도 없습니다.

‘도메인은 열리지 않지만 네트워크는 정상인 것 같다’면 먼저 로그에서 DNS 조회 시간 초과가 발생했는지 확인한 뒤 현재 DNS 설정이 덮어써졌는지 살펴보세요. 모드, DNS 서버, 노드를 한꺼번에 바꾸지 마세요. 한 번에 하나씩 변경해야 실제 원인을 찾을 수 있습니다.

TUN은 트래픽이 들어오는 경로이지, 네 번째 프록시 모드가 아닙니다

TUN을 켠 상태에서도 규칙·전역·직접 연결 모드를 선택할 수 있습니다. 데스크톱에서는 가상 네트워크 어댑터와 라우팅이 설정되었는지, Android에서는 VPN 권한이 적용되었는지 확인하세요. 앱 제외 목록에 포함된 프로그램은 전역 모드로 표시되어도 커널을 거치지 않을 수 있습니다. 반대로 직접 연결 모드에서도 TUN은 계속 트래픽을 받아 전달할 수 있습니다.

직접 연결이 실패해도 프록시 규칙이 원인이라고 단정할 수 없습니다

규칙·전역·직접 연결 모드에서 모두 실패한다면 먼저 로컬 네트워크, 대상 서비스 상태, 포트 수신 여부와 커널 로그를 확인하세요. 클라이언트를 완전히 우회해 비교하려면 시스템 프록시와 TUN을 끄고 클라이언트를 정상 종료한 뒤 시스템에 프록시 설정이 남아 있지 않은지 확인해야 합니다. 직접 연결 모드로 바꾸는 것만으로는 커널의 DNS 및 라우팅 영향을 배제할 수 없습니다.