Clash 분류 규칙: 본토 직결·해외 프록시 최적 전략

왜 분류 규칙이 체감 속도를 가장 크게 바꿀까요?

많은 사용자가 노드 지연만 줄이려고 서버를 바꾸곤 합니다. 그런데 실제로 체감이 둔해지는 원인은 대개 불필요하게 프록시를 한 바퀴 돈 트래픽입니다. 예를 들어 본토 결제 페이지, 지역 캐시가 있는 동영상, 회사 메일, 혹은 이미 가까운 CDN 엣지로 붙을 수 있는 다운로드까지 전부 해외 릴레이를 타면 왕복 시간이 불어납니다. 반대로 해외 API나 차단된 리전의 SaaS를 직결로 밀어버리면 끊기거나 아예 열리지 않습니다.

Clash 계열 클라이언트의 핵심은 도메인·IP·지리 정보를 기준으로 연결 목적지를 정하는 분류 규칙입니다. 정책 그룹이 어떤 프록시 풀을 쓸지 정한다면, 규칙은 그 풀에 들어갈지 말지를 먼저 가르는 관문입니다. 이 관문이 정교할수록 DIRECT 비율은 올라가고, 프록시 큐에 들어가는 요청 수는 줄어듭니다. 그 결과 같은 노드라도 대기열이 짧아져 체감이 좋아집니다.

💡

한 줄 요약 최적화의 목표는 프록시를 많이 쓰는 것이 아니라, 꼭 필요한 요청만 프록시에 올리는 것입니다. 나머지는 과감히 DIRECT로 돌려 보내세요.

설계 철학: 레지던시 망은 직결, 글로벌 SaaS만 릴레이

중국 본토에 거주하거나 본토 서비스를 자주 쓰는 환경이라면, GEOIP,CN이나 공개 Rule Provider에 포함된 국내 도메인 묶음을 DIRECT에 두는 패턴이 널리 쓰입니다. 한국·일본 등 다른 국가에 계신 분이라도 원리는 같습니다. 은행·공공·지역 쇼핑몰처럼 현지 ASN에 붙어야 하는 트래픽은 직결이 안정적이고, 해외 데이터센터로 빼면 오히려 이상 동작하는 경우가 많습니다.

해외 고속 프록시는 지연보다 경로 일관성이 더 중요한 경우가 많습니다. DNS가 한 번 엇나가면 규칙이 아무리 잘 짜여 있어도 잘못된 IP로 매칭되어 DIRECT로 새어 나가거나, 반대로 전부 프록시로 몰릴 수 있습니다. 그래서 스플릿 라우팅을 설계할 때는 규칙 YAML만 보지 말고, dns 섹션의 enhanced-mode, 그리고 Meta 계열의 스니퍼 옵션까지 함께 그림으로 그려 보는 습관이 필요합니다.

규칙 순서와 최종 MATCH

Clash는 위에서 아래로 규칙을 읽으며 첫 매칭에서 결정을 멈춥니다. 그래서 흔한 실수가 큰 덩어리의 GEOIP,CN나 광범위한 IP-CIDR를 너무 위에 두어, 원래 프록시를 타야 할 특정 도메인까지 직결로 흘려보내 버리는 경우입니다. 반대로 특수 예외를 너무 아래에 두면 앞선 광역 규칙에 먹혀 버립니다.

실무에서는 다음 순서를 권장합니다. 첫째, LAN·디바이스 로컬 대역은 DIRECT입니다. 둘째, 프록시 클러스터 자체의 엔드포인트와 관리 도메인은 DIRECT로 고정해 루프를 막습니다. 셋째, 광고 차단이나 보안 정책이 있다면 REJECT 계열을 앞에 둡니다. 넷째, 반드시 릴레이해야 하는 서비스 목록을 DOMAIN·DOMAIN-SUFFIX로 명시합니다. 다섯째, 지역 기반 광역 규칙을 둡니다. 마지막에 MATCH로 정책 그룹을 연결합니다.

# Example skeleton — adjust names to your profile
rules:
  - IP-CIDR,127.0.0.0/8,DIRECT
  - IP-CIDR,198.18.0.0/15,DIRECT
  - DOMAIN-SUFFIX,your-proxy-provider.com,DIRECT
  - DOMAIN-SUFFIX,googleapis.com,PROXY
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

