A complete guide to how the Connection Inspector combines DNS, reverse DNS, geolocation, and reachability checks, and why it can't show hop-by-hop routing like a traceroute.
Launch the Connection Inspector →The Connection Inspector is a combined diagnostic tool that runs several distinct checks against a single domain or IP address in one pass: forward DNS resolution, reverse DNS (PTR) lookup, approximate IP geolocation, and repeated HTTPS reachability probes to measure average response time. The results are presented both as a summary panel (Target Host, Resolved IP, Reverse DNS, Reachability, Average Response Time, Approximate Geolocation) and as a scrolling log showing each individual step as it happens.
This tool exists to consolidate several checks that would otherwise require using multiple separate tools in sequence — a DNS lookup, a reverse DNS lookup, a geolocation lookup, and a reachability test — into a single "give me the full picture on this host" action, which mirrors how a network administrator often actually wants to triage an unfamiliar domain or IP address during initial troubleshooting.
The tool's own on-page notice states this directly: browsers cannot send raw ICMP or UDP traceroute packets, nor can they read the hop-by-hop router replies that a real traceroute depends on, because that requires low-level operating-system network access that no website is ever granted by any browser, for the exact same security reasons explored in depth in the Ping Tool's documentation.
This matters enough to call out explicitly because a traceroute (the traceroute command on macOS/Linux, or tracert on Windows) works by sending a sequence of probes with progressively increasing TTL (time-to-live) values, and reading the "TTL expired" responses sent back by each intermediate router along the path, building up a hop-by-hop map of the route your traffic takes to reach a destination. Every single step of that process depends on raw socket access to craft and send specifically-formed packets, and on receiving ICMP error responses from routers that are not even the final destination — capabilities that are completely outside what a browser's JavaScript environment is allowed to do.
Because of that, every probe this tool sends targets the exact same final destination IP address shown in the Target IP field, not a sequence of different intermediate routers. The tool is explicit about this on the page itself specifically so users don't misread the repeated response-time measurements as hop-by-hop timing data the way a real traceroute would present it. What it does provide instead — repeated timing measurements against the single final destination — is still genuinely useful for understanding latency and consistency to that one specific endpoint, just not the path getting there.
Forward DNS resolution uses the same DNS-over-HTTPS technique described in detail in the DNS Propagation Tool and NSLookup Tool documentation: a request to a public DoH resolver's JSON API, asking for the A record of the hostname entered. If you enter a raw IP address instead of a hostname, this step is skipped since there's nothing to resolve.
Reverse DNS (PTR) lookup works in the opposite direction: given the resolved IP address, it asks whether that IP has a PTR record pointing back to a hostname. This is commonly used to check how a mail server or hosting provider has configured its reverse DNS, since many email systems check that an incoming mail server's IP has a matching, sensible PTR record as a basic spam-filtering signal.
Approximate geolocation uses the same category of third-party geolocation API approach detailed extensively in the Check My IP Address tool's documentation — a request to a geolocation provider that maps the resolved IP address to an approximate city, region, and country based on that provider's own internal database, with the same accuracy caveats that apply to any IP geolocation lookup.
Reachability and average response time uses the same favicon-based HTTPS timing technique described in depth in the Ping Tool's documentation: a series of timed fetch() requests to the resolved IP address, measuring how long each one takes to complete or time out, then averaging the successful results.
Each of the four checks performed here already exists as its own dedicated, more detailed tool elsewhere on NexTechTools: the NSLookup Tool for deep DNS record queries, the Check My IP Address tool for geolocation (applied to your own address), and the Ping Tool for reachability timing. The Connection Inspector exists for a different purpose: a fast, single-pass overview when you're starting from scratch on an unfamiliar host and want a general sense of what's going on before deciding which deeper tool to reach for next.
This mirrors a common real-world workflow: when investigating a problem with an unfamiliar domain, the first step is usually a quick "what is this, where does it point, and does it respond" check, with deeper diagnostics (specific record types, detailed packet-level reachability testing, full certificate inspection) reserved for whatever the initial overview suggests actually needs attention.
Inspecting an unfamiliar IP address found in a server access log might reveal that it resolves to a hosting provider in a specific country, has no reverse DNS entry configured (common for addresses used in automated scanning or hosting burstable traffic), and responds with moderate but consistent latency — collectively useful context for deciding whether that traffic looks like a legitimate visitor, a bot, or something worth blocking.
It's common for this tool to return a mix of successful and empty results on the same host, and each combination tells a different story worth understanding rather than treating any blank field as an error:
Because this tool runs each check independently and reports exactly what it found rather than trying to synthesize a single pass/fail verdict, it's designed to give you the raw signal and let you apply the right context, which is usually more useful for real troubleshooting than an oversimplified good/bad indicator.
Each individual check this tool performs — the DNS lookup, reverse DNS lookup, geolocation request, and reachability probes — is sent directly from your browser to the relevant third-party service (a DoH resolver, a geolocation provider, or the target host itself for the reachability probes). NexTechTools does not operate a server in any part of this flow and does not log, store, or see the hosts you inspect or the results returned.
Because the reachability probes are genuine HTTPS requests sent to the target host, that host's own server logs will show a request originating from your IP address, exactly as they would from any other visitor making a normal web request.
Showing hop-by-hop routing information is what a traceroute does, and browsers cannot send the raw ICMP/UDP packets a real traceroute depends on. This tool instead performs repeated timing checks against the single final destination, which is explained directly on the page and in detail in the Why This Tool Doesn't Show Hop-by-Hop Router Information section above.
Not every IP address has a PTR record configured. Many consumer internet connections, cloud instances, and even some business servers simply don't have reverse DNS set up, which is a normal and common configuration, not a tool malfunction.
No. IP-based geolocation is a database estimate based on how IP address blocks are allocated, not a live positioning signal, and carries the same accuracy limitations described in detail in the Check My IP Address tool's documentation.
Yes — entering your own domain gives you a quick combined view of whether it resolves correctly, whether reverse DNS is configured as expected (relevant mainly for mail servers), and whether it's responding promptly, all from a vantage point outside your own network.