„Mul on tohutu probleem VPS-iga. Installin OpenClaw’d uuesti juba 3. või 4. korda.”

See sõnum ilmus OpenClaw Discordis eelmisel kuul. Kasutaja polnud ainus. Kerige läbi kogukonnakanaalite ja leiate kümneid variatsioone samast teemast: brauseri tööriist ebaõnnestub, agent ei jõua Chromiumini, VPS-il saab mälu otsa, eile töötas kõik ja täna mitte.

Kui loete seda, sest otsisite just „OpenClaw brauser ei tööta VPS”, olete õiges kohas. See postitus selgitab viit asja, mis katki lähevad, miks need frustreerivalt koos toimivad, ja kuidas lahendasime need kõik OpenClaw.rocks Kubernetes operaatoris, et te ei peaks enam kunagi brauseri seadistamisega tegelema.

Viga, mida kõik näevad

Kõige levinum veateade OpenClaw kogukonnas on see:

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

See ilmub Ubuntus, Debianis, Dockeris, Hetzneris, Hostingeris, GCP-s ja kõikjal mujal, kus inimesed üritavad OpenClaw’d brauseri automatiseerimisega käitada. Gateway logid ütlevad „Browser control service ready.” Aga kui agent üritab brauserit kasutada, aegub päring.

Viga on üldine. Põhjused ei ole. On vähemalt viis erinevat tõrkeviiisi ja väljastpoolt näevad need kõik ühesugused välja.

Tõrge 1: Snap Chromium ja AppArmori müür

Värskelt installitud Ubuntu 22.04+ serveris tagastab which chromium-browser tee /usr/bin/chromium-browser. See näeb õige välja. Ei ole.

Alates Ubuntu 22.04-st on vaikimisi Chromiumi pakett snap. Kui OpenClaw gateway üritab seda binaarfaili systemd teenuse kaudu käivitada, blokeerib AppArmori piirangukiht selle. Snap-pakett ei saa Chrome DevTools Protocol (CDP) silumisporte läbi liivakasti siduda. Binaarfail käivitub, näib töötavat, ja siis vaikselt ebaõnnestub pordi avamisel, mida OpenClaw vajab.

Logides näete „Failed to start Chrome CDP on port 18800” või mõnikord mitte midagi. Brauseri protsess käivitub ja sureb enne ühtegi logirea kirjutamist.

Lahendus on installida Google Chrome’i .deb pakett või kasutada Playwrighti iseseisvat Chromiumi binaarfaili kaustast ~/.cache/ms-playwright/. Mõlemad mööduvad snap-liivakastist. Aga lahendus pole ilmne. OpenClaw brauseri tuvastamine skannib standardteid järjekorras, leiab snap-binaarfaili esimesena ja üritab seda kasutada. GitHub issue #4978 sisaldab täielikku kirjeldust.

Tõrge 2: Headless-vaikeseaded, mis eeldavad ekraani

OpenClaw tarnitakse vaikeseadetega headless: false ja noSandbox: false. See on loogiline Macis või Windowsis ekraaniga. VPS-is ekraani pole. Ilma otsese konfiguratsioonita üritab Chromium avada akent kuvariservris, mida ei eksisteeri.

Kaks konfiguratsioonimuudatust lahendavad probleemi:

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

Enamik VPS-juhendeid mainib seda. Aga kui järgite OpenClaw standardseid installimisJuhiseid, ei ilmu kumbagi rida. Installite, proovite brauserit, ebaõnnestub. Otsite viga. Leiate blogipostituse. Muudate konfiguratsiooni. Taaskäivitate. Ja jõuate tõrke number kolmeni.

Tõrge 3: Nähtamatu OOM-tapp

Üks Chromiumi vahekaart mõne avatud lehega tarbib 2 kuni 4 GB RAM-i. 4 GB VPS-is ei jää peaaegu midagi OpenClaw’ile endale, operatsioonisüsteemile ja muudele töötavatele teenustele.

