If your domain is not yet pointing to the Tomcat site, the issue is usually not with Tomcat itself, but with DNS, the web server mapping, SSL configuration, or the domain setup in Plesk. In a managed hosting environment with My App Server, the domain must resolve correctly first, then the domain has to be linked to the Java application or Tomcat instance, and only after that will the site appear in the browser.
This article explains the most common reasons why a domain still shows an old page, a default hosting page, or an error instead of the Tomcat application. It also shows how to check the domain, DNS, SSL, Apache, and Tomcat service settings in a practical order.
Why the domain may not point to the Tomcat application yet
When a domain does not open the Tomcat site, one of these situations is usually responsible:
- The domain’s DNS records still point to another server or to old hosting.
- The domain is not assigned to the correct subscription or hosting account.
- The Tomcat application is installed, but not mapped to the domain in Plesk.
- Apache is still serving the default document root instead of forwarding to the Java app.
- The Tomcat service is stopped, not listening on the expected port, or not started correctly.
- SSL is configured for the domain, but the certificate does not match the current setup.
- Browser, CDN, or DNS cache is showing an older result.
- The application is deployed, but the context path or port is wrong.
In Java hosting setups, it is common to have both Apache and Tomcat involved. Apache receives the public request on the domain name, and Tomcat serves the Java application behind it. That means the domain must be correctly configured at several layers before the site will respond as expected.
Check whether DNS is already pointing to the hosting account
The first thing to verify is the DNS record for the domain. Even if the Tomcat application is configured properly inside Plesk, the browser will not reach it if the domain still resolves elsewhere.
What to check in DNS
- The A record for the domain should point to the correct server IP.
- The www subdomain should usually point to the same target, either by A record or CNAME.
- There should not be conflicting records that send traffic to another host.
- If you recently changed nameservers, allow time for propagation.
If you manage DNS externally, make sure the domain’s registrar uses the correct nameservers and that the zone file contains the updated record. If DNS is managed in the control panel, confirm that the zone has been edited and saved properly.
Common signs of DNS-related delay include:
- The site works on one network but not another.
- The domain opens a previous site or parked page.
- www works but the root domain does not, or the other way around.
- The browser shows an SSL warning because it reaches a different server.
How long DNS changes can take
DNS changes can appear quickly, but in some cases they may take longer depending on TTL values and resolver caches. If you have recently updated the A record or nameservers, wait long enough for propagation before assuming the Tomcat configuration is broken.
Make sure the domain is assigned to the correct hosting subscription
In Plesk-based hosting, the domain must be attached to the right subscription or hosting account. If the domain is created as an alias, parked domain, or addon domain in the wrong place, it may not load the application you expect.
Check these domain settings
- The domain is added under the correct subscription.
- The document root matches the intended web application structure.
- The domain is not still linked to an old site directory.
- The domain alias is pointing to the correct primary domain.
If you have multiple domains on the same account, it is easy to deploy the Tomcat application correctly but leave the domain pointing to the wrong hosting root. In that case, Plesk will serve the wrong content even though Tomcat is installed and running.
Confirm that My App Server or Tomcat is installed and started
With ITA Java hosting, the application is typically run through My App Server, which provides control over a private JVM and a Tomcat installation inside the hosting account. If the service is not installed or not started, the domain will not reach the Java application.
What to verify in the control panel
- The Java app server instance exists for the subscription.
- The selected Java version is installed and compatible with the application.
- The Tomcat service is running.
- The application has been deployed successfully.
- The context path or root mapping is set correctly.
If you are using a private JVM, also verify that the JVM has been assigned the expected resources and that the service is actually active. A stopped or failed Java process will often result in a blank page, gateway timeout, or 503 error instead of the application.
Typical service-related symptoms
- 502 Bad Gateway if Apache cannot reach Tomcat.
- 503 Service Unavailable if the Java service is down.
- Connection refused if the port is not listening.
- Default hosting page if Apache is serving the document root instead of forwarding to Java.
Check the domain mapping between Apache and Tomcat
In many hosting setups, Apache handles the public domain and forwards requests to Tomcat. If the proxy, handler, or mapping is incorrect, the request never reaches the application.
What can go wrong
- The domain is still mapped to a static website directory.
- The virtual host is not linked to the Java application.
- The proxy rule to Tomcat is missing or broken.
- The application is deployed under a different context path than expected.
For example, the application might be installed under /myapp, but you are testing the root domain. In that case, the site may work only when you open the correct path. If you want the Tomcat app to be shown at the domain root, check whether the service and deployment are configured for the root context.
Recommended checks in Plesk
- Open the domain settings and verify the hosting type.
- Check whether the document root points to the intended app.
- Review the Java application settings in My App Server.
- Confirm that the web server configuration has been updated after changes.
If the hosting platform provides a button for installing ready-made Java or Tomcat versions, make sure you selected the correct version and completed the service activation step. If you uploaded a custom version manually, confirm that all paths, permissions, and startup settings are correct.
Verify SSL certificate and HTTPS redirection
Sometimes the domain appears not to point to the Tomcat site because HTTPS is failing while HTTP still works, or because the certificate does not match the current domain mapping.
SSL issues that can interfere with access
- The certificate was issued for another domain or subdomain.
- www and the root domain are not both covered.
- HTTPS is forced before DNS has fully updated.
- The browser is cached to a previous certificate or redirect.
If you recently changed the server IP, domain alias, or hosting target, reissue or update the SSL certificate after the DNS settings are correct. Otherwise the browser may show a certificate warning that makes it look as if the Tomcat site is unavailable.
Also check whether there is a redirect from HTTP to HTTPS configured at the Apache or application level. If the redirect points to an old host or wrong hostname, the domain may appear broken even though the Tomcat service itself is fine.
Check the browser, cache, and DNS resolver cache
Before making deeper changes, test the site from more than one place. A local cache can make an old site appear even after the hosting setup has been corrected.
Useful tests
- Open the domain in a private or incognito browser window.
- Try a different browser.
- Test from a mobile connection instead of your office network.
- Flush your local DNS cache if needed.
- Check the domain using an online DNS lookup tool.
If the site works only sometimes, the DNS change may still be propagating, or one resolver may still be serving the old IP. If it works everywhere except your own device, the problem is likely local cache rather than hosting.
Check whether the application is deployed correctly
Even when the domain and service are configured correctly, the site may not appear if the WAR file, JSPs, or servlet application was not deployed properly.
Deployment items to review
- The WAR file uploaded successfully.
- The app extracted or deployed without errors.
- Required files are present in the expected directory.
- The application’s start page exists and is reachable.
- Permissions allow the service to read the deployment files.
If the application starts but returns an error page, check logs for deployment problems. A missing file, wrong context path, or invalid configuration can make Tomcat run while the site still appears unavailable.
Check logs for Apache, Tomcat, and application errors
Logs are often the fastest way to understand why the domain is not reaching the Tomcat site. In a managed hosting environment, the relevant logs may include Apache access and error logs, Tomcat service logs, and application-specific logs.
What to look for in logs
- Proxy connection errors between Apache and Tomcat.
- Permission denied messages.
- Port binding errors.
- Java exceptions during startup.
- Deployment failures or missing context errors.
Examples of useful clues include:
- Connection refused when Apache tries to reach Tomcat.
- Address already in use if the port is already occupied.
- Class not found or configuration errors inside the application.
- 404 if the site is deployed but the path is wrong.
If you do not have access to server-level troubleshooting, you can still identify whether the issue is related to DNS, SSL, or application deployment by comparing the error you see in the browser with the current control panel settings.
Practical step-by-step checklist
Use this checklist in order. It helps narrow down the problem quickly without changing too many things at once.
- Confirm the domain resolves to the correct server IP.
- Check that the domain is added to the right hosting subscription.
- Verify that My App Server or Tomcat is installed and started.
- Confirm the correct Java version is selected for the application.
- Check the Tomcat deployment path and context path.
- Review Apache proxy or hosting mapping for the domain.
- Validate the SSL certificate for both root and www hostnames.
- Test the site in a private browser window and from another network.
- Inspect logs for startup, proxy, or deployment errors.
If the site still does not appear after these checks, the configuration may need a review of the service setup or the custom application server parameters.
Special notes for My App Server users
With ITA’s My App Server, the focus is on practical Java hosting inside a shared hosting account, with a private JVM and controlled Tomcat service management. That means you can usually handle common app server tasks from the control panel without needing a separate server.
Good to verify in this setup
- The correct Tomcat version is installed for the app.
- The Java version matches the application requirements.
- The service control shows the app server as running.
- The custom app server configuration has not been overwritten.
- The application is deployed to the expected context.
If you installed a custom application server version, double-check the service usage and any platform limits. A misconfigured custom service may not become available even though the domain and DNS are correct.
Frequently asked questions
Why does the domain open the default page instead of Tomcat?
This usually means Apache is still serving the domain’s document root, or the domain is not mapped to the Java application. Check the hosting assignment and proxy or handler settings in Plesk.
Why does the domain work on HTTP but not on HTTPS?
The SSL certificate may not match the domain, or HTTPS may be redirected incorrectly. Verify the certificate, the redirect rule, and whether DNS has fully propagated.
Why does the Tomcat app work on a subpath but not on the main domain?
The application may be deployed under a context path such as /app instead of the domain root. Review the deployment settings and the app server mapping.
Why do I get a 502 or 503 error?
These errors often indicate that Apache cannot reach Tomcat, or that the Java service is not running properly. Check the service status and the logs.
How can I tell whether it is DNS or Tomcat?
If the domain resolves to the wrong IP, it is a DNS issue. If the domain reaches the server but shows an error page or default content, it is more likely a web server, SSL, or Tomcat mapping issue.
Do I need to wait after changing nameservers or A records?
Yes. DNS changes can take time to propagate depending on the TTL and resolver cache. Test again after some time before changing the application setup.
Conclusion
When a domain is not yet pointing to the Tomcat site, the problem is usually found in one of five places: DNS, domain assignment, Apache mapping, SSL, or Tomcat service status. In a My App Server environment, the fastest way to resolve it is to check the domain resolution first, then confirm that the Java application is installed and running, and finally review the domain-to-app mapping in the control panel.
By following the checklist above, you can usually identify whether the issue is outside the hosting account, inside the Plesk configuration, or inside the Tomcat deployment itself. Once those layers are aligned, the domain should load the Java application normally.