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

If your domain is not yet pointing to the Tomcat site in the UK, the cause is usually one of three things: the DNS record is still propagating, the domain is not assigned to the correct hosting subscription in Plesk, or Apache and Tomcat are not yet aligned to serve the application from the expected hostname. In a managed hosting environment with My App Server, the DNS setup and the application deployment must both be correct before the domain will open the Java site.

This article explains how to check whether the issue is DNS, web server configuration, SSL, or the Tomcat application itself, and what to do in each case. It is written for UK hosting customers using Java hosting, Tomcat hosting, JSP hosting, or servlet hosting through Plesk and the My App Server extension.

Why a domain may not point to a Tomcat site yet

When a domain does not open the Tomcat application, the browser is usually reaching one of these states:

The domain still resolves to the old IP address or to no IP address at all.
The correct DNS zone exists, but the A or CNAME record is not set properly.
The domain has not been added to the correct Plesk subscription or hosting space.
The Tomcat service is running, but the application is deployed on a different context path.
Apache is serving the default site instead of forwarding requests to the Java application.
SSL is forcing HTTPS, but the certificate is missing or the host name does not match.
Local DNS cache or browser cache is showing an old result.

In many cases the domain itself is fine, but the web traffic is not yet reaching the intended Tomcat application. For that reason, the troubleshooting should be done in layers: DNS first, then hosting assignment, then Tomcat deployment, and finally SSL and proxy settings.

Check whether DNS is pointing to the correct hosting account

The first step is to confirm that the domain is resolving to the correct server IP address. If the DNS record is wrong, the browser will never reach your Tomcat site, regardless of how well the application is configured.

What to verify in DNS

Make sure the domain has an A record pointing to the correct IPv4 address.
If your setup uses IPv6, confirm the AAAA record is also correct.
If the domain uses a CNAME, confirm it points to the intended hostname and that the target resolves correctly.
Check whether www is configured separately from the root domain.
Make sure there are no conflicting records such as old A records, parked-domain records, or multiple overlapping entries.

Common DNS mistakes

The domain still points to the previous hosting provider.
The root domain points correctly, but www.domain points elsewhere.
The DNS zone was created, but the registrar is still using different nameservers.
The record was edited recently and propagation is still in progress.

If you manage DNS externally, confirm that the nameservers at the registrar are correct. If DNS is managed in Plesk, check the zone editor and ensure the A record matches the hosting server IP assigned to your account.

Allow time for DNS propagation

Even when DNS is configured correctly, the domain may not point to the Tomcat site immediately. DNS changes need time to propagate across resolvers. Some users may see the new destination quickly, while others continue to see the old result until cached data expires.

How long propagation can take

Propagation may take from a few minutes to 24-48 hours depending on the previous TTL values, ISP cache behaviour, and local resolver caching. If you changed nameservers, the delay can be longer than a simple A record update.

What you can do during propagation

Test the domain from a different network or device.
Flush the DNS cache on your computer.
Clear the browser cache or use a private browsing window.
Wait for the TTL period to expire before making additional changes.

If the domain starts working for some users but not for others, propagation is the most likely cause.

Confirm that the domain is assigned in Plesk

For hosted Java applications, DNS alone is not enough. The domain must also be assigned to the correct subscription or hosting configuration in Plesk so the web server knows which site should respond to incoming requests.

Check the domain binding

Open the domain in Plesk and verify it exists under the correct subscription.
Confirm the domain is not only added as an alias if it should be the primary site.
Make sure the document root or application path is set correctly for the site.
Check whether the domain is supposed to open the Tomcat application directly or through a forwarded Apache configuration.

In My App Server setups, the domain may be connected to a Java application that runs inside its own JVM and Tomcat instance. If the domain is assigned to the wrong site, Apache may serve a different application or a default page instead of the intended Tomcat content.

Typical assignment problems

The domain was created, but the hosting plan does not include the Java service.
The application was installed under a different domain or subdomain.
The domain points to the account, but the hosting subscription is missing the required Apache/Tomcat integration.
The application is deployed under a context path such as /app while the user expects it at the root domain.

Check the Tomcat service status

If DNS and domain assignment are correct, the next step is to confirm that the Tomcat service is actually running. A Tomcat site will not respond if the service is stopped, crashed, or still starting after deployment.

What to look for in My App Server

Verify that the Java service is enabled for the subscription.
Check whether the Tomcat instance is started.
Confirm that the selected Java version is available and supported by the deployed application.
Review the service control status for errors or warnings.

My App Server is designed to let you manage your own private JVM and Tomcat instance from Plesk. That makes it easier to deploy WAR files, JSP applications, and servlet-based sites without asking for full server administration. However, the service still depends on a valid runtime, correct configuration, and sufficient account resources.

Symptoms of a stopped or broken Tomcat service

The domain opens a 502, 503, or gateway timeout error.
The site loads a default Apache page instead of the Java application.
The browser shows a blank page or a deployment error.
The application works from one path but not from the main domain.

If the service does not start, review the application logs and service logs in Plesk. A misconfigured Java version, low memory limit, invalid WAR deployment, or a broken startup script can prevent the site from becoming available.

Make sure Apache is forwarding traffic correctly

In many hosting setups, Apache receives the request first and then forwards it to Tomcat. If that link is broken, the domain may resolve correctly but still not show the Java site.

Things to verify in Apache and proxy settings

Check that the domain is configured to pass requests to Tomcat.
Confirm that proxy rules or rewrite rules are not sending traffic to the wrong location.
Make sure there is no leftover static site content in the document root that overrides the Java application.
Check whether the application expects traffic on HTTP only, HTTPS only, or both.

If Apache is serving an old site or a placeholder page, remove conflicting files or adjust the site configuration so the Tomcat application can be reached. In some cases, the web root and the Tomcat context are not aligned, especially after migration or redeployment.

