[fivetran-paulharper]

Summary

Makes install.ps1 and proxy-agent-manager.ps1 upgrade work from behind a network proxy by honoring the same environment variables curl already reads on Linux: HTTPS_PROXY (falling back to HTTP_PROXY) and NO_PROXY.

Windows PowerShell 5.1, which is what ships on Windows Server, ignores these variables. Until now a proxied host could only reach GitHub, the image registry and the Fivetran API if the user first set [System.Net.WebRequest]::DefaultWebProxy by hand in the same session, which is what the docs in fivetran/engineering#286828 currently tell them to do. That instruction also doesn't carry into the dashboard's one-line install command, which runs the installer in a child powershell process.

What changed

• Set-WebProxyFromEnvironment in both scripts. Builds a System.Net.WebProxy from HTTPS_PROXY or HTTP_PROXY and sets it as the process default, so every Invoke-WebRequest / Invoke-RestMethod in the script goes through it. Credentials in the URL (http://user:pass@host:port) are passed as NetworkCredential and kept out of the printed address.
• NO_PROXY entries become bypass rules with curl's semantics: each entry matches the host and its subdomains, with or without a leading dot. CIDR ranges are not supported.
• Internet Options still works. With no proxy variables set, .NET's default proxy (the user's Internet Options, including PAC scripts) is kept, and the script prints the system proxy in effect for the registry host so a stalled install shows what it is going through. Env vars take precedence when set, matching curl.
• Windows credentials for the proxy. Corporate proxies commonly require NTLM or Kerberos, which .NET only answers when told to (the classic (407) Proxy Authentication Required from Invoke-WebRequest). Both the env-var proxy, when its URL carries no credentials, and the Internet Options default now use the current Windows identity.
• The installer applies it at entry; the manager only for upgrade, the one command that makes a web request. start, stop, restart, status and logs are unaffected.
• README: new "Installing behind a network proxy" section.

The function is duplicated rather than shared because the two scripts are downloaded independently. A Pester test asserts the two copies are identical (modulo Write-Log) so they can't drift.

What this does not do

• The dashboard install command's own download. The one-liner fetches install.ps1 with irm before any of our code runs, so this change can't help that request. A companion change in fivetran/engineering sets the proxy in that child process before the fetch (branch paulh/proxy-agent-windows-install-command-proxy, PR to follow). Downloading the script first, as the README shows, already works.
• Docker's proxy settings. The Docker daemon needs its own proxy configuration to pull the image, and the agent needs proxy_host / proxy_port in config.json to reach Fivetran at runtime. Both remain the user's responsibility; setting daemon-wide proxy settings and restarting the Docker service from an installer seemed too invasive for a shared host.

Testing

• tests/pwsh/Manager.Tests.ps1: six new cases under "behind a network proxy" covering HTTPS_PROXY with credentials and NO_PROXY bypass matching, the HTTP_PROXY fallback with Windows credentials, a stand-in Internet Options proxy being kept, reported and given Windows credentials, a direct connection reporting nothing, an invalid proxy URL (fails before contacting the registry), and the install/manager function parity check.
• Locally: 23/23 Pester tests and 0 PSScriptAnalyzer findings under pwsh 7 in a Linux container. Windows PowerShell 5.1 coverage comes from this PR's CI run on the windows-2022 and windows-2025 runners.
• The Windows integration test does not exercise a proxy; that would need a stub proxy server on the runner.

Stacking

Stacked on #13 so the new tests run in its CI. Independent of #12.

🤖 Generated with Claude Code