Clash 클라이언트 UI 한눈에 보기: 프록시·구성·로그 페이지의 역할

먼저 이해해야 할 클라이언트의 4단 구조

Clash 그래픽 클라이언트는 이름과 배치가 서로 달라도 핵심 정보는 대체로 네 층으로 나뉩니다. 구성은 사용할 프록시 노드와 규칙을 정하고, 프록시 페이지는 정책 그룹의 현재 출구를 선택하며, 연결 페이지는 코어를 통과 중인 세션을 보여 줍니다. 로그 페이지는 코어가 해당 세션을 처리한 과정을 기록합니다. 시스템 프록시, TUN 모드, 포트 설정은 더 낮은 계층에서 기기 트래픽을 Clash 또는 mihomo 코어로 전달합니다.

mihomo 코어를 사용하는 데스크톱 클라이언트를 예로 들면 왼쪽에 보통 ‘개요’, ‘프록시’, ‘구성’, ‘연결’, ‘로그’, ‘설정’이 표시됩니다. 일부 클라이언트는 구성을 ‘구독’, 프록시를 ‘정책’이라고 부르며, 코어 설정을 별도의 ‘서비스’ 페이지에 넣기도 합니다. 명칭은 달라도 데이터 흐름은 대체로 같습니다.

개요 페이지는 ‘트래픽이 들어오는지’ 확인하기 좋습니다

개요 페이지에는 보통 코어 상태, 업로드 속도, 다운로드 속도, 활성 연결 수, 메모리 사용량이 표시됩니다. 시스템 프록시를 켠 뒤 새 웹페이지에 접속했을 때 연결 수가 0에서 6으로 늘고 다운로드 속도가 잠시 320KB/s로 표시된다면, 적어도 일부 트래픽이 코어에 유입된 것입니다. 다만 이 현상만으로 원격 프록시 노드가 정상이라고 단정할 수는 없습니다.

개요 페이지가 계속 0B/s라면 노드를 반복해서 바꾸기보다 먼저 시스템 프록시 스위치와 수신 포트를 확인하세요. 개요 페이지에 트래픽이 표시되는데도 웹페이지가 열리지 않는다면 프록시·연결·로그 페이지에서 노드 시간 초과, DNS 실패, 규칙 오매칭을 확인합니다.

프록시 페이지: 정책 그룹과 노드는 서로 다른 계층입니다

프록시 페이지는 가장 오해하기 쉬운 곳입니다. 화면의 큰 카드는 대개 정책 그룹이며, 그룹을 펼쳤을 때 나오는 항목이 노드 또는 다른 정책 그룹입니다. 구성 파일은 proxy-groups로 이러한 관계를 정의합니다. 규칙은 보통 특정 노드를 직접 지정하지 않고 정책 그룹 이름을 가리킵니다.

예를 들어 한 규칙이 트래픽을 ‘노드 선택’으로 보내고, 이 정책 그룹에서 현재 ‘자동 선택’을 골랐으며, ‘자동 선택’이 지연 시간 테스트를 통해 ‘도쿄 02’를 골랐다고 해 보겠습니다. 실제 경로는 ‘노드 선택 → 자동 선택 → 도쿄 02’로 표시됩니다. 연결 상세 정보에 여러 단계의 경로가 보이는 것은 정상입니다.

자주 쓰이는 정책 그룹 유형

• 수동 선택: select에 해당하며 사용자가 노드 또는 하위 정책 그룹을 지정합니다. 선택은 구성을 다시 불러오거나 선택 항목이 무효화되거나 클라이언트가 상태를 초기화할 때까지 유지됩니다.
• 자동 속도 측정: url-test에 해당하며 테스트 주소와 간격에 따라 노드를 측정하고, 일반적으로 지연 시간이 낮으면서 테스트에 성공한 결과를 선택합니다.
• 장애 조치: fallback에 해당하며 목록에서 앞에 있고 상태 확인을 통과한 노드를 우선 사용합니다.
• 로드 밸런싱: load-balance에 해당하며 구성된 정책에 따라 사용 가능한 여러 노드에 연결을 분산합니다.
• 직접 연결 및 거부: DIRECT는 대상에 직접 연결하고, REJECT는 일치한 트래픽을 차단합니다.

