„Hatalmas gondjaim vannak a VPS-emmel. Most telepítem újra az OpenClaw-ot 3. vagy 4. alkalommal.”

Ez az üzenet jelent meg az OpenClaw Discordon a múlt hónapban. A felhasználó nem volt egyedül. Görgess végig a közösségi csatornákon, és tucatnyi változatot találsz ugyanarra a témára: a böngészőeszköz meghibásodik, az ágens nem éri el a Chromiumot, a VPS-nek elfogy a memóriája, tegnap minden működött, ma nem.

Ha azért olvasod ezt, mert éppen az „OpenClaw böngésző nem működik VPS” keresést futtatod, jó helyen vagy. Ez a bejegyzés elmagyarázza azt az öt dolgot, ami elromlik, miért hatnak egymásra frusztrálóan, és hogyan oldottuk meg mindet az OpenClaw.rocks Kubernetes operátorban, hogy soha többé ne kelljen böngészőbeállítással foglalkoznod.

A hiba, amit mindenki lát

A leggyakoribb hibaüzenet az OpenClaw közösségben ez:

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

Megjelenik Ubuntu-n, Debian-on, Dockerben, Hetzneren, Hostingeren, GCP-n és mindenhol máshol, ahol OpenClaw-ot próbálnak böngésző-automatizálással futtatni. A gateway logok azt mondják: „Browser control service ready.” De amikor az ágens megpróbálja használni a böngészőt, időtúllépés történik.

A hiba általános. Az okok nem azok. Legalább öt különálló meghibásodási mód létezik, és kívülről mind egyformának tűnnek.

Meghibásodás 1: Snap Chromium és az AppArmor fal

Egy friss Ubuntu 22.04+ szerveren a which chromium-browser a /usr/bin/chromium-browser útvonalat adja vissza. Helyesnek tűnik. Nem az.

Az Ubuntu 22.04 óta az alapértelmezett Chromium csomag snap. Amikor az OpenClaw gateway-e megpróbálja elindítani ezt a binárist egy systemd szolgáltatáson keresztül, az AppArmor korlátozási rétege blokkolja. A snap csomag nem tudja megnyitni a Chrome DevTools Protocol (CDP) hibakeresési portjait a sandboxon keresztül. A bináris elindul, úgy tűnik, hogy fut, majd csendben nem nyitja meg azt a portot, amire az OpenClaw-nak szüksége van.

A logokban „Failed to start Chrome CDP on port 18800” jelenik meg, vagy néha semmi. A böngészőfolyamat elindul és meghal, mielőtt egyetlen sort írna a logba.

A megoldás a Google Chrome .deb csomagjának telepítése vagy a Playwright önálló Chromium binárisának használata a ~/.cache/ms-playwright/ mappából. Mindkettő megkerüli a snap sandboxot. De a megoldás nem nyilvánvaló. Az OpenClaw böngészőfelismerése sorrendben vizsgálja a standard útvonalakat, először a snap binárist találja meg, és azt próbálja használni. A GitHub issue #4978 tartalmazza a teljes leírást.

Meghibásodás 2: Headless alapértékek, amelyek kijelzőt feltételeznek

Az OpenClaw headless: false és noSandbox: false böngésző-alapértékekkel érkezik. Ez logikus egy Mac-en vagy Windows gépen kijelzővel. VPS-en nincs kijelző. Explicit konfiguráció nélkül a Chromium megpróbál egy ablakot nyitni egy nem létező megjelenítőszerveren.

Két konfigurációs változtatás megoldja:

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

A legtöbb VPS útmutató megemlíti ezt. De ha az OpenClaw standard telepítési utasításait követed, egyik sor sem jelenik meg. Telepítesz, kipróbálod a böngészőt, meghibásodik. Keresed a hibát. Találsz egy blogbejegyzést. Módosítod a konfigurációt. Újraindítod. És jön a harmadik meghibásodás.

Meghibásodás 3: A láthatatlan OOM kill

Egyetlen Chromium fül néhány nyitott oldallal 2-4 GB RAM-ot fogyaszt. Egy 4 GB-os VPS-en szinte semmi sem marad magának az OpenClaw-nak, az operációs rendszernek és bármely más futó szolgáltatásnak.