위 예시는 개념용 뼈대입니다. 실제 구독 프로필에는 Rule Provider로 거대한 리스트를 불러오고, 정책 그룹 이름도 PROXY 대신 🚀-Select 같은 별칭을 쓰는 경우가 많습니다. 이름이 무엇이든 rules의 마지막 줄이 전체 기본값이라는 점만 기억하면 됩니다.

Rule Provider로 대규모 규칙을 안전하게 유지하기

수만 줄짜리 도메인을 매번 수동 편집하는 것은 비현실적입니다. rule-providers는 원격 URL이나 로컬 파일에서 규칙 묶음을 주기적으로 받아와 캐시합니다. Loyalsoldier 계열, anti-ADN 등 커뮤니티에서 잘 관리되는 세트를 쓰면 출퇴근 시간에 맞춰 업데이트만 맞춰도 최신 CDN 분기를 따라갈 수 있습니다.

다만 Provider를 여러 개 겹치면 로딩 순서와 behavior에 따라 충돌이 납니다. behavior: classical인지 domain인지에 따라 내부 자료구조가 달라지고, 메모리 사용량도 달라집니다. 저사양 라우터나 구형 PC에서는 과도한 Provider를 줄이고, 꼭 필요한 세트만 남기는 편이 낫습니다. 업데이트 주기도 너무 짧게 잡으면 디스크 I/O와 부팅 시간이 늘어납니다.

GEOIP, IP-CIDR, 그리고 DNS의 삼각 관계

GEOIP,CN는 GeoLite 데이터베이스 품질에 좌우됩니다. 멀티 클라우드 환경에서는 한 IP가 여러 국가 태그를 받는 듯한 애매한 경우도 있으니, 중요한 도메인은 GEOIP에만 맡기지 말고 DOMAIN 규칙으로 한 번 더 고정하는 것이 안전합니다. 기업망에서는 사내망 대역을 IP-CIDR로 먼저 DIRECT 처리해 두면 VPN과 Clash가 동시에 있을 때 경로 꼬임이 줄어듭니다.

fake-ip 모드는 규칙 매칭 속도에 유리하지만, 일부 앱이 가짜 IP를 그대로 캐시해 버리면 이후 DIRECT 분기가 깨질 수 있습니다. 문제가 반복되면 일시적으로 redir-host로 바꿔 원인을 분리해 보세요. TUN 모드와 함께 쓸 때는 DNS 루프에 특히 주의해야 합니다. 자세한 활성화 순서와 점검은 Clash TUN 모드 상세 가이드에서 다루고 있으니, 스플릿 라우팅을 TUN까지 확장할 계획이라면 함께 읽는 것을 권합니다.

정책 그룹: 자동 선택과 폴백을 규칙 뒤에 두기

규칙이 PROXY 정책 그룹을 가리키면, 그 안의 url-test나 fallback이 실제 노드를 고릅니다. 여기서 흔한 오해는 자동 선택이 항상 최저 지연을 고른다는 점인데, 측정 URL과 간격 설정이 맞지 않으면 출퇴근 시간에 엉뚱한 노드가 고정되기도 합니다. 측정 대상은 자신이 주로 쓰는 해외 SaaS와 가까운 리전을 골라야 합니다.

load-balance는 다운로드처럼 세션을 나눌 때 유용하지만, 은행이나 OAuth 흐름처럼 IP 고정이 필요한 서비스와는 상성이 나쁠 수 있습니다. 이런 도메인은 DOMAIN 규칙으로 특정 select 그룹에 묶어 두는 편이 안전합니다. 즉, 규칙 층에서 대략적인 방향을 정하고, 정책 그룹 층에서 미세 조정한다고 이해하면 설정이 단순해집니다.

중국 본토 직결과 해외 고속 프록시를 동시에 노리는 전형 시나리오

위챗·타오바오·바이두 지도처럼 본토 ASN에 최적화된 서비스는 DIRECT가 지연과 오류 모두에서 유리합니다. 반면 npm 레지스트리 미러, PyPI 미러, 대학 CDN 등은 이미 국내에 가까운 거울이 있으므로, 무조건 해외 노드를 태우기보다 미러 도메인을 DIRECT에 두는 편이 빠른 경우가 많습니다. 개발자라면 Git 호스트와 패키지 레지스트리를 DOMAIN 단위로 정리해 두면 팀 전체가 같은 경험치를 얻습니다.

