2026년 Clash로 Hugging Face Hub·Spaces·Inference API를 안정적으로: 도메인 분류·DNS·실측

① 왜 Hugging Face는 「범용 AI RULE-SET 한 장」으로 끝내기 어렵나

Hugging Face Hub는 브라우저에서 모델 카드를 보는 트래픽만이 아니라, 대용량 가중치를 끌어오는 CDN·Git LFS 경로, huggingface-cli·transformers 라이브러리가 붙는 API·리다이렉트가 동시에 등장합니다. Spaces에 배포된 데모는 종종 *.hf.space 같은 별도 호스트로 열리고, Inference API(또는 이와 연동된 라우터)는 api-inference·router 계열 이름이 Clash 연결 로그에 따로 찍히는 패턴이 흔합니다. TLS에서 보이는 SNI가 제품 메인 도메인 하나로만 정리되지 않고, 짧은 링크용 hf.co와 마케팅용 huggingface.com이 섞여 들어오기도 합니다.

그래서 「한 줄 DOMAIN-SUFFIX,openai.com」 식의 범용 생성 AI 규칙만 넓게 켜 두면, 웹은 되는데 LFS만 DIRECT로 나가 받기가 중간에 멈춘 것처럼 보이거나, 반대로 Spaces만 간헐적으로 실패하는 식으로 증상이 어긋날 수 있습니다. 규칙 문법이 처음이면 사용자 정의 규칙 튜토리얼에서 rules와 proxy-groups 이름을 맞추는 방법부터 익히면 실수가 줄어듭니다.

② 증상부터 나누기: 웹만·CLI만·모델 다운로드만·Spaces만·Inference만

같은 「안 된다」라도 원인 후보가 다릅니다. 아래처럼 먼저 쪼개 두면 Clash 로그와 브라우저 개발자 도구의 네트워크 탭, 터미널의 curl·git 출력을 병행하기 쉽습니다.

• 브라우저 탭만: 카드·문서는 되는데 특정 자산·임베드만 실패 → 정적 자산·임베드 대상 호스트가 빠졌을 가능성
• CLI·파이썬만: OS 프록시 환경 변수·가상환경·회사 네트워크 정책이 브라우저와 달라 동일 YAML이라도 체감이 갈림
• 모델 다운로드·LFS: 대역폭이 큰 객체 스토리지·CDN 호스트가 PROXY 정책과 어긋나거나, 한쪽만 느린 노드로 나감
• Spaces·Gradio 데모만: 프레임·WebSocket·업로드 경로가 다른 서브도메인으로 갈라짐
• Inference API만: 배치·동기화가 아니라 짧은 요청·응답이 반복되는 경로가 별도 호스트로 분리됨

노트·협업 제품에만 필요한 줄을 찾는 글과 비교하려면 Notion·Notion AI 분류의 호스트 표와 나란히 두고, 모델 허브에만 필요한 줄이 무엇인지 구분해 보세요.

③ 분류 대상: 로그에서 자주 보이는 Hugging Face 계열 호스트 후보

아래는 출발점으로 쓸 수 있는 후보이며, 제품 업데이트와 지역·엔드포인트 설정에 따라 달라질 수 있습니다. 확정은 항상 Clash 연결 로그와 실제 요청 이름으로 맞추는 것이 좋습니다.

• 허브·웹 셸: huggingface.co, 짧은 링크 hf.co, 마케팅·리다이렉트에 쓰이는 huggingface.com
• 대용량·LFS·CDN: cdn-lfs.huggingface.co 등 LFS·객체 스토리지 계열(로그에 따로 보일 수 있음)
• Spaces: 배포 환경에 따라 *.hf.space 같은 Spaces 전용 서브도메인
• Inference API: api-inference.huggingface.co, 라우팅·게이트웨이로 자주 거론되는 router.huggingface.co 등(실제 이름은 콘솔·문서·로그로 확인)
• 기타 API·인증: 제품·토큰·조직 정책에 따라 추가 호스트가 붙을 수 있음

첨부·CDN 호스트를 한 번에 거대 RULE-SET으로 밀어 넣기보다, 실제로 실패한 요청의 도메인을 기준으로 DOMAIN-SUFFIX를 쌓는 편이 안전합니다. IPv6 우선 해석 뒤 특정 구간에서만 끊기면 OS·코어의 IPv4/IPv6 일관성도 함께 봅니다.

