“Har kæmpe problemer med min VPS. Geninstallerer OpenClaw for 3. eller 4. gang nu.”

Den besked dukkede op i OpenClaw Discord sidste måned. Brugeren var ikke alene. Scroll gennem community-kanalerne, og du finder dusinvis af variationer over samme tema: browserværktøjet fejler, agenten kan ikke nå Chromium, VPS’en løber tør for hukommelse, alt virkede i går og nu gør det ikke.

Hvis du læser dette, fordi du lige har søgt på “OpenClaw browser virker ikke VPS”, er du det rette sted. Dette indlæg forklarer de fem ting der går galt, hvorfor de interagerer på frustrerende måder, og hvordan vi løste dem alle i OpenClaw.rocks Kubernetes-operatoren, så du aldrig skal tænke på browseropsætning igen.

Fejlen alle ser

Den mest almindelige fejlmeddelelse i OpenClaw-communityet er denne:

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

Den dukker op på Ubuntu, Debian, i Docker, på Hetzner, Hostinger, GCP og alle andre steder, hvor folk prøver at køre OpenClaw med browserautomatisering. Gateway-loggene siger “Browser control service ready.” Men når agenten forsøger at bruge browseren, timeout’er den.

Fejlen er generisk. Årsagerne er det ikke. Der er mindst fem forskellige fejltilstande, og de ser identiske ud udefra.

Fejl 1: Snap Chromium og AppArmor-muren

På en frisk Ubuntu 22.04+ server returnerer which chromium-browser stien /usr/bin/chromium-browser. Det ser korrekt ud. Det er det ikke.

Siden Ubuntu 22.04 er standard Chromium-pakken en snap. Når OpenClaws gateway forsøger at starte den binære fil via en systemd-service, blokerer AppArmors begrænsningslag den. Snap-pakken kan ikke binde Chrome DevTools Protocol (CDP) debugging-porte gennem sandboxen. Den binære fil starter, ser ud til at køre, og fejler derefter lydløst med at åbne den port, OpenClaw har brug for.

Du vil se “Failed to start Chrome CDP on port 18800” i loggene, eller nogle gange slet intet. Browserprocessen starter og dør, før den skriver en eneste loglinje.

Løsningen er at installere Google Chromes .deb-pakke eller bruge Playwrights selvstændige Chromium-binær fra ~/.cache/ms-playwright/. Begge omgår snap-sandboxen. Men løsningen er ikke oplagt. OpenClaws browserdetektion scanner standardstier i rækkefølge, finder snap-binæren først og forsøger at bruge den. GitHub issue #4978 har en fuld gennemgang.

Fejl 2: Headless-standardværdier der forudsætter en skærm

OpenClaw leveres med headless: false og noSandbox: false som browserstandarværdier. Det giver mening på en Mac eller Windows-maskine med skærm. På en VPS er der ingen skærm. Uden eksplicit konfiguration forsøger Chromium at åbne et vindue på en displayserver, der ikke eksisterer.

To konfigurationsændringer løser det:

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

De fleste VPS-guider nævner dette. Men hvis du følger OpenClaws standardinstallationsinstruktioner, dukker ingen af linjerne op. Du installerer, du prøver browseren, den fejler. Du søger fejlen. Du finder et blogindlæg. Du ændrer konfigurationen. Du genstarter. Og så kommer du til fejl nummer tre.

Fejl 3: Det usynlige OOM-kill

En enkelt Chromium-fane med et par åbne sider bruger 2 til 4 GB RAM. På en VPS med 4 GB er der næsten intet tilbage til OpenClaw selv, operativsystemet og eventuelle andre kørende tjenester.

Når Linux løber tør for hukommelse, afslutter kernens OOM-killer den mest hukommelseskrævende proces. Det er Chromium. Processen dør. OpenClaw logger en browser-timeout. Ingen crashrapport, ingen stacktrace, ingen indikation af at hukommelse var problemet.

Der er også en mere subtil version af dette problem. Chromium starter underordnede renderer-processer for hver fane. Hvis disse ikke ryddes op korrekt, akkumuleres de. Et GitHub issue dokumenterede 39 forældreløse renderer-processer, der brugte 3,8 GB RAM på en VPS, der burde have haft rigeligt med plads.

Du kan tjekke bagefter med dmesg | grep -i "oom\|killed\|chromium", men de fleste tænker ikke på at kigge der. De genstarter OpenClaw, det virker i et par minutter, og så sker det igen.

Den officielle side for serverkrav anbefaler minimum 4 GB til en grundlæggende opsætning. Men det tal forudsætter ingen browserautomatisering. Med browseren aktiveret er 8 GB det realistiske minimum. Hos Hetzner er det forskellen mellem en cpx22 ($5/md.) og en cpx42 ($17/md.).

