Methods-to-configure-proxies-in-Docker
  • December 29, 2025
  • Jennifer R.
  • Tools

Containers revolutionised software development as they resolved many challenges programmers faced. They help deliver products that work reliably and consistently across various systems and devices. Docker, in its turn, took containers themselves to a new level, as the platform made building, managing, and running them much easier and faster. Docker also supports the use of third-party proxies and provides several methods for doing so. Why pair it with alternative IPs, which way is better for your particular case, and what exactly to do step by step – keep reading the article to know.

Why use proxies with Docker

Ensuring stable, secure, and controlled internet access is the answer. Sometimes, to ensure access at all.

Docker needs access to the Web to perform tasks such as image pulling, package installing, etc. However, a lot of corporate networks don’t offer a normal connection – outbound traffic is controlled or restricted. Safety reasons are to blame; however, it still hinders developers’ work. Approved proxies sometimes are the only way to reach the Net and avoid seeing messages like “Connection timed out” or “Unable to access www.example.com“.

Also, in some cases, authentication is necessary to use the net. Docker itself doesn’t support authentication, so an external proxy is the way to go.

Runtime applications may also call for an external connection. There are situations when a container needs to connect to cloud APIs, databases, third-party services, etc. If it is protected by a firewall, a proxy is necessary to reach target endpoints.

There are also other reasons to use proxies. Routing traffic via an alternative server may resolve speed issues and help with traffic monitoring for logging, malware, SSL inspection, and more. They also help maintain network consistency across different types of servers and machines, as well as mask internal information – IP address, internal DNS requests, and NAT, providing better security.

How to configure proxies in Docker

There are four different layers you can configure proxies at – The Docker Daemon (or Docker Engine in other words), Docker Client, containers, and OS-level. There are also different methods to set proxies on each layer. Depending on what you choose, it will affect different parts. All options have their advantages, and you should choose according to your use case. Let’s discuss them one by one – which one suits the best for what purposes and what exactly to do.

Layer 1:  Configure the Docker Daemon

Proxies, configured on that level, control pulling and pushing images, accessing Docker Hub and private registries. They are also responsible for reaching Docker Swarm.

When to choose this option:

  • You need all image operations to run through a proxy;
  • Commands like docker pull or docker push fail;
  • You must route all traffic from your machine via a corporate proxy;
  • External network access is possible only with proxies;
  • With Docker Swarm.

It’s stable and predictable, and, if you use Desktop, it’s easy to configure proxies with its graphical interface. On the other hand, on older versions (< 17.x) and some rare setups, configurations may affect all containers, which may slow down containers that don’t use the internet. In modern versions, Daemon proxy doesn’t affect containers as settings aren’t inherited automatically.

There are four ways to configure the Docker Daemon proxy.

Way 1 – Use daemon.json

This method is Linux only, and it’s recommended for this OS. You configure proxy behaviour in this daemon.json file:


{
 "proxies": {
   "http-proxy": "http://proxy.example.com:3128",
   "https-proxy": "https://proxy.example.com:3129",
   "no-proxy": "*.test.example.com,.example.org,127.0.0.0/8"
 }
}

      
        
        
        
        
        
        

      

After changing the file, restart Docker for the changes to start working:


sudo systemctl restart docker

      
        
      
Way 2 – Via systemd drop-in file

This also works for Linux only. You can run this in regular and rootless modes.

Anyway, start by creating a system directory:


sudo mkdir -p /etc/systemd/system/docker.service.d

      
        
      

Then, create a file with a name /etc/systemd/system/docker.service.d/http-proxy.conf that adds proxy environment variables.


[Service]
Environment="HTTP_PROXY=http://proxy.example.com:3128"

      
        
        
      

If you use an HTTPS server, change your variable to “HTTPS_PROXY”. You can set multiple variables. Then save it and restart Docker.


sudo systemctl daemon-reload
sudo systemctl restart docker

      
        
        
        
Way 3 – Use environment variables for dockerd

Docker Daemon checks environment variables before running. However, this method usually isn’t the first choice.


export HTTP_PROXY=...
dockerd

      
        
        
      
Way 4 – Docker Desktop

Technically, Docker Desktop relies on a lightweight Linux Virtual Machine and uses it to configure Docker. You may read that Docker Desktop is available for Windows/macOS only. Technically, it’s available for Linux as well; however, it’s rare and optional, and you still manage Daemon inside a VM, not a native engine. So, this method is still preferable for Windows/macOS. Follow this path:

Docker Desktop > Settings > Resources > Proxies.

Layer 2: Configure Docker Client (CLI) proxies

Docker Client uses proxies to make requests. It applies to API calls made by the CLI and commands such as docker login, docker pull, docker push.

When to choose this option:

  • If you need the client to authenticate through a proxy;
  • When there are company restrictions on outbound traffic;
  • When you don’t need to affect the daemon or containers.

The Client is quick and easy to configure, and there is no need to restart the daemon. However, this method won’t work if you need to fix container build or run access issues, or Daemon push and pull errors.

Usually, you would configure Docker Client using shell environment variables.

It looks like this for Linux and macOS:


export HTTP_PROXY=http://PROXY:PORT

      
        
      

or


export HTTPS_PROXY=http://PROXY:PORT

      
        
      

Use this for Windows:


setx HTTP_PROXY http://PROXY:PORT

      
        
      

Note: on Windows, when you use CMD, there may be issues. PowerShell works.

There is another way, though it’s a rarely used one – configure per-command.


