Clash 오픈소스 생태계 정리: 코어, 클라이언트와 규칙 세트의 관계

세 층 구조: 코어, 클라이언트와 규칙 세트

Clash 생태계의 프로젝트는 세 층으로 나눌 수 있습니다. 코어는 설정을 파싱하고 연결을 맺고 분기를 실행하는, 실제로 트래픽을 처리하는 유일한 부분입니다. 클라이언트는 창과 트레이 아이콘, 구독 관리, 프로세스 감시를 제공할 뿐 규칙을 직접 해석하지 않습니다. 규칙 세트와 데이터 파일은 이름 목록일 뿐이고 코어가 실행 중에 읽어 갑니다. 세 층은 두 종류의 파일로 맞물립니다. 하나는 YAML 설정 파일, 다른 하나는 규칙 데이터 묶음입니다.

층을 나누는 이유는 문제 위치를 가려내기 위해서입니다. 구독 갱신 실패, 연결 수립 실패, 특정 도메인이 엉뚱한 분기로 가는 문제는 각각 클라이언트, 코어, 규칙 세트에서 발생합니다. 먼저 어느 층의 문제인지 판단하고 해당 저장소에서 답을 찾는 편이 클라이언트에서 스위치를 반복해서 눌러보는 것보다 훨씬 효율적입니다.

코어 계보: 원본 Clash, Clash Premium, mihomo

원본 코어와 그 유지보수의 종착점

원본 코어는 Go로 작성된 Dreamacro/clash를 말합니다. 지금 널리 쓰이는 proxies, proxy-groups, rules YAML 구조를 정한 것이 이 프로젝트이며, 모든 클라이언트가 읽는 설정 형식이 여기서 출발했습니다. 2023년 11월 전후로 원본 코어는 업데이트가 중단되고 저장소가 읽기 전용으로 전환됐으며, 같은 시기에 Clash for Windows도 GitHub에서 내려갔습니다.

지원 범위를 분명히 해둘 필요가 있습니다. rule-providers, proxy-providers, tun은 지원하지 않고, 아웃바운드 프로토콜은 Shadowsocks, VMess, Trojan, Snell 중심이며 규칙 유형은 DOMAIN, DOMAIN-SUFFIX, IP-CIDR, GEOIP, MATCH에 집중돼 있습니다. 설정에 tun: 필드가 하나라도 있으면 원본 코어는 곧바로 오류를 내고 종료합니다.

Clash Premium: 클로즈드 소스 바이너리, 본선과 함께 종료

Clash Premium은 원작자가 배포한 클로즈드 소스 무료 코어로, tun, script, rule-providers, proxy-providers 네 가지 기능을 채워 넣었고 한때 macOS에서 TUN 모드를 쓰는 주요 선택지였습니다. 배포는 원본 본선과 함께 멈췄기 때문에 지금은 역사적 의미만 남았습니다. 어떤 문서에 'Premium 코어를 사용하세요'라고 적혀 있다면 그 문서는 대개 2023년 이전에 멈춰 있는 것입니다.

Clash.Meta와 mihomo: 현재의 사실상 본선

MetaCubeX가 관리하는 Clash.Meta는 원본을 기반으로 프로토콜과 설정 기능을 보강한 프로젝트로, 2024년 초 mihomo로 이름을 바꿨습니다. 저장소 주소는 MetaCubeX/mihomo이고 실행 파일 이름과 기본 설정 디렉터리도 mihomo로 함께 변경됐습니다. 지금도 업데이트되는 클라이언트의 내장 코어는 대부분 이것이거나 그 하위 프로젝트입니다.

원본과 비교했을 때 mihomo의 추가분은 네 갈래로 정리됩니다.

• 아웃바운드 프로토콜: VLESS, Hysteria, Hysteria2, TUIC, WireGuard, SSH, ShadowTLS.
• 설정 기능: sub-rule, 논리 규칙(AND / OR / NOT), listeners, sniffer, find-process-mode, geox-url.
• 규칙 세트 형식: YAML과 text 외에 용량이 더 작고 로딩이 빠른 mrs 바이너리 형식을 지원합니다.
• 데이터 파일: geoip.dat 외에 geoip.metadb를 쓸 수 있고 ASN 기준 매칭을 지원합니다.

호환은 한 방향입니다. 원본에서 돌아가던 설정은 대체로 mihomo에 그대로 올려도 실행되지만 반대는 성립하지 않습니다. 이전할 때는 mihomo -t -f config.yaml로 먼저 검증하면 어떤 필드가 범위를 벗어나는지 한눈에 보입니다.

클라이언트 층: 누가 관리하고, 누가 2023년에 멈췄는가

