Proxy connection refused or timing out

Short answers

If Chrome shows ERR_PROXY_CONNECTION_FAILED, use the Chrome connection checklist to identify the browser’s active proxy before comparing it with curl. For another message, the proxy error index links each failure to its next check.

Where a proxy connection can fail

A request through the gateway passes three stages before your request reaches the destination. Each stage fails in its own way, so name the stage before choosing a fix.

Reach the gateway

Your client resolves the gateway hostname and opens a TCP connection to the port. The name may not resolve, the port may refuse, or nothing may answer before the connect timeout.

Proxy handshake

The client speaks the proxy protocol: HTTP CONNECT on 7000, or the SOCKS5 greeting and sign-in on 7001. The protocol may not match the port, the credentials may be rejected, or the gateway may accept the connection and not answer.

Tunnel answer

An HTTP gateway answers CONNECT with a status. 200 opens the tunnel; any other status means the gateway answered and refused. A 407 belongs to the 407 guide; 403, 502 and 503 belong to the CONNECT tunnel guide.

Only after these stages does TLS start between your client and the destination, inside the tunnel. CONNECT itself is defined in RFC 9110. This guide covers the first two stages, where no tunnel status exists yet.

Run two bounded probes

Copy the complete username from the connection builder and replace YOUR_FULL_PROXY_USERNAME. curl asks for the password; leave it out of the command so it stays out of your shell history. --connect-timeout 10 limits the connection and, in our tests, the proxy handshake too. --max-time 20 limits the whole check.

curl --disable --silent --show-error --noproxy '' \
  --connect-timeout 10 --max-time 20 \
  --proxy 'http://gw.portproof.org:7000' \
  --proxy-user 'YOUR_FULL_PROXY_USERNAME' \
  --output /dev/null \
  --write-out 'curl_exit=%{exitcode} connect_status=%{http_connect}\n' \
  'https://example.com/'

Then send the same check to the SOCKS5 port. The socks5h scheme asks the gateway to resolve the destination name, so the lookup happens on the proxy side rather than on your machine. SOCKS5 has no HTTP status, so connect_status stays 000 here.

curl --disable --silent --show-error --noproxy '' \
  --connect-timeout 10 --max-time 20 \
  --proxy 'socks5h://gw.portproof.org:7001' \
  --proxy-user 'YOUR_FULL_PROXY_USERNAME' \
  --output /dev/null \
  --write-out 'curl_exit=%{exitcode} connect_status=%{http_connect}\n' \
  'https://example.com/'

Each probe is one GET with no retry. --disable comes first so curl skips its default configuration file, and the empty --noproxy list keeps proxy environment settings out of the check. Use a small HTTPS endpoint you are allowed to test; example.com is the reserved example domain. On Windows PowerShell, call curl.exe and adapt the line continuations.

The output is curl’s error line, from --show-error, and the summary line. Keep both. Do not add -v to a trace you plan to share: in our test run the verbose output printed the Proxy-Authorization header, which is your username and password in reversible Base64.

Read the exit code and the message together

These are the results of the two probes above against local test servers. The message is curl’s text, shortened.

The CONNECT statuses in this table were chosen by the test server; on the live gateway, read the status curl prints. Other curl releases can attach a different number to the same failure: from curl 8.20.0, CONNECT tunnel failed, response … exits with 7 instead of 56. Match the message as well as the number, and treat 7 as a refusal only when the text says Couldn't connect to server.

Code 6 does not always mean your destination is wrong. With a SOCKS5 proxy URL it named the gateway. Through a working gateway, a destination that did not resolve came back as a 502 from the HTTP port or a 97 from the SOCKS5 port, never as 6.

Work through the causes in order

1. Hostname: re-copy it from the dashboard rather than retyping it. Code 5, or code 6 naming the gateway, means the name did not resolve.
2. Port and scheme together: http:// with 7000, socks5h:// with 7001. A mismatch connects first and then fails with 56, 28 or 97, so it rarely looks like a refusal. Use the scheme the connection builder shows: with https://, curl starts TLS to the gateway itself, and against a plain HTTP proxy port our test server timed out (28) or failed the TLS handshake (35).
3. Your network: run the same probes from another network, such as a phone hotspot. If it works there, a firewall, egress rule or network policy on the first network is the difference, not your client.
4. A gateway that accepted and went quiet: exit 28 after the connection opened, as in the two handshake rows above. Retry once after a pause; if it repeats, collect the support report rather than raising the timeout.
5. Sticky sessions: if only a job with a session name fails, repeat the probe with a new session name in the username. If the new name works, the old session was the difference, not your host, port or password. A sticky session keeps the same device; the carrier may still change the IP. Why a sticky session changed IP covers the next checks.

