Hugging Face Hub와 Git LFS가 Clash에서 갈라지는 이유

2026년에도 많은 팀이 오픈 가중치·데이터셋의 기본 창구로 Hugging Face(허브·문서·CLI)를 씁니다. 브라우저에서 모델 카드·토큰 발급·토론 스레드는 잘 열리는데, git clone 뒤 Git LFS 단계나 huggingface-cli download만 수 시간 걸리거나 중간에 끊긴다면, 문제는 “사이트가 막혔다”기보다 요청이 서로 다른 호스트로 나가며 한 축만 불안정한 경우가 흔합니다. 허브 UI는 huggingface.co 트리에 가깝고, 짧은 리다이렉트·에셋에는 hf.co가 등장하기도 하며, 대용량 포인터가 가리키는 스토리지·cdn-lfs 류 CDN은 또 다른 FQDN 묶음으로 잡힙니다. Clash 분할 규칙이 huggingface.co 한 줄에만 머물면 “페이지는 되는데 LFS만 실패” 같은 부분 증상이 남습니다.

이 글은 우회를 조장하지 않으며, 직장·학교 정책과 서비스 약관·현지 법규를 지키는 범위에서, 이미 합법적으로 프록시를 쓸 수 있는 환경을 전제로 도메인 목록·전략 그룹·DNS 점검 순서를 기술적으로 정리합니다.

참고: Hugging Face는 리전·캐시·스토리지 게이트웨이 호스트명을 바꿀 수 있습니다. 아래 DOMAIN-SUFFIX 목록은 출발점이며, 실패한 요청의 호스트를 브라우저 개발자 도구·Git/CLI 표준 오류 출력·Clash 연결 로그에서 확인한 뒤 한 줄씩 보강하는 것이 가장 정확합니다.

OpenRouter·Cursor 글과 겹치지 않게: 허브·LFS·스토리지 축

저장소의 OpenRouter 분할 가이드는 집계 API 엔드포인트에 맞춰져 있고, Cursor IDE 가이드는 확장 마켓·에디터 동기화 도메인에 초점을 둡니다. 반면 본문은 모델 레지스트리·Git LFS·대용량 바이너리가 나가는 huggingface.co·hf.co·스토리지·cdn-lfs 패턴을 한 번에 정리합니다. DeepSeek·CDN 글처럼 “웹과 대용량 다운로드 경로가 다르다”는 관점은 비슷하지만, 도메인 집합과 사용 도구(git·CLI·허브 웹)가 다릅니다.

즉, IDE 안에서 API 한 줄만 바꿔 쓰는 시나리오가 아니라, 수십~수백 기가바이트 아티팩트를 장시간 TCP로 받는 시나리오에 맞춰 노드 안정성·세션 유지를 우선해야 합니다.

증상: 허브는 열리는데 LFS·CLI 모델 다운로드만 끊김

다음 패턴이 겹치면 규칙 매칭 로그와 실제 요청 호스트를 동시에 보세요.

  • 카탈로그·로그인은 되는데 git lfs pull만 재시도 루프: 메타데이터는 가벼운 경로로 받았으나, 포인터가 가리키는 스토리지 호스트만 다른 정책 그룹·느린 출구로 나가는 경우입니다.
  • huggingface-cli 진행 바가 중간에 멈춤: 인증 토큰 요청은 성공했는데 Range 다운로드가 특정 CDN 이름에서만 타임아웃하는 경우입니다.
  • 동일 레포를 사무실망에선 되고 집망에선 안 됨: GEOIP 기반 DIRECT 규칙이 스토리지 축만 국내 회선에 남겨 두었을 때 흔합니다.
  • 브라우저 “파일 다운로드”는 되는데 Git만 실패: 브라우저가 쓰는 호스트와 Git/CLI가 쓰는 호스트가 다를 수 있습니다. 각각의 SNI를 로그로 분리하세요.

복사해 쓰기 좋은 도메인 후보: huggingface.co·hf.co·LFS·CDN

