Hugging Face 내려받기가 멈출 때: Hub·CDN·LFS 도메인을 Clash(mihomo)로 분기하는 실측 단계 (2026)

1. 왜 Hub만 느리고 LFS만 끊길까

웹 UI에서 메타데이터·카드 목록을 가져오는 요청과, 실제 모델 다운로드에 쓰이는 대용량 객체는 호스트가 갈라지는 경우가 많습니다. Hugging Face는 CDN과 캐시 계층을 쓰기 때문에, huggingface.co로 시작한 세션이 곧바로 같은 출구로 이어지지 않을 수 있습니다. git-lfs 클라이언트는 HTTP 레인지·재개·여러 청크를 오가며 긴 연결을 유지하므로, 일부 요청만 DIRECT로 빠지거나 다른 노드로 새면 진행률이 멈춘 것처럼 보입니다.

mihomo에서 Fake-IP를 쓰면 도메인 규칙과 잘 맞지만, 터미널 도구가 시스템 리졸버를 직접 쓰거나, 컨테이너 안에서 별도 DNS를 쓰면 Clash 밖으로 해석이 나가 규칙과 실제 경로가 어긋납니다. 회사망·캠퍼스망에서는 SNI 기반 정책으로 특정 경로만 불안정한 경우도 있어, 「브라우저만 되고 CLI만 안 된다」 패턴이 반복되기도 합니다.

2. 대화형 AI 글과 다른, 모델·LFS 트래픽의 특징

DeepSeek나 ChatGPT 글은 짧은 API 왕복·세션 쿠키·채팅 호스트에 초점을 둡니다. 반면 허브에서 내려받는 가중치 파일은 대역폭·TCP 윈도·중간 프록시의 타임아웃 설정에 더 민감합니다. 따라서 같은 「AI」 키워드라도 YAML 목록을 그대로 복사하면 부족할 수 있고, LFS·정적 호스트를 로그에서 추가로 잡아야 합니다.

Sora·Steam 글도 CDN 논의를 다루지만, 여기서는 PyTorch·Safetensors·게이트드 레포처럼 개발자가 CLI로 반복 실험하는 흐름을 전제로 합니다. 재생 DRM이나 게임 CDN과 완전히 같은 호스트 집합은 아니므로, 실제 환경에서 관측한 FQDN을 우선합니다.

3. 규칙에 넣기 좋은 도메인 출발점

아래는 출발점입니다. 인프라는 수시로 바뀌므로, 개발자 도구 네트워크 탭·mihomo 로그·GIT_CURL_VERBOSE=1 같은 관측으로 목록을 보강하세요. 일반적으로 DOMAIN-SUFFIX,huggingface.co와 DOMAIN-SUFFIX,hf.co로 상당 부분을 한 번에 잡을 수 있습니다. 대용량 객체는 cdn-lfs.huggingface.co 등 LFS 전용 호스트 이름이 로그에 따로 찍히는 경우가 많습니다.

클라우드 스토리지나 제3자 CDN 호스트가 로그에 보이면, 여러 서비스가 공유하는지 확인한 뒤 DOMAIN 단위로 좁히거나, 과도하게 넓은 DOMAIN-KEYWORD는 피하세요. *.amazonaws.com처럼 범위가 큰 접미는 다른 트래픽까지 끌어와 부작용이 생기기 쉬워, 가능하면 로그에 찍힌 전체 FQDN을 기준으로 추가합니다.

4. mihomo rules 스니펫

전용 정책 그룹 이름을 예시로 🤗 HuggingFace라고 하면, rules 상단에서 넓은 MATCH·지역 규칙보다 위쪽에 둡니다. 그룹·노드 이름은 본인 구독에 맞게 바꿉니다. 우선순위 개념은 고급 라우팅 가이드와 함께 보면 이해가 빨라집니다.

rules:
  # Hugging Face Hub / LFS — above broad MATCH / GEOIP
  - DOMAIN-SUFFIX,huggingface.co,🤗 HuggingFace
  - DOMAIN-SUFFIX,hf.co,🤗 HuggingFace
  # LFS/CDN subdomains (e.g. cdn-lfs.*) are covered by huggingface.co; add extra FQDNs from logs if needed

  # ... LAN, CN, then MATCH
  - GEOIP,PRIVATE,DIRECT
  - MATCH,🔰 Proxy

구독 갱신 시 커스텀 규칙이 덮어써지지 않게 하려면 구독 가져오기와 프로필 머지 순서를 확인하세요. 장시간 내려받기에서는 url-test가 노드를 자주 바꿔 세션이 끊겨 보일 수 있어, 실측 시 한동안 노드를 고정하는 대조 실험도 권합니다.

5. CLI·Git·Docker 쪽 출구 맞추기

huggingface-cli download·git clone·git lfs pull은 브라우저와 달리 HTTP(S)_PROXY 환경 변수나 Git 설정의 http.proxy에 의존하는 경우가 많습니다. 시스템 프록시만 켜 두고 터미널은 직행하면, UI는 되는데 CLI만 느린 패턴이 납니다. TUN 모드는 이런 불일치를 줄이는 데 유리하지만, 권한·다른 VPN과의 충돌을 점검해야 합니다.

컨테이너나 WSL2 안에서 내려받는다면 호스트와 DNS·프록시 스택이 달라질 수 있습니다. Docker·호스트 Clash 글과 WSL2 글의 출구 맞추기 흐름을 참고해, 한 환경에서는 한 가지 스택을 유지하는 편이 디버깅에 유리합니다.

Windows·macOS에서 클라이언트 첫 설정이 필요하면 Verge Rev Windows·macOS 글을 함께 보세요.

6. DNS·fake-ip·nameserver-policy

mihomo에서 enhanced-mode: fake-ip를 쓰면 도메인 규칙과 궁합이 좋지만, 브라우저·OS의 DoH가 우선하면 해석이 엔진 밖으로 새어 규칙과 실제 연결이 어긋날 수 있습니다. huggingface.co·hf.co만 지정 리졸버로 보내고 싶다면 nameserver-policy를 검토합니다. IP 기반 규칙이 필요해지면 Sniffer 설정을 열어두고 로그로 교차 검증하세요.

# Optional — example only; use your own resolvers
dns:
  nameserver-policy:
    "+.huggingface.co":
      - https://dns.google/dns-query
    "+.hf.co":
      - https://dns.google/dns-query

전체 그림은 Clash 개요에서 DNS와 모드를 함께 보는 것이 좋습니다. 서비스 약관·데이터 처리 방침은 사용자마다 다르므로 본문은 전송 경로만 다룹니다. 합법적으로 이용 가능한 환경에서 연결을 안정화하는 용도로만 활용하세요.

7. 실측 점검 순서

권장 순서는 다음과 같습니다. 첫째, Clash 로그에서 문제 요청이 의도한 DOMAIN-SUFFIX 줄에 매칭됐는지 확인합니다. 둘째, 🤗 HuggingFace에 묶인 노드의 지연·출구가 기대와 맞는지 Proxies 화면에서 봅니다. 셋째, 브라우저 내려받기와 CLI·LFS를 같은 노드로 맞췄을 때 증상이 사라지는지 비교합니다. 넷째, DoH·다른 VPN·TUN 충돌을 점검합니다. 다섯째, 구독 갱신·TLS 오류가 의심되면 구독·TLS·DNS 로그 글의 순서와 교차합니다.

모바일 핫스팟이나 셀룰러 DNS가 끼어 있으면 증상이 간헐적으로만 나올 수 있습니다. Wi-Fi와 LTE를 오가며 패턴이 달라지면 단말 쪽 해석 경로를 의심하세요.