Agents Behind a Forward Proxy

October 8, 2026 · InfraScout Team

Servers that reach the internet only through a corporate forward proxy can now run the InfraScout agent. Until now, the agent service did not reliably pick up proxy settings, so those hosts stayed cut off. From agent 0.40.0 and the matching portal release, you give the agent a proxy, and every connection it makes goes through it: the persistent agent connection on TCP 8443 to server.infrascout.cloud, enrollment, certificate renewal, self-updates, and the connections of any MCP servers the agent hosts.

What You Can Configure

The proxy is an http://host:port or https://host:port address. On Windows you can set it to system instead, and the agent reads the WinHTTP machine proxy (the one netsh winhttp show proxy shows) when the service starts. It is opt-in. Setting it to direct makes the agent ignore every proxy, including environment variables. Next to the proxy sits a no-proxy list of comma-separated hosts, domain suffixes and CIDR ranges, such as .corp.local,10.0.0.0/8.

The agent's own proxy setting wins. Without one, the agent falls back to HTTPS_PROXY and NO_PROXY in the service's environment, and without those it connects directly.

Proxy authentication is Basic only. NTLM and Kerberos, the Windows-integrated methods, are not supported. If your proxy requires them, ask your network team for an exception or for Basic authentication on the agent's account.

Set It When You Install

The agent download dialog and the screen that shows a newly minted enrollment key now have optional Proxy URL and No proxy fields. Whatever you enter flows into the generated install, enroll and rollout-script commands. A proxy password never goes into those commands. You supply it on the host.

The rollout scripts take the same settings. The PowerShell script uses -Proxy, -NoProxy and -ProxyCredential (Get-Credential). The shell script uses --proxy, --no-proxy and --proxy-username, and reads the password only from the INFRASCOUT_PROXY_PASSWORD environment variable. The Ansible playbook takes infrascout_proxy, infrascout_no_proxy, infrascout_proxy_username, and infrascout_proxy_password from ansible-vault. For a single host, enroll and enroll auto accept --proxy, --no-proxy and --proxy-username. The standalone rollout-scripts dialog without an enrollment key doesn't carry the proxy yet, and neither does the plain binary download line in the download dialog.

Change It on an Installed Agent

An agent that is already enrolled gets a proxy command. Run it elevated, with sudo on Linux and macOS or from an elevated prompt on Windows:

sudo agent proxy set --url http://proxy.example.com:8080 --no-proxy .corp.local,10.0.0.0/8 --username svc-infrascout
sudo agent proxy set-password
sudo agent proxy status

set-password prompts for the password, or reads it from INFRASCOUT_PROXY_PASSWORD, and protects it before writing it to the agent's configuration. agent proxy clear removes the setting. Each setter restarts the agent service so the change takes effect, and --no-restart stages it for the next restart instead.

status shows where the proxy setting comes from, the proxy address (never credentials), the username, whether a password is stored, and whether an authentication pause is active. It then probes two paths through the proxy: the agent connection on 8443 and the release host. The 8443 probe also detects a TLS-inspecting proxy, because the certificate chain it gets back is not InfraScout's. A failed probe prints what to fix, for example: "The proxy refuses tunnels to server.infrascout.cloud:8443. Allow CONNECT to that port."

You can also check from the portal. An agent's details on the Agents page show its Network route: Direct, or Via proxy with the proxy's address and whether the setting came from the agent's configuration, the Windows system proxy or the service's environment. That makes it easy to confirm across a rollout which hosts actually picked up the proxy.

What Your Proxy Needs to Allow

The proxy must allow CONNECT to port 8443 for server.infrascout.cloud, not just to 443. TLS inspection is not supported, so exempt the InfraScout hosts from it, as described in TLS Inspection Breaks the Agent Connection. Deploying the proxy's inspection certificate to your hosts does not work around this: the agent accepts only InfraScout's own certificate authority for its connection to InfraScout.

The proxy is for the agent's own connections. Commands and scripts the agent runs during an assessment do not inherit it, so a script that needs the internet has to be given the proxy itself. If the agent hosts MCP servers on your internal network, add them to the no-proxy list, because those connections use the proxy too.

When the proxy rejects the agent's credentials, the agent pauses proxy use for 60 to 72 minutes instead of retrying, so it doesn't lock the account. Restarting the service lifts the pause, and set-password restarts it for you.

Shared proxy accounts and password rotation

If many agents share one proxy account and its password rotates, every agent keeps presenting the old password until you update it, and an account lockout policy can then lock the account for all of them. Exempt the account from lockout, or use one account per group of hosts.

The update banner on the agent card now recognizes proxy failures as well. Its Last attempt failed line tells you when the proxy rejected the credentials, requires Windows authentication, refuses the tunnel to a port, inspects TLS, or can't be reached, along with what to do about it. Agent Updates explains the banner.

Agents older than 0.40.0

An older agent on a proxy-only host can use an interim route through service environment variables, for unauthenticated proxies only. Network Requirements describes it.

Find Out More

Forward Proxies covers what the proxy must allow, the command reference documents every proxy subcommand, and Fleet Rollout shows the proxy parameters in each rollout script.

Questions or feedback? Reach us at info@infrascout.cloud.