NuGet merges settings from several nuget.config files, and the file closest to your solution wins for single value settings. Lists such as package sources are combined across files, unless a clear element resets them. Without a clear, a stray user or parent folder file can add sources you never intended.
Where NuGet looks
Per Microsoft's documentation, when you do not name a config file on the command line, NuGet loads settings in this order:
- The uncommon NuGetDefaults.Config, which holds package source settings only.
- The computer level file.
- The user level file.
- Every folder from the drive root down to the current folder, which for a solution is the solution folder.
If you pass a config file explicitly, such as restore with the configfile option, only that file is used.
How values combine
| Type of setting | Rule |
|---|---|
| Single item, for example a default push source | The closest file replaces earlier values |
| Collection, for example package sources | Values from all files are combined |
| A clear element on a node | Earlier values for that node are ignored |
Keys are case sensitive. A config file placed in a project folder, rather than the solution folder, has no effect on that project when restoring the solution. Restoring a project on its own treats the project directory as the solution directory, which can lead to different behavior.
Why this is a security matter
Package sources are a collection, so they accumulate. A developer's user level file may list a feed they added for a side project. A parent folder may contain a file from an unrelated checkout. NuGet will happily use them all. Microsoft's best practices call out the Downloads folder in particular, because NuGet accumulates settings from parent folders and MSBuild imports Directory.Build.props from parent directories too.
The repeatable pattern
Put one nuget.config at the repository root. Start the sources list with clear, then add exactly what you want.
<configuration>
<packageSources>
<clear />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
</packageSources>
<packageSourceMapping>
<clear />
</packageSourceMapping>
</configuration>
Microsoft recommends clear elements so that no user or machine specific configuration is applied.
A debugging routine
- Note the folder you run restore from.
- List every nuget.config on the path up to the drive root, plus the user and machine files.
- Read the sources and mappings in order and apply the three rules.
- Check for malformed XML. NuGet silently ignores an entire file that is not well formed, which Microsoft warns about.
- Fix by adding or moving clear elements, then restore again and read the source list in the output.
Things clear does not do
A clear in your repository file does not stop an administrator from deploying NuGetDefaults.Config, and no NuGet setting can block access to nuget.org on its own. Microsoft says a firewall is needed for that.
Try it yourself
Click through it at your own pace, or open it full screen. A change to nuget.config is a good candidate for a required review, because it changes where code comes from.
Safeguard policies and gates can run checks on pull requests, and a free scan covers your dependency list.
Quick check
If I forget the clear element, what happens?
Sources from other config files are added to yours, so restore may use feeds you did not list.
Does a nuget.config inside a project folder apply to that project?
Not reliably. Microsoft notes a file in a project folder has no effect when restoring through the solution. Use the solution or repository root.
Sources
- Common NuGet configurations, Microsoft Learn
- Best practices for a secure software supply chain, Microsoft Learn
Last reviewed: 19 October 2026.
