기초 읽는 시간 약 9분

Clash 규칙·전역·직접 연결 모드 비교: 어떤 모드를 선택할까?

Clash의 rule·global·direct 모드를 실제 상황에 맞춰 비교합니다. 트래픽 처리 방식과 적합한 용도, 모드 전환 후 적용 여부를 확인하는 방법을 알아보세요.

세 가지 모드는 트래픽의 출구를 정할 뿐, 트래픽이 코어로 들어오는지 여부를 결정하지 않습니다

Clash의 프록시 모드는 트래픽이 코어에 들어온 뒤 처리하는 방식을 뜻합니다. rule은 규칙에 따라 정책을 선택하고, global은 내장된 전역 정책 GLOBAL을 사용하며, direct는 직접 연결로 나갑니다. Clash Meta에서 mihomo로 이어진 뒤에도 이 세 가지 기본 모드의 설정값은 동일합니다.

두 가지를 구분해야 합니다. 시스템 프록시, 앱 프록시, TUN은 연결을 코어로 보내고, 프록시 모드는 코어가 받은 연결을 어디로 보낼지 정합니다. 따라서 ‘전역 모드’로 바꿨다고 해서 컴퓨터의 모든 프로그램이 자동으로 프록시를 거치는 것은 아닙니다. 시스템 프록시를 무시하고 TUN에도 포함되지 않은 프로그램은 전역 모드로 전환해도 노드를 통해 연결되지 않습니다.

설정값일반적인 UI 표시명새 연결의 출구 선택 방식주요 용도
rule규칙, Rule규칙을 순서대로 확인하고 일치하는 항목의 정책 적용일상적인 트래픽 분리, LAN 직접 연결 유지
global전역, GlobalGLOBAL에서 현재 선택한 출구 사용일시적으로 출구 통일, 규칙 동작 비교
direct직접 연결, Direct프록시 노드를 거치지 않고 대상에 직접 연결로컬 네트워크 테스트, 일시적으로 프록시 전달 중단

규칙 모드: 순서대로 확인하고 처음 일치한 규칙 적용

mode: rule은 설정에 따라 트래픽을 분리하는 모드입니다. 흔히 도메인 접미사, 대상 IP 대역, 마지막 기본 정책을 규칙으로 사용합니다. 규칙은 보통 위에서 아래로 확인하며, 먼저 일치한 규칙이 해당 연결의 정책을 정합니다. 뒤에 있는 규칙은 출구를 다시 선택하지 않습니다.

간단하고 읽기 쉬운 트래픽 분리 예시

다음은 설정 예시입니다. 내장 정책 DIRECT만 사용하므로 문법을 독립적으로 이해하기 좋으며, 프록시 노드가 새로 만들어지지는 않습니다.

mode: rule
log-level: info

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,DIRECT

실제 구독 설정에 Proxy라는 프록시 그룹이 이미 있다면 마지막 줄을 MATCH,Proxy로 바꿀 수 있습니다. 이름은 대소문자까지 설정에 있는 프록시 그룹과 정확히 일치해야 합니다. 규칙만 추가하고 해당 그룹을 빠뜨리면 설정을 불러올 때 정책이 없다는 오류가 발생할 수 있습니다.

프록시 그룹에 일치해도 프록시 노드가 선택된 것은 아닙니다

규칙이 가리키는 대상은 정책입니다. 정책은 노드, 선택 그룹, 자동 지연 테스트 그룹 또는 DIRECT일 수 있습니다. 예를 들어 규칙이 Proxy에 일치하더라도 해당 선택 그룹에서 DIRECT를 선택했다면 연결은 실제로 직접 연결됩니다. 문제를 확인할 때는 ‘어떤 규칙에 일치했는지’와 ‘정책 그룹에서 최종적으로 무엇을 선택했는지’를 함께 살펴보세요. 규칙 이름만 확인해서는 충분하지 않습니다.

전역 모드: GLOBAL을 사용하지만 트래픽 가로채기 범위는 그대로 적용됩니다

mode: global은 코어에 들어온 일반 연결을 일반적인 rules 목록으로 분리하지 않고 내장된 GLOBAL 선택 정책으로 보냅니다. 모드를 바꾼 뒤 클라이언트의 프록시 선택 화면에서 GLOBAL을 찾아 원하는 노드나 정책이 선택되어 있는지 확인해야 합니다.

클라이언트에 따라 이 항목은 ‘전역’ 또는 ‘전역 선택’으로 표시될 수 있습니다. 메뉴 이름은 클라이언트마다 다르므로 현재 모드가 global이고 전역 정책에서 실제로 원하는 항목을 선택했는지 확인하세요. GLOBAL이 여전히 DIRECT를 가리킨다면 전역 모드로 바꿔도 프록시 출구가 생기지 않습니다.

