„Imam ogromne probleme sa VPS-om. Reinstaliram OpenClaw 3. ili 4. put.”

Ova poruka se pojavila na OpenClaw Discord-u prošlog meseca. Korisnik nije bio jedini. Pregledajte kanale zajednice i naći ćete desetine varijacija na istu temu: alat pregledača ne radi, agent ne može da dosegne Chromium, VPS-u ponestaje memorije, juče je sve radilo a danas ne.

Ako ovo čitate jer ste upravo pretražili „OpenClaw pregledač ne radi VPS”, na pravom ste mestu. Ovaj članak objašnjava pet stvari koje se kvare, zašto međusobno deluju na frustrirajuće načine, i kako smo ih sve rešili u Kubernetes operatoru OpenClaw.rocks da se nikada više ne morate brinuti o konfiguraciji pregledača.

Greška koju svi vide

Najčešća poruka o grešci u OpenClaw zajednici je:

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

Pojavljuje se na Ubuntu, Debian, u Docker-u, na Hetzner-u, Hostinger-u, GCP-u i svuda drugde gde se pokušava pokretanje OpenClaw sa automatizacijom pregledača. Gateway logovi kažu „Browser control service ready.” Ali kada agent pokuša da koristi pregledač, istekne vremensko ograničenje.

Greška je generička. Uzroci nisu. Postoji najmanje pet različitih načina kvara, a spolja svi izgledaju identično.

Kvar 1: Snap Chromium i zid AppArmor

Na svežem Ubuntu 22.04+ serveru, which chromium-browser vraća /usr/bin/chromium-browser. Izgleda ispravno. Nije.

Od Ubuntu 22.04, podrazumevani Chromium paket je snap. Kada gateway OpenClaw-a pokuša da pokrene tu binarnu datoteku putem systemd servisa, AppArmor sloj ograničenja je blokira. Snap paket ne može da otvori Chrome DevTools Protocol (CDP) portove za debagovanje kroz sandbox. Binarna datoteka se pokrene, izgleda da radi, a zatim tiho ne uspe da otvori port koji OpenClaw treba.

U logovima ćete videti „Failed to start Chrome CDP on port 18800”, ili ponekad ništa. Proces pregledača se pokrene i umre pre nego napiše jedan jedini red loga.

Rešenje je instalirati .deb paket Google Chrome ili koristiti samostalnu Chromium binarnu datoteku Playwright-a iz ~/.cache/ms-playwright/. Oba zaobilaze snap sandbox. Ali rešenje nije očigledno. Detekcija pregledača u OpenClaw-u skenira standardne putanje redom, nalazi snap binarnu datoteku prvu i pokušava da je koristi. GitHub issue #4978 sadrži potpun opis.

Kvar 2: Headless podrazumevane vrednosti koje pretpostavljaju ekran

OpenClaw dolazi sa headless: false i noSandbox: false kao podrazumevanim vrednostima pregledača. To ima smisla na Mac ili Windows mašini sa ekranom. Na VPS-u nema ekrana. Bez eksplicitne konfiguracije, Chromium pokušava da otvori prozor na serveru ekrana koji ne postoji.

Dve promene konfiguracije to rešavaju:

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

Većina VPS vodiča to spominje. Ali ako pratite standardna uputstva za instalaciju OpenClaw-a, nijedan od ovih redova se ne pojavljuje. Instalirate, isprobate pregledač, ne radi. Tražite grešku. Nađete blog post. Promenite konfiguraciju. Restartujete. I dolazite do kvara broj tri.

Kvar 3: Nevidljivi OOM kill

Jedna Chromium kartica sa nekoliko otvorenih stranica troši 2 do 4 GB RAM-a. Na VPS-u sa 4 GB, skoro ništa ne ostaje za sam OpenClaw, operativni sistem i ostale pokrenute servise.

Kada Linux-u ponestane memorije, OOM killer kernela završava proces koji troši najviše memorije. To je Chromium. Proces umire. OpenClaw beleži tajmaut pregledača. Nema izveštaja o padu, nema stack trace-a, nema naznake da je memorija bila problem.

Postoji i suptilnija verzija ovog problema. Chromium pokreće podređene renderer procese za svaku karticu. Ako se ne očiste pravilno, gomilaju se. Jedan GitHub issue dokumentovao je 39 siročadi renderer procesa koji su trošili 3,8 GB RAM-a na VPS-u koji je trebalo da ima dovoljno rezerve.

Možete proveriti naknadno sa dmesg | grep -i "oom\|killed\|chromium", ali većina ljudi ne pomisli da pogleda tamo. Restartuju OpenClaw, radi nekoliko minuta, i onda se ponovi.

Zvanična stranica zahteva servera preporučuje minimum 4 GB za osnovnu konfiguraciju. Ali taj broj pretpostavlja odsustvo automatizacije pregledača. Sa uključenim pregledačem, 8 GB je realistični minimum. Na Hetzner-u, to je razlika između cpx22 (5 $/mes.) i cpx42 (17 $/mes.).

Kvar 4: Nedostajuća deljena memorija Docker-a

Ako pokrećete OpenClaw u Docker-u (uobičajeno za VPS implementacije), postoji još jedna zamka. Docker-ov podrazumevani /dev/shm je 64 MB. Chromium koristi deljenu memoriju za međuprocesnu komunikaciju. Kada se potroši, kartice tiho padaju ili prikazuju prazne stranice.

Rešenje je jedan red u docker-compose.yml:

shm_size: '2gb'

Ili eksplicitno montirajte:

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

Ovo nije dokumentovano u vodiču za podešavanje OpenClaw-a. To je ponašanje specifično za Docker koje utiče na svaku aplikaciju koja koristi Chromium, ali ako nikada niste implementirali headless pregledače u Docker-u, ne biste znali da to trebate tražiti.

Kvar 5: Kolizije portova na koje niko nije upozorio

Browser control servis OpenClaw-a radi na zasebnom portu od gateway-a. Podrazumevano je port gateway-a plus 2. Ako je vaš gateway na 18789, browser control servis bi trebalo da bude na 18791, a extension relay na 18792.

U Docker-u, ako izložite samo port 18789, browser control servis je nedostupan spolja kontejnera. Još gore, gateway beleži „Browser control service ready” čak i kada se port 18791 nikada zapravo ne veže. Issue #17584 pratio je ovo do gateway-a koji je uvozio pogrešan modul: onaj koji beleži poruku „ready” bez pokretanja HTTP servera. Log kaže da je sve u redu. Port je mrtav.

U Kubernetes-u, ako drugi kontejner u istom pod-u već koristi port 9222 (standardni CDP port), funkcija ensurePortAvailable() OpenClaw-a detektuje port kao zauzet i odbija povezivanje, čak i ako je onaj ko zauzima upravo ta Chromium instanca sa kojom OpenClaw treba da komunicira.

Zašto se ovi kvarovi kumuliraju

Svaki od ovih pet problema ima poznato rešenje. Ali međusobno deluju. Rešite snap problem i naiđete na headless podrazumevanu vrednost. Popravite konfiguraciju i Chromium se pokrene. Radi deset minuta, zatim OOM killer udari. Dodate swap prostor, a sada ograničenje deljene memorije Docker-a uzrokuje tihe greške renderinga. Popravite to i otkrijete da port 18791 nije izložen.

Petlja debagovanja izgleda ovako: traži grešku, nađi delimično rešenje, primeni rešenje, naiđi na sledeću grešku, ponovi. Jedan Discord korisnik opisao je reinstalaciju celog operativnog sistema „3. ili 4. put.” Drugi je prijavio da je pregledač bio „nestabilan” nakon onoga što je mislio da je potpuna konfiguracija. Treći je otvorio issue naslovljen jednostavno „Browser tool consistently fails on VPS.”

Kako smo pokvarili Chromium tri puta (i šta smo naučili)

Svakog OpenClaw.rocks agenta pokrećemo na Kubernetes-u sa našim operatorom otvorenog koda. Browser sidecar nam je trebao nedelje da proradi ispravno. Naišli smo na sopstvenu verziju svakog opisanog problema, plus nekoliko koji se pojavljuju samo u kontekstu orkestracije kontejnera.

Ideja je bila jednostavna: pokrenite Chromium kao zaseban kontejner pored OpenClaw-a, povezan putem CDP-a. Jedan red u Custom Resource-u i pregledač jednostavno radi.

spec:
  chromium:
    enabled: true

Rezultat kodira sva naša iskustva: sidecar izolacija (Chromium u sopstvenom kontejneru, bez snap, bez Playwright), posvećeni resursi (sopstveni CPU i memorijski limiti, Kubernetes restartuje samo pregledač ako prekorači), deljena memorija (automatski 1 GB /dev/shm), rutiranje portova (pod IP za CDP URL aktivira remote režim), anti-bot detekcija (podrška za extraArgs na Chromium sidecar-u), i bezbednost bez kompromisa (sve Linux capabilities uklonjene, non-root UID 999).

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"

Šta to znači za vas

Ako pokrećete OpenClaw na VPS-u i pregledač radi, čestitamo. Prošli ste kroz pet različitih načina kvara i izašli na drugu stranu. Zadržite svoju konfiguraciju. Napravite rezervnu kopiju.

Ako pregledač ne radi, ili radi povremeno, ili ste se umorili od debagovanja Chromium-a na VPS-u od 5 dolara, razmislite koliko vredi vaše vreme.

OpenClaw.rocks pokreće svakog agenta na Kubernetes-u sa operatorom opisanim iznad. Browser sidecar je prethodno konfigurisan. Memorija je alocirana. Portovi su rutirani. Bezbednost je ojačana. Ne instalirate ništa, ne konfigurišete ništa i ne debagujete ništa.

Vaš agent dobija pregledač koji radi. Svaki put. Spreman za korišćenje.

Pet popravki ukratko

  1. Zamenite snap Chromium sa .deb paketom Google Chrome ili samostalnom binarnom datotekom Playwright-a
  2. Omogućite headless režim: openclaw config set browser.headless true i browser.noSandbox true
  3. Alocirajte 8 GB+ RAM-a ili dodajte 4 GB swap za automatizaciju pregledača
  4. Montirajte deljenu memoriju u Docker-u: shm_size: '2gb'
  5. Izložite sva tri porta: gateway, browser control (gateway + 2) i extension relay (gateway + 3)

Ili preskočite listu. Nabavite svog asistenta na OpenClaw.rocks i prepustite nam infrastrukturu.