Proxy connected but not working

Published: 19 July 2026 · 7 min read

TL;DR: If the IP changed but sites still time out, your client is almost certainly on HTTP instead of SOCKS5, so DNS never goes through the proxy. Switch to SOCKS5 first. And test with curl -v -x socks5h://gw.roamproxy.com:41080 -U 'username:password' https://ip.sb — without -x, curl connects directly and reports your own IP.

Start here: one command that tells you where the fault is

Before changing anything in your client, run this from a terminal. It talks to our gateway directly, so it separates "the account or the route is broken" from "the client is misconfigured".

curl -v -x socks5h://gw.roamproxy.com:41080 -U 'username:password' https://ip.sb

If this returns a proxy IP but your client does not work, the account and the route are fine and the problem is in the client. If this also fails, read the curl error text — it usually names the cause outright.

Two ways this command gets written wrong, both of which produce a misleading result:

  • The proxy must follow -x. Many tutorials print curl -v socks5h://gw.roamproxy.com:41080 ..., passing the proxy as if it were a URL. curl silently ignores it, connects directly in the clear, and returns your own IP address. People then conclude the proxy is dead when it was never used.
  • Pass credentials with -U in single quotes, not inside the URL. If your password contains #, @, / or :, embedding it in the proxy URL truncates it or triggers Unsupported proxy syntax. Keeping it in -U '...' avoids both.

Symptom 1: ip.sb loads and the IP changed, but every other site times out

This is by far the most common report, and the one most often mistaken for a broken product. A changed IP proves authentication and the tunnel are working. The fault is in what kind of traffic is being routed — usually DNS.

Verifying with ip.sb alone is not enough. It is a single, small, frequently cached request; it can succeed while normal browsing fails.

Work through these in order

  1. Switch the proxy type to SOCKS5. With an HTTP-type proxy, only HTTP/HTTPS traffic is proxied — DNS lookups still go out over your local network. If local DNS is poisoned or returns an address that is unreachable from the exit, you get exactly this pattern: the proxy connects, but pages never load. Under SOCKS5 the hostname is resolved through the proxy, and this class of failure largely disappears.

  2. Set routing to global / proxy-all. Rule-based modes (Shadowrocket's "Config" mode, for example) send a portion of domains direct. While diagnosing, force everything through the proxy; add rules back only after you have a working baseline.

  3. If your network cannot reach our gateway directly, chain Roam behind an upstream proxy. On a restricted network or behind a corporate firewall, the connection to gw.roamproxy.com:41080 may never be established at all. In that case you need an upstream hop first, with Roam chained behind it. See the Shadowrocket setup guide for the chaining step.

  4. Confirm from the command line. Run the curl command above. Success there plus failure in the client narrows it to client configuration every time.

Symptom 2: the client is switched on but nothing happens

  1. Select the server first, then flip the switch. With no server selected, toggling the switch does nothing at all — no error, no traffic.
  2. Check that the VPN profile was actually installed. On iOS: Settings → General → VPN & Device Management. If you tapped "Don't Allow" at any point during setup, there is no profile here. Delete the configuration and import it again, allowing the profile this time. On macOS the equivalent check is in System Settings → Network — see the macOS setup guide.
  3. Look for leading or trailing spaces in the username and password. Copy-paste picks these up constantly, and most clients show no error — they just fail to authenticate.

Symptom 3: you cannot access ChatGPT or Claude

This is usually not an IP problem. Our exit IPs can reach both services. When access fails, it is nearly always one of the following two things.

1. Your network cannot reach our gateway, and no upstream hop is configured

If your connection to gw.roamproxy.com:41080 is blocked by a restricted network or a corporate firewall, nothing downstream will work. Put an upstream proxy in front and chain Roam behind it — the chaining step is covered in the Shadowrocket setup guide.

2. The IP region does not match the account's region

These services compare where an account was registered with where it is being used. Logging into a US-registered account from a Japanese IP can trip a risk check and force verification. Pick one region and stay on it; frequent switching is what triggers challenges.

If you are on a datacenter IP rather than a residential one, the odds of being classified as automated traffic are markedly higher. For sites like these, use residential IPs — dynamic residential is $2/GB and static residential is $4 per IP per month.

Symptom 4: the dashboard shows billed traffic, but nothing works

Billed traffic means the connection was established and authentication succeeded — the account is fine. In practice this is almost always Symptom 1, so work through that checklist.

One thing to keep in mind: diagnosing consumes bandwidth too. Test with small requests such as curl https://ip.sb rather than reloading heavy pages over and over, especially on the 300MB trial.

Still not working

Send support these three things and you will skip an entire round trip:

  1. Your operating system and client name (for example: iOS 18 + Shadowrocket).
  2. The proxy type in use (SOCKS5 or HTTP), and whether an upstream proxy is chained in front.
  3. The full output of curl -v -x socks5h://gw.roamproxy.com:41080 -U 'username:password' https://ip.sb — with the password redacted.

FAQ

Why does ip.sb work but no other site loads?

Almost always because the proxy type is set to HTTP instead of SOCKS5. Under HTTP only web traffic is proxied and DNS lookups still go through your local network, so hostnames resolve to addresses the exit cannot reach. ip.sb often succeeds anyway because the request is small and frequently cached. Switch the client to SOCKS5 so name resolution goes through the proxy as well.

My curl test returns my own IP address. Is the proxy broken?

No — the command is almost certainly missing the -x flag. Writing curl -v socks5h://gw.roamproxy.com:41080 passes the proxy as a URL, which curl ignores before connecting directly in the clear. The correct form is curl -v -x socks5h://gw.roamproxy.com:41080 -U 'username:password' https://ip.sb, with the proxy after -x.

My password contains special characters and the connection fails immediately. What is wrong?

Characters such as # @ / and : break when embedded in a proxy URL — the string is truncated or curl reports Unsupported proxy syntax. Pass the credentials separately with -U and wrap them in single quotes so the shell does not touch them. Most GUI clients have separate username and password fields for the same reason.

The dashboard shows I used bandwidth, but nothing loads. Am I being charged for a broken service?

Billed traffic means the connection was established and your credentials were accepted, so the account itself is working. This pattern is nearly always the DNS/SOCKS5 issue described in Symptom 1. Note that troubleshooting itself uses bandwidth, so test with small requests like curl https://ip.sb rather than reloading pages.

Working through the client configuration from scratch is often faster than patching a broken one — see the Shadowrocket guide or the macOS guide. The 300MB trial is enough to confirm a fix before you top up.