Docker Proxy Configuration: Daemon, Containers and Apps

"Docker proxy configuration" covers three settings that control different processes:

1. Daemon proxy. dockerd uses it to reach registries and other swarm nodes, not to route container traffic.
2. Client-injected variables. ~/.docker/config.json, docker run --env and --build-arg put HTTP_PROXY-style strings into containers and builds; each program decides whether to honor them.
3. Application configuration. The client inside the container is told which proxy and credential to use. The authenticated Databay route belongs here.

The Databay gateway, gw.databay.co:8888, serves HTTP proxying, HTTPS CONNECT tunnelling and SOCKS5, with no UDP. Traffic is billed per GB, so a route that also captures image pulls, package downloads or internal service calls wastes paid traffic. Scope it to the requests that need it, and use it only for destinations you own or are permitted to access, following each destination's terms.

Check each Docker control against this matrix before shipping.

The daemon proxy governs dockerd's own connections to registries and swarm nodes. Docker recommends the proxies object in daemon.json, followed by sudo systemctl restart docker:

{
  "proxies": {
    "http-proxy": "http://egress.corp.example:3128",
    "https-proxy": "http://egress.corp.example:3128",
    "no-proxy": "registry.internal.example,127.0.0.0/8"
  }
}

A systemd drop-in at /etc/systemd/system/docker.service.d/http-proxy.conf also works: set HTTP_PROXY, HTTPS_PROXY and NO_PROXY in Environment= lines under [Service], write each % of a percent-encoded value as %%, run sudo systemctl daemon-reload, restart Docker, and confirm with sudo systemctl show --property=Environment docker. Configuring the daemon directly takes precedence over those variables. Rootless mode uses ~/.config/systemd/user/docker.service.d/ and systemctl --user.

Docker Desktop ignores daemon.json proxy settings; its Resources > Proxies settings split a Docker Desktop proxy for host-level traffic, such as signing in and the CLI, from a Containers proxy for image pulls that covers outbound container traffic only under air-gapped container enforcement. A Databay credential in any of these places would bill registry pulls without routing your application.

In ~/.docker/config.json, the default key applies to every daemon the client uses; a daemon address as the key scopes the settings to that daemon:

{
  "proxies": {
    "default": {
      "httpProxy": "http://egress.corp.example:3128",
      "httpsProxy": "http://egress.corp.example:3128",
      "noProxy": "localhost,127.0.0.1,api,db,.internal.example"
    }
  }
}

Docker maps httpProxy, httpsProxy, noProxy, ftpProxy and allProxy to uppercase and lowercase variables and build arguments for containers and builds only, not the CLI or Engine; saved changes apply without a restart to new containers and builds. docker run --env and docker build --build-arg set the same names per command, with the same exposure. Docker's cautions explain why no credential belongs here:

• Environment variables are stored as plain text in the container's configuration, can be inspected through the remote API, and are committed into an image by docker commit.
• The Dockerfile ENV instruction embeds proxy settings in the image.
• Predefined proxy build arguments stay out of docker history unless a matching ARG instruction preserves them, and Docker calls build arguments inappropriate for secrets.

A global setting also offers the paid route to package managers in every build. For Databay, an HTTPS_PROXY value still starts with http://: the variable name picks which destinations use the proxy, and HTTPS destinations are tunnelled with CONNECT.

Only the application knows which requests need an external exit. Configured there, the route covers just those requests and the image holds nothing about Databay.

1. Pass the gateway address, gw.databay.co:8888, as ordinary configuration.
2. Mount the username and password as secret files, using the *_FILE convention from Docker's Compose secrets guide: a variable holds a path under /run/secrets, not the value.
3. At startup, read each file, strip any trailing newline, and pass the values to the client's own proxy setting, as the Python Requests, Node.js fetch and cURL guides show. Never log the result.

Choose the product and routing in the dashboard, then copy the complete username, such as USER-zone-residential-countryCode-us, instead of assembling flags from memory. Premium Residential targets one of country, state, city, ZIP, coordinate or ASN at a time; Residential Flex, Datacenter and Mobile target country or continent. A sticky session adds a segment such as -sessionId-abc123 and requests continuity for up to 1440 minutes on Premium Residential and Residential Flex where available, or up to 120 minutes on Datacenter and Mobile. The IP can change before the window ends. All pools are shared: a new proxy connection may select an available exit and a reused connection may retain one, so jobs should tolerate either.

One service receives the credential as two secret files, and an on-demand check shares its default network. The example/collector:1.4.2 image is a placeholder for your own application, which must implement the *_FILE reads described above.

