“Har enorma problem med min VPS. Installerar om OpenClaw för 3:e eller 4:e gången nu.”

Det meddelandet dök upp i OpenClaw Discord förra månaden. Användaren var inte ensam. Scrolla genom communityns kanaler och du hittar dussintals variationer på samma tema: webbläsarverktyget misslyckas, agenten kan inte nå Chromium, VPS:en har slut på minne, allting fungerade igår och nu gör det inte det.

Om du läser det här för att du just sökte på “OpenClaw webbläsare fungerar inte VPS” är du på rätt plats. Det här inlägget förklarar de fem sakerna som går sönder, varför de samverkar på frustrerande sätt, och hur vi löste allihop i OpenClaw.rocks Kubernetes-operatorn så att du aldrig behöver tänka på webbläsarkonfiguration igen.

Felet som alla ser

Det vanligaste felmeddelandet i OpenClaw-communityn är detta:

Can't reach the OpenClaw browser control service
(timed out after 15000ms)

Det dyker upp på Ubuntu, Debian, i Docker, på Hetzner, Hostinger, GCP och överallt annars där folk försöker köra OpenClaw med webbläsarautomation. Gateway-loggarna säger “Browser control service ready.” Men när agenten försöker använda webbläsaren tar det timeout.

Felet är generiskt. Orsakerna är det inte. Det finns minst fem distinkta felsätt, och de ser identiska ut utifrån.

Fel 1: Snap Chromium och AppArmor-muren

På en nyinstallerad Ubuntu 22.04+ server ger which chromium-browser sökvägen /usr/bin/chromium-browser. Det ser korrekt ut. Det är det inte.

Sedan Ubuntu 22.04 är standardpaketet för Chromium en snap. När OpenClaws gateway försöker starta den binären via en systemd-tjänst blockerar AppArmors begränsningslager den. Snap-paketet kan inte binda Chrome DevTools Protocol (CDP) debuggingsportar genom sandboxen. Binären startar, verkar köra, och misslyckas sedan tyst med att öppna porten som OpenClaw behöver.

Du ser “Failed to start Chrome CDP on port 18800” i loggarna, eller ibland ingenting alls. Webbläsarprocessen startar och dör innan den skriver en enda loggrad.

Lösningen är att installera Google Chromes .deb-paket eller använda Playwrights fristående Chromium-binär från ~/.cache/ms-playwright/. Båda kringgår snap-sandboxen. Men lösningen är inte uppenbar. OpenClaws webbläsardetektering skannar standardsökvägar i ordning, hittar snap-binären först och försöker använda den. GitHub issue #4978 har en fullständig genomgång.

Fel 2: Headless-standardvärden som förutsätter en skärm

OpenClaw levereras med headless: false och noSandbox: false som webbläsarstandarder. Det är logiskt på en Mac eller Windows-dator med skärm. På en VPS finns ingen skärm. Utan explicit konfiguration försöker Chromium öppna ett fönster på en displayserver som inte existerar.

Två konfigurationsändringar löser det:

openclaw config set browser.headless true
openclaw config set browser.noSandbox true

De flesta VPS-guider nämner detta. Men om du följer OpenClaws standardinstallationsinstruktioner dyker ingen av raderna upp. Du installerar, du testar webbläsaren, den misslyckas. Du söker felet. Du hittar ett blogginlägg. Du ändrar konfigurationen. Du startar om. Sedan kommer du till fel nummer tre.

Fel 3: Den osynliga OOM-killen

En enda Chromium-flik med några öppna sidor förbrukar 2 till 4 GB RAM. På en VPS med 4 GB blir det nästan inget kvar för OpenClaw självt, operativsystemet och eventuella andra tjänster.

När Linux får slut på minne avslutar kernelns OOM-killer den mest minneshungriga processen. Det är Chromium. Processen dör. OpenClaw loggar en webbläsartimeout. Ingen kraschrapport, ingen stacktrace, ingen indikation på att minne var problemet.

Det finns också en subtilare version av detta problem. Chromium startar underordnade renderingsprocesser för varje flik. Om dessa inte städas upp ordentligt ackumuleras de. En GitHub issue dokumenterade 39 föräldralösa renderingsprocesser som förbrukade 3,8 GB RAM på en VPS som borde ha haft gott om marginal.

Du kan kontrollera i efterhand med dmesg | grep -i "oom\|killed\|chromium", men de flesta tänker inte på att titta där. De startar om OpenClaw, det fungerar i några minuter, och sedan händer det igen.

Den officiella sidan för serverkrav rekommenderar minst 4 GB för en grundläggande uppsättning. Men den siffran förutsätter ingen webbläsarautomation. Med webbläsaren aktiverad är 8 GB det realistiska golvet. På Hetzner är det skillnaden mellan en cpx22 (5 $/mån) och en cpx42 (17 $/mån).

Fel 4: Dockers saknade delade minne

