OpenClaw on a VPS: Why Chromium Screams "I'm a Bot" and How We Fix It at hablo

The problem that shows up when you move OpenClaw to a VPS

Many users who start running OpenClaw on a VPS hit the same wall: the agent boots, the environment responds, Chromium opens pages… but the moment it tries to navigate real sites, the blocks begin.

“I'm running OpenClaw on a VPS. I've also tested it locally on a Mac. But when I try to give it access to a real browser for web tasks — logging in, browsing a site, filling out forms or simulating an order — many sites detect that it's automation and block the attempt almost immediately.”

It's a very common frustration. Locally, everything seems reasonable. On a VPS, though, the browser tends to step out into the world with signals that look nothing like those of a normal user.

The IP is usually a datacenter IP. The graphical environment may be minimal or nonexistent. Chromium runs in headless mode. Fonts are missing. The resolution is odd. The language and time zone don't always line up. And in some setups, the User-Agent flat-out includes something as subtle as HeadlessChrome.

Before it does anything suspicious, the browser has already raised its hand and said: “I'm automation.”

Chromium can work and still look like a bot

The classic mistake is assuming that “Chromium works” means “Chromium looks like a real browser.” They're not the same thing.

OpenClaw can control a browser, read pages, click, fill out forms and handle complex web flows. But if that browser runs in an artificial environment, many anti-bot systems detect it before the agent ever gets a chance to do its job.

Some of the usual signals are:

• A headless Chromium User-Agent.
• A cloud-provider or datacenter IP.
• An inconsistent fingerprint.
• Unnatural language, timezone or viewport.
• Missing fonts, APIs or standard browser capabilities.
• Sessions with no history or prior context.
• Captchas left unsolved or poorly integrated into the flow.

Sometimes the site isn't even especially secure. It simply uses a standard anti-bot provider, and that provider flags a combination of signals that's just too artificial.

Tailscale, VPNs and residential IPs: they help, but they don't fix everything

A common idea is to route the VPS traffic through a local machine using Tailscale, WireGuard or another private VPN. It can make sense in some scenarios, especially if the main issue is IP reputation.

But the IP is only one signal.

If the browser is still headless, if its fingerprint doesn't add up and if the environment still looks like lab automation, changing the network exit doesn't magically turn that session into normal browsing.

On top of that, tunneling through a local machine adds operational complexity: security, maintenance, availability, performance and control over which traffic goes where. It can be useful, but it shouldn't be the only answer.

What we've changed at hablo

At hablo we've had to touch these settings because our agents don't live only in clean demos. They have to work with real websites: dashboards, forms, CRMs, booking systems, stores, analytics tools and back offices that were never designed with autonomous agents in mind.

That's why we don't let the browser start out shouting “I'm a bot.”

We've tuned the Chromium environment so it's more coherent from the very first moment: how the browser presents itself, the basic environment signals, session consistency and the little details that tend to give away poorly prepared automation.

We also give agents access to anti-captcha systems when the legitimate flow calls for it. Not to abuse sites or bypass security restrictions, but so they can complete real tasks when a website drops an automated verification into the middle of a normal process.

If a person can solve a check to access their account, confirm an operation or continue a procedure, an agent acting on that person's behalf needs a controlled way to handle that step.

Legitimate automation isn't abuse

There's a huge difference between automating legitimate tasks and automating abusively.

We're not talking about aggressive scraping, mass account creation, spam, fraud or evading security controls. We're talking about everyday cases:

• Logging into a private dashboard.
• Downloading reports.
• Filling out forms.
• Reviewing orders.
• Preparing a purchase.
• Managing work tools.
• Running authorized repetitive tasks.

For those cases, blocking the agent just because it runs on a VPS with a badly presented Chromium is a technical limitation. Intent matters, but so does the browser.

The future of agents runs through better-integrated browsers

Personal agents can't rely on APIs alone. Many tools have no public API, have incomplete APIs, or are simply meant to be used from a web interface.

That's why the browser is still a fundamental piece.

But not just any browser will do. An agent needs a persistent, coherent web environment, one that can log in, hold context, interact with forms, handle verifications and complete real flows.

This is one of those details that seem minor until you try to take an agent to production. Locally, everything seems to work. On a VPS, the blocks begin. And that's when you discover that “having Chromium” isn't the same as “having a browser that's operational for real automation.”

At hablo we're building OpenClaw agents ready to work in real environments. Users shouldn't have to wonder whether Chromium is in headless mode, whether the User-Agent is giving the agent away, or whether they need to tunnel traffic through Tailscale to keep a website from blocking it.

That should come solved by the platform. Because a useful agent isn't just an AI model plugged into tools: it's a complete system capable of acting in the digital world reliably.

And on the real web, that starts with something as basic as not opening the browser by announcing: “I'm a bot.”