프록시 클라이언트를 처음 켜면 대부분의 사람이 속도와 도달 가능성 두 가지를 동시에 원합니다. 한국의 뱅킹·쇼핑·공공 포털은 국내 회선으로 직접 나가는 편이 지연과 인증 오류가 적고, 글로벌 SaaS·개발자 도구·일부 미디어는 해외 노드를 거치는 편이 안정적인 경우가 많습니다. Clash 계열이 널리 쓰이는 이유는 바로 이 장면을 한 번에 코드로 표현할 수 있다는 점인데, 그 중심이 RULE(규칙) 모드와 rules: 블록입니다. 이 글에서는 규칙이 어떤 순서로 평가되는지, 어떤 유형이 실무에서 자주 등장하는지, 한국 사용자 관점에서 국내 트래픽은 DIRECT·해외만 선택한 프록시 그룹으로 보내는 패턴을 어떻게 설계하는지를 예제와 함께 풀어 드립니다. 특정 상용 서비스 이름을 전제로 한 조립법이라기보다, YAML을 직접 다루거나 구독 제공자의 규칙 세트를 이해·수정해야 할 때 필요한 판단 기준을 축으로 설명합니다.

왜 “모두 프록시”가 아니라 규칙 분산인가요?

모든 트래픽을 하나의 해외 노드로 몰아넣으면 설정은 단순해지지만 부작용이 분명합니다. 첫째, 국내 연결은 불필요하게 먼 길을 돌아 지연과 패킷 손실이 커집니다. 둘째, 금융·통신사·일부 스트리밍은 출구 IP가 바뀌면 추가 인증·차단을 요구하는 경우가 있습니다. 셋째, 프록시 서버 대역폭을 국내 트래픽까지 쓰게 되어 노드 비용과 큐잉이 빨리 한계에 닿습니다. 반면 규칙 분산은 요청마다 “이 도메인·이 IP는 어디로 보낼까?”를 자동으로 결정합니다. 사용자는 한두 줄의 예외만 추가해 두어도 회사 VPN 대역, 홈 네트워크 스트리밍 박스, 특정 API 엔드포인트처럼 민감한 목적지를 안전하게 분리할 수 있습니다.

모바일과 데스크톱을 함께 쓰는 환경에서는 같은 YAML을 공유하는 경우가 많습니다. 이때 규칙 표가 명료하면 기기마다 세세한 옵션을 건드리지 않고도 동작을 통일할 수 있다는 장점도 있습니다. 요약하면 규칙 분산은 편의를 넘어 체감 품질과 비용을 동시에 관리하는 레이어입니다.

RULE 모드가 하는 일: 평가 순서를 몸에 익히기

클라이언트 UI에서 Rule 또는 규칙 모드를 선택하면, 코어는 연결 요청마다 rules 목록을 위에서 아래로 읽습니다. 처음으로 조건이 참이 되는 한 줄이 선택되고, 그 아래 줄은 무시됩니다. 이 때문에 같은 규칙이라도 한 줄 위아래 차이가 결과를 완전히 바꿉니다. 예를 들어 MATCH,PROXY가 목록 최상단에 있으면 그 아래의 GEOIP 규칙은 사실상 의미가 없어집니다. 반대로 너무 세분화된 예외를 중간중간 넣다 보면, 나중에 추가한 글로벌 패턴이 의도치 않게 특정 트래픽까지 덮어쓸 위험이 있습니다.

실무에서는 다음 순서를 기본 골격으로 두는 경우가 많습니다. (1) 반드시 직결해야 하는 LAN·사설 대역, (2) 반드시 특정 프록시 그룹을 타야 하는 서비스 목록, (3) 지역 기반 분기(GEOIP), (4) 마지막 포섭 규칙 MATCH. 세부 문법은 Mihomo·클래식 Clash 등 코어 버전에 따라 확장 키워드가 조금씩 다를 수 있으므로, 적용 전 사용 중인 코어 문서의 rules 섹션을 함께 열어 두는 습관이 필요합니다.

팁: 규칙을 수정했다면 UI에서 프로필 재로드 후, 로그 패널에서 첫 연결 한두 번이 어떤 규칙 이름으로 찍히는지 확인하세요. 텍스트 에디터와 로그를 번갈아 보면 순서 실수를 빠르게 잡을 수 있습니다.

자주 쓰는 규칙 유형과 선택 기준

