What this symptom usually tells you
Seeing an IP address in the browser after entering the domain is usually an application or server canonicalization problem, not ordinary DNS resolution. A redirect Location header, application base URL or virtual-host rule may be generating absolute URLs with the server address.
Evidence that narrows the cause
Use the live diagnostic to test the exact hostname involved. For this problem, the highest-value evidence is below. Treat each result as one piece of the HTTP routing and redirects diagnosis rather than as a standalone health score.
- Inspect redirect chain — Follow every hop rather than checking only the final page. The conflicting rule is usually visible where the chain changes scheme, hostname or destination repeatedly.
- Inspect canonical — Follow every hop rather than checking only the final page. The conflicting rule is usually visible where the chain changes scheme, hostname or destination repeatedly.
- Check hosting vhost/domain assignment — Verify check hosting vhost/domain assignment from the public Internet and compare it with the value the responsible provider says should be live.
Record the current state before editing
Before changing HTTP routing and redirects settings, save the exact public values for inspect redirect chain, inspect canonical, check hosting vhost/domain assignment and note which hostname or mail path is failing. This creates a rollback point and prevents a later resolver cache, provider dashboard or unrelated working record from being mistaken for the original cause. Change one evidence-backed setting at a time, then compare the same signals again.
Safest repair path
Trace the redirect chain to identify the first hop that introduces the IP. Correct the application/site URL, proxy forwarded-host handling or virtual-host canonical rule at that layer. Keep DNS pointed at the correct server; changing DNS will not fix a server that deliberately redirects to its own IP.
How to confirm this specific repair
Start from both HTTP and HTTPS versions of the domain. Every redirect should preserve or intentionally canonicalize to a hostname, never to the numeric server address. Inspect the page canonical tag as well so search engines are not told that the IP is the preferred URL.
A common wrong turn
Do not add another redirect in front of an unknown existing redirect. Competing web-server, CDN and application rules can turn a simple IP redirect into a loop.
When to escalate with evidence
If these public checks match the provider's current documented configuration but the service still fails, give support the exact hostname, the observed HTTP routing and redirects result, a timestamp, and the failing network or message path. That separates a provider-side incident from a DNS change that has not actually become authoritative.
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.