지연 시간 수치는 어떻게 읽어야 할까요

노드 오른쪽의 38ms, 126ms 또는 Timeout은 보통 한 번의 HTTP 상태 확인 결과입니다. 전체 웹페이지 로딩 시간이나 ICMP Ping과는 다릅니다. 테스트에는 구성의 테스트 URL과 클라이언트 구현에 따라 DNS, TCP, TLS, HTTP 응답 시간이 포함될 수 있습니다.

노드를 안전하게 바꾸는 순서

1. 프록시 페이지에서 규칙이 실제로 참조하는 주 정책 그룹(예: ‘노드 선택’ 또는 ‘프록시’)을 찾습니다.
2. 먼저 지연 시간 테스트를 실행해 Timeout으로 표시된 노드를 제외합니다.
3. 한 번의 테스트에서 가장 작은 숫자만 보지 말고 지연 시간이 안정적인 노드를 선택합니다.
4. 새 브라우저 탭을 열어 기존 연결이 원래 경로를 계속 재사용하지 않게 합니다.
5. 연결 페이지에서 새 연결의 정책 경로에 방금 선택한 노드가 포함되어 있는지 확인합니다.

구성 페이지: 구독, 로컬 파일, 현재 구성

구성 페이지는 코어에 입력되는 설정을 관리합니다. 완전한 구성에는 보통 포트, DNS, 프록시 노드, 정책 그룹, 규칙이 포함됩니다. 구독 URL은 구성 출처 중 하나이고 로컬 YAML 파일은 또 다른 출처입니다. 구독을 클라이언트에 추가했다는 것은 구성 항목이 저장됐다는 뜻일 뿐입니다. 현재 구성으로 지정하고 정상적으로 불러와야 프록시 페이지에 해당 정책 그룹이 표시됩니다.

구성 카드의 정보는 무엇을 의미하나요

• 구성 이름: 출처를 식별하기 위한 이름으로, 클라이언트가 자동으로 만든 이름을 사용하거나 직접 바꿀 수 있습니다.
• 업데이트 시간: 구성을 마지막으로 성공적으로 가져오거나 저장한 시각입니다. 그때 모든 노드가 사용 가능했다는 뜻은 아닙니다.
• 업데이트 간격: 클라이언트가 구독을 다시 가져오는 주기입니다. 6시간, 12시간, 24시간 설정이 흔합니다.
• 현재 표시: 코어가 현재 사용 중인 구성을 뜻합니다. 카드를 선택했더라도 불러오지 않았다면 상태가 바뀌지 않을 수 있습니다.
• 트래픽 정보: 일부 구독 응답 헤더에는 사용량, 총량, 만료 시간이 포함됩니다. 정보가 제공되지 않으면 클라이언트에 표시할 수 없습니다.

일반적인 경로는 ‘구성’ → ‘새로 만들기’ → ‘URL에서 가져오기’입니다. 구독 주소를 붙여 넣고 저장한 다음 구성 카드 메뉴에서 ‘현재 구성으로 설정’ 또는 ‘활성화’를 선택합니다. 클라이언트에 따라 ‘구독’ → ‘구독 추가’로 표시되기도 합니다. 업데이트할 때는 카드를 계속 삭제하고 다시 가져오기보다 카드의 업데이트 버튼을 사용하세요.

로컬 YAML 구성은 세밀한 제어에 적합합니다

로컬 파일에서는 필드를 직접 확인하고 수정할 수 있습니다. YAML은 공백으로 계층을 표현하므로 Tab 들여쓰기나 잘못된 계층 때문에 불러오기에 실패할 수 있습니다. 다음은 UI 간 관계를 설명하기 위한 간단한 구조입니다. 포트, 정책 그룹, 규칙은 각각 설정 페이지, 프록시 페이지, 연결 상세 정보에 대응합니다.

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: example-node
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - example-node
      - DIRECT

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

