Endpoint Access

OnchainProbe workers make frequent RPC calls to your endpoints during test runs. If your endpoints are behind a reverse proxy, firewall, or cloud WAF with rate limiting enabled, you need to allowlist the OnchainProbe IP addresses to avoid false failures.

OnchainProbe IP addresses

All test traffic currently originates from the following IP addresses:

46.225.88.37

Note

These IPs may change or expand in the future. We will notify you via email and in-app announcement before any change takes effect.

Why this matters

A typical test run makes dozens to hundreds of RPC calls in a short burst (10-30 seconds). Rate limiters tuned for normal application traffic will often throttle this pattern, causing:

• Intermittent 429 Too Many Requests errors
• Timeouts that trigger infra_failed run status
• Inconsistent latency measurements that pollute your baselines
• False comparison mismatches between endpoints with different rate limits

Quick check

Before configuring anything, verify whether rate limiting is actually a problem. Trigger a manual run and check for 429 status codes or timeout failures in the run samples. If your endpoints are self-hosted without a rate limiter, you may not need any changes.

Nginx

If your RPC node sits behind Nginx with limit_req, create a geo-based bypass:

# Define a variable based on source IP
geo $rate_limit_bypass {
    default         0;
    46.225.88.37    1;
}

# Apply rate limit only when bypass is not set
limit_req_zone $binary_remote_addr zone=rpc:10m rate=100r/s;

server {
    listen 443 ssl;
    server_name rpc.example.com;

    location / {
        # Skip rate limiting for OnchainProbe workers
        limit_req zone=rpc burst=50 nodelay;
        limit_req_status 429;

        if ($rate_limit_bypass) {
            set $limit_req_zone "";
        }

        proxy_pass http://127.0.0.1:8545;
    }
}

Alternative: use allow/deny with a separate location block:

# Separate location with no rate limit for OnchainProbe
location /rpc-probe {
    allow 46.225.88.37;
    deny all;
    proxy_pass http://127.0.0.1:8545/;
}

Then use the /rpc-probe path as your endpoint URL in OnchainProbe.

Caddy

Caddy does not have built-in rate limiting, but if you use the caddy-ratelimit plugin or a Caddy-layer WAF:

rpc.example.com {
    @onchainprobe remote_ip 46.225.88.37

    # No rate limit for OnchainProbe
    handle @onchainprobe {
        reverse_proxy localhost:8545
    }

    # Rate-limited path for everyone else
    handle {
        rate_limit {remote.ip} 100r/m
        reverse_proxy localhost:8545
    }
}

If you are not using any rate-limit plugin, no changes are needed.

HAProxy

frontend rpc
    bind *:443 ssl crt /etc/haproxy/certs/rpc.pem
    default_backend rpc_nodes

    # Identify OnchainProbe traffic
    acl is_onchainprobe src 46.225.88.37

    # Apply rate limit only to non-OnchainProbe traffic
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src unless is_onchainprobe
    http-request deny deny_status 429 if { sc_http_req_rate(0) gt 200 } !is_onchainprobe

backend rpc_nodes
    server node1 127.0.0.1:8545

Cloudflare

If your endpoint is behind Cloudflare:

1. Go to Security > WAF > Rate limiting rules.
2. Create or edit your rate limiting rule.
3. Add an exception condition: IP Source Address equals 46.225.88.37.
4. Alternatively, create an IP Access Rule under Security > WAF > Tools: action Allow, value 46.225.88.37, zone-wide.

Tip

Cloudflare IP Access Rules (allow) bypass all WAF rate limiting and managed rules for that IP. This is the simplest approach.

AWS Application Load Balancer

If your RPC endpoint is behind an ALB with AWS WAF:

1. Open AWS WAF > Web ACLs and select your ACL.
2. Create an IP set containing 46.225.88.37/32.
3. Add a rule that matches the IP set with action Allow and set its priority higher (lower number) than your rate-limiting rule.

This ensures OnchainProbe traffic is allowed before the rate-limit rule evaluates it.

Firewall / iptables

If you use OS-level rate limiting (e.g., iptables with hashlimit):

# Allow OnchainProbe without rate limit
iptables -I INPUT -s 46.225.88.37 -p tcp --dport 8545 -j ACCEPT

# Rate limit everyone else
iptables -A INPUT -p tcp --dport 8545 -m hashlimit \
    --hashlimit-above 100/sec --hashlimit-mode srcip \
    --hashlimit-name rpc_limit -j DROP

Caution

The iptables -I (insert) flag places the allow rule before the rate limit rule. Order matters.

Execution client flags

Some execution clients have built-in RPC rate limiting. If enabled, either disable it or raise the limit for the worker IP.

Client	Flag	Default
Geth	No built-in RPC rate limit	N/A
Nethermind	--JsonRpc.RequestQueueLimit	500
Reth	No built-in RPC rate limit	N/A
Erigon	--rpc.ratelimit	0 (disabled)
Besu	--rpc-http-max-active-connections	80

If you hit limits, increase these values or proxy through Nginx/Caddy with the IP-based bypass above.

Verifying access

After configuring, trigger a test run and confirm:

1. No 429 responses in run samples.
2. Run completes with success status (not infra_failed or timeout).
3. Latency measurements are stable across consecutive runs.

If you still see failures, check that the allowlist rule has higher priority than the rate-limit rule in your proxy/WAF configuration.

Next step

With access configured, set up your test suites: Configure Suites