«Har enorme problemer med VPS-en min. Installerer OpenClaw på nytt for 3. eller 4. gang nå.»

Den meldingen dukket opp i OpenClaw Discord forrige måned. Brukeren var ikke alene. Bla gjennom community-kanalene, og du finner dusinvis av variasjoner over samme tema: nettleserverktøyet feiler, agenten kan ikke nå Chromium, VPS-en går tom for minne, alt fungerte i går og nå gjør det ikke det.

Hvis du leser dette fordi du nettopp søkte etter «OpenClaw nettleser fungerer ikke VPS», er du på rett sted. Dette innlegget forklarer de fem tingene som går galt, hvorfor de samhandler på frustrerende måter, og hvordan vi løste alle sammen i OpenClaw.rocks Kubernetes-operatoren slik at du aldri trenger å tenke på nettleseroppsett igjen.

Feilen alle ser

Den vanligste feilmeldingen i OpenClaw-communityet er denne:

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

Den dukker opp på Ubuntu, Debian, i Docker, på Hetzner, Hostinger, GCP og overalt ellers hvor folk prøver å kjøre OpenClaw med nettleserautomatisering. Gateway-loggene sier «Browser control service ready.» Men når agenten prøver å bruke nettleseren, timer den ut.

Feilen er generisk. Årsakene er det ikke. Det er minst fem distinkte feilmodi, og de ser identiske ut utenfra.

Feil 1: Snap Chromium og AppArmor-muren

På en fersk Ubuntu 22.04+ server gir which chromium-browser stien /usr/bin/chromium-browser. Det ser korrekt ut. Det er det ikke.

Siden Ubuntu 22.04 er standard Chromium-pakken en snap. Når OpenClaws gateway prøver å starte den binære filen via en systemd-tjeneste, blokkerer AppArmors begrensningslag den. Snap-pakken kan ikke binde Chrome DevTools Protocol (CDP) debugging-porter gjennom sandboxen. Den binære filen starter, ser ut til å kjøre, og feiler deretter stille med å åpne porten OpenClaw trenger.

Du vil se «Failed to start Chrome CDP on port 18800» i loggene, eller noen ganger ingenting i det hele tatt. Nettleserprosessen starter og dør før den skriver en eneste logglinje.

Løsningen er å installere Google Chromes .deb-pakke eller bruke Playwrights frittstående Chromium-binær fra ~/.cache/ms-playwright/. Begge omgår snap-sandboxen. Men løsningen er ikke opplagt. OpenClaws nettleserdeteksjon skanner standardstier i rekkefølge, finner snap-binæren først og prøver å bruke den. GitHub issue #4978 har en fullstendig gjennomgang.

Feil 2: Headless-standardverdier som forutsetter en skjerm

OpenClaw leveres med headless: false og noSandbox: false som nettleserstandarder. Det gir mening på en Mac eller Windows-maskin med skjerm. På en VPS finnes det ingen skjerm. Uten eksplisitt konfigurasjon prøver Chromium å åpne et vindu på en displayserver som ikke eksisterer.

To konfigurasjonsendringer fikser det:

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

De fleste VPS-guider nevner dette. Men hvis du følger standard OpenClaw-installasjonsinstruksjonene, dukker ingen av linjene opp. Du installerer, du prøver nettleseren, den feiler. Du søker etter feilen. Du finner et blogginnlegg. Du endrer konfigurasjonen. Du starter på nytt. Og så kommer feil nummer tre.

Feil 3: Den usynlige OOM-killen

En enkelt Chromium-fane med noen åpne sider bruker 2 til 4 GB RAM. På en VPS med 4 GB er det nesten ingenting igjen til OpenClaw selv, operativsystemet og eventuelle andre kjørende tjenester.

Når Linux går tom for minne, avslutter kjernens OOM-killer den mest minnekrevende prosessen. Det er Chromium. Prosessen dør. OpenClaw logger en nettleser-timeout. Ingen krasjrapport, ingen stacktrace, ingen indikasjon på at minne var problemet.

Det finnes også en mer subtil versjon av dette problemet. Chromium starter underordnede renderer-prosesser for hver fane. Hvis disse ikke ryddes opp ordentlig, akkumuleres de. Et GitHub issue dokumenterte 39 foreldreløse renderer-prosesser som brukte 3,8 GB RAM på en VPS som burde ha hatt rikelig med margin.

Du kan sjekke i etterkant med dmesg | grep -i "oom\|killed\|chromium", men de fleste tenker ikke på å se der. De restarter OpenClaw, det fungerer i noen minutter, og så skjer det igjen.

Den offisielle siden for serverkrav anbefaler minimum 4 GB for et grunnleggende oppsett. Men det tallet forutsetter ingen nettleserautomatisering. Med nettleseren aktivert er 8 GB det realistiske gulvet. Hos Hetzner er det forskjellen mellom en cpx22 ($5/mnd.) og en cpx42 ($17/mnd.).