규칙 줄은 보통 TYPE,패턴,정책 형태를 따릅니다. 세 번째 칸의 정책은 DIRECT일 수도 있고, proxy-groups에 정의된 이름일 수도 있습니다. 대표 유형은 다음과 같습니다.

  • DOMAIN: 단일 호스트명 전체 일치. 테스트나 특정 API 한 줄만 분리할 때 유용합니다.
  • DOMAIN-SUFFIX: 접미사 기준으로 묶습니다. 예를 들어 같은 회사의 여러 하위 도메인을 한 번에 같은 정책으로 보낼 때 씁니다.
  • DOMAIN-KEYWORD: 호스트 문자열에 키워드가 포함되면 매칭됩니다. 편하지만 과매칭 위험이 있어 신중히 써야 합니다.
  • IP-CIDR: 특정 대역을 정확히 지정합니다. 피어 목록이 고정된 자산 방화벽이나 테스트 장비 대역을 다룰 때 좋습니다.
  • GEOIP: GeoLite 같은 데이터베이스를 이용해 국가 코드로 분기합니다. 한국 사용자에게는 GEOIP,KR,DIRECT 패턴이 대표적입니다.
  • MATCH: 여기까지 규칙에 안 걸린 모든 트래픽을 마지막 정책으로 보냅니다. 거의 항상 목록 맨 아래에 둡니다.

실제 구독 파일에는 수천 줄의 도메인 규칙이 미리 들어 있는 경우가 많습니다. 그럼에도 사용자 정의 규칙 블록을 따로 허용한다면, 개인 사내망과 업무 VPN 대역처럼 공급자가 알 수 없는 목적지를 손으로 넣는 편이 안전합니다. GEOIP는 편리하지만 CDN처럼 국내 서비스라도 해외 POP으로만 연결되는 예외가 있어, 체감 이상이 있으면 DOMAIN 규칙으로 한 번 더 덮어씌우는 전략이 필요합니다.

한국 사용자를 위한 기본 패턴: 국내 직결 + 해외 프록시

아래 예시는 개념을 보여 주기 위한 단순화입니다. 실제 파일에서는 제공자가 넣어 둔 긴 목록 사이에 끼워 넣거나, 사용자 규칙 파일을 병합하는 방식을 씁니다.

# conceptual excerpt — adapt names to your proxy-groups
rules:
  - IP-CIDR,192.168.0.0/16,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - DOMAIN-SUFFIX,corp.example,DIRECT
  - GEOSITE,category-ads-all,REJECT
  - GEOIP,KR,DIRECT
  - GEOIP,private,DIRECT
  - MATCH,proxy-select

여기서 proxy-select 자리에는 클라이언트 Proxies 화면에서 고르는 메인 선택 그룹 이름을 넣습니다. 철자가 하나라도 다르면 로드 단계에서 오류가 나거나 조용히 기본값으로 떨어져 의도와 다른 출구를 탈 수 있습니다. GEOSITE나 광고 차단 규칙은 코어와 규칙 세트를 함께 배포한 경우에만 동작하므로, 자신의 패키지에 포함됐는지 확인해야 합니다.

프록시 그룹과 정책 이름 맞추기

규칙은 단독으로 존재하지 않습니다. proxy-groups에 선언된 이름이 실제 노드 풀·폴백 순서·지연 기반 선택 로직을 담고 있기 때문입니다. 사용자 입장에서 자주 보는 패턴은 다음과 같습니다.

  • select: UI에서 직접 하나를 고르는 그룹. 규칙의 최종 목적지로 자주 쓰입니다.
  • url-test / fallback: 자동으로 살아 있는 노드를 고르는 그룹. 규칙으로 넣기보다 select 아래 단계에서 동작하게 두는 구성이 흔합니다.
  • DIRECT를 포함한 relay 형태: 특정 워크플로에서만 쓰이며, 잘못 넣으면 이중 홉 지연이 커질 수 있습니다.

규칙 분산을 새로 짠다면 이름 표를 메모장에 적어 두고 YAML과 대조하는 방법이 가장 빠릅니다. 특히 영문 대소문자 혼동과 공백은 클라이언트마다 오류 메시지 가독성이 달라 놓치기 쉽습니다.

DNS와 규칙이 맞물리는 지점

