Ollama pull が遅いときの対処法：DNS・プロキシ・TLS・ディスク・キャッシュ

ollama pull が遅くても、最初からモデルの blob URL を探さないでください。manifest、レイヤー、オブジェクトストレージのアドレスは変化するため、古い直リンクは不安定で、Ollama の整合性確認を回避する恐れがあります。

より確実なのは、Ollama サービス、DNS、HTTPS プロキシ、証明書、オブジェクトストレージへの経路、ディスク、破損した未完了ダウンロードのどこが遅いかを切り分ける方法です。

最初にバージョンとエラー原文を記録する

1
2
3

ollama --version
ollama list
ollama pull qwen3:4b

「非常に遅い」を記録しないでください。 少なくとも元のテキスト、発生時間、モデル名、システム、オラマバージョンを保持します。 一般的な現象は異なる方向に傾向があります:

Ollama サービスが正常か確認する

ローカルAPIを最初にテストし、インターネット上のすべての問題を解決するのではなく、

1

Invoke-RestMethod -Uri 'http://127.0.0.1:11434/api/version'

ローカル API がアクセスできない場合は、Ollama を再起動し、サービスログを表示します。 Windowsのログディレクトリ:

1

explorer "$env:LOCALAPPDATA\Ollama"

モデルと構成は通常:

1

explorer "$env:USERPROFILE\.ollama"

Linux標準インストールビューログ:

1
2

sudo systemctl status ollama
journalctl -u ollama --no-pager --follow --pager-end

Docker：

1
2

docker ps
docker logs --tail 200 <container-name>

デバッグログを開く

Windowsはトレイから完全にオラマを終了し、PowerShellからデバッグモードを開始します。

1
2

$env:OLLAMA_DEBUG = '1'
& 'ollama app.exe'

現在のインストールパスが直接見つけられない場合 ollama app.exeはい。 %LOCALAPPDATA%\Programs\Ollama . ダウンロード後再びそれを読んで下さい server.log ターゲットホスト、ステータスコード、リトライ情報です。

Linux システムは一時的な暫定書を加えることができます:

1

sudo systemctl edit ollama

執筆:

1
2

[Service]
Environment="OLLAMA_DEBUG=1"

次に実行します:

1
2
3

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -u ollama --no-pager --follow

DNSとHTTPSをチェックする

ウィンドウズ:

1
2
3

Resolve-DnsName registry.ollama.ai
Test-NetConnection registry.ollama.ai -Port 443
curl.exe -I https://registry.ollama.ai/v2/

リナックス:

1
2

getent hosts registry.ollama.ai
curl -I -v https://registry.ollama.ai/v2/

バックナンバー 401 Unauthorized 必ずしも機能不全ではなく、DNS、TCP、TLSが手元から出ていることを意味します。実際の必要性は、パース、接続タイムアウト、証明書の検証の失敗、またはHTMLエラーページのプロキシリターンの失敗に集中することです。

特定のネットワーク環境のみが失敗した場合、携帯電話ホットスポットは一度にコントラストできます。 ホットスポットの成功と元のネットワークの失敗は、問題は、ローカルゲートウェイ、DNS、代理店、またはオペレータがモデル自体よりもリンクされている可能性が高いことを示唆しています。

プロキシを正しく設定する

モデル取得では Ollama が推奨する HTTPS_PROXY を設定します。特別な理由がなければ HTTP_PROXY は設定しないでください。Ollama のローカル API 自体が HTTP を使うため、誤った設定がクライアント接続を妨げることがあります。

現在のPowerShellのセッション テスト:

1
2

$env:HTTPS_PROXY = 'http://127.0.0.1:7890'
ollama pull qwen3:4b

確認したら。 HTTPS_PROXY Windows のユーザ環境変数を記述し、完全に Ollama を終了し、再起動します。 デスクトップアプリケーションは起動後に変更された環境変数を自動的に継承しません。

Linux システム:

1
2

[Service]
Environment="HTTPS_PROXY=http://127.0.0.1:7890"

Docker：

1
2
3
4
5
6

docker run -d \
  --name ollama \
  -e HTTPS_PROXY=http://proxy.example.com:8080 \
  -p 11434:11434 \
  -v ollama:/root/.ollama \
  ollama/ollama

TLS証明書のエラーを処理する方法

企業プロキシが HTTPS 証明書を再発行する場合があります。certificate signed by unknown authority が出る場合は、企業 CA を OS またはコンテナのトラストストアへ追加し、証明書検証を無効化しないでください。

包装の例:

1
2
3

FROM ollama/ollama
COPY company-ca.pem /usr/local/share/ca-certificates/company-ca.crt
RUN update-ca-certificates

信頼できないウェブサイトから、いわゆる一般証明書をダウンロードし、APIキー、プロキシパスワード、または公開ログをアップロードしないでください。

モデルディレクトリとディスクをチェックする

公式のデフォルトモデルの位置:

• ウィンドウズ:%USERPROFILE%\.ollama\models
• MacOS:~/.ollama/models
• Linux の標準サービス:/usr/share/ollama/.ollama/models

Windowsの点検スペース:

1
2

Get-PSDrive -PSProvider FileSystem
Get-ChildItem -LiteralPath "$env:USERPROFILE\.ollama\models" -Force

リナックス:

1
2

df -h
sudo du -sh /usr/share/ollama/.ollama/models

使用した場合 OLLAMA_MODELS Ollama を実行するアカウントが権限を読み、書き込みしていることを確認する場所を変更しました。 Linux標準サービスは、通常、 ollama ユーザの実行:

1

sudo chown -R ollama:ollama /path/to/models

中断後に回復する方法

同じモデルを直接お試しください:

1

ollama pull qwen3:4b

Ollamaは、利用可能なものに基づいて継続します。 サービスの実行中にバッチを削除しないでください blobs, と直接キャッシュにオンラインで見つけた空白のファイルをインサートしません.

同じレベルの反復検証が失敗した場合:

1. オラマを停止します。
2. バックアップモデルディレクトリのリスト。
3. ログから失敗したものを判断します。
4. 不完全なファイルや破損したファイルだけが削除されます。
5. Ollama を再起動し、ollama pull をもう一度実行します。

ターゲットが不確実な場合、モデルライブラリ全体を削除するのではなく、疑わしいファイルを一時ディレクトリに移動する方が好ましいです。

ダウンロード結果を検証する

1
2
3

ollama list
ollama show qwen3:4b
ollama run qwen3:4b "OK だけを返してください"

再試行、検証障害、ディスクエラーの非再生のためのログをチェックします。 ダウンロードの速度は、問題が解決されていないという意味ではありません。 渡る前に引き取られて再起動してロードすることができます。

それでも遅いときに収集すべきことは何ですか?

• Ollama 版およびオペレーティング システム。
• モデル名と近似サイズ。
• 間違ったテキストが完了するとエラーが発生します。
• プロキシ、VPN、Docker、企業証明書を使用しているか。
• registry.ollama.ai:443 接続性の結果。
• ポスト感度サービスログクリップ。
• モデルカタログの残りのスペース。

この情報は、クライアントの問題、ネットワークリンク、および上流サービスの問題と区別するのに十分であり、オフ・ザ・シェルフ・ダウンロードを共有するよりも簡単に再構築されます。

参考文献:

• オラマトラブルシューティング
• Ollama FAQ：プロキシとモデルディレクトリ