입문 가이드 읽는 시간 약 9분

Clash 규칙·전역·직접 연결 모드 비교: 차이와 선택 방법

Clash 규칙·전역·직접 연결 모드의 작동 방식과 적합한 상황을 비교하고, 모드 전환 후 연결 문제가 생겼을 때 확인할 항목을 정리했습니다.

세 모드의 차이: 연결 경로를 정할 뿐, 트래픽을 가져오는 범위는 정하지 않습니다

일상적으로 로컬 서비스와 프록시가 필요한 사이트를 함께 이용한다면 보통 규칙 모드를 사용합니다. 노드를 잠시 테스트하거나 규칙 매칭 여부를 확인하려면 전역 모드를, 로컬 네트워크의 직접 연결 상태를 비교하려면 직접 연결 모드를 사용하세요. 세 모드는 “Clash로 들어온 연결을 어떻게 처리할지”를 정하는 설정이지, “어떤 앱의 트래픽을 Clash가 가져올지”를 정하는 설정은 아닙니다.

Clash 계열 클라이언트에는 Rule, Global, Direct 또는 이에 해당하는 한국어가 표시될 수 있습니다. Clash Meta의 후속 프로젝트는 mihomo라는 이름을 사용하며, 일반적인 클라이언트에서는 이 세 가지 모드를 그대로 제공하는 경우가 많습니다. 세부 규칙 기능은 코어에 따라 달라질 수 있지만, ‘트래픽을 가져오는 범위’와 ‘연결 경로 선택’은 구분해서 이해해야 합니다.

모드 가져온 연결의 처리 방식 주요 사용 상황 혼동하기 쉬운 점
규칙 Rule 규칙을 위에서부터 순서대로 확인한 뒤 직접 연결, 차단 또는 정책 그룹으로 처리합니다. 로컬 서비스와 프록시 연결을 구분해 일상적으로 사용 노드를 선택해도 모든 사이트가 해당 노드를 경유하는 것은 아닙니다.
전역 Global 일반적인 분기 규칙 대신 GLOBAL 정책을 통해 연결 경로를 선택합니다. 노드 임시 테스트, 규칙 오매칭 여부 확인 GLOBAL에서 DIRECT를 선택할 수도 있으며, 모든 앱의 트래픽을 가져온다는 뜻은 아닙니다.
직접 연결 Direct 코어가 가져온 연결을 대상 서버에 직접 연결합니다. 로컬 네트워크와 비교하거나 프록시 노드를 잠시 사용하지 않을 때 코어, 수신 포트, DNS 기능은 계속 작동할 수 있습니다.

규칙 모드: 규칙을 순서대로 확인한 뒤 정책 그룹으로 전달

규칙 모드는 설정에 등록된 규칙을 위에서부터 확인해 연결을 처리합니다. 일반 규칙에 매칭되면 지정된 대상으로 연결을 보냅니다. 대상은 DIRECT, REJECT 또는 실제로 존재하는 정책 그룹일 수 있습니다. 정책 그룹은 다시 사용할 노드나 하위 정책을 결정합니다. 따라서 연결 경로를 확인할 때는 두 가지를 살펴봐야 합니다. 어떤 규칙에 매칭됐는지, 해당 규칙이 가리키는 그룹에서 최종적으로 무엇을 선택했는지입니다.

규칙은 개수보다 순서가 중요합니다

아래는 규칙 구간 예시이며, 그대로 가져다 쓸 수 있는 전체 구독 설정이 아닙니다. ‘노드 선택’은 현재 설정에 정의된 정책 그룹 이름으로 바꿔야 합니다. 예시 이름을 그대로 두고 해당 그룹을 정의하지 않으면 설정을 불러오지 못할 수 있습니다.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,노드 선택
  • DOMAIN-SUFFIX,example.com은 해당 도메인과 하위 도메인에 매칭됩니다. 문자열에 같은 부분이 포함된 모든 도메인에 매칭되는 것은 아닙니다.
  • 192.168.0.0/16과 10.0.0.0/8은 흔히 쓰이는 사설 IP 주소 대역입니다. 이 예시에 모든 로컬 주소 대역이 포함된 것은 아닙니다.
  • no-resolve는 이 IP 규칙만을 위해 도메인을 새로 조회하지 않도록 합니다. 대상이 이미 IP 주소라면 규칙 매칭은 계속 가능합니다.
  • MATCH는 최종 규칙입니다. 앞쪽에 두면 뒤에 있는 규칙은 매칭될 기회를 얻지 못합니다.

