Clash 클라이언트 화면 한눈에 보기: 프록시·프로필·로그 화면 기능

화면, 코어, 트래픽 유입 경로부터 확인하기

Clash 계열 GUI 클라이언트는 설정을 표시하고 정책을 전환하며 시스템 프록시를 제어합니다. 실제 규칙 매칭과 연결 전달은 코어가 처리합니다. Clash Verge Rev, ClashX 계열, 모바일 클라이언트는 메뉴 이름이 서로 다를 수 있습니다. 이 글에서는 프록시, 프로필, 연결, 로그, 설정의 다섯 가지 기능을 기준으로 설명합니다. 화면에는 Proxies, Profiles, Connections, Logs, Settings로 표시될 수도 있으니 버튼 이름을 그대로 찾기보다 기능에 맞는 메뉴를 확인하세요.

처음 클라이언트를 열면 홈이나 설정 화면에서 코어 상태를 확인한 다음, 현재 프로필이 정상적으로 불러와졌는지 살펴보세요. 창이 열렸다는 것은 GUI가 시작됐다는 뜻일 뿐입니다. 코어 시작 실패, 포트 충돌, 설정 파싱 오류가 있으면 프록시 화면에 이전 노드 목록이 남아 있어도 트래픽이 정상적으로 전달된다고 볼 수 없습니다.

화면 영역	확인할 항목	이것만으로는 알 수 없는 점
홈 또는 개요	코어 실행 상태, 현재 프로필, 실시간 트래픽	트래픽이 0이어도 장애라고 단정할 수 없습니다. 요청이 없을 수도 있습니다.
프록시 화면	정책 그룹 이름, 현재 선택 항목, 테스트 결과	지연 시간이 짧아도 모든 사이트에 접속할 수 있는 것은 아닙니다.
프로필 화면	현재 활성 항목, 업데이트 결과, 파싱 오류	다운로드에 성공해도 프로필이 활성화된 것은 아닙니다.
연결 화면	대상 주소, 매칭된 규칙, 정책 체인	목록에 기록이 없다고 바로 노드 문제로 볼 수는 없습니다.
로그 화면	시간, 수준, 오류 관련 맥락	오류 한 건이 모든 연결의 실패를 뜻하지는 않습니다.

프록시 화면: 정책 그룹, 노드, 실행 모드

그룹 이름을 확인한 다음 그룹 안의 항목을 살펴보세요

프록시 화면에는 보통 정책 그룹이 카드 형태로 표시됩니다. 카드 제목은 설정의 proxy-groups 이름에 해당합니다. 그룹 안에는 단일 노드, 다른 정책 그룹, DIRECT 같은 내장 정책이 들어갈 수 있습니다. 구독에 표시된 ‘자동 선택’, ‘수동 선택’, ‘해외 트래픽’은 그룹 이름일 뿐입니다. 동작을 판단할 때는 중국어 이름만 보고 추측하지 말고 그룹의 type을 확인하세요.

select: 수동 선택입니다. 항목을 누르면 이후 해당 그룹을 사용하는 새 연결은 보통 새로 선택한 항목을 따릅니다.
url-test: 테스트 결과에 따라 자동으로 선택합니다. 전환 여부는 테스트 주기와 허용 오차 등의 설정에도 영향을 받습니다.
fallback: 설정된 순서에 따라 사용 가능한 출구를 선택합니다. 지연 시간이 가장 짧은 노드를 단순히 고르는 방식은 아닙니다.
load-balance: 설정된 분배 방식에 따라 연결별 출구를 선택합니다. 단일 다운로드 연결의 대역폭을 여러 노드만큼 합산하지는 않습니다.

한 그룹이 다른 자동 그룹을 참조한다면 자동 그룹을 선택한 뒤에도 해당 그룹에 선택을 맡기게 됩니다. 문제를 확인할 때는 최종 노드까지 펼쳐 전체 정책 체인을 기록하세요. 예를 들어 ‘해외 트래픽 → 자동 선택 → 노드 A’라고 적어두면 ‘자동 선택을 골랐다’고만 기록하는 것보다 문제를 재현하기 쉽습니다.

Rule, Global, Direct는 각각 어떤 부분을 바꿀까요?

일상적인 규칙 기반 분기에는 Rule을 사용합니다. 코어는 규칙을 순서대로 확인해 대상에 맞는 정책으로 전달합니다. 현재 요청이 한 번도 매칭되지 않은 그룹을 바꿔도 해당 요청의 출구는 달라지지 않습니다. Global은 코어에 들어온 트래픽을 전역 정책으로 전달하므로 전역 그룹 선택을 확인해야 합니다. Direct는 코어에 들어온 트래픽을 직접 연결합니다. Global로 전환해도 원래 시스템 프록시를 사용하지 않던 앱이 자동으로 코어에 들어오는 것은 아닙니다.

