화면, 코어, 구성 파일부터 구분하기

Clash 클라이언트는 일반적으로 세 계층으로 구성됩니다. 그래픽 인터페이스는 버튼과 상태를 표시하고, Clash Meta(현재는 보통 mihomo라고 부름) 같은 코어는 연결을 처리하며 DNS와 규칙 매칭을 실행합니다. YAML 구성 파일은 포트, 노드, 정책 그룹, 규칙을 정의합니다. 화면에서 “노드 A”를 클릭하는 것은 실제로 코어의 제어 인터페이스에 정책 그룹 선택을 전달하는 동작이고, “구독 업데이트”를 클릭하면 원격 구성을 다운로드한 뒤 코어가 다시 불러옵니다.

클라이언트마다 메뉴를 “프록시”, “정책”, “Proxies”로 표시하거나 “구성”을 “구독”, “Profiles”로 표기하기도 합니다. 버튼 위치도 데스크톱과 모바일에서 달라질 수 있지만 데이터 관계는 대체로 같습니다. 화면을 볼 때 아이콘 위치만 외우지 말고, 현재 영역이 코어를 제어하는지, 구성을 관리하는지, 실행 기록을 확인하는지 먼저 판단하세요.

상단 상태 영역에 표시되는 항목

일반적인 데스크톱 구성에서는 혼합 프록시 포트를 7890, 외부 제어 포트를 9090으로 설정하는 경우가 많습니다. 구형 구성에서는 HTTP와 SOCKS를 각각 7890과 7891에 지정하기도 합니다. 이는 흔한 값일 뿐 고정 표준은 아닙니다. 실제 포트는 “설정” → “네트워크” → “포트 설정”에서 확인하거나 현재 YAML의 mixed-port, port, socks-port를 직접 확인하세요.

프록시 페이지: 정책 그룹, 노드, 지연 시간

프록시 페이지는 단순한 서버 목록이 아닙니다. 먼저 구성에 정의된 정책 그룹을 보여 주고, 각 그룹 안에 선택 가능한 노드나 하위 정책 그룹을 나열합니다. 규칙은 최종적으로 정책 그룹을 가리키며, 정책 그룹이 실제 연결에 사용할 노드를 결정합니다. 이 관계를 이해해야 특정 노드로 전환했는데 일부 트래픽에만 영향을 주는 이유를 설명할 수 있습니다.

정책 그룹 카드는 어떻게 볼까

정책 그룹에는 보통 그룹 이름, 유형, 현재 선택 항목, 후보 목록이 표시됩니다. 예를 들어 규칙이 스트리밍 도메인을 “스트리밍” 그룹으로 보내고, “스트리밍” 그룹이 현재 “홍콩 노드”를 선택한 상황을 생각해 보세요. 이때 “노드 선택” 그룹을 바꿔도 스트리밍에는 영향을 주지 않을 수 있습니다. 두 규칙이 서로 다른 정책 그룹을 가리킬 수 있기 때문입니다.

DIRECT는 로컬 네트워크에서 직접 연결한다는 뜻이고, REJECT는 연결을 거부한다는 뜻입니다. 둘 다 내장 정책이며 원격 서버가 아닙니다. 광고 도메인이 REJECT에 매칭되면 로그에 거부 기록이 남을 수 있지만 프록시 페이지에는 노드 지연 시간이 표시되지 않습니다.

지연 시간 결과를 대역폭으로 보면 안 되는 이유

노드 옆에 표시되는 68ms, 214ms 같은 숫자는 보통 테스트 URL에 HTTP 요청을 보낼 때 걸린 시간입니다. 당시 연결 응답 속도는 보여 주지만 다운로드 속도를 직접 나타내지는 않습니다. 테스트 URL, DNS 해석, TLS 핸드셰이크, 노드 부하, 로컬 Wi-Fi가 모두 결과에 영향을 줍니다. 지연 시간이 80ms인 노드가 50ms인 노드보다 처리량이 더 높을 수도 있습니다.

  1. 먼저 개별 정책 그룹의 테스트 버튼을 클릭하고 모든 후보 항목의 결과가 나올 때까지 기다리세요.
  2. 시간 초과로 표시된 노드는 순간적인 패킷 손실인지 확인하기 위해 한 번 더 테스트하세요.
  3. 후보 항목을 선택한 뒤 대상 웹사이트를 다시 열어 새 연결에 새 정책을 적용하세요.
  4. 기존 페이지가 계속 이전 노드를 사용한다면 연결 페이지에서 해당 연결을 종료하거나 연결이 자연스럽게 닫힐 때까지 기다리세요.

구성 페이지: 구독, 활성 구성, 오버라이드

구성 페이지에서는 구성의 출처를 관리합니다. 일반적으로 원격 구독, 로컬 YAML, 클라이언트가 생성한 임시 구성, 오버라이드가 적용된 실행 구성이 여기에 포함됩니다. 한 클라이언트에 여러 구성을 저장할 수 있지만 코어는 보통 한 번에 하나의 활성 구성만 불러옵니다.