일상적으로 쓰기 좋지만 트래픽 분기 기준을 관리해야 합니다

예를 들어 로컬 네트워크 저장 장치는 직접 연결하고, 특정 해외 사이트는 프록시 그룹으로 보내며, 나머지 트래픽은 기본 그룹으로 전달할 수 있습니다. 규칙 모드에서는 이런 요구를 함께 설정할 수 있습니다. 다만 로그인, 이미지, 동영상이 서로 다른 도메인을 사용할 수 있습니다. 메인 페이지에 규칙이 올바르게 적용됐다고 해서 모든 하위 요청도 같은 경로로 연결되는 것은 아닙니다.

‘페이지는 열리는데 이미지가 보이지 않는’ 경우 실패한 요청의 도메인과 매칭된 규칙부터 확인하세요. 모든 트래픽을 프록시로 돌려 장기간 사용하는 방식으로 해결하거나, 브라우저 주소창의 메인 도메인만 보고 규칙을 추가하지 마세요. 규칙의 출처, 구독 업데이트, 코어 지원 범위도 함께 확인해야 합니다.

전역 모드: 노드 테스트에 적합하지만 모든 기기를 프록시로 연결하지는 않습니다

전역 모드는 가져온 일반 연결을 GLOBAL 정책으로 처리합니다. 모드를 바꾼 뒤에는 클라이언트의 프록시 또는 정책 그룹 화면에서 GLOBAL이 현재 어떤 대상을 선택했는지 확인하세요. 일부 인터페이스에서는 그룹이 숨겨져 있거나 전역 선택기가 따로 표시됩니다. 실제 연결 정보에 표시되는 연결 경로를 기준으로 확인하세요.

전역 모드라고 해서 반드시 원격 노드를 거치는 것은 아닙니다. GLOBAL이 DIRECT를 선택하면 연결은 직접 이루어집니다. GLOBAL이 다른 정책 그룹을 가리키는 경우에는 해당 그룹에서 최종적으로 선택된 대상까지 확인해야 합니다. 규칙 모드에서 자주 쓰는 ‘노드 선택’ 그룹이 GLOBAL과 자동으로 동기화되는 것도 아닙니다.

전역 모드로 노드 문제와 규칙 문제 구분하기

  1. 규칙 모드에서 실패한 요청의 도메인, 매칭 규칙, 출구 노드를 기록합니다.
  2. 전역 모드로 전환한 뒤 GLOBAL에서 테스트할 노드를 직접 선택합니다.
  3. 기존 연결을 종료하고 요청을 다시 보냅니다. 기존 연결을 재사용 중인 페이지를 그대로 확인하는 데 그치지 마세요.
  4. 전역 모드는 되지만 규칙 모드는 안 된다면 분기 규칙, 대상 정책 그룹, DNS 차이를 먼저 확인하세요. 두 모드 모두 실패한다면 노드와 로컬 트래픽 연결 경로를 확인합니다.

이 비교는 원인을 좁히기 위한 것이며 최종 결론은 아닙니다. 원격 서비스의 요청 제한, DNS 캐시, 연결 재사용, 테스트 시점 차이가 결과에 영향을 줄 수 있습니다. 가능한 한 같은 네트워크, 같은 대상, 같은 노드를 유지하고 모드만 바꿔 테스트하세요.

직접 연결 모드: 네트워크 비교에 적합하지만 클라이언트를 종료하는 것은 아닙니다

직접 연결 모드에서는 코어로 들어온 일반 연결이 보통 프록시 노드를 선택하지 않고 대상에 직접 연결됩니다. 이 모드는 “이번 실패가 프록시 노드와 관련이 있는가?”라는 질문에 답할 때 유용합니다. 예를 들어 같은 리소스가 직접 연결에서는 열리고 지정한 프록시 노드에서는 실패한다면, 해당 노드의 연결 상태나 대상 사이트의 출구 제한을 확인할 수 있습니다.

