If a Tomcat site is still loading from the old server after a migration or go-live, the cause is usually not Tomcat itself. In most cases, the browser, DNS, proxy caching, or a missed configuration change is still sending traffic to the previous host. During a cutover, it is also common for some visitors to reach the new Tomcat server while others continue to see the old one until DNS fully propagates.
In a managed hosting environment with Plesk and a Java hosting setup such as My App Server, the goal is to move the domain, application, and traffic path together. If only the application files were moved, but the domain still points to the old IP, the site will keep loading there. This article explains the most common reasons this happens, how to verify where the request is going, and what to check in Tomcat, Plesk, DNS, and browser cache.
Why a Tomcat site may still resolve to the old server
When a browser opens a site, it first resolves the domain name to an IP address through DNS. If that IP is still the old server, the request reaches the old Tomcat instance or even a different web server entirely. Even if DNS has already been updated, caching may delay the change for some users.
The most common causes are:
- DNS has not fully propagated yet, or the TTL was high before the change.
- The local DNS cache on the user’s device, router, or company network is still holding the old record.
- The browser cache is showing an older response.
- The domain’s A/AAAA record still points to the old server.
- The site is behind a proxy, CDN, or load balancer that is still forwarding to the old origin.
- Tomcat or Apache virtual host settings on the new server are incomplete, so the domain is not served correctly after DNS switches.
- The application was moved, but the DNS cutover was not completed for all relevant hostnames, such as www and the apex domain.
First check: where does the domain currently point?
Before changing anything in Tomcat, confirm the active DNS target. If the domain still resolves to the old server, the fix is in DNS, not in the Java application.
Check the A and AAAA records
Verify the domain’s A record for IPv4 and, if used, the AAAA record for IPv6. Both should point to the new hosting environment if the site is meant to run there. If only IPv4 was updated but IPv6 still points to the old server, some visitors may continue to land on the previous host.
Also check related hostnames:
- the root domain, such as example.com
- the www subdomain, such as www.example.com
- any application-specific subdomains, such as app.example.com
Check nameserver delegation
If the domain was moved to a new DNS zone, make sure the registrar still points to the correct nameservers. A mismatch between registrar delegation and the hosted DNS zone can keep the old records active or make the domain inconsistent across resolvers.
Check TTL values
TTL determines how long DNS resolvers may keep the old answer. If the TTL was set to several hours or days, the old server may continue to receive traffic until caches expire. For planned go-live changes, a lower TTL should be used in advance so the cutover takes effect faster.
How DNS propagation affects a Tomcat cutover
DNS propagation is not instant from the user’s point of view. Different resolvers refresh at different times. This means a site can appear to be working from the new Tomcat server in one location and still load from the old server in another.
This is normal during a cutover window, especially when:
- the domain was recently pointed to a new IP
- the previous TTL was long
- the domain is cached by an ISP, office network, or VPN
- the old server still has the same content, making the issue less visible
If you need a faster and cleaner migration, reduce the TTL at least 24 to 48 hours before the change, then update the DNS record during the go-live window.
Browser cache and local DNS cache can hide the change
Sometimes the site is already serving from the new Tomcat server, but the browser or operating system keeps showing an older response. This can happen after a redirect, a Java web app update, or a DNS change.
What to test on the client side
- Open the site in a private/incognito window.
- Clear the browser cache.
- Flush the local DNS cache on the device.
- Try the site from a mobile connection instead of the office network.
- Test from a different resolver, such as a public DNS service, if allowed by policy.
If the site loads correctly elsewhere but not on one network, the problem is likely a cache or resolver issue rather than Tomcat.
Verify the new Tomcat host in Plesk and My App Server
In a hosting platform that uses Plesk and a Java extension such as My App Server, the domain must be connected to the correct service profile. If the app was deployed to Tomcat but the domain is still mapped to the old subscription, document root, or vhost, traffic may not reach the intended JVM.
Check the domain mapping
Make sure the domain is attached to the correct hosting subscription and points to the expected web application path. In Tomcat hosting, this usually includes:
- the correct domain name or subdomain
- the correct Tomcat instance or private JVM
- the right Java version selected for the app
- the correct deploy target, such as WAR, exploded app, or application directory
Check the service status
Confirm that the Tomcat service is running on the new server. If the service is stopped, failed, or still restarting, some requests may fall back to the old environment if DNS or upstream routing still allows it.
In My App Server environments, service control should be used to confirm that:
- the Java process is active
- Tomcat started without errors
- the application deployed successfully
- the expected port is listening
Check logs for startup or deployment errors
If the new server is not serving the site correctly, review Tomcat logs and application logs for deployment failures, missing libraries, port conflicts, or permissions issues. A broken deployment can make it look like the old site is still live when in fact the new one is not ready.
Common configuration mistakes during a Tomcat migration
Even with correct DNS, a migration can appear incomplete if one piece of the application stack was missed.
1. Only the application files were moved
Moving the WAR file or application directory does not automatically move DNS. If the domain still points to the old server, users will stay there until the records update.
2. The www and non-www versions were treated differently
It is common to update example.com but forget www.example.com, or the other way around. If both names are used publicly, both must be checked and redirected consistently.
3. Apache or reverse proxy still points to the old backend
In some hosting setups, Apache sits in front of Tomcat. If Apache or a proxy rule still forwards traffic to the old backend, the site may continue to behave as if it were hosted there even after DNS changes.
4. The application depends on hardcoded absolute URLs
Java web applications sometimes contain links, callbacks, or asset URLs hardcoded to the old hostname or server address. The page may load from the new host, but parts of the site can still call the old one.
5. Session or cookie issues create mixed behavior
If both the old and new servers are temporarily active, sessions can behave inconsistently. One request may land on the old host and the next on the new one, especially if sticky routing is not in place. This is another reason to complete DNS cutover cleanly and avoid serving the same app from two places for too long.
Step-by-step checklist to confirm the site is on the new server
Use the checklist below to isolate the issue quickly.
1. Confirm DNS records
- Check the A record for the root domain.
- Check the A record for www and any app subdomains.
- Check AAAA records if IPv6 is enabled.
- Make sure the records point to the new server.
2. Confirm registrar nameservers
- Verify the domain uses the intended authoritative nameservers.
- Check that the DNS zone at those nameservers is updated.
3. Confirm the new Tomcat service is healthy
- Open the Plesk or hosting control panel.
- Check My App Server / Tomcat service status.
- Verify the app starts with the correct Java version.
- Review logs for deployment or startup problems.
4. Test direct server response
- Test the hostname from multiple networks if possible.
- Compare results in a private browser window.
- Use the resolved IP address to confirm whether it is the old or new server.
5. Check redirects and proxy rules
- Review Apache virtual host or reverse proxy settings.
- Confirm no rule forwards requests to the old backend.
- Verify HTTP to HTTPS redirects are correct.
6. Review cached content
- Clear browser cache.
- Flush DNS cache.
- Wait for TTL expiry if the record was recently changed.
How to reduce downtime during Tomcat DNS cutover
A clean cutover depends on timing. For Tomcat hosting and other Java applications, the safest approach is to prepare the new server before changing public DNS.
Recommended migration sequence
- Deploy the application to the new Tomcat instance.
- Verify the app locally or through a temporary hostname.
- Lower the TTL on the active DNS records in advance.
- Confirm Apache, proxy, and Tomcat settings on the new server.
- Switch the A and AAAA records to the new IP.
- Monitor access logs and application logs after the change.
- Keep the old server available briefly in case some resolvers still cache the previous address.
This approach reduces the chance that users will see an outdated server or an incomplete deployment.
When the problem is not DNS
After DNS has propagated, if the site still appears to load from the old server, the issue may be in the application or web server layer.
Look for these signs:
- The hostname resolves to the new IP, but the page content looks like the old deployment.
- Static assets load from the old domain or old path.
- Application links still point to the previous server.
- The Java app starts, but the wrong context root is active.
- The request is reaching Apache instead of Tomcat, or vice versa.
In those cases, review the Tomcat context, deployment path, virtual host configuration, and any application-specific base URL settings.
Tomcat-specific checks in a managed hosting environment
For Java hosting on a shared hosting account with a private JVM, the site may depend on a small set of service-specific settings. These should be verified during go-live:
- Tomcat version matches the application requirements.
- Java version is compatible with the deployed app.
- Service port is configured correctly.
- Application context path matches the public URL.
- Deployment permissions allow the app to start and write where needed.
- Proxy or Apache integration forwards requests to the intended JVM.
If the app is based on WAR files, JSP pages, or servlets, it is especially important that the public hostname, the Tomcat context, and the deployment package all match. A mismatch can make the site appear to be “stuck” on the old server, even when DNS is correct.
FAQ
How long can a Tomcat site keep loading from the old server after DNS changes?
It depends on the previous TTL and the resolver cache in use. Some users may see the new server within minutes, while others may continue to reach the old one for several hours or longer if the old TTL was high.
Why does my site load correctly on mobile but not on office Wi-Fi?
The office network may be using a cached DNS answer or a proxy that still points to the old server. Test from a different network and compare the resolved IP address.
Can browser cache make a site look like it is still on the old Tomcat server?
Yes. Browser cache can preserve old redirects, assets, or page fragments. However, if the entire site consistently resolves to the wrong IP, the root cause is usually DNS rather than browser cache.
What if only www works on the new server but the root domain still goes to the old one?
This usually means the DNS records were updated inconsistently. Check both the root domain and the www host, and confirm they point to the same intended destination.
Do I need to change anything inside Tomcat when moving to a new server?
Sometimes yes. If the application uses hardcoded URLs, context paths, environment variables, or backend endpoints, these may need to be updated. You should also verify the Java version and Tomcat service settings on the new host.
How can I verify which server is answering the request?
Check the resolved IP address for the domain and compare it with the new server’s IP. You can also review access logs on both servers to see which one receives requests for the hostname.
Conclusion
When a Tomcat site still loads from the old server, the most likely cause is an incomplete cutover: DNS has not fully changed, caches are still active, or the new hosting setup is not yet fully aligned with the public hostname. In a Plesk-based Java hosting environment with My App Server, the safest way to resolve this is to verify DNS, confirm service status, check domain mapping, and review Tomcat and Apache configuration together.
If the records are correct, the service is running, and the app is deployed properly, the old-server behavior usually disappears as caches expire. For future migrations, lower TTL early, test the new Tomcat instance before go-live, and update all related hostnames at the same time. That is the most reliable way to switch traffic with less downtime.