Ollama ollama pull이 pulling manifest에서 멈출 때 무엇을 의미하나

로컬에서 로컬 LLM을 돌리려면 결국 한 번은 ollama pull <모델>을 실행하게 됩니다. 진행 표시줄이 빠르게 올라가다가도 초반에 pulling manifest 문구에서 수십 분이 지나가거나, 아예 응답 없이 멈춘 것처럼 보일 때 사용자는 대개 “회선 전체가 끊겼나”부터 의심합니다. 그러나 컨테이너 registry와 비슷하게, 모델 카탈로그를 돌려주는 레지스트리 API 축과 실제 가중치 파일을 내려받는 CDN·오브젝트 스토리지 축은 호스트명만으로도 쉽게 갈라집니다. 한 축은 프록시를 타면 안정적인데 다른 축은 넓은 GEOIP 직통 규칙에 걸려 느린 출구로 새거나, 반대로 회사 방화벽이 특정 미러 이름만 막는 식의 부분 장애일 수 있습니다.

본문은 법적으로 허용된 네트워크 환경에서만 적용한다는 전제 하에, Clash 또는 Mihomo 계열 클라이언트로 분할 규칙을 어떻게 쌓아야 하는지에 초점을 맞춥니다. 이미 저장소에 있는 npm 레지스트리·tarball 분할 글이나 Hugging Face LFS 시리즈와 맥은 같습니다. 메타데이터는 빠른데 덩치 큰 바이너리만 막히는 패턴은 애플리케이션 이름이 npm이든 Ollama든 디버깅 습관이 동일합니다.

안내: Ollama 측이 사용하는 정확한 호스트명과 리다이렉트 체인은 버전·지역·레지스트리 정책에 따라 바뀔 수 있습니다. 아래에 등장하는 registry.ollama.ai·ollama.com 등은 이해를 돕기 위한 출발점이며, 실제 장애 재현 시 터미널·프록시 로그에 찍힌 FQDN을 기준으로 목록을 교체해야 합니다.

Docker Hub·Docker Desktop 시나리오와의 차이

Docker Hub에서 베이스 이미지를 받을 때와 겉으로는 비슷해 보이지만, 호스트 묶음이 완전히 같지는 않습니다. Docker 엔진은 registry-1.docker.io 계열과 production.cloudflare.docker.com 류의 분기가 흔하고, Ollama CLI는 기본적으로 Ollama 프로젝트가 운영하는 레지스트리 이름공간으로 붙습니다. 그래서 Docker용으로 잘 정리된 규칙 세트를 그대로 복사해도 ollama pull 한 줄에는 빈 구멍이 남습니다.

다만 개발자 PC에서 Docker Desktop과 Ollama를 동시에 쓰는 경우가 많으므로, 한 프로필 안에서 레이어 다운로드와 Ollama blob을 서로 다른 전략 그룹에 태우면 일상 웹 서핑까지 끌고 가지 않고도 두 레이턴시를 동시에 잡을 수 있습니다. 컨테이너 내부에서 Ollama 서버를 띄우는 구성이라면, 호스트의 TUN 적용 범위와 브리지 네트워크 설정까지 함께 봐야 타임아웃 원인이 호스트인지 컨테이너인지 갈립니다.

pulling manifest형 증상을 나누는 체크리스트

