# “We're verifying your browser” on a Vercel Security Checkpoint

Vercel served a Security Checkpoint instead of the origin HTML, and from a cloud VM's datacenter IP that check often never finishes. A residential or mobile exit sometimes lets the site through.

## Fix

```sh
npx aluvia-cli setup
aluvia proxy-on
```

Then reload the page.

## What the page says

Any of these is a string the page showed:

- "We're verifying your browser"
- "Vercel Security Checkpoint"
- "Failed to verify your browser Code 11 Vercel Security Checkpoint"

![We're verifying your browser. Vercel Security Checkpoint.](https://aluvia.io/unblock/vercel-security-checkpoint.png)

## Why it happens

Sites hosted on Vercel can intercept the request with a Security Checkpoint before any application HTML comes back. From a cloud VM the client is a datacenter IP, so that check often never finishes: the spinner stays on We're verifying your browser, or the same surface reports Code 11. The origin never ran.

svgrepo.com is a public Vercel-hosted page that shows this checkpoint when the browser still uses the VM's own IP. A residential or mobile exit is the part Aluvia can change. Fingerprint, TLS, and canvas stay the same.

## What those commands do

`npx aluvia-cli setup` aims the existing Chrome at a local proxy. `aluvia proxy-on` sends every tab through a residential or mobile IP. Neither command restarts the browser after that first setup.

Vercel shows the Security Checkpoint while the client is the VM's datacenter IP, before origin HTML, which is why these commands exist.

## If it is still blocked

One exit IP can be blocked on its own. Get a different one and reload again.

```sh
aluvia rotate-ip
```

## When this is the wrong tool

The checkpoint is Vercel verifying the browser before origin HTML, not a password form. Aluvia changes the exit IP so the request might reach the site. A sign-in page that already rendered is a different problem.

---

Source: https://aluvia.io/unblock/vercel-security-checkpoint