클라이언트와 코어
Mihomo
Mihomo는 Clash Meta의 계보를 잇는 생태계에서 널리 사용되는 설정·프록시 코어로, YAML 설정을 해석하고 연결을 수립하며 규칙을 실행하고 정책 그룹을 관리합니다.
클라이언트마다 사용하는 코어 버전이 다를 수 있습니다. 인터페이스 이름이 비슷하더라도 클라이언트의 코어 정보와 설정 호환 범위를 확인해야 합니다.
Glossary / Network map
클라이언트 인터페이스, 설정 파일과 네트워크 모드에서 혼동하기 쉬운 용어를 하나의 색인으로 정리했습니다. 먼저 분류별로 개념을 찾은 다음 다운로드 페이지나 튜토리얼에서 실제 설정을 진행하세요.
01 / Runtime layer
이 용어들은 “설정을 실제로 실행하는 주체는 누구인가”라는 질문에 답합니다. 클라이언트는 조작 창구를 제공하고, 코어는 설정 해석·연결 수립·규칙 실행을 담당합니다.
클라이언트와 코어
Mihomo는 Clash Meta의 계보를 잇는 생태계에서 널리 사용되는 설정·프록시 코어로, YAML 설정을 해석하고 연결을 수립하며 규칙을 실행하고 정책 그룹을 관리합니다.
클라이언트마다 사용하는 코어 버전이 다를 수 있습니다. 인터페이스 이름이 비슷하더라도 클라이언트의 코어 정보와 설정 호환 범위를 확인해야 합니다.
클라이언트와 코어
Clash 클라이언트는 프록시 코어를 실행하고 그래픽 인터페이스를 제공하는 애플리케이션으로, 일반적으로 설정 가져오기, 모드 전환, 연결 확인과 시스템 프록시 변경을 담당합니다.
클라이언트를 선택할 때는 먼저 운영체제, 코어 지원 여부와 TUN 같은 시스템 수준 기능의 필요성을 확인한 뒤 데스크톱 또는 모바일 도구를 결정하세요.
클라이언트와 코어
YAML은 Clash와 Mihomo에서 자주 사용하는 설정 파일 형식으로, 들여쓰기와 콜론 구조가 문법적 의미를 가집니다.
들여쓰기 오류, 키 이름 오타 또는 잘못된 자료형으로 인해 설정을 불러오지 못할 수 있습니다. YAML을 편집할 때는 기존 계층 구조를 유지하고, 수정 후 설정 해석 결과를 다시 확인하는 것이 좋습니다.
02 / Connection path
이 용어들은 연결이 로컬 컴퓨터에서 출발한 뒤 프록시 진입점으로 들어가는 방식과 연결 응답 상태를 확인하는 방법을 설명합니다.
프록시와 연결
노드는 설정에 정의된 하나의 프록시 서버 연결로, 일반적으로 주소, 포트, 프로토콜, 인증 정보와 전송 매개변수를 포함합니다.
하나의 설정에 여러 노드를 넣어 정책 그룹에서 선택할 수 있습니다. 노드 이름은 식별용 레이블일 뿐이며, 이름만으로 실제 지역·속도·안정성을 판단할 수는 없습니다.
프록시와 연결
지연 시간은 클라이언트가 탐색 요청을 보낸 뒤 응답을 받기까지 걸리는 시간으로, 보통 밀리초로 기록합니다. 탐색 대상, 네트워크 거리와 테스트 프로토콜에 따라 측정값이 달라집니다.
지연 시간이 짧다는 것은 응답이 빠르다는 뜻일 뿐, 대역폭·안정성·모든 웹사이트에서의 실제 사용 경험을 단독으로 나타내지는 않습니다. 연결이 불안정하다면 시간 초과, 패킷 손실과 실제 접속 결과도 함께 확인해야 합니다.
프록시와 연결
프록시 포트는 클라이언트가 로컬 컴퓨터에서 연결을 받아들이는 진입점으로, HTTP 또는 SOCKS 포트가 그 예입니다.
브라우저, 명령줄 도구와 다른 애플리케이션은 올바른 주소와 포트를 사용해야 트래픽을 Clash로 전달할 수 있습니다. 포트 충돌이나 수신 주소 설정 오류는 연결 거부로 나타납니다.
03 / Configuration source
구독은 설정의 출처를 정하고, 설정 파일은 클라이언트의 실행 방식을 결정합니다. 서로 관련되어 있지만 같은 개념은 아닙니다.
구독과 설정
구독은 보통 프록시 설정을 가져오기 위한 URL이며, 서버는 노드·정책 그룹·규칙 등의 내용을 반환합니다.
클라이언트가 구독을 업데이트하면 원격 콘텐츠를 현재 사용할 수 있는 설정 파일로 변환합니다. 업데이트에 실패하면 먼저 주소가 유효하고 계정 상태가 정상인지 확인한 뒤, 반환된 내용이 여전히 해석 가능한 설정인지 점검해야 합니다.
구독과 설정
설정 파일은 프록시 노드, 포트, DNS, 규칙과 정책 그룹 등의 실행 매개변수를 정의하며, 코어의 동작을 결정하는 주요 근거입니다.
구독으로 생성된 설정을 기반으로 덮어쓰기나 로컬 편집을 통해 개인 설정을 추가할 수 있습니다. 수정하기 전에 사용 가능한 복사본을 보관하면 이전 상태로 빠르게 되돌릴 수 있습니다.
구독과 설정
프록시 제공업체는 구독 주소와 그에 연결된 네트워크 서비스를 제공하며, Clash 클라이언트 자체가 프록시 서비스인 것은 아닙니다.
구독을 사용하기 전에 출처, 계정 상태, 트래픽 제한과 서비스 약관을 확인해야 합니다. 구독 만료, 노드 만료 또는 서버 측 형식 변경이 발생하면 클라이언트는 보통 업데이트 또는 해석 실패를 알리는 데 그칩니다.
04 / Decision layer
규칙은 연결이 어떤 경로를 사용할지 판단하고, 정책 그룹은 일치한 뒤 구체적인 노드나 처리 방식을 선택합니다.
규칙과 정책 그룹
규칙은 미리 정한 조건에 따라 도메인, IP 주소, 프로세스 또는 네트워크 요청을 매칭하고 연결을 지정된 정책 그룹으로 전달합니다.
규칙은 보통 위에서 아래로 실행되며, 앞에서 일치한 항목이 이후 처리에 영향을 줍니다. 분기 결과를 점검할 때는 먼저 실제로 일치한 규칙을 확인한 다음, 해당 규칙이 가리키는 정책 그룹을 살펴보세요.
규칙과 정책 그룹
규칙 제공자는 광고 도메인, 로컬 네트워크 주소 또는 특정 서비스 도메인 모음처럼 독립적으로 업데이트할 수 있는 규칙 파일 묶음을 참조하는 데 사용합니다.
설정에는 규칙 형식과 동작, 원격 또는 로컬 출처를 선언해야 합니다. 규칙 제공자가 업데이트된 뒤에도 해당 동작이 현재 설정의 정책 그룹 이름과 일치하는지 확인해야 합니다.
규칙과 정책 그룹
정책 그룹은 노드나 다른 정책을 선택하는 계층으로, 수동 선택·자동 속도 측정·장애 조치 등이 일반적인 유형입니다.
규칙이 정책 그룹과 일치하면 최종적으로 해당 그룹이 연결에 사용할 프록시 경로를 결정합니다. 수동 선택은 직접 제어할 때 적합하고, 자동 방식은 테스트 대상과 상태 점검 설정의 영향을 더 많이 받습니다.
05 / Traffic capture
네트워크 모드는 클라이언트가 가로챌 수 있는 트래픽의 범위를 결정합니다. 시스템 프록시는 시스템 설정을 따르는 애플리케이션에 적합하고, TUN 같은 모드는 더 넓은 범위를 지원합니다.
네트워크 모드
TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 시스템 트래픽을 가로채므로, 프록시를 수동으로 설정할 수 없는 애플리케이션도 Clash 처리 경로에 포함할 수 있습니다.
활성화하려면 보통 시스템 권한이 필요하며, 라우팅·DNS·우회 목록도 함께 확인해야 합니다. 활성화 후 로컬 네트워크 장치나 시스템 서비스에 문제가 생기면 노드를 반복해서 바꾸기보다 먼저 규칙과 라우팅 범위를 확인하세요.
네트워크 모드
시스템 프록시는 운영체제가 제공하는 HTTP, HTTPS 또는 SOCKS 프록시 설정으로, 브라우저처럼 시스템 설정을 따르는 애플리케이션이 이를 사용합니다.
시스템 프록시의 적용 범위는 애플리케이션이 해당 설정을 읽는지에 따라 달라지며, 모든 트래픽을 가로채는 것과 같지는 않습니다. 클라이언트를 종료한 뒤에도 시스템 프록시가 켜져 있으면 일부 애플리케이션이 더 이상 수신하지 않는 포트에 계속 연결을 시도할 수 있습니다.
네트워크 모드
Redir-Host는 DNS 처리 방식 중 하나로, 클라이언트가 도메인 조회 결과와 원래 도메인을 연결하는 매핑을 유지한 뒤 연결을 처리할 때 원래 도메인을 복원합니다.
비교적 완전한 DNS 설정에 의존하며, 애플리케이션 자체 DNS 조회를 사용하는 경우 추가 처리가 필요할 수 있습니다. DNS 모드를 선택할 때는 규칙 요구 사항, 로컬 네트워크 접속과 애플리케이션별 DNS 처리 방식을 함께 고려해야 합니다.
06 / Resolution and route
이 개념들은 IP 지리 정보 판단, 가상 주소 매핑과 도메인 조회 경로를 다루며, “규칙과 일치했는데도 접속이 비정상적인” 문제를 파악하는 중요한 기초입니다.
시스템과 라우팅
GeoIP 데이터베이스는 IP 주소를 바탕으로 등록된 지리적 영역을 판단하며, 규칙은 이를 이용해 로컬 네트워크·중국 본토·해외 주소 등의 트래픽을 구분할 수 있습니다.
GeoIP 결과는 데이터베이스 버전에 따라 달라지므로 정확한 위치 확인 용도로 사용해서는 안 됩니다. 데이터베이스가 오래되면 규칙이 실제 주소를 다른 영역으로 분류할 수 있으므로, 업데이트 후 주요 분기 결과를 다시 확인해야 합니다.
시스템과 라우팅
Fake-IP 모드는 도메인에 프록시 클라이언트가 관리하는 가상 주소를 반환한 뒤 매핑 테이블을 통해 원래 도메인을 찾습니다.
도메인 정보를 유지하고 규칙 처리와 연동하는 데 도움이 되지만, 실제 DNS 응답이나 하드코딩된 IP에 의존하는 일부 애플리케이션은 우회 설정이 필요할 수 있습니다. 로컬 네트워크 장치에 문제가 생기면 먼저 Fake-IP 제외 목록을 확인하세요.
시스템과 라우팅
DNS 누수는 프록시 트래픽이 프록시 경로를 통과하는 동안에도 도메인 조회가 로컬 네트워크나 예상하지 못한 다른 DNS 서비스에서 처리되는 현상입니다.
문제를 점검할 때는 DNS 모드, 수신 주소, 시스템 리졸버와 애플리케이션 자체의 암호화 DNS 설정을 함께 확인해야 합니다. 브라우저의 프록시 설정만 확인해서는 모든 애플리케이션의 도메인 조회 경로를 파악할 수 없습니다.