클라이언트를 열면 가장 먼저 무엇을 봐야 할까: 메인 화면 전체 구조
Clash 클라이언트마다(원판 코어 기반이든 Clash Meta/mihomo 코어 기반이든) 외형 디자인은 조금씩 다르지만, 메인 화면의 기능 구분은 대체로 비슷합니다. 보통 사이드바나 탭바를 기준으로 개요(또는 홈), 프록시, 설정, 규칙, 연결, 로그 등 몇 개의 영역으로 나뉘고, 여기에 설정 페이지가 하나 더 붙습니다. 처음 사용하는 분에게 실제로 매일 열어야 하는 화면은 세 곳뿐입니다. 프록시 페이지는 노드 선택을, 설정 페이지는 구독 관리를, 로그 페이지는 문제 확인을 담당합니다. 이 세 화면만 익혀두면 일상적인 사용의 90% 정도를 처리할 수 있습니다.
본격적인 분해에 들어가기 전에 먼저 알아둘 점이 있습니다. 클라이언트 자체는 하나의 그래픽 외피일 뿐이고, 실제로 트래픽 전달과 분기 규칙 실행을 처리하는 것은 그 뒤에 있는 코어 프로그램(엔진)입니다. 화면에 보이는 스위치 하나, 로그 한 줄도 본질적으로는 코어의 상태를 보여주거나 코어 설정을 변경하는 것입니다. 이 점을 이해해두면 "화면은 정상인데 네트워크가 안 될 때" 어디에서 원인을 찾아야 하는지 알 수 있습니다. 화면 자체를 계속 재시작하는 것이 아니라 코어 로그를 확인해야 합니다.
프록시 페이지: 노드 그룹, 지연 시간 측정, 수동 전환
프록시 페이지는 사용 빈도가 가장 높은 화면으로, 핵심 표시 단위는 "프록시 그룹(Proxy Group)"입니다. 구독 설정에는 보통 몇 개의 그룹이 미리 나뉘어 있는데, 예를 들어 지역별로 나눈 "홍콩 노드" "일본 노드", 또는 용도별로 나눈 "전체 프록시" "스트리밍 해제" "광고 차단" 등이 있습니다. 각 그룹 안에는 구체적인 노드들과, 선택 로직을 결정하는 정책 유형이 포함되어 있습니다.
- select 그룹: 수동 선택형. 클릭한 노드가 그대로 사용되며, 어떤 경로를 쓸지 명확히 정해둔 경우에 적합합니다.
- url-test 그룹: 자동 측정형. 클라이언트가 주기적으로 그룹 내 노드에 지연 시간 테스트를 실행해 현재 가장 빠른 노드로 자동 전환합니다.
- fallback 그룹: 주-보조형. 목록 앞쪽 노드를 우선 사용하고, 사용할 수 없게 되면 순서대로 뒤로 물러나 대체합니다.
- load-balance 그룹: 로드 밸런싱형. 규칙에 따라 여러 연결을 다수 노드에 분산시킵니다.
프록시 페이지에서 각 노드 뒤에는 보통 지연 시간 수치가 밀리초 단위로 표시됩니다. 이 수치는 클라이언트가 노드에 테스트 요청을 보내 얻은 왕복 소요 시간으로, 낮을수록 응답이 빠른 편이지만 지연 시간이 낮다고 다운로드 속도가 빠른 것은 아닙니다. 두 항목은 서로 다른 지표이므로, 노드를 고를 때 지연 시간은 1차 필터로만 활용하고 속도와 안정성은 실제로 한동안 사용해봐야 알 수 있습니다. "속도 측정" 버튼을 누르면 일괄 테스트를 수동으로 실행할 수 있고, 일부 클라이언트는 자동 측정 간격을 설정 페이지에서 조정할 수 있도록 지원합니다.
노드를 수동으로 전환하는 방법은 간단합니다. 해당 그룹으로 들어가 원하는 노드를 클릭하면 되고, 전환은 보통 즉시 적용되어 클라이언트를 재시작하거나 시스템 프록시를 다시 연결할 필요가 없습니다. 전환 후에도 웹페이지가 여전히 열리지 않는다면 대부분 노드 문제가 아니라 시스템 프록시 스위치나 분기 규칙 문제일 가능성이 높으므로, 이때는 로그 페이지로 이동해 구체적인 연결 기록을 확인해야 합니다.
설정 페이지: 구독 관리, 업데이트 주기, 설정 전환
설정 페이지(일부 클라이언트에서는 "구독" 또는 "Profiles"라고 부름)는 완전한 YAML 설정 파일 한 벌씩을 관리하는 곳으로, 각 설정에는 노드 정보, 그룹 규칙, 분기 규칙이 모두 담겨 있습니다. 대부분의 사람들은 서비스 제공처나 자체 구축 노드 판매처가 제공하는 구독 링크로 설정을 받으며, 클라이언트는 이 링크로 주기적으로 요청을 보내 최신 노드 목록을 가져옵니다.
이 페이지에서는 주로 세 가지 작업을 처리합니다.
- 구독 추가: 구독 링크를 붙여넣으면 클라이언트가 한 번 다운로드하고 파싱하여 사용 가능한 설정 항목을 생성합니다.
- 수동/자동 업데이트: 구독 내용은 고정되어 있지 않습니다. 서비스 제공처가 수시로 노드를 교체하거나 대역폭 배분을 조정하기 때문에, 설정 페이지에는 보통 "지금 업데이트" 버튼이 있고 자동 업데이트 주기도 설정할 수 있습니다. 흔히 매일 또는 몇 시간마다 새로고침하는 방식이 많습니다.
- 여러 설정 전환: 여러 개의 구독이나 커스텀 설정을 동시에 저장해두었다면 설정 페이지에 목록 형태로 표시되며, 항목을 클릭하면 해당 설정으로 전환됩니다. 현재 적용 중인 설정에는 보통 눈에 띄는 표시가 붙습니다.
주의할 점은, 설정을 전환하거나 구독을 업데이트한 뒤에는 프록시 페이지에서 수동으로 선택했던 노드가 보통 그룹의 기본값으로 재설정된다는 것입니다. 새 설정 안의 그룹과 노드 목록이 이미 바뀌었을 수 있기 때문에, 클라이언트는 이전 선택 상태를 강제로 유지하지 않습니다. "구독 업데이트 후 노드가 다시 기본값으로 돌아갔다"는 상황은 정상적인 현상이므로, 프록시 페이지로 돌아가 다시 선택하면 됩니다.
또한 설정 파일에는 보통 DNS 설정과 TUN 모드 관련 필드도 포함되어 있습니다. TUN 모드는 시스템 네트워크 계층에 가상 네트워크 카드를 만들어 전체 트래픽을 인수하는 동작 방식으로, 일반적인 시스템 프록시 모드보다 적용 범위가 넓어 시스템 프록시 설정을 따르지 않는 프로그램의 트래픽도 처리할 수 있습니다. 다만 해당 스위치와 상태는 보통 설정 페이지 자체가 아니라 환경설정 페이지나 개요 페이지에 있으며, 설정 페이지는 이 필드들이 구독과 함께 적용되도록 하는 역할만 합니다.
로그 페이지: 연결 기록, 규칙 매칭, 문제 해결 실마리
문제를 확인할 때 가장 먼저 봐야 할 곳은 환경설정 페이지가 아니라 로그 페이지입니다. 이 페이지는 클라이언트가 각 네트워크 연결을 처리하는 실시간 과정을 기록하며, 일반적인 로그 한 줄에는 대략 다음과 같은 정보가 담깁니다.
[Info] [TCP] example.com:443 match Rule(DOMAIN-SUFFIX,example.com) using 홍콩노드01이 로그를 풀어보면 네 가지를 알 수 있습니다. 연결의 목적지 주소와 포트, 이 연결이 어떤 분기 규칙에 매칭됐는지, 규칙의 구체적인 매칭 방식(여기서는 도메인 접미사 매칭), 그리고 최종적으로 이 연결이 어떤 노드로 처리됐는지입니다. 이 네 요소를 대응시켜 보면 "이 사이트가 왜 이 노드로 나갔는지" 또는 "이 규칙이 실제로 적용되고 있는지"를 대체로 판단할 수 있습니다.
로그 페이지는 보통 로그 레벨별 필터링도 지원하며, 일반적으로 낮은 것부터 높은 순으로 Debug, Info, Warning, Error 정도가 있습니다. 네트워크가 안 되는 문제를 일상적으로 확인할 때는 레벨을 Debug로 올려두면 연결 시도의 전체 과정, 즉 연결 수립 실패나 DNS 해석 오류 같은 세부 사항까지 확인할 수 있어 문제 파악 효율이 눈에 띄게 좋아집니다. 다만 로그가 갱신되는 속도도 훨씬 빨라지므로, 확인이 끝나면 기본 레벨로 되돌려두는 것이 리소스 낭비를 막는 데 도움이 됩니다.
또 하나 자주 있는 요구가 "연결" 패널을 보는 것입니다(일부 클라이언트는 연결 목록과 로그를 별도의 하위 페이지로 나눠둡니다). 연결 패널은 현재 활성 중이거나 지나간 네트워크 연결 목록을 보여주며, 각 연결의 출처 프로세스, 목적지 주소, 사용 중인 노드, 누적 트래픽까지 확인할 수 있습니다. 특정 프로그램(예: 브라우저나 어떤 클라이언트 소프트웨어)의 트래픽이 실제로 프록시를 통해 나가는지, 아니면 프록시를 우회해 직접 연결되는지 확인하는 데 적합합니다.
문제 해결 순서 권장: 먼저 로그 페이지에서 연결이 예상한 규칙에 매칭됐는지 확인하고, 그다음 프록시 페이지로 돌아가 그룹에서 선택된 노드가 정상 작동하는지 확인한 뒤, 마지막으로 시스템 프록시나 TUN 스위치 상태를 확인하는 것이 좋습니다. 순서를 반대로 하면 관련 없는 부분에서 시간을 낭비하기 쉽습니다.
3대 패널을 함께 활용하는 몇 가지 요령
세 화면 각각의 역할을 파악했다면, 실제 사용에서 유용한 조합 방식을 몇 가지 더 소개합니다.
프록시 페이지의 측정 수치가 계속 타임아웃으로 나오는데, 노드가 죽은 건가요?
꼭 그렇지는 않습니다. 타임아웃은 노드가 실제로 사용할 수 없는 상태일 수도 있지만, 측정에 쓰인 목적지 주소 자체가 현재 네트워크 환경에서 접속이 제한되어 있거나, 로컬 네트워크가 잠시 흔들려 한 번의 측정만 실패했을 수도 있습니다. 한두 번 수동으로 다시 측정해보고, 계속 타임아웃이 나오면서 로그 페이지에서도 해당 노드의 연결 실패 기록이 확인되면 그때 노드 문제로 판단하고 그룹 내 다른 노드로 교체하는 것을 고려하세요.
구독을 업데이트한 뒤 설정 페이지에서 이전에 저장한 커스텀 규칙이 안 보이는데, 어떻게 해야 하나요?
커스텀 규칙을 구독 설정 파일에 직접 작성해뒀다면, 구독을 업데이트할 때 원격의 최신 내용을 가져오면서 로컬에서 수동으로 수정한 부분이 덮어씌워집니다. 커스텀 규칙을 유지하려면 보통 클라이언트가 제공하는 "오버라이드" 또는 "추가 규칙" 기능을 사용해 커스텀 내용을 따로 저장하고, 구독 업데이트로 갱신되는 메인 설정과 섞이지 않게 해야 합니다.
로그 페이지 정보량이 너무 많아 보기 힘든데, 특정 노드나 규칙의 기록만 볼 방법이 있나요?
일부 클라이언트의 로그 페이지는 키워드 필터링이나 검색창을 지원하므로, 노드 이름이나 도메인 키워드를 직접 입력해 범위를 좁힐 수 있습니다. 클라이언트 자체에 필터 기능이 없다면 연결 패널에서 목적지 주소 기준으로 정렬해 확인하는 방법도 비슷한 효과를 낼 수 있습니다.