Incogniton proxy status: no connection

Last checked 2026-09-10

incogniton proxy status no connection

Incogniton reports the proxy status by making a test request through it. A "no connection" result means that request did not come back, so the profile will not launch with that proxy attached.

Most of the time the failure is on the proxy side or in how the credentials were entered, not in Incogniton. Work top to bottom; each step has a copy-paste command that reproduces what Incogniton is doing.

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 the status Incogniton reports is not about reachability at all.

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 the ip:port:username:password string itself.

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 no change of connection type inside Incogniton will 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	Connection type set to the wrong protocol	Incogniton's proxy form offers two connection types, HTTPS or SOCKS5. An HTTP/HTTPS proxy saved with SOCKS5 selected - or the reverse - will not connect, and the profile reports the same no connection status as a proxy that is simply offline.
The browser	Proxy string saved without its port	Incogniton expects a proxy as a single ip:port:username:password string, with the port inside the ip:port segment. A paste that drops the port, or splits host and port across the wrong fields, saves as an incomplete proxy that will never connect no matter how correct the credentials are.
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 profile status alone this is indistinguishable from a proxy that is fully down.
The proxy	An IPv6 proxy pointed at a target that only answers over IPv4	An IPv6 proxy only works with the sites and services that themselves support IPv6. The proxy can be genuinely live while a specific destination still times out, which reads as no connection even though the exit itself is healthy.
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 no connection 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 Incogniton this looks identical to a broken proxy, and nobody can tell you who else is currently using it, so the same no connection 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 status 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 ip:port:username:password string is the same shape across both tools.
gologin	`gologin proxy not working`	GoLogin surfaces the same connection-type and credential mismatches, just inside a different profile form. A proxy that fails there and passes the curl checks above is a GoLogin configuration issue, not evidence the proxy itself is bad.
dolphin-anty	`dolphin anty failed to establish proxy connection`	Worded as a connection failure rather than a status label, but the same port-and-format check applies first: Dolphin Anty also parses a single proxy string into fields, and a malformed one produces this same wording.

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 Incogniton itself, such as how it renders proxy status or auto-detects timezone, WebRTC and geolocation values. 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

Incogniton represents a proxy as a single ip:port:username:password string that can be pasted into the ip:port field to auto-populate the rest, the interface offers HTTPS or SOCKS5 as the two connection types, and a Check button verifies the connection before the proxy is saved to the library. https://docs.incogniton.com/proxy-management/integrating-proxies (checked 2026-09-10)
Incogniton's own troubleshooting guidance for a profile that fails to launch lists connection type mismatch (HTTPS vs SOCKS5), a proxy address missing its port in the ip:port field, username/password versus IP-based authentication, and IPv6-only proxies as the most common causes, and recommends manually setting timezone, WebRTC and geolocation when a proxy that works elsewhere still fails inside Incogniton. https://docs.incogniton.com/proxy-management/troubleshooting/proxy-connection-issues (checked 2026-09-10)