Un firewall, la protezione anti-bot di una CDN o un plugin di sicurezza possono bloccare i nostri controlli mentre i visitatori reali passano. Il monitor segnala allora un’interruzione che non c’è, di solito HTTP 403, HTTP 429 o un timeout. Consenti una volta i nostri controlli e il problema sparisce.
Da dove arrivano i controlli
Stoccolma, Svezia: 95.111.205.91 e, via IPv6, 2a04:3541:8000:1000::/64Londra, Regno Unito: 94.237.50.166 e, via IPv6, 2a04:3541:1000:500::/64New York, Stati Uniti: 209.94.56.204 e, via IPv6, 2605:7380:8000:1000::/64
Quando aggiungiamo una località, il suo indirizzo viene aggiunto a questo elenco, quindi torna a controllare qui quando compare una nuova località in Locations nel modulo di un monitor. Un monitor senza località scelte viene controllato da tutte le località online, quindi una nuova località inizia subito a controllarlo.
I controlli di siti web, porte e ping, le riverifiche e i traceroute arrivano da tutti questi indirizzi. I flussi multi-step, le scansioni della salute del sito, Test request nel modulo del monitor e gli avvisi webhook arrivano solo da Stoccolma. Se il tuo sito ha un indirizzo IPv6 (un record AAAA), i controlli possono arrivare via IPv6 da qualsiasi indirizzo degli intervalli IPv6 indicati sopra, quindi consenti gli interi intervalli, non singoli indirizzi.
User agent
Controlli di siti web e API e flussi: Uptimecheck/1.0 (+https://uptimecheck.com). Un User-Agent che aggiungi in Request headers lo sostituisce.Scansioni della salute del sito: Mozilla/5.0 (compatible; UptimecheckBot/1.0; +https://uptimecheck.com/bot).Test request nel modulo: Uptimecheck/1.0 (+https://uptimecheck.com; test run). Avvisi webhook: Uptimecheck-Alerts/1.0.I flussi con Run in a real browser e gli screenshot degli incidenti vengono eseguiti nella rete di Cloudflare, non dagli indirizzi indicati sopra. I loro user agent contengono Uptimecheck/1.0.La Page speed viene misurata da Google PageSpeed Insights, quindi quelle richieste arrivano da Google, con uno user agent che contiene Chrome-Lighthouse.
Tutti i nostri contengono Uptimecheck. Chiunque può inviare uno user agent, quindi, dove puoi, consenti in base all’indirizzo.
Cloudflare
Se il tuo sito è dietro Cloudflare, consentici lì: il tuo server vede solo gli indirizzi di Cloudflare.
Nella dashboard di Cloudflare, apri il tuo dominio, vai in Security rules e scegli Create rule › Custom rules.Chiamala “Uptimecheck”, scegli Edit expression e inserisci (ip.src in {95.111.205.91 2a04:3541:8000:1000::/64 94.237.50.166 2a04:3541:1000:500::/64 209.94.56.204 2605:7380:8000:1000::/64}). Aggiungi altri indirizzi tra le parentesi graffe, separati da spazi.In Then take action, scegli Skip e seleziona All remaining custom rules, All rate limiting rules e All managed rules, più All Super Bot Fight Mode rules se il tuo piano lo prevede. Tra gli altri componenti, seleziona Browser Integrity Check e Security Level.Metti la regola al primo posto e scegli Deploy.
Bot Fight Mode, sul piano Free di Cloudflare, non può essere aggirato con una regola personalizzata. Aggiungi invece una regola di accesso IP: Create rule › IP access rules, inserisci un indirizzo, scegli l’azione Allow e poi Create, una volta per ogni indirizzo e intervallo IPv6 indicato sopra. Quando una regola di accesso IP corrisponde per prima, Bot Fight Mode non interviene. Per vedere cosa ha bloccato un controllo, apri Security analytics, la scheda Events, e guarda il campo Service.
Plugin di sicurezza per WordPress
In Wordfence, apri Firewall › All Firewall Options, aggiungi gli indirizzi a Allowlisted IP addresses that bypass all rules e salva. Anche Solid Security, All-In-One Security e plugin simili hanno una allowlist. Se il tuo hosting usa un proprio firewall, come Imunify360 o ModSecurity, chiedi di inserire gli indirizzi nella allowlist. Con fail2ban:
# /etc/fail2ban/jail.local
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 95.111.205.91 2a04:3541:8000:1000::/64 94.237.50.166 2a04:3541:1000:500::/64 209.94.56.204 2605:7380:8000:1000::/64
nginx
Se nginx limita un percorso a indirizzi noti, aggiungi i nostri:
location = /health {
allow 95.111.205.91;
allow 2a04:3541:8000:1000::/64;
allow 94.237.50.166;
allow 2a04:3541:1000:500::/64;
allow 209.94.56.204;
allow 2605:7380:8000:1000::/64;
deny all;
proxy_pass http://127.0.0.1:8080;
}
Per mantenere un rate limit per tutti gli altri, assegna ai nostri indirizzi una chiave vuota. nginx non conta le richieste con chiave vuota:
geo $limit {
default 1;
95.111.205.91 0;
2a04:3541:8000:1000::/64 0;
94.237.50.166 0;
2a04:3541:1000:500::/64 0;
209.94.56.204 0;
2605:7380:8000:1000::/64 0;
}
map $limit $limit_key {
0 “”;
1 $binary_remote_addr;
}
limit_req_zone $limit_key zone=perip:10m rate=10r/s;
Dietro una CDN o un load balancer, nginx vede l’indirizzo del proxy, a meno che non sia configurato real_ip_header.
Oppure consenti un header segreto
Gli indirizzi cambiano quando aggiungiamo località; un header no. In un monitor Website or API, scegli Keyword, headers and more e aggiungi una riga in Request headers, ad esempio X-Monitor-Token: a-long-random-value. Poi consenti le richieste che lo contengono, ad esempio in una regola personalizzata di Cloudflare: any(http.request.headers[“x-monitor-token”][*] == “a-long-random-value”). Tutti nel tuo workspace possono vedere il valore, quindi non usarlo per nient’altro.
Cron job e agent del server
I ping dei cron job e l’agent del server si connettono verso app.uptimecheck.com via HTTPS (porta 443). Se i tuoi server possono raggiungere solo host approvati, consenti quel nome. Job e agent configurati prima del 16 ottobre 2026 potrebbero usare platform.uptimecheck.com, il nostro indirizzo precedente, che funziona ancora.
Ancora down? Leggi perché un monitor risulta down quando il sito funziona. Scopri di più sul monitoraggio uptime.