이 글이 필요한 상황
Clash rule-providers를 검색하는 사용자는 대개 모든 트래픽을 한 번에 프록시로 보내려는 것이 아니라, AI 서비스·개발 플랫폼·일반 웹사이트를 서로 다른 정책으로 나누고 싶어 합니다. 예를 들어 GitHub Copilot, OpenAI API, Anthropic API, Google AI 같은 서비스는 안정적인 프록시 그룹을 사용하게 하고, 국내 패키지 미러나 사내 Git 서버는 DIRECT로 남겨야 할 수 있습니다. 글로벌 모드는 처음에는 간단하지만, 패키지 다운로드 속도가 느려지거나 사내 시스템 접근이 끊기는 순간 원인을 추적하기 어렵습니다.
이 글에서는 Clash Verge Rev와 Mihomo 계열 코어에서 사용할 수 있는 모듈형 규칙 구조를 기준으로 설명합니다. 핵심은 하나의 거대한 YAML 파일에 모든 도메인을 직접 적는 대신, GitHub에서 관리하는 작은 규칙 파일을 rule-provider로 불러오고, 메인 설정에서는 provider의 이름과 우선순위만 조정하는 방식입니다. AI 서비스와 개발 도구가 새 도메인을 추가하거나 엔드포인트를 변경해도 규칙 파일만 수정하면 되므로 여러 기기와 프로필을 운영할 때 특히 유용합니다.
다만 규칙 제공자는 접속을 우회해 주는 서비스 자체가 아닙니다. 어떤 호스트를 어떤 프록시 그룹으로 보낼지 결정하는 데이터 모듈이며, 실제 연결 품질은 사용 중인 노드·DNS·로컬 포트·상류 서버 상태에 좌우됩니다. 따라서 이 글은 특정 제공자나 노드 이름을 추천하기보다, 재현 가능하고 감사하기 쉬운 설정 구조와 점검 순서를 다룹니다.
rule-providers의 구조와 분리 기준
Clash의 일반적인 라우팅 흐름은 요청 호스트 확인 → 위에서 아래로 규칙 매칭 → 마지막 MATCH 규칙 적용입니다. rule-provider는 이 과정에 들어갈 도메인 목록이나 IP 목록을 외부 파일로 분리합니다. 메인 설정에 수백 줄의 DOMAIN-SUFFIX를 넣는 대신, AI-SERVICES나 DEV-PLATFORMS 같은 이름으로 목록을 호출하는 형태입니다. 이렇게 하면 규칙의 내용과 라우팅 정책을 독립적으로 검토할 수 있습니다.
분리할 때는 서비스 이름만 보고 묶기보다 통신 목적을 기준으로 나누는 편이 좋습니다. 모델 API와 웹 콘솔이 같은 프록시를 사용해야 하는지, 인증 호스트를 별도로 처리해야 하는지, 개발 플랫폼의 코드 저장소와 패키지 레지스트리를 같은 정책으로 보낼 것인지부터 결정하세요. 지나치게 넓은 DOMAIN-SUFFIX,google.com 같은 규칙은 일반 검색·광고·문서 트래픽까지 포함할 수 있으므로, 실제 로그에서 확인한 최소 범위를 우선 사용해야 합니다.
- AI API: 모델 호출, 스트리밍 응답, 임베딩과 같은 백엔드 엔드포인트를 묶습니다.
- AI 로그인: OAuth, 토큰 교환, 계정 확인에 사용되는 인증 도메인을 별도로 관리합니다.
- 개발 플랫폼: GitHub, GitLab, 코드 검색, Copilot 및 관련 개발자 API를 관리합니다.
- 패키지·컨테이너: npm, PyPI, Maven, Docker Registry처럼 다운로드 특성이 다른 호스트를 분리합니다.
- 내부 예외: 사내 Git, 테스트 서버, 로컬 네트워크를
DIRECT또는no-resolve정책으로 명시합니다.
규칙 파일은 일반적으로 한 줄에 하나의 규칙을 담는 text 형식이 관리하기 쉽습니다. 파일 확장자와 실제 내용 형식이 일치하지 않으면 코어가 provider를 읽지 못할 수 있으므로, GitHub Raw URL을 브라우저에서 열었을 때 불필요한 HTML 페이지가 아니라 순수한 규칙 텍스트가 표시되는지 확인해야 합니다.
GitHub에서 규칙을 버전 관리하는 방법
운영용 규칙 저장소는 공개 여부보다 변경 이력과 검토 절차가 더 중요합니다. 공개 저장소를 사용한다면 API 키, 구독 URL, 개인 노드 주소, 사내 도메인처럼 민감한 값은 절대 넣지 마세요. 규칙 provider에는 공개되어도 문제가 없는 도메인 목록만 두고, 실제 프록시 그룹 이름과 비밀 설정은 각 사용자의 로컬 프로필에 남기는 구조가 안전합니다.
저장소 안에는 목적별 디렉터리를 만들고 파일 이름만 보아도 범위를 알 수 있게 하세요. 예를 들어 rules/ai-api.list, rules/ai-auth.list, rules/dev-platforms.list, rules/package-registries.list처럼 구성할 수 있습니다. 각 파일의 상단에는 사람이 읽을 수 있는 설명을 주석으로 적고, 도메인을 추가한 이유와 확인 날짜를 커밋 메시지에 남기면 나중에 오탐을 되돌리기 쉽습니다.
# AI API endpoints
DOMAIN,api.openai.com
DOMAIN,api.anthropic.com
DOMAIN,generativelanguage.googleapis.com
# Developer platforms
DOMAIN-SUFFIX,github.com
DOMAIN-SUFFIX,githubusercontent.com
DOMAIN-SUFFIX,gitlab.com위 목록은 예시일 뿐이며 모든 제품의 실제 연결 호스트를 자동으로 대표하지는 않습니다. 특히 데스크톱 앱과 CLI는 서로 다른 인증·업데이트·텔레메트리 도메인을 사용할 수 있습니다. 따라서 새 규칙을 넣기 전에는 Clash 연결 로그에서 호스트를 확인하고, 단순히 서비스 브랜드의 대표 도메인을 와일드카드로 확장하지 않는 것이 좋습니다. 추가 → 테스트 → 로그 확인 → 필요할 때만 범위 확대 순서를 지키면 규칙이 불필요하게 커지는 것을 막을 수 있습니다.
직접 설정하기: provider와 라우팅 순서 연결
이제 로컬 프로필에서 외부 규칙 파일을 등록합니다. Mihomo 호환 설정에서는 provider마다 type, behavior, url, path, interval 같은 항목을 지정합니다. path는 캐시 파일이 저장될 위치이고, interval은 원격 파일을 다시 확인하는 주기입니다. 너무 짧은 간격을 사용하면 GitHub 요청이 불필요하게 늘어나고, 너무 길면 규칙 변경이 늦게 반영되므로 서비스 성격에 맞춰 정하세요.
rule-providers:
AI-API:
type: http
behavior: domain
url: https://raw.githubusercontent.com/example/rules/main/rules/ai-api.list
path: ./rules/ai-api.list
interval: 86400
DEV-PLATFORMS:
type: http
behavior: domain
url: https://raw.githubusercontent.com/example/rules/main/rules/dev-platforms.list
path: ./rules/dev-platforms.list
interval: 86400
rules:
- RULE-SET,AI-API,AI-PROXY
- RULE-SET,DEV-PLATFORMS,DEV-PROXY
- DOMAIN-SUFFIX,internal.example,DIRECT
- MATCH,GLOBAL여기서 중요한 부분은 RULE-SET 규칙의 위치입니다. provider를 선언했다고 해서 자동으로 사용되는 것은 아니며, rules 아래에서 해당 이름을 호출해야 합니다. 또한 AI 규칙을 일반 GEOSITE 규칙보다 아래에 배치하면 먼저 매칭된 넓은 규칙이 요청을 가져갈 수 있습니다. 구체적인 서비스 예외는 위에, 지역·범용 분류는 아래에, 최종 안전망인 MATCH는 가장 마지막에 두는 것이 기본 원칙입니다.
프록시 그룹도 목적별로 나누면 장애 분석이 쉬워집니다. AI 스트리밍에 안정적인 그룹과 GitHub 웹·대용량 릴리스 다운로드에 적합한 그룹이 항상 같지는 않습니다. 하나의 그룹만 사용하면 설정은 짧아지지만, 모델 응답은 빠른데 Git clone이 느리거나 반대로 코드 다운로드는 되는데 긴 SSE 연결이 자주 끊기는 문제를 구분하기 어렵습니다. 그룹 이름은 AI-PROXY, DEV-PROXY처럼 역할을 드러내고, 실제 노드 선택은 클라이언트의 지연 테스트와 연결 로그를 기준으로 조정하세요.
설정 저장 후에는 먼저 provider가 정상적으로 다운로드되었는지 확인합니다. 파일 상태가 error, parsing failed, timeout으로 표시되면 라우팅 결과를 보기 전에 URL·인증서·파일 형식·코어 지원 문법을 점검해야 합니다. provider가 비어 있는 상태에서 테스트하면 모든 요청이 다음 규칙으로 내려가므로, 잘못된 규칙 문제와 다운로드 문제를 혼동하기 쉽습니다.
우선순위와 자동 업데이트를 안정적으로 운영하기
규칙 우선순위는 단순한 위아래 정렬 이상의 의미를 가집니다. 예를 들어 DOMAIN-SUFFIX,github.com을 개발 플랫폼 provider보다 위에 두면, provider 안에서 특정 GitHub API만 다른 그룹으로 보내려는 의도가 무시될 수 있습니다. 반대로 내부 Git 호스트를 가장 위에 배치하지 않으면 넓은 개발 도구 규칙이 내부 주소를 프록시로 보낼 수 있습니다. 운영 환경에서는 내부 예외 → 민감하거나 목적이 분명한 API → 개발 플랫폼 → 범용 분류 → MATCH 순서가 출발점으로 적합합니다.
자동 업데이트가 항상 좋은 것도 아닙니다. 공개 저장소의 규칙이 예고 없이 바뀌면 기존에 직접 연결되던 도메인이 프록시로 이동하거나, 반대로 필요한 API가 목록에서 빠질 수 있습니다. 업무용 프로필에서는 업데이트 간격을 길게 잡고, 저장소의 릴리스 태그나 고정 커밋 URL을 사용하는 방법을 검토하세요. 최신 규칙이 중요한 개인용 프로필과, 변경 통제가 필요한 업무용 프로필을 같은 provider URL로 운영하지 않는 편이 안전합니다.
| 운영 항목 | 권장 확인 방식 | 문제가 생겼을 때 |
|---|---|---|
| 원격 파일 | Raw 응답과 파일 형식 확인 | HTML 응답, 404, 리디렉션을 점검 |
| 갱신 주기 | 개인용 1일, 업무용은 검토 후 적용 | 캐시 파일과 마지막 성공 시각 확인 |
| 규칙 순서 | 구체적인 예외를 상단에 배치 | 로그에서 실제 매칭 규칙 이름 확인 |
| 변경 이력 | 커밋 메시지와 검토 기록 유지 | 직전 커밋으로 되돌린 뒤 원인을 비교 |
여러 장치에서 같은 provider를 사용할 때는 모든 클라이언트가 같은 문법을 지원하는지 확인해야 합니다. Clash Verge Rev와 최신 Mihomo는 비교적 많은 provider 옵션을 지원하지만, 오래된 Clash 계열 앱이나 다른 모바일 클라이언트는 behavior: domain 또는 특정规则类型을 다르게 해석할 수 있습니다. 하나의 저장소를 무조건 모든 플랫폼에 배포하기보다, 공통 도메인 목록과 클라이언트별 변환본을 분리하는 편이 호환성 측면에서 낫습니다.
로그로 매칭 결과와 실제 경로 검증하기
설정이 적용된 뒤에는 브라우저에서 페이지가 열리는지만 보지 말고, AI CLI·Git 클라이언트·패키지 매니저처럼 실제 사용하려는 프로그램을 직접 실행하세요. Clash 로그에서 호스트명, 매칭된 규칙, 선택된代理 그룹, 연결 시간, 종료 원인을 같은 요청 단위로 확인합니다. 호스트가 DIRECT로 표시되었다면 provider가 누락된 것인지, 앞선 규칙이 가로챈 것인지, 애초에 애플리케이션이 예상과 다른 도메인을 사용한 것인지 구분해야 합니다.
AI 서비스는 짧은 HTTPS 요청보다 스트리밍 연결에서 문제가 잘 드러납니다. 모델 응답이 시작된 뒤 일정 시간 후 멈춘다면 규칙 매칭 자체는 성공했을 가능성이 있으므로, 노드의 장시간 연결 안정성·HTTP/2 처리·MTU·프록시 타임아웃을 함께 살펴보세요. 반대로 OAuth 로그인만 실패하고 API 호출은 성공한다면 인증 provider에 필요한 호스트가 빠졌거나 브라우저와 CLI가 서로 다른 시스템 프록시를 사용하고 있을 수 있습니다.
개발 도구는 또 다른 함정을 가집니다. git clone은 GitHub 도메인을 사용하지만, 릴리스 파일·LFS·서브모듈·패키지 다운로드는 별도의 호스트로 연결될 수 있습니다. 한 번의 성공만으로 규칙이 완성되었다고 판단하지 말고, clone·push·릴리스 다운로드·패키지 설치를 각각 시험하세요. 컨테이너나 원격 SSH 세션에서 실행하는 프로그램은 로컬 Clash의 시스템 프록시를 자동으로 상속하지 않을 수 있으므로, 필요한 경우 해당 런타임에 HTTP_PROXY, HTTPS_PROXY, NO_PROXY를 별도로 설정해야 합니다.
문제를 재현할 때는 한 번에 여러 값을 바꾸지 않는 것이 중요합니다. 먼저 provider 캐시가 최신인지 확인하고, 다음으로 매칭 규칙을 확인한 뒤, 마지막으로 프록시 그룹과 DNS 경로를 바꾸세요. 각 변경 후에는 동일한 호스트에 같은 명령을 반복해 결과를 비교하면 원인 범위를 좁힐 수 있습니다. 설정 파일을 수정하기 전에는 현재 작동하는 프로필을 복사해 두고, GitHub 저장소와 로컬 YAML 모두에서 변경 이력을 남기는 습관을 권합니다.
보안과 유지보수를 위한 최종 점검
rule-provider 저장소는 공개된 라우팅 데이터만 담아야 합니다. 개인 구독 URL을 GitHub Issue나 커밋에 붙여 넣지 말고, 사내 서비스의 전체 호스트 목록이 외부에 노출되어도 되는지 확인하세요. 도메인 목록 자체가 조직 구조나 사용 중인 SaaS를 드러낼 수 있으므로, 공개 저장소가 부담스럽다면 비공개 저장소나 내부 웹 서버를 사용하고 접근 인증을 별도로 구성하는 방법도 있습니다.
정기 점검에서는 사용하지 않는 도메인을 삭제하고, 넓은 DOMAIN-KEYWORD 규칙을 구체적인 DOMAIN 또는 DOMAIN-SUFFIX로 줄이는 작업이 효과적입니다. 서비스 제공자가 엔드포인트를 변경했을 때는 공식 문서만 믿지 말고 실제 연결 로그와 DNS 조회 결과를 함께 확인하세요. DNS 설정이 프록시 정책과 어긋나면 올바른 규칙이 있어도 먼저 잘못된 주소로 연결을 시도할 수 있습니다.
일반적인 수동 YAML 복사는 한두 개의 서비스만 다룰 때 빠르지만, 규칙이 늘어나면 중복·오타·우선순위 충돌이 누적되고 여러 기기에서 서로 다른 상태가 되기 쉽습니다. 반면 rule-provider와 GitHub 버전 관리는 초기 설계와 검토가 필요하지만, AI API와 개발 플랫폼을 목적별로 분리하고 변경 이력을 남길 수 있으며, 로그에서 어떤 정책이 적용되었는지도 더 명확하게 확인할 수 있습니다. 특히 Clash는 규칙 그룹, provider 캐시, 연결 로그를 한 흐름에서 점검할 수 있어 단순 글로벌 프록시보다 개발 환경에 맞춘 운영이 수월합니다.