Clash 클라이언트마다 메뉴 이름과 배치는 조금씩 다르지만, 핵심 화면은 대체로 같은 작업을 중심으로 구성됩니다. 설정 불러오기, 코어 시작, 시스템 트래픽 가로채기, 프록시 그룹에서 출구 선택, 로그와 연결 기록을 통한 문제 확인이 그것입니다. 특정 클라이언트에서 버튼이 어디에 있는지 외우는 것보다 각 화면의 관계를 이해하는 편이 중요합니다.

일반적인 데스크톱 클라이언트는 화면을 ‘개요, 프록시, 설정, 연결, 로그, 설정’ 등으로 표시할 수 있으며, Android 클라이언트에서는 일부 기능이 사이드바나 하단 탐색 메뉴에 들어가기도 합니다. mihomo 코어를 사용하는 클라이언트에는 규칙 프로바이더, 외부 제어, 설정 오버라이드 또는 런타임 설정 메뉴가 추가될 수 있습니다. 이름은 달라도 데이터 흐름은 다음과 같이 정리할 수 있습니다. 설정이 규칙과 노드를 제공하고, 코어가 매칭과 전달을 수행하며, 시스템 프록시 또는 TUN이 앱 트래픽을 코어로 보내고, 로그와 연결 화면이 실행 결과를 보여줍니다.

개요 화면: 실제로 트래픽을 처리하고 있는지 확인

개요 화면은 ‘홈’, ‘대시보드’ 또는 ‘상태’로 표시되기도 합니다. 보통 코어 실행 상태, 현재 프록시 모드, 시스템 프록시 스위치, TUN 스위치, 업로드·다운로드 속도, 활성 연결 수와 메모리 사용량을 한곳에 보여줍니다. 클라이언트가 창만 열려 있는지, 실제 네트워크 트래픽을 처리하기 시작했는지 가장 먼저 판단할 수 있는 화면입니다.

코어 실행 상태

그래픽 클라이언트와 프록시 코어는 서로 다른 계층입니다. 인터페이스 프로세스는 설정 관리와 시스템 연동을 담당하고, Clash 또는 mihomo 코어는 포트 수신, 규칙 매칭과 연결 수립을 담당합니다. 따라서 창이 정상적으로 열렸다고 해서 코어가 반드시 성공적으로 시작된 것은 아닙니다. 개요 화면에 ‘중지됨’, ‘코어가 실행되지 않음’이 표시되거나 시작 직후 종료된다면 포트 사용 여부, 설정 구문과 코어 파일 상태부터 확인하세요.

코어가 성공적으로 시작되면 HTTP, SOCKS 또는 mixed-port와 같은 로컬 수신 포트가 표시되는 경우가 많습니다. mixed-port는 하나의 포트에서 HTTP와 SOCKS5 요청을 모두 받을 수 있습니다. 일반 사용자는 포트를 자주 바꿀 필요가 없지만, 다른 프록시 도구나 개발 환경 또는 구형 클라이언트가 같은 포트를 사용하면 시작에 실패할 수 있습니다.

시스템 프록시와 TUN의 차이

시스템 프록시는 운영체제의 프록시 설정을 변경합니다. 브라우저와 시스템 프록시를 따르는 앱은 요청을 Clash에 전달하지만, 일부 게임·명령줄 프로그램·자체 네트워크 스택을 사용하는 소프트웨어는 이 설정을 무시할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 만들어 더 낮은 계층에서 라우팅 조건에 맞는 트래픽을 가로채므로 적용 범위가 대체로 더 넓습니다.

둘은 단순한 ‘강도’ 단계가 아닙니다. 시스템 프록시는 이해하고 문제를 확인하기 쉬워 일반적인 웹 브라우징에는 충분한 경우가 많습니다. TUN은 시스템 프록시를 읽지 않는 앱, UDP 트래픽 또는 더 완전한 투명 프록시가 필요한 상황에 적합합니다. TUN을 활성화하려면 관리자 권한이 필요할 수 있으며, 방화벽·다른 가상 네트워크 어댑터·기업 보안 소프트웨어·시스템 라우팅의 영향을 받을 수 있습니다.

트래픽 그래프 읽는 법

