»Imam ogromne težave z mojim VPS. OpenClaw zdaj ponovno nameščam že tretjič ali četrtič.«

To sporočilo se je pojavilo na OpenClaw Discord prejšnji mesec. Uporabnik ni bil edini. Preglejte kanale skupnosti in našli boste na desetine različic iste teme: orodje za brskalnik odpove, agent ne doseže Chromium, VPS zmanjka pomnilnika, včeraj je vse delovalo, danes pa ne.

Če to berete, ker ste pravkar iskali »OpenClaw brskalnik ne deluje VPS«, ste na pravem mestu. Ta objava pojasnjuje pet stvari, ki se pokvarijo, zakaj medsebojno delujejo na frustrirajoče načine, in kako smo jih vse rešili v Kubernetes operaterju OpenClaw.rocks, da se vam nikoli več ne bo treba ukvarjati z nastavitvijo brskalnika.

Napaka, ki jo vidijo vsi

Najpogostejše sporočilo o napaki v skupnosti OpenClaw je to:

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

Pojavi se na Ubuntu, Debian, v Dockerju, na Hetzner, Hostinger, GCP in povsod drugod, kjer poskušajo poganjati OpenClaw z avtomatizacijo brskalnika. Dnevniki gateway sporočajo »Browser control service ready.« Ampak ko agent poskuša uporabiti brskalnik, poteče časovna omejitev.

Napaka je splošna. Vzroki niso. Obstaja vsaj pet ločenih načinov odpovedi, ki od zunaj izgledajo enako.

Odpoved 1: Snap Chromium in zid AppArmor

Na svežem strežniku Ubuntu 22.04+ ukaz which chromium-browser vrne /usr/bin/chromium-browser. To izgleda pravilno. Ni.

Od Ubuntu 22.04 je privzeti paket Chromium snap. Ko gateway OpenClaw poskuša zagnati to binarno datoteko prek storitve systemd, jo omejitvena plast AppArmor blokira. Paket snap ne more odpreti vrat za razhroščevanje Chrome DevTools Protocol (CDP) skozi peskovnik. Binarna datoteka se zažene, zdi se, da teče, nato pa tiho odpove pri odpiranju vrat, ki jih OpenClaw potrebuje.

V dnevnikih boste videli »Failed to start Chrome CDP on port 18800« ali včasih nič. Proces brskalnika se zažene in umre, preden zapiše eno samo vrstico dnevnika.

Rešitev je namestitev paketa .deb Google Chrome ali uporaba samostojne Chromium binarne datoteke Playwright iz ~/.cache/ms-playwright/. Oba obideta snap peskovnik. A rešitev ni očitna. Zaznavanje brskalnika v OpenClaw preiskuje standardne poti po vrsti, najprej najde snap binarno datoteko in jo poskuša uporabiti. GitHub issue #4978 vsebuje celoten opis.

Odpoved 2: Privzete nastavitve headless, ki predpostavljajo zaslon

OpenClaw se dobavlja z headless: false in noSandbox: false kot privzetimi nastavitvami brskalnika. To ima smisel na Macu ali Windows računalniku z zaslonom. Na VPS zaslona ni. Brez izrecne konfiguracije Chromium poskuša odpreti okno na strežniku za prikaz, ki ne obstaja.

Dve spremembi konfiguracije to rešita:

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

Večina VPS vodičev to omenja. Ampak če sledite standardnim navodilom za namestitev OpenClaw, se nobena od teh vrstic ne pojavi. Namestite, preizkusite brskalnik, odpove. Iščete napako. Najdete blog objavo. Spremenite konfiguracijo. Ponovno zaženete. In pridete do odpovedi številka tri.

Odpoved 3: Nevidni OOM kill

En sam zavihek Chromium z nekaj odprtimi stranmi porabi 2 do 4 GB RAM. Na VPS s 4 GB ne ostane skoraj nič za sam OpenClaw, operacijski sistem in morebitne druge delujoče storitve.

