Share feedback
Answers are generated based on the documentation.

Configure an upstream proxy

もくじ

This page describes proxy settings for local sandboxes and the local daemon. For cloud sandbox egress controls, see Cloud network policy.

重要

Upstream proxy support is experimental. Everything described on this page — proxy URLs, PAC files, SOCKS5, use of the OS system proxy, proxy authentication, and the settings that configure them — is subject to change. Share feedback and bug reports in the docker/sbx-releases repository.

An upstream proxy is the corporate or network proxy that Docker Sandboxes forwards outbound traffic through on its way to the internet. This is separate from the network policy, which decides which destinations are allowed. The upstream proxy decides how allowed traffic reaches them.

Docker Sandboxes sends two kinds of outbound traffic, and you can proxy them independently:

  • Sandbox traffic — network access from inside your sandboxes.
  • Daemon traffic — the sbx daemon's own access, including image pulls, telemetry, and feature flags. CLI requests for sbx login and sbx diagnose --upload also use this scope.

Default behavior

By default, both kinds of traffic use your operating system's proxy settings, including any PAC URL configured there. You don't need to configure anything. On macOS and Windows, sbx tracks the OS proxy setting while it runs, so a change to your network, VPN, or PAC configuration is picked up without a restart. If your OS has no proxy configured, traffic goes direct.

Set a proxy manually

Use sbx settings set to override the default for one or both kinds of traffic:

$ sbx settings set proxy http://proxy.corp:3128          # both kinds of traffic
$ sbx settings set proxy.sandbox socks5://proxy.corp:1080 # sandbox traffic only
$ sbx settings set proxy.daemon direct                    # daemon traffic only

A proxy value can be any of the following:

ValueMeaning
(unset)Fall back to the wider scope, then environment variables, then the OS system proxy (the default)
http://host:port or https://host:portAn HTTP or HTTPS proxy
socks5://host:port or socks5h://host:portA SOCKS5 proxy
pac+http://host/proxy.pac, pac+https://host/proxy.pac, or file:///path/proxy.pacA PAC (proxy auto-config) file
systemForce the use of the OS system proxy
directForce a direct connection with no proxy

With socks5://, DNS is resolved locally before the connection is handed to the proxy. With socks5h://, DNS resolution is delegated to the proxy.

Exclude destinations from the proxy

Exclusion lists mirror the same scopes. Each takes a comma-separated list of hosts, domain suffixes, IP addresses, or CIDR ranges, or * to bypass the proxy entirely:

$ sbx settings set no_proxy "*.internal.corp,10.0.0.0/8"    # both kinds of traffic
$ sbx settings set no_proxy.sandbox "*.svc.cluster.local"   # sandbox traffic only
$ sbx settings set no_proxy.daemon "registry.internal"      # daemon traffic only

Environment variables

Because sbx runs from your shell, it also honors the standard and legacy proxy environment variables, so existing setups keep working without migration:

  • HTTP_PROXY, HTTPS_PROXY, and NO_PROXY (and their lowercase forms) — the standard variables. They apply to both kinds of traffic when no proxy or no_proxy setting is configured.
  • DOCKER_SANDBOXES_PROXY and DOCKER_SANDBOXES_NO_PROXY — the environment form of proxy.sandbox and no_proxy.sandbox. They apply to sandbox traffic only and never affect daemon traffic.

For how to apply environment variable changes to the CLI and daemon, see Settings environment variables.

Precedence

For each kind of traffic, the first match wins:

  1. The scope-specific value:
    • proxy.sandbox or DOCKER_SANDBOXES_PROXY for sandbox traffic
    • proxy.daemon for daemon traffic
  2. The proxy setting
  3. HTTP_PROXY or HTTPS_PROXY from the shell
  4. The OS system proxy (the default)
  5. Direct

The matching exclusion list (no_proxy.<scope>, then no_proxy) applies to the chosen proxy, and the standard NO_PROXY variable still applies on the environment path.

For example, if proxy specifies a shared proxy and proxy.sandbox is set to direct, sandbox traffic connects directly while daemon traffic uses the shared proxy. If no proxy setting is configured, HTTP_PROXY takes precedence over the OS system proxy.

When changes take effect

Proxy settings take effect at different times depending on the consumer:

  • Sandbox scope (proxy.sandbox, no_proxy.sandbox, and the sandbox side of proxy and no_proxy) is resolved when a sandbox network proxy is created. Sandboxes you create after a change use the updated settings. Existing sandboxes retain their selected upstream proxy until sbx daemon restart rebuilds their network proxies. Restarting a sandbox alone is insufficient.
  • Daemon scope (proxy.daemon, no_proxy.daemon, and the daemon side of proxy and no_proxy) is resolved once when the daemon starts. Changes to the daemon's own traffic require sbx daemon restart.
  • Supported CLI clients read daemon-scoped settings on each invocation, including sbx login and sbx diagnose --upload. Changes apply on the next invocation without a daemon restart.

The DOCKER_SANDBOXES_* environment variables are a separate case. They control sandbox traffic only, as described in Environment variables, but sbx reads them from the daemon's environment as the daemon starts, so changing one also requires a daemon restart. If one of these variables overrides a stored setting, unset the variable and restart the daemon for the stored setting to take effect.

When a system or PAC proxy is in use, sbx still tracks OS-level proxy changes (such as switching networks, connecting a VPN, or updated PAC contents) live.

Authentication

If the upstream proxy requires you to authenticate to it, sbx supports two mechanisms.

Credentials in the proxy URL

Put the credentials in the proxy URL: http://user:pass@host:port for an HTTP or HTTPS proxy, or socks5://user:pass@host:port for SOCKS5. This works on all platforms and covers proxies that challenge with Basic authentication.

Integrated Windows authentication

Proxies that answer CONNECT with a 407 challenge and accept only integrated schemes — NTLM or Kerberos/Negotiate — can instead authenticate you with your Windows sign-in identity. This is opt-in and off by default:

$ sbx settings set proxy.integratedAuth true

The setting isn't scoped: it applies to both sandbox and daemon traffic. If the proxy offers several schemes, the strongest one is used, preferring Negotiate over NTLM. Changes follow the same schedule as other proxy settings: on the next invocation for supported CLI clients, when you create a sandbox, and after sbx daemon restart for daemon traffic and existing sandbox proxies.

Your identity stays on the host. Authentication to the upstream proxy happens on the host side of the sandbox boundary, after network policy has already been applied, so no credential enters the sandbox and nothing about which destinations a sandbox may reach changes.

This depends on Windows SSPI, so it has no effect on macOS or Linux. On those platforms, credentials in the proxy URL remain the only option.