Proxy Server Errors 407, 502, 504 and tunnel failed: Step-by-Step Diagnostics for Beginners

Introduction: What You'll Get From This Guide

If you work with mobile proxies, sooner or later you'll see a line like "407 Proxy Authentication Required," "502 Bad Gateway," "504 Gateway Timeout," or the short and scary "tunnel failed" in your parser logs, in your antidetect browser console, or right in your ad account window. A proxy server error at that moment feels like a black box: you can't tell whether the proxy itself is to blame, your software, the target website, or just an outdated password. This guide turns that black box into a clear action plan.

We're deliberately narrowing the scope: we only cover codes and messages returned by the proxy layer. Connection-level network timeouts (when there's no response at all and the client aborts the wait on its own) are covered separately on the blog, and we won't duplicate them here. If your log shows a specific code or a phrase about a tunnel, you're in the right place.

What You'll Get Out of It

• You'll understand what each of the four errors means and exactly where in the chain "your software — proxy — target website" it's born.
• You'll learn to identify the source of the problem in two or three minutes using curl, the utility built into every system.
• You'll get ready-made action sequences for 407, 502, 504, and tunnel failed that you can follow like a checklist.
• You'll configure your software to react correctly to each code: some errors should be retried, others are pointless to retry.
• You'll build a personal incident log that will save you hours the next time something breaks.

Who This Guide Is For

This guide is written for marketers, media buyers, small team owners, and developers who use mobile proxies but don't have to be network engineers. The main part is aimed at beginners: every command is explained, every action is spelled out. For those who write their own scripts and want to go deeper, there's a separate advanced section at the end.

What You Need to Know Beforehand

It's enough to be able to open a terminal or command line, paste text into it, and read the result. Understanding what an IP address and port are will help, but we'll briefly recap that too. No programming experience is required.

How Much Time It Takes

A full read-through and your first diagnostic session will take 60 to 120 minutes. If you're dealing with a specific error right now, jump to the relevant step: each individual error has 15-25 minutes allocated, including checks.

Preliminary Preparation: Tools and Access

Diagnosing proxy-layer errors doesn't require installing heavy software. Almost everything you need is already on your operating system. Still, it's worth preparing in advance so that when something breaks, you're not hunting for passwords or trying to remember where the config file lives.

Required Tools

1. Terminal or command line. On Windows 10 and 11, open the Start menu, type "cmd" or "PowerShell," and press Enter. On macOS, open "Applications," then "Utilities," then "Terminal." On Linux, the terminal is usually invoked with Ctrl+Alt+T.
2. The curl utility. It's built into Windows starting from version 10 (build 1803), into macOS, and into most Linux distributions. To check: type curl --version in the terminal and press Enter. You should see a line with a version number, like "curl 8.x.x." If instead it says the command isn't found, install curl via your system's package manager.
3. A regular browser with developer tools. Any modern browser will do, as long as pressing F12 opens a panel with a "Network" tab.
4. A text editor for keeping an incident log. Notepad will do, but something with syntax highlighting is more convenient for seeing the structure of logs.
5. Your working software: antidetect browser, parser, ad account manager, or your own script. We'll need access to its proxy settings and its logs.

Required Access

• Login to your proxy provider's dashboard. For mobileproxy.space users, this is the page for managing your channels, where you can see the host, port, login, password, authentication type, and the IP change link.
• Current credentials for at least one proxy: address (host), port, login and password, or a confirmed IP for IP-based authentication.
• An understanding of which protocol you're using: HTTP(S) proxy or SOCKS5. The dashboard will show this too.

System Requirements

Any operating system released in the past eight years. An internet connection that can reach the proxy host. Nothing else is needed.

Backups

Before changing proxy settings in your working software, save the current state. This takes five minutes and saves you from the situation where you "fixed" an error and simultaneously lost a working configuration for ten accounts.

1. In your antidetect browser, export the profile list along with proxy settings. The export function is usually in the profile menu and creates a CSV or JSON file.
2. In your parser or script, copy the config file to a separate folder with the date in the name, like "config_backup_2026-03-14."
3. From the dashboard, copy the credentials for all channels into a text file. Keep this file somewhere outsiders can't access it.
4. Write down your computer's or server's current IP. You'll need it if you're using IP-based authentication.

Tip: create a single text file called "Proxy Log" and record every error there in the format "date, time, code, proxy host, target website, what I did, what helped." In a month, you'll have a personal knowledge base that's more useful than any article.

Check: the terminal opens, the curl command shows a version, you're logged into the dashboard and can see the credentials for at least one proxy, and config backups are in a separate folder. You're ready to move on.

Basic Concepts: How the Proxy Layer Works and Where Codes Come From

