1 Gemma 4·오픈 가중치를 쓸 때 왜 네트워크가 갈라지는가
Gemma 4는 Google이 공개한 오픈 가중치 모델군으로, 문서와 데모는 Google AI Studio 흐름과 맞물리고 가중치·토크나이저는 Hugging Face에서 받는 경우가 많습니다. 겉으로는 같은 오픈 모델 이야기지만 네트워크는 두 상이한 출판사·CDN·인증이 겹칩니다. Studio 탭은 브라우저가 시스템 프록시를 따르는데, 터미널의 huggingface-cli·git lfs·Python huggingface_hub는 환경 변수나 TUN 없이 DIRECT로만 나가다 중간에 끊기는 패턴이 흔합니다.
Clash 분할의 목표는 속도 경쟁이 아니라, Connections 로그에서 «Studio 로그인 → 프롬프트 실행 → 허브 메타데이터 → 모델 다운로드 완료»까지 의도한 프록시 그룹이 이어지게 만드는 것입니다. Mihomo는 DOMAIN-SUFFIX와 Rule Provider로 목록을 버전 관리하기 좋아 릴리스 주기가 빠른 시즌에 유리합니다. 클라이언트가 없다면 다운로드 페이지에서 GUI를 고른 뒤 Rule 모드 프로파일을 적용하세요.
호스트 이름은 분기마다 바뀔 수 있습니다. 예시 YAML은 출발점일 뿐이며, 실제 SNI·FQDN 로그로 한 번 검증하는 것이 안전합니다.
2 기존 «Gemini 2.5·AI Studio» 글과 어떻게 나누는가
같은 사이트의 《Gemini 2.5와 Google AI Studio를 Clash로》는 Gemini API·generativelanguage.googleapis.com 등 Google 클라우드 호스트군을 한 묶음으로 다룹니다. 본 글은 그 연장선에서 Gemma 4를 언급하되, 실무 축을 오픈 가중치 배포와 Hugging Face·LFS·외부 CDN으로 옮깁니다. 두 글을 같이 북마크해 두면 클라우드 API 실험과 허브에서 로컬로 받기를 같은 Clash 정책 스택으로 설명할 수 있습니다.
팀에서 이미 Google 전용 그룹을 쓰고 있다면 HF 전용 접미사만 추가해도 됩니다. 반대로 허브만 막히는 환경이라면 Google 묶음은 최소화하고 huggingface.co·스토리지 호스트를 우선 보강하세요.
3 Google AI Studio 쪽에서 자주 보이는 호스트
Google AI Studio는 브라우저 UI와 키·쿼터 안내가 섞여 있고, 백그라운드에서는 google.com·gstatic.com·googleusercontent.com·googleapis.com·google.dev·ai.google.dev 등 Google 서비스 패밀리가 동시에 돕니다. Gemma 카드가 Studio에 노출되면 모델 이름 링크만 바뀌어도 스크립트 출처가 달라질 수 있어 «모델 한 줄 DOMAIN-KEYWORD»보다 접미사 묶음이 덜 깨집니다.
로그인·OAuth가 끼면 accounts.google.com이 필수 축이 됩니다. Colab·Drive까지 같이 쓰면 호스트가 더 늘어나므로, 운영 정책에 따라 개발용 Google 그룹을 넓게 잡을지 Studio·문서만 좁게 잡을지 팀에서 먼저 합의하세요. 구독 YAML이 Clash 형식이 아니면 구독 변환 가이드로 정규화한 뒤 규칙을 얹으세요.
4 Hugging Face·모델 카드·LFS·CDN 축
Hugging Face 웹은 huggingface.co가 중심이고, 대용량 모델 다운로드는 LFS·리전 스토리지·Cloudflare 등 CDN 호스트로 리다이렉트되는 경우가 많습니다. 브라우저 «파일 받기»와 CLI가 서로 다른 경로를 타면 진행률이 90%에서 멈춘 것처럼 보이거나 Range 요청이 끊겨 처음부터 다시 받게 됩니다.
cdn-lfs.huggingface.co 등 호스트는 시점에 따라 달라질 수 있으니, 실패 직후 Connections 로그를 캡처해 DOMAIN-SUFFIX 후보를 적습니다. hf.co 단축 도메인이나 미러를 쓰는 팀은 해당 접미사도 같은 PROXY-HF 그룹에 넣는 것이 재현성에 유리합니다.
HF_ENDPOINT 등 환경 변수로 엔드포인트를 바꾸면 규칙에 없는 호스트가 추가됩니다. 팀 표준 URL을 정했다면 Rule Provider 주석에 함께 적어 두세요.
5 우선순위: 두 그룹 vs 한 그룹
분할 규칙은 위에서 아래로 매칭됩니다. GEOSITE나 거대한 Rule Provider가 구체 호스트보다 위에 있으면 의도한 출구에 도달하기 전에 흡수됩니다. 실무에서는 (1) Studio·Google 묶음을 PROXY-GOOGLE, (2) HF·LFS·CDN을 PROXY-HF로 나누거나, 지연이 크게 다르지 않으면 둘 다 PROXY-AI-DEV 한 그룹으로 통합합니다.
노드 품질이 Google과 HF에서 다르게 느껴지면 두 그룹이 디버깅에 유리합니다. 반대로 실험용 랩탑 하나 수준이면 한 그룹으로 단순화하고 로그만 주기적으로 확인해도 됩니다. 중요한 것은 프로파일 안에서 이름과 순서가 한 번에 읽히게 적혀 있는지입니다.
DOMAIN-KEYWORD,hf는 오탐이 있을 수 있어 장기 운영에는 DOMAIN-SUFFIX,huggingface.co 등 접미사를 우선하고 키워드는 진단용으로만 쓰는 편이 안전합니다.
6 DOMAIN-SUFFIX·rules 예시 (개념 스니펫)
아래는 병합용 예시입니다. PROXY-GOOGLE·PROXY-HF는 본인 proxy-groups 정의와 일치시키고, 상위 규칙과 충돌하지 않게 순서를 조정하세요. 실제 배포 전에는 반드시 로그로 검증합니다.
# Google AI Studio + common Google API hosts (example)
- DOMAIN-SUFFIX,google.com,PROXY-GOOGLE
- DOMAIN-SUFFIX,googleapis.com,PROXY-GOOGLE
- DOMAIN-SUFFIX,gstatic.com,PROXY-GOOGLE
- DOMAIN-SUFFIX,google.dev,PROXY-GOOGLE
- DOMAIN-SUFFIX,googleusercontent.com,PROXY-GOOGLE
# - DOMAIN-SUFFIX,ai.google.dev,PROXY-GOOGLE
# Hugging Face hub + short domain (example)
- DOMAIN-SUFFIX,huggingface.co,PROXY-HF
- DOMAIN-SUFFIX,hf.co,PROXY-HF
# After a failed weight download, paste LFS/CDN hosts from logs:
# - DOMAIN-SUFFIX,cdn-lfs.huggingface.co,PROXY-HF
# (prefer full FQDN when possible; avoid over-broad CDNs)지나치게 넓은 CDN 접미사는 다른 서비스까지 끌어올 수 있습니다. 로그의 전체 호스트명을 우선하고, 어쩔 수 없을 때만 접미사를 넓히세요. YAML 병합이 헷갈리면 mixin·구독 덮어쓰기로 개인 보강만 분리하는 방법도 있습니다.
7 Rule Provider로 목록 갱신하기
오픈 모델 시즌에는 호스트가 자주 바뀌므로, 팀 저장소에 작은 텍스트 목록을 두고 Rule Provider로 끌어오는 방식이 유지보수에 유리합니다. behavior: classical에 맞춘 목록을 올려 두고 RULE-SET,gemma-hf-google-2026,PROXY-HF처럼 참조한 뒤, 상단에 Studio 전용 한두 줄을 수동으로 두면 긴급 패치와 주간 동기화를 나눌 수 있습니다.
8 모델 다운로드·재시도·장시간 연결
오픈 가중치 파일은 수 기가바이트까지 올라가며, 중간 노드가 세션을 끊으면 낭패입니다. 브라우저 다운로드·CLI 모두 같은 PROXY-HF를 타게 TUN으로 맞추거나, 터미널에 프록시 환경 변수를 명시하세요. 회사망에서 대용량만 차단하는 경우, 규칙보다 방화벽 정책이 원인일 수 있음을 잊지 마세요.
Git LFS는 여러 청크로 나눠 받습니다. 일부 청크만 다른 출구를 타면 체크섬 단계에서 실패하는 것처럼 보일 수 있습니다. 다운로드 중에는 노드를 바꾸지 말고, 가능하면 한 세션 고정으로 끝까지 받은 뒤 규칙을 조정하세요.
9 시스템 프록시·DoH·TUN으로 경로 맞추기
브라우저만 프록시를 타고 터미널만 직행하는 패턴은 Google AI Studio와 Hugging Face를 같이 쓸 때 특히 잘 드러납니다. TUN 모드로 시스템 트래픽을 한 규칙 엔진에 넣으면 Studio 탭과 huggingface-cli가 같은 정책을 쓰기 쉽습니다. VPN·회사 터널과 겹치면 지연이 커질 수 있으니 허용 범위 안에서만 적용하세요.
규칙이 맞아도 DNS가 ISP로 새면 지역 응답이 엇나갑니다. DoH·FakeIP 가이드에 맞춰 Clash DNS·OS 리졸버·TUN을 정렬하세요. 대용량 모델 다운로드 전에는 잠시 노드를 고정하는 것도 방법입니다.
10 트러블슈팅 체크리스트
- Studio만 되고 CLI만 실패: 터미널 프록시 환경 변수·TUN 적용 여부를 확인합니다.
- 메타데이터만 받고 바이너리가 안 받아짐: LFS·CDN 호스트가 다른 그룹으로 새는지 Connections에서 확인합니다.
- 중간 퍼센트에서 끊김: 불안정한 노드·이중 홉·MTU 이슈를 의심하고, 동일 파일로 노드 A/B를 비교 테스트합니다.
- 403·rate limit: Hugging Face·Google 계정 정책·토큰 범위 문제일 수 있어 프록시만으로는 해결되지 않을 수 있습니다.
- IPv6 불일치: IPv6 직통·IPv4만 프록시 조합이면 증상이 납니다. 환경에 맞게 v6 정책을 정리합니다.
11 약관·수출·망 정책
연결이 안정되어도 모델 라이선스·지역 제한·학교·회사망 정책은 그대로입니다. 본문은 합법적인 개발 환경에서의 분할 규칙 구성을 설명할 뿐, 통제된 네트워크를 우회하라는 뜻이 아닙니다. 클라이언트 소스는 GitHub 등에서 확인할 수 있으나, 설치 패키지는 사이트 다운로드 페이지를 우선하는 편이 출처 관리에 유리합니다.
12 정리
2026년 Gemma 4 같은 오픈 가중치 릴리스는 Google AI Studio에서의 체험과 Hugging Face에서의 모델 다운로드가 한 작업 흐름으로 묶입니다. 네트워크는 그렇지 않으므로 Clash·Mihomo로 DOMAIN-SUFFIX·Rule Provider를 정리하고, 브라우저·CLI·LFS·CDN이 같은 출구를 쓰게 시스템 프록시·DoH·FakeIP·필요 시 TUN까지 맞추는 것이 핵심입니다. 클라우드 API 중심 설명은 Gemini 2.5 글을 함께 보면 같은 개발자 트래픽을 빈틈없이 덮을 수 있습니다.
다른 범용 AI 튜토리얼인 ChatGPT·Claude 글과도 키워드가 겹치지 않게, 본 글은 오픈 모델 허브 축에만 초점을 맞춥니다. 설치와 릴리스 정보는 Clash 다운로드 페이지에서 OS별로 확인할 수 있습니다.
동급 GUI에서 규칙을 편집하고 프로파일로 저장해 두면, 팀원이 같은 분할 규칙으로 Gemma 4를 받아 실험하기 쉽습니다. 비슷한 후보를 비교해 본인 워크스테이션에 맞는 클라이언트를 고르세요. Rule 편집기·TUN 토글이 잘 보이는 제품이 운영 스트레스를 줄여 줍니다.
