Zapora sieciowa, ochrona przed botami w CDN lub wtyczka bezpieczeństwa może blokować nasze sprawdzenia, choć prawdziwi odwiedzający przechodzą bez problemu. Monitor zgłasza wtedy awarię, której nie ma – zwykle HTTP 403, HTTP 429 lub przekroczenie limitu czasu. Wystarczy raz zezwolić na nasze sprawdzenia, a problem zniknie.
Skąd pochodzą sprawdzenia
Sztokholm, Szwecja: 95.111.205.91 oraz, przez IPv6, 2a04:3541:8000:1000::/64Londyn, Wielka Brytania: 94.237.50.166 oraz, przez IPv6, 2a04:3541:1000:500::/64Nowy Jork, Stany Zjednoczone: 209.94.56.204 oraz, przez IPv6, 2605:7380:8000:1000::/64
Gdy dodajemy lokalizację, jej adres trafia na tę listę, więc zajrzyj tu ponownie, gdy w formularzu monitora w sekcji Locations pojawi się nowa lokalizacja. Monitor bez wybranych lokalizacji jest sprawdzany ze wszystkich lokalizacji, które są online, więc nowa lokalizacja od razu zaczyna go sprawdzać.
Sprawdzenia stron, portów i pingi, ponowne sprawdzenia i traceroute pochodzą ze wszystkich tych adresów. Scenariusze wieloetapowe, skanowanie kondycji strony, Test request w formularzu monitora i alerty przez webhooki pochodzą tylko ze Sztokholmu. Jeśli Twoja strona ma adres IPv6 (rekord AAAA), sprawdzenia mogą przychodzić przez IPv6 z dowolnego adresu z powyższych zakresów IPv6, więc zezwól na całe zakresy, a nie na pojedyncze adresy.
User agenty
Sprawdzenia stron i API oraz scenariusze: Uptimecheck/1.0 (+https://uptimecheck.com). User-Agent dodany w sekcji Request headers go zastępuje.Skanowanie kondycji strony: Mozilla/5.0 (compatible; UptimecheckBot/1.0; +https://uptimecheck.com/bot).Test request w formularzu: Uptimecheck/1.0 (+https://uptimecheck.com; test run). Alerty przez webhooki: Uptimecheck-Alerts/1.0.Scenariusze z opcją Run in a real browser i zrzuty ekranu incydentów działają w sieci Cloudflare, a nie z powyższych adresów. Ich user agenty zawierają Uptimecheck/1.0.Page speed mierzy Google PageSpeed Insights, więc te żądania pochodzą od Google, z user agentem zawierającym Chrome-Lighthouse.
Wszystkie nasze zawierają Uptimecheck. User agenta może wysłać każdy, więc tam, gdzie to możliwe, zezwalaj według adresu.
Cloudflare
Jeśli Twoja strona działa za Cloudflare, zezwól na nas właśnie tam: Twój serwer widzi tylko adresy Cloudflare.
W panelu Cloudflare otwórz swoją domenę, przejdź do Security rules i wybierz Create rule › Custom rules.Nazwij regułę „Uptimecheck”, wybierz Edit expression i wpisz (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}). Kolejne adresy dodawaj w nawiasach klamrowych, oddzielając je spacjami.W sekcji Then take action wybierz Skip i zaznacz All remaining custom rules, All rate limiting rules i All managed rules, a także All Super Bot Fight Mode rules, jeśli Twój plan to obejmuje. Wśród pozostałych komponentów zaznacz Browser Integrity Check i Security Level.Ustaw regułę jako pierwszą i wybierz Deploy.
Bot Fight Mode w darmowym planie Cloudflare nie może zostać pominięty przez regułę niestandardową. Zamiast tego dodaj regułę dostępu IP: Create rule › IP access rules, wpisz adres, wybierz akcję Allow i kliknij Create – osobno dla każdego adresu i zakresu IPv6 z listy powyżej. Gdy reguła dostępu IP zadziała jako pierwsza, Bot Fight Mode nie reaguje. Aby sprawdzić, co zablokowało sprawdzenie, otwórz Security analytics, zakładkę Events, i spójrz na pole Service.
Wtyczki bezpieczeństwa WordPress
W Wordfence otwórz Firewall › All Firewall Options, dodaj adresy do Allowlisted IP addresses that bypass all rules i zapisz. Solid Security, All-In-One Security i podobne wtyczki też mają listę dozwolonych adresów. Jeśli Twój hosting ma własną zaporę, taką jak Imunify360 czy ModSecurity, poproś go o dodanie adresów do listy dozwolonych. W przypadku 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
Jeśli nginx ogranicza ścieżkę do znanych adresów, dodaj nasze:
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;
}
Aby zachować limit żądań dla wszystkich pozostałych, nadaj naszym adresom pusty klucz. nginx nie liczy żądań z pustym kluczem:
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;
Za CDN lub load balancerem nginx widzi adres proxy, chyba że skonfigurowano real_ip_header.
Albo zezwól na tajny nagłówek
Adresy zmieniają się, gdy dodajemy lokalizacje; nagłówek się nie zmienia. W monitorze strony lub API wybierz Keyword, headers and more i dodaj wiersz w sekcji Request headers, na przykład X-Monitor-Token: a-long-random-value. Następnie zezwól na żądania, które go zawierają, na przykład w regule niestandardowej Cloudflare: any(http.request.headers[„x-monitor-token”][*] == „a-long-random-value”). Wartość widzi każdy w Twojej przestrzeni roboczej, więc nie używaj jej do niczego innego.
Zadania cron i agent serwera
Pingi zadań cron i agent serwera łączą się wychodząco z app.uptimecheck.com przez HTTPS (port 443). Jeśli Twoje serwery mogą łączyć się tylko z zatwierdzonymi hostami, zezwól na tę nazwę. Zadania i agenty skonfigurowane przed 16 października 2026 mogą używać platform.uptimecheck.com, naszego wcześniejszego adresu, który nadal działa.
Monitor nadal pokazuje awarię? Zobacz, dlaczego monitor zgłasza awarię, choć strona działa. Więcej o monitorowaniu dostępności.