"I’ve switched to a new IP—why can I still access the website using the old one?"

This question puzzles many VPS users, leading some to wonder if the new IP has actually taken effect. In reality, the continued accessibility of an old IP is a common phenomenon resulting from a combination of technical factors—ranging from standard caching delays to configuration issues. This article breaks down the six main reasons why an old IP might remain "active" and provides a comprehensive guide for troubleshooting and resolution.

Reason 1: DNS Cache Has Not Yet Expired (The Most Common Cause)

DNS resolution is the first step in accessing a website. When you update a domain's A record from an old IP to a new one, DNS caches across the globe do not update instantaneously.

A key parameter in DNS records is TTL (Time to Live), which determines how long a resolution result remains valid within various levels of DNS caches. If your domain's TTL is set to 3,600 seconds (1 hour), any DNS server or user device that has already cached the old resolution result will continue to use the old IP during that hour.

Caching occurs at multiple levels: the user's local device (computer, smartphone, browser), the local router, and the ISP's recursive DNS servers. If the cache at any of these levels has not expired, the user may still be directed to the old IP. A typical symptom is being able to access the site via a mobile 4G connection but not via office Wi-Fi, as the two networks have different DNS cache states.

Troubleshooting Method: Run `nslookup yourdomain 8.8.8.8` and `nslookup yourdomain 114.114.114.114`. If different public DNS servers return different IPs, it indicates the system is still within the cache window.

Reason 2: Local DNS Cache Has Not Been Refreshed

Even if your domain registrar has updated the records, your local machine's DNS cache may still hold the old IP.

Windows systems cache DNS resolution results until the TTL expires or the cache is manually refreshed; macOS and Linux systems employ similar caching mechanisms. If a user accessed the site prior to the IP change, the old record stored locally will remain in effect until it naturally expires or is manually cleared. Solution: Run `ipconfig /flushdns` on Windows, `sudo killall -HUP mDNSResponder` on macOS, and `sudo systemd-resolve --flush-caches` on Linux.

Reason 3: The old IP remains on the server in a "dual-IP coexistence" state.

This is a technical detail that is easily overlooked. Many service providers do not immediately release the old IP when switching IPs; instead, they retain both the new and old IPs on the server, providing a transition window (usually 48 hours).

During this window, both the new and old IP addresses are bound to the server's network interface. The old IP (often assigned to an alias like `eth0:0`) can still receive external requests and respond normally. This explains why the website still loads when accessed via the old IP—the request actually reaches the server, and the server indeed responds.

A critical risk to watch out for: some providers' "automatic switching" processes only complete about 70% of the work. They add the new IP but fail to modify the default gateway or remove the old IP configuration. After 48 hours, when the upstream provider reclaims the old IP, the server may lose connectivity entirely; if the default route still points to the old gateway, outbound traffic cannot be forwarded, even though the new IP remains bound to the interface.

Troubleshooting: Run `ip -4 addr show` to check if both the new and old IPs exist on the network interface. Run `ip route` to confirm whether the default gateway points to the new gateway or the old one.

Reason 4: TCP persistent connections remain active.

If your application uses TCP persistent connections (such as WebSockets, database connection pools, or SSH sessions), these connections are bound to the old IP when established. As long as the connection remains open, data transmission continues via the old IP.

This is standard TCP behavior: once a connection is established, it is identified by a 4-tuple (source IP, source port, destination IP, destination port) and does not rely on DNS re-resolution. Even if the domain name resolves to the new IP, existing connections do not automatically switch over.

Typical scenario: A database connection pool is established when the application starts, holding connections bound to the old IP. After the IP change, the connection pool does not automatically refresh until the connections time out or the application restarts.

Solution: Restart the application or service to force the connection pool to re-establish connections. For WebSocket-based applications, simply disconnecting and reconnecting is sufficient to switch to the new IP.

Reason 5: The service is listening on `0.0.0.0` rather than being bound to a specific IP.

If a service on the server (such as Nginx, SSH, or a database) is configured to listen on `0.0.0.0` (all interfaces), it will respond to requests regardless of which IP address they arrive on.

