How URL Monitoring Works at Net Neutrality Monitor

When a website, app endpoint or online service seems unavailable, the cause is not always obvious. A failed connection may result from a DNS response, an ISP-level block, a routing problem, a server outage or a restriction applied only in a particular country. Submitting a URL for monitoring helps separate these possibilities with evidence collected from network probes.

Net Neutrality Monitor is a beta, volunteer-supported project developed and powered by AirVPN. Its results are intended for indicative research rather than legal certification or a guarantee that every user will experience the same outcome. For people in Australia, where access can vary between NBN providers, mobile networks and public Wi-Fi, a structured URL check can provide useful context.

Why Submit A Website For Monitoring

A monitoring request can help identify whether a domain is reachable from selected countries and whether DNS servers return a normal answer. This is useful when a site loads in Melbourne but not in Perth, works over a mobile connection but fails on home broadband, or appears unavailable only through one provider. Recording the URL gives the project a specific address to test instead of relying on a general report.

The result may also reveal a difference between a blocked domain and a broken service. If a website’s hosting platform is offline, probes may fail in several locations without indicating censorship. If DNS responses differ by country or network, the pattern may warrant closer review. The project’s data cannot establish intent by itself, but it can show where access conditions diverge.

Australian users may encounter these differences while switching between Telstra, Optus, TPG or smaller NBN retailers, or when moving from a home connection to a café network. Mobile data in Sydney can produce a different result from fixed-line access in regional New South Wales, even when the same phone and browser are used.

Prepare A Clear Monitoring Request

Before submitting a URL, identify the exact resource that needs checking. A complete web address is preferable to a vague description such as “the news site” or “the video service”. If the issue concerns a particular host, subdomain or IP address, record that detail separately. Avoid including passwords, private documents, tracking links or personal information in the submission.

A concise report gives reviewers enough context to reproduce the issue without turning the request into a personal support case. The service focuses on network accessibility and censorship signals, so details about browser extensions or account settings are useful only when they help explain a connection pattern.

Useful information to prepare includes:

• The full URL, domain or IP address
• The country and network where access failed
• The approximate date, time and connection type
• Any visible DNS, timeout or block-page message

It is also helpful to make a basic comparison before submitting. Try the address over fixed broadband and mobile data if both are available, and note whether the failure affects the whole domain or only one path. Australians often use home NBN, 4G or 5G interchangeably, so identifying the connection prevents a provider-specific problem from being mistaken for a nationwide block.

Keep the request focused on observable facts:

• What loaded, failed or redirected
• Which network or location was tested
• Whether the problem was consistent or intermittent

Submit The URL Through The Website

The submission process is designed to collect a URL or IP address for later review and monitoring. Enter the address carefully, preserve the correct protocol where relevant, and check that spelling, subdomains and unusual port numbers are accurate. A single incorrect character can send a probe to a different host and produce a misleading result.

If the form asks for comments, describe the access symptom in plain language. “The domain times out on an Australian NBN connection but loads through mobile data” is more useful than “blocked”. The latter is a conclusion; the former gives reviewers a testable observation. For guidance on available functions and project terminology, consult the help centre while completing the request.

Submitting a URL does not necessarily mean that an immediate public result will appear. Net Neutrality Monitor operates as a beta project with volunteer-supported analysis, so review timing and coverage can vary. Some addresses may need additional checking, may be unsuitable for automated probes, or may be queued until the relevant country and DNS measurements are available.

What The Monitoring Process Measures

After an address is accepted for review, probes can compare how it resolves and responds from different networks or geographic locations. DNS measurements may show whether a resolver returns the expected address, gives an error, redirects the request or provides no useful answer. These signals can be compared with connection-level results to identify a possible filtering pattern.

A failed probe is not automatically proof of censorship. Websites frequently use content delivery networks, geoblocking, rate limits, bot protection and rapidly changing infrastructure. A server may reject automated traffic while remaining available to ordinary visitors. Similarly, an IP address can host many unrelated services, so blocking it may affect more than the original domain.

The project can record several kinds of evidence, including blacklist entries, DNS observations, probe outcomes and statistical patterns. Each category answers a slightly different question. A blacklist may show that an address has been identified for attention, while a probe result shows what happened during a particular test. Their relationship matters more than any single status label.

How Probe Results Are Reviewed

Monitoring data becomes more useful when results from multiple locations agree. If probes in several Australian networks fail while overseas probes succeed, that is a stronger indication of a country or provider-specific access issue than one isolated timeout. If all locations fail, the likely explanations include an inactive server, a misconfigured domain or a service that rejects automated requests.

Reviewers may examine repeated measurements rather than relying on one test. DNS answers can change because of caching, resolver policy or the website’s own traffic management. A later successful check does not erase an earlier observation; it shows that accessibility can be temporary or inconsistent. Dates and measurement conditions are therefore important parts of the record.

For readers who want to understand country-level measurements, the probe data guide explains how to interpret the available evidence without treating every failure as a confirmed block. This is especially relevant when comparing an Australian result with observations from New Zealand, the United States or another market.

Reading Australian Results In Context

Australian access conditions are shaped by a mix of national regulation, commercial networks and household habits. The Online Safety Act 2021 gives the eSafety Commissioner powers in specific online safety areas, but a monitoring result is not a legal finding under that legislation. Net Neutrality Monitor shows technical reachability and filtering signals; it does not decide whether a restriction is lawful or identify the responsible authority.

Geography also matters. A user in Brisbane may reach a service through one NBN retailer while a user in Adelaide sees a DNS error, and a traveller using hotel Wi-Fi in Perth may encounter yet another result. Congestion, resolver configuration and security filtering can all affect the comparison. A report should therefore state the network and approximate location rather than simply saying “Australia”.

Everyday usage creates further complications. Streaming services, gaming platforms, social networks and cloud applications rely on multiple domains, so a visible app failure may originate from an API or content host that the user never typed. Testing the exact failing hostname can be more informative than submitting the brand’s homepage. The project’s published reports provide broader country and address-level context for this kind of comparison.

Use The Evidence Carefully

Monitoring results are most valuable when treated as a starting point for verification. Compare the timestamp, country, network type, DNS response and probe behaviour before drawing a conclusion. A result marked as unreachable may describe a narrow technical condition rather than a universal ban. Conversely, a repeated pattern across independent measurements deserves more attention than a single successful browser visit.

The following distinctions help keep a report precise:

Observation	What it may indicate	What it does not prove
DNS failure in one network	Resolver filtering, misconfiguration or an outage	That the website is blocked nationwide
Connection timeout from several probes	Routing trouble, server downtime or filtering	Who caused the failure
Different answers by country	Geolocation, DNS policy or access restriction	That the difference is unlawful
Repeated failure with a block page	Deliberate handling by a network or intermediary	That every user sees the same page
Successful access after a later test	Temporary fault or changed network conditions	That earlier measurements were invalid

When documenting a submission, preserve the original URL, note whether it was tested on NBN or mobile data, and record the approximate time in Australian local time. Avoid adding sensitive account details. The practical takeaway is to submit a precise address with observable network context, then read the resulting measurements as evidence of access conditions rather than as a final verdict on censorship.