During website maintenance, server management, or domain name resolution debugging, many users encounter a common and confusing problem: the domain name resolution results obtained using nslookup are inconsistent with the IP address actually accessed by the browser. The same domain name showing different resolution pointers seems absurd, but it's very common in real-world environments.

　　This situation can not only lead to abnormal visitor access but also cause developers and site administrators to misjudge the direction of troubleshooting. To completely resolve the "inconsistent query results" problem, it's essential to understand the differences between various mechanisms such as nslookup, browsers, system DNS caching, recursive DNS, CDN, and the HTTP protocol.

　　Why are nslookup and browser resolutions different? What is the underlying reason?

　　Many people mistakenly believe that nslookup queries the DNS results actually used by the browser during access, but in reality, they are different. The differences mainly stem from the following factors:

　　1. Browsers use system caches and local DNS caches.

　　When accessing a website, browsers prioritize reading their own DNS cache, the operating system's DNS cache, and the hosts file. nslookup, however, does not read these; it directly queries the DNS server configured on your local machine. Therefore, when the local cache is not updated and the TTL has not expired, the browser and nslookup will resolve to different addresses.

　　2. nslookup does not use DoH/DoT by default, while browsers do.

　　Modern browsers (Chrome/Firefox/Edge, etc.) enable DoH and DoT by default. These technologies bypass the system DNS and directly use the browser's built-in encrypted DNS service, while nslookup uses the system's DNS settings (such as your ISP's DNS or a custom DNS). This causes them to resolve to completely different CDN edge nodes, thus returning different IPs.

　　3. Differences in IP service nodes due to CDN load balancing.

　　If your domain uses a CDN, when accessing the same domain, the CDN will automatically assign different edge nodes based on the client's network location. This means that the browser may access the nearest CDN node, while nslookup may query a node in a different region, so different IPs are normal.

　　4. Inconsistent Caches between ISP DNS and Public DNS

　　For example, a browser might use Cloudflare DNS via DoH, while nslookup uses the ISP's DNS. Due to differences in their caching systems and TTLs, the resolved IPs will naturally differ.

　　5. Some HTTPDNS/Apps Completely Bypass System DNS

　　Some software or SDKs (especially domestic apps) use HTTPDNS. If the browser or system has a similar mechanism enabled, resolution discrepancies will occur.

　　How to Determine Where the Discrepancy Occurs? Complete Troubleshooting Steps

　　Step 1: Check the Browser's Actual Resolution Results

　　Open Chrome and enter:

chrome://net-internals/#dns

　　Click "Clear host cache" to clear the cache, then access the target domain again. You can then view the actual IP address used by your browser.

　　Step 2: Check the system DNS cache

　　Windows：

ipconfig /displaydns

　　To clear the system cache:

ipconfig /flushdns

　　Mac：

sudo killall -HUP mDNSResponder

　　Step 3: Compare using different DNS queries

　　For example, you can query Cloudflare DNS:

nslookup yourdomain.com 1.1.1.1

　　Query Google DNS:

nslookup yourdomain.com 8.8.8.8

　　Query your local ISP's DNS:

nslookup yourdomain.com

　　If the three returns different results, it indicates that your domain name is being load balanced by a CDN, or that the DNS servers are in different cache states.

　　Step 4: Check if the authoritative domain name resolution is consistent

　　Use dig:

dig yourdomain.com +trace

　　The trace function starts from the root domain and traces up to the authoritative DNS server to see the final, actual resolution record.

　　If the authoritative server resolution is correct, but the public DNS query does not yield the correct result, it indicates DNS cache latency or a high TTL.

　　Step 5: Check if DoH/DoT is enabled.

　　Chrome checks DoH:

chrome://settings/security

　　If "Use secure DNS" is enabled, the browser will bypass the system DNS.

　　Effective methods to resolve inconsistencies between nslookup and the browser:

　　1. Clear the browser and system DNS cache. Nearly 30% of DNS problems are caused by caching.

　　2. Disable browser DoH to ensure it uses the same DNS as nslookup. For example, in Chrome, go to Settings → Security → Use secure DNS → Disable. This will ensure the browser's DNS resolution path matches nslookup's.

　　3. Shorten the TTL of DNS records to improve real-time update speed. For example, change the A record TTL from the default 3600 (1 hour) to 300 (5 minutes).

　　4. If using a CDN, understand that "inconsistent IPs in different regions" is normal. CDNs allocate different nodes based on geographical location. Since nslookup uses different DNS, it will naturally query different node IPs.

　　5. Fix DNS resolution issues caused by domain name configuration errors

　　Check if A records are pointing to multiple servers simultaneously? Are multiple CDN services running, causing conflicts? Are multiple CNAME records bound (a CNAME record cannot coexist with an A record)? Are there any ineffective configurations on the CDN platform?

　　Correct example:

example.com  CNAME  xxx.cdnprovider.net

　　Error example:

example.com  A      1.1.1.1
example.com  CNAME  xxx.cdnprovider.net

　　In summary, discrepancies between nslookup and browser resolution results are a very common and easily misunderstood phenomenon. The real reasons are often not errors in the domain name itself, but rather outdated browser caches, different DNS paths due to the use of DoH (Domain-Oriented Hierarchy), different CDN nodes, inconsistent DNS caching by the ISP, or excessively high TTL settings. Once you understand the differences between browsers and command-line tools, DNS debugging becomes clear and simple, and you will no longer be troubled by seemingly contradictory resolution results.