Clash rule-providers 고급 설정: AI·개발 도구 YAML 분기 가이드

서론: 거대한 설정 파일을 나누는 이유

Clash를 처음 사용할 때는 하나의 YAML 파일 안에 모든 도메인과 규칙을 직접 작성해도 큰 문제가 없습니다. 그러나 AI 서비스, 개발 도구, 스트리밍, 업무용 SaaS를 함께 사용하기 시작하면 rules 섹션이 지나치게 길어지고 관리가 어려워지는 현상이 발생합니다. 특정 도메인을 추가할 때마다 기존 규칙과 충돌하는지 확인해야 하며, 서비스 제공업체의 도메인이 변경되면 전체 설정을 다시 수정해야 합니다.

rule-providers는 이러한 문제를 해결하는 Clash의 분리형 규칙 관리 기능입니다. AI 서비스용 도메인, 개발 도구용 도메인, 광고 차단 목록 등을 별도의 YAML 파일로 나누고, 메인 설정 파일에서는 각 목록을 불러와 사용할 수 있습니다. 이렇게 구성하면 서비스별 정책을 독립적으로 수정할 수 있고, Git을 이용한 버전 관리와 변경 이력 확인도 쉬워집니다.

이 기능은 단순히 규칙을 여러 파일로 나누는 것에 그치지 않습니다. 같은 도메인에 서로 다른 정책이 적용되는 상황을 줄이고, 일반 웹 트래픽과 업무용 트래픽을 분명하게 구분하여 장애 원인을 빠르게 찾도록 도와줍니다. 다만 rule-provider는 사용하는 코어와 설정 형식에 따라 지원 범위가 다를 수 있으므로, 구형 Clash 클라이언트보다는 최신 Mihomo 코어를 사용하는 환경을 권장합니다.

1rule-provider 구조와 YAML 기본 문법

rule-provider는 크게 provider 정의와 rules에서의 호출 두 부분으로 구성됩니다. provider 정의에는 규칙 파일의 주소, 파일 형식, 새로고침 주기를 작성하고, rules 섹션에서는 해당 provider를 어떤 프록시 그룹으로 보낼지 지정합니다.

먼저 AI 서비스와 개발 도구를 분리한 기본 구조를 살펴보겠습니다. 아래 예시는 원격 URL을 사용하지 않고 로컬 파일을 읽는 방식이므로, 테스트 단계에서 가장 안전하게 시작할 수 있습니다.

type: file은 로컬 파일을 사용한다는 뜻입니다. path는 메인 설정 파일을 기준으로 한 상대 경로이며, Clash Verge Rev에서 프로필을 저장하는 위치와 실제 실행 권한에 따라 경로가 달라질 수 있습니다. 경로를 잘못 입력하면 provider가 로드되지 않으므로, 가능하면 프로필 파일과 같은 폴더 안에 rules 디렉터리를 만들고 상대 경로를 단순하게 유지하세요.

• behavior: domain: 도메인 단위 규칙을 읽습니다. DOMAIN, DOMAIN-SUFFIX 형태의 목록에 적합합니다.
• behavior: classical: 여러 종류의 Clash 규칙 문법을 함께 사용할 때 사용합니다. IP, 키워드, 도메인 규칙이 섞인 목록에 적합합니다.
• interval: 원격 provider를 사용하는 경우 업데이트 간격을 초 단위로 지정합니다. 로컬 파일을 수동 관리한다면 필수적인 값은 아니지만, 자동 갱신 정책과 함께 사용하기 좋습니다.
• RULE-SET: provider의 모든 규칙을 한 번에 호출하는 명령입니다. provider 이름과 연결할 정책 그룹을 정확히 일치시켜야 합니다.

2AI·개발 도구용 규칙 파일 작성

provider 파일은 일반 YAML 설정 파일과 달리 전체 프록시 설정을 포함하지 않습니다. 해당 서비스의 요청을 어떻게 식별할지만 작성하고, 실제 연결 대상은 메인 설정 파일의 RULE-SET 뒤에서 결정합니다. 이 분리를 지켜야 동일한 규칙 목록을 여러 그룹에 재사용하기 쉽습니다.

AI 서비스 provider 만들기