To fix a proxy server error meaningfully rather than by trial and error, you need to picture the request path. It has three segments, and each of our four errors lives in its own segment.

The Three Segments of the Request Path

• Client — proxy. Your browser, parser, or script connects to the proxy's host and port. Authentication is checked here. This is where error 407 is born, along with some cases of tunnel failed.
• Proxy — mobile network — target website. The proxy server, having received your request, opens a connection on its own behalf through the modem with the carrier's SIM card to the target website. This is where 502 and 504 arise.
• Target website — return path. The website's response travels back through the same nodes. If the website returned its own code, like 403 or 429, that's no longer a proxy-layer error, and it's important to learn to tell them apart.

Code Classes in Plain Language

A response code is a three-digit number that the server sends as the first line of its response. The first digit tells you the class. Codes 4xx mean "the problem is on your side, fix the request." Codes 5xx mean "the problem is on the server side or beyond it." For the proxy layer, it works like this:

• 407 Proxy Authentication Required — the proxy says: "I don't know who you are, or your data is wrong." Class 4xx: fix it on your end.
• 502 Bad Gateway — the proxy says: "I tried to reach further, but got a broken connection or garbage instead of a response." Class 5xx: the problem is behind the proxy or in the proxy itself.
• 504 Gateway Timeout — the proxy says: "I waited the allotted time for a response from the next node and didn't get one." This is also 5xx.

How Code 504 Differs From a Network Timeout

This is the key distinction for the whole article. When you see code 504, the proxy server is alive, accepted your request, waited for the website's response itself, and told you about the failure itself. The connection between you and the proxy worked perfectly. But when your client says "connection timed out" or "operation timed out" without a code, it means there was no response at all, and your software initiated the disconnect. The first is the subject of this guide. The second is a different topic covered in related blog materials. A simple sign: if there's a three-digit number in the response, keep reading here.

What a Tunnel Is and Why It "Fails"

When you open a website over HTTPS through an HTTP proxy, the browser first sends the proxy a special CONNECT command with the destination address and port. The proxy opens a connection to the website and replies "200 Connection established." After that, an encrypted stream flows through the proxy, which the proxy itself no longer reads. This kind of connection is called a tunnel. If the proxy responds to the CONNECT command with anything other than 200, the client says "tunnel failed" and usually specifies which code came back. So tunnel failed is not a standalone error but a wrapper around one of the codes.

Two Authentication Methods

• Login and password. The client sends them in the Proxy-Authorization header. The most common method, and the most frequent source of 407.
• IP-based authentication. You pre-register your computer's or server's address in the dashboard, and the proxy lets all requests from that address through without a password. Convenient, but breaks when your IP changes.

Service Headers That Reveal Who Answered

The proxy often adds Via, Proxy-Agent, or X-Proxy headers to its responses. Target websites don't set these. If a response with code 502 has a Proxy-Agent header, you know for sure the proxy answered. If there are no such headers but there is a Server header with the website's web server name, that's the website's response. We'll actively use this sign.

Tip: remember the mnemonic rule: "four means look on your end, five means look beyond the proxy, tunnel means check the number next to it." It solves half the cases without further reading.

Step 1: Determine Who Exactly Returned the Error

Goal: in a few minutes, establish exactly whether the proxy server, the target website, or your own software answered you, and capture the full response text for further work.

Instructions

1. Open your dashboard and copy the credentials for the problematic proxy: host, port, login, password. For the example, let's assume the host is proxy.example.net, the port is 8080, the login is user1, and the password is pass1. Substitute your own values.
2. Open the terminal.
3. Type the command, replacing the credentials and target address with your own, and press Enter: curl -v -x http://user1:pass1@proxy.example.net:8080 https://example.com/. The -v flag enables verbose output, the -x flag sets the proxy.
4. Wait for the command to finish. This usually takes one to three seconds. If the command "hangs" for more than 30 seconds, press Ctrl+C: you're most likely dealing with a network timeout, not a code, and that's not our topic.
5. Find the lines in the output that start with a "greater than" symbol (that's what curl sent) and with a "less than" symbol (that's what came back). The first response line will look like "HTTP/1.1 407 Proxy Authentication Required" or "HTTP/1.1 200 Connection established."
6. Look at the line with CONNECT. If a code other than 200 came right after it, the proxy returned the error at the tunnel stage. If CONNECT got a 200 and the error code came later, after the TLS handshake lines, then the target website answered.
7. Find the response headers. The presence of Proxy-Agent, Via, or similar service headers clearly points to the proxy. A Server header with a web server name and a Set-Cookie header point to the target website.
8. Repeat the same command without the -x flag, i.e., directly: curl -v https://example.com/. If the website responds with 200 but through the proxy you get 5xx, the problem is localized beyond the proxy.
9. Repeat the command through the proxy but to a different website, say any stable major resource. If the second website opens, the problem is tied to a specific destination, not to the proxy as a whole.
10. Copy the entire output to your proxy log along with the date and time. You'll need it in the following steps.

