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

Ova poruka pojavila se na OpenClaw Discordu prošlog mjeseca. Korisnik nije bio jedini. Pregledajte kanale zajednice i naći ćete desectke varijacija na istu temu: alat preglednika ne radi, agent ne može dosegnuti Chromium, VPS-u je ponestalo memorije, jučer je sve radilo, a danas ne.

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

Greška koju svi vide

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

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

Pojavljuje se na Ubuntuu, Debianu, u Dockeru, na Hetzneru, Hostingeru, GCP-u i svugdje drugdje gdje ljudi pokušavaju pokrenuti OpenClaw s automatizacijom preglednika. Gateway logovi govore „Browser control service ready.” Ali kada agent pokuša koristiti preglednik, istekne vremensko ograničenje.

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

Kvar 1: Snap Chromium i zid AppArmor

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

Od Ubuntu 22.04, zadani Chromium paket je snap. Kada gateway OpenClawa pokuša pokrenuti tu binarnu datoteku putem systemd servisa, AppArmor sloj ograničenja je blokira. Snap paket ne može otvoriti Chrome DevTools Protocol (CDP) portove za otklanjanje grešaka kroz sandbox. Binarna datoteka se pokrene, čini se da radi, a zatim tiho ne uspijeva otvoriti port koji OpenClaw treba.

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

Rješenje je instalirati .deb paket Google Chromea ili koristiti samostalnu Chromium binarnu datoteku Playwrighta iz ~/.cache/ms-playwright/. Oboje zaobilazi snap sandbox. Ali rješenje nije očito. Detekcija preglednika u OpenClawu skenira standardne putanje redom, nalazi snap binarnu datoteku prvu i pokušava je koristiti. GitHub issue #4978 sadrži potpuni opis.

Kvar 2: Headless zadane vrijednosti koje pretpostavljaju zaslon

OpenClaw dolazi s headless: false i noSandbox: false kao zadanim vrijednostima preglednika. To ima smisla na Macu ili Windows računalu sa zaslonom. Na VPS-u nema zaslona. Bez eksplicitne konfiguracije, Chromium pokušava otvoriti prozor na poslužitelju zaslona koji ne postoji.

Dvije promjene konfiguracije to rješavaju:

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

Većina VPS vodiča to spominje. Ali ako slijedite standardne upute za instalaciju OpenClawa, nijedan od ovih redaka se ne pojavljuje. Instalirate, isprobate preglednik, ne radi. Tražite grešku. Nađete blog post. Promijenite konfiguraciju. Restartate. I dolazite do kvara broj tri.

Kvar 3: Nevidljivi OOM kill

Jedna Chromium kartica s nekoliko otvorenih stranica troši 2 do 4 GB RAM-a. Na VPS-u s 4 GB, ne ostaje gotovo ništa za sam OpenClaw, operativni sustav i bilo koje druge pokrenute servise.

Kada Linuxu ponestane memorije, OOM killer kernela završava proces koji troši najviše memorije. To je Chromium. Proces umire. OpenClaw bilježi timeout preglednika. Nema izvješća o padu, nema stack tracea, 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 dokumentirao je 39 siročadi renderer procesa koji su trošili 3,8 GB RAM-a na VPS-u koji je trebao imati dovoljno rezerve.

Možete provjeriti naknadno s dmesg | grep -i "oom\|killed\|chromium", ali većina ljudi ne pomisli pogledati tamo. Restartaju OpenClaw, radi nekoliko minuta, i onda se ponovi.

Službena stranica zahtjeva poslužitelja preporuča minimum 4 GB za osnovnu konfiguraciju. Ali taj broj pretpostavlja odsutnost automatizacije preglednika. S uključenim preglednikom, 8 GB je realistični minimum. Na Hetzneru, to je razlika između cpx22 (5 $/mj.) i cpx42 (17 $/mj.).

Kvar 4: Nedostajuća dijeljena memorija Dockera

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

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

shm_size: '2gb'

Ili eksplicitno montirajte:

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

Ovo nije dokumentirano u vodiču za postavljanje OpenClawa. To je ponašanje specifično za Docker koje utječe na svaku aplikaciju koja koristi Chromium, ali ako nikada niste implementirali headless preglednike u Dockeru, ne biste znali da to trebate tražiti.

