규칙 분류가 Clash의 핵심인 이유
프록시 클라이언트를 쓰는 이유는 단순히 “해외 노드에 연결한다”는 것만이 아닙니다. 은행·회사 VPN·사내 Git·NAS처럼 반드시 직접 연결해야 하는 트래픽과, 지연을 줄이기 위해 특정 지역 노드만 쓰고 싶은 스트리밍, 그리고 나머지 일반 웹 서핑을 한 번에 섞어 쓰면 설정이 금방 엉킵니다. Clash 계열(Mihomo 코어)은 이런 요구를 proxy-groups와 rules 두 축으로 정리해, “한 번 매칭되면 즉시 결정”하는 단순하고 예측 가능한 모델을 제공합니다.
초보 단계에서는 구독이 제공하는 기본 RULE 모드만으로도 충분한 경우가 많습니다. 하지만 업무용 PC, 게임, 원격 개발 환경처럼 트래픽 성격이 뚜렷이 다른 장치를 다룰 때는 커스텀 규칙 그룹을 직접 설계하는 편이 훨씬 안정적입니다. 아래에서는 그 설계 순서를 “출구 만들기 → 규칙으로 연결하기 → 외부 규칙 세트로 유지보수하기” 순으로 풀어 설명합니다. 기초 설치와 화면 조작은 Clash 사용 튜토리얼에서 다루므로, 여기서는 YAML 관점에 집중합니다.
rules는 위에서 아래로 읽히며 처음 맞는 한 줄만 적용됩니다. “나중에 더 구체적인 규칙”을 두었다가 무시되는 일을 막으려면, LAN·직결·예외 도메인을 항상 상단에 두는 습관이 필요합니다.
proxy-groups: 커스텀 “출구” 설계하기
proxies 목록은 개별 서버(또는 서버 그룹)의 정의이고, proxy-groups는 그것들을 묶어 정책 단위로 노출하는 레이어입니다. 규칙 줄 끝에 적는 이름은 결국 여기서 정의한 그룹 이름과 정확히 일치해야 하므로, 이름 짓기부터 팀 내에서 통일하는 것이 좋습니다. 예를 들어 PROXY는 범용 해외 출구, STREAM는 지연에 민감한 스트리밍 전용, WORK는 회사 허용 노드만 묶은 선택 그룹처럼 역할을 드러내는 식입니다.
자주 쓰는 그룹 타입
- select: 사용자가 UI에서 고정 출구를 고릅니다. “항상 이 노드”보다는 “이 카테고리 안에서 골라 쓴다”는 느낌으로 쓰면 관리가 쉽습니다.
- url-test: 짧은 주기로 지연을 재측정해 자동으로 최적 노드를 고릅니다. 스트리밍·일반 브라우징에 흔히 씁니다.
interval과tolerance를 너무 공격적으로 잡으면 출구가 자주 바뀌어 세션이 끊길 수 있으니, 실사용에 맞게 조절하세요. - fallback: 순서대로 헬스체크에 통과하는 첫 노드를 씁니다. “한 대가 죽으면 다음으로”라는 장애 대응용 패턴입니다.
- load-balance: 동일 호스트에 대해 세션 단위로 분산합니다. 특정 다운로드·대역폭 시나리오에서만 신중히 쓰고, 일반 웹에는 과할 수 있습니다.
- relay: 체인 프록시(다중 홉)를 만듭니다. 보안 정책상 이중 출구가 필요할 때 제한적으로 사용합니다.
그룹 안에는 다른 그룹을 중첩해 넣을 수 있습니다. 예를 들어 FINAL 그룹이 url-test를 가리키고, 그 url-test의 후보에 여러 지역 select를 넣는 식으로 “자동 + 수동”을 혼합할 수 있습니다. 다만 중첩이 깊어질수록 디버깅이 어려워지므로, 실무에서는 2~3단 이내로 제한하는 편이 정신 건강에 이롭습니다.
rules와 첫 일치 원칙
rules 섹션은 “도메인·IP·지리 정보·프로세스 이름” 등의 조건을 한 줄씩 나열합니다. 코어는 연결 요청이 들어올 때마다 위에서부터 스캔하다가 처음 성공한 규칙에서 멈춥니다. 그래서 다음과 같은 순서를 추천합니다.
- 로컬·사설 대역 직결 —
IP-CIDR로192.168.0.0/16등을DIRECT로 보냅니다. TUN 모드에서 이걸 빼먹으면 프린터·NAS 접속이 끊기는 대표적인 증상이 납니다. - 신뢰 도메인 직결 — 결제, 본인 인증, 캡차가 도는 국내 사이트는
DOMAIN-SUFFIX로 명시적으로DIRECT처리하는 편이 안전합니다. - 업무·스트리밍 등 목적별 그룹 — 각각 다른
proxy-groups이름으로 보냅니다. - 지역 기반 광역 규칙 — 예를 들어
GEOIP,CN,DIRECT처럼 넓은 범위는 중간 이후에 둡니다. - 마지막 포괄 규칙 —
MATCH,FINAL처럼 남은 모든 트래픽을 한 그룹으로 모읍니다.
DNS 모드가 fake-ip일 때는 규칙 매칭이 도메인 기준으로 일어나는 경우와 IP 기준으로 일어나는 경우가 섞입니다. “규칙은 맞는데 실제 연결이 이상하다”면 DNS 섹션과 규칙의 조합을 의심하고, 클라이언트의 연결 로그에서 최종 매칭 결과를 확인하세요. 프로토콜별 동작 개요는 프로토콜 안내 페이지와 함께 보면 전체 그림이 잡힙니다.
RULE-SET과 rule-providers로 규칙 모듈화
수십~수백 줄의 DOMAIN-SUFFIX를 매번 수작업으로 붙여 넣으면 구독을 갱신할 때마다 충돌이 납니다. rule-providers는 외부 텍스트(또는 내장 어댑터)에서 규칙 묶음을 불러와 RULE-SET 한 줄로 참조하게 해 줍니다. 팀 단위로 “스트리밍 목록”, “광고 차단”, “중국 직결” 같은 조각을 나눠 두면, 메인 설정 파일은 짧게 유지한 채 역할만 읽히게 만들 수 있습니다.
아래는 개념을 보여 주는 축약 예시입니다. 실제 URL·경로·정책 이름은 사용 중인 구독과 클라이언트 환경에 맞게 바꿔야 합니다.
# Example only — adjust paths and policy names for your setup
rule-providers:
streaming:
type: http
behavior: classical
url: "https://example.com/rules/streaming.txt"
path: ./ruleset/streaming.yaml
interval: 86400
proxies:
- name: "node-a"
type: ss
server: 198.51.100.10
port: 8388
cipher: aes-256-gcm
password: "your-secret"
proxy-groups:
- name: STREAM
type: url-test
proxies:
- node-a
- DIRECT
url: "https://www.gstatic.com/generate_204"
interval: 300
rules:
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- RULE-SET,streaming,STREAM
- GEOIP,CN,DIRECT
- MATCH,STREAMno-resolve 플래그를 붙이는 패턴이 흔합니다. 반대로 도메인 규칙만으로는 잡히지 않는 연결을 IP로 잡아야 할 때는 CIDR 줄의 위치와 DNS 결과가 맞물리는지 꼭 로그로 검증하세요.
실전 패턴: 상황별로 트래픽 나누기
아래 표는 “규칙을 새로 쓸 때 자주 쓰는 사고방식”을 정리한 것입니다. 숫자는 우선순위가 아니라 사례 번호입니다.
| 시나리오 | 규칙 설계 포인트 | 그룹 제안 |
|---|---|---|
| 재택 업무 + 일반 웹 | 회사 SSO·화상 회의 도메인은 상단에 DIRECT 또는 전용 WORK 그룹으로 고정합니다. |
WORK(select), PROXY(url-test) |
| 스트리밍·지역 락 | 지역별 노드가 다르면 RULE-SET으로 스트리밍 도메인만 분리하고, 해당 그룹은 지연 안정성 위주 url-test로 둡니다. |
STREAM, PROXY |
| 게임·UDP | 국내 게임 서버는 GEOIP 또는 알려진 IP 대역으로 DIRECT. 해외만 프록시로 보내 지연을 줄입니다. |
GAME, DIRECT |
| 개발 패키지·컨테이너 | 레지스트리 도메인을 명시하면 CLI 도구도 일관되게 같은 출구를 씁니다. 회사 방화벽 정책에 맞춰 예외를 둡니다. | DEV, DIRECT |
일부 Mihomo 빌드에서는 PROCESS-NAME 규칙으로 특정 실행 파일만 다른 그룹으로 보낼 수 있습니다. 다만 OS별로 이름이 달라 유지보수 비용이 크므로, 가능하면 도메인·IP 규칙으로 해결하고 프로세스 규칙은 보조 수단으로 쓰는 편이 낫습니다.
자주 하는 실수와 점검 체크리스트
- 순서 뒤바뀜: 포괄적인
GEOIP나MATCH를 너무 위에 두면 세밀한 예외가 영원히 적용되지 않습니다. - 그룹 이름 오타: 규칙 끝의 정책 이름이
proxy-groups에 없으면 설정 로드 자체가 실패하거나 예기치 않은 폴백으로 이어집니다. - 구독 덮어쓰기: GUI에서 “구독 병합” 시 사용자 규칙이 아래로 밀리면 동작이 바뀝니다. 사용자 규칙 조각을 별도 파일로 두고 병합 순서를 문서화하세요.
- DNS와 규칙 불일치: fake-ip 환경에서 GEOIP가 기대와 다르게 동작하면 DNS·폴백 필터 설정을 함께 점검합니다.
규칙 분류는 한 번 완벽하게 만든다기보다, 로그를 보며 서서히 다듬는 작업에 가깝습니다. 클라이언트에서 연결 기록을 열어 “어떤 규칙에 걸렸는지”를 확인하는 습관만 있어도, 커스텀 그룹을 만족스러울 때까지 조정하는 데 걸리는 시간이 크게 줄어듭니다.
정리: 규칙 그룹은 트래픽의 지도
커스텀 규칙 그룹의 목표는 단순히 “우회”가 아니라, 각 트래픽이 가야 할 최단·최안전 경로를 일관되게 유지하는 것입니다. 출구를 역할별로 나누고, 규칙 목록을 읽기 쉬운 순서로 정렬하며, RULE-SET으로 자주 바뀌는 목록을 밖으로 빼 두면 운영 부담이 확 줄어듭니다. 같은 Mihomo 코어를 쓰더라도 클라이언트 UI와 병합 방식에 따라 편의가 달라지므로, 장기적으로는 “내 설정 조각이 어디에서 합쳐지는지”를 아는 것이 가장 큰 자산입니다.
동일한 코어를 다루는 다른 도구들에 비해, Clash 계열은 규칙 표현이 단순하고 커뮤니티 자료가 풍부한 편이라 학습 곡선이 완만합니다. 초기 설정이 막힌다면 문서의 단계별 안내를 따라가며 YAML을 조금씩 확장해 보세요. 안정적인 클라이언트와 최신 코어 조합이 있으면, 여기서 설계한 그룹 구조를 그대로 오래 유지해도 됩니다.