구독 카드의 각 작업은 무엇을 할까

구독을 업데이트한 뒤에는 먼저 “마지막 업데이트” 시간이 바뀌었는지 확인하고, 노드 수와 정책 그룹이 예상과 일치하는지 살펴보세요. 시간이 갱신되었지만 내용이 같다면 원격에서 동일한 구성을 반환했을 수 있습니다. HTTP 401, 403 또는 429가 표시되면 구독 권한, 링크 유효 기간, 요청 빈도를 확인하세요. 다운로드는 성공했지만 로드에 실패했다면 YAML 문법과 필드 호환성을 계속 점검해야 합니다.

오버라이드와 직접 편집의 차이

원격 구독은 다음 업데이트 때 다시 다운로드됩니다. 캐시 파일을 직접 수정하면 새 내용으로 덮어써지는 경우가 많습니다. 오버라이드 기능은 구독을 다운로드한 뒤 코어가 로드하기 전에 필드를 추가하거나 조정하므로 로컬 포트, DNS, TUN 매개변수를 유지하기에 더 적합합니다. 클라이언트에 따라 메뉴가 “구성” → “오버라이드”에 있거나 구성 카드의 더보기 메뉴에 있을 수 있습니다.

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

external-controller: 127.0.0.1:9090

이 공통 필드는 혼합 프록시가 로컬 7890 포트에서 수신하고, 실행 모드는 규칙 모드이며, 로그 레벨은 info임을 나타냅니다. 로컬 네트워크 기기는 이 프록시 포트에 직접 접근할 수 없고, 제어 인터페이스는 루프백 주소에서만 수신합니다. 그래픽 인터페이스의 포트가 파일과 다르다면 오버라이드로 별도의 실행 구성이 생성되었는지 확인하세요.

로그 페이지: 기록 하나로 연결 경로 추적하기

로그 페이지에서는 코어 이벤트를 확인할 수 있습니다. 구성 로드, 수신 포트, DNS 초기화 같은 실행 메시지뿐 아니라 연결 대상, 규칙 매칭, 정책 경로도 포함됩니다. “클라이언트에는 연결됨으로 표시되지만 웹사이트가 열리지 않는” 문제를 해결할 때 로그가 프록시 페이지의 지연 시간보다 더 직접적인 단서를 제공하는 경우가 많습니다.

로그 레벨은 어떻게 선택할까

일반적인 경로는 “설정” → “매개변수 설정” → “로그 레벨” → “Info”입니다. DNS나 TUN 세부 동작을 추적해야 할 때만 Debug로 잠시 전환해 문제를 한 번 재현한 뒤 Info로 되돌리세요. 클라이언트마다 메뉴 이름은 조금씩 다르지만 최종적으로 수정되는 항목은 보통 log-level입니다.

연결 로그 하나에서 확인할 수 있는 단서

TCP 127.0.0.1:53142 --> example.com:443
match DomainSuffix(example.com)
using ProxyGroup[Hong Kong 01]

첫 번째 줄은 로컬 프로세스가 TCP를 통해 example.com:443에 접속했음을 보여 줍니다. 두 번째 줄은 도메인 접미사 규칙이 매칭되었음을 나타냅니다. 세 번째 줄에는 규칙이 가리키는 정책 그룹과 최종 선택 항목이 표시됩니다. 실제 mihomo 로그 형식은 버전과 클라이언트 래퍼에 따라 달라질 수 있지만, 문제를 해결할 때는 프로토콜, 대상 주소, 매칭 규칙, 아웃바운드 경로라는 네 가지 정보를 계속 찾으세요.

  1. 현재 로그를 지워 오래된 기록이 방해하지 않도록 하세요.
  2. 대상 앱의 기존 연결을 닫고 대상 페이지를 다시 여세요.
  3. 도메인, 대상 IP 또는 포트로 필터링하세요. 예를 들어 :443을 검색할 수 있습니다.
  4. 기록이 DIRECT인지, 특정 프록시 그룹인지, 아니면 REJECT인지 확인하세요.
  5. 기록이 전혀 없다면 해당 앱이 시스템 프록시를 사용하는지, 또는 TUN을 활성화해야 하는지 확인하세요.

연결 페이지와 3대 페이지를 함께 활용하는 법

많은 클라이언트에는 “연결” 페이지도 있습니다. 이 페이지에서는 현재 활성 연결의 소스 주소, 대상 호스트, 다운로드량, 업로드량, 규칙, 정책 경로를 보여 줍니다. 로그가 이벤트 흐름에 초점을 둔다면 연결 페이지는 현재 상태를 보여 줍니다. 두 화면을 함께 보면 노드를 바꾼 뒤에도 기존 다운로드가 이전 경로를 사용하는 이유를 판단할 수 있습니다.