Ko Linux zmanjka pomnilnika, OOM killer jedra zaključi proces, ki porabi največ pomnilnika. To je Chromium. Proces umre. OpenClaw zabeleži časovno omejitev brskalnika. Brez poročila o zrušitvi, brez sledenja sklada, brez namiga, da je bil problem pomnilnik.

Obstaja tudi bolj subtilna različica te težave. Chromium sproži podrejene renderer procese za vsak zavihek. Če se ti ne očistijo pravilno, se kopičijo. En GitHub issue je dokumentiral 39 osirotelih renderer procesov, ki so porabili 3,8 GB RAM na VPS, ki bi moral imeti dovolj rezerve.

Preverite lahko naknadno z dmesg | grep -i "oom\|killed\|chromium", ampak večina ljudi ne pomisli, da bi pogledala tam. Ponovno zaženejo OpenClaw, deluje nekaj minut, nato pa se ponovi.

Uradna stran za zahteve strežnika priporoča najmanj 4 GB za osnovno konfiguracijo. Ampak ta številka predpostavlja odsotnost avtomatizacije brskalnika. Z vklopljenim brskalnikom je 8 GB realistični minimum. Pri Hetzner je to razlika med cpx22 (5 $/mes.) in cpx42 (17 $/mes.).

Odpoved 4: Manjkajoč deljeni pomnilnik Dockerja

Če poganjate OpenClaw v Dockerju (pogosto pri VPS namestitvah), vas čaka še ena past. Privzeti /dev/shm Dockerja je 64 MB. Chromium uporablja deljeni pomnilnik za medprocesno komunikacijo. Ko se izčrpa, zavihki tiho odpovejo ali prikažejo prazne strani.

Rešitev je ena vrstica v docker-compose.yml:

shm_size: '2gb'

Ali izrecno priključite:

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

To ni dokumentirano v vodniku za nastavitev OpenClaw. Gre za vedenje, specifično za Docker, ki vpliva na vsako aplikacijo, ki uporablja Chromium, ampak če še nikoli niste nameščali headless brskalnikov v Dockerju, ne bi vedeli, da to iščete.

Odpoved 5: Trki vrat, na katere nihče ni opozoril

Storitev za nadzor brskalnika OpenClaw teče na ločenih vratih od gateway. Privzeto so to vrata gateway plus 2. Če je vaš gateway na 18789, naj bi bila storitev za nadzor brskalnika na 18791 in relay razširitev na 18792.

V Dockerju, če izpostavite samo vrata 18789, je storitev za nadzor brskalnika nedosegljiva od zunaj vsebnika. Še huje, gateway beleži »Browser control service ready«, tudi ko se vrata 18791 nikoli dejansko ne vežejo. Issue #17584 je sledil temu do gateway, ki je uvažal napačen modul: tak, ki beleži sporočilo »ready«, ne da bi zagnal HTTP strežnik. Dnevnik pravi, da je vse v redu. Vrata so mrtva.

V Kubernetes, če drug vsebnik v istem podu že uporablja vrata 9222 (standardna vrata CDP), funkcija ensurePortAvailable() OpenClaw zazna vrata kot zasedena in zavrne povezavo, tudi če je zasedalec natanko tista instanca Chromium, s katero naj bi OpenClaw komuniciral.

GitHub issue #10994 dokumentira primer, ko je nastavitev VPS uporabnika delovala pravilno. Nato so se po nekaj avtomatiziranih dejanjih vrata CDP zataknila. Edina rešitev je bila najti in ustaviti potepuške procese Chromium, ki so držali vrata.

Zakaj se te odpovedi seštevajo

Vsak od teh petih problemov ima znano rešitev. Ampak medsebojno vplivajo. Rešite težavo s snap in naletite na privzeto nastavitev headless. Popravite konfiguracijo in Chromium se zažene. Teče deset minut, nato udari OOM killer. Dodate swap prostor in zdaj omejitev deljenega pomnilnika Dockerja povzroča tihe napake upodabljanja. Popravite to in odkrijete, da vrata 18791 niso izpostavljena.

