NuGet: 'error NU1301: Unable to load the service index for source'

error NU1301: Unable to load the service index for source https://nuget.invalid/v3/index.json. means one of the package sources NuGet is configured to use cannot be reached, and restore fails even if every package you need is on nuget.org. Find the source in your NuGet.config files and remove it, fix its URL, or restore with --ignore-failed-sources until it is back.

dotnet nuget list source shows every source in effect for the current folder, including ones inherited from parent folders and your user configuration. The URL in the error tells you which one to look for.

The error

  Determining projects to restore...
...\FixLab\FixLab.csproj : error NU1301: Unable to load the service index for source https://nuget.invalid/v3/index.json.
...\FixLab\FixLab.csproj : error NU1301:   No such host is known. (nuget.invalid:443)
...\FixLab\FixLab.csproj : error NU1301:   No such host is known.

The long absolute path before FixLab.csproj is shortened; nothing else was changed.

Why it happens

Every NuGet v3 source starts with a service index, a small JSON document that tells the client where to search and download. During restore NuGet asks each configured source for it. If one source fails (a mistyped URL, a company feed that needs VPN, a feed that was shut down, an expired credential), restore stops with NU1301 instead of quietly carrying on with the others.

One detail makes this error look random. In the test below, once the package was already in the global packages folder, the same broken configuration restored with only a NU1900 warning from the vulnerability check, because NuGet had no package to fetch. The error came back as soon as the project referenced a package that was not cached. So a dead source can sit unnoticed in a config for months and then break a fresh clone or a CI agent with an empty cache.

The fix

The source as it was in the project's NuGet.config:

  <packageSources>
    <add key="team-feed" value="https://nuget.invalid/v3/index.json" />
  </packageSources>

With that add line deleted, the same restore, on a package that was not cached:

  Determining projects to restore...
  Restored ...\FixLab\FixLab.csproj (in 1.33 sec).

If the feed is only down for a while and you still need to build, run dotnet restore --ignore-failed-sources. On the broken configuration it turned each NU1301 into a NU1801 warning and restored from nuget.org. Do not leave that switch in a CI script: it would also hide a real outage of a private feed you depend on, and the build would carry on with whatever the other sources offer.

How it was reproduced

On Windows 11 with .NET SDK 10.0.401: a net10.0 console project with one package reference (Bogus 35.6.1 first, then Spectre.Console 0.49.1 for the final runs) and a NuGet.config next to it that adds a source on the reserved .invalid domain, which never resolves. dotnet restore failed with the error above; with the source line removed it restored. The source name team-feed is the test's own.

Frequently asked

How do I fix NU1301 Unable to load the service index for source?

Run dotnet nuget list source to see every source in effect, then remove or correct the one whose URL is in the error. If the feed is only down temporarily, dotnet restore --ignore-failed-sources lets restore continue from the other sources.

Why does dotnet restore fail when nuget.org is working?

NuGet asks every configured source, not just nuget.org. If any one of them cannot be reached, restore stops with NU1301, even when the packages you need are on nuget.org.

Why does NU1301 only happen on CI or a new machine?

When all packages are already in the local global packages folder, NuGet has nothing to download and only warns. A machine with an empty cache has to query the sources, and the dead one fails the restore.

Another error from the restore stage is NETSDK1004: Assets file not found. More decoded errors are in the Fixes category.