왜 Hub·LFS 풀은 “끊김”에 민감한가
Hugging Face Hub는 웹 UI·REST·git·huggingface-cli·Python huggingface_hub 등으로 같은 저장소 뒤에 붙지만, 실제 바이트는 원본 호스트·미러·CDN·LFS 엔드포인트로 흩어질 수 있습니다. Clash 프로필에서 메인 API만 프록시로 보내고 LFS·다운로드 URL은 직접 연결로 빠지면, TLS SNI·세션이 엇갈리거나, 한쪽은 빠른 노드·한쪽은 느린 노드를 타 재개(resume)가 어긋날 수 있습니다. 반대로 DNS가 Fake-IP와 실제 출국 경로를 섞으면, 클라이언트가 다시 조회한 IP가 앞선 연결과 달라 대용량 전송이 초기화되기도 합니다. 그래서 채팅 웹보다 모델 다운로드는 일관된 분기를 요구하는 편입니다.
문서·설정 허브에서 DNS·TUN을 먼저 읽고, 이 글은 huggingface.co·git-lfs·관련 하위 도메인을 한 정책 그룹으로 묶는 실무 루트에 맞췄습니다. Meta DNS 튜토리얼이 누수·캐시를, connection reset 글이 로그·규칙을 잡는다면, 여기서는 그 흐름을 Hub에 적용한 시나리오입니다.
트래픽이 갈라지는 대표 지점
도메인·리다이렉트
브라우저로 모델 카드를 열고 다운로드를 누르든, hf download를 쓰든, HTTPS 요청이 지나는 첫 hop은 보통 huggingface.co·hf.co·인증·API 서브도메인 쪽에 붙습니다. 이어서 LFS·signed URL·region CDN으로 302·pre-signed 리다이렉트가 나가면, Clash 입장에선 완전히 다른 FQDN·AS로 보입니다. 분류 규칙에 huggingface만 있고 실제 LFS 호스트가 MATCH·GEOIP 쪽으로만 정리돼 있으면, 대용량만 다른 정책을 타 대역이 갈릴 수 있습니다. Sniffer·PROCESS-NAME은 규칙 우선순위와 함께 써, “이 프로세스의 연결”을 한꺼번에 PROXY로 보내는 식이 재현성이 좋을 때가 있습니다(환경·코어·OS에 따라 가용 여부는 다릅니다).
장시간·재시도
가중치 샤드·스레드 수가 많을수록 TCP가 오래 열리고, 중간 노드의 유휴 타임아웃·MTU 이슈가 재연결을 유발할 수 있습니다. url-test·fallback 그룹이 다운로드 중 노드를 바꾸지 않게, Hub 전용 정책을 따로 두고 고정해 두는 편이 끊김을 줄이는 데 도움이 될 때가 있습니다(그룹 설계는 url-test 글과 맞춰 읽는 것이 안전합니다).
핵심: Hub는 한 앱처럼 보여도, 망 관점에선 여러 도메인이 합쳐진 파이프라인입니다. DNS·첫 SNI·리다이렉트 뒤 호스트를 한 번에 그리지 않으면, Clash 로그에만 봐도 어딘가 DIRECT·어딘가 PROXY로 찢어집니다.
DNS, Fake-IP, DoH
Clash Meta·Mihomo는 dns·fake-ip·redir-host·DoH 조합이 최종 연결과 일치해야, “이름이 가리킨 IP로 실제로 패킷이 나간다”는 직관이 맞습니다. Fake-IP를 쓰면 로컬 가짜 대역이 생기고, 스니퍼·도메인 기반 매칭이 뒤따르므로, Hub 관련 이름이 스플릿-horizon처럼 서로 다른 DNS에 물리지 않게 하나의 DNS 체인에 모으는 편이 대용량에 유리한 경우가 많습니다. 도메인 서픽스로 +.huggingface.co 류를 nameserver 그룹에 태울지, 전역 DoH만 쓸지는 정책마다 다르지만, “같은 FQDN이 쿼리마다 다른 응답”이 나오지 않게 하는 것이 1차 목표입니다. 구체 키는 사용 중인 빌드의 문서를 따릅니다.
LAN·기업 DNS 캐시가 끼어 있으면, 터미널의 resolve와 Clash 내부 해석이 달라질 수 있으니, 문제 재현 시에는 로그에 찍힌 질의·응답을 함께 봅니다. QUIC·HTTP/3가 임의 포트로 분류에서 빠질 수 있으니, TUN·system proxy·앱 설정을 한 축으로 맞추는 것이 좋습니다.
분류 규칙: Hub를 한 꾸러미로
rules는 위에서 아래 첫 일치입니다. DOMAIN-SUFFIX·RULE-SET에 Hugging Face·AWS·Cloud·CDN 관련 리스트를 나열하되, 사내·연구망이면 DIRECT가 더 빠른 경우도 있어 벤치가 필요합니다. 전형적인 개인 시나리오에서는 huggingface.co·hf.co·LFS에 쓰인 스토리지 호스트(환경·리전에 따라 다름)를 같은 proxy-group에 넣고, GitHub Release·PyPI와 섞이지 않게 앞줄에 좁은 DOMAIN을 두는 식이 디버깅이 쉽습니다. ACL·GEOSITE 룰셋을 쓰면 이름이 버전마다 달라질 수 있으니, 로그로 실제 SNI를 한 번 덤프해 누락을 메우는 것이 안전합니다. GEOIP/GEOSITE 글과 세트 선택이 맞아야 나머지가 MATCH로 깔끔히 떨어집니다.
# Illustrative only — place rules in correct order; names match your profile
# Tight rows first, then broad GEOIP / MATCH
rules:
- DOMAIN-SUFFIX,huggingface.co,PROXY_HUB
- DOMAIN-SUFFIX,hf.co,PROXY_HUB
- DOMAIN-SUFFIX,github.com,PROXY_DEV
- GEOIP,CN,DIRECT
- MATCH,PROXY
PROXY_HUB는 url-test 대신 고정 selector·필터로 두어 다운로드 중 노드가 바뀌지 않게 하는 편이 재개에 유리할 때가 있습니다(환경·과금·대역에 따라 직접이 맞는 경우도 있습니다).
huggingface-cli·git-lfs·라이브러리
huggingface-cli download·from_pretrained·git lfs pull는 스택마다 TLS·캐시·프록시 환경 변수(HTTP(S)_PROXY 등)를 다루는 방식이 조금씩 다릅니다. Clash를 시스템 프록시로 올리면 일부 도구는 따로 NO_PROXY가 필요할 수 있고, 파이썬 venv·도커·WSL2는 호스트의 출구와 게스트의 라우트가 달라 끊김이 한쪽에만 남기도 합니다. VMware·호스트 튜토리얼의 “누가 어느 게이트웨이를 쓰는가” 정신을, 로컬 ML 워크스페이스에도 그대로 적용하면 원인이 빨리 좁혀집니다.
캐시 디렉터리(예: HF_HOME·TRANSFORMERS_CACHE)는 동일한 호스트에서 부분 파일이 남은 채 재시도할 수 있으니, 디스크·권한·심볼릭 링크를 먼저 점검한 뒤, Clash 측 분기를 만지는 순서를 추천합니다.
MCP 글·스트리밍 글과의 보완
동일 AI 열풍 아래서도, MCP 글은 로컬 IDE가 원격 모델 API에 붙는 짧은 요청을 다루고, 본문은 Hub에서 대용량을 한 번에 받는 경로에 맞췄습니다. 둘 다 DNS·분류를 한 프로필에 맞춰야 하지만, API 타임아웃이 걱정인지, GB 단위 전송이 중도 실패하는지에 따라, 읽는 로그·최적화 포인트가 달라집니다. 오픈소스·라이선스·이슈는 GitHub에서 확인할 수 있고, 클라이언트 바이너리는 사이트 다운로드를 우선합니다.
점검 순서(요약)
- DNS 응답이 쿼리마다 흔들리지 않는지, Fake-IP·캐시·DoH를 한 축으로 맞췄는지 확인합니다.
huggingface.co·LFS·리다이렉트 호스트가 같은 정책을 탔는지, 로그의 매칭 규칙·노드·DIRECT·REJECT를 한 타임라인으로 봅니다.- 다운로드 중 url-test·자동 전환이 끼어들지 않는지, Hub 전용 그룹을 고정해 실험합니다.
- OS·가상 환경·프록시 환경 변수가 터미널과 GUI 앱에 일관되는지 확인합니다.
- 변경은 한 층씩: DNS → 분류 → 노드 순을 지키고, 롤백이 쉬운 스냅샷을 둡니다.
알림: 사내·학교 망 정책·데이터 규율·인증 요구를 위반하지 않는 범위에서만 프록시를 쓰세요. 이 글은 인프라 공학 설명이며, 이용 약관·로컬 법은 본인 책임입니다.
맺음말
Hugging Face Hub는 AI 개발자에게 모델·데이터셋 공급의 중심이 됐고, 큰 파일이 끊기지 않게 가져오는 일은 스트리밍 못지않게 망 품질에 민감합니다. Clash·Mihomo로 분류 규칙과 DNS를 정리해 두면, LoRA·미세조정 파이프라인 앞에 서 있는 지연과 알 수 없는 실패를, 로그로 읽을 수 있게 바꿀 수 있습니다. 다른 툴과 비교해도, 한 프로필에서 도메인·정책을 일관되게 쓰는 경험이면 Clash가 손에 잘 맞는 편입니다. 설치·구독 흐름을 한곳에 맞추려면 다운로드 페이지·문서를 함께 보시길 권합니다.