Om du kör OpenClaw i Docker (vanligt för VPS-deployments) finns det en till fälla. Dockers standard-/dev/shm är 64 MB. Chromium använder delat minne för interprocesskommunikation. När det tar slut kraschar flikar tyst eller renderar tomma sidor.

Lösningen är en rad i din docker-compose.yml:

shm_size: '2gb'

Eller montera det explicit:

volumes:
  - /dev/shm:/dev/shm

Detta dokumenteras inte i OpenClaws installationsguide. Det är ett Docker-specifikt beteende som påverkar alla applikationer som använder Chromium, men om du inte har deployat headless-webbläsare i Docker tidigare vet du inte att du ska leta efter det.

Fel 5: Portkollisioner som ingen varnar för

OpenClaws webbläsarkontrolltjänst körs på en separat port från gatewayen. Som standard är det gatewayns port plus 2. Om din gateway är på 18789 ska webbläsarkontrolltjänsten vara på 18791, och extensionsrelayet på 18792.

I Docker, om du bara exponerar port 18789, är webbläsarkontrolltjänsten oåtkomlig utifrån containern. Ännu värre loggar gatewayen “Browser control service ready” även när port 18791 aldrig faktiskt binds. Issue #17584 spårade detta till att gatewayen importerade fel modul: en som loggar “ready”-meddelandet utan att starta HTTP-servern. Loggen säger att allt är bra. Porten är död.

I Kubernetes, om en annan container i samma pod redan använder port 9222 (standard-CDP-porten), detekterar OpenClaws ensurePortAvailable()-funktion porten som upptagen och vägrar ansluta, även om ockupanten är exakt den Chromium-instans som OpenClaw borde prata med.

GitHub issue #10994 dokumenterar ett fall där användarens VPS-uppsättning fungerade korrekt. Sedan, efter några automatiserade åtgärder, fastnade CDP-porten. Enda lösningen var att hitta och döda vilsna Chromium-processer som höll porten.

Varför dessa fel förstärker varandra

Vart och ett av dessa fem problem har en känd lösning. Men de samverkar. Du löser snap-problemet och stöter på headless-standardvärdet. Du fixar konfigurationen och Chromium startar. Det körs i tio minuter, sedan slår OOM-killern till. Du lägger till swap-utrymme, och nu orsakar Dockers gräns för delat minne tysta renderingsfel. Du fixar det och upptäcker att port 18791 inte är exponerad.

Felsökningsslingan ser ut så här: sök fel, hitta delvis lösning, tillämpa lösning, stöta på nästa fel, upprepa. En Discord-användare beskrev att ha installerat om hela sitt operativsystem “för 3:e eller 4:e gången.” En annan rapporterade att webbläsaren var “instabil” efter vad de trodde var en komplett uppsättning. En tredje öppnade en issue med den enkla titeln “Browser tool consistently fails on VPS.”

Problemet är inte att varje enskild lösning är svår. Problemet är att det finns fem, att de beror på ditt specifika operativsystem, pakethanterare, containerruntime och VPS-leverantör, och att ett enda misstag i kedjan innebär att webbläsaren inte fungerar.

OpenClaw-teamet förtjänar erkännande för att de stadigt fixar relaterade buggar. Den vilseledande “ready”-loggen, uppstädningen av föräldralösa renderare och CDP-porthanteringen har alla förbättrats i senaste versionerna. Men uppströmskorrigeringarna adresserar symptom inom OpenClaws kod. De kan inte installera rätt Chromium-binär på din server, konfigurera Dockers delade minne eller allokera tillräckligt med RAM för webbläsarautomation. Det förblir ditt ansvar.

Hur vi kraschade Chromium tre gånger (och vad vi lärde oss)

Vi kör varje OpenClaw.rocks-agent på Kubernetes med vår öppen källkods-operator. Webbläsar-sidecaren tog oss veckor att få rätt. Vi stötte på vår egen version av varje problem beskrivet ovan, plus några som bara dyker upp i en containerorkestreringskontext.

Idén var enkel: köra Chromium som en separat container bredvid OpenClaw, ansluten via CDP. En rad i Custom Resource och webbläsaren bara fungerar.

spec:
  chromium:
    enabled: true

Så här blev den raden till i verkligheten.

Krasch 1: Fel användare, skrivskyddat filsystem

Vårt första försök körde Chromium-containern som UID 1001 med ett skrivskyddat rotfilsystem. Bästa praxis för säkerhet. Och helt trasigt. Browserless-avbildningen förväntar sig UID 999 (blessuser), och Node.js anropar os.userInfo() vid uppstart, vilket misslyckas med ENOENT när UID:t saknar /etc/passwd-post. Även efter att ha fixat UID:t blockerade det skrivskyddade filsystemet Chrome från att skriva temporära filer. Sidecaren kraschade vid varje uppstart innan den skrev en enda loggrad. Issue #12 har hela historien.

Krasch 2: WebSocket-säkerhetsmuren