Alternative Path via the Browser

If working in the terminal is inconvenient, open a browser configured with the proxy, press F12, go to the "Network" tab, check "Preserve log," and refresh the page. In the request list, find the line with the red code, click it, and on the "Headers" tab examine the "Response Headers" block. The logic is the same: look for proxy service headers. The downside is that the browser often hides the details of the CONNECT stage, so for tunnel failed the terminal is preferable.

Warning: the -v command prints your proxy login and password in plain text. Don't paste this output into public chats, support tickets, or screenshots without replacing the password with asterisks.

Tip: add the -sS flag along with -o and point it to an empty device to avoid cluttering the screen with the response body: curl -sS -v -o /dev/null -x http://user1:pass1@proxy.example.net:8080 https://example.com/. On Windows, use NUL instead of /dev/null.

Expected Result

An entry with the full response has appeared in your log, and you can confidently say one of three things: "the proxy answered at the authentication stage," "the proxy answered at the website-request stage," or "the website itself answered." This directs you to step 2, 3-4, or outside this article entirely.

Possible Problems

• The command says "Could not resolve proxy." A typo in the host. Check it character by character against the dashboard.
• The command says "Failed to connect to proxy." The port is closed or wrong. This is a transport problem, not a code; check the port and try another channel.
• The output stops at the TLS line without a code. That means the tunnel was established but the website didn't respond within your client's time limit. Don't confuse this with 504: there's no code, so it's not our case.

Check: you can name who answered and the exact code or phrase, and the curl output line is saved in your log.

Step 2: Fixing Error 407 Proxy Authentication Required

Goal: get the proxy to respond "200 Connection established" to the CONNECT command instead of 407, and understand the cause so the error doesn't return.

Why 407 Occurs

The proxy didn't accept your credentials. There are usually six causes, and we'll check them in order of increasing complexity: a typo, special characters in the password, your IP changing with address-based authentication, an expired channel, the software not sending the data at all, or cached old data in the browser.

Instructions

1. Open your dashboard and find the problematic channel. Make sure its expiration date hasn't passed and its status is active. If it's expired, renew it and retry the request a minute later; in that case you don't need to go further.
2. Check which authentication type is enabled for the channel: login and password, or IP address. Many panels let you enable both at once.
3. If IP-based authentication is enabled, find your computer's or server's current external address. Open any IP-showing service in a browser without a proxy and compare it with the address recorded in the dashboard. Home ISPs and mobile carriers often change the address after a router reboot. If the addresses differ, update it in the dashboard and wait one or two minutes: changes don't apply instantly.
4. If you're using login and password, copy them from the dashboard fresh, don't retype them by hand. Paste them into the curl command from step 1 and run it. Half the 407 cases end here.
5. Look at the password. If it contains @, :, /, #, ?, %, or space characters, they need to be encoded when passed in the address string. @ becomes %40, colon becomes %3A, hash becomes %23, percent sign becomes %25. For example, the password p@ss:1 is written in a URL as p%40ss%3A1. To avoid encoding, pass the data with a separate flag: curl -v -x proxy.example.net:8080 --proxy-user user1:p@ss:1 https://example.com/. Here curl handles the characters itself.
6. If curl works but your working software still gets 407, the problem is in the software itself. Open its proxy settings. Check that the login and password are entered in separate fields, not glued to the address if the program doesn't expect that. Check for a trailing space in the password: it often appears when copy-pasting.
7. In your antidetect browser, open the settings for a specific profile, not the global settings. Many users change the password in the shared proxy list, but the profile keeps an old copy. Re-save the proxy in the profile and restart the profile.
8. If the browser remembered the old data and won't ask for new, clear saved passwords for that host in the browser settings or create a new profile for testing.
9. Pay attention to the Proxy-Authenticate header in the 407 response. If it says "Basic," the proxy expects a standard login-password pair. If it specifies another scheme, your software must support it; mobile proxies almost always use Basic, and a mismatch means a wrong proxy type setting.
10. Repeat the curl request and make sure CONNECT now returns 200.

Warning: don't try to "solve" 407 with mass request retries. Some proxy servers temporarily block an address after a series of failed authentications, and you'll get an extra problem on top of the original one. One check, one fix, one check.

Tip: if you have dozens of channels, keep them in a table where login and password are in separate columns, with an adjacent column holding the URL-encoded password. That way you'll never mix up which version goes where.

Expected Result

In the curl output, the response line to CONNECT became "HTTP/1.1 200 Connection established," and the website returned content. Requests pass in your working software. The cause is recorded in the log: typo, encoding, IP change, expiration, or cache.

