ollama pull model_name:tag puede descargar muy lento en algunas regiones, y el proceso no siempre es estable.
Si el problema que encuentras es que la descarga de un modelo grande se interrumpe repetidamente a mitad de camino, con errores como TLS handshake timeout o unexpected EOF, es muy probable que el problema no esté solo en registry.ollama.ai, sino en la ruta real de descarga después de la redirección.
Este artículo registra una idea de diagnóstico simple y directa: primero obtener la dirección real de descarga del archivo del modelo, luego confirmar dónde termina realmente el tráfico y por último optimizar solo los dominios clave.
Obtener la dirección de descarga del archivo del modelo
Puedes usar el siguiente proyecto para extraer directamente el manifest y las direcciones de descarga de blobs correspondientes al modelo de Ollama:
https://github.com/Gholamrezadar/ollama-direct-downloader
Tomando gemma4:latest como ejemplo, se pueden extraer enlaces parecidos a los siguientes.
Dirección del manifest
|
|
Direcciones de blobs
|
|
Si solo quieres verificar rápido, también puedes descargar directamente el manifest y los blobs con curl:
|
|
Dirección real después de la redirección
Al intentar descargar uno de los blobs con wget, verás que la solicitud no se queda siempre en registry.ollama.ai, sino que redirige a una dirección de almacenamiento de objetos Cloudflare R2:
|
|
En el log se ven varios puntos clave:
registry.ollama.aidevuelve307 Temporary Redirect- La dirección final cae en
*.r2.cloudflarestorage.com - La transferencia real del archivo grande la soporta en realidad el dominio de almacenamiento de objetos posterior
Este paso es importante, porque demuestra que si tu proxy o reglas de routing solo cubren registry.ollama.ai, pero no tratan *.r2.cloudflarestorage.com, la descarga seguirá pudiendo ser lenta o interrumpirse repetidamente.
Ajustar la configuración de red
Después de confirmar la ruta real de descarga, la dirección de diagnóstico queda mucho más clara.
Si estás usando proxy, reglas de routing o DNS personalizado, se recomienda revisar primero:
- Si
registry.ollama.aiy*.r2.cloudflarestorage.compasan por la misma ruta estable - Si las reglas de proxy solo cubren el primero y se olvidan del segundo
- Si la salida actual es adecuada para descargas sostenidas de varios GB o decenas de GB
La clave de este tipo de problema no es “si se puede abrir la web oficial”, sino “si la ruta de almacenamiento de objetos después de la redirección es estable y puede transferir durante largo tiempo”. Muchas veces, lo que de verdad hay que optimizar es la capa Cloudflare R2, no el dominio registry anterior.
Comparación antes y después del ajuste
Abajo hay una descarga real de gemma4:31b-it-q8_0.
Antes del ajuste, la velocidad era baja y aparecía error a mitad de camino:
|
|
Después del ajuste, al descargar de nuevo el mismo modelo, la velocidad y estabilidad mejoraron claramente:
|
|
Esto no significa que todos los entornos de red obtengan el mismo resultado, pero al menos muestra algo: el cuello de botella probablemente no está en el cliente Ollama, sino en la ruta real de descarga de archivos grandes.