Kui Linuxil saab mälu otsa, lõpetab kerneli OOM-tapja enim mälu tarbiva protsessi. See on Chromium. Protsess sureb. OpenClaw logib brauseri aegumise. Pole krahhiraportit, pole pinu jälge, pole märki, et mälu oli probleem.

On ka selle probleemi peenem versioon. Chromium käivitab iga vahekaardi jaoks alamrenderdusprotsesse. Kui neid korralikult ei puhastata, kuhjuvad need. Üks GitHub issue dokumenteeris 39 orvuks jäänud renderdusprotsessi, mis tarbisid 3,8 GB RAM-i VPS-is, millel pidi olema piisavalt varu.

Saate tagantjärele kontrollida käsuga dmesg | grep -i "oom\|killed\|chromium", aga enamik inimesi ei mõtle sinna vaadata. Nad taaskäivitavad OpenClaw’d, see töötab mõne minuti ja siis juhtub uuesti.

Ametlik serverinõuete leht soovitab põhiseadistuseks vähemalt 4 GB. Aga see number eeldab brauseri automatiseerimise puudumist. Brauseriga sisselülitatuna on 8 GB realistlik miinimum. Hetzneris on see vahe cpx22 (5 $/kuus) ja cpx42 (17 $/kuus) vahel.

Tõrge 4: Dockeri puuduv jagatud mälu

Kui käitate OpenClaw’d Dockeris (VPS-juurutustel tavaline), on veel üks lõks. Dockeri vaikimisi /dev/shm on 64 MB. Chromium kasutab jagatud mälu protsessidevaheliseks suhtluseks. Kui see otsa saab, krahhivad vahekaardid vaikselt või renderdavad tühje lehti.

Lahendus on üks rida teie docker-compose.yml failis:

shm_size: '2gb'

Või monteerige otseselt:

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

Seda pole OpenClaw seadistusjuhendis dokumenteeritud. See on Dockerile omane käitumine, mis mõjutab iga Chromiumi kasutavat rakendust, aga kui te pole kunagi headless-brausereid Dockeris juurutanud, ei teaks te seda otsida.

Tõrge 5: Pordikollisioonid, millest keegi ei hoiatanud

OpenClaw brauseri juhtimisteenes töötab gateway’st eraldi pordis. Vaikimisi on see gateway’i port pluss 2. Kui teie gateway on pordis 18789, peaks brauseri juhtimisteenos olema pordis 18791 ja laienduste relee pordis 18792.

Dockeris, kui paljastate ainult pordi 18789, on brauseri juhtimisteenos konteinerist väljastpoolt kättesaamatu. Veel hullem, gateway logib „Browser control service ready” isegi kui port 18791 kunagi tegelikult ei seostu. Issue #17584 jälitas selle gateway’ni, mis importis vale mooduli: sellise, mis logib „ready” sõnumi ilma HTTP serverit käivitamata. Logi ütleb, et kõik on korras. Port on surnud.

Kubernetesis, kui teine konteiner samas podis juba kasutab porti 9222 (standardne CDP port), tuvastab OpenClaw funktsioon ensurePortAvailable() pordi hõivatuna ja keeldub ühendumast, isegi kui hõivaja on täpselt see Chromiumi instants, millega OpenClaw peaks suhtlema.

GitHub issue #10994 dokumenteerib juhtumi, kus kasutaja VPS-seadistus töötas korrektselt. Siis pärast mõnda automatiseeritud tegevust jäi CDP port kinni. Ainus lahendus oli leida ja tappa eksinud Chromiumi protsessid, mis porti hoidsid.

Miks need tõrked kuhjuvad

Igal nendest viiest probleemist on teadaolev lahendus. Aga nad mõjutavad üksteist. Lahendate snap-probleemi ja satute headless-vaikeseadele. Parandate konfiguratsiooni ja Chromium käivitub. Töötab kümme minutit, siis lööb OOM-tapja. Lisate swap-ruumi ja nüüd Dockeri jagatud mälu limiit põhjustab vaikseid renderdusvigu. Parandate selle ja avastate, et port 18791 pole paljastatud.

