„Mám obrovské problémy so svojím VPS. Preinštalúvam OpenClaw po 3. alebo 4. raz.”

Táto správa sa objavila na OpenClaw Discorde minulý mesiac. Používateľ nebol sám. Prejdite komunitné kanály a nájdete desiatky variácií na rovnakú tému: nástroj prehliadača zlyháva, agent sa nedokáže pripojiť k Chromiu, VPS dochádza pamäť, včera všetko fungovalo a dnes nie.

Ak čítate tento článok, pretože ste práve hľadali „OpenClaw prehliadač nefunguje VPS”, ste na správnom mieste. Tento príspevok vysvetľuje päť vecí, ktoré sa pokazia, prečo spolu interagujú frustrujúcim spôsobom, a ako sme ich všetky vyriešili v Kubernetes operátore OpenClaw.rocks, aby ste sa už nikdy nemuseli zaoberať nastavením prehliadača.

Chyba, ktorú vidia všetci

Najčastejšia chybová správa v komunite OpenClaw je táto:

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

Objavuje sa na Ubuntu, Debiane, v Dockeri, na Hetzner, Hostinger, GCP a všade inde, kde sa ľudia pokúšajú prevádzkovať OpenClaw s automatizáciou prehliadača. Logy gateway hlásia „Browser control service ready.” Ale keď sa agent pokúsi použiť prehliadač, vyprší časový limit.

Chyba je všeobecná. Príčiny nie sú. Existuje najmenej päť odlišných módov zlyhania a zvonka vyzerajú všetky identicky.

Zlyhanie 1: Snap Chromium a múr AppArmor

Na čerstvom serveri Ubuntu 22.04+ vráti which chromium-browser cestu /usr/bin/chromium-browser. Vyzerá to správne. Nie je.

Od Ubuntu 22.04 je predvolený balíček Chromium snap. Keď sa gateway OpenClaw pokúsi spustiť tento binárny súbor cez službu systemd, obmedzovacia vrstva AppArmor ho zablokuje. Balíček snap nemôže viazať ladiace porty Chrome DevTools Protocol (CDP) cez sandbox. Binárny súbor sa spustí, zdá sa, že beží, a potom ticho zlyhá pri otvorení portu, ktorý OpenClaw potrebuje.

V logoch uvidíte „Failed to start Chrome CDP on port 18800”, alebo niekedy nič. Proces prehliadača sa spustí a zomrie skôr, než zapíše jediný riadok logu.

Riešením je nainštalovať balíček .deb Google Chrome alebo použiť samostatný binárny súbor Chromium od Playwright z ~/.cache/ms-playwright/. Oba obchádzajú sandbox snap. Ale riešenie nie je zrejmé. Detekcia prehliadača v OpenClaw skenuje štandardné cesty v poradí, nájde binárny súbor snap ako prvý a pokúsi sa ho použiť. GitHub issue #4978 obsahuje úplný popis.

Zlyhanie 2: Headless predvolené hodnoty predpokladajúce displej

OpenClaw sa dodáva s headless: false a noSandbox: false ako predvolenými hodnotami prehliadača. To dáva zmysel na Macu alebo Windows počítači s displejom. Na VPS žiadny displej nie je. Bez explicitnej konfigurácie sa Chromium pokúsi otvoriť okno na serveri displeja, ktorý neexistuje.

Dve zmeny konfigurácie to vyriešia:

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

Väčšina VPS sprievodcov to spomína. Ale ak postupujete podľa štandardných inštalačných pokynov OpenClaw, žiadny z týchto riadkov sa neobjaví. Nainštalujete, vyskúšate prehliadač, zlyhá. Hľadáte chybu. Nájdete blogový príspevok. Zmeníte konfiguráciu. Reštartujete. A potom príde zlyhanie číslo tri.

Zlyhanie 3: Neviditeľný OOM kill

Jedna karta Chromium s niekoľkými otvorenými stránkami spotrebuje 2 až 4 GB RAM. Na VPS so 4 GB nezostane takmer nič pre samotný OpenClaw, operačný systém a akékoľvek ďalšie bežiace služby.

