설정 필드 / 개념 구분 / 문제 해결 단서

Clash 용어 사전

인터페이스 설정부터 코어 필드까지 자주 쓰는 용어 24개를 6개 분야로 정리했습니다. 먼저 트래픽이 클라이언트에 들어오는 경로를 구분하고, 규칙이 아웃바운드를 선택하는 방식을 확인한 뒤 DNS와 구독 설정을 살펴보세요.

6개 분야 용어
설정 필드 비교
개별 링크 공유 가능

실행 계층과 사용자 인터페이스

코어와 클라이언트

클라이언트는 관리 인터페이스를 제공하고 코어는 연결을 처리합니다. 문제를 해결할 때 창 제목만 보지 말고 둘의 이름을 모두 기록하세요.

Clash 클라이언트#: GUI / client클라이언트는 구독 가져오기, 프록시 그룹 선택, 로그 확인, 프록시 전환 등의 인터페이스를 제공합니다. 실제 연결은 보통 코어가 처리합니다. 같은 코어를 여러 클라이언트에서 사용할 수 있으며, 인터페이스의 옵션 이름이나 설정 병합 방식은 서로 다를 수 있습니다. 특정 필드가 적용되지 않으면 코어의 지원 여부와 클라이언트가 해당 필드를 최종 실행 설정에 반영했는지 모두 확인하세요.

mihomo 코어#: mihomo / Clash Metamihomo는 Clash Meta에서 발전한 프록시 코어로, 프로토콜 연결, 규칙 매칭, DNS 처리, TUN 등의 기능을 담당합니다. 클라이언트 인터페이스에 Clash라는 문구가 있다고 해서 동일한 코어가 실행 중이라는 뜻은 아닙니다. 설정의 프로토콜 유형, 규칙 문법, 실험적 옵션은 실제로 실행 중인 코어의 문서와 시작 로그를 기준으로 확인하세요.

노드#: proxies / outbound노드는 보통 선택 가능한 원격 프록시 아웃바운드를 뜻하며, 프로토콜 유형, 서버 주소, 포트, 인증 정보를 포함합니다. 클라이언트를 설치해도 연결 도구만 준비된 것이며, 노드는 사용 가능한 설정이나 구독을 통해 받아야 합니다. 노드 이름은 화면에 표시되는 라벨일 뿐, 경로의 위치나 대역폭, 가용성을 증명하지 않습니다. 연결 문제는 실제 설정값과 오류 로그를 확인하세요.

지연 시간 테스트#: url-test / timeout지연 시간은 지정한 테스트 대상과 방식으로 측정한 응답 시간이며 다운로드 속도나 단순한 왕복 시간과 같지 않습니다. 클라이언트마다 테스트 주소가 다를 수 있으므로 결과를 직접 비교하기는 어렵습니다. 시간 초과가 발생하면 테스트 대상에 접근할 수 없는지, 노드 연결이 실패했는지, 조회에 문제가 있는지 확인하고 실제 웹사이트 접속과 로그를 함께 살펴보세요.

로컬 진입점과 원격 전송

프록시 프로토콜

로컬 앱이 연결하는 프록시 진입점과 클라이언트가 원격 서버에 연결할 때 사용하는 프로토콜은 서로 다른 계층에 속합니다.

HTTP 프록시#: HTTP / CONNECTHTTP 프록시를 사용하면 앱이 프록시 주소로 요청을 보냅니다. HTTPS 연결은 보통 CONNECT 방식으로 터널을 설정합니다. 앱에 로컬 HTTP 프록시 주소를 입력했다고 해서 원격 노드도 HTTP 프로토콜을 사용한다는 뜻은 아닙니다. HTTP 프록시 자체가 모든 전송을 암호화하지는 않습니다. 대상 사이트의 HTTPS, 로컬 진입점의 전송, 원격 노드의 암호화는 각각 구분해야 합니다.

