MyIP.dogChecking…
IP testing methodology
How address observations, DNS queries, registry lookups and subnet calculations are performed and interpreted.
Last updated: 2026-09-28
How address observations, DNS queries, registry lookups and subnet calculations are performed and interpreted.
Last updated: 2026-09-28
Checking…
IP testing is useful when the operation matches the question. Observing a browser's source address, reading a registration record, and calculating a subnet are different operations with different evidence. This methodology explains those boundaries so a result can be interpreted accurately. IP testing should not turn a successful request into a general claim about privacy, location, ownership, or the health of an entire network.
The basic reporting pattern is to identify the input, perform the stated operation, preserve the relevant output, name the source, and explain important limits. For live requests, the observation time also matters. IP testing results can change after a network switch, provider reassignment, DNS update, VPN change, or browser configuration change. A saved result describes an earlier observation and should not silently be presented as current.
The homepage's primary task is to show the public source address associated with the browser connection. In a supported Cloudflare Worker environment, trusted edge metadata can provide the address before external lookups finish. IP testing does not need to wait for a city database, a map, or a blog query to display that observation. Other fields can remain unavailable without making the address itself disappear.
The trust boundary is essential. Arbitrary X-Forwarded-For values from the public internet are not reliable evidence of the original visitor. IP testing must know which infrastructure supplied a forwarding header before trusting it. The implementation checks its runtime context rather than treating header presence alone as authorization. On a direct server connection, a supported peer address can be used without trusting a caller's forwarded value.
When the server lacks a trusted public source, the browser can request its address from the disclosed ipify endpoint. That is a different observation and is labeled accordingly. IP testing must not call an external “my address” service from the backend and show the backend's address to the visitor. The fallback runs in the browser because the browser's connection is the one being measured.
Personalized address responses are marked private and no-store. The implementation also separates concurrent request context so one visitor's address is not stored as a global result. IP testing involving live visitor data requires these boundaries: a correct address becomes an incorrect result if a shared cache or global variable gives it to another person. Deployment cache rules must preserve the same restriction.
The IPv6 tool performs two independent browser requests, one to an IPv4-only endpoint and one to an IPv6-only endpoint. Each request has a bounded timeout. IP testing reports the observed address when the endpoint responds successfully. It reports an endpoint failure when the request does not complete under those conditions. The failed operation is not relabeled as proof that the operating system has no IPv6 configuration.
A single dual-stack request reveals only the family chosen for that connection. Separate endpoint requests answer a narrower and more useful comparison question. Even then, IP testing does not establish reachability to every destination or the routes used by every application. VPN split tunneling, privacy relays, network translation, filtering, and browser configuration can produce differences that require additional evidence.
The IP comparison starts several named browser HTTP requests in parallel. This IP testing path does not use our backend as a relay and does not substitute another provider when one destination fails. Each request has an eight-second limit and a bounded response body. Only valid public addresses enter the comparison, and IPv4 is evaluated separately from IPv6. Matching IP testing observations carry an explicit coverage count; a missing destination remains unmeasured. The displayed HTTP completion time includes connection and service work, so it is not ICMP latency. Regional labels require separately configured nodes and do not identify a visitor's physical location or another website's observed exit.
DNS lookup sends a selected record question to Google Public DNS over HTTPS from the server. Reverse DNS constructs the address's reverse name and requests PTR records through the same resolver. IP testing preserves the answer rows, record types, TTLs, response code, and authenticated-data flag. It does not reduce all empty results to a generic “not found,” because the protocol distinguishes several important conditions.
NOERROR without an answer differs from NXDOMAIN, and SERVFAIL indicates a different failure again. A resolver's authenticated-data flag is also a scoped statement about DNS data, not a rating of a website's safety. IP testing explains these distinctions near the result. The requested name is sent to the provider, so confidential internal hostnames should not be entered casually into a public diagnostic.
These requests do not identify the recursive resolver normally used by the visitor's browser. IP testing for DNS leakage would require session-specific names and an authoritative observer able to associate the resulting DNS queries with the test. A server-side DoH request cannot supply that evidence. Accordingly, ordinary DNS lookup is not represented as a working DNS leak test.
The registration tools classify the address, consult the appropriate IANA bootstrap directory, and request a matching network record from a supported regional internet registry. IP testing constrains the allowed registry destinations and checks redirects before following them. A typed address cannot become an arbitrary fetch URL. The resulting record is interpreted as registration data, with its source and retrieval time.
The displayed range, network name, handle, and type describe the returned object. Registration country is labeled as registration country. IP testing does not convert it into a physical location estimate. The registered holder can be a provider or another organization several steps away from the end user, and shared public addresses can represent many users. The result is not a personal identification service.
The domain WHOIS lookup complements address-based IP testing with exact-name registry RDAP queries. It selects the longest whole-label match in IANA's domain directory, validates the returned object class and name, and does not fetch registrar referrals. IP testing keeps a registry 404 distinct from missing directory coverage, restricted access, malformed responses and transport failure. Domain summaries preserve entity nesting and explicit redaction notices; missing contact fields do not prove privacy protection. DNSSEC declarations are reported as registry fields, not live signature validation. Display limits are flagged, and no registration query establishes purchase availability.
The ASN tool uses RIPEstat to associate a public address with a matching prefix and its observed origins, or to inspect a number's overview. IP testing preserves multiple returned origins and separates holder descriptions from subscriber identity. The response retrieval time is not presented as the age of the underlying routing measurement. Source query windows remain visible when provided.
This form of IP testing does not send packets to the queried address or check its application services. A negative origin status follows the source's visibility threshold and can include transit-only networks. Special-use numbers are classified from published ranges without an upstream lookup. These distinctions keep IP testing failures, missing observations and local classifications from becoming unsupported outage claims.
The WebRTC test begins only on request, gathers browser ICE candidates through a named STUN endpoint, and compares readable public addresses with fresh same-family HTTP references. This IP testing path uses no media permissions or remote call. Local and mDNS candidates remain distinguishable; relay addresses are excluded from subscriber-address comparisons.
IP testing ends candidate collection on completion, cancellation, browser error or a twelve-second deadline and closes the connection. A timeout preserves partial evidence. Missing references, reported STUN errors and absent public candidates prevent a complete matching conclusion. A difference is presented as an observation requiring context, not proof of a failed VPN. This IP testing method does not measure DNS routing or other applications.
The HTTP headers check adds application-response evidence to IP testing. It uses public remote HEAD measurements with fixed public destinations and a maximum of five responses. Every redirect is revalidated. IP testing records incomplete, truncated and unverified TLS observations explicitly; a field-presence review is not a security grade. Targets, URL paths, queries and results are public at the provider.
The ping test and online traceroute submit one public target to one Globalping probe after the visitor starts the operation. This IP testing method pins a hostname to one validated public address selected through Google Public DNS. It requests five packets for ping; TCP uses port 443, while traceroute also offers the provider's UDP mode. The actual remote origin, protocol, target, source link, and latest timestamp stay visible. IP testing preserves partial results, missing hops, failed probes, and absent RTT statistics instead of manufacturing a health score. Collection stops at its deadline or on request, but the remote measurement may continue. The provider's targets and results are public; this IP testing path cannot establish local device latency, application availability, or a complete physical route.
The port checker initiates one TCP connection per selected port from the site server to a validated public address. Fixed presets check four or six ports sequentially against that same selected address, within a thirty-five-second total budget. This IP testing operation pins hostname resolution before opening a socket, sends no application payload and closes the socket after an outcome, abort or five-second deadline. A connection event establishes TCP reachability for that attempt; it does not establish TLS or application health. IP testing keeps refusal, timeout, unreachable routes and runtime restrictions separate. Stops and page departure invalidate browser results, while a server attempt can continue until its own deadline if cancellation does not reach it. IP testing reports the actual origin as the site server without inventing a probe location.
Subnet calculations use integer arithmetic for both IPv4 and IPv6. The implementation derives the network boundary, last address, mask, and exact range size from the prefix. IP testing of this arithmetic includes zero-length prefixes, single-address prefixes, IPv4 point-to-point pairs, and large IPv6 values. The calculator does not contact devices in the range, so it cannot report which addresses are occupied.
Conventional IPv4 usable-host counts exclude network and broadcast values when the prefix supports that model. The /31 case assumes a point-to-point link, and /32 is treated as one address. IPv6 has no IPv4-style broadcast output. IP testing keeps mathematical totals distinct from operational assignment rules, reserved addresses, router requirements, DHCP plans, and provider routing policy.
Address classification identifies common private, shared, loopback, link-local, multicast, documentation, and reserved cases. It rejects ambiguous legacy IPv4 forms, URLs, ports, and interface suffixes in public lookup inputs. IP testing should make normalization explicit so equivalent IPv6 text can be compared and an IPv4-mapped socket address is not mistaken for evidence of native IPv6 connectivity.
A provider can time out, return an error, omit a field, or provide a valid response with no matching data. IP testing distinguishes these cases wherever the source allows it. Missing information stays missing. A failed measurement does not trigger an invented result, and an older observation is not silently assigned a new measurement time. The interface should tell you whether a visible value belongs to an earlier successful check.
No single measurement covers every privacy or connectivity risk. IP testing here does not automatically prove VPN safety, anonymity, exact location, historical ownership, or universal reachability. A useful next step depends on the uncertainty: compare a known baseline, inspect local settings, query the authoritative source, or gather evidence from the application that actually fails. Strong conclusions require evidence that addresses the relevant alternatives.
Record the page, exact query, address family, source, observation time, active network, and VPN state. Change one condition at a time when comparing results. IP testing becomes much easier to review when a second person can ask the same question and understand the environment in which it was asked. Remove passwords, authentication cookies, unrelated account details, and confidential names before sharing a report.
The data sources page links the providers and standards behind these operations. Tool guides explain common interpretation mistakes and provide examples. IP testing remains an evidence-gathering process rather than a promise that every possible network condition has been reproduced. When behavior and documentation disagree, the discrepancy should be investigated and corrected without overstating either the measurement or the written explanation.
The internet speed test sends bounded sequential requests directly from the browser to Cloudflare’s measurement endpoints. This part of IP testing uses our own browser transport, not the Cloudflare SDK. It warms the connection, takes ten idle HTTP time-to-first-byte samples, then runs download and upload size groups. Usable transfer rates are summarized at the ninetieth percentile, with server time included and samples shorter than ten milliseconds excluded.
Speed-related IP testing validates response size and exposed Resource Timing data. Cached, mismatched or restricted timing cannot establish a throughput result. Concurrent HTTP latency is labeled separately and does not certify link saturation. IP testing preserves stop, timeout and missing states; generated payload budgets exclude wire overhead and are shown before the explicit start action. No separate results-logging request is sent. Read the tool’s sample table and complete measurement explanation for the current mode limits and arithmetic.
Mail-focused IP testing queries SpamCop and PSBL through Google Public DNS. Each IPv4 lookup first validates positive and negative controls; failed controls prevent that source’s target query. IP testing preserves response codes, cache lifetimes, source coverage and unavailable states. IPv6 is explicitly unsupported by this integration, and negative answers do not certify mail delivery or safety.
Forward-name IP testing sends separate A, AAAA and CNAME questions to Google Public DNS. It follows only returned alias owners, limits path inspection to sixteen hops and preserves each query’s errors and times. This IP testing does not connect to resolved addresses. CDN suffix hints cite documented naming patterns; they do not establish delivery, origin location or ownership.
The CIDR calculator extends local IP testing with exact range covers, network unions and paged subdivisions. Host-bit normalization is disclosed, address gaps are preserved, and counts use arbitrary-precision integers. Calculation inputs are not sent to a provider. This IP testing path describes mathematical coverage, not usable-host policy or routing authorization.