Understanding the DNS Leak Tester

The DNS Leak Tester is a specialized, client-side network utility designed to verify your apparent public-facing IP address and connection routing. Built on the Alpine.js framework, it performs asynchronous cross-verification using established CDN and API endpoints to help confirm whether your VPN, proxy, or secure tunnel is properly masking your true network identity.

How the Detection Engine Works

At its core, this tool does not rely on server-side processing or backend databases. Instead, it leverages your browser's native Fetch API to communicate directly with trusted diagnostic endpoints. Here is a step-by-step technical breakdown of its internal mechanics:

• Primary Trace via Cloudflare: The tool initiates its check by sending a request to https://www.cloudflare.com/cdn-cgi/trace. This endpoint acts as a CORS-friendly diagnostic tool that returns your connection parameters as plain text. The script parses this raw text by trimming whitespace, splitting the payload by newline characters (\n), and mapping each line by splitting at the equals sign (=). It then uses Object.fromEntries() to create a structured object containing your connection variables, specifically extracting the ip and loc (location country code) values.
• Cross-Verification via Ipify: To ensure accuracy and provide a fallback, a secondary asynchronous request is made to https://api.ipify.org?format=json. This JSON response provides an independent secondary confirmation of your public IP address.
• Data Aggregation: The application merges these responses into a single reactive data object. It prioritizes the IP address obtained from the Cloudflare trace, but falls back to the Ipify result if the trace IP is undefined. The location relies strictly on Cloudflare's regional routing data, defaulting to "Unknown (Protected)" if missing.
• Fail-safe and Error Handling: If the network requests fail—which can occur due to aggressive ad-blockers, network drops, or strict firewall rules preventing third-party API calls—the tool catches the exception. In the catch block, it immediately flags the connection state with a warning by setting the leaked boolean to true. It sets the IP to "Detection Blocked" and the location to "Check VPN Settings", proactively treating the failure as a potential tunnel collapse.
• Visual Feedback: While the asynchronous network requests often resolve in just a few milliseconds, the interface utilizes a setTimeout function within its finally block to enforce a 1,500-millisecond visual delay. During this time, a CSS-animated "radar sweep" is displayed, providing a clear state change before rendering the final parsed results.

Data Points Displayed

Once the verification cycle concludes, the user interface updates reactively to present a structured summary:

• Status Banner: A dynamic alert box that toggles its state based on the leaked boolean. On success, it applies a bg-success-light class with a green checkmark indicating a safe status. On failure, it switches to a bg-danger-light class with a warning icon.
• Connection Info: Displays the final determined Public IP address alongside the associated geolocation code (e.g., "US", "GB").
• Verification Sources: A table detailing the endpoints queried. It highlights the "Cloudflare Network" as the primary source, lists the detected IP, and tags it with a "Verified" badge. It also populates a Primary DNS fallback row utilizing the same trace IP.

Worked Example

Let's walk through a concrete scenario of what happens under the hood when you interact with the tool.

Action: You click the main "Start Test" button.

Execution:

1. The interface state switches to analyzing = true, hiding the button and revealing the spinning radar animation.
2. The script fetches the Cloudflare trace endpoint. Suppose the endpoint returns the following plain text payload:
   fl=24f122
h=www.cloudflare.com
ip=198.51.100.42
ts=1672531200
visit_scheme=https
uag=Mozilla/5.0...
colo=ORD
sliver=none
http=http/2
loc=US
3. The script executes its text transformation, converting this block into an object where traceData.ip equals 198.51.100.42 and traceData.loc equals US.
4. Simultaneously, the Ipify fetch resolves, returning a JSON payload: {"ip": "198.51.100.42"}.
5. The Alpine component assigns the final result object, mapping the IP to 198.51.100.42 and the location to US, while explicitly setting leaked: false.

Result: After the mandated 1.5-second animation delay concludes, the results panel is rendered. It displays "198.51.100.42" under Public IP, "US" under Location, and presents a green status banner confirming the connection parameters.

Frequently Asked Questions

Why does the test show my location as a two-letter code instead of a specific city?

The tool determines your geographical location using the loc parameter extracted from Cloudflare's CDN-CGI trace. This specific endpoint returns standard ISO 3166-1 alpha-2 country codes (such as 'US', 'CA', or 'DE') based on the physical location of the Cloudflare data center (the colo code) that handled your HTTP request. It does not utilize an exact, city-level IP geolocation API, which ensures faster response times and relies on routing data rather than third-party geo-databases.

What happens if my browser blocks third-party cross-origin requests?

Because the tool operates entirely client-side and relies on cross-origin resource sharing (CORS) requests to Cloudflare and Ipify, any strict browser extension (like Privacy Badger, uBlock Origin, or Brave Shields) that intercepts these outgoing requests will trigger the script's error handler. When the fetch request fails, the tool's catch block activates, defaulting the IP address to "Detection Blocked" and displaying a red warning banner indicating a potential connection issue.

Does this tool generate unique subdomains to test DNS servers?

No. This specific implementation focuses on verifying your apparent public IP address and connection routing via the Cloudflare network and Ipify. It does not perform the traditional DNS leak methodology of resolving uniquely generated, non-existent subdomains to capture backend resolver IPs. Instead, it serves primarily as a tunnel verification and public IP sanity check to ensure your proxy or VPN is actively modifying your outbound IP address.

Why is there a delay before showing the final results?

Even though the API requests to Cloudflare and Ipify are highly optimized and usually complete in well under 200 milliseconds, the application deliberately enforces a hardcoded 1,500-millisecond delay (using setTimeout) within its asynchronous finally block. This ensures that the user interface always displays the visual radar scanning animation for a reasonable duration, preventing a jarring flash of content and confirming that a new, active test cycle has been fully executed.