Check the application context path

A very common reason why a domain does not appear to point to the Tomcat site is that the application is actually deployed under a context path rather than at the root of the domain.

Example

If your application is deployed as myapp.war, it may open at:

https://domain.tld/myapp

instead of:

https://domain.tld/

This does not mean the domain is pointing incorrectly. It may simply mean the application URL is different from what you expected.

What to check

The WAR file name and resulting context path.
Whether a root application has been defined.
Whether the Plesk/Apache configuration maps the root domain to the Java app.
Whether an alias or redirect should be added from the root path to the application path.

If you want the Tomcat app to open from the bare domain, confirm the deployment is set up for the root context. Otherwise, update links, redirects, or the application mapping to match the deployed path.

Review SSL certificate and HTTPS settings

If the domain is configured for SSL but the certificate is not ready, the site may appear broken even when DNS is correct. This is especially relevant when you have just added the domain or switched it to a Java application.

SSL checks

Ensure a valid certificate is installed for both the root domain and www if needed.
Check that the certificate hostname matches the site hostname.
Confirm that HTTPS redirects do not send users to a non-existent or wrong URL.
Verify that the application supports the current HTTPS setup in front of Tomcat.

If a browser warns about certificate mismatch, the domain may still be pointing correctly, but the SSL configuration is incomplete. In a hosting environment, the safest approach is to install or renew the certificate after the domain has been properly assigned in Plesk and the application is reachable over HTTP.

Common SSL-related symptoms

Browser warning about insecure connection or certificate name mismatch.
Redirect loop between HTTP and HTTPS.
The site opens on HTTP but fails on HTTPS.
Only one host name works, such as www, while the root domain fails.

Check for redirects, parked domains, or old DNS records

Sometimes the domain appears not to point to the Tomcat site because another redirect or a leftover DNS record is taking precedence.

What to inspect

Domain forwarding rules in the registrar panel.
Redirects configured in Plesk.
Old DNS records that still point to a previous website.
Parking or placeholder settings left active after migration.

When migrating to a Java hosting environment, it is common to forget one old redirect or A record. That can send part of the traffic to the wrong destination while the new Tomcat application remains hidden.

Step-by-step troubleshooting checklist

Use the following checklist to isolate the issue quickly:

Check the current DNS A record for the domain and confirm it points to the correct server IP.
Verify that www and the root domain are both configured as needed.
Confirm the registrar is using the correct nameservers if DNS is managed externally.
Wait for DNS propagation if a recent change was made.
Open the domain in Plesk and confirm it is assigned to the correct subscription.
Check the My App Server service status and ensure Tomcat is running.
Review the deployed application path and context root.
Test the site over HTTP and HTTPS to separate SSL problems from DNS problems.
Inspect Apache proxy or rewrite rules for conflicts.
Look at logs for startup errors, deployment errors, or memory-related issues.

If the domain works by IP address or by a temporary URL but not by the hostname, the problem is usually DNS or virtual host mapping. If the hostname resolves but the Java app does not load, the issue is more likely in Tomcat, Apache, or the application deployment.

How to test whether DNS is the real problem

You can often tell whether the issue is DNS by comparing what happens in different tests.

DNS is likely the issue if:

The domain does not resolve at all in some networks.
The domain opens an old site after you recently changed DNS.
The IP address returned by lookup is not the hosting server IP.
Only some users can see the new site.

Tomcat or hosting configuration is likely the issue if:

The domain resolves correctly but shows an error page.
The site opens Apache default content instead of the application.
The Tomcat service is stopped or not responding.
The application opens only at a subpath, not at the root domain.

Best practice for UK Tomcat hosting setups

For a stable Java hosting configuration in a managed environment, keep the DNS, domain mapping, and application deployment simple and consistent.

Use one clear primary domain for the application.
Set both the root domain and www consistently.
Deploy the application with a clear context path or root mapping.
Keep SSL enabled once the host mapping is stable.
After any migration, verify the site from DNS to browser response in order.

My App Server is particularly useful for small and medium Java deployments where you want direct control over the Tomcat service, Java version, and application deployment inside a shared hosting account. The key is to make sure the domain, web server, and Java runtime all point to the same site.

FAQ

Why does my domain resolve, but the Tomcat site still does not open?

Because DNS resolution and application routing are separate. The domain may point to the server correctly, but Apache, Tomcat, or the application context may still be misconfigured.

How long should I wait after changing the domain to point to the new hosting account?

Most changes are visible quickly, but full DNS propagation can take up to 24-48 hours depending on TTL values and cache behaviour.

Can the domain point correctly but still show a default page?

Yes. That usually means the domain is assigned to the server, but the virtual host or Tomcat mapping is not sending requests to the application.

Why does the site work on /app but not on the root domain?

The application is probably deployed under a context path. You need to configure a root mapping or redirect the root URL to the application path.

Could SSL stop the domain from reaching Tomcat?

SSL usually does not stop DNS resolution, but a missing certificate or incorrect HTTPS redirect can make the site appear unavailable or misconfigured.

What should I check first if I changed DNS today?

Start with the A record, then verify nameservers, then wait for propagation. After that, check the Plesk subscription and Tomcat service status.

Conclusion

If the domain is not pointing to the Tomcat site yet, the problem is usually not in one single place. In a managed hosting setup, the site must be correctly configured in DNS, assigned in Plesk, linked to the right Tomcat service, and exposed through the correct Apache and SSL settings. When you check these layers in order, the root cause is usually easy to find.

For UK Java hosting customers using My App Server, the most reliable approach is to confirm the DNS record, verify the Plesk assignment, ensure Tomcat is running, and check the application context path. Once those pieces match, the domain should open the intended Java site normally.

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