Clash 클라이언트 화면 가이드: 프록시·프로필·연결·로그 페이지 사용법

화면 구성: 프로필·선택 항목·실행 상태 구분하기

Clash 클라이언트는 그래픽 인터페이스와 프록시 코어가 함께 작동합니다. 인터페이스에서는 설정을 가져오고 옵션을 변경하며 상태를 확인하고, Clash 또는 Clash Meta(mihomo) 코어는 포트를 열고 규칙을 매칭해 연결을 처리합니다. 따라서 인터페이스가 열리는 것, 구독 업데이트 성공, 노드 연결 테스트 결과는 서로 다른 상태이며 같은 의미로 볼 수 없습니다.

클라이언트마다 사이드바의 메뉴 이름과 순서는 다릅니다. 데스크톱에서는 보통 ‘프록시’, ‘프로필’, ‘연결’, ‘규칙’, ‘로그’, ‘설정’이 보이고, 모바일에서는 일부 기능이 하단 탐색 메뉴나 하위 메뉴에 들어갈 수 있습니다. 아래 설명은 일반적인 기능 흐름을 따릅니다. 메뉴 경로는 기능을 찾기 위한 안내이며, 실제 메뉴명은 사용 중인 클라이언트에 따라 다를 수 있습니다. 특정 버전의 화면을 픽셀 단위로 설명하는 내용은 아닙니다.

페이지	주요 항목	먼저 확인할 내용
프록시 페이지	정책 그룹과 노드	현재 모드, 그룹에서 선택한 항목
프로필 페이지	구독, YAML, 오버라이드	활성 프로필, 업데이트 결과
연결 페이지	현재 처리 중인 연결	대상, 규칙, 프록시 체인
규칙 페이지	적용 중인 매칭 규칙	규칙 순서, 대상 정책
로그 페이지	코어 실행 이벤트	시간, 수준, 오류 위치
설정 페이지	트래픽 진입 경로와 클라이언트 옵션	시스템 프록시, TUN, 수신 포트

프록시 페이지: 노드 하나만 고르는 것이 아니라 정책 그룹도 선택하기

규칙·전역·직접 연결 모드

보통 ‘프록시’ → ‘모드’에서 설정합니다. 규칙 모드에서는 mode: rule에 따라 구성 파일의 규칙 순서대로 연결을 보낼 곳을 찾습니다. 전역 모드에서는 일반 연결이 전역 정책으로 전달되며, 보통 GLOBAL로 표시됩니다. 직접 연결 모드에서는 프록시를 거치지 않고 연결합니다. 모드는 트래픽을 분기하는 방식을 정하며, 시스템 프록시나 TUN처럼 앱 트래픽을 코어로 전달하는 기능을 대신하지 않습니다.

일반적으로 규칙 모드를 선택한 뒤 규칙에서 참조하는 정책 그룹을 확인합니다. 예를 들어 규칙이 특정 도메인을 ‘웹 연결’ 그룹으로 보내는데 ‘다운로드 연결’ 그룹만 바꿨다면, 해당 도메인의 새 연결은 여전히 기존 노드를 사용할 수 있습니다. 변경이 적용됐는지 확인할 때는 노드 카드의 강조 표시만 볼 것이 아니라 실제로 매칭된 그룹을 확인해야 합니다.

정책 그룹 유형에 따라 버튼의 기능이 달라집니다

select: 노드나 하위 정책 그룹을 직접 선택합니다. 출구를 지정하고 싶을 때 적합합니다.
url-test: 설정된 테스트 주소와 주기에 따라 후보를 평가하고, 허용 오차 등의 옵션을 반영해 출구를 선택합니다. 다운로드 속도 순위와는 다릅니다.
fallback: 대개 후보 순서에 따라 사용 가능한 항목을 선택합니다. 지연 시간이 가장 짧은 항목을 항상 고르는 방식이 아니라 장애 전환에 중점을 둡니다.
load-balance: 설정된 정책에 따라 연결을 분배합니다. 일반적인 다운로드 연결 하나에 모든 노드의 대역폭을 합친다는 뜻은 아닙니다.

그룹에는 DIRECT, REJECT 또는 다른 정책 그룹이 표시될 수도 있습니다. 각각 직접 연결, 연결 거부, 다음 단계 그룹에 선택을 넘긴다는 뜻이며, 모두 실제 서버를 가리키는 것은 아닙니다. 속도 테스트 버튼에 표시되는 밀리초 값은 지정된 테스트 대상에 한 번 연결해 본 결과입니다. 예를 들어 80ms와 160ms는 해당 테스트 조건에서 비교할 수 있을 뿐, 동영상 전송 속도를 의미하지 않습니다. 여기의 수치는 화면 읽는 법을 보여주는 예시이며 실제 측정 결과가 아닙니다.