Silumistsükkel näeb välja selline: otsida viga, leida osaline parandus, rakendada parandus, sattuda järgmisele veale, korrata. Üks Discordi kasutaja kirjeldas kogu operatsioonisüsteemi uuesti installimist „3. või 4. korda.” Teine teatas, et brauser oli „ebastabiilne” pärast seda, mida pidas täielikuks seadistuseks. Kolmas avas issue pealkirjaga lihtsalt „Browser tool consistently fails on VPS.”

Probleem pole selles, et iga üksik parandus oleks raske. Probleem on selles, et neid on viis, nad sõltuvad teie konkreetsest operatsioonisüsteemist, paketihaldusest, konteineri käituskeskkonnast ja VPS-pakkujast, ning üksainus viga ahelas tähendab, et brauser ei tööta.

OpenClaw meeskond väärib tunnustust seotud vigade pidevate parandamise eest. Eksitav „ready” logi, orvuks jäänud renderdajate puhastamine ja CDP pordi käsitsemine on kõik paranenud hiljutistes versioonides. Aga ülesvoolu parandused adresseerivad sümptomeid OpenClaw koodis. Nad ei saa installida õiget Chromiumi binaarfaili teie serverisse, konfigureerida Dockeri jagatud mälu ega eraldada piisavalt RAM-i brauseri automatiseerimiseks. See jääb teie vastutuseks.

Kuidas me Chromiumi kolm korda katki tegime (ja mida õppisime)

Käitame iga OpenClaw.rocks agenti Kubernetesis meie avatud lähtekoodiga operaatoriga. Brauseri sidecar võttis meil nädalaid, et korrektselt tööle saada. Kohtasime oma versiooni igast ülalkirjeldatud probleemist, pluss mõned, mis ilmnevad ainult konteineri orkestreerimise kontekstis.

Idee oli lihtne: käitada Chromiumi eraldi konteinerina OpenClaw kõrval, ühendatuna CDP kaudu. Üks rida Custom Resource’is ja brauser lihtsalt töötab.

spec:
  chromium:
    enabled: true

Nii see üks rida tegelikult teostus.

Krahh 1: Vale kasutaja, ainult lugemiseks failisüsteem

Meie esimene katse käitas Chromiumi konteinerit UID 1001-na ainult lugemiseks juurkataloogiga. Turvalisuse parim praktika. Ja täielikult katki. Browserless-pilt ootab UID 999 (blessuser) ja Node.js kutsub käivitamisel os.userInfo(), mis ebaõnnestub ENOENT-iga, kui UID-l pole /etc/passwd kirjet. Isegi pärast UID parandamist blokeeris ainult lugemiseks failisüsteem Chrome’il ajutiste failide kirjutamise. Sidecar krahhis iga käivitamise ajal enne ühtegi logirea kirjutamist. Issue #12 sisaldab kogu lugu.

Krahh 2: WebSocket turvamüür

Konteineriga lõpuks töötamas oli Chromium üleval, CDP vastas pordis 9222, aga OpenClaw keeldus seda kasutamast. Gateway sidus end podi LAN IP-ga (vajalik Kubernetes Service’i marsruutimiseks) ja OpenClaw turvakiht blokeeris tavateksti ws:// ühendused mitte-loopback aadressidele: „SECURITY ERROR: Gateway URL uses plaintext ws:// to a non-loopback address. Both credentials and chat data would be exposed to network interception.”

Õigustatud turvakontroll. Aga Kubernetes podis jagavad kõik konteinerid võrgu nimeruumi. Liiklus nende vahel ei lahku kunagi sõlmest. Me ei saanud OpenClaw turvakontrolli muuta, seega lisasime nginx reverse proxy sidecari, mis kuulab kõigil liidesetel ja suunab gateway’le loopbackis. Gateway jääb turvaliseks. Service jääb kättesaadavaks. Issue #135 dokumenteerib silumise.

Krahh 3: Pordi 3000 kollisioon