Amikor a Linuxnak elfogy a memóriája, a kernel OOM killere leállítja a legtöbb memóriát fogyasztó folyamatot. Ez a Chromium. A folyamat meghal. Az OpenClaw böngésző-időtúllépést naplóz. Nincs összeomlási jelentés, nincs stack trace, semmi jel arra, hogy a memória volt a probléma.

Van ennek a problémának egy finomabb változata is. A Chromium minden fülhöz gyermek renderer folyamatokat indít. Ha ezeket nem takarítják el rendesen, felhalmozódnak. Egy GitHub issue 39 árva renderer folyamatot dokumentált, amelyek 3,8 GB RAM-ot fogyasztottak egy olyan VPS-en, amelynek bőven kellett volna tartaléknak lennie.

Utólag ellenőrizheted a dmesg | grep -i "oom\|killed\|chromium" paranccsal, de a legtöbben nem gondolnak rá, hogy ott nézzenek. Újraindítják az OpenClaw-ot, néhány percig működik, aztán újra megtörténik.

A hivatalos szerverkövetelmények oldal minimum 4 GB-ot ajánl alapkonfigurációhoz. De ez a szám böngésző-automatizálás nélkül értendő. Bekapcsolt böngészővel 8 GB a reális minimum. A Hetznernél ez a különbség egy cpx22 (5 $/hó) és egy cpx42 (17 $/hó) között.

Meghibásodás 4: A Docker hiányzó megosztott memóriája

Ha az OpenClaw-ot Dockerben futtatod (VPS telepítéseknél gyakori), van még egy csapda. A Docker alapértelmezett /dev/shm mérete 64 MB. A Chromium megosztott memóriát használ a folyamatok közötti kommunikációhoz. Ha elfogy, a fülek csendben összeomlanak vagy üres oldalakat renderelnek.

A megoldás egyetlen sor a docker-compose.yml fájlban:

shm_size: '2gb'

Vagy csatold explicit módon:

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

Ez nincs dokumentálva az OpenClaw telepítési útmutatójában. Ez egy Docker-specifikus viselkedés, amely minden Chromiumot használó alkalmazást érint, de ha korábban nem telepítettél headless böngészőket Dockerben, nem tudnád, hogy ezt keresd.

Meghibásodás 5: Portkollíziók, amelyekre senki nem figyelmeztet

Az OpenClaw browser control szolgáltatása a gateway-től külön porton fut. Alapértelmezés szerint a gateway port plusz 2. Ha a gateway-ed a 18789-es porton fut, a browser control szolgáltatásnak a 18791-esen kell lennie, az extension relay-nek pedig a 18792-esen.

Dockerben, ha csak a 18789-es portot teszed elérhetővé, a browser control szolgáltatás elérhetetlen a konténeren kívülről. Ráadásul a gateway naplózza: „Browser control service ready”, még akkor is, ha a 18791-es port soha nem kötődik meg. Az issue #17584 kiderítette, hogy a gateway rossz modult importált: olyat, amely naplózza a „ready” üzenetet anélkül, hogy elindítaná a HTTP szervert. A log azt mondja, minden rendben. A port halott.

Kubernetesben, ha egy másik konténer ugyanabban a podban már használja a 9222-es portot (a standard CDP port), az OpenClaw ensurePortAvailable() funkciója foglaltnak észleli a portot és megtagadja a csatlakozást, még ha a foglaló pontosan az a Chromium példány, amellyel az OpenClaw-nak kommunikálnia kellene.

A GitHub issue #10994 dokumentál egy esetet, ahol a felhasználó VPS-beállítása helyesen működött. Aztán néhány automatizált művelet után a CDP port beragadt. Az egyetlen megoldás a kóbor Chromium folyamatok megtalálása és leállítása volt, amelyek a portot tartották.

Miért halmozódnak ezek a meghibásodások

Mind az öt problémának van ismert megoldása. De egymásra hatnak. Megoldod a snap problémát és beleütközöl a headless alapértékbe. Javítod a konfigurációt és a Chromium elindul. Tíz percig fut, aztán az OOM killer lecsap. Hozzáadsz swap tárhelyet, és most a Docker megosztott memória korlátja csendes renderelési hibákat okoz. Megjavítod és kiderül, hogy a 18791-es port nincs kitéve.