AI 서비스는 웹 페이지 도메인과 정적 리소스, 사용자 콘텐츠 서버가 서로 다른 경우가 있습니다. 한 도메인만 등록하면 로그인은 되지만 대화 생성이나 파일 업로드가 실패할 수 있으므로, 서비스의 주요 도메인을 기능별로 확인해야 합니다.

behavior: domain provider에서는 목록 파일에 payload:를 두고 도메인 규칙을 작성하는 방식이 일반적입니다. 다만 모든 AI 서비스가 동일한 정책을 요구하는 것은 아닙니다. API 호출은 안정적인 고정 노드가 필요할 수 있고, 웹 검색이나 일반 문서 서비스는 다른 그룹으로 분리하는 편이 더 적합할 수 있습니다.

개발 도구 provider 만들기

개발 도구는 소스 코드 저장소, 패키지 레지스트리, 컨테이너 이미지 저장소, 문서 사이트가 함께 사용됩니다. 개발 중에는 GitHub 페이지는 열리지만 Git 작업이나 패키지 다운로드가 실패하는 경우가 있으므로, 브라우저 도메인만 등록하지 말고 실제 작업에 필요한 엔드포인트를 함께 고려해야 합니다.

회사 내부 Git 서버나 사설 패키지 저장소는 공개 provider에 넣지 않는 것이 좋습니다. 내부 도메인은 별도의 local-dev.yaml에 분리하고 DIRECT 또는 사내 프록시 그룹을 적용하면, 공개 목록이 바뀌어도 내부 업무 경로가 영향을 받지 않습니다.

3프록시 그룹과 규칙 우선순위 최적화

provider를 작성했더라도 프록시 그룹이 없거나 규칙 순서가 잘못되면 기대한 경로로 연결되지 않습니다. 먼저 AI와 개발 도구를 받을 그룹을 정의하고, 그 다음에 RULE-SET을 상단에 배치해야 합니다.

규칙은 일반적으로 위에서 아래로 평가되며, 먼저 일치한 규칙이 적용됩니다. 따라서 MATCH,PROXY를 위쪽에 작성하면 뒤에 있는 provider 규칙이 도달하지 않습니다. 또한 같은 도메인을 AI provider와 광고 차단 provider에 동시에 넣으면 어느 목록이 먼저 선언되었는지에 따라 결과가 달라질 수 있습니다.

• 예외 규칙을 가장 위에 배치: 사내 도메인, 로컬 네트워크, 직접 연결이 필요한 서비스는 provider보다 앞에 둡니다.
• 전용 provider를 일반 provider보다 먼저 배치: AI·개발 도구처럼 명확한 목적이 있는 목록을 넓은 해외 규칙보다 위에 둡니다.
• 최종 MATCH는 마지막에 배치: 어디에도 일치하지 않는 트래픽의 기본 동작을 결정합니다.
• no-resolve를 신중히 사용: IP 기반 규칙에서 DNS 확인을 줄일 수 있지만, 도메인 기반 분기와 함께 사용하면 예상과 다른 결과가 생길 수 있습니다.

4원격 provider와 Git 버전 관리

로컬 파일이 안정적으로 동작하는 것을 확인한 다음에는 GitHub나 사내 웹 서버에 provider를 올려 여러 기기에서 공유할 수 있습니다. 원격 파일을 사용하면 노트북과 휴대폰의 규칙을 동일하게 유지할 수 있지만, 외부 URL이 응답하지 않는 순간 규칙 업데이트가 실패할 수 있으므로 항상 마지막으로 정상 저장된 파일을 보존해야 합니다.

url은 원격 파일 주소이고 path는 다운로드한 파일을 캐시할 위치입니다. 원격 서버가 HTTPS를 사용하고, 응답 본문이 순수한 YAML인지 확인하세요. 웹 페이지의 HTML 오류 화면이 YAML 파일로 저장되면 provider 파싱 오류가 발생합니다. 비공개 저장소의 인증 URL을 설정 파일에 직접 넣는 것도 피해야 합니다. 주소가 유출되면 토큰이 함께 노출될 수 있기 때문입니다.

