증상: pending·시간 초과가 왜 골치인가

Clash·mihomo 계열에서 rule-providers나 원격 rule-set을 쓰면, 코어는 주기적으로 HTTP(S)로 규칙 파일을 받아 옵니다. 이때 UI나 로그에 갱신이 멈춰 있고 pending만 뜨거나, 곧바로 timeout·연결 실패가 반복되면 규칙 엔진이 비어 있거나 예전 스냅샷에 갇혀 트래픽 분기 전체가 엉뚱해질 수 있습니다. 사용자 입장에서는 “구독은 되는데 규칙만 안 받아진다”거나 “GitHub 주소만 자꾸 실패한다”는 식으로 나타납니다.

중요한 점은, 규칙 파일을 가져오는 요청도 결국 하나의 TCP 세션이라는 것입니다. 그 세션이 DNS에서 어떤 IP로 풀리는지, Clash의 rules에서 DIRECT로 나가는지 프록시 체인을 타는지, 출구 네트워크가 해당 호스트를 허용하는지가 모두 맞물립니다. 따라서 “GitHub가 막혔다”는 결론만 내리기 전에, 먼저 이 요청이 실제로 어떤 경로를 밟는지를 분해하는 것이 빠릅니다.

rule-provider 트래픽이 따라가는 길

rule-providers 항목은 보통 type: http와 url:로 원격 YAML·텍스트를 가리킵니다. 코어가 이 URL에 접속할 때도 일반 트래픽과 같이 최상위 rules가 적용됩니다. 즉 MATCH가 DIRECT면 규칙셋 요청도 DIRECT로 나가고, 특정 도메인을 프록시 그룹에 묶어 두었다면 그 경유지·출구 정책을 그대로 탑니다.

반대로 말하면, 규칙셋 호스트를 아직 규칙으로 덮지 못한 상태에서 기본이 DIRECT인 환경이면, 프록시가 잘 되는 것처럼 보여도 규칙 다운로드만 “직결로 나가다 RST나 필터에 걸린다”는 패턴이 자주 나옵니다. 또는 프록시 그룹이 잘못되어 루프에 가깝게 돌다 타임아웃 나는 경우도 있습니다. YAML에서 rules 우선순위와 proxy-groups를 이미 정리해 두었다면, 이번에는 “어떤 도메인이 어떤 줄에 먼저 걸리는가”를 규칙셋 URL에 특화해서 읽어 보면 됩니다.

1단계: DNS와 도메인 이름부터 분리한다

raw.githubusercontent.com, github.com, 일부 미러 도메인은 지역·ISP·회사망에 따라 해석 결과와 가용성이 달라집니다. Clash 쪽에서는 dns 섹션의 enhanced-mode(Fake-IP 등)와 네임서버 지정이, 브라우저나 OS의 해석과 어긋나면 “여기서만 안 열린다”는 착시를 만들기도 합니다.

실무에서는 다음을 순서대로 확인합니다. 첫째, 운영체제나 dig·nslookup로 해당 호스트가 기대한 IP로 풀리는지. 둘째, Clash 로그에 DNS 관련 경고나 재시도가 없는지. 셋째, Fake-IP를 쓰는 경우 규칙셋 요청이 애플리케이션 레벨에서 기대한 도메인으로 이어지는지입니다. DNS를 완전히 의심하기보다, “규칙셋 전용으로 좁은 예외”를 두기 전에 전역 DNS 정책이 과격하지 않은지부터 보는 편이 안전합니다.

팁

같은 URL을 기기 브라우저에서 열었을 때는 되는데 코어만 실패한다면, 브라우저 확장·별도 VPN·시스템 프록시가 개입했을 가능성을 의심해 보세요. Clash 로그의 실패 소스 IP·프록시 이름이 브라우저와 같은지 비교하면 갈림길이 빨라집니다.

2단계: DIRECT인지 프록시인지 “규칙 한 줄”로 가른다

GitHub Raw류 URL이 막히는 환경에서 흔한 처방은 DOMAIN-SUFFIX,githubusercontent.com,프록시그룹 같은 행을 rules 앞쪽에 추가하는 것입니다. 다만 이때 프록시 그룹 자체가 건강해야 합니다. 출구 노드가 TLS 핸드셰이크를 끊거나 SNI 정책에 걸리면, 도메인만 옮겨도 계속 실패합니다.

점검 순서를 제안하면 다음과 같습니다. 규칙셋 요청이 어느 그룹을 타는지 Connections(또는 동등 패널)에서 확인하고, 그 그룹의 url-test·fallback 대상 URL이 너무 공격적이지 않은지 봅니다. 그다음 동일 그룹으로 일반 HTTPS 사이트를 열어 TLS 오류가 없는지 확인합니다. 마지막으로 규칙 우선순위 때문에 의도와 다른 DIRECT 행이 먼저 매칭되지 않았는지, GEOIP나 대형 rule-set이 GitHub 계열을 집어삼키지 않았는지까지 훑습니다.

3단계: raw.githubusercontent.com과 차단·지연의 관계

많은 공개 규칙 저장소가 https://raw.githubusercontent.com/… 형태를 씁니다. 이 호스트는 CDN 성격의 응답을 보이지만, 일부 네트워크에서는 속도가 불안정하거나 간헐적으로 차단되는 사례가 있습니다. “전체가 막힌 것은 아닌데 대용량 파일만 끊긴다”는 식이면 MTU·중간 박스 이슈까지 의심해야 해서, 먼저 작은 텍스트 파일로 HEAD나 GET을 시도해 보는 것이 좋습니다.