A hibakeresési hurok így néz ki: hibát keresni, részleges megoldást találni, megoldást alkalmazni, következő hibába ütközni, ismételni. Egy Discord felhasználó leírta, hogy az egész operációs rendszerét „3. vagy 4. alkalommal” telepítette újra. Egy másik jelentette, hogy a böngésző „instabil” volt az után, amit teljes beállításnak hitt. Egy harmadik egyszerűen a „Browser tool consistently fails on VPS” címmel nyitott issue-t.

A probléma nem az, hogy az egyes javítások nehezek lennének. A probléma az, hogy öt van belőlük, a konkrét operációs rendszeredtől, csomagkezelődtől, konténer runtime-odtól és VPS szolgáltatódtól függenek, és egyetlen hiba a láncban azt jelenti, hogy a böngésző nem működik.

Az OpenClaw csapat elismerést érdemel azért, hogy folyamatosan javítja a kapcsolódó hibákat. A félrevezető „ready” log, az árva rendererek takarítása és a CDP port kezelése mind javultak a közelmúltbeli verziókban. De az upstream javítások az OpenClaw kódján belüli tüneteket kezelik. Nem tudják a megfelelő Chromium binárist telepíteni a szerveredre, konfigurálni a Docker megosztott memóriáját, vagy elegendő RAM-ot allokálni a böngésző-automatizáláshoz. Az a te felelősséged marad.

Hogyan törték el háromszor a Chromiumot (és mit tanultunk belőle)

Minden OpenClaw.rocks ágenst Kubernetesen futtatunk a nyílt forráskódú operátorunkkal. A böngésző sidecar hetekbe telt, mire megfelelően működött. Találkoztunk a fent leírt minden probléma saját verziójával, plusz néhánnyal, amelyek csak konténer-orkesztrálási kontextusban jelennek meg.

Az ötlet egyszerű volt: futtasd a Chromiumot külön konténerként az OpenClaw mellett, CDP-n keresztül csatlakoztatva. Egy sor a Custom Resource-ban és a böngésző egyszerűen működik.

spec:
  chromium:
    enabled: true

Így született meg valójában ez az egyetlen sor.

Összeomlás 1: Rossz felhasználó, csak olvasható fájlrendszer

Első próbálkozásunk a Chromium konténert UID 1001-ként futtatta csak olvasható gyökérfájlrendszerrel. Biztonsági best practice. És teljesen hibás. A browserless image UID 999-et vár (blessuser), és a Node.js induláskor meghívja az os.userInfo()-t, ami ENOENT hibával sikertelen, ha az UID-nak nincs /etc/passwd bejegyzése. Az UID javítása után is a csak olvasható fájlrendszer megakadályozta a Chrome-ot az ideiglenes fájlok írásában. A sidecar minden induláskor összeomlott, mielőtt egyetlen sort írt volna a logba. Az issue #12 tartalmazza a teljes történetet.

Összeomlás 2: A WebSocket biztonsági fal

A konténer végre futott, a Chromium működött, a CDP válaszolt a 9222-es porton, de az OpenClaw megtagadta a használatát. A gateway a pod LAN IP-jéhez kötődött (szükséges a Kubernetes Service routinghoz), és az OpenClaw biztonsági rétege blokkolta a titkosítatlan ws:// kapcsolatokat nem-loopback címekre: „SECURITY ERROR: Gateway URL uses plaintext ws:// to a non-loopback address. Both credentials and chat data would be exposed to network interception.”

Jogos biztonsági ellenőrzés. De egy Kubernetes podban minden konténer osztja a hálózati namespace-t. A közöttük lévő forgalom soha nem hagyja el a node-ot. Nem tudtuk megváltoztatni az OpenClaw biztonsági ellenőrzését, ezért hozzáadtunk egy nginx reverse proxy sidecar-t, amely minden interfészen figyel és a gateway-re továbbít loopbacken. A gateway biztonságos marad. A Service elérhető marad. Az issue #135 dokumentálja a hibakeresést.

Összeomlás 3: 3000-es port kollízió

