If a Tomcat website is showing the wrong path, a missing page, or a 404 error, the problem is usually related to how the application is deployed, which context path is being used, or how Apache, Plesk, and Tomcat are mapped together. In a managed hosting setup, this often happens after a redeploy, a change in the application name, a Java version update, or a configuration change in the control panel.
On a hosting platform that provides Java hosting through a private Tomcat instance, the good news is that most of these issues can be diagnosed quickly. In many cases, the site is still running, but the browser is requesting the wrong URL path, the app was installed under a different context, or the web application itself is missing the expected start page.
Why Tomcat returns 404 or the wrong path
Tomcat uses a context path to decide where your application lives. If the app is deployed as /myapp, then visiting the root domain / may show a 404 unless there is a redirect or a default application configured. A “wrong path” issue usually means the browser URL does not match the actual app context in Tomcat or the Apache mapping in front of it.
Common causes include:
- The application was uploaded under a different context name than expected.
- The WAR file was renamed during deploy.
- Apache or Plesk is forwarding requests to Tomcat, but the target path is incorrect.
- The app’s
web.xmlor framework routing expects a different base path. - The application root page does not exist, so Tomcat correctly returns 404.
- A previous deployment is still cached or partially active.
Check the Tomcat context path first
The first thing to verify is the application context. In Tomcat, the context path is the URL segment after the domain name. For example, if the app is deployed as /shop, then the correct address is https://example.co.uk/shop/.
How to verify the context path
- Open the Plesk control panel and go to your My App Server or Java hosting service.
- Check the installed application name or deployment target.
- Confirm whether the app is deployed as the domain root or as a sub-path.
- Look for any alias, rewrite rule, or Apache mapping that points the domain to Tomcat.
If the application is not meant to be available at the root of the domain, then a 404 on / can be normal. In that case, the correct fix is to use the exact context path or set up a redirect to the app entry point.
Confirm that the start page really exists
A Tomcat app can be deployed successfully and still show 404 if there is no valid landing page. This is common with JSP, servlet, and framework-based applications after an incomplete build or a bad package upload.
What to check in the application
- Is there an
index.jsp,index.html, or framework-defined default route? - Does the application redirect from
/to a login page or dashboard? - Was the WAR file built correctly and fully expanded by Tomcat?
- Are the static files and compiled classes present in the expected folders?
If the app uses Spring, Struts, JSF, or another framework, the root path may need explicit routing. If that route was changed during deployment, the browser may still request an old page and receive a 404.
Check for Apache and Tomcat path mismatch
In managed hosting, requests often pass through Apache before they reach Tomcat. Apache may serve the domain root, forward selected paths, or rewrite the request to the Java application. If these rules do not match the app’s actual location, visitors may see the wrong path or a 404 error.
This is especially important when the domain is configured to show a Java app under Plesk. The domain may be pointing to Apache, while Apache internally forwards traffic to the private Tomcat instance managed by My App Server.
Typical signs of a mismatch
- The home page works, but inner application links fail.
- The app works on one path, but not on the domain root.
- Static files load, but JSP or servlet routes return 404.
- The browser shows the correct domain, but the content belongs to another directory.
If Apache rewrites are involved, check whether the configured rule still points to the current Tomcat context. A small path change can break the whole app.
Check whether the WAR was deployed under a different name
Tomcat commonly uses the WAR file name as the context path. For example, app.war usually becomes /app. If the file was renamed to ROOT.war, the app may become available at the domain root. If it was uploaded as myapp-v2.war, the context becomes /myapp-v2.
This is one of the most frequent reasons for “wrong path” complaints after a redeploy.
Things to verify after upload
- Did the WAR file name change?
- Was the application installed as a new version with a different context?
- Did Tomcat keep the old exploded directory alongside the new one?
- Did the deploy finish fully, or did it stop halfway?
When possible, use a consistent deployment name. If the application must stay at the same URL, keep the same context path across releases.
Clear cached deployment data when the path looks wrong
Sometimes the application itself is correct, but Tomcat or the browser is still using stale deployment data. This can happen after an update, rollback, or configuration change.
Safe cleanup steps
- Stop the Tomcat service from Plesk or the My App Server control page.
- Remove old expanded application folders if you have access and if your hosting setup allows it.
- Check for duplicate WAR files with similar names.
- Start the service again and test the application URL.
- Test in a private browser window or clear browser cache.
In some cases, an old redirect or cached 302 response in the browser can make it look as if the application is still deployed under the wrong path.
Check permissions and file ownership
A 404 can also appear if Tomcat cannot read the deployed application files correctly. This is less common than a path mismatch, but it still happens, especially after manual uploads or file replacements.
Look for these permission problems
- The web app directory is missing read access for the service user.
- The uploaded files are owned by the wrong user.
- The application did not unpack completely due to permission restrictions.
- Static resources are inaccessible, causing partial page loads and broken links.
If you use Plesk, compare the file permissions with other working websites or Java applications in the same account. The hosting environment should allow the Tomcat service to read the deployed application files without manual workarounds.
Check the app server status in My App Server
When using a private Tomcat instance through My App Server, the service itself must be running cleanly. If Tomcat is stopped, restarting, or misconfigured, the application may appear broken or may expose old paths.
Useful service checks
- Verify that the Java runtime version matches the app requirements.
- Confirm that the Tomcat service is running.
- Check whether a recent configuration update changed the startup parameters.
- Review the service log for deployment errors.
If the service starts but the app still returns 404, the issue is usually application-specific rather than a full server outage.
Review application logs for deployment errors
Logs often show the real reason behind a wrong path or 404 response. In a Tomcat hosting environment, they can reveal whether the app deployed successfully, whether a servlet mapping failed, or whether the application context was rejected.
What to search for in logs
- Deployment failures
- Class loading errors
- Missing resources
- Context startup exceptions
- Conflicting application names
- 404 entries for the exact requested URL
If the logs mention a failed context initialization, Tomcat may not expose the application as expected. If the logs show the correct app name but the browser still gets 404, then the issue is likely in routing or the Apache mapping.
Check whether the app expects HTTPS or a canonical host
Some Java applications generate URLs based on the host name or protocol. If the app expects https:// but receives http://, or if it is hardcoded to a different domain, links inside the site can point to the wrong path.
Common symptoms
- The first page opens, but internal links go to an old URL.
- Redirects send users to a different host name.
- The browser path changes after login or form submission.
This is often a configuration issue inside the application. Review the base URL, server name, and redirect settings in the app configuration if the domain itself is correct but the navigation is not.
How to fix the problem step by step
If you need a practical order of checks, use this sequence:
- Open the exact URL that should serve the application.
- Confirm the app context path in Plesk or My App Server.
- Check whether the WAR name matches the expected URL path.
- Make sure the application includes a valid entry page or route.
- Review Apache rewrite rules or domain mapping.
- Restart the Tomcat service.
- Clear browser cache and test again.
- Inspect application and Tomcat logs for deployment errors.
This sequence resolves most 404 and wrong-path cases without needing deeper changes to the hosting account.
Examples of common scenarios
Example 1: The domain root shows 404
The app was uploaded as portal.war, so Tomcat deployed it as /portal. Visiting example.co.uk returns 404 because no application exists at the root. The correct URL is example.co.uk/portal/, or the app must be deployed as ROOT.war if root access is intended.
Example 2: The app worked yesterday, but links now fail
The application was redeployed with a new name, such as portal-new.war. The main page still loads, but internal links point to the old context. Updating the app’s base URL or restoring the original context name fixes the issue.
Example 3: Static files load, but servlet routes return 404
The Apache layer serves the static content, but the servlet mapping in Tomcat does not match the requested path. The fix is to review the servlet mapping, deployment descriptor, or framework routing rules.
When to contact support
Contact support if the application is still returning a wrong path or 404 after you have checked the context path, deployment name, logs, and service status. It is especially useful to contact support when:
- You see a deployment error in the Tomcat log but cannot identify the cause.
- The control panel shows the app as installed, but the URL still returns 404.
- Apache and Tomcat mappings are not behaving as expected.
- The service does not start after a Java or Tomcat version change.
Include the domain name, the exact URL that fails, the expected path, and any recent changes you made. This helps the hosting team identify whether the issue is in the application, the Tomcat deployment, or the Apache routing layer.
FAQ
Why does Tomcat show 404 if the app is installed?
Because installed does not always mean available at the URL you are testing. The app may be deployed under a different context path, or it may not have a valid start page.
Why is the browser going to the wrong path after deployment?
This usually happens when the WAR file name changed, the context path changed, or the app stores an old base URL in its configuration.
Can Apache cause a Tomcat 404?
Yes. If Apache rewrite rules or proxy mapping point to the wrong Tomcat path, users can get 404 even when the Java application itself is working.
Should the domain root always open the Java app?
No. Only if the application is deployed at the root context or you configured a redirect. Otherwise the app may live under a sub-path such as /app or /portal.
Will restarting Tomcat fix the problem?
Sometimes. A restart can clear stale deployment state, but if the context path or routing is incorrect, the error will return until the configuration is corrected.
Conclusion
A Tomcat website showing the wrong path or a 404 error is usually caused by a deployment mismatch, context path issue, Apache rewrite problem, or missing application route. In a Plesk-based Java hosting setup with a private Tomcat instance, the fastest way to resolve it is to verify the deployed context, check the WAR name, review logs, and confirm that the service and mappings match the URL you expect.
Once the application path is aligned with the control panel configuration and the app includes a valid entry page, most 404 and wrong-path issues can be fixed without rebuilding the whole site.