How to Set Up a Monitoring Probe in Australia

A monitoring probe is a small, repeatable measurement point that checks whether websites, domains or IP addresses can be reached through a particular Internet connection. By contributing observations from Australia, you can help distinguish a genuine block from a temporary outage, DNS error, routing problem or content filter applied by a local provider.

Net Neutrality Monitor is a beta, volunteer-supported project developed and powered by AirVPN. Its results are intended for indicative research, so the value of each submission depends on careful setup, consistent testing and clear records. A probe at home, in a small office or on a low-cost server can add useful geographic and network-level coverage.

Probe location	Useful for	Main limitation
Australian home connection	Measuring everyday ISP and DNS behaviour	Results can change after router or ISP updates
Small office or community space	Comparing a second fixed-line network	Shared users may affect bandwidth and access
Mobile broadband	Testing cellular filtering and carrier DNS	IP addresses and routes change frequently
Australian VPS	Stable, automated measurements	It may reflect hosting-network policy rather than household access
Regional or remote connection	Showing geographic differences	Availability and latency can limit test frequency

Choose A Suitable Host

Begin with a connection that represents the access you want to measure. A home NBN service in Sydney, Melbourne, Brisbane or Perth can show ordinary fixed-line conditions. A probe connected through a 4G or 5G modem can provide a useful comparison, especially where mobile access is the main alternative to fixed broadband.

Location matters because Australian networks are not identical. Telstra, Optus and Vodafone may use different DNS infrastructure, routing arrangements and filtering practices. A regional connection in Queensland or Western Australia may also take a different path to an overseas site than a metropolitan connection. Record the city, state, ISP, access technology and whether the service uses carrier-grade NAT.

Before deploying hardware, review the project’s community discussions for current probe requirements, supported software and reporting conventions. Instructions can change while a monitoring service is in beta. The community may also reveal whether a particular release has known issues with Australian routers, residential DNS resolvers or IPv6.

Prepare The Network And Hardware

A probe does not need to be an expensive dedicated computer. A spare Linux mini-PC, Raspberry Pi-class device, virtual machine or modest cloud instance may be suitable if it can run continuously and maintain a reliable connection. Use a wired Ethernet link where possible. Wi-Fi can introduce packet loss, sleep behaviour and radio interference that look like website failures.

Keep the measurement device separate from everyday browsing. A home router may be rebooted, a family member may change its DNS settings, or a VPN may be enabled for streaming. These changes can invalidate comparisons. If the probe shares the connection, label it clearly and avoid using it for personal accounts, banking or general downloads.

Australian conditions can affect availability in practical ways. Summer heat in Adelaide or inland New South Wales may stress poorly ventilated equipment, while storms and bushfire-related power interruptions can create gaps in regional data. A small uninterruptible power supply, automatic restart setting and stable ventilation help preserve continuity without making the installation unnecessarily complex.

For background on the human consequences of losing reliable connectivity during emergencies, see this discussion of the psychological impact of displacement after a natural disaster. The probe itself is not an emergency communications system, but documenting access failures can become especially valuable when communities depend on online information.

Install And Register The Probe

Follow the project’s current deployment instructions rather than copying commands from an old forum post. Typically, setup involves installing the probe software, assigning a device identifier, confirming its country and network, and enabling a scheduled measurement process. Use a dedicated operating-system account with only the permissions the software needs.

Record the initial configuration in a short local file or notebook. Include the operating system, software version, connection type, ISP, approximate location, DNS resolver and whether IPv4 or IPv6 is active. Do not record passwords, authentication tokens or unrelated browsing history. A simple change log makes it easier to explain why results shifted after an upgrade.

Registration should use an email address or account method appropriate to the project’s current policy. Protect any access credentials with a password manager and restrict administrative access to the device. If the service supplies a probe key, treat it like a secret: publish its identifier only when the project explicitly asks for it, and never paste the key into a public issue or screenshot.

Establish A Baseline

