1. 왜 Hugging Face와 Google AI를 한 번에 잡아야 할까
Gemma 4를 비롯한 최신 오픈 모델은 카드뉴스 한 줄로 끝나지 않고, 공식 안내에 따라 Hugging Face에서 파일을 받거나, Google AI Studio·문서·Colab 링크를 오가며 설정하는 경우가 많습니다. 사용자 입장에서는 모두 “인터넷이 된다”로 뭉뚱그려지지만, 실제 패킷은 huggingface.co, hf.co, cdn-lfs.huggingface.co 같은 저장소 계열과, ai.google.dev, generativelanguage.googleapis.com, googleapis.com 하위의 API·인증 흐름으로 갈라집니다.
한쪽만 우회에 성공하면 “문서는 열리는데 git lfs pull만 실패”하거나, 반대로 “CLI는 되는데 브라우저 콘솔만 막히는” 식으로 증상이 갈라집니다. 그래서 호스트 단위 분류와 연결 로그 검증이 중요합니다. 구독 YAML 흐름이 익숙하지 않다면 구독 가져오기 튜토리얼로 프로필 구조를 맞춘 뒤 이 글을 적용하세요.
2. 트래픽 층: 허브 UI·LFS·CLI·브라우저 콘솔
핵심은 목적지가 한 덩어리가 아니다는 점입니다. 웹 UI에서 모델 카드를 볼 때의 요청, 실제 바이너리를 끌어오는 LFS·스토리지 호스트, Python에서 huggingface_hub로 받을 때의 엔드포인트, 그리고 Google 측 OAuth·API는 서로 다른 접미사를 씁니다. 브라우저 개발자 도구의 네트워크 탭과 Clash의 실시간 연결 목록을 나란히 놓으면 “어느 문자열이 DIRECT로 새는지”가 빨리 드러납니다.
서버나 헤드리스 Linux에서만 받는다면 OS 시스템 프록시를 무시하는 경로가 더 늘어납니다. 이때는 Linux에서 Mihomo를 systemd로 상주시키는 구성과 맞추어, 셸 환경 변수와 코어 프록시 포트를 표준으로 문서화하는 편이 재현성이 좋습니다.
| 구분 | 예시 방향 | 메모 |
|---|---|---|
| 허브·카드 UI | huggingface.co, hf.co | 검색·메타데이터·리디렉션. |
| 대용량 파일·LFS | 허브가 가리키는 스토리지·CDN | 끊기면 부분 파일·체크섬 오류. |
| Google AI 문서·콘솔 | ai.google.dev 등 | 튜토리얼·할당량 안내. |
| Generative Language API | generativelanguage.googleapis.com | 키·지역 정책과 연동. |
3. DNS·fake-ip: 규칙 판정과 TLS가 어긋나면 다운로드만 꼬인다
fake-ip 모드는 체감 속도에 도움이 될 수 있으나, 해석 결과와 실제 연결 목적지가 어긋나면 대용량 전송 구간에서 재시도가 늘고, 진행률 표시만 도는 것처럼 보일 수 있습니다. 서브도메인과 CDN이 많은 서비스일수록 nameserver-policy나 특정 접미사에 대한 DNS 정책을 분리하는 편이 안전합니다.
상위 DNS가 불안정하면 어떤 규칙을 써도 증상이 흔들립니다. 일반적인 DNS·연결 오류 절차는 Clash 일반 트러블슈팅 가이드와 함께 보시면 좋습니다.
4. 시스템 프록시와 TUN: 터미널·컨테이너가 빠지는 구멍
브라우저로 허브 페이지를 열 때는 괜찮은데, 터미널의 huggingface-cli download나 git lfs만 실패한다면 시스템 프록시를 읽지 않는 경로를 의심하세요. TUN 모드는 라우팅 계층에서 잡아 주어 일관성은 좋아지나, 다른 VPN과의 충돌 같은 변수가 늘어납니다. TUN 모드 안내를 참고한 뒤, 연결 로그로 Hugging Face·Google 관련 호스트가 모두 기대한 정책 그룹으로 나가는지 확인합니다.
Docker 내부에서 받는 경우 호스트의 Clash와 네임스페이스가 달라 별도 설정이 필요할 수 있습니다. “한 PC에서는 되는데 CI에서만 실패”는 대개 프록시 환경 변수 미전달 때문이므로, 팀 문서에 HTTP(S)_PROXY와 NO_PROXY 예외를 명시해 두면 재현하기 어려운 실패를 줄일 수 있습니다.
5. 규칙 그룹: 대용량 다운로드와 API 트래픽을 나눌지
한 그룹에 모두 넣어도 동작은 하지만, 운영 관점에서는 장시간 대역폭을 쓰는 가중치 다운로드와, 짧은 지터에 민감한 API 호출을 분리하면 장애 분석이 쉬워집니다. 자동 페일오버가 과하면 세션이 자주 갈아타며 전송이 끊길 수 있습니다. 전송 프로토콜 특성은 프로토콜 비교 글에서 보조 근거를 얻을 수 있습니다.
ChatGPT·OpenAI 분류 가이드는 생성형 채팅·API 호스트에 초점이 있고, 이 글은 Hugging Face·Gemma·Google AI 개발자 리소스에 맞춘 목록으로 쓰시면 중복을 피할 수 있습니다.
6. 규칙 예시 (그룹 이름은 환경에 맞게 교체)
# Example only — replace PROXY with your policy group name
rules:
- DOMAIN-SUFFIX,huggingface.co,PROXY
- DOMAIN-SUFFIX,hf.co,PROXY
- DOMAIN-KEYWORD,huggingface,PROXY
- DOMAIN-SUFFIX,googleapis.com,PROXY
- DOMAIN-SUFFIX,google.dev,PROXY
- DOMAIN-SUFFIX,ai.google.dev,PROXY실제 구성에서는 공급자 규칙 세트의 순서가 앞서 DIRECT로 보내 버리면 위 항목이 무용지물이 됩니다. 사용자 규칙을 상단에 두거나, 공급자 규칙과 충돌하지 않게 정리하세요. 스토리지 전용 호스트만 별도 그룹으로 빼려면 연결 로그에 찍힌 FQDN을 기준으로 DOMAIN,cdn-xxx...,PROXY_LFS처럼 명시하는 방식이 디버깅에 유리합니다.
7. GUI 워크플로: 연결 패널로 호스트 필터링
Mihomo 기반 클라이언트에서는 실시간 연결 목록에 도메인 문자열이 그대로 남습니다. “huggingface”, “google”, “lfs”로 필터링해 잘못된 DIRECT나 의도와 다른 정책 그룹을 빠르게 찾을 수 있습니다. 첫 설치와 구독 흐름은 초보자 가이드를 따르세요.
8. 추가 함정: 인증서 고정·사내 필터·이중 VPN
일부 기업망은 특정 CDN만 차단해 “목록은 보이는데 바이너리만 실패” 패턴을 만듭니다. 같은 PC에서 브라우저로 스토리지 URL에 직접 접속해 보는 대조 실험이 도움이 됩니다. Clash와 다른 상시 VPN을 동시에 켜면 루프나 이중 터널처럼 보이는 증상이 납니다. 한 번에 하나의 출구만 남기고 다시 테스트하세요.
Google 측 API 키·지역 정책은 이 글의 범위를 넘지만, 네트워크가 정상일 때만 의미 있는 오류 메시지를 받을 수 있습니다. 먼저 Clash 로그에서 해당 호스트가 올바른 그룹으로 나가는지 확인한 뒤, 콘솔의 할당량·권한 메시지를 해석하는 순서를 권장합니다.
9. 정리: 핫이슈가 아니라 개발자 워크플로에 맞춘 분류
Gemma 4와 같은 신형 오픈 모델은 모델 다운로드와 공식 문서·API가 동시에 필요합니다. 이 글은 Clash 분류와 DNS를 근거 있게 맞추어 Hugging Face·Google AI 관련 호스트를 한 번에 점검할 수 있게 정리했습니다. 연결 로그에 찍힌 도메인 목록이 곧 팀 내 네트워크 체크리스트가 됩니다.
규칙을 손으로 다듬는 부담이 크다면 Mihomo 내장 공식 클라이언트에서 로그와 업데이트를 한곳에 모으는 편이 실무적으로도 편합니다. → Clash 를 무료로 내려받고 차이를 직접 확인해 보세요