If your Java website is showing the wrong path, an unexpected URL, or a 404 error in the UK, the problem is usually related to the web server mapping, the Tomcat application path, the domain configuration in Plesk, or the way the app is deployed inside My App Server. In many cases, the application itself is fine, but the request is reaching the wrong context path or the wrong document root.
This is especially common when hosting Java apps through a managed hosting panel such as Plesk with a private JVM or Apache Tomcat instance. A small change in deployment path, application name, proxy settings, or domain aliases can make a Java site look broken even though the service is running.
Why a Java website can show the wrong path or 404
A Java application does not always behave like a standard static website. With Tomcat-based hosting, the URL path is often tied to the deployed application name, context root, and reverse proxy configuration. If any of these do not match, visitors may see a 404 page, a wrong subfolder, or a route that works on one path but not another.
The most common causes are:
- the application is deployed under a different context path than expected;
- the domain in Plesk points to the wrong directory or service;
- Apache is serving the request instead of Tomcat, or vice versa;
- the WAR file name changed and created a new context path;
- the application expects a base URL that is not configured correctly;
- rewrite rules or proxy rules are missing;
- the app uses absolute links pointing to an old path;
- the service is running, but the deployed app is not loaded correctly.
Check whether the issue is in the application or in hosting
Before changing anything, confirm whether the error appears for all visitors or only for certain pages. If the homepage works but a specific page returns 404, the issue is often inside the application routing. If the whole site opens at the wrong path, the cause is more likely in the hosting setup.
Quick checks
- Open the site in a private browser window.
- Test the root domain and the exact path that fails.
- Check whether the site works on the application’s own Tomcat URL if one is available.
- Compare the deployed app name with the URL path shown in the browser.
- Review recent changes such as redeployments, service restarts, or domain edits.
If the application works on the service URL but not on the domain, the issue is usually with the domain mapping or proxy configuration. If it fails everywhere, the app itself may be missing files, not starting properly, or using the wrong context root.
Context path problems in Tomcat hosting
One of the most frequent reasons for a Java website showing the wrong path is the Tomcat context path. In Tomcat, the URL path is commonly derived from the WAR file name or the application context configuration.
For example:
- myapp.war may deploy as /myapp
- ROOT.war may deploy at the site root /
- a custom context can point to /shop, /app, or any other path
If you expected the site to open at https://example.co.uk/ but the app is actually deployed at https://example.co.uk/myapp, users may see a 404 when they visit the root domain. The opposite can also happen: the app may require a subpath, but the browser is sent to the root.
How to fix context path issues
- Check the deployed WAR or application folder name.
- Confirm the context path configured in My App Server or Tomcat.
- If the site should open at the domain root, deploy the app as ROOT where appropriate.
- Remove old deployments that may still be accessible under a previous path.
- Restart the Java service after changing deployment settings.
If you are using the My App Server extension in Plesk, review the service and deployment details to make sure the selected app server matches the domain and the intended URL structure.
Domain mapping and document root in Plesk
In a managed hosting environment, a domain must be linked to the correct hosting subscription, website directory, and Java service. If the domain points to a standard web root while the Java app is deployed in Tomcat, the browser may receive a 404 from Apache because it is looking in the wrong place.
This is common when a domain is added, moved, or cloned and the web root changes. It can also happen when the site is supposed to be proxied to Tomcat but the proxy setup is incomplete.
What to verify in Plesk
- the domain is assigned to the correct subscription;
- the hosting type supports the Java service you installed;
- the document root matches the intended site structure;
- the domain is connected to the correct Apache/Tomcat setup;
- the active service is the one created through My App Server.
If the site recently moved to a different domain or alias, double-check the domain configuration and any redirect rules. A wrong alias can send traffic to an old path or a disabled deployment.
Apache and Tomcat are not serving the same path
Java hosting often uses Apache as the public front end and Tomcat as the application engine. In this setup, Apache receives the request first and may forward it to Tomcat. If the forwarding rules are missing or incorrect, Apache can respond with a 404 before Tomcat ever sees the request.
This can happen when:
- the proxy rule to the Tomcat service is missing;
- the virtual host points to the wrong backend;
- the app is running on Tomcat but Apache still serves the domain as a static site;
- rewrite rules are not passing the requested path correctly.
What to check
- Confirm that the Apache virtual host is linked to the Java app service.
- Check whether the request is expected to go through a reverse proxy.
- Review any rewrite rules that might strip or duplicate the path.
- Restart Apache and the Java service after changes.
If the application uses clean URLs, make sure the routing rules are still valid after deployment. A path that worked under one context may fail after the app was renamed or redeployed.
Why the site shows the wrong folder or subpath
Sometimes the issue is not a full 404, but the site opens under an unexpected folder path. For example, a visitor may reach /app instead of the root domain, or links inside the app may point to a different directory. This usually means the application was built with a base path that no longer matches the actual deployment.
Typical causes
- hardcoded base URLs in the application;
- incorrect base href settings in the front-end part of the app;
- old redirects left behind after a migration;
- the app was deployed under a different WAR name;
- session or login redirects point to a stale path.
In Java applications, especially JSP and servlet apps, links can be built dynamically from the current context path. If that logic is wrong, the browser may be sent to a non-existing path and show a 404.
Step-by-step troubleshooting for Java 404 errors
Use the following approach to identify the cause quickly.
1. Confirm the application is running
Open the service control page in Plesk and check the Java service status. If the private JVM or Tomcat instance is stopped, the app will not respond properly.
2. Check the deployment name
Look at the WAR file name or deployed application folder. The context path often follows that name. If you changed the file name during upload, the URL path may also have changed.
3. Test the root path and application path
Try both the domain root and the expected application subpath. If one works and the other fails, the app is probably deployed under a different context than expected.
4. Review proxy and rewrite rules
Make sure Apache is forwarding requests to the correct Tomcat backend. Incorrect rewrites can produce 404 responses or loop back to the wrong location.
5. Check application logs
Review the Tomcat and application logs for deployment errors, missing files, or startup exceptions. A failed deployment can leave the service online but the application unavailable.
6. Verify file permissions and paths
If the app cannot read resources, JSP files, or configuration files, it may return errors that look like a path problem. Check that the files are present and readable by the service user.
7. Restart the Java service
After any deployment or configuration change, restart the My App Server instance or Tomcat service. Some path changes are not picked up until the service reloads.
Common reasons after a redeploy
Many path-related 404 errors appear right after a redeployment. This is because the new package may not match the old path, or leftover files from a previous version can confuse the routing.
- The app was uploaded with a different WAR name.
- The previous deployment was not removed.
- The context root changed during publishing.
- Static assets still point to the old directory.
- The cache in the browser or proxy still shows the old route.
When redeploying, try to keep the same application name if you want the same URL path. If a new path is intended, update all links, redirects, and bookmarks accordingly.
When the browser cache makes the problem look worse
Sometimes the hosting is correct, but the browser keeps requesting an old route or displaying an outdated redirect. This can happen after a migration, path change, or rewrite update.
Try this before changing the server again
- clear the browser cache;
- test in incognito/private mode;
- clear cached redirects in the browser;
- check from another device or network;
- verify the issue with the direct application URL.
If the site works elsewhere, the problem may be client-side caching rather than the hosting setup.
How My App Server helps with Java path management
With My App Server in Plesk, you can manage a private JVM or Apache Tomcat instance directly from the hosting panel. This is useful for Java, JSP, and servlet applications because the service, version, and deployment path are easier to control from one place.
In practical terms, this means you can:
- install a ready-made Java/Tomcat version with one click;
- use a custom app server if your app needs a different setup;
- control the service from the panel;
- choose the Java version that matches your application;
- deploy WAR-based apps without managing a separate server manually;
- keep the JVM isolated within the hosting account.
If a site is showing the wrong path, this control is helpful because you can check whether the app is actually deployed under the intended service and context. A mismatch is easier to spot when the application server is visible inside the hosting panel.
Examples of real-world fixes
Example 1: Root domain shows 404, but /app works
This usually means the Java application is deployed under /app and not at the domain root. Rename the deployment to ROOT if the app should open at /, or update the domain links to use the correct subpath.
Example 2: Old path still works, new path returns 404
The old context may still be active, or the new deployment may not have loaded. Remove stale deployments, confirm the new WAR name, and restart the service.
Example 3: Apache serves a 404, Tomcat app is running
This usually points to a proxy or virtual host mismatch. Check that the domain is connected to the correct Java backend and that the request is forwarded to Tomcat.
Example 4: Login redirects to a wrong folder
This is often caused by hardcoded redirects, incorrect base URLs, or a missing context path variable. Review application configuration and test after clearing the browser cache.
What to send to support if the issue continues
If you still cannot find the cause, provide the following details when contacting hosting support:
- the domain name;
- the exact URL that returns the 404;
- the expected correct path;
- the deployed WAR or app name;
- the Java version and Tomcat version used;
- any recent changes made in Plesk or My App Server;
- relevant log excerpts from the application or service.
These details help isolate whether the issue is in Apache, Tomcat, the deployment path, or the application code.
FAQ
Why does my Java site work on one URL but not another?
Because the app is likely deployed under a specific context path. One URL matches that path, while the other does not. Check the WAR name, context root, and domain mapping.
Can a 404 mean Tomcat is down?
Yes, but not always. A 404 can also mean Tomcat is running while Apache, the proxy, or the app path is misconfigured.
Does renaming the WAR file change the URL?
Often yes. In Tomcat, the deployment name commonly becomes part of the context path. Renaming the file can change where the app is published.
Why do my links go to the wrong folder after migration?
The application may still use an old base URL, old rewrite rules, or an old context path from the previous hosting setup.
Should I use the domain root or a subfolder for a Java app?
Either can work, but the deployment must match the intended URL. If the site should be the main domain, deploy it at the root context. If it is a sub-application, keep the subfolder consistent.
What if the app only fails after I restart the service?
That often means the deployment did not load correctly after restart, or the startup configuration points to the wrong path. Review the service logs and deployment settings.
Conclusion
When a Java website shows the wrong path or a 404 error, the root cause is usually a mismatch between the domain, the Tomcat context path, and the Apache or Plesk configuration. In a managed Java hosting environment, the fastest way to fix it is to verify the deployment name, check the service status, confirm the domain mapping, and review logs for routing or startup errors.
With My App Server, you can control the Java service, select the correct Java version, and manage Tomcat deployment in one place, which makes path-related issues easier to diagnose. In most cases, the fix is not to rebuild the application from scratch, but to align the hosted app with the exact URL path that users should reach.