Possible Problems

• Code 407 arrives twice: first on CONNECT, then inside the tunnel. This is a sign that the software sends credentials at only one of the stages. Update the program or enable its option to pass authentication at CONNECT.
• The dashboard says the IP is added, but 407 persists. You're probably working through a corporate network or a server with multiple outbound addresses. Check the address from the exact machine sending the requests.
• It works for you but not for a colleague with the same credentials. With IP-based authentication this is expected: your colleague has a different address. Switch to login and password or add a second IP.

Check: three consecutive requests through curl and through your working software passed without 407, and the cause is recorded in the log.

Step 3: Dealing With Error 502 Bad Gateway From the Proxy

Goal: distinguish a brief hiccup during an IP change from a persistent problem with a destination or channel, and choose the right response for each case.

Why the Proxy Returns 502

The proxy accepted your request, tried to open a connection further, and got a break, refusal, or unreadable response. For mobile proxies, the typical causes are: the modem was switching IP addresses or re-registering with the carrier's network at that moment; the target website dropped the connection; the proxy failed to resolve the website's domain name; the channel is overloaded with too many simultaneous streams; the website is down for everyone.

Instructions

1. Record the exact time the 502 appeared, down to the second. This matters for the next point.
2. Open the IP change history for this channel in the dashboard, or recall whether you have automatic rotation on a schedule. If rotation kicked in during the same seconds as the error, you're dealing with normal behavior: during an address switch, requests get 502 for two to ten seconds. The fix is to retry after a pause.
3. Wait ten seconds and repeat the curl command from step 1. If the response became 200, log "502 during rotation" and move on to setting up retries in step 6.
4. If the 502 keeps repeating steadily, try a different website through the same proxy. If it opens, the problem is with the destination. If it doesn't, the problem is with the channel.
5. For a destination problem: open the target website directly without a proxy. If it's unavailable directly too, or returns 5xx, the proxy isn't to blame: the website is down. If it works directly, the website is probably dropping connections from this carrier's addresses. Change the IP via the link in your dashboard and retry. If that doesn't help, try a channel from a different carrier or region.
6. For a channel problem: check the equipment status in the dashboard. Many providers have a modem status indicator. A red or yellow status means the channel is recovering, and all you can do is wait or switch to a backup.
7. Check the load. Look in your software at how many simultaneous streams are going through this channel. A mobile channel has limited bandwidth, and with dozens of parallel connections the proxy starts rejecting some requests with exactly 502. Halve the concurrency and retest.
8. Check if it's DNS-related. Make a request to the website by IP address instead of domain, if the website allows it, or switch to the socks5h scheme, where names are resolved by the proxy, and compare results. If the name gives 502 but the IP works fine, it's about name resolution on the proxy side; report the exact domain name to your provider.
9. If nothing helped within 15 minutes, collect the curl -v output, the time, the channel host, the target domain, and send it to your provider's support. Properly collected information cuts resolution from a day to an hour.

Tip: when working with scheduled rotation, sync your software's pauses with the IP change interval in advance. If the address changes every 5 minutes, let the parser pause for 15 seconds at the start of each five-minute block. The number of 502s will drop to almost zero without a single line of complex code.

Expected Result

You know exactly which category your 502 falls into: rotation moment, specific destination, channel overload, equipment failure, or website unavailability. For the first three you have a fix; for the last two, an understanding of what to wait for and whom to contact.

Possible Problems

• 502 arrives only on large files. The website is closing the connection due to slow upload speed. Reduce the size of the requested data or use a channel with better coverage.
• 502 comes from the website, not the proxy. Check the headers: if there's the website's Server header and no Proxy-Agent, it's an internal website failure — retry later.
• 502 alternates with 200 for no apparent reason. A classic sign of channel overload. Reduce concurrency until you get a stable result.

Check: ten consecutive requests with a two-second pause through the problematic channel to a stable website return 200, or you have a support ticket in hand with all the data.

Step 4: Working With Code 504 Gateway Timeout

Goal: understand where time is being lost beyond the proxy and reduce the share of 504s to an acceptable level, without confusing the code with a client-side network timeout.

What 504 From the Proxy Actually Means

The proxy server has its own internal time limit for waiting on a response from the website. When the website fails to respond within that limit, the proxy stops waiting and honestly tells you with code 504. Your client didn't drop the connection; a response arrived. That's exactly why your software's timeout should be longer than the proxy's: otherwise you'll see a network timeout without a code and won't be able to understand what's happening.

Instructions