Med containern äntligen igång var Chromium uppe, CDP svarade på port 9222, men OpenClaw vägrade använda det. Gatewayen band till poddens LAN-IP (krävs för Kubernetes Service-routing), och OpenClaws säkerhetslager blockerade klartext-ws://-anslutningar till icke-loopback-adresser: “SECURITY ERROR: Gateway URL uses plaintext ws:// to a non-loopback address. Both credentials and chat data would be exposed to network interception.”

En legitim säkerhetskontroll. Men i en Kubernetes-pod delar alla containrar ett nätverksnamespace. Trafik mellan dem lämnar aldrig noden. Vi kunde inte ändra OpenClaws säkerhetskontroll, så vi lade till en nginx reverse proxy sidecar som lyssnar på alla interface och vidarebefordrar till gatewayen på loopback. Gatewayen förblir säker. Servicen förblir nåbar. Issue #135 dokumenterar felsökningen.

Krasch 3: Port 3000-kollision

Chromium körde. Gatewayen var proxiad. Men webbläsaren anslöt fortfarande inte. Browserless-avbildningen använder port 3000 som standard, vilket kolliderade med OpenClaws interna webbläsarkontrolltjänst. Och när vi bytte till port 9222 detekterade OpenClaws ensurePortAvailable() den som “använd av något annat” och vägrade ansluta, eftersom i ett delat nätverksnamespace ser sidecarens port lokal ut.

Lösningen var att använda poddens IP-adress (via Kubernetes Downward API) istället för localhost för CDP-URL:en. En icke-loopback-adress säger åt OpenClaw att använda remote/attach-only-läge: ansluta till det som redan kör istället för att försöka starta en egen webbläsare. PR #183 löste detta.

Resultatet: fem fixar, automatiskt tillämpade

Var och en av dessa krascher lärde oss något. Den nuvarande operatorn kodar in allt detta:

Sidecar-isolering. Chromium körs i sin egen container. Ingen snap. Ingen Playwright. Inga headless-flaggor. Browserless-avbildningen hanterar allt det.

Dedikerade resurser. Sidecaren får egna CPU- och minnesbegränsningar (250m-1000m CPU, 512Mi-2Gi RAM som standard, konfigurerbart). Om Chromium överskrider sin minnesgräns startar Kubernetes bara om webbläsarcontainern. Din agent fortsätter köra.

Delat minne. Operatorn monterar automatiskt en 1 GB minnesbaserad volym på /dev/shm. Ingen Docker shm_size-konfiguration behövs.

Portroutning. Podd-IP för CDP-URL:en aktiverar fjärrläge. OpenClaw ansluter till sidecaren istället för att försöka ta porten. ensurePortAvailable()-konflikten försvinner.

Inbyggd anti-bot-detektering. Många webbplatser flaggar standard headless Chromium och blockerar automation. Operatorn stöder extraArgs på Chromium-sidecaren, så du kan skicka flaggor som --disable-blink-features=AutomationControlled och anpassade user agents utan att bygga en anpassad containeravbildning:

spec:
  chromium:
    enabled: true
    extraArgs:
      - "--disable-blink-features=AutomationControlled"
      - "--user-agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
      - "--window-size=1920,1080"

Säkerhet utan kompromisser. Alla Linux-capabilities borttagna, privilegieeskalering inaktiverad, seccomp RuntimeDefault, icke-root UID 999. Inget --no-sandbox som root.

Vad detta betyder för dig

Om du kör OpenClaw på en VPS och webbläsaren fungerar, grattis. Du har navigerat fem distinkta felsätt och kommit ut på andra sidan. Behåll din uppsättning. Säkerhetskopiera din konfiguration.

Om webbläsaren inte fungerar, eller fungerar sporadiskt, eller om du är trött på att felsöka Chromium på en VPS för 5 dollar, fundera på vad din tid är värd.

OpenClaw.rocks kör varje agent på Kubernetes med operatorn beskriven ovan. Webbläsar-sidecaren är förkonfigurerad. Minne är allokerat. Portar är routade. Säkerhet är härdad. Du installerar inget, konfigurerar inget och felsöker inget.

Din agent får en webbläsare som fungerar. Varje gång. Direkt ur lådan.

De fem fixarna sammanfattade

Om du vill fortsätta med egen hosting, här är den kompletta checklistan:

  1. Byt ut snap Chromium mot Google Chromes .deb-paket eller Playwrights fristående binär
  2. Aktivera headless-läge: openclaw config set browser.headless true och browser.noSandbox true
  3. Allokera 8 GB+ RAM eller lägg till 4 GB swap för webbläsarautomation
  4. Montera delat minne i Docker: shm_size: '2gb'
  5. Exponera alla tre portar: gateway, webbläsarkontroll (gateway + 2) och extensionsrelay (gateway + 3)

Eller hoppa över checklistan. Hämta din assistent på OpenClaw.rocks och låt oss sköta infrastrukturen.