업로드·다운로드 속도는 데이터가 코어를 통과하고 있다는 뜻일 뿐, 대상 웹사이트 접속이 정상이라는 것을 직접 증명하지는 않습니다. 소량의 트래픽이 계속 발생하는 것은 시스템 업데이트, 메시지 푸시 또는 백그라운드 동기화 때문일 수 있습니다. 활성 연결 수가 계속 늘고 줄어들지 않는다면 연결 화면에서 관련 프로세스와 대상 도메인을 확인하세요. 클라이언트에 트래픽이 0으로 표시되는데 브라우저는 정상적으로 인터넷에 연결된다면, 현재 앱이 Clash를 거치지 않거나 DIRECT 경로를 사용하고 있을 수 있습니다.

프록시 화면: 노드 목록보다 정책 그룹 이해하기

프록시 화면은 가장 오해하기 쉬운 영역입니다. 여기에는 서버 노드뿐 아니라 정책 그룹도 표시됩니다. 정책 그룹에는 여러 노드가 포함될 수 있고 다른 정책 그룹을 중첩할 수도 있습니다. 규칙이 특정 정책 그룹과 일치한 뒤에야 코어가 해당 그룹의 현재 선택 방식에 따라 출구를 결정합니다.

주요 정책 그룹 유형

  • select: 수동 선택. 화면에서 특정 노드나 하위 정책 그룹을 직접 선택할 수 있으며, 선택 결과는 설정을 다시 불러오거나 클라이언트의 저장 기능으로 바뀔 때까지 유지됩니다.
  • url-test: 자동 속도 측정. 코어가 지정된 테스트 주소에 주기적으로 접속해 지연 시간을 기준으로 성능이 더 좋은 노드를 선택합니다. 측정값은 테스트 대상의 응답을 의미하며 모든 웹사이트의 실제 속도와 같지는 않습니다.
  • fallback: 장애 조치. 목록 순서에 따라 사용 가능한 노드를 선택하고 현재 출구를 사용할 수 없으면 다음 후보로 전환합니다.
  • load-balance: 부하 분산. 설정된 방식에 따라 여러 노드에 연결을 분배하며, 세션 일관성 요구 사항을 명확히 이해하고 있는 환경에 더 적합합니다.

화면에 ‘자동 선택’, ‘노드 선택’, ‘해외 미디어’, ‘메신저’ 같은 이름이 표시되더라도 이는 대개 설정 제공자가 정의한 이름이며 클라이언트의 고정 기능이 아닙니다. 정책 그룹을 클릭하는 것은 해당 그룹의 출구를 바꾸는 작업일 뿐입니다. 현재 웹사이트에 영향을 주는지는 규칙이 그 웹사이트를 이 그룹에 할당했는지에 따라 달라집니다.

지연 시간 숫자의 실제 의미

노드 옆의 지연 시간은 일반적으로 전통적인 ICMP ping이 아니라 HTTP 테스트를 통해 측정됩니다. 결과는 테스트 주소, DNS, 네트워크 혼잡, 노드 부하와 측정 간격의 영향을 받습니다. 지연 시간이 짧으면 대화형 접속에 유리하지만 다운로드 속도는 대역폭, 경로 품질과 대상 사이트에도 좌우됩니다. ‘시간 초과’가 표시되어도 노드가 완전히 작동하지 않는다는 뜻은 아닙니다. 테스트 주소가 제한되었거나, 제한 시간이 너무 짧거나, 현재 네트워크에서 일시적으로 연결할 수 없는 경우일 수 있습니다.

노드를 선택할 때는 먼저 사용 가능 여부를 확인한 뒤 실제 접속 성능을 함께 비교하세요. 전체 그룹의 속도 측정을 반복하면 여러 테스트 연결이 동시에 생성됩니다. 모바일 네트워크나 노드가 많은 환경에서는 추가 트래픽이 발생하고 짧은 시간 동안 결과가 흔들릴 수 있습니다.

설정 화면: 구독 업데이트·설정 전환·오버라이드의 범위

