A sudden loss of server connectivity, interrupted user access, and a flood of customer complaints—this is the scenario every webmaster and DevOps engineer dreads. While Hong Kong servers are renowned for low latency and exemption from ICP filing requirements, risks such as IP blocking, data center network fluctuations, and server outages persist. DNS failover and automatic IP switching mechanisms are the key solutions to these issues.
Why do Hong Kong servers need DNS failover?
Hong Kong servers host a vast number of services targeting users in mainland China. The low latency of CN2 GIA lines ensures a domestic access experience comparable to local servers; however, this also means that if an IP is blocked or the server fails, the resulting service interruption directly impacts end-users.
IP blocking and server outages share similar symptoms—domestic users cannot access the service—yet the response strategies differ significantly. When an IP is blocked, SSH connections from overseas nodes remain functional, whereas a server outage renders the server inaccessible from all nodes. Accurately diagnosing the issue is essential for selecting the correct failover strategy.
The core logic of DNS failover involves continuously monitoring server health; upon detecting an anomaly, the system automatically updates DNS records via the provider's API to redirect traffic to a standby address. Users remain unaware of the switch, as access is automatically routed to a healthy node.
Two mainstream failover solutions
Solution 1: Native failover provided by the DNS service provider
If your domain is hosted by a DNS provider that supports failover (such as 51DNS), you can configure health checks and primary/standby address pools directly within the control panel.
51DNS’s outage monitoring and automatic failover features are value-added services available only in paid plans; they support the automatic removal of problematic IPs and intelligent switching. DNSPod offers similar capabilities, allowing for more flexible failover logic via its API.
The advantages of this approach are simple configuration and automated execution by the platform, eliminating the need for manual script maintenance. The downsides include associated costs and significant feature variations between providers.
Solution 2: Automatic switching via scripts calling the DNS API
If your DNS provider does not offer native failover (e.g., the free tier of Cloudflare), you must use scripts to periodically monitor server status and call the API to update DNS records when an anomaly is detected. Taking Cloudflare as an example, `jinqians/cloudflare_dns` is a mature solution that supports automatic failover between primary and backup VPS instances and functions correctly even when Cloudflare's proxy mode is enabled. The deployment process is as follows:
Step 1: Obtain a Cloudflare API Token. Log in to the Cloudflare Dashboard and create a token under "My Profile → API Tokens." Select only the `Zone:Zone:Read` and `Zone:DNS:Edit` permissions, adhering to the principle of least privilege.
Step 2: Obtain the Zone ID and Record ID. Use the API to retrieve the Zone ID for your domain and the Record ID for the specific DNS record you wish to modify.
Step 3: Download the script and grant it execution permissions:
wget https://raw.githubusercontent.com/jinqians/cloudflare_dns/refs/heads/main/dns_switch.sh
chmod +x dns_switch.sh
Step 4: Run the configuration wizard. The script will prompt you to enter details such as the API Token, Zone ID, Record ID, the IP addresses and ports of the primary and backup VPS instances, and the health check port and HTTP path.
Step 5: Set up a scheduled task. Add a cron job using `crontab -e`; it is recommended to run the check every 5 minutes.
The script performs health checks based on TCP ports and HTTP status codes. It automatically switches DNS resolution to the backup VPS if the primary VPS fails and can send notifications via Telegram when the IP address changes.
Practical Solutions for Rapid IP Switching on Hong Kong Servers
In addition to DNS-level switching, IP management for the Hong Kong server itself requires a complementary strategy. Below are several common methods for IP switching.
Option 1: Contact the service provider to change the IP.
This is the most direct method. Most Hong Kong VPS providers allow IP changes for a fee, typically ranging from 20 to 50 RMB. If a change is needed because the IP has been blocked, it is advisable to prioritize providers that offer an IP replacement guarantee when purchasing the service.
Option 2: Enable Cloudflare CDN to hide the real IP.
This is the most highly recommended long-term solution. By using Cloudflare's proxy mode, users connect to Cloudflare's IP addresses rather than your actual server IP, preventing the Great Firewall (GFW) from directly blocking your origin server. Simply change your domain's nameservers to the addresses provided by Cloudflare and set the DNS record's proxy status to "Orange Cloud" in the Cloudflare dashboard.
Note that the free version of Cloudflare does not offer native failover; if automatic switching is required, you will still need to use the script-based solution mentioned above.
Option 3: Multi-node Redundancy Architecture
Deploy one VPS in Hong Kong and another in the US (or Japan), utilizing intelligent DNS routing: users in mainland China resolve to the Hong Kong IP, but if that IP fails, the system automatically switches to the US node. Data between the two server sets is synchronized in real-time.
The core advantage of this architecture is geographic redundancy. If the Hong Kong data center experiences a total outage or its IP range is blocked, the backup node can take over immediately, ensuring business operations are not completely interrupted by a failure in a single region.
Why Jtti's Hong Kong Node is Ideal as the Primary Node for High-Availability Architecture
Regardless of the switching strategy chosen, the network quality and stability of the primary node directly determine the final outcome. If the primary node frequently encounters issues, even the best failover mechanism becomes merely a form of "firefighting."
Jtti's Hong Kong CN2 VPS features optimized CN2 GIA return routes, providing direct connections from Guangzhou to the Hong Kong data center across all three major carriers without inefficient routing. Real-world testing shows an average latency of 40–63ms across these carriers: approximately 46ms for China Mobile, 67ms for China Unicom, and 76ms for China Telecom. For scenarios demanding extreme stability—such as high-frequency trading or API gateways—the CN2 GIA line maintains a packet loss rate consistently below 0.5%, with minimal latency fluctuation during peak evening hours.
Network quality serves as the first line of defense for high-availability architecture. A stable CN2 GIA connection significantly reduces the likelihood of "false failure" triggers; it prevents misidentifying downtime due to network jitter, thereby avoiding unnecessary failover operations.
The "same price for renewal" policy ensures that the initial purchase price remains the same for renewals. For businesses requiring long-term high-availability architecture, cost predictability is an integral part of operational planning.
DNS failover and rapid IP switching essentially build a "second line of defense" for your business operations. The first line of defense lies in the server's network quality and hardware stability, while the second is the automatic failover mechanism. Only by combining these two can a truly seamless, "imperceptible to the user" experience be achieved. Visit the Jtti official website to view the full specifications and current promotions for Hong Kong CN2 VPS, and choose a stable starting point for your high-availability architecture.
EN
CN