Network restrictions

Running a worker behind a firewall, a NAT, a proxy, or a provider that blocks ICMP.

A worker needs less network access than most people expect, and one thing that is occasionally hard to get.

What it needs

Behind NAT

Entirely fine. Nothing needs to reach the worker, so no port forward, no static address and no public address is required. A worker on a home connection behind a router works.

Behind a corporate firewall

Outbound HTTPS is usually already allowed. Outbound ICMP frequently is not, and this is the common blocker in corporate environments. Without ICMP the worker enrols and measures nothing, which looks like success until you check.

Behind an HTTP proxy

The worker honours the standard proxy environment variables for its HTTPS traffic. ICMP cannot go through an HTTP proxy at all: it is a different layer. A host whose only outbound path is an HTTP proxy cannot run a useful worker.

Providers that block ICMP

Some hosting providers block outbound ICMP by default. Many allow it to be enabled in a firewall or security group; some do not.

Check before investing time:

docker run --rm alpine ping -c 3 1.1.1.1

From inside a container, because that is where the worker will be, and container ICMP is sometimes blocked where host ICMP is not.

IPv6

Useful if you have it and not required. A worker with working IPv6 can measure targets an IPv4-only worker cannot, which makes it a more valuable vantage point rather than a differently configured one.

Rate limiting

The worker's traffic is small: a few ICMP packets per minute per target and a heartbeat about every thirty seconds. It is unlikely to trip a rate limit. If a provider's abuse system objects, it is usually because it treats any outbound ICMP to many destinations as scanning, which is worth raising with them: the target list is fixed and signed, and the worker measures exactly what is on it.