설정 화면은 ‘Profiles’ 또는 ‘구독’으로 표시되기도 합니다. 원격 구독, 로컬 YAML 파일과 클라이언트가 생성한 설정을 저장하는 역할을 합니다. 설정을 하나 선택하면 클라이언트가 보통 해당 내용을 코어에 전달해 로드합니다. 프록시 그룹, 규칙, DNS와 노드 목록의 주요 출처도 이 화면입니다.

구독 업데이트와 설정 전환은 다릅니다

‘업데이트’는 기존 구독 주소에서 내용을 다시 가져오는 작업이고, ‘전환’은 이미 저장된 다른 설정을 코어에 로드하는 작업입니다. 구독 업데이트가 성공하면 노드와 정책 그룹이 바뀔 수 있으며, 수동으로 선택한 정책이 초기화될 수도 있습니다. 업데이트에 실패했다면 다운로드 실패, 응답 내용 형식 오류, 코어 로드 실패를 구분해야 합니다.

  1. 다운로드 실패는 보통 시간 초과, 도메인 확인 실패, 연결 거부 또는 비정상적인 HTTP 상태로 나타납니다.
  2. 형식 오류는 웹페이지 주소, 단일 노드 링크 또는 로그인 페이지를 Clash 설정으로 가져왔을 때 발생할 수 있습니다.
  3. 로드 실패가 발생하면 로그에 YAML 파싱, 필드 형식, 규칙 구문 또는 포트 충돌 관련 정보가 표시되는 경우가 많습니다.

자동 업데이트 간격은 클라이언트가 원격 설정을 얼마나 자주 확인할지를 뜻하며, 구독 서버에 반드시 새 내용이 생긴다는 의미는 아닙니다. 설정 제공자가 특정 요청 방식을 요구한다면 클라이언트가 해당 매개변수를 지원하는지도 업데이트 결과에 영향을 줍니다.

YAML 설정에는 어떤 항목이 들어가나

일반적인 설정에는 수신 포트, 실행 모드, DNS, 노드, 정책 그룹과 규칙이 포함될 수 있습니다. 프록시 프로바이더나 규칙 프로바이더를 사용하면 일부 내용이 원격 파일로 분리됩니다. 구조를 이해하기 위한 간단한 예시는 다음과 같습니다.

mixed-port: 7890
mode: rule

proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - 자동 선택
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,노드 선택
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

규칙은 순서대로 매칭되며 먼저 일치한 규칙이 적용됩니다. 마지막 MATCH는 보통 최종 대체 규칙 역할을 합니다. 어떤 도메인이 앞에서 이미 DIRECT와 일치했다면 기본 그룹을 바꿔도 경로는 달라지지 않습니다. 화면에 표시되는 정책 이름은 규칙에서 참조하는 이름과 일치해야 하며, 그렇지 않으면 설정을 불러올 때 오류가 발생할 수 있습니다.

오버라이드와 병합 기능

일부 클라이언트는 Merge, Script, Override 또는 오버라이드 기능을 제공해 구독 업데이트 후 로컬 설정을 추가할 수 있습니다. 예를 들어 DNS를 조정하거나 규칙을 삽입하고 정책 그룹을 수정할 수 있습니다. 구독 캐시를 직접 편집하지 않아도 된다는 점이 장점입니다. 캐시는 다음 업데이트 때 덮어써지기 때문입니다. 반면 처리 단계가 길어지므로 문제를 확인할 때 원본 설정과 오버라이드 결과를 모두 확인해야 합니다.

처음에는 꼭 필요한 수정만 유지하고 각 오버라이드의 목적을 기록하는 것이 좋습니다. 업데이트 후 갑자기 시작되지 않는다면 오버라이드를 잠시 비활성화한 뒤 원본 설정이 로드되는지 테스트하세요. 그러면 문제가 구독 내용에서 비롯되었는지 로컬 가공 단계에서 비롯되었는지 빠르게 구분할 수 있습니다.

연결 화면: 어떤 앱이 어느 주소에 접속하는지 확인

연결 화면에는 현재 또는 최근 코어를 통과한 네트워크 연결이 표시됩니다. 주요 항목으로 대상 도메인, 대상 IP, 출발지 주소, 네트워크 유형, 업로드·다운로드량, 일치한 규칙, 사용된 정책 체인과 연결 수립 시간이 있습니다. 분류 결과를 확인하기에 가장 직접적인 화면입니다.