Feil 4: Dockers manglende delte minne

Hvis du kjører OpenClaw i Docker (vanlig for VPS-deployments), er det enda en felle. Dockers standard /dev/shm er 64 MB. Chromium bruker delt minne til interprosesskommunikasjon. Når det går tomt, krasjer faner stille eller renderer tomme sider.

Løsningen er én linje i din docker-compose.yml:

shm_size: '2gb'

Eller mount det eksplisitt:

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

Dette er ikke dokumentert i OpenClaws oppsettguide. Det er en Docker-spesifikk oppførsel som påvirker enhver applikasjon som bruker Chromium, men med mindre du har deployet headless-nettlesere i Docker før, ville du ikke vite at du skal se etter det.

Feil 5: Portkollisjoner ingen advarte om

OpenClaws browser control service kjører på en separat port fra gatewayen. Som standard er det gateway-porten pluss 2. Hvis gatewayen din er på 18789, skal browser control service være på 18791, og extension relay på 18792.

I Docker, hvis du bare eksponerer port 18789, er browser control service utilgjengelig utenfra containeren. Enda verre logger gatewayen «Browser control service ready» selv når port 18791 aldri faktisk binder. Issue #17584 sporet dette til at gatewayen importerte feil modul: en som logger «ready»-meldingen uten å starte HTTP-serveren. Loggen forteller deg at alt er i orden. Porten er død.

I Kubernetes, hvis en annen container i samme pod allerede bruker port 9222 (standard CDP-porten), oppdager OpenClaws ensurePortAvailable()-funksjon porten som opptatt og nekter å koble til, selv om den som opptar porten er nøyaktig den Chromium-instansen OpenClaw burde snakke med.

GitHub issue #10994 dokumenterer et tilfelle der brukerens VPS-oppsett fungerte korrekt. Deretter, etter noen automatiserte handlinger, hang CDP-porten seg. Eneste løsning var å finne og drepe streifende Chromium-prosesser som holdt porten.

Hvorfor disse feilene akkumuleres

Hvert av disse fem problemene har en kjent løsning. Men de samhandler. Du løser snap-problemet og treffer headless-standardverdien. Du fikser konfigurasjonen og Chromium starter. Det kjører i ti minutter, så slår OOM-killeren til. Du legger til swap-plass, og nå forårsaker Dockers delt-minne-grense stille renderingsfeil. Du fikser det og oppdager at port 18791 ikke er eksponert.

Feilsøkingsløkken ser slik ut: søk feil, finn delvis løsning, anvend løsning, treff neste feil, gjenta. En Discord-bruker beskrev å ha reinstallert hele operativsystemet «for 3. eller 4. gang». En annen rapporterte at nettleseren var «ustabil» etter det de trodde var et komplett oppsett. En tredje åpnet et issue med den enkle tittelen «Browser tool consistently fails on VPS».

Problemet er ikke at hver enkelt løsning er vanskelig. Problemet er at det er fem av dem, de avhenger av ditt spesifikke operativsystem, pakkebehandler, container-runtime og VPS-leverandør, og én enkelt feil i kjeden betyr at nettleseren ikke fungerer.

OpenClaw-teamet fortjener anerkjennelse for jevnt å fikse relaterte bugs. Den villedende «ready»-loggen, oppryddingen av foreldreløse renderere og CDP-porthåndteringen har alle blitt forbedret i nyere versjoner. Men upstream-rettelsene adresserer symptomer inne i OpenClaws kode. De kan ikke installere riktig Chromium-binær på serveren din, konfigurere Docker delt minne eller allokere nok RAM til nettleserautomatisering. Det forblir ditt ansvar.

Hvordan vi krasjet Chromium tre ganger (og hva vi lærte)

Vi kjører hver OpenClaw.rocks-agent på Kubernetes med vår åpen kildekode-operator. Nettleser-sidecaren tok oss uker å få til å fungere. Vi traff vår egen versjon av hvert problem beskrevet ovenfor, pluss noen som bare dukker opp i en containerorkestreringssammenheng.

Ideen var enkel: kjør Chromium som en separat container ved siden av OpenClaw, koblet via CDP. Én linje i Custom Resource og nettleseren bare fungerer.

spec:
  chromium:
    enabled: true

Slik ble den ene linjen faktisk til.

Krasj 1: Feil bruker, skrivebeskyttet filsystem

Vårt første forsøk kjørte Chromium-containeren som UID 1001 med et skrivebeskyttet rotfilsystem. Beste sikkerhetspraksis. Og fullstendig ødelagt. Browserless-imaget forventer UID 999 (blessuser), og Node.js kaller os.userInfo() ved oppstart, som feiler med ENOENT når UID-en ikke har en /etc/passwd-oppføring. Selv etter å ha fikset UID-en blokkerte det skrivebeskyttede filsystemet Chrome fra å skrive midlertidige filer. Sidecaren krasjet ved hver oppstart før den skrev en eneste logglinje. Issue #12 har hele historien.