Chromium töötas. Gateway’l oli proxy. Aga brauser ikka ei ühendunud. Browserless-pilt kasutab vaikimisi porti 3000, mis põrkas kokku OpenClaw sisemise brauseri juhtimise teenusega. Ja kui lülitusime pordile 9222, tuvastas OpenClaw ensurePortAvailable() selle kui „kasutuses millegi muu poolt” ja keeldus ühendumast, sest jagatud võrgu nimeruumis näeb sidecari port välja kohalik.

Lahendus oli kasutada podi IP-aadressi (Kubernetes Downward API kaudu) localhost asemel CDP URL-i jaoks. Mitte-loopback aadress ütleb OpenClaw’ile kasutada remote/attach-only režiimi: ühenduda sellega, mis juba töötab, selle asemel et üritada oma brauserit käivitada. PR #183 lahendas selle.

Tulemus: viis parandust, automaatselt rakendatud

Iga neist krahhidest õpetas meile midagi. Praegune operaator kodeerib selle kõik:

Sidecari isolatsioon. Chromium töötab omas konteineris. Pole snap’i. Pole Playwrighti. Pole headless-lippe. Browserless-pilt tegeleb kõigega.

Pühendatud ressursid. Sidecar saab oma CPU ja mälu limiidid (250m-1000m CPU, 512Mi-2Gi RAM vaikimisi, konfigureeritav). Kui Chromium ületab oma mälulimiidi, taaskäivitab Kubernetes ainult brauseri konteineri. Teie agent jätkab tööd.

Jagatud mälu. Operaator monteerib automaatselt 1 GB mälupõhise köite asukohta /dev/shm. Pole vaja Docker shm_size konfiguratsiooni.

Pordi marsruutimine. Podi IP CDP URL-i jaoks aktiveerib kaugrežiimi. OpenClaw ühendub sidecariga selle asemel, et üritada porti hõivata. ensurePortAvailable() konflikt kaob.

Sisseehitatud anti-bot tuvastamine. Paljud veebisaidid tuvastavad vaikimisi headless Chromiumi ja blokeerivad automatiseerimise. Operaator toetab extraArgs parameetrit Chromiumi sidecaril, et saaksite edastada lippe nagu --disable-blink-features=AutomationControlled ja kohandatud user agente ilma kohandatud konteineripilti ehitamata:

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"

Turvalisus ilma kompromissideta. Kõik Linuxi võimekused eemaldatud, privileegide eskalatsioon keelatud, seccomp RuntimeDefault, mitte-root UID 999. Pole --no-sandbox rootina.

Mida see teie jaoks tähendab

Kui käitate OpenClaw’d VPS-is ja brauser töötab, palju õnne. Olete navigeerinud läbi viie erineva tõrkeviisi ja jõudnud teisele poole. Hoidke oma seadistust. Varundage oma konfiguratsioon.

Kui brauser ei tööta, või töötab juhuslikult, või olete väsinud Chromiumi silumisest 5-dollarilisel VPS-il, mõelge, kui palju teie aeg väärt on.

OpenClaw.rocks käitab iga agenti Kubernetesis ülalkirjeldatud operaatoriga. Brauseri sidecar on eelkonfigureeritud. Mälu on eraldatud. Pordid on marsruuditud. Turvalisus on tugevdatud. Te ei installi midagi, ei konfigureeri midagi ja ei silu midagi.

Teie agent saab brauseri, mis töötab. Iga kord. Kohe kasutusvalmis.

Viis parandust kokkuvõttena

Kui soovite jääda ise-majutamise juurde, siin on täielik kontrollnimekiri:

  1. Asendage snap Chromium Google Chrome’i .deb paketiga või Playwrighti iseseisva binaarfailiga
  2. Lülitage sisse headless-režiim: openclaw config set browser.headless true ja browser.noSandbox true
  3. Eraldage 8 GB+ RAM-i või lisage 4 GB swap’i brauseri automatiseerimiseks
  4. Monteerige jagatud mälu Dockeris: shm_size: '2gb'
  5. Paljastage kõik kolm porti: gateway, brauseri juhtimine (gateway + 2) ja laienduste relee (gateway + 3)

Või jätke nimekiri vahele. Hankige oma assistent OpenClaw.rocksist ja laske meil infrastruktuuriga tegeleda.