Keď Linuxu dojde pamäť, OOM killer jadra ukončí proces s najväčšou spotrebou pamäte. To je Chromium. Proces zomrie. OpenClaw zaloguje timeout prehliadača. Žiadny crash report, žiadny stack trace, žiadna indikácia, že problémom bola pamäť.

Existuje aj jemnejšia verzia tohto problému. Chromium spúšťa podradené renderer procesy pre každú kartu. Ak nie sú správne vyčistené, hromadia sa. Jeden GitHub issue zdokumentoval 39 osirelých renderer procesov spotrebúvajúcich 3,8 GB RAM na VPS, ktorý mal mať dostatok rezervy.

Môžete to skontrolovať spätne pomocou dmesg | grep -i "oom\|killed\|chromium", ale väčšina ľudí by nenapadlo sa tam pozrieť. Reštartujú OpenClaw, funguje pár minút, a potom sa to stane znova.

Oficiálna stránka serverových požiadaviek odporúča minimálne 4 GB pre základnú konfiguráciu. Ale toto číslo predpokladá absenciu automatizácie prehliadača. So zapnutým prehliadačom je 8 GB realistické minimum. Na Hetzner je to rozdiel medzi cpx22 (5 $/mes.) a cpx42 (17 $/mes.).

Zlyhanie 4: Chýbajúca zdieľaná pamäť Dockeru

Ak prevádzkujete OpenClaw v Dockeri (bežné pri VPS nasadeniach), je tu ďalšia pasca. Predvolený /dev/shm Dockeru je 64 MB. Chromium používa zdieľanú pamäť na medziprocesovú komunikáciu. Keď dôjde, karty ticho padajú alebo renderujú prázdne stránky.

Riešenie je jeden riadok v docker-compose.yml:

shm_size: '2gb'

Alebo namontujte explicitne:

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

Toto nie je dokumentované v sprievodcovi nastavením OpenClaw. Je to správanie špecifické pre Docker, ktoré ovplyvňuje akúkoľvek aplikáciu používajúcu Chromium, ale ak ste nikdy nedeployovali headless prehliadače v Dockeri, nevedeli by ste, že to máte hľadať.

Zlyhanie 5: Kolízie portov, na ktoré nikto neupozornil

Browser control služba OpenClaw beží na samostatnom porte od gateway. Predvolene je to port gateway plus 2. Ak váš gateway beží na 18789, browser control služba by mala byť na 18791 a extension relay na 18792.

V Dockeri, ak vystavíte iba port 18789, browser control služba je nedostupná zvonka kontajnera. Ešte horšie, gateway loguje „Browser control service ready” aj keď sa port 18791 nikdy skutočne nenaviaže. Issue #17584 vystopoval problém ku gateway importujúcemu nesprávny modul: taký, ktorý loguje správu „ready” bez spustenia HTTP servera. Log hovorí, že je všetko v poriadku. Port je mŕtvy.

V Kubernetes, ak iný kontajner v tom istom pode už používa port 9222 (štandardný CDP port), funkcia ensurePortAvailable() OpenClaw detekuje port ako obsadený a odmietne sa pripojiť, aj keď je obsadzujúci práve tá inštancia Chromium, s ktorou by OpenClaw mal komunikovať.

GitHub issue #10994 dokumentuje prípad, keď nastavenie VPS používateľa fungovalo správne. Potom po niekoľkých automatizovaných akciách sa CDP port zasekol. Jediným riešením bolo nájsť a ukončiť zatúlané procesy Chromium blokujúce port.

Prečo sa tieto zlyhania kumulujú

Každý z týchto piatich problémov má známe riešenie. Ale vzájomne interagujú. Vyriešite problém snap a narazíte na predvolenú hodnotu headless. Opravíte konfiguráciu a Chromium sa spustí. Beží desať minút, potom uderí OOM killer. Pridáte swap a teraz limit zdieľanej pamäte Dockeru spôsobuje tiché chyby renderovania. Opravíte to a zistíte, že port 18791 nie je vystavený.

