Problem: ollama pull hangs/times out (official registry unreachable from CN) —— Trove problem library

What you will run into

After installing ollama, ollama pull qwen2.5 spins for tens of minutes with no progress, or reports a connection timeout; no model downloads at all.

You think the command is wrong or the model doesn't exist — it's actually the official model registry being unstable on direct CN connections, not a command problem.

Why this happens

ollama pulls models from the official registry (ollama.com / registry.ollama.ai) by default; direct CN connections to those domains are unstable (measured: official registry direct connection times out).

Model files are 4~70GB each, and a mid-transfer drop makes you start over — worse.

The right path (measured in this marketplace): download the GGUF file from ModelScope (CN-reachable) and import it with ollama create — bypassing the official registry.

Measured 2026-08-29: qwen2.5-0.5b-instruct-q4_k_m GGUF 491MB downloaded in 58.5s + create import succeeded + CPU smoke passed (local repro log 2026-08-29).

ollama pull follows "CLI → registry resolution (ollama.com/registry.ollama.ai) → fetching each layer blob by digest → writing into blobs/ and generating the manifests/ index".

When direct connectivity to the registry hostname is unstable, connections fail at the transport layer; model files are 4-70GB, and an interrupted transfer restarts from scratch.

The GGUF import path bypasses exactly the "registry resolution" hop: ollama create consumes a local GGUF file directly, computes digests, writes blobs/, and generates the manifest — the download hop moves to ModelScope (reachable domestically), and the import hop never touches the network.

Deterministic takeaway: when ollama pull hangs, first confirm it is the registry domain (curl -I https://registry.ollama.ai) rather than your command;

after GGUF import, the model appearing in ollama list is success, and at runtime it is equivalent to a pulled model (manifest + blobs); ollama run afterwards needs no network — it works offline.

Step by step

1. Confirm it's the network, not the command — Required (rule out service/command issues)

ollama list

Server working but pull hangs/times out → network problem; switch to the ModelScope path.

2. Download the GGUF from ModelScope — Required (check disk with df -h / first)

curl -sL -o /tmp/qwen2.5-0.5b-instruct-q4_k_m.gguf https://modelscope.cn/models/Qwen/Qwen2.5-0.5B-Instruct-GGUF/resolve/master/qwen2.5-0.5b-instruct-q4_k_m.gguf

Measured: 491MB / 58.5s (2026-08-29, campus network reachable). Check disk first: df -h /.

3. Import with ollama create — Required

ollama create qwen2.5:0.5b -f - <<EOF
FROM /tmp/qwen2.5-0.5b-instruct-q4_k_m.gguf
EOF

(The Modelfile can also be written to a file and passed with -f ./Modelfile.)

4. Verify and run — Required (acceptance)

ollama list && ollama run qwen2.5:0.5b "hello"

Model listed and a reply produced means success (measured: create success + CPU smoke passed).

How to confirm it works

ollama list

The imported model appearing in the list means success. Measured output shape: ModelScope download 491MB/58.5s → ollama create success → model appears in the list.

When NOT to use this solution

This solution is for when the official registry is unreachable/unstable from your network; if your network can reach it directly, plain ollama pull is simpler — no need to go through GGUF import.

• When the official registry is reachable: if curl -I https://registry.ollama.ai returns 200/301, just use ollama pull — GGUF import is a detour.
• When you need an exact version/digest pin: GGUF import requires finding the matching file yourself; official pull keeps a more reliable digest mapping. Don't switch paths unless you actually have a mirror problem.
• When ollama runs inside a container: container images usually ship with registry config baked in — try pulling inside the container first, it's faster than GGUF import on the host.

Not sure? Run curl -I https://registry.ollama.ai — reachable means go official; unreachable means this page's path.

Other environments

Symptom

Common failure forms of ollama pull:

# Form 1: stuck with no progress / connection timeout (unstable direct registry)
ollama pull qwen2.5
# spins for tens of minutes, or Error: ... dial tcp ... i/o timeout

# Form 2: large transfer dies halfway
# unexpected EOF / connection reset mid-download

# Form 3: model name does not exist (not a network problem)
Error: pull model manifest: ... not found

Same family but different root cause (don't fight the network on this page):

• pull model manifest: ... not found -> misspelled/nonexistent model or tag; verify the name on ModelScope / HuggingFace first;
• no space left on device (download/import stage) -> models are 4~70GB, check df -h / first; under WSL, df showing free space but writes failing means the host drive is full — see wsl-no-space-left.

Cause

The official model registry (ollama.com / registry.ollama.ai) is unstable on direct CN connections; large model transfers fail midway.

Solution

1. Download the GGUF from ModelScope: curl -sL -o /tmp/qwen2.5-0.5b-instruct-q4_k_m.gguf https://modelscope.cn/models/Qwen/Qwen2.5-0.5B-Instruct-GGUF/resolve/master/qwen2.5-0.5b-instruct-q4_k_m.gguf.
2. Import with `ollama create qwen2.5:0.5b -f - <<EOF

FROM /tmp/qwen2.5-0.5b-instruct-q4_k_m.gguf EOF`.

1. Confirm with ollama list, verify with ollama run.

Related canonicals

Read in order: precondition -> this page -> same root / related:

• Precondition (rule out first): ollama won't install — official installer unreachable — no install, no pull
• Follow-up (pits after pulling): ollama reports "could not connect" — model pulled but server not started/unreachable
• Same root (unstable registry direct-connect -> switch source): docker pull fails / mirror (docker image registry direct-connect unstable -> mirror accelerator, same family of fixes)
• Related (same domain):
• Open WebUI RAG retrieval not working / embedding misconfig (embedding model not pulled -> file upload 404)
• Move the model directory (model storage dir is movable)