In Linux, `0.0.0.0` represents "any address"—a socket bound to this address accepts connection requests on all local IP addresses, including both the old and new IPs. As long as the old IP remains configured on the network interface, the service will continue to respond to requests sent to that old IP.

This is normal and recommended practice. A service listening on `0.0.0.0` does not care which IP the request comes from; it processes any request that reaches the server. The real issue lies in when the old IP is actually removed from the network interface.

Troubleshooting method: Run `ss -tlnp | grep :80`. If the output shows `0.0.0.0:80` instead of a specific IP, the service is listening on all interfaces.

Reason 6: The old IP is hardcoded in the application-layer configuration.

Some applications may have the old IP hardcoded in their configuration files, causing the application layer to continue referencing the old IP even after DNS and network-layer switches have occurred.

Common locations for hardcoded IPs include: Nginx `listen` directives specifying the old IP instead of `0.0.0.0`; database configurations where `bind-address` points to the old IP; SSL certificate bindings that include the old IP; and external dependencies such as API whitelists, CDN origin-pull addresses, or monitoring alert targets configured with the old IP.

Troubleshooting method: Run `grep -r "old_IP" /etc/nginx/ /etc/mysql/ /etc/redis/ 2>/dev/null` on the server to search for any remaining references to the old IP in configuration files.

Complete troubleshooting and resolution process

If you encounter a situation where the old IP remains accessible, troubleshoot in the following order:

Step 1: Confirm that the new IP has actually taken effect. Run `ip addr` on the server to verify that the new IP is bound to the network interface. If the new IP is missing, the switchover operation itself is flawed.

Step 2: Check for the coexistence of both IPs. Run `ip addr` and `ip route` to verify whether the old IP remains on the network interface and if the default gateway has successfully switched to the new one.

Step 3: Verify DNS resolution status. Compare results using `dig domain @8.8.8.8` and `dig domain @114.114.114.114` to confirm that the resolution has been updated.

Step 4: Check local cache. Clear the local DNS cache and test using Incognito mode or a different device.

Step 5: Check service listening configurations. Ensure critical services are listening on `0.0.0.0` rather than being hardcoded to the old IP.

Step 6: Check for hardcoded values ​​at the application layer. Search configuration files for any remaining references to the old IP.

Proactive Strategy: Shortening the Transition Period

Understanding the reasons above allows for proactive measures to reduce the "lifespan" of the old IP.

Lower the TTL in advance. Reduce the domain's TTL value to 300 seconds or even 60 seconds 24–48 hours before the planned IP switch. This ensures that DNS caches expire quickly after the IP change, allowing global resolution updates to complete within minutes.

Configure a 301 redirect on the old IP. As long as the old IP remains available during the transition, configure a 301 permanent redirect on the associated service to forward all requests to the domain linked to the new IP. This ensures that users still directed to the old IP are automatically rerouted to the new address.

Confirm the new gateway is active before relying on the new IP. Especially when the service provider offers a "dual-IP coexistence window," it is crucial to check `ip route` during this period to ensure the default gateway points to the new one. Otherwise, once the window closes and the old gateway goes offline, the server could lose connectivity entirely.

The stability of the underlying infrastructure is a prerequisite for a successful switch. If the server's network connection is unstable, cache updates and connection re-establishment during the IP switch may fail due to packet loss. Jtti’s Hong Kong and US nodes utilize premium CN2 GIA lines with optimized direct connectivity across major carriers; packet loss rates remain consistently below 0.1% even during evening peak hours, ensuring reliable connection re-establishment during the IP switch. Dedicated bandwidth and independent IP addresses come standard across the entire product line, providing flexible infrastructure support for operations that require frequent IP rotation or the maintenance of multiple IP addresses. A policy of maintaining the same price upon renewal ensures predictable long-term operating costs.

The continued accessibility of old IP addresses is essentially the result of a combination of "cache latency" and "transition-period design." While short-term accessibility of an old IP is normal caching behavior, if it remains available long after the transition period has ended, one should inspect service listening configurations, hard-coded values ​​at the application layer, and default gateway settings.