Cyklus ladenia vyzerá takto: hľadať chybu, nájsť čiastočné riešenie, aplikovať riešenie, naraziť na ďalšiu chybu, opakovať. Jeden používateľ Discordu opísal, že preinštaloval celý operačný systém „po 3. alebo 4. raz.” Iný hlásil, že prehliadač bol „nestabilný” po tom, čo považoval za kompletné nastavenie. Tretí otvoril issue s jednoduchým názvom „Browser tool consistently fails on VPS.”

Problém nie je v tom, že by jednotlivá oprava bola ťažká. Problém je, že ich je päť, závisia od vášho konkrétneho operačného systému, správcu balíčkov, container runtime a poskytovateľa VPS, a jediná chyba v reťazci znamená, že prehliadač nefunguje.

Tím OpenClaw si zaslúži uznanie za stabilné opravovanie súvisiacich bugov. Zavádzajúci log „ready”, čistenie osirelých rendererov a spracovanie CDP portu sa v posledných verziách zlepšili. Ale upstream opravy riešia symptómy vo vnútri kódu OpenClaw. Nemôžu nainštalovať správny binárny súbor Chromium na váš server, nakonfigurovať zdieľanú pamäť Dockeru alebo prideliť dostatok RAM pre automatizáciu prehliadača. To zostáva vašou zodpovednosťou.

Ako sme rozbili Chromium trikrát (a čo sme sa naučili)

Každého agenta OpenClaw.rocks prevádzkujeme na Kubernetes s naším open source operátorom. Sidecar prehliadača nám trvalo týždne, kým začal správne fungovať. Narazili sme na vlastnú verziu každého vyššie opísaného problému plus niekoľko, ktoré sa prejavia iba v kontexte orchestrácie kontajnerov.

Myšlienka bola jednoduchá: prevádzkovať Chromium ako samostatný kontajner vedľa OpenClaw, pripojený cez CDP. Jeden riadok v Custom Resource a prehliadač jednoducho funguje.

spec:
  chromium:
    enabled: true

Takto ten jeden riadok skutočne vznikol.

Pád 1: Nesprávny používateľ, súborový systém len na čítanie

Náš prvý pokus spúšťal kontajner Chromium ako UID 1001 so súborovým systémom root len na čítanie. Bezpečnostný best practice. A kompletne rozbitý. Image browserless očakáva UID 999 (blessuser) a Node.js pri štarte volá os.userInfo(), čo zlyhá s ENOENT, keď UID nemá záznam v /etc/passwd. Aj po oprave UID súborový systém len na čítanie bránil Chrome v zápise dočasných súborov. Sidecar padal pri každom štarte skôr, než zapísal jediný riadok logu. Issue #12 obsahuje celý príbeh.

Pád 2: WebSocket bezpečnostný múr

S konečne bežiacim kontajnerom bolo Chromium aktívne, CDP odpovedalo na porte 9222, ale OpenClaw ho odmietol používať. Gateway sa naviazal na LAN IP podu (nutné pre routing Kubernetes Service) a bezpečnostná vrstva OpenClaw blokovala nešifrované ws:// pripojenia na non-loopback adresy: „SECURITY ERROR: Gateway URL uses plaintext ws:// to a non-loopback address. Both credentials and chat data would be exposed to network interception.”

Legitímna bezpečnostná kontrola. Ale v Kubernetes pode všetky kontajnery zdieľajú sieťový namespace. Prevádzka medzi nimi nikdy neopustí uzol. Nemohli sme zmeniť bezpečnostnú kontrolu OpenClaw, preto sme pridali nginx reverse proxy sidecar, ktorý počúva na všetkých rozhraniach a preposiela na gateway na loopback. Gateway zostáva bezpečný. Service zostáva dostupný. Issue #135 dokumentuje ladenie.

Pád 3: Kolízia portu 3000

Chromium bežalo. Gateway malo proxy. Ale prehliadač sa stále nepripájal. Image browserless používa predvolený port 3000, ktorý kolidoval s internou browser control službou OpenClaw. A keď sme prepli na port 9222, funkcia ensurePortAvailable() OpenClaw ho detekovala ako „používaný niečím iným” a odmietla pripojenie, pretože v zdieľanom sieťovom namespace port sidecaru vyzerá ako lokálny.

Riešením bolo použitie IP adresy podu (cez Kubernetes Downward API) namiesto localhost pre CDP URL. Non-loopback adresa hovorí OpenClaw, aby použil režim remote/attach-only: pripojiť sa k tomu, čo už beží, namiesto pokusu spustiť vlastný prehliadač. PR #183 to vyriešil.

Výsledok: päť opráv, aplikovaných automaticky

Každý z týchto pádov nás niečo naučil. Aktuálny operátor kóduje všetko:

Izolácia sidecar. Chromium beží vo vlastnom kontajneri. Žiadny snap. Žiadny Playwright. Žiadne headless flagy. Image browserless sa o všetko postará.

Dedikované zdroje. Sidecar dostáva vlastné limity CPU a pamäte (250m-1000m CPU, 512Mi-2Gi RAM predvolene, konfigurovateľné). Ak Chromium prekročí svoj limit pamäte, Kubernetes reštartuje iba kontajner prehliadača. Váš agent beží ďalej.

Zdieľaná pamäť. Operátor automaticky montuje 1 GB pamäťovo zálohovaný zväzok na /dev/shm. Žiadna konfigurácia Docker shm_size.

Smerovanie portov. IP podu pre CDP URL aktivuje vzdialený režim. OpenClaw sa pripojí k sidecaru namiesto pokusu zabrať port. Konflikt ensurePortAvailable() zmizne.

Vstavaná anti-bot detekcia. Mnohé weby detekujú predvolený headless Chromium a blokujú automatizáciu. Operátor podporuje extraArgs na sidecari Chromium, takže môžete predávať flagy ako --disable-blink-features=AutomationControlled a vlastné user agenty bez zostavovania vlastného image kontajnera:

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"

Bezpečnosť bez kompromisov. Všetky Linux capabilities odobraté, eskalácia oprávnení zakázaná, seccomp RuntimeDefault, non-root UID 999. Žiadne --no-sandbox ako root.

Čo to znamená pre vás

Ak prevádzkujete OpenClaw na VPS a prehliadač funguje, gratulujeme. Prešli ste piatimi odlišnými módmi zlyhania a dostali sa na druhú stranu. Ponechajte si svoje nastavenie. Zálohujte konfiguráciu.

Ak prehliadač nefunguje, alebo funguje sporadicky, alebo vás unavilo ladiť Chromium na VPS za 5 dolárov, zamyslite sa nad tým, koľko stojí váš čas.

OpenClaw.rocks prevádzkuje každého agenta na Kubernetes s operátorom opísaným vyššie. Sidecar prehliadača je predkonfigurovaný. Pamäť je pridelená. Porty sú smerované. Bezpečnosť je posilnená. Nič neinštalujete, nič nekonfigurujete a nič neladíte.

Váš agent dostane prehliadač, ktorý funguje. Zakaždým. Ihneď po nasadení.

Päť opráv v súhrne

Ak chcete zostať pri self-hostingu, tu je kompletný checklist:

  1. Nahraďte snap Chromium balíčkom .deb Google Chrome alebo samostatným binárnym súborom Playwright
  2. Zapnite headless režim: openclaw config set browser.headless true a browser.noSandbox true
  3. Prideľte 8 GB+ RAM alebo pridajte 4 GB swap pre automatizáciu prehliadača
  4. Namontujte zdieľanú pamäť v Dockeri: shm_size: '2gb'
  5. Vystavte všetky tri porty: gateway, browser control (gateway + 2) a extension relay (gateway + 3)

Alebo checklist preskočte. Získajte svojho asistenta na OpenClaw.rocks a nechajte infraštruktúru na nás.