What is the Status Page

The Status Page shows connection details that can help with troubleshooting. If support instructed you to collect the info from this page, click the Copy results button at the top and send the results privately. The copied results do not include the verification probe error; support may need that error collected separately if verification fails.

🚧
Personal Information
Do not post these results in a public place, as they will contain personal information like your IP address and your Endpoint ID. Only provide this to support in an email or other non-public means.

What are all the sections?

IPv4/IPv6 Address

These rows show what your current ISP assigned IPv4 and IPv6 (if available) addresses are, as well as your ISP and country.

Using Control D

This row reports the result of a verification check made from the browser viewing the page. It works with both free and premium Control D resolvers, but does not verify every app or device on your network.

Using Control D: the check completed and detected a Control D resolver for the browser's DNS path.
Not using Control D: the check completed without detecting a Control D resolver for that path. Check the setup intended for this browser or device.
Unable to verify: the check failed to complete successfully, so the page cannot determine whether this browser is using Control D. Follow the steps below.

Unable to verify

Unable to verify means browser verification failed. It does not confirm that DNS is broken or that you are not using Control D. Normal DNS lookups may still work even when the Status page cannot complete its check.

The verification request can be affected by browser settings, extensions, VPNs, security software, or network restrictions. It can also fail because of a problem with Control D's verification service or the probe itself. These are possibilities to investigate, not a diagnosis from the message alone.

If normal DNS lookups work

If other sites and apps work, or a DNS lookup for an ordinary domain succeeds, treat this as a verification problem first rather than replacing a working DNS setup. Successful browsing alone does not identify the resolver in use.

Note your operating system, browser, and how you configured Control D: in the OS, on a router, in the browser, or through an app/ctrld. Review the matching setup instructions in the dashboard or self-provisioning flow; the Supported Platforms page explains the available setup types. A browser-only setup is not expected to change OS-wide DNS.
Inspect the browser's Secure DNS / DNS-over-HTTPS setting and compare it with your intended setup. A browser override is one possible explanation for a browser/OS mismatch, not something this message proves. If another resolver is explicitly configured there, use the browser's Control D setup instructions or your administrator's guidance to correct that mismatch. Do not disable security controls just to clear the warning.
Where a command line is available, use Check if DNS is working to compare the DNS path outside the browser. A successful command-line check does not prove that the browser uses the same path. On Windows with DNS Intercept Mode, follow the platform-specific testing guidance, since nslookup bypasses NRPT rules.

If normal DNS lookups also fail

Troubleshoot the DNS or connectivity failure separately; Unable to verify alone does not identify its cause. Check whether ordinary domains fail only in the browser or also in other apps/devices. Review the settings for the actual installation type: OS DNS settings, router DNS settings, browser Secure DNS settings, or the Control D app/ctrld status. For a managed device or network, ask your administrator to check the intended resolver and policy rather than changing them blindly.

What to send support

If you still cannot verify the connection, contact support privately with:

The time of the check and your time zone, OS/browser, and setup type.
The exact Unable to verify message, whether ordinary DNS lookups work, and whether the problem affects only the browser or other apps/devices too.
The current Copy results output. It is useful context, but does not include the verification probe error. If support needs that error, ask for instructions to collect only the relevant failed request/error separately.

Copied results contain personal information, including your IP address and Endpoint ID. Do not post them publicly. Do not send HAR files, cookies, or full console dumps; share only the specific diagnostic details requested through a private support channel.

Resolver

This will tell you your Endpoint ID (the premium resolver you're using). If you're using the free DNS service, this will always be N/A. N/A in the Resolver and DNS Protocol rows is expected for Free DNS and does not mean verification failed.

DNS Protocol

If you're using a premium DNS resolver, this will tell you what DNS protocol you're using:

Legacy
DNS-over-HTTPS
DNS-over-TLS
DNS-over-QUIC

Free resolvers will always show N/A.

DNS Latency

This tells you the exact latency to the closest Control D location that is serving your DNS traffic. If you ping dns.controld.com you should see approximately the same latency.

DNS Host

This shows you the hostname of a Control D server that is serving your DNS traffic. The first 3 letters will be an IATA airport code for the physical location.

DNS Source IP

This shows you the source IP as seen by the DNS server. In most cases this will match your IP address printed at the very top of the page.

Proxy Authorized

This tells you if your current DNS configuration is capable of redirecting traffic. If you see a red ❌ that means you either don't have any redirection rules in your enforced Profile, or something is wrong if you do have such rules, and they don't work. More on the solution below.

Proxy Latency

This is analogous to "DNS Latency", except it shows you the latency to the closest Control D location capable of serving redirected traffic. In some cases this will be identical to DNS Latency, but not always.

📘
Higher Latency than DNS
Every Control D location is capable of serving DNS traffic, but not every location can serve Proxy (redirected) traffic. If your closest DNS location is such a location, your proxy traffic will be sent to the next closest location that CAN serve it. Sometimes this location can be a lot further away, and have much higher latency.

Proxy Host

This is analogous to "DNS Host", except it shows you the hostname of a Control D server that is serving your Proxy (redirected) traffic. The first 3 letters will be an IATA airport code for the physical location.

Proxy Source IP

This is analogous to "DNS Source IP", except it shows you the source IP as seen by the Proxy server. In most cases this will match your IP address printed at the very top of the page, but this may not always be the case.

🚧
Different IP from DNS Source IP
If you see that this IP differs from DNS Source IP, this is an unusual situation, but can happen on some cellular networks that use IPv6. If you're not redirecting any traffic, then the mismatch is of no consequence. If you are redirecting your traffic, this mismatch can cause connectivity problems as this IP will not be authorized in the global firewall, and you will not be able to reach the proxy, so all redirected requests would fail.
There are 2 solutions to this problem if you happen to encounter it:

Disable IPv6 - this will solve the problem, but may not be possible on some cellular networks.

Manually authorize the mismatched IP.

New IPv4/IPv6 Address

If you're using Default Rule in Redirect mode, you will be assigned a Control D IP address that is visible to all websites and services you use, instead of your true IP at the top of the page. These rows will show you your new IP addresses (IPv4 and IPv6).