해외 쪽은 검색, 번역 API, 클라우드 콘솔, AI 추론 엔드포인트처럼 지연에 민감한 HTTPS가 많습니다. 이때는 DOMAIN-KEYWORD를 남발하기보다, Rule Provider가 이미 정리한 목록을 가져와 누락분만 DOMAIN으로 보강하는 방식이 유지보수에 유리합니다. 스트리밍은 지역 잠금과 이용약관 이슈가 크므로, 기술적 설명에 그치고 실제 시청 경로는 각 서비스 정책을 준수해야 합니다.

Windows·macOS GUI에서 규칙을 다룰 때의 팁

대부분의 사용자는 YAML을 직접 열기보다 GUI의 프로필 편집기를 씁니다. 이때 중요한 것은 GUI가 생성한 규칙 순서가 구독 병합 과정에서 뒤섞이지 않는지 확인하는 것입니다. 구독이 전체 rules를 덮어쓰면 사용자 정의 DIRECT 줄이 사라질 수 있으니, 커스텀 귀칙을 별도 파일로 빼고 script나 프로필 병합 순서를 클라이언트 문서대로 맞추세요.

Windows에서 처음 환경을 구축한다면 Clash Verge Rev Windows 완전 가이드에서 설치와 TUN, 시스템 프록시 정렬을 먼저 끝낸 뒤 이 글의 순서대로 규칙을 얹으면 학습 비용이 줄어듭니다. macOS 사용자는 ClashX Pro 등에서 동일한 개념이 적용되며, 시스템 DNS와 클라이언트 DNS가 이중으로 잡히지 않게만 정리하면 됩니다.

검증 순서: 로그로 새는 트래픽 잡기

설정을 바꾼 뒤에는 브라우저 개발자 도구와 Clash 로그를 같이 보면서 의도한 경로로 나가는지 확인하세요. 특정 사이트가 느리다면, 먼저 해당 도메인이 어떤 규칙에 매칭됐는지 찍어 보고, DIRECT로 가야 할 트래픽이 PROXY에 붙었는지부터 봅니다. 반대로 PROXY를 타야 할 API가 DIRECT로 새면 DNS 응답이나 SNI 기반 스니퍼 설정을 의심합니다.

점검을 반복할 때는 한 번에 여러 줄을 바꾸지 말고, 블록 단위로 적용하고 되돌리기 쉬운 백업을 남기세요. Git으로 프로필을 관리하면 차이가 명확해져 팀 협업에도 좋습니다. 릴리스 노트를 보면 코어 버전마다 규칙 문법이 미세하게 달라질 수 있으니, Clash Meta(Mihomo) 기준 문서를 북마크해 두면 업그레이드 때 안전합니다.

합법 사용·보안·회사 정책

분류 규칙은 강력한 라우팅 도구일 뿐, 특정 서비스의 지역 제한을 우회하도록 조장하는 목적의 정보는 제공하지 않습니다. 거주지와 접속 대상 서비스의 약관·법령을 반드시 확인하시고, 회사 장비에서는 IT 정책을 따르세요. 오픈소스 프로젝트의 이름과 브랜드는 각자의 상표권자에게 있으며, 본 튜토리얼은 일반적인 기술 이해를 돕기 위한 것입니다.

정리하며

스플릿 라우팅의 최적점은 직결로 돌릴 수 있는 트래픽을 최대화하면서, 꼭 필요한 해외 경로만 고품질 릴레이에 올리는 것입니다. Rule Provider와 GEOIP로 큰 덩어리를 처리하고, 예외는 DOMAIN으로 조여 주면 유지보수와 속도를 동시에 잡을 수 있습니다. DNS·TUN·시스템 프록시까지 한 줄기로 맞춰야 체감이 살아납니다.

Clash 계열은 규칙 기반이라 한 번 흐름을 이해하면 이후 확장이 쉽습니다. 설치 파일 출처가分散해 있어 혼동하기 쉬운데, ClashFast 다운로드 페이지에서 플랫폼별 클라이언트를 모아 두었으니 변조 위험을 줄이면서 시작할 수 있습니다. 프로필을 손에 익혔다면 → Clash를 무료로 내려받아 분류 규칙을 직접 튜닝해 보세요.