Clash 규칙·전역·직접 연결 모드 차이와 초보자 선택법
Clash의 규칙·전역·직접 연결 모드별 처리 방식과 사용 시점을 정리해 초보자가 모드를 잘못 선택하지 않도록 안내합니다.
Mode Basics
세 모드가 결정하는 것은 출구 경로입니다
Clash Verge Rev는 mihomo 코어로 연결을 처리하며, 규칙·전역·직접 연결 모드는 코어에 이미 들어온 트래픽이 어떤 출구로 나갈지를 결정합니다. 세 모드는 특정 앱이 트래픽을 Clash에 전달할지 여부를 직접 결정하지 않으며, 시스템 프록시나 TUN 스위치와도 동일하지 않습니다. 이 차이를 이해하는 것이 모드를 잘못 선택하지 않는 핵심입니다.
규칙 모드에서는 코어가 설정 파일의 규칙을 위에서부터 확인하고, 도메인·IP·포트·프로세스·규칙 집합 등의 조건에 따라 연결을 지정된 정책 그룹, 프록시 노드, DIRECT 또는 REJECT로 보냅니다. 전역 모드에서는 코어에 들어온 일반 연결을 보통 전역 정책 그룹으로 일괄 전달한 뒤, 사용자가 해당 그룹의 노드나 정책을 선택합니다. 직접 연결 모드에서는 이러한 연결이 DIRECT 출구를 사용하므로 프록시 노드를 거치지 않습니다.
| 모드 | 결정 방식 | 대표적인 용도 | 주요 유의점 |
|---|---|---|---|
| 규칙 | 규칙 순서에 따라 연결별 출구를 선택 | 일상 사용, 지역별 분할, 서비스별 노드 선택 | 규칙의 품질·순서와 정책 그룹 선택에 따라 결과가 달라짐 |
| 전역 | 일반 트래픽을 전역 정책으로 일괄 전달 | 노드 임시 테스트, 규칙 영향 빠른 배제 | 로컬 또는 중국 본토 서비스도 선택한 프록시를 거칠 수 있음 |
| 직접 연결 | 트래픽이 대상 주소에 직접 연결 | 프록시 일시 중지, 로컬 네트워크 및 대상 연결 가능 여부 테스트 | 네트워크 조건의 제약을 받는 대상은 직접 연결해도 접속이 복구되지 않음 |
Rule Mode
규칙 모드: 연결 특성에 따른 세밀한 트래픽 분할
규칙 모드는 일반적으로 일상 사용에 가장 적합한 선택입니다. 동시에 여러 출구를 사용할 수 있어 LAN 주소는 직접 연결하고, 특정 서비스는 전용 정책 그룹으로 보내며, 광고나 추적 도메인은 차단하고, 나머지 연결은 최종 정책으로 처리할 수 있습니다. 모든 연결을 하나의 노드로 보내는 방식보다 규칙 기반 분할이 접속 경로, 지연 시간, 로컬 네트워크 자원을 더 쉽게 균형 있게 관리합니다.
mihomo가 새 연결을 처리할 때는 설정에 정의된 규칙 순서대로 일치 여부를 확인합니다. 규칙 하나에 일치하면 해당 대상 정책을 적용하고 뒤에 있는 일반 규칙은 더 이상 확인하지 않습니다. 따라서 규칙은 조건이 많다고 좋은 것이 아니며, 순서도 임의로 배치하면 안 됩니다. 범위가 좁고 의도가 분명한 규칙은 앞에, 범위가 넓은 규칙은 뒤에 배치하고 마지막에는 MATCH를 최종 규칙으로 사용합니다.
rules:
- DOMAIN-SUFFIX,example.cn,DIRECT
- DOMAIN-SUFFIX,example.com,PROXY
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,PROXY이 예시는 지정한 .cn 도메인을 직접 연결하고, 지정한 .com 도메인을 PROXY라는 정책 그룹으로 보내며, 일반적인 사설 네트워크 대역은 직접 연결하고, 나머지 연결은 PROXY로 전달한다는 뜻입니다. 실제 구독 설정의 정책 그룹 이름은 “노드 선택”, “자동 선택” 등으로 다를 수 있으므로, 규칙 대상은 설정에 이미 정의된 노드·정책 그룹 또는 내장 동작과 일치해야 합니다.
규칙 모드의 결과를 결정하는 세 가지 요소
- 규칙 일치: 연결이 어떤 정책 그룹이나 내장 출구로 전달될지 결정합니다. 도메인 규칙, IP 규칙, 규칙 집합, 프로세스 규칙은 각각 일치 조건이 다릅니다.
- 정책 그룹 상태: 규칙이 수동 선택 그룹을 가리키면 최종 출구는 현재 선택한 노드에 따라 결정됩니다. 자동 속도 측정 그룹을 가리키는 경우에는 해당 그룹의 테스트 결과와 허용 오차 설정이 결정합니다.
- 노드 가용성: 규칙과 정책 선택이 올바르더라도 노드 자체의 연결 시간 초과, 프로토콜 매개변수 변경 또는 네트워크 경로 이상이 발생하면 요청이 실패할 수 있습니다.
따라서 “규칙 모드에서 접속할 수 없다”는 말이 규칙 모드 자체가 작동하지 않는다는 뜻은 아닙니다. 더 효과적인 확인 방법은 연결 기록을 열어 대상 도메인을 찾고, 어떤 규칙에 일치했는지, 어떤 정책 그룹으로 들어갔는지, 최종적으로 어떤 출구를 사용했는지 확인하는 것입니다. 대상 서비스가 잘못 DIRECT로 전달되었다면 규칙 순서나 규칙 집합 내용을 확인해야 합니다. 예상한 프록시 그룹에 이미 들어갔다면 해당 그룹에서 선택한 노드를 계속 점검하세요.
DNS 결과도 규칙 판단에 영향을 줍니다
도메인 연결은 DOMAIN, DOMAIN-SUFFIX 또는 규칙 집합의 도메인 항목에 직접 일치할 수 있습니다. 일부 연결은 대상 IP만 제공하므로 코어가 DNS 매핑, 스니핑 결과 또는 IP 규칙을 바탕으로 경로를 판단해야 할 수 있습니다. Fake IP, 실제 IP 해석 또는 도메인 스니핑을 활성화하면 판단 과정이 달라지지만 기본 원칙은 같습니다. 먼저 코어가 실제로 도메인과 IP 중 무엇을 인식했는지 확인한 다음 해당 유형의 규칙을 점검하세요.
웹페이지에 표시된 주소만 보고 규칙 일치 결과를 추측하지 마세요. 하나의 페이지가 메인 도메인, 이미지 도메인, API 도메인, 서드파티 콘텐츠 전송 도메인에 동시에 요청할 수 있으며, 각각 직접 연결·프록시·차단으로 나뉠 수 있습니다. 페이지 일부만 로드되고 일부가 실패할 때는 모드를 계속 바꾸기보다 연결 목록을 확인하는 편이 진단에 더 유용합니다.
Global Mode
전역 모드: 단일 출구로 빠르게 테스트하기
전역 모드는 일반적인 개별 규칙 판단을 우회하고, 코어에 들어온 일반 연결을 전역 정책으로 전달합니다. 클라이언트의 전역 정책 그룹에서 노드를 선택하면 가로채진 트래픽 대부분이 해당 노드를 사용합니다. 경로가 단순하고 결과를 관찰하기 쉽다는 점 때문에 “문제가 규칙 때문인지 노드 때문인지” 판단할 때 유용합니다.
예를 들어 규칙 모드에서 특정 사이트에 접속할 수 없지만, 전역 모드로 전환한 뒤 정상 작동이 확인된 노드를 선택하면 사이트가 열리는 경우가 있습니다. 이는 로컬 프록시 진입점과 노드 경로가 대체로 정상이며, 다음으로 규칙 모드에서 해당 사이트가 어디에 일치했는지 확인해야 한다는 뜻입니다. 반대로 전역 모드에서도 실패한다면 노드 상태, 프로토콜 설정, DNS, 앱의 트래픽 가로채기 방식 또는 대상 서비스의 연결 조건에 문제가 있을 가능성이 큽니다.
전역 모드는 일반적으로 장기 기본값으로 적합하지 않습니다. LAN 서비스, 중국 본토 사이트, 소프트웨어 업데이트, 낮은 지연 시간이 필요한 서비스도 원격 노드로 전달되어 경로가 길어지고 속도가 떨어지거나, 서버의 지역 및 로그인 인증을 유발할 수 있습니다. 라우터 관리 페이지, 프린터, 네트워크 저장 장치 같은 로컬 리소스에 접근할 때는 클라이언트나 코어가 LAN 주소를 우회하도록 설정되어 있는지도 확인해야 합니다.
또한 전역 모드가 품질이 낮은 노드를 사용 가능한 노드로 바꿔 주는 것은 아닙니다. 수동 노드를 선택하면 관련 연결이 모두 해당 출구에 집중됩니다. 노드에서 패킷 손실이나 지연 변동이 발생하면 웹페이지, 동영상, 메신저가 동시에 영향을 받을 수 있습니다. 테스트할 때는 화면에 표시된 “전역”이라는 글자만 보지 말고 전역 정책 그룹에서 현재 선택된 항목을 먼저 확인하세요.
Direct Mode
직접 연결 모드: 코어를 거칠 수 있지만 프록시 노드는 사용하지 않음
직접 연결 모드의 핵심은 가로채진 트래픽이 로컬 네트워크를 통해 대상에 직접 연결되도록 하는 것입니다. 프록시 출구를 일시적으로 중지하거나, 통신사 네트워크가 대상에 직접 도달할 수 있는지 확인하거나, 프록시 노드가 이상을 일으키는지 점검할 때 사용합니다. 직접 연결 모드는 인터넷 연결을 끄는 스위치가 아니며 Clash를 완전히 종료하는 것과도 다릅니다.
시스템 프록시가 계속 켜져 있으면 브라우저는 요청을 로컬 프록시 포트로 계속 보낼 수 있고, mihomo가 요청을 받은 뒤 DIRECT를 선택하게 됩니다. TUN이 계속 켜져 있으면 시스템 트래픽도 가상 네트워크 인터페이스를 거친 다음 코어가 대상에 직접 전달할 수 있습니다. 따라서 연결 경로에서 “코어를 거친 뒤 직접 연결”과 “앱이 Clash를 완전히 우회”하는 것은 같은 의미가 아닙니다.
직접 연결 모드로 확인할 수 있는 것
- 특정 중국 본토 사이트의 문제가 프록시 노드나 원격 출구 때문인지 확인할 수 있습니다.
- 현재 로컬 네트워크에서 대상 도메인이나 IP에 직접 접속할 수 있는지 확인할 수 있습니다.
- 앱이 실제로 시스템 프록시나 TUN에 의해 가로채지고 있는지 확인할 수 있습니다.
- 다운로드 속도 변화가 원격 노드 경로와 관련 있는지 확인할 수 있습니다.
원래 프록시 경로가 필요한 대상이라면 직접 연결로 전환한 뒤 접속에 실패하는 것은 예상 가능한 결과입니다. 직접 연결은 대상 서비스 자체의 계정 제한, 지역 정책, 인증서 문제 또는 로컬 방화벽을 우회하지도 않습니다. 문제를 해결할 때는 전환 전후의 연결 기록과 오류 유형을 기록하고, “열린다” 또는 “열리지 않는다”만으로 결론 내리지 마세요.
클라이언트가 네트워크 경로에 완전히 관여하지 않게 하려면 현재 설정에 따라 시스템 프록시와 TUN을 끄고, 관련 앱에 로컬 프록시 포트가 별도로 입력되어 있지 않은지 확인해야 합니다. 일부 앱은 프록시 설정을 캐시하거나 기존 연결을 유지하므로 전환 후 새 연결을 만들어야 합니다. 필요하면 해당 앱을 다시 시작하고, 곧바로 모드 전환이 적용되지 않았다고 판단하지 마세요.
Traffic Entry
프록시 모드와 시스템 프록시·TUN 모드는 서로 다른 스위치입니다
초보자가 가장 자주 혼동하는 부분은 “규칙 모드”를 트래픽 가로채기 범위로, “TUN 모드”를 트래픽 분할 규칙의 한 종류로 이해하는 것입니다. 실제로 둘은 서로 다른 계층에 있습니다. 시스템 프록시와 TUN은 트래픽을 코어로 진입시키고, 규칙·전역·직접 연결은 코어에 들어온 뒤 사용할 출구를 결정합니다.
| 기능 | 계층 | 주요 역할 |
|---|---|---|
| 시스템 프록시 | 트래픽 진입점 | 운영체제의 프록시 설정을 따르는 앱이 로컬 HTTP 또는 혼합 프록시 포트에 연결하도록 함 |
| 앱 내 프록시 | 트래픽 진입점 | 앱이 Clash가 제공하는 로컬 프록시 포트에 직접 연결 |
| TUN | 트래픽 진입점 | 가상 네트워크 인터페이스를 통해 더 많은 TCP·UDP 트래픽과 시스템 프록시를 읽지 않는 앱의 트래픽을 가로챔 |
| 규칙·전역·직접 연결 | 출구 결정 | 코어에 들어온 연결이 규칙 결과, 통합 프록시 또는 직접 연결을 사용할지 결정 |
브라우저는 일반적으로 시스템 프록시를 읽으므로 시스템 프록시만 켜도 일반적인 웹 접속을 처리할 수 있습니다. 그러나 게임, 명령줄 도구, 일부 스토어 앱과 사용자 지정 네트워크 스택을 사용하는 소프트웨어는 시스템 프록시를 따르지 않을 수 있습니다. 이 경우 앱에 프록시를 직접 입력하거나, 라우팅·DNS·권한 요구 사항을 이해한 뒤 TUN을 사용해야 합니다.
TUN은 가로채는 범위를 넓혀 주지만 잘못된 규칙을 자동으로 수정하지는 않습니다. TUN에서 규칙 모드를 사용하면 연결은 계속 규칙에 따라 분할됩니다. 전역 모드에서는 TUN이 가로챈 연결이 보통 전역 정책으로 들어가고, 직접 연결 모드에서는 이러한 연결이 코어를 통해 직접 전송됩니다. UDP의 성공 여부는 노드 프로토콜, 노드 서버, 네트워크 환경, 정책 체인의 각 계층이 UDP를 지원하는지에 따라 달라집니다.
Selection Guide
초보자 선택법: 일상에는 규칙, 진단에는 전역, 검증에는 직접 연결
구독 설정에 정책 그룹과 규칙이 제대로 포함되어 있다면 초보자는 규칙 모드를 일상적인 기본값으로 사용하면 됩니다. 서비스마다 다른 출구를 사용하면서 LAN과 일반적인 직접 연결 경로도 유지할 수 있습니다. 구독을 처음 가져온 뒤에는 먼저 프록시 또는 정책 페이지에서 사용 가능한 노드를 선택하고, 규칙 모드와 시스템 프록시 상태, 브라우저 연결 기록이 나타나는지 확인하세요.
사용 상황에 따른 선택
- 일반적인 웹 검색·동영상·일상적인 소프트웨어: 규칙 모드를 우선 사용해 설정이 지역 및 서비스별 트래픽을 분할하도록 합니다.
- 노드 작동 여부 확인: 전역 모드로 잠시 전환하고 대상 노드를 명확히 선택한 뒤 테스트 대상에 접속합니다.
- 로컬 네트워크의 직접 연결 확인: 직접 연결 모드로 전환해 새 연결을 만들고 오류 유형과 응답 속도를 비교합니다.
- 시스템 프록시를 읽지 않는 앱: 먼저 TUN이나 앱 내 프록시가 필요한지 판단한 뒤 알맞은 라우팅 모드를 선택합니다.
- LAN 기기 접속 이상: 사설 주소 규칙, TUN 라우팅, LAN 우회 설정을 확인하고 프록시 노드만 계속 바꾸지 마세요.
반복 가능한 문제 해결 순서
- 설정이 로드되었고 정책 그룹에 선택 가능한 노드가 있는지 확인한 뒤, 지연 시간 또는 연결 가능성 테스트를 한 번 실행합니다.
- 대상 앱이 시스템 프록시, 앱 내 프록시 또는 TUN을 통해 코어에 들어오는지 확인하고 연결 패널에서 해당 기록을 찾습니다.
- 규칙 모드를 유지한 채 대상 도메인이 일치한 규칙, 정책 그룹, 최종 노드를 확인합니다.
- 전역 모드로 전환하고 정상 작동이 확인된 노드를 선택한 뒤 새 연결을 만들어 규칙 분할의 영향을 배제합니다.
- 직접 연결 모드로 전환해 다시 테스트하고 로컬 네트워크에서 직접 접속할 수 있는지 판단합니다.
- 세 모드 모두 문제가 있다면 DNS, 시스템 시간, 방화벽, 노드 프로토콜 매개변수, 구독 유효 상태와 로컬 네트워크 제한을 차례로 확인합니다.
테스트 중에는 한 번에 하나의 변수만 바꾸는 것이 좋습니다. 예를 들어 같은 노드에서 규칙 모드와 전역 모드를 비교하거나, 같은 모드에서 두 노드를 비교하세요. 노드 변경, TUN 활성화, DNS 수정, 모드 전환을 동시에 하면 결과가 회복되더라도 실제로 효과가 있었던 변경 사항을 특정하기 어렵습니다.
모드 전환을 영구적인 해결책으로 여기지 마세요
특정 서비스가 전역 모드에서만 접속된다면 전역 모드에 계속 머무는 것이 당장은 해결책처럼 보일 수 있지만, 더 합리적인 방법은 규칙 모드로 돌아가 일치 결과를 확인하는 것입니다. 서비스 관련 도메인이 잘못 직접 연결되었는지, 규칙 집합이 업데이트되었는지, 정책 그룹에서 적절한 노드를 선택했는지, 최종 규칙이 예상대로 작동하는지 확인할 수 있습니다.
특정 서비스가 직접 연결 모드에서만 접속된다면 규칙 모드에서 해당 서비스가 적절하지 않은 프록시 그룹으로 전달되는지 확인해야 합니다. 로컬 출구를 유지해야 하는 서비스라면 설정 구조를 이해한 뒤 더 구체적인 직접 연결 규칙을 추가하고, 범위가 넓은 프록시 규칙보다 앞에 배치할 수 있습니다. 구독으로 생성된 설정을 수정할 때는 구독 업데이트가 로컬 편집 내용을 덮어쓸 수 있다는 점에 유의하세요. 오버라이드, 스크립트 또는 설정 병합을 지원하는 클라이언트에서는 사용자 지정 규칙을 별도의 설정 계층으로 관리할 수 있습니다.