먼저 클라이언트, 구성, 코어를 구분하기
Clash Plus, Clash Verge Rev, FlClash 같은 데스크톱 프로그램은 클라이언트 셸로, 화면을 표시하고 구성을 관리하며 프록시 코어를 호출합니다. 실제로 규칙 매칭, DNS 조회, 연결 전달, TUN 인계를 수행하는 것은 대개 Mihomo 코어입니다. 클라이언트마다 사이드바 아이콘, 메뉴 이름, 배치는 다를 수 있지만 핵심 기능은 네 가지로 나눌 수 있습니다. 프록시 페이지는 트래픽을 어떤 정책으로 보낼지 정하고, 구성 페이지는 어떤 규칙 세트를 불러올지 결정하며, 연결 페이지는 현재 진행 중인 세션을 보여 주고, 로그 페이지는 코어가 해당 세션을 처리한 과정을 기록합니다.
이 역할을 이해하면 작업 순서도 명확해집니다. 먼저 구성 페이지에서 구독을 가져와 활성화하고, 프록시 페이지에서 실행 모드와 정책 그룹을 확인한 다음 시스템 프록시 또는 TUN을 켭니다. 마지막으로 연결 페이지와 로그 페이지에서 결과를 검증합니다. 현재 구성과 트래픽 인계 방식을 확인하지 않고 프록시 페이지에서 노드만 반복해서 바꾸는 것은 초보자가 가장 흔히 하는 비효율적인 작업입니다.
| 화면 영역 | 주요 대상 | 주로 하는 작업 | 담당하지 않는 작업 |
|---|---|---|---|
| 프록시 페이지 | 실행 모드, 정책 그룹, 노드 | 노드 선택, 정책 전환, 지연 시간 테스트 | 구독 내용 업데이트 |
| 구성 페이지 | 로컬 YAML, 원격 구독, 구성 제공자 | 구성 가져오기, 업데이트, 활성화 | 개별 연결에 어떤 규칙이 적용됐는지 판단 |
| 연결 페이지 | 현재 TCP·UDP 세션 | 대상 주소, 규칙, 프록시 체인, 트래픽 확인 | 장기간 보관할 전체 진단 기록 저장 |
| 로그 페이지 | 코어 실행 이벤트 | DNS, 규칙, 연결 시도, 구성 오류 확인 | 구독 편집기 역할 |
| 설정 페이지 | 시스템 프록시, TUN, 포트, 코어 매개변수 | 애플리케이션이 트래픽을 인계하는 방식 결정 | 프록시 페이지의 정책 그룹 선택을 대신함 |
프록시 페이지: 모드, 정책 그룹, 노드 선택
프록시 페이지는 단순한 서버 목록이 아닙니다. 구성 파일의 proxy-groups를 표시하며, 각 그룹에는 고유한 역할이 있습니다. 예를 들어 “노드 선택”은 수동 선택 그룹일 수 있고, “자동 선택”은 url-test 그룹일 수 있으며, “장애 조치”는 fallback 그룹일 수 있습니다. 최종 연결 경로는 실행 모드, 규칙 매칭 결과, 정책 그룹의 중첩 관계, 현재 선택 항목에 따라 결정됩니다.
세 가지 실행 모드는 어떻게 작동할까
- Rule: 구성에 정의된 규칙을 위에서부터 순서대로 매칭합니다. 도메인은
DOMAIN-SUFFIX에, IP는IP-CIDR에 매칭될 수 있으며, 어디에도 매칭되지 않은 트래픽은 최종적으로MATCH로 들어갑니다. 일상적인 사용에서 가장 흔한 모드입니다. - Global: 대부분의 연결을 하나의 전역 정책 그룹으로 보냅니다. 일반 규칙에 따라 연결을 개별적으로 분기하지 않습니다. 특정 노드를 통해 웹사이트에 접속할 수 있는지 일시적으로 확인할 때 유용하지만, 규칙 모드를 장기간 대신하는 용도로는 적합하지 않습니다.
- Direct: 연결을 보통 대상에 직접 전송하며 프록시 노드를 거치지 않습니다. 로컬 네트워크와 비교 테스트할 때 사용할 수 있지만, 프록시 페이지에서 노드를 선택했더라도 실제 트래픽에는
DIRECT가 표시될 수 있습니다.
웹페이지가 계속 직접 연결된다면 먼저 페이지 상단이나 설정 영역에서 현재 모드가 Direct인지 확인하세요. 모든 웹사이트가 같은 노드를 사용한다면 Global로 잘못 전환한 것은 아닌지도 확인해야 합니다. 클라이언트는 재시작 후 대개 이전 상태를 복원하므로, 문제를 해결할 때 기억만으로 현재 모드를 판단해서는 안 됩니다.
정책 그룹 유형에 따라 선택 방식이 달라짐
| 그룹 유형 | 화면 동작 | 적합한 상황 |
|---|---|---|
select |
사용자가 노드 또는 하위 정책 그룹을 직접 선택 | 고정 지역, 고정 회선, 수동 제어 |
url-test |
테스트 주소의 지연 시간 결과에 따라 자동 선택 | 같은 유형의 노드 중 응답이 빠른 노드 선택 |
fallback |
사용 가능한 목록에서 앞쪽 노드를 우선 사용 | 주 회선에 장애가 발생하면 예비 회선으로 전환 |
load-balance |
구성된 정책에 따라 연결을 분배 | 여러 노드로 연결을 분산하며, 대역폭이 합산되는 것은 아님 |
지연 시간 수치는 테스트 URL이 해당 검사에서 응답하는 데 걸린 시간만 나타냅니다. 80ms로 표시된 노드가 120ms인 노드보다 다운로드가 반드시 빠른 것은 아닙니다. 실제 속도는 출구 대역폭, 패킷 손실, 대상 사이트의 위치, 혼잡도에도 영향을 받습니다. 테스트 실패가 노드 전체의 고장을 의미하지도 않습니다. 테스트 주소 차단, DNS 조회 실패, 제공자 업데이트 지연 때문에 결과가 시간 초과로 표시될 수 있습니다.
구성 페이지: 구독 가져오기, 업데이트, 활성화 상태
구성 페이지는 전체 실행 입력을 관리합니다. 원격 구독은 대개 Clash YAML 구성으로 다운로드되며, 여기에는 포트, DNS, 노드, 정책 그룹, 규칙, 규칙 제공자가 포함될 수 있습니다. 일부 서비스는 범용 Base64 노드 목록만 반환하므로 Clash 구성 페이지에서 바로 해석된다고 보장할 수 없습니다. 가져오기 중 “형식 오류”가 표시되거나 노드만 나타나고 규칙 그룹이 보이지 않는다면 먼저 구독 형식을 확인하세요.
가져오기에 성공했다고 활성화된 것은 아님
대부분의 클라이언트는 여러 구성을 동시에 저장할 수 있습니다. 새 구독을 가져온 뒤에도 구성 카드, 라디오 표시 또는 “활성화” 버튼을 눌러 현재 구성으로 지정해야 합니다. 전환 성공 여부는 프록시 페이지에서 정책 그룹 이름이 바뀌었는지 확인하거나 로그 페이지에서 구성이 다시 로드된 기록을 찾으면 알 수 있습니다. 새 구독과 기존 구독에 같은 이름의 정책 그룹이 있다면 프록시 페이지 제목만으로는 부족합니다. 구성 페이지의 선택 표시와 업데이트 시간을 함께 확인하세요.
- 「구성」 또는 「Profiles」 페이지를 엽니다.
- 구독 입력란에
https://로 시작하는 전체 주소를 붙여 넣습니다. - “가져오기”, “다운로드” 또는 더하기 버튼을 클릭하고 분석이 완료될 때까지 기다립니다.
- 새로 나타난 구성 카드를 선택해 현재 구성으로 지정합니다.
- 업데이트 버튼을 클릭하고 업데이트 시간이 변경됐는지 확인합니다.
- 프록시 페이지로 돌아가 정책 그룹과 노드가 예상대로 표시되는지 확인합니다.
자동 업데이트와 로컬 수정의 경계
자동 업데이트 간격은 24시간이 일반적이며, 일부 클라이언트에서는 6시간, 12시간 또는 48시간으로 설정할 수 있습니다. 업데이트 시간은 클라이언트가 구독을 가져오려고 시도했다는 뜻일 뿐, 상위 서버의 내용이 실제로 바뀌었다는 의미는 아닙니다. 서버가 401 또는 403을 반환한다면 구독 만료 여부와 인증 매개변수가 빠짐없이 포함됐는지 확인하세요. 시간 초과가 발생하면 DNS, 현재 네트워크, 구독 도메인에 접근할 수 있는지도 계속 확인해야 합니다.
원격 구독에서 생성된 YAML을 직접 편집할 때는 덮어쓰기 관계에 주의하세요. 다음 업데이트에서 원격 버전이 로컬 수정 내용을 덮어쓸 수 있습니다. 사용자 지정 규칙을 장기간 유지하려면 로컬 구성으로 복사하거나 클라이언트가 제공하는 오버라이드, 스크립트, Merge, Mixin 기능을 사용하세요. 구체적인 메뉴는 「구성」→「오버라이드」 또는 「설정」→「구성 관리」에 있을 수 있습니다. 수정하기 전에 정상적으로 로드되는 구성 사본을 보관해 문법 오류가 발생했을 때 되돌릴 수 있도록 하세요.
mixed-port: 7890
mode: rule
log-level: info
allow-lan: false
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,노드 선택위 예시의 mixed-port: 7890은 HTTP와 SOCKS 인바운드가 7890 포트를 함께 사용한다는 뜻이지만, 이는 흔한 구성일 뿐 고정값은 아닙니다. 클라이언트 설정 페이지에 표시된 실제 포트를 튜토리얼 화면보다 우선하세요. 브라우저, 터미널 또는 다른 애플리케이션에 프록시를 수동으로 입력할 때는 현재 실행 중인 구성을 확인해야 하며, 모든 클라이언트가 7890을 사용한다고 가정해서는 안 됩니다.
연결 페이지: 트래픽이 실제로 어디로 가는지 확인
연결 페이지는 실행 상태를 가장 직접적으로 보여 주는 근거입니다. 일반적으로 출발지 주소, 대상 호스트, 대상 IP, 네트워크 유형, 업로드·다운로드량, 매칭 규칙, 정책 그룹, 프록시 체인을 표시합니다. 브라우저에서 웹페이지 하나를 열어도 기본 문서, 이미지, 스크립트, 글꼴, 통계 API가 서로 다른 도메인에 접속할 수 있으므로 목록에 수십 개의 세션이 나타나는 것은 이상한 일이 아닙니다.
중점적으로 확인할 네 가지 필드
- Host 또는 대상 도메인: 확인 중인 연결이 대상 애플리케이션에 속하는지 확인합니다. 도메인 없이 IP만 표시된다면 애플리케이션이 IP에 직접 접속했거나 도메인 스니핑 결과를 얻지 못했을 가능성이 있습니다.
- Rule:
DOMAIN-SUFFIX,GEOSITE,IP-CIDR,MATCH같은 매칭 규칙 유형을 표시합니다. 규칙의 세부 값은 인접한 필드에 표시되는 경우가 많습니다. - Chains: 정책 그룹에서 최종 출구까지의 경로를 표시합니다. 예를 들면 “해외 웹사이트 → 자동 선택 → HK-01”과 같습니다. 최종 값이
DIRECT이면 직접 연결,REJECT이면 규칙에 의해 거부된 것입니다. - Network: TCP와 UDP를 구분합니다. 웹페이지 본문은 대개 TCP 또는 UDP 기반 QUIC을 사용하며, 음성 통화, 게임, DNS에서도 UDP 세션이 발생할 수 있습니다.
규칙을 점검할 때는 먼저 필터 조건을 지운 다음 검색창에 대상 도메인을 입력하세요. 웹페이지를 다시 열고 새 연결을 확인합니다. 프록시를 통해야 하는데 DIRECT에 매칭된다면 규칙 순서를 계속 확인하세요. Clash는 일반적으로 위에서 아래로 규칙을 매칭하며 먼저 일치한 규칙이 적용됩니다. 사용자 지정 규칙을 범위가 넓은 직접 연결 규칙 뒤에 배치하면 문법이 올바르더라도 실행되지 않습니다.
연결 페이지에서는 노드 전환이 적용됐는지도 확인할 수 있습니다. 기존 경로가 “노드 선택 → JP-01”이었다가 SG-02로 바뀐 경우, 이미 연결된 장기 세션에는 여전히 JP-01이 표시되고 새 연결에는 “노드 선택 → SG-02”가 표시될 수 있습니다. 연결 재사용으로 인한 정상적인 현상입니다. “모든 연결 닫기”를 클릭하면 현재 세션이 중단되며, 진행 중인 파일 다운로드, 원격 터미널, 온라인 회의에도 영향을 줍니다.
로그 페이지: 증상에서 구체적인 단계까지 추적
로그 페이지에는 코어 시작, 구성 로드, DNS 조회, 규칙 매칭, 프록시 연결 시도, 오류 이벤트가 기록됩니다. 연결 페이지가 “이 트래픽이 어디로 갔는가”에 답한다면, 로그 페이지는 “왜 연결이 수립되지 않았는가”에 답합니다. 문제를 해결할 때는 먼저 info 수준을 유지하세요. 일반 로그만으로 부족할 때만 일시적으로 debug로 전환합니다. 디버그 수준은 정보가 더 많이 생성되므로 원인을 찾은 뒤에는 info로 되돌려야 합니다.
자주 보이는 로그 키워드와 대응 방향
| 로그 내용 | 일반적인 의미 | 다음 단계 |
|---|---|---|
connection refused |
대상 포트에서 연결을 능동적으로 거부함 | 노드 주소, 포트, 서비스 상태 확인 |
i/o timeout |
제한 시간 안에 연결 또는 읽기가 완료되지 않음 | 네트워크나 노드를 바꾸고 패킷 손실 및 대상 접근 가능 여부 확인 |
no such host |
도메인 조회 실패 | DNS 구성, 상위 서버, 네트워크 권한 확인 |
address already in use |
수신 포트를 다른 프로세스가 사용 중 | 해당 프로그램을 종료하거나 mixed, HTTP, SOCKS 포트 변경 |
proxy provider 업데이트 실패 |
노드 제공자 파일을 가져오지 못함 | provider URL, 업데이트 간격, 접근 경로 확인 |
| YAML 줄 번호 또는 필드 오류 | 구성 문법이나 필드 구조를 해석할 수 없음 | 구성 페이지에서 사본을 복원한 뒤 들여쓰기와 필드 계층 확인 |
로그를 복사해 도움을 요청하기 전에 구독 URL, 노드 서버 주소, 인증 매개변수, 로컬 네트워크 IP, 접속 도메인이 포함되어 있는지 확인하세요. 전체 페이지를 붙여 넣기보다 장애 발생 전후 약 20~50줄을 남기고, 작업 시간, 클라이언트 이름, 코어 버전, 실행 모드, 인계 방식을 함께 설명하는 편이 효과적입니다.
설정 페이지: 시스템 프록시, TUN, 포트의 연동 방식
프록시 페이지에서 노드를 선택해도 트래픽이 코어로 들어가야 합니다. 시스템 프록시와 TUN은 흔히 사용하는 두 가지 인계 방식입니다. 시스템 프록시는 클라이언트가 운영체제의 HTTP, HTTPS 또는 SOCKS 프록시를 로컬 포트로 지정하는 방식이며, 브라우저처럼 시스템 설정을 따르는 프로그램이 이를 사용합니다. 터미널 도구, 게임, 일부 독립 네트워크 스택은 시스템 프록시를 읽지 않을 수 있습니다.
TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 트래픽을 인계합니다. 시스템 프록시를 읽지 않는 프로그램에 적합하지만 시스템 권한, 라우팅, DNS 구성의 영향을 더 많이 받습니다. Windows에서 TUN을 활성화하면 클라이언트가 관리자 권한이나 서비스 모드 설치를 요구할 수 있습니다. 시스템 프록시와 TUN을 함께 사용하도록 클라이언트가 조정할 수도 있지만, 문제를 해결하는 동안에는 어느 방식을 사용하는지 명확히 해 여러 변수를 동시에 바꾸지 않는 것이 좋습니다.
기억해 둘 로컬 포트
7890: HTTP와 SOCKS 연결을 모두 받을 수 있는 일반적인 mixed 포트입니다. 실제 값은 설정 페이지를 기준으로 하세요.7891: 일부 구형 구성에서는 SOCKS 포트로 사용했지만, 최신 구성에서는 이 할당을 유지하지 않을 수 있습니다.9090: 일반적인 external controller 포트로, 클라이언트 화면이 코어의 제어 인터페이스에 연결할 때 사용합니다. 브라우저에 입력하는 프록시 포트가 아닙니다.53: 표준 DNS 포트입니다. TUN과 강화된 DNS 구성에서는 내부 리스너 또는 전달을 통해 조회를 처리할 수 있으므로, 포트 번호만으로 정상 작동 여부를 판단해서는 안 됩니다.
“클라이언트에는 실행 중이라고 표시되지만 웹페이지가 열리지 않는” 경우 「설정」→「포트 설정」에서 mixed 포트를 확인한 다음 시스템 프록시 주소가 127.0.0.1과 같은 포트를 사용하는지 확인하세요. 로그에 address already in use가 표시되면 포트 수신에 실패한 것입니다. 이때 시스템 프록시 스위치가 켜져 있어도 애플리케이션은 요청을 코어로 전달할 수 없습니다.
안정적인 일상 사용 흐름
화면에 익숙해지면 매번 모든 페이지를 확인할 필요는 없습니다. 평소에는 일정한 절차로 간단히 사용하고, 문제가 생겼을 때만 트래픽 흐름을 따라 단계별로 되짚어 보면 됩니다.
- 구성 페이지: 구독 업데이트 시간과 현재 활성화된 구성을 확인합니다. 구독이 변경되었다면 먼저 업데이트한 뒤 새 정책 그룹이 나타나는지 확인하세요.
- 프록시 페이지: Rule 모드를 사용하고 필요한 정책 그룹 또는 노드를 선택합니다. 지연 시간 테스트는 사용 가능 여부를 판단하는 참고 자료로만 활용하세요.
- 설정 페이지: 애플리케이션 유형에 따라 시스템 프록시 또는 TUN을 활성화하고 로컬 수신 포트를 확인합니다.
- 연결 페이지: 대상 웹사이트에 접속한 뒤 도메인으로 새 세션을 필터링하고 규칙과 프록시 체인을 확인합니다.
- 로그 페이지: 연결이 수립되지 않으면 발생 시간을 기준으로 DNS, 시간 초과, 연결 거부, 구성 오류를 확인합니다.
예를 들어 브라우저는 접속되지만 터미널 명령이 직접 연결된다면 먼저 터미널이 시스템 프록시를 읽는지 확인하거나 TUN을 사용하세요. 모든 애플리케이션에 연결 기록이 없다면 시스템 프록시, TUN, 포트 수신 상태를 먼저 확인합니다. 연결 페이지에 기록은 있지만 경로가 DIRECT라면 프록시 모드와 규칙 순서를 다시 확인하세요. 경로가 이미 지정한 노드까지 도달했는데도 시간 초과가 발생한다면 노드 접근 가능 여부, DNS, 대상 사이트 상태를 점검합니다.