Skip to content
Latchkey

curl "Failed to connect to ... port 443" (egress blocked) in CI

The name resolved but the connection to port 443 did not complete. On a locked-down runner network this usually means direct egress on 443 is blocked and traffic must go through the corporate proxy, or the host is not permitted at all.

What this error means

curl fails with "Failed to connect to <host> port 443: Connection refused" or "...: Connection timed out" (exit 7), while the same call works from a developer machine.

Terminal
curl: (7) Failed to connect to github.com port 443:
Connection refused

Common causes

Direct egress on 443 is blocked

The runner network forbids direct outbound HTTPS; only proxied traffic or an allowlist is permitted, so a direct connect fails.

The destination is not on the allowlist

Even where egress is allowed, a host not in the permitted set is refused or dropped at the network boundary.

How to fix it

Route HTTPS through the proxy

  1. Set the proxy env vars so clients tunnel 443 through the sanctioned proxy.
  2. Include internal hosts in NO_PROXY so they are not proxied.
  3. Re-run and confirm the connection completes.
.github/workflows/ci.yml
env:
  HTTPS_PROXY: http://proxy.corp.example:8080
  NO_PROXY: localhost,127.0.0.1,.internal.example.com

Allowlist the destination for direct egress

If direct egress is the intended path, add the host to the firewall or security-group allowlist for port 443.

Terminal
curl -sS --connect-timeout 5 https://github.com -o /dev/null -w '%{http_code}\n'

How to prevent it

  • Document required HTTPS endpoints and keep the egress allowlist current.
  • Configure proxy env vars centrally when direct 443 egress is disallowed.
  • Fail fast with a short connect timeout so blocked egress is obvious.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →