Where should you start when a proxy connection fails?
Validate connection parameters and authentication first, then check the plan, region, network, and target. A fixed sequence prevents unrelated configuration changes.
Quick recommendation
Check protocol, host and port, authentication, plan status, regional nodes, and finally the local network or client. Prove a minimal proxy request before returning to the production workflow so proxy failures and target failures stay separate.
Six-step troubleshooting order
Change one variable at a time and keep the result of each test.
- 01
Confirm the proxy protocol
Confirm whether the endpoint supports an HTTP proxy or SOCKS5. An HTTP proxy can usually tunnel HTTPS with CONNECT, but the client proxy type must still match the endpoint.
- 02
Copy the host and port again
Rule out spaces, missing characters, expired nodes, or confusing an extraction URL with a proxy endpoint.
- 03
Verify authentication
Allowlisting must use the current public egress IP; credentials must match the assigned username, password, and scope.
- 04
Check plan and resource status
Confirm validity, balance or traffic, concurrency limits, and availability for the selected region.
- 05
Run a minimal request against a simple target
Verify egress IP, region, and baseline latency before testing the real destination.
- 06
Cross-check with another client or network
A second environment helps isolate local proxy rules, firewalls, DNS, and client-specific configuration.
Diagnose by symptom
The same unavailable message can originate from very different stages.
| Symptom | Check first | Next step |
|---|---|---|
| Connection refused immediately | Check firstProtocol, host, port, and node validity | Next stepRepeat the same parameters in a known-good client |
| HTTP 407 | Check firstCredentials, allowlist, and authentication mode | Next stepConfirm the public egress IP and authorization scope |
| HTTP 401 | Check firstIdentify whether the response came from the target, management API, or another layer | Next stepCheck that service's token, cookies, account status, and request headers |
| Connection works but is slow | Check firstDistance, node load, concurrency, and response size | Next stepLower concurrency and compare regions or time periods |
| Region result is inconsistent | Check firstEgress IP, target caching, and the detection database | Next stepClear the session and compare multiple sources |
Common failure patterns
First classify the issue as connectivity, performance, or regional output.
No connection at all
Validate protocol, endpoint, authentication, and local networking before changing application logic.
Start with a minimal connectivity test
Variable speed or success rate
Record time, region, concurrency, and target response to separate persistent issues from temporary congestion.
Use controlled batches instead of one observation
Regional detection mismatch
Egress location, database labels, and the target platform result may differ and need separate validation.
Save the egress IP and detection source
What to prepare before contacting support
Complete context shortens reproduction and diagnosis time.
Redact passwords, tokens, and full authentication strings before sharing diagnostic information. Include:
- protocol, client name, and client version;
- redacted host, port, and authentication method;
- complete error text, occurrence time, and timezone;
- target, selected region, egress IP, and concurrency;
- whether the issue reproduces consistently and which checks are complete.
Never expose credentials or private endpoint parameters in public chats or screenshots.