프로필 페이지: 가져오기·업데이트·활성화는 각각 다른 작업

보통 ‘프로필’ → ‘가져오기’ 또는 ‘새로 만들기’에서 시작합니다. 원격 구독은 구독 주소를 입력하고, 로컬 프로필은 YAML 파일을 선택합니다. 가져오기는 프로필 항목을 등록하는 작업이고, 업데이트는 내용을 다시 가져오는 작업이며, 활성화는 코어가 해당 프로필을 불러오게 하는 작업입니다. 가져온 뒤 자동으로 활성화하는 클라이언트도 있고 프로필 카드를 눌러야 하는 클라이언트도 있습니다. 목록에 이름이 보인다는 이유만으로 전환이 완료됐다고 판단하지 마세요.

프로필을 가져온 뒤 확인할 네 가지

콘텐츠 형식: 브라우저에서 열리는 주소라고 해서 반드시 Clash YAML을 반환하는 것은 아닙니다. 로그인 페이지, 오류 안내 또는 다른 클라이언트용 형식이면 파싱에 실패할 수 있습니다.
활성 상태: 원하는 프로필이 선택되거나 강조 표시되어 있는지 확인한 다음, 프록시 페이지에 예상한 정책 그룹이 나타나는지 살펴보세요.
업데이트 시간: 업데이트 성공은 클라이언트가 새 콘텐츠를 가져왔다는 뜻이지, 모든 노드의 연결을 보장한다는 뜻은 아닙니다.
오류 메시지: 다운로드 실패, YAML 문법 오류, 코어에서 지원하지 않는 필드는 각각 원인과 해결 방법이 다릅니다.

구독 주소에는 보통 접근 인증 정보가 포함되므로 비밀번호처럼 취급해야 합니다. 화면을 공유할 때는 전체 주소와 QR 코드, 토큰을 가리고 공개 문의 게시판에 올리지 마세요. 일부 클라이언트에 표시되는 트래픽 한도와 만료일은 서버 응답 헤더에서 가져옵니다. 해당 값이 보이지 않는다고 해서 가져오기에 실패한 것은 아닐 수 있습니다.

원본 프로필 편집과 오버라이드의 차이

원격 프로필을 업데이트하면 직접 수정한 내용이 덮어써질 수 있습니다. 로컬 규칙, DNS, 포트 설정을 계속 유지하려면 클라이언트의 ‘오버라이드’, ‘병합’ 또는 스크립트 기능을 우선 사용하고, 어떤 프로필에 적용되는지 확인하세요. 병합 순서는 클라이언트마다 다르므로 편집기의 원본 YAML만 보고 실제 적용 값을 판단할 수 없습니다.

# 안내용 예시: 필드의 의미를 보여주는 조각이며, 완전한 구독 설정이 아닙니다
mixed-port: 7890
mode: rule
log-level: info
allow-lan: false

여기서 7890은 HTTP와 SOCKS 프록시 연결을 모두 받을 수 있는 혼합 수신 포트의 예시이며, 모든 클라이언트의 기본값은 아닙니다. 저장한 뒤 ‘실행 설정 보기’와 같은 메뉴가 있다면 그곳에서 최종 적용 값을 확인하세요. 필드 설명은 YAML 설정 핸드북을 참고하세요. 이 조각을 그대로 완전한 연결 설정으로 사용해서는 안 됩니다.

연결 페이지: 요청이 어떤 출구를 거쳤는지 확인하기

연결 페이지에서는 코어에 들어온 트래픽을 확인할 수 있습니다. 일반적으로 대상 호스트, 대상 IP, 포트, 업로드·다운로드 바이트 수, 연결 시간, 매칭 규칙, 프록시 체인이 표시됩니다. 프로세스 이름 표시 여부는 시스템 권한, 코어 기능, 프로세스 식별 설정에 따라 달라집니다. 이름이 비어 있다고 해서 트래픽에 문제가 있다는 뜻은 아닙니다.

연결 한 건으로 처리 경로 확인하기

‘연결’ 페이지를 열고 대상 도메인이나 프로세스로 필터링합니다. 백그라운드 트래픽을 줄이려면 테스트할 사이트 하나만 방문하세요.
대상 포트를 확인합니다. HTTPS는 보통 443을 사용하지만, 포트만으로 프록시를 거쳤는지 판단할 수는 없습니다.
DOMAIN-SUFFIX, IP-CIDR 또는 기본 규칙인 MATCH 등 어떤 규칙이 적용됐는지 확인합니다.
프록시 체인을 확인해 최종 경로가 DIRECT인지, 지정한 노드인지, 중첩된 정책 그룹을 거치는지 살펴봅니다.
그룹에서 선택한 항목을 바꾼 뒤 새 연결을 만들고 프록시 체인이 달라졌는지 비교합니다.

