How can I tell if a website's inaccessibility is due to DNS caching or a server malfunction?

　　When a website is inaccessible, 80% of people's first reaction is "the server is down," but the actual problem is often "DNS not updated" or "local cache expired." These two issues look so similar that some people assume the server has crashed and frantically restart it three times, only to find that their router's DNS cache hadn't been refreshed; others firmly believe it's a DNS problem, wait two hours, and finally discover that the fiber optic cable in the data center has been severed. Distinguishing between these two issues doesn't rely on intuition, but rather on a few commands.

　　I. First, understand what DNS caching problems and server crashes look like.

　　Before starting any diagnostics, you need to know the "symptoms" of each type of failure.

　　1. DNS Caching Problems

　　DNS caching problems are essentially "calling the wrong address"—the address you have is outdated, and the IP address the domain name resolves to is no longer the IP address currently used by the server.

　　Typical Symptoms:

　　On the same network, computer A cannot access the website, but computer B can access it normally.

　　Mobile phones cannot access the website via Wi-Fi, but can access it normally by switching to 4G/5G mobile data.

　　Browser displays errors such as "Unable to resolve the server's DNS address" or "ERR_NAME_NOT_RESOLVED".

　　The IP address returned by pinging the domain name is inconsistent with the IP address set by your domain registrar.

　　Switching to a different DNS server (e.g., changing from the default to 114.114.114.114) restores normal functionality.

　　Common Causes:

　　The domain's A record or CNAME record was recently modified before the TTL expired.

　　The local operating system's DNS cache has not been refreshed.

　　The browser's built-in DNS cache (Chrome and other browsers have independent cache pools).

　　The router's or LAN gateway's DNS cache.

　　The ISP's recursive DNS server cache has not been updated.

　　2. The Server Itself is Down

　　A server downtime means the address is correct, but the door is locked or no one is inside—the IP can be resolved, but the service port is not responding, or the server is physically offline.

　　Typical Symptoms:

　　Directly accessing the server via IP (bypassing DNS resolution) also fails.

　　Other ports on the same server (e.g., SSH port 22) are also inaccessible.

　　Ping the server IP is successful, but the web service's ports 80/443 are unresponsive.

　　Inaccessibility is impossible from multiple different networks and regions.

　　The server console (VNC/IPMI) shows system freezes or kernel errors.

　　Common Causes:

　　Process crashes (Nginx/PHP-FPM/MySQL crashes)

　　System resource exhaustion (memory failure, CPU overload, disk I/O blockage)

　　Firewall or security group rules mistakenly blocking

　　Cloud service provider data center failure or network cutover

　　Server attack causing excessive bandwidth usage

　　These two situations appear almost identical—browsers both display "This website cannot be accessed." However, the diagnostic approaches are completely different; going in the wrong direction wastes time.

　　II. Diagnostic Process: Follow the steps in order, don't skip steps.

　　Below is a set of troubleshooting steps proven in practice. Strictly follow the order; don't immediately suspect the server is down, and don't immediately clear the cache. Step 1: Access Directly by IP

　　This is the most crucial step. Access http://server IP (or https://server IP) directly using your browser. If there's an SSL certificate warning, ignore it and continue.

　　If you can access it → the server itself is working properly, and the web service is running. The problem is 100% with domain name resolution or DNS. Skip to step 3 to check the DNS.

　　If you cannot access it → don't jump to conclusions. It might be a forced SSL redirect or Nginx only binding the domain name and not listening on the IP. Proceed to step 2.

　　Step 2: Test the Server Port

　　If IP access fails, test the port using telnet or nc:

　　If the port is accessible (showing Connected) → the service process is running. It might be an Nginx/Apache configuration issue (e.g., only binding the domain name and not the IP, or incorrect SSL configuration). Check the web server configuration.

　　If the port is inaccessible (showing Connection refused or timed out) → the service process is not running, or it's blocked by the firewall. Continue logging into the server via SSH to check the process status. If SSH also fails to connect, the server is truly down—check the instance status in your cloud service provider's backend; a forced restart may be necessary.

　　Step 3: Check DNS Resolution Results

　　If you can access the server using the IP address in Step 1, or if Step 2 confirmed the server port is accessible, the problem lies with the DNS.

　　If @8.8.8.8 returns the same IP as your server, but your local `dig` or `nslookup` returns an old IP → Indicate: your local DNS cache or ISP recursive DNS cache is not updated.

　　If all DNS servers return incorrect IPs (inconsistent with the IP you set at your domain registrar) → Indicate: the DNS records are not effective or have been tampered with. Check the records in your domain registrar/DNS service provider's console.

　　If no records are found (NXDOMAIN) → Indicate: the DNS records have been deleted, or the DNS server configuration is incorrect.

　　Step 4: Sniff Your Browser's DNS Cache

　　Many people overlook this step. Browsers like Chrome and Edge have their own independent DNS caching pools, independent of the operating system.

　　Click "Clear host cache" to clear your browser's DNS cache, then refresh the page and try again. If the website opens after clearing the browser cache, the problem lies with the browser cache, not the server.

　　Step 5: Check your local hosts file for hijacking.

　　Sometimes it's not a DNS issue, but rather that someone has added hard DNS entries to your hosts file, or you modified it during previous testing and forgot to delete it.

　　Windows: C:\Windows\System32\drivers\etc\hosts

　　Linux/macOS: /etc/hosts

　　Don't panic if your website is inaccessible. Follow the steps above step by step; you should be able to locate the problem within ten minutes.

　　In most cases, the conclusion that "the server is down" comes too easily—you instinctively think it's a server problem and start investigating in that direction, only to find out you're going in the wrong direction after a long time, wasting valuable troubleshooting time.