mixed-port: 7890은 HTTP와 SOCKS 인바운드가 7890 포트를 함께 사용할 수 있음을 뜻합니다. mode: rule은 규칙에 따라 연결을 처리한다는 의미입니다. 마지막의 MATCH,DIRECT는 앞선 규칙이 모두 일치하지 않을 때 직접 연결하는 기본 규칙입니다. 실제 구독 구성에는 보통 DNS, 규칙 집합, provider, 추가 정책 그룹도 포함됩니다.

구성을 업데이트하면 선택 항목이 바뀌는 이유

구독 업데이트로 노드가 추가·삭제되거나 이름이 바뀔 수 있습니다. 정책 그룹에서 이전에 선택한 노드가 더 이상 존재하지 않으면 코어는 그룹 내 사용 가능한 항목으로 돌아갑니다. 구체적인 결과는 클라이언트의 상태 저장 방식과 정책 그룹 유형에 따라 달라집니다. 프록시 페이지가 갑자기 ‘도쿄 02’에서 ‘자동 선택’으로 바뀌었다고 해서 스위치가 고장 난 것은 아닙니다. 새 구성에 같은 이름의 노드가 없을 수도 있습니다.

업데이트 후에는 세 곳을 확인하세요. 구성 페이지에서 업데이트 시간이 바뀌었는지, 프록시 페이지에서 정책 그룹 내용이 새로 고쳐졌는지, 로그 페이지에서 구성 다시 불러오기에 오류가 없는지 확인합니다. ‘다운로드 성공’만으로는 충분하지 않습니다. 다운로드 완료와 코어 로드는 서로 다른 단계이기 때문입니다.

연결 페이지: 특정 프로그램이 실제로 어디로 나가는지 확인

연결 페이지는 트래픽 분할 결과를 가장 직접적으로 확인할 수 있는 곳입니다. 각 기록에는 보통 출발지 주소, 대상 도메인 또는 IP, 네트워크 유형, 업로드·다운로드량, 적용 규칙, 정책 경로, 연결 수립 시간이 포함됩니다. 브라우저가 페이지 하나를 열 때 수십 개의 연결을 동시에 만들 수 있으므로 목록 상단만 보지 말고 도메인 필터를 함께 사용하세요.

중점적으로 확인할 4개 필드

1. Host 또는 대상 주소: 해당 기록이 테스트 중인 웹사이트인지 확인합니다. IP만 표시된다면 DNS 해석 방식이나 애플리케이션 프로토콜이 도메인을 제공하지 않았을 수 있습니다.
2. Rule: DomainSuffix, GeoIP, RuleSet 또는 마지막 기본 규칙 등 적용된 규칙을 표시합니다.
3. Chains: 정책 그룹에서 최종 노드까지의 선택 경로를 보여 줍니다. 예: ‘노드 선택 → 홍콩 01’.
4. Process: 시스템과 권한이 허용하면 프로세스 이름을 표시합니다. TUN 모드에서 프로세스를 식별할 수 있는지는 플랫폼과 클라이언트 구현에 따라 달라집니다.

example.com에 접속한 뒤 연결 상세 정보에 규칙이 DomainSuffix, 정책 경로가 ‘노드 선택 → 싱가포르 03’으로 표시된다면 이 새 연결이 도메인 규칙에 따라 지정된 정책 그룹으로 들어가 최종적으로 싱가포르 03을 사용했다는 뜻입니다. 정책 경로가 DIRECT라면 규칙 순서, 실행 모드, 구성 전환 여부를 확인하세요.

기존 연결은 계속 이전 노드를 사용할 수 있습니다

