Issue Station
Sign In
Tools hereToolbox

ollama - 💡(How to fix) Fix "no such host" error during blob download for specific tags despite active proxy configuration [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
ollama/ollama#15708•Fetched 2026-04-20 11:59:10
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
cubemaccubemac
Participants
cubemaccubemac
Timeline (top)
labeled ×1

Error Message

There is an inconsistency in how Ollama handles DNS resolution for different model tags when a proxy is configured. While standard tags pull successfully, specific or longer tags (e.g., qwen3.6:35b-a3b-coding-nvfp4) fail with a no such host error. The pull for the specific tag starts, retrieving the manifest and initiating the first blob, but then fails immediately with a DNS error: Error: max retries exceeded: Get "https://registry.ollama.ai/v2/library/...": dial tcp: lookup registry.ollama.ai on <internal-dns-ip>:53: no such host

RAW_BUFFERClick to expand / collapse

What is the issue?

Bug Report: Inconsistent DNS resolution when pulling specific model tags behind a proxy

Ollama Version: 0.21.0 OS: macOS (Apple Silicon M4 Pro) Network Environment: Restricted corporate network. All external traffic must go through an HTTP/HTTPS proxy. Internal DNS cannot resolve external hostnames.

Description:

There is an inconsistency in how Ollama handles DNS resolution for different model tags when a proxy is configured. While standard tags pull successfully, specific or longer tags (e.g., qwen3.6:35b-a3b-coding-nvfp4) fail with a no such host error.

Crucially, the failure often occurs after the manifest has been successfully retrieved and the blob download has initiated, suggesting that subsequent connection attempts or retries are bypassing the proxy's DNS resolution.

Steps to Reproduce

Configure proxy environment variables: export HTTP_PROXY="http://<proxy-host>:<port>" export HTTPS_PROXY="http://<proxy-host>:<port>" export no_proxy="localhost,127.0.0.1" Start the server: ollama serve Pull a standard model: ollama pull qwen3.6:35b -> Success Pull a specific tag: ollama pull qwen3.6:35b-a3b-coding-nvfp4 -> Fail Observed Behavior

The pull for the specific tag starts, retrieving the manifest and initiating the first blob, but then fails immediately with a DNS error:

pulling manifest pulling model: 0% ▏ ▏ 11 KB/ 21 GB
Error: max retries exceeded: Get "https://registry.ollama.ai/v2/library/...": dial tcp: lookup registry.ollama.ai on <internal-dns-ip>:53: no such host It appears that while the initial request respects the proxy, certain subsequent calls (possibly for specific blobs or during multi-threaded downloads) attempt a local DNS lookup against the <internal-dns-ip>, which is unable to resolve external addresses.

Expected Behavior

Ollama should use the configured proxy for all network operations, including DNS resolution for every manifest and blob request, regardless of the tag length or complexity.

Additional Context

curl -I -x http://<proxy-host>:<port> https://registry.ollama.ai/v2/ works consistently in the same environment. The issue is reproducible even when GODEBUG=netdns=go or netdns=cgo is set. The fact that it fails after pulling the first few KB of the model blob indicates that the proxy was initially used, but then lost or bypassed for the next connection attempt.

Relevant log output

OS

macOS

GPU

Apple

CPU

Apple

Ollama version

0.21.0

extent analysis

TL;DR

The issue can be mitigated by ensuring that all DNS lookups are routed through the configured proxy, potentially by adjusting the no_proxy environment variable or implementing a custom DNS resolver.

Guidance

  • Review the no_proxy environment variable to ensure it is not inadvertently bypassing the proxy for certain hosts or subdomains.
  • Consider setting GODEBUG=netdns=go to force Go's internal DNS resolver, which might help in troubleshooting or as a temporary workaround.
  • Verify that the proxy server is correctly configured to handle DNS resolution for external hosts, as the issue seems to stem from a mismatch in DNS resolution between the initial request and subsequent connections.
  • Test the proxy configuration using tools like curl with the -x option to confirm it works as expected for the specific URLs used by Ollama.

Example

No specific code example is provided due to the nature of the issue, which seems more related to environment and network configuration rather than code.

Notes

The solution might depend on the specific proxy server configuration and the network environment. The fact that curl works with the proxy suggests the issue is specific to how Ollama handles DNS resolution in certain scenarios.

Recommendation

Apply workaround: Adjust the no_proxy environment variable and test with GODEBUG=netdns=go set to troubleshoot and potentially mitigate the issue, as upgrading to a fixed version is not mentioned as an option in the provided context.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#environment variable

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING