MoreLogin proxy detection failed

Last checked 2026-09-10

morelogin proxy detection failed

MoreLogin validates a proxy by making a request through it and recording the result as a status. A detection failed result only tells you the request did not come back; it does not say whether the proxy is offline, refusing your credentials, blocking the request type, or being throttled by the provider.

Every check below runs outside MoreLogin on purpose. If a proxy passes curl and still fails detection inside MoreLogin, the problem is in how the proxy was entered. If it fails in both, the browser is not involved at all.

Replace USER, PASS, HOST and PORT with your own values in each command. Keep the single quotes: an ampersand or a hash in a generated password will otherwise be eaten by your shell.

Five-minute checklist

1. Check the credentials work at all

A 200 here means the host, the port, the protocol and the credentials are all fine, and a detection failed status inside MoreLogin is not about reachability.

curl -sS -o /dev/null -w 'http_code=%{http_code}\n' --max-time 15 --proxy 'http://USER:PASS@HOST:PORT' https://example.com

2. Separate "wrong credentials" from "not reachable"

Send the same request with no credentials. A 407 proves the proxy is listening and demanding authentication, so the host and port are right and only the credentials are wrong. A timeout or refused connection means the host or the port is the problem, which points at how the proxy string was entered.

curl -sS -o /dev/null -w 'http_code=%{http_code}\n' --max-time 15 --proxy 'http://HOST:PORT' https://example.com

3. Confirm whether only HTTPS is broken

HTTPS through a proxy needs the CONNECT method. Some upstreams allow plain HTTP and refuse CONNECT, or have the exit port for CONNECT blocked. If this command succeeds while the first one fails, the problem is CONNECT, not the credentials, and switching the protocol dropdown inside MoreLogin will not fix it.

curl -sS -o /dev/null -w 'http_code=%{http_code}\n' --max-time 15 --proxy 'http://USER:PASS@HOST:PORT' http://example.com

4. Confirm the exit IP and rule out IP-based authentication

Some upstreams authenticate by source IP rather than by username and password, so what you need to check against the allowlist is your own machine's direct egress IP, not the address the proxy would show. The empty --proxy value is deliberate: it forces a direct connection so the reported IP is genuinely yours, not the proxy's.

curl -sS --max-time 15 --proxy '' https://api.ipify.org

5. Read the handshake to see which layer stops

The verbose trace shows whether the TCP connection, the proxy authentication exchange, or the TLS handshake is where it stops. That is the difference between a network problem, a credentials problem, and a certificate problem.

curl -sS -v --max-time 15 --proxy 'http://USER:PASS@HOST:PORT' https://example.com 2>&1 | head -n 25

Which side owns the problem

Owner	Cause	What it looks like
The browser	Wrong protocol selected for the proxy	MoreLogin's proxy form offers HTTP, HTTPS and SOCKS5 as separate protocol choices when a proxy is added. An HTTP proxy saved with SOCKS5 selected, or the reverse, will not complete a connection, and the detection result reads the same as a proxy that is simply offline.
The browser	Host or port entered in the wrong field	The proxy form asks for the host and the port as separate fields rather than a single combined string. A port pasted into the host field, or a host that still has the port appended to it, produces a value that cannot be reached, and detection fails before credentials are even checked.
The proxy	Plan exhausted or concurrency limit hit on the upstream	The upstream can still accept the TCP connection and even authenticate, then refuse to forward once the plan's bandwidth, session count, or concurrent-connection limit is hit. From the detection status alone this is indistinguishable from a proxy that is fully down.
The proxy	CONNECT not permitted on the exit	Plain HTTP requests succeed while every HTTPS target fails, because the upstream accepts ordinary requests but refuses the CONNECT method that HTTPS needs. Detection failed then means only the HTTPS path is broken, not the proxy as a whole.
Credential handling	Authentication method mismatch: username and password versus IP allowlist	Some upstreams authenticate by username and password, others by allow-listing your machine's IP address. Entering credentials into a proxy that actually gates by source IP, or the reverse, reports as detection failed even though the string was copied correctly.
Credential handling	The same host:port:user:pass string handed to several people at once	When one proxy string is shared with several people, the upstream sees concurrent sessions from unrelated IPs and may throttle or block the whole string. Inside MoreLogin this looks identical to a broken proxy, and nobody can tell you who else is currently using it, so the same detection failed status keeps coming back.

The same failure in other browsers

Vendor documentation only covers its own product. These are the phrasings the same underlying faults get in the other antidetect browsers.

Browser	How it reads	What differs
adspower	`adspower proxy not working`	Same failure order applies: a pass/fail result cannot say whether the proxy is offline, refusing the credentials, blocking CONNECT, or authenticating fine while a plan limit throttles it. The credential-handling causes are identical because the host:port:user:pass string is the same shape across both tools.
gologin	`gologin proxy not working`	GoLogin surfaces the same protocol and credential mismatches, just inside a different profile form. A proxy that fails there and passes the curl checks above is a configuration issue in that tool, not evidence the proxy itself is bad.
octo-browser	`octo browser failed to get proxy data`	Worded as a data-reading failure rather than a detection status, but the same host/port field-splitting check applies first: a proxy string parsed into the wrong fields produces this same class of failure before any request is even sent.

What this page cannot fix

socks5 upstreams. Our first release only accepts http and https upstream proxies.
An upstream IP that the destination site has already banned. That needs a different exit, and we do not sell IPs.
Bandwidth caps, concurrency limits and throttling applied on the provider side of the upstream proxy.
Anything inside MoreLogin itself, such as how it renders detection status or resolves IP location for a proxy. We do not ship a browser.

If you hand these credentials to other people

Most of the causes above are diagnosable in one command. One is not: when the same host:port:user:pass string is in several hands, you cannot tell who is using which credential, so the same failure keeps coming back and every diagnosis starts from zero.

Proxy Bastion gives each person a separate, revocable, metered link instead of your proxy credentials. They never see the upstream address or password, and you can revoke one without rotating anything.

How it works

Sources

MoreLogin's self-owned proxy form requires choosing a protocol of HTTP, HTTPS or SOCKS5, then filling in the proxy host, port, account and password, and separately lets you pick an IP query channel from IP2location, MaxMind, DB-IP or IP-API to control how the proxy's location is looked up. https://support.morelogin.com/en/articles/10204320-self-owned-proxy-settings (checked 2026-09-10)
MoreLogin's proxy list can be filtered by a Proxy Status field with only two values, Detection Failed and Normal, and supports running detection as a batch action across selected proxies. https://support.morelogin.com/en/articles/10204323-proxy-management (checked 2026-09-10)