The You Up? probe

You found this address in your access log, in a request that said:

User-Agent: Mozilla/5.0 (compatible; uup/1.0; +https://uup.dev/probe)
X-Uup-Check: chk_…

The You Up? probe sends both. The uup in them is the name our software gives itself, as in our address, uup.dev, and it stays the same so that rules you write for it keep working.

Every request is signed

Every request the probe sends is signed with Web Bot Auth, an open method, being standardized at the IETF, that lets a server or a bot filter check that a request came from the bot it names. The signature is in three more headers:

Signature-Agent: "https://uup.dev"
Signature-Input: sig1=…
Signature: sig1=:…:

Signature-Agent names us, and it is always exactly "https://uup.dev", quotes included. The other two change with every request. The keys that check them are listed in our key directory, at https://uup.dev/.well-known/http-message-signatures-directory.

A server that ignores these headers works as it did before, and nothing else about the request changes. A server or a bot filter that wants to can check the signature against the key directory. A signature that checks was made with our key, for your site, in the last minute.

What this traffic is

You Up? is an uptime monitoring service. A customer of ours asked us to check that an address on your server answers. That customer is usually you, your company, or somebody who builds or runs the site for you.

The probe is not a crawler and not a scanner. It requests the one address it was given, on the schedule the customer chose, from a few places in the world. It follows no links and reads no other pages.

It does not read robots.txt. That file tells crawlers which pages they may visit, and the probe visits only the one address a customer gave it.

A visit may also come from the Down checker, a free tool on uup.dev where anyone can check whether a website answers. Then the request says X-Uup-Check: dck_…, and the probe sends one GET of the address typed, once from each place, with nothing added. It never shows anyone what your server sent back.

Why the connection closes before the response finishes

The probe reads the status line and the headers, and then it closes the connection. It downloads the body only when the customer asked it to check what the body says, or when the answer is an error, and then it reads only a small part of it.

Some servers write this early close to the log as a client abort. nginx logs it as status 499. Your server did nothing wrong, and neither did the probe. It had what it came for.

How to allow it

If a firewall or a bot filter blocks the probe, our customer is told that your site is down when it is not. The safest way to let it through is to allow requests from the addresses listed under Where it comes from, and to skip bot and rate-limit checks for them. Allow the IPv6 addresses as well as the IPv4 ones. Steps for each service shows where that is done in the tools sites use most.

If your tool can only match a request's headers, allow requests that match either of these:

• a User-Agent header that contains uup/1.0
• an X-Uup-Check header. Every request the probe sends has one.

Anybody can copy a header, so an allow rule on a header is a rule for traffic that you are willing to let anybody send. The signature is different: nobody else can make a new one that checks. If your tool can check it, see Every request is signed.

The value of X-Uup-Check starts with chk_ and names the check that sent the request. The same check always sends the same value. If you run the site, you can use it to recognize your own checks, or to skip a side effect that a monitoring request must not cause.

Where it comes from

The probe sends only from these addresses, one server in each place. The list last changed on 13 October 2026. When an address is added or replaced, it changes here first, and that date moves.

The same addresses, for a script that keeps an allowlist current: ips.txt, one address per line, and ips.json, by location, with updatedAt set to the day the list last changed.

Check that a request really came from us

Every address above has reverse DNS that names a host under probe.uup.dev, and that name resolves back to the same address. Only we can set both. Look up the address from your log, then look up the name it gives:

dig -x ADDRESS +short
NAME.probe.uup.dev.

dig NAME.probe.uup.dev A +short
ADDRESS

Ask for AAAA instead of A for an IPv6 address. If the name is not under probe.uup.dev, or it does not lead back to the address you started from, the request did not come from us, whatever its headers say.

Steps for each service

Each service names its menus its own way and changes them from time to time. These steps follow what each one publishes, as it read on 14 October 2026. Some keep part of their documentation behind a login; if a menu is not where a step says, their support can point you to it. Add every address from ips.txt, and only those.

Cloudflare

The probe is a Cloudflare verified bot: see its entry in Cloudflare Radar's bots directory. If your Cloudflare rules still block it, these steps let it through.

1. In your account's Settings, open Lists, create a list with the content type IP, name it uup_probes and add every address.
2. In the site's Security rules, create a custom rule with the expression ip.src in $uup_probes and the action Skip.
3. Tick all remaining custom rules, all rate limiting rules, all managed rules and all Super Bot Fight Mode rules, and deploy it.

Or, on any plan, add each address as an IP access rule with the action Allow.

Bot Fight Mode, on the Free plan, cannot be skipped this way. Cloudflare documents that it runs outside its rules, so Skip, Bypass and Allow have no effect on it. If it blocks the probe, turn it off under Security settings, Bot traffic. On Pro and above, Super Bot Fight Mode takes its place, and the Skip rule above lets the probe through it.

Akamai Bot Manager

1. Create a custom bot category, since a custom bot cannot join one of Akamai's own.
2. In it, create a custom-defined bot that matches these addresses.
3. In your security policy, set that category's action to Allow, and activate the configuration.

A Client List used as an IP/Geo Firewall block exception does not do the same: Akamai documents that it lifts only IP, geography and network blocks, not its other protections.

DataDome

1. Open Access Control, Custom Rules, Create a Custom Rule.
2. Enter the addresses as a query, such as ip:192.0.2.10 OR ip:"2001:db8::10", with every IPv6 address in double quotes.
3. Add it as an Allow rule, with a priority above any Block or Captcha rule.

HUMAN (PerimeterX)

1. Open Bot Defender, Policies, Policy Settings, and add a custom rule.
2. Set its condition to IP address is each address, joined with OR, and its action to Allow.
3. Give it a priority above any rule that blocks, then Save & Activate.

Imperva

1. Open the site's Settings, Security, Bot Access Control.
2. Add an exception by IP for each address, and save.

AWS WAF and Bot Control

1. In the AWS WAF console, create two IP sets, one for IPv4 with each address as /32 and one for IPv6 with each as /128, in the web ACL's Region, or Global for CloudFront.
2. In the web ACL, add a rule for each IP set with the action Allow.
3. Move both rules to the top, above the Bot Control rule group and any rate-based rule.

Vercel Firewall

1. In the project, open Firewall, Configure, and add a rule.
2. Set its condition to IP Address equals each address, joined with OR, and its action to Bypass.
3. Place it above any rule that blocks, save it and publish.

Fastly Next-Gen WAF

1. Open Security, Next-Gen WAF, Lists, and add a list of type IP addresses with every address.
2. Under Rules, add a request rule: IP address is in list that list, with the action Allow.

F5

On BIG-IP Advanced WAF:

1. Open Security, Application Security, IP Addresses, IP Address Exceptions, and create one for each address.
2. Choose Never block this IP Address and Ignore in Anomaly Detection, then apply the policy.

On F5 Distributed Cloud, add the addresses to your Bot Defense allowlist policy under IP Allowlist, and to the load balancer's trusted client rules.

Radware

In Cloud WAAP, add an advanced rule whose condition is the source address being in a list of these addresses, with the action Bypass.

Kasada

Kasada publishes no steps of its own for this. Ask Kasada's support or your account team to allow the addresses in ips.txt.

Sucuri

In the firewall dashboard, open the site's Access Control, enter each address under Allow IP Addresses, and press Allow.

Wordfence

Open Wordfence, Firewall, All Firewall Options, add every address to Allowlisted IP addresses that bypass all rules, and save.

nginx

To keep the probe out of a limit_req limit, give it an empty key, since nginx does not count a request whose key is empty:

geo $uup_probe {
    default 0;
    194.113.73.108 1;
    2605:7380:8000:1000:b0a1:fcff:fe31:4439 1;
    209.50.61.33 1;
    2604:ed40:1000:1711:b0a1:fcff:fe31:617f 1;
    85.9.207.57 1;
    2a04:3542:1000:910:b0a1:fcff:fe31:2cdb 1;
    80.47.224.164 1;
    2a04:3540:1000:310:b0a1:fcff:fe31:1fc9 1;
    213.163.193.152 1;
    2a04:3543:1000:2310:b0a1:fcff:fe31:7791 1;
}

map $uup_probe $limit_key {
    0 $binary_remote_addr;
    1 "";
}

limit_req_zone $limit_key zone=perip:10m rate=10r/s;

nginx checks allow and deny in order, so put these above any deny:

allow 194.113.73.108;
allow 2605:7380:8000:1000:b0a1:fcff:fe31:4439;
allow 209.50.61.33;
allow 2604:ed40:1000:1711:b0a1:fcff:fe31:617f;
allow 85.9.207.57;
allow 2a04:3542:1000:910:b0a1:fcff:fe31:2cdb;
allow 80.47.224.164;
allow 2a04:3540:1000:310:b0a1:fcff:fe31:1fc9;
allow 213.163.193.152;
allow 2a04:3543:1000:2310:b0a1:fcff:fe31:7791;

Apache

Let the addresses through a block that denies others:

<RequireAny>
    Require ip 194.113.73.108 2605:7380:8000:1000:b0a1:fcff:fe31:4439 209.50.61.33 2604:ed40:1000:1711:b0a1:fcff:fe31:617f 85.9.207.57 2a04:3542:1000:910:b0a1:fcff:fe31:2cdb 80.47.224.164 2a04:3540:1000:310:b0a1:fcff:fe31:1fc9 213.163.193.152 2a04:3543:1000:2310:b0a1:fcff:fe31:7791
    <RequireAll>
        Require all granted
        # your existing Require not ip lines
    </RequireAll>
</RequireAny>

With ModSecurity, load this before your other rules, with an id none of your rules uses:

SecRule REMOTE_ADDR "@ipMatch 194.113.73.108,2605:7380:8000:1000:b0a1:fcff:fe31:4439,209.50.61.33,2604:ed40:1000:1711:b0a1:fcff:fe31:617f,85.9.207.57,2a04:3542:1000:910:b0a1:fcff:fe31:2cdb,80.47.224.164,2a04:3540:1000:310:b0a1:fcff:fe31:1fc9,213.163.193.152,2a04:3543:1000:2310:b0a1:fcff:fe31:7791" \
    "id:1000010,phase:1,pass,nolog,ctl:ruleEngine=Off"

Behind a proxy or a CDN, the server sees the proxy's address unless it restores the visitor's, with real_ip in nginx or mod_remoteip in Apache.

Who to write to

If you did not ask for this traffic and you want it to stop, or anything about it looks wrong, write to probe@uup.dev. Include the X-Uup-Check value from your log. It lets us find the exact check and the customer who owns it.