Krasj 2: WebSocket-sikkerhetsmuren

Med containeren endelig kjørende var Chromium oppe, CDP svarte på port 9222, men OpenClaw nektet å bruke det. Gatewayen bandt seg til poddens LAN-IP (påkrevd for Kubernetes Service-routing), og OpenClaws sikkerhetslag blokkerte klartekst ws://-tilkoblinger til ikke-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 sikkerhetssjekk. Men i en Kubernetes-pod deler alle containere et nettverksnamespace. Trafikk mellom dem forlater aldri noden. Vi kunne ikke endre OpenClaws sikkerhetssjekk, så vi la til en nginx reverse proxy sidecar som lytter på alle grensesnitt og videresender til gatewayen på loopback. Gatewayen forblir sikker. Servicen forblir tilgjengelig. Issue #135 dokumenterer feilsøkingen.

Krasj 3: Port 3000-kollisjon

Chromium kjørte. Gatewayen var proxyet. Men nettleseren ville fortsatt ikke koble til. Browserless-imaget bruker port 3000 som standard, som kolliderte med OpenClaws interne browser control service. Og da vi byttet til port 9222, oppdaget OpenClaws ensurePortAvailable() den som «i bruk av noe annet» og nektet tilkobling, fordi i et delt nettverksnamespace ser sidecarens port lokal ut.

Løsningen var å bruke poddens IP-adresse (via Kubernetes Downward API) i stedet for localhost for CDP-URL-en. En ikke-loopback-adresse forteller OpenClaw å bruke remote/attach-only-modus: koble til det som allerede kjører i stedet for å prøve å starte sin egen nettleser. PR #183 løste dette.

Resultatet: fem fikser, automatisk anvendt

Hver av disse krasjene lærte oss noe. Den nåværende operatoren koder inn alt dette:

Sidecar-isolering. Chromium kjører i sin egen container. Ingen snap. Ingen Playwright. Ingen headless-flagg. Browserless-imaget håndterer alt det.

Dedikerte ressurser. Sidecaren får egne CPU- og minnegrenser (250m-1000m CPU, 512Mi-2Gi RAM som standard, konfigurerbart). Hvis Chromium overskrider minnegrensen sin, restarter Kubernetes bare nettlesercontaineren. Agenten din fortsetter å kjøre.

Delt minne. Operatoren monterer automatisk et 1 GB minnebasert volum ved /dev/shm. Ingen Docker shm_size-konfigurasjon nødvendig.

Portrouting. Pod-IP for CDP-URL-en aktiverer fjernmodus. OpenClaw kobler til sidecaren i stedet for å prøve å ta porten. ensurePortAvailable()-konflikten forsvinner.

Innebygd anti-bot-deteksjon. Mange nettsteder flagger standard headless Chromium og blokkerer automatisering. Operatoren støtter extraArgs på Chromium-sidecaren, slik at du kan sende flagg som --disable-blink-features=AutomationControlled og egendefinerte user agents uten å bygge et egendefinert containerimage:

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"

Sikkerhet uten kompromisser. Alle Linux-capabilities fjernet, privilege escalation deaktivert, seccomp RuntimeDefault, non-root UID 999. Ingen --no-sandbox som root.

Hva dette betyr for deg

Hvis du kjører OpenClaw på en VPS og nettleseren fungerer, gratulerer. Du har navigert fem distinkte feilmodi og kommet ut på den andre siden. Behold oppsettet ditt. Ta backup av konfigurasjonen.

Hvis nettleseren ikke fungerer, eller fungerer sporadisk, eller hvis du er lei av å feilsøke Chromium på en VPS til $5, tenk over hva tiden din er verdt.

OpenClaw.rocks kjører hver agent på Kubernetes med operatoren beskrevet ovenfor. Nettleser-sidecaren er forhåndskonfigurert. Minne er allokert. Porter er routet. Sikkerhet er herdet. Du installerer ingenting, konfigurerer ingenting og feilsøker ingenting.

Agenten din får en nettleser som fungerer. Hver gang. Rett ut av boksen.

De fem fiksene oppsummert

Hvis du vil fortsette med selvhosting, her er den komplette sjekklisten:

  1. Erstatt snap Chromium med Google Chromes .deb-pakke eller Playwrights frittstående binær
  2. Aktiver headless-modus: openclaw config set browser.headless true og browser.noSandbox true
  3. Alloker 8 GB+ RAM eller legg til 4 GB swap for nettleserautomatisering
  4. Mount delt minne i Docker: shm_size: '2gb'
  5. Eksponer alle tre porter: gateway, browser control (gateway + 2) og extension relay (gateway + 3)

Eller hopp over sjekklisten. Hent din assistent på OpenClaw.rocks og la oss håndtere infrastrukturen.