짧은 시간 동안 비교 테스트할 때 유용합니다

  1. 규칙 모드에서 특정 사이트 연결에 문제가 생기면 먼저 어떤 규칙과 정책이 적용됐는지 기록합니다.
  2. 전역 모드로 전환하고 정상 작동이 확인된 노드를 선택합니다.
  3. 대상 사이트의 기존 연결을 끊고 새 요청을 보냅니다.
  4. 새 연결이 정상 작동한다면 규칙 순서, 도메인 적용 범위, 기존 정책 그룹의 선택 상태를 다시 확인합니다.

이 결과로 알 수 있는 것은 두 테스트에서 서로 다른 처리 경로를 사용했다는 점뿐이며, ‘규칙 파일이 손상됐다’고 단정할 수는 없습니다. 두 테스트에서 서로 다른 노드를 사용했거나 DNS 결과가 바뀌었거나 기존 연결이 유지된 경우에도 결과가 달라질 수 있습니다. 비교할 때는 노드, 대상 주소, 트래픽을 가로채는 방식을 동일하게 유지하고 모드만 바꾸세요.

직접 연결 모드: 노드는 사용하지 않지만 클라이언트가 꺼지는 것은 아닙니다

mode: direct는 코어에 들어온 연결을 프록시 노드 없이 대상에 직접 연결한다는 뜻입니다. 시스템 프록시 설정, TUN 가상 네트워크 어댑터, 코어의 DNS 서비스는 계속 활성화되어 있을 수 있습니다. 따라서 ‘직접 연결 모드’와 ‘클라이언트 종료 및 트래픽 가로채기 해제’는 같은 테스트 조건이 아닙니다.

예를 들어 브라우저가 요청을 로컬 주소 127.0.0.1:7890로 계속 보내고 코어가 요청을 받은 뒤 대상에 직접 연결한다면, 여전히 로컬 프록시를 거친 것입니다. 여기서 7890은 흔히 사용되는 설정 예시일 뿐입니다. 실제 포트는 현재 실행 설정의 mixed-port 또는 port 값을 확인하세요.

직접 연결 모드로 비교해 볼 수 있는 문제

직접 연결한다고 모든 웹사이트에 접속할 수 있는 것은 아니며 DNS가 자동으로 인터넷 서비스 제공업체의 서버로 바뀌는 것도 아닙니다. 현재 설정에 따라 암호화 DNS, 지정된 리졸버, 다른 DNS 규칙이 계속 사용될 수 있습니다. DNS 문제를 확인하려면 모드 전환을 DNS 초기화 버튼처럼 여기지 말고 dns 설정을 별도로 살펴보세요.

모드 전환 적용 여부 확인: 설정, 연결, 출구를 따로 확인

YAML에서 mode를 수정했다고 해서 실행 중인 코어에 새 값이 적용되는 것은 아닙니다. 일부 클라이언트는 UI 상태나 오버라이드 설정으로 구독 필드를 덮어쓸 수 있고, 구독을 업데이트하면 직접 수정한 내용이 바뀔 수도 있습니다. 클라이언트에 표시된 현재 실행 모드와 새 연결 기록을 기준으로 확인하세요.

웹페이지가 열리는지만 보지 말고 정해진 순서로 확인하세요

  1. 기존 상태를 기록합니다. 모드, 현재 노드, 시스템 프록시 또는 TUN의 활성화 상태를 적어 두고 복구할 수 있는 설정을 보관합니다.
  2. 변수 하나만 바꿉니다. 모드만 전환하고 DNS, 노드, 규칙은 동시에 수정하지 마세요. 전역 모드에서 출구를 선택해야 한다면 선택한 항목도 기록합니다.
  3. 새 연결을 만듭니다. 테스트 프로그램의 기존 연결을 끊고 필요한 경우 클라이언트 연결 화면에서 관련 연결을 종료합니다. 기존 TCP 연결은 새 출구로 자동 전환되지 않는 경우가 많습니다.
  4. 연결 상세 정보를 확인합니다. ‘연결’ 또는 ‘Connections’ 화면에서 대상 도메인, 대상 IP, 일치한 규칙과 정책 체인을 찾습니다. 표시되는 항목은 클라이언트마다 다를 수 있습니다.
  5. 출구를 확인합니다. 신뢰할 수 있는 공인 IP 조회 서비스로 결과를 확인한 뒤 직접 연결 기준값과 비교합니다. 두 경로가 같은 공인 출구를 공유할 수 있으므로 IP가 같다고 설정이 적용되지 않았다고 단정할 수는 없습니다.

curl로 테스트 경로 고정하기

현재 설정에서 mixed-port: 7890을 사용한다고 가정합니다. 로컬 프록시를 명시하면 브라우저 확장 프로그램이나 시스템 프록시 설정으로 인한 간섭을 줄일 수 있습니다.

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

