Mobile Proxy Not Working

Symptom table

Run this first, from the machine that has the problem, with your own connection details in place of the placeholders. It prints the HTTP status and timing without downloading a body.

curl -sS -o /dev/null \
  -w '%{http_code} connect=%{time_connect}s total=%{time_total}s\n' \
  -x http://PROXY_HOST:PROXY_PORT -U 'YOUR_PROXY_USERNAME:YOUR_PROXY_PASSWORD' \
  https://api.ipify.org

Then match what you see. The messages in the table are the exact output of curl 8.7.1, recorded against a local test proxy on October 30, 2026.

Browsers report the same faults with their own names. In Chromium's network error list, ERR_PROXY_CONNECTION_FAILED means the browser could not resolve or connect to the proxy itself, while ERR_TUNNEL_CONNECTION_FAILED means the proxy was reached but the CONNECT tunnel to the destination failed. The first is a host or port problem; the second is usually authentication or a destination the proxy cannot reach. curl's own codes are documented in libcurl's error list.

Authentication errors

The HTTP standard, RFC 9110, names code 407 Proxy Authentication Required: the proxy wants credentials it did not get or did not accept. MDN's page on 407 adds that the proxy names its authentication scheme in a Proxy-Authenticate header; for most commercial proxies that scheme is Basic.

Work through these causes in order:

1. Copy the credentials again from the dashboard. Trailing spaces and swapped characters cause most 407s.
2. Encode special characters. If you put the password inside a URL such as http://user:pass@host:port, characters like @, :, /, # and % must be percent-encoded, as RFC 3986 requires for the user information part. Passing the password separately (curl's -U, a library's auth parameter) avoids the problem. Our Python Requests guide shows both forms.
3. Check the allowlist. If the line authenticates by source IP instead of a password, the proxy compares your current public IP with the list. Cloud servers, office networks and home connections can change their public address, and a container may leave through a different NAT than you expect. The IP allowlisting guide explains which address the proxy actually sees.
4. Use the right scheme. An HTTP client pointed at a SOCKS5 port, or the reverse, fails before authentication even starts. SOCKS5 has its own username and password method defined in RFC 1929, on top of the protocol in RFC 1928.
5. Check the client, not just the proxy. Some runtimes refuse to send Basic credentials for HTTPS tunnels by default; Java's built-in HTTP client is the best-known example, and our language comparison shows the setting it needs.

A 407 never means the site blocked you. The site never saw the request.

Connection refused and timeouts

If curl cannot resolve or reach the proxy, nothing about credentials or the site matters yet.

• Resolve failures (exit code 5). Confirm the hostname character by character, then run nslookup PROXY_HOST on the same machine. Corporate DNS filters sometimes block proxy hostnames.
• Refused connections (exit code 7). The host answered and nothing listens on that port. Check that you used the port for the protocol you chose. A local firewall or a security product that blocks outbound connections to unusual ports produces the same error.
• Timeouts (exit code 28). Packets leave and nothing comes back. Try the same command from another network, such as a phone hotspot. If it works there, your network blocks the port. If it fails everywhere, the line may be restarting.
• Drops mid-transfer (exit code 56 without a 407, or "connection reset"). Long idle connections can be cut by NAT timeouts on either side. Use timeouts and retries in your client rather than one connection held open for hours.

Mobile lines restart now and then: the modem reconnects to the carrier, and for a short time the line does not answer. A rotation also briefly interrupts traffic while the device reattaches. Set client timeouts that tolerate a short gap and retry idempotent requests with backoff.

If you use the OpenVPN profile instead of HTTP or SOCKS5, connection problems look different; see OpenVPN Connect fixes.

IP not changing

On a Coronium line you can change the IP from the dashboard, through the API, with a rotation link or on a timer. When the address stays the same, one of these rules is usually in play.

• The interval. There must be at least 60 seconds between rotations. A request inside that window does not produce a new address.
• On-demand devices. Some device types rotate only when you ask, with no timer. Brazil lines, for example, rotate on request only and carry 20 GB of mobile data per month.
• The carrier kept the address. A rotation asks the carrier for a new IP, and sometimes the carrier assigns the same one. The MCP server reports this as unchanged; wait about 60 seconds and try again.
• A rotation still in progress. Through the MCP server, a rotate call returns done with the new IP, rotating (poll the status, do not resubmit), or unchanged. Resubmitting while it is rotating only adds load.
• The client reused a connection. Keep-alive connections opened before the rotation can keep using the old path for a while. Close the client session after rotating and open a new one, then check the IP with a fresh request.

The rotation link deserves its own warning. It rotates the IP on every GET request it receives, and messaging apps, email security scanners and link-preview services all send GET requests to URLs you paste. Paste a rotation link into a chat and the preview bot rotates your line; paste it into a shared document and every viewer's preview does the same. Keep the link in a secret store and call it from your own code.

To confirm a rotation, compare the address before and after with the IP lookup or a request to an IP echo service through the proxy. Our guide to mobile IP rotation covers when to rotate and when not to.

Flagged sessions

If curl returns 200 and the IP is right but a site still shows a captcha, a block or an account warning, the connection works and something else gives the session away.

1. Check for leaks with the WebRTC leak test and the DNS leak test from the same browser profile.
2. Match the browser to the line. Time zone, language and locale should fit the exit country.
3. Keep sessions stable. Rotating the IP in the middle of a logged-in session is a stronger signal than any address. Rotate between sessions.
4. Slow down. Request rates and account actions that no person produces are scored no matter which network carries them.
5. Read the actual message. "Proxy detected", a Cloudflare page or an account lock each have different causes; our proxy detected guide and proxy error codes list them.

A proxy can only fix network-layer causes. If the browser profile or the account history is the problem, a new IP will be flagged too.

When to restart or replace

Restart when the line is unresponsive or slow and a rotation did not help. In the dashboard, use the restart action; through the API, the endpoint is POST /api/v3/modems/:id/restart. Give it a couple of minutes to reconnect to the carrier before testing again.

Replace when a device keeps failing after a restart, or keeps returning addresses that sites have flagged. You can make up to 2 replacements per rolling 24 hours. The replacement device comes with new credentials and may be on a different carrier, so update your configuration before testing.

Contact support when a restart and a replacement did not help, or when the dashboard shows the line offline. Send the line ID, the curl command you ran with the password removed, its exact output and the time with your time zone. That is enough for anyone to reproduce the problem. Support is at hello@coronium.io, on Telegram and through dashboard tickets. For setup from scratch on each operating system, see the proxy setup tutorial, and for the product itself, Coronium mobile proxies.

Frequently asked questions