Diagnosing Proxy Connection Failures

Work up the stack (DNS, TCP, the CONNECT tunnel, then TLS) until the failing layer names itself. Covers firewalls, MTU and container networking.

This guide is for the case where the proxy never answers: the attempt dies with Connection refused, or sits in silence until a timeout. If the proxy answered with anything at all, even an error, the network path is fine and the problem is elsewhere: a 407 is a credentials problem, covered in fixing 407 errors, and a refusal from the destination site is covered in why your IP gets blocked.

Start by running the connection once with everything visible:

curl -v -x http://USERNAME:PASSWORD@HOST:PORT https://api.ipify.org

A proxied HTTPS request is built in four layers, and the first line that goes wrong names the one that failed:

What `curl -v` shows	Layer	Section
`Could not resolve proxy`	DNS: the hostname never became an address	Layer one
`Connection refused`	TCP: a machine answered and rejected the connection; usually a wrong host or port	Layer two
A long pause, then `Connection timed out`	TCP: your packets left and nothing came back; usually a firewall dropping them	Layer two, then firewalls
`CONNECT` is sent, then an error arrives	The tunnel: the proxy is reachable but declined or something intercepted it	Layer three
`TLS handshake, Client hello`, then the output freezes	TLS: almost always the MTU problem	Layer four
A `407` status	Not a connection failure; the path works and the proxy is asking about credentials	The 407 guide

Test from the bottom up. Rewriting application code while the real problem is a firewall costs an afternoon; the layers below take minutes each.

Layer one: the hostname must resolve

Resolve the name yourself, through the resolver your machine uses:

dig +short gw-rotating_datacenter.node4.io
# or, on systems without dig:
nslookup gw-rotating_datacenter.node4.io

This layer applies to the gateway hostnames (gw-*.node4.io). Static datacenter proxies, the free set included, are listed on the Proxies page by IP address, so there is nothing to resolve; for those, go straight to layer two. Resolve the hostname you are actually connecting to, and check it for typos.

If an older configuration gives you gw-rotating_shared.node4.io, resolve that one: it is the former name of the same Rotating Datacenter listeners, it still resolves and still serves on the same addresses and ports. A difference in the hostname alone is not a fault. New setups use gw-rotating_datacenter.node4.io.

When resolution genuinely fails, three causes cover nearly every case: a corporate resolver that answers only for internal names, a container with a stale or empty resolv.conf, or an old entry in /etc/hosts (or the Windows equivalent) overriding DNS for that one name. Prove DNS is the only problem by taking it out of the path for one request:

curl -v --resolve HOST:PORT:IP_ADDRESS -x http://USERNAME:PASSWORD@HOST:PORT https://api.ipify.org

If that succeeds and the plain command fails, fix the resolver, not the proxy configuration.

Layer two: the port must accept a connection

Test raw TCP reachability with no HTTP involved:

nc -vz HOST PORT
# or, where netcat is not installed:
curl -v telnet://HOST:PORT --connect-timeout 5

Refused: re-check the host and port against the dashboard character by character. The Rotating Datacenter gateway's HTTP listener is port 8083, the residential gateway's is 8082, and each SOCKS5 listener is a different port again (SOCKS5 setup lists them). Sending HTTP traffic to a SOCKS5 port, or connecting to an endpoint copied from an old config, produces exactly this symptom. In an anti-detect browser, a proxy check that times out usually means the proxy type selected in the profile and the port disagree, for example SOCKS5 chosen with an HTTP port; the AdsPower, BitBrowser and Hubstudio setup guides show which port goes with which type.

Timeout: try the same command from a different network. Tether to a phone hotspot and repeat it. If it succeeds over the hotspot and fails on your normal network, your machine, your account and the proxy are all fine, and the network you are on is filtering the traffic.

Corporate firewalls and egress filtering

Proxy ports are not web ports, and a lot of network policy amounts to "outbound 80 and 443 only". Office networks, universities, hotels, guest Wi-Fi and cloud security groups left at a restrictive default all do this. The signature: ordinary browsing works, the proxy times out, the hotspot test succeeds.

There is no client-side workaround, because the block is enforced by equipment you do not control. Ask whoever runs the network to permit outbound TCP to the specific host and port. In a cloud VPC, add the destination to your instance's egress rules. In Kubernetes, check for an egress NetworkPolicy on the namespace, which can silence one namespace while the node underneath connects freely.

Layer three: the CONNECT tunnel

For an https:// target, your client first asks the proxy to open a tunnel (CONNECT example.com:443), and the proxy answers HTTP/1.1 200 Connection established before any TLS begins. Both lines should appear in verbose output.

An error at this step means the proxy, or something claiming to be it, is reachable but declined the tunnel. A 407 belongs to the credentials guide. An HTML block page, a certificate issued by a name you do not recognize, or a redirect usually means a middlebox on your network intercepted the CONNECT. Corporate TLS-inspection appliances do this; the tell is in the certificate details curl -v prints. If the issuer is your employer's security vendor rather than a public certificate authority, your traffic is being intercepted before it leaves the building.

Layer four: TLS, and the MTU trap

Everything succeeds, Client hello is sent, and then nothing, until a timeout. No refusal, no reset, no error.

This is an MTU black hole. Small packets travel fine, which is why DNS, TCP and the CONNECT all worked; the certificate exchange arrives in full-size packets, and if a link on the path (a VPN, a PPPoE home connection, an overlay network) carries a smaller maximum packet size while the "fragmentation needed" signal is blocked, those packets are dropped without a trace. Test with pings that refuse to fragment:

ping -M do -s 1472 HOST        # Linux
ping -D -s 1472 HOST           # macOS

If 1472 bytes fails but a smaller size such as 1300 succeeds, you have found it. Enable MSS clamping on the VPN or router where the smaller link is, or lower your interface MTU to 1400.

The pool is IPv4

Node4 endpoints publish IPv4 addresses only. On a machine with a misconfigured dual-stack setup, a client can spend its whole timeout on an address family with no route before trying the one that works. Force IPv4 as a test:

curl -4 -v -x http://USERNAME:PASSWORD@HOST:PORT https://api.ipify.org

If -4 fixes it, configure your client or resolver to prefer IPv4 for these hostnames.

Containers

A container has its own network namespace, resolver file, routes, and often proxy-related environment variables baked into the image, so every layer above can pass on the host and fail inside. Establish which side is broken first:

docker run --rm curlimages/curl \
  -v -x http://USERNAME:PASSWORD@HOST:PORT https://api.ipify.org

If that works while your application container fails, compare the differences: an inherited HTTP_PROXY or NO_PROXY variable overriding your configuration, container DNS pointing somewhere dead (test with --dns 1.1.1.1), or host firewall rules applied to forwarded traffic. Overlay networks often run a reduced MTU, which reproduces the hanging-TLS symptom only inside the cluster.

The decision tree

Run curl -v through the proxy and note the first line that goes wrong.
Name will not resolve? Test with --resolve. If that works, repair DNS: resolver config, resolv.conf in the container, or a stale hosts-file entry.
Refused? Re-check host and port against the dashboard. Confirm you are not sending HTTP to a SOCKS5 listener or the reverse.
Timeout? Hotspot test. Works elsewhere: egress filtering, take it to whoever administers the network or the security group. Fails everywhere: open a support ticket from the dashboard with the verbose output and a traceroute HOST attached.
CONNECT answered with an error? A 407 goes to the credentials guide. An unfamiliar certificate or a block page means interception on your side.
TLS hangs? Run the ping test. Clamp the MTU or fix the VPN.
curl succeeds but your application still cannot connect? The network is fine and the bug is in how the application passes proxy settings. The Python and Node.js guides cover the library-specific traps, and the curl converter translates the command that just worked into your client library.

The proxy connection builder assembles a correct curl command from a host, port, protocol and credential, and the other free tools cover neighboring checks such as which address you are leaving from.

When the tree ends at a ticket, include the full curl -v transcript with the password redacted, which networks you tested from, and the exact host and port. Those three facts usually turn a back-and-forth into one reply. If you are still choosing a product rather than debugging a live plan, the features overview describes how static endpoints and gateway hostnames differ.