services:
  collector:
    image: example/collector:1.4.2
    environment:
      DATABAY_PROXY_ADDR: "gw.databay.co:8888"
      DATABAY_PROXY_USER_FILE: /run/secrets/databay_proxy_user
      DATABAY_PROXY_PASS_FILE: /run/secrets/databay_proxy_pass
    secrets:
      - databay_proxy_user
      - databay_proxy_pass

  exit-check:
    image: curlimages/curl:8.23.0
    user: "0:0"  # one-shot check can read owner-only file secrets
    profiles: ["verify"]
    command: ["--disable", "--proxy", "http://gw.databay.co:8888", "--noproxy", "",
              "--variable", "databay_user@/run/secrets/databay_proxy_user",
              "--variable", "databay_pass@/run/secrets/databay_proxy_pass",
              "--expand-proxy-user", "{{databay_user:url}}:{{databay_pass:url}}",
              "--silent", "--show-error", "--max-time", "20",
              "https://api.ipify.org?format=json"]
    secrets:
      - databay_proxy_user
      - databay_proxy_pass

secrets:
  databay_proxy_user:
    file: ./secrets/databay_proxy_user
  databay_proxy_pass:
    file: ./secrets/databay_proxy_pass

Write the files from your secret manager's variables without trailing newlines, and list secrets/ in .gitignore and .dockerignore:

umask 077
mkdir -p secrets
printf '%s' "$DATABAY_PROXY_USER" > secrets/databay_proxy_user
printf '%s' "$DATABAY_PROXY_PASS" > secrets/databay_proxy_pass

Run docker compose run --rm exit-check; targeting a profiled service runs it, while docker compose up skips it. cURL 8.3 and later can import files into variables and expand them inside an option. The pinned image supports this: the username and password are read inside cURL rather than inserted into a URL, command line or quoted config file, with the url function encoding each part before libcurl decodes the proxy credential. This preserves literal percent signs, quotes and backslashes. --disable skips its default config file and --noproxy "" prevents inherited exclusions from bypassing the gateway.

Compose bind-mounts file-based secrets and ignores uid, gid and mode for them, so host file permissions decide whether the container user can read them. The one-shot cURL service runs as container root to read the private files; give your application only the file access its configured user needs. Compose also interpolates $ in the Compose file ($$ is a literal dollar sign) and in unquoted or double-quoted env_file values; single quotes keep a value literal.

Reserve env_file for applications that read only environment variables: Docker advises against passing passwords that way, and the values land in the container's configuration.

Observe the exit on a harmless endpoint before any real destination, from the workload's network. Docker may inject both uppercase and lowercase proxy variables from the client configuration, so an ordinary docker run is not a direct control by itself. The baseline explicitly disables proxy use, while the Compose check selects the gateway and overrides inherited NO_PROXY exclusions.

# Proxy variable names injected by the client
docker run --rm alpine sh -c 'env | grep -i _proxy | cut -d= -f1'

# Direct baseline: ignore client-injected proxy variables and default cURL config
docker run --rm curlimages/curl:8.23.0 --disable --proxy "" \
  --silent --show-error --max-time 20 "https://api.ipify.org?format=json"

# Proxied check: read mounted secrets with an explicit proxy and no bypass
docker compose run --rm exit-check

A proxied result equal to the baseline means the expected route was not demonstrated; inspect the effective client configuration before continuing. For a second observer, use https://databay.com/what-is-my-ip/json, explained on the What Is My IP page. Then have the application's first request reach that endpoint through its own client, logging only the address, image tag and UTC time. An observed IP is point-in-time evidence, not proof of anonymity; re-check sticky sessions at your job's checkpoints.

Find the first failing layer before changing anything. Proxy-hop failures occur between the container and gw.databay.co:8888; destination-hop failures occur after the gateway accepts the request or tunnel.

SOCKS5 depends on the client library inside the container: the gateway accepts it on the same host and port, but Docker only passes the ALL_PROXY string, so socks5:// or socks5h:// works only if that client implements SOCKS5. The HTTP versus SOCKS5 comparison covers who resolves the destination name.

1. Keep Databay values out of Dockerfile ENV, ARG, LABEL and RUN lines; .dockerignore keeps secret files out of the build context, so COPY cannot reach them.
2. If a build truly needs a credential, use docker build --secret with RUN --mount=type=secret, mounted at /run/secrets/<id> by default. Builds should not need the Databay route.
3. Never run docker commit on a container that received proxy credentials through its environment.
4. Treat docker inspect output, docker compose config output (it shows interpolated values) and debug logs as sensitive; redact Proxy-Authorization and credential-bearing URLs, and never screenshot a visible password.
5. Source secret files from a secret manager. On Swarm, Docker secrets serve only swarm services, are encrypted in transit and at rest, and mount in an in-memory filesystem.
6. After any exposure, rotate the credential in the dashboard, replace the files and recreate the containers.

Compare networks on the proxy product hub once the in-container check matches the requested route.