④ 최소 규칙 예시: huggingface.co·hf.co·hf.space·추론 호스트를 PROXY, 나머지는 환경에 맞게

아래는 개념 YAML입니다. PROXY 자리에는 구독 프로필의 프록시 그룹 이름을 넣고, 맨 아래 MATCH는 국내 트래픽 DIRECT 등 본인 정책에 맞게 조정하세요. api-inference·router 줄은 본인 로그에 맞춰 주석 처리하거나 이름을 바꿉니다.

rules:
  # Hugging Face — verify hostnames in your logs after upstream changes
  - DOMAIN-SUFFIX,huggingface.co,PROXY
  - DOMAIN-SUFFIX,hf.co,PROXY
  - DOMAIN-SUFFIX,hf.space,PROXY
  - DOMAIN-SUFFIX,huggingface.com,PROXY
  - DOMAIN,api-inference.huggingface.co,PROXY
  - DOMAIN,router.huggingface.co,PROXY
  - DOMAIN-SUFFIX,cdn-lfs.huggingface.co,PROXY
  - MATCH,DIRECT

cdn-lfs를 빼면 웹 UI는 되는데 모델 저장소 동기화만 실패하는 식으로 갈릴 수 있습니다. hf.space를 빼면 Spaces 데모만 끊기는 경우가 있습니다. 아무 것도 매칭되지 않을 때는 잠시 MATCH,PROXY로 바꿔 노드·터널 자체가 정상인지부터 가르는 것도 좋은 디버깅 순서입니다. 반대로 국내 사이트까지 느려지면 범위가 과한 것이니, 다시 좁혀 나가면 됩니다.

⑤ Hub·Spaces·Inference를 나누고 싶을 때: 프록시 그룹을 둘 이상

지연·안정성 때문에 브라우저와 API·CLI에 서로 다른 출구를 쓰고 싶다면 그룹을 나눠 규칙에서 이름만 바꿉니다. 예시는 구조 이해용이며, 실제 노드 목록은 본인 구독에 맞게 바꿉니다.

proxy-groups:
  - name: HF_HUB
    type: select
    proxies: [🚀 자동 선택, DIRECT]
  - name: HF_INFERENCE
    type: select
    proxies: [🚀 자동 선택, DIRECT]

rules:
  - DOMAIN-SUFFIX,huggingface.co,HF_HUB
  - DOMAIN,api-inference.huggingface.co,HF_INFERENCE
  - MATCH,DIRECT

이렇게 나누면 「웹만 간헐적으로 실패한다」일 때 HF_HUB만 노드를 바꿔 테스트하기 쉽습니다. 그룹 중첩·이름 짓기는 프록시 그룹(proxy-groups) 가이드와 함께 보면 정리가 수월합니다.

⑥ 규칙 우선순위: 위에서 아래로, 앞줄이 이긴다

Clash의 rules는 일반적으로 먼저 매칭된 한 줄이 최종 정책이 됩니다. 그래서 GEOIP,KR,DIRECT나 구독에 포함된 RULE-SET이 huggingface.co 관련 줄보다 위에 있으면, 의도와 다르게 DIRECT로 나가 버릴 수 있습니다. 반대로 지나치게 아래에 두면 이미 MATCH에 걸려 끝나기도 합니다.

재현이 어려울 때는 로그의 매칭된 규칙 이름·행 순서를 남겨 두고, 한 번에 한 줄만 위아래로 옮겨 보는 방식이 안전합니다. 범용 AI RULE-SET과 커스텀 줄이 같이 있을 때는, Hugging Face 전용 줄이 실제로 먼저 적중하는지를 숫자로 확인하는 것이 중요합니다.

⑦ DNS가 원인일 때: fake-ip, DoH, 조회 경로 엇갈림

증상이 「느리다」가 아니라 간헐적 이름 실패·한 앱만 이상한 IP라면 DNS를 의심합니다. fake-ip 프로필에서는 애플리케이션이 보는 주소와 실제 outbound 경로가 어긋나 보일 수 있고, OS나 브라우저 DoH가 켜진 채 Clash dns 블록도 동작하면 어느 쪽이 먼저 응답했는지에 따라 결과가 달라집니다. 장시간 이어지는 모델 다운로드는 DNS·연결 재시도 타이밍에 특히 민감합니다.