SOCKS5#: SOCKS / UDP ASSOCIATESOCKS5는 프록시 진입점에 대상 주소와 연결 요청을 전달하며, 브라우저, 개발 도구, 명령줄 프로그램의 프록시 설정에 자주 사용됩니다. TCP 연결을 전달할 수 있고 UDP 중계 방식도 정의되어 있지만, 실제 UDP 지원 여부는 앱, 클라이언트, 원격 경로에 따라 달라집니다. 도메인을 로컬에서 조회할지 프록시 측에서 조회할지는 해당 앱의 옵션을 확인하세요.

Shadowsocks#: type: ssShadowsocks는 원격 프록시 프로토콜의 하나로, 서버의 암호화 방식과 인증 정보에 맞게 설정해야 합니다. 서버 주소와 포트만으로는 연결되지 않는 경우가 많으며, 플러그인 등 추가 요구 사항도 서버와 일치해야 합니다. 가져온 뒤 연결할 수 없다면 규칙 모드를 탓하기 전에 코어의 해당 방식 지원 여부와 설정값을 확인하세요.

TLS#: TLS / SNI / servernameTLS는 전송 연결을 보호하고 서버의 신원을 확인하며, 여러 프록시 프로토콜의 외부 전송 계층에 사용됩니다. SNI는 핸드셰이크 중 전달되는 서버 이름 정보이며, 인증서 검증에서는 이름 일치 여부와 인증서 신뢰 여부도 확인합니다. 핸드셰이크에 실패하면 시스템 시간, 서버 이름, 인증서 체인을 점검하세요. 인증서 검증을 건너뛰는 방법을 일반적인 해결책으로 사용하지 않는 것이 좋습니다.

연결이 코어에 들어온 다음

규칙과 라우팅

규칙은 연결을 어느 아웃바운드로 보낼지 결정하고, 프록시 그룹은 현재 어떤 노드를 선택했는지 보여줍니다. 두 항목을 함께 확인해야 합니다.

규칙 기반 라우팅#: mode: rule / rules규칙 모드에서는 rules를 위에서 아래로 확인해 연결을 처리하며, 보통 처음 일치한 규칙이 아웃바운드를 결정합니다. 예를 들어 DOMAIN-SUFFIX,example.com,PROXY는 해당 도메인과 하위 도메인을 PROXY로 전달하고, 마지막의 MATCH,PROXY는 앞선 규칙과 일치하지 않은 연결을 처리합니다. 범위가 넓은 규칙을 앞쪽에 두면 뒤의 세부 규칙이 적용되지 않을 수 있습니다.

프록시 그룹#: proxy-groups / select / url-test프록시 그룹은 여러 아웃바운드를 하나로 묶어 규칙에서 참조할 수 있게 하며, 설정은 proxy-groups에서 관리합니다. select 그룹은 직접 선택할 때, url-test 그룹은 지정한 주소의 테스트 결과에 따라 자동 선택할 때 사용합니다. 자동 테스트가 모든 웹사이트에서 가장 빠른 경로를 선택한다는 뜻은 아닙니다. 규칙이 특정 그룹을 가리킨다면 그룹 안에서 현재 선택된 항목도 확인하세요.

GeoIP#: GEOIP,CN,DIRECTGeoIP는 IP 지리 분류 데이터베이스를 기준으로 대상 주소를 매칭해 특정 지역의 주소를 지정한 아웃바운드로 전달할 때 사용됩니다. 도메인 분류를 기준으로 하는 GeoSite와는 다르며, 웹사이트의 운영 주체나 서비스 내용을 이것만으로 판단할 수는 없습니다. 도메인 연결에서 IP 규칙을 적용하려면 먼저 주소를 조회할 수 있으므로 데이터베이스 상태, 조회 결과, 규칙 순서가 최종 매칭에 영향을 줍니다.

규칙 세트#: rule-providers / RULE-SET규칙 세트는 여러 도메인, IP 대역, 매칭 조건을 별도로 관리합니다. rule-providers로 불러온 뒤 RULE-SET 규칙에서 참조합니다. 선언한 동작 유형과 파일 형식은 실제 내용과 일치해야 하며, 파일을 내려받았더라도 기본 설정에서 사용 중이라는 뜻은 아닙니다. 문제를 해결할 때는 로드 로그, 참조 이름, 아웃바운드 이름, 규칙 순서를 차례로 확인하세요.