Fejl 4: Dockers manglende delte hukommelse

Hvis du kører OpenClaw i Docker (almindeligt for VPS-deployments), er der endnu en fælde. Dockers standard /dev/shm er 64 MB. Chromium bruger delt hukommelse til interprocesskommunikation. Når den løber tør, crasher faner lydløst eller renderer tomme sider.

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

shm_size: '2gb'

Eller mount den eksplicit:

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

Dette er ikke dokumenteret i OpenClaws opsætningsguide. Det er en Docker-specifik adfærd, der påvirker enhver applikation, der bruger Chromium, men medmindre du har deployet headless-browsere i Docker før, ville du ikke vide, at du skal lede efter det.

Fejl 5: Portkollisioner ingen advarede om

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

I Docker, hvis du kun eksponerer port 18789, er browser control service utilgængelig udefra containeren. Endnu værre logger gatewayen “Browser control service ready”, selvom port 18791 aldrig faktisk binder. Issue #17584 sporede dette til, at gatewayen importerede det forkerte modul: et der logger “ready”-beskeden uden at starte HTTP-serveren. Loggen fortæller dig, at alt er fint. Porten er død.

I Kubernetes, hvis en anden container i samme pod allerede bruger port 9222 (standard CDP-porten), detekterer OpenClaws ensurePortAvailable()-funktion porten som optaget og nægter at forbinde, selvom den, der optager porten, er præcis den Chromium-instans, OpenClaw burde tale med.

GitHub issue #10994 dokumenterer et tilfælde, hvor brugerens VPS-opsætning fungerede korrekt. Derefter, efter et par automatiserede handlinger, gik CDP-porten i stå. Den eneste løsning var at finde og dræbe strejfende Chromium-processer, der holdt porten.

Hvorfor disse fejl akkumuleres

Hvert af disse fem problemer har en kendt løsning. Men de interagerer. Du løser snap-problemet og rammer headless-standardværdien. Du retter konfigurationen, og Chromium starter. Det kører i ti minutter, så slår OOM-killeren til. Du tilføjer swap-plads, og nu forårsager Dockers delte hukommelsesgrænse lydløse renderingsfejl. Du fikser det og opdager, at port 18791 ikke er eksponeret.

Fejlsøgningsløkken ser sådan ud: søg fejl, find delvis løsning, anvend løsning, ram næste fejl, gentag. En Discord-bruger beskrev at have geninstalleret hele sit operativsystem “for 3. eller 4. gang.” En anden rapporterede, at browseren var “ustabil” efter det, de troede var en komplet opsætning. En tredje åbnede et issue med den simple titel “Browser tool consistently fails on VPS.”

Problemet er ikke, at hver enkelt løsning er svær. Problemet er, at der er fem, de afhænger af dit specifikke operativsystem, pakkehåndtering, container-runtime og VPS-udbyder, og én enkelt fejl i kæden betyder, at browseren ikke virker.

OpenClaw-teamet fortjener anerkendelse for støt at fikse relaterede bugs. Den vildledende “ready”-log, oprydningen af forældreløse renderere og CDP-porthåndteringen er alle blevet forbedret i nyere versioner. Men upstream-rettelserne adresserer symptomer inden i OpenClaws kode. De kan ikke installere den rigtige Chromium-binær på din server, konfigurere din Docker-delte hukommelse eller allokere nok RAM til browserautomatisering. Det forbliver dit ansvar.

Hvordan vi crashede Chromium tre gange (og hvad vi lærte)

Vi kører hver OpenClaw.rocks-agent på Kubernetes med vores open source-operator. Browser-sidecaren tog os uger at få til at fungere. Vi ramte vores egen version af hvert problem beskrevet ovenfor, plus et par der kun dukker op i en containerorkestreringssammenhæng.

Idéen var simpel: kør Chromium som en separat container ved siden af OpenClaw, forbundet via CDP. Én linje i Custom Resource, og browseren virker bare.

spec:
  chromium:
    enabled: true

Sådan blev den ene linje faktisk til virkelighed.

Crash 1: Forkert bruger, skrivebeskyttet filsystem

Vores første forsøg kørte Chromium-containeren som UID 1001 med et skrivebeskyttet rodfilsystem. Bedste sikkerhedspraksis. Og fuldstændig i stykker. Browserless-imaget forventer UID 999 (blessuser), og Node.js kalder os.userInfo() ved opstart, som fejler med ENOENT, når UID’et ikke har en /etc/passwd-post. Selv efter at have rettet UID’et blokerede det skrivebeskyttede filsystem Chrome fra at skrive midlertidige filer. Sidecaren crashede ved hver opstart, før den skrev en eneste loglinje. Issue #12 har hele historien.

