Why does my Nodetonet proxy return 407 even though it shows green on the dashboard?

The green status means Nodetonet accepted your credentials — the local listener is fine. The 407 is coming from the upstream provider that Nodetonet forwards to on the second hop. Open the proxy detail page and check the Upstream health card; the AUTH or BLOCK chip will point you to the exact cause.

What is the difference between AUTH and BLOCK on the upstream health card?

AUTH means the upstream provider returned 407 because the credentials were rejected — wrong password, hidden whitespace, or an unescaped colon. BLOCK means the credentials were accepted but the specific request was refused — typically a geographic restriction, paused subscription or exhausted pool. Check the Upstream health card closely and treat each one differently.

How do I whitelist the Nodetonet edge IP with my upstream provider?

Go to the Servers page in the Nodetonet panel, find the server your proxy is assigned to, and copy its egress IP address. Then paste that IP into the IP allow-list settings on your upstream provider's dashboard. The Upstream health card should turn OK within the next probe cycle.

My upstream password contains a colon. How do I enter it correctly?

URL-encode the colon as %3A before saving it in the proxy settings. The internal credential parser uses a colon as a delimiter between the host, port, username and password fields, so a literal colon in the password breaks parsing unless escaped.

The health card alternates between OK and BLOCK rapidly — what does that mean?

This pattern almost always indicates pool exhaustion: the upstream provider has run out of available exit IPs for the country or city you have targeted. It is not a credentials problem. Reduce concurrency on that proxy, broaden the geographic target, or ask the upstream provider about pool availability for your region.

Can I forward through multiple upstream providers on different proxies?

Yes. Each proxy in Nodetonet can have its own upstream configuration — different provider, different host, different credentials. You can run residential forwarding on some proxies and mobile-only exit on others from the same panel. See the upstream forwarding guide and the upstream-only proxies post for setup details.

Tunnel up, every request 407 — debugging upstream auth failures

Your Nodetonet proxy is green on the dashboard. The listener is bound, your credentials are accepted on our side, and yet every request you push through comes back with HTTP/1.1 407 Proxy Authentication Required. The tunnel is up — the problem is one hop further along, at the upstream provider your proxy is configured to forward through.

This guide walks through the exact checklist we use when a support ticket lands with this symptom. Follow each step in order: you will narrow the root cause to one of four scenarios and have a fix in place within minutes.

What is upstream forwarding and why does auth matter?

When you configure upstream-residential forwarding on a Nodetonet proxy, requests travel two hops: your client → Nodetonet → upstream provider → target site. Nodetonet authenticates you on the first hop; the upstream provider authenticates Nodetonet on the second hop. A 407 on the second hop means the upstream provider rejected Nodetonet's credentials — not yours.

This architecture is how you chain a residential or third-party pool onto a Nodetonet endpoint, gaining carrier-grade trust for the exit IP while managing everything from one panel. The details of the forwarding setup are covered in upstream-only proxies explained.

Step 1 — Confirm the failure is upstream, not local

Before touching anything on the upstream side, rule out a simpler mistake: your own credentials to Nodetonet could be wrong. Run this from your terminal, substituting your real proxy username, password, subdomain and port:

curl -v -x http://u8x2:p7q1@sub42.nodetonet.com:48888 https://api.ipify.org 2>&1 | grep -i "407|proxy"

Interpret the output carefully:

If the 407 comes back with the header Proxy-Authenticate signed by Nodetonet, the local credentials are wrong — fix your username or password in the panel and stop here.
If Nodetonet accepts your credentials but then returns a 502, a closed connection, or a response containing X-Nodetonet-Upstream-Status: 407, the upstream rejected us. Continue to step 2.

You can also verify the exit IP independently with our free proxy checker — it tells you whether the proxy is reachable and what IP the world sees.

Step 2 — Read the upstream health card

Open the proxy detail page in the panel. Directly below the connection string you will find the Upstream health card. It probes the upstream every minute and shows one of four status chips. Understanding which chip is lit eliminates guesswork:

Status chip	What it means	Where to look first
OK	Last probe completed successfully; exit IP was captured.	The upstream is fine — check your client-side configuration.
AUTH	The upstream returned 407. The password, username, or modifier syntax is wrong.	Re-enter credentials; check for extra spaces or unescaped colons.
BLOCK	Upstream accepted the credentials but refused the request — geographic restriction, paused subscription, or exhausted pool.	Check provider dashboard for account status or geo approval.
DOWN	TCP connect to the upstream host and port failed entirely.	Verify the host, port, and that the provider's gateway is reachable.

