제어판은 Clash의 내부 상태를 들여다보는 창입니다. "왜 안 열리지?"라는 질문의 답은 패널을 잠깐 열어보는 것만으로 찾을 수 있는 경우가 많습니다. 이 글은 페이지별로 하나씩 다룹니다. 프록시, 연결, 로그 페이지가 각각 어떤 문제를 해결해 주는지 살펴보겠습니다.
패널은 어디서 열까
데스크톱 클라이언트에는 보통 패널 진입점이 기본으로 들어 있습니다. 커맨드라인 코어를 직접 돌린다면 설정 파일에 아래 항목이 있는지 확인하고, 브라우저로 원하는 웹 패널(yacd, metacubexd 등)에 접속하면 됩니다.
external-controller: 127.0.0.1:9090 secret: "your-api-secret" # set one if exposed to LAN
프록시 페이지: 지연 시간 숫자 읽는 법
정책 그룹의 번개 아이콘을 누르면 전체 노드 속도 테스트가 한 번에 실행됩니다. 지연 시간 색상이 의미하는 바는 다음과 같습니다.
- 초록색(200ms 미만): 상태가 좋습니다. 웹서핑, 영상 시청 모두 문제없습니다.
- 노란색(200~500ms): 쓸 수는 있지만 다소 느립니다. 게임이나 영상 회의에서는 끊김이 눈에 띌 수 있습니다.
- 빨간색 / 타임아웃: 현재 사용할 수 없는 노드입니다. 선택하지 마세요.
주의할 점은, 여기서 측정하는 지연 시간은 "내 기기 → 노드 → 테스트 대상 서버"로 이어지는 전체 경로라는 것입니다. 단순 ping 값이 아닙니다. 같은 노드라도 측정 시점에 따라 값이 크게 달라질 수 있고, 사용자가 몰리는 시간대에는 전반적으로 높게 나오는 게 정상입니다.
연결 페이지: 누가 트래픽을 몰래 쓰고 있는지 한눈에
연결 페이지는 현재 활성화된 모든 연결을 나열합니다. 각 행에는 목적지 도메인, 매칭된 규칙, 사용 중인 정책 그룹과 노드, 사용한 트래픽량이 표시됩니다. 자주 쓰는 활용법 세 가지를 소개합니다.
- 분기 확인: 어떤 사이트에 접속한 뒤 여기서 그 도메인을 검색해, 매칭된 규칙과 출구 노드가 예상과 맞는지 확인합니다.
- 트래픽 과다 사용 앱 찾기: 트래픽 기준으로 정렬하면 백그라운드에서 몰래 업데이트하는 앱이 바로 드러나고, 필요하면 × 버튼으로 해당 연결만 끊을 수 있습니다.
- 규칙 오작동 진단: 직결되어야 할 사이트가 프록시를 타고 있다면, 어떤 규칙에 매칭됐는지 확인하고 설정 파일에서 순서나 규칙 내용을 수정합니다.
로그 페이지: 문제 해결의 마지막 카드
연결 페이지로도 원인을 못 찾겠다면 로그 페이지를 볼 차례입니다. 로그 레벨을 잠시 debug로 바꾸면 흔한 오류를 바로 알아볼 수 있습니다.
| 로그 키워드 | 가능성 높은 원인 | 대처 |
|---|---|---|
connection refused | 노드 포트가 막혔거나 노드가 이미 다운됨 | 노드 교체, 구독 갱신 |
timeout | 노드 응답 지연, 회선 혼잡 | 지연 시간이 낮은 노드로 교체 |
auth failed | 구독 만료, 비밀번호/UUID 무효 | 서비스 제공업체에서 갱신 후 구독 업데이트 |
dns resolve failed | DNS 설정 문제 | DNS 설정 완전 정리 글을 참고해 점검 |
점검이 끝나면 로그 레벨을 info로 되돌려 두세요. debug 레벨은 로그 기록에 자원을 많이 씁니다.
알아두면 좋은 세 가지 활용 팁
- 규칙 조회: 일부 패널은 도메인을 입력하면 어떤 규칙에 매칭되는지 바로 조회할 수 있는 기능을 제공합니다. 규칙을 수정하기 전에 여기서 미리 시뮬레이션해 보세요.
- 트래픽 그래프: 개요 페이지의 실시간 업/다운로드 곡선으로 속도 테스트 결과를 검증할 수 있습니다. 대역폭을 가득 채울 때 곡선이 안정적이어야 정상이고, 톱니 모양이면 노드가 불안정하다는 신호입니다.
- 내부 네트워크 관리:
allow-lan을 켜면 연결 페이지에서 휴대폰, TV 등에서 오는 연결도 볼 수 있어, 집 안 모든 기기의 트래픽을 하나의 패널에서 관리할 수 있습니다.
어떤 패널을 쓸까: 내장 패널 vs 서드파티 웹 패널
데스크톱 클라이언트에 내장된 패널은 보통 프록시, 연결, 로그 세 기능을 모두 갖추고 있어 그대로 열어서 쓰면 됩니다. 별도 설정이 필요 없습니다. 서버나 공유기에서 순수 코어만 돌린다면, 자주 쓰이는 서드파티 웹 패널마다 강점이 조금씩 다릅니다.
- yacd: 화면이 깔끔하고 로딩이 빠릅니다. 안정성이 강점이라 핵심 정보만 빠르게 확인하고 싶은 사용자에게 어울립니다.
- metacubexd: 기능이 더 풍부하고 그래프도 다양하며 연결 상세 정보를 더 세밀하게 보여줍니다. 데이터를 깊이 파보는 걸 좋아하는 사용자에게 적합합니다.
둘 다 결국 external-controller API를 통해 Clash와 통신한다는 점은 같아서 기능적으로 본질적인 차이는 없습니다. 어떤 걸 고를지는 순전히 취향과 사용 습관 문제이고, 바꿔 쓰는 데도 별다른 비용이 들지 않습니다. 패널은 어차피 "읽고 조작"하는 화면일 뿐, 설정과 연결 상태는 항상 Clash 쪽에 있습니다.
모바일에서는 패널을 어떻게 볼까
모바일도 마찬가지입니다. 클라이언트가 패널 기능을 지원한다면 조작 방식은 데스크톱과 완전히 같습니다. 프록시 페이지에서 속도 테스트하고 전환하기, 연결 페이지에서 트래픽 확인하기, 로그 페이지에서 문제 진단하기까지 하나도 빠짐없이 가능합니다. 모바일 클라이언트에 패널 진입점이 따로 없다면, 브라우저로 external-controller에 설정한 주소에 직접 접속해도 됩니다(단, 휴대폰과 코어가 실행 중인 기기가 같은 네트워크에 있어야 합니다). 결과는 동일하고, 다만 브라우저를 한 번 더 열어야 하는 수고가 있을 뿐입니다.
패널을 습관으로 만들기
많은 사람이 네트워크에 문제가 생겼을 때만 패널을 떠올리는데, 사실 더 좋은 활용법은 패널을 상시 관찰 창으로 삼는 것입니다. 평소에는 한쪽에 띄워 두고, 노드를 바꾸기 전에 지연 시간을 한번 확인하고, 느려질 때는 짐작이 아니라 연결 페이지부터 열어보는 식입니다. 이 습관이 자리 잡으면 대부분의 "네트워크 문제"는 커뮤니티나 디스코드에 물어볼 필요 없이, 패널에 이미 나와 있는 정보로 답을 찾을 수 있다는 걸 알게 됩니다.
이 시리즈의 다른 글과 함께 보면 좋은 점
제어판은 사실 이 시리즈 전체의 문제 해결 흐름을 관통하는 축입니다. DNS가 의심된다면 로그 페이지에서 레벨을 debug로 바꾸고 "Clash DNS 설정 완전 정리" 글의 점검 절차와 나란히 대조해 보세요. 정책 그룹의 스케줄링이 제대로 안 되는 것 같다면 프록시 페이지에서 노드 상태를, 연결 페이지에서 매칭된 정책 그룹을 확인하고 "로드 밸런싱과 페일오버 실전 활용" 글의 점검 방향과 맞춰 보세요. 규칙 분기가 잘못됐다고 의심된다면 연결 페이지에서 도메인을 검색해 매칭된 규칙을 확인하고 "규칙 세트(rule-providers) 활용 가이드"에서 강조한 "순서가 결과를 결정한다"는 원칙을 떠올려 보세요. 즉, 앞의 여러 글은 "어떻게 설정할까"를 다뤘고, 이 글은 "설정한 뒤 어떻게 검증하고 문제를 해결할까"를 다룹니다. 둘을 합쳐야 완전한 사용 방법론이 됩니다.
Clash를 이제 막 시작했다면, 이 글을 "로드 밸런싱과 페일오버 실전 활용" 글과 함께 읽어보는 걸 추천합니다. 먼저 스케줄링 정책을 구성하고, 그다음 패널로 정책이 실제로 기대대로 동작하는지 확인하는 순서로 가면 시행착오를 훨씬 줄일 수 있습니다.