1. Check the timeout in your software. In most programs it's called timeout, "response wait time," or "Read timeout." If it's under 30 seconds, temporarily set it to 60. This is a diagnostic step: you need to wait for the code from the proxy.
2. Measure the time to response through the proxy. Run: curl -sS -o /dev/null -w "%{http_code} %{time_connect} %{time_starttransfer} %{time_total}" -x http://user1:pass1@proxy.example.net:8080 https://example.com/. The -w flag outputs four numbers: the code, time to connect, time to first byte, and total time in seconds.
3. Run the same command without the -x flag. Compare time to first byte. If the website responds directly in 0.4 seconds but through the proxy in 8 seconds, the delay in the "proxy — website" segment is large, and 504 will appear at any fluctuation in the mobile network.
4. Check which request produces the 504. Make a HEAD request, which doesn't download the page body: curl -I -x http://user1:pass1@proxy.example.net:8080 https://example.com/. If HEAD passes but a GET of the page gives 504, the problem is in the page's size or slow generation, not in the connection itself.
5. Change the channel's IP via the link in your dashboard. A mobile network isn't uniform: one address may connect to an overloaded base station, another to a free one. Repeat the measurement. If the time dropped severalfold, add a rule to your software: on 504, change the IP first, then retry the request.
6. Check the weight of the target page. Some sites send a response only after completing long server-side operations. If your goal is specific data, try a lighter address on the same site: an API, a mobile version, a page without sorting parameters.
7. If 504 comes only for a specific domain and only through channels from one carrier, record this in your log and redistribute work on that domain to channels from another carrier.
8. Return the timeout in your software to a working value, but now deliberately: it should be slightly more than the typical response time through the proxy and less than you're willing to wait within the task. For most scenarios, that's 30-45 seconds.

Warning: don't set the timeout in your software to several minutes "just in case" and don't leave it that way forever. One hung stream will occupy a slot in the queue, and a dozen hung streams will create the illusion that the proxy isn't working, when the problem is one slow website.

Tip: add a "time to first byte" column to your software's log. It shows whether a channel is degrading gradually or falling off a cliff. Gradual growth means overload or poor coverage; an abrupt drop more often indicates rotation or a carrier failure.

Expected Result

You know the typical response time through each channel, you've set the software timeout above the proxy's limit, and 504s have become a rare event with an automated response configured.

Possible Problems

• You increased the timeout, and instead of 504 you started getting a network timeout. That means the proxy waits longer than you thought, or the connection to the proxy itself is unstable. This is beyond codes now; see related materials on timeouts.
• 504 only at certain hours. Evening peak load on mobile networks. Move heavy tasks to night or morning.
• 504 on the first request to a new website, then everything is fast. Initial name resolution and connection setup on the proxy side. Add one warm-up request before the main series.

Check: a series of twenty requests to a working website shows time to first byte in a predictable range with no more than one or two 504s, and your software changes IP and retries on 504.

Step 5: Fixing the tunnel failed Error

Goal: learn to read the number next to the phrase tunnel failed, match it to the real cause, and fix protocol, port, and proxy type settings.

What It Looks Like and What It Means

In curl, the message looks like this: "CONNECT tunnel failed, response 407." In browsers and antidetect solutions, it may be "Proxy tunnel failed," "Unable to establish tunnel," or "Tunnel connection failed." One thing is common: the client sent a CONNECT command and the proxy responded with something other than 200. The number next to it is that very code, and working with it comes down to the previous steps plus a few special cases that only appear at the tunnel stage.

Instructions

1. Run curl with the -v flag against an HTTPS address and find the tunnel failed line. Write down the number after the word response.
2. If it's 407, go back to step 2. There's only one difference: make sure the software passes authentication at the CONNECT stage specifically. In older versions of some programs, the "Proxy authentication" checkbox only applies to HTTP requests, and the tunnel goes out without a password.
3. If it's 502 or 504, go back to steps 3 and 4. The proxy couldn't open a connection to the website's port 443 or didn't get a response from it.
4. If it's 403, the proxy refused to open a tunnel to the specified port or host. Check which port you're connecting to. Mobile proxies usually allow tunnels on 443 and a few common ports. If your service listens on a non-standard port, check the dashboard or ask your provider if it's allowed.
5. If it's 400, the proxy didn't understand the command. The most common cause: you specified a SOCKS5 proxy as HTTP, or vice versa. Open your dashboard and see which protocol and port you were given. Many providers use different ports for HTTP and SOCKS5 on the same channel.
6. Fix the scheme in the command. For SOCKS5, use: curl -v -x socks5h://user1:pass1@proxy.example.net:1080 https://example.com/. The letter h in socks5h means that domain names are resolved by the proxy, not your computer. For mobile proxies, this is the preferred option.
7. If you're in an antidetect browser, open the profile's proxy settings and find the type dropdown: HTTP, HTTPS, SOCKS5. Select the one specified in your dashboard and check the port. After saving, restart the profile completely, not just refresh the tab.
8. If there's no number next to tunnel failed, just the phrase, enable verbose logging in your software or reproduce the situation via curl to get the code.
9. Check whether your software is trying to establish a TLS connection with the proxy itself. Some programs, when you select type "HTTPS," encrypt not just traffic to the website but also the connection to the proxy. If the proxy doesn't support this, you'll get tunnel failed or a handshake error. Switch to type "HTTP" for the proxy connection: traffic to the website still stays encrypted inside the tunnel.
10. Repeat the test and make sure CONNECT gets 200 and the page loads.