페이지에 대상 앱의 연결이 나타나지 않으면 노드를 바꾸기 전에 앱 트래픽이 프록시에 들어오는지부터 확인하세요. 앱이 시스템 프록시 설정을 따르지 않거나 자체 프록시 설정을 사용하거나, 시스템 우회 목록에 포함됐거나, TUN 경로가 대상 트래픽을 포함하지 않을 수 있습니다. 연결 페이지에는 코어가 처리한 연결만 표시되므로 시스템 전체의 트래픽 모니터로 볼 수는 없습니다.

‘연결 닫기’는 선택한 세션을 끊으며 앱이 자동으로 다시 연결할 수 있습니다. ‘모두 닫기’는 다운로드 중인 파일, 회의, 장시간 연결 서비스에 영향을 줄 수 있으므로 필터링한 대상 연결만 닫는 편이 좋습니다. 페이지에 표시되는 누적 트래픽은 대개 현재 실행 중이거나 현재 통계 기준에 따른 값이며, 구독 서비스의 청구 내역과는 다릅니다.

규칙 페이지: 직접 연결되거나 프록시를 거치는 이유 확인하기

규칙 페이지는 보통 실행 중인 상태를 보여주는 화면이며, 직접 편집할 수 없는 경우도 있습니다. 규칙은 순서대로 매칭되며 먼저 일치한 규칙이 처리 대상을 결정합니다. 더 구체적인 규칙이 포괄적인 규칙 뒤에 있으면 적용되지 않을 수 있습니다. 아래 예시는 예약된 테스트 도메인을 사용해 규칙 순서와 정책 참조를 보여줍니다.

rules:
  - DOMAIN-SUFFIX,example.com,웹 연결
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,웹 연결

전체 설정에 웹 연결 정책 정의가 있어야 합니다. no-resolve는 해당 IP 규칙을 처리하면서 도메인 조회를 새로 시도하지 않는다는 뜻이지, 클라이언트의 DNS 기능 전체를 끈다는 뜻은 아닙니다. 마지막의 MATCH는 기본 규칙입니다. 목록 앞쪽에 배치하면 뒤에 있는 일반 규칙은 매칭될 수 없습니다.

설정에서 rule-providers를 사용하는 경우 기본 규칙 목록과 외부 규칙 집합을 구분해야 합니다. 규칙 집합 다운로드 실패, 콘텐츠 미갱신, 규칙 순서 오류는 화면에서 비슷하게 보일 수 있습니다. 전역 모드로 계속 바꾸기보다는 먼저 연결 상세 정보에서 실제 매칭 항목을 확인하고, 프로필 페이지에서 규칙 출처를 살펴보는 편이 원인을 찾기 쉽습니다.

로그 페이지: 한 줄씩 짐작하지 말고 시간대별로 오류 찾기

보통 ‘로그’ → ‘수준 필터’에서 확인합니다. 코어 로그의 일반적인 수준은 debug, info, warning, error이며 클라이언트에 따라 한글로 표시될 수 있습니다. 필터는 현재 화면에 보이는 항목만 바꿉니다. log-level을 변경해야 코어가 어떤 수준의 로그를 생성할지 달라지므로 두 설정은 서로 다릅니다.

자주 보이는 로그 메시지	확인할 내용	다음 단계
`address already in use`	로컬 수신 주소나 포트가 이미 사용 중임	다른 클라이언트나 백그라운드 코어가 실행 중인지 확인
`connection refused`	연결 요청이 거부됨	오류가 발생한 대상을 확인한 뒤 서비스 상태와 포트를 점검
`i/o timeout`	네트워크 작업 시간 초과	DNS 조회, 노드 연결, 대상 연결 중 어느 단계인지 구분
`no such host`	이름 조회 결과를 받지 못했거나 유효한 결과가 없음	해당 도메인과 DNS 설정 확인
`certificate`	TLS 인증서 검증 오류일 수 있음	시스템 시간, 서버 이름, 인증서 정보 확인

효율적으로 문제를 찾으려면 먼저 작업 시간을 기록한 뒤 같은 동작을 한 번 재현하세요. 예를 들어 14:32:10에 요청했다면 그 시각 전후의 로그를 확인해 오류 대상이 구독 서버인지, 프록시 노드인지, 목적지 사이트인지 구분합니다. timeout 한 줄만 캡처하면 판단에 필요한 앞뒤 상황이 빠지는 경우가 많습니다.