하지만 직접 연결 모드로 바꿔도 시스템 프록시가 로컬 수신 포트를 가리키거나 TUN 가상 네트워크 인터페이스가 계속 작동할 수 있습니다. 클라이언트의 DNS 수신, 캐시, 관련 조회 경로도 중단되지 않을 수 있습니다. 따라서 직접 연결 모드는 프록시 노드를 사용하지 않는 비교 테스트일 뿐, 클라이언트를 종료한 상태의 원래 네트워크와 완전히 같지는 않습니다.

  • 노드만 잠시 사용하지 않으려면: 직접 연결 모드를 선택하고 연결 정보의 출구가 DIRECT인지 확인하세요.
  • 클라이언트를 완전히 거치지 않는지 테스트하려면: 먼저 시스템 프록시와 TUN을 끄고 필요하면 클라이언트도 종료한 다음, 시스템에 수동 프록시 설정이 남아 있지 않은지 확인하세요.
  • 종료 후 모든 웹페이지가 열리지 않는다면: 시스템이 127.0.0.1 프록시 포트를 가리키고 있지만 해당 포트의 수신은 이미 중단된 상태인지 확인하세요.

직접 연결을 사용해도 모든 대상에 접속할 수 있는 것은 아닙니다. 대상 서비스에 연결할 수 있는지는 로컬 네트워크, 라우팅, DNS, 서버 정책에 따라 달라집니다. 특정 사이트의 직접 연결 실패만으로 클라이언트 설정에 문제가 있다고 단정할 수 없습니다.

시스템 프록시와 TUN: 어떤 연결을 코어로 가져올지 결정합니다

시스템 프록시는 운영체제의 프록시 설정을 통해 해당 설정을 따르는 앱의 요청을 로컬 HTTP 또는 SOCKS 주소로 전달합니다. 브라우저는 대체로 시스템 프록시를 지원하지만 명령줄 도구, 게임, 일부 독립 실행형 앱은 자체 네트워크 설정을 사용할 수 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅으로 대상 트래픽을 가져옵니다. 적용 범위는 라우팅, 제외 항목, 권한, 코어 설정에 따라 달라집니다.

수신 포트를 먼저 확인한 뒤 트래픽 연결 경로 테스트

아래 명령은 클라이언트의 HTTP 또는 혼합 수신 포트가 7890이라고 가정합니다. 설명을 위한 예시일 뿐 모든 클라이언트의 기본 포트는 아니므로, 실행 전에 클라이언트의 포트 설정을 확인하세요. Windows에서는 curl.exe를, macOS와 Linux에서는 보통 curl을 사용합니다.

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

첫 번째 명령은 로컬 프록시 주소를 명시적으로 사용하고, 두 번째 명령은 curl의 애플리케이션 프록시 사용을 비활성화합니다. TUN이 켜져 있다면 두 번째 요청도 가상 네트워크 인터페이스를 통해 처리될 수 있으므로 클라이언트를 완전히 우회하는 테스트는 아닙니다. 연결 패널에서 두 요청이 코어에 들어왔는지, 최종 출구가 무엇인지 함께 확인하세요.

명령에서 HTTP 응답이 반환됐다는 것은 해당 요청이 응답을 받았다는 뜻일 뿐, 동영상이나 게임 UDP, 시스템 전체가 정상적으로 프록시를 사용한다는 뜻은 아닙니다. HTTP 프록시 테스트와 UDP 트래픽 처리는 별개이며, UDP는 연결 방식, 노드 프로토콜, 서버 지원 여부에도 영향을 받습니다.

모드 전환 후 연결 문제: 다섯 단계로 확인하기

1. 현재 설정과 최종 연결 경로 확인

먼저 어떤 구독 또는 로컬 설정이 활성화됐는지 확인한 다음 모드와 정책 그룹을 살펴보세요. 구독을 업데이트하면 규칙과 그룹 이름이 바뀔 수 있습니다. 화면에서 이전에 선택했던 노드가 현재 연결에 사용되는 노드와 다를 수도 있습니다. 규칙 모드에서는 매칭 규칙, 전역 모드에서는 GLOBAL, 직접 연결 모드에서는 DIRECT를 확인하세요.

