When a domain is not pointing to a Java site yet, the most common reason is that the DNS records, Apache routing, or proxy settings have not fully taken effect, or they are still pointing to a different web root than the one used by your Java application. In a managed hosting environment with Plesk and a Java hosting extension such as My App Server, the domain must resolve correctly first, and then the web server must forward the right traffic to Tomcat or the private JVM behind the scenes.
If your Java application was installed recently, or if you changed the domain’s nameservers, IP address, document root, or SSL settings, the site may still show a default page, an old website, or an error page until all related settings align. In many cases the issue is not with the Java app itself, but with DNS propagation, Apache virtual host configuration, or the domain binding in the control panel.
What this usually means
A domain “not pointing” to the Java site usually means one of these situations:
- The domain still resolves to the old server or old IP address.
- The DNS A record or CNAME record has not been updated correctly.
- The domain exists in Plesk, but it is not assigned to the Java application.
- Apache is serving the default website instead of forwarding requests to Tomcat.
- The Java site is installed, but the application is bound to another hostname or subdomain.
- SSL is enabled on one hostname, while the browser requests a different one.
- DNS changes are still propagating across the internet.
For Java hosting, the key point is that the browser must first reach the correct server through DNS. After that, the hosting platform must route the request to the Java service. If either step fails, the site will not open as expected.
How Java hosting routing works in Plesk
In a typical Java hosting setup, the domain is handled by Apache and the control panel, while the Java application runs in its own Tomcat instance or private JVM. The hosting platform may use a Plesk extension such as My App Server to connect the domain to the running Java service.
In practice, the flow is:
- The visitor types the domain in the browser.
- DNS resolves the domain to the hosting server IP.
- Apache receives the request for that domain.
- Plesk or the Java extension routes the request to the correct Java application.
- Tomcat or the private JVM serves the JSP, servlet, or WAR content.
If the domain is correctly registered in Plesk but still not opening the Java application, the problem is often in step 2 or 4. If the site opens over the IP address but not over the domain name, DNS or virtual host binding is usually the cause.
First checks to perform
1. Confirm that the domain resolves to the correct IP
Check the DNS A record for the domain and make sure it points to the hosting account’s current IP address. If you use a www hostname, verify that both the root domain and the www subdomain are configured properly.
Common examples:
- example.com should point to the current server IP via an A record.
- www.example.com should usually point to the same destination, either through an A record or a CNAME record.
If the domain was moved from another host, old DNS values may still be cached on your local computer or in your internet provider’s resolver. That can make the site appear to point elsewhere even after you changed it.
2. Verify the domain is added in Plesk
Open the control panel and check that the domain exists as an active site. In Plesk, the domain must be assigned to the correct subscription or hosting account. If the domain is missing, suspended, or attached to the wrong subscription, the Java app will not be reached through that hostname.
Also confirm that the domain name is exactly the one used by the application. A mismatch between example.com, www.example.com, and a test subdomain can cause the routing to fail.
3. Confirm the Java app is started and assigned
If you use My App Server, check whether the Tomcat instance or private JVM is running. A domain can point correctly to the server, but if the Java service is stopped, Apache may show an error, a fallback page, or nothing at all.
Useful things to verify:
- The Java application was installed successfully.
- The selected Java version is available and compatible.
- The service status is running.
- The app is attached to the correct domain or hostname.
- The deploy path or WAR file is correct.
4. Check whether Apache is still serving the old site
If Apache still has an older virtual host configuration, it may continue to serve a previous website or default content. This often happens after a migration, domain alias change, or manual DNS switch.
In a shared hosting setup, the document root and the Java app mapping must match the current domain. If the domain is still connected to an old document root, the browser may not reach the Java application at all.
5. Wait for DNS propagation if you changed records recently
DNS changes do not always apply immediately everywhere. Even if your DNS provider shows the correct record, public resolvers may still cache the old value for a while. This is especially common after switching nameservers, changing the A record, or moving the domain to another server.
Propagation can take from a few minutes to up to 24-48 hours, depending on the TTL and the resolver caches in use. During that time, some users may see the new Java site while others still reach the old destination.
Step-by-step troubleshooting
Step 1: Test the domain from an external network
Open the domain in a browser from a different connection, such as mobile data, or use an online DNS lookup tool. This helps rule out local cache issues on your computer or office network.
If the site works elsewhere but not on your device, clear your browser cache and flush local DNS cache if possible.
Step 2: Check the DNS records in the zone
Look for:
- A record for the root domain
- A record or CNAME for www
- Any conflicting old records
- Incorrect AAAA records if your server does not use IPv6 for that host
Make sure there is no old record still pointing to another host. A common mistake is updating the root domain but forgetting the www hostname, or vice versa.
Step 3: Make sure the domain is the one configured in My App Server
Inside the Java hosting interface, verify which domain the application is bound to. Some setups allow a Tomcat instance to be installed for a specific domain, while others use a subdomain or a separate hostname for the app.
If the domain is wrong, reassign the application to the correct site. In some cases, you may need to redeploy the WAR or adjust the application context so the path matches the expected hostname.
Step 4: Confirm the hosting service is active
Use the service controls to check whether the Java service is running. If the service was stopped, restarted during maintenance, or failed to start due to a configuration issue, the domain may still resolve correctly but the application will not answer.
If the service status shows an error, review the Java version, memory limits, port usage, and deployment files. For small and medium Java applications, a mismatch in JVM version or insufficient memory can prevent the app from starting cleanly.
Step 5: Review SSL settings
If the domain uses HTTPS, verify that the certificate is installed for the correct hostname. A certificate for example.com will not fully cover www.example.com unless it includes that name as well.
Typical SSL-related symptoms include:
- Browser warning that the certificate does not match the hostname.
- Redirect loops between HTTP and HTTPS.
- Site opens on one hostname but not another.
When a Java app is behind Apache, SSL termination often happens at the web server level before requests are passed to Tomcat. That means the certificate, vhost, and redirect rules must all be correct.
Step 6: Check redirects and rewrite rules
Sometimes the domain does point to the server, but a redirect sends the visitor somewhere else. This can happen because of .htaccess rules, Apache configuration, or application-level redirects in the Java app.
Look for:
- Redirects from HTTP to HTTPS that loop endlessly.
- Redirects from the root domain to a different hostname.
- Rules that send traffic to an old path or old application context.
- Application code that forces a canonical domain that no longer matches the current setup.
Step 7: Confirm the correct document root or proxy target
In some Java hosting setups, Apache serves as a reverse proxy in front of Tomcat. In others, the Java service is mapped through a dedicated control panel configuration. If the proxy target is incorrect, Apache may appear healthy while the Java site is unreachable.
Make sure the domain’s document root or proxy mapping points to the current app deployment. If you changed the app context or reinstalled Tomcat, update the mapping accordingly.
Common scenarios and what they mean
The domain shows a default hosting page
This usually means DNS is correct enough to reach the server, but the domain is still assigned to the default website in the control panel. Recheck the domain binding in Plesk and the Java app assignment.
The domain shows an old website
This often indicates cached DNS, a stale virtual host entry, or a leftover document root. Clear caches, verify the domain mapping, and confirm that the old site has been fully removed or detached.
The domain works by IP but not by name
This is usually a DNS problem. The server is reachable, but the domain name does not yet resolve to it correctly. Check A records, nameservers, and propagation.
The domain opens, but the Java app is missing
This suggests that Apache is receiving the request, but the request is not being passed to the Java service. Check the My App Server configuration, the Tomcat service status, and the hostname binding.
HTTPS fails while HTTP works
This points to an SSL configuration issue. Verify the certificate, the domain covered by the certificate, and the redirect rules from HTTP to HTTPS.
DNS records to verify for Java hosting
For most Java hosting setups, the following records are worth checking:
- A record for the root domain — points to the server IP.
- www record — points to the same site, either by A record or CNAME.
- MX records — only if mail is also hosted on the account.
- TXT records — for SPF, DKIM, DMARC, or verification tools.
Even though MX and TXT records do not control the Java site itself, incorrect DNS changes sometimes break mail or verification tools at the same time as the website. That is why it is useful to review the full zone, not only the web records.
When to clear cache and when to wait
Clearing your local browser cache can help if you are seeing an old page that no longer exists. You may also want to clear the DNS cache on your device or router if the domain was moved recently.
However, if the problem is public DNS propagation, local cache clearing will not fully solve it. In that case, wait for the TTL period to expire and verify the records from a public resolver.
A practical rule:
- If only your computer is affected, clear local cache.
- If all users are affected, check DNS and hosting configuration.
- If some users see the site and others do not, suspect propagation.
Best practice for moving a domain to a Java site
When migrating a domain to a Java application, follow a simple order to reduce downtime:
- Prepare the Java app and Tomcat installation.
- Confirm the domain is added in Plesk.
- Assign the domain to the correct application in My App Server.
- Test the app with a temporary URL or internal preview if available.
- Update the DNS A record or nameservers.
- Verify SSL certificate coverage for the exact hostnames used.
- Check Apache routing and redirects after propagation.
This approach is especially helpful for JSP and servlet applications that depend on a stable hostname and clean HTTP-to-app routing.
What not to overlook in Tomcat-based hosting
Tomcat hosting inside a shared hosting account is usually straightforward, but a few details can block domain routing:
- The wrong Java version is selected.
- The Tomcat instance is installed but not started.
- The application context path does not match the domain setup.
- The deployed WAR did not unpack correctly.
- Port or memory limits prevent the service from starting.
- Apache is still serving cached or default content.
These are not enterprise cluster issues; they are the everyday configuration points that affect whether the domain reaches the Java application at all.
FAQ
How long does it take for a domain to point to a new Java site?
It depends on DNS TTL values and resolver caching. In many cases it updates within minutes, but full propagation can take up to 24-48 hours.
Why does the site open on the server IP but not on the domain?
That usually means the server is online, but the domain’s DNS record or virtual host configuration is still incorrect. Check the A record and the domain binding in Plesk.
Can the Java app work before DNS is fully propagated?
Yes, on networks that already resolve the new DNS value. Other users may still reach the old destination until propagation finishes.
Why do I see a certificate warning after switching the domain?
The SSL certificate may not include the exact hostname you are visiting, or the domain may still point to another host. Check both certificate coverage and DNS.
Do I need to restart Tomcat after changing DNS?
No. DNS changes do not require a Tomcat restart. But if you changed the application mapping, Java version, or service settings, a restart may be needed.
What should I check first in Plesk?
Start with the domain assignment, hosting status, DNS zone, and the My App Server service state. Those four checks solve many routing problems.
Summary
If your domain is not pointing to the Java site yet, the issue is usually one of four things: DNS is not updated, the domain is not assigned correctly in Plesk, Apache is still serving another site, or the Java service is not running. In a Java hosting setup with My App Server, the domain must resolve properly and then be mapped to the right Tomcat or private JVM instance.
By checking DNS records, domain binding, SSL coverage, redirects, and service status in order, you can quickly identify where the routing breaks. For most JSP, servlet, and WAR deployments, fixing the hostname mapping is enough to make the site appear as expected once propagation is complete.