Zanke razhroščevanja izgledajo takole: iskanje napake, iskanje delne rešitve, uporaba rešitve, nalet na naslednjo napako, ponovitev. En uporabnik Discorda je opisal, da je celoten operacijski sistem ponovno namestil »tretjič ali četrtič«. Drug je poročal, da je bil brskalnik »nestabilen« po tem, za kar je mislil, da je popolna nastavitev. Tretji je odprl issue z naslovom preprosto »Browser tool consistently fails on VPS«.

Problem ni v tem, da bi bila posamezna popravka težka. Problem je, da jih je pet, odvisne so od vašega specifičnega operacijskega sistema, upravitelja paketov, izvajalnega okolja vsebnikov in ponudnika VPS, in ena sama napaka v verigi pomeni, da brskalnik ne deluje.

Ekipa OpenClaw si zasluži priznanje za stalno popravljanje povezanih hroščev. Zavajajoč dnevnik »ready«, čiščenje osirotelih rendererjev in rokovanje z vrati CDP so se v zadnjih različicah izboljšali. Ampak upstream popravki obravnavajo simptome v kodi OpenClaw. Ne morejo namestiti pravilnega Chromium na vaš strežnik, konfigurirati deljenega pomnilnika Dockerja ali dodeliti dovolj RAM za avtomatizacijo brskalnika. To ostaja vaša odgovornost.

Kako smo Chromium pokvarili trikrat (in kaj smo se naučili)

Vsakega agenta OpenClaw.rocks poganjamo na Kubernetes z našim odprtokodnim operaterjem. Brskalniški sidecar nam je vzel tedne, da je začel pravilno delovati. Naleteli smo na lastno različico vsakega opisanega problema in še nekaj, ki se pojavijo le v kontekstu orkestracije vsebnikov.

Ideja je bila preprosta: poganjajte Chromium kot ločen vsebnik ob OpenClaw, povezan prek CDP. Ena vrstica v Custom Resource in brskalnik preprosto deluje.

spec:
  chromium:
    enabled: true

Takole je ta ena vrstica dejansko nastala.

Zrušitev 1: Napačen uporabnik, datotečni sistem samo za branje

Naš prvi poskus je pognal vsebnik Chromium kot UID 1001 z datotečnim sistemom root samo za branje. Najboljša varnostna praksa. In popolnoma pokvarjeno. Slika browserless pričakuje UID 999 (blessuser), Node.js pa pri zagonu kliče os.userInfo(), kar odpove z ENOENT, ko UID nima vnosa v /etc/passwd. Tudi po popravku UID je datotečni sistem samo za branje preprečil Chromu pisanje začasnih datotek. Sidecar se je zrušil ob vsakem zagonu, preden je zapisal eno vrstico dnevnika. Issue #12 vsebuje celotno zgodbo.

Zrušitev 2: Varnostni zid WebSocket

Z vsebnikom, ki je končno deloval, je bil Chromium aktiven, CDP je odgovarjal na vratih 9222, ampak OpenClaw ga je zavrnil. Gateway se je vezal na LAN IP poda (potrebno za usmerjanje Kubernetes Service), varnostna plast OpenClaw pa je blokirala nešifrirane ws:// povezave na ne-loopback naslove: »SECURITY ERROR: Gateway URL uses plaintext ws:// to a non-loopback address. Both credentials and chat data would be exposed to network interception.«

Legitimno varnostno preverjanje. Ampak v Kubernetes podu vsi vsebniki delijo omrežni namespace. Promet med njimi nikoli ne zapusti vozlišča. Nismo mogli spremeniti varnostnega preverjanja OpenClaw, zato smo dodali nginx reverse proxy sidecar, ki posluša na vseh vmesnikih in posreduje na gateway na loopback. Gateway ostaja varen. Service ostaja dosegljiv. Issue #135 dokumentira razhroščevanje.

Zrušitev 3: Trk vrat 3000

Chromium je tekel. Gateway je imel proxy. Ampak brskalnik se še vedno ni povezal. Slika browserless privzeto uporablja vrata 3000, ki so se trčila z notranjo storitvijo za nadzor brskalnika OpenClaw. Ko smo preklopili na vrata 9222, je ensurePortAvailable() OpenClaw zaznala kot »v uporabi s strani nečesa drugega« in zavrnila povezavo, ker v skupnem omrežnem namespace vrata sidecara izgledajo lokalna.

Rešitev je bila uporaba IP naslova poda (prek Kubernetes Downward API) namesto localhost za CDP URL. Ne-loopback naslov pove OpenClaw, naj uporabi način remote/attach-only: poveže se s tem, kar že teče, namesto da poskuša zagnati lasten brskalnik. PR #183 je to rešil.

Rezultat: pet popravkov, samodejno uporabljenih

Vsaka od teh zrušitev nas je naučila nečesa. Trenutni operater kodira vse to:

Izolacija sidecar. Chromium teče v lastnem vsebniku. Brez snap. Brez Playwright. Brez headless zastavic. Slika browserless poskrbi za vse.

Namenski viri. Sidecar dobi lastne omejitve CPU in pomnilnika (250m-1000m CPU, 512Mi-2Gi RAM privzeto, nastavljivo). Če Chromium preseže omejitev pomnilnika, Kubernetes ponovno zažene le vsebnik brskalnika. Vaš agent teče naprej.

Deljeni pomnilnik. Operater samodejno priključi 1 GB nosilec, podprt s pomnilnikom, na /dev/shm. Brez konfiguracije Docker shm_size.

Usmerjanje vrat. IP poda za CDP URL aktivira oddaljeni način. OpenClaw se poveže s sidecarjem namesto da poskuša zavzeti vrata. Konflikt ensurePortAvailable() izgine.

Vgrajena zaznava proti botom. Mnoge spletne strani zaznajo privzeti headless Chromium in blokirajo avtomatizacijo. Operater podpira extraArgs na Chromium sidecarju, tako da lahko podajate zastavice kot --disable-blink-features=AutomationControlled in uporabniške agente po meri brez gradnje slike vsebnika po meri:

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"

Varnost brez kompromisov. Vse Linux zmožnosti odstranjene, stopnjevanje privilegijev onemogočeno, seccomp RuntimeDefault, non-root UID 999. Brez --no-sandbox kot root.

Kaj to pomeni za vas

Če poganjate OpenClaw na VPS in brskalnik deluje, čestitke. Prebrodili ste pet ločenih načinov odpovedi in prišli na drugo stran. Obdržite svojo nastavitev. Naredite varnostno kopijo konfiguracije.

Če brskalnik ne deluje, ali deluje občasno, ali ste naveličani razhroščevanja Chromium na VPS za 5 dolarjev, premislite, koliko je vreden vaš čas.

OpenClaw.rocks poganja vsakega agenta na Kubernetes z operaterjem, opisanim zgoraj. Brskalniški sidecar je prednastavljen. Pomnilnik je dodeljen. Vrata so usmerjena. Varnost je utrjena. Nič ne nameščate, nič ne nastavljate in nič ne razhroščujete.

Vaš agent dobi brskalnik, ki deluje. Vsakič. Takoj pripravljen za uporabo.

Pet popravkov na kratko

Če želite ostati pri lastnem gostovanju, tukaj je celoten seznam:

  1. Zamenjajte snap Chromium s paketom .deb Google Chrome ali samostojno binarno datoteko Playwright
  2. Omogočite način headless: openclaw config set browser.headless true in browser.noSandbox true
  3. Dodelite 8 GB+ RAM ali dodajte 4 GB swap za avtomatizacijo brskalnika
  4. Priključite deljeni pomnilnik v Dockerju: shm_size: '2gb'
  5. Izpostavite vsa tri vrata: gateway, nadzor brskalnika (gateway + 2) in relay razširitev (gateway + 3)

Ali preskočite seznam. Pridobite svojega asistenta na OpenClaw.rocks in nam prepustite infrastrukturo.