Fix CONNECT tunnel failed: 403, 502 and 503

Short answers

Start by recording the CONNECT status separately from the destination status. Then check the proxy address, authentication, requested destination and any documented gateway error code. If no CONNECT status comes back at all, because the port refused the connection, the attempt timed out or the gateway name did not resolve, use connection refused and timeouts instead. For a different message, find its diagnostic in the proxy error guide.

Record the tunnel status without exposing the password

Copy your full username from the connection builder and replace YOUR_FULL_PROXY_USERNAME. Run this in an interactive POSIX terminal. curl asks for the proxy password; do not append it to the command or publish it in a support log.

curl_status=0
curl --disable --silent --show-error \
  --proxy 'http://gw.portproof.org:7000' \
  --proxy-user 'YOUR_FULL_PROXY_USERNAME' \
  --noproxy '' \
  --connect-timeout 5 --max-time 15 \
  --output /dev/null \
  --write-out 'connect_status=%{http_connect} target_status=%{response_code}\n' \
  'https://example.com/' || curl_status=$?
printf 'curl_exit=%s\n' "$curl_status"

This is one GET request with no automatic retry or redirect following. Use a small HTTPS endpoint you are allowed to test. --disable comes first so curl does not load a default configuration file. The explicit proxy and empty exclusion list make this one check independent of proxy environment settings. Keep your normal deployment settings in place. curl command options.

The password prompt is for an interactive diagnostic. For unattended checks, use your existing secret mechanism and the complete client examples in setup documentation. Do not enable shell tracing around secrets. On Windows PowerShell, use curl.exe and adapt the shell syntax.

The diagnostic produces three separate results:

These fields describe different stages; read them together. curl error codes, CONNECT response code, transfer write-out.

Examples below are illustrative diagnostic outcomes:

connect_status=502 target_status=000
curl_exit=56

The tunnel failed. There is no destination HTTP status to interpret.

connect_status=200 target_status=403
curl_exit=0

The tunnel opened and the HTTPS endpoint refused the request. That is a different problem from a 403 returned to CONNECT. This command does not use curl’s HTTP-failure option, so a completed transfer with a 403 response can still return exit code 0.

What CONNECT does

For an HTTPS destination through an HTTP proxy, the client first asks the proxy to connect to a destination host and port, such as example.com:443. A successful 2xx CONNECT response starts the tunnel; commonly it is 200. The client then performs TLS through that tunnel before sending the HTTPS request. HTTP CONNECT semantics.

A failed CONNECT response does not establish that the destination is down. The proxy might refuse the port, reject credentials or fail to reach an upstream connection. It also does not prove no upstream connection was attempted. Treat the failure stage as evidence and investigate its cause separately.

A plain HTTP request may use the proxy without CONNECT. That means success against an http:// URL does not establish that HTTPS tunnelling works. HTTP proxy behaviour.

Read 403, 407, 502 and 503 in context

The status meanings are documented in the references for 403, 407, 502 and 503.

curl: (56) is a broader receive error, not a synonym for “proxy broken.” The text after the code and the recorded CONNECT status provide the useful detail. Received HTTP code 502 from proxy after CONNECT is the wording curl used for the same failure before 7.87.0. From curl 8.20.0 a CONNECT answered with a non-2xx status exits with code 7 instead of 56, so match the text and the CONNECT status rather than the number. curl’s error reference, curl 8.20.0 changes.

If the tunnel opens but TLS fails afterwards, investigate the certificate or handshake error. Keep certificate verification enabled: turning it off does not repair a refused CONNECT request.

When the gateway reports unavailable country stock

For Portproof, use live locations and the account’s connection builder to check the requested pool and country. A location shown online in a snapshot may change before your connection is attempted.

If the gateway or a support diagnostic provides E_NO_STOCK_COUNTRY, check that code against the current gateway error documentation. Do not infer it from HTTP 502 alone, and do not assume curl will display a structured error body from a rejected CONNECT request.

For a job that requires one market, record an unavailable result and stop or retry later within a fixed limit. If another pool is suitable, select it explicitly while keeping the requested country. Silently changing the country would change the meaning of the measurement.