정책 그룹을 바꿔도 이미 수립된 TCP 연결이 강제로 이동하지는 않습니다. 브라우저가 HTTP/2 또는 HTTP/3 세션을 재사용할 수도 있으므로 노드를 바꾼 직후 페이지를 새로 고쳐도 연결 페이지에 잠시 이전 경로가 표시될 수 있습니다. 해당 연결을 닫거나 새 시크릿 창을 열고, 기존 세션이 종료된 뒤 다시 테스트하세요. ‘모든 연결 닫기’를 사용하면 진행 중인 다운로드와 다른 네트워크 작업이 중단되므로 주의해야 합니다.

로그 페이지: 레벨과 키워드로 오류 찾기

로그 페이지에는 코어의 실행 과정이 기록됩니다. 정상적으로 접속할 때는 연결, 규칙 매칭, 아웃바운드 정보가 보이고, 구성이나 네트워크에 문제가 생기면 파싱 실패, 연결 거부, 시간 초과, TLS 핸드셰이크 실패 등이 기록될 수 있습니다. 로그가 많다면 먼저 레벨로 필터링한 다음 도메인, 포트, 정책 그룹 이름을 검색하세요. 한 줄씩 스크롤하는 것보다 효율적입니다.

자주 발생하는 오류 3가지

• connection refused: 대상 포트가 연결을 명확히 거부했습니다. 노드 서비스가 수신 대기 중이 아니거나 주소가 잘못됐거나, 로컬에서 연결하려는 제어 포트가 실행되지 않았을 수 있습니다.
• i/o timeout: 제한 시간 안에 읽기 또는 쓰기를 완료하지 못했습니다. DNS, TCP 연결 수립, TLS 핸드셰이크, 원격 응답 중 어느 단계인지 추가로 구분해야 합니다.
• address already in use: 수신 포트를 다른 프로세스가 이미 사용 중입니다. 혼합 포트가 7890이라면 다른 프록시 클라이언트가 7890을 사용하고 있지 않은지 확인하세요.

문제를 확인할 때는 먼저 현재 로그를 지우고 Info 레벨을 켠 다음 문제를 한 번만 재현하세요. 예를 들어 로그를 지운 뒤 대상 도메인에 접속하고 5초간 기다린 다음 스크롤을 멈추고 해당 도메인을 검색합니다. 이렇게 하면 이전 기록과 백그라운드 앱 연결이 판단을 방해하는 것을 줄일 수 있습니다. Info만으로 부족할 때 Debug로 임시 전환하세요. Debug를 계속 켜 두면 로그 양이 크게 늘어납니다.

설정 페이지: 시스템 프록시, TUN, 포트는 각각 다른 계층을 담당합니다

설정 페이지는 트래픽이 코어로 들어오는 방식을 결정합니다. 시스템 프록시는 운영체제의 HTTP, HTTPS 또는 SOCKS 프록시 설정을 변경하며 시스템 프록시를 따르는 브라우저와 데스크톱 앱에 적합합니다. TUN 모드는 가상 네트워크 인터페이스를 만들어 더 넓은 범위의 트래픽을 처리합니다. 시스템 프록시 설정을 읽지 않는 앱도 가로챌 수 있지만, 필요한 시스템 권한과 올바른 라우팅·DNS 구성이 필요합니다.

포트 필드를 혼동하지 마세요

• Mixed Port: 혼합 프록시 포트입니다. 일반적인 값은 7890이며 HTTP와 SOCKS 연결을 모두 받을 수 있습니다.
• HTTP Port: HTTP 프록시에만 사용됩니다. 일부 구성에서는 7890을 사용합니다.
• SOCKS Port: SOCKS5 프록시에만 사용되며 기존 구성에서는 7891이 흔합니다.
• External Controller: 그래픽 UI 또는 Dashboard가 코어를 제어할 때 사용합니다. 흔한 주소 형식은 127.0.0.1:9090입니다. 브라우저 프록시 포트가 아닙니다.

클라이언트가 혼합 포트 7890을 사용한다면 터미널 프로그램의 HTTP 프록시는 보통 제어 포트 9090이 아니라 http://127.0.0.1:7890을 가리켜야 합니다. 구체적인 값은 현재 구성과 설정 페이지를 기준으로 확인하세요. 포트를 변경한 뒤에는 시스템 프록시 주소, 브라우저 수동 프록시, 터미널 환경 변수도 함께 업데이트해야 합니다.

시스템 프록시와 TUN 중 무엇을 선택할까요

처음 사용할 때는 시스템 프록시를 먼저 켜 기본 경로를 확인하는 것이 좋습니다. 브라우저에서 트래픽이 발생하고, 프록시 페이지에서 노드를 사용할 수 있으며, 연결 페이지에서 규칙 매칭이 보인다면 구성과 출구가 대체로 정상입니다. 특정 앱이 시스템 프록시를 따르지 않을 때 TUN을 고려하세요. 이렇게 하면 ‘노드를 사용할 수 없음’과 ‘TUN 라우팅 이상’을 나누어 처리할 수 있습니다.

일부 데스크톱 클라이언트는 TUN을 안정적인 권한으로 활성화하려면 먼저 서비스 모드를 설치해야 합니다. 일반적인 경로는 ‘설정’ → ‘서비스 모드’ → ‘설치’로 이동한 뒤 ‘설정’ → ‘TUN 모드’로 돌아와 켜는 방식입니다. 실제 경로는 클라이언트 버전에 따라 다릅니다. 활성화한 뒤에는 새 가상 네트워크 어댑터가 나타났는지, DNS가 해석되는지, 로컬 네트워크와 로컬 개발 서비스에 계속 정상적으로 접근할 수 있는지 확인하세요.

10분 만에 UI 점검 완료하기

처음 구성을 가져온 뒤에는 정해진 순서로 점검할 수 있습니다. 구성 출처에서 시작해 노드 선택과 트래픽 유입 경로를 확인하고, 마지막으로 연결과 로그에서 결과를 검증하는 순서라 여러 페이지를 반복해서 오갈 필요가 줄어듭니다.

1. 1분차: 구성 페이지를 열어 구독 또는 로컬 파일이 존재하고 현재 구성으로 표시되어 있는지 확인합니다.
2. 2분차: 한 번 업데이트하고 업데이트 시간이 바뀌었으며 구성 파싱 알림이 없는지 확인합니다.
3. 3~4분차: 프록시 페이지에서 주 정책 그룹의 지연 시간 테스트를 실행하고, 연속 두 번 안정적으로 응답한 노드를 선택합니다.
4. 5분차: 설정 페이지에서 코어 실행 여부와 혼합 포트 및 시스템 프록시 주소의 일치 여부를 확인합니다.
5. 6분차: 시스템 프록시를 켜고 새 브라우저 창에서 테스트 페이지에 접속합니다.
6. 7~8분차: 연결 페이지에서 대상 도메인으로 필터링하고 적용 규칙과 최종 노드를 확인합니다.
7. 9분차: 개요 페이지로 돌아가 연결 수와 업로드·다운로드 트래픽이 변했는지 확인합니다.
8. 10분차: 로그 페이지에서 Warning과 Error를 필터링해 포트, DNS, 시간 초과 오류가 계속 발생하지 않는지 확인합니다.

문제가 생기면 현상에 맞는 페이지로 돌아가세요

UI를 이해하면 문제 해결 흐름은 한 줄로 정리할 수 있습니다. 구성 페이지에서 ‘무엇을 불러왔는지’, 프록시 페이지에서 ‘무엇을 선택했는지’, 설정 페이지에서 ‘트래픽이 어떻게 들어오는지’, 연결 페이지에서 ‘실제로 어디로 갔는지’, 로그 페이지에서 ‘왜 성공하거나 실패했는지’를 확인하면 됩니다. 이 다섯 가지 질문은 다섯 페이지에 대응하며, 대부분의 첫 연결 문제를 다룹니다.