DDEV Proxy Settings for the Host and Web Container

Use host variables and Docker client proxy configuration for their respective consumers; the Docker daemon still owns base-image downloads.

A mounted Wget configuration can fix Wget while leaving Drush or Composer unchanged. Start with the program making the failing request, then supply the proxy at that program's launch boundary.

Host programs

For host programs supporting the usual variables, provide:

export http_proxy=http://proxy.example:8080
export https_proxy=http://proxy.example:8080
export no_proxy=localhost,127.0.0.1,::1,.ddev.site

The HTTPS variable selects HTTPS destinations; its HTTP URL describes the proxy listener. An endpoint from the HTTP proxy list is a candidate when the relevant host or web-container download may use a public route.

Container builds and runtime

DDEV documents the proxies section in the existing ~/.docker/config.json:

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.example:8080",
      "httpsProxy": "http://proxy.example:8080",
      "noProxy": "localhost,127.0.0.1,::1,.ddev.site"
    }
  }
}

Merge this section instead of replacing authentication or other existing entries, then restart the DDEV project. Docker uses these settings to supply environment variables and build arguments. Programs in the web container still need to support them.

Base-image pulls

A missing base image is downloaded by the Docker daemon. The client configuration above does not set that daemon's proxy, and a warm image cache can avoid the pull entirely.

Retain DDEV's local application and service routes in the intended direct scope. Adapt bypass syntax to the actual consumer when adding internal domains or address ranges.

Related articles