규칙과 정책 체인을 중점적으로 확인

웹사이트가 예상한 노드를 사용하지 않을 때는 먼저 연결 화면에서 도메인을 검색한 다음 일치한 규칙과 정책 체인을 확인하세요. 예를 들어 ‘DOMAIN-SUFFIX → DIRECT’로 표시되면 규칙이 직접 연결을 명시한 것입니다. ‘MATCH → 노드 선택 → 특정 노드’라면 요청이 기본 규칙에 들어가 지정된 정책 그룹과 노드를 거쳤다는 뜻입니다.

일부 연결에 도메인 없이 IP만 표시되는 것은 앱이 IP에 직접 접속했거나, DNS 매핑 정보가 연결되지 않았거나, 스니핑 기능이 프로토콜의 호스트 이름을 인식하지 못했기 때문일 수 있습니다. 이때는 대상 IP, 프로세스 정보와 로그를 함께 확인해야 하며, 도메인란이 비어 있다는 이유만으로 규칙이 작동하지 않았다고 단정해서는 안 됩니다.

웹페이지를 닫아도 연결이 남아 있는 이유

최신 브라우저는 HTTP/2, HTTP/3 또는 지속 연결을 재사용하며, 메시지 앱도 연결을 계속 유지하는 경우가 많습니다. 따라서 페이지를 닫은 뒤에도 연결이 잠시 남을 수 있습니다. 노드나 규칙을 바꿔도 기존 연결이 새 출구로 자동 이동하지는 않습니다. 연결 화면의 닫기 버튼으로 특정 연결을 종료하면 앱이 현재 규칙에 따라 새 연결을 수립합니다.

‘모두 닫기’는 진행 중인 다운로드, 통화와 백그라운드 동기화를 중단합니다. 프록시 모드나 정책을 변경한 뒤 확인할 때는 유용하지만 일상적인 속도 향상 수단으로 사용해서는 안 됩니다. 연결이 즉시 반복해서 다시 만들어진다면 어떤 프로세스가 계속 요청을 보내는지 확인하세요.

로그 화면: 수준과 시간으로 시작·DNS·연결 오류 찾기

로그 화면에는 코어 실행 이벤트가 기록됩니다. 일반적인 수준으로 debug, info, warning과 error가 있습니다. 평소에는 info로 충분합니다. debug는 매칭과 연결 세부 정보를 더 많이 출력하므로 짧은 시간 동안 문제를 확인할 때 유용하지만 기록량이 크게 늘어납니다. 확인이 끝나면 일반 로그 수준으로 되돌리세요.

먼저 오류가 발생한 단계를 확인

  • 시작 단계: 설정 파싱 실패, 수신 포트 사용 중, 권한 부족, TUN 장치 생성 실패와 데이터베이스 파일 로드 오류를 확인합니다.
  • DNS 단계: 확인 시간 초과, 상위 서버 연결 불가, 비정상적인 주소 응답과 fake-ip의 앱 호환성 문제를 확인합니다.
  • 연결 단계: 연결 시간 초과, 연결 거부, TLS 핸드셰이크 실패, 네트워크 연결 불가와 노드 인증 오류를 확인합니다.
  • 규칙 단계: 규칙 프로바이더 다운로드 실패, 정책 그룹 없음과 현재 코어에서 지원하지 않는 규칙 필드를 확인합니다.

로그 한 줄에는 보통 시간, 수준, 네트워크 유형, 대상 주소, 일치한 규칙과 최종 출구가 포함됩니다. 읽을 때 마지막의 ‘timeout’만 보지 말고 같은 대상 주변의 DNS와 라우팅 기록을 앞쪽으로 따라가세요. 시간 초과가 로컬에서 노드로 가는 구간, 노드에서 대상까지의 구간 또는 DNS 조회에서 발생했는지에 따라 해결 방법이 달라집니다.

INFO  TCP connection matched DOMAIN-SUFFIX
source: 127.0.0.1
target: example.com:443
policy: 노드 선택
outbound: 자동 선택

