왜 Ollama 받기만 Hugging Face에서 자주 멈출까

Ollama로 로컬 LLM을 쓰려면 결국 모델 가중치를 어딘가에서 내려받아야 합니다. 공식 흐름 가운데 많은 레이어가 Hugging Face 허브와 연결된 호스트를 거칩니다. 화면에서는 “조금 받다 멈춘다”, “진행률이 한동안 그대로”, “TLS 한참 뒤 타임아웃”처럼 보이지만, 실제 네트워크 관점에서는 작은 JSON·메타데이터 요청과 수 기가바이트 Blob 전송이 서로 다른 도메인·경로·캐시 계층으로 갈라지는 경우가 많습니다.

문제는 이 축들이 모두 같은 품질의 회선과 같은 정책으로 나가야 한다는 전제가 성립하지 않는다는 점입니다. 어떤 노드는 짧은 API 호출에는 빠르지만 장시간 대역폭을 유지하지 못하고, 반대로 다른 노드는 반대 성향을 보이기도 합니다. 그래서 Clash 같은 규칙형 프록시에서 “전역으로 한 줄”보다 HF 본체·짧은 리다이렉트 도메인·대용량 CDN·LFS 후보를 나눠 분기하는 접근이 체감 차이를 만들 때가 많습니다.

이 글은 웹 챗봇 트래픽만 다루는 일반적인 AI 프록시 글과 달리, 개발 도구·모델 아티팩트 다운로드의 시간 초과 병목을 전제로 합니다. TikTok·Threads처럼 한 서비스 안에서도 메인과 CDN이 갈리는 패턴은 TikTok CDN 분기 글과 같은 원리이지만, 여기서는 허브 생태계와 레지스트리까지 포함합니다.

합법적 이용과 네트워크 정책

프록시·분기 설정은 본인이 권한을 가진 회선·장비·계정 범위 안에서만 적용해야 하며, 회사나 학교 정책을 우회하려는 목적으로 사용하면 안 됩니다. 모델 라이선스·허브 이용약관도 각 레포지토리 조건을 따릅니다.

트래픽이 갈라지는 대표 축

실제 현장에서는 매 버전마다 호스트 표기가 조금씩 달라질 수 있어 “완결 목록”보다 로그로 확인한 이름을 규칙에 옮기는 습관이 더 안전합니다. 그래도 방향을 잡기 위해 자주 등장하는 축은 다음과 비슷합니다.

  • 허브 웹·API 축: 브라우저 탭에서 레포를 열거나 작은 메타데이터를 주고받을 때 보이는 huggingface.co 계열 요청.
  • 짧은 리다이렉트·별칭 축: hf.co처럼 리다이렉트 체인에 섞이는 호스트. 규칙에서 빠뜨리면 다른 줄로 새어 나가기 쉽습니다.
  • 대용량 CDN·스토리지 후보: 바이너리 조각이 실제로 흐르는 축은 허브 도메인과 문자 그대로 같지 않은 경우가 많습니다. 클라이언트 로그에 찍힌 호스트 이름 전체를 기준으로 잡는 편이 정확합니다.
  • LFS·조각 전송: 이름에 lfs가 들어가거나 경로에 조각 식별자가 길게 붙는 요청은 글로벌 규칙 한 줄에 섞이면 노드 특성과 안 맞아 끊길 수 있습니다.
  • 컨테이너 레지스트리: 모델이 아니라 이미지를 당겨 오는 흐름이라면 ghcr.io 같은 호스트가 따로 찍힙니다.

정리하면 “허브 사이트가 열린다”와 “ollama pull이 끝까지 간다”는 서로 다른 검증입니다. 앞장에서 나열한 축 가운데 하나만 다른 전략으로 새 나가도 최종 결과는 실패로 돌아가기 쉽습니다.

증상을 로그로 좁히기

설정을 건드리기 전에 Clash 클라이언트의 연결 기록에서 같은 시각대의 호스트를 스크롤해 보세요. 다음 패턴이 보이면 분기 후보가 이미 떠 있습니다.

  • 앞부분 요청은 특정 노드로 나가는데, 용량이 큰 요청만 DIRECT나 다른 그룹으로 튕겨 나간다.
  • 동일 명령을 반복할 때마다 실패 지점 직전 호스트만 바뀐다. DNS 응답이나 리다이렉트 단계에서 새 호스트가 노출된 것입니다.
  • 브라우저 확장 프로그램으로는 빠른데, 터미널 바이너리만 오래 걸린다. 이 경우는 규칙과 별개로 프로세스 단 프록시 미적용을 의심합니다.

원격 규칙 세트를 쓰고 있다면 목록이 최신인지도 함께 봅니다. 갱신이 자주 멈추면 다른 문제로 헛발을 디디기 쉬우므로, rule-provider·원격 규칙 갱신 문제 글의 순서로 먼저 정상화하는 편이 낫습니다.

프록시 그룹 설계

실무에서는 새 그룹 이름 하나만 만들어도 충분한 경우가 많습니다. 예를 들어 PROXY_HF 같은 selector를 두고, 후보로 안정적인 노드 두세 개와 필요하면 DIRECT를 함께 넣습니다. url-test로 자동 회전시키고 싶다면 테스트 URL을 너무 가벼운 페이지 하나에만 고정하지 말고, 실제로 문제가 되는 다운로드 축과 완전히 무관한 응답만 보게 되지 않는지도 의식합니다.

공항 프리셋이 이미 비슷한 용도 그룹을 제공한다면 이름만 맞춰 참조해도 됩니다. 중요한 것은 “어떤 이름의 그룹으로 규칙을 묶을지”가 팀 안에서 일관되게 읽히는지입니다.

규칙 배치와 YAML 스케치

rules 배열에서는 더 좁은 매칭을 위쪽에 둡니다. 아래 예시는 출발점일 뿐이며, 실제 운영에서는 로그에 나온 호스트를 한 줄씩 덧붙여야 합니다.

# Sketch only — expand hostnames from your live connection logs.
proxy-groups:
  - name: PROXY_HF
    type: select
    proxies:
      - YOUR_MAIN_PROXY
      - DIRECT

rules:
  - DOMAIN-SUFFIX,huggingface.co,PROXY_HF
  - DOMAIN-SUFFIX,hf.co,PROXY_HF
  - DOMAIN-KEYWORD,lfs,PROXY_HF
  # Append CDN/storage hosts seen during failed pulls.

DOMAIN-KEYWORD는 편하지만 과하게 넓으면 의도치 않은 사이트까지 같은 출구로 모입니다. 최종 형태에서는 가능한 한 DOMAIN-SUFFIX와 로그에 관측된 전체 호스트명 위주로 좁히는 것이 안전합니다.

충돌 순서

GEOIP나 거대한 원격 규칙 세트가 위쪽에서 이미 매칭을 끝내 버리면, 아래에 새로 넣은 HF 줄은 실행되지 않습니다. “규칙을 추가했는데 로그가 안 바뀐다”면 우선 순서를 의심하세요.

ghcr·기타 레지스트리까지 확장하기

모델 파일이 아니라 컨테이너 레이어를 당겨 오는 스크립트라면 실패 호스트가 허브와 전혀 다를 수 있습니다. 로그에 ghcr.io가 반복되면 같은 프록시 그룹으로 묶거나, 레지스트리만 다른 그룹으로 빼서 노드를 따로 고르게 만들 수 있습니다. 레지스트리 축은 인증 헤더·청크 재개 같은 특성이 있어, 불안정한 노드에서만 문제가 드러나기도 합니다.

Ollama 프로세스에 프록시 반영하기

Clash 규칙이 아무리 완벽해도, 터미널에서 돌아가는 바이너리가 프록시 정보를 모르면 효과가 반쪽입니다. 일반적으로는 다음 환경변수를 같은 셸 세션에서 내보낸 뒤 ollama pull을 다시 시도합니다.

  • HTTPS_PROXY와 HTTP_PROXY: 로컬 Clash가 노출한 HTTP 또는 SOCKS 주소를 넣습니다. 클라이언트가 어떤 스킴을 권장하는지에 맞춥니다.
  • ALL_PROXY: 일부 스택이 여기를 우선 보기도 합니다.
  • NO_PROXY: 루프백·사내망·특정 레지스트리 mirror를 직접 두고 싶을 때만 신중히 채웁니다.

서비스 형태로 상주 실행된다면 systemd 유닛의 Environment=, macOS의 Launch Agent plist, Windows 서비스 환경 같은 위치에 같은 값을 넣어야 재부팅 뒤에도 유지됩니다. GUI 클라이언트가 시스템 프록시만 등록하고 있다면, 터미널 도구는 여전히 비어 있을 수 있다는 점을 염두에 둡니다.