트래픽 가로채기와 아웃바운드 모드

네트워크 모드

시스템 프록시와 TUN은 트래픽이 들어오는 방식이고, 규칙 모드와 글로벌 모드는 아웃바운드를 선택하는 방식입니다. 하나를 켜도 다른 하나가 자동으로 대체되지는 않습니다.

시스템 프록시#: system proxy / loopback시스템 프록시는 운영체제에 로컬 프록시 주소를 등록해 해당 설정을 따르는 앱이 클라이언트의 수신 포트로 요청을 보내도록 합니다. 일부 게임, 명령줄 프로그램, 자체 네트워크 설정을 사용하는 앱은 시스템 프록시를 사용하지 않을 수 있으므로, 프록시를 켰다고 해서 모든 연결이 가로채지는 것은 아닙니다. 클라이언트를 종료한 뒤 웹페이지에 접속할 수 없다면 운영체제에 종료된 포트를 가리키는 프록시 설정이 남아 있는지 확인하세요.

TUN 모드#: tun / auto-route / dns-hijackTUN은 가상 네트워크 인터페이스와 라우팅 규칙으로 트래픽을 받아 시스템 프록시를 따르지 않는 일부 프로그램까지 처리할 수 있습니다. 필요한 권한이나 서비스 구성 요소가 있어야 할 수 있으며, 실제 적용 범위는 라우팅 제외 항목, 네트워크 환경, 클라이언트 구현에 따라 달라집니다. 다른 VPN과 충돌하면 여러 트래픽 가로채기 도구를 반복해서 전환하기보다 기본 경로와 DNS부터 확인하세요.

글로벌 모드#: mode: global / GLOBAL글로벌 모드에서는 코어에 들어온 연결을 GLOBAL에서 현재 선택한 아웃바운드로 전달하며, 일반적인 rules 라우팅은 적용하지 않습니다. 아웃바운드 선택 방식만 바뀌므로 원래 클라이언트를 우회하던 프로그램까지 자동으로 프록시를 사용하지는 않습니다. 규칙 문제를 임시로 비교할 때 활용할 수 있지만 GLOBAL에서 선택된 항목을 확인해야 합니다. 규칙 모드로 돌아간 뒤에는 기존 규칙의 매칭 결과를 다시 살펴보세요.

혼합 포트#: mixed-port: 7890혼합 포트는 하나의 수신 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받으며, 해당 필드 이름은 mixed-port입니다. 7890은 자주 쓰이는 예시 값일 뿐 모든 클라이언트가 고정으로 사용하는 포트는 아닙니다. 앱에 직접 설정할 때는 현재 적용 중인 값을 확인하세요. LAN의 다른 기기에서 연결할 수 있는지는 수신 주소, allow-lan, 방화벽에도 달려 있으므로 포트 번호만 바꾸면 해결되는 것은 아닙니다.

도메인, 주소, 조회 경로

DNS와 조회

DNS는 주소를 찾고 라우팅 규칙은 연결의 아웃바운드를 선택합니다. 웹사이트가 열린다는 사실만으로 DNS 조회 경로가 예상대로 설정됐다고 볼 수는 없습니다.

DNS 조회#: dns / nameserverDNS는 도메인을 IP 주소 등의 레코드로 변환하며, 앱은 보통 대상에 연결하기 전에 DNS를 조회합니다. 운영체제, 브라우저, 코어가 각각 캐시를 유지하거나 서로 다른 조회 서버를 사용할 수 있으므로 한 곳의 DNS를 바꿔도 모든 앱에 적용되는 것은 아닙니다. 문제를 해결할 때는 대상 도메인 조회, 프록시 서버 도메인 조회, 조회 서버가 연결에 필요한 주소를 얻는 과정을 구분하세요.

Fake-IP#: enhanced-mode: fake-ipFake-IP는 도메인에 매핑 주소를 할당합니다. 앱이 해당 주소에 연결하면 코어가 도메인 정보를 복원해 라우팅에 활용할 수 있습니다. 로그에 표시되는 매핑 주소는 웹사이트 서버의 실제 주소가 아니며, 노드의 위치를 판단하는 데 사용할 수도 없습니다. 실제 조회 결과에 의존하는 앱은 예외 설정이 필요할 수 있습니다. 도메인별로 필터를 설정하고 모든 도메인을 일괄 제외하지 마세요.