설정 페이지: 시스템 프록시·TUN·포트의 역할

시스템 프록시는 앱 트래픽의 진입 경로

보통 ‘설정’ → ‘시스템 프록시’에서 찾을 수 있으며, 일부 클라이언트는 홈 화면에 스위치를 둡니다. 이 기능은 대개 운영체제의 프록시 주소를 로컬 수신 포트(예: 127.0.0.1:7890)로 지정합니다. 시스템 프록시 설정을 따르는 앱만 이 경로로 트래픽을 보냅니다. 스위치가 켜져 있어도 모든 프로그램이 코어에 연결됐다고 볼 수는 없습니다.

외부 프로그램에 프록시 주소를 직접 입력해야 한다면 클라이언트에 표시된 실제 포트를 사용하세요. HTTP 전용, SOCKS 전용, 혼합 포트는 서로 다를 수 있습니다. 패널의 external-controller API 주소를 브라우저 프록시 입력란에 넣지 마세요. 이 주소는 제어 인터페이스이지 트래픽 프록시 진입점이 아닙니다.

TUN은 가상 네트워크 인터페이스이지 별도의 노드가 아닙니다

데스크톱에서는 보통 ‘설정’ → ‘TUN 모드’에서 찾을 수 있으며, 시작할 때 관리자 권한이나 서비스 지원이 필요할 수 있습니다. TUN은 가상 인터페이스와 라우팅을 통해 IP 트래픽을 처리하지만, 실제 적용 범위는 자동 라우팅, 제외 경로, DNS 가로채기, 시스템 환경에 따라 달라집니다. 모바일은 시스템 VPN 인터페이스를 이용하는 경우가 많아 스위치 위치와 구성 방식이 데스크톱과 다릅니다.

시스템 프록시는 작동하지만 일부 앱은 작동하지 않음: 먼저 앱이 시스템 프록시를 지원하는지 확인한 뒤 TUN이 필요한지 검토하세요.
TUN을 켠 뒤 로컬 네트워크 접속에 문제가 생김: 로컬 네트워크 제외 경로, DNS, 다른 VPN과의 충돌을 확인하세요. 노드만 바꾸지 마세요.
LAN 허용: allow-lan은 다른 기기가 프록시 수신 서비스에 연결할 수 있는지를 제어합니다. 이 옵션이 로컬 기기에서 LAN 장치에 접속하는 기능을 뜻하는 것은 아닙니다.
시작 시 실행과 시작 후 프록시 활성화: 별개의 설정일 수 있으므로 하나를 구성한 뒤 다른 설정도 확인해야 합니다.

클라이언트를 바꿔야 한다면 클라이언트별 비교에서 운영체제와 기능을 비교해 보세요. 여러 클라이언트의 시스템 프록시와 TUN을 동시에 켠 상태에서 특정 클라이언트의 동작을 판단하지 마세요. 트래픽 진입 경로를 하나만 남겨야 문제를 같은 조건에서 재현하기 쉽습니다.

처음 사용할 때: 화면을 확인하는 6단계

프로필 페이지: 사용할 Clash YAML 또는 구독을 가져오고, 업데이트 성공 여부를 확인한 뒤 활성화합니다.
프록시 페이지: 규칙 모드를 선택하고, 규칙에서 실제로 참조하는 정책 그룹을 찾아 사용 가능한 출구를 선택합니다.
설정 페이지: 코어 실행 여부, 실제 수신 포트, 시스템 프록시 또는 TUN 진입 상태를 확인합니다.
연결 페이지: 대상 사이트에 접속한 뒤 새 연결의 대상, 매칭 규칙, 프록시 체인을 확인합니다.
로그 페이지: 요청이 실패하면 발생 시각 전후의 로그를 확인하고 오류와 관련된 설정 하나만 조정합니다.
프로필 페이지 재확인: 구독을 업데이트한 뒤 로컬 오버라이드와 활성 프로필을 점검해 변경 사항이 여전히 적용되는지 확인합니다.

이 6단계는 ‘프로필이 불러와졌는지’, ‘트래픽이 들어오는지’, ‘규칙이 매칭됐는지’, ‘출구에 연결할 수 있는지’를 따로 확인하는 방법입니다. 프록시 페이지는 정상인데 웹사이트가 열리지 않거나 노드를 바꾼 뒤에도 출구가 그대로인 것 같다면 해당 페이지로 돌아가 확인하세요. 서로 다른 단계의 문제를 한 번에 섞어 처리하지 않을 수 있습니다.