실측된 FQDN을 우선하되, 초기 프로필에 올리기 좋은 후보는 다음과 같습니다.

  • 허브 공식 트리: DOMAIN-SUFFIX,huggingface.co 한 줄이면 카탈로그·계정·문서·일부 API에 붙는 하위 호스트를 넓게 덮습니다. 토큰·OAuth 콜백이 별도 서브도메인으로 보이면 개발자 도구에서 확인해 DOMAIN 한 줄로 보강합니다.
  • 짧은 도메인·리다이렉트: 링크·에셋에 hf.co가 섞이면 DOMAIN-SUFFIX,hf.co를 추가합니다. 규칙이 huggingface.co에만 있을 때 일부 클릭 경로만 실패하는 증상이 줄어듭니다.
  • Git LFS·스토리지: 로그에 cdn-lfs.huggingface.co·cas-bridge.xethub.hf.co 등이 보이면 각각 DOMAIN으로 명시하거나, 관측이 반복되면 상위 접미사를 신중히 확장합니다. 서비스 측 명칭은 바뀔 수 있으니 “문서에 나온 고정 목록”보다 본인 환경 로그가 우선입니다.
  • 대용량만 분리할지: UI는 DIRECT로 두고 LFS·CLI만 프록시 그룹으로 보내 대역폭을 아끼고 싶다면, 스토리지 호스트만 별도 전략 그룹에 넣습니다. 반대로 인증·다운로드를 한 그룹에 묶어 단순화할 수도 있습니다.

지나치게 넓은 접미사는 다른 Hugging Face 트래픽까지 끌어올 수 있으니, 로그에 찍힌 이름을 기준으로 최소 확장하세요.

전략 그룹과 rules: 예시

개념용 축약 YAML입니다. 그룹 이름·프록시 목록은 구독에 맞게 바꾸고, 도메인 줄은 본인 환경 로그에 맞게 덧붙이세요.

YAMLproxy-groups:
  - name: "HuggingFace-Hub"
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies:
      - DIRECT
      # ... stable nodes for huggingface.co (browse, auth) ...

  - name: "HuggingFace-LFS"
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies:
      - DIRECT
      # ... nodes that tolerate long downloads / large objects ...

  - name: "Proxy"
    type: select
    proxies:
      - DIRECT
      # ... general subscription ...

rules:
  - DOMAIN-SUFFIX,huggingface.co,HuggingFace-Hub
  - DOMAIN-SUFFIX,hf.co,HuggingFace-Hub
  # Add observed storage / CDN hosts explicitly, e.g.:
  # - DOMAIN,cdn-lfs.huggingface.co,HuggingFace-LFS
  # - DOMAIN,cas-bridge.xethub.hf.co,HuggingFace-LFS
  # Put these above GEOIP / broad RULE-SET / MATCH

url-test 헬스 URL은 구독 제공자 권장 주소로 바꿀 수 있습니다. 짧은 헬스가 통과해도 수십 기가바이트 규모의 모델 다운로드는 다른 특성을 가질 수 있으므로, HuggingFace-Hub와 HuggingFace-LFS에 서로 다른 리전·라인을 두고 비교 실험해 보세요. 헬스는 가볍게 통과하는 노드가 장시간 전송에서 재전송이 잦을 수 있습니다.

모델 다운로드·Git LFS·장시간 TCP

LFS와 CLI는 장기 TCP·Range 재개·중간 캐시에 민감합니다. TLS 핸드셰이크에서 멈추면 SNI·인증서·중간 장비를 의심하고, 전송 중 끊기면 패킷 손실이 큰 노드·세션 제한·ISP 셰이핑을 의심합니다. 동일 레포를 DIRECT와 프록시 그룹으로 번갈아 받아 보고, 끊김이 특정 출구에만 붙는지 확인하세요. Perplexity CDN 글에서 다룬 것처럼 “본문 API”와 “대용량 정적”을 나누는 선택과 같은 맥락입니다.

DNS·fake-ip와 규칙이 엇갈릴 때