That single chip collapses the search space from "anything could be wrong" to one of four specific problems. Most issues are AUTH or BLOCK.

Step 3 — Fix the root cause

Match the chip to the fix below.

AUTH — wrong upstream password or malformed username

This is the most common cause. When someone generates upstream credentials and pastes them, a leading or trailing whitespace is invisible in most text editors but fatal to HTTP auth headers. Equally common: a password that contains a literal colon (:) breaks the host:port:user:pass parser used internally.

Open the proxy in the panel and retype the password by hand — do not paste from a source that may have hidden characters.
If the password contains a colon, URL-encode it as %3A before saving.
Check the upstream username modifier syntax — a badly formed country tag or session string will also produce 407 on some providers.

AUTH — IP allow-list on the provider side

Many residential providers let you lock the gateway to a specific IP. If you previously whitelisted your office IP but this proxy now runs through a Nodetonet edge server, the edge dials from a different address and is silently rejected. The provider returns 407 even though the password itself is correct.

You have two clean fixes:

Switch the auth mode to username/password on the provider side. Most providers support both IP whitelist and password auth simultaneously — enable password auth so the IP no longer matters.
Whitelist the Nodetonet edge IP. Go to the Servers page in the panel, find the server your proxy is assigned to, and copy its egress IP. Paste that into the IP allow-list on the upstream provider's dashboard.

BLOCK — geographic restriction

Some providers gate country exits behind extra approval. If you set a country modifier such as -country-ir and your account has not been approved for that exit, the upstream accepts your auth credentials and then refuses the specific request. This surfaces as BLOCK rather than AUTH in the health card. Contact the upstream provider to enable the country, or switch to a country your account covers. See geo-targeting for how to set country and carrier in the proxy username.

BLOCK — paused subscription or exhausted bandwidth

If the upstream provider account ran out of purchased bandwidth, the card on file was declined, or someone hit "pause" in the provider dashboard, the gateway still answers — but returns 407 with a body such as Subscription expired or Bandwidth limit reached. Log in to the upstream provider's panel directly, top up the balance or unpause the account, and the Nodetonet health card will flip back to OK within a minute.

If the health card alternates between OK and BLOCK every few minutes, you are almost certainly looking at pool exhaustion for the country or city you have selected — not a credentials problem. The upstream ran out of available exit IPs matching your target. Reduce the concurrency on that proxy, choose a broader geo target, or contact the upstream provider about pool capacity.

Step 4 — Bypass Nodetonet to isolate the upstream

If the health card shows AUTH but re-entering the credentials does not fix it, probe the upstream directly from your own machine to confirm the credentials work at all:

curl -v -x http://USER:PASS@gate.provider.com:7000 https://api.ipify.org

Replace USER, PASS, gate.provider.com and 7000 with your upstream provider's actual values. Two outcomes:

The direct curl also returns 407 — the problem is with the upstream credentials, not Nodetonet. Fix them at the provider and then update the proxy in the panel.
The direct curl succeeds but Nodetonet still returns 407 — you are hitting an IP allow-list. The credentials work from your IP but not from the Nodetonet edge IP. Apply fix 2 in step 3.

Step 5 — Verify with the proxy checker

After making a change, give the panel's health card up to one minute to re-probe, then confirm the endpoint is serving real traffic by running it through our proxy checker. A passing check — showing the provider's exit IP and a clean HTTP 200 — is the final confirmation that auth is working end to end.

Preventing recurrence

Keep upstream credentials in the panel, not in client configs. If you rotate the provider password, update it in one place (the proxy detail page) rather than hunting through scripts.
Monitor the health card. The card flips to AUTH within one minute of a credential problem. Pair it with tunnel health monitoring to get alerted before your job fails.
Use per-client quotas and expiry. If multiple clients share one upstream proxy, set per-client quotas to prevent one heavy user from exhausting the upstream allowance for everyone.
Understand sticky vs rotating. A sticky session pins you to one upstream exit; a rotating session cycles them. If the upstream pool is small for your target country, rotating will exhaust it faster. Read when to use rotating proxies before configuring.

What to do if none of the above works

If you have stepped through every check above and the health card still shows AUTH or BLOCK, open a support ticket and include:

The proxy ID from the panel URL.
A screenshot of the health card chip.
The output of your direct curl against the upstream (censor the password).

The team can pull the edge log for that proxy and pinpoint whether the 407 carries an error body the health card does not surface. You can also reach us on Discord for a faster async response.