A Chromium futott. A gateway-nek volt proxyja. De a böngésző továbbra sem csatlakozott. A browserless image alapértelmezetten a 3000-es portot használja, ami ütközött az OpenClaw belső browser control szolgáltatásával. És amikor a 9222-es portra váltottunk, az OpenClaw ensurePortAvailable() „valami más által használt”-ként észlelte, és megtagadta a csatlakozást, mert megosztott hálózati namespace-ben a sidecar portja lokálisnak tűnik.

A megoldás a pod IP-címének használata volt (a Kubernetes Downward API-n keresztül) a localhost helyett a CDP URL-hez. Egy nem-loopback cím arra utasítja az OpenClaw-ot, hogy remote/attach-only módot használjon: csatlakozzon ahhoz, ami már fut, ahelyett, hogy saját böngészőt próbálna indítani. A PR #183 megoldotta ezt.

Az eredmény: öt javítás, automatikusan alkalmazva

Minden összeomlás tanított minket valamire. A jelenlegi operátor kódolja mindezt:

Sidecar izoláció. A Chromium saját konténerben fut. Nincs snap. Nincs Playwright. Nincsenek headless flag-ek. A browserless image mindent kezel.

Dedikált erőforrások. A sidecar saját CPU és memória limiteket kap (250m-1000m CPU, 512Mi-2Gi RAM alapértelmezetten, konfigurálható). Ha a Chromium meghaladja a memórialimitjét, a Kubernetes csak a böngésző konténert indítja újra. Az ágens tovább fut.

Megosztott memória. Az operátor automatikusan csatol egy 1 GB-os memória-alapú kötetet a /dev/shm-re. Nincs szükség Docker shm_size konfigurációra.

Port routing. Pod IP a CDP URL-hez aktiválja a távoli módot. Az OpenClaw a sidecar-hoz csatlakozik ahelyett, hogy a portot próbálná elfoglalni. Az ensurePortAvailable() konfliktus eltűnik.

Beépített anti-bot detekció. Sok weboldal felismeri az alapértelmezett headless Chromiumot és blokkolja az automatizálást. Az operátor támogatja az extraArgs paramétert a Chromium sidecar-on, így átadhatók flag-ek mint --disable-blink-features=AutomationControlled és egyéni user agentek anélkül, hogy egyéni konténer image-et kellene építeni:

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"

Biztonság kompromisszumok nélkül. Minden Linux capability eltávolítva, jogosultság-eszkaláció letiltva, seccomp RuntimeDefault, nem-root UID 999. Nincs --no-sandbox root-ként.

Mit jelent ez számodra

Ha OpenClaw-ot futtatsz VPS-en és a böngésző működik, gratulálok. Átnavigáltál öt különálló meghibásodási módon és átjutottál a másik oldalra. Tartsd meg a beállításodat. Készíts biztonsági mentést a konfigurációdról.

Ha a böngésző nem működik, vagy szórványosan működik, vagy belefáradtál a Chromium hibakeresésébe egy 5 dolláros VPS-en, gondold át, mennyit ér az időd.

Az OpenClaw.rocks minden ágenst Kubernetesen futtat a fent leírt operátorral. A böngésző sidecar előre konfigurált. A memória allokálva. A portok irányítva. A biztonság erősítve. Nem telepítesz semmit, nem konfigurálsz semmit és nem keresel hibát semmiben.

Az ágensed kap egy böngészőt, ami működik. Minden alkalommal. Azonnal, minden beállítás nélkül.

Az öt javítás összefoglalva

Ha a self-hostingnál szeretnél maradni, itt a teljes ellenőrzőlista:

  1. Cseréld le a snap Chromiumot a Google Chrome .deb csomagra vagy a Playwright önálló binárisára
  2. Kapcsold be a headless módot: openclaw config set browser.headless true és browser.noSandbox true
  3. Allokálj 8 GB+ RAM-ot vagy adj hozzá 4 GB swapot böngésző-automatizáláshoz
  4. Csatold a megosztott memóriát Dockerben: shm_size: '2gb'
  5. Tedd elérhetővé mind a három portot: gateway, browser control (gateway + 2) és extension relay (gateway + 3)

Vagy hagyd ki a listát. Szerezd meg az asszisztensedet az OpenClaw.rocks-on és bízd ránk az infrastruktúrát.