Crash 2: WebSocket-sikkerhedsmuren

Med containeren endelig kørende var Chromium oppe, CDP svarede på port 9222, men OpenClaw nægtede at bruge det. Gatewayen bandt til poddens LAN-IP (påkrævet for Kubernetes Service-routing), og OpenClaws sikkerhedslag blokerede klartekst ws://-forbindelser 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.”

Et legitimt sikkerhedstjek. Men i en Kubernetes-pod deler alle containere et netværksnamespace. Trafik mellem dem forlader aldrig noden. Vi kunne ikke ændre OpenClaws sikkerhedstjek, så vi tilføjede en nginx reverse proxy sidecar, der lytter på alle interfaces og videresender til gatewayen på loopback. Gatewayen forbliver sikker. Servicen forbliver tilgængelig. Issue #135 dokumenterer fejlsøgningen.

Crash 3: Port 3000-kollision

Chromium kørte. Gatewayen var proxiet. Men browseren ville stadig ikke forbinde. Browserless-imaget bruger port 3000 som standard, som kolliderede med OpenClaws interne browser control service. Og da vi skiftede til port 9222, detekterede OpenClaws ensurePortAvailable() den som “i brug af noget andet” og nægtede at forbinde, fordi i et delt netværksnamespace ser sidecarens port lokal ud.

Løsningen var at bruge poddens IP-adresse (via Kubernetes Downward API) i stedet for localhost til CDP-URL’en. En ikke-loopback-adresse fortæller OpenClaw at bruge remote/attach-only-tilstand: forbind til det, der allerede kører, i stedet for at forsøge at starte sin egen browser. PR #183 løste dette.

Resultatet: fem fikse, automatisk anvendt

Hver af disse crashes lærte os noget. Den nuværende operator koder det hele ind:

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

Dedikerede ressourcer. Sidecaren får sine egne CPU- og hukommelsesgrænser (250m-1000m CPU, 512Mi-2Gi RAM som standard, konfigurerbart). Hvis Chromium overskrider sin hukommelsesgrænse, genstarter Kubernetes kun browsercontaineren. Din agent kører videre.

Delt hukommelse. Operatoren monterer automatisk et 1 GB hukommelsesbaseret volume ved /dev/shm. Ingen Docker shm_size-konfiguration nødvendig.

Portrouting. Pod-IP til CDP-URL’en aktiverer fjerntilstand. OpenClaw forbinder til sidecaren i stedet for at forsøge at optage porten. ensurePortAvailable()-konflikten forsvinder.

Indbygget anti-bot-detektion. Mange websites flagger standard headless Chromium og blokerer automatisering. Operatoren understøtter extraArgs på Chromium-sidecaren, så du kan sende flag som --disable-blink-features=AutomationControlled og brugerdefinerede user agents uden at bygge et brugerdefineret 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"

Sikkerhed uden kompromiser. Alle Linux-capabilities fjernet, privilege escalation deaktiveret, seccomp RuntimeDefault, non-root UID 999. Ingen --no-sandbox som root.

Hvad dette betyder for dig

Hvis du kører OpenClaw på en VPS, og browseren virker, tillykke. Du har navigeret fem forskellige fejltilstande og er kommet ud på den anden side. Behold din opsætning. Tag backup af din konfiguration.

Hvis browseren ikke virker, eller virker sporadisk, eller hvis du er træt af at fejlsøge Chromium på en VPS til $5, så overvej hvad din tid er værd.

OpenClaw.rocks kører hver agent på Kubernetes med operatoren beskrevet ovenfor. Browser-sidecaren er forudkonfigureret. Hukommelse er allokeret. Porte er routet. Sikkerhed er hærdet. Du installerer intet, konfigurerer intet og fejlsøger intet.

Din agent får en browser, der virker. Hver gang. Lige ud af boksen.

De fem fikse opsummeret

Hvis du vil forblive selvhostet, her er den komplette tjekliste:

  1. Erstat snap Chromium med Google Chromes .deb-pakke eller Playwrights selvstændige binær
  2. Aktivér headless-tilstand: openclaw config set browser.headless true og browser.noSandbox true
  3. Alloker 8 GB+ RAM eller tilføj 4 GB swap til browserautomatisering
  4. Mount delt hukommelse i Docker: shm_size: '2gb'
  5. Eksponér alle tre porte: gateway, browser control (gateway + 2) og extension relay (gateway + 3)

Eller spring tjeklisten over. Hent din assistent på OpenClaw.rocks og lad os håndtere infrastrukturen.