첫 번째 명령은 지정한 로컬 HTTP 프록시를 거친 뒤 현재 모드에 따라 출구가 결정됩니다. ‘원격 노드를 강제로 사용’하는 명령은 아닙니다. 두 번째 명령은 curl에 프록시를 명시하지 않지만 TUN이 트래픽을 계속 가로채고 있으면 요청이 코어로 들어갈 수 있으므로 클라이언트를 우회하는 기준 테스트로 볼 수 없습니다. Windows PowerShell에서 curl 별칭 때문에 차이가 생기면 curl.exe를 사용하세요.

예시의 연결 시간 제한 10초와 전체 시간 제한 20초는 테스트를 위한 상한이며 속도 기준이 아닙니다. 명령에서 HTTP 상태 코드가 반환되면 응답을 받았다는 뜻이지만 예상한 출구를 사용했다는 증거는 아닙니다. 코어의 연결 기록도 함께 확인하세요. 대상 사이트가 HEAD 요청을 지원하지 않는다면 일반 GET 요청으로 다시 확인합니다.

사용 상황별 선택: 일상적인 트래픽 분리, 임시 문제 확인, 직접 연결 기준 테스트

사용 상황우선 선택함께 확인할 항목
일상적으로 내부망과 외부 서비스를 함께 이용규칙 모드로컬 네트워크 대역, 도메인 규칙, 기본 정책이 적절한지
특정 도메인이 잘못 분리되는 것으로 의심될 때전역 모드로 잠시 전환해 비교GLOBAL에서 선택한 항목, 기존 연결 종료 여부
일시적으로 프록시 노드를 사용하지 않을 때직접 연결 모드DNS와 트래픽 가로채기는 계속 작동할 수 있음
특정 프로그램이 연결 화면에 전혀 표시되지 않을 때먼저 트래픽 가로채기 방식 확인앱 프록시 설정, 시스템 프록시 지원 여부, TUN 라우팅
클라이언트를 거치지 않는 로컬 네트워크 테스트가 필요할 때트래픽 가로채기를 끄고 테스트시스템 프록시, TUN, 앱의 수동 프록시 설정이 모두 원래 상태로 복구됐는지

일상적인 사용은 보통 규칙 모드에서 시작하면 됩니다. 어떤 연결은 직접 연결하고 어떤 연결은 프록시 그룹으로 보낼지 명확히 설정하세요. 전역 모드는 잠시 출구를 통일하거나 규칙 동작을 비교할 때, 직접 연결 모드는 일시적으로 노드를 사용하지 않거나 일부 테스트의 기준을 만들 때 적합합니다. 세 모드에 고정된 속도 순위는 없으며 실제 결과는 출구, 노드 품질, 대상 서비스, 로컬 네트워크에 따라 달라집니다.

자주 하는 오해: 모드 전환으로 해결되지 않는 문제

전역 모드에서는 인터넷이 되지만 규칙 모드에서는 안 됩니다. 전역 모드를 계속 켜 둬야 하나요?

바로 그렇게 결론 내릴 필요는 없습니다. 먼저 규칙 모드에서 실패한 연결에 어떤 규칙이 적용됐는지 확인한 다음, 해당 그룹에서 사용 가능한 노드를 선택했는지 살펴보세요. 하나의 서비스에서 여러 관련 도메인을 사용할 수도 있으므로 기본 도메인만 처리하면 로그인, 정적 리소스, API 요청이 계속 실패할 수 있습니다. 연결 기록을 바탕으로 규칙을 보완하면 모든 트래픽 분리를 우회해 인트라넷 접속을 포기하는 것보다 낫습니다.

직접 연결 모드로 바꿨는데 로그가 계속 쌓이는 이유는 무엇인가요?

직접 연결 모드에서도 코어는 계속 작동합니다. 시스템 프록시나 TUN이 트래픽을 코어로 보내고 있다면 연결 기록은 계속 표시됩니다. 원격 노드를 사용했는지는 클라이언트의 트래픽 카운터가 움직이는지로 판단하지 말고 최종 정책과 출구를 확인하세요.

전역 모드에서는 모든 UDP를 프록시로 보낼 수 있나요?

아닙니다. UDP가 코어에 들어올 수 있는지는 트래픽을 가로채는 방식에 달려 있고, 전달 가능 여부는 인바운드, 선택한 노드의 프로토콜, 해당 노드의 설정에 따라 달라집니다. 브라우저용 HTTP 시스템 프록시만 설정해도 게임이나 음성 채팅 프로그램의 UDP 트래픽까지 가로채진다고 보장할 수 없습니다. 모드를 global로 바꿔도 빠진 경로가 추가되지는 않습니다.

자세한 설정은 사용 가이드에서 확인하세요. mode, rules, 포트, DNS 항목을 확인하려면 설정 참고 문서를 살펴보세요. 확인 순서는 동일합니다. 먼저 트래픽이 코어에 들어오는지 확인하고, 다음으로 정책 선택을 확인한 뒤, 마지막으로 실제 출구를 살펴봅니다.

Clash 다운로드