Why is the domain not pointing to the Java site yet in the UK

If your domain is still not pointing to the Java site, the cause is usually not the Java application itself but a DNS or web server configuration issue. In a hosting environment with Plesk and My App Server, the domain must first resolve to the correct hosting account and then be mapped to the Apache Tomcat application endpoint. If either step is incomplete, visitors may see an old website, a parked page, a generic placeholder, or a DNS error instead of your Java app.

In practice, this means checking three layers: the domain’s DNS records, the hosting subscription and document root, and the Tomcat or Java service setup in Plesk. This is especially important when you have just changed nameservers, switched hosting providers, added a new domain, or deployed a WAR application for the first time.

Why the domain may not be pointing to the Java site

There are several common reasons why a domain does not reach the Java site yet:

DNS has not fully propagated after a nameserver or record change.
The A record or CNAME is pointing to the wrong destination.
The domain is not assigned to the hosting subscription in Plesk.
The Apache virtual host is still serving a default site instead of the Java app.
My App Server or Tomcat is not running, or the application was not deployed correctly.
SSL is configured for the domain but the hostname mapping is incomplete.
Cloudflare or another proxy is caching old DNS data.
The application is on a non-root path, but the domain is expected to open the app directly.

For Java hosting, a domain can resolve correctly and still not show the application if the web server, proxy, or Tomcat route is not linked to the app properly. That is why you should check DNS and hosting configuration together.

Check whether DNS is already correct

The first step is to verify that the domain resolves to the correct hosting platform. If the domain still points elsewhere, the Java site cannot load no matter how correctly the app is deployed.

What to verify in DNS

Nameservers are set to the correct provider, if you manage DNS at the registrar.
A record for the main domain points to the correct IP address.
www record points to the same destination, usually via A record or CNAME.
AAAA record does not point to an old IPv6 destination if your hosting does not use it.
TXT records for verification or mail are not conflicting with site routing.

If you recently changed DNS, keep in mind that propagation can take time. Some users may already see the new target, while others still reach the old one depending on local cache and resolver TTL values.

Useful checks from a control panel perspective

In Plesk, confirm that the domain is created under the correct subscription and that the domain name matches the site you want to serve. If the domain is not added as a web domain, alias, or relevant host entry, the server may not know where to send requests for that hostname.

If you use the My App Server extension, make sure the domain or subdomain is linked to the Java application and not only to a static web root. A working Tomcat instance still needs the correct virtual host mapping.

Check domain assignment in Plesk

When a domain is registered in DNS but still does not show the Java site, the issue is often inside the hosting account. In a managed hosting setup, the domain must be associated with the correct subscription and service configuration.

Things to confirm in the hosting account

The domain exists in the subscription used for the Java site.
The correct document root or application path is assigned.
The site is not still mapped to a default index file such as a placeholder HTML page.
The domain alias, if used, points to the same hosting target.
There is no conflicting redirect from HTTP to another hostname.

If you deployed a WAR file or JSP application, confirm that the application is installed in the expected location and that it is assigned to the domain you are testing. A common mistake is deploying the app correctly but browsing the naked domain while the app listens on a different path or hostname.

Verify My App Server and Tomcat status

In ITA’s Java hosting setup, My App Server allows you to manage Apache Tomcat and a private JVM through Plesk. If the service is stopped, the domain may still resolve but nothing useful will respond behind it.

What to check in the service controls

The Java service is started.
The selected Tomcat version is installed and active.
The JVM version matches the application requirements.
The application is deployed and not failing on startup.
Logs do not show port conflicts, memory issues, or deployment errors.

If the service was just restarted, wait a short time before testing again. Some Java applications need a few moments to finish startup, especially after a clean deploy or configuration change.

For service-based hosting, the domain usually becomes useful only after Tomcat is up and the app context is loaded. If the app is configured to run behind Apache, then Apache must also proxy or route the request to the right backend.

Check whether Apache is serving the correct site

In many hosting environments, Apache sits in front of Tomcat. That means the domain request first reaches Apache, and Apache then forwards the request to the Java app. If Apache is still serving the old page, the domain will not reach the Java site even if Tomcat is healthy.

Common Apache-side problems

The virtual host still points to an old document root.
A default index file is taking priority over the application route.
Rewrite rules send traffic elsewhere.
The proxy configuration to Tomcat is missing or incomplete.
SSL virtual host settings are different from the HTTP configuration.

When testing, try both the plain domain and the secure version with HTTPS. If one works and the other does not, the issue may be in the SSL virtual host rather than DNS.

SSL can make the domain look like it is not pointing correctly

Many users assume a domain problem is always DNS-related, but SSL can create the same impression. If the certificate is issued for the wrong hostname, the browser may warn that the site is unsafe or may not load it as expected.

SSL checks to perform

The certificate includes the exact domain name you are visiting.
The certificate also covers www if that hostname is used.
HTTP to HTTPS redirects go to the correct domain.
No old certificate is still bound to the site.
The domain’s SSL configuration matches the current hosting setup.

If you use a Java application with a separate Tomcat backend, make sure the SSL termination happens on the correct frontend layer. An SSL certificate installed in Plesk does not automatically fix a wrong domain mapping inside the application configuration.

