Fixing .NET NuGet Timeout Issues In Ubuntu 24.04 GitLab CI/CD

Nov 8, 2025 by Andrew McMorgan 62 views

Hey Plastik Magazine readers! So, you're trying to get your .NET 8.0 project humming with CI/CD on a self-hosted GitLab CE instance, running on Ubuntu 24.04? Awesome! But, are you running into that frustrating nuget restore timeout issue? Yeah, that one can be a real headache. Let's dive into how we can tackle this and get your builds flowing smoothly. We're going to explore common causes for these timeouts and then look at effective solutions, ensuring your .NET projects build flawlessly. We'll be using Ubuntu 24.04, so we need to know all the nuances and requirements.

Understanding the Problem: NuGet Timeout Woes

Alright, let's get down to brass tacks. When you run dotnet restore, what's happening under the hood? Essentially, your project's dependencies are being downloaded from NuGet package sources. NuGet is the package manager for .NET, and it's super important for managing all those external libraries your project depends on. When the restore command takes too long, or fails altogether, you're likely seeing a timeout error. This can be caused by a few key culprits:

Network Issues: The most common culprit! Your build server might be struggling to reach the NuGet servers. This could be due to a slow internet connection, network congestion, or firewall restrictions blocking access to NuGet.org (or your private NuGet feed).
NuGet Server Problems: Sometimes, the NuGet.org servers themselves are overloaded or experiencing issues. This is less common but still possible. More often, the problem is related to the network but sometimes the servers are unreachable.
Package Source Configuration: Your nuget.config file (or lack thereof) might be misconfigured. It could be pointing to an invalid package source, or the authentication details might be incorrect for private feeds. GitLab CE itself may have some specific network configuration settings that must be considered.
DNS Resolution Problems: Your build server might be having trouble resolving the domain names of the NuGet servers. This can lead to connection timeouts.
Build Server Resource Constraints: If your build server is under heavy load (CPU, memory, disk I/O), it might not be able to complete the nuget restore operation within the allotted time. It's especially relevant if you are using a shared environment, or your server's resources are limited. So before anything else, check that the hardware meets the .NET build requirements.

Troubleshooting Steps: Diagnosing the Root Cause

Before you start applying fixes, you've got to figure out what's causing the problem. Here’s a checklist to help you diagnose the issue:

Network Connectivity Check: The first thing is to check the basics! Can your build server actually reach the internet and resolve domain names? Try pinging nuget.org from your build server's terminal. If you're getting timeouts or no responses, you have a network issue.
- ping nuget.org
If the ping test fails, check your DNS settings. You can try using a public DNS server like Google's (8.8.8.8) or Cloudflare's (1.1.1.1).
Verify NuGet Package Sources: Make sure your nuget.config file (usually located in your project's root directory or the user's home directory on the build server) is correctly configured. Check that the package sources are valid and that you have the necessary authentication credentials if you are using private feeds. A misconfigured nuget.config is a really common cause of these issues.
Check the GitLab CI/CD Runner Configuration: If you're using GitLab CI/CD, your runner configuration could be the problem. Ensure that your runner has the necessary network access and that there are no proxy settings that are interfering with the NuGet restore operation. Also, check the runner's resources: Does it have enough CPU and memory to build your project?
Examine the Build Logs: The build logs are your best friend! They often contain detailed error messages that can point you to the root cause. Look for specific timeout errors, DNS resolution failures, or authentication issues. These logs can often give you very specific clues. If you can, increase the verbosity of your NuGet restore command to get more detailed information.
- dotnet restore -v d
Test Locally: Does the restore work locally? If it does, then the issue is with your CI/CD setup, the runner, or the network configuration. If it doesn't, it could be a project issue or an environment problem. Building your project locally can reveal a lot of problems.

Solutions: Fixing the NuGet Timeout Problem

Once you have diagnosed the issue, here are several solutions to try:

Increase the Timeout: You can increase the timeout value for the dotnet restore command. This gives the command more time to complete. You can do this by using the http-timeout option. You should be careful with this, because it can be masking a bigger problem. It is more a temporary fix, to allow you time to apply a more solid solution. Also, you should try to determine why the initial timeout happens. Check the network and other potential issues.
- Modify your .gitlab-ci.yml file:
```
stages:
  - build

build_job:
  stage: build
  image: mcr.microsoft.com/dotnet/sdk:8.0
  script:
    - dotnet restore --http-client-timeout 60000
    - dotnet build
```
Use a NuGet Cache: NuGet can cache packages on your build server. This speeds up subsequent builds by allowing the restore operation to use local cached packages instead of downloading them from NuGet.org every time. You can set up a local cache to avoid downloading packages repeatedly.
- Configure NuGet Cache: Create or modify the nuget.config file in your project or in your user profile on the build server to specify a local cache directory. You can add a globalPackagesFolder to your nuget.config file:
```
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="globalPackagesFolder" value=".nuget/packages" />
  </config>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
  </packageSources>
</configuration>
```
Optimize Network Settings: Optimize the network settings of your GitLab runner or build server to improve connectivity with the NuGet servers. Verify the network configuration and ensure it is correct. Also, you must guarantee that the DNS resolves correctly.
- Check DNS Resolution: If you suspect DNS resolution problems, try specifying the DNS server in your runner's configuration. You can modify the resolver settings in the runner configuration. Then restart the runner.
Use a NuGet Proxy: If your network has restrictions, using a NuGet proxy can help. A proxy server acts as an intermediary between your build server and the NuGet servers, caching packages and reducing network traffic. Set up a NuGet proxy server within your network. You may want to look into dedicated NuGet servers like