Fix NU1301: Diagnose NuGet Service Index Errors

DEV Community

nu1301 unable to load service index, and which source failed

A nu1301 unable to load service index error means dotnet restore asked a package source for its V3 index and did not get a usable answer, so it never got as far as looking for your packages. The message always names the source, and the second line, which people skip, carries the reason. Read those two lines together and the error resolves into one of three ordinary situations. NU1301 is raised before any package lookup happens, which is why it names a source and never a package. The second line is the one that says what to fix. What this error means Restore fails early, before any package is mentioned, with a line that names your project file, the code NU1301, and a source URL. A second NU1301 line follows, indented, carrying the underlying failure. NuGet documents NU1301 as "Restore could not be completed because the listed source is unavailable", which covers a remote feed that will not answer and a local folder that is not there. The block below is a container running the .NET SDK 10.0.401 with a single package source pointed at a server that answers 503 to everything. This page carries no reproduction on a Latchkey runner, so the host in the message is ours; the two line structure is the part that matches yours. ```.NET SDK 10.0.401, package source answering 503 /w/app.csproj : error NU1301: Unable to load the service index for source http://mirror503:8899/v3/index.json. /w/app.csproj : error NU1301: Response status code does not indicate success: 503 (Service Unavailable). Failed to restore /w/app.csproj (in 5.44 sec).

Common causes

A private feed is down, throttled or slow

Azure Artifacts, a GitHub Packages feed or a self hosted Nexus answering 503 or 429 is the everyday version. Restore contacts the index before it knows what it needs, so the failure arrives before any package name appears and looks unrelated to the change that triggered the build.

The restore is authenticating to a feed it was never given credentials for

A private feed answers 401 to an anonymous index request, and NuGet reports that as NU1301 rather than as an authentication error, which sends people looking for an outage. On GitHub Actions this usually means the credential provider was not installed, or the source was added without a token in the step that added it.

A source from a developer machine is in scope on the runner

A nuget.config checked into the repository, or one in a parent directory of the checkout, can carry a local folder source or an internal host that does not exist in CI. NuGet merges configuration files up the directory tree, so a source nobody remembers adding is still contacted on every restore.

The runner cannot reach the host at all

A self hosted runner behind a proxy, a network policy that blocks egress to a new domain, or DNS that does not resolve an internal name. The second line says so plainly in this case, naming a connection or name resolution failure rather than a status code, which is the fastest way to tell this cause apart from the others.

How to fix it

Find out which source failed, and whether you need it

1. Print the sources the runner will actually use, which is the merged result of every nuget.config in scope, not just the one in the repository.
2. Remove sources the build does not need. Every extra feed is another chance for restore to fail on something irrelevant.
3. Start the source list from a clean slate in the repository so a machine level configuration cannot add to it.

```Terminal
dotnet nuget list source
Pin the source list in the repository with a clear element A nuget.config at the repository root that begins by clearing inherited sources makes the restore reproducible: the runner uses exactly the feeds listed and nothing a machine level file added. This alone removes the third cause above permanently. <?xml version="1.0" encoding="utf-8"?>



<add key="nuget.org" value="https://api.nuget.org/v3/index...

Powered by Readybot.io