Troubleshooting

Common proxy symptoms, their likely causes, and the fastest fix for each. Work through the section that matches what you're seeing, then test server-side to confirm.

Before you start. Most connection problems come down to one of three things: an IP whitelist that doesn't include your current IP, wrong or mangled credentials, or a targeting suffix typo. The sections below cover each in turn. If you're not sure how your setup authenticates, start with Authentication.

Connection refused / connection reset

This almost always means the proxy accepted your request and then rejected it because your source IP isn't allowed. It rarely means the endpoint is down.

Most common cause: IP whitelist

If you've added any IPs to your whitelist in the dashboard, then only those IPs can connect, and they connect without a username or password. A request from any other IP is refused, even if you also send valid credentials. This trips people up when their public IP changes, which happens on home connections, mobile networks, and cloud instances that get a new address.

Fix. Pick one:

Add your current public IP under Whitelist in the dashboard. Find your IP by visiting https://api.ipify.org from the machine that will connect.
Or switch to username + password authentication and connect as http://<username>:<password>@<endpoint>:<port>. Credentials work from any IP, so this is the better choice on connections with a changing address.

Whitelist and credentials are separate paths. As soon as you add one or more IPs to your whitelist, access is gated by IP and only those IPs can connect. If you'd rather authenticate with a username and password from anywhere, remove every whitelist entry so the credential path is the one in play. See Authentication for the full picture.

Other causes

Wrong endpoint or port for your product. Each product has its own host and port, and connecting to the wrong one fails. Check the table below against your plan.
Local firewall or network policy blocking outbound connections to the proxy port. Test from a different network to rule this out.

Product	Endpoint	Port(s)
Budget Unlimited	`residential.proxyomega.com`	10000-10099
Premium Unlimited	assigned in dashboard	8000
Residential / ISP	`platinum.proxyomega.com`	20228
Mobile	`mobile.proxyomega.com`	20229
IPv6	`ipv6.proxyomega.com`	9000
Static ISP	`isp.proxyomega.com`	30000-30099

407 Proxy Authentication Required

A 407 means the proxy rejected your username or password. The connection reached us fine, but the credentials didn't check out.

Fixes, in order of likelihood:

Copy your credentials fresh from the dashboard. Re-copy the username and password rather than reusing an old value. A stale password won't authenticate.
Check you didn't mangle the targeting suffix. Targeting parameters attach to the username, dash-separated, and the password stays unchanged. A typo in the suffix, such as a stray space, a missing dash, or a wrong parameter for that product, can invalidate the whole username. For example, Budget Unlimited only accepts country, session and ttl, so sending -city- or -asn- to it will be rejected. See Targeting for which parameters each product supports.
Watch for copy-paste errors such as trailing whitespace, a truncated password, or the wrong account. Paste into a plain text field first to confirm there are no hidden characters.

A correctly formed username with a valid targeting suffix looks like this (password unchanged):

http://<username>-country-us-session-abc123-ttl-30:<password>@residential.proxyomega.com:10000

Let the dashboard build it for you. The proxy-list generator assembles the full username string (including targeting) and the endpoint, so you can copy a known-good line rather than typing the suffix by hand.

Timeouts or slow responses

If requests hang, time out, or crawl, the credentials and routing are usually fine. The problem is on the target side or in how much load you're pushing.

The target may be blocking or rate-limiting proxies. Some sites throttle or challenge traffic they suspect is automated. Try a different -country-, rotate to a fresh IP by changing or omitting -session, or slow your request rate.
Try a different country or session. A specific exit IP may be slow or flagged for that target. A new session value gives you a different IP, and a different country gives you a different pool entirely.
Reduce concurrency. Firing too many simultaneous requests through one IP invites throttling on the target's end. Spread load across more sessions or ease off the parallelism.
Check your plan's capacity isn't exhausted. On Budget Unlimited, concurrency scales with your port count (5, 15, 25, 50 or 100 ports), so if every port is saturated, add ports or queue your work. On IPv6, concurrency is bounded by the number of threads you bought. On pay-as-you-go products (Residential / ISP, Mobile), confirm you still have GB balance in the dashboard.

Wrong country, or IP not where expected

If exits land in the wrong location, check the targeting first, because the syntax is exact.

Confirm the country code is correct. Use the two-letter code, for example -country-us, -country-de, -country-gb. A wrong or unrecognised code won't target the country you intended.
Confirm the product supports that targeting. Not every product accepts every parameter. Country is available on all rotating products; state and city are Premium and Residential / ISP; ASN is Residential / ISP only. Mobile and IPv6 are country-level only. See the full matrix in Targeting.
Remember rotating sessions change IP. Without a -session value (or with a fresh one each time), you get a new IP on every request, so successive requests can appear in different places within your targeted country. To hold one IP, reuse the same -session value and set -ttl-<minutes> for how long to hold it. See Sessions & rotation.

Static ISP is different. On Static ISP each port is already a fixed, dedicated US IP, with no rotation or targeting parameters to add. If the wrong IP appears there, check you're connecting to the right port in the 30000-30099 range.

How do I test server-side?

The quickest way to isolate a problem is to send one request through the proxy from a terminal and read the result. Replace user, pass and the endpoint/port with your own values:

curl -x "http://user:[email protected]:10000" \
  -w "HTTP %{http_code}\n" \
  https://api.ipify.org

How to read the result:

A proxied IP is printed

You see an IP address that isn't your own, and HTTP 200. The proxy is working. If your app still fails, the issue is on the client side, such as wrong credentials in your code, a whitelist mismatch, or a local firewall.

HTTP 407

Authentication failed. Re-copy your username and password from the dashboard and check the targeting suffix, as in the 407 section above.

Connection refused / reset

Most likely a whitelist that doesn't include the IP of the machine running curl. Add that IP, or use username + password. See Connection refused.

Timeout / no response

The target may be blocking the exit, or the request is slow. Try a different -country- or a fresh -session, and test against a neutral URL like https://httpbin.org/ip first.

Using https://api.ipify.org or https://httpbin.org/ip as the test URL works well, because both echo back the IP they saw. A proxied IP in the output is proof the request went through the proxy rather than your own connection.

Adjust the endpoint and port for the product you're testing (see the endpoint table). For products that use HTTPS or SOCKS5 only, use the appropriate scheme, for example socks5://user:[email protected]:20228.

Still stuck?

✓

We're happy to help. If you've worked through the relevant section and it still won't connect, contact us at [email protected] or use the in-dashboard chat. Include the product, the endpoint and port you're using, a sample of the request (with the password redacted), and the exact error or HTTP code, so we can pinpoint it quickly. For a refresher on the three authentication methods, see Authentication.

Last updated 6 July 2026