프록시 화면에서 모드를 Rule로 설정하고 대상 트래픽을 처리하는 정책 그룹을 확인합니다.
수동 그룹으로 이동해 특정 노드 하나를 선택하고, 다른 그룹은 동시에 변경하지 않습니다.
기존 테스트 연결을 종료한 뒤 다시 접속하고 연결 화면에서 실제 정책 체인을 확인합니다.
기존 연결이 여전히 이전 출구를 사용한다면 연결 화면에서 해당 테스트 연결만 종료하세요. 모든 연결을 먼저 끊을 필요는 없습니다.

지연 시간은 한 번의 테스트 결과일 뿐입니다

프록시 화면의 밀리초 값은 보통 지정된 테스트 URL에 요청을 보내 확인한 시간이며, 고정된 ICMP ping 값은 아닙니다. 클라이언트마다 테스트 URL, 시간 제한, 동시 실행 설정이 다를 수 있습니다. 예를 들어 한 번의 테스트에서 85ms와 140ms가 나왔다면 해당 조건에서는 앞의 응답 시간이 더 짧았다는 뜻일 뿐, 동영상 전송 속도도 반드시 더 빠르다는 의미는 아닙니다. ‘시간 초과’는 테스트 주소 접속 불가, DNS 오류, 노드 핸드셰이크 실패 등으로 발생할 수 있으니 로그와 함께 확인하세요.

프로필 화면: 가져오기, 활성화, 업데이트는 별개의 작업입니다

프로필 화면에서는 구독 URL, 로컬 YAML 파일, 클라이언트가 제공하는 병합 또는 오버라이드 설정을 관리합니다. 처음 사용할 때는 유효한 설정 소스를 가져온 뒤 파싱이 끝날 때까지 기다리고, 해당 프로필이 현재 설정으로 표시되는지 확인하세요. 가져온 뒤 자동으로 활성화되는 클라이언트도 있고 프로필 카드나 ‘사용’을 직접 눌러야 하는 클라이언트도 있습니다. 현재 활성 표시와 프록시 화면에 나타난 실제 그룹 이름을 기준으로 확인하세요.

가져오기: ‘프로필’ 또는 Profiles로 이동해 URL에서 가져오거나 로컬 파일을 불러옵니다. 구독 주소에 액세스 토큰이 포함될 수 있으니 공개 스크린샷에 붙여 넣지 마세요.
활성화: 사용할 프로필을 선택하고 다시 불러오기가 끝날 때까지 기다립니다. 프록시 화면에서 해당 프로필에 정의된 정책 그룹이 표시되는지 확인하세요.
업데이트: 해당 구독을 업데이트하고 시간과 결과를 확인합니다. 새 내용을 다운로드한 뒤에도 설정 파싱이나 다시 불러오기가 실패했다는 알림이 없는지 살펴보세요.
되돌리기: 수정 전에 사용할 수 있는 로컬 사본을 보관하세요. 오류가 생기면 정상 작동이 확인된 설정을 먼저 복원하고 변경 사항을 하나씩 비교합니다.

구독 카드의 ‘남은 트래픽’과 ‘만료일’은 보통 서버가 반환하는 구독 정보를 표시합니다. 표시되지 않아도 클라이언트 프록시 기능에 문제가 있다는 뜻은 아닙니다. 사용량이 표시되어도 현재 연결이 반드시 작동하는 것은 아닙니다. 로컬 파일에는 대개 이런 서버 정보가 없으므로 파일 내용과 불러오기 상태를 확인하면 됩니다.

업데이트 때 덮어써지는 구독 내용을 직접 수정하지 마세요

원격 구독에서 다운로드한 YAML을 직접 편집하면 다음 업데이트에서 수정 사항이 덮어써질 수 있습니다. 규칙을 계속 추가해야 한다면 먼저 현재 클라이언트에서 오버라이드, 병합, 스크립트 처리 기능을 지원하는지 확인하고 어느 설정에 적용되는지도 살펴보세요. 클라이언트마다 처리 형식이 다르므로 다른 클라이언트용 스크립트를 그대로 붙여 넣지 마세요. 임시 테스트용으로 로컬 프로필에 복사할 수 있지만, 이 사본에는 원래 구독의 새 노드가 자동으로 추가되지 않습니다.

설정 화면: 포트, 시스템 프록시, TUN 확인