2. 기존 연결을 종료한 뒤 다시 테스트

모드를 바꾸면 보통 새 연결부터 설정이 적용되며, 기존 TCP 연결이나 일부 UDP 세션은 이전 경로를 계속 사용할 수 있습니다. 브라우저의 HTTP/2·HTTP/3 연결 재사용으로 이런 현상이 더 두드러질 수 있습니다. 클라이언트 연결 패널에서 대상 연결을 종료한 뒤 페이지를 다시 여세요. 모든 연결을 종료하면 다운로드나 화상 회의도 중단되므로 작업을 먼저 저장하세요.

3. DNS와 실제 연결 경로를 따로 확인

DNS 조회에 실패했다면 전역 모드로 바꾸는 것만으로 해결되지 않을 수 있습니다. 로그에서 DNS 시간 초과, 대상 주소 조회 오류, fake-ip 관련 문제를 확인하세요. mihomo의 경우 DNS 업스트림, 조회 정책, 규칙 준수 여부는 실제 설정에 따라 달라집니다. ‘전역 모드에서는 모든 DNS가 노드를 거친다’고 단정할 수 없습니다. 변경 전에 설정을 백업하고 DNS, 노드, 모드를 한꺼번에 바꾸지 마세요.

4. 시스템 프록시, TUN, 다른 네트워크 도구 확인

프록시를 명시한 테스트는 정상인데 브라우저 연결이 기록되지 않는다면 브라우저가 별도 프록시 설정을 사용하는지 먼저 확인하세요. TUN을 켠 뒤 문제가 생겼다면 실행 권한, 라우팅 제외 설정, 다른 VPN과의 충돌을 확인합니다. 원인을 파악할 때는 트래픽을 가져오는 경로를 한 번에 하나만 사용해 시스템 프록시와 여러 가상 네트워크 인터페이스가 서로 영향을 주지 않도록 하세요.

5. 지연 시간만 보지 말고 같은 조건으로 기록

노드 지연 시간 테스트는 보통 특정 주소에 한 번 연결해 보는 것으로, 대상 사이트의 실제 전송 속도를 보여 주지는 않습니다. 같은 네트워크에서 세 번 테스트한 모드, 노드, 대상 도메인, 결과, 오류 정보를 기록해 보세요. 예를 들어 “규칙 모드에서 DIRECT에 매칭되어 연결 시간 초과, 전역 모드에서 노드 A를 선택해 HTTP 200 반환”이라고 남기면 “노드 지연 시간 80ms”만 기록하는 것보다 원인을 파악하기 쉽습니다. 숫자는 기록 형식 예시이며 이 사이트에서 측정한 결과가 아닙니다.

일상적인 모드 선택: 규칙 모드를 기본으로, 전역과 직접 연결은 비교용으로

  • 업무, 웹 탐색, 로컬 네트워크 기기를 함께 사용하는 경우: 규칙 모드를 우선 사용하고 사설 주소와 자주 쓰는 서비스에 실제로 어떤 규칙이 적용되는지 확인하세요.
  • 트래픽 분기 오류가 의심되는 경우: 잠시 전역 모드로 바꾸고 테스트할 노드를 직접 선택한 뒤 기존 연결을 종료하고 같은 대상을 비교하세요.
  • 노드나 원격 경로에 문제가 있는 것으로 의심되는 경우: 직접 연결을 비교 테스트에 사용하세요. 원래 네트워크 상태를 확인하려면 시스템 프록시와 TUN도 끄세요.
  • 특정 앱 하나에서만 문제가 생기는 경우: 해당 앱의 트래픽이 코어로 들어오는지 먼저 확인하세요. 트래픽을 가져오는 방식을 점검하는 대신 세 모드를 반복해서 바꾸지 마세요.

신뢰할 수 있는 점검 순서는 트래픽이 코어로 들어오는지, 선택한 모드가 이를 어떻게 처리하는지, 최종 연결 경로가 예상과 맞는지 확인하는 것입니다. 세 가지를 확인한 뒤 규칙이나 노드를 조정하세요. 설치와 설정 가져오기 방법은 Clash 사용 가이드를, 규칙 항목은 프로토콜 참고서를 확인하세요.

Clash 다운로드