Adeel Imran
Engineering field note4 min read

Website Not Loading on One Computer? Check DNS First

Website not loading on one computer? A real DNS caching fix, plus the debugging approach I use to keep frontend launches moving.

Adeel Imran

Written by

Adeel Imran

I had just deployed Signature, my email signature generator. It worked on other machines. But the website was not loading on one computer: the laptop I had used to deploy it.

I restarted the laptop. Still nothing. It looked like something had gone wrong with the deployment, and redeploying would have been an easy next move.

Instead, I checked where the request was failing. The fix needed no application changes, but it did involve a cache my laptop restart couldn't clear.

Application changes: 0
Redeployments: 0
Result: Normal HTTPS access and a working signature editor
Tools: curl, dig, macOS


Website not loading on one computer? Start with the error

First, I checked the site from the terminal:

curl -I --connect-timeout 10 --max-time 20 \
  https://signature.adeelhere.com/

The result was curl: (6) Could not resolve host: signature.adeelhere.com. The browser showed ERR_NAME_NOT_RESOLVED.

In plain English: my laptop couldn't find an IP address for the website.

The request hadn't reached my application. Changing React components or redeploying wouldn't fix that. The next check was DNS.


Compare your DNS resolver with a public one

DNS translates a hostname into an IP address. I asked my usual resolver, then Cloudflare and Google:

dig signature.adeelhere.com A
dig @1.1.1.1 signature.adeelhere.com A
dig @8.8.8.8 signature.adeelhere.com A

The answers disagreed:

ResolverAnswer
My usual resolverNXDOMAIN: the name doesn't exist
Cloudflare and GoogleNOERROR, with valid address records

The response through my router also included: Result from negative cache for entire name.

That was the clue. DNS caches failures too, not just successful lookups. A resolver can temporarily remember "this name doesn't exist," even after the record becomes available. This is called negative caching.

I couldn't establish when that failed lookup had been cached. But my normal resolver was giving me an outdated answer. Next, I checked whether the server itself was reachable.


Test HTTPS without relying on the failing DNS lookup

Using an IP address returned by the working resolvers, I ran:

curl -I --connect-timeout 10 --max-time 20 \
  --resolve signature.adeelhere.com:443:216.198.79.1 \
  https://signature.adeelhere.com/

It returned HTTP/2 200.

--resolve tells curl which address to use for that hostname and port. It skips the failing DNS lookup while keeping normal TLS certificate verification.

That confirmed the HTTPS endpoint was reachable. It didn't prove every feature worked, but it separated the DNS problem from the deployment.

The address above was valid during my investigation. For your own test, use a current address from a working resolver. Don't hardcode this one as a fix.


What actually fixed it

During the investigation, the negative answer expired. My usual dig query started returning valid addresses, but curl still couldn't resolve the hostname.

I then flushed the local macOS DNS cache:

dscacheutil -flushcache

That was enough in my case. I reran the ordinary curl request, without --resolve, and got 200 OK. The browser loaded the site and the signature editor too.

The order matters: the stale answer from my normal resolver had already expired before I cleared the local cache.

A laptop restart can't clear a cache on another device or an upstream resolver. Neither can a local cache flush.

No code changes. No redeployment. Just fixing the layer that was actually failing.


Quick DNS troubleshooting FAQ

Why does a website work on other devices but not mine?

Devices can use different DNS resolvers and cached answers. DNS was the cause here, but this symptom alone doesn't prove it. Start with the actual error.

Should I redeploy when I see ERR_NAME_NOT_RESOLVED?

Check DNS first. That error points to hostname resolution, not an application response.

Does curl --resolve fix the browser too?

No. It overrides resolution for that curl request. Verify normal browser access separately afterward.


What this means for a fixed-price frontend project

This wasn't a React or Next.js bug. But it was a launch blocker.

That's why I don't treat frontend delivery as finished when the UI looks right on my machine. The work includes checking the deployed result and separating application bugs from issues around them.

For a founder, the distinction matters: a wrong diagnosis can turn a small blocker into unnecessary development work.

I take on fixed-price React and Next.js projects with defined deliverables, such as:

  • A Next.js marketing site: responsive pages, technical SEO foundations, and deployment checks.
  • A React product interface: a dashboard, onboarding flow, or feature connected to your existing API.
  • A focused improvement to an existing app: a specific UI rebuild, performance issue, or launch blocker.

We agree on the scope, timeline, price, and acceptance checks before implementation. If the problem is still unclear, we scope the investigation first rather than guessing at a quote.

Bring your designs or existing URL, the outcome you need, and your target deadline.

Need a React or Next.js project taken from scope to launch? I help SaaS teams build and ship frontend features through clearly scoped, fixed-price projects. Book a consultation to discuss your project.

Work together

Need a senior React and JavaScript partner to move faster?

Book a session