Unable to resolve package source '...' caused by stale HTTP cache

Answer first

A stale HTTP cache entry can contribute to the generic “Unable to resolve package source ‘…’” error during restore, but it is not confirmed as the root cause without verification. The error is generic and can also be produced by network failures, authentication changes, or an unreachable source.

Confirmed facts

• NuGet clients cache HTTP responses for package metadata and package files on disk and retain ETag and Last-Modified when supplied by the source.
• Cache freshness is driven by Cache-Control directives from the source and by client-side http-cache policy configured in nuget.config. Cache location and naming have changed across NuGet versions and OS.
• For restore operations, nuget.exe and dotnet restore use the same NuGet client library. Core revalidation logic is shared. Observed differences usually come from different config layers, MSBuild properties, or command-line switches, not from a separate validation algorithm per tool.

Likely explanation

A previously cached metadata response, such as a 404 or an outdated index, can be served while the entry is considered fresh per max-age. If the source later changes its index, removes a package, or alters headers, the stale entry can surface as the generic “Unable to resolve package source” rather than a fresh server error.

When revalidation is skipped

Revalidation with If-None-Match or If-Modified-Since is typically attempted when a cached entry is stale per max-age or when the source requires validation. Skip is more likely when:

• The entry is within max-age and the source provides permissive Cache-Control.
• The source omits validation headers, so the client has no basis to revalidate.

Cache-Control behavior is source-dependent. A source that omits or weakens headers increases risk of stale reads regardless of client settings.

Force revalidation without disabling caching entirely

Cache behavior can be influenced via nuget.config http-cache settings and via restore options that bypass the local HTTP cache for a single operation. Exact names and defaults are version-sensitive.

Scoped verification steps:

1. Check effective configuration and versions.

nuget help

dotnet --version

Note the client version reported and the effective nuget.config hierarchy for http-cache mode and duration settings.

2. Run restore with increased verbosity and look for cache hit vs revalidation messages for the failing source URL.

dotnet restore -v n

3. Inspect timestamps and sizes of files under the user’s NuGet http-cache directory before and after a restore to see if entries are being reused. Do not delete the global packages folder; that removes downloaded packages and increases restore time.
4. Clear only the HTTP cache for the affected source and repeat restore to see if the error changes to a fresh server error.

Assumptions and uncertainty: The design does not specify a fixed rule for honoring Cache-Control:max-age versus always re-validating. Behavior varies by NuGet client version, .NET SDK version, and source protocol type v2 vs v3. Configuration that works for one version may be ignored or renamed in another.

One missing diagnostic detail that changes the recommendation: the exact NuGet client version and whether the failing source is v2 or v3. Confirming those lets you know which http-cache policy names and restore switches apply.