HTTP_PROXY=http://PROXY docker login

      
        
      

Layer 3: Container proxy

If you go with this method, applications inside containers will use proxies. You can configure proxies for builds or run containers with proxies.

When to choose this option:

  • Containers need an external connection;
  • Builds fail to run package managers;
  • Apps inside containers need to route API requests via an external proxy.

It’s easy to set per container and suits mixed environments, when some containers need proxies, and others don’t. They also offer a clean separation from OS and daemon configurations. However, you will have to configure proxies manually for each build and run. This option is also not the best for large-scale deployments, and it’s associated with security risks as proxy credentials may leak.

Way 1 – Configure proxies per build

docker build \
 --build-arg HTTP_PROXY=http://PROXY:PORT \
 --build-arg HTTPS_PROXY=http://PROXY:PORT \
 -t myimage .

      
        
        
        
        
      
Way 2 – Use Dockerfile

ENV Dockerfile or environment variables embed your settings into the image. This method comes with security risks, and you shouldn’t use it for builds.


ENV HTTP_PROXY=http://PROXY:PORT

      
        
      

ENV HTTPS_PROXY=http://PROXY:PORT

      
        
      
Way 3 – Configure proxies per run

docker run \
 -e HTTP_PROXY=http://PROXY:PORT \
 -e HTTPS_PROXY=http://PROXY:PORT \
 image

      
        
        
        
        
      
Way 4 – Opt for Docker Compose

This is a safe, recommended option:


environment:
 HTTP_PROXY: http://PROXY:PORT
 HTTPS_PROXY: http://PROXY:PORT
 NO_PROXY: "localhost,127.0.0.1"

      
        
        
        
        
      

Note: In official Docker documentation, two different concepts are named CLI, and it may confuse you. There is a Docker CLI proxy that affects the client program. There are also Docker CLI flags – they inject proxy settings inside containers. They affect containers, not the client. However, in both cases, you use command-line tools.

Layer 4: Operating system proxy

You can set it so that all traffic from your device goes via a proxy server. It will affect both Docker Daemon and Docker Client; sometimes it may affect even containers and all other apps you use.

When to use this option:

  • The company requires system-level use of proxies;
  • There are a lot of apps besides Docker that need proxies too.

This method is simple and quick – you configure proxies once, and those settings work for the majority of parts and apps. However, it’s not Docker-specific, and it makes debugging harder. Also, pay attention that it’s really rare for containers to inherit those settings automatically, so you may still need to configure them separately.

Here, you can find step-by-step tutorials on configuring proxies for various OSes, including macOS and Windows.

Also, you can visit the official documentation provided by Docker to find more details about each method and all available variables.

Docker Daemon proxy configuration

How to configure the Docker Client

How to adjust Docker Desktop proxy changes

Does Docker have internal proxies?

Docker offers a so-called internal HTTP(S) proxy for image builds only, and this confuses people, as some think that external proxies aren’t necessary.

BuildKit internal proxy is used only for builds, and it speeds up access, erases DNS issues, and prevents DNS settings from leaking into builds. However, it can’t help with establishing secure outbound connections. You can’t use it instead of a proxy.

Common configuration problems and how to troubleshoot them

Fixing proxy-related errors in Docker may be tricky because of its multiple layers. There are five of the most common problems and their fixes.

Error 1: Docker pull/docker push fails

If you notice that proxy pull hangs or times out, or the connection is refused, it means Docker Daemon doesn’t know about your proxy. To fix it, configure proxies on the engine level.

Error 2: There is no connection, even if Daemon works

At the same time, dicker pull works, but containers can’t run pip install and other dependencies. Errors like Temporary failure resolving may occur. Such a situation happens with modern Docker versions because the Daemon proxy doesn’t apply automatically inside containers. To get rid of it, apply a container-level proxy in Dockerfile or Docker Compose.

Error 3: The NO_PROXY variable doesn’t work

If you still see that Docker tries to route traffic via proxies despite your settings, containers fail to communicate, or registry mirrors fail, it may be due to incorrect syntax. Try using comma-separated entries and don’t specify protocols while including domains.

NO_PROXY=localhost,127.0.0.1,.corp.example.com,registry.internal

Error 4: Proxy credentials contain unsupported symbols

In this case, Docker may fail to start or route traffic via proxies. To resolve this one, you need to URL-encode symbols like  @, #, %, :

It will look like this:

Environment=”HTTP_PROXY=http://user:Pa%%23ss@proxy:8080″

Error 5: Docker ignores desktop proxy settings

When you set proxies using Desktop, yet builds fail, and containers cannot establish a connection, it may be a sign to use another configuration option. Desktop affects Daemon, but not containers directly. Try setting container-level proxies.

To sum up

Docker and proxies are a powerful combination that grants speed, security, and effective deployment. To get the most out of it, you need to choose a suitable configuration and, of course, opt for legally-derived high-quality proxies. DataImpulse has your back with it – there are 90+million ethically-sourced proxies at your service, as well as 24/7 human support to help you with development tasks. Feel free to write to us at [email protected] or hit the “Try Now” button to start with us. Click “Try now” or contact us at [email protected] to start.

Jennifer R.

Content Editor

Content Manager at DataImpulse. Jennifer's degree in philology and translation and several years of experience in content writing help her create easy-to-understand copies, even on tangled tech topics. While writing every text, her goal is to provide an in-depth look at the given topic and give answers to all possible questions. Subscribe to our newsletter and always be updated on the best technologies for your business.