Git으로 규칙을 관리할 때는 한 번에 너무 많은 도메인을 추가하지 말고 변경 이유를 커밋 메시지에 남기는 것이 좋습니다. 예를 들어 add package registry for team A처럼 서비스와 목적을 기록하면 나중에 특정 도메인이 왜 추가되었는지 쉽게 확인할 수 있습니다. 배포 전에는 YAML 문법 검사, 중복 도메인 검사, 실제 연결 테스트를 순서대로 수행하세요.

5충돌과 연결 장애 진단 방법

규칙을 분리한 뒤 접속 문제가 발생하면 먼저 프록시 노드 자체를 의심하기보다 provider 로드 상태, 규칙 순서, DNS 결과를 차례로 확인해야 합니다. Clash Verge Rev의 규칙 또는 연결 로그에서 요청한 도메인과 적용된 규칙을 확인하면 실제로 어떤 provider가 선택되었는지 알 수 있습니다.

• provider가 보이지 않는 경우: 이름의 대소문자, 파일 경로, YAML 들여쓰기, behavior 값을 확인합니다.
• provider는 로드되지만 규칙이 적용되지 않는 경우: RULE-SET 이름이 provider 키와 동일한지, 그 앞에 더 넓은 규칙이 있는지 확인합니다.
• 로그인만 되고 기능이 실패하는 경우: 정적 리소스, API, 업로드 도메인이 목록에서 빠졌을 가능성이 큽니다.
• Git과 패키지 다운로드만 느린 경우: 브라우저 도메인과 저장소 도메인을 분리하고, Dev-Group의 노드별 지연과 대역폭을 비교합니다.
• 갑자기 모든 연결이 실패하는 경우: 원격 provider 서버가 다운되었는지 확인하고, 캐시된 로컬 파일로 임시 전환합니다.

문제를 재현할 때는 한 번에 여러 값을 바꾸지 않는 것이 중요합니다. 먼저 provider 하나만 비활성화하여 변화가 있는지 확인하고, 다음으로 해당 규칙을 임시로 직접 작성해 비교하세요. 직접 작성한 규칙은 작동하지만 provider만 실패한다면 파일 형식이나 provider 선언 문제일 가능성이 높습니다.

자주 묻는 질문

모든 Clash 클라이언트에서 rule-provider를 사용할 수 있나요?

기본적인 rule-provider는 여러 Clash 계열 클라이언트에서 지원되지만, type: http, 스크립트, 프로세스 규칙처럼 확장 기능이 포함된 설정은 코어별 차이가 있습니다. Clash Verge Rev나 Mihomo 기반 클라이언트에서 설정을 먼저 검증하고, ClashX 또는 모바일 클라이언트로 옮길 때 지원되는 필드만 남기는 것이 안전합니다.

DOMAIN과 DOMAIN-SUFFIX 중 무엇을 사용해야 하나요?

정확히 하나의 호스트만 지정하려면 DOMAIN을 사용하고, 해당 도메인의 하위 호스트까지 포함하려면 DOMAIN-SUFFIX를 사용하세요. 서비스가 여러 하위 도메인을 사용한다면 suffix가 편리하지만, 너무 넓은 상위 도메인을 선택하면 관련 없는 서비스까지 같은 프록시 그룹으로 전송될 수 있습니다.

원격 provider 업데이트가 실패하면 인터넷도 끊기나요?

대부분의 경우 이전에 캐시된 provider 파일이 남아 있어 기존 규칙은 계속 동작합니다. 그러나 최초 다운로드 전에 실패했거나 캐시 파일이 손상되면 해당 RULE-SET이 적용되지 않을 수 있습니다. 중요한 환경에서는 로컬 백업 파일과 마지막 정상 커밋을 보관하고, 업데이트 실패 시 로그를 확인한 뒤 수동으로 되돌리세요.

같은 도메인이 두 provider에 들어가면 어떻게 되나요?

규칙은 위에서 아래로 평가되므로 먼저 일치한 provider의 정책이 적용됩니다. 따라서 AI provider와 일반 프록시 provider에 동일한 도메인이 있다면 AI provider를 먼저 선언해야 합니다. 중복을 완전히 제거하거나, 예외 규칙을 가장 위에 두는 방식이 장기적으로 더 관리하기 쉽습니다.