When a Tomcat website shows the wrong path, redirects to an unexpected location, or returns a 404 error, the problem is usually related to the application context path, the deployed webapp name, a proxy or Apache mapping, or the Tomcat deployment itself. In a hosting environment with a control panel such as Plesk and a managed Java service like My App Server, these issues are often fixable without changing the application code.
This article explains the most common reasons why a Tomcat site may display the wrong path or a 404 error, how to check the configuration in a hosted Java environment, and what to do when your WAR, JSP, or servlet app is deployed but not reachable.
What the wrong path or 404 error usually means
In Tomcat, the visible URL path is tied to the application context. If that context is not what you expect, Tomcat may respond with a 404, open the app under a different path, or serve the default Tomcat page instead of your application.
Common symptoms include:
- Opening
/shows Tomcat’s default page instead of your app. - Your app works at
/myapp, but not at the domain root. - The browser shows a 404 after deployment, even though the app appears installed.
- Static files or JSP pages load with the wrong path.
- Links inside the app point to old or incorrect URLs.
- After an update, the application suddenly starts using a different context path.
In hosted Tomcat environments, these problems are often caused by deployment naming, context configuration, Apache reverse proxy rules, virtual host settings, or application-side path assumptions.
Most common causes of Tomcat path and 404 problems
1. The application context path is not what you expect
Tomcat usually uses the WAR file name or deployed application folder name as the context path. For example, myapp.war is commonly available at /myapp. If you expected the site on the domain root, that may be the reason for the 404.
Typical cases:
- WAR file named
app.waropens at/app. - Application deployed under a subpath, but the user tries to open the domain root.
- The app was renamed during upload, changing the URL.
2. The application is deployed, but not as the root app
If you want the Tomcat app to open at /, it must be deployed as the root context. In some hosting setups, that means using a specific root deployment name or a dedicated configuration in the control panel.
If the app is deployed as a non-root webapp, the domain root may still be handled by Apache or another default document root, which can result in a 404 or a different site being shown.
3. Apache or proxy routing is pointing to the wrong backend path
Many hosted environments use Apache in front of Tomcat. In that setup, Apache may forward requests to Tomcat using proxy rules or application mappings. If those rules point to the wrong path, Tomcat can receive requests that do not match the deployed application.
Examples of misrouting include:
- Proxying
/to/myappincorrectly. - Missing rewrite or proxy rules after a site rename.
- Apache serving static content from the wrong document root.
- Virtual host configuration pointing to an old app location.
4. The deployment did not complete successfully
Tomcat may show an application as installed, but if deployment failed during startup, the context may not become available. In that case, a request to the app path often returns 404.
Possible reasons include:
- Invalid WAR file.
- Missing dependencies inside the application.
- Startup error in
web.xmlor application code. - Java version mismatch.
- Configuration file error.
5. The application expects a different base URL
Some Java web applications generate links, redirects, or resource paths based on a hardcoded base URL or a fixed context path. If the app was moved, renamed, or deployed under another path, the browser may be sent to an invalid location and show a 404.
This is especially common with:
- Old absolute URLs in JSP templates.
- Redirects in servlets that assume a fixed path.
- Front-end resources loaded with hardcoded
/paths.
6. Cached browser data or stale redirects
Sometimes the issue is not on the server side. Browsers can cache redirects, old application paths, or script files. A stale cache may make a working app appear broken.
7. File permissions or ownership issues
If Tomcat cannot read the deployed files, or if the application directory is incomplete, requests may fail with a 404 or partial loading. This is less common when the app is installed through a managed control panel, but it can happen after manual changes or uploads.
How to check the problem step by step
1. Confirm the exact URL you are opening
Start by checking whether the app is supposed to open at the domain root or at a subpath. For example:
https://example.com/https://example.com/myapp/https://example.com/appname/
If the application is deployed as a subapplication, a 404 at the root may be normal. In that case, the fix is to use the correct context path or reconfigure the deployment if you want root access.
2. Check the application name in the control panel
In a Plesk-based Java hosting environment, the application name or deployment name can determine the visible path. Open the My App Server service or Java hosting section and verify:
- Which Tomcat instance is running.
- Which application is deployed.
- The assigned context path.
- Whether the app was installed as root or as a named application.
If the deployed name is different from the URL you are testing, that may explain the 404.
3. Verify that the Tomcat service is running
If the service is stopped, restarted incorrectly, or still starting, Tomcat may not serve the app. In My App Server, check the service status and confirm that the JVM and Tomcat instance are active.
Useful checks:
- Service is started.
- The correct Java version is selected.
- Tomcat has finished startup.
- No recent restart failed.
4. Review deployment and startup logs
Logs are one of the fastest ways to identify why the path returns 404. Look for:
- Context deployment messages.
- WAR unpacking errors.
- ClassNotFoundException or NoClassDefFoundError.
- Port binding problems.
- Application startup exceptions.
If you see that the application failed to deploy, the path may not exist even though the file is present on disk.
5. Test the app directly on the Tomcat context path
If Apache is proxying the site, try accessing the Tomcat app through the expected internal context, if your setup allows it. This helps separate Apache mapping issues from Tomcat deployment issues.
If the app works directly on its Tomcat path but not through the public domain, the problem is usually in Apache, reverse proxy rules, or virtual host configuration.
6. Check whether the app is installed as a WAR or extracted folder
Tomcat can serve applications from a WAR file or from an unpacked directory. If the folder name changed, or if there is both a WAR and an extracted directory with mismatched names, the active context may not be what you expect.
Look for:
- Duplicate deployments.
- Old WAR files left in place after updates.
- Extracted folders with different names.
- Stale context descriptors.
7. Confirm that links inside the app use the correct base path
If the home page loads, but internal links return 404, the issue may be inside the application. Check whether the app uses absolute paths such as /css/style.css or /login when it should use context-aware paths.
For JSP and servlet apps, a safer approach is to generate links relative to the application context rather than hardcoding the domain root.
How to fix the issue in a hosted Tomcat environment
Fix the context path
If your application should open at a different URL, rename the deployment or adjust the context in the hosting control panel. In many Tomcat setups, the deployed file name defines the path. If you want /myapp, the file or folder often needs to match that name.
If you want root access, deploy as the root application according to your hosting setup.
Adjust Apache or proxy mapping
If Apache sits in front of Tomcat, review the mapping rules so the public domain routes to the correct app path. Common fixes include:
- Correcting proxy target paths.
- Updating rewrite rules after application renaming.
- Ensuring the domain points to the correct virtual host.
- Removing old route definitions that reference deprecated app names.
Redeploy the application cleanly
If deployment looks inconsistent, remove the old copy and redeploy the application from a fresh WAR file. This can fix issues caused by stale files, incomplete extraction, or conflicting old versions.
Before redeploying, it is a good idea to:
- Stop the service if needed.
- Remove the old deployment folder.
- Upload a clean WAR file.
- Start the service again.
- Check the logs immediately after startup.
Verify Java compatibility
A Tomcat app may deploy with one Java version and fail with another. In My App Server, you can select a Java version supported by your application. If the app was built for a specific runtime, make sure the selected version matches the app requirements.
Version mismatch can lead to startup errors that appear as 404 because the application never became active.
Update application configuration for the correct base URL
If the app redirects to the wrong path, review configuration values such as:
- Base URL.
- Server URL.
- Context path property.
- Redirect target settings.
- Environment variables used by the app.
After moving a Tomcat app, these values often need to be updated so the application generates correct links.
Clear cache and retest
After making changes, test the site in a private window or clear browser cache. If you changed redirects, also clear any CDN or application cache if used in front of Tomcat.
Specific checks for My App Server users
If you use ITA My App Server for Java hosting, Tomcat hosting, JSP hosting, or servlet hosting, the following checks are especially useful:
- Confirm that the service is started in the Plesk extension.
- Check which Java version is assigned to the app server.
- Verify the application is deployed in the correct service instance.
- Look for a mismatch between the deployed app name and the public URL.
- Review whether the application was installed automatically or uploaded manually.
- Check if multiple Java/Tomcat versions exist and the app is attached to the wrong one.
My App Server is designed for practical managed Java hosting with a private JVM and Tomcat-style deployment inside a shared hosting account. That makes it a good fit for small and medium Java applications, but the app still needs correct deployment naming and path handling to work as expected.
Examples of common scenarios
Example 1: Site works at /app but not at the domain root
This usually means the app is deployed under the /app context. Either use that URL, or redeploy the app as the root context if your hosting setup supports it.
Example 2: Homepage loads, but CSS and images return 404
This often means the application uses absolute asset paths that do not match the deployed context. Update the app to build resource paths relative to the context root.
Example 3: After update, the site now shows a 404
This can happen if the new WAR deployed under a different name, the old context was removed, or the application failed to start due to an error. Check the logs and confirm the new context path.
Example 4: Domain opens Apache default page instead of Tomcat app
This usually points to an Apache virtual host or proxy issue. The domain may not be routed to the Tomcat app, or the document root may still be serving static content.
What not to do
- Do not assume a 404 always means the app is missing.
- Do not rename files randomly without checking the resulting context path.
- Do not leave old WAR files and old extracted folders in place if you redeploy.
- Do not ignore startup errors in logs.
- Do not hardcode domain-root paths inside the application unless that is intentional.
When to contact support
Contact support if you have already checked the URL, deployment name, and logs, but the app still shows the wrong path or a 404. It helps to include:
- The exact URL you are testing.
- The expected application path.
- The WAR or application name.
- The Tomcat or Java version in use.
- Any relevant log messages.
- Whether the issue started after a redeploy or configuration change.
With that information, support can quickly determine whether the issue is in Tomcat deployment, Apache routing, or the application itself.
FAQ
Why does my Tomcat app open on a different URL than expected?
Most often because the deployment name defines the context path. If the WAR is named shop.war, the app usually opens at /shop.
Why do I get 404 even though the app is installed?
The app may not have deployed successfully, may be deployed under a different path, or Apache may be routing traffic to the wrong location.
Can I make a Tomcat app open at the domain root?
Yes, if your hosting setup allows root deployment. Otherwise you may need to deploy the app under a named context or adjust the proxy configuration.
Why do some pages work and others return 404?
This usually means the application has incorrect internal links, missing resources, or redirects pointing to an old base path.
Does changing the Java version affect 404 errors?
Indirectly, yes. If the app fails to start due to Java incompatibility, Tomcat may not publish the context, which can appear as a 404.
How do I know whether the problem is in Apache or Tomcat?
If the app works directly under its Tomcat context but not through the public domain, the issue is likely Apache or proxy routing. If the app does not work at the Tomcat path either, focus on deployment and logs.
Summary
A wrong path or 404 error in a Tomcat website is usually caused by a context path mismatch, failed deployment, Apache or proxy routing, or application-side URL assumptions. In a managed hosting environment with Plesk and My App Server, the fastest path to resolution is to verify the deployed application name, confirm the service is running, check logs, and review any Apache mapping or redirect rules.
Once the correct context path is restored and the app is deployed cleanly, most Tomcat 404 and wrong-path issues are resolved without code changes. If the application itself generates incorrect URLs, update the base path settings so the site matches the deployment location.