DNS 누수#: resolver path / DNS interceptionDNS 누수는 코어에서 처리되어야 할 조회 요청이 다른 조회 서버로 전송되는 등 예상한 경로를 벗어나는 현상입니다. 검사 페이지에 표시된 조회 서버가 전달이나 애니캐스트를 사용할 수 있으므로 이름이나 지역만으로 단정할 수 없습니다. 시스템 DNS, 브라우저의 암호화 DNS, TUN의 DNS 가로채기 설정, 실제 로그를 함께 확인하세요. Fake-IP를 켰다고 모든 DNS 요청이 제어된다는 뜻은 아닙니다.

nameserver-policy#: dns.nameserver-policynameserver-policy는 도메인 매칭 조건에 따라 DNS 업스트림을 지정해 도메인별로 서로 다른 조회 서버를 사용할 수 있게 합니다. 조회 대상을 선택하는 설정이며, 업무 연결이 어떤 노드를 통해 나갈지 정하는 rules를 대신하지는 않습니다. 변경 후에는 매칭 문법, 조회 서버 연결 경로, 기존 캐시를 확인하세요. 캐시에 남은 이전 응답을 새 설정이 적용되지 않은 것으로 오해하지 않도록 주의해야 합니다.

설정 출처와 최종 적용 내용

구독과 설정

구독 업데이트, 로컬 편집, 클라이언트 오버라이드가 동시에 적용될 수 있습니다. 설정 문제를 확인할 때는 코어에 최종 전달된 설정을 기준으로 삼으세요.

구독#: subscription / profile구독은 링크를 통해 노드 목록이나 전체 설정을 배포하며, 포함되는 내용은 제공자와 클라이언트의 가져오기 방식에 따라 달라집니다. 업데이트 성공은 보통 내용을 가져왔다는 뜻일 뿐입니다. 현재 설정이 활성화됐는지, 프록시 그룹이 있는지, 사용 가능한 아웃바운드가 선택됐는지 확인하세요. 구독 링크에는 접근 정보가 포함되는 경우가 많으므로 로그나 화면을 공유할 때 링크와 인증 정보를 숨기고, 공개 URL처럼 전달하지 마세요.

YAML#: config.yaml / indentationYAML은 Clash 설정에 자주 사용하는 구조화 텍스트 형식으로, 들여쓰기로 매핑과 목록의 계층을 표현합니다. 편집할 때는 공백 들여쓰기를 일관되게 유지하고 탭으로 계층을 표시하지 마세요. 특수 문자가 포함된 문자열은 따옴표 사용에 주의해야 합니다. 문법 검사를 통과해도 필드 이름, 노드 참조, 현재 코어의 지원 범위까지 올바르다는 뜻은 아닙니다.

오버라이드#: override / merge / patch오버라이드는 로컬 DNS, 규칙, 기타 설정을 구독 원본과 별도로 저장한 뒤 클라이언트가 병합해 실행 설정을 만드는 방식입니다. 구독 업데이트 후에도 유지해야 할 설정에 유용하지만, 병합 순서와 배열 처리 방식은 클라이언트마다 다릅니다. 규칙이 중복되거나 필드가 사라지거나 순서가 바뀌면 구독 파일과 오버라이드 파일만 비교하지 말고 최종 설정을 확인하세요.

proxy-providers#: proxy-providers / useproxy-providers는 소스별로 노드 목록을 불러오며, 프록시 그룹에서 use로 참조할 수 있어 노드 업데이트와 기본 설정 관리를 분리할 수 있습니다. 프록시 아웃바운드를 불러오는 기능으로, 매칭 조건을 가져오는 rule-providers와는 다릅니다. 소스 파일 형식, 참조 이름, 업데이트 상태를 확인하세요. 제공자를 선언했더라도 사용 가능한 프록시 그룹에서 참조하지 않으면 원하는 선택 목록에 나타나지 않을 수 있습니다.