이러한 기록은 연결이 이미 코어에 들어왔고 도메인 규칙에 따라 ‘노드 선택’ 정책으로 전달되었음을 의미합니다. 연결 화면과 로그에서 대상 요청을 모두 찾을 수 없다면 트래픽이 Clash에 들어오기 전 단계에서 문제가 발생했을 가능성이 큽니다. 개요 화면으로 돌아가 시스템 프록시, TUN, 앱 프록시 설정과 우회 규칙을 확인하세요.

규칙·프로바이더 화면: 설정 내용이 로드되었는지 확인

일부 클라이언트는 규칙 화면, 프록시 프로바이더 화면과 규칙 프로바이더 화면을 별도로 제공합니다. 규칙 화면에는 보통 현재 로드 순서에 따른 DOMAIN, DOMAIN-SUFFIX, IP-CIDR, GEOIP, GEOSITE 등의 항목과 대상 정책이 표시됩니다. 특정 규칙이 존재하는지 확인하기에는 적합하지만 실제 매칭 결과는 연결 화면을 기준으로 판단해야 합니다.

프록시 프로바이더는 외부 파일에서 노드 목록을 불러오고, 규칙 프로바이더는 규칙 목록을 불러옵니다. 화면에 표시되는 업데이트 시간, 상태 확인 결과와 오류 메시지는 원격 리소스의 사용 가능 여부를 판단하는 데 도움이 됩니다. 프로바이더 업데이트 성공이 기본 구독 업데이트를 의미하지는 않습니다. 두 항목은 서로 다른 주소와 업데이트 주기를 사용할 수 있습니다.

mihomo는 다양한 규칙 유형과 실행 기능을 지원하지만 설정을 사용할 수 있는지는 클라이언트에 포함된 코어 버전에 따라 달라집니다. ‘지원하지 않는 규칙 유형’ 또는 ‘알 수 없는 필드’ 오류가 발생하면 클라이언트 외형의 버전 번호만 보지 말고 실제로 어떤 코어가 실행 중인지 확인하세요.

설정 화면: 포트·모드·DNS·시스템 시작 옵션 선택

설정 화면에는 항목이 가장 많지만 대부분의 옵션은 자주 조정할 필요가 없습니다. 특히 이해해 둘 만한 항목은 프록시 모드, 수신 포트, 로컬 네트워크 접근, DNS, TUN, 외부 제어와 시스템 시작입니다.

프록시 모드

  • Rule: 설정의 규칙에 따라 직접 연결, 차단 또는 프록시 사용을 결정하는 모드로, 일상적인 사용에 가장 흔합니다.
  • Global: 트래픽을 전역 정책 그룹에 전달하며, 규칙 분류 때문에 문제가 발생했는지 임시로 확인할 때 주로 사용합니다.
  • Direct: 트래픽을 직접 연결하도록 하며, 프록시 경로를 잠시 끄고 비교 테스트할 때 적합합니다.

전역 모드는 모든 시스템 트래픽을 자동으로 클라이언트에 넣지 않습니다. 이미 코어에 들어온 트래픽의 출구 선택 방식만 바꿉니다. 시스템 프록시와 TUN이 모두 비활성화되어 있다면 Global로 전환해도 효과가 보이지 않을 수 있습니다.

로컬 네트워크 접근과 외부 제어

‘로컬 네트워크 연결 허용’을 켜면 같은 네트워크의 다른 기기가 이 컴퓨터의 프록시 수신 포트에 접근할 수 있습니다. 프록시를 공유해야 하는 경우에만 활성화하고, 방화벽·수신 주소·인증 설정으로 접근 범위를 제한하세요. 외부 제어 인터페이스는 그래픽 화면이나 관리 도구가 상태를 읽고 정책을 전환하거나 연결을 종료하는 데 사용됩니다. 신뢰할 수 없는 네트워크에 노출되지 않도록 해야 합니다.

DNS와 fake-ip

Clash의 DNS 모듈은 설정에 따라 상위 서버를 선택하고 규칙 매칭, 도메인 복원과 TUN 가로채기와 연동할 수 있습니다. fake-ip 모드에서는 앱에 예약 주소를 반환한 뒤 코어가 연결을 원래 도메인으로 매핑하므로 도메인 기반 분류에 도움이 됩니다. 일부 로컬 네트워크 서비스, 특정 게임 또는 실제 DNS 응답에 의존하는 앱은 예외 목록에 추가해야 할 수 있습니다.