브라우저가 이미 “노드 A”를 통해 HTTP/2 장기 연결을 만든 상태에서 프록시 페이지의 선택을 “노드 B”로 바꾼다고 가정해 보겠습니다. 기존 연결은 대개 새 노드로 이동하지 않습니다. 연결 페이지에는 이전 경로가 계속 표시되고, 새로 여는 연결부터 노드 B를 사용합니다. 연결 종료를 클릭하면 현재 요청이 중단되며 다운로드 중인 파일이나 실시간 통화도 끊길 수 있으므로 “모두 닫기”를 일상적인 새로 고침 버튼처럼 사용하지 마세요.

시스템 프록시와 TUN의 화면 차이

시스템 프록시는 브라우저와 운영체제의 프록시 설정을 따르는 앱에 적합합니다. Windows 11에서는 “설정” → “네트워크 및 인터넷” → “프록시”에서 시스템 프록시 상태를 확인할 수 있습니다. macOS에서는 “시스템 설정” → “네트워크” → “현재 네트워크” → “세부사항” → “프록시”에서 확인하세요. 클라이언트에서 시스템 프록시를 켜면 주소는 일반적으로 127.0.0.1과 현재 HTTP 또는 혼합 포트를 가리킵니다.

TUN 모드는 가상 네트워크 카드로 더 많은 트래픽을 처리하므로 시스템 프록시를 읽지 않는 앱, 일부 명령줄 프로그램, UDP가 필요한 환경에 적합합니다. 데스크톱 시스템에서 처음 활성화할 때는 관리자 권한이 필요할 수 있습니다. TUN을 켠 뒤 인터넷이 완전히 끊긴다면 가상 인터페이스 생성 여부, 기본 경로 등록 여부, 코어의 DNS 처리 여부, 다른 VPN이나 네트워크 필터링 프로그램이 동시에 라우팅을 수정하고 있는지 확인하세요.

처음 설치한 뒤 화면을 확인하는 순서

클라이언트를 처음 열었을 때 복잡한 규칙부터 바로 수정할 필요는 없습니다. 구성 로드, 코어 시작, 정책 선택, 트래픽 연결 방식 활성화, 로그 확인으로 이어지는 검증 가능한 최단 경로부터 완성하세요. 다음 순서는 Windows 11 24H2, macOS 및 일반적인 Android 클라이언트에 적용할 수 있으며, 구체적인 권한 요청은 시스템에 따라 달라집니다.

  1. 구성 페이지 열기: 구독 또는 로컬 YAML을 가져오고, 구성이 정상적으로 파싱되는지와 정책 그룹 및 노드 수가 올바른지 확인하세요.
  2. 활성 구성으로 설정: 상단 상태를 확인해 코어가 파일 다운로드만 완료한 것이 아니라 실제 실행 상태에 들어갔는지 살펴보세요.
  3. 프록시 페이지 열기: 후보 노드의 지연 시간을 한 번 테스트한 뒤 수동 선택 그룹에서 응답 가능한 노드를 선택하세요.
  4. 시스템 프록시 켜기: 데스크톱에서는 먼저 시스템 프록시로 브라우저 트래픽을 확인하세요. 수신 주소는 로컬 주소이고 포트는 설정 페이지와 일치해야 합니다.
  5. 로그 페이지 열기: Info 레벨을 유지한 채 새 도메인에 접속하고, 대상·규칙·정책 기록이 나타나는지 확인하세요.
  6. 필요할 때만 TUN 켜기: 앱이 시스템 프록시를 사용하지 않거나 UDP 처리가 필요하거나 트래픽을 통합 관리하려는 경우에만 활성화하세요.

자주 보이는 화면 현상과 확인할 항목

화면 조작에서 구성 읽기로 넘어가기

세 페이지에 익숙해지면 각 클릭 동작을 YAML에 대응해 볼 수 있습니다. 프록시 페이지는 proxy-groups와 proxies에서 가져오고, 구성 페이지는 파일 전체와 업데이트 출처를 관리하며, 로그 페이지는 rules의 매칭 결과를 보여 줍니다. 시스템 프록시와 TUN은 트래픽이 먼저 코어로 들어갈지를 결정합니다. 이렇게 화면을 읽으면 특정 클라이언트 버전의 고정된 레이아웃에 의존할 필요가 없습니다.

구성을 수정할 때는 검증 과정을 끊지 마세요. 저장한 뒤 구성이 다시 로드되었는지 확인하고, 프록시 페이지에서 정책 그룹이 그대로 있는지 점검한 다음 로그로 대상 도메인이 예상한 규칙에 매칭되었는지 검증하세요. 문제가 생기면 먼저 이전의 정상 구성으로 되돌리고, 시작되지 않는 파일에 수정을 계속 덧붙이지 마세요.