클라이언트는 설정 형식을 정의하지 않고 세 가지만 결정합니다. 어떤 코어를 내장했는지, 설정 파일을 어디에 두는지, 인터페이스에 어떤 스위치를 노출하는지입니다. 그래서 클라이언트를 고를 때 첫 번째 기준은 코어 출처이고, 두 번째가 UI 취향입니다.

Clash Verge는 원 저장소가 중단된 뒤 커뮤니티가 Clash Verge Rev로 이어받았고, 코어는 mihomo로 교체됐으며 구독 관리와 profile 구성 방식은 그대로 이어졌습니다. 데스크톱에서 아직 Clash for Windows를 쓰고 있다면 mihomo 기반 클라이언트로 옮기는 것이 변경 폭이 가장 작습니다. YAML은 손댈 필요 없이 설정을 다시 가져오기만 하면 됩니다.

iOS는 다른 경로

iOS에는 Clash 코어를 그대로 재사용하는 클라이언트가 없습니다. App Store의 Stash 같은 앱은 자체 규칙 엔진을 구현하고 Clash 스타일 YAML만 읽습니다. 'iOS에서 Clash 설정을 가져올 수 있다'는 말은 형식 호환이라는 뜻이지 코어가 같다는 뜻이 아닙니다. 판단 방법은 간단합니다. tun, script, rule-providers 같은 필드가 iOS에서 어디까지 지원되는지는 각 앱의 자체 문서를 기준으로 봐야 하고, 데스크톱 경험을 그대로 적용하면 안 됩니다.

설정 디렉터리: 코어 기본값과 클라이언트 관리

코어를 단독으로 실행할 때 원본은 기본적으로 ~/.config/clash/를 읽고, Windows에서는 %USERPROFILE%\.config\clash\로 펼쳐집니다. mihomo는 ~/.config/mihomo/로 바뀌었습니다. GUI 클라이언트는 보통 이 부분을 대신 처리합니다. 예를 들어 Clash Verge Rev는 profile과 규칙 캐시를 자체 앱 데이터 디렉터리(Windows에서는 %APPDATA%\io.github.clash-verge-rev.clash-verge-rev\)에 두기 때문에 덮어쓰기 설치를 해도 구독이 지워지지 않습니다. 문제를 추적할 때는 YAML을 반복해서 확인하기보다 코어가 실제로 어느 파일을 읽는지 먼저 확인하는 편이 효과적입니다.

규칙 세트와 데이터 파일: 가장 자주 갱신되는 층

규칙 세트는 네트워크 구현이 전혀 없는 순수한 목록입니다. 코어는 rule-providers로 목록을 가져와 RULE-SET으로 참조하거나, GEOSITE, GEOIP로 컴파일된 dat 파일을 읽습니다. 이 층은 갱신이 가장 잦고, 코어의 일부로 오해받기도 가장 쉽습니다.

자주 쓰이는 저장소 몇 가지:

• Loyalsoldier/clash-rules: domain과 ipcidr로 묶인 rule-provider로, release 브랜치에서 reject.txt, direct.txt, proxy.txt, gfw.txt, cncidr.txt 같은 파일을 제공하므로 rule-providers에 바로 넣을 수 있습니다.
• blackmatrix7/ios_rule_script: 서비스별로 분리된 규칙 세트로, 경로가 rule/Clash/<서비스명>/<서비스명>.yaml 형태이며 스트리밍과 AI 서비스의 세분화된 목록을 대부분 찾을 수 있습니다.
• MetaCubeX/meta-rules-dat: mihomo용으로 컴파일된 geosite.dat, geoip.dat, geoip.metadb, country.mmdb를 제공하고 mrs 형식의 개별 규칙 세트도 함께 올라옵니다. 상위 데이터는 v2fly의 domain-list-community에서 옵니다.
• ACL4SSR/ACL4SSR: ACL4SSR_Online.ini로 대표되는 규칙 템플릿으로, 보통 구독 변환 도구와 함께 사용합니다.
• tindy2013/subconverter: Clash 형식이 아닌 구독 링크를 Clash YAML로 변환합니다. 형식 변환만 담당하고 실행에는 관여하지 않습니다.

rule-providers:
  reject:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/reject.txt"
    path: ./ruleset/reject.yaml
    interval: 86400
  cn-domain:
    type: http
    behavior: domain
    format: mrs
    url: "https://github.com/MetaCubeX/meta-rules-dat/raw/meta/geo/geosite/cn.mrs"
    path: ./ruleset/cn.mrs
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - RULE-SET,cn-domain,DIRECT
  - GEOSITE,geolocation-!cn,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