DNS는 DOMAIN-SUFFIX가 기대대로 적용되는지를 좌우합니다. enhanced-mode: fake-ip를 쓰면 대부분 호스트명 단계에서 도메인 규칙이 먼저 매칭되지만, 앱이 Clash 밖에서 이미 IP로 소켓을 열면 DOMAIN 계열이 건너뛰어질 수 있습니다. Git·CLI만 실패할 때는 TUN 모드로 트래픽을 커널에 태우는 방안과 함께 검토하세요.

DoH·OS DNS와 Clash DNS가 동시에 동작하면 “규칙은 맞는데 실제 질의는 다른 리졸버”가 되기도 하므로, 한 번에 한 축만 바꿔 가며 확인합니다. fake-ip-filter는 증상이 있을 때만 최소한으로 추가하세요.

GEOIP·RULE-SET이 Hugging Face 규칙을 덮어쓸 때

Clash 규칙은 위에서 아래로 첫 일치에서 종료합니다. GEOIP,KR,DIRECT나 광범위한 MATCH를 목록 상단에 두고 그 아래에 huggingface.co 줄을 적으면 아래 줄은 실행되지 않습니다. Hugging Face용 DOMAIN·DOMAIN-SUFFIX는 해당 GEOIP·MATCH보다 위에 두세요. 일반 원리는 규칙 분할 가이드와 같습니다.

구독 템플릿의 RULE-SET이 특정 키워드나 TLD를 다른 정책으로 보내는 경우도 있습니다. 대시보드 로그에서 어떤 규칙에 매칭됐는지 확인하고, 로컬 예외를 위로 올리거나 provider 순서를 조정하세요.

실측 점검 순서: 로그·연결·노드 전환

  1. Git·CLI·브라우저에서 실패·지연한 요청의 호스트를 적어 규칙에 반영합니다.
  2. Clash 로그에서 매칭된 규칙·정책 그룹이 HuggingFace-Hub·HuggingFace-LFS(또는 본인이 지정한 이름) 중 어디인지 확인합니다.
  3. 동일 다운로드를 각 그룹 안에서 노드만 바꿔 반복해 출구·리전 의존성을 좁힙니다.
  4. 터미널에서 프록시를 강제한 채 curl -vI 등으로 TLS 단계까지 도달하는지 봅니다.
  5. 증상이 특정 시간대에만 나타나면 노드 풀 혼잡과 스토리지 측 지연을 구분합니다.

주의: 출처가 불분명한 원격 rule-set은 악성 규칙이 섞일 수 있습니다. 모델 아티팩트·토큰을 다루는 프로필일수록 신뢰할 수 있는 소스만 사용하세요.

마무리

Hugging Face Hub는 huggingface.co 한 줄로 끝나지 않고, hf.co·Git LFS·cdn-lfs·스토리지 게이트웨이가 섞이면 “같은 서비스처럼 보이는데 경로는 여럿”이 됩니다. 허브 UI는 열리는데 대용량만 끊길 때는 DOMAIN-SUFFIX로 서비스 축을 묶고 전용 전략 그룹에 할당한 뒤, DNS·규칙 순서·노드 품질을 한 번에 맞추면 원인 분석이 단순해집니다.

일체형 VPN과 비교했을 때 Clash·Mihomo 계열은 표현력이 높아 모델 다운로드와 일상 브라우징을 나누기에 적합하지만, 로그를 읽고 순서를 관리할 책임도 함께 따라옵니다.

설치와 프로필 반영 절차는 문서·튜토리얼을 참고하시고, 규칙을 적용할 준비가 되었다면 → Clash를 무료로 다운로드하여 본문 예시를 바탕으로 proxy-groups와 rules만 조정해 보시길 바랍니다. huggingface.co·hf.co와 로그에서 확인한 LFS·CDN 호스트를 각각 한 덩어리로 정리해 두면, 이후 스토리지 엔드포인트가 늘어날 때 목록만 덧붙이면 됩니다.