Kvar 5: Kolizije portova na koje nitko nije upozorio

Browser control servis OpenClawa radi na zasebnom portu od gatewaya. Zadano je port gatewaya plus 2. Ako je vaš gateway na 18789, browser control servis bi trebao biti na 18791, a extension relay na 18792.

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

U Kubernetesu, ako drugi kontejner u istom podu već koristi port 9222 (standardni CDP port), funkcija ensurePortAvailable() OpenClawa detektira port kao zauzet i odbija povezivanje, čak i ako je zauzeće točno ona Chromium instanca s kojom OpenClaw treba komunicirati.

GitHub issue #10994 dokumentira slučaj gdje je VPS konfiguracija korisnika radila ispravno. Zatim, nakon nekoliko automatiziranih radnji, CDP port se zaglavio. Jedino rješenje bilo je pronaći i ubiti zalutale Chromium procese koji su držali port.

Zašto se ovi kvarovi kumuliraju

Svaki od ovih pet problema ima poznato rješenje. Ali međusobno djeluju. Riješite snap problem i naiđete na headless zadanu vrijednost. Popravite konfiguraciju i Chromium se pokrene. Radi deset minuta, zatim OOM killer udari. Dodate swap prostor, a sada ograničenje dijeljene memorije Dockera uzrokuje tihe greške renderiranja. Popravite to i otkrijete da port 18791 nije izložen.

Petlja otklanjanja grešaka izgleda ovako: traži grešku, nađi djelomično rješenje, primijeni rješenje, naiđi na sljedeću grešku, ponovi. Jedan Discord korisnik opisao je reinstalaciju cijelog operativnog sustava „po 3. ili 4. put.” Drugi je prijavio da je preglednik bio „nestabilan” nakon onoga što je mislio da je potpuna konfiguracija. Treći je otvorio issue naslovljen jednostavno „Browser tool consistently fails on VPS.”

Problem nije u tome da je svako pojedinačno rješenje teško. Problem je u tome da ih je pet, ovise o vašem specifičnom operativnom sustavu, upravitelju paketa, container runtimeu i VPS pružatelju, i jedna jedina greška u lancu znači da preglednik ne radi.

Tim OpenClawa zaslužuje priznanje za stalno popravljanje povezanih bugova. Obmanjujući „ready” log, čišćenje siročadi renderera i rukovanje CDP portom su se poboljšali u nedavnim verzijama. Ali upstream popravci adresiraju simptome unutar koda OpenClawa. Ne mogu instalirati pravu Chromium binarnu datoteku na vaš server, konfigurirati dijeljenu memoriju Dockera ili alocirati dovoljno RAM-a za automatizaciju preglednika. To ostaje vaša odgovornost.

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

Svakog OpenClaw.rocks agenta pokrećemo na Kubernetesu s našim open source operatorom. Browser sidecar nam je trebao tjedne da proradi ispravno. Naišli smo na vlastitu verziju svakog opisanog problema, plus nekoliko koji se pojavljuju samo u kontekstu orkestracije kontejnera.

Ideja je bila jednostavna: pokrenite Chromium kao zasebni kontejner pokraj OpenClawa, povezan putem CDP-a. Jedan red u Custom Resourceu i preglednik jednostavno radi.

spec:
  chromium:
    enabled: true

Evo kako je taj jedan red zapravo nastao.

Pad 1: Pogrešan korisnik, datotečni sustav samo za čitanje

Naš prvi pokušaj pokrenuo je Chromium kontejner kao UID 1001 s datotečnim sustavom root samo za čitanje. Najbolja sigurnosna praksa. I potpuno pokvareno. Browserless image očekuje UID 999 (blessuser), a Node.js pri pokretanju poziva os.userInfo(), što ne uspijeva s ENOENT kada UID nema /etc/passwd unos. Čak i nakon popravka UID-a, datotečni sustav samo za čitanje blokirao je Chrome od pisanja privremenih datoteka. Sidecar je padao pri svakom pokretanju prije nego je napisao jedan red loga. Issue #12 sadrži cijelu priču.

Pad 2: WebSocket sigurnosni zid