브라우저가 이름을 먼저 풀고 나서 IP로 접속한다면, 도메인 규칙은 비교적 직관적으로 동작합니다. 그러나 Fake-IP나 특정 DNS 처리 방식을 쓰면 규칙 매칭 시점의 정보가 달라져 사용자가 예상한 정책과 다른 출구가 선택되기도 합니다. 일반적인 점검 순서는 다음과 같습니다.

  1. 설정 파일의 dns: 블록에서 enhanced-mode나 이름 결정 방식을 확인합니다.
  2. 문제가 되는 도메인을 로그에서 검색해 어떤 규칙 타입으로 매칭됐는지 확인합니다.
  3. 필요하면 해당 도메인을 DOMAIN 규칙으로 명시하거나, DNS 서버 목록을 조정합니다.

DNS만 고치고 규칙 순서는 그대로 두면 같은 증상이 반복되기 쉽습니다. 두 섹션을 한 번에 읽으며 수정하는 편이 시간 낭비를 줄입니다.

주의: 로컬 필터나 회사 보안 에이전트가 자체 DNS를 강제하면 클라이언트 설정과 충돌합니다. 이 경우 규칙만으로는 해결되지 않으므로 OS 단 네트워크 프로필부터 확인해야 합니다.

로그와 트래픽 뷰어로 검증하기

규칙 수정 후에는 반드시 실측을 거치세요. 대부분의 클라이언트는 연결 이벤트마다 선택된 정책 이름과 타깃을 로그로 남깁니다. 확인 포인트는 간단합니다. 국내 금융 도메인이 해외 노드를 타고 있지 않은지, 반대로 차단된 개발자 레지스트리가 실수로 DIRECT로 나가고 있지 않은지입니다. 모바일에서는 배터리 최적화 때문에 로그 버퍼가 짧을 수 있으니, 재현 직후 바로 캡처하는 습관이 좋습니다.

트래픽 분석 탭이 있는 빌드라면 프로세스 이름까지 보여 주어 “어느 앱이 어떤 규칙을 탔는지”를 빠르게 좁힐 수 있습니다. 게임 런처처럼 시스템 프록시를 무시하는 프로그램은 규칙만 고쳐서는 나아지지 않을 수 있으니, 그럴 때는 TUN 계층 문서를 함께 참고해야 합니다.

흔한 실수와 회피 방법

  • MATCH를 너무 위에 두기: 모든 트래픽이 한 정책으로 흡수되어 GEOIP가 무용지물이 됩니다.
  • 중복·상충하는 DOMAIN-KEYWORD: 광범위한 키워드 한 줄이 업무용 도메인까지 덮어씁니다.
  • 코어 확장 문법 혼용: 한 파일 안에서 서로 다른 스펙의 단축 태그를 섞으면 파서 오류가 납니다.
  • GEOIP 데이터 누락: 규칙은 살아 있지만 DB 파일이 없으면 조용히 건너뛰거나 오류를 낼 수 있습니다.

이런 유형의 문제는 UI 스위치 몇 개를 바꾼다고 해결되지 않습니다. 결국 YAML 한 블록과 로그 한 줄을 연결해 보는 작업이 필요합니다.

정리하며: 규칙 분산은 “속도와 안전의 타협점”

규칙 분산을 처음 접하면 도메인 목록의 길이에 압도되기 쉽지만, 핵심은 길이가 아니라 평가 순서와 정책 이름의 정합성입니다. 한 번 바람직한 골격을 만들어 두면 이후에는 예외 몇 줄만 추가하면 되므로 운영 부담이 크게 줄어듭니다.

단순히 “항상 VPN”만 강제하는 통합 클라이언트들은 설정은 쉬워도 국내 트래픽까지 멀리 돌려 보내 체감 지연과 불필요한 차단을 초래하기 쉽습니다. 반면 브라우저 플러그인형 우회는 시스템 전역 트래픽을 커버하지 못하고 앱마다 설정이 갈라져 관리 비용이 커집니다. Clash 계열은 YAML 한 장으로 전역 규칙과 노드 선택을 묶을 수 있고, RULE 모드 덕분에 한국 사용자에게 필요한 국내 직결 패턴을 자연스럽게 유지할 수 있습니다. 최신 코어를 따라가는 빌드라면 새 프로토콜과 세분화된 규칙 세트도 같은 프레임 안에서 확장할 수 있어, 장기적으로 교체 비용도 낮습니다.

최신 Clash 클라이언트 무료 다운로드로 규칙 분산 구성 마무리하기 →