Error reference Browser & network

How to fix ERR_NAME_NOT_RESOLVED

ERR_NAME_NOT_RESOLVED is Chrome's way of saying it couldn't turn a hostname into an IP address — the request never left your machine. The cause is DNS: a typo, a dead resolver, a stale cache, or software intercepting lookups. With proxies in the mix, the key question becomes which side resolves the name — your machine or the proxy.

Try clean residential routes All error codes

ERR_NAME_NOT_RESOLVED

What ERR_NAME_NOT_RESOLVED means

Before any TCP connection, the browser must resolve the hostname to an IP address via DNS. ERR_NAME_NOT_RESOLVED means that lookup returned nothing — an NXDOMAIN answer or an outright resolver failure — so no packet was ever sent toward the site. It is not a server error and not a timeout; the target was never contacted.

Typical causes, roughly in order of frequency: a typo or a domain that genuinely doesn't exist (expired registration, wrong TLD), the configured DNS server being down or unreachable, a stale entry in the OS or browser DNS cache, a hosts-file override left over from testing, or VPN, antivirus, and firewall software intercepting DNS traffic and failing silently.

When a proxy is configured, resolution splits in two. Your machine always resolves the proxy's hostname. The target hostname is resolved either locally or by the proxy, depending on protocol: HTTP proxying sends the target as a name, so the proxy resolves it; SOCKS5 goes either way — socks5:// resolves locally, socks5h:// hands the name to the proxy. That split tells you where to look when this error appears.

ERR_NAME_NOT_RESOLVED

How to fix ERR_NAME_NOT_RESOLVED

Start by proving whether DNS works at all on the failing machine, then narrow down which resolver or cache is giving the wrong answer.

Rule out a typo and confirm the domain exists: nslookup example.com 8.8.8.8 queries a public resolver directly. NXDOMAIN there means the domain itself is the problem, not your setup.
If the public resolver answers but a plain nslookup example.com fails, your configured DNS server is broken — switch your network settings to 1.1.1.1 or 8.8.8.8.
Flush caches: ipconfig /flushdns on Windows, resolvectl flush-caches on Linux, and clear Chrome's internal cache at chrome://net-internals/#dns.
Check the hosts file (C:\Windows\System32\drivers\etc\hosts or /etc/hosts) for stale overrides pointing the domain at a dead IP or 127.0.0.1.
Temporarily disable VPN clients, antivirus web protection, and firewall DNS filtering — these commonly intercept port 53 and fail without any visible error.
In Docker or CI, inspect /etc/resolv.conf inside the container; broken container DNS is a top cause of name-resolution failures in scraping stacks.
Using a proxy or PAC file? Verify the proxy hostname itself resolves and the PAC URL loads — a proxy config that can't be resolved surfaces as a name error before anything else happens.
Using SOCKS5? Switch to remote DNS (socks5h:// in curl and most libraries, or Firefox's Proxy DNS when using SOCKS v5 option) so the proxy resolves target names instead of your broken local resolver.

ERR_NAME_NOT_RESOLVED

DNS and proxies: who resolves what

A proxied request involves up to two lookups. Your machine always resolves the proxy endpoint — for ProxyOmega, residential.proxyomega.com — and no proxy setting can offload that one. The target hostname is different: with HTTP proxying and with socks5h://, the name travels to the proxy and is resolved there, from the proxy's network rather than yours.

That has a useful consequence: a correctly configured proxy routes around broken or filtered local DNS for target sites, because your resolver is no longer asked about them. It also has a diagnostic one: if you see ERR_NAME_NOT_RESOLVED while a proxy is configured, the failing lookup is almost always the proxy hostname itself, or a SOCKS mode that resolves locally.

HTTP and HTTPS proxying: the proxy resolves the target

When your client sends requests through an HTTP proxy port, the target hostname travels inside the request and DNS happens on the proxy side. Every ProxyOmega port speaks HTTP, HTTPS, and SOCKS5 on the same port — port 10000 in the examples — so no separate DNS configuration is needed.

SOCKS5: local vs remote resolution

socks5:// asks your machine to resolve the target before connecting; socks5h:// sends the raw hostname so the proxy resolves it. If local DNS is unreliable or filtered, use socks5h and the problem disappears from the target path entirely. In Firefox, the equivalent is enabling Proxy DNS when using SOCKS v5.

The one lookup you can't delegate

residential.proxyomega.com must resolve on your machine. If it doesn't, fix the local resolver — public DNS servers, container resolv.conf — because everything else depends on it. IP whitelist authentication changes how you authenticate, not how names resolve, so it won't route around a DNS failure.

ERR_NAME_NOT_RESOLVED

Verify DNS layer by layer

This sequence proves each stage separately: the local lookup of the proxy endpoint, then a proxied request where the target name is resolved by the proxy — which succeeds even when your local resolver can't see the target site.

# 1. The proxy hostname must resolve locally -- test it explicitly
dig +short residential.proxyomega.com

# 2. HTTP proxying: the target hostname is resolved by the proxy,
#    so this works even if local DNS can't resolve the target
curl -sS -x "http://USERNAME-country-us:[email protected]:10000" \
     https://api.ipify.org

# 3. SOCKS5 with remote DNS (socks5h) on the SAME port -- note the 'h'
curl -sS -x "socks5h://USERNAME-country-us:[email protected]:10000" \
     https://api.ipify.org

FAQ

Frequently asked questions

Is ERR_NAME_NOT_RESOLVED caused by the website being down?

No. The error occurs before any connection is attempted — your machine simply couldn't translate the hostname into an IP address. A site that is down but has valid DNS produces different errors: timeouts, connection refused, or 5xx status codes. If the domain resolves cleanly via nslookup but the page still fails, you are dealing with a different problem.

Why do I get ERR_NAME_NOT_RESOLVED only inside Docker or CI?

Containers carry their own resolver config. If /etc/resolv.conf points at a DNS server the container can't reach — common with VPNs, custom networks, or hardened CI runners — every lookup fails while the host works fine. Set explicit DNS for the container (Docker's --dns flag or daemon.json), or route target lookups through your proxy with socks5h.

Does using a proxy fix DNS errors?

For target hostnames, often yes: with HTTP proxying or socks5h://, the proxy resolves the target from its own network, so a broken or filtered local resolver stops mattering. But the proxy endpoint itself must still resolve locally. If residential.proxyomega.com fails to resolve on your machine, fix local DNS first — nothing else can proceed until it does.

What's the difference between socks5:// and socks5h://?

One letter and one responsibility: socks5:// makes your client resolve the target hostname locally before connecting, while socks5h:// forwards the hostname so the proxy resolves it. Prefer socks5h in scraping stacks — it sidesteps local DNS problems and keeps lookups on the proxy path. ProxyOmega ports accept SOCKS5 alongside HTTP and HTTPS on the same port.

Route around broken DNS Start routing today.

HTTP, HTTPS, and SOCKS5 with proxy-side name resolution on every ProxyOmega port.

Get started