DNS 문제는 여러 옵션을 동시에 바꾸는 방식으로 해결하지 않는 편이 좋습니다. 먼저 시스템의 DNS 조회가 Clash로 전달되는지 확인하고, 다음으로 상위 DNS에 연결할 수 있는지 점검한 뒤, 대상 도메인이 어떤 결과를 받고 어떤 규칙과 일치하는지 확인하세요. 브라우저의 보안 DNS 기능이 시스템 DNS 경로를 우회할 수도 있으므로 함께 고려해야 합니다.

시스템 시작과 무음 시작

시스템 시작은 클라이언트를 실행하는 기능일 뿐입니다. 코어 자동 실행, 시스템 프록시 복원 또는 TUN 활성화 여부는 클라이언트의 별도 설정에 따라 달라집니다. ‘재부팅 후 인터넷이 되지 않음’ 문제를 확인할 때는 클라이언트가 이전 스위치 상태를 복원했는지, 비정상 종료 후 시스템 프록시가 로컬 포트를 가리키는 설정으로 남아 있는지 확인하세요.

반복해서 적용할 수 있는 Clash 화면 문제 해결 절차

각 화면에 익숙해지면 노드, DNS와 모드 사이를 무작정 바꾸지 않고 자주 발생하는 문제를 하나의 고정된 절차로 줄일 수 있습니다.

  1. 설정 화면 확인: 현재 선택된 설정, 업데이트 시간과 로드 상태를 확인하고 구문 또는 프로바이더 오류가 있는지 살펴봅니다.
  2. 개요 화면 확인: 코어가 실행 중인지 확인하고 현재 트래픽이 시스템 프록시를 통하는지 TUN을 통하는지 명확히 파악합니다.
  3. 프록시 모드 확인: 평소에는 Rule을 사용하고, 규칙의 영향을 확인해야 할 때는 Global 또는 Direct를 잠시 비교 테스트에 사용합니다.
  4. 프록시 화면 확인: 대상 정책 그룹에서 사용할 수 있는 노드를 선택했는지 확인합니다. 대상 트래픽과 관계없는 그룹만 변경하지 않도록 주의하세요.
  5. 연결 다시 수립: 대상 앱의 기존 연결을 닫아 현재 세션이 이전 출구를 계속 사용하지 않도록 합니다.
  6. 연결 화면 확인: 대상 도메인 또는 IP를 찾아 일치한 규칙, 정책 체인과 실제 출구를 확인합니다.
  7. 로그 화면 확인: 장애가 발생한 시간대를 기준으로 DNS, 연결, TLS, 규칙 또는 권한 오류를 찾습니다.

Direct에서는 접속되지만 Rule에서는 접속되지 않는다면 규칙과 정책 그룹을 중점적으로 확인하세요. Global에서도 접속할 수 없다면 노드, DNS와 대상 연결 가능성을 계속 점검해야 합니다. 세 모드 모두에서 해당 연결 기록이 없다면 시스템 프록시, TUN 라우팅 또는 앱 자체의 프록시 설정을 확인하세요. 이런 단계별 판단을 통해 문제를 설정, 트래픽 가로채기, 분류 또는 출구 중 한 계층으로 빠르게 좁힐 수 있습니다.

Clash 클라이언트 인터페이스는 본질적으로 코어를 관찰하고 제어하는 도구 모음입니다. 프록시 화면은 ‘어떤 출구를 사용할지’, 설정 화면은 ‘규칙과 노드가 어디에서 오는지’, 연결 화면은 ‘이 트래픽이 실제로 어디로 갔는지’, 로그 화면은 ‘실행 중 무슨 일이 일어났는지’를 보여줍니다. 이 네 가지 질문을 이해하면 플랫폼이나 화면 배치가 달라져도 해당 기능을 찾아 기본 설정과 문제 확인을 수행할 수 있습니다.

Clash 클라이언트 설정 계속하기

현재 시스템에 맞는 클라이언트를 선택한 뒤 안내에 따라 설정 가져오기, 프록시 모드 선택과 연결 확인을 진행하세요.

다운로드 페이지 사용법 보기