Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP Proxy settings from preferences are injected as environment variables in containers #981

lukevella opened this issue Nov 23, 2016 · 9 comments


None yet
10 participants
Copy link

commented Nov 23, 2016

Expected behavior

I am behind a corporate proxy so I configured the preferences with an HTTP Proxy so that I can pull images from Docker Hub when building my containers, but don't expect the same settings to be injected into the containers as environment variables.

Actual behavior

The images are pulled successfully through the proxy however, the same HTTP Proxy settings are being injected in to the containers as environment variables. This causes some issues since I am using docker-compose to link two containers and they are attempting to communicate with each other through the proxy (which fails). I tried to exclude the hostnames of the linked containers via the preferences, hoping that they will be injected as $NO_PROXY but this doesn't happen.

Steps to reproduce the behavior

  1. Configure the preferences with an HTTP/S Proxy and Exclude values.
  2. docker run -it ubuntu bash
  3. echo $HTTP_PROXY
  4. echo $NO_PROXY
    output: empty

This comment has been minimized.

Copy link

commented Nov 30, 2016

docker run -e HTTP_PROXY= -it ubuntu bash will do the job, no?


This comment has been minimized.

Copy link

commented Nov 30, 2016

@ebriney That might be a workaround but it doesn't solve the issue.

I'm hoping that setting the HTTP Proxy settings in the app preferences will have the same effect as setting the environment variables for the docker daemon in systemd. See:

When doing the above the HTTP Proxy environment variables do not get injected into containers. It should be the same on macOS. These settings are only for enabling a connection to Docker registries through a proxy.


This comment has been minimized.

Copy link

commented Dec 16, 2016

Strongly agree, this behavior where a proxy I happen to be using for web browsing on my mac automatically and without my choice gets injected into all containers seems a bit nuts.

This feature, although documented (, is too clever, causes more confusion than it's worth. Let users enter the proxy in the Docker Preferences tab, anyway there's no guarantee you'd want to use the same proxy the Mac is otherwise using.

And a really bad bug is that Docker for Mac doesn't "reset" this after "unchecking" "Web Proxy (HTTP)" in Settings => Network => Proxies tab. The old value is still in the Docker Preferences, grayed out. I have to actually delete the ip and port from the Mac settings, even though those fields are being ignored by the Mac.


This comment has been minimized.

Copy link

commented Dec 22, 2016

Thanks for the report. I've escalated this to the Docker for Mac and Windows networking team. We hope to work on our support for HTTP proxies over the next few releases -- I'll let you know how we get on.


This comment has been minimized.

Copy link

commented Jun 5, 2017

@lukevella the latest master builds of Docker for Mac have experimental support for transparent HTTP(S) proxying. If this special mode is enabled then no environment variables are rewritten. If you'd like to try it, I've written some instructions:

(Note the current implementation doesn't currently support no_proxy properly -- hopefully this will be implemented soon)

Feedback is very welcome!


This comment has been minimized.

Copy link

commented Oct 17, 2017

The problem has become extremely urgent, without the no_proxy radio option in Proxies Tab. I hope the option will be introduced again.


This comment has been minimized.

Copy link

commented Mar 28, 2018

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale


This comment has been minimized.


This comment has been minimized.

Copy link

commented Jul 9, 2019

@djs55 I think this issue may be resolved better.

Let me explain the problem I encounter first:

  1. I am using docker behind a corporate proxy
  2. I use docker to maintain and iterate my development environment.
  3. To pull images from dockerhub, of course, I need to set docker daemon proxy, as this:
  4. I need to access Internet in the development environment, so I also set the proxy inside container, as this:
  5. And I need to connect to company local git through https/ssh, which shouldn't be accessed with proxy setting. As you can see in the pictures above, I set "" to no_proxy both in docker daemon proxy setting and in container env.
  6. Now I encounter the problem:
    a. I can not access "" now, because vpn passthrough strategy pass all my container's flow into docker daemon proxy, even when no_proxy is set.
    b. If I want to access "", I have to unset docker daemon proxy to "system proxy", in order to use container proxy completely;
    c. If I need to download images from dockerhub, I have to set docker daemon proxy to "manual proxy".
    d. And switching this setting require restarting docker daemon, so I have to close all my container when I am developing. This make my life much harder.

I think the key problem is that the proxy to pull images and the proxy for container(vpn passthrough) shouldn't be mixed. They are completely for different purpose. Providing two separate setting might be a better solution.
Or did I misunderstand some of these setting?

@djs55 djs55 self-assigned this Jul 9, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.