Clash 커널
설정을 읽고 프록시 연결을 수립하며 로컬 포트를 열고 규칙을 적용하는 핵심 프로그램입니다. 그래픽 클라이언트는 보통 제어 계층일 뿐 실제 트래픽 처리는 커널이 담당합니다. 시작 오류를 조사할 때는 클라이언트 화면 로그와 커널 실행 로그를 따로 확인해 두 프로세스를 혼동하지 않아야 합니다.
INDEX / 06 GROUPS
사용 상황별로 찾기
먼저 문제가 발생한 단계에 맞는 범주로 이동하세요. 설정 오류는 구독과 설정, 연결은 되지만 라우팅이 맞지 않으면 규칙과 정책 그룹, 앱이 제어되지 않으면 프록시와 터널 또는 플랫폼 연동을 확인하면 됩니다.
BAY A / RUNTIME
커널과 클라이언트
네트워크 트래픽을 처리하는 커널, 조작 화면을 제공하는 클라이언트, 그리고 두 구성 요소가 함께 사용하는 설정 및 데이터 디렉터리를 구분합니다.
mihomo
Clash Meta를 이어 유지 관리하는 프록시 커널 프로젝트로, 규칙 기반 라우팅, TUN, DNS 강화와 다양한 프로토콜 기능을 제공합니다. 일부 클라이언트에서는 Meta 커널 또는 mihomo 커널로 표시됩니다. 클라이언트 버전과 mihomo 버전은 별도의 릴리스 기록이므로 기능을 비교할 때 각각 확인해야 합니다.
그래픽 클라이언트
프록시 커널을 감싸고 구독 가져오기, 정책 전환, 로그 확인과 시스템 프록시 제어 같은 시각적 기능을 제공하는 데스크톱 또는 모바일 앱입니다. 같은 커널을 사용하더라도 클라이언트마다 설정 디렉터리, 권한 요청과 시스템 연동 방식이 다를 수 있습니다. 클라이언트를 바꾸기 전에 기존 설정을 바로 가져올 수 있는지 확인하세요.
설정 디렉터리
YAML 설정, 규칙 세트, GeoIP 데이터, 캐시와 로그를 저장하는 로컬 디렉터리입니다. 그래픽 클라이언트는 설정마다 별도 하위 디렉터리를 만들거나 업데이트 중 임시 파일을 생성할 수 있습니다. 문제를 해결할 때는 실행 로그에서 실제 로드 경로를 먼저 확인한 뒤 해당 파일을 수정해, 사용하지 않는 복사본을 편집하지 않도록 하세요.
BAY B / TRAFFIC
프록시와 터널
트래픽이 커널로 들어오는 방식, 원격 노드에 연결하는 방식, 시스템 프록시와 TUN의 제어 범위 차이를 설명합니다.
노드
원격 프록시 연결을 수립하기 위해 설정에 등록하는 서버 항목으로, 일반적으로 주소, 포트, 프로토콜과 인증 매개변수를 포함합니다. 노드 이름은 표시용 레이블일 뿐 회선 품질이나 실제 위치를 판단할 근거가 아닙니다. 노드를 사용할 수 없을 때는 연결 로그를 통해 DNS 실패, 핸드셰이크 실패, 인증 오류와 원격 시간 초과를 구분해야 합니다.
지연 시간
클라이언트가 테스트 대상에 요청을 보낸 뒤 결과를 받을 때까지 걸리는 시간으로, 보통 밀리초로 표시합니다. 지연 시간은 테스트 주소, 네트워크 혼잡, 원격 부하와 측정 방식의 영향을 받습니다. 지연 시간이 짧다고 반드시 대역폭이 큰 것은 아니며 실제 전송 속도는 패킷 손실, 회선 용량과 대상 사이트 응답에도 좌우됩니다.
시스템 프록시
운영체제의 HTTP, HTTPS 또는 SOCKS 프록시를 Clash의 로컬 수신 포트로 지정합니다. 브라우저와 시스템 네트워크 설정을 따르는 대부분의 데스크톱 앱은 이 경로를 사용하지만 자체 네트워크 스택을 구현한 프로그램은 우회할 수 있습니다. 시스템 프록시가 켜져 있는데도 앱이 직접 연결되면 먼저 앱 자체의 프록시 설정을 확인하세요.
TUN 모드
가상 네트워크 인터페이스로 시스템 IP 트래픽을 받은 뒤 커널이 직접 연결할지 프록시를 사용할지 판단합니다. 시스템 프록시 설정을 읽지 않는 앱도 제어할 수 있지만 DNS와 라우팅 문제를 확인하는 경로도 달라집니다. 활성화하려면 해당 시스템 권한이 필요하며 가상 네트워크 어댑터, 라우팅 테이블과 다른 네트워크 도구의 충돌을 점검해야 합니다.
BAY C / ROUTING
규칙과 정책 그룹
연결이 매칭 조건에서 정책 그룹으로 들어가는 방식과 규칙 순서, 외부 규칙 세트 및 지역 데이터가 결과에 미치는 영향을 설명합니다.
규칙 기반 라우팅
도메인, IP, 프로세스 또는 규칙 세트로 연결을 매칭한 뒤 지정된 정책 그룹으로 전달합니다. 대부분의 설정은 위에서 아래로 규칙을 검사하고 먼저 매칭된 항목을 실행하므로, 더 구체적인 규칙을 넓은 규칙보다 앞에 배치하는 것이 일반적입니다. 라우팅 오류가 발생하면 로그에서 매칭된 규칙 유형과 대상 정책을 확인해야 합니다.
정책 그룹
여러 노드나 다른 정책 그룹을 하나의 논리적 출구로 구성해 수동 선택, 자동 테스트, 부하 분산 또는 장애 조치를 적용합니다. 규칙은 보통 정책 그룹을 가리키므로 노드가 바뀌어도 규칙을 하나씩 수정할 필요가 없습니다. 정책 그룹을 지나치게 중첩하면 문제 해결 단계가 늘어나므로 최종 출구를 단계별로 확인해야 합니다.
규칙 세트
용도에 따라 관리하는 도메인, IP 대역 또는 기타 매칭 조건의 모음으로, 로컬 파일이나 원격 주소에서 불러올 수 있습니다. 규칙 세트를 사용하면 기본 설정을 간결하게 유지하고 별도로 업데이트할 수 있습니다. 원격 다운로드에 실패해도 클라이언트가 캐시 버전을 계속 사용할 수 있으므로 업데이트 시각, 다운로드 로그와 실제 매칭 결과를 함께 확인해야 합니다.
GeoIP
IP 주소가 속한 지역을 기준으로 매칭하는 데이터 및 규칙 유형으로, 이미 IP로 해석된 연결을 처리할 때 자주 사용합니다. 실시간 위치 확인 서비스가 아니며 결과는 로컬 데이터베이스에 따라 달라집니다. Clash GeoIP를 업데이트한 뒤에는 커널이 새 파일을 읽었는지 확인해야 하고, 오래된 데이터는 새로 할당된 주소를 잘못된 정책으로 보낼 수 있습니다.
MATCH ORDER
규칙 순서 예시
DOMAIN-SUFFIX먼저 구체적인 도메인 범위를 처리PROCESS-NAME그다음 앱 프로세스로 라우팅을 보완GEOIP이미 해석된 지역 IP 범위를 처리MATCH앞에서 매칭되지 않은 연결을 처리
BAY D / PROFILE
구독과 설정
원격 구독, 현재 설정, YAML 텍스트 형식과 외부 노드 제공자를 구분해 가져오기 및 파싱 단계의 문제를 찾습니다.
구독
서비스 제공자가 게시하고 정기적으로 업데이트할 수 있는 원격 설정 소스입니다. Clash 구독 링크를 성공적으로 가져왔다는 것은 클라이언트가 주소를 저장했다는 뜻일 뿐입니다. 네트워크 요청, 콘텐츠 다운로드와 설정 파싱까지 완료되어야 노드가 화면에 표시됩니다. 구독에 실패하면 응답 상태, 반환된 내용과 파싱 로그를 나누어 확인해야 합니다.
YAML
Clash 설정에 자주 사용하는 텍스트 직렬화 형식으로, 들여쓰기로 객체와 목록의 계층을 표현합니다. 탭 문자, 일관되지 않은 들여쓰기, 누락된 공백 또는 특수 문자를 올바르게 인용하지 않아 파싱이 실패할 수 있습니다. 직접 편집할 때는 기존 계층을 유지하고 한 번에 적은 부분만 수정한 뒤 설정 검사를 다시 실행하세요.
설정 파일
수신 포트, 프록시 노드, 정책 그룹, 규칙, DNS와 TUN 매개변수를 정의하는 YAML 문서입니다. 클라이언트는 여러 설정을 저장할 수 있지만 실행 중에는 현재 활성 항목만 로드합니다. 수정 사항이 적용되지 않으면 파일 저장, 설정 재로드 여부와 화면에 표시된 현재 설정 이름을 확인해야 합니다.
proxy-provider
외부 파일이나 원격 주소에서 프록시 노드 목록을 불러오는 설정 방식으로, 업데이트 간격, 캐시 경로와 상태 점검을 지정할 수 있습니다. 노드 출처를 기본 설정과 분리해 여러 출처를 조합하기에 적합합니다. 제공자 로드에 실패하면 이를 참조하는 정책 그룹이 비어 있을 수 있으므로 정책 그룹만 테스트하지 말고 먼저 제공자 상태를 확인해야 합니다.
BAY E / RESOLVER
DNS와 네트워크
도메인 해석이 Clash로 들어오는 방식, Fake-IP와 Redir-Host의 차이, DNS 누수와 분할 DNS 확인 방향을 설명합니다.
DNS 누수
연결 트래픽은 이미 프록시를 거치지만 도메인 조회는 시스템 기본 해석 경로로 전송되는 현상입니다. 방문 도메인이 노출되거나 DNS 결과와 프록시 출구 지역이 일치하지 않을 수 있습니다. 브라우저 테스트, 시스템 DNS 설정, TUN 상태와 커널 로그를 함께 확인해야 하며 단 한 번의 웹 결과만으로는 원인을 특정하기 어렵습니다.
Fake-IP
커널이 도메인에 예약 주소를 먼저 반환한 다음 연결 단계에서 해당 주소를 원래 도메인으로 매핑하고 규칙을 적용하는 DNS 강화 방식입니다. 도메인 정보를 유지하는 데 유리하지만 일부 로컬 네트워크 기기, 게임 또는 특수 앱이 이 결과를 처리하지 못할 수 있습니다. 호환성 문제가 생기면 특정 도메인을 제외 범위에 추가할 수 있습니다.
Redir-Host
실제 해석 결과를 바로 반환하는 DNS 강화 방식으로, 이후 연결은 주로 실제 IP를 사용합니다. 일반 DNS에 가까운 네트워크 동작을 보이지만 연결 단계에서 도메인 정보가 사라질 수 있어 일부 도메인 규칙은 스니핑이나 다른 메커니즘으로 보완해야 합니다. 모드를 전환한 뒤에는 기존 DNS 캐시를 삭제하고 다시 테스트하세요.
nameserver-policy
도메인 조건에 따라 DNS 서버를 지정하는 설정 항목으로, 서로 다른 도메인을 각기 다른 DNS 경로로 보낼 수 있습니다. 분할 DNS, 로컬 네트워크 도메인 또는 특정 규칙 세트에 자주 사용합니다. 설정할 때 기본 nameserver, fallback과 매칭 조건을 함께 확인해 여러 설정이 겹친 뒤 예상치 못한 결과가 나오지 않도록 해야 합니다.
DNS CHECK PATH
앱 조회
시스템 해석 경로
Clash DNS
분할 DNS 정책
상위 DNS 서버
BAY F / SYSTEM
플랫폼 연동
백그라운드 서비스, 가상 네트워크 어댑터, 프로세스 식별과 우회 범위를 다루며 클라이언트 화면 밖에서 발생하는 운영체제 네트워크 동작을 처리합니다.
시스템 서비스
운영체제의 백그라운드 서비스로 커널이나 보조 구성 요소를 실행하는 방식이며, 사용자 화면을 닫은 뒤에도 네트워크 처리를 계속 제공할 수 있습니다. 서비스가 별도의 계정, 권한과 작업 디렉터리를 사용할 수 있습니다. 화면 상태와 실제 프록시 상태가 다르면 서비스 프로세스, 시작 매개변수와 읽어 오는 설정 경로를 확인해야 합니다.
가상 네트워크 어댑터
TUN 모드가 만들거나 사용하는 논리 네트워크 인터페이스로, Clash로 라우팅된 IP 트래픽을 받습니다. 시스템 라우팅 선택에 관여하지만 실제 네트워크 포트에 해당하지는 않습니다. 인터페이스 생성에 실패하면 관리자 권한, 드라이버 상태, 남은 라우팅 설정과 VPN 또는 가상화 소프트웨어의 네트워크 구성 요소를 점검해야 합니다.
프로세스 매칭
연결을 시작한 프로그램 이름이나 실행 파일 경로를 기준으로 규칙을 선택하는 매칭 방식으로, 특정 앱에 독립적인 정책을 적용할 때 적합합니다. 시스템이 제공하는 프로세스 정보에 의존하므로 컨테이너, 백그라운드 서비스와 일부 모바일 플랫폼에서는 제한될 수 있습니다. 규칙이 매칭되지 않으면 로그에서 실제로 식별된 프로세스 이름을 확인해야 합니다.
우회 목록
시스템 프록시로 처리하지 않을 도메인, 주소 또는 네트워크 대역을 지정하며, 로컬 네트워크 기기, 개발 주소와 시스템 내부 서비스에 주로 사용합니다. 범위가 너무 좁으면 로컬 리소스 접근에 영향을 주고, 너무 넓으면 프록시가 필요한 요청이 직접 연결됩니다. 수정 후 로컬 네트워크 주소와 외부 대상을 각각 확인해야 합니다.
FIELD NOTE / LOOKUP
로그에서 용어 역추적하기
로그에 설정 파싱 오류가 나타나면 YAML, 설정 파일과 proxy-provider를 먼저 확인하세요. 규칙은 매칭되지만 출구가 잘못되면 규칙 기반 라우팅과 정책 그룹을, 연결 수립에 실패하면 노드와 지연 시간을 확인합니다. 일부 앱만 프록시로 들어오지 않을 때는 시스템 프록시, TUN, 프로세스 매칭과 우회 목록을 점검하세요.
용어는 문제 해결 단계를 확인하기 위한 것이며 로그의 결론을 직접 대체하지 않습니다. 한 번에 변수 하나만 변경하고 설정을 다시 불러온 뒤 문제를 재현하여 수정 전후의 로그 변화를 비교하세요.