Check whether the application is deployed to the correct context path

Sometimes the domain does point to the hosting account, but the Java application is deployed under a context path such as /app instead of the root path. In that case, opening the bare domain will not show the expected app unless there is a redirect or alias configured.

Typical deployment scenarios

Root deployment: the domain opens the app directly at /.
Context deployment: the app opens at /app or another path.
Subdomain deployment: the app is attached to app.example.com.
Alias-based access: multiple hostnames reach the same app.

If you expected the domain to open the app directly, check whether the application was deployed as the root application or whether an index page is still present in the document root. A leftover static file can hide the Java site even though the backend is working.

Review DNS cache and propagation delays

After changing records, the domain may appear to be incorrect simply because a resolver is still caching old data. This is common after:

nameserver changes at the registrar;
switching A records to a new IP;
changing www from A record to CNAME;
removing old IPv6 or proxy records;
moving a domain between hosting accounts.

To reduce confusion, test the site from different networks and devices. If the domain works on one connection but not another, it is likely a DNS cache issue rather than a server failure.

If you use a DNS proxy service, clear or pause the proxy temporarily while verifying the domain target. A proxy can hide the current origin and make troubleshooting harder.

How to troubleshoot step by step

Use the following sequence to isolate the problem quickly:

Confirm the domain’s A record or CNAME points to the correct hosting destination.
Check that the domain is added to the right Plesk subscription.
Verify that My App Server and Tomcat are running.
Open the site both with HTTP and HTTPS.
Check whether the Java app is deployed at the root or under a context path.
Review Apache or proxy settings for hostname routing.
Look for an old index file or redirect rule that overrides the app.
Test again from another network after DNS propagation has had time to complete.

If the domain still shows the wrong page

If the domain resolves to the hosting account but you still see the wrong content, the most likely causes are a misassigned virtual host, a wrong document root, or a conflicting application deployment. In a Java hosting environment, also check whether the application was uploaded successfully and whether Tomcat logged any startup errors.

Examples of common scenarios

Example 1: Domain was just moved from another provider

The A record was updated, but some visitors still see the old site. In this case, wait for DNS propagation and verify that the previous host no longer serves cached content. Also confirm that the domain exists in the correct Plesk subscription and that Tomcat is active on the new platform.

Example 2: Domain opens a placeholder page

This usually means Apache is serving a default document root instead of the Java application. Check for an old index.html or verify that the app is deployed as the active web root. If the app is meant to run from Tomcat, confirm the Plesk mapping through My App Server.

Example 3: HTTPS does not work but HTTP does

This often points to SSL binding or certificate mismatch. Ensure the certificate includes the exact hostname and that the secure virtual host uses the same domain assignment as the non-secure one.

Example 4: www works but the naked domain does not

This means the DNS or host mapping is incomplete for one hostname. Add or fix the apex A record, or configure the root domain to redirect to the working hostname consistently.

Best practice for Java sites on hosted platforms

For a stable setup, keep DNS, Plesk, Apache, and Tomcat aligned. The domain should resolve to the hosting account, the account should serve the correct vhost, and the vhost should forward the request to the active Java application. That way, a WAR, JSP, or servlet app loads predictably without relying on manual workarounds.

Use one clear primary hostname.
Keep www and non-www consistent.
Remove old placeholder files after deployment.
Check service status after every Java or Tomcat update.
Review SSL settings whenever the domain name changes.

When to contact support

Contact hosting support if you have already confirmed DNS, domain assignment, and Tomcat status, but the domain still does not point to the Java site. It helps to include:

the domain name;
the exact symptom you see;
whether HTTP or HTTPS behaves differently;
the DNS records you changed;
the Tomcat or application version in use;
any error messages from Plesk or the browser.

With that information, support can check whether the issue is in DNS, Apache routing, SSL binding, or application deployment.

FAQ

How long does it take for a domain to point to a Java site?

It depends on DNS propagation and caching. In some cases it changes quickly, while in others it can take longer before all resolvers and devices see the new target.

Can a domain be pointed correctly in DNS but still not show the Java app?

Yes. The DNS can be correct while Plesk, Apache, Tomcat, or the application context path is still misconfigured.

Do I need to restart Tomcat after changing the domain?

Not always, but if the app depends on hostname-specific routing or updated configuration, a restart or redeploy may be necessary.

Why does the browser show a certificate warning?

The SSL certificate may not match the hostname, or the secure virtual host may still be bound to an old domain configuration.

What if the Java app works on a subdomain but not on the main domain?

That usually means the main domain is not assigned to the same web root or application mapping. Check the Plesk domain setup and the Apache or proxy configuration.

Conclusion

If your domain is not pointing to the Java site yet, focus on the full path from DNS to the Java service. Confirm the record resolves correctly, verify the domain is assigned in Plesk, check that My App Server and Tomcat are running, and make sure Apache or SSL settings are not serving a different site. In most cases, the issue is a configuration mismatch rather than a problem with the Java application itself.

Once DNS, virtual host mapping, and Tomcat deployment are aligned, the domain should serve the Java site normally through the hosting platform.

Why is the domain not pointing to the Java site yet in the UK?