이 설정에서 format: mrs는 mihomo만 읽을 수 있고, interval: 86400의 단위는 초이므로 24시간마다 목록 갱신을 확인한다는 뜻입니다. rules 섹션은 구체적인 것에서 넓은 것 순으로 배치하고 일치하면 멈추며 마지막 MATCH가 나머지를 처리합니다. 이것이 설정이 완전한지 판단하는 최소 조건이기도 합니다.

GEOSITE / GEOIP와 RULE-SET의 선택

• GEOSITE, GEOIP는 로컬 dat 파일을 읽고 매칭이 메모리에서 끝나므로 속도가 빠른 대신 전체 패키지 용량이 크고 갱신 단위가 데이터베이스 전체입니다.
• RULE-SET은 provider 단위로 개별 목록을 가져오므로 세분화가 가능하고 교체하기 쉽지만, provider마다 HTTP 요청 한 번과 로컬 캐시 한 벌이 필요합니다.
• mihomo에서 geodata-mode: true이면 GEOIP 규칙은 geoip.dat를 읽고, 기본값은 country.mmdb를 사용합니다. geox-url과 함께 쓰면 데이터 소스를 미러 주소로 돌려 다운로드 실패를 피할 수 있습니다.

설정 호환성: 실행 가능한 점검 순서

1. 먼저 코어 이름과 버전을 봅니다. 클라이언트 설정에 mihomo 또는 Clash.Meta가 표시되면 Meta 계열이고, Clash만 적혀 있고 업데이트 시점이 2023년에 멈춰 있다면 원본 코어입니다.
2. 다음으로 고급 필드를 확인합니다. 설정에 tun, rule-providers, proxy-providers, script, listeners, sub-rule 중 하나라도 있으면 원본 코어는 곧바로 오류를 내고 종료합니다.
3. 코어에 내장된 검증 옵션으로 한 번 돌려봅니다. mihomo -t -f config.yaml은 파싱만 하고 실행하지 않으며, 원본 코어도 -t를 지원합니다.
4. 로그의 첫 번째 오류를 읽습니다. unsupported proxy type은 프로토콜, unsupported rule type은 규칙 문제이며 둘 다 코어 버전 문제이므로 설정 문법을 고쳐도 소용없습니다.
5. 마지막으로 포트를 봅니다. mixed-port(흔히 7890)와 external-controller(흔히 127.0.0.1:9090)가 다른 프로세스에 점유되지 않았는지 확인합니다. 대시보드가 열린다면 코어는 정상 기동한 것이고 남은 문제는 모두 규칙 층에 있습니다.

어떤 저장소를 지켜볼까

사용 시나리오별로 대응하는 저장소는 다음과 같습니다.

• 데스크톱 일상 사용: 클라이언트 자체의 릴리스 주기를 보고, 코어 업데이트는 클라이언트를 따라갑니다. 따로 올려야 할 때는 클라이언트 설정의 코어 버전 항목에서 수동으로 업데이트합니다.
• TUN, VLESS, Hysteria2, 논리 규칙이 필요할 때: MetaCubeX/mihomo 저장소와 공식 문서를 기준으로 하고, 설정 필드도 문서를 기준으로 확인하세요. 예전 튜토리얼을 기준으로 삼으면 안 됩니다.
• 라우터: OpenWrt에서는 OpenClash를 쓰거나 SSH로 ShellClash를 배포합니다. 둘 다 내장 코어는 mihomo입니다.
• 분기 정확도: Loyalsoldier/clash-rules는 필요할 때 가져오는 목록을, MetaCubeX/meta-rules-dat는 dat와 mrs 데이터를 담당합니다. 이 두 저장소의 커밋 시간이 새 도메인이 제대로 분기되는지를 좌우합니다.
• 구독 형식 변환: subconverter 또는 Sub-Store. 형식 변환만 하고 실행에는 관여하지 않습니다.

Clash 관련 저장소를 계속 지켜볼 만한지 판단할 때는 세 가지만 보면 됩니다. 최근 커밋 시간, README에 명시된 코어 의존성, 이슈에 관리자가 답변을 달고 있는지입니다. 세 층 구조에서 어느 한 층이 멈춰도 영향 범위는 그 층에만 머뭅니다. 코어가 멈추면 프로토콜과 설정 필드에, 클라이언트가 멈추면 시스템 통합과 UI에, 규칙 세트가 멈추면 분기 정확도에 영향이 갑니다. 이 세 가지를 분리해서 보면 특정 클라이언트가 내려갔다고 해서 설정 전체가 무효라고 생각할 일은 없습니다.