Clash Meta 원격 규칙이 안 받아질 때: path와 갱신 주기부터 고치기

어떤 증상이면 이 글을 보면 될까

아래에 해당하면 원인 후보가 rule-providers 쪽에 가깝습니다. (노드 구독 실패와 증상이 겹칠 수 있으니, 먼저 프록시 그룹이 비어 있지 않은지는 별도로 확인하세요.)

• 설정에 RULE-SET,이름,정책이 있는데 코어 로그에 provider를 찾을 수 없음 또는 파일 없음에 가까운 메시지가 반복된다.
• GUI에서 규칙 세트 크기가 0이거나, 파일 타임스탬프가 수 주 전에서 멈춘다.
• 수동으로 브라우저에서는 규칙 URL이 열리는데, 코어만 TLS·타임아웃·403으로 실패한다—User-Agent·출구 경로(자기 자신을 다시 프록시하는 루프)를 의심합니다.
• 같은 설정을 다른 PC로 복사했을 때만 실패한다—거의 항상 path 기준 디렉터리나 실행 사용자 권한 문제입니다.

동작하는 최소 예시부터 맞추기

Clash Meta 계열에서 흔한 http 타입 rule-providers는 type·behavior·url·path·interval(초) 조합으로 이해하면 됩니다. 일부 문서나 UI에서는 “갱신 주기”를 다른 키로 표기하기도 하지만, 실제 YAML에는 코어가 인식하는 필드 이름이 들어가야 합니다. 이 사이트 한국어 튜토리얼 예시도 interval: 86400 형태를 씁니다.

# Minimal pattern — replace url/path and policy group names
rule-providers:
  example-rules:
    type: http
    behavior: classical
    url: "https://example.com/rules.yaml"
    path: ./ruleset/example.yaml
    interval: 86400

rules:
  - RULE-SET,example-rules,PROXY
  - MATCH,DIRECT

behavior는 classical·domain·ipcidr 등 원격 파일 형식과 맞아야 합니다. 잘못 고르면 “다운로드는 됐는데 파싱 실패”로 넘어가므로, 공개 규칙 저장소의 README를 한 번 더 확인하세요.

1단계: URL·TLS·리다이렉트·User-Agent

가장 먼저 코어가 직접 요청할 때와 브라우저가 요청할 때의 조건이 같은지 봅니다. CDN이 지역·헤더에 따라 다른 응답을 주거나, 일시적으로 429·5xx를 내는 경우가 많습니다.

2단계: path는 “어디 기준”인가

path: ./ruleset/foo.yaml처럼 상대 경로를 쓰면, 실제 저장 위치는 프로세스의 현재 작업 디렉터리와 GUI가 설정한 홈 디렉터리에 따라 달라집니다. “한 PC에서는 되는데 노트북에서는 빈 폴더”류의 불일치가 여기서 나옵니다.

• Windows·macOS GUI: 프로필별 데이터 디렉터리 아래에 ruleset 등이 생기는지, 디스크 용량·동기화 소프트웨어가 해당 폴더를 잠그지 않는지 확인합니다.
• Linux systemd: 유닛의 WorkingDirectory가 비어 있으면 상대 path가 엉뚱한 곳을 가리킵니다. 운영 가이드는 《Linux 헤드리스 Clash Meta》와 함께 보세요.
• Docker: 컨테이너 안의 상대 경로는 엔트리포인트 기준입니다. 호스트에 캐시를 남기려면 볼륨 마운트와 path를 한 세트로 설계합니다—《Clash Meta Docker 배포》에서 볼륨 패턴을 참고하면 재현이 쉬워집니다.

3단계: 갱신 간격 interval과 “안 바뀌는 것 같음”

interval은 초 단위입니다. 86400이면 하루 한 번 수준으로만 네트워크 갱신을 시도합니다. “방금 고쳤는데도 옛 규칙이다”라고 느껴지면, 실제로는 아직 다음 주기가 안 왔거나 직전 시도가 실패해 캐시만 유지된 경우가 많습니다.

값·상태	의미	실무 메모
interval 큼	트래픽·요청 부담은 적음	긴급 도메인 추가는 로컬 규칙으로 보완
interval 매우 짧음	CDN·원본에 부담	429·차단 위험, 운영 정책 확인
수동 갱신	GUI·API·재시작	코어 버전별 엔드포인트 이름이 다름

GUI에서 “업데이트 간격”이라고만 보일 때 내부 YAML 키가 무엇으로 저장되는지 확인하세요. 키가 비어 있거나 잘못된 이름이면 자동 갱신이 아예 돌지 않을 수 있습니다.

