# Docker CLI not always using web proxy properly

**URL:** <https://forums.docker.com/t/docker-cli-not-always-using-web-proxy-properly/149814>\
**Category:** General\
**Created:** [September 18, 2025, 9:06am UTC](https://forums.docker.com/t/docker-cli-not-always-using-web-proxy-properly/149814 "2025-09-18T09:06:39Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![mosesontheweb](https://sea3.discourse-cdn.com/docker/user_avatar/forums.docker.com/mosesontheweb/32/61542_2.png) [@mosesontheweb](https://forums.docker.com/u/mosesontheweb)\
**Post date:** [September 18, 2025, 9:06am UTC](https://forums.docker.com/t/docker-cli-not-always-using-web-proxy-properly/149814/1 "2025-09-18T09:06:39Z")

</div>

Hi there,

I’m currently switching an application from purely install to docker container and found a really strange behavior, maybe someone of you might have an idea, what the reason could be.

Our environment is sitting behind a firewall, so every connection from inside must use a web proxy to get something from outside. So, on Linux we usually do an explicit `export https_proxy=...` to be able to do so.

I tried this for testing purposes with some small defaults, like `hello-world` or `alpine`, so a normal pull from the usual Docker-hubs work correctly with the proxy set via environment variable. But not so for `europe-docker.pkg.dev`.

Whatever I tried to do, I always ran into a timeout, regardless if the environment variable for the proxy was set via export or even `~/.docker/config.json`. A colleague from our network department traced down the firewall and found out that my machine requested two IPs from outside directly, without going over the proxy. He added a rule to accept the connection for those two IP addresses (both from Google data centers) and voilá, it finally started to work, I was able to pull my image from `europe-docker.pkg.dev`.

What I’m now asking myself is, why does the Docker CLI do that for this one particular adress? Why isn’t it going over the proxy and tries to contact the IPs directly? Any ideas?

Our docker version is 27.5.1, build 9f9e405 (bound to our RHEL distribution).

Regards, Thomas

---

<div class="post-metadata">

**Author:** ![rimelek](https://sea3.discourse-cdn.com/docker/user_avatar/forums.docker.com/rimelek/32/41602_2.png) [@rimelek](https://forums.docker.com/u/rimelek)\
**Post date:** [September 20, 2025, 9:47am UTC](https://forums.docker.com/t/docker-cli-not-always-using-web-proxy-properly/149814/2 "2025-09-20T09:47:55Z")

</div>

Are we sure that the proxy didn’t work for the request and not just the answer never arrived so Docker tried it without proxies? I don’t know if it does it?.I would try running a local proxy and checking the logs if the request arrives to that. You wouldn’t even need to make it actually forward request correctly at this point, just see if the request appears in the logs. I do this also when I want to know what IP addresses I should ask to enable from network admins, since there could be some redirections I wouldn’t know otherwise.

I don’t know why the proxy variables would work differently for Docker Hub and other registries. I only know that not everything uses the same variables. Some could support `HTTPS_PROXY` and some could use `https_proxy`. If there is any component used for other registries, setting both the uppercase and lowercase versions could help.

Maybe there were also some requests to an HTTP endpoints which would have redirected you to HTTPS. If it is the case, you need to make sure you are using `http_proxy` and `HTTP_PROXY` variables as well, not just HTTPS.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/docker/original/3X/d/4/d4fbccd46c81bfcffe9822e20e17736d946fa821.png) [@system](https://forums.docker.com/u/system)\
**Post date:** [October 20, 2025, 9:48am UTC](https://forums.docker.com/t/docker-cli-not-always-using-web-proxy-properly/149814/3 "2025-10-20T09:48:38Z")

</div>

Closed on October 20, 2025, 9:48am UTC

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