TUN이 필요해지는 경우

환경변수를 무시하는 바이너리나 Go 기본 스택의 특정 빌드 조합에서는 프록시 주입이 불완전할 수 있습니다. 이때는 클라이언트의 TUN 모드로 시스템 라우팅 자체를 잡는 선택지가 있습니다. 다만 권한·다른 VPN과의 충돌·회사 보안 소프트웨어 같은 변수가 커지므로, 우선 시스템 프록시와 환경변수 조합으로 재현 가능한 최소 설정을 만든 뒤 단계적으로 옮기는 편이 디버깅 비용이 적습니다.

DNS·Fake-IP와 함께 볼 때

증상이 “규칙을 고쳤는데 여전히 엉뚱한 출구”처럼 보이면 DNS 단계에서 이미 엇나갔을 수 있습니다. Fake-IP를 켠 프로필이라면 필터와 예외 목록이 허브 호스트와 충돌하지 않는지, 도메인 규칙과 IP 규칙이 같은 트래픽을 두 번 다르게 해석하지 않는지 점검합니다. 이 부분은 서비스별 CDN 글들과 공통되는 레이어입니다.

검증 순서 요약

  1. 동일 명령으로 문제를 한 번 재현하고 연결 로그에 어떤 호스트가 찍히는지 목록화합니다.
  2. 프록시 그룹을 만든 뒤 세분 규칙을 상단에 추가하고 코어를 재적용합니다.
  3. 터미널에 프록시 환경변수를 넣고 같은 셸에서 다시 받아 봅니다.
  4. 진행 시간과 실패 메시지가 바뀌었는지 비교합니다. 호스트가 새로 보이면 그 줄을 규칙에 추가하는 과정을 반복합니다.
  5. 그래도 정체가 남으면 DNS·TUN·다른 필터를 순서대로 격리합니다.

자주 묻는 질문

전역 프록시 한 줄이 더 간단하지 않나요?

간단하지만 대용량 Blob까지 같은 노드 특성에 묶입니다. 지연은 낮아 보여도 긴 세션에서 끊기는 노드라면 오히려 재시도 폭증으로 더 불안정해질 수 있습니다. 분기는 설정 줄 수가 늘지만 출구 선택의 자유도를 되돌려 줍니다.

허브만 빠르게 열리면 성공인가요?

아니요. 웹 UI와 실제 가중치 경로는 다른 호스트일 수 있습니다. pull 명령이 끝까지 성공하는지를 최종 기준으로 두세요.

규칙이 계속 길어집니다.

정상입니다. 인프라가 진화하면 CDN 패턴도 바뀝니다. 주기적으로 로그를 다시 스캔하고 안 쓰는 줄을 정리하는 관리가 필요합니다.

정리

Ollama가 Hugging Face 연결에서 멈추는 많은 사례는 단일 노드 품질 문제만이 아니라 호스트 축이 여러 갈래인데 규칙은 한 갈래만 바라보는 상태에서 발생합니다. 로그로 실제 이름을 확인하고 Clash에서 세분 매칭을 위로 올린 뒤, 터미널 프로세스에까지 프록시 정보가 전달됐는지 검증하면 같은 증상이라도 원인 범위가 빠르게 줄어듭니다.

과거에는 규칙 파일을 수작업으로 맞추느라 시간을 많이 썼지만, 원격 규칙 프로바이더와 내장 편집기가 있는 최신 클라이언트는 같은 보안 전제에서 반복 시험 비용이 더 낮습니다. 한쪽 화면은 연결 로그, 다른 쪽은 YAML 또는 GUI 규칙 탭을 열어 두고 호스트가 새로 나올 때마다 한 줄씩 옮기면 장기적으로도 관리가 수월합니다.

일부 도구는 분기 개념 없이 전역 스위치만 제공해 대용량 전송에서 같은 병목을 반복하기 쉽고, 규칙을 고쳐도 앱이 프록시를 모르면 체감이 바뀌지 않습니다. Clash 계열은 규칙·프로세스 환경·TUN까지 같은 맥락에서 맞출 수 있어 개발용 다운로드에 특히 잘 어울립니다. 최신 클라이언트 패키지는 Clash 다운로드 센터에서 한번에 비교할 수 있으니, 지금 쓰는 환경에 맞는 빌드를 고른 뒤 Clash를 무료로 내려받아 규칙 실험을 시작해 보시길 권합니다.