Clash 또는 Clash Meta(mihomo) 코어 기반 클라이언트를 처음 사용하면 화면에 표시되는 ‘규칙’, ‘전체’, ‘직접 연결’이 혼란스러울 수 있습니다. 이는 서로 다른 구독이나 독립된 프록시 서버 세 개가 아니라, 연결을 어떻게 배분할지 결정하는 실행 모드입니다. 모드를 전환하면 클라이언트가 도메인, IP 주소, 애플리케이션 연결을 서로 다른 경로로 처리하므로 같은 웹사이트도 모드에 따라 접속 결과가 달라질 수 있습니다.
세 가지 옵션을 이해하는 핵심은 특정 버튼의 위치를 외우는 데 있지 않습니다. 클라이언트가 트래픽을 전달받았는지, 유입된 트래픽이 규칙과 어떻게 매칭되는지, 매칭 결과가 프록시로 갈지 로컬 네트워크로 갈지를 구분해야 합니다. 이 글에서는 데스크톱 클라이언트에서 흔히 사용하는 흐름을 기준으로 각 모드의 작동 방식, 적합한 테스트 상황, 연결 이상 발생 시 순서대로 점검하는 방법을 설명합니다.
1. 세 가지 모드에서 달라지는 점
Clash 설정에는 일반적으로 프록시 노드, 프록시 그룹, 규칙, 규칙 제공자 등이 포함됩니다. 클라이언트가 코어를 시작하면 설정에 지정된 HTTP, SOCKS, 혼합형 또는 기타 프록시 포트를 수신 대기하며, 시스템 프록시를 지원하는 애플리케이션은 요청을 이 포트로 전달할 수 있습니다. 시스템 프록시를 사용하지 않는 프로그램도 클라이언트에서 TUN을 활성화하고 시스템 권한, 라우팅, DNS 설정이 조건을 충족하면 원래 프록시 포트를 직접 사용하지 않던 일부 트래픽을 가로챌 수 있습니다.
트래픽이 코어에 들어오면 모드가 규칙 처리 흐름에 영향을 줍니다. 규칙 모드는 설정 파일의 규칙 순서에 따라 하나씩 매칭하며, 매칭 결과는 특정 프록시 그룹, DIRECT, REJECT 또는 기타 정책일 수 있습니다. 전체 모드는 일반적인 도메인 및 IP 규칙을 우회하고, 가로챌 수 있는 연결을 현재 선택된 전체 프록시 그룹으로 일괄 전달합니다. 직접 연결 모드는 연결을 로컬 네트워크로 보내며 보통 DIRECT로 처리됩니다. 단, 모드는 이미 Clash의 처리 범위에 들어온 트래픽에만 적용됩니다. 애플리케이션이 시스템 프록시를 사용하지 않거나 TUN 가로채기가 실패했거나 클라이언트가 실행 중이 아니라면 모드를 바꿔도 해당 연결에는 변화가 없습니다.
규칙 모드: 설정에 따라 연결 경로 결정
규칙 모드는 대부분의 사용자가 일상적으로 선택하는 방식입니다. 설정 파일은 도메인 접미사, 전체 도메인, 지리 데이터베이스, IP 주소, 프로세스 또는 규칙 세트 등의 조건에 따라 연결 경로를 결정합니다. 예를 들어 LAN 주소와 중국 본토 서비스를 DIRECT로 보내고, 특정 도메인은 프록시 그룹으로 전달한 뒤 MATCH를 최종 기본 규칙으로 둘 수 있습니다. 실제 동작은 현재 설정의 구체적인 내용에 따라 달라지므로 클라이언트의 버튼 이름만 보고 판단해서는 안 됩니다.
규칙에는 순서가 있습니다. 앞에 있는 규칙이 먼저 처리 기회를 얻고, 뒤의 규칙은 아직 매칭되지 않은 연결만 처리합니다. 따라서 범위가 넓은 도메인 규칙이 앞에 있으면 뒤에 배치한 더 구체적인 규칙이 적용되지 않을 수 있습니다. 규칙 모드에서 ‘특정 사이트가 예상대로 프록시를 거치지 않는’다면 모드를 반복해서 전환하기보다 먼저 연결 상세 정보와 매칭된 규칙을 확인하세요.
전체 모드: 현재 프록시 그룹으로 일괄 전달
전체 모드의 목적은 규칙에 따른 변수를 줄이는 것입니다. 전체 모드로 전환하면 클라이언트는 일반적으로 화면에서 선택한 전체 프록시 또는 프록시 그룹을 사용해 연결을 처리합니다. 클라이언트마다 명칭은 조금 다를 수 있습니다. 어떤 화면에서는 ‘전체 프록시’로, 다른 화면에서는 현재 프록시 그룹으로 표시되지만, 본질적으로는 트래픽 경로를 하나의 명확한 프록시 선택으로 모으는 방식입니다.
전체 모드가 ‘모든 시스템 트래픽이 100% 자동으로 프록시를 통과한다’는 뜻은 아닙니다. 시스템 프록시, 클라이언트의 가로채기 범위, 애플리케이션 프로토콜, TUN 상태의 영향을 여전히 받습니다. 브라우저가 이미 시스템 프록시를 사용한다면 테스트 결과가 비교적 명확하지만, 일부 게임, 명령줄 도구, 가상 머신, 시스템 서비스는 시스템 프록시를 읽지 않으므로 TUN, 애플리케이션 자체의 프록시 설정 또는 별도의 라우팅 방식이 필요할 수 있습니다.
직접 연결 모드: 연결을 로컬 네트워크로 전달
직접 연결 모드는 Clash의 처리 범위에 들어온 연결을 프록시 노드 없이 DIRECT 경로로 목적지에 접속하게 합니다. 로컬 DNS, 인터넷 회선, 회사 네트워크, 라우터, 애플리케이션 자체가 정상인지 점검할 때 적합하며, 프록시 노드를 일시적으로 사용할 수 없을 때 일반적인 로컬 서비스 접속을 복구하는 데도 유용합니다.
직접 연결 모드는 ‘Clash를 종료한다’는 뜻이 아닙니다. 클라이언트는 계속 실행될 수 있고 시스템 프록시나 TUN도 켜진 상태일 수 있습니다. 다만 코어가 전달받은 연결에 로컬 출구를 선택할 뿐입니다. 클라이언트의 가로채기 영향을 완전히 배제하려면 설정과 현재 작동 상태를 확인한 뒤 시스템 프록시를 끄거나 관련 가로채기 기능을 중지하고 비교 테스트를 진행하세요.
2. 일상적으로 어떤 모드를 선택해야 할까
규칙이 잘 준비된 구독 설정이라면 규칙 모드가 장기적인 일상 사용에 가장 적합합니다. 트래픽 유형에 따라 프록시, 로컬 직접 연결 또는 다른 정책 그룹으로 나누어 수동 전환을 줄일 수 있습니다. 예를 들어 자주 사용하는 중국 본토 웹사이트는 낮은 지연 시간으로 접속하고, 지정한 해외 도메인은 프록시 그룹으로 보내며, LAN 장치는 계속 로컬 주소로 이용할 수 있습니다. 규칙 모드의 편의성은 설정 품질을 전제로 합니다. 규칙 세트 업데이트 시점, 정책 그룹 이름, DNS 동작, 기본 규칙이 최종 결과에 영향을 줍니다.
전체 모드는 진단 도구에 가깝고, 브라우저나 특정 애플리케이션을 일시적으로 하나의 노드로 통일해 연결해야 할 때도 적합합니다. 테스트할 때는 먼저 정상 작동이 확인된 노드나 프록시 그룹을 선택한 다음 전체 모드로 전환하고 대상 사이트를 열어 연결 상세 정보를 확인하세요. 전체 모드에서는 접속되지만 규칙 모드에서는 접속되지 않는다면 문제는 대개 노드 자체가 아니라 규칙 매칭, 정책 그룹 선택 또는 규칙 세트 업데이트에 있습니다.
직접 연결 모드는 반대 방향의 비교 테스트에 적합합니다. 규칙 모드에서 사이트가 열리지 않을 때 직접 연결로 전환해 같은 주소에 접속하면 로컬 네트워크 문제와 프록시 경로 문제를 구분하는 데 도움이 됩니다. 직접 연결은 되지만 전체 모드가 되지 않는다면 노드, 프록시 그룹, 원격 DNS 또는 프록시 프로토콜을 확인하세요. 직접 연결과 전체 모드 모두 실패한다면 도메인 확인, 네트워크 연결, 애플리케이션 상태, 대상 서비스 자체를 계속 점검해야 합니다.
| 모드 | 주요 처리 방식 | 적합한 상황 |
|---|---|---|
| 규칙 | 규칙 순서대로 매칭한 뒤 해당 정책으로 전달 | 일상 사용, 사이트별 분기, LAN과 프록시 혼합 접속 |
| 전체 | 가로챌 수 있는 연결을 현재 프록시 그룹으로 일괄 전달 | 노드 확인, 임시 전체 프록시, 규칙 변수 배제 |
| 직접 연결 | 가로챌 수 있는 연결을 로컬 네트워크로 접속 | 로컬 네트워크 확인, 프록시 장애 비교, 로컬 서비스 접속 |
3. 세 단계 비교로 접속 문제 찾기
웹페이지가 열리지 않거나 애플리케이션 연결이 시간 초과되거나 로그인 API에 이상이 생겼다면 테스트 대상과 조건을 고정하는 것이 좋습니다. 매번 노드, DNS, 모드, 브라우저를 동시에 바꾸면 결과가 달라져도 어떤 설정이 영향을 주었는지 판단하기 어렵습니다.
- 먼저 직접 연결을 테스트합니다. 대상 주소, 브라우저, 네트워크 환경을 그대로 유지한 채 직접 연결 모드로 전환하세요. 도메인이 확인되는지와 페이지 연결이 성립하는지를 확인하고 브라우저 오류 메시지를 기록합니다. 직접 연결도 실패한다면 먼저 로컬 네트워크, DNS, 시스템 시간 또는 대상 서비스 문제를 처리하세요.
- 다음으로 전체 모드를 테스트합니다. 정상 상태인 프록시 노드나 프록시 그룹을 선택하고 전체 모드로 전환하세요. 클라이언트 연결 목록에 대상 도메인이 나타나는지 확인하고, 사용된 정책, 아웃바운드 유형, 오류 정보를 살펴봅니다. 연결이 목록에 나타나지 않는다면 시스템 프록시 또는 TUN 가로채기 범위를 집중적으로 점검하세요.
- 마지막으로 규칙 모드로 돌아갑니다. 규칙 모드에서 같은 대상에 다시 접속하고 연결 상세 정보를 열어 매칭된 규칙을 확인하세요. DIRECT가 매칭되었다면 규칙이 해당 연결을 직접 연결로 배정한 것입니다. 특정 프록시 그룹이 매칭되었다면 그룹의 현재 선택과 노드 지연 시간을 확인하세요. MATCH가 매칭되었다면 기본 정책이 실제로 어디를 가리키는지 살펴봐야 합니다.
이 순서로 변수를 단계적으로 늘릴 수 있습니다. 직접 연결에서는 기본 네트워크를 먼저 확인하고, 전체 모드에서는 프록시 경로를 확인하며, 마지막으로 규칙 모드에서 트래픽 분기 로직을 확인합니다. 명령줄 도구는 애플리케이션이 지원하는 프록시 인자나 환경 변수로 개별 테스트할 수 있고, 브라우저는 시스템 프록시가 적용되는지 확인해야 합니다. 테스트할 때는 브라우저 캐시, 연결 재사용, DNS 캐시에도 주의하고 필요하면 페이지를 닫았다가 다시 여세요.
4. 규칙 모드에서 흔히 하는 오판
DIRECT가 매칭되었다고 규칙이 작동하지 않는 것은 아닙니다
DIRECT는 명확한 아웃바운드 선택입니다. 많은 설정이 LAN 도메인, LAN IP, 중국 본토 사이트 또는 특정 서비스를 의도적으로 직접 연결합니다. 연결 상세 정보에 DIRECT가 표시되면 먼저 설정 의도와 대조하세요. 원래 직접 연결되어야 하는 도메인이라면 정상 결과입니다. 프록시를 거쳐야 하는데 DIRECT가 매칭되었다면 앞선 규칙이 도메인을 먼저 처리했는지 또는 규칙 세트가 오래된 버전인지 확인하세요.
프록시 그룹이 매칭되었다고 노드가 반드시 사용 가능한 것은 아닙니다
규칙은 연결을 특정 정책으로 전달할 뿐이며, 정책 그룹 안에는 여러 노드, 자동 선택 그룹, 장애 조치 그룹 또는 체인형 프록시 그룹이 포함될 수 있습니다. 전체 모드에서도 구체적인 노드를 선택하거나 프록시 그룹의 현재 선택을 확인해야 합니다. 노드 지연 시간 테스트에 성공했다고 모든 대상 프로토콜에 접속할 수 있는 것은 아닙니다. 지연 시간 측정과 실제 HTTPS, WebSocket 또는 UDP 트래픽이 사용하는 경로가 다를 수 있기 때문입니다.
도메인 규칙과 IP 규칙은 서로 다른 결과를 낼 수 있습니다
일부 요청은 도메인으로 접속하고, 일부 연결은 확인 후 IP 대상처럼 처리됩니다. 설정의 도메인 규칙, GeoIP 규칙, 논리 규칙, DNS 모드가 함께 매칭 결과에 영향을 줄 수 있습니다. 같은 서비스의 웹페이지, 데스크톱 앱, API 동작이 서로 다르다면 각 연결의 대상 도메인, 대상 IP, 포트, 매칭 규칙을 비교해야 하며 브라우저 주소 표시줄만 보고 판단해서는 안 됩니다.
5. TUN 모드와 세 가지 프록시 모드의 관계
TUN은 시스템 수준에서 트래픽을 가로채는 방식입니다. 클라이언트가 가상 네트워크 인터페이스를 만들고 조건에 맞는 네트워크 트래픽을 코어로 전달합니다. TUN이 해결하는 문제는 ‘어떤 트래픽을 Clash로 유입할 수 있는가’이고, 규칙·전체·직접 연결 모드가 해결하는 문제는 ‘유입된 뒤 어떤 출구를 선택하는가’입니다. 둘은 서로 다른 계층에 있습니다. TUN을 켠다고 모든 연결이 자동으로 프록시를 통과하는 것은 아니며, 전체 모드로 전환한다고 TUN의 권한, 라우팅, DNS 설정을 대신할 수도 없습니다.
브라우저는 규칙 모드에서 작동하지만 시스템 프록시를 읽지 않는 특정 애플리케이션에 연결 기록이 전혀 없다면, 해당 앱을 가로채는 데 TUN이 필요한지 확인해 볼 수 있습니다. TUN을 활성화하기 전에는 클라이언트에 필요한 시스템 권한이 있는지 확인하고, 다른 VPN, 가상 네트워크 카드, 기업용 보안 소프트웨어, 네트워크 가속 도구와 충돌하지 않는지 살펴보세요. TUN의 DNS 처리, 자동 라우팅, LAN 및 IPv6 우회 동작도 결과에 영향을 줄 수 있으므로 한 번에 하나의 옵션만 조정하고 기존 설정을 보존하는 것이 좋습니다.
TUN이 켜져 있어도 직접 연결 모드는 여전히 로컬 네트워크로 접속할 수 있고, 전체 모드는 여전히 유효한 프록시 노드가 필요하며, 규칙 모드는 여전히 설정 순서에 따라 처리됩니다. TUN을 켠 뒤 모든 네트워크가 비정상이라면 먼저 직접 연결 모드로 돌아가 연결을 관찰한 다음 TUN을 잠시 끄고 비교하세요. 끈 뒤 복구된다면 가상 인터페이스, 라우팅, DNS, 다른 네트워크 소프트웨어 간 충돌로 점검 범위를 좁힐 수 있습니다.
6. 모드 전환 전후 점검 목록
- 현재 클라이언트에서 방금 가져왔지만 아직 전환하지 않은 파일이 아니라 대상 설정 파일이 활성화되어 있는지 확인하세요.
- 구독 업데이트 시간이 정상인지, 정책 그룹이 유지되고 있는지, 노드 목록이 비어 있지 않은지 확인하세요.
- 현재 시스템 프록시 포트를 기록하세요. 일부 프로그램은 HTTP 프록시만 지원하고 일부는 SOCKS를 지원하므로 해당 포트를 사용해야 합니다.
- 시스템 프록시 스위치와 클라이언트 실행 상태가 일치하는지 확인해 브라우저가 이전 포트에 계속 연결하지 않도록 하세요.
- 다른 VPN, 프록시 소프트웨어, 네트워크 필터 또는 가상 네트워크 카드 도구가 동시에 실행 중인지 확인하세요.
- 테스트할 때 동일한 도메인과 애플리케이션을 고정하고 직접 연결, 전체, 규칙 모드에서 각각 연결 상세 정보를 기록하세요.
- 규칙 모드로 돌아온 뒤 프록시 그룹의 실제 선택을 확인하세요. 자동 선택 그룹의 속도 측정 결과가 대상 사이트 테스트를 대신할 수는 없습니다.
점검을 마친 뒤 일상 설정은 보통 규칙 모드로 돌아가야 합니다. 프록시가 반드시 필요한 사이트는 적절한 규칙이나 규칙 세트에 지정하고, LAN과 로컬 서비스는 직접 연결로 유지하세요. 진단이나 임시 목적이 아니라면 전체 모드를 장기간 사용하는 것은 피하는 편이 좋습니다. 이렇게 하면 트래픽 분기의 제어력을 유지하면서 프록시가 필요 없는 서비스를 원격 노드로 보내지 않아 접속 경로와 장애 범위의 불확실성도 줄일 수 있습니다.
7. 결론: 문제를 먼저 판단하고 모드를 선택하세요
규칙, 전체, 직접 연결 중 항상 ‘최고’인 선택지는 없습니다. 규칙 모드는 ‘설정에 따라 트래픽을 분기한다’는 뜻이고, 전체 모드는 ‘가로채기 범위 안에서 현재 프록시를 일괄 사용한다’는 뜻이며, 직접 연결 모드는 ‘가로채기 범위 안에서 로컬 네트워크로 돌아간다’는 뜻입니다. 문제가 생기면 직접 연결, 전체, 규칙 순서로 비교하고 연결 기록과 매칭 규칙을 함께 확인하는 것이 모드 버튼을 반복해서 누르는 것보다 원인을 빠르게 찾는 방법입니다.
안정적인 일상 사용이 목표라면 먼저 구조가 명확한 설정을 준비하고 구독과 정책 그룹이 정상적으로 업데이트되는지 확인한 뒤 시스템 프록시 또는 TUN이 대상 애플리케이션까지 적용되는지 점검하세요. 이 판단 방식을 익히면 모드 전환은 감에 의존한 시도가 아니라 반복 가능한 네트워크 문제 해결 절차가 됩니다.