If your Java site still opens from the old server after you have changed DNS, the most common reason is that the DNS cutover has not fully propagated yet, or that the request is still being served from cache, an old nameserver, or a local browser/session cache. In Java hosting setups with Tomcat, JSP, or a private JVM managed through a control panel such as Plesk, it is also possible that the application itself is correctly moved, but the domain still points to the previous IP address for some users or for certain records only.
In practice, this usually means one of four things: the domain is still resolving to the old IP, the TTL is delaying the switch, the web app is bound to the wrong hostname or virtual host, or the old server is still answering because traffic has not fully drained yet. The good news is that this can usually be diagnosed quickly if you check DNS, hosting configuration, and the Java application binding in the right order.
Why a Java site can keep loading from the old server
When you move a Java application during DNS cutover, the browser does not connect to “the site” in a general sense. It connects to a specific IP address resolved from DNS. If that DNS answer is stale, cached, or incomplete, the user may still reach the old server even though you have already updated the hosting account or deployed the application on the new platform.
In managed hosting environments, especially when using Apache and Tomcat behind a Plesk-based control panel, there are several layers involved:
- the domain’s A or AAAA record
- nameserver delegation at the registrar
- TTL caching at resolvers, browsers, and devices
- Apache virtual host mapping
- Tomcat connector or application binding
- application-level redirects, cookies, or session state
If any one of these still points to the old server, your Java site may appear to “stay behind” even after migration.
Most common causes during DNS cutover
DNS records still point to the old IP
The most direct cause is simply that the domain’s A record still resolves to the previous server. This may happen if only one record was changed, or if the apex domain and the www subdomain were updated separately. Java applications often use both forms, so it is important to check each one.
Also verify whether your site uses IPv6. If there is an AAAA record pointing to the old server, some clients may still reach it even when the IPv4 A record is correct.
TTL has not expired everywhere yet
DNS TTL determines how long resolvers are allowed to cache an answer. Even after you update the DNS record, some internet providers, corporate networks, and local resolvers may continue serving the previous IP until the cached TTL expires. This is a normal part of DNS propagation and is one of the main reasons a site appears to move gradually rather than instantly.
Nameserver change is still propagating
If you changed nameservers at the registrar, the old DNS zone may remain active for a while in some locations. During this period, different resolvers may still follow different nameserver data. This can make it look as if the Java site is loading from two different servers at the same time.
Local cache on the device or browser
The browser, operating system, router, or company proxy may cache DNS responses. In this case, one user sees the new server while another still sees the old one, even from the same URL. A stale browser session can also keep a site looking unchanged if the page assets or redirects are cached.
Apache virtual host or domain binding is still configured on the old server
If the DNS has already moved but requests still end up on the old hosting account, the old server may still be configured to answer for that hostname. In Apache-based hosting, a virtual host may remain active and serve the same domain until you remove or disable it. This matters especially when both servers host the same domain during migration.
Tomcat or My App Server app was not deployed on the new target correctly
In Java hosting, a domain can resolve to the new server, but the application may still redirect to an old hostname, old context path, or hardcoded URL. If the app uses absolute URLs, old cookies, or session redirects, the user may think the old server is still serving the site when in reality the new app is simply pointing back to the previous environment.
There is a CDN, proxy, or external cache in front
If a CDN, reverse proxy, or external caching layer is used, traffic may continue to hit the edge or origin configured before the cutover. In some cases the domain resolves correctly, but the cached content or origin mapping still references the old server.
How to check where the domain is really pointing
Before changing anything else, confirm the current DNS answer for the domain and for each relevant hostname.
Check the A and AAAA records
Verify the records for:
- the root domain, such as example.com
- the www hostname, such as www.example.com
- any application-specific hostnames, such as app.example.com
Make sure each hostname resolves to the intended new server IP. If you use both IPv4 and IPv6, confirm both addresses are correct and intentional.
Compare multiple DNS resolvers
Check resolution from more than one public resolver. If one resolver returns the new IP and another returns the old IP, the issue is likely propagation or caching, not the application itself. If all resolvers return the old IP, the zone data probably has not been updated correctly.
Test from the command line if possible
If you have shell access, compare results using standard DNS lookup tools. This helps you see the authoritative answer and identify whether the cache is local or upstream. In a hosting support context, this is often the fastest way to prove whether the request is still going to the old server.
Use the hosting control panel to confirm the active site setup
In Plesk or a similar control panel, review the domain’s document root, hosting settings, and any Java application configuration created through My App Server. Confirm that the domain is attached to the correct subscription, the correct IP, and the right service profile.
What to check in Plesk and My App Server
If your Java site is managed through My App Server, the application may be moved but not yet aligned with the domain configuration. Review these areas carefully:
Domain hosting settings
Ensure the domain is assigned to the new hosting account and the correct IP address. If the site uses a dedicated Apache virtual host, verify that it is enabled on the new environment and no longer active on the previous one.
Tomcat instance and Java version
Check that the correct Tomcat instance or private JVM is installed and running on the target account. If the application was tied to a specific Java version, confirm that the same or compatible version is selected in the My App Server interface.
Application context and deployment
Confirm that the WAR, JSP, or servlet application was deployed to the correct context path. A common error is deploying the app successfully but leaving the root domain mapped to a different container or path.
Service status
Verify the application service is started and responding. If the Java service is stopped on the new server, visitors may still be receiving content from the old server simply because that is the only live endpoint.
Custom app server settings
If you use custom Tomcat configuration, review connector ports, environment variables, and any host bindings. A mismatch between the domain name and the server name in the configuration can cause requests to land on the wrong virtual host or fall back to the default site.
Step-by-step fix for a Java site still loading from the old server
1. Confirm DNS has been updated everywhere
Check the authoritative zone and verify that the A and AAAA records point to the new server. Make sure both the root domain and www are updated if both are used.
2. Lower TTL before future migrations
If you still have time before a planned move, reduce TTL in advance. This shortens the period during which resolvers can cache the old record and makes the cutover smoother.
3. Wait for propagation and test from outside your network
Test using a mobile network, an external resolver, or an online DNS checker. Do not rely only on your local browser, because it may still show the old answer from cache.
4. Clear local caches
Clear browser cache, restart the browser, and if needed flush the OS DNS cache. If the issue is only on one device or one network, this often solves it immediately.
5. Check Apache virtual host mapping
On the old server, remove or disable the virtual host for the domain once traffic has moved. On the new server, make sure Apache is ready to answer for that hostname and that the correct document root or proxy target is configured.
6. Verify Tomcat app settings
Check whether your Java application uses absolute URLs, redirects, or hardcoded hostnames. Update any old server references inside configuration files, environment variables, or application code if needed.
7. Review SSL certificate setup
If HTTPS is involved, ensure the new server has a valid certificate for the domain. An SSL mismatch can cause users to think they are still on the old server when the browser is actually failing over, redirecting, or reusing cached behavior.
8. Disable or retire the old endpoint after the cutover
Once the new server is confirmed working, remove the domain from the old hosting account or set a temporary redirect only if required. Leaving the old server live for too long can create split traffic and make troubleshooting harder.
How to tell whether the issue is DNS or the application
A useful rule of thumb is this: if the hostname resolves to the old IP, it is a DNS issue. If the hostname resolves to the new IP but the site still behaves as if it were old, it is likely an Apache, Tomcat, or application configuration issue.
Examples:
- DNS issue: browser connects to the wrong server after a nameserver change
- Apache issue: the domain is attached to the wrong virtual host on the new server
- Tomcat issue: the WAR is deployed, but the app redirects to an outdated hostname
- Cache issue: some users see the old site because their resolver has not refreshed
Special cases in Java hosting migrations
Hardcoded base URL inside the app
Some Java applications store the site URL in configuration files, database settings, or environment variables. If this value still points to the old domain or old server name, users may be bounced back even after DNS is correct.
Session or login redirects
Login flows can expose migration issues because they often rely on cookies, session data, and callback URLs. If a user logs in and lands back on the old server, check the authentication redirect targets in the application configuration.
Mixed www and non-www setup
It is common for one hostname to be updated while the other still points elsewhere. Make sure the canonical version of the site is used consistently and that redirects are set intentionally, not by accident.
Reverse proxy in front of Tomcat
If Apache or another proxy sits in front of Tomcat, verify both layers. The proxy may point to the new backend, but the backend application may still reference the old host, or the proxy rule itself may still target the previous environment.
Best practices to avoid this problem next time
- lower TTL 24 to 48 hours before migration
- document the old and new IP addresses, hostnames, and services
- test the application on the new server before changing DNS
- check both A and AAAA records
- update root and www hostnames together
- review Apache and Tomcat bindings before go-live
- remove old server mappings after confirmation
- keep a rollback plan ready in case the cutover needs to be reversed
For Java hosting specifically, it is also a good idea to confirm that the selected Java version, Tomcat version, and application context are documented before the move. This makes it easier to restore the same runtime environment on the new server if needed.
When to contact support
Contact hosting support if DNS has clearly updated but the site still loads from the old server after a reasonable propagation period, or if the control panel shows the domain is attached correctly but the application is still resolving inconsistently. Support can help check zone data, virtual host configuration, Tomcat service status, and whether any old mappings remain active on the previous server.
If you are using My App Server, it is especially helpful to provide the domain name, expected target IP, the Java/Tomcat version in use, and the exact symptom you see. That allows the support team to verify whether the issue is in DNS, Apache, the Tomcat service, or the application itself.
FAQ
How long can DNS propagation take?
It can vary from minutes to a day or more, depending on TTL values, resolver behavior, and whether nameservers were changed. Lower TTL values usually reduce the wait, but cached answers can still persist until they expire.
Why does one browser show the new site and another show the old one?
Different browsers, devices, or networks may use different cached DNS answers. One may already have the new IP while another still has the old one cached.
Can the old server still serve the site after DNS is changed?
Yes. If cached DNS, old virtual host configuration, or application redirects remain in place, some traffic can still reach the old server for a period of time.
Should I change only the A record or also the www record?
Update every hostname you expect visitors to use. In most cases that means both the root domain and www, and sometimes additional subdomains used by the Java application.
What if the domain points to the new server but the app still looks old?
Then the issue is likely in the hosting configuration or application layer, not DNS. Check Apache virtual hosts, Tomcat deployment, redirects, cached assets, and any hardcoded server URLs inside the application.
Does My App Server support moving a Java app during DNS cutover?
Yes, it is designed for practical Java hosting use cases such as Tomcat, JSP, servlet, WAR deployment, and private JVM management in a shared hosting account. The important part is to align the DNS, domain mapping, and service configuration during the move.
Conclusion
A Java site that still loads from the old server after a DNS change is usually caused by DNS caching, incomplete record updates, or a remaining Apache/Tomcat binding on the previous environment. In a Plesk-based Java hosting setup, the safest approach is to verify DNS first, then confirm the domain mapping and Tomcat service on the new server, and finally remove or disable the old endpoint once traffic has fully moved.
For the smoothest go-live, lower TTL ahead of time, update all relevant hostnames, test from external networks, and make sure your Java application is not using old absolute URLs or redirects. With the right checks, most cutover issues can be resolved quickly and without extended downtime.