Run baseline checks before interpreting censorship results. Confirm that the probe can resolve common domains, reach a neutral test page, contact the project’s service and maintain accurate system time. Check both IPv4 and IPv6 when available, because a site may fail over one protocol while working over the other.

A baseline should include several ordinary Australian and international destinations. Test at different times, such as morning, evening and the busy period after work, because congestion can resemble filtering. NBN users in Melbourne or Sydney may see different evening performance from the same service during daytime. Keep a record of latency, DNS response, HTTP status and whether the connection timed out.

Do not switch between multiple VPN providers while collecting a single series. A VPN hides the access provider being measured and changes the route, resolver and apparent country. If you need to compare a VPN exit with a household ISP, treat it as a separate probe with separate labels and records.

Protect Privacy And Legal Boundaries

Measure only what the project requests. A monitoring probe should make controlled requests to listed domains or addresses, not crawl entire websites, attempt authentication, bypass access controls or generate high traffic. Respect robots, rate limits and provider terms where they apply, and stop a test that causes instability.

Australian privacy rules still matter in a volunteer project. The Privacy Act 1988 and the Australian Privacy Principles may apply depending on who operates the service and what information is collected. Avoid storing full URLs containing personal data, cookies, form values or account identifiers. A probe should never inspect private messages or capture household traffic.

The project’s private-services information can help clarify how privacy-focused services differ from an ordinary ISP measurement point. Keep those functions separate: a monitoring probe reports network reachability, while a privacy service is intended to protect or alter a user’s connection. Combining them makes the evidence harder to interpret.

Secure the host with timely updates, a firewall, strong authentication and limited exposed ports. Disable remote administration from the public Internet unless it is essential. Keep logs long enough to investigate failures, then remove unnecessary data. A clean, minimal system is easier to trust than a powerful machine running many unrelated services.

Interpret Measurements Carefully

A failed request is not automatically evidence of censorship. DNS failure, certificate errors, server downtime, geoblocking, broken IPv6, upstream routing faults and overloaded resolvers can all produce similar symptoms. Compare DNS answers, connection attempts and HTTP responses before labelling an event as blocked.

Repeat a result from the same probe, then compare it with another Australian network if available. A domain that fails on an Optus mobile connection but works on a Telstra fixed-line service may indicate network-specific behaviour, although it still requires verification. A failure across several providers and protocols is stronger evidence of a wider outage or block.

Political and news sites can change addresses, hosting providers and content rapidly. For example, a test URL covering India’s Rohingya policy should be recorded with its exact URL, timestamp and observed response, rather than treated as a permanent indicator. Content availability can change for editorial, legal or technical reasons.

Australia also has lawful website-blocking mechanisms administered through the eSafety Commissioner and other regulatory processes. A measurement can reveal that access is unavailable, but it cannot by itself establish which authority, rule or commercial decision caused the result. Use cautious labels such as DNS anomaly, timeout, HTTP denial or confirmed multi-network failure until the evidence supports more.

Share Reliable Evidence

When the probe is stable, submit observations through the project’s supported channel. Include the measurement time in UTC, local timezone, ISP, city or broad region, access technology, resolver and relevant software version. A broad location is generally safer than a street address and is usually enough for geographic analysis.

Describe changes plainly: “access failed after DNS resolution on IPv4” is more useful than “the site is censored.” Attach only the logs needed to reproduce the finding, with tokens, IP addresses of household devices and personal data removed. Keep the original records privately in case the project asks for verification.

Expect gaps. Power cuts, NBN maintenance, modem resets, mobile handovers and ISP resolver changes are normal parts of Australian connectivity. Marking an interruption is better than silently presenting incomplete data as continuous monitoring. Consistency matters more than a large burst of measurements followed by weeks of inactivity.

The key point to remember is that a probe contributes trustworthy evidence when its network identity, test conditions and limitations are documented. Stable hardware, restrained requests, privacy-conscious records and repeated observations turn a single failed page load into useful research about how Internet access behaves across Australia.