vCenter Server appliance: outbound proxy configuration

Configuring the vCenter Server appliance itself to reach the internet through a proxy (depot access, NTP, DNS-over-internet, external registration, and similar outbound calls) – not to be confused with a VCF Operations Cloud Proxy (a separate appliance for inbound data collection, see Field notes). Applies regardless of track – VCF, VVF, or standalone vSphere – since this is a plain vCenter appliance networking setting, independent of any licensing layer.

The method is version-specific and the two are not interchangeable. Using the pre-9.x file on a 9.x appliance (or vice versa) does not just fail cleanly – on 9.x it is explicitly called out as the wrong file to touch. Check the running vCenter’s major version before following either section below.

Not every appliance component historically read the same setting the same way. Per Broadcom’s own proxy-troubleshooting KB 373713 (applies to vCenter Server 7.0 and later), the VAMI (management interface) uses wget internally while VUM / Lifecycle Manager uses curl – two different HTTP clients that can, in principle, resolve proxy settings from different places (wget also reads /etc/wgetrc / ~/.wgetrc on top of the system-wide setting). Not confirmed by Broadcom as the reason, but worth knowing: on 9.x, proxy handling moves to a single config.json file rather than the older per-tool arrangement, which removes this particular class of inconsistency either way.

vCenter 7.0.x / 8.0.x

Two methods, per Broadcom KB 370265:

VAMI GUI (https://<vcenter-fqdn>:5480 → Networking → Proxy Settings → Edit): pick the traffic type (HTTP/HTTPS/FTP), enter the proxy server/port and optional username/password, Save, then restart services:

service-control --stop --all && service-control --start --all

Manual file edit (SSH to the appliance as root, edit /etc/sysconfig/proxy):

1. Back it up first: cp proxy proxy.bak
2. PROXY_ENABLED="yes"
3. HTTP_PROXY="http://proxy.example.com:8080" and HTTPS_PROXY="http://proxy.example.com:8080" (same URL if it’s a single-port proxy for both)
4. NO_PROXY="localhost,127.0.0.1,example.com" – CIDR notation is supported here from 7.0 U1c onward
5. Reboot the appliance (not just a service restart) for the change to take effect

vCenter 9.x

Do not edit /etc/sysconfig/proxy on 9.x – per Broadcom KB 402684, that’s the pre-9.x file and is explicitly the wrong one here.

The VAMI UI’s proxy validation is broken on 9.x – it fails trying to validate the proxy by connecting to vmware.com or the vCenter’s own IP through it, surfacing as “HTTP: Cannot connect to proxy server” even with correct settings. The VAMI UI also flatly rejects CIDR notation in the exclusion list.

The supported path is a direct JSON file edit:

1. SSH to the vCenter appliance as root.
2. Edit /var/lib/vmware-envoy-system-proxy/config.json.
3. One object per protocol – http_proxy, https_proxy, ftp_proxy – each with:

   {
     "scheme": "<proxy url schema>",
     "host": "<proxy url host>",
     "port": <port or null>,
     "username": "<credential or null>",
     "password": "<credential or null>"
   }

   Leave irrelevant protocol entries blank. Remove any comment sections before saving – the file must be valid JSON.
4. Add a no_proxy array with comma-separated exclusion entries as needed – this is also the only place to add CIDR notation, since the VAMI UI rejects it.
5. No service restart is needed after saving.

Worked example – HTTP and HTTPS traffic through the same proxy, FTP left unused, one internal domain and one CIDR block excluded:

{
  "http_proxy": {
    "scheme": "http",
    "host": "proxy.example.com",
    "port": 8080,
    "username": null,
    "password": null
  },
  "https_proxy": {
    "scheme": "http",
    "host": "proxy.example.com",
    "port": 8080,
    "username": null,
    "password": null
  },
  "ftp_proxy": {
    "scheme": null,
    "host": null,
    "port": null,
    "username": null,
    "password": null
  },
  "no_proxy": ["localhost", "127.0.0.1", "example.com", "10.0.0.0/24"]
}

Validate the file is syntactically correct JSON before trusting it took effect – a trailing comma or leftover comment left in from editing is enough to silently break parsing:

python3 -m json.tool /var/lib/vmware-envoy-system-proxy/config.json

Verifying the proxy is actually reachable

Independent of which method configured it, confirm the appliance can reach the internet through the proxy itself before assuming an upgrade-blocking connectivity issue is something else. Per KB 373713, from an SSH session on the appliance:

HTTP_PROXY="http://<proxy-host>:<port>/" curl -I http://example.com
HTTPS_PROXY="https://<proxy-host>:<port>/" curl -I https://example.com
wget --spider http://example.com
https_proxy="http://<proxy-host>:<port>/" wget --spider https://example.com

These test whether the proxy server itself is reachable and forwarding correctly – a clean result here doesn’t by itself confirm vCenter’s own app-level config (config.json on 9.x, /etc/sysconfig/proxy on 7.0.x/8.0.x) is being read correctly, only that the proxy is a working path if the appliance is pointed at it.

Sources

• How to configure proxy settings for vCenter Server – VAMI GUI and /etc/sysconfig/proxy methods, 7.0.x/8.0.x
• “HTTP Cannot connect to proxy server” when configuring a proxy in vCenter VAMI UI – the 9.x config.json method and the VAMI UI’s known validation failure
• Troubleshooting vCenter Server Proxy Configuration – the wget vs. curl distinction and the curl/wget reachability test commands, vCenter Server 7.0 and later