Eine Firewall, der Bot-Schutz eines CDN oder ein Sicherheits-Plugin kann unsere Checks blockieren, während echte Besucher durchkommen. Der Monitor meldet dann einen Ausfall, der keiner ist, meist HTTP 403, HTTP 429 oder einen Timeout. Geben Sie unsere Checks einmal frei, und das Problem ist behoben.
Woher die Checks kommen
Stockholm, Schweden: 95.111.205.91 und über IPv6 2a04:3541:8000:1000::/64London, Vereinigtes Königreich: 94.237.50.166 und über IPv6 2a04:3541:1000:500::/64New York, USA: 209.94.56.204 und über IPv6 2605:7380:8000:1000::/64
Wenn wir einen Standort hinzufügen, kommt seine Adresse auf diese Liste. Schauen Sie also erneut hier nach, sobald im Formular eines Monitors unter Locations ein neuer Standort erscheint. Ein Monitor ohne ausgewählte Standorte wird von jedem Standort geprüft, der online ist, ein neuer Standort prüft ihn also sofort mit.
Website-, Port- und Ping-Checks, Nachprüfungen und Traceroutes kommen von all diesen Adressen. Mehrstufige Flows, Site-Health-Scans, Test request im Monitorformular und Webhook-Alarme kommen nur aus Stockholm. Hat Ihre Website eine IPv6-Adresse (einen AAAA-Eintrag), können Checks über IPv6 von jeder Adresse der oben genannten IPv6-Bereiche kommen. Geben Sie daher die ganzen Bereiche frei, nicht einzelne Adressen.
User-Agents
Website- und API-Checks sowie Flows: Uptimecheck/1.0 (+https://uptimecheck.com). Ein User-Agent, den Sie unter Request headers hinzufügen, ersetzt ihn.Site-Health-Scans: Mozilla/5.0 (compatible; UptimecheckBot/1.0; +https://uptimecheck.com/bot).Test request im Formular: Uptimecheck/1.0 (+https://uptimecheck.com; test run). Webhook-Alarme: Uptimecheck-Alerts/1.0.Flows mit Run in a real browser und Screenshots von Vorfällen laufen im Netzwerk von Cloudflare, nicht von den Adressen oben. Ihre User-Agents enthalten Uptimecheck/1.0.Page speed wird von Google PageSpeed Insights gemessen, diese Anfragen kommen also von Google, mit einem User-Agent, der Chrome-Lighthouse enthält.
Alle unsere User-Agents enthalten Uptimecheck. Einen User-Agent kann jeder senden, geben Sie also nach Möglichkeit per Adresse frei.
Cloudflare
Liegt Ihre Website hinter Cloudflare, geben Sie uns dort frei: Ihr eigener Server sieht nur die Adressen von Cloudflare.
Öffnen Sie im Cloudflare-Dashboard Ihre Domain, gehen Sie zu Security rules und wählen Sie Create rule › Custom rules.Nennen Sie sie „Uptimecheck“, wählen Sie Edit expression und geben Sie (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}) ein. Weitere Adressen fügen Sie innerhalb der geschweiften Klammern hinzu, durch Leerzeichen getrennt.Wählen Sie unter Then take action die Aktion Skip und haken Sie All remaining custom rules, All rate limiting rules und All managed rules an, dazu All Super Bot Fight Mode rules, falls Ihr Tarif das hat. Haken Sie unter den übrigen Komponenten Browser Integrity Check und Security Level an.Setzen Sie die Regel an die erste Stelle und wählen Sie Deploy.
Den Bot Fight Mode im Free-Tarif von Cloudflare kann eine Custom Rule nicht überspringen. Legen Sie stattdessen eine IP-Zugriffsregel an: Create rule › IP access rules, eine Adresse eingeben, die Aktion Allow wählen und auf Create klicken, einmal für jede Adresse und jeden IPv6-Bereich oben. Greift zuerst eine IP-Zugriffsregel, wird der Bot Fight Mode nicht aktiv. Um zu sehen, was einen Check blockiert hat, öffnen Sie Security analytics, den Tab Events, und sehen sich das Feld Service an.
WordPress-Sicherheits-Plugins
Öffnen Sie in Wordfence Firewall › All Firewall Options, tragen Sie die Adressen unter Allowlisted IP addresses that bypass all rules ein und speichern Sie. Solid Security, All-In-One Security und ähnliche Plugins haben ebenfalls eine Allowlist. Betreibt Ihr Hoster eine eigene Firewall, etwa Imunify360 oder ModSecurity, bitten Sie ihn, die Adressen freizugeben. Mit 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
Beschränkt nginx einen Pfad auf bekannte Adressen, ergänzen Sie unsere:
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;
}
Um für alle anderen ein Rate Limit beizubehalten, geben Sie unseren Adressen einen leeren Schlüssel. Anfragen mit leerem Schlüssel zählt nginx nicht:
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;
Hinter einem CDN oder Load Balancer sieht nginx die Adresse des Proxys, sofern real_ip_header nicht eingerichtet ist.
Oder einen geheimen Header freigeben
Adressen ändern sich, wenn wir Standorte hinzufügen, ein Header nicht. Wählen Sie bei einem Website- oder API-Monitor Keyword, headers and more und fügen Sie unter Request headers eine Zeile hinzu, etwa X-Monitor-Token: a-long-random-value. Geben Sie dann Anfragen frei, die ihn mitsenden, zum Beispiel in einer Custom Rule bei Cloudflare: any(http.request.headers[„x-monitor-token“][*] == „a-long-random-value“). Jeder in Ihrem Workspace kann den Wert sehen, verwenden Sie ihn also für nichts anderes.
Cron-Jobs und der Server-Agent
Cron-Job-Pings und der Server-Agent verbinden sich ausgehend über HTTPS (Port 443) mit app.uptimecheck.com. Dürfen Ihre Server nur freigegebene Hosts erreichen, geben Sie diesen Namen frei. Jobs und Agents, die vor dem 16. Oktober 2026 eingerichtet wurden, nutzen unter Umständen platform.uptimecheck.com, unsere frühere Adresse, die weiterhin funktioniert.
Immer noch down? Lesen Sie, warum ein Monitor down ist, obwohl Ihre Website funktioniert. Mehr zum Uptime-Monitoring.