TUN과 DNS를 같이 쓸 때의 절차는 TUN 모드·DNS 심화 글의 순서를 참고하면 후보를 빠르게 줄일 수 있습니다.

⑧ 모드 선택: Rule, Global, Direct와 시스템 프록시·TUN

Rule 모드는 앞서 정한 rules 순서대로 매칭합니다. 문제를 처음 재현할 때는 Global을 잠깐 켜서 노드 품질부터 가르는 것이 유용합니다. 시스템 프록시는 프록시를 존중하는 앱 위주로 동작하고, TUN은 가상 NIC로 더 많은 트래픽을 끌어와 규칙 적용을 일관되게 만들 수 있습니다. 회사 PC에서는 사내 VPN·보안 에이전트와 충돌할 수 있으니 정책을 먼저 확인해야 합니다.

전역 터널과 규칙 기반의 장단은 Clash와 VPN의 차이에서 정리한 대로, 호스트 단위 정책이 필요하면 Clash 쪽이 유리한 경우가 많습니다.

⑨ 실측 절차: Hub 페이지·Spaces·Inference API를 한 번에 밟으며 로그에 맞추기

1. 프로필 백업: YAML 내보내기 또는 클라이언트 백업으로 현재 설정을 저장합니다.
2. Rule 모드: 선택된 프록시 그룹이 의도와 같은지, 상위 GEOIP 등이 huggingface.co보다 먼저 먹지 않는지 확인합니다.
3. 브라우저 Hub 테스트: 모델 카드 하나를 연 뒤 Clash 로그에서 매칭된 DOMAIN·정책을 확인하고, 빠진 서픽스를 추가합니다.
4. LFS·대용량: 작은 파일이 아닌 실제 가중치 다운로드를 시도해 cdn-lfs 등이 새로 뜨는지 봅니다.
5. Spaces: 배포된 데모 URL을 열고, 프레임·WebSocket이 실패하면 hf.space 계열을 보강합니다.
6. Inference API: 문서에 나온 엔드포인트로 curl 또는 SDK를 한 번 호출한 뒤, 동일 세션에서 추가로 뜨는 호스트가 있는지 로그로 확인합니다.
7. DNS 분리: 실패가 규칙인지 해석인지 나누기 위해 OS 도구와 브라우저 네트워크 탭을 병행합니다.
8. 회귀 테스트: 규칙을 고친 뒤에는 국내 뱅킹·사내 포털 등 민감 사이트가 의도대로 DIRECT인지도 함께 확인합니다.

처음 클라이언트를 쓴다면 Clash 입문 튜토리얼에서 프로필·모드 개념을 익힌 뒤 이 체크리스트를 적용하면 훨씬 덜 헷갈립니다.

⑩ 보안·정책·토큰·서비스 약관을 함께 기억하기

네트워크 경로를 다루는 방법과 별개로, 토큰·조직 정책·이용 가능 지역·요금제는 사용자가 스스로 확인해야 합니다. 이 글은 합법적 범위에서의 연결 품질·분류를 기술적으로 설명하는 것이며, 특정 규제를 우회하라는 뜻으로 읽혀서는 안 됩니다. 기업 환경에서는 IT 부서의 프록시·DLP 정책을 우선합니다.

⑪ 정리: Hugging Face는 「Hub·CDN·Spaces·Inference API」를 한 세트로 보라

2026년에도 오픈 모델과 Gradio·Spaces 데모에 대한 관심은 ML·연구 검색에서 이어지고, 네트워크 경로만으로 해결되지 않는 증상(쿼터·권한·지역 정책)도 있습니다. 그럼에도 Clash로 관측 가능한 범위에서는 도메인 분류가 빠짐없이 매칭되는지, DNS가 같은 경로를 보는지, 규칙 표에서의 순서가 의도와 맞는지에 따라 체감이 갈립니다. 단일 챗봇 중심 글과 달리, 저장소·LFS·Spaces·추론이 한 워크플로에 섞이므로 로그를 통한 보강이 특히 중요합니다.

설치와 버전 안내는 릴리스만 쫓기보다 사이트의 다운로드 페이지를 따르는 편이 혼선이 적습니다. 전역 터널보다 관측 가능한 분류에서 Clash가 장기적으로 잘 맞는 경우가 많습니다. → Clash를 무료로 내려받고, Hugging Face Hub·Spaces·Inference API용 도메인 규칙과 DNS를 맞춰 보세요.