The dashboard’s connection test is an additional check from the service’s side. It does not reproduce your application’s local environment, and an observed IP address is not, by itself, independent confirmation of its country.

For a VoidMob connection, its mobile proxy troubleshooting article covers that service’s connection checks. Use the endpoint and credentials issued by your operator; the Portproof gateway codes above apply only to Portproof.

If the browser shows ERR_TUNNEL_CONNECTION_FAILED

ERR_TUNNEL_CONNECTION_FAILED describes a proxy tunnel that could not be established in Chromium’s network error definitions. The browser message alone does not establish the CONNECT status or its cause.

Run the curl diagnostic above against a small HTTPS endpoint you are permitted to test. Use the same intended proxy host, port and complete username. Read the CONNECT and target statuses separately.

These were local curl checks with synthetic credentials and certificate verification enabled. They did not test a browser or the live gateway. The 403 transfer completed with exit 0 because the diagnostic does not use --fail. curl’s separate CONNECT and response codes.

If curl succeeds and the browser fails, compare the browser’s active system proxy, PAC configuration or extension and its authentication with the explicit curl check. The two clients may use different routes. The client configuration guide covers that comparison.

Prepare a redacted support report

Use values you recorded and leave unavailable fields as not recorded. Exclude passwords, API keys, authentication headers, full proxy usernames and URLs containing credentials or tokens.

Checked at (UTC):
Browser name and version:
Browser error shown (exact text):
Browser proxy source: system / PAC / extension / not recorded
curl version:
Proxy protocol, hostname and port (no credentials):
Destination hostname and port (no path, query or tokens):
connect_status:
target_status:
curl_exit:
Certificate error, if any (redacted):
Documented gateway code, if any:
Same intended proxy and destination in both checks: yes / no / not recorded
Small authorised endpoint succeeded: yes / no / not checked

Find the responding hop and decide whether to retry

An unexpected status does not prove that a corporate proxy answered instead of the configured gateway. A gateway, an upstream hop or an intermediary may produce a failure. The HTTP number alone cannot establish ownership.

Use a short comparison:

1. Confirm the proxy host, protocol and port against your connection settings.
2. Run the explicit curl diagnostic above with an authorised HTTPS test endpoint.
3. Repeat once against the small endpoint your application actually needs, if you have permission to test it.
4. If curl succeeds and the application fails, inspect that process’s HTTPS_PROXY and client settings.
5. If both fail, keep the UTC timestamp, curl version, destination hostname and port, CONNECT status, curl exit code and any non-secret gateway code for support.

Do not send the password, API key, full credential-bearing URL or an unredacted environment dump. A verbose trace can contain authentication headers and other sensitive request information. curl verbose-output guidance.

For a suspected temporary failure on a safe read-only check, an example retry budget is three attempts within 60 seconds, with a delay between attempts. Honour longer server Retry-After guidance by stopping this diagnostic and trying later. This is an example policy, not a gateway limit or a guarantee of recovery.

Stop on repeated failures. Resolve authentication and policy errors before retrying. For purchases, form submissions or other writes, use the application’s idempotency rules and confirm whether the operation already completed before sending it again. HTTP guidance on retrying methods.

SOCKS5 uses a different exchange

SOCKS5 has its own connection request and reply codes; it does not return an HTTP CONNECT status. A SOCKS handshake failure can appear as curl error 97. Check the SOCKS endpoint and client configuration instead of applying the HTTP status table above. curl proxy errors.

For Portproof, use the HTTP endpoint gw.portproof.org:7000 for HTTP proxy configuration and the SOCKS5 endpoint gw.portproof.org:7001 for SOCKS configuration. The HTTP and SOCKS5 guide explains the client syntax.

Once the diagnostic succeeds, run the same small check in your application's actual client before expanding the job. Use the curl guide for connection checks and the traffic planning guide before sizing a larger run.

What is not allowed

Use these checks only for services you are permitted to access. Follow the acceptable-use policy.

Read next