아래에 해당하면 Clash 연결 패널을 열고 문제가 된 TCP 세션이 어떤 정책에 매칭됐는지부터 확인하는 편이 빠릅니다.

  • 메시지는 manifest인데 실제로는 이미지 blob에 시간이 걸림: 진행률 UI가 단계 이름만 보여 줄 때가 있어, 뒤늦게야 대용량 전송이 시작되는 경우입니다. 세션 목적지 호스트가 ollama 상표와 다른 스토리지 업체 도메인으로 바뀌었는지 봅니다.
  • 동일 Wi-Fi에서는 되지만 LTE 테더링에서만 실패: 이동통신사 DNS나 필터가 특정 HTTPS 미러만 막는 패턴입니다. 분할 규칙에서 해당 이름만 다른 노드로 보내거나, DIRECT가 오히려 느린 경우 프록시로 올립니다.
  • curl로 작은 API는 되는데 ollama만 실패: HTTPS_PROXY 가 터미널에만 없고 GUI 클라이언트만 프록시를 쓰는 구성, 혹은 그 반대인 경우가 많습니다.
  • 사내 공식 미러를 썼을 때만 즉시 완료: 공개 registry와 사내 이름공간이 갈라져 있으므로, 사내 호스트는 DIRECT로 고정하고 공용 이름만 글로벌 노드로 보내야 충돌이 줄어듭니다.

registry·미러·blob 후보를 DOMAIN으로 묶기

첫 실행에서는 DOMAIN-SUFFIX 로 넓게 시작했다가, 대시보드에서 실제 매칭 도메인을 보며 한 줄씩 좁히는 방식이 안전합니다. 광역 패턴이 과하면 음악 스트리밍처럼 전혀 관계없는 트래픽까지 같은 고지연 노드로 흘러가 타임아웃 체감만 바뀔 수 있습니다.

공개 문서·커뮤니티 로그에서 자주 등장하는 축은 registry.ollama.ai 와 ollama.com 주변입니다. 리다이렉트 끝이 클라우드 스토리지 브랜드를 가리키면 그 FQDN을 별도 그룹에 넣고, 회사에서 허용한 미러 전용 접두사가 있다면 그 묶음은 최상단에 두어 다른 규칙이 가로채지 못하게 합니다.

실무 팁: Linux나 macOS에서 OLLAMA_DEBUG=1 환경 변수를 주고 pull을 다시 실행하면 HTTP 레벨에서 어떤 URL까지 도달했는지 단서가 늘어납니다. 로그에 찍힌 호스트명을 그대로 클립보드에 모아 두었다가 Clash 프리로드 귀칙에 붙여 넣으면 추측보다 정확합니다.

YAMLproxy-groups:
  - name: "OLLAMA-REGISTRY"
    type: select
    proxies:
      - DIRECT
      # Stable nodes for small JSON / manifest APIs
      - node-A
      - node-B

  - name: "OLLAMA-BLOBS"
    type: url-test
    url: https://registry.ollama.ai/v2/
    interval: 300
    tolerance: 50
    proxies:
      - node-B
      - node-C
      - DIRECT

  - name: "Proxy"
    type: select
    proxies:
      - DIRECT
      - node-A
      # ...

rules:
  - DOMAIN,registry.ollama.ai,OLLAMA-REGISTRY
  - DOMAIN-SUFFIX,ollama.com,OLLAMA-REGISTRY
  # Append observed blob/CDN hosts from your own logs:
  # - DOMAIN-SUFFIX,example-cdn.vendor.tld,OLLAMA-BLOBS
  # Mirror / on-prem registry base:
  # - DOMAIN-SUFFIX,mirror.mycompany.internal,DIRECT

예시에서 url-test 헬스 URL은 구독 환경에 맞게 바꿉니다. 레지스트리 ping이 blob 회선과 다르면 별도의 소형 정적 파일 URL을 섞거나, 수동 select 그룹으로 운용하는 편이 디버깅에 유리할 때가 있습니다.

HTTPS_PROXY·NO_PROXY와 TUN·DNS 정렬

Ollama CLI는 Go 런타임의 기본 프록시 환경 변수를 따르는 경우가 많습니다. Clash mixed-port 가 7890 이라면 셸에 export HTTPS_PROXY=http://127.0.0.1:7890 를 선언하고, 로컬 추론 API는 빠르게 하려면 export NO_PROXY=127.0.0.1,localhost 를 함께 두는 편이 낫습니다. 프록시 변수는 있지만 커널 경로는 TUN 을 타지 않는 혼합 상태면, 터미널만 예외적으로 막히는 것처럼 보이기도 합니다.

