Hugging Face Hub에서 모델·LFS가 자꾸 멈춤? Clash로 huggingface.co·hf.co·CDN 분할과 노드 실측 (2026)

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 호스트를 각각 한 덩어리로 정리해 두면, 이후 스토리지 엔드포인트가 늘어날 때 목록만 덧붙이면 됩니다.