Tip: make two short test requests part of your daily routine: one to an address over HTTP, the second to the same address over HTTPS. If the first passes but the second fails with tunnel failed, you know in a second that it's about the tunnel, not authentication or the channel.

Expected Result

The phrase tunnel failed has vanished from the logs, the correct type and port are recorded for each channel, and unnecessary proxy connection encryption is disabled in your software.

Possible Problems

• The tunnel establishes but then a certificate error occurs. That's no longer the proxy layer: it's the website or your system's certificate store. Check the date and time on your computer.
• Works in curl but not in the software with the same data. The software applies a different scheme or adds its own prefix. Study its documentation for the proxy string format.
• tunnel failed only for one website. The website uses a non-standard port; go back to the point about 403.

Check: an HTTPS request through curl and through your working software returns 200 on CONNECT, and the type and port for all channels are recorded in your table.

Step 6: Configuring the Right Software Response to Each Code

Goal: make proxy server errors handled automatically: some retried with a pause, others immediately raising the alarm, while you get clear logs instead of a stream of red lines.

The Principle: Not All Errors Are Equal

Retrying a request on 407 is pointless: the password won't become correct from a retry. Retrying on 502 during rotation is essential: in five seconds everything will work. Retrying on 504 is best done after changing IP. These three rules form the basis of healthy error handling.

Instructions for Off-the-Shelf Software

1. Open your parser or account manager settings and find the section responsible for retries. It may be called "Retries," "Retry attempts," or "Error handling."
2. Set the number of retries for 5xx to 3, and the initial pause between them to 5 seconds, doubling each time: 5, 10, 20 seconds. This kind of growing pause is called exponential backoff and prevents your software from overwhelming an overloaded channel.
3. If the software lets you specify a list of codes to retry, list 502 and 504. Don't include 407.
4. Find the action setting for 407. If there isn't one, set the retry count in the general section to a minimum and enable notifications for failed requests. Your goal is to see 407 within the first minutes, not after a day of downtime.
5. Find the field for the IP change link, if there is one. Paste in the link from your dashboard for the corresponding channel and enable the "Change IP on error" or "Rotate on failure" option.
6. Limit the number of simultaneous streams per mobile channel. Start with 3-5 and increase until the share of 502s stays below one percent.
7. Enable verbose logging that saves the response code and headers. Make sure the log shows the difference between a code from the proxy and a code from the website: many programs show this in a separate "Proxy status" column.
8. Save the settings, restart the software, and run a test series of 50 requests.

Instructions for Your Own Script

If you write code, the logic is the same. In pseudocode with Python's requests library it looks like this:

proxies = {"http": "socks5h://user1:pass1@proxy.example.net:1080", "https": "socks5h://user1:pass1@proxy.example.net:1080"} for attempt in range(3): r = session.get(url, proxies=proxies, timeout=45) if r.status_code == 407: alert("auth failed") break if r.status_code in (502, 504): rotate_ip() sleep(5 * 2 ** attempt) continue break

Note three things. First: on 407 we exit the loop immediately and send a notification. Second: on 502 and 504 we first change the IP, then wait a growing pause. Third: the timeout value is chosen so that we wait for a code from the proxy instead of dropping the connection earlier.

Warning: in some libraries, an error at the CONNECT stage doesn't arrive as a response with a code but as an exception whose text contains tunnel failed and the number. Catch such exceptions separately and extract the code from the text, otherwise your retry logic won't work.

Tip: calculate the shares of codes per channel per day and output them in a simple table. A channel whose 5xx is consistently above the others is worth checking first, even if it formally works.

Expected Result

The software automatically retries requests on 502 and 504 with a growing pause and an IP change, immediately reports 407, limits the number of streams, and keeps a log separating proxy and website codes.

Possible Problems

• The software retries 407 too, causing the proxy to temporarily block the address. Disable retries for 4xx entirely or reduce the total retry count to one.
• After enabling rotate-on-error, the IP changes too often. Set a minimum interval between changes, say 60 seconds, so one series of 502s doesn't trigger five rotations in a row.
• The log grows to gigabytes. Write headers only for responses with error codes, and for 200 save a single line.

