How to report a broken or inaccurate probe result to our team

A failed probe can indicate censorship, but it can also result from a DNS error, a slow server, a denied application request or a fault in the monitoring path. Reporting a broken or inaccurate measurement therefore helps protect the credibility of Net Neutrality Monitor’s published findings. The goal is not to demand a censorship finding; it is to give the team evidence that can be checked, classified and, where warranted, corrected.

Net Neutrality Monitor is a beta, volunteer-supported project developed and powered by AirVPN. Its reports combine blocked websites and addresses, blacklist information, probe outcomes, DNS data and statistics across countries. Because these figures are supplied for indicative research rather than as definitive verdicts, a well-documented anomaly can materially improve how the results are interpreted.

For Australian contributors, timing and network context matter. Record the local time and UTC offset: AEST is UTC+10, while AEDT is UTC+11 where daylight saving applies. A result obtained through an Australian internet service provider may also differ from one collected through a DNS resolver, mobile connection or remote hosting network, so those details belong in the report.

A useful submission identifies the exact record, the expected and observed behaviour, and the conditions under which the discrepancy occurred. It should include evidence another reviewer can use while omitting passwords, session tokens and personal information. Clear reports save the volunteer team from repeating every preliminary test and make it easier to decide whether a probe, blacklist entry or statistical result needs revision.

Understand what the probe result measures

A probe result is evidence about one observation under particular conditions, not a universal verdict about a website or network. Depending on the check, the result may describe DNS resolution, HTTP reachability or the failure to complete a connection. A timeout, connection refusal and HTTP error status are different symptoms and should not be grouped under a single “blocked” label without further evidence.

DNS introduces another layer of uncertainty. Different resolvers can return different addresses because of content delivery networks, split-horizon DNS, caching or resolver-level filtering. A resolver serving Sydney, Melbourne or Brisbane may therefore return a different destination from another Australian resolver for the same domain. This variation can affect the subsequent web request even when DNS itself is working correctly.

If the meaning of a published field remains unclear, the community forum is the appropriate place to ask for clarification before submitting a full report. Mention the affected probe or domain and quote the displayed result, but avoid posting login credentials or links containing private access tokens. Direct discussion can prevent a genuine measurement issue from being mistaken for censorship.

Reproduce the discrepancy before submitting

Repeat the check using the same URL, port, path and request method where possible. A browser request can succeed where a scripted request fails because of JavaScript, cookies, automated-access controls or a missing redirect. Record the complete HTTP status code, error text and timing rather than writing only that the destination was “unreachable.” Include the destination address returned by DNS if it differs from the submitted IP address.

Compare DNS resolution and HTTP access separately. A domain may resolve correctly while its web server refuses the request, or a web request may time out before DNS information can be interpreted. Testing from more than one connection can help isolate the cause, especially when an Australian fixed broadband service such as Telstra, Optus or Aussie Broadband behaves differently from a mobile network or another resolver.

The practical impact of an apparent outage is also relevant. If the affected content is an emergency or community-safety page, the information maintained by the Australian Public Safety Association can help establish what public-facing services Australian communities expect to remain accessible. That comparison provides context; it does not turn an unreachable page into proof of filtering.

Give the team evidence that can be verified

Start with a stable target and an exact reference. Provide the full URL, including its scheme, port and path, or the IP address under investigation. Quote the probe identifier, measurement type and timestamp. For a URL containing a query string, remove session identifiers or unrelated personal parameters while preserving enough detail to identify the resource. If the address has never been monitored, use the site’s submission route for a URL or IP address rather than treating an ordinary access failure as a report about an existing probe.

Describe the measurement environment. State the Australian internet service provider or network operator, connection type, DNS resolver and resolver IP address when known, approximate location, device and testing software. Also note whether a VPN, corporate proxy, captive portal, antivirus filter or parental-control system was active. A controlled probe should not accidentally inherit a restriction created by the tester’s own environment.

Attach concise, redacted evidence. Useful material includes relevant log lines, status codes, DNS responses, error messages and screenshots showing the record identifier and timestamp. Preserve the original files so later checks can be compared without editing them out of context. Where the issue concerns measurement design or the classification of filtering, the ICTD research network offers relevant background for understanding reachability tests and Internet measurement methods.

Separate filtering from ordinary access failures

An HTTP 403 may reflect an application’s access controls rather than network censorship, while a 404 can mean that a page has moved or never existed. A 451 response commonly identifies a legal restriction, although the status alone does not establish who imposed it. TLS handshake failures may result from certificate, protocol or server configuration problems. Each explanation should be tested rather than assumed.

Regional policies and commercial account rules can also affect Australian users. Australia’s online betting and payments market differs from many overseas markets, with licensed operators and payment providers applying their own state, country and account conditions. A payment-flow explainer such as the Skrill deposit guide illustrates why redirects, regional restrictions and account-specific checkout rules can change the destination encountered during a transaction. These differences should be considered before an unavailable payment page is classified as filtering.

Look for corroboration within the project’s data. Compare the affected result with other probes, published blacklist entries and DNS observations from similar Australian networks. One isolated outlier may indicate a faulty measurement; a repeated pattern may justify stronger scrutiny, but the pattern should not be overstated. The report should distinguish a confirmed correction from a request for further investigation.

The following comparison separates common symptoms from the evidence that can help identify their cause.

Recorded symptom	Explanations to check	Evidence to attach
Connection timeout	Remote outage, overloaded route, blocked destination or slow DNS	Timestamps, repeated attempts and results from different connections
DNS resolves but HTTP fails	Application refusal, regional policy, missing redirect or injected resolver	Resolver response, destination address and exact status code
HTTP 403 or 451	Access controls, account restrictions or a deliberate legal block	Response headers and matching observations from other Australian networks
TLS handshake failure	Certificate, protocol, server configuration or middlebox interference	Full error message, client details and successful comparison result
Different answers from resolvers	CDN routing, split-horizon DNS, caching or resolver filtering	Resolver IP addresses and responses recorded in different cities

Submit the evidence and follow the outcome

Submit the material in a form that permits verification. Link to the affected probe or DNS record, quote the exact discrepancy and explain what kind of change would resolve it: a corrected HTTP status, a reclassified timeout, an updated blacklist entry or a qualification of an unreliable resolver. If the underlying check cannot be repeated, say so explicitly and describe what prevented reproduction.

After submission, the team may compare the observation with other Australian probes, DNS answers and published blacklists. A correction can take the form of a revised record or a methodological qualification. Since the project relies on volunteer effort and measurements depend on changing networks, retaining the original evidence and recording later test conditions can make any follow-up assessment more precise.

The next concrete step is to open the affected probe record, copy its identifier and timestamp into a post on the community channel, and attach the redacted test evidence for the monitoring team.