4단계: rules의 이름이 rule-providers와 일치하는가

다운로드가 성공해도 RULE-SET,이름,정책의 이름이 YAML 키와 다르면 규칙이 적용되지 않습니다. 오타·대소문자·복사 시 숨은 공백을 의심하세요. 여러 프로필을 오간다면 지금 활성 프로필에 해당 블록이 들어 있는지도 다시 봅니다.

5단계: 손상 캐시·부분 파일 삭제 후 재시도

다운로드 중단·디스크 가득 참 이후 반쯤 쓰인 파일이 남으면 파싱 오류가 납니다. 코어를 끄고 해당 path 파일·동일 이름의 임시 파일을 지운 뒤 다시 시작하면 깨끗이 받는 경우가 많습니다. GUI가 캐시 DB를 따로 쓰는 경우도 있으니, 클라이언트 문서의 “캐시 초기화” 경로를 함께 확인하세요.

proxy-providers와 헷갈리면 시간만 갑니다

노드 목록을 가져오는 proxy-providers(구독)와, 도메인·IP 규칙 묶음을 가져오는 rule-providers는 완전히 다른 파이프라인입니다. GUI에서 “구독 갱신” 버튼만 눌렀다면 노드 쪽만 새로고침되고 규칙 파일은 그대로일 수 있습니다. 반대로 규칙만 수동 갱신하는 메뉴가 따로 있는 클라이언트도 있으니, 화면에 보이는 라벨이 아니라 실제로 어떤 API·액션을 호출하는지 확인하세요.

원격 규칙 URL을 proxy-providers에 넣거나, 구독 링크를 rule-providers에 넣는 실수도 흔합니다. 전자는 파싱 단계에서 깨지고, 후자는 “다운로드는 됐는데 RULE-SET이 비정상”으로 이어집니다. 의심스러우면 공개 예제 하나만 남기고 최소 재현 설정으로 줄인 뒤 다시 붙이는 방식이 가장 빠릅니다.

로그를 볼 때 최소한 집어야 할 단서

클라이언트마다 로그 탭 이름은 다르지만, 다음 키워드 근처를 보면 원인 축을 빠르게 나눌 수 있습니다.

• DNS·TLS·certificate: URL은 맞는데 전송 계층에서 막힌 경우—중간 인증서·시간 동기·Sniffer와 겹치면 우선 TLS를 고칩니다.
• no such file·permission denied: 거의 항상 path 부모 디렉터리·샌드박스·컨테이너 볼륨 문제입니다.
• parse·yaml·unmarshal: 다운로드는 끝났으나 형식 불일치—behavior와 원격 파일 타입, 인코딩(BOM)·빈 본문을 의심합니다.

DNS·Sniffer와 헷갈리지 않기

규칙 파일이 오래되면 새 CDN 엣지나 서비스 도메인을 놓쳐 “우회가 안 된다”로 보일 수 있습니다. 이는 곧바로 DNS 글로 가기 전에 provider 타임스탬프를 먼저 봅니다. 한편 Sniffer·fake-ip 설정이 꼬이면 사이트는 열리는데 규칙 매칭만 이상해 보일 수 있으니, 필요하면 《Clash Meta Sniffer HTTPS 오류》와 《DNS·fake-ip 점검》을 순서대로 참고하세요.

FAQ

브라우저는 되는데 코어만 실패한다

TLS 검증 차이·시스템 프록시 우회·User-Agent·자기 루프 가능성을 점검하세요. 동일 호스트를 DIRECT로 두는 임시 규칙으로 분리 실험을 해도 좋습니다.

interval을 0으로 두면?

구현·버전에 따라 “수동만”에 가깝게 동작하거나 예상과 다르게 해석될 수 있습니다. 운영 중 혼란이면 합리적인 양의 정수(초)로 고정하고 수동 갱신 버튼·API로 보조하세요.

모바일 클라이언트는?

샌드박스 경로와 백그라운드 제한으로 상대 path가 달라질 수 있습니다. 앱이 제공하는 규칙 디렉터리 안에 두고, iOS는 《iOS 구독·Wi‑Fi》에서 말한 네트워크·프로필 제약도 함께 봅니다.

실무 체크리스트

정리

rule-providers 문제는 대부분 네트워크 한 줄과 디스크 경로 한 줄에서 끝납니다. 로그 용어에 익숙하지 않아도, 위 순서를 표로 체크하면 재발을 줄일 수 있습니다.

Clash를 무료로 내려받고 규칙·구독을 한곳에서 관리해 보세요