Raise --connect-timeout only after this list. A longer wait cannot repair a closed port, a wrong name or a protocol mismatch. Once both probes pass, the curl testing guide checks the exit IP, latency and rotation.

The same split in Python Requests

Requests raises different exceptions for an HTTP gateway and a SOCKS5 gateway, so the order of the except branches matters. The example reads the username and password from the environment, as in the Requests guide, and the gateway from PROXY_SERVER. For SOCKS5, install the extra with python -m pip install "requests[socks]" and set PROXY_SERVER to socks5h://gw.portproof.org:7001.

import os
from urllib.parse import quote

import requests

server = os.environ.get("PROXY_SERVER", "http://gw.portproof.org:7000")
scheme, _, address = server.partition("://")
if scheme not in ("http", "socks5h") or not address or "@" in address:
    raise SystemExit("Use http:// or socks5h:// with a host and port, no credentials")

user = quote(os.environ["PROXY_USER"], safe="")
password = quote(os.environ["PROXY_PASSWORD"], safe="")
proxy = f"{scheme}://{user}:{password}@{address}"

try:
    response = requests.get(
        "https://example.com/",
        proxies={"http": proxy, "https": proxy},
        timeout=(3.05, 27),
    )
    print("HTTP", response.status_code)
except requests.exceptions.ConnectTimeout:
    print("No answer from the proxy within the connect timeout")
except requests.exceptions.ProxyError as error:
    print("The HTTP proxy failed:", error)
except requests.exceptions.ConnectionError as error:
    print("Connection failed:", error)
except requests.exceptions.Timeout:
    print("Connected, but no answer within the read timeout")

So ConnectTimeout alone misses an HTTP gateway that never accepts the connection: urllib3 wraps that timeout in ProxyError. The last branch catches an HTTP gateway that accepted the connection but never answered CONNECT; without it, the script stopped with a traceback. In that case the wait was limited by the connect value, 3.05 seconds, not the read value. The printed messages contained no password in our runs.

Requests also reads HTTPS_PROXY and HTTP_PROXY when you pass no proxies. If curl works and your script does not, compare the two processes with the environment-settings guide.

Certificate errors belong to another layer

An HTTP gateway relays CONNECT and does not terminate TLS: your client checks the destination’s certificate through the tunnel. In our test without the right CA bundle, the HTTP probe ended with connect_status=200 and exit 60, SSL certificate problem: unable to get local issuer certificate. Requests reported the same failure as SSLError with CERTIFICATE_VERIFY_FAILED.

A 200 there means the gateway did its part. Check the destination hostname, your system clock, your CA bundle, and whether a corporate or public network intercepts TLS with its own certificate. Keep verification on: switching it off hides exactly the interception you are trying to find, and it repairs none of the failures above.

What to send support

If the checklist does not settle it, send the measured result rather than a description. Leave out the password, the full username and any -v trace.

Checked at (UTC):
curl version:
Proxy scheme, hostname and port (no credentials):
Destination hostname and port:
curl error line (exact text):
curl_exit:
connect_status:
Same result from another network: yes / no / not checked
Session name, if the username has one:

What we checked locally

On 1 October 2026 we ran both probes and the Python example, as printed, against local test servers: an HTTP proxy with CONNECT and Basic authentication, a SOCKS5 server with username and password, variants that accept a connection and never answer, a closed port, a port that never completes a connection, and an HTTPS origin signed by a local test CA. Credentials were synthetic and certificate verification stayed on; the only additions were the test addresses and that CA bundle.

Versions: curl 8.7.1 on macOS, Python 3.12.14, requests 2.34.2, urllib3 2.8.0 and PySocks 1.7.1. On that machine the operating system abandoned an unanswered connection after about 7.8 seconds, which is why a 10-second limit could end with Couldn't connect to server while still exiting 28. These checks do not measure the live gateway, its timing or the statuses it sends.

What is not allowed

Run these checks only against endpoints you are permitted to test, and follow the acceptable-use policy.

Read next