Un firewall, la protección contra bots de una CDN o un plugin de seguridad pueden bloquear nuestras comprobaciones aunque los visitantes reales sí pasen. El monitor informa entonces de una caída que no es real, normalmente HTTP 403, HTTP 429 o un timeout. Basta con permitir nuestras comprobaciones una vez para que deje de ocurrir.
De dónde vienen las comprobaciones
Estocolmo, Suecia: 95.111.205.91 y, por IPv6, 2a04:3541:8000:1000::/64Londres, Reino Unido: 94.237.50.166 y, por IPv6, 2a04:3541:1000:500::/64Nueva York, Estados Unidos: 209.94.56.204 y, por IPv6, 2605:7380:8000:1000::/64
Cuando añadimos una ubicación, su dirección se añade a esta lista, así que vuelve a mirar aquí cuando aparezca una ubicación nueva en Locations en el formulario de un monitor. Un monitor sin ubicaciones elegidas se comprueba desde todas las ubicaciones activas, así que una nueva empieza a comprobarlo al momento.
Las comprobaciones de webs, puertos y ping, las recomprobaciones y los traceroutes vienen de todas estas direcciones. Los flujos de varios pasos, los análisis de salud del sitio, Test request en el formulario del monitor y las alertas por webhook vienen solo de Estocolmo. Si tu web tiene una dirección IPv6 (un registro AAAA), las comprobaciones pueden llegar por IPv6 desde cualquier dirección de los rangos IPv6 anteriores, así que permite los rangos completos, no direcciones sueltas.
User agents
Comprobaciones de webs y API, y flujos: Uptimecheck/1.0 (+https://uptimecheck.com). Un User-Agent que añadas en Request headers lo sustituye.Análisis de salud del sitio: Mozilla/5.0 (compatible; UptimecheckBot/1.0; +https://uptimecheck.com/bot).Test request en el formulario: Uptimecheck/1.0 (+https://uptimecheck.com; test run). Alertas por webhook: Uptimecheck-Alerts/1.0.Los flujos con Run in a real browser y las capturas de pantalla de las incidencias se ejecutan en la red de Cloudflare, no desde las direcciones anteriores. Sus user agents contienen Uptimecheck/1.0.Page speed lo mide Google PageSpeed Insights, así que esas peticiones vienen de Google, con un user agent que contiene Chrome-Lighthouse.
Todos los nuestros contienen Uptimecheck. Cualquiera puede enviar un user agent, así que, siempre que puedas, permite por dirección.
Cloudflare
Si tu web está detrás de Cloudflare, permítenos allí: tu propio servidor solo ve las direcciones de Cloudflare.
En el panel de Cloudflare, abre tu dominio, ve a Security rules y elige Create rule › Custom rules.Llámala “Uptimecheck”, elige Edit expression e introduce (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}). Añade más direcciones dentro de las llaves, separadas por espacios.En Then take action, elige Skip y marca All remaining custom rules, All rate limiting rules y All managed rules, además de All Super Bot Fight Mode rules si tu plan lo incluye. Entre los demás componentes, marca Browser Integrity Check y Security Level.Coloca la regla en primer lugar y elige Deploy.
Bot Fight Mode, en el plan Free de Cloudflare, no se puede omitir con una regla personalizada. Añade en su lugar una regla de acceso por IP: Create rule › IP access rules, introduce una dirección, elige la acción Allow y pulsa Create, una vez por cada dirección y rango IPv6 de arriba. Cuando una regla de acceso por IP coincide primero, Bot Fight Mode no actúa. Para ver qué bloqueó una comprobación, abre Security analytics, la pestaña Events, y mira el campo Service.
Plugins de seguridad de WordPress
En Wordfence, abre Firewall › All Firewall Options, añade las direcciones a Allowlisted IP addresses that bypass all rules y guarda. Solid Security, All-In-One Security y plugins similares también tienen una lista de permitidos. Si tu hosting usa su propio firewall, como Imunify360 o ModSecurity, pídele que añada las direcciones a su lista de permitidos. 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
Si nginx limita una ruta a direcciones conocidas, añade las nuestras:
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;
}
Para mantener un límite de peticiones para todos los demás, asigna a nuestras direcciones una clave vacía. nginx no cuenta las peticiones con clave vacía:
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;
Detrás de una CDN o un balanceador de carga, nginx ve la dirección del proxy salvo que real_ip_header esté configurado.
O permite una cabecera secreta
Las direcciones cambian cuando añadimos ubicaciones; una cabecera, no. En un monitor de web o API, elige Keyword, headers and more y añade una línea en Request headers, como X-Monitor-Token: a-long-random-value. Después permite las peticiones que la lleven, por ejemplo con una regla personalizada de Cloudflare: any(http.request.headers[«x-monitor-token»][*] == «a-long-random-value»). Todos los miembros de tu espacio de trabajo pueden ver el valor, así que no lo uses para nada más.
Cron jobs y el agente de servidor
Los pings de cron jobs y el agente de servidor se conectan hacia fuera a app.uptimecheck.com por HTTPS (puerto 443). Si tus servidores solo pueden conectarse a hosts aprobados, permite ese nombre. Los jobs y agentes configurados antes del 16 de octubre de 2026 pueden usar platform.uptimecheck.com, nuestra dirección anterior, que sigue funcionando.
¿Sigue apareciendo caído? Consulta por qué un monitor aparece caído cuando tu web funciona. Más información sobre la monitorización de disponibilidad.