Check: a test series of 50 requests completed without manual intervention, the log shows retries with pauses of 5, 10, 20 seconds for 5xx, and when you substitute a wrong password the software stopped and displayed a 407 notification.

Verifying the Result: Checklist and Tests

Go through the list and mark each item. If even one isn't done, go back to the corresponding step.

Checklist

• The curl command with the -v flag runs, and you can find the CONNECT response line and proxy service headers in the output.
• For each channel, the table records the host, port, protocol type, authentication method, and encoded password.
• With IP-based authentication, your machine's current address matches the one in the dashboard.
• An HTTPS request through each channel gets a 200 on CONNECT.
• You've measured the typical time to first byte through each channel, and the software's timeout exceeds it with a margin.
• The software is configured to retry only 502 and 504, with pauses of 5, 10, 20 seconds and an IP change before the retry.
• On 407 the software stops and notifies.
• The number of streams per channel is limited, and the share of 5xx in the test series is below one percent.
• The incident log is maintained and contains at least one fully analyzed entry.

How to Test

1. Deliberately enter a wrong password and run one request. Expected: 407 in curl and a notification in the software without a retry series.
2. Restore the correct password and run 30 requests to a stable website with a one-second pause. Expected: all 200s or no more than one 5xx with a successful retry.
3. During the series, click the IP change link in your dashboard. Expected: one or two 502s in the log, then an automatic retry and the series continues.
4. Set the proxy type to SOCKS5 for a channel that was issued as HTTP and make a request. Expected: tunnel failed or a protocol error that you recognize in a second. Restore the correct type.

Success Indicators

The share of proxy-layer errors in working series doesn't exceed one to two percent, every error is classified by code, and none requires manual intervention except 407. Response time to 407 is minutes, not hours.

Common Mistakes and Solutions

Problem: 407 After Every Router Reboot

Cause: IP-based authentication, and your ISP issues a dynamic address.

Solution: switch to login-and-password authentication or enable both at once. If you specifically need IP, ask your ISP for a static address.

Problem: The Password Is Correct, But the Browser Gets 407 While curl Passes

Cause: the browser or antidetect browser profile cached old data.

Solution: re-save the proxy in the specific profile's settings and restart the profile; if needed, clear saved passwords for the proxy host.

Problem: 502 Every N Minutes Exactly

Cause: it coincides with the automatic IP rotation interval.

Solution: sync your software's pauses with the rotation schedule, or switch to changing IP via the link at convenient moments between tasks.

Problem: 502 With Many Streams, All Fine With Few

Cause: mobile channel overload.

Solution: reduce concurrency to 3-5 streams per channel and spread the load across several channels.

Problem: 504 Only on One Website, Others Are Fast

Cause: the website slowly generates the page or restricts mobile carrier addresses.

Solution: use lighter addresses on the website, change IP before retrying, and if the problem persists, move work on that website to a channel from another carrier.

Problem: Instead of 504 You Started Getting a Break Without a Code

Cause: the software's timeout is less than the proxy's internal limit.

Solution: increase the software timeout to a value that lets you receive the code, usually 30-60 seconds.

Problem: tunnel failed, response 400

Cause: a SOCKS5 port is specified as an HTTP proxy or vice versa.

Solution: check the type and port against your dashboard; for SOCKS5 use the socks5h scheme, for HTTP use http.

Problem: tunnel failed, response 403 on a Non-Standard Port

Cause: the proxy doesn't allow tunnels to that port.

Solution: find out the list of allowed ports from your provider and, if possible, reconfigure the target service to port 443.

Problem: Code 502 or 504 Comes With a Server Header From the Website

Cause: this is the website's own response, not the proxy layer: the website is having trouble with its internal services.

Solution: wait and retry later; changing proxies won't help.

Additional Capabilities for Advanced Users

If you've mastered the basic diagnostics, the following techniques will make working with proxy-layer errors almost automatic.

Manually Sending the Authorization Header

Sometimes it's useful to check how the proxy reacts to a specific header. Base64-encode the login:password pair with any local tool and send the header yourself: curl -v -x proxy.example.net:8080 -H "Proxy-Authorization: Basic dXNlcjE6cGFzczE=" http://example.com/. This method works for regular HTTP requests and helps you understand whether the proxy accepts the credentials at all, regardless of how your software builds them. For CONNECT, use the --proxy-header flag instead of -H.

Name Resolution on the Proxy Side

The socks5h scheme and HTTP tunnel pass the domain name to the proxy server instead of resolving it locally. This gives two advantages: the website sees a request coming entirely from the mobile network, and you avoid discrepancies where your local DNS returns one address and the carrier's network another. If you see 502 only with local resolution, switching to socks5h often fixes the problem without contacting your provider.