DNS 층면에서 fake-ip 를 쓰는 프로필이라면, OS 캐시와 Clash DNS의 교차 때문에 분할 규칙이 첫 패킷부터 어긋날 수 있습니다. 규칙 우선순위 가이드 에서 설명하듯 GEOIP 한 줄이 앞서면 그 뒤의 Ollama 전용 줄은 장식이 됩니다. 실패가 재현되는 동안에는 문제 호스트 줄을 잠시 최상단 근처로 끌어올려 반응을 확인하고, 안정되면 원래 자리에 맞춥니다.

  1. ollama rm <모델> 로 캐시를 비우거나 새 모델 이름으로 똑같이 재현합니다.
  2. Clash 로그에서 해당 세션의 rule 이름과 proxy 이름을 캡처합니다.
  3. 노드를 바꾸거나 DIRECT 여부를 바꿔 한 번에 한 축만 조정합니다.
  4. 문제가 blob 축으로 좁혀지면 OLLAMA-BLOBS 그룹의 후보만 교체합니다.
  5. 새벽 대역에서도 같은지 확인해 ISP 혼잡인지 노드 품질 문제인지 나눕니다.

위험: 알 수 없는 서드파티 미러 URL을 그대로 신뢰하면 바이너리 무결성 검사를 우회하는 셈이 될 수 있습니다. 조직 정책으로 승인된 미러가 아니면 공식 레지스트리나 내부 아티팩트 저장소만 사용하고, 규칙에 넣기 전에 TLS 인증서 체인까지 검증하십시오.

FAQ 정리와 마무리

pulling manifest 문자열만 보고 네트워크 레이어 전체를 의심하기보다, 실패 시점의 TCP 목적지와 응답 코드를 한 줄이라도 남기는 습관이 가장 큰 시간 절약으로 이어집니다. 모델 카드 JSON과 멀티파트 다운로드가 서로 다른 제공자를 가리키면, 한 줄짜리 MATCH 규칙으로는 절대 같이 해결되지 않습니다.

Windows나 Linux 서비스로 Ollama를 띄운 뒤 밤새 동기화 스크립트를 돌릴 때는 GUI 프록시 토글과 systemd 유닛 환경 변수가 어긋나기 쉬우므로, 서비스 정의 파일 안에 Environment=HTTPS_PROXY=... 를 명시했는지도 점검합니다.

대용량 전송이 많을수록 단일 상용 VPN 앱의 “모든 앱 동시 터널” 모드는 스트리밍·금융·사내 포털까지 같은 출구로 몰아넣어 체감 속도를 깎아 버리기 쉽습니다. 반면 Clash 계열은 행 정책 한 줄마다 목적지와 노드를 바꿀 수 있어, Ollama blob만 안정 회선으로 보내고 국내 사이트는 DIRECT로 남기는 식의 미세 조정이 가능합니다. 다만 룰 파일을 손으로 얽어놓으면 팀원마다 디바이스 상태가 조금씩 다를 때 재현이 느려지기도 하므로, 검증된 패턴과 언어별 글을 한곳에 모아 두는 것이 장기적으로는 가장 저렴한 비용입니다.

범용 VPN보다 분할 규칙과 구독 수명주기까지 한 흐름으로 정리된 클라이언트를 찾는다면 Clash 공식 사이트 가 로컬 개발자와 LLM 실험 환경 사이의 간격을 줄이는 데 도움이 됩니다. 미세 호스트 목록을 쌓는 법과 문서 허브 를 함께 두고 참고한 뒤, 위 순서대로 다시 ollama pull 을 재현 테스트해 보고 싶다면 Clash 공식 사이트 클라이언트를 내려받아 동일 프로필 패턴을 적용해 보시면 manifest 단계 정체와 실제 타임아웃 을 한 번에 분리해 보기 쉬워집니다.