로컬 포트는 앱과 프록시 코어 사이의 진입점입니다. 예시 설정의 mixed-port: 7890은 같은 포트에서 HTTP 프록시와 SOCKS 연결을 모두 받는다는 뜻입니다. 설치 환경에 따라 다른 포트를 사용할 수 있으므로 현재 실행 설정을 기준으로 확인하세요. 프록시를 직접 입력할 때 호스트에는 127.0.0.1을, 포트에는 실제로 수신 중인 값을 넣어야 합니다. 구독 서버 주소를 로컬 프록시 호스트로 입력하면 안 됩니다.

설정 항목	확인 방법	흔한 오해
로컬 수신 포트	실행 설정에서 mixed-port 또는 개별 포트를 확인합니다.	모든 클라이언트의 기본 포트가 7890이라고 생각합니다.
시스템 프록시	켜고 나서 시스템 네트워크 프록시의 주소와 포트를 확인합니다.	스위치를 켜면 모든 앱에 적용된다고 생각합니다.
TUN	클라이언트 지원 여부, 권한 안내, 시작 로그를 확인합니다.	스위치가 켜지면 라우트가 정상적으로 설정된 것이라고 생각합니다.
LAN 연결 허용	다른 기기에서 접속해야 할 때만 설정합니다.	이 기기만 사용하는 경우에도 켜야 한다고 생각합니다.

Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 시스템 프록시를 확인할 수 있습니다. macOS 13 이후 버전에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스의 ‘세부사항’ → ‘프록시’에서 확인하세요. 관리되는 기기는 메뉴나 권한이 다를 수 있습니다. 클라이언트를 종료한 뒤에도 브라우저가 닫힌 로컬 포트를 가리키면 연결에 실패할 수 있습니다. 이때는 구독을 반복해서 업데이트하기보다 남아 있는 시스템 프록시 설정을 확인하세요.

TUN에는 보통 추가 시스템 권한, 서비스 구성 요소 또는 네트워크 확장이 필요하며, 구체적인 요구 사항은 클라이언트 구현과 운영 체제에 따라 다릅니다. 처음 문제를 확인할 때는 브라우저와 시스템 프록시로 기본 연결을 먼저 검증한 뒤 시스템 프록시를 따르지 않는 앱을 살펴보세요. TUN, DNS, 규칙을 동시에 바꾸면 원인을 찾기 어려워집니다.

연결 화면: 요청이 실제로 어떤 규칙에 매칭됐는지 확인

연결 화면은 프록시 화면과 로그 화면을 이어주는 확인 단계입니다. 대상 도메인 또는 IP, 업로드·다운로드량, 연결 시간, 매칭 규칙, 정책 체인이 표시되는 경우가 많습니다. 일부 클라이언트는 프로세스도 표시하지만, 권한과 플랫폼, 프로세스 검색 설정에 따라 사용할 수 있는지가 달라집니다. 프로세스 열이 비어 있어도 연결에 문제가 있다고 단정할 수 없습니다.

대상 기록이 없을 때: 요청을 다시 보내고 화면 필터가 해제되어 있는지 확인합니다. 그래도 기록이 없다면 앱의 트래픽이 프록시 진입점으로 들어오는지 살펴보세요.
기록에 DIRECT가 표시될 때: 매칭된 규칙을 확인해 의도한 직접 연결인지 살펴보세요. 노드가 선택되어 있다는 이유만으로 해당 요청이 프록시를 사용한다고 판단하지 마세요.
정책 체인은 맞지만 접속에 실패할 때: 해당 시간의 DNS, 핸드셰이크, 연결 오류를 확인하고 필요하면 특정 노드를 선택해 다시 테스트하세요.
노드를 바꿨는데도 출구가 그대로일 때: 기존 TCP 연결이나 장시간 연결은 이전 출구를 계속 사용할 수 있습니다. 테스트 연결을 종료하고 새로 연결한 뒤 전환 여부를 확인하세요.

브라우저에서 페이지 하나를 열어도 여러 도메인에 연결될 수 있습니다. 페이지 본문, 이미지, API가 각각 다른 규칙에 매칭될 수 있기 때문입니다. 문제를 확인할 때는 실제로 실패한 도메인을 기록하고, 한 건의 직접 연결 기록을 페이지 전체의 출구로 판단하지 마세요.

로그 화면: 수준으로 필터링하고 시간으로 오류 찾기