또한 Release 자산이 아닌 Raw 경로이므로, 레이트 리밋이나 리다이렉트 정책이 바뀌면 클라이언트 캐시와 맞지 않아 오래된 URL이 갑자기 실패하기도 합니다. 규칙 제공자가 권장하는 최신 URL이 있는지 README를 확인하고, 로컬 path:와 interval: 조합이 운영에 맞는지도 같이 보세요.

4단계: 미러·대체 원본은 신뢰와 갱신을 함께 본다

공개 미러(예: jsDelivr를 통한 번들, 커뮤니티 프록시 프런트)는 규칙 다운로드 성공률을 올리는 데 도움이 될 수 있지만, 중간 캐시가 끼어 들면 내용이 한 박자 늦거나 변조 위험이 이론상 존재합니다. 따라서 미러를 쓰더라도 제공자가 공식적으로 안내하는 URL인지, HTTPS인지, 조직 내부라면 허용 목록에 올릴 만한지를 먼저 판단하는 것이 좋습니다.

실무 패턴은 “(1) 공식 Raw가 가능하면 Raw 유지 (2) 네트워크가 불가하면 검증된 미러로만 전환 (3) interval을 너무 짧게 두지 않아 출구·미러 모두에 부담을 주지 않기”입니다. 팀에서 규칙을 고정하고 싶다면 원격 대신 CI로 파일을 받아 저장소에 두고 path:만 바꾸는 방식도 충돌이 적습니다.

설정 스케치: rule-provider와 rules 앞쪽 분기

아래는 개념을 잡기 위한 예시이며, 실제 그룹 이름·정책은 본인 프로필에 맞게 바꿔야 합니다. 핵심은 규칙 프로바이더가 사용하는 호스트가 의도한 전략 그룹으로 빨리 매칭되도록 rules 상단에 좁은 DOMAIN-SUFFIX를 두는 것입니다.

# Put narrow GitHub raw rules BEFORE broad GEOIP / catch-all rule-sets
rules:
  - DOMAIN-SUFFIX,raw.githubusercontent.com,PROXY_RULE_FETCH
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY_RULE_FETCH
  - DOMAIN,github.com,PROXY_RULE_FETCH
  # ... your other rules ...

rule-providers:
  community:
    type: http
    behavior: classical
    url: "https://raw.githubusercontent.com/example/repo/master/rules.yaml"
    path: ./rulesets/community.yaml
    interval: 86400

PROXY_RULE_FETCH는 실제로는 쓰고 있는 안정 그룹 이름으로 교체합니다. DIRECT가 필요한 특수망이라면 같은 자리에 DIRECT를 두되, 그 경우에는 앞 단계에서 말한 대로 직결 경로가 Raw를 수용할 수 있는지 반드시 검증해야 합니다.

로그와 Connections로 “어느 줄에 걸렸는지” 확인

문제가 반복될 때는 로그 레벨을 잠시 올리고, 규칙셋 요청 시점에 어떤 규칙 이름·체인이 찍히는지 확인하세요. “DNS만 나오고 세션이 안 붙는다”면 해석 이후 경로, “TCP 연결은 되는데 TLS에서 끊긴다”면 출구·SNI·중간 검사 쪽 의심이 커집니다. UI에 Connections가 있다면 호스트별로 필터링해 보면 규칙 우선순위 디버깅에 큰 도움이 됩니다.

한 번에 설정을 많이 바꾸기보다, 분기 한 덩어리만 바꾸고 재시도하는 습관이 롤백 비용을 줄입니다. 구독·proxy-providers 쪽 갱신과 동시에 문제가 생겼다면, 동일한 출구 그룹을 쓰는지도 함께 비교해 보세요.

주의

공용 미러나 변환 서비스에 민감한 내부 규칙 URL을 그대로 붙여 넣지 마세요. 외부 서버에 요청이 기록될 수 있고, 규칙 내용이 유출될 수 있습니다. 가능하면 신뢰할 수 있는 자체 미러나 허용된 도메인만 사용하세요.

실전 체크리스트

  1. 호스트: 브라우저·curl로 동일 URL이 열리는가.
  2. 경로: Connections에서 규칙셋 요청이 DIRECT인가 프록시인가.
  3. 우선순위: 더 넓은 rule-set이 GitHub 계열을 먼저 잡아먹지 않는가.
  4. 출구: 잡은 프록시 그룹이 TLS와 장문 응답을 버티는가.
  5. DNS: Fake-IP·fallback DNS가 이 호스트에서 역행하지 않는가.
  6. 운영: interval·미러·캐시 파일 path가 정책과 맞는가.

정리

rule-provider·원격 rule-set이 끊기는 문제는 단일 원인보다는 DNS·분기·출구 품질이 겹친 합성 증상인 경우가 많습니다. GitHub Raw만 특정해서 보면 “벽이다”라고 결론 내리기 쉽지만, 실제로는 DIRECT로 새고 나가며 ISP 필터에 걸리거나, 프록시 그룹이 피로해져 TLS에서 무너지는 경우가 흔합니다. 단계적으로 좁히면 대부분은 규칙 몇 줄과 출구 한 그룹 안에서 끝납니다.

규칙 엔진이 건강해야 나머지 앱별 분기 글에서 다루는 세부 도메인도 안정적으로 따라옵니다. 최신 클라이언트와 공식 다운로드 페이지의 빌드를 맞춰 두면 로그·UI로 경로를 보기도 쉬워집니다. → Clash를 무료로 내려받은 뒤, rule-provider와 분기 설정을 한 번에 점검해 보세요.