왜 Hugging Face만 «자꾸 끊기는 것처럼» 보일까요?
한 저장소를 보더라도 트래픽은 한 줄로 이어지지 않습니다. 저장소 메타데이터와 파일 목록은 huggingface.co나 짧은 도메인 hf.co 쪽 API·웹을 타고, 실제 가중치 바이트는 LFS 포인터가 가리키는 별도 호스트로 리다이렉트되는 경우가 많습니다. Python huggingface_hub는 내부적으로 여러 엔드포인트를 오가며 레쥼(resume) 캐시를 쓰기도 하므로, 브라우저 한 탭이 빠르다고 해서 터미널의 git lfs pull이 같은 노드·같은 지연 특성을 갖지 않을 수 있습니다.
국경을 넘는 회선에서는 «느리지만 끝까지 가는 노드»와 «처음엔 빠르다가 긴 스트림에서 끊기는 노드»가 섞입니다. 대형 모델 가중치는 연결을 오래 유지해야 하므로, 짧은 지연 테스트만 보고 고른 정책 그룹이 LFS 긴 다운로드에는 맞지 않는 경우가 있습니다. Clash에서는 목적지 도메인 접미사별로 아웃바운드를 나누면, 허브 JSON 요청은 가벼운 노드·수 기가 직통은 다른 노드처럼 전략을 분리할 수 있습니다.
MODEL·HF_LFS 같은 묶음 이름을 떠올리면 프로필이 길어져도 역할이 분명해집니다.
트래픽 종류부터 나누기: 웹·Git·LFS·라이브러리
실무에서는 최소 네 갈래를 머릿속에 그려 두는 것이 좋습니다. 첫째, 브라우저로 모델 카드·토큰 입력 UI·토론 탭을 볼 때의 웹 HTTPS. 둘째, git clone으로 히스토리와 작은 파일만 가져올 때의 Git HTTPS/SSH. 셋째, 대용량 포인터를 실제 파일로 바꿀 때의 Git LFS 배치 요청. 넷째, from_pretrained나 huggingface-cli download가 쓰는 허브 클라이언트 경로입니다.
네 종류가 모두 같은 PROXY 한 덩어리에 들어가도 동작은 하지만, «카드는 뜨는데 LFS만 503»처럼 증상이 한 축에만 몰리면 디버깅이 어렵습니다. 분기를 해 두면 로그에서 «이번 연결은 HF_LFS 그룹»이라고 가정할 수 있어, 노드 교체나 타임아웃 값을 조정할 때 실수가 줄어듭니다.
SSH vs HTTPS 선택과 프록시
SSH로 클론하면 22번 포트와 다른 핑거프린트 경로를 타므로, 브라우저용 HTTP 프록시 규칙과 완전히 겹치지 않을 수 있습니다. Clash로 L4를 다루는 방식은 클라이언트·코어 조합에 따라 다르므로, 본 글은 HTTPS 기반 Git LFS를 기본 전제로 하고 SSH 사용자는 «실패 시 찍히는 원격 호스트 이름»을 기준으로 같은 DOMAIN-SUFFIX 묶음을 확장하면 됩니다.
규칙에 넣기 전에 확인할 호스트 이름
공식 문서가 바뀌거나 리전이 늘어나면 스토리지 호스트도 달라질 수 있으므로, 블로그 한 편에 «완전한 화이트리스트»를 고정해 두는 것은 위험합니다. 대신 다음 원칙을 권장합니다. 첫째, 실패한 세션에서 git·curl·huggingface_hub의 verbose 로그에 나온 정확한 호스트를 복사합니다. 둘째, DOMAIN-SUFFIX,huggingface.co와 DOMAIN-SUFFIX,hf.co처럼 사용자에게 보이는 브랜드 축을 먼저 포괄합니다. 셋째, 로그에 *.cloudfront.net·*.amazonaws.com 같은 공용 CDN 접미사가 잡히면, 그 줄을 무분별하게 넓히기보다 해당 세션에 한정해 RULE-SET이나 별도 provider로 관리할지 판단합니다. 너무 넓은 접미사는 다른 클라우드 다운로드까지 끌고 가 버립니다.
회사망이나 학교망에서는 SNI·증명서 검사로 «프록시를 탄 TLS»만 느려지는 경우도 있습니다. 이때는 노드 문제가 아니라 중간 장비일 수 있으니, 같은 호스트를 DIRECT와 프록시로 바꿔 가며 한 번씩 재현해 보는 것이 빠릅니다.
- huggingface.co — 모델 카드, 허브 API, 웹 UI의 중심 축입니다.
- hf.co — 짧은 링크·일부 리다이렉트에 자주 등장합니다.
- Git LFS 배치 URL — 포인터 파일이 가리키는 실제 다운로드 도메인은 저장소·파일마다 다를 수 있어 로그 확인이 필수입니다.
- huggingface_hub 캐시 — 로컬 디스크의
HF_HOME경로와 함께, 재시도 시 같은 호스트로 이어지는지 추적하면 규칙 적용 여부를 확인하기 쉽습니다.
정책 그룹 설계: HF_HUB와 HF_LFS를 나눌지 합칠지
가장 단순한 형태는 HF 하나에 허브와 LFS를 모두 넣는 것입니다. 노드 품질이 안정적이면 이것으로 충분한 경우가 많습니다. 그러나 «메타데이터 요청은 직결로 빠르게, 수십 기가 스트림만 우회»처럼 회선 특성이 갈리면 HF_HUB와 HF_LFS 두 그룹으로 나누는 편이 낫습니다. 전자에는 url-test나 수동 select로 응답이 가벼운 노드를, 후자에는 장시간 TCP에 강한 노드나 특정 지역 고정을 넣는 식입니다.
proxy-groups 이름은 rules 인자와 한 글자라도 어긋나면 안 되므로, UI에서 이름을 바꿨다면 YAML 양쪽을 함께 고쳐야 합니다. 그룹 유형별 동작 차이는 YAML 규칙 분기 가이드의 proxy-groups 절을 참고하세요. 정책 그룹이 많아질수록 대시보드에서 헷갈리므로, HF 전용은 이름 접두사를 통일해 두면 장기 운영에 유리합니다.
rules 예시: 허브 축과 LFS 축을 순서에 맞게
아래는 개념을 보여 주는 최소 스니펫입니다. 실제 프로필에서는 사설 IP·LAN·국내 직행을 더 위에 두고, 포괄 규칙 GEOIP·MATCH보다 서비스별 예외를 올려 두어야 합니다. Clash는 위에서 아래로 첫 매칭 한 줄에서 멈추므로, 순서가 뒤바뀌면 의도와 다른 아웃바운드로 나갑니다.
rules: - DOMAIN-SUFFIX,huggingface.co,HF_HUB - DOMAIN-SUFFIX,hf.co,HF_HUB # Append storage DOMAIN-SUFFIX lines from git / hub verbose logs # ... GEOIP, MATCH, etc.
HF_HUB와 HF_LFS를 같은 그룹으로 쓰려면 두 줄 모두 같은 정책 이름을 가리키면 됩니다. 반대로 LFS만 다른 노드 묶음을 쓰고 싶다면 HF_LFS 그룹의 구성원만 바꿉니다. Git LFS가 리다이렉트 체인을 타면 중간 호스트마다 규칙이 달라질 수 있으니, 한 번 실패한 뒤 코어 로그의 최종 SNI를 기준으로 줄을 추가하는 방식이 안전합니다.
Git·환경 변수와 Clash 포트 맞추기
터미널에서 git이 시스템 프록시를 자동으로 따르지 않는 환경이 많습니다. 이때는 HTTPS_PROXY=http://127.0.0.1:포트처럼 Clash의 혼합 포트나 HTTP 포트를 명시하거나, Git 전용 http.proxy 설정을 씁니다. WSL이나 원격 Linux에서 받을 때는 Windows 쪽 Clash의 Allow LAN과 방화벽, 그리고 게이트웨이 주소까지 맞춰야 해서, WSL2·Git 프록시 글의 순서를 같이 보는 것이 좋습니다.
GIT_LFS_SKIP_SMUDGE=1로 클론한 뒤 필요한 파일만 git lfs pull하는 워크플로에서는, 스모지 단계와 풀 단계가 서로 다른 호스트를 칠 수 있습니다. 각 단계마다 로그를 한 번씩 남겨 두면 분기 줄을 빠르게 보강할 수 있습니다.
타임아웃·재시도 메시지와 로그를 한 줄로 맞추기
대용량 전송이 중간에 끊기면 클라이언트는 자동으로 범위 요청(range)으로 이어 받기를 시도합니다. 이때 표면 메시지는 «read timed out»처럼 포괄적이지만, Clash 쪽에서는 특정 아웃바운드에서 TCP 실패나 TLS 핸드셰이크 지연으로 찍힐 수 있습니다. 같은 시각의 코어 로그와 터미널 타임스탬프를 맞춰 보면 «어느 규칙 줄이 선택됐는지»와 «어느 노드로 나갔는지»를 동시에 확인할 수 있습니다.
로그에 규칙 이름이 안 보이는 클라이언트라면, 일시적으로 log-level를 올리거나 트래픽 뷰어에서 해당 흐름만 필터링해 보세요. 재시도가 빠르게 반복되면 노드 한도에 걸린 것인지, 로컬 Wi‑Fi 절전인지 구분이 필요합니다. 유선 연결·다른 시간대·다른 노드로 세 변수를 바꿔 가며 한 번에 하나만 바꾸면 원인 추적이 쉬워집니다.
HTTP/2·다중 연결 이슈
허브 클라이언트는 동시에 여러 스레드로 조각을 받을 수 있습니다. 이때 일부 연결만 느린 노드로 새고 나머지는 다른 경로로 가면, 전체 진행률이 들쭉날쭉해 보일 수 있습니다. 정책 그룹 안에서 노드를 고정해 두면 이런 «절반만 빠른 현상»을 줄이는 데 도움이 됩니다.
TUN·DNS와 함께 쓸 때의 짧은 체크리스트
TUN 모드는 편하지만 가상 NIC와 DNS 모드가 겹치면, 브라우저와 터미널이 서로 다른 리졸버 결과를 보는 경우가 있습니다. fake-ip 환경에서는 규칙에 넣은 도메인이 기대와 다른 IP로 매핑되지 않았는지, fake-ip-filter에 허브 관련 이름이 필요하지 않은지 함께 확인하세요. 로컬 루프백·사내 대역은 다른 글에서 말한 것처럼 규칙 상단에서 DIRECT로 빼 두는 것이 안전합니다.
코어 기능·프로토콜 쪽을 손보는 단계라면 미호모 코어 업그레이드 가이드에서 최신 스택을 맞춘 뒤, 동일한 HF 작업을 다시 측정해 보는 것도 방법입니다. 구버전 TLS 스택에서만 나는 오류는 규칙과 무관하게 해결되기도 합니다.
npm·Cursor 분기 글과 무엇이 다른가요?
이전에 정리한 Cursor·npm 개발자 분기는 레지스트리·IDE 확장 마켓 축이 중심입니다. 반면 Hugging Face 시나리오는 대형 모델 가중치와 Git LFS·허브 라이브러리가 주연이고, 한 번의 «다운로드」가 수천 개의 작은 tarball이 아니라 소수의 거대 객체로 이어지는 경우가 많습니다. 그래서 노드 선택 기준과 타임아웃 해석이 npm 때와 다르게 느껴지는 것이 자연스럽습니다.
두 글을 같은 프로필에 공존시키려면 이름만 겹치지 않게 DEV와 HF_LFS처럼 역할을 나누고, rules에서 각각의 DOMAIN-SUFFIX 묶음을 나란히 두면 됩니다. 장기적으로는 Rule Provider로 «개발 도구 세트»와 «ML 허브 세트»를 파일로 분리해 두면 구독 갱신 때 덜 깨집니다.
마무리
2026년에도 오픈 가중치 수요는 줄지 않고, Hugging Face 쪽 CDN과 Git LFS 경로는 계속 진화합니다. Clash에서는 브랜드 도메인과 로그에 드러난 스토리지 호스트를 분기 줄로 고정하고, 허브 메타와 대용량 스트림을 서로 다른 정책 그룹에 태울지 결정하면 «한 축만 이상하게 느린» 상황을 체계적으로 줄일 수 있습니다. 증상이 남으면 규칙만 의심하지 말고 DNS·TUN·Git 프록시 환경을 같은 타임라인에서 대조하는 습관이 중요합니다.
같은 Clash 계열이라도 GUI 머지 방식은 제품마다 다르지만, 최종적으로 코어가 읽는 YAML을 기준으로 생각하면 디버깅이 빨라집니다. 검증된 클라이언트에서 프로필을 한 번 맞춰 두면, 이후에는 로그에 나온 호스트만 조금씩 보강하는 운영으로 이어집니다.