로그 화면에는 보통 수준 필터링, 키워드 검색, 자동 스크롤 일시 중지, 표시된 로그 지우기 기능이 있습니다. ‘화면에 표시할 로그 필터’와 ‘코어 로그 수준’을 구분해야 합니다. 화면 필터를 Debug로 바꿔도 코어가 이전에 기록하지 않은 디버그 정보가 다시 생기지는 않습니다. 클라이언트에서 실행 로그 수준을 설정할 수 있다면 해당 설정을 변경하거나 유효한 설정에서 log-level을 지정하세요.

수준	사용 상황	중점 확인 사항
info	일상적인 상태 확인과 기본 문제 해결	시작, 설정 불러오기, 일반 연결 정보
warning	완전히 실패하지는 않았지만 이상 징후가 있을 때	경고가 언급한 구성 요소와 이후 결과
error	명확한 실패 원인 확인	대상, 시간, 실패 단계와 원인
debug	복잡한 문제를 짧게 재현할 때	더 자세한 처리 과정 확인. 완료 후 info로 되돌리기

문제를 재현하기 전에 14:32:10처럼 시간을 기록한 다음, 대상 요청을 한 번만 보내고 그 전후 몇 초 동안 관련 도메인을 찾으세요. connection refused가 표시되면 연결 대상 주소에서 서비스를 수신 중인지 확인해야 합니다. timeout은 어떤 단계가 제한 시간 안에 완료되지 않았다는 뜻일 뿐이므로, 맥락을 살펴 DNS 조회, 연결, 핸드셰이크 중 어느 단계에서 발생했는지 판단하세요. 구독 요청 단계에서 401 또는 403이 로그에 나오면 분기 그룹을 바꾸기보다 구독 권한을 먼저 확인하세요.

최소 설정으로 필드와 화면 항목의 대응 관계 확인하기

아래는 화면을 이해하기 위한 로컬 예시입니다. 기본 필드를 지원하는 Clash 또는 mihomo 클라이언트에서 별도로 가져올 수 있습니다. 직접 연결만 설정되어 있으며 원격 노드는 포함하지 않으므로 실제 구독을 대체하지 않습니다. 테스트용 로컬 프로필을 새로 만들고 현재 사용 중인 구독을 덮어쓰지 마세요.

interface-demo.yaml

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 수동 출구
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,수동 출구

프로필 화면: 가져와서 활성화한 뒤 현재 설정이 이 로컬 예시인지 확인합니다.
프록시 화면: ‘수동 출구’ 그룹이 표시되고 선택 항목은 DIRECT 하나여야 합니다.
연결 화면: 코어에 들어온 새 요청은 마지막 MATCH 규칙에 따라 ‘수동 출구’로 전달되고, 최종적으로 직접 연결됩니다.
로그 화면: 기본 로그 수준은 info입니다. 클라이언트에서 전역 오버라이드를 사용하면 실제 실행 값은 파일과 다를 수 있습니다.

7890을 다른 프로세스가 사용 중이면 클라이언트 설정이나 테스트 파일에서 비어 있는 포트를 선택하고 앱의 프록시 설정도 같은 값으로 바꾸세요. 많은 GUI 클라이언트는 전역 설정과 구독 내용을 병합하므로 화면에 표시된 실제 수신 포트와 실행 모드를 다시 확인해야 합니다. 편집기에 보이는 원본 YAML만 확인해서는 안 됩니다.

처음 사용할 때 확인할 여섯 단계

코어 확인: 정상 실행 중인지, 시작 또는 설정 파싱 오류가 없는지 확인합니다.
프로필 확인: 구독을 가져온 뒤 현재 활성 항목을 확인하고 프록시 화면에 표시되는 그룹 이름도 살펴봅니다.
진입 경로 확인: 먼저 브라우저에서 시스템 프록시를 사용하고 실제 로컬 주소와 포트를 기록합니다.
선택 확인: Rule 모드에서 대상 규칙이 참조하는 그룹의 출구를 선택합니다.
연결 확인: 요청을 다시 보내 대상 도메인, 매칭 규칙, 최종 정책 체인을 확인합니다.
로그 확인: 같은 시간대의 오류를 찾고 설정을 한 번에 하나씩만 바꾼 뒤 다시 테스트합니다.

이 순서대로 확인하면 ‘프로필이 활성화되지 않음’, ‘앱 트래픽이 코어에 들어오지 않음’, ‘규칙에서 직접 연결을 선택함’, ‘출구 연결 실패’를 각각 구분해 처리할 수 있습니다. 설치나 권한 설정이 더 필요하다면 설정 가이드를 확인하세요. 정책 그룹, 규칙, TUN 등의 용어는 용어 빠른 안내에서 살펴볼 수 있습니다.