Automation via the Provider's API

mobileproxy.space has a programmatic interface for changing IP and getting channel status. Build the IP change call into your 504 handler, and channel status checks into your persistent-502 handler. Then the script itself decides whether to retry through the same channel or switch to a backup. A simple algorithm: three 502s in a minute — request status; if the channel is fine, change IP; if not, mark the channel unavailable for five minutes and move to the next one.

Separating Proxy and Website Metrics

Create two separate metrics in your monitoring system: codes that arrived with proxy headers and codes that arrived without them. The first metric speaks to the health of your proxy infrastructure, the second to the behavior of target websites. As long as they're mixed, you'll be hunting for a proxy server error where there is none, and vice versa.

Weighted Channel Pool

Assign each channel a weight that decreases with each 5xx and slowly recovers over time. Distribute requests proportionally to the weights. This approach automatically moves load away from a problematic carrier or region and brings it back when the channel recovers, without a single manual switch.

Exporting HAR From the Browser

For complex cases in an antidetect browser, open the Network tab, reproduce the error, and select "Save all as HAR." The file contains all request and response headers, including stages that aren't visible in the program's regular log. Before sending it to support, remove the Proxy-Authorization values and cookies from the file.

Optimizing Timeouts

Collect time-to-first-byte statistics per channel and destination over a week. Set the software timeout to the 95th percentile plus 10 seconds. Such a timeout rarely cuts off live requests and simultaneously frees up streams quickly during real hangs.

FAQ: Common Diagnostic Questions

How Do I Know Whether the Proxy Returned 502 or the Website Did?

Look at the response headers. If there's a Proxy-Agent, Via, or other proxy service headers and no Set-Cookie and website Server header, the response is from the proxy. Additionally: if the code arrived immediately in response to CONNECT, it's definitely the proxy.

Should I Retry a Request on 407?

No. Credentials won't become correct from a retry, and a series of failed attempts can lead to a temporary block of your address on the proxy side. Fix the data and retry once.

Why Does Everything Work in curl but Not in My Software?

Most often the software builds the proxy string differently, doesn't encode special characters in the password, applies a different protocol type, or doesn't pass authentication on CONNECT. Compare the exact string from the software settings with the working curl command character by character.

How Do I Properly Write a Password With Special Characters?

In the address string, encode: @ as %40, : as %3A, # as %23, % as %25, space as %20. In separate login and password fields, enter the password as is, without encoding.

How Does 504 Differ From the Timeout Covered in Other Articles?

504 is a code the proxy returned itself after waiting out its own time limit for the website. A timeout without a code means your client dropped the connection without receiving anything. They're treated differently, which is why they're covered in separate materials.

How Many Streams Can I Push Through One Mobile Channel?

There's no universal number. Start with 3-5 and increase until the share of 502s stays below one percent. For heavy pages the number will be lower, for lightweight API requests higher.

Should I Change IP on Every Error?

On 504 and persistent 502, yes, that's the first action. On 407, no; changing IP doesn't affect authentication. Set a minimum interval between changes so a series of errors doesn't cause an avalanche of rotations.

What Should I Send to Support to Resolve the Issue Faster?

The full curl -v output with the password replaced by asterisks, the exact time down to the second with time zone, the channel host and port, the target domain, the authentication type, and the result of a direct request without a proxy. With that set, support usually answers in the first message.

Can I Use HTTPS to Connect to the Proxy Itself?

Only if the provider explicitly supports it. In most cases, mobile proxy connections use plain HTTP or SOCKS5, while traffic encryption to the website is provided by the tunnel. Enabling extra encryption to the proxy results in tunnel failed or a handshake error.

Conclusion

You've gone from an incomprehensible red line in the log to a full diagnostic system. Now you can determine who exactly returned the response, read 407 as a signal to check credentials and the authentication method, 502 as a sign of a failure beyond the proxy or during rotation, 504 as an honest proxy report of a slow website, and tunnel failed as a wrapper around one of these codes with a hint in the form of a number. Your software no longer retries pointlessly or gives up on something temporary.

What to Do Next

1. Keep an incident log for at least a month. In just two weeks you'll notice recurring patterns and eliminate their causes.
2. Review the shares of codes per channel once a week and redistribute the load.
3. Automate IP changes and status checks via the provider's API so routine 5xxs are resolved without you.
4. Study the related blog materials on network timeouts and target website behavior to cover the remaining two segments of the request path.

Where to Grow

The next level is building your own pool of channels with weights and monitoring, where a proxy server error becomes not a reason to panic but a point on a graph that the system handles itself. You already have all the tools for that: an understanding of codes, curl, the provider's dashboard, and the habit of writing things down. Good luck with your work and stable 200s.