HHostWithSheryWebsite & Domain Troubleshooting ToolsCheck a domain
Menu
Exact error diagnosisReviewed 2026-08-13By HostWithShery technical editorial

NSURLErrorCannotFindHost (-1003)

Apple networking could not resolve the hostname in the requested URL. The failure occurs before an HTTP response can be received, so start with the exact hostname and its DNS path.

Start with evidence from your own domain before changing DNS, SSL or mail settings.
Check your own configuration

DNS Lookup

This page is preconfigured with the DNS Lookup that best matches this problem.

No accountPublic evidence only
Live public check

Returns public A, AAAA, CNAME, MX, TXT, NS, SOA and CAA data.

No account · Public configuration only
On this page

What this error means

Apple networking could not resolve the hostname in the requested URL. The failure occurs before an HTTP response can be received, so start with the exact hostname and its DNS path. The browser or proxy message describes the symptom, not necessarily the root cause. HostWithShery therefore checks the DNS resolution and delegation evidence that can be observed publicly before recommending a configuration change.

Most likely causes

These are the first explanations to test because each can produce this exact symptom. Treat them as hypotheses until the matching public evidence is present.

  • Hostname is misspelled or does not exist — Verify hostname is misspelled or does not exist from the public Internet and compare it with the value the responsible provider says should be live.
  • A/AAAA/CNAME is missing for the requested host — Compare IPv4 and IPv6 separately. A healthy A record can hide a broken AAAA path that affects only visitors whose network prefers IPv6.
  • Delegation or resolver path is failing — Compare independent resolvers or regional probes together with TTL. Different answers are evidence of cache/authority differences, not a reason to claim a fixed global propagation time.
  • The app is constructing the wrong host — Verify the app is constructing the wrong host from the public Internet and compare it with the value the responsible provider says should be live.

What to check on your domain

Use the embedded scan to compare the failing layer with adjacent layers that can produce the same visible error. This prevents a DNS change from being used to “fix” a TLS problem, or an SSL-mode change from masking an origin failure.

  • Hostname is misspelled or does not exist — Verify hostname is misspelled or does not exist from the public Internet and compare it with the value the responsible provider says should be live.
  • A/AAAA/CNAME is missing for the requested host — Compare IPv4 and IPv6 separately. A healthy A record can hide a broken AAAA path that affects only visitors whose network prefers IPv6.
  • Delegation or resolver path is failing — Compare independent resolvers or regional probes together with TTL. Different answers are evidence of cache/authority differences, not a reason to claim a fixed global propagation time.
  • The app is constructing the wrong host — Verify the app is constructing the wrong host from the public Internet and compare it with the value the responsible provider says should be live.
  • Copy the exact host from the failing request — Verify copy the exact host from the failing request from the public Internet and compare it with the value the responsible provider says should be live.

Fixes in the recommended order

Change the smallest confirmed layer first. Preserve working DNS and mail records, document the current value, apply one repair, and then retest before moving to the next possibility.

  • 1. Copy the exact host from the failing request. Confirm the public result after this step before making another unrelated change.
  • 2. Check public DNS for that hostname. Confirm the public result after this step before making another unrelated change.
  • 3. Compare authoritative nameservers with resolver answers. Confirm the public result after this step before making another unrelated change.
  • 4. Fix the app URL only if DNS is healthy for the intended host. Confirm the public result after this step before making another unrelated change.

How to confirm the repair

Authoritative DNS should publish the intended record and independent resolvers should converge on that answer as their previous cached TTLs expire.

If the error remains

Capture the checked hostname, exact timestamp, final DNS addresses, redirect/TLS result and the failing public status before escalating. That evidence gives a hosting or provider support team something testable instead of only the browser message. If results differ by resolver or network, include those differences rather than assuming the failure is universal.

What not to change

Do not replace nameservers, delete unrelated mail records, disable security controls, remove IPv6 blindly or purge the entire configuration merely because this message appears. Diagnose the failing layer first; broad changes can turn one isolated fault into several independent faults.

Technical references

These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.