1 Qwen3를 받을 때 트래픽이 세 갈래로 나뉘는 이유
Qwen3 계열은 공식 카드·문서가 Hugging Face와 ModelScope에 병행되고, 추론 API·쿼터는 DashScope(百炼) 같은 알리 클라우드 콘솔과 맞물립니다. 겉으로는 «같은 모델 이름»이지만 실제 연결은 (1) HF 허브·LFS·글로벌 CDN, (2) modelscope.cn·국내에 가까운 스토리지·OSS 호스트, (3) aliyun.com·console.aliyun.com·dashscope 관련 API 엔드포인트처럼 서로 다른 사업자·인증·지연을 탑니다.
브라우저 탭은 시스템 프록시를 따르는데 터미널의 huggingface-cli·git lfs·Python SDK는 환경 변수 없이 DIRECT로만 나가면, 카드 페이지는 열리고 대형 언어 모델 가중치 다운로드만 중간에 멈추는 패턴이 흔합니다. Clash 분할의 목적은 속도 자랑이 아니라 Connections 로그에서 «메타데이터 → 스토리지 리다이렉트 → 청크 완료»까지 의도한 프록시 그룹이 이어지게 만드는 것입니다. 클라이언트가 없다면 다운로드 페이지에서 GUI를 고른 뒤 Rule 모드 프로파일을 적용하세요.
호스트명은 시즌마다 바뀔 수 있습니다. 예시 YAML은 출발점일 뿐이며, 실패 직후 SNI·FQDN 로그로 한 번 검증하는 것이 안전합니다.
2 기존 글과 어떻게 나누는가
《DeepSeek와 Clash 분할》은 중국계 서비스 웹·API 호스트군을 중심에 두고, 《Gemma·Hugging Face》는 Google AI Studio와 HF·LFS·CDN 정렬에 초점을 둡니다. 《OpenRouter》는 집계형 API·대시보드 도메인 묶음입니다. 본 글은 그 사이에서 Qwen3라는 단일 패밀리를 전제로 HF 축과 ModelScope 축을 동시에 적고, 通义·DashScope 콘솔까지 한 프로파일 안에서 이름만으로 구분할 수 있게 합니다.
이미 HF 전용 그룹을 쓰고 있다면 ModelScope·阿里 접미사만 추가하면 되고, 반대로 국내에서 ModelScope만 쓰는 팀이라면 HF 규칙을 최소화하고 실패 시 로그로 보강하면 됩니다.
3 Hugging Face 쪽 Qwen3 트래픽
Hugging Face에서 Qwen3 카드를 열면 huggingface.co·hf.co가 중심이고, 실제 가중치 다운로드는 LFS·리전 스토리지·Cloudflare 등 CDN 호스트로 리다이렉트됩니다. 브라우저 «파일» 버튼과 huggingface-cli download가 서로 다른 경로를 타면 진행률이 멈춘 것처럼 보이거나 Range 요청이 끊깁니다.
로그에 잡힌 cdn-lfs.huggingface.co 같은 호스트는 시점에 따라 달라질 수 있으니, 실패 직후 Connections를 캡처해 DOMAIN-SUFFIX 후보를 적습니다. HF_ENDPOINT 등으로 미러를 바꾸면 규칙에 없는 호스트가 추가되므로 팀 표준 URL을 Rule Provider 주석에 남겨 두세요. 구독 YAML이 Clash 형식이 아니면 구독 변환 가이드로 정규화한 뒤 규칙을 얹습니다.
DOMAIN-KEYWORD,qwen은 오탐이 있을 수 있어 장기 운영에는 DOMAIN-SUFFIX,huggingface.co 같은 접미사를 우선하고, 키워드는 진단용으로만 쓰는 편이 안전합니다.
4 ModelScope(魔搭)·데이터셋·OSS
ModelScope는 modelscope.cn·www.modelscope.cn을 중심으로 모델 카드·데이터셋·커뮤니티 기능을 제공하고, 대용량 파일은 알리바바 클라우드 쪽 객체 스토리지(예: *.oss-cn-*.aliyuncs.com 형태)로 넘어가는 경우가 많습니다. OSS 접미사를 한꺼번에 넓게 잡으면 다른 알리 서비스까지 끌어올 수 있으므로, 실제 실패 로그의 FQDN을 우선하고 어쩔 수 없을 때만 접미사를 넓히세요.
ModelScope CLI·modelscope Python 패키지가 쓰는 호스트는 웹 UI와 다를 수 있습니다. 다운로드 세션 중에는 노드를 바꾸지 말고, 가능하면 한 출구 고정으로 끝까지 받은 뒤 규칙을 조정하는 편이 LFS·분할 전송 오류를 줄입니다.
5 通义千问·DashScope·API 콘솔
클라우드에서 通义千问 API를 쓰면 dashscope.aliyuncs.com·dashscope.console.aliyun.com·tongyi.aliyun.com·console.aliyun.com 등 阿里 클라우드 패밀리가 동시에 등장합니다. 이 축은 HF·ModelScope와 목적이 다릅니다: 가중치 파일이 아니라 토큰 과금·쿼터·키 관리입니다. 규칙에서 PROXY-ALIYUN-API처럼 이름을 분리해 두면 «모델은 HF에서 받고 추론만 클라우드» 같은 혼합 워크플로를 디버깅하기 쉽습니다.
브라우저 로그인·OAuth가 끼면 signin.aliyun.com 등 추가 호스트가 필요할 수 있습니다. 팀 정책에 따라 «개발용阿里 묶음을 넓게» 할지 «DashScope 몇 개만» 할지 먼저 합의하세요.
6 우선순위와 프록시 그룹 설계
분할 규칙은 위에서 아래로 매칭됩니다. 거대한 GEOSITE나 포괄적인 Rule Provider가 구체 호스트보다 위에 있으면 의도한 출구에 닿기 전에 흡수됩니다. 실무에서는 (1) PROXY-HF, (2) PROXY-MS(ModelScope·필요 시 OSS FQDN), (3) PROXY-ALIYUN-API처럼 세 덩어리로 나누거나, 지연이 크게 다르지 않으면 HF+MS를 PROXY-MODEL-HUB 한 그룹으로 묶을 수 있습니다.
노드 품질이 허브마다 다르게 느껴지면 분리가 유리하고, 개인 랩탑 한 대면 단순화해도 됩니다. YAML 병합이 복잡하면 mixin·구독 덮어쓰기로 개인 보강만 분리하는 방법도 있습니다.
7 DOMAIN-SUFFIX·rules 예시(개념 스니펫)
아래는 병합용 예시입니다. proxy-groups 이름은 본인 프로파일과 일치시키고, 상위 규칙과 충돌하지 않게 순서를 조정하세요. OSS는 로그로 확인한 뒤 한 줄씩 추가하는 방식을 권장합니다.
# Hugging Face hub + short domain (example)
- DOMAIN-SUFFIX,huggingface.co,PROXY-HF
- DOMAIN-SUFFIX,hf.co,PROXY-HF
# After a failed download, add LFS/CDN hosts from logs, e.g.:
# - DOMAIN-SUFFIX,cdn-lfs.huggingface.co,PROXY-HF
# ModelScope (example)
- DOMAIN-SUFFIX,modelscope.cn,PROXY-MS
# Alibaba Cloud console / DashScope / Tongyi (examples — verify in your logs)
- DOMAIN-SUFFIX,aliyuncs.com,PROXY-ALIYUN-API
- DOMAIN-SUFFIX,aliyun.com,PROXY-ALIYUN-API
# Narrow down if too broad: use full FQDN from Connections when possible
aliyuncs.com·aliyun.com 접미사는 범위가 넓습니다. 운영 환경에서는 콘솔에서 실제로 쓰인 호스트만 골라 더 좁은 DOMAIN-SUFFIX나 FULL 도메인 규칙으로 바꾸는 것이 안전합니다.
8 Rule Provider로 목록 유지보수(선택)
오픈 모델 시즌에는 LFS·OSS 호스트가 자주 바뀌므로, 팀 저장소에 텍스트 목록을 두고 Rule Provider로 끌어오는 방식이 유지보수에 유리합니다. behavior: classical 목록을 올려 RULE-SET,qwen-hf-ms-2026,PROXY-MODEL-HUB처럼 참조하고, 긴급 한두 줄은 프로파일 상단에 수동으로 두면 주간 동기화와 핫픽스를 나눌 수 있습니다.
9 CLI·브라우저·TUN·DNS로 경로 맞추기
브라우저만 프록시를 타고 터미널만 직행하는 패턴은 HF와 ModelScope를 번갈아 쓸 때 특히 잘 드러납니다. TUN 모드로 시스템 트래픽을 한 규칙 엔진에 넣으면 탭과 git lfs·CLI가 같은 정책을 쓰기 쉽습니다. VPN·회사 터널과 겹치면 지연이 커질 수 있으니 허용 범위 안에서만 적용하세요.
규칙이 맞아도 DNS가 ISP로 새면 지역 응답이 엇나갑니다. DoH·FakeIP 가이드에 맞춰 Clash DNS·OS 리졸버·TUN을 정렬하세요. 대용량 가중치 다운로드 전에는 잠시 노드를 고정하는 것도 방법입니다.
10 트러블슈팅 체크리스트
- 카드만 열리고 바이너리가 안 받아짐: LFS·CDN·OSS 호스트가 다른 그룹으로 새는지 Connections에서 확인합니다.
- HF만 실패하고 MS는 성공: 노드·지역·rate limit을 분리해 보고, 필요 시 HF 전용 그룹만 교체합니다.
- 중간 퍼센트에서 끊김: 불안정한 노드·MTU·이중 홉을 의심하고 동일 파일로 노드 A/B를 비교합니다.
- 403·토큰 오류: Hugging Face·阿里 계정 정책 문제일 수 있어 프록시만으로는 해결되지 않을 수 있습니다.
- IPv6 불일치: IPv6 직통·IPv4만 프록시 조합이면 증상이 납니다. 환경에 맞게 정리합니다.
11 약관·수출·망 정책
연결이 안정되어도 모델 라이선스·지역 제한·학교·회사망 정책은 그대로입니다. 본문은 합법적인 개발 환경에서의 분할 규칙 구성을 설명할 뿐, 통제된 네트워크를 우회하라는 뜻이 아닙니다. 클라이언트 소스는 GitHub 등에서 확인할 수 있으나, 설치 패키지는 사이트 다운로드 페이지를 우선하는 편이 출처 관리에 유리합니다.
12 정리
2026년 Qwen3·通义千问 가중치는 Hugging Face와 ModelScope 두 허브를 오가며, 추론은 DashScope 등 阿里 API와 섞입니다. 네트워크는 한 흐름이 아니므로 Clash·Mihomo로 DOMAIN-SUFFIX·선택적 Rule Provider를 정리하고, 브라우저·CLI·LFS·OSS가 같은 출구를 쓰게 시스템 프록시·DoH·FakeIP·필요 시 TUN까지 맞추는 것이 핵심입니다. API 집계형 설명은 OpenRouter 글, HF 단일 축은 Gemma 글과 나란히 두면 같은 개발자 스택을 빈틈없이 덮을 수 있습니다.
동급 GUI에서 규칙을 편집하고 프로파일로 저장해 두면 팀원이 같은 Clash 분할로 Qwen3 가중치를 받기 쉽습니다. Rule 편집기·TUN 토글이 잘 보이는 제품을 고르세요.
