Clash
Clash ecosystemClash는 원래 규칙 기반 프록시 코어를 가리키며, 호환되는 설정 방식을 사용하는 클라이언트 생태계 전체를 뜻하기도 합니다. “Clash 설정 지원”이라고 해서 모든 클라이언트가 같은 필드나 프로토콜을 지원한다고 볼 수는 없습니다. 설정 오류를 확인하기 전에 설치 파일이나 창 제목만 기록하지 말고 실제 실행 중인 코어 이름부터 확인하세요.
설정 용어 / 해당 필드 / 사용 시 주의점
설정 주제별로 용어를 찾아보세요. 각 항목은 개념, 관련 필드, 흔한 오해를 설명합니다. 필드 설명은 mihomo를 기준으로 하며 클라이언트 화면의 명칭은 다를 수 있습니다.
연결을 처리하는 코어와 설정을 관리하는 인터페이스를 먼저 구분한 다음, 문제가 어느 계층에서 발생했는지 확인하세요.
Clash는 원래 규칙 기반 프록시 코어를 가리키며, 호환되는 설정 방식을 사용하는 클라이언트 생태계 전체를 뜻하기도 합니다. “Clash 설정 지원”이라고 해서 모든 클라이언트가 같은 필드나 프로토콜을 지원한다고 볼 수는 없습니다. 설정 오류를 확인하기 전에 설치 파일이나 창 제목만 기록하지 말고 실제 실행 중인 코어 이름부터 확인하세요.
mihomo는 Clash.Meta를 이어 발전한 오픈 소스 프록시 코어로, 연결 처리, DNS 확인, 프로토콜 통신, 규칙 실행을 담당합니다. 독립 실행할 수도 있고 그래픽 클라이언트가 실행하고 관리할 수도 있습니다. 설정 문서의 tun, sniffer 같은 필드는 코어 버전과 플랫폼에 따라 사용할 수 있는지 확인해야 합니다.
그래픽 클라이언트는 구독 가져오기, 정책 선택, 로그 확인, 시스템 연동 등의 기능을 코어에 제공합니다. 화면에서 바꾼 설정은 클라이언트가 병합한 뒤 코어에 전달될 수 있으므로 직접 편집한 파일이 최종 적용 파일이 아닐 수도 있습니다. 클라이언트 버전과 코어 버전은 별개의 정보입니다. 문제를 문의할 때 두 버전을 함께 기록하면 화면 캡처만 제공하는 것보다 원인 파악에 도움이 됩니다.
시스템 프록시는 운영체제의 프록시 설정이 클라이언트의 로컬 리스닝 주소를 가리키도록 합니다. 예를 들면 루프백 주소의 HTTP 포트나 혼합 포트가 있습니다. 해당 설정을 따르는 앱만 연결을 프록시로 보내며 일부 명령줄 도구와 게임은 자체 네트워크 설정을 사용합니다. 시스템 프록시를 켜도 모든 트래픽이 처리되는 것은 아니며 DNS 조회 경로가 모두 자동으로 바뀌는 것도 아닙니다.
클라이언트는 보통 특정 노드를 통해 지정된 테스트 주소에 접속한 뒤 구현 방식에 따라 요청 시간을 기록합니다. ICMP ping과 같은 측정이라고 단정할 수는 없습니다. 테스트 주소, 연결 재사용, 시간 제한, 당시 네트워크 상태가 모두 결과에 영향을 줍니다. 테스트 값이 낮다는 것은 이번 테스트 경로의 응답 시간이 짧았다는 뜻일 뿐, 다운로드 대역폭이나 영상 전송 속도, 다른 사이트의 접속 가능성을 바로 알 수 있는 지표는 아닙니다.
프로토콜은 클라이언트와 프록시 서버가 통신하는 방식을 정합니다. 노드 매개변수는 서버 설정과 일치해야 하며, 이름이 같다고 설정을 그대로 바꿔 쓸 수 있는 것은 아닙니다.
프록시 노드는 프록시 서버에 연결하는 데 필요한 매개변수 모음으로, 보통 type, server, port 및 인증 필드를 포함합니다. 노드를 proxies에 직접 정의하거나 노드 제공자에서 불러올 수 있습니다. 표시 이름은 로컬에서 참조하는 식별자일 뿐이므로 이름에 적힌 지역이나 배율만으로 실제 라우팅, 성능, 서비스 제공 범위를 판단할 수 없습니다.
HTTP 프록시는 HTTP 프록시 방식으로 요청을 전달하며, HTTPS 대상에 접속할 때는 보통 CONNECT로 터널을 설정합니다. 설정에 있는 HTTP 프록시 노드는 원격 출구이며 클라이언트가 로컬에 여는 HTTP 리스닝 포트와는 다른 개념입니다. 대상이 HTTPS라고 해서 클라이언트와 프록시 서버 사이도 자동으로 TLS를 사용하는 것은 아니므로 노드의 전송 설정을 확인해야 합니다.
SOCKS5는 TCP 연결과 UDP 전달을 지원하는 프록시 프로토콜이며 사용자 이름과 비밀번호로 인증할 수도 있습니다. 프로토콜 자체에는 전송 암호화 기능이 없으므로 비밀번호가 필요하다고 해서 연결 구간이 암호화된 것은 아닙니다. UDP를 실제로 사용할 수 있는지는 앱이 해당 방식을 사용하는지, 서버가 지원하는지, 노드 설정에서 기능을 활성화했는지에 따라 달라집니다.
Shadowsocks는 암호화 프록시 프로토콜로, mihomo 노드 설정에서 type: ss를 사용합니다. 서버 주소, 포트, 암호화 방식, 비밀번호가 서로 일치해야 하며 노드 이름을 바꾼다고 프로토콜이 변환되지는 않습니다. 플러그인이나 UDP 전달을 사용하는 경우 코어가 해당 기능을 지원하는지 확인하고 서버 매개변수와 일치시켜야 합니다.
Trojan은 TLS로 전송을 보호하는 프록시 프로토콜이며 노드 설정에는 type: trojan을 사용합니다. 연결 성공 여부는 비밀번호뿐 아니라 대상 주소, SNI, 인증서 체인, 전송 방식에도 영향을 받습니다. 인증서 오류가 발생하면 인증서 검증을 건너뛰는 것을 일반적인 해결책으로 삼지 말고 도메인, 기기 시간, 인증서 상태부터 확인하세요.
규칙은 연결의 유형을 판단하고, 정책 그룹은 해당 연결이 최종적으로 사용할 출구를 결정합니다.
규칙 기반 라우팅은 도메인, IP, 프로세스 등의 조건에 따라 연결을 직접 연결, 차단 또는 프록시 출구로 보냅니다. 규칙 모드에서는 보통 rules를 위에서 아래로 확인하며 먼저 일치하는 규칙이 처리 대상을 결정합니다. 구체적인 예외 규칙은 포괄적인 규칙보다 앞에 두세요. 규칙에서 참조하는 정책 그룹 이름이 실제로 존재해야 하며, 전역 모드로 전환하면 연결이 계속 같은 순서로 분기된다고 가정해서는 안 됩니다.
정책 그룹은 여러 노드나 다른 정책 그룹을 묶어 규칙에서 참조할 일관된 출구 이름을 제공합니다. select는 보통 수동 선택, url-test는 테스트 결과에 따른 선택, fallback은 순서대로 사용 가능한 출구를 찾는 데 중점을 둡니다. 선택 결과는 테스트 주소와 매개변수에 따라 달라집니다. 그룹 안의 노드가 사용 가능해 보여도 모든 서비스에 접속할 수 있다는 뜻은 아닙니다.
GeoIP는 데이터베이스에 기록된 IP 할당 정보에 따라 매칭합니다. 예를 들어 GEOIP,CN,DIRECT와 같이 설정할 수 있습니다. 실시간 위치 확인이 아니며 웹사이트의 언어나 운영 주체를 직접 나타내지도 않습니다. CDN 주소 변경도 결과에 영향을 줍니다. 실제로 사용할 데이터 파일은 코어의 데이터 모드에 따라 달라집니다. no-resolve를 추가할 때는 도메인 조회를 유발하는 조건에 어떤 제한이 생기는지도 확인해야 합니다.
GeoSite는 서비스나 용도별로 정리된 도메인 모음이며 GEOSITE 규칙에서 참조할 수 있습니다. 분류명과 포함 범위는 데이터 소스에서 관리하므로 출처마다 같은 분류를 제공한다고 볼 수 없으며 새 도메인이 즉시 반영되는 것도 아닙니다. GeoSite는 도메인 모음과 매칭하고 GeoIP는 IP 할당 정보를 기준으로 하므로 서로 대체할 수 없습니다. 데이터를 업데이트한 뒤에는 로드 로그를 확인하세요.
MATCH는 추가 매칭 조건이 없는 기본 규칙으로, 보통 rules의 마지막에 두어 앞선 규칙에 일치하지 않은 연결을 처리합니다. 대상은 프록시 정책 그룹뿐 아니라 DIRECT 같은 내장 정책일 수도 있으므로 반드시 프록시를 사용해야 하는 것은 아닙니다. 목록 앞쪽에 두면 뒤에 있는 일반 규칙이 매칭될 기회를 잃습니다. 규칙을 계속 추가하기보다 순서를 먼저 확인하는 것이 중요합니다.
DNS 조회 경로와 연결 경로는 별개입니다. 트래픽이 제대로 처리되는지 확인하려면 앱, 운영체제, 코어 설정을 함께 점검해야 합니다.
DNS는 도메인을 IP 주소 등의 레코드로 변환합니다. mihomo의 dns 섹션에서는 내장 DNS 확인 서비스와 업스트림을 설정합니다. nameserver를 지정해도 모든 앱이 자동으로 이 서버를 사용하는 것은 아닙니다. 시스템 리졸버와 브라우저 자체의 암호화 DNS가 다른 경로를 사용할 수 있습니다. 문제를 진단할 때는 누가 조회를 시작했는지, 어디로 요청을 보냈는지, 조회 결과에 해당하는 연결이 어떻게 라우팅되는지 각각 확인하세요.
TUN 모드는 가상 네트워크 인터페이스를 통해 시스템 라우팅으로 전달된 IP 패킷을 받아 시스템 프록시를 따르지 않는 일부 프로그램의 트래픽도 처리할 수 있습니다. 보통 추가 권한, 네트워크 스택, 라우팅 설정이 필요하며 실제 처리 범위는 제외 규칙, IPv6, 다른 VPN의 영향도 받습니다. tun.enable은 설정을 시작하는 항목일 뿐입니다. 라우팅 테이블, 연결 로그, DNS 처리 결과를 함께 확인해야 합니다.
Fake-IP는 도메인 조회에 합성 주소를 반환하고, 코어는 주소와 도메인의 대응 관계를 저장합니다. 연결이 코어에 들어오면 이 대응 정보를 이용해 라우팅합니다. 합성 주소는 대상 서버의 실제 주소가 아니므로 IP 위치 정보 판단에 사용해도 의미가 없습니다. 실제 DNS 결과가 필요한 서비스는 호환성에 맞춰 fake-ip-filter를 설정할 수 있으며, 설정을 바꾼 뒤에는 이전 DNS 캐시의 영향도 고려해야 합니다.
DNS 유출은 도메인 조회가 예상한 경로를 벗어나 의도하지 않은 확인 서버로 전송되는 현상입니다. 시스템 DNS, 앱 자체 DoH, IPv6, 네트워크 전환 후의 폴백 동작을 함께 확인해야 하며 웹사이트에 표시되는 출구 IP만으로 판단할 수 없습니다. 테스트 페이지에 표시된 확인 서버 이름은 참고 자료일 뿐입니다. 실제 설정 의도와 코어 로그를 확인하고 테스트를 반복해 판단하세요. TUN 모드를 사용한다는 사실만으로 결론을 내릴 수도 없습니다.
도메인 스니핑은 HTTP Host나 일부 TLS 핸드셰이크의 SNI처럼 연결에서 확인할 수 있는 프로토콜 메타데이터를 추출해 IP만 확인되는 연결의 도메인 정보를 보완합니다. 임의의 HTTPS 내용을 복호화할 수 없으며 모든 연결에서 도메인을 알아낼 수 있는 것도 아닙니다. sniffer를 활성화한 뒤에는 프로토콜과 대상별로 동작을 확인하세요. DNS 설정이나 정확한 규칙 데이터를 대신하는 기능은 아닙니다.
전체 설정, 노드 모음, 규칙 모음을 구분해야 가져오기 경로와 업데이트 시 덮어쓰이는 항목을 파악할 수 있습니다.
구독은 URL로 노드나 설정을 가져와 업데이트하는 배포 방식이며 프록시 프로토콜은 아닙니다. 링크에서 전체 YAML, 인코딩된 노드 목록 또는 다른 형식의 콘텐츠를 반환할 수 있으므로 클라이언트에 맞는 가져오기 메뉴를 사용해야 합니다. 구독 URL에는 계정 인증 정보가 포함될 수 있으므로 민감한 정보로 취급하세요. 로그나 화면 캡처를 공개할 때는 전체 링크를 숨겨야 합니다. 업데이트에 실패했다고 해서 캐시된 노드가 모두 즉시 만료되는 것은 아닙니다.
YAML은 mihomo 설정에 사용하는 데이터 직렬화 형식으로, 매핑은 필드 관계를 나타내고 리스트는 항목 모음을 나타내며 들여쓰기로 계층을 구분합니다. 들여쓰기에는 공백을 사용하고 특수 문자가 포함된 값은 문법에 맞게 따옴표로 묶어야 합니다. 탭과 공백을 함께 사용하면 안 됩니다. YAML 파서가 파일을 읽을 수 있다는 것은 문법 형식이 맞다는 뜻일 뿐입니다. 필드 유형, 정책 이름 참조, 코어의 필드 지원 여부도 확인해야 합니다.
노드 제공자는 proxy-providers로 정의하며 원격 또는 로컬 소스에서 노드 모음을 불러옵니다. 이후 정책 그룹의 use 필드에서 참조합니다. 노드 업데이트를 규칙 및 정책 그룹 구성과 분리할 수 있어 로컬 라우팅 규칙을 유지하는 설정에 적합합니다. 제공자 소스가 모든 전체 설정 파일을 지원하는 것은 아닙니다. 문제를 진단할 때는 응답 콘텐츠, 캐시 경로, 업데이트 상태, 참조 이름이 서로 일치하는지 확인하세요.
규칙 제공자는 rule-providers로 업데이트 가능한 규칙 모음을 불러오고, RULE-SET 규칙으로 주 규칙 목록에 연결합니다. behavior는 도메인, IP 대역, 클래식 규칙 등 콘텐츠 유형을 구분하고 format은 파일 형식을 지정합니다. 둘 다 데이터 소스에 맞아야 합니다. 제공자를 정의하는 것만으로는 라우팅에 반영되지 않으므로 참조 위치와 rules 안의 순서도 확인해야 합니다.
재정의 및 병합은 구독 설정을 바탕으로 로컬 설정을 유지하거나 추가하는 과정이며, 포트와 DNS를 조정하거나 규칙을 보완할 때 자주 사용합니다. 구체적인 동작은 클라이언트마다 다릅니다. 일부 필드는 전체 교체되고 일부는 병합되며 리스트는 앞이나 뒤에 추가될 수 있습니다. 수정 후 최종 적용 설정을 확인하고 다시 불러오세요. override.yaml은 흔히 사용하는 파일 이름일 뿐, 모든 클라이언트가 자동으로 읽는 공통 설정 경로는 아닙니다.