S kontejnerom koji konačno radi, Chromium je bio aktivan, CDP je odgovarao na portu 9222, ali OpenClaw je odbijao koristiti ga. Gateway se vezao za LAN IP poda (potrebno za Kubernetes Service routing), a sigurnosni sloj OpenClawa blokirao je plaintext ws:// veze na ne-loopback adrese: „SECURITY ERROR: Gateway URL uses plaintext ws:// to a non-loopback address. Both credentials and chat data would be exposed to network interception.”

Legitimna sigurnosna provjera. Ali u Kubernetes podu, svi kontejneri dijele mrežni namespace. Promet između njih nikada ne napušta čvor. Nismo mogli promijeniti sigurnosnu provjeru OpenClawa, pa smo dodali nginx reverse proxy sidecar koji sluša na svim sučeljima i prosljeđuje gatewayu na loopback. Gateway ostaje siguran. Service ostaje dostupan. Issue #135 dokumentira otklanjanje grešaka.

Pad 3: Kolizija porta 3000

Chromium je radio. Gateway je imao proxy. Ali preglednik se i dalje nije povezivao. Browserless image zadano koristi port 3000, koji se sudario s internim browser control servisom OpenClawa. A kada smo prešli na port 9222, ensurePortAvailable() OpenClawa ga je detektirala kao „u upotrebi od strane nečeg drugog” i odbila vezu, jer u dijeljenom mrežnom namespaceu port sidecara izgleda lokalno.

Rješenje je bilo korištenje IP adrese poda (putem Kubernetes Downward API) umjesto localhost za CDP URL. Ne-loopback adresa govori OpenClawu da koristi remote/attach-only način: povežite se s onim što već radi umjesto pokušaja pokretanja vlastitog preglednika. PR #183 je ovo riješio.

Rezultat: pet popravaka, automatski primijenjenih

Svaki od ovih padova naučio nas je nešto. Trenutni operator kodira sve to:

Sidecar izolacija. Chromium radi u vlastitom kontejneru. Bez snap. Bez Playwright. Bez headless zastavica. Browserless image se brine za sve.

Namjenski resursi. Sidecar dobiva vlastita CPU i memorijska ograničenja (250m-1000m CPU, 512Mi-2Gi RAM zadano, konfigurirajuće). Ako Chromium premaši svoje memorijsko ograničenje, Kubernetes restarta samo kontejner preglednika. Vaš agent nastavlja raditi.

Dijeljena memorija. Operator automatski montira 1 GB volumen temeljen na memoriji na /dev/shm. Bez Docker shm_size konfiguracije.

Usmjeravanje portova. Pod IP za CDP URL aktivira udaljeni način. OpenClaw se povezuje na sidecar umjesto pokušaja zauzimanja porta. Konflikt ensurePortAvailable() nestaje.

Ugrađena anti-bot detekcija. Mnoge web stranice detektiraju zadani headless Chromium i blokiraju automatizaciju. Operator podržava extraArgs na Chromium sidecaru, tako da možete proslijediti zastavice poput --disable-blink-features=AutomationControlled i prilagođene user agente bez gradnje prilagođenog container imagea:

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"

Sigurnost bez kompromisa. Sve Linux capabilities uklonjene, eskalacija privilegija onemogućena, seccomp RuntimeDefault, non-root UID 999. Bez --no-sandbox kao root.

Što to znači za vas

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

Ako preglednik ne radi, ili radi povremeno, ili ste se umorili od otklanjanja grešaka Chromiuma na VPS-u od 5 dolara, razmislite koliko vrijedi vaše vrijeme.

OpenClaw.rocks pokreće svakog agenta na Kubernetesu s operatorom opisanim iznad. Browser sidecar je prethodno konfiguriran. Memorija je alocirana. Portovi su usmjereni. Sigurnost je ojačana. Ne instalirate ništa, ne konfigurirate ništa i ne otklanjate ništa.

Vaš agent dobiva preglednik koji radi. Svaki put. Spreman za korištenje.

Pet popravaka ukratko

Ako želite ostati na self-hostingu, evo potpune liste:

  1. Zamijenite snap Chromium s .deb paketom Google Chromea ili samostalnom binarnom datotekom Playwrighta
  2. Omogućite headless način: openclaw config set browser.headless true i browser.noSandbox true
  3. Alocirajte 8 GB+ RAM-a ili dodajte